IRC channel logs

2021-08-16.log

back to list of logs

<str1ngs>probably want to use a syscall for this if it's possible
<daviid>str1ngs: updating g-golf in guix would be wonderful, it needs 3.0 >= 3.0.7 or 2.2, 2.0 > 2.0.14 ... please make sure to pick the very latest commit 9ef7c0b1f4cfa3acd4750295f6ef558aa622d8bb
<str1ngs>daviid I think I can use 3.0.7 though maybe it might be better to wait til 3.0.7 is more ubiquitous?
<daviid>str1ngs: i meant to say that if 3.0, it has to be >= 3.0.7, not sure which version is in guix ...
<str1ngs>daviid: I can specifically use 3.0.7 but most guile packages are currently using 3.0.2
<daviid>str1ngs: i am now working on g-golf using 3.0.7
<str1ngs>I think only nomad is using g-golf right now so should not matter.
<daviid>str1ngs: that won't work
<str1ngs>3.0.2 won't work is what you mean? because I can use only 3.0.7 for g-golf
<daviid>3.0.7 fixes a long waiting fix that g-golf depends on ...
<str1ngs>right, not a problem I can use 3.0.7 it's just I'd have to do that with all the dependds like gulie-lib. it's not a big deal.
<daviid>g-golf won't work with any guile 3.0 < 3.0.7
<str1ngs>right yes I understand. I'm saying most guile libraries are using 3.0.2 so it bucks he normal. but it's still possible to use 3.0.7 which I'll just do since probably only nomad is using g-golf. and that puts g-golf a head of the curve.
<str1ngs>so update g-golf to use guile 3.0.7 by default. create a nother g-golf that for version to. something like g-golf-2.2 sound good?
<daviid>str1ngs: not familiar to guix enough, but when using autotools, g-golf checks which guile version the user has,and will accept 3.0 if >= 3.0.7, any 2.2 and 2.0 if >2.0.14
<daviid>str1ngs: i think 1 g-golf package is fine, so if guix has 3.0.7, go for it and don't 'loose' time with earlier version, i'd say ...
<str1ngs>I guess the question is are you okay with the default g-golf using guile 3.0.7? and if someone wants a guile 2 stack. I'll create a second package for that. ie there exists a guile-2.2-lib for gulie-lib for context.
<daviid>str1ngs: fine, i think 1 pkg using 3.0.7 is ok, till someone complains... to minimize your time ....
<str1ngs>only nomad is using g-golf currently. so targeting beyond the curve is good IMHO
<str1ngs>probably later defaulting to gtk 4 but that's another topic :)
<daviid>str1ngs: excellent, go for it ... i think gtk4 isn't in guix yet ... but it isin debianandthat iswhat i use daily
<daviid>g-golfnow has examples/gtk-4 as well
<str1ngs>I planned to look at that eventually. I figure by the time I release proper nomad version guile 3 and gtk 4 will be the norm everywhere.
<daviid>str1ngs: note that unless to run tests, g-golf 'build' doesn't depend onanyspecific gtk/gdk version
<str1ngs>so far, g-golf update worked no problem. and I'm really close to having nomad works with guile 3. I just need to push some changes for emacsy to support guile 3.0. so pretty happy. was quite painless. whatever work you did for guile 3 and g-golf helped greatly. much appreciated.
<daviid>str1ngs: welcome. could you confirm that those warningsyou were reporting earlier, you get those when using guile >= 3.0.7
<str1ngs>daviid: just with guile 3.0.7 they could be there with 2.2 but they don't cause critical loss of the binding.
<str1ngs>it more a PITA because insert is nice syntactic sugar for emacsy it works exactly likes emacs insert. so not something I can just rename.
<str1ngs>daviid: would it be okay to turn of tests for the guix package for the time being? until I can resolve this cannot register existing type 'GdkPixbuf' issue it only happens with Guix and currently only during the g-golf test.
<daviid>str1ngs: i thought the problemwas solved, but really, do as you think the best, and other guix 'expert' advise ... i don't remember well what the problem is/was - which is notimportant, just mentioning i don't remember ...
<str1ngs>daviid: thanks. I know what the problem is but I'm not sure how to debug it. the basically idea is multi versions of GIRS are "probably" being loaded as in there libs but they should not be. turning off tests helps for now until find a better solution. even guile-git suffers from this
<daviid>ah yes, i vaguely remember - if even guile-git has a similar problem, which is used by guix itself, likely at some point maintainers will find a solution, that will then hopefully apply to g-golf ...
<str1ngs>I don't think this would be the same problem as guile-git. since it seems gobject introspection related. but I could wrong.
<daviid>str1ngs: i don't understand, but you wrote 'even guile-git suffers from this (which surprised me ... but) - so i just repeated ...
<daviid>str1ngs: but never mind, my concern is 'what about examples', but till guix has gtk4, we won't t know ...
<str1ngs>daviid sorry I meant guile-gi my bad
<str1ngs>force of habit. I guess I use git too much :(
<daviid>ah, that make sense :)
<str1ngs>on letter makes such a difference haha
<str1ngs>one*
<str1ngs>I can test examples locally with ubuntu 20.04 if it helps. right now I'm just focused on guile 3 support. but I'll get there eventually. though ubuntu 20.04 should be on par with your debian distro IIRC
<daviid>str1ngs: indeed, :) - no need to test on ubuntu, examples definitely work,i meant do they work on guix ...
<daviid>because what prevents this 'bug' while running tests to 'appear' when using g-golf ...
<str1ngs>aye, it might be better if I help work on gtk4 after I'm happy with guile 3 support. its just that I need to make sure emacsy and nomad are working. g-golf looks good so I don't need to worry about that
<str1ngs>working as in with guile 3
<str1ngs>daviid you think that bug will go away with gtk4?
<str1ngs>what I can do though. Is update g-golf and add a g-golf 2.2 package in regards to guile 3 . then I can work on nomad guile's 3 and possible gtk4 at the same time. that should kill two birds with one stone.
<daviid>str1ngs: no i don't think so - till someone discover why guix tries to load and register more then once ...
<str1ngs>I suspect I'll be the only one motivated to figure out the GIR issue in that case.
<str1ngs>mother of necessity and all :)
<daviid>str1ngs: i don't remember who, but while you were 'away', two guix contributors started to work on gtk-4 for guix ...
<str1ngs>there is a gtk 4 branch IIRC
<str1ngs>daviid: raghavgururajan works on GTK IIRC
<str1ngs>but yes, maybe that is better focus of effort. I'll get g-golf upto guile 3 then I can stage my nomad changes locally mean time and work on gtk4 at the sametime.
<daviid>i think getting gtk4 in guix is a high priority, not for g-golf, for guix itself ...
<str1ngs>it's a win for everybody I agree.
<daviid>vijaymarupudi: so, get-item is 'shadowed-by' get-object, so you should call get-object instead
<daviid>vijaymarupudi: although i may fix g-golf so that g-list-model-get-item and get-item are defined instead - this will need a bit of work, in the mean time,please call g-list-model-get-object or get-object, will ping you when fixed
<raghavgururajan>sneek, later tell char: I have replied to your message in #48554.
<sneek>Okay.
<vijaymarupudi>daviid: I see, thanks!
<vijaymarupudi>daviid: I'm having trouble using Gtk.ListView.bind_model, see code here https://paste.gnome.org/po9drjvdl/tr2few/raw
<vijaymarupudi>daviid: Link to docs: https://gnome.pages.gitlab.gnome.org/gtk/gtk4/method.ListBox.bind_model.html
<vijaymarupudi>daviid: I get these errors
<vijaymarupudi>Warning: Unimplemented (pointer to): : void
<vijaymarupudi>(guile:254722): Gtk-CRITICAL **: 23:40:30.434: gtk_list_box_bind_model: assertion 'model == NULL || create_widget_func != NULL' failed
<vijaymarupudi>daviid: I tried many argument combos, not sure what to use
<daviid>vijaymarupudi: i'll try - tx for the snipset
***roptat_ is now known as Guest5707
<dokma>Can anyone tell me what is this dot notation?
<dokma>(match *open-sockets*
<dokma> (() #f)
<dokma> (((s . force-close) . rest)
<dokma> (set! *open-sockets* rest)
<dokma> force-close))
<dokma>What is it called?
<dokma>I don't see it in the match documentation.
<dokma>Is that a cons pair? (1 . 2) ??
<lloda>i updated gnulib for https://lists.gnu.org/archive/html/bug-guile/2021-08/msg00003.html but i don't have that glibc to test it
<lloda>anyone who can lmk
<taylan>dokma: yes that's a pair
<taylan>dokma: but remember also that lists are represented as chains of pairs in Scheme, like (first . (second . (third . ()))), so it can be used to capture the rest of a list.
<apteryx_>Hello Guilers! I have a problem where a port (the read side of a pipe) is always selected as ready (by Guile's 'select'), but read-char? on it says #f. Any ideas what that could be so?
<apteryx_>why*
<apteryx_>here's the full context: https://paste.gnome.org/py9lo4clj
***Guest5707 is now known as roptat
<dsmith-work>{appropriate time} Greetings, Guilers
<tohoyn>when will we have guile 3.0.7 in debian?
<apteryx_>dsmith-work: hello!
<apteryx_>tohoyn: you'd want to ask to vagrantc, but they aren't online ATM.
***apteryx_ is now known as apteryx
<apteryx>uh, I'm getting char-ready? #t on a closed port รด.O
<apteryx>hm, nope, pebcak
<apteryx>is it possible to unload a module at the REPL?
***Guest6445 is now known as chrislck
<apteryx>the Guile Reference manual also mentions (ice-9 time) should contain the 'profile' and 'trace' procedures, but I don't see them.
<apteryx>so yeah my problem remains that select says a file descriptor is read ready, while char-ready? says #f; which causes my loop to use all the CPU (it's unexpected that this should happen).
<apteryx>hmm, so perhaps if the child process doesn't close its write end of the port (a pipe), the parent will keep reading EOF from its read side when its empty? (an char-ready? says #t)
<apteryx>ah, it seems this may be by design of select?: "File descriptors associated with regular files shall always select true for ready to read, ready to write" per https://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html, which is not the same manual as 'man 2 select' returns on my system.
<apteryx>(mine doesn't say such thing)
<apteryx>this suggests the original scope of select is intended for something else than regular files, I'm guessing sockets.
<apteryx>hmm, but my file descriptor is that of a pipe... so not a regular file.
*apteryx is confused
<vijaymarupudi>Pipes should work
<vijaymarupudi>Is the port blocking when select says that it is ready?
<apteryx>what do you mean by "is the port blocking" ? it seems to always return EOF when there's nothing in the pipe's buffer, and doesn't seem to block waiting for more
<apteryx>here's a more recent capture of the debug output I see: https://paste.gnome.org/pxvcjfnd9
***ec is now known as tl
<apteryx>here's a minimal reproducer of my problem: https://paste.gnome.org/pd2ttdqti
<apteryx>perhaps it's specific to how the Guile child process handles its side (write) of the pipe?
<vijaymarupudi>When I replace get-string-all with read-char, I get a lot of <eofs>
<vijaymarupudi>Looks like get-string-all is not returning <eof>, instead it's returning empty strings
<vijaymarupudi>Maybe just use read-char, and then close the pipe when you get an eof?
<apteryx>vijaymarupudi: but it seems EOF here just means "nothing to be read at the moment", rather than "I'm done"
<apteryx>so supposing the child process would output stuff irregularly on a long period of time, closing the pipe after EOF would mean loosing future output
<apteryx>so what I'd really like to have is if select would do what it's supposed to be used for: block until there's really something to be read, instead of returning EOF whenever the pipe is empty
<vijaymarupudi>In C, read does not return EOF unless it's actually EOF
<vijaymarupudi>It would be odd if guile does the same
<vijaymarupudi>doesn't do the same*
<apteryx>my minimal example suggest it does, unless there's something wrong in my usage of select/pipes (likely? :-))
<apteryx>I'm rewriting it in C for the kinks
<vijaymarupudi>I don't see an eof in the minimal example until the process ends
<vijaymarupudi>I added a sleeps between the two prints, and there was no eof there
<apteryx>strange, what is your Guile version? https://paste.gnome.org/p7lymw7zo
<apteryx>I'm on 3.0.7
<apteryx>And get the same behavior with 3.0.2
<apteryx>and 2.2.7
<apteryx>vijaymarupudi: ah, "until the process ends"; so after it ends the EOF are expected?
<vijaymarupudi>I don't think we're getting different behavior, there's a discrepancy in what's being communicated
<vijaymarupudi>Yep!
<apteryx>I was hoping/expecting select would block in this situation rather than (unhelpefully?) telling me I can read EOF ad-eternam
<apteryx>unhelpfully*
<apteryx>as it seems to be meant to 'detect activity' on a port -- nothing happening (EOF) is not a meaningful activity ;-)
<vijaymarupudi>EOF is meaningful activity to me, it means close the fd, and don't put it back into select
<apteryx>I see! Then it's just my inexperience at POSIX/C programming. Thank you for clearing that up!
<vijaymarupudi>No problem!