IRC channel logs


back to list of logs

<mark_weaver>'compile-and-load', 'read-and-compile', and 'compile-file' all take a #:from keyword argument, which defaults to (current-language)
<ijp>well, it needs to, in order to load the files afterward, right?
<ijp>so, I think it depends on the load/module forms in the compiled code
<ijp>load and load in vicinity take it as an argument, defaulting to #f
<mark_weaver>I'm not as worried about 'load' as I am about 'use-modules'
<mark_weaver>it's probably easiest to just do an experiment than to trace through the code.
<ijp>yes, I was just looking through the code for use-moduels
<mark_weaver>dynamically-scoped variables are always trouble :-(
<mark_weaver>here, what we really want is just for the one REPL to be using wisp.. not for the entire system to start using wisp by default for everything.
<ijp>try-module-autoload seems to use primitive-load-path, which is unhelpfully not in boot
<ijp>I expect the author cases fall back on it as well
<mark_weaver>the solution to being able to find all the code nicely is to run "make tags" in the guile build dir, and then M-x visit-tags-table on the top-level TAGS file. then M-x find-tag, which shows that p
<mark_weaver>'primitive-load-path' is defined in libguile/load.c
<ijp>I had some problem building tags the other day, but I hadn't looked into it
<ijp>so I'm falling back on 'git grep' :/
<bipt>there was an ML discussion about current-language a couple years ago:
<ijp>primitive-load-path does depend on the current reader fluid
<bipt> rather
<mark_weaver>ultimately, it calls 'compile-file'.
<mark_weaver>and it does _not_ pass a #:from keyword argument to 'compile-file', which means that (current-language) will be used. *sigh*
<ijp>there is a silver lining, I think
<ijp>which is that the module system for non-scheme is terrible
<ijp>otherwise, I expect we'd have ran into it trying to compile a scheme source as $foo, and gotten a report
<mark_weaver>well, it currently is, that's true. but I don't see why it needs to be.
<ijp>mark_weaver: it needn't be, it shouldn't be, but it means we can fix this
<mark_weaver>ijp: true. we hadn't really tackled this problem yet.. but it does mean that --language isn't really working properly yet either, because it borks module-loading.
<mark_weaver>to be more precise, it's not that the module system for non-scheme is terrible. it's that the module system for any language other than (current-language) is terrible.
<mark_weaver>well, anyway, it's no surprise that our support for multiple languages is still not quite there yet.
<mark_weaver>and indeed, we can and should fix it.
<mark_weaver>the thing that disappoints me is that wisp-as-a-language, and in the case of emacsy, noweb as a language instead of a bunch of reader extensions, is apparently not feasible in 2.0.9, unless we can find a reasonable workaround that's not too gross.
<ijp>a medium level of gross would be supplying it as s keyword to the module spec
<ijp>(use-modules ((emacscy foo) #:language noweb))
<ijp>load & co take a reader, but could be extended to specify a language
<mark_weaver>I think it's a bad idea for the user of a module to have to know what language the module is written in. what is the module changes languages?
<mark_weaver>s/what is/what if/
<ijp>very true
<ArneBab>how do you define a module for guile in a non-schemish language?
<mark_weaver>anyway, I don't doubt that we can fix this in 2.0.10 by making the module-load machinery ignore (current-language) and decide by some other method what language the module is written in.
<ijp>ArneBab: non-scheme code module forms would get translated into guile ones when compiling
<mark_weaver>my immediate question is: is there a workaround to make wisp-as-a-language usable in Guile 2.0.9?
<ArneBab>how comes that I could actually use wisp on the REPL?
<mark_weaver>ditto for noweb-as-a-language
<mark_weaver>ArneBab: if the modules you're trying to load are already compiled, then there's no problem.
<ArneBab>ah, ok
<mark_weaver>ArneBab: the problem only arises if any of the modules you're trying to load are not fresh, and are not written in wisp.
<ijp>bipt: what's your take on this, as elisp czar? :)
<ArneBab>that really sounds like a dangerous tripwire for new users ;)
*ArneBab would never have expected that the compile-state would affect this.
<ijp>(aside: we should really be having this discussion on the mailing list)
<ijp>wingo and civodul are both distracted, but at least it would be there others
<mark_weaver>*nod* but it can still be useful to discuss here and then distill it down to a few proposals for the ML.
<mark_weaver>For modules, I like the file extension approach, if we can make it work without too much of an efficiency hit.
<ijp>as heuristics go, it's at least cheaper than others I can think of
<ijp>like shelling out to file(1)
<mark_weaver>I also don't like the idea of forcing elisp or ecmascript modules to be named *.scm
<ArneBab>so that means, parsing all language/*/spec.scm files before doing anything?
<mark_weaver>to reduce the number of stat calls, I think we should actually read the directory listing ourselves and look for filenames of the form FOO.EXT.
<ArneBab>or rather language/*/spec.*
<ijp>I think we can require specs files to be scheme
<ijp>doing it in the language itself is a bootstrap issue, and if we're being restrictive, I'd say scheme, rather than $langauge_installed_earlier
<ijp>the files are short anyway, often just a module declaration, and a define-language form
<ijp>basically a config file
<mark_weaver>ijp: I don't see why we'd have to require them to be Scheme. The natural thing is to simply load the (language FOO spec) module, like any other module is loaded.
<ijp>well, if not scheme, then a language that is shipped with guile
<mark_weaver>but of course, the language spec can't be written in its own language.
<mark_weaver>and more generally, the graph must be acyclic.
<mark_weaver>with Scheme being the only exception, since we have a bootstrap system already in place for Scheme.
<mark_weaver>we could make recommendations, but actually enforcing that would be more work for us, to no good end that I can see.
<ijp>there is one problem with FOO.EXT, which is that guile allows no file extension
<ijp>it's in the default extensions list
<mark_weaver>true. we'd have to search for that also.
<mark_weaver>anyway, the point is that it's a lot cheaper for us to read the whole directory listing than to try a bunch of stat calls for every combination of load-path-element and supported-extension.
<mark_weaver>no matter what, I think that's a useful thing to do. and then we could start supporting .sls as well.
*mark_weaver updates his TODO :)
<ijp>right, so then the question is how to extend it
<ijp>we've got two ideas already, any others?
<mark_weaver>the two ideas being autoloads for the spec files, and (language extension EXT) ?
<ijp>oh, and since the extensions list is extensible, should it be scheme only?
*ijp rummages around for the env var
<ijp>actually, that's a moot point, the documentation says "containing scheme code"
<mark_weaver>I think that any extensions listed in %load-extensions should default to being scheme code, unless the as-yet-determined mapping mechanism says otherwise. does that make sense?
<ijp>hmm, in theory we could make it into an alist, where the car is an extension and the cdr is a symbol
<ijp>mark_weaver: no argument here
<ijp>in the non pair case, it would be as if it was a pair with 'scheme in the cdr
<ijp>one problem with loading spec files has occurred to me
<ijp>we have to load all the ones that aren't #:for-humans? too
<mark_weaver>ijp: sounds reasonable, but I don't want users to have to add that configuration to their dot files in order to use a new language.
<ijp>sometimes devil's advocacy is just too easy :)
<mark_weaver>ijp: I'd like someone to be able to use guildhall to load a library that includes code written in another language, without having to tweak their .guile or anything like that.
<mark_weaver>here's another idea: load (language FOO extensions)
<mark_weaver>gotta go afk for a while...
<ijp>well, we'd still stat, but we wouln't need to load
<ijp>that's a little cheaper, and it makes it more self-contained
<ijp>right, later
<davexunit>is earmuff notation suitable from a variable that is only visible within one module?
<davexunit>it is mutated in said module, as well.
<ijp>I think so
<ijp>but it's hard for me to examples of me actually doing it
<ijp>on the other hand, I have managed to find code where I use words like "antecedent"
<ijp>well, I do it in
<davexunit>okey dokey.
<ijp>but I've gotten too good at avoiding top level mutable state
<davexunit>I have a few situations where I don't see another way currently.
<ijp>many cases where I would have done it before I use parameters
<davexunit>I was reading the docs on parameters.
<ijp>hehe ";;; note: all untested (for obvious reasons)"
<ijp>amazing what you find in old code
<davexunit>maybe I should use a parameter
<davexunit>I'm currently trying to use weak keys to create a register of sprites that have animations so that guile-2d can update them and keep it transparent to the user.
<ijp>I put earmuffs around a top level hashtable
<ijp>I wouldn't*
<davexunit>okay. what would your reason be? because I'm not re-assigning the value of the variable, but instead mutating the object it references?
<davexunit>the manual says that object properties can be used in many situations where you'd want a weak key hash table.
<ijp>an object property is basically a wrapper around them
<davexunit>I'm still trying to understand object properties.
<ijp>okay, so in cunning-bot, one property I have is the admin-command? property
<mark_weaver>I'm skeptical that parameters would be sufficient to eliminate the need for mutable state in a game engine. Well, "need" is too strong a word, but IMO this is a case where it would be awkward and inefficient to avoid mutation.
<mark_weaver>and IMO, parameters are not very nice either. they have many quite serious disadvantages.
<ijp>you make one with (define prop (make-object-property))
<ijp>then you can test it with (prop some-object), and set one with (set! (prop some-ojbect) some-val)
<ijp>that's basically it
<davexunit>perhaps I should try to briefly describe my problem: I would like to create a collection of sprites (images, basically) that are animated that the game engine can iterate over to advance the animation as needed.
<davexunit>a sprite being in this list shouldn't be enough to save it from garbage collection.
<ijp>right, so you want a weak structure
<davexunit>with object properties, would I be able to say: give me all of the sprites that are animated?
<mark_weaver>you can't do that with object properties
<ijp>not wtih object properties
<davexunit>okay, that's what I though.
<mark_weaver>but I'm not sure this the right idea though anyway.
<mark_weaver>suppose a sprite hasn't been GC'd, because something, somewhere, still holds a reference to it. that doesn't mean it's on the screen. so you don't want to waste time animating it if it's not on the screen.
<davexunit>mark_weaver: that would be a further optimization, yes.
<mark_weaver>it seems to me more sensible to record a list of the sprites that are animated, as you are iterating over them to draw them in the first place, or something like that.
<davexunit>mark_weaver: ah. and clear that list after every update?
<mark_weaver>but admittedly, I haven't thought much about this.
<davexunit>that way, only sprites that are being drawn get updated.
<mark_weaver>sure, maybe something like that.
<davexunit>that definitely removes the need for a weak structure.
<mark_weaver>I haven't looked at the details of guile-2d, so I don't know.
<davexunit>I think that's a fine solution.
<mark_weaver>I'll also point out that weak structures are relatively inefficient for the GC to deal with.
<davexunit>it accomplishes what I want: to not force the user to manually deal with animations
<davexunit>the user should be able to call make-sprite, give it an <animation> object, and have it "just work"
<mark_weaver>cool :)
<mark_weaver>makes sense.
<davexunit>and then it's trivial to write a task that gets scheduled to run every frame that ticks the animations.
<mark_weaver>going afk for a bit. happy hacking!
<davexunit>see ya mark_weaver, and thanks
<davexunit>since my scheduler is used so heavily, and since it uses queues internally (one for every timestamp), could anyone wager a guess as to whether or not it would be worth it to use object pooling to avoid instantiating so many new queues?
<davexunit>typically a new queue every tick, which is 60 per second.
<davexunit>I plan to do some benchmarking before I implement such a thing, but I'm curious if anyone that knows more about the GC could weigh in.
<ijp>well, queues do allocating anyway, so I doubt it would save much
<davexunit>ijp: good point.
<ijp>maybe with a different queue type it would
<davexunit>I'm in a battle with the GC, though I'm pretty sure that it's all because of floating point math.
<davexunit>everything gets converted to floats for OpenGL calls.
<davexunit>it's just the nature of OpenGL.
<davexunit>I don't use many floating point numbers directly, but the FFI layer will create them for sure.
<ijp>I know that's how opengl works, but the thought of all that converting gets me
<davexunit>yeah, it's very apparent when rendering several sprites
<davexunit>and computing rotations and things
<davexunit>I've seen the GC run many times per second
<davexunit>which is not good.
<ijp>I don't suppose it will make any difference, but did you try running it in incremental mode?
<davexunit>yes, it seemed to make the problem slightly worse, but that could've been a fluke.
<davexunit>it certainly wasn't better.
<davexunit>I just bet on guile getting better at handling floating point math in the future. the important people know about it. :)
<davexunit>how do I get the pointer for an object?
<davexunit>I need something to use for keys in a hash table
<mark_weaver>well, there's 'object-address'
<mark_weaver>but 'eq?' hash tables effectively hash the addres.
<mark_weaver>davexunit: why not just use the object itself as a key in an 'eq?' hash table?
<davexunit>that would work.
<davexunit>that worked just fine. now all of my sprite animations are happy.
<davexunit>mark_weaver: naming convention opinion: draw-sprite or sprite-draw ?
<mark_weaver>coming up with good names is hard. I find it harder than anything else. I'd probably use 'draw-sprite', but reasonable people might disagree :)
<davexunit>okay. :)
<mark_weaver>I should rebase my nan-boxing patch, to see how much it helps performance on guile-2d.
<davexunit>I have draw-sprite currently, but I've noticed that I do the reverse as well for other objects, so I want to make everything consistent.
<mark_weaver>I'm not sure if nan-boxing is the way to go, but it would at least be an easy way to see how much of the problem is boxed floats.
<davexunit>that would be cool. the particles example would be what you'd want to run.
<davexunit>that example isn't as efficient as it could be, but it displays the problem nonetheless.
<davexunit>alright, time to learn texinfo...
<davexunit>guile-2d needs a manual.
<davexunit>I have docstrings for most things, but I didn't realize until a month or so ago that the tex-info stuff is totally separate from that.
<mark_weaver>ideally, we'd allow optional use of a more efficient, generational GC. unfortunately, I'm afraid that some code is being written that assumes conservative GC.
<mark_weaver>and some advice is being given on the ML that you don't have to write SMOB markers anymore, etc.
<ijp>I think some of the docs in system foreign assumed points don't move
<mark_weaver>which is effectively committing us to an inefficient, non-moving GC.
<davexunit>uh oh.
<ijp>and there's scm->pointer
<mark_weaver>admittedly, conservative GC is the right approach for easy integration with C.
<ijp>this may be okay for libffi, I dunno
<mark_weaver>so any generational GC option would involve some loss of features.
<ijp>nicferrier was asking on #emacs the other day if guile could move to a generational gc, and my answer was "probably, but it wouldn't be easy"
<mark_weaver>if we're going to keep that option open, we should probably try to implement it as soon as possible, so that people write code with that possibility in mind.
<ijp>a number of people aren't really happy with emacs' gc
<ijp>all I know is, I don't want to be the one debugging the gc :)
<ijp>it was bad enough when I wrote some toy one's with racket's gc language
<mark_weaver>admittedly, it would be kind of painful. we'd need to do precise scanning of the C stack, which would require proper accounting.
<davexunit>I want to make a first release guile-2d by the GNU 30th anniversary, but I have a dependency that hasn't made a release yet: guile-figl. should I just bundle it with guile-2d for the time being?
<mark_weaver>we should look at Racket's tool for preprocessing C code for precise GC. I only vaguely remember what that's about, but it seems like a useful approach.
<ijp>davexunit: you don't have to bundle it in the code, you could put a tarball in your project downloads bit on github
<ijp>I did that for guile-sdl when ttn's didn't work on guile 2
<davexunit>so make my own tarball?
<ijp>pretty much
<mark_weaver>I think that would be better than bundling it in your own tarball.
<mark_weaver>it's not ideal, but maybe the best option, assuming you can't convince the figl authors to make a release.
<davexunit>I sent a message to guile-user about it, I'll see what happens.
<davexunit>people have trouble with it currently because make fails when building the docs.
<ijp>you have to be firm with wingo ;)
<ijp>I had to moan a couple of times to get him to include a fix in his sqlite module
<davexunit>the issue with the docs bug is that the docs are autogenerated, so I can't just fix the single error for them and submit a patch. I would have to fix the generator.
<davexunit>other than that the master branch HEAD is perfectly suitable for my needs.
<mark_weaver>well, it's free software, so you're well within your rights to distribute your own tarball, with any modifications needed to make it work properly :)
<mark_weaver>but it would certainly be better if wingo and/or wigs could be convinced to make a proper release.
<mark_weaver>but I haven't seen wigs around in a while, and wingo is pretty focused on the RTL compiler right now, so it won't be easy :-/
<davexunit>yeah, wigs has been the one to respond to my previous emails
<davexunit>wingo is too busy
<davexunit>is there a way to provide texinfo docs for the accessors of a record type?
<davexunit>that guild doc-snarf picks up, anyway.
<mark_weaver>probably not.
<mark_weaver>is doc-snarf the thing that guile used to use, and then we decided it was a failed experiment?
<davexunit>having never written texinfo documentation, how should I go about writing my manual?
<davexunit>I see that guile and guile-sdl have manuals with the same format.
<mark_weaver>I'm afraid I can't be of much help here. My experience with texinfo is pretty much limited to adding some docs to Guile's manual, which I mostly did by copying what other people did.
<mark_weaver>(and occasionally looking in the texinfo manual)
<davexunit>alright, I'll just inspect the guile docs further
<mark_weaver>the emacs lisp manual might be more worthy of emulation, however. our manual has some serious organizational problems.
<mark_weaver>(though I'd emulate our manual in terms of how definitions are presented, etc)
<davexunit>okay. I'll keep that in mind.
<davexunit>I'll just clean up docstrings for tonight, I think.
<nalaginrut>morning guilers~
<nalaginrut>davexunit: heya~
<nalaginrut>I saw your plan for release of guile-2d
<davexunit>yeah, trying to write some docs at the moment.
<nalaginrut>I want to release after ORM
<davexunit>any progress there?
<nalaginrut>davexunit: I wrote something, but I think it's better to read more book/paper of archetecture
<nalaginrut>POSA is so large bunch of books, I'm looking forward to the things I needed
<davexunit>good luck :)
<youlysses>Anyone play with Guile-wm yet? Is it usable for trivial day-to-day computing?
<nalaginrut>where's guile-wm?
<mark_weaver>you better use git though. the tarballs listed in that email have problems.
<nalaginrut>I got it
<nalaginrut>maybe test it under VM
<mark_weaver>a VM is a bit much. Xephyr might be nicer.
<nalaginrut>I ever think about a WM based on Weyland
<nalaginrut>yup, Xephyr
<civodul>Hello Guilers!
<Arne`>#whois ArneBab_
<ArneBab_>sneek: later tell mark_weaver I would start with using two blank lines for finishing all sexps in a file, too. It’s easy to loosen that restriction later on, but it would be a nightmare to add it retroactively when there is already existing code which relies on the old feature.
<sneek>Got it.
<ArneBab_>sneek: botsnack
<dsmith>2013-09-09 07:06:02 9728 17656
<dsmith>2013-09-09 07:15:01 9732 17656
<dsmith>2013-09-16 07:15:01 12484 18856
<dsmith>2013-09-16 07:30:01 12484 18856
<dsmith>rss grew by 3M, and vsz by 1M
<dsmith>In one week.
<dsmith>sneek, botsnack!
<dsmith>sneek, botsnack
<dsmith>[16/09/2013 - 07:39:09] dsmith! is flooding me. We will ignore him/her/it.
<dsmith>sneek, botsnack
<dsmith>silly bot
<civodul>new bug?
<dsmith>civodul, No, it thought I was flooding it.
***linas_ is now known as linas
<add^_>Hey ijp, what paper should I read to best understand how to use your priority search queues?
<add^_>Besides trying to hack on them and read the sourcecode.
<ijp>the paper that describes the implementation is in the readme
<add^_>Right :-O
<ijp>"A Simple Implementation Technique for Priority Search Queues"
<add^_>Thanks for pointing that out :-)
<ijp>a psq is basically a finite map + priority queue squished together
<ijp>the values determine the priority
<ijp>that file could do with some helpers, not least an alist->psq
<add^_>will read the paper, then I'll go for a walk in half an hour
<add^_>I'm trying to figure out how to make a pathfinder, and I'm going to use your psqs when I have a better idea about how to use it..
<ijp>so, say you care computing shortest paths
<ijp>the vertex is the key, and it's priority is the distance
<add^_>vertex, like, a node?
*add^_ is just confirming
<ijp>you can pop off the minimum one, and then you can use psq-update to change the priorities of the adjacent vertices
*add^_ realizes he should have asked waaaay earlier..
<ijp>vertex is a node
<ijp>graph theory is horrible for non-standard names for things
<ijp>you can have long dull arguments about what the difference between a walk, a trail, and a path is
<add^_>thanks ijp, I'll have to get back to this when I get back. :-)
<shanecelis>I'm getting weird behavior with define-record-type when I'm using it with C:
<shanecelis>Are record accessors macros rather than procedures?
<ijp>they are inlined functions
<shanecelis>Is that why I can't call them the from C?
<ijp>looks like it
<ijp>hmm, I'm not sure what to suggest, since they would fall back to normal procedures in scheme
<shanecelis>I think the workaround is to just do (define wud-widget2 wud-widget)
<shanecelis>Then I can call wud-widget2 from C.
<ijp>yes, that's probably the best way for now
<ijp>I think it would be worth reporting this one though
<ijp>also, shanecelis, you mentioned the thompson bug the other day when I posted my quine
<ijp>I was bored the other day, so I wrote one :)
<shanecelis>ijp: Ha ha ha, this is awesome!
<shanecelis>ijp: I love the clarity of this: (define (thompson-compile form)
<shanecelis> (cond ((bug? form) buggy-code)
<shanecelis> ((compiler? form) buggy-compiler)
<shanecelis> (else form)))
<ijp>the code has a horrible amount of duplication, which I could get rid of
<ijp>but it's harder to keep your head straight
<shanecelis>This is blog post worthy with the Thompson stuff that's been going around.
<ijp>I've been meaning to do a write up of it myself
<shanecelis>You should!
<ijp>and mark pointed me to which suggests a defence
<shanecelis>In a couple weeks, if you haven't written it up yourself yet, I'd be happy to do it.
<ijp>I'm going to try removing some of the duplication, but if I'm going to have a writeup, I'll have it by next week
<shanecelis>Cool. Look forward to it!
<shanecelis>I think it'd be really eye-opening for some developers that are not used to having compiler extensions at their finger tips. Thompson's bug is arcane magic, totally inaccessible. But scheme can do it in a page of code and it's explicable.
<add^_>Brr, that was kinda cold actually.. :-S
<bananagram>is there a function to get the type of a value?
<add^_>I'm not sure about a general function that takes a value and prints what type it is, but there are things like integer? , null? and so on
<ijp>bananagram: not really
<bananagram>hm, okay
<ijp>there is one for GOOPs
<ijp>but I'm not sure how it fits in with guile's normal records
<ijp>hmm, looks like it works okay
<ijp>,use (srfi srfi-9)
<ijp>(define-record-type <box> (box x) box? (x unbox set-box!))
<ijp>(class-of (box 3))
<ijp>$4 = #<<class> <<box>> 99501c0>
<ijp>oops, missing a ,use (oop goops)
<sjoerd`>anyone aware of how I could access the current path of the current ".scm/.go" file?
<ijp>you can use (current-file-name) to get the file name (this is a macro, not a function)
<ijp>err, wrong name
<ijp>for the go, that + compiled-file-name I think
<sjoerd`>right, thanks