<ArneBab>leoprikler: you have to jump through some ugly hoops to make it unhygienic <easbarbosa>hey, whats is meaning of: #$output #~() and the likes? tnx <rlb>sneek: later tell tohoyn it's unlikely to be added to unstable until bullseye releases (i.e. too far in the freeze to be accepted, and we'd also want the macro fix we added recently), so once bullseye is out, we can add it to unstable, and then it'll propagate to testing. *rlb guesses that it'll be 3.0.8 that goes into unstable, though I'd also like to resolve the inlining issues first too. <daviid>vijaymarupudi: (ice-9 receive), or let-values ... let me paste an example <vijaymarupudi>I've been using call-with-values, maybe I'm going it wrong, one sec <daviid>vijaymarupudi: i still need to fix the other problem ... <vijaymarupudi>daviid: Makes sense to me! This is excellent. Will I have to free the gtk-tree-path? <vijaymarupudi>I like g-golf's little touches like using multiple returns, seems as idiomatic to guile as oop can be <daviid>vijaymarupudi: tx, but i didn't invent anything - all languages that implement multiple-values do so in their GI bindings and 'out arguments ... <vijaymarupudi>daviid: Just making sure I have an answer, do I have to free the gtk-tree-path? Don't want to have any memory leaks if possible. <daviid>vijaymarupudi: no, as itis you don't need to free the path <daviid>vijaymarupudi: but after i fix 'that problem' exposed by clone, probably, we'll see - in the mean time, you should extract the path indice(s) as you receive the path, as it will be gc'd ... <daviid>vijaymarupudi: actually need to double check, i mixed twoinfo here <daviid>vijaymarupudi: sorry for the confusion, but yes, you'll need to free the path returned by get-cursor <daviid>*you/one need to free the path returned by get-cursor ... <vijaymarupudi>In PyGObject, they seem to make a class for the struct? I wonder if that's manual <daviid>vijaymarupudi: as things are, in g-golf, none opaque struct are serialize/deserialized, and so you receive or pass a list of values - opaque struct, you receive and 'blindingly' pass the lib pointer - opaque struct -> goops class, maybe (probably), but not a priority for now ... <daviid>vijaymarupudi: wrt PyGObject, opaque struct as classes is definitely done automaticallty, not sure about how they 'treat' none opaque struct though <jgart>Hi, is there an async version of system or system*? <jgart>I'm having trouble finding it <sneek>tohoyn, rlb says: it's unlikely to be added to unstable until bullseye releases (i.e. too far in the freeze to be accepted, and we'd also want the macro fix we added recently), so once bullseye is out, we can add it to unstable, and then it'll propagate to testing. <manumanumanu>leoprikler, ArneBab : No. It only guarantees outward hygiene. I was hit by this recently: I tried to write a looping facility using syntax-case, and I programmatically expanded the (in-list ...), (in-xxxx ...). in-list introduces 2 bindings (%pair and %cursor), but since I was never leaving syntax-case during the programmatic expansion, these 2 bindings collided even thought they were not from the <manumanumanu>same expansion, nor from the same place and time. This is all documented in syntax-case, and not surprising. It is what I usually mean when I say that syntax-case is not hygienic enough. If you introduce bindings, and you risk introducing the same binding twice within the scope of one call to the syntax transformer you must use gensym (yuck) to ensure hygiene. <manumanumanu>srfi-72 solves this by making sure that any binding introduced will be unique unless they are the same object. <manumanumanu>but that never caught on so now I have to either gensym or use continuation-passing syntax-rules macros, which is as much fun as you'd expect. <manumanumanu>until about line 262 is what I use to dispatch and retain expansion control from user-defined macros. <leoprikler>manumanumanu: Guile has quasi-syntax tho: see #` <leoprikler>And I'm pretty sure it's defined in terms of syntax-case ***Guest3569 is now known as chrislck
<lloda>benchmark of core vector-fill! vs the vector-fill! that was in (scheme base) <leoprikler>btw. this is compiled mode, right? no interpreter overhead <lloda>this isn't surprising, the core version is just a for() *a++ = x loop <dthompson>anyone had issues evaling guile code in geiser lately? <dthompson>I can eval stuff in the geiser buffer just fine <dthompson>but when I do C-x C-e in a scheme buffer it throws a strange error <defolos>hey folks, anyone knows how well guille supports elisp? <lloda>(scheme base) vector-copy! uses move-left/move-right, so it's C either way <leoprikler>defolos: enough to run vaguely do stuff in it, but it's no drop-in replacement <defolos>leoprikler: thanks, so the basic stuff should work I guess? <leoprikler>depends on what you mean by "basic stuff", but yeah <lloda>memmove is smart enough to do nothing when asked to copy self, but there's enough improvement for the mid sizes that I think it's worth it <defolos>leoprikler: mostly get basic lists out of an elisp file <vijaymarupudi>Q: Is there a way to get destructor semantics from GOOPS? In other words, can I arrange for a method to run when the instance is being garbage collected <lloda>vector-move-left! vector-move-right! are bad primitives, there's always one which is the correct one and the other is wrong, vector-copy! frees you from that decision <vijaymarupudi>Also, speaking of vectors, I wonder if it's possible to have a vector-resize function that uses realloc to take advantage of the mremap syscall <lloda>if that is linux only, an alternate impl would be needed <lloda>probably worth writing to guile-devel about it <defolos>leoprikler: ok, well I guess I'll just try it first <defolos>and if it works then I'll stick with guile, otherwise I'll use emacs itself <vijaymarupudi>Oh, libc's realloc in Linux uses mremap, one would just need a function that uses it to resize a vector. The only way to do this right now seems to be making a new vector and copying it in <vijaymarupudi>I don't know if guile-devel can be used for feature requests <manumanumanu>leoprikler: yes. That I know. But the know-how to implement a (forcefully-hygienic-quasi-syntax ...) is currently not available to me <manumanumanu>hmmm. I could do an eq-hash of all syntax-objects AND symbols and only allow colliding symbols if the eq-syntax-objets is also in there. <manumanumanu>but, continuing my proud tradition of lacking intellectual rigour: this is the way of someone who doesn't understand how quasisyntax works under the hood. There are probably loads of problems with this. <manumanumanu>Pondering this while doing laundry I already found at least one problem. <manumanumanu>(let ((a #'banana) (b #'banana)) #`(let ((#,a 5) (#,b 4)) (+ a b))) makes for an invalid let. <manumanumanu>But it shows the problem. I had a looping construct that I tried to write in syntax-case where I programmatically expanded the loop clasues. The problem was that if I had 2 (in-list the-list) in the same loop, they introduced the same bindings using that method <manumanumanu>(the loop variables were called %cursor and %pair) or something like that. I didn't want to push the use of gensym on to whoever were writing the clauses, so I had to solve it differently <manumanumanu>RhodiumToad: sorry, that example is an error anyway: the (+ a b) should be (+ #,a #,b). <RhodiumToad>let: duplicate bound variable in form (let ((banana 5) (banana 4)) (+ banana banana)) <manumanumanu>RhodiumToad: yes. SRFI-72 guarantees "internal hygiene", whereas r6rs syntax-case happily consider two #'bananas to be the same, even though they can be introduced at completely different times, as long as they are introduced within the execution of one syntax-transformer. <manumanumanu>SRFI-72 would treat those as two different bindings, and rename one of them. <manumanumanu>This is only really a problem once you start expanding macros programmatically. Racket has local-expand which expands a macro in the context of the current macro, which solves the problem IIRC. <manumanumanu>using gensym for your own variables isn't bad. But in my case I would have had to force others to use it, which feels icky. <manumanumanu>because if anyone wants to write an iterator clause for goof-loop I want them to be able to do it in syntax-rules. <manumanumanu>If I programatically expadn a body of something and splice the results into a syntax object, I don't want it to behave differently than if I had not programmatically expanded the macro. <sneek>I've been running for 2 days <sneek>This system has been up 2 weeks, 2 days, 4 hours, 22 minutes <ft>Arbitrarily? There is call/ec from (ice-9 control). <dsmith-work>Sheilong: `do` does not. `while` has break (and continue). <dsmith-work>I think do is not used very much. Named let seems preferred. <Sheilong>Yes, arbitrarily. Anyway, I need to debug my code, I did some mistake in here and things are not work as it should lol. <rlb>mfiano: I do maintain debian's guile. <mfiano>rlb: I see. I never formally reported a bug I discovered, being new to Scheme. Just wanted to get a maintainer's opinion.