IRC channel logs

<wingo>cool, i implemented support for cml operations outside of fibers

<wingo>so you can get-message / send-message from a 'foreign' thread

<wingo>so channels work whether or not you are in a fiber.

<wingo>cool if you have to interact with some other system that's pegged to a certain kernel thread, like a gui

<paroneayea>wingo: I've thought about doing that in 8sync but, since we're running the actor model, it would have to set *something* as the actor id

<paroneayea>but I guess that something *could* be #f.

<paroneayea>er, the from id

<wingo>ACTION nod

<wingo>you could also spin up a temporary actor or something like that

<paroneayea>yeah

<paroneayea>well, it could also be sent from the hive

<paroneayea>which is the meta-actor all actors attach to

<paroneayea>(equivalent to the Vat in E... I think :))

<wingo>:)

<paroneayea>(or rather, there can be multiple hives, but all actors have a hive, and often they're shared.)

<paroneayea>soon I'll work on "inter-hive-communication"... communication between processes, across servers, etc... that will be fun. :)

<wingo>:)

<wingo>ok, zzz

<wingo>night!

<paroneayea>night wingo!

<paroneayea>thanks for the help ttoday

<amz3>héllo all

<sneek>Welcome back amz3, you have 1 message.

<sneek>amz3, paroneayea says: I'm glad you found it interesting :)

<davexunit>wingo: I've gotta take another stab at responding to your feedback. the "few nits" read more like "it's entirely broken"

<davexunit>but I'll take another whack at it. I guess I should just implement what I think I can handle and ask for clarification on the other points.

<davexunit>oh no, looks like the coop repl server is broken in 2.1.5?

<davexunit>not sure if it's guile or my computer yet

<davexunit>ERROR: In procedure select: Interrupted system call

<davexunit>wingo: I hadn't seen mark_weaver's additional email about my patch. needless to say I'm a bit scared of the damage I might do.

<janneke>ACTION -> zZzz

<PuercoPop>I'm having trouble hunting down the repo for the current, or more recent, effort for guile-gir/gtk3 bindings. Does anyone know what is the status?

<paroneayea>davexunit: I get that interrupted system call thing too

<paroneayea>it has something to do with the coop repl server's select

<paroneayea>but!

<paroneayea>you can connect to it...

<paroneayea>if you connect fast

<paroneayea>:)

<paroneayea>and then it'll work until you somehow close your *Guile REPL* buffer

<paroneayea>then you'll need to restart the process

<paroneayea>same thing with something set up with --listen

<paroneayea>davexunit: I've been meaning to file a bug, but that's been my kludgy workaround :)

<davexunit>whaaaa

<davexunit>so weird

<davexunit>paroneayea: thanks for the tip, though.

<davexunit>now, to re-post my floating point comparison patch

<davexunit>the new floating point comparison optimization patch: https://git.dthompson.us/guile.git/commitdiff/53cfdb4d86efaa88ff3b952347fa5a1c202c2359

<davexunit>smaller than the previous version!

<davexunit>I made some mistakes and the solution was simply to remove all of the code in one file that I touched. ;)

<davexunit>paroneayea: fwiw the repl server issue is still happening on latest master

<paroneayea>davexunit: thanks, useful to know

<paroneayea>davexunit: ooh, new patch, yay

<zv>does anyone know if there is a canonical s-expression format doc outside of rivest's?

<paroneayea>zv: I don't know of one

<paroneayea>zv: do you mean the expired IETF submission?

<zv>yeah

<paroneayea>zv: I think canonical s-expressions are pretty great though

<paroneayea>I'm considering writing a pure scheme implementation and possibly use it as a serialization format for inter-process message pasing.

<zv>do you happen to know how much lookahead is required to parse s-expressions by any chance? I am working on one and have never written a 'real' parser before by hand, I figure it would be good to know ahead of time what I should prepare for

<paroneayea>zv: I don't think you need any lookahead for the canonical s-expressions format

<zv>what is implied by 'canonical'?

