IRC channel logs


back to list of logs

<apteryx>ACTION snarfs SRFI 64's documentation
<apteryx>we have only 2 levels worth of section depth when documenting SRFIs :-/ (starts at subsubsection)
<apteryx>err, subsection
<isaneran>wingo: it would be cool to be able to print the native disassembly of procedures from the jit
<yarl>Hello guile.
<dthompson>hello yarl
<yarl>In 7.12 File Tree Walk it is said "Files and
<yarl> directories, as identified by their device/inode number pair, are
<yarl> traversed only once." for file-system-fold, ftw and nftw, but it is not true, right?
<yarl>(sorry about \n)
<dthompson>what makes you suspect it isn't true? I'm not familiar with the implementation
<yarl>I just tried with a simple directory foo with files foo/bar and symlink foo/lbar (being `ln bar lbar`)
<yarl>leaf is called on bar AND lbar.
<dthompson>that's what I would expect
<dthompson>would be weird if it skipped symlinks, I think
<yarl>Not a symlink sorry
<yarl>A link.
<dthompson>oh a hard link
<dthompson>I dunno, someone that knows the file system stuff better should comment. my intuition is that I would still expect to iterate over both since they are both names within the directory
<yarl>And at first I wonder what the second value of file-system-fold was (it's a vhash). Actually, it's a vhash of pairs of (device number, inode) pairs.
<yarl>But in the end it contains only pairs for directories, not files.
<isaneran>dthompson is there a way to get a list of scripts in chickadee?
<yarl>I don't know if I misunderstood the manual or if it's a bug.
<yarl>Or a bug in the manual.
<dthompson>isaneran: are you referring to the chickadee cli or something else?
<isaneran>ah like for example in a repl
<isaneran>Take the example of the script that runs tweens in the info manual
<isaneran>if I run that in a repl multiple times I will start a bunch of scripts and if I don't have a variable reference to them I can't cancel them
<dthompson>tween doesn't start a script, but runs in a script. so if you run a script and keep hold of the handle you can cancel it later.
<isaneran>right, the example uses script to run the tweets
<isaneran>tweens* lol
<isaneran>but what I meant is if I don't have a reference to it, or accidentally overwrite my reference
<isaneran>It would be nice if I could inspect the currently running scripts to get rid of a script that I don't want anymore
<dthompson>you'll be hard pressed to figure out which script to cancel if you don't have a reference to the specific one
<isaneran>yeah though if I can have a list or something of all scripts, then I could write code that collects the scripts I do have a reference of and cancel the ones that aren't in that collection
<dthompson>you could either clear the current agenda entirely, or use different agendas for different purposes so you're clearing things relevant to some subset of what you're doing
<isaneran>ahh, yeah clearing could probably get the work done
<dthompson>it would be possible to write an agenda->alist function or something but there isn't one yet
<dthompson>the agenda uses a mutable binary heap to efficiently order scheduled tasks
<dthompson>it's also possible to yield scripts to things that aren't the agenda, though, so it wouldn't be a general purpose solution
<isaneran>I think the thing I run into is fairly easily done though, you have a (define something (script ...)) and run C-c C-c in geiser, and oops you forgot to cancel the previous version of that script
<dthompson>maybe an agenda-for-each procedure would be the thing
<dthompson>well, no, because actually the agenda has no idea what a script is
<dthompson>it just schedules thunks
<dthompson>there's no global table of scripts
<isaneran>is there a way to put the script in a weak reference box so that if there is no outside reference to it it can be collected and finalized?
<dthompson>the agenda could add support for unscheduling a thunk, but in your case I think you'd have to clear the agenda entirely
<isaneran>though I guess you wanna support just writing (script ..) an have it work
<isaneran>maybe it would be better to add indirection when live debugging a script
<dthompson>in general, scripts have a yield operator, and where their continuation is stored is not known to the system.
<isaneran>like do (define (my-indirection) ...) and call it in the script until you're happy with it
<dthompson>usually it's the current agenda because yielding to wait for time to pass is the most common case
<dthompson>I typically give each game "entity" (however you want to define that) its own agenda
<dthompson>so I can reset a particular entity by clearing its agenda and resetting other state
<dthompson>you might want some helper that keeps a global weak table of scripts
<isaneran>that sounds like a good approach
<dthompson>the other thing is, at the repl, if you *don't* assign the script value to a top-level variable, it will automatically be given a unique name like $42
<dthompson>so you'll have a reference to use for cancelling later
<isaneran>true, though I'm not sure if doing C-c C-c in geiser gives you the value number
<isaneran>but in the repl yeh
<dthompson>oh are you re-evaling the whole buffer?
<isaneran>no just the top level statement
<isaneran>although I guess I sometimes do the whole buffer when coding with geiser
<dthompson>I thought you were cancelling with C-c C-c. I use C-x C-e to eval a statement so I was confused.
<dthompson>or an expression, rather :)
<isaneran>is the command
<dthompson>ohhh okay. I know that as C-M-x. didn't realize it was also bound to C-c C-c
<isaneran>it will eval the current top level statement you are inside, or the one before where you are (if cursor is in toplevel)
<dthompson>yeah I use this all the time
<isaneran>yeah for elisp it's C-M-x
<dthompson>it's also that for geiser :)
<isaneran>oh really!
<isaneran>oh damn, it is
<dthompson>now that I understand you a bit better, I suggest adding a special form for this case.
<isaneran>C-c C-c is pretty convenient to type though
<dthompson>a macro that will check if the existing defined value is a script and cancel it upon redefinition
<isaneran>ah yeah
<isaneran>that's a good idea
<dthompson>perhaps named define-script
<isaneran>Might even be a good addition to the api
<dthompson>(define name (if (and (defined? 'name) (script? name)) (begin (cancel-script name) ...) ...))
<dthompson>yeah it might.
<isaneran>btw, for the livecoding chapter in the manual, it might be good to tell the user to switch the module to chickadee-user after connecting
<dthompson>chickadee is not an engine so it leaves a lot of the dev environment integration up to the programmer, so not sure, but maybe.
<isaneran>yeah that's fair
<isaneran>people have different workflows so
<dthompson>though define-script would be a pretty tiny macro so wouldn't be a big deal to include it
<dthompson>the 'chickadee play' section of the manual recently got changed to mention chickadee-user. the next release will have that clarification.
<dthompson>guess I could duplicate that in the live coding section
<isaneran>I figured it out eventually by doing ,module in the repl
<dthompson>isaneran: glad you are having at least a somewhat decent time with chickadee, though :)
<dthompson>always good to hear from people who are using it
<isaneran>yeah it is fun!
<isaneran>still a chickadee noob though
<dthompson>me too ;)
<attila_lendvai>guile keeps recompiling some .scm.go files, even though the .go is newer than the .scm file. is there a common pitfall that i'm not aware of?
<sneek>Yey! dsmith-work is back
<dsmith-work>sneek, botsnack
<dsmith-work>Happy Friday, Guilers!!
<mhcat>hey guile people, this might just be a scheme question; I see that goblins uses ^ to prefix actor names - r6rs (and the repl) doesn't seem to care where I use ^ in identifiers, but is this a wider convention, a guile convention, or a goblins convention?
<samplet>mhcat: As far as I know, it’s a Goblins thing.
<samplet>I believe it’s that way in Racket, too, and I’ve never seen it elsewhere in Scheme land.
<dthompson>mhcat: samplet is right. it's a goblins naming convention to distinguish actor constructors.
<dthompson>we think of the ^ like a little hard hat. it's a stretch but :)
<dthompson>it's kind of like how things in minikanren end in "o", evalo, appendo, etc.
<mhcat>samplet: dthompson: thanks, that makes sense - I'm finding a lot of cute things in goblins that aren't explained, but I think the docs are all about establishing patterns - and the comparison to little *er style is very helpful in that regard
<dthompson>mhcat: I thought we explained the hard hat thing in the goblins manual, but turns out it's just a footnote in one of our whitepapers
<dthompson>I suppose we should explain the convention in the manual, too
<dthompson>you may enjoy joining the #spritely channel, btw. :)
<mhcat>good idea! I went looking for #goblins which probably fortunately doesn't exist
<festerdam>mwette: I asked this before, but seeing that it isn't in the logs I think it didn't send correctly. I'm sorry for asking this, considering there's documentation. In nyacc in the (nyacc lang c99 parser) module in the parse-c99 function, what's the difference between #:mode 'file and #:mode 'decl? For my hello world program, they generated the same sxml. I was expecting #:mode 'file to not process the
<festerdam>#include <stdio.h> (since the docs say that top-level preprocessor statements aren't evaluated), yet it did (the contents of stdio.h is present in the output). What am I missing?