<mark_weaver>and after doing that, the next time you spawn the inferior guile process via geiser, it should inherit those variables. <mark_weaver>(if you already have guile running, then you can exit it and relaunch guile in geiser after setting them) <paroneayea>hey, C-c C-a is a great geiser feature I didn't discover till now :) <ijp>You'll need to excuse the one line compiler output <ijp>I was mostly rewriting the existing code to be not-awful, but I did get that early escape with call/cc to work <ijp>davexunit: very little on my part since we already had cps <davexunit>ijp: oh so you're compiler operates on the output of cps? <ijp>I take the output from cps, run the same few passes that compile-bytecode does (closure conversion / renumbering / etc) and then operate on that <ijp>once I have a decent amount done, I'm going to try and reconstruct more idiomatic (hence faster) javascript <ijp>well, I can push it no problem, but not right now <ijp>I was something of a wreck last week, but now I'm pretty comfortable with it <remi`bd>hey guile! a question about Dynamic FFI: when you make up a pointer by yourself using make-pointer, you can specify a finalizer function that Guile will call once your pointer becomes unreachable; but if I have C functions create_foo & destroy_foo that allocate/deallocate space on the heap, how can I tell Guile to use destroy_foo as a finalizer to pointers returned by create_foo? <amz3>how do I convert an float to an integer ? <amz3>well integer? returns #t for 123.0 <amz3>remi`bd: you have to make-pointer I think <amz3>remi`bd: again, I'm not sure, but I think that, it's when you use scm->pointer that yoiu don't need to register a finalizer <remi`bd>and to convert a real to an integer, you have truncate, round, and ceil <mark_weaver>amz3: in the scheme world, 123.0 is an integer, but an *inexact* one. <mark_weaver>scheme handles numbers in a very different way than most languages <mark_weaver>it keeps track of a semantic "exactness" flag automatically, associated with numbers. <mark_weaver>so you can know by the exactness flag whether or not a result might differ from the mathematical ideal. <mark_weaver>and then some operations require an exact integer, e.g. the indexing operations like 'vector-ref', 'string-ref', etc. <mark_weaver>so, with that background in mind, I'm curious how the number became inexact in the first place, and why you want to coerce it to an exact one. there are valid reasons, but in practice we don't need inexact->exact very often. <amz3>I building a texture programmatically in sly, the number is in a list passed to list->u8vector <amz3>in sly (make-color) takes rgba in [0..1], but textures have their values [0..255] <amz3>(the texture is a single color, nothing fancy) <davexunit>amz3: do you know about bytevector->texture? <amz3>davexunit: what texture shall I use for the shape? <amz3>null-texture doesn't work <amz3>model-paint + null-texture <amz3>Maybe I should change blend mode? not sure what blend mode is. <amz3>you will also need color->texture which I've put right now in sly/texture.scm <amz3>btw kivy use libtess2 to draw shapes <davexunit>well I don't want to use color->texture because it's pointless <davexunit>you need to pass a color object to model-paint <davexunit>amz3: model-paint will not work with a texture argument <amz3>I'm not using a texture argument: (define player (model-paint (make-color 0 1 0 1) (make-circle yellow))) <amz3>I tried the following: (define player (model-paint (make-color 0 1 0 1) (make-circle null-texture))) <amz3>davexunit: maybe i made other changes to sly code... I should push my code somewhere <amz3>it's ok I've do no changes besides the color->texture <davexunit>this might require an alternative shader or something. <amz3>hmm... shader. hmm.. probably! <davexunit>but I'd the default shader to work with this <davexunit>when the model uses the null texture, the expectation is that texturing is turned *off* for that draw call, but that doesn't mean the polygons shouldn't be colored. <davexunit>a-ha, this will have to be an additional shader parameter. <davexunit>the shader program will need to know if texturing is enabled or not. <davexunit>I need to make the whole rendering pipeline more modular, but I'm not sure how to do it. <amz3>on my side, I'm not in a hurry <davexunit>I really want to be able to write shaders in scheme, but we're a ways off from there. <amz3>I had this period where I wanted to write everything in python too :) <amz3>now I want the same in guile ^^ <davexunit>sneek: later tell amz3 pushed 2 commits to fix the null texture issue. <paroneayea>davexunit: we need something like start-sly-repl for the web loop in guile :) <davexunit>would be cool to have a cooperative repl but it's harder to integrate <davexunit>the http server needs other improvements, too. <davexunit>like allowing for a websocket implementation. <paroneayea>damn those racket people and all their cool toys! <davexunit>ah, this just creates its own websocket server <davexunit>I was trying to integrate with guile's http server <davexunit>but perhaps I should've just done something like this. <davexunit>yeah I was referring to this and the RFC while writing my code <paroneayea>oh well. Soon I'll start doing some guile web hacking for activitystuff. Maybe I can be more useful re: guile and web things then. <davexunit>guile's web modules are really well done, I think. <davexunit>a more robust web server would be nice, but the building blocks are great. <davexunit>URIs are a real data type and not just a string <paroneayea>I went through the manual and the little tutorial it had at the end <paroneayea>davexunit: so back to the repl, do you use spawn-server to start a repl in another thread then? <davexunit>which opens you up to thread synchronization issues <paroneayea>I guess you don't need thread safety really when just hacking something with GET and POST operations though <davexunit>but in practice it isn't much of an issue if you control every request that is made to your dev server. <davexunit>I'm not sure how a cooperative server could be integrated. <please_help>I have a function and I want to override its definition to add a statement to it while still calling it if the statement evaluates to false. Closures don't work for this it seems (they don't capture the environment??), and referring to the previous name doesn't seem possible inside the new function's body. What can I do about it? <taylanub>please_help: (set! function (let ((original-fn function)) (lambda () <use original-fn here>))) or so? <taylanub>closures do capture the environment (by definition); I'm guessing you had some scoping issue or so <taylanub>please_help: why do you need to "override" a function though? <please_help>taylanub: that works. Reason I need to override is that the same function is used as part of a generic framework that support arbitrary amount of "plugins". <taylanub>hm, ok. something like Emacs Lisp's "advice" system would had been neat for your use case I suppose. <ijp>you need to be careful when overriding, since you might have old references to the function still around <taylanub>please_help: if that is a common point of modification, how about making the main function be aware of possible extensions, and e.g. call to procedures in some global data structure that can be populated? <taylanub>a list, in the simplest case, so it would be like hooks in Emacs <ijp>if you want hooks, use the existing hook functions, but you till have an issue <ijp>(add-hook *blah* foo) (set! foo frob) (run-hooks *blah*) ; calls original foo, not frob <taylanub>oh, I forgot Guile has hooks (info "(guile) Hooks") <taylanub>well, a hook doesn't really sound like the right thing here since the return value of the added statement determines what happens later <please_help>hooks don't give me both the output of the previous hook and the original arguments though <please_help>in that case I should instead make my own list of functions and fold through it I guess <ijp>hooks were not a suggestion for implementing advice <ijp>when I wrote a "plugin" system using guile, I just used guile modules as the plugins with specific magic identifiers <taylanub>please_help: maybe you want something like: <taylanub>(unless (any (lambda (proc) (proc my-args)) user-added-functions) <taylanub>that'll go through `user-added-functions' until one returns true, and if none do it will use <original-code> <please_help>In the one specific instance I'm working on right now, I want (define (apply-the-functions . args) (fold or (map (lambda (x) (apply x args)) list-of-functions))) <please_help>well, the fold call is incorrect but you get the point <please_help>in general I want (apply-the-functions . args) -> (fold (lambda (next prev) (apply next prev args)) *nothing* list-of-functions) where *nothing* -> some (gensym) ***karswell` is now known as karswell
<cybrNaut>is there a convention for making a ./configure script use a particular version of guile? <cybrNaut>e.g. something like --with-guile=/usr/bin/guile-1.8? <daviid>cybrNaut: it's done in configure.ac, like PKG_CHECK_MODULES([GUILE], [guile-2.0]), look in the manual, ection 5.8 Autoconf Support <ijp>hmm, when does guile use a toplevel box, and when does it use a module box with (guile) <ijp>hmm, it probaby uses the former for the current module <cybrNaut>btw, i don't seem to have a choice in versions <cybrNaut>gnucash broke ledger in a migration from wheezy to jessie <cybrNaut>so i need to compile gnucash 2.4.10 on debian 8. <daviid>gnucash team would break API between 2.4 and 2.6 ? i'd rather use jessie version and solve the ledger related prob if i was you <daviid>using a gnucash version which forces you to use guile-1.8, unmaintained for about 6 years now, is the perfect route to hell :), my 2c <cybrNaut>daviid: i tried that first and it was a disaster. ledger can directly read gnucash 2.4.10 files just fine, but not 2.6.x. it's a shame there was no debian "suggests" or "recommends" relationships between the packages, which might have prevented the version advancement <cybrNaut>gnucash 2.6.x only has experimental hacks for getting the data out <daviid>you should bring this to gnucash people <daviid>it make no sence to me that they would not be able to read a ledger from 2.4 in 2.6 <daviid>but hey, i'm not even using gnucash <cybrNaut>daviid: it's the other way around.. ledger reads gnucash <cybrNaut>gnucash developers seem to be unaware of ledger <daviid>how come? it's in the manual 6.16. General Ledger <ijp>er, whoops, merge.html is wrong, it should oonly have copied the region <civodul>shouldn't the output be turned back to direct style? <civodul>wingo would know which form JS compilers would best be able to optimize <civodul>i suspect they work best when the input is direct style <cybrNaut>daviid: "ledger" is also a generic term in accounting, and i suspect that's what you're seeing <civodul>anyway, that's already excellent news <daviid>cybrNaut: anyway do as you wish, but you've been warned, do not use guile-1.8, unless you're 1 of the devel's friend :) <cybrNaut>daviid: i'm trying for the easiest path -- which is apparently the path of the devil <ijp>civodul: asm.js is the ideal, but I want to be able to compile full modules first <daviid>try to fix this ledger related prob instead, use the latest gnucash... <davexunit>if you scroll down the generated JS it's like a little roller coaster <ijp>civodul: how are the guixlings comeing along <ijp>davexunit: well, that's what uglifyjs calls beautiful, and it's at least better than the minimised one liner I'm actually generating <civodul>ijp: well, it's making progress everyday :-) <civodul>the main thing that needs improvement now is GuixSD support <ijp>civodul: I was meaning the gsoc students <ijp>davexunit: I've actually done very little today, since I'm just cleaning up for a "release" <civodul>phant0mas has done great work on the Hurd stuff <ijp>and I have relatives down from Glasgow, so I can't be rude <civodul>the GNUnet project is still at the very beginning, just writing bindings for GNUnet so far <ijp>maybe that should be "up from" <civodul>the DHCP client seems to be on track <davexunit>ijp: OT, but how is Glasgow? I visited Scotland many years ago but never made it there. <ijp>it's okay as long as you don't go into any of the football bars <taylanub>MikOo: you can see code generated by Guile's optimizer by using the ",optimize" command in the REPL, and you can benchmark snippets via ",time" and profile them via ",profile" <taylanub>MikOo: but unless you really have very performance-critical code, I would say don't worry about such small differences <MikOo>taylanub: yes I saw repeated2 and 3 are not tail-recursive. <taylanub>repeated3 looks tail-recursive to me, but I don't think that matters much becuase in any case the call to 'repeated' builds up the whole chain of closures, so when you call them it's all the same <mark_weaver>MikOo: where efficiency is paramount, in inner loops, you should try to avoid calling procedures defined at the top-level, because top-level bindings are always mutable (they can be set!) so the compiler can't assume anything about them. <cybrNaut>where is the guile config normally kept? <mark_weaver>however, for inner bindings, if they are not 'set!' anywhere in their lexical scope, then the compiler can assume they are immutable and can do inlining. <MikOo>taylanub: repeated is tail-recursive <taylanub>cybrNaut: what kind of config do you mean? <cybrNaut>taylanub: i'm not sure myself.. I just know that to compile gnucash, I must supply the guile config file <mark_weaver>so, for example, if 'compose' is defined within something else, e.g. another procedure or (let () ...) then those will be candidates for inlining, and a much faster loop is achievable. <taylanub>cybrNaut: do you perhaps mean a "pkg-config" file? <ijp>repeated itself is not tail recursive, but f_iter in repeated is <mark_weaver>maybe you are thinking of the 'guile-config' program? <MikOo>mark_weaver: yes at the origine compose come from another file, but compose is a general function, that it could use every where not only in repeated2 <cybrNaut>i'm told i need to run => ./configure GUILE=/usr/bin/guile-1.8 GUILE_CONFIG=guile1.8-config <cybrNaut>but the "GUILE_CONFIG=" needs something on the right hand side, i suspect.. not what's there <mark_weaver>MikOo: right, and 'guile' provides a 'compose' procedure in the default environment. for most purposes, I wouldn't advocate microoptimizing things like this, but where efficiency is paramount sometimes hacks are needed. <MikOo>mark_weaver: ok thanks, I learn shell... <mark_weaver>modern scheme standards (r6rs and r7rs) mandate that any variable imported from another module is immutable, which would allow us to do inlining, but we have not yet implemented that in guile. <taylanub>BTW I think the top-level/internal difference won't make much a difference here because if I understand the intent correctly, it's probably to make the generated procedure more efficient, and not the generation of said procedure. all the calls to compose will happen during the generation, and not when later calling the generated procedure. <mark_weaver>and anyway, for native guile modules, we will have to maintain our older semantics where all top-level variables are mutable, for backward compatibility. <davexunit>mark_weaver: how would that affect re-defining things at the REPL? <mark_weaver>davexunit: the REPL is a different case, where of course the set of bindings changes over time. <paroneayea>mark_weaver: I wonder if something could happen like <mark_weaver>but even r6rs and r7rs allow mutable variables, they just don't allow mutating variables from another module. <davexunit>mark_weaver: for a scenario: I enter modules from the REPL and re-define procedures that are used by others. <davexunit>ohhh so I guess this scenario remains unaffected. <mark_weaver>(and for r6rs, they don't allow mutating any variable that is accessible from other modules) <MikOo>mark_weaver: I note that for future, but at this time is a simple exercise <mark_weaver>davexunit, paroneayea: guile will have to continue supporting the existing module semantics, of course. large amounts of code depends on it. <MikOo>I use guile because I can see the calling stack with ,trace <ijp>MikOo: a simple rule of thumb is that performance correlates with allocation <ijp>less allocation more faster <ijp>by this rule of thumb, I'd expect repeated to be the most performant at creating the procedure you return <mark_weaver>but perhaps we will add another kind of module that support immutable top-level bindings that can be inlined. <mark_weaver>MikOo: yes, ijp is right. repeated avoids allocation and is the fastest. <MikOo>ijp: I think so, I find repeated2 on the net <ijp>performance of the returned procedure is more subtle, but generally speaking I'd still expect repeated to win, since it would be a loop + n calls to f, instead of n function calls + n other calls <MikOo>it is an exercise from SICP (1.43) <mark_weaver>repeated2 is not tail recursive. it uses stack space proportional to n <MikOo>mark_weaver: it is the worst in fact <mark_weaver>well, not just stack. it allocates n closures before composing them <mark_weaver>I should mention actually that scheme has no concept of a stack, but typically implementations use one where possible for efficiency. *taylanub prefers simple code over "elegant" code and would do it like this: http://sprunge.us/NJMA that's code I could understand even when drunk :-) <MikOo>taylanub: it is just another way <ijp>huh, I never realised that when I call meta/guild it used the installed guile rather than meta/guile <ijp>non-linear patterns in match are so nice, but I only use them like three times a year <paroneayea>everything converts back and forth now, which is good <please_help>I have to generate an A by B by A by B matrix while calculating dX/dX where X is an A by B matrix (that is, dX/dX = D -> Dij = dX/dXij). With even small real-world test cases, that's more than 5 GB memory. I then need to go over the A by B subarrays and set a single element in each of them to 1. Any way to not generate something so outrageously expensive, off-hand? *ijp goes hunting for the missing argument <ijp>turns out that wasn't a new bug, it just wasn't as noticeable in the more verbose representation <ijp>hmm, no, I don't think this is a bug, just a misunderstanding, maybe *ijp gives up for the day