IRC channel logs

2014-02-17.log

back to list of logs

<davexunit>dynamic signals work!
<davexunit>the define-signal form I wrote seems to be working as expected
<mark_weaver>nice!
<nalaginrut>morning guilers~
<b4283>nalaginrut: hello~
<nalaginrut>heya
*nalaginrut is glad to see Guile into GDB
<b4283>i
<b4283>i've got a question, why are guile module in the category named "ice-9" ?
<nalaginrut>b4283: http://en.wikipedia.org/wiki/Ice-nine
<b4283>*guile modules*
<b4283>nalaginrut: thanks
<nalaginrut>np ;-P
<mark_weaver>it's mentioned here: http://wingolog.org/archives/2009/01/07/a-brief-history-of-guile
<mark_weaver>"Indeed, this is the reason for the naming of the many Guile modules that live in the ice-9 namespace, a nod to the fictional substance in Kurt Vonnegut's novel, Cat's Cradle, capable of acting as a seed crystal to crystallize the mass of software."
<b4283>very cool
<Yawar>both literally and figuratively
<mark_weaver>:)
<b4283>according to wikipedia, this material is inorganic but contageous
<nalaginrut>contification, interesting concept hmm...;-P
*nalaginrut decide to change to master in my main laptop from now on
<nalaginrut>I wish it won't effect web modules in negative way, since I have to continue to develop artanis...
<nalaginrut>but I guess it's unlikely effect web modules
<nalaginrut>hmm...load-thunk-from-memory: No such file or directory
<mark_weaver>make clean
<nalaginrut>oh, it's my problem, I loaded some modules in ~/.guile, it's OK after I dropped them
<nalaginrut>the modules are in system/vm, I guess wingo dropped something
<mark_weaver>okay
<nalaginrut>I'll report if I have problem
*nalaginrut is trying to hack rtl now...
<nalaginrut>actually, "playing" is a better word
<nalaginrut>in registerVM, the amount instructions is reduced to the half compared to stackVM(on average), so I thought the speed of compiling should be reduced too, but it seems not. Maybe the amount of the instructions is unrelative to the speed of compiling.
<taylanub>Hrm, the `define-values' we have now would already allow for well-optimized truly-private (pseudo-)toplevels, right ? It expands to something that uses `set!' in a couple ways but it's not used up to the point where the values are returned.
<mark_weaver>I'm sorry, I don't understand what you mean.
<taylanub>mark_weaver: (define-values (x) (letrec ((x <whatever>) (y (lambda () (begin do-something (y))))) (values x))) ;If `y' were a regular top-level, it couldn't be compiled to a tight loop.
***Shozan is now known as SHODAN
<taylanub>Sorry, I don't know how to most cleanly explain. :)
<taylanub>I'm talking about the whole "we don't have *real* private toplevels in modules" thing, because even private toplevels can be referenced and even set from outside the module.
<taylanub>If there's a clean way to turn a sequence of sexprs beginning with (define-module ...) and ending at the end of the file (?) into the appropriate `define-values' form using `letrec', we could now have a `define-module' flag or so that enables doing that and thus making un-exported toplevels truly private (and better optimizable).
<mark_weaver>yes, I've thought about that too.
<mark_weaver>but this doesn't work with exported macros.
<mark_weaver>we can't get a macro from the inside to the outside using 'define-values'.
<taylanub>Ow, I never thought of that.
<mark_weaver>and even if we could, the macro couldn't reference the variables inside.
<mark_weaver>having said this, you can still use 'define-values' to define multiple procedures that share a lexical scope. such a lexical scope could have something like a module inside, with much better optimization.
<mark_weaver>as long as you don't need to export an macro from it.
<mark_weaver>in theory, we could automatically translate R6RS/R7RS modules that don't export macros into such a form.
<mark_weaver>but it has implications for debugging and REPL usage.
<mark_weaver>actually, since R6RS says that exported bindings can't be mutated (not even by the exporting module), and "exporting" in this context includes bindings that are "implicitly exported" by an exported macro that might expand into references, I suppose it would be legal to define such macros on the outside of the lexical scope, and reference the external copies of the exported variables.
<taylanub>Right, we could hoist syntax definitions to outside the `define-values', and detect (unexported / implicitly exported) toplevels in macro output and include them in the values defined by the `define-values' along the (explicitly) exported ones. But the implementation effort for this might not pay off.
<taylanub>Oh wait, even if the `define-values' (re)defines *all* variables bound in the `letrec*', that doesn't affect the optimizability of those since the variables created by `define-values' are distinct from the ones created by the `letrec*', right ?
<taylanub>(With "(re)defines" I mean "makes toplevel bindings for" or so.)
<mark_weaver>right
<mark_weaver>the thing to do would be to put all the non-mutated toplevels into the 'define-values'.
<mark_weaver>the macros would have to be in both the inside and the outside, in general.
<mark_weaver>well, all of the top-level macros would be on the inside. the exported ones would also be on the outside.
<taylanub>I wonder if some deeper changes to the module system would be better than such hacks.
<mark_weaver>probably so
<mark_weaver>fwiw, I've long wanted something like this too. It's in the back of mind, and I'll try to make it happen when I can.
<jmd>(string->number "z" 32) returns #f
<jmd>Why?
<taylanub>36 would have been correct
<taylanub>We need sneek. :P
<mark_weaver>z is not a valid digit in base 32
<nalaginrut>why sneek is gone?!
<mark_weaver>I haven't seen sneek or dsmith here in quite a while.
<mark_weaver>actually, checking my logs, I see that dsmith has been here recently
<nalaginrut>mark_weaver: well, sneek2 could be helpful
<nalaginrut>sneek2: hi
<mark_weaver>ni!
<mark_weaver>nice!
<mark_weaver>dsmith-w`: where's sneek?
<nalaginrut>sneek2: hello
<sneek2>what's up dude?
<nalaginrut>sneek2: later tell nalaginrut it's ok
<sneek2>got it.
<sneek2>welcome back nalaginrut! you have 1 message.
<sneek2>nalaginrut, 2014/02/17 20:41:34 nalaginrut said: it's ok
<nalaginrut>alright
<nalaginrut>,tr 大家好 << zh|en
<sneek2>nalaginrut, it means: Hello everyone
<mark_weaver>the last record I have of sneek being here is on Feb 2.
<nalaginrut>it's the brand new translator feature
<mark_weaver>wow, how do you do the translation?
<mark_weaver>sneek2: botsnack
<nalaginrut>from google
<mark_weaver>ah
<nalaginrut>oh, I didn't write botsnack plugin, it's easy
<nalaginrut>sneek2: good boy
<sneek2>;-)
<mark_weaver>heh :)
<nalaginrut>have to go, see you tomorrow
<mark_weaver>sneek2: does your master treat you well?
<mark_weaver>okay, good night nalaginrut!
<nalaginrut>I'll do some AI research with it, so you can't talk to it at present, but maybe future
<nalaginrut>night
<taylanub>sneek2: Later tell jmd z is invalid in base 32, you probably wanted base 36
<mark_weaver>I suspect what he actually wanted was a different set of "digits" than 0-9a-z
<mark_weaver>he probably wanted the characters normally associated with "base32" encoding.
<lloda>sneek2: are you case-sensitive?
<cluck>:)
<wingo>(gdb) stepi
<wingo>(gdb)
<wingo>:)
*davexunit is trying to figure out how to use gbd enough to track down a segfault
<davexunit>wingo: is that unboxed floating point math?
<davexunit>I can't quite parse that.
<wingo>davexunit: yes :)
<davexunit>very cool!
<wingo>and the source code that it prints is scheme :)
<wingo>and the symbol is a scheme name
<davexunit>is this with gdb master?
<wingo>this is with normal gdb
<davexunit>that civodul showed off?
<davexunit>oh okay.
<wingo>it's because i wrote out an elf file with the right info
<davexunit>cool. this is guile master then?
<jemarch>gdb eats dwarfes
<wingo>haven't seen potluck stuff yet, been heads-down and also my home internet is out :)
<davexunit>wingo: this is your compost project right?
<wingo>it seems that one core can do around 400K particle updates/s at 60 fps
<wingo>davexunit: yeah
<davexunit>!!!
<davexunit>I *need* this!
<wingo>:-))
<wingo>0 gc time :)
*davexunit dreams of the bullet hell shooting games he can make with this
<davexunit>400K particles is crazy
<wingo>if you're just doing constant forces you can probably do more; my demo has some divisions and a sqrt
<wingo>still some things to do before i can write about it, back to the hack
<davexunit>okay! I'm very excited. The whole reason I discovered Guile in the first place was investigating how to write a DSL for bullet patterns in a shoot-em-up game. :)
<wingo>:-))
<taylanub>Has there been an improvement to the unboxed floats, or is it still the same strategy which IIRC wasn't suitable to make default ?
<davexunit>taylanub: wingo is working on a hack of which I don't know the details, but it's called "compost" and it seems to be a separate library, which is fine by me.
<jemarch>wingo: does the new compiler feature a JIT compiler to native?
<wingo>jemarch: this is a little experimental hack
<wingo>it's aot; it produces elf that is then dlopened and accessed with the ffi
<wingo>but if you mean the compiler in to-be-guile 2.2, no there is no jit compiler
<wingo>because guile is implemented in itself; it never makes sense to jit-compiler your jit compiler :P
<jemarch>yes well, that depends on how the "itself" part is implemented :)
*taylanub has Xzibit flash in front of his eyes
<jemarch>wingo: so your JIT compiler compiles scheme into what exactly? A lower level scheme?
<wingo>i just told you i didn't have one :)
<wingo>my little aot compiler compiles a subset of scheme into x86-64 assembly
<wingo>machine code, rather
<jemarch>but that is not 2.2?
<wingo>that's just a little hack for the potluck
<jemarch>ok
<davexunit>found my segfault.
<davexunit>an after-gc-hook that tries to make GL calls.
<davexunit>I guess the proper thing would be to schedule the operation to be run in the game loop instead.
<wingo>finalizers are bad mkay
<wingo>:)
<davexunit>wingo: I wrote a demo that counter the number of GC calls.
<davexunit>wingo: and what about a finalizer that is guaranteed not to run outside the context of a certain thread?
<wingo>you can use (gc-stats) if you like
<davexunit>wingo: well, I wanted to respond to that event rather than poll (gc-stats).
<davexunit>re: finalizers, I have a guardian for opengl textures and after the GC runs, I schedule a reaping procedure to be run in the main event loop.
<wingo>that's ok
<davexunit>okay, cool.
<davexunit>switched to a new branch and now the same demo program has a different segfault. oh boy.
<didi>When using `read-line', can I set the end-of-line mark to another one? I'm reading a file that uses `\\r\\n'.
<ijp>the read-line in (ice-9 rdelim) takes it as an option, I think
<didi>ijp: AFAICS it accepts single characters.
<ijp>ah, misremembered
<ijp>hmm, the rnrs get-line might handle it, but I suspect it just shells out to read-line
<didi>ijp: I might read the whole file with `read-string' and then split it using `string-split'.
<didi>Is there a bot that eval guile expressions here?
<ijp>(define (read-line* port) (define p (read-delimited "\\r\\n" port 'split)) (when (and (eqv? (cdr p) #\\return) (eqv? (peek-char port) #\\newline)) (read-char port)) (car p))
<ijp>didi: no
<didi>ijp: Thank you.
<davexunit>Are recursive mutexes bad in any way?
<davexunit>I have a situation that seems to call for one.
<didi>Is there a procedure version of `,time'?
<wingo>didi: unhappily, no; a patch would be appreciated
<didi>wingo: :^)
<davexunit>okay, this is strange.
<davexunit>I have a program that segfaults upon exit *only* when the file is compiled before running.
<davexunit>running the program again seems to work just fine.
<davexunit>wtf.
<davexunit>does anyone have the slightest idea about what might cause such behavior?
<dje42>Try running under valgrind?
<davexunit>I'm using gdb currently.
<davexunit>I'll try valgrind too
<mark_weaver>wingo: wow, that's some crazy awesomeness you've got brewing there! :)
<mark_weaver>davexunit: while it's not impossible that recursive mutexes could be used properly, they also can very easily lead to buggy code. why do you want them?
<mark_weaver>btw, system asyncs like the one queued by 'after-gc-hook' is also quite likely to lead to problems.
<mark_weaver>and if there are multiple threads in the system, your after-gc-hook could run in any of the threads. you don't know which.
<mark_weaver>but even if it runs in the thread that you want it to run in, it could run at any arbitrary point in the scheme code.
<mark_weaver>which makes it sort of like a signal, with some of the same problems.
<mark_weaver>well, that's not quite true, but close enough to being true to be a problem.
<davexunit>mark_weaver: re: recursive mutex, I wanted to make my agenda data type thread safe, but I ran into an issue where I would try to lock the mutex twice.
<davexunit>the 'schedule' locks the mutex, and so does 'tick-agenda!'. The problem is that 'tick-agenda!' could call a procedure that calls 'schedule'.
<mark_weaver>can you unlock the mutex around the call to the arbitrary procedure?
<mark_weaver>(sort of like a condition variable unlocks the mutex you give it while waiting)
<mark_weaver>here's the problem: if you use recursive mutexes, then if your system async (after-gc-hook) calls something that locks that mutex, it would hide a problem.
<davexunit>yeah I think I could just unlock the mutex.
<mark_weaver>one thread could lock the mutex, and then, in its critical section, the after-gc-hook gets called and it manipulates the same data structure.
<mark_weaver>if its a recursive mutex, then the lock within the after-gc-hook will not block, and you'll think everything is okay, but in fact you could be manipulating a data structure when it's not in a consistent state.
<mark_weaver>btw, why do you want to make your agenda data thread safe? keep in mind that it's going to slow things down a lot to use mutexes.
<mark_weaver>I hope there's a compelling reason for it.
<davexunit>well my compelling reason is not-so-compelling now that you brought up that problem with after-gc-hook and system asyncs.
<davexunit>so I'll just revert this change.
<wingo>wooo, particle demo working properly now
<wingo>it can just manage 400K particles
<mark_weaver>wingo: sweet!
<wingo>running at 430% cpu on this two-core, four thread-per-core chip
<wingo>or is it a 4-core 2 thread per chip?
<wingo>i can't recall
<wingo>surely the latter
<wingo>and the free radeon drivers
<wingo>400K particles at 60 FPS :)
<wingo>;;; 119 frames in 2.00 sec = 59.49 fps; 16.81 ms/frame, 31.61 ms max; 419.31% CPU
<wingo>but that's pushing it ;-)
<davexunit>woo!
<davexunit>400K is way more than you'd ever really want on screen anyway.
<wingo>depends on your screen i guess ;)
<davexunit>10-20k is about all I desire.
<mark_weaver>wingo: I was rather curious why you made 'abs' and 'sqrt' into interesting primitives. now I know :)
<wingo>100K is quite smooth
<wingo>:)
<wingo>now, to make a demo that's a bit less static...
<davexunit>wingo: since finalizers are bad, is there a better approach to reaping defunct GL textures and other objects?
<wingo>davexunit: for gl textures, i'm afraid that manual management is the thing
<wingo>dunno tho :)
<davexunit>okay.
<mark_weaver>what about guardians?
<wingo>you can pump a guardian from the gl thread, perhaps that is a thing
<davexunit>well I'm using guardians currently with an after-gc-hook that triggers the guardian reaping.
<davexunit>perhaps I should just remove the after-gc-hook part.
<mark_weaver>davexunit: I'd avoid the after-gc-hook, and check the guardian in your event loop.
<wingo>right
<davexunit>okay. I can just poll periodically.
<davexunit>I could use a pretty long polling interval too, I imagine.
<davexunit>several seconds.
<mark_weaver>why would you want to do that? it just means more work when the time comes, and thus a longer pause time, no?
<davexunit>I guess I could just pump them every frame then.
<wingo>right, polling a guardian is cheap
<wingo>it's a mutex lock and a function call. cheap.
<davexunit>I was under the impression that mutex locks were quite expensive.
<mark_weaver>well, it's cheap in the context of once-per-frame.
<mark_weaver>it's all relative.
<davexunit>currently, I have 3 GL objects with guardians. shaders, shader programs, and textures.
<davexunit>so I would be pumping 3 guardians every frame.
<mark_weaver>why 3 guardians? why not just one?
<davexunit>I suppose I could use one and type check.
<mark_weaver>well, it probably doesn't matter much anyway.
<wingo>once per frame is 16000000 clock cycles. there's room for a 100-cycle lock :)
<mark_weaver>even three pthread mutex locks per frame is trivial.
<davexunit>okay, I'll do that, then. thanks.
<mark_weaver>np!
<davexunit>I wonder how much overhead it would add to add them to the agenda for each frame.
<davexunit>might generate too much garbage. a new queue every frame.
<mark_weaver>I wouldn't worry about it, as long as the added garbage per frame is small constant.
<davexunit>okay.
<mark_weaver>the things you have to worry about are the per-object-on-the-screen things.
<mark_weaver>beware the evils of premature optimization :)
<davexunit>heh. that's why I pitch a lot of ideas here.
<wingo>anyone want to try my compost thing? i'm almost ready but it requires guile master and figl built against it
<davexunit>I would try but I don't have guile master compiled right now.
<davexunit>and it takes awhile.
<davexunit>I'll start compiling, though.
<davexunit>I think there's a missing configure check in master. when I ran make it complained about "gperf" not being found.
<wingo>i think that's a developer-only thing, fwiw
<wingo>i.e. it doesn't happen from a tarball
<davexunit>oh okay
<davexunit>nvm, then.
<wingo>so the conventional wisdom is that you just have to have some things installed when you build from git
<mark_weaver>wingo: I'd be stoked to try it, but I'm on MIPS. actually, I'd like to port it to MIPS.
<davexunit>wingo: makes sense to me.
<wingo>mark_weaver: sure; the backend isn't too bad
<wingo>probably mips assembler is a lot better to deal with too
<davexunit>building master now.
<mark_weaver>I suspect so, yes :)
<taylanub>Code efficiency can be really unintuitive .. the other day I benchmarked two alternative versions of a small piece of Elisp only to find out that there was barely a difference between a car call plus a setcdr call, and a puthash call. A sole setcdr seemed to be only about two times as fast as a whole puthash.
<wingo>bytecode overhead
<wingo>ok, compost is pushed
<wingo> https://gitorious.org/guile-compost
<davexunit>wooooooo!
<mark_weaver>sweet :)
<mark_weaver>you bring awesomeness to new heights, wingo!
<wingo>*bashful grin* <3
<davexunit>the example code is really neat
<davexunit>hopefully I'll get to see it in action soon
<mark_weaver>hmm, I can't seem to access that URL successfully. probably has something to do with the fact that I'm using Tor for most everything now.
<mark_weaver>what's the git clone URL?
<davexunit>git@gitorious.org:guile-compost/guile-compost.git
<wingo>i did sign analysis to prove that the result of sqrt was real; neat stuff
<mark_weaver>heh, nice!
<mark_weaver>hmm, should I be doing a git clone, or adding a new remote to my existing local guile git repo?
<mark_weaver>I still have much to learn about igt.
<mark_weaver>s/igt/git/
<wingo>mark_weaver: that's not guile
<mark_weaver>ah, okay.
<wingo>it's a separate project
<wingo>so a clone is probably the thing to do
<mark_weaver>thankx
<wingo>np :)
*wingo feels like a complete idiot every time he touches hg
<davexunit>I avoid hg for that reason.
<ArneBab_>wingo: why that?
<ArneBab_>(means: Is there anything I can do to help?)
<davexunit>looking at wingo's particle system example, what does batch-mode? do exactly?
<wingo>no thanks :)
<ArneBab_>wingo: ok
<wingo>davexunit: in practice, false if you import from the repl, true otherwise
<wingo>i don't recall how it gets set
<davexunit>wingo: thanks, I didn't see it documented in the manual.
<madsy>Hm.. I need an array of bytearrays. What's a decent container for that? Just a list?
<madsy>Basically what I really need is the closest representation Guile has for a order-2 C array
<mark_weaver>depends on how many bytearrays, and how quickly you need to index them.
<madsy>Or else I have to do a copy
<mark_weaver>well, guile has multidimensional arrays, including packed arrays.
<mark_weaver>but I think they have some efficiency problems on stable-2.0. they'll be better in 2.2.
<mark_weaver>for now, you might consider a vector of bytevectors.
<mark_weaver>maybe wingo or lloda has better advice here; he's recently dug into the array code quite a bit.
<mark_weaver>s/he's/they've/
<didi>madsy: I don't know about your specific case, but I just found out that a matrix made of a vector of vectors perform better than the built-in array.
<mark_weaver>if it were me, and I didn't need the extra features of arrays, I would use a vector of bytevectors.
<didi>At least for my use case.
<mark_weaver>yes.
<madsy>A vector of bytevectors sounds consistent with what I already have. All 1-order pointers are bytevectors already
<madsy>So, thanks :)
<mark_weaver>np!
<lloda`>if the bytearrays have different lenghts, then use a vector of byte arrays.
<madsy>lloda`: They all have the same length. Just like int foo[a][b] would in C, for constants a and b
<lloda`>do you need to pass the whole 2d structure to C?
<lloda`>then a 2d array would be better, as you could do it w/o copying (assuming you don't use libguile on the C side)
<lloda`>if you want to manipulate it in Scheme, it depends a bit on what you do
<lloda`>if you want to slice, transpose, etc. in 2D, that's much faster with a 2D array
<lloda`>if you operate element per element, then with the current implementation a vector of vectors will probably be faster.
<taylanub>You could also always use one bytevector and accessor procedures to calculate the offset (x*a+y), dunno if that would be more efficient or if it's a stupid idea.
<lloda`>that's exactly what 2d arrays do, so it would be reinventing the wheel
<lloda`>granted, doing that in Scheme might compile better than using array-ref, etc. if you operate element per element
<mark_weaver>well, not quite exactly.
<taylanub>It might help with constant-propagation/partial-evaluation when the sizes are constants, I imagine ? (Using self-written accessors.)
<madsy>lloda`: I just have some OpenGL API call that expects a 2D C array of integers. The best thing would be to be able to avoid copying, but it's not a big deal.
<lloda`>you can use #2s32 for that
<madsy>mark_weaver already suggested a vector of bytevectors, which would be the most consistent in my case.
<mark_weaver>array operations have additional overheads because they are generic, support arbitrary affine transformations (x*a+y*b+c, not x*a+y), and the stable-2.0 implementation at least is rather slow.
<mark_weaver>but lloda did a huge amount of work to improve things on master, so presumably they will be better in 2.2.
<lloda`>mark_weaver: uf, my job was mostly pressuring wingo who did the important changes
<mark_weaver>but, it's certainly true that arrays have the advantage that you can avoid copying.
<mark_weaver>so it depends on which ops you'll be doing how often, I suppose.
<mark_weaver>yeah, wingo deserves huge props as well. I guess it's fairest to call it a collaboration between wingo and lloda :)
<lloda`>i'd argued before here that the reason arrays are slow is type dispatch more than the affine transform, and I stand by that. But as taylanub says, the compiler might do a better job with the index ops when the whole thing is in Scheme. We might move arrays to Scheme one day, eh?
<mark_weaver>yes, I think when we have decent native code generation that will be a big win.
<lloda`>Fortran does full affine transforms and it isn't slow ;p
<mark_weaver>sure. it's a *lot* easier to optimize fortran.
<lloda`>I concede that
<wingo>easier than c; fortran doesn't do aliasing iirc
<mark_weaver>anyway, I'm not saying it can't be done in Guile, but right now we have issues like: almost any procedure call, even to top-level procedures in the same module, is not a known procedure because its variable might have been mutated since it was compiled, etc.
<mark_weaver>and there are also things like first-class continuations to contend with: almost any procedure call could return more than once.
<wingo>we already open-code many primitives, fwiw -- we are ignoring that difficulty, to an extent
<mark_weaver>it's hellishly hard to optimize scheme code while retaining the expected semantics.
<wingo>it would be nice to get some better semantic support for that kind of thing (immutable module exports for example, at least semantically)
<mark_weaver>yes, I'd like to work on that at some point.
<wingo>you could mutate them at runtime but then you'd be responsible for doing so :)
<taylanub>I made that ML post about that some time ago but never started to work on it. :(
<mark_weaver>in R6RS, exported variables cannot be mutated, by either the exporting or importing libraries. that goes for "implicitly exported" variables also, i.e. variables that could have references generated by an exported macro.
<mark_weaver>with those semantics, we could do much better.
<wingo>mark_weaver: are you certain? i thought that the library being imported could mutate them
<wingo>i say that without consulting the spec again tho
<mark_weaver>iirc, what you say is true for R7RS but not R6RS.
<taylanub>I know of it too -- it really forbids mutating exported variables. You can always export accessors to a private when you need that ...
<taylanub>(R6RS, that is.)
<mark_weaver>R6RS is more strict. even the exporting library cannot mutate them. in R7RS, the importing library cannot mutate them but the exporting library can. iirc...
<wingo> http://www.cs.indiana.edu/~dyb/pubs/auto-xlib-opt.pdf
<wingo>very nice paper
<taylanub>I used to dislike the R6RS approach for being too strict and not gaining you anything beyond some optimizer simplicity (static analysis can find out what exported variables *are* mutated in practice, so you don't lose optimizability in general), but then I realized that a getter+setter would be cleaner anyway (ideally, just use parameters!)
<mark_weaver>wingo: I haven't read that paper yet, but was immediately turned off by the introduction, which made it sound mostly useful for proprietary software.
<wingo>mark_weaver: i don't recall that bit, but its applicability is much broader
<wingo>i would like to use define instead of define-inlinable, in many cases
<mark_weaver>"The library group form works well, but is not a good fit for situations where all of the source code is not available at compile time ..."
<mark_weaver>I'm left wondering why the library group form isn't sufficient for our needs.
<wingo>the library group thing requires specification
<wingo>er
<wingo>what am i saying :)
<wingo>requires manual intervention and code changes
<wingo>whereas the cross-module inlining thing is fairly automagic
<mark_weaver>hmm. I don't understand, but perhaps I should just add the paper to my reading list.
<wingo>it's simple: they just embed small constants and procedures into the object file
<wingo>and the expander / inliner do optimistic lookups of cross-module references in those object files
<wingo>they are post-expansion constants and procedures, so they are cheap to look up
<wingo>it's like lto in some ways, but it's at expansion time
<wingo>and peval time
<wingo>it seems to me that library-group is a failed experiment, but ymmv
<mark_weaver>ah, okay. well, your description sounds good to me :)
*wingo loves particle-demo.scm 50000
<davexunit>wingo: how do I build figl against my newly compiled guile master?
<davexunit>and will that clash with the figl that I already have installed for 2.0?
<wingo>davexunit: have you installed guile?
<wingo>guile master i mean
<wingo>i suggest configuring --prefix=/opt/guile-2.2 fwiw
<wingo>you won't have to rebuild the scheme if you do that
<mark_weaver>yeah, just: for dir in lib libguile guile-readline; do make -C $dir clean; done
<mark_weaver>we should probably have a target that does that.
<mark_weaver>well, I guess the build system should ideally render that unnecessary, if there are no bugs.
<davexunit>wingo: okay so I install 2.2. to /opt/guile-2.2. do I use the same prefix for figl?
<davexunit>I don't want to clobber my existing install.
<dje42>As expected, people are coming out on gdb-patches@ not liking very much the 2.0.x solution of handling SIGINT.
<mark_weaver>davexunit: you might have to set PKG_CONFIG_PATH=/opt/guile-2.2/lib/pkgconfig before running guile-figl's configure script.
<davexunit>ah okay, cool.
<davexunit>I'll give that a shot.
<dje42>Oh well, no matter.
<mark_weaver>dje42: I'd like to come up with a better solution, but obviously I cannot change previous releases of guile.
<dje42>Righto. No worries here.
<mark_weaver>I suppose the easiest thing would be to add this feature to guile's already-extant signal-handling thread.
<mark_weaver>but it still feels a bit hacky to me.
<dje42>Yeah. My patch for 2.0.x is simple enough to tide gdb over until the no-thread-at-all solution is ready.
<mark_weaver>dje42: do you think it will be accepted?
<dje42>My patch? I think so. I think the only issue is just getting the configury right so it doesn't bother users on systems without pthreads.
<davexunit>wingo: success!!!!
<davexunit>wingo: my thinkpad x220 can handle about 100000 without noticable stutters.
<davexunit>150000+ still reports ~60fps but there's noticable pauses for GC
<wingo>do you think it's gc?
<davexunit>I just assumed.
<davexunit>perhaps not.
<wingo>anyway, nice to see that it works for you :)
<davexunit>50000 at 1366x712 is very smooth.
<wingo>i am changing the quads to be cubes, but it is making me investigate a peval issue :)
<davexunit>haha
<stis>hi all, in order to get better tail call properties for logic program I will try to implement gc of logical variables
<stis>what is the mark bit?
<dsmith>Hey hey
<stis>oh need to go, I'll take this up later!
<wingo>woo, i have cubes
<davexunit>yay!
<wingo>i think i should do an n-body thing
<wingo>hummm
<davexunit>hmmmm the GC is eating things that I swear have references.
<davexunit>I have a weak key hash table that is being wiped out! the poor objects!
<wingo>weak hash tables + guardians = badness
<wingo>the documentation says one thing, the implementation does another
<wingo>check the ml archives
*wingo -> z, good night :)
<davexunit>this is just weak hash tables without guardians.
<davexunit>night, wingo!