IRC channel logs

2019-11-15.log

back to list of logs

***daviid is now known as Guest84731
***catonano_ is now known as catonano
<spk121>.
<sneek>spk121, you have 2 messages.
<sneek>spk121, daviid says: whenever you have a few minutes, you could pull and make (the latest g-golf devel branch - that I have enhanced since my last message) and then try/valgrind this g-idle-add example https://paste.debian.net/1116132/ (that I also updated today ...), it should not leak, it doesn't leak here anymore. If/once this is confirmed, I'd be happy to share some knowledge I gained wrt all this, including what i believe is a
<sneek>spk121, daviid says: I suggest read the channel log, I think our bot only got one part of the long sentence I wrote ...
<rozzin>Hey, all...
<rozzin>I'm trying to learn about Guile's VM and figure out what sort of safety assurances there are (if any) against bugs in bytecode programs--or if bytecode is basically not typesafe at all....
<rozzin>Reading through the VM docs and C source, it looks to me like it's actually possible to run a branch instruction with a bogus offset and have the VM end up casting non-opcode data into opcodes and just start trying to execute them--no tag-checks on the opcodes before dereferencing them.
<rozzin>Am I missing something that should be obvious?
<rozzin>Or maybe, "what not-entirely-obvious thing am I ignoring"? Hrm.
<amz3>rozzin: hello, interesting question! come in a few hours or send a mail to the mailing list
<rozzin>Actually I'm pretty sure I'm overlooking something relating to OP() and the the operation-definition APIs..., but I'm not quite sure what--I'm afraid I'm having trouble allocating enough wetware stackspace to understand everything that's going on there.
<amz3>wingo is around GMT+2
<rozzin>I'm -5, here.
<rozzin>Well, the timezone _here_ is -5. My personal timezone is frequently more like -7 or -10.... ;)
<amz3>try the mailing list then: https://lists.gnu.org/mailman/listinfo/guile-user
<rozzin>Well, there's a question, actually--
<amz3>or: https://lists.gnu.org/mailman/listinfo/guile-devel
<rozzin>is this line of inquiry appropriate for guile-user, or should I be posting to guile-devel instead?
<amz3>rozzin: dunno!
<amz3>rozzin: I would say guile-user is fine.
<amz3>guile-devel is more like for submitting patches or coordinating work ?
<rozzin>I remember when Keisuke started the whole guile-vm thing 20 years ago those discussions were on guile-user.
<rozzin>Though that was... OMG that was a long time ago :)
<amz3>rozzin: are you looking at master branch or a stable branch?
*rozzin . o O ( OMG I've been using Guile for over 20 years... )
<rozzin>I've been looking at both 2.2 and 2.0.
<amz3>2.0 is deprecated.
<rozzin>Obviously :)
<amz3>and 2.9 and 3.x have major changes (like a JIT)
<rozzin>So I've been trying to focus on 2.2;
<rozzin>I noticed that the "unboxed arithmetic" ops came in for 2.2, coincidentally along with the register VM.
<amz3>I tried to read the vm code once or twice but not enough to understand a thing.
<amz3>I would like at some point add wasm target. I know what I want the target code to look like, but I am clueless about how to do it
<rozzin>I tried to read Racket's last week; Guile's seems pretty straightforward by comparison....
<amz3>oh really
<amz3>I started my compilation course with nanopass framework
<amz3>(self-learning)
<amz3>never read racket code
<amz3>rozzin: I am working on a search engine
<amz3>sneek: what is culturia
<sneek>Last time I checked culturia is a re-search project
<rozzin>It felt like I was spending too much time staring at Racket's source and not really being able to make heads or tails of it (er..., cars or cdrs?), and so I set it aside and went looking at Guile instead....
<rozzin>And, actually--then I heard a rumor that there had been some discussion about trying to plug Guile in as a back-end for Racket....
<rozzin>That would be kind of exciting.
<amz3>I prefer r7rs
<rozzin>Oh?
<amz3>I am not sure what is appealing to racket, I don't know much of racket ouside the step macro expander.
<amz3>at least for my work, racket is not suitable, I need native threads.
<amz3>(and greenthreads)
<rozzin>"Racket continues to have everything" https://octodon.social/@cwebber/99796414911796158
<rozzin>amz3: more background on that: "A Guiler's Year of Racket" https://archive.fosdem.org/2019/schedule/event/guileracket/
<amz3>Yes, I saw that.
<amz3>there was several post on guile mailing list about it.
<spk121>rozzin: true. It is the bootstrapping problem: to be popular, you need to have everything. To have everything, you need to be popular. But Guile is more popular now than 5 years ago, and is starting to get more of the necessary libraries completed.
<rozzin>spk121: Yes. And apparently guile is where all of the VM work is happening..., which is actually what I'm interested in at the moment :)
<rozzin>The impression I have is that Racket's VM situation seems to be that there hasn't really been significant VM work in at least a decade, and at this point it looks like they're more interested in just doing direct-to-native compilation since Chez Scheme became available for use as a back-end and mostly giving up on the VM?
<rozzin>spk121: "Phosphorous, The Popular Lisp" http://web.archive.org/web/20090715095034/http://lambda-the-ultimate.org/node/3488
<spk121>rozzin: lol
<rozzin>That paper really is a gem....
<amz3>is it terse?
<amz3>(reference to bel language)
<spk121>amz3: you should make a terse version of Scheme by giving each RnRS procedure an alias which is a single Hanzi character. And you could shrink the parens by making them accents.
<Harzilein>spk121: heh
<Harzilein>spk121: and i thought that arabic rtl (naturally) lisp someone made as an art project was weird
<Harzilein>does the japanese r5(?)ns translation have kanji translations for the procedure names?
<Harzilein>rs*
***ng0_ is now known as ng0
<civodul>Hello Guilers!
<marusich>Why is it correct for (vhash? (vhash-delete "foo" (vhash-cons "foo" "bar" vlist-null))) to evaluate to #f?
<marusich>I am surprised by this. I expected vhash-delete to evaluate to a vhash, i.e., something that would always evaluate to #f when passed to vhash?.
<marusich>Let me rephrase my last sentence. I am surprised by this. I expected vhash-delete to evaluate to a vhash, i.e., something that would always evaluate to #t when passed to vhash?.
*civodul just looked at wip-exceptions, it's awesome!
<civodul>hi marusich!
<civodul>marusich: i think (vhash? vlist-null) => #false
<civodul>that's what you're seeing here
<civodul>it's debatable whether vhash? should return true in this case, but that's how it is
<wingo>o/
<chrislck> \o
<wingo>:)
<wingo>tx for wip-exceptions review civodul
<civodul>hi wingo!
<civodul>that's a super high-level "review" ;-)
<civodul>it was interesting looking at it, and i'm really happy with this direction
<civodul>oh, another question: i think the record hierarchy is not officially documented, right?
<civodul>perhaps on purpose?
<wingo>civodul: there is documentation in make-record #:parent i think
<wingo>er make-record-type
<wingo>and also of course r6rs documents it, and exceptions document it
<wingo>what other documentation were you thinking might be needed?
<civodul>wingo: oh you're right, then i guess nothing's missing
<civodul>just an oversight on my part
<wingo>np
*wingo goes to finish r7rs stuff
<wingo>we have way too much srfi-1 things implemented in c :P
<civodul>heh, remnants of the past!
<civodul>BTW, 9de674e6e63ed1576c5b0660ac709f430822dbcf rewrote 'map' to be recursive to show off expandable stacks :-)
<civodul>do you remember how it affected performance, if at all?
<wingo>civodul: iirc it was equivalent.
<civodul>neat
<civodul>it makes backtraces less readable though
<wingo>but of course you can test. hard to test tho because it's basically an allocation benchmark
<civodul>because you can see all these map1 calls
<civodul>yeah
<wingo>civodul: hey is there something in guile that will (f "ßa") -> "SSA" besides string-locale-upcase ?
<wingo>srfi-13 string-upcase is restricted in that the result will have the same number of characters as the argument
<rozzin>wingo: good morning. Did you see my questions about bytecode/VM safety in your scrollback? :)
<RhodiumToad__>converting even ascii characters to uppercase correctly requires knowing the locale
***RhodiumToad__ is now known as RhodiumToad
<wingo>rozzin: no i missed them :) link?
<civodul>wingo: no it's just string-locale-upcase with a de_* locale
<wingo>my locale isn't de_* but it does produce ßa -> SSA
<civodul>ah perhaps that bit is duplicated in most locales
<civodul>because that's the only meaningful result anyway
<wingo>yeah
<civodul>ßa vs. cps
<rozzin>wingo: like to a web archive (is there such a thing?), or to a timestamp?
<rozzin>Oh, right--I see the URL in the welcome-message.
<rozzin>Oh, wrong--"The requested URL /bot/log/guile was not found on this server."
<rozzin>wingo: is there an updated archive base URL? The URL that ChanServ gave me is apparently wrong (or broken): "ChanServ‎: [notice] [#guile] Welcome to #guile! This channel is logged, see <https://gnunet.org/bot/log/guile>."
<chrislck>logs.guix.gnu.org/guile/
<rozzin>chrislck: thanks
<rozzin>wingo: http://logs.guix.gnu.org/guile/2019-11-15.log
<dsmith-work>Happy Friday, Guilers!!
<civodul>hey dsmith-work
<civodul>Happy Friday!
<davexunit>does guile have any handy dandy procedures for reading fixed point numbers from bytevectors?
<davexunit>I haven't found anything in my search
<davexunit>for some reason I decided, against all better judgement, to try writing a truetype font parser and there's a bunch of cases where some bytes are to be interpreted as fixed point numbers of various precision. probably I will just have to write my own procedure to do it.
<davexunit>but it's yet another yak to shave on this silly journey full of other yaks
<dsmith-work>davexunit: fixed point? Never seen that in guile.
<davexunit>neither have I :) I don't think it exists but worth asking
<davexunit>sometimes there's an undocumented life changing procedure somewhere
<dsmith-work>Heh
*dsmith-work used to hack on Analog Devices fixed-point DSP's years ago
<davexunit>truetype files are... strange.
<davexunit>they seem easy to parse at first glance but they aren't.
<amz3>if you by fixed point numbers you mean numbers encoded using a fixed number of bytes, you may look at industria struct pack procedure
<amz3>or bytevector as integer chapter from the documentation
<dsmith-work>fixed point numbers are "integers" but with the decimal point in the middle somehere instead of at the end.
<amz3>ok.
<amz3>tx.
***apteryx_ is now known as apteryx