IRC channel logs


back to list of 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>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 :))
<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>ok, zzz
<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>you can connect to it...
<paroneayea>if you connect fast
<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>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:
<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?
<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>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
<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
<paroneayea>ok, gimme 5min :)
<paroneayea>gonna double finish off this last bit
<paroneayea>davexunit: alrighty, take a gander!
<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
<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>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 , if you want to take a look at it first
<lloda>deadlock traces
<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>i guess the right thing is to not do range inference over flonums; is that what your patch does?
<davexunit>wingo: yes
<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>all good. I figured it out on my own once I started hacking on it again.
<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.
<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>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
<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>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>amz3: guix package -f guix.scm means to install the package. We don't even have it pointing to a source yet.
<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!
<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 !