<dsmith>sneek: later tell dokma Here's an idea: If all you need is a signal to exit a blocked syscall, how about using SIGUSR1 or SIGUSR2 and have the signal handler that just returns? <vijaymarupudi>daviid: That seems to work, thank you very much! I'll do further experiments with GtkListView and will report if I find anything odd <daviid>vijaymarupudi: ok, perfect - for the record, the GI team did mention that theywere happy icould fix, sayingf that this was not possible in GJS originally,and only fixed after 5y ... <vijaymarupudi>daviid: Oh wow, I'm glad you could get this figured out! I looked like you didn't have to change too much code to do so too <daviid>i'll look into your last post then ... let me check ... 'll get back <vijaymarupudi>Looks like all subclasses have the same g-type and g-name, not a problem for me right now, just an observation <daviid>vijaymarupudi: right, didn't have to change much indeed, but it took me a few hours to figure out this 'simple solution ... proof that although i didn't think about this in early design phase, the design i cameup with is 'robust' :) <daviid>you mean subclasses of <person>, iteslf subclass of <gobject>? <daviid>tx for the nicewrods about my commit msgs:) ***chris is now known as Guest4988
<vijaymarupudi>Greatly appreciate the time spent, g-golf is coming along nicely :) <daviid>vijaymarupudi: ah ok, yes that is expected - g-golf looks and takes the first superclass that is either <gobject> or a <gobject> subclass ... <daviid>vijaymarupudi: expected for derived classes - that is <daviid>vijaymarupudi: so, g-list-model-get-item is a vfunct, and g-golf misses it - i'll get back asa i have thoseimportedaswell, which right now is'nt the case (yet) <daviid>vijaymarupudi: you know that Gio ListModel is an interface right? so you shouldn't (even try to) instantiate, but use a class that implements it ... just tomake sure ... ***chris is now known as Guest6445
***edmrk is now known as fren
<str1ngs>hello daviid, I almost have a working guile-3 stack for nomad. but I'm having some issues with g-golf's short names clashing with a generic method despite adding it to %gi-method-short-names-skip. e.g. WARNING: (nomad gtk widget): `insert' imported from both (g-golf) and (emacsy emacsy) <roptat>if I have a string like "src/*.c", how can I find these files with guile? <roptat>I tried looking for glob in the manual, but that didn't return anything useful <roptat>maybe it's not a glob pattern either, there's ** which means "anything at any depth" <flatwhatson>roptat: not sure if there's a globbing library, but in general there's file-system-fold from (ice-9 ftw) <flatwhatson>just need to translate your glob expressions to regexes <dokma>Definitely a bug: guile -s <(echo '(use-modules (system repl server)) (define ss (make-tcp-server-socket #:port 51281)) (run-server ss)') <sneek>Welcome back dokma, you have 2 messages! <sneek>dokma, avp says: yes, REPL allows to define new procedures. Did you call 'ks-shutdown' right after the definition, in the same REPL session? <sneek>dokma, dsmith says: Here's an idea: If all you need is a signal to exit a blocked syscall, how about using SIGUSR1 or SIGUSR2 and have the signal handler that just returns? <dokma>Now I can access the server socket from the repl: <dokma>$1 = #<input-output: socket 10> <dokma>BUT!! If I run close-port on this socket the server remains up. <dokma>scheme@(guile-user)> (close-port ss) <dokma>Can anyone reproduce this? It takes 1 minute. <dokma>It is different to calling stop-server-and-clients! though where after calling stop-server-and-clients! I can connect normally back in. <dokma>If I manually call (close-port ss) I cannot connect back in but the server is still running and does not terminate. <dokma>sneek: defining new procedures works fine. I can now call ks-shutdown. <dokma>My lingering problem is that I cannot get run-server to terminate normally. <str1ngs>dokma: the server stays up? or the socket file stays? <dokma>dsmith: using SIGUSR1 or 2 might work. The issue I have is that the repl module advertises a function that shuts the server down: stop-server-and-clients! but it doesn't do what it promises to do. <dokma>I cannot connect back in if I (close-port ss) <dokma>If I (stop-server-and-clients!) nothing changes and I can connect back in and use the repl as if though I haven't called (stop-server-and-clients!) <dokma>str1ngs: could you take a few seconds to verify this if you're on Linux? <str1ngs>wait you are not using a socket it's tcip server <str1ngs>I suspect close the port is probably not intended in this case. Would not (stop-server-and-clients!) do that? <flatwhatson>hmm, there's a comment ;; 'shutdown-server' is called by 'stop-server-and-clients!' <dokma>(stop-server-and-clients!) does nothing on my side <flatwhatson>it closes any open client connections for me, but doesn't cause (run-server) to return <str1ngs>I use coop with a socket file. so things might be slightly different there. <dokma>If I have multiple clients they will all disconnect <dokma>But I can normally connect right back in. <dokma>scheme@(guile-user)> (port-closed? ss) <str1ngs>for multiple clients I would use coop :) <dokma>I don't know anything about coop. Started with guile and scheme in general a few weeks back. <str1ngs>but you will have to manually poll so probably need you own thread anyways. <str1ngs>there is a coop repl server intended for multiple connections. <dokma>The provided TCP server is just what I need. <str1ngs>you can use TCP with the coop server <str1ngs>the coop server is a repl server intended for multiple connections <str1ngs>after you spawn the coop server you'll want a thread that sleeps periodically and calls poll-coop-repl-server <str1ngs>that's when it will process repl calls <str1ngs>sorry I don't have a better working example, but should give you and idea <dokma>str1ngs: give me a few minutes to grok all that <dokma>I've just tested guile --listen=51281 <dokma>and it behaves exactly the same as my embedded repl <dokma>(stop-server-and-clients!) just disconnects all clients but the repl still runs. <str1ngs>but as it says Please note that in the current implementation, the REPL threads are cancelled without unwinding their stacks. If any of them are holding mutexes or are within a critical section, the results are unspecified. <str1ngs>I suspect you'll want to use coop anyways. the standard REPL does not scale with many clients. <dokma>What does this do? (display #\! shutdown-write-pipe) <str1ngs>I did not test with with any clients. and the port defaults to 37146 <vijaymarupudi>daviid: Yep, I'm aware, I was using Gio.ListStore as an implementation for Gio.ListModel. Just need to use those ListModel methods on the ListStore. <dsmith>dokma: #\{something} is a char literal <avp>Guilers, when I use SRFI-9 records, Guile compiler prints warnings like this: "warning: possibly unused local top-level variable `%tunnel?-procedure'". I looked into 'srfi-9.scm' and found those '<something>-procedure' variables are created by 'define-record-type' macro. Is there an "official" way to deal with that? <leoprikler><something>-procedure should be used by <something> <leoprikler>so unless you use <something> in your code or export it, that warning will be printed <leoprikler>In Guix there is the opposite problem: <something>-procedure is sometimes bound twice <str1ngs>IIRC the draw back to using #:metaclass <redefinable-class> is performance. I have an unavoidable situation where another module makes a class and I need to change-class so I can extend it. It's not ideal but I can't figure out another way. This is in regards to guile 3 for context. <muradm>is there a library with bindings to inotify? <muradm>i want to wait for inotify events on file changes <iskarian>Hello #guile :) How would I go about copying a record and changing just one or two fields without having to match and type them all out? <leoprikler>iskarian: (srfi srfi-9 gnu) provides such extensions, albeit for functional records <iskarian>leoprikler, thanks :) though I just figured out that I can use inherit since I'm using guix records defined with define-record-type* <str1ngs>leoprikler still not as good as goops but I hear what you are saying :) <iskarian>I feel like goops would be a rabbit hole. Sometimes simpler is better <leoprikler>9 times out of 10 i prefer records being records <daviid>muradm: ^^ lists 2 libs that bind inotify ... <daviid>str1ngs: nice to hear from you, I hope your are fine! <muradm>daviid: cool, may be sneek could also filter that list? :D <daviid>str1ngs: i'lltry to reproduceusing foo bar modules <daviid>muradm: not the sneek author ... <daviid>str1ngs: but if you beat me,ihave twomajorissuesto fix beforei'll get to yours ... <daviid>[still have a spacebar keyboard problem ... sorry for 'joint words' ...] <str1ngs>daviid: I am well, thanks for asking. been a year though. hope you have been well too. It's not a rush I can get around the multiple binds mean time. <str1ngs>daviid: also I was thinking of updating g-golf in guix. the current g-golf would default to guile 3.0 and then added a g-golf-2.2 for guile 2.0 where needed. seems to be the guix way of doing thigns. WDYT? <str1ngs>iskarian: it's not really a rabbit hole IMHO. it handles inheritance and copying quite nicely. if those things are important to you. <iskarian>(disclaimer: no personal experience with goops specifically) When it's useful, it's very useful. In practice (IMO) it gives developers incentive to make things more complicated than necessary, especially if you end up mixing functional and imperative styles because of it. In the end it's the age-old debate <muradm>how do i call ioctl from guile? is there something in standard lib about it? searching manual has no ioctl presence