<amz3>sure it's not a simple matter <amz3>manumanumanu: at last, I use and-let* <wingo>amz3: intmap should generally be better than fash unless your integers are spread quite far apart <amz3>oh then I think I will use fash because I spread revisions over random unsigned 64 bits integers and most likely there is much less than (expt 2 64) revision in my history (otherwise said revision numbers are far apart) <amz3>I have a procedure that is 79 lines of code, that is a "delayed continuation" aka. some kind of lazy stream and I am not sure right now how to make it shorter <amz3>79 lines in one hour that are not tested... not bad ;) <manumanumanu>amz3: and-let* is my favourite srfi together with cut, fmt and irregex <manumanumanu>especially together with false-if-exception for smaller scripts (or (and-let* blah blah) (error "blah")) <manumanumanu>which is more the CL way of doing stuff, but it is nice anyway ***justin2 is now known as justin_smith
<stis>darn, a deepcopy of a continuations is impossible in guile 2.2, int guile 2.0 it is possible <stis>the reason is that the contination has a copy of the stack and it is impossible to know which stack element is immediate or not <stis>I'm looking at a python clone in guile that I made <stis>in python you have deepcopy which is different from continuations <stis>in continuations you copy the stack but in a deep copy you should continue dig into variables on the stack so not only copy the references but the whole object <stis>This is needed if you would be able to completely regenerate a calulation for which you can't in a delimeted continuation which is a shallow copy <stis>If your program is functional this is a non issue. The thing is that python programs mutate en masse by design <stis>but the issue in 2.2 is that you don't know if an object on the stack is a SCM value or a unpacked intermediate. <stis>The compiler knows, but not the continuation <stis>as an example, take the tee function in python itertools. It takes and iterater and makes multiple equals copies, would be swell to just do deepcopies of those <stis>but then you have iterators via the yield statement meaning that you use delimeted continuations. For guile code that is ok. But these continuations usually ivolves <stis>involves a for loop, for which you typically must mutate variables, meaning that you are sold when copying the stack <stis>no you need to do some C magic. I do have deep copy of closurs wotking for 2.2 <stis>It uses some compiled C code to dig into the guile internals. Would be great to haw scheme support but we don't have it <stis>I took this from my prolog implementation <stis>Also in my guile prolog I use closurse in stead of delimeted continuations and have a special version of delimeted continuation implemented in my c engine which supports deepcopy by the way. <stis>This means that I can serialize an entire state which is cool. <stis>whould be great if a python program could be serialized like that as well, but no it can't. To be honest cpython can't do that as well <stis>cpython can't picle lambdas and for iterators I don't know. <stis>(sure classes but what about generators) <stis>well I'm quite finished with the core python, now I need to code the batteries, a lot of things to learn <manumanumanu>I myself am trying to write a simpler ffi for guile that allows for passing bytevectors without bytevector->pointer and allow for defining your own external types, but without any performance penalties <stis>I will implement tee differently like in cpython <stis>the ffi is cool and fun as well <daviid>lloda: are you there? did you solve your problem compiling gwrap? <daviid>and guile-gnome... all work with the latest here ... fi <manumanumanu>stis: the problem is that my old approach was a hash with symbols as keys, which is all fine and dandy, until someone redefines an already defined type <manumanumanu>so I made types regular records of syntax objects of the lambdas want to use, but that has a performance pnalty <manumanumanu>and you could specify the bytevector argument, and it implicitly wraps in in bytevector->pointer, or even nullable-bytevector which converts #f to %null-pointer <manumanumanu>The thing is, if it isn't zero overhead after the optimizer is done with it, I am not interested. <manumanumanu>but that was harder than I thought. I keep bumping into corner cases <manumanumanu>and I keep thinking that the first option of storing all new types in a hash is the best way <stis>(define mytype (cons 'mytype (current-modeul))) <stis>and an eq hash on those keys? <stis>so if you keep the types local to the module unique you won't get too much trouble <stis>perhasp you should use an equal hash donough <manumanumanu>the thing is, I already have a hash of the already existing types <manumanumanu>because I overwrite the default ones. That is simpler than detecting whether they are renamed from (system foreign) <manumanumanu>and makes it clear that mixing the two modules isn't a good idea <stis>you may wrap the standard types and make them non symbol as you use them, but represents themselves as the foreign types <manumanumanu>you may explain that in swedish to me in a private conversation :D <stis>it depends on how you use the types, <stis>(define double (list 'double (current-module) (lambda () 'double)) <stis>And then the constructor would be ((list-ref double 2)) -> 'double <stis>but it all depends on how you are working, hard to see it from my distance. <stis>there are multiple options, but you link a type to som construction function like my simple one <stis>anyway got to go see ya! <bavier`>daviid: could you "fix" guile-cv's repl print issue in guile by using srfi-9 records with an appropriate custom record printer, instead of lists, to represent images? <bavier`>forgive me if this has been discussed before <daviid>bavier`: that would mean a complete rewrite of gule-cv, and i did think very carefully before to choose the date structure ... and decided to use lists, otherwise i would have used goops, not records, but that won't happen I'm afraid, so we have to wait for guile maintainers to address this (very annoying) limitation, that by the way, I am far from being the only one expressing a wish for a repl and raised exception system capable of <daviid>truncated large strucutres ... we just have to be patient, they will fix this, one day or another <bavier`>sure, just thought I'd ask; didn't know what avenues have been explored already :) <daviid>bavier`: patching guile is really easy, and I wrote a very good entry in the manual for this, but it is just that malbda users ar scared to patch, which is uunderstandable <bavier`>yeah, I was thinking about how to incorporate those patches into guix's guile; whether or not the change would upset other usecases <daviid>bavier`: I've asked both rikardo and civodul, who's also a guile maintainer, and they said they dont want to do that, they wan't to patch guile ... <daviid>they don't want to patch the guile version in guix, they wan't to wait guile upstream being patched ... <daviid>and agree, it's just that I dod not expect to have to wait so long ... training patience here :) .. I'm unemployed, may months now, otherwise I'd pay one of the maintainer to fix this ... I can't <daviid>bavier`: so xcolor is the monster then? <daviid>I guess it triggers lot's of otherdepencies ... <bavier`>daviid: heh, yeah, there is some subtle setup involved in building it and some dependencies. <daviid>too bad, sorry about that, and thanks again, take your time .. I think your approach is the right one <daviid>I should make another release of guile-cv in March, mid March probably, el'ts see