<paroneayea>zv: "canonical" here means it has a "canonical form"

<paroneayea>the same s-expression can be written in multiple human readable ways

<zv>paroneayea: i.e omitting vectors, N:X forms, etc?

<paroneayea>but it will always be able to be converted to a "canonical form" which will always be the same

<paroneayea>for signing, etc

<paroneayea>zv: if you look at the (ice-9 json) module davexunit wrote some time ago, you could probably write a simple parser that operates somewhat like that

<paroneayea>just recursing into different parsing functions as it sees new data

<zv>yeah, I am doing that now (recursive descent I believe it's called?)

<paroneayea>yeah I think so

<zv>Which brings up one kindof whacky detail

<paroneayea>I'm not very parsing savvy :)

<holomorph>aw man, ice-9 json ;-;

<zv>So, I've heard that with heaps you can just allocate everything required for a graph at once

<zv>I.e there is a way with simple numerical arithmetic to determine "which is the 6th cdr cell", as long as you know how large the set of cdr cells is going to be

<zv>(of course then you dont need to store pointers either)

<zv>Does anyone now much about this?

<zv>err, *know*

<zv>Ok, this isn't really much of a rust issue but I'll shoot anyway -- I've heard that you can allocate trees (and presuambly s-expressions) 'statically' with a heap

<zv>err, sorry, wrong channel, haha

<paroneayea>zv: list-ref

<paroneayea>scheme@(guile-user)> (list-ref '(a b c d) 2)

<paroneayea>$1 = c

<zv>paroneayea: does list-ref not traverse the cdr's?

<davexunit>zv: what do you mean? in paroneayea's example it has to use cdr twice

<zv>davexunit: that was my confusion too

<davexunit>sorry I'm not following you

<davexunit>(list-ref '(a b c d) 2) is the same as (car (cdr (cdr '(a b c d))))

<paroneayea>caddr :)

<paroneayea>zv: davexunit is right

<zv>Yes, that was my understanding too

<paroneayea>it's just a procedure which does that traversal for you... and yes, by cdr'ing

<paroneayea>zv: if you're noticing that accessing a list element is linear, you're right :)

<zv>But my original question was about converting an s-expression to it's 'implicit representation of trees'

<paroneayea>zv: I don't know what that means..

<paroneayea>I think an s-expression is implicitly a tree

<zv>i.e the 5th cdr cell would be root_scm_object + (2*sizeof(root_scm_object) * 5 + 1

<zv>You see what I mean?

<paroneayea>no, sorry I'm lost

<zv>Rather than storing trees as data+pointer, just store the data

<zv>and then use the *index* as the 'pointer'

<paroneayea>zv: you mean, like a vector?

<zv>no

<paroneayea>ok

<zv> http://opendatastructures.org/ods-cpp/10_1_Implicit_Binary_Tree.html

<zv>i think you can do it without using binary trees, but I dont really know.

<zv>(or at least some ordered structure)

<davexunit>like a binary heap?

<davexunit>I have a binary heap implementation that uses a single vector to store the entire tree

<paroneayea>zv: well anyway, you asked

<paroneayea><zv> I.e there is a way with simple numerical arithmetic to determine "which is the 6th cdr cell", as long as you know how large the set of cdr cells is going to be

<paroneayea>maybe I misunderstood

<paroneayea>I thought you were asking how to get to the 6th cdr cell

<zv>oh, ok

<paroneayea>maybe you're talking about an optimization

<paroneayea>?

<zv>davexunit: yes, exactly!

<zv>but for s-expressions!

<davexunit>that structure is not desirable for cons cells

<paroneayea>zv: it may be that for canonical s-expressions you want to use not-cons-cells though

<paroneayea>zv: probably it's fine to use vectors

<davexunit>guix has a canonical s-expression implementation

<davexunit>used for gpg stuff, IIRC

<paroneayea>davexunit: I think it uses the libgcrypt canonical s-expression C implementation

<paroneayea>wraps it

<paroneayea>but doesn't have its own parser

<zv>oh nice

<davexunit>paroneayea: oh okay

<paroneayea>davexunit: maybe that's good enough, though I'd love to have a canonical sexp implementation that's a bit more scheme'y

<davexunit>yeah, would be nice.

<paroneayea>davexunit: still interested in doing a review of the tutorial?

<paroneayea>I'm about to export it

<davexunit>sure

<paroneayea>ok, gimme 5min :)

