IRC channel logs

2020-02-21.log

back to list of logs

<daviid>heya guilers
<sneek>daviid, you have 4 messages.
<sneek>daviid, str1ngs says: great news and excellent timing. I will look at this ASAP.
<sneek>daviid, str1ngs says: looks good so far. just to clarify #:flags '(handles-open can-override-app-id) is known to not work right? also for the language binding does it make more sense to have drop argc? seems redundant for people to use and might be a source of gotcha for non C programmers. just a thought. also passing the wrong value to argc can cause a seg faults. WDTY? for now this signature is okay if it means to much work.
<sneek>daviid, str1ngs says: what I'm proposing is something like this. (g-application-run (command-line)) the length is implied.
<sneek>daviid, str1ngs says: (g-application-run app (command-line)) ** to be more precise.
<daviid>str1ngs: let's talk about the <gtk-application> flags as a separate matter, we need to fix this, but I want to make sure tha g-application argc and argv work fine: I mean by that I would like you to confirm that when you pass these args with sensible values for your usage, it does use those, and you cn 'prove it', so to speak, is the case?
<daviid>str1ngs: wrt g-application arg list, this is something users can do, if/whn they wish, for example, you could well provide nomad with a nomad-run procedure that does what you suggested ... g-golf however will nevr do that, the reson being things must be 100% automatic, and based, stricktly, on the GI typelib(s) it imports
<daviid>so for g-golf, gtk-init, clutter-init ... have 2 args, g-application-run has 3 args ... and g-golf does not make 'jugements' about that, of course not ... this being said, there are two know well justified (and documented) exceptions
<daviid>(1) 'out args must _not_ be provided, g-golf allocates mem and return those ... and (b) the boolean values, upon user request only, can be stripped from the results, when the boolean merely tells the user if the procedure call succeeded (this is describe in g-golf's manual)
<daviid>*reason
<daviid>*judgments
<daviid>g-golf provide users with the scheme representation of the objects, properties, functions, methods ... as an exact scheme representation of what is in the GI typelib, except for the two above lested exceptions
<daviid>wrt why <gtk-applicaion> flags do not 'behave' the way you say it should - there is no bug though, which makes things a bit more complicated to 'debug' - i have no idea, but i want you to connect (even tmporarily) to this signal the warning claims it's missing, and try the app, see if everything then behave as expected ... if every signal closure is called, iow, if the app runs fine then ...
<daviid>if yu do that, with the shortest posssible app/scrpt, then i can ask to the #introspection folks why it stop working if we comment the 'missing' connect ...
<daviid>I still need to wotk on the 'inout and double check the 'out arguments 'preparation (which preceeds the call to invoke ...)
<str1ngs>daviid: in terms of passing argc to gtk-init etc. I understand your reasoning in terms of automatic one to one bindings. I'm passing on that for none C programmers this could be a real gotcha. And also give the wrong input it will it will segfault.
<str1ngs>daviid: as for the open signal handling this is not working as expected. connecting to command-line or handle-local-options just to by pass this does not help fix the problem. Given the example I gave you. the flags #:flags '(handles-open) should call the 'open signal when passed non flag arguments on the command line. if this does not work now that's fine. but I don't see the benefit of trying to get this to work with any of the other
<str1ngs>signals. Since I've have never had to use those before.
<daviid>str1ngs: i am sorry you are not willing to help, but without a workning snipsett, i can' tven check that the flags are being set properly ...
<str1ngs>I have provide two examples one in C and the other in scheme, I'm not sure how much more helpful I can be.
<daviid>str1ngs: you gona reapeat this ... the scheme example does not even launch, so i cant even track the flags ...
<str1ngs>when setting the 'handles-open flags previously I've only had to use 'open and 'activate as it's documented. 'command-line and 'handle-local-options could by pass the error but they do different things
<str1ngs>we are only repeating this because you are insisting the use of command-line which actually makes the example more complicated.
<daviid>str1ngs: i've added a 'command-line signal, just to be able to track the flags
<daviid>and it seems at least ther are being set properly
<daviid>but then raised another exception, do i have to pass an argumnt to launch it?
<daviid>here the example i run - http://paste.debian.net/1131335/
<str1ngs> the signature for the lambda should be (lambda (app command-line))
<daviid>str1ngs: . args will do
<str1ngs>I'm not sure how . args works sorry
<str1ngs>also I would provide #:application-id "org.gnu.example.open"
<daviid>i just wanted to double check that the app flags are being set correctly by g-golf, which seems thecase
<str1ngs>you need a dbus ID since it uses dbus to communicate with the primary application
<daviid>str1ngs: i know nothing and don't really want to know, which is why i wanted you to provide an exmple ...
<str1ngs>what does . args do? or can you point to the documentation so I can better understand that
<daviid>please patch the above and paste, tell me with what args i should launch the app and let's try to figure out why ....
<str1ngs> http://paste.debian.net/1131337 this example works but really not that useful
<daviid>str1ngs: . args, args is bound to what ever arguments the singllsend ... i didn't know how may, what they are ... at this point i didn't care ...
<str1ngs>ah like so a variadic argument? I guees
<daviid>str1ngs: all ths is just temporary, we need to 'do something' to track ... hence, i don't care about the command-line signal args, i don't know, don't want to know ... then you can use (lambda (. args) 'nothing) ... just a temporary trick
<str1ngs>daviid: I think to test with local-options or command-line I need to provide an options group
<str1ngs>actually --help should work mabye
<daviid>str1ngs: i didnt wna test 'command-line, i wanted to check the flags, that's done
<daviid>there are correct
<daviid>do we agree? then why would they not trigger the same expected behavior in scheme then in C .. that is the mistery, but they are set, i think
<daviid>the last example you pasted works, but it doesn use the same flags ...
<daviid>do you pass an arg on the cmmand-line?
<str1ngs>well you need a primary instance so do ./foo.scm & disown
<str1ngs>then test with ./foo.scm file
<daviid>what file
<str1ngs>but local-options and command-line deals with arguments but I always just use 'open since it handles files and I can just make an option group for the reaset
<str1ngs>file can be anything it just treats it as a "file to open"
<str1ngs>which should then be opened on by the primary instance using the 'open signal
<str1ngs>handle-local-options can theoretically open files too. but it has many edge cases.
<str1ngs>see https://developer.gnome.org/gio/stable/GApplication.html#GApplication-handle-local-options
<daviid>let's try to figure, now that we agree the flags are being set properly, do we? why the 'open does sem to be 'sufficient' in scheme, while it is in C
<str1ngs> https://developer.gnome.org/gio/stable/GApplication.html#g-application-open says the application must be registerd first
<daviid>str1ngs: i don't know gio - that much
<daviid>gnome became unusable
<daviid>gtk2 is a billion better then all this :):)
<daviid>what a mess
<daviid>so, back to our example, the ./open.scm
<daviid>let's focus, it is supposed to work just like this?
<daviid>i mean commentig the 'command-line signal
<daviid>this one - http://paste.debian.net/1131341/
<str1ngs>daviid: you only need on open signal but yes that looks right
<str1ngs>also maybe comment out can-override-app-id for now because it caused it's own issues
<str1ngs>daviid: s/on/one
<daviid> http://paste.debian.net/1131342/
<str1ngs>also you need a application property for application-id like this #:application-id "org.gnu.example.open"
<daviid>and i only have to launch it once? with ot without command-line argument(s)?
<str1ngs>the way this should work is. the first call with ./open.scm & disown will call 'activate. once it is running if you do ./open.scm ./test-file . it will call 'open but on the primary instance
<str1ngs>it's like emacsclient works to open files
<str1ngs>like how*
<daviid>i don't laubch gimp twice ... this is chineeese for me ... but ok
<str1ngs>well this avoids launching gimp twice. it just tell the main program to open the file and exits
<str1ngs>it's basically a RPC call over DBUS
<str1ngs>some times is handle purely by dbus with a service file. you just don't notice this if use double click and not a shell.
<daviid>str1ngs: i wish to have an exmple i only launch once
<daviid>so i can post on #introspection
<str1ngs> well that would require a threads
<str1ngs>give them this example it's pretty text book. they should understand how the primary and local application works
<str1ngs>this is atypical gtk program as far as I'm concerned
<spk121>.
<daviid>spk121: do you have a scheme code i can snarf for gi-gflags->integer
<daviid>or look at, i found there is a bug in mie :):)
<spk121>daviid: the way we handle flags is slightly complicated. A flag is a goops class that has a symbol slot and a number slot, created during introspection. To convert flag to integer, we just look at the integer slot of the goops instance
<daviid>spk121: in g-golf, flags are instances, the code to convert a list of flags to an integer is here (I snarfed it from sbank iirc - not to justify myself, just fwiw), just 4 lies of code - http://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/support/flag.scm?h=devel line 69 ...
<daviid>spk121: g-application-flags are like this: http://paste.debian.net/1131347/
<daviid>when i call (gi-gflags->integer $3 '(handles-open)) -| 8, but i should get 4
<daviid>or any bitwise pro here can help of course
<daviid>here is the list of flags
<daviid>(flags-none is-service is-launcher handles-open handles-command-line send-environment non-unique can-override-app-id allow-replacement replace)
<daviid>here the list of one flag, to test: '(handles-open)
<daviid>here is the list of booleans i obtain: $7 = (#f #f #f #t #f #f #f #f #f #f)
<daviid>then (list->integer (reverse ...)) gives me 8 - what am i doing wrong here?
<RhodiumToad>list->integer isn't the right thing there?
<RhodiumToad>flags-none is 0, not 1
<daviid>the gnome team tells me it should be 4
<RhodiumToad>no I mean it's not the right thing to use
<RhodiumToad>the presence of flags-none is pushing everything left by one bit
<daviid>hum
<RhodiumToad>it's easier to understand the problem if you think about the case when there's actually only one flag
<RhodiumToad>shouldn't you get the value from the enum-set slot rather than assuming that they are contiguous bits?
<daviid>RhodiumToad: i don't have a clear picture yet, because it did work fine so far, whch mans that allother flags i somewhat 'played' with, clutter, gtk ... including in the tst-suite, prob didnt have a zero entry
<RhodiumToad>(so think about the case where there's actually only one flag but it has the value 8, not 1, because other flags were deprecated)
<daviid>RhodiumToad: this the most hidden bug i faced in years, because (gi-integer->gflags $3 (gi-gflags->integer $3 '(handles-open))) -| $11 = (handles-open) _but_ it passes the integer to the gnome app, as 8, and the gnome app expect 4 ... it took me days to find out this
<RhodiumToad>that suggests you've made a compensating bug in the conversion from integer back to flag
<daviid>RhodiumToad: both algo are just a few ies, here - http://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/support/flag.scm?h=devel line 69 ...
<RhodiumToad>sec, just cloning your repo for convenient access
<RhodiumToad>devel branch, yes?
<daviid>RhodiumToad: oh, ok :)
<daviid>yes, the devel branch
<RhodiumToad>ok, well both functions are clearly making the same fundamental mistake
<RhodiumToad>they are assuming that the symbols list represent bits starting from bit 0 and increasing contiguously, with no symbol for 0 (i.e. no bits set at all) and no gaps
<RhodiumToad>this assumption is not sane
<sneek>I'll keep that in mind.
<daviid>RhodiumToad: can you suggest a patch?
<RhodiumToad>(what'd I say that triggered the bot?)
<daviid>RhodiumToad: yes:):) our bot is listening to everything we say haha
<str1ngs>RhodiumToad: I know that was kinda random of him lol
<str1ngs>sneek: settle down please :)
<RhodiumToad>blah, test
<RhodiumToad>heh
<str1ngs>this is a word sneek
<str1ngs>this assumption is not sane
<sneek>Okay.
<RhodiumToad>daviid: so let me test my understanding, a gi-flag is just a gi-enum where the enum values are intended to be OR'd into an integer?
<str1ngs>hmm this assumption seems to trigger something
<daviid>RhodiumToad: the enum vlues are given by the GI descrition of the flags 'instance'
<RhodiumToad>so given a list of symbols you should be converting them to an integer by ORing the values, and converting an integer to a list by testing each bit
<daviid>hum, i need to double check what i just said, but i am almost certain the values are given at import time
<RhodiumToad>this assumption maybe is relevant to the bot
<RhodiumToad>this assumption is strange
<RhodiumToad>this bot is not sane
<sneek>I'll keep that in mind.
<RhodiumToad>hah
<str1ngs>lol
<daviid>RhodiumToad: not sure what the algo should be exactly :(, i thought i got it right :)
<daviid>i think it should be based on the values we receive from GI introspection
<daviid>RhodiumToad: asking on #introspection, it seems most flags descriptions star with a flag that is zero 'associated', but not _always_
<RhodiumToad>right, basing it on the enum values is exactly what I said you should do
<RhodiumToad>I'm thinking something along the lines of (apply logior (map (lambda (f) (assq-ref enum-set f)) flags))
<RhodiumToad>(semi-pseudocode, you probably want to do something more meaningful if an unknown flag was supplied)
<daviid>RhodiumToad: thanks, what do you mean ukown flag?
<RhodiumToad>(gi-gflags->integer $3 '(i-am-not-a-valid-flag))
<daviid>ah ok
<daviid>what would be the gi-integer->gflags semi-pseudo code, if i may abuse your help
<RhodiumToad>er
<RhodiumToad>sec
<RhodiumToad>something like (filter-map (lambda (a) (and logtest flags (cdr a)) (car a))) enum-set)
<RhodiumToad>er
<RhodiumToad>something like (filter-map (lambda (a) (and (logtest flags (cdr a)) (car a))) enum-set)
<RhodiumToad>filter-map from srfi-1 of course
<daviid>RhodiumToad: thanks a lot, the encoding is working already, but i need to raise an exception for those (gi-gflags->integer $3 '(i-am-not-a-valid-flag)) :))
<RhodiumToad>(or (assq-ref ...) (raise whatever)) :-)
<daviid>yes, tha's what i thought tx
<daviid>:)
<RhodiumToad>not sure what to do about the analogous case in gi-integer->gflags, i.e. if a bit is set in the integer value that has no flag
<RhodiumToad>the expression I gave above will simply ignore those
<daviid>RhodiumToad: yes, i think i will assume this can not happen, due to the way gnome works
<RhodiumToad>the simplest way to check would be to convert the result of that expression back to an integer and check it's equal to the input.
<daviid>could do that to, true, will keep the idea in mind
<RhodiumToad>hm
<daviid>but for now, i'll asume it can't happen - the integer that is in a gobject subclass instance must either be the default, or encoded using gi-gflags->integer ... then it would raise an exception after i add the or ...
<RhodiumToad>actually, that one could maybe do with a small tweak; it'll return an empty list if there's no flag set, but if a (foo . 0) entry exists in the enum-set it should probably return that instead
<RhodiumToad>that's a simple enough refinement
<RhodiumToad>(lambda (a) (and (if (zero? flags) (zero? (cdr a)) (logtest flags (cdr a))) (car a)))
<daviid>i'll try that
<daviid>in the above, you wrote flags, you meant to write n i guess
<RhodiumToad>or that could be done as
<RhodiumToad>er sorry, yes
<daviid>ok
<RhodiumToad>(lambda (a) (and (or (= n (cdr a)) (logtest n (cdr a))) (car a)))
<RhodiumToad>or even
<RhodiumToad>(lambda (a) (and (= (cdr a) (logand n (cdr a))) (car a)))
<daviid>ok, trying that
<daviid>hum, that doen't work as expected
<daviid>but i must admit i followed you 'blindçy' so to speak :)
<daviid>(gi-integer->gflags $3 (gi-gflags->integer $3 '(handles-open)))
<daviid>$16 = (flags-none handles-open)
<RhodiumToad>oh, oops
<RhodiumToad>yeah, that's not right
<RhodiumToad>back up to the (and (if (zero? flags) (zero? (cdr a)) (logtest flags (cdr a))) one
<daviid>ok
<RhodiumToad>the (and (or (= n (cdr a)) (logtest n (cdr a))) (car a)) one is OK too.
<daviid>yes, i actually picked that one :), it works fine now, many thanks
<daviid>i shall just rename, use match to avoid car cdr and push a patch in a few minutes
<RhodiumToad>match-lambda would work for that I guess
<RhodiumToad>(match-lambda ((k . v) (and (or (= n v) (logtest n v)) k)))
<daviid>right
<daviid>str1ngs: i just pushed a fix for this flag problem, and now when i run the './open.scm' example, the one i pasted on #introspection, it raises another execption ... but i beleive the flag problem is ok now
<daviid>RhodiumToad: many thanks, you may pull as well of course
<str1ngs>daviid great will test out. based on the log, this should fix the can-override-app-id as well. which exception?
<daviid>str1ngs: well i was thinking you could try to see if you have an idea ...
<str1ngs>just about to test it out
<daviid>WARNING: compilation of /usr/alto/projects/g-golf/examples/./open.scm failed: ;;; In procedure scm_i_foreign_call: Wrong type argument in position 1 (expecting POINTER_P): #f
<daviid>be right back
<str1ngs>daviid: right that's new
<RhodiumToad>speling: "Unkown flag: " should be "Unknown flag: "
<str1ngs>daviid is something's g-inst %null-pointer maybe
<str1ngs>daviid: something is returning #f that should not . I think you might need some exception handling instead of the continuation just being #f
<str1ngs>I would check to see what you changed and where it might have a continuation of #f instead of returning something usefule
<str1ngs>though with this effecting all flags could be something unrelated to this commit
<str1ngs>just doing (gi-import "Gio") will cause this
<str1ngs>GLib too
<daviid>right, a bit strange
<daviid>RhodiumToad: tx, will fix
<daviid>the tipo
<str1ngs>daviid: my guess is this gflags change had a side effect when importing now
<str1ngs>I guess gi-gflags->integer might be used during gi-import?
<daviid>probably yes, i need to find out, sorry about that!
<str1ngs>no worries this is not a huge rush for me. it's mainly a bug report
<RhodiumToad>one hidden assumption in the code I gave is that flag value enums never have more than 1 bit set
<RhodiumToad>if that's not true, then the code needs a small tweak
<RhodiumToad>(match-lambda ((k . v) (and (or (= n v) (= (logand n v) v)) k)))
<daviid>not sure i understand
<daviid>'... flag value enums never have more than 1 bit set ...'
<RhodiumToad>i.e. every enum label corresponds to exactly one bit
<daviid>RhodiumToad: some flags can have aliases
<wingo>moin
<RhodiumToad>two names for the same flag bit is ok, it's just a problem when one name sets multiple bits
<daviid>I need to rest :)
<daviid>RhodiumToad: no that won't happen, afaict
<RhodiumToad>eh. I'm no gnome expert but I'd be wary of it.
<RhodiumToad>the correction given above is probably worth using even if only as a defensive measure
<daviid>there is something else going on, i think, but i can reverse loclly to see
***apteryx_ is now known as apteryx
<RhodiumToad>er sorry, that correction is wrong
<RhodiumToad>still isn't properly handling the zero flag
<RhodiumToad>(match-lambda ((k . v) (and (if (zero? v) (zero? n) (= (logand n v) v)) k)))
<daviid>yes, i revert locally, the patch causes the problem, though the error seemed to pretend it was somewhere else ..
<daviid>*reverted
<daviid>RhodiumToad: ok let me try that
<daviid>that triggers te problem as well
<RhodiumToad>ok, so the problem is likely to be a bug elsewhere that was hidden by the bug in the flags handling.
<daviid>i agree
<daviid>though the backtrce says it is trying to call (g-base-info-get-name with #f) instad of a GIBaseInfo pointer ...
<daviid>which is far from a flag related bug :), oh well, need to rest
<daviid>i should have been sleeping 4h/5h ago already ...
<daviid>thanks all, bb tomorrow
<daviid>str1ngs: picj the master branch version of (g-golf support flsg) to be able to continue to work in the men time ...
<str1ngs>daviid: I'm using guix so switch hashes no problem I'm not affected
<str1ngs>daviid: have a good sleep ttyl
<RhodiumToad>I wonder if the bot is sane
<RhodiumToad>or maybe it is not sane
<RhodiumToad>this is sane
<RhodiumToad>this is not sane
<RhodiumToad>fascinating
<RhodiumToad>this bot is not sane
<sneek>So noted.
<RhodiumToad>this bot is strange
<RhodiumToad>this bot is not strange
<RhodiumToad>some bot is not sane
<sneek>So noted.
<RhodiumToad>some bot is possibly sane
<sneek>Understood.
<RhodiumToad>some assumption is possibly sane
<sneek>Understood.
<RhodiumToad>some word is possibly sane
<sneek>Okay.
<RhodiumToad>some word possibly sane
<RhodiumToad>aha, I bet it's the "is" that triggers it
<RhodiumToad>foo is bar
<RhodiumToad>foo is possibly bar
<RhodiumToad>foo is possibly sane
<sneek>I'll keep that in mind.
<RhodiumToad>foo may be possibly sane
<RhodiumToad>so it sees is ... sane?
<RhodiumToad>no, that's already ruled out
<RhodiumToad>foo is lacking sanity
<RhodiumToad>foo is bar sane
<sneek>I'll keep that in mind.
<RhodiumToad>foo is not sane
<sneek>Understood.
<RhodiumToad>this is not sane
<RhodiumToad>this x is not sane
<sneek>I'll keep that in mind.
<RhodiumToad>this x is sane
<RhodiumToad>this x is y sane
<sneek>I'll keep that in mind.
<RhodiumToad>this x are y sane
<sneek>I'll keep that in mind.
<RhodiumToad>this x foo y sane
<RhodiumToad>so the pattern is [this] X [is|are] Y sane ?
<str1ngs>seems that way
*RhodiumToad feels like he's playing 2-4-6 against the bot
<RhodiumToad>this x was y sane
<RhodiumToad>this x is p q r s sane
<sneek>So noted.
<RhodiumToad>this x is p q r s san
<RhodiumToad>this x is p q r s insane
<RhodiumToad>this x is p q r s inane
<RhodiumToad>this x is p q r s ane
<RhodiumToad>this x is p q r s sane
<sneek>So noted.
<RhodiumToad>perhaps this x is p q r s sane
<sneek>I'll keep that in mind.
<RhodiumToad>maybe perhaps this x is p q r s sane
<sneek>Okay.
<RhodiumToad>zz yy xx maybe perhaps this x is p q r s sane
<RhodiumToad>zz yy xx this x is p q r s sane
<sneek>So noted.
<RhodiumToad>zz yy xx ww this x is p q r s sane
<RhodiumToad>zz yy xx ww x is p q r s sane
<sneek>So noted.
<RhodiumToad>the "is" additionally needs to be within the first 6 words?
<civodul>heh, who knows :-)
<RhodiumToad>this was sparked by the bot randomly interjecting itself into a conversation earlier
<dsmith>The bot does some kind of sloppy matching on nicks. Words sane, some, since match the bots nick.
<dsmith>Never say "is" and the bots nick at the start or end of a line.
<dsmith>Notice how I'm using "the bot"..
<dsmith>sneek: forget zz yy xx ww x
<sneek>Okay.
<dsmith>sneek: forget zz yy xx ww this x
<sneek>Okay.
<dsmith>sneek forget something you did not know
<sneek>Consider it forgotten.
<dsmith>sane botsnack
<sneek>:)
<dsmith>some botsnack
<dsmith>since botanack
<dsmith>Hmm.
<dsmith>seen botsnack
<sneek>:)
<dsmith>That's it.
*RhodiumToad did not expect using "sane" at the end of a line to be a problem
<dsmith>Ya. Need to fix that.
<RhodiumToad>frankly that seems a bit too sloppy to me
<dsmith>Guile is fantastic, sneek
<sneek>Understood.
<dsmith>sneek: Guile?
<sneek>Its been said that Guile is an implementation of the Scheme language.
<dsmith>sneek: Guile?
<sneek>Guile is an implementation of the Scheme language.
<dsmith>sneek: Guile?
<sneek>I've heard Guile is fantastic, sneek
<dsmith>Ur?
<RhodiumToad>heh
<dsmith>sneek: forget Guile is fatastic, sneek
<sneek>Okay.
<wingo>i would love to spend another few weeks golfing guile performance :P
<wingo>ain't got the time currently tho
<chrislck>nly! thanks for the ongoing work on rastache-guile! mustache.github.io is lacking guile port!
<dsmith-work>Happy Friday, Guilers!!
<gagbo>Hello, I created a "listener thread" which (read-line port) in loop using (make-thread). How can I kill / stop the thread in Guile ? I tried using (cancel-thread) but it didn't work (i.e. the program didn't terminate here : https://github.com/gagbo/xile/blob/master/hello_xi.scm#L55-L57 )
<gagbo>I'm open on suggestions if I do things obviously wrong, I'm still in the early chapters of the Guile manual
<gagbo>s/on/to
<RhodiumToad>hm, that basic structure works for me
<RhodiumToad>looping on char-ready? is highly inefficient, though
<gagbo>hmmm, maybe that's a Guile 3 issue then ?
<gagbo>I should just loop #t you think ?
<RhodiumToad>no
<RhodiumToad>oh, you mean loop around the read-line?
<gagbo>At least I'm relieved that my code is working somewhere, I was starting to get frustrated with this cancel-thread thing
<gagbo>basically I want to loop around read-line yeah (it'll be a dispatch later)
<RhodiumToad>note I didn't try your actual code, just a simple skeleton using read-line
<gagbo>oh I see. Then maybe I'm still doing something weird within the jobs but the calls regarding threads are the ones I'm supposed to have
<RhodiumToad>hm, interesting
<RhodiumToad>if the thread is actually blocked in read-line, then cancel-thread isn't stopping it.
<gagbo>That's what I was afraid of. That's why I started tinkering with char-ready? to try to find a solution to peek into the port.
<gagbo>Or I need another solution to get asynchronously messages from an input-port
<RhodiumToad>ok. it _looks_ like setting the ports as nonblocking would suffice. but I'm not sure how you'd get that on a read-write port from popen
<RhodiumToad>since as far as I can see it's hiding the actual underlying ports in a closure
<gagbo>Setting the ports as non blocking how ?
<gagbo>(use-modules (ice-9 suspendable-ports)) (install-suspendable-ports!) ?
<gagbo>I'll try this tonight I guess
<RhodiumToad>there's an "arcane UNIX incantation" for it given in the docs, but it relies on knowing the port
<RhodiumToad>no, you probably don't need the whole suspendable-ports infrastructure
<RhodiumToad>however, loading the suspendable-ports module might have the required effect without needing to do anything else
<gagbo>Otherwise I'd have to dig into ports API to see how I can get port->fdes on the input-port part of my open-input-output-port (that I might get with (port->fdes (current-input-port)) in the job thread)
<gagbo>Well, it looks like the suspendable-ports code is necessary even with the incantation since I want the guile process to continue execution
<jcowan>wingo: URL for "interface stability is an artifact of culture"? Dr. Google not helpful.
<spd>Hi folks, is this a good place to ask for debugging help? I'm trying to get started with the low-level trap interface, and I have this short test script (https://gist.github.com/sdevlin/2d3e3b5350926c0fb78f4bff4f3a8899). I'm basically just trying to print the procedure and its arguments (similar to the interactive ,trace command) as a starting point. When I run this script under Guile 2.2.6, the behavior I see is that the arguments are
<spd>not always bound when the trap fires. It seems they are never available during the apply-handler and only sometimes available during the return-handler. Is this expected? Am I doing something wrong? Thanks!
<dsmith-work>spd: While this *is* a good place to ask, the chan is often slow, or the devs are not around.
<dsmith-work>spd: The mailing lists are often better. (they hang around longer and might be more visible)
<spd>dsmith-work: Thanks! I'll post my question to the list.
***emacsoma1 is now known as emacsomancer