IRC channel logs


back to list of logs

<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.
<sneek>Got it.
*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.
<vijaymarupudi>daviid: Thank you, the get-cursor method now returns a pointer. The docs mention there being two out values for this method. How would I get the other one? Additionally, am I responsible for manually managing the lifetime of the pointer?
<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
<vijaymarupudi>Ah, I still can't see the other parameter
<vijaymarupudi>Actually, I stand corrected
<vijaymarupudi>I see both the values now
<vijaymarupudi>What about lifetimes?
<daviid> - this is 'your example', just removed the with, and a few tiny changes ..
<daviid>vijaymarupudi: i still need to fix the other problem ...
<mfiano>rlb: Are you a maintainer?
<vijaymarupudi>daviid: Makes sense to me! This is excellent. Will I have to free the gtk-tree-path?
<vijaymarupudi>vijaymarupudi: I see, that bug looked a lot trickier...
<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>Ah I see, well, that's good then :)
<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.
<vijaymarupudi>Using `gtk-tree-path-free` that is
<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>*two infos ...
<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 ...
<daviid>vijaymarupudi: while talking about 'out arguments, makesure you read this in the manual -
<vijaymarupudi>daviid: I was not aware of that, thanks for the heads up
<vijaymarupudi>sounds good, I'll free the path
<vijaymarupudi>In PyGObject, they seem to make a class for the struct? I wonder if that's manual
<vijaymarupudi>Or automatically generated from the bindings
<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
<vijaymarupudi>Ah I see!
<jgart>Hi, is there an async version of system or system*?
<jgart>I'm having trouble finding it
<jgart>what does the guile community think of having crowd sourced docs like janet or clojure?
<jgart>or maybe a guile cookbook?
<tohoyn>sneek: botsnack
<sneek>tohoyn, you have 1 message!
<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>like this:
<manumanumanu>until about line 262 is what I use to dispatch and retain expansion control from user-defined macros.
<manumanumanu>jgart: pipes or (@@ (ice-9 popen) open-process), maybe?
<ArneBab>manumanumanu: ah, yes. Thank you!
<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>so core is significantly quicker?
<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?
<dsmith-work>Happy Friday, Guilers!!
<lloda>benchmark of (scheme base) vector-copy! vs a new version using memmove
<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
<leoprikler>probably yes, but maybe no
<leoprikler>for instance, it has no setf
<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>it being realloc
<vijaymarupudi>I don't know if guile-devel can be used for feature requests
<lloda>seems all right to me
<vijaymarupudi>Will draft one up right now
<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.
<RhodiumToad>do you have a simple example of the problem?
<manumanumanu>(let ((a #'banana) (b #'banana)) #`(let ((#,a 5) (#,b 4)) (+ a b))) makes for an invalid let.
<manumanumanu>this is a simple inane example
<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).
<manumanumanu>srfi-72 solves it, but it seems pretty forgotten.
<RhodiumToad>let: duplicate bound variable in form (let ((banana 5) (banana 4)) (+ banana banana))
<RhodiumToad>like that?
<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>(let ((banana 5) (banana-1 4)) (+ banana banana-1))
<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.
<manumanumanu>Anyway, SRFI-72 explains this better than I can.
<sneek>I've been running for 2 days
<sneek>This system has been up 2 weeks, 2 days, 4 hours, 22 minutes
<Sheilong>Is it possible to break a do loop?
<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.
<dsmith-work>(I know I like it better)
<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.
<leoprikler>obviously exit :P
<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.