<paroneayea>gonna double finish off this last bit

<paroneayea>davexunit: alrighty, take a gander! http://dustycloud.org/tmp/8sync-new-manual.html

<davexunit>alright!

<paroneayea>I should cut out the "intro to the tutorial" section

<paroneayea>it's already too wordy, and I didn't end up adding the IRC "game", since I favored having some other simpler actors

<paroneayea>it does start out with an irc bot though!

<davexunit>paroneayea: it's really good so far

<paroneayea>:D

<davexunit>I don't think I'll be able to read all of it

<paroneayea>davexunit: yeah sorry, it's a bit verbose

<davexunit>but so far everything clicks and the example is fun

<davexunit>I can finish reading it tomorrow

<paroneayea>cool

<paroneayea>I'd really love to hear what you think :)

<wleslie>wingo: so it turns out I know one of the people behind grumpy; happens to be a very good VM engineer, did a lot of work on pypy recently

<wleslie>I will get to asking him if he managed to preserve sequential consistency

<nalaginrut>mark_weaver: IIRC, years ago you said you want to use Rope or similar things to enhance Guile string? ;-)

<amz3>PuercoPop: ask david when he comes back

<amz3>OrangeShark: hey, how are you doing?

<lloda>deadlock with n-par-for-each @ block_self, could use help

<sneek>Welcome back lloda, you have 1 message.

<sneek>lloda, efraim says: I'm going to write a more indepth "help with aarch64 port" post later, but as far as I can tell, the crux of my problem can be seen in this diff between stage1 and stage2 of gcc-final, in the libXXX config.log-s https://i.imgur.com/5LP41Il.jpg , if you want to take a look at it first

<lloda>deadlock traces http://paste.lisp.org/+772Y

<lloda>this is on current master fwiw

<wingo>lloda: interesting

<wingo>lloda: are you able to make a minimal test?

<wingo>it's quite possible i borked something there

<lloda>the program is a mess :-( I'll see if I can narrow it down

<efraim>lloda: sorry about that, wrong nick again :/

<lloda>efraim: np :-)

<lloda>gdb 7.12 doesn't support guile > 2.1 :-(

<ArneBab>for the first time in several years, I can use lilypond (on Guile 2.1) to compile my infinite hands sheet notes!

<OrangeShark>amz3: I am doing alright, how about you?

<davexunit>wingo: morning. I sent my updated float comparison patch to guile-devel last night.

<wingo>great

<wingo>i guess the right thing is to not do range inference over flonums; is that what your patch does?

<davexunit>wingo: yes

<wingo>great

<davexunit>I just removed that code entirely

<davexunit>and everything still works as expected for me.

<davexunit>I was rewriting some of linear algebra code last night and checking the disassembly along the way and things looked great.

<davexunit>some of my*

<wingo>yep, makes sense

<wingo>i should have mentioned it in the review mail but i hadn't fully paged the problem back in

<wingo>and only thought of that later while hiking in the woods :)

<davexunit>:)

<davexunit>all good. I figured it out on my own once I started hacking on it again.

<wingo>cool

<davexunit>I just monkey-typed too much

<davexunit>the secret to good performance for my game stuff seems to be define-inlinable and using bytevectors instead of proper structs.

<davexunit>one thing I discovered was that min and max, procedures I use a lot, were causing boxing, so I wrote a specialized, inlinable version in the case that there are only 2 arguments.

<wingo>yep

<davexunit>I wrap the bytevectors in a record type for abstraction purposes which works well.

