IRC channel logs


back to list of logs

<madsy>Hey jemarch :)
<davexunit>good evening guilers
<unknown_lamer>davexunit: float allocation should not be an issue btw
<unknown_lamer>bipt explained what the compiler does... it stores the boxed float on the stack
<unknown_lamer>at least for constants
<unknown_lamer>I think the packed-struct unpacking stuff is spewing garbage actually
<davexunit>unknown_lamer: oh really?
<davexunit>well what about the floats resulting from regular math operations?
<unknown_lamer>intermediates that are not mutated should end up in the local object table iirc
<davexunit>so what's spewing all of the garbage then?
<davexunit>floats are immutable.
<unknown_lamer>I'm going to worry about gc stalls later
<davexunit>so they should be in the local object table?
<unknown_lamer>I almost have a basic and very poorly implemented vertex/fragment shader loader
<unknown_lamer>one thing, the vm was just thrown out for the rtl compiler
<davexunit>I have written some code around that awhile ago.
<unknown_lamer>so... it's completely different in master vs stable-2.0 :(
<davexunit>was bipt referring to what the rtl compiler does?
<unknown_lamer>nope, the vm
<unknown_lamer>you can use something like
<unknown_lamer>,c (lambda () 0.0) to see
<davexunit>I'm not used to looking at this output
<davexunit>what is the relevant output here?
<davexunit>I'm going to compile guile master and see if guile-2d programs even run.
<davexunit>and if they do, if the GC runs less.
<nalaginrut>morning guilers~
<davexunit>hello nalaginrut.
<nalaginrut>how about guile-2d?
<davexunit>slow progress.
<nalaginrut>is it possible to write a tiny RPG?
<davexunit>I've been really having a hard time with coming up the right API to describe pieces of a game (main menu, battle screen, etc.)
<davexunit>and I'm also working on how to reduce GC runs
<nalaginrut>besides, since it's named guile-2d, maybe support HTML5 in the future?
<davexunit>nalaginrut: I don't know how I could possibly do that.
<nalaginrut>never mind, it's cool
<davexunit>you could write a small rpg from with what is in master, though.
<nalaginrut>I'm going to try it if it support sound ;-P
<davexunit>there's still tons of rough edges. been trying hard to figure out an elegant API and having trouble.
<davexunit>nalaginrut: there are probably bugs, but there is an audio module.
<nalaginrut>I'll try an example
<davexunit>in fact I know there are bugs in it, but sound is very low on my priority list.
<nalaginrut>I see
<nalaginrut>no sound example at present?
<davexunit>I've also been working on why animation was looking really choppy and unpleasant looking.
<davexunit>nalaginrut: no, sorry.
<nalaginrut>I'll read the code ;-)
<davexunit>look at (2d module)
<davexunit>right now it's a really really simple wrapper around SDL
<nalaginrut>anyway, it's cool
<davexunit>thank you. I would love suggestions for how to make things better.
<davexunit>like I said, I've been having a difficult time designing some things lately.
<nalaginrut>I understand, I'm facing a hard time for Artanis, I have to learn much about ORM
<nalaginrut>davexunit: I think there's actually no (sdl mixer) which appears in audio.scm ?
<davexunit>maybe leave ORM out?
<davexunit>yeah, it's included.
<nalaginrut>but even myself want ORM
<davexunit>you need the guile-sdl library, though.
<nalaginrut>oh, seems it's not in
<nalaginrut>maybe this: GUILE_SDL_OPTLIB([mixer],[Mix_OpenAudio])
<davexunit>yeah, I didn't know how to enforce guile-sdl being installed
<davexunit>could you explain what that line does? I can't make sense of autotools.
<nalaginrut>I could make a pull request when I'm free
<davexunit>I would appreciate it.
<nalaginrut>davexunit: it's actually a macro defined in guile-sdl
<davexunit>how would I use it then?
<nalaginrut>use it to checkout if guile-sdl was installed and contains mixer feature
<nalaginrut>when configure
<nalaginrut>ok, have to work, see you later ;-
<davexunit>see ya!
<davexunit>thanks for trying things out.
***fangism is now known as fangism-shadow
<unknown_lamer>not exciting, and pretty fugly
***linas_ is now known as linas
<nalaginrut>it seems strange that '(a b . c) ==> (a . (b . c)) in Guile, for other Scheme I've tested, it's '(a b . c)
<nalaginrut>although it's same result for car/cdr, I don't know if it'll effect 'match'
<kindahero>hi there, I like to use guile to prototype a scientific application. it
<kindahero>requires to read and write netcdf files. is there any netcdf4 binding for guile.?
<madsy>Morning all :)
<nalaginrut>kindahero: this?
<nalaginrut>madsy: heya
<b4283>wow, never heard of such a file format until just now
<nalaginrut>me too
<nalaginrut>what's the benefit of it?
<b4283>nalaginrut: what's even more is that you could find a guild binding right away :P
<madsy>Yeah that's impressive
<kindahero>@nalaginrut ohh Thanks. do a web search before asking questions. :/
<nalaginrut>guild is also correct ;-)(
<madsy>nalaginrut: Do you happen to know how to do docstring snarfing?
<madsy>Or do I have to eyeball the libguile sources? :)
<nalaginrut>ah, unfortunately I never tried snarf, but I'd like to
<madsy>I already do normal snarfing. But it seems it's also required to get docstrings from the C procedures
<madsy>But how to do that isn't documented
<nalaginrut>seem so
<madsy>I'll look around in the sources
<mark_weaver>nalaginrut: can you elaborate on your comment "it seems strange that '(a b . c) ==> (a . (b . c)) in Guile, for other Scheme I've tested, it's '(a b . c)" ?
<mark_weaver>when I type '(a b . c) in guile, it prints back (a b . c)
<mark_weaver>anyway, (a . (b . c)) is the exact same data structure, and thus cannot be distinguished from (a b . c)
<nalaginrut>mark_weaver: what's your version? mine is
<nalaginrut>scheme@(guile-user)> '(a b . c)
<nalaginrut>$1 = (a . (b . c))
<mark_weaver>mine is the same version
<mark_weaver>that's very strange.
<mark_weaver>what if you type '(a b c) ?
<nalaginrut>'(a b c)
<nalaginrut>$2 = (a b c)
<nalaginrut>anyway, I realized it won't effect my program, but it's strange
<madsy>'(a b . c) => (a b . c) here, in 2.0.9
<mark_weaver>nalaginrut: is this stock guile 2.0.9, or are you using your custom print hook with highlighting?
<mark_weaver>(I've forgotten the details of your REPL extensions, but it seems a likely cause for this)
<madsy>mark_weaver: I'm using stock 2.0.9 and get the same results as you, even in Geiser
<nalaginrut>mark_weaver: mean guile-colorized, yes I'm using it
<nalaginrut>I'll try a bare REPL
<mark_weaver>nalaginrut: I suspect the bug is in guile-colorized.
<nalaginrut>mark_weaver: yes, it's fine with -q
<nalaginrut>I'll handle it...
<nalaginrut>thanks for reveal it ;-P
<mark_weaver>np :)
<mark_weaver>my guess is that you're checking whether to print '.' by seeing if the cdr is a 'list?', but you should rather be checking if the cdr is a 'pair?'.
<mark_weaver>(or 'null?')
<nalaginrut>I never know that the dot could hide when cdr is pair of null
<mark_weaver>okay, time for me to sleep.
*mark_weaver --> zzz
<madsy>Hooray for rainbow-delimiters mode
<madsy>I forgot to install it after getting a new laptop
<madsy>morning wingo
<nalaginrut>morning wingo
<civodul>Hello Guilers!
<madsy>hey civodul
<lloda>Hello there, could I get some feedback about those old array patches? yesterday I tried rebasing on master and I had conflicts with compile-assembly (which is gone) where I had fixed some of the array syntax read bugs. If the patches are good, it'd be better to merge before master diverges further...
<wingo>yes sorry about that
<lloda>I'd also like to finish the deprecation of the generalized-vector stuff...
<wingo>would you mind sending me a mail again? i will do it tomorrow
<wingo>apologies again for the delay
<lloda>np, will send that email
<lloda>thanks :)
<wingo>but now since rtl landed my brain is more free
<civodul>lloda: apologies, i think i'm guilty
<wingo>thank you for your patience!
<wingo>civodul: i can take it if you like -- i have time tomorrow
<wingo>lloda: put me on Cc please
<lloda>sure, will send an email with a summary today :D
<civodul>wingo: great, thanks
<wingo>lloda: also any failing test cases on master would be great
<wingo>i was surprised that more array things didn't fail
<wingo>which probably means that we are lacking in tests
<lloda>the patches add a fair amount of testing
<madsy>Hah, awesome! I got the doc snarfing working
<madsy>But I stole the scripts and tool from the guile 2.0.9 sources
<nalaginrut>madsy: congrats! any blogs for it?
<madsy>nalaginrut: I can make one, as soon as I actually get this .doc file loaded
<madsy>Not entirely working until the last step works
<madsy>Oh, wait.. I have to compile the doc files
<wingo>see libguile/, or the corresponding thing in guile-gnome
<madsy>I thought ice-9 documentation could use the .doc files directly
<wingo>no it needs a text-rendered texinfo file
<madsy>Yep I noticed
<madsy>Also, "documentation-files" in ice-9 documentation takes absolute paths. Ew
<madsy>Wonder if I can change that when I need libguile self-hosted
<madsy>wingo: They seem to have their own tools
<madsy>So: doc->tex->txt ? Seems to be the steps.
<madsy>wingo: Do you know which format the .doc files are in?
<madsy>Maybe it's a custom format only used by the guile build process
<madsy>Aha! guild has an undocumented parameter "snarf-check-and-output-texi"
<madsy>wingo: Finally works now. Making a HOWTO now :)
<wingo>cool, tx :)
***goto is now known as anderson
<dsmith-work>wingo: Speaking of doc snarfing... Did you mention something about keeping docstrings in a special section of .go files?
<wingo>dsmith-work: that works now
<wingo>they are in the .guile.docstrings section, or something like that
<dsmith-work>Ahh cool. But for scheme.
<wingo>that's for scheme files
<unknown_lamer>I have a slightly better (well, uglier still) version that eliminates use of the standard vertex and color arrays
<wingo>madsy: awesome!
<wingo>unknown_lamer: neat :) now the trick is to do the particle effect with the vertex shader instead of with guile
<unknown_lamer>I am working on adding uniform variable setting next
<unknown_lamer>(local branch does attribute setting)
<unknown_lamer>all of this by the seat of your pants error checking is for losers
<wingo>yes i would start with debugging things first, tbh
<wingo>checking linking/compilation errors for shaders, getting out the error string from the driver
<unknown_lamer>make-shader, make-program both do some error checking
<wingo>otherwise you're gonna have a bad time...
<wingo>ah ok, perhaps i missed that
<unknown_lamer>if shader source loading / compilation or program linking fail, it extracts the gl diagnostic
<unknown_lamer>but, afaict, opengl and error checking is a joke
<wingo>anyway be careful with garbage though, don't make lists on the hot path if you can avoid it
<unknown_lamer>there are limited cases where you can even really detect errors!
<unknown_lamer>unlike errno, the gl error state is not cleared implicitly
<unknown_lamer>and if you have more than one gl context in a program in different threads, afaict you literally cannot determine what set the error state
<unknown_lamer>almost everything just sets invalid-operation, move along
<davexunit>I'm really interested to see if you can reduce the amount of garbage, unknown_lamer
<unknown_lamer>I don't wanna spend time profiling memory use
<davexunit>I was curious if the new rtl version of guile would magically reduce GC runs for the particles demo. It did not.
<wingo>haha, then you can't complain about stuttering then :)
<wingo>davexunit: right, i had the same experience
<wingo>i guess the garbage is all flonums
<davexunit>that's what I've been told.
<wingo>well, there will be ways to fix that i think -- but they will take a little longer
<wingo>with rtl though we can think about having unboxed values on the stack
<wingo>that would totally fix this issue
<davexunit>if you're confident that it can be addressed, then I will not do what I was planning: writing a C extension for particle simulations.
<unknown_lamer>also a real time garbage collector that never blocked ;)
<davexunit>unknown_lamer: with unboxed values, the GC runs will reduce to almost nothing.
<davexunit>they will be very infrequent.
<wingo>davexunit: i'm confident that we can fix it but writing a c extension might still be a good idea ;) depends on what you want to do...
<wingo>if i were to do it i would compile to asm directly...
<wingo>but that's getting ahead of myself i think
<davexunit>I would like to keep things in pure guile if possible, but batch rendering sprites or particles or anything that is moving is expensive.
<wingo>i would do scheme -> tree-il -> cps, optimize the cps, verify that it type-checks, then use the cps to emit unboxed C or assembly
<davexunit>each frame: move sprites, fill a vertex array, draw it, watch the GC run.
<wingo>which would create a foreign function that could operate on a scheme bytevector
<wingo>that way you're still programming in scheme
<wingo>you can still use lovely macros, you have control over your toolchain, etc
<davexunit>that would be very nice. do you see this as something that could arrive for 2.2 or something much farther down the road?
<madsy>I want to make a small DSL for shaders
<davexunit>a Guile->GLSL compiler would be awesome.
<wingo>davexunit: dunno, i would do it on the side i think -- it wouldn't have to ship with guile
<wingo>i'll think about it
<madsy>Can't be that difficult, can it?
<wingo>madsy: should be fairly straightforward i would think
<madsy>At least if I keep it simple. Just turn a bunch of symbols into strings and concaternate them together
<unknown_lamer>after getting a bit more of a handle on using shaders, I want to do GLSL sexp notation
<madsy>And add newlines
<davexunit>wingo: okay. I'm just trying to gauge which route I should go. maybe I'll write the C extension in the meantime and happily delete it should the given optimizations come along.
<davexunit>unknown_lamer: I think that is what madsy is talking about.
<unknown_lamer>similar to parenscript, before the current maintainer forcibly took over the project (grumble grumble) and ruined it
<unknown_lamer>"it's slow!!!" did you profile it "no"
<unknown_lamer>oic, let's replace a modern compiler with one from the 60s
<unknown_lamer>rather than trying to compile scheme -> glsl, I just want glsl in scheme
<madsy>unknown_lamer: What's the difference? I don't follow
<davexunit>me either.
<unknown_lamer>you'd lose the entire standard library etc because glsl program sizes are pretty limited, so why bother trying to fit scheme semantics on glsl ...
<madsy>I was thinking of just making a macro which lets you write shader code without putting everything inside strings
<davexunit>unknown_lamer: that CEPL project did it.
<wingo>davexunit: well, if you assume functions that take some sequence of f32vectors and float32 variables and return some error or success code it would be possible to go from optimized cps -> assembly in a weekend
<wingo>for a subset of scheme anyway
<madsy>Though wouldn't use of quotes and parantheses be a problem when handed to a macro?
<wingo>you could hook that up to fork/exec of gas and be on your way
<unknown_lamer>davexunit: soooooort of
<unknown_lamer>it only looks like common lisp inside of defshader
<davexunit>wingo: well that sounds promising.
<unknown_lamer>wingo: actually, hrm. glsl only works on stuff like that...
<madsy>(define-shader shader (void main(){ gl_FragColor = vec4(1.0); }))
<wingo>of course eventually we want to do native compilation for everything and we'll have an assembler in guile, so you can make machine code directly
<madsy>Wouldn't "()" mess up stuff?
<wingo>but that will be much later
<wingo>doing some special-purpose code generation in the meantime seems appropriate
<unknown_lamer>madsy: I am thinking more (define-shader type name &body)
<wingo>you get to use all the xmm registers you want :)
<madsy>unknown_lamer: I don't see a reason to take a shader type :)
<unknown_lamer>where &body is something like (define (main -> void) (set! gl-frag-color (vec4 ...))
<davexunit>wingo: native compilation will be very nice, and I agree with you about some special code generation as a short-term solution.
<madsy>unknown_lamer: Okay, so you want a scheme dialect for GLSL
<unknown_lamer>madsy: just sexp notation for glsl
<madsy>I quite like the GLSL language :)
<unknown_lamer>I despise it >:O
<davexunit>unknown_lamer: that's what I had in mind.
<unknown_lamer>now I'm kind of wondering, since GLSL has limited data types and is really oriented toward float processing...
<unknown_lamer>SGLSL -> optimized unboxed fp munching code on the gpu?
<unknown_lamer>err, cpu
<wingo>unknown_lamer: don't get distracted! :)
<unknown_lamer>wingo: naturally, step one is "can set uniform variables" :)
<unknown_lamer>step two is "do something more than screw around with the particle demo"
<davexunit>is it possible to ship off all of the particle effect computation to the gpu?
<davexunit>oh cool.
<unknown_lamer>my step 1.5 goal is to do that
<unknown_lamer>should be straightforward...
<madsy>Billboarded particles can be passed to OpenGL as GL_POINTS. If you set glPointSize to greater than 1, you get quads
<davexunit>madsy: now what about moving the particles? can the shader do that as well?
<davexunit>and what about textured particles?
<madsy>davexunit: Sure. Just pass in a matrix to transform the points with
<unknown_lamer>just pass time to the vertex shader, then integrate velocity over time to compute the current position
<unknown_lamer>caveat: assumes velocity is constant
<madsy>davexunit: Again, yep. Billboarded GL_POINTS also have texture coordinates
<davexunit>madsy: but you're still doing the movement in scheme, right?
<davexunit>that's the slow part.
<davexunit>ideally, I would like to just make the vertex array and let the shader do the rest.
<madsy>davexunit: What? Nope. Just pass a shader and transform the points in the vertex shader
<madsy>Pass a matrix*
<davexunit>I know next to nothing about shaders.
<davexunit>thanks for explaining.
<madsy>If you need to move individual points, store the matrices in a texture buffer and read it in the vertex shader
<davexunit>yeah, I would want to move each particle around.
<madsy>Or rather, a position vector. A matrix is overkill
<davexunit>but all of the vertex mutation should be done in the shader, seems in scheme it will cause tons of gc runs.
<madsy>davexunit: Are you familiar with buffer objects in OpenGL?
<davexunit>not really.
<davexunit>I have a lot to learn.
<madsy>Okay. Buffer objects is just an object abstraction for a chunk of video memory. You upload a bunch of data to the GPU, and it resides in vram.
<madsy>Then you can refer to that data via a buffer object name
<madsy>Texture buffers are the same thing, only you can actually access the data inside shaders
<madsy>Very handy
<davexunit>hmm, neat.
<madsy>So to translate individual points, you could do something like: void main(){ int id = gl_VertexID; vec4 pos = texelFetch(sampler, id); gl_Position = projectionModelviewMatrix * pos; }
<madsy>To update the matrix array on the fly, you would use glMapbufferRange()
<madsy>Err.. position array
<madsy>I got matrices on my mind, it seems
<davexunit>so glMapbufferRange would do the actual mutation?
<madsy>glMapBufferRange maps a portion of video memory to a C pointer, so you can read/write data in a buffer object
<davexunit>so that would be outside the shader?
<madsy>The copying of the data, yes
<madsy>The positions have to come from somewhere
<davexunit>that won't gain me anything then.
<davexunit>moving particles is what costs so much in GC.
<madsy>Well, what is your suggestion? How do you want to move them? Procedurally?
<davexunit>doing 5000+ floating point operations per frame is painful in Guile right now.
<madsy>You can do that in a shader too. Just add some sine waves or something.
<davexunit>I don't have a suggestion. I was just wondering what my possibilties were.
<madsy>Well, if you want to do different stuff per point (sprite), gl_VertexID is a counter that is unique to each point
<madsy>You can use that for lookups or as a scale
<davexunit>moving everything by a given velocity would be enough.
<davexunit>anyway, I have to head out for a bit to get a city parking pass.
<davexunit>going afk.
<unknown_lamer>wingo: can you generate a program in one thread and then have another thread execute it without weirdness happening?
<wingo>unknown_lamer: you mean a shader program or a guile program?
<wingo>yes, that should work fine
<unknown_lamer>what I would like to do that might be Wrong (tm): spawn the glutMainLoop in a dedicated thread, use a queue to send code to that thread's display or on-idle handler for evaluation
<unknown_lamer>there wasn't some sort of lockless queue hiding guile that I've missed was there?
<wingo>if it's just every frame and there is low contention you don't need it to be lockless
<wingo>you just need an async queue
<wingo>or an mvar
<wingo>which is basically the same thing
<civodul>oh i hadn't noticed that mark_weaver had added other ASM_* macros in the VM
<wingo>ah neat, i hadn't seen that either
<unknown_lamer>oh yeah, is guildhall still active at all?
<wingo>dunno, i think ijp is curating it currently
*wingo has not had time
<unknown_lamer>I saw the mvar in core email, seems like a reasonable module to throw in there
<unknown_lamer>maybe I can finally break free of common lisp
<davexunit>unknown_lamer: come to the dark side. (are we the dark side?)
<unknown_lamer>I think hacking everything I miss onto guile is slightly less effort than the eventual need to write a common lisp compiler if I don't ;)
<unknown_lamer>davexunit: CL is the dark side
<unknown_lamer>I started here!
<unknown_lamer>then libraries and money swayed my allegiances
<davexunit>wingo: you wrote guile-gnome, correct? would you be able to briefly explain why you used GOOPS? I'm still trying to understand the use-cases for object oriented programming in Scheme.
<wingo>i used goops because the gnome libs are object-oriented
<wingo>very much so
<wingo>so it seemed a good fit
<wingo>also the project was originally started by someone else
<wingo>who used goops
<davexunit>wingo: okay. that makes sense. have you used GOOPS outside of that project?
<wingo>dunno, i usually don't reach for goops, but it's nice to know that it's there
<wingo>i've used goops for some things and i would do it again, anywhere I want MOP-like extensibility
<wingo>rather than functional composition
<wingo>i was going to use it for a ggplot2-alike in guile but didn't finish it
<davexunit>maybe I should just use GOOPS for what I'm doing.
<wingo>it was the reason i got involved with guile's compiler, because i realized goops would never be fast without scheme being fast
<wingo>its speed is ok
<davexunit>I'm slightly worried by the overhead of GOOPS, but it might be the only nice way to design certain things.
<unknown_lamer>davexunit: GOOPS should not have much overhead
<unknown_lamer>at least once upon a time it was optimized highly, not sure how much of that is true in the 2.0 world
<unknown_lamer>IIRC generic dispatch is still cached and goops classes don't have much overhead over records
<davexunit>I'm trying to figure out the best way for someone using guile-2d to say: "this is the main menu scene. it has it's own special data that guile-2d couldn't possibly know about. here is how to draw it, update it, and respond to input."
<davexunit>right now, I have a "scene" record that holds the callback procedures and has one slot called "data".
<unknown_lamer>I'm toying with the idea of wrapping things like shaders in objects and using a guardian + after-gc-hook to "garbage collect" them (taking advantage of being able to mark things for deletion that GL owns and GL supposedly being smart about it)
<wingo>unknown_lamer: that way lies badness
<wingo>you have no guarantees about the context that the finalizer runs in
<unknown_lamer>it feels wrong passing ints around
<unknown_lamer>wingo: oh, only for shareable objects
<davexunit>to me, it seems like what I've done is written a crappy vtable.
<wingo>the finalizer will likely be called from a different thread entirely
<davexunit>and I should just use GOOPS...
<wingo>davexunit: right, maybe goops is the thing. dunno :)
<unknown_lamer>davexunit: sounds like classic OO to me
<davexunit>or it could be that I have the wrong idea of how to do something.
<gjanssens>Hi, I'm having some issues in gnucash with guile2
<gjanssens>It looks like the-environment has been redefined since guile 1.8
<ijp>is this a problem in your code, or in gnucash itself?
<gjanssens>One of the gnucash reports using this parameter is bailing out with a back trace
<gjanssens>There is a bug report on the gnucash bug tracker for this:
<gjanssens>I didn't write the gnucash report, but I worked a lot on getting gnucash to work with guile 2
<gjanssens>(continuing on the patches Andy Wingo kindly provided quite some time ago)
<gjanssens>I'm trying to get this bug fixed, but the errors are in some fairly low level regions of guile
<gjanssens>Lower than my current experience goes unfortunately
<ijp>can you point me to where in gnucash this code is?
<wingo>gjanssens: does gnucash do guile 2 already? neat
<gjanssens>This is one of three files using the-environment
<wingo>gjanssens: probably you just have to import the (ice-9 local-eval) module into whatever environment that report runs in
<wingo>the-environment and local-eval moved to that module
<gjanssens>wingo: yes, this issue is the last one
<gjanssens>wingo: I did include it, but that got me a different back trace
<ijp>well, the problem will be that eguile isn't using local-eval, but regular eval
<ijp>assuming I haven't grossly misremembered those patches
<wingo>ijp: the-environment should work anywhere, no?
<wingo>you can only use it as an arg to local-eval
<wingo>but i think that was the case already in guile 1.8
<gjanssens>From the eguile-gnc.scm: (local-eval s-expression (or env (the-environment)))
<wingo>gjanssens: yes, just add a (use-modules (ice-9 local-eval)) to the right place
<wingo>but only for guile-2.0
<wingo>using the usual cond-expand trick
<gjanssens>wingo: that was my last attempt before I came here
<gjanssens>It gives yet another backtrace
<wingo>what a nasty backtrace, sorry 'bout that
<gjanssens>I'm afraid *I* can't read it... :(
<wingo>ERROR: Wrong type to apply: #<syntax-transformer the-environment>
<wingo>that means that when compiling a scheme file, the expanded looked to see if the-environment was a macro or not
<wingo>and it wasn't
<wingo>so it residualized a call to a variable that wasn't known at compile-time
<wingo>but you modified a separate file, to provide the-environment
<wingo>the definition you provided wasn't a procedure -- it's a macro
<wingo>this problem can occur when you have separate compilation (as we do) without proper dependency tracking (as we unfortunately don't have)
<wingo>probably if you remove your guile compilation cache it will try again
<wingo>on that report
<wingo>and will succeed
<wingo>though of course, fingers crossed :)
<wingo>this is assuming that you have auto compilation enabled
<wingo>s/a scheme file, the expanded/the taxreport.scm file, the expander/
<gjanssens>The syntax-transformer error didn't happen once I used the (cond-expand trick...
<gjanssens>unless I misunderstand your explanation
<gjanssens>I got that error when I used this instead:
<gjanssens>(if (>= (string->number (major-version)) 2)
<gjanssens> (use-modules (ice-9 local-eval))) ; for the-environment
<wingo_>gjanssens: right, you need to use cond-expand
<gjanssens>Got that, thanks.
<wingo_>so what is your current error?
<gjanssens>ERROR: source expression failed to match any pattern
<gjanssens>See for the full details
<wingo_>it's missing the last bit
<wingo_>there should be a couple more frames there
<gjanssens>oh, right
<gjanssens>let me see if I can recover those as well
<wingo_>gah, we have two backtrace printers, and the one that case uses is terrible
<wingo_>well, even worse than the other, rather ;)
***wingo_ is now known as wingo
<gjanssens>ehm, what I posted on bz is all I get
<gjanssens>How can I make guile print the full backtrace ?
<gjanssens>Or is that something in gnucash limits ?
<wingo>don't know; usually the frame count should go down to 0 instead of stopping at 3
<gjanssens>That's what I expected as well...
<wingo>can you paste a link to where the eguile files are?
<gjanssens>give me a minute
<gjanssens>the updated files are only in my local git repo
<gjanssens>but I'll push them to github
<wingo>ah, it would probably be in somewhere...
*wingo reads
<wingo>so the bt mentions entry in entries
<wingo>that is from
<wingo>where is that for macro defined?
<wingo>is that a gnucash thing somewhere?
<wingo>otherwise it could simply be a report that hasn't worked for a long long time -- guile 1.8 treats "do" as a value as a normal thing, but to guile 2.0 it's an early syntax error
<wingo>eguile appears to be here:
<wingo>buf, trac. yuk :)
*gjanssens is looking where the for syntax comes from...
<gjanssens>if you prefer github:
<gjanssens>That's a branch with the cond-expand changes included
<gjanssens>The for syntax is defined in
<gjanssens>Near the end of the file
<wingo>have you tried removing your .cache/guile ?
<wingo>gjanssens: ^
<gjanssens>Same result :(
<gjanssens>wingo: ^
<wingo>gjanssens: are you sure that the eguile-utilities module is imported when evaluating reports?
<gjanssens>wingo: on top of the taxinvoice.scm file is this:
<gjanssens>(use-modules (gnucash report eguile-utilities))
<wingo>i see
<wingo>this could be a local-eval vs use-modules problem
<wingo>use-modules is designed to be run at top level
<wingo>or could it somehow be that the-environment isn't capturing the module.... hummm
<wingo>gjanssens: can you show me the code that loads taxinvoice.scm?
<wingo>it looks like it should be fine tho
<gjanssens>wingo: I have to look for it a bit as well, but part of it happens here:
<wingo>gjanssens: actually i think i found it
<wingo>typo, no?
<wingo>if without a consequent
<wingo>or not...
<wingo>so hard to read scheme without proper indentation :)
<gjanssens>wingo: that part looks ok to me...
<wingo>gjanssens: do you have a tree i can check out?
<DerGuteMoritz>whoa, what's the deal with that "for" syntax in that code?
<gjanssens>wingo: is a git tree ok ?
<wingo>a git tree is great :)
<wingo>DerGuteMoritz: thin syntax-rules layer over for-each, it seems
<ijp>DerGuteMoritz: if we had a beer for every time a lisper wrote a loop macro, we'd all die of alcohol poisoning
<gjanssens>wingo: ^
<DerGuteMoritz>ijp: cheers!
*ijp chugs his cup of tea
<gjanssens>I have to leave for today...
<gjanssens>I'll come back later, so I'll check for other questions/suggestions
<gjanssens>Thanks a lot for looking at this
***gjanssens is now known as gjanssens-afk
<stis>ijp: I've parted loop and racket matcher, drink that! muhahahahahaha...
<TaylanUB>.oO( ported* )
<ijp>stis: I've used the matcher, and for the sake of politeness, I will not comment on CL's loop
*wingo refills wine
<stis>ijp: no the CL loop port was really a ploy.
<stis>also the racket matcher is nonfunctuional, which means that it can destroys tricks with delimited continuations
<stis>but still nice to have if one is porting over code from racket.
<stis>anyway, i'm fighting my way right now on implementing prolog!
<stis>funnily the hardest part is to get references of functions in any sane way, still enabling normal prolog programs to work.
<stis>Also I do not want to pay for aiso specification so the documentation is very thin.
<davexunit>wingo: just saw your latest tweet and instantly new what HN comment section it must have been from.
<wingo>davexunit: :)
<wingo>i try not to read it but sometimes i go into troll mode :)
<davexunit>HN is one of those places that I sort of hate but keep going back to anyway...
<wingo>i like twitter much more -- i get to hear from people i care about and block others
*tupi would like a sip of wingo's wine :)
<wingo>ruthless, but i think it's the right thing.
*DerGuteMoritz opens beer
<davexunit>apparently hacking is seeking venture capital for the web application your startup is making.
*wingo passes the cheap "club des sommeliers languedoc" to tupi, far from his home :)
<tupi>haha, nice tx!
<wingo>davexunit: of course, get with the program dude :)
<ijp><fsbot> hn -- [0] hackernews <fsbot> [1] reddit for snobs,
<davexunit>wingo: yeah, I think I just need to subscribe to more interesting RSS feeds and follow more interesting folks on twitter/
<davexunit>ijp: hahaha
<davexunit>I'm done with all this guile stuff. I'm going to write some more HTML/CSS/JS.
*wingo hacks on firefox for the day job
<ijp>wingo: please bring back the three coloured go/stop/reload button kthxbai
<wingo>three colors? reformist. WE DEMAND MANY COLORS
<ijp>I think they got rid of that about 20 versions ago now :(
<wingo>after the revolution there will be 100000000000000 colors
<wingo>each one will have a name, i think ijp you are alloted about 500 to name
<TaylanUB>How does one find jobs where one can work on free software ?
<wingo>it's a good question
<wingo>either you find some free software project that someone is paying for, or you sneak in free software things in your work hours
<wingo>it happens most often with corporate-controlled free software, but it can happen elsewhere
<wingo>mozilla does a fairly good job fwiw, perhaps that could be a thing
<ijp>wingo: did you see the bug report from the guy running guile on a blue gene?
<wingo>ijp: haha, no i did not :)
<wingo>the things i miss by ignoring my email :)
***ijp is now known as Ijp
***Ijp is now known as ijp
<TaylanUB>ijp: On a what ?
<TaylanUB>wow :D
<ijp>it's plausible, because there is actually a bluegene/q at the university of rochester
<tupi>mark is not around, snif :(
*tupi is concerned about a possible solution before the end of this week for the (ice-9 popen) not thread safe bug
<wingo>tupi: poke me tomorrow evening if it isn't solved
<tupi>wingo: ok tx!
<wingo>i kinda miss debug-mode-only assertions
<wingo>in guile
<wingo>compared to other projects i work on.
<wingo>of course it's a complication, but still sometimes i don't do certain checks because they just ensure that things are like i expect them to be
<wingo>and the way they should be, in production...
<tristan_>Hi All
***tristan_ is now known as Guest61926
<Guest61926>I'm trying to test building guile-snmp with current master and am seeing an odd error
<Guest61926>I get a file not found from the load-extension
<Guest61926>even though strace indicates that the extension is being loaded, and I can't see any obviously failing opens in a strace
***fangism-shadow is now known as fangism
<Guest61926>The best I can tell at the moment, it is because I have an eval-when (eval load compile), but the load-extension is getting called, and as best as I can tell, it is working
***sneek_ is now known as sneek