<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>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 <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' :/ <ijp>primitive-load-path does depend on the current reader fluid <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>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? <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>ArneBab: if the modules you're trying to load are already compiled, then there's no problem. <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. <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>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>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. <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 <davexunit>is earmuff notation suitable from a variable that is only visible within one module? <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>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 <ijp>hehe ";;; note: all untested (for obvious reasons)" <ijp>amazing what you find in old code <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 <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) <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? <ijp>not wtih object properties <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? <davexunit>that way, only sprites that are being drawn get updated. <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. <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" <davexunit>and then it's trivial to write a task that gets scheduled to run every frame that ticks the animations. <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 <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>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 <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>I just bet on guile getting better at handling floating point math in the future. the important people know about it. :) <davexunit>I need something to use for keys in a hash table <mark_weaver>davexunit: why not just use the object itself as a key in an 'eq?' hash table? <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 :) <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>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. <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 <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>is there a way to provide texinfo docs for the accessors of a record type? <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. <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>I'll just clean up docstrings for tonight, I think. <davexunit>yeah, trying to write some docs at the moment. <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 <youlysses>Anyone play with Guile-wm yet? Is it usable for trivial day-to-day computing? <mark_weaver>you better use git though. the tarballs listed in that email have problems. <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. <dsmith>[16/09/2013 - 07:39:09] dsmith!~dsmith@cpe-184-56-129-232.neo.res.rr.com is flooding me. We will ignore him/her/it. <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 <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^_ 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>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>Are record accessors macros rather than procedures? <ijp>they are inlined functions <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) <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 <shanecelis>ijp: I love the clarity of this: (define (thompson-compile 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>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>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 <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 <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>(define-record-type <box> (box x) box? (x unbox set-box!)) <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>for the go, that + compiled-file-name I think