IRC channel logs

2013-09-15.log

back to list of logs

<dsmith-w32>Howdy Guilers
<taylanub>Wohoo, I found the following comment in control.scm in scm_c_abort: /* Only reify if the continuation referenced in the handler. */
<taylanub>So prompts don't heap-copy any stack frames if the continuation passed to the handler isn't referenced.
<foeniks>hi I am using the http web server of guile web package along the lines of the manual's example
<foeniks>thinks work mostly, yet I experience problems with the connection
<foeniks>i.e.
<foeniks>I start the server
<foeniks>load the page
<foeniks>everything is fine
<foeniks>but reloading it or sending another request takes for ages
<foeniks>"Waiting for localhost"
<foeniks>and then it works again when I open a new browser tab
<add^_>sneek: later tell davexunit I've been watching some touhou 6 videos, the game seems just so... awesome! Is this a place you've gotten some of your inspiration from?
<sneek>Will do.
<add^_>sneek: botsnack
<sneek>:)
<add^_>lol
*add^_ should have waited just a couple of minutes
<taylanub>Ah, those old arcade shoot'em up thingies ... well I only ever played them on emulators. :P
<add^_>heh
<davexunit>happy sunday guilers
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, add^_ says: I've been watching some touhou 6 videos, the game seems just so... awesome! Is this a place you've gotten some of your inspiration from?
<add^_>:-)
<add^_>Same to you davexunit
<davexunit>add^_: oh absolutely. I love Touhou.
<add^_>:-D
<davexunit>there's a version of the game called danmakufu that lets you write your own scripts
<davexunit>that's where I got inspired
<add^_>I've watched a video on someone who plays on lunatic difficulty, it's... insane.
<add^_>Aha
<davexunit>I had been learning emacs and was loving lisp, and then I saw the danmakufu code and how ugly it was.
<add^_>ah
<davexunit>it was this custom C-like language that ZUN (the author) must have made his own VM for.
<add^_>Uh
<davexunit>it had a yield keyword for making coroutines
<davexunit>so I thought: let's try to make something like this and use a lisp DSL for writing the game scripts?
<add^_>ah
<add^_>Nice
<davexunit>and here I am. 1 year later and still not there. :P
<add^_>Meh
<davexunit>I started gnumaku, and then gshmup with an allegro 5 wrapper, and now guile-2d
<add^_>But your still working on it
<add^_>I keep losing interest in my projects :-/
<davexunit>guile-2d is by far the most useful since I've made something that can be used for many games and not just what I plan on doing.
<davexunit>add^_: I've lost interest in tons of projects
<davexunit>which is why I now try to show off my projects frequently. when other people say "that's cool", it's a good sign and motivation to continue.
<add^_>Well, perfectstorm is about to end up being put on hold, which I don't really want but I kinda feel like.. Meh.
<add^_>Although that's a CL project
<add^_>It's still a project
<add^_>perfectstorm's revival*
<davexunit>what is perfectstorm?
<add^_>the RTS game thingy made by cupe in #lispgames
<add^_>But that was back in 2008, I just fixed it up
<add^_>to it's former "glory"
<davexunit>oh cool
<add^_>But since noone seems interested, it's kinda...
<add^_>Boring to work on, AND it's not scheme
<davexunit>have you advertised it at all?
<add^_>I don't care about other people, I want to have fun working on it, I've advertised it only in #lispgames and lispgames.org
<davexunit>ah, okay.
<add^_>Not outside people
<davexunit>is it not fun to work on?
<add^_>Not when your alone and in a language your not very happy to work with
<add^_>Smaller projects are ok, but a large project like that is a bit much for me
<davexunit>well then I suppose you're right to lose interest.
<add^_>:-/
<add^_>I kinda wish someone else would pick it up for me, but I suppose that wont happen..
<add^_>Although, maybe I could use the pathfinding and quadtree code and convert it to scheme and help you ;-)
<add^_>:-)
<davexunit>:)
<davexunit>I'm pushing that stuff off until after the 0.1 release, which I can hopefully release *real soon now*
<add^_>Nice
<davexunit>I really want to have this released by the GNU 30th birthday.
*davexunit is wondering how other libraries manage sprite animations...
<davexunit>they have to be updated every tick, but I don't want the user to have to manually update every sprite that uses an animation... hmmm.
<add^_>:-)
*davexunit is reading the pyglet source
<davexunit>a-ha. I see how they did it.
<davexunit>but, if I implement this in scheme and the animation loops, the sprite will never get GC'd...
***Guest89641 is now known as micro`
<davexunit>I have a procedure naming question:
<davexunit>I have a type, foo, which has a constructor and several procedures that use that type.
<davexunit>I see that the convention is naming the constructor make-foo
<davexunit>and procedures that get foo object attributes are named like foo-attribute
<davexunit>now, when I am writing higher level procedures on top of these primitives, do I use the *-foo naming style, or foo-* ?
<ijp>afternoon
<add^_>davexunit: I'm not sure what's the most used, but I'd use foo-*
<add^_>Probably at least
<add^_>Sometimes I just go for the more grammatically correct one...
<davexunit>add^_: yeah I think I'll go with that
<davexunit>I followed the *-foo naming style for things like: draw-sprite, update-agenda
<davexunit>and I guess they should be renamed to sprite-draw and agenda-update
<add^_>hmm
<add^_>You might want to ask others for their opinion too :-)
<add^_>I need to find a good paper explaining the a* algorithm..
<add^_>Meh, wikipedia will have to do..
<davexunit>you can do it!
<add^_>:-P
<davexunit>divide and conquer
<add^_>ERROR: Devided by zero, crash burn and die.
<add^_>:-)
<davexunit>D:
<add^_>lol
<add^_>You ran a script on me which failed ;-)
<add^_>Anyway, davexunit, what did you mean?
<add^_>I was just joking around without knowing what you meant
<davexunit>add^_: divide a* up into many small problems that you can solve.
<add^_>ah
<add^_>right
<add^_>^^
<add^_>Well, I actually will have to do this later as I'm having dinner now and have to go away right after that :-(
<add^_>So... cya later.
<add^_>Gosh, thunder, need to shut off :-S
<ArneBab>sneek: later tell mark_weaver for wisp itself, only a new top-level datum or EOF close all parens. But in the REPL, any two consecutive blank lines (really blank, no whitespace, no comments) end the expression.
<sneek>Okay.
<ArneBab>sneek: later tell mark_weaver so the semantics are slightly different for the REPL and files. In the python REPL one single empty line triggers the reading, but that creates quite a few problems (people often use single blacnk lines to separate logical parts of the code)
<sneek>Okay.
<ArneBab>sneek: later tell mark_weaver so in the wisp REPL, the separator is two consecutive empty lines
<sneek>Will do.
<ArneBab>sneek: later tell mark_weaver in python 2 consecutive empty lines are normally used to separate function definitions. If that is similar in scheme, they should be safe in the REPL.
<sneek>Will do.
<ArneBab>sneek: botsnack
<sneek>:)
<taylanub>Good idea there, that REPL/file difference in Python can be quite annoying AFAIK.
*taylanub still thinks people should submit to parens/Paredit and be done with it but w/e. :P
<mark_weaver>ArneBab: Guile makes no provision for different syntax at the REPL than in a file.
<sneek>mark_weaver, you have 4 messages.
<sneek>mark_weaver, ArneBab says: for wisp itself, only a new top-level datum or EOF close all parens. But in the REPL, any two consecutive blank lines (really blank, no whitespace, no comments) end the expression.
<sneek>mark_weaver, ArneBab says: so in the wisp REPL, the separator is two consecutive empty lines
<mark_weaver>ArneBab: is it necessary to have a different syntax at the REPL? Remember that it's possible to generate EOF at the REPL using Ctrl-D.
***anderson is now known as Anderson
<ArneBab>mark_weaver: two empty lines are a convenience feature, because Ctrl-D also closes guile, so if you by accident hit it twice, you finish your guile session. And if you by accident hit it thrice, you log off…
<ArneBab>mark_weaver: The problem is that you cannot visually distinguish an empty line from a line with only whitespace in a file.
<ArneBab>mark_weaver: but when functions get bigger, people will likely want to use two empty lines in files (at least that’s what happens in python).
<ArneBab>If you use (define) inside (define) inside (define), you might want to separate the second define more strongly from the sourrounding code.
<ArneBab>taylanub: yes, the difference can get quite annoying in python…
<ArneBab>mark_weaver: but splitting on two empty lines makes it possible to copy-paste code and have it actually ealuated.
<ArneBab>you cannot easily include an EOF in text copied from a website…
<mark_weaver>well, I suppose you could make two different languages: wisp-repl and wisp.
<mark_weaver>maybe I'm being too fundamentalist, but the idea of the language being different at a REPL than in a file seems gross to me.
<mark_weaver>how about saying that two or more empty lines (where empty lines can include whitespace, but no comments) closes all brackets?
<dje42>Why does scm_error_scm take key,subr,message,args,data arguments but the catch handlers for scm_c_catch only take key,args arguments?
<ijp>the answer is probably historical reasons
<mark_weaver>dje42: scm_throw is the low-level analogue, where the 'key' and 'args' are given directly to catch.
<mark_weaver>dje42: however, for most kinds of exceptions, there is a conventional meaning to the arguments, and 'scm_error_scm' reflects that.
<dje42>Suppose I want the catch handler to call scm_display_error based on various conditions?
<dje42>subr,message are lost.
<mark_weaver>if you invent your own exception key, then you can use whatever args you like.
<ijp>they aren't lost
<dje42>Awesome. Where are they? :)
<mark_weaver>the 'args' passed to 'scm-error' is only one of the elements of the list passed as 'args' to the catch handler.
<dje42>I'm guessing I need to funnel them into the "args" argument to the catch handler. It's not immediately clear how to do that. Maybe I'm looking at it the wrong way.
<mark_weaver>(catch #t (lambda () (scm-error 'key 'subr "message" (list 'some 'args) 'data)) (lambda (key . args) (cons key args)))
<mark_weaver>=> (key subr "message" (some args) data)
<mark_weaver>see. nothing is lost.
<mark_weaver>'scm-error' is the same as 'scm_error_scm'.
<dje42>So I'm correct in inferring that "args" to scm_display_error is not "args" to the scm_c_catch handler?
<ijp>it's more obvious if you look at the prototype of scm_throw
<ijp>which has two arguments KEY and ARGS
<ijp>for error to use that, it coalesces those into a list, and then throws it
<ijp>ERR_TOO_MANY_PRONOUNS
<dje42>Changing the name of one of those "args" parameters would be NICE!
<dje42>thx!
<mark_weaver>dje42: 'scm_display_error' looks at the 'key', and if it recognizes the key, it tries to do a nicer job of displaying the error, based on the convention meaning of the 'args' list for that exception type.
<add^_>Hm
<add^_>Hello again all!
<ijp>there's actually a lot of neat stuff in libunistring I hadn't noticed before
<ijp>like word and line breaking
<dje42>I found scm_handle_by_message_noexit and scm_print_exception which look promising. I couldn't find them in the docs.
<dje42>I can pass key,args to scm_handle_by_message_noexit in my catch handler and get the desired output. haven't tried it yet.
<dje42>The "handler_data" parameter to throw.c:handler_message is either no longer used or a work-in-progress.
<dje42>Or maybe scm_handle_by_message_noexit is intended to be passed as a catch handler. Doh.
<dje42>Still, the comment string for throw.c:scm_handle_by_message describing HANDLER_DATA is misleading then.
<mark_weaver>dje42: stepping back for a moment: what are you trying to do?
<mark_weaver>dje42: if you just want exceptions to be printed nicely, 'call-with-error-handling' might be a good choice.
<dje42>Catch and print a Scheme error when called from C.
<dje42>For example,
<mark_weaver>dje42: how about using 'scm_print_exception' ?
<mark_weaver>you can pass SCM_BOOL_F for the 'frame' argument.
<mark_weaver>dje42: actually, you're probably right that 'scm_handle_by_message_noexit' will be more convenient.. sorry for the distraction.
<mark_weaver>(In my programs, C is used only for extensions to Guile. The main program is always Guile itself.)
<dje42>Suppose a gdb conditional breakpoint is implemented in Scheme. If a Scheme exception occurs I want to print the error, maybe a stack trace (under user control).
<dje42>Sorry for the delay in completing the example ... got pulled away for a bit.
<dje42>Yeah, in my case Guile is the subordinate, gdb is "in control".
<mark_weaver>*nod*
<mark_weaver>dje42: how about wrapping the user-provided Scheme code in a wrapper that uses 'call-with-error-handling' ?
<mark_weaver>that provides the most flexibility, allowing optional backtraces, interactive Scheme debugging, etc.
<dje42>I currently have it wrapped in scm_c_catch, and printing the exception from the pre_unwind_handler.
<mark_weaver>in general, doing more of the work from Scheme and less from C will be easier and more featureful.
<dje42>Righto. Using scm_c_catch seemed easy enough at the start.
<mark_weaver>basically, instead of calling the user-provided Scheme procedure directly, you could call your own Scheme procedure, with the user-provided procedure as an argument.
<dje42>I also need to block continuation capture. e.g. I can't re-enter Scheme with an earlier copy of gdb's stack.
<mark_weaver>and then your Scheme procedure could wrap the user-provided procedure with 'call-with-error-handling'.
<mark_weaver>dje42: see 'with-continuation-barrier' (or 'scm_with_continuation_barrier')
<mark_weaver>that could also be part of the Scheme wrapper.
<dje42>Thx. I found them, just haven't plugged them in yet.
<dje42>Righto.
<mark_weaver>dje42: here's what such a wrapper might look like: http://paste.lisp.org/display/138998
<dje42>thx
<ArneBab>mark_weaver: a problem when you cannot use more than 2 empty lines is for example when you have continuous testing as with flymake in emacs: You cannot add 3 empty lines and then start filling it.
<ArneBab>mark_weaver: but even for scheme the REPL is different from the file. It offers tools like ,trace and ,time
<ijp>tools not syntax
<ijp>nothing stopping you from ,trace (load "")
<ArneBab>so you could simply treat this as a tool which adds an EOF when you add 2 empty lines
<ijp>and all those should be available as normal scheme procedures and macros
<ijp>except the debugging ones
<ArneBab>that’s what I have in the wisp-parser: read-chunk reads up to the next 2 empty lines or EOF
<mark_weaver>well, the immediate problem is that Guile's language support simply doesn't support different syntaxes for REPL vs non-
<mark_weaver>...non-REPL.
<mark_weaver>the REPL commands are always at the beginning of the REPL, and that's not part of the language itself.
<mark_weaver>beginning of the input, I mean.
<dsmith>mario-goulart, ,foo stuff?
<mark_weaver>dsmith: right
<dsmith>s/mario-goulart/mark_weaver/
<ijp>taylanub: I posted my solution in my gist, and I removed that bit, since it makes the code horrible
<mark_weaver>in particular, the 'reader' and 'compiler' in the language spec is not told whether it is reading/compiling something that came from the REPL or not. the same code is called whether from the REPL or from a file.
<mark_weaver>so even if you convinced us that this was a good idea, it would require changing the APIs and core language support.
<taylanub>ijp: Ah, I see, that's neat.
<taylanub>ijp: Heh, in SRFI-1 I just spotted this example usage of `fold': (fold cons tail rev-head) That's basically the `append+reverse' I had implemented yesterday. :P
*taylanub should use folds more ...
<ijp>yes
<ijp>taylanub: https://github.com/ijp/monad/blob/master/writer.sls for comparison
<ijp>but doing it in terms of composition of (functions from values to values+state) is much easier to explain
<ArneBab>mark_weaver: I think changing APIs would be too much :)
<ArneBab>mark_weaver: So I’d rather disallow doubled empty lines in guile-wisp.
<ArneBab>mark_weaver: with the definition: A line is empty if it only contains whitespace.
<ArneBab>mark_weaver: comments aren’t empty then.
<ArneBab>mark_weaver: is it possible to disable stopping the guile-interpreter with Ctrl-D?
<ArneBab>… that would feel kinda strange…
<ArneBab>especially because I need that to get out of the debugging mode
<ArneBab>mark_weaver: easier way to make it feel better: would it be possible to make Ctrl-D insert an EOF in the first line?
<ArneBab>mark_weaver: describing that clearer: If I type define (hello) : display "Hello World" Ctrl-D
<ArneBab>mark_weaver: it currently does not do anything
<ArneBab>mark_weaver: if that would run the line, Ctrl-D would be a general “run this” command in guile-wisp
<ArneBab>mark_weaver: I just tried coding in the REPL with Ctrl-D, by the way, and it feels much less strange than I expected.
<ArneBab>mark_weaver: from that experience, I think Ctrl-D for running the code would be good, as long as we find a way to avoid the problem of the ambiguity of Ctrl-D: insert EOF or quit the REPL.
<mark_weaver>Ctrl-D is handled in the kernel itself, not in Guile. I don't think we can really control the fact that it only sends EOF if it's at the beginning of a line.
<ArneBab>mark_weaver: is it possible to add a different shortcut?
<ArneBab>mark_weaver: does Ctrl-L actually send ^L?
<ArneBab>that would then be a page-break.
<mark_weaver>well, the terminal (handled in the kernel) normally doesn't send anything to Guile until the newline is typed.
<ArneBab>ah, ok. It goes that deep…
<mark_weaver>however, you could perhaps recognize ^L specially in the wisp reader (whether at the REPL or in a file) as another way to close all brackets. that would be very reasonable.
<mark_weaver>but at the REPL, you'd still need to type RET in addition to ^L
<ArneBab>yes
<mark_weaver>however, another complication is how readline handles these characters. I don't know, since I never use readline (I do pretty much everything in Emacs, including my shells)
<ArneBab>that would not be completely convenient, but much less dangerous than typing Ctrl-D while coding.
<ArneBab>currently readline in guile also has a problem with newlines…
<ArneBab>they get stripped
<mark_weaver>ah yes, I remember you mentioning that. hmm.
<mark_weaver>we should fix that.
<ArneBab>that would be great!
<ArneBab>besides: how can I choose the language within a file?
<mark_weaver>hmm. are you sure? when I type (at the Scheme REPL): "test RET test RET test", I get the expected string back with the newlines in there.
<ArneBab>when I do it with wisp, I lose that.
<mark_weaver>hmm. interesting.
<ijp>strictly, you can't choose the language in a file
<ArneBab>try (test RET test RET test)
<mark_weaver>ijp: we ought to fix that somehow.
<ijp>modulo setting it explicitly in an eval when, probably
<ijp>evil
<mark_weaver>well, outside of string constants, newlines are ignored by Scheme (except as whitespace)
<ArneBab>yepp, and that somehow bleeds into readline when I use wisp
<mark_weaver>ArneBab: for now, you need to specify the language explicitly to "guild compile" or to the 'compile' or 'compile-file' procedures.
<mark_weaver>(using the #:from keyword argument)
<ijp> http://lists.gnu.org/archive/html/guile-devel/2012-07/msg00062.html
<mark_weaver>ArneBab: well, if readline is loses the newlines, we certainly ought to fix that. I'm just confused, since it seems to be preserving them within Scheme string literals.
<ijp>hmm, not that thread
<ijp>I had one where I went over the various design choices
<ijp> http://lists.gnu.org/archive/html/guile-devel/2012-11/msg00147.html
<ijp>looks like I only covered scripting
<ArneBab>sounds like a good discussion
<ArneBab>did you actually find a result?
<ijp>--language is there for scripts, everything else is still on the table
<mark_weaver>it's hard, because all of the proposed solutions have some problems.
<mark_weaver>I think we all concluded that there was no magic bullet, and that we'd need to implement some hybrid approach, as distasteful as that sounds.
<ijp>_if_ people were willing to give up executing other language modules directly, maybe indirect through an include, then a file maker like #lang in racket was the no-brainer
<ijp>but people are not going to want that, especially when that language has a module system, like python or lua
<ijp>js it would work okay for
<ArneBab>they look like they are suited for different problems: guile-$lang for distributions: #!/usr/bin/guile-$lang. If that’s not present, via file extension.
<ijp>or mime type!!!
<ijp>was that a joke? I'm not sure
<ArneBab>well… I never used a mime type for that (my browser does…)
<mark_weaver>that would mean yet another dependency on some kind of mime type lookup library :-(
<ijp>yes :(
<ijp>it's also problematic for module lookup
<ijp>if you want to go the file extension route, those should be a field in spec
<ArneBab>file-extension is suited for quick testing: just download and run with guile.
<ArneBab>or for using guile without distro support
<ArneBab>and --lang would be great for getting the correct repl with ease
<ijp>_and_ it's problematic when you allow additional extensions (which guile does)
<mark_weaver>I think the file extension method is a good one for modules especially, but we'll need to implement a more efficient module lookup mechanism that doesn't require N*M stat system calls (where N is the number of entries in your path, and M is the number of supported extensions)
<ArneBab>so why should they be exclusive?
<ijp>there is no one solution, that much is obvious
<ijp>but that doesn't mean we should implement everything we can think of
<ArneBab>you could try to group the solutions by usecase and then check which solutions are the best for a given usecase
<ijp>which I did in those emails?
<mark_weaver>I'm sympathetic to Racket's #lang marker approach also, but that has its own problems. what to do about script shebangs? and it means using some kind of special reader at first that just scans for the lang marker, before the real language is chosen.
<ArneBab>you noted advantages ad disadvantages
<ijp>it's a simple matter to regroup them
<ArneBab>ijp: but they did not make it explicit, that for some usecases a given approach clearly wins while for another usecase another approach wins
<ArneBab>ijp: yepp
<ijp>for example, guessing on filetype is not obviously best for scripts
<ijp>.pl -- prolog or perl?
<mark_weaver>putting the supported file extensions in each language spec file means that we'd have to load all of the spec files ahead of time, looking for extensions.
<ArneBab>ijp: otherwise I could not have done it that quickly here ;) (your post provides very good information - just not in a structure which facilitates decision making :) )
<ijp>mark_weaver: sigh, yes indeed
<mark_weaver>indeed, we don't want scripts to require an extension, but scripts can be handled using a command-line flag.
<ijp>but if it's a fixed list, then all languages need to be distributed with guile
<ijp>but the hard question is modules, everything else I'm not concerned about
<ijp>s/not/less/
<mark_weaver>right
<mark_weaver>we certainly don't want a fixed list.
***linas__ is now known as linas
<mark_weaver>I think loading all the spec files isn't too terrible.
<ijp>it's not an option, but it would be a little cheaper to load if we didn't compare script and cache
<mark_weaver>another alternative would be to have a special module name for each extension, saying which language it corresponds to, e.g. (language extension scm). but that's kind of gross.
<mark_weaver>the thing is, if we did that, we wouldn't have to load them all at initialization. instead, when looking for module (foo bar), if we found foo/bar.EXT, then we'd look for (language extension EXT).
<mark_weaver>but even so, I'm not crazy about this approach. probably better to just load the spec files and be done with it.
<ijp>the problem with spec files is they import other module files
<ArneBab>why not just start with a simple approach like guile-$lang? That would make all scripts executable at once
<ijp>autoloads could fix that
<mark_weaver>ijp: true
<ijp>ArneBab: that isn't the issue here
<mark_weaver>ArneBab: that doesn't solve the problem of loading modules in a larger program that's composed of multiple languages.
<mark_weaver>e.g. loading a wisp module from a larger scheme program.
<ijp>and we have a simple approach for scripts, it requires about 10 more characters than guile-$lang, but it works
<mark_weaver>there are (at least) two separate problems that probably need different solutions: detecting the language of a script, and detecting the language of a module.
<ArneBab>hm, yes…
<mark_weaver>for scripts, I like our existing --language command-line option better than guile-$lang, for several reasons, not the least of which is allowing new languages to be supported simply by having some more languages in your GUILE_LOAD_PATH, and not requiring a new link in /usr/bin/ (or wherever)
<mark_weaver>among other things, Guildhall allows easy installation of new guile modules, but not of new executables.
<ijp>well, it can do that, but there are two options for it, and I never got an answer back about what the difference was
<ijp>so I don't tell people to enable it in my wiki page
<dsmith>Personally, I like scripts to have no extension. The shebang handles it.
<mark_weaver>dsmith++
<ijp>right
<dsmith>I *don't* need to know implementation details just to run a script..
<mark_weaver>fortunately, 2.0.9 already supports the --language switch, which I think covers the script case nicely (though I haven't tried it)
<ijp>I had problems using it with lua, but that turned out to be luas fault
<ijp>works okay
<mark_weaver>hmm. I see that --language sets the 'current-language' parameter. does that mean that if 'current-language' is set to wisp, that when loading scheme modules it will try to read them using the wisp reader (if they're not already compiled)?
<mark_weaver>I didn't really pay attention to our implementation of that feature. I hope we didn't mess it up.
<ijp>load-in-vicinity takes a reader, but it looks like it defaults to #f