<davexunit>the user doesn't need to know the sins I've committed.

<davexunit>the last performance related thing I started doing is creating functional and in-place versions of most operations. use the functional ones for elegance in non-critical paths, use the in-place ops when allocation is killing me.

<wingo>i would like a foreign struct data type

<davexunit>same

<davexunit>my SDL2 bindings could benefit from that.

<ArneBab>wingo: lilypond currently uses scm_protects to investigate the elements in the garbage collector. Is there an easy replacement for that in Guile 2.2?

<wingo>that is a bytevector with a tag, which has attached metadata

<ArneBab>(that’s the only thing missing to get lilypond working on Guile 2.2)

<davexunit>wingo: would using record types to wrap up the bytevector and metadata be adequate?

<wingo>ArneBab: scm_gc_protect_object

<ArneBab>that simple… nice! thank you!

<wingo>davexunit: yes but it's a bit more allocation than i'd like

<davexunit>I have a type called <matrix4>, a 4x4 matrix, which is a 16 element f32vector. I wrap that in a record type and cache a pointer object.

<wingo>ArneBab: yw :)

<davexunit>wingo: ah I see.

<ArneBab>wingo: almost … I need something to "Return hash of protected objects"

<wingo>ArneBab: in that case you can make a hash table on your own, scm_gc_protect_object that hash table (though if you focus only on guile >= 2.0 you can just keep it in a static SCM variable) and then use that hash table

<ArneBab>I *think* what lilypond needs is information about the objects for debugging (the function is commented as "debugging mem leaks")

<ArneBab>so not even additional protection, just retrieving the related information

<ArneBab>but maybe it already has that information and the part is just missing in the code…

<ArneBab>it uses scm_gc_protect_object directly. Does that mean that it would have to add a lilypond-managed datastructure which references the protected objects and scm_gc_protect_object that?

<amz3>OrangeShark: I am in a mess, I can't run the test suite

<amz3>OrangeShark: i can't even run the configure script, it got worse

<OrangeShark>amz3: what test suite?

<amz3>OrangeShark: guile-git

<OrangeShark>ah

<davexunit>wingo: if I may bug you one more time: paroneayea and I have noticed that REPL servers are pretty broken on master. I ran 'guile --listen' and see this line in stdout after a client connects: ERROR: In procedure select: Interrupted system call

<OrangeShark>what issue are you having?

<davexunit>for the cooperative REPL server, this error happens after the first call to poll-coop-repl-server and no clients may connect.

<davexunit>I'll file a real bug report, but figured I'd mention it here in case you have thoughts about the cause.

<wingo>davexunit: humm, interesting. i can take a look

<wingo>i mean, i messed with related things recently so it could be i broke something

<paroneayea>it complains about the select

<paroneayea>and there is a select in the coop repl code

<paroneayea>or one of the repl files

<paroneayea>I looked very briefly for the possible cause

<davexunit>wingo: in the 'guile --listen' case, the first client connects fine, then you see the error. try to connect a second client and it will just hang.

<davexunit>since the server thread died but the socket is still open

<davexunit>or maybe the thread didn't die, but it certainly isn't accepting any new clients.

<paroneayea>there's also a timing issue

<paroneayea>if you wait too long to connect

<paroneayea>it'll spit out an error at the console

<paroneayea>and then you won't be able to

<paroneayea>so I think there's some timeout that happens on whatever select is running, and the first thing succeeds

<paroneayea>but then it all goes broken after the timeout or first connection

<paroneayea>that's a *guess*

<OrangeShark>amz3: you can try ./bootstrap to regenerate the configure script

<paroneayea>that's what it looks like

<amz3>OrangeShark: git clean -fxd && ./bootstrap: is ok

<amz3>OrangeShark: then ./configure fails with the following error

<amz3>OrangeShark: http://dpaste.com/36CHGJ7

<amz3>guix package -f guix.scm does fail too

<amz3>my machine is broken

<amz3>I tried to create vm with guix it fails too

<OrangeShark>guix package -l guix.scm

<amz3>really -l?

<OrangeShark>I mean

<OrangeShark>guix envrionment -l guix.scm

<paroneayea>yeah in module/system/repl/(coop-)server.scm

<paroneayea>in both of those there's a select

<paroneayea>and that appears to be what breaks.

<paroneayea>ERROR: In procedure select: Interrupted system call

<paroneayea>is what you see at the terminal once it breaks

<paroneayea>hence that guess

<OrangeShark>*environment

<OrangeShark>amz3: guix package -f guix.scm means to install the package. We don't even have it pointing to a source yet.

<amz3>maybe

<amz3>I though it was supposed to create an environment with the needed dependencies

<amz3>it says there is not guile

<amz3>except guile... wait...

<OrangeShark>no, that was environment

<amz3>guile is pointing to guix's guile so it must be the correct thing

<amz3>let me try environment

<dsmith-work>Thursday Greetings, Guilers

<wleslie>Happy Friday dsmith-work!

<dsmith-work>heh

<wleslie>it's quite a good Friday. not that Thursday was plain, but it's worth looking forward to.

<davexunit>ACTION read's the 8sync tutorial

<davexunit>paroneayea: "Let's try applying that to our own code by turning our manager into a micromanager."

<davexunit>laughed at this

<davexunit>paroneayea: overall I really liked the tutorial!

<davexunit>I'm sure you already know this but there's a bunch of typos or other little nits that one more editing pass would surely uncover.

<davexunit>getting to the network enabled actors part was really cool

<davexunit>paroneayea: one thing that wasn't explained that I'm wondering about is the actor-alive? calls.

<davexunit>the manager and worker both check if they are still alive. shouldn't their threads die if they are no longer alive?

<davexunit>I am now very excited to try applying this to a game

<amz3>maybe I was hacked I don't know... I will update my machine

<OrangeShark>amz3: are you using GuixSD?

<amz3>just guix ontop of ubuntu

<OrangeShark>you are having issues with other parts of your computer too? Or just guile and guix?

<amz3>just guile andd guix

<paroneayea>davexunit: so yeah, I haven't tyop checked it enuf :)

<paroneayea>I'm glad you overall liked it

<paroneayea>about being "alive", so the way an actor runs, it's not exactly in its own thread.

<paroneayea>There are two ways to handle the "letting the loop die off with the actor"

<paroneayea>one is to check actor-alive?, which I figured was easier for the tutorial, but it's good to see that it raises a question, which means maybe I can/should address it

<paroneayea>the other route is to do this

<davexunit>in my little experiments, I would stop continuations from being resumed for the dead thing

<paroneayea>(define (my-actor-loop actor message)

<paroneayea> "Handler for the 'loop action"

<paroneayea> ;; the main "doing something" part of our loop, maybe

<paroneayea> ;; reading a message or churning through some data or something

<paroneayea> (do-something)

<paroneayea> ;; "recurse" on ourselves by calling this same message handler again

<paroneayea> (<- (actor-id actor) 'loop))

<paroneayea>so in this route, the way we send a loop is to recurse on sending a message to ourselves again

<paroneayea>and if our actor is dead

<paroneayea>that message simply won't be delivered

<paroneayea>so it won't be handled

<paroneayea>in a sense it's kind of the same idea of tail call optimization, but with message passing

<paroneayea>I thought bringing that up would make things too confusing

<paroneayea>but now I think I should add that alternate route to the tutorial

<paroneayea>davexunit: does that make sense?

<paroneayea>btw, the actor-alive? procedure is dead simple/dumb

<paroneayea>it just checks if the actor is still registered with its own hive.

<davexunit>I'll have to read this later, gotta go afk!

<davexunit>I'll process it, though

<paroneayea>davexunit: ok, cool. Glad to hear you seem to think it's overall good :)

<paroneayea>and I'll add that to the tutorial.

<paroneayea>later davexunit !

IRC channel logs

2017-01-05.log