<daviid>str1ngs: nothing to be scared of, g-golf will only call unref on a g-inst pointer iif the (goops) instance that holds it becomes/is unreachable <dokma>The pattern is (() #f) Shouldn't that match an empty list and a false? <dokma>The code is from guile's server.scm module <ft>dokma: if *open-sockets* is the empty list, it evaluates to #f. <stis>am about to compile 3.0.7 <iskarian>Hi all :) is there a guile method that sorts by key (that is, sorts with respect to the value of PROC(element))? <dsmith>scheme@(guile-user)> (sort '(1 5 2 4 3) <) <dsmith>scheme@(guile-user)> (sort '(1 5 2 4 3) >) <iskarian>dsmith, right. I was just looking for a shortcut so I could write, say, (sort lst #:key string-length) instead of (sort lst (lambda (left right) (< (string-length left) (string-length right))) <dsmith>Well, if you use that a lot: (define (string-len-< l r) {whatever}) and then (sort foo string-len-<) <dsmith>There is the cut stuff I've never used. <iskarian>Yeah, that's fair. Usually it's not worth adding another define so I'll just live with it <str1ngs>daviid: hello, I'm not worried about g-golf. it's just how nomad works. often I remove a widget from a container and then add it again. without ref the widget. Nomad has a buffer killhook where widgets are destroyed when the buffer destroyed. its more a emacs pattern and a anti GTK pattern. <str1ngs>I discovered this on my own `#(,(version)), can I this be called a quasiquote vector? <str1ngs>daviid but having read what you said in more details. then it might not be an issues since it sounds like the guile GC will destroy it for me? <daviid>str1ngs: ah, ok - well if you remove a widget, as in it becomes unreachable, with g-golf latest, it might be gc'ed, unless you keep a 'strong' reference in nomad <str1ngs>still this is not as bad as I thought. I was thinking removing a widget from a container would unreference it? <daviid>str1ngs: right - the thing to double check here is the ref count after you add and after you remove <str1ngs>okay, I'll have to test this some before I switch try it with nomad. also regards to g-golf I got some feed back on my patch series mainly related to guile 2. are you still wanting this commit 9ef7c0b1f4cfa3acd4750295f6ef558aa622d8bb ? <str1ngs>basically to do this series right I should add a guile 2 variant of g-golf. <daviid>str1ngs: when you instantiate a widget, its ref-count will be 1, then we need to check that adding the widget,asin add-child in gtk4 or add container widget in gtk3, raises the ref-count, sothat <daviid>str1ngs: so that when you remove it, the ref-countisone, then if unreachable, it willbe gc'ed, which calls unref - the thing to check in nomad, if you can, is to force a gc after you remove a widget and see if there isno bug... <daviid>str1ngs: do you understand what i wrote? not sure i am being 'clear' <str1ngs>I think so. basically it works like GTK normally does. <daviid>str1ngs: let's not mix subject fornow, and talk about guix version 'later',asin after we solve the issue we are talking about <str1ngs>in which case if I want to keep a widget after removing it I would need to g-object-ref it before hand. <daviid>str1ngs: well no, that's notwhat i wrote <daviid>(1) (make <a-widget>) - its ref-count is 1; (2) add ... - its ref-count is 2; (3) remove ... - itsref-count is 1 <daviid>so, you shouldn't need to call g-object-ref 'yourself' <str1ngs>ahh in which case it won't get distroyes. <daviid>just keep a strong ref tothe goops instance <str1ngs>destroyed. okay that's good. since this lets guile handling though. how do you handle the last reference. does goops have a destruction method? <daviid>str1ngs: it won't be gc'ed if you keep astrong ref to the goopsinstance <daviid>if what i wrote is indeed correct, which i'd be happy if you confirm <str1ngs>I agree, I think this will be okay. because I have guile references to the widgets <daviid>str1ngs: confirms means try, if i am correct, you should be ableto add, remove and add again <str1ngs>I will test, just don't have time right now for nomad. work, personal. but I will look at probably early next week. <daviid>ifthe last operationfails, letmeknow ... <str1ngs>from what you are saying it sounds like it will be okay. I was thinking in terms of how GTK works. <str1ngs>this is the right approach for guile IMHO <daviid>str1ngs: you may call and peek (g-object-ref-count (!g-inst your-widget)) before add, after add, after remove ... <str1ngs>gotcha will test it out next early next week. I did test g-golf and GTK4 on guix. no issues there BTW <str1ngs>I was actually hoping to help with some GTK4 things on guix, but been kinda busy. <daviid>str1ngs: ok (to both 'things' you just said) <daviid>str1ngs: now, wrt guix versions, wether guile 2.2 (any) or guile 3.0 (>3.0.7), you should pick the latest commit, bd0c3fa194f855bddc66c1645e5a0ab6c9286ff8 <str1ngs>okay, I'll bump git hash when I update my patch series. <str1ngs>btw if you were to git tag a v0.1.0 that would be really handy. Though that might break GNU standards? <daviid>str1ngs: sorry, i will only start to tag when start to release <str1ngs>understandable, just makes version in guix easier. ie I can just do git describe <ArneBab>vijaymarupudi: did you see my questions yesterday? <str1ngs>ArneBab: another advantage with guile. it's C interop is extremely good. most procedures can be called from C. There are 3 official ways to interop with C too. <dsmith-work>though there are Forces For Good that are pushing things to Scheme <ArneBab>which is a good thing and not contradictory :-) <stis>1 guiles hackability, Very nicely made compiler and infrastructure <stis>2. delimited continuations <stis>3. C-land infrastructure is really nicely done. <stis>5. absolurtely lovely to haveproper macro system <stis>6. that we can efficiently skip macros and use proper lambdas in stead . <vijaymarupudi_>ArneBab: I'm comparing Guile to Python, R, and C++. R has something like macros, but they're runtime and very slow, while Python and C++ have barriers for abstraction <sneek>Welcome back vijaymarupudi_, you have 2 messages! <sneek>vijaymarupudi_, ArneBab says: which language do you compare it to? <sneek>vijaymarupudi_, ArneBab says: and which aspect of Guile makes it great for prototyping and creativity? <ArneBab>stis: I’ll have to summarize that :-) <vijaymarupudi_>As for prototyping and creativity, I'd say quick startup time, the availability of a REPL, combined with macros and lambdas are the killer features for me <ArneBab>stis: do you have a language (or languages) you compare Guile to? <stis>1. delimitid continuations is superior to pythons yield, tha macrology is superior to any langugae except scheme, the hackability is better then essentially all closed sorurce solutions of program languages, fibers is better than all the cludge of marking procedures and what not and it is match by very few languages. And the efficient inlining of lambdas is perhaps matched by C, but not many higher langugaes. The design of scheme really shines <stis>here compered to e.g. python <ArneBab>stis: can I directly quote you on that (with typo fixes)? ***dongcarl4 is now known as dongcarl