<rlb>ok, so this is repeatable on s390x: <rlb> Running suspendable-ports.test <rlb> UNRESOLVED: suspendable-ports.test: non-revealed port is closed <rlb> ERROR: suspendable-ports.test: revealed port fdes not closed - arguments: ((system-error "seek" "~A" ("Bad file descriptor") (9))) <rlb>Any ideas? If not, I'll delve if I get time. <rlb>but I can test without if we think that might matter. <RhodiumToad>since it's clearly closing some file descriptor at the wrong time <rlb>You mean strace -f ...? If so, should also be easy to provide. <rlb>Also, it doesn't happen *every* time, just often. <rlb>Hmm, I'll need to look at the test more carefully, but it looks like the error complaining about the fseek is expected because it gets a EBADFD for a seek right after a close(that_fd) <rlb>Might not have anything to do with the arch, specifically, of course. <rlb>Not sure - don't know which test (what it's doing yet), but yeah, might be some issue with gc or something too I suppose. <rlb>All this is also in the context of a big migration in debian wrt libgc. <rlb>(newer libgc, which might or might not be relevant) <RhodiumToad>if it's incorrectly concluding that something isn't reachable, it might be closing the fd too soon <rlb>right, or the test isn't guarding the thing sufficiently, or... <rlb>though I guess without weak refs, if it has a ref, then shouldn't be closed that way. <rlb>I'll perhaps also try without the jit, just to see if that makes a difference, since it's easy. <daviid>str1ngs: nice catch, I fixed but i can't push because i have a series of pending push related to my work on GInterfaces ... but in the mean you can make the folling 'local change' <rlb>RhodiumToad: same errors with --enable-jit=no, fwiw. <daviid>str1ngs: here (g-golf hl-api closure) (I made the paste valid for one day, if it expires beofre you could grab it let me know ... <johnjay>daviid: i've never seen the !# syntax before. <str1ngs>daviid: thanks will try this out now. <daviid>str1ngs: ok. one unrelated thing, in you scripts, you must import )oop goops) before to call (default-duplicate-binding-handler <daviid> '(merge-generics replace warn-override-core warn last)), otherwise, the merge-generics is not known by gule, and silently ignored <daviid>str1ngs: another tiny thing, maybe you know already, but you do not need to import "Gtk" "Container", since it is in the class precedence list of other things you import ... <daviid>johnjay: fwiw, 6.18.1.3 Block Comments <str1ngs>daviid: I was fiddling with gi-import because remove was showing srfi1 in geiser for some reason. so GtkContainer got orphaned there. <daviid>str1ngs: ok, i assumed you did know already, but just wanted to make sure :) <johnjay>daviid: ah ok it's a guile only thing <daviid>johnjay: i asume it is, in CL, we uswed #|| ... ||# <str1ngs>daviid: no problem this is just an test case anyways. I should probably start a new geiser now and again. I tend to evaluate to much that way. :( <daviid>johnjay: but i don1t know about other schemes <str1ngs>daviid: I'm not sure why that new snippet doesn't work either. should we wait for this? it's not a huge rush. <daviid>str1ngs: make sure you quit any other sessino that ru that example <daviid>str1ngs: you did patch (g-golf hl-api closure) right? <str1ngs>daviid: yes I did it a couple of times. and uninstalled g-golf an just use ./pre-inst-env. are you sure that's the right snippet? <daviid>str1ngs: yes, can you run git diff and paste? <daviid>or i can paste you may compare, here <str1ngs>well diff won't help because tabs get mangled which I can next get just right. can you paste a patch would be easier <str1ngs>thank patch is easier. or if I can get your tab/space settings right. which I can never do <daviid>str1ngs: i should check my .emacs setting, there should be no tab ... i think i did solve that a while ago but ... <daviid>str1ngs: i think it's mine because gnome paste does indent my code wrong sometimes ... which is the symptom of tab instead of spaces .. <daviid>but anyway, that patch fixes the bug, so let me know <str1ngs>there is no ancestor for that patch lol. either way the change is trivial it should be if (or #f (null-pointer? value) not ( if (null-pointer? value) correct? <daviid>you can see thatr in the 'original' paste i posted earlier today <str1ngs>right, still not working. if its fixed for you that's fine we can revisit this later since I'm missing ancestry due to your interface work probably. and this is not a big rush <daviid>str1ngs: definitely working here, is there a bug in my ./pre-inst-env maybe? <str1ngs>I don't there would be one in ./pre-inst-env . it's using the in tree g-golf fine <str1ngs>./pre-inst-env nomad even works flawlessly with no g-golf installed <daviid>str1ngs: that it doen't work after you patch scares me :) <str1ngs>I hear ya, I'm confident if it's fixed on your end with history probably will be fixed for me. so lets not rush it. <str1ngs>I'm using it for something highly experimental won't probably see sight of day lol <daviid>str1ngs: is this using guix? maybe you can try your ubuntu, and do a full patch, make, make check, make install <daviid>str1ngs: but it is a good catch, there will be other 'similar' situations ... <str1ngs>daviid: no I use ~/local . only time I use guix is for testing an making packages <str1ngs>the g-golf hash I used is pinned to the guix declaration <str1ngs>daviid: does clicking click me work? <daviid>str1ngs: yes, see the 3 screenshots, scroll ... <daviid>str1ngs: but the bug made it so it would not even display the first screen anyway ..., so that is the fix, when there is no parent <str1ngs>ah missed that sorry.. nice. also in my example I'm not sure if I need g-object-ref . since you have to explicitly use destroy anyways? <str1ngs>right that's why I make sure the button was added after the signal. to show lack of parent would cause the bug. <daviid>i didn't look deeply, but ig remove (the gtk method) lower the object ref, then yes, you'd need to do that <str1ngs>probably if you remove that the button will go away? <daviid>str1ngs: i ust say it is a veru weird example :), but i wanted to fix the g-golf bug, and i think is is fixed <daviid>or locally test, it is a rare situation where i have other pending pushes that needs furthjer work ... shoulkd be there very soon now, but not today :) <daviid>the bug, lines 26, 28 and then 31, the report, is as if you did not patch c and g-closure-marshal-g-value-ref <daviid>so your pre-inst-env is playing games with you <daviid>you should make, make check, make install and not use pre-inst-env ... and see <str1ngs>I just added a dimfi to make sure it was working. <daviid>str1ngs: yes, but that is not the proc that is called <daviid>something is wrong with you pre-inst-env, or mine (g-golf) <daviid>you did see the screenshots, i can't possibly make those 'manually' :):) <str1ngs>I'm not doubting it's fixed on your end. So I'm okay with that. we can revisit this when my history catches up with yours? WDYT? <daviid>str1ngs: ok, but are you not interested to understand why it does fix it here and not on your side? i couldn't even sleep :):), but as you wish, let me just paste the exmaple (that i updated for 'cosmetic' taste, so to speak, but what if it did 'fix something else' ...) <str1ngs>daviid: it's not that I'm not interested. it just that you have a different git history so later when I'm on par we can follow up. I'm assuming it's fixed as you have noted. <daviid>str1ngs: nothing here influences that fix <str1ngs>oh you don't have the 'parent-set signal? <str1ngs>I could have made this example simpler sorry. but later I need to actually test that the signal works when changing the button's parent. <daviid>ok, let me see what's wrong still <daviid>i hope g-golf will have nice images like guile ... :):) <str1ngs>I know that that guile image is great. <str1ngs>daviid: maybe g-golf can have a gopher mascot. often you can find a gopher on a golf course :P <daviid>maybe, the manual drawing, sort of scifi characters of the guile's web site are cute <str1ngs>yes, the artist did a very good job. <str1ngs>daviid (or (not value) (null-pointer? value)) is working <daviid>str1ngs: perfect, sorry for the previous bad patch <str1ngs>thank for the fix. I'll play around with this now <daviid>str1ngs: welcome, that was a very good catch, i am glad we fixed it <str1ngs>parent-set is kinda useful for nomad. though not sure how many people use that. <daviid>str1ngs: actually from my perspective, it is not so much the parent-set, but the fact that a signal that expect an instance as one of its argument can sometimes receive NULL - that was the catch <str1ngs>aye, does GI indicate that somehow in terms for a language binding? <str1ngs>sometimes it's odd because using GTK from C I don't have to worry about some subtitles. <daviid>although i did use parent-set in the past, but not in this context, rather, when you create an instance from a glade (xml) file, it is unparented, and you need to parent it ... <daviid>yes and no, to the last quiz, this really was a bug in g-golf anyway <str1ngs>understandable. often times NULL is in GTK functions or methods but I can't think of any other instance where NULL could pass to a signal closure other then maybe user-data. though in this case it makes sense that the parent could be NULL of course. <str1ngs>daviid: (setq-default indent-tabs-mode nil) seemed to <daviid>i have this: (set-default 'indent-tabs-mode nil) <daviid>so is it a bug and should be (setq-default 'indent-tabs-mode nil)? <str1ngs>this the effect is the same. it never uses tabs though #:duplicates still have tabs. which you can see with white-space-mode <str1ngs>it's not a huge deal, as long as I can replicate your settings to some degree. I can handle diffs better. ***apteryx_ is now known as apteryx
***slyfox_ is now known as slyfox
<leoprikler>Is there a way of inserting expressions between expressions with a syntax-rule/syntax-case? <leoprikler>I want to do something like (trace (foo) (bar)) → (begin (display "(foo)" (foo) ...) <leoprikler>well, tracing is just an intermediary step in something larger <leoprikler>after that, I want to be able to "step" through the code one-by-one (using prompts) <leoprikler>so I'd insert abort-to-prompt in-between the expressions <RhodiumToad>(define-syntax-rule (trace-int exp) (let ((v exp)) (format #t "~A ~A" (quote exp) v) (newline) v)) <RhodiumToad>(define-syntax-rule (trace exp ...) (begin (trace-int exp) ...)) <RhodiumToad>(define-syntax trace (syntax-rules () ((_ exp) (let ((v exp)) (format #t "~S ~S" (quote exp) v) (newline) v)) ((_ exp0 exp1 ...) (begin (trace exp0) (trace exp1) ...)))) <RhodiumToad>to insert an abort-to-prompt you'd do something like ((_ exp) (begin (abort-to-prompt whatever) exp)) as the single-arg case <RhodiumToad>yes, that would expand to (begin (begin a b) (begin a c) ...) but that doesn't matter <RhodiumToad>and the multi-arg case can be ((_ exp0 exp1 ...) (begin exp0 (trace exp1) ...) if you don't want to insert an abort-to-prompt before the first one <leoprikler>I'll have lot's of (begin)s in the code being stepped through anyway <RhodiumToad>the tree-il for (begin a b c d) and (begin (begin a b) (begin c d)) is the same anyway <leoprikler>hmm, that works for the trace, but I think I'm having some troubles with the prompt <leoprikler>The prompt-tag is not exported from the module however <leoprikler>which is a bit weird, because the tree-il seems to correctly use @@ to load everything from the correct module <RhodiumToad>I'm wondering whether you really need shift/reset instead, because those re-establish the prompt when calling the continuation, whereas call-with-prompt does not <leoprikler>So if I say (define prompt-tag (make-prompt-tag 'tag)) <leoprikler>and then (call-with-prompt-tag prompt-tag ...) twice, what happens? <RhodiumToad>call-with-prompt puts the tag into the dynamic context when executing the thunk. abort-to-prompt aborts to the nearest outer context that has that tag. <RhodiumToad>you can reuse one tag as many times as you like, nested or not <leoprikler>i.e. i can not do (call-with-prompt-tag ...) (abort-to-prompt) <RhodiumToad>you can only abort to a prompt while inside the thunk invoked by call-with-prompt <RhodiumToad>i.e. (call-with-prompt prompt-tag (lambda () ...stuff... (abort-to-prompt prompt-tag ...) ...stuff...) (lambda (k . args) ...stuff...)) <RhodiumToad>the subtlety is that if you invoke (k), the prompt is not automatically re-established, so if the thunk contains more than one abort in sequence, you need to re-establish the prompt each time <leoprikler>ahh, but in (lambda (k . args) ... stuff ...) there should already be a call-with-prompt-tag <leoprikler>[hence my earlier comment about calling it twice] <leoprikler>(lambda (k . args) (call-with-prompt-tag (lambda () ... more stuff ...)) <RhodiumToad>call-with-prompt has a first argument which is the tag <leoprikler>oops, that's my fault, I meant (call-with-prompt prompt-tag ...) whenever I wrote call-with-prompt-tag <RhodiumToad>(letrec ((handler (lambda (k v) (format #t "cont ~A\n" v) (% mytag (k) handler)))) (% mytag (begin (format #t "point 1\n") (abort-to-prompt mytag 1) (format #t "point 2\n") (abort-to-prompt mytag 2) 3) handler)) <str1ngs>sneek later tell daviid, Hello I found another bug in g-golf see this example https://paste.gnome.org/pw0t0lrhr. Essentially (append-page (make <gtk-notebook>) (make <gtk-label> #:label) #f) should work. but the method to handle #f does not exist. <rlb>civodul: I might have found the 390x test issue (and if so it's not arch specific). In ports.test in the "non-revealed port is closed", if the port isn't gc'ed, we just close-fdes the file descriptor and mark it unresolved. The problem is that the port still has a reference to that fd, whcih the next test then starts using, and when the next test calls (gc), the port from the *previous* test closes the fd, breaking that next test. <rlb>At least that's my theory. See if I can find some way to disable that lingering object's close of the fd it should no longer "own", even via a hack, to see if that makes the failures go away. <rlb>I suspect for the "non-revealed port is closed" test we need something like (port-forget-fd ...) to call after we call close-fds in the catch handler... <rlb>But in the end that test is perhaps just trying to do something a bit shady... <rlb>Also noticed that we may not be checking overflow in places wrt the port revealed counts. <rlb>i.e. it's a C int and we may have some unchecked "revealed += adjustment" code, etc. <rlb>OK, I think I might have a plausible hack/fix. I'll send a patch later. <rlb>I take it back. I don't see a way yet to avoid the possibility that that test will just break subsequent tests if/when its port isn't gc'ed during the test, and then is later, randomly closing the fd that another test is trying to use. <rlb>I think for now I'll just comment out that test for Debian, and I'll file a bug suggesting we might want to do the same in guile proper unless we can come up with some way to really force the gc, or alternately, maybe a way to sneak around behind the gc's back. <manumanumanu>leoprikler: if you want to know how much fun you can have with syntax-rules you should go read the source of taylor campbell's foof-loop implementation. <leoprikler>In my case it was really just an issue about not trying to be smart with syntax-case and just sticking to syntax-rules with helpers <leoprikler>Although I still kinda wish I could rewrite this as a syntax-case <manumanumanu>leoprikler: you could implement something akin to implicit renaming using syntax-case if you miss the more CL-styled loops <leoprikler>I prefer myself some map/for-each, even (let loop (())) <manumanumanu>leoprikler: I had a brain fart, sorry. loops became macros in my brain. foof loop is actually quite schemey. Not magic and mutating like loop or iter. You can treat it as syntactic sugar over a named let, just using the homogenous looping over various collections. <leoprikler>I get (part of?) that from the documentation, but I'm still not vibing the syntax, is all. <leoprikler>the initial example was "count-matching-items" and that to me is (length (filter pred list)) <leoprikler>which is shorter than any of the presented alternatives ;) <leoprikler>even if I used for-each so as to not construct a new list, I'd only need one lambda in there plus the correct for-each for the datatype <manumanumanu>(fold (lambda (elt acc) (if (pred? elt) (+ acc 1) acc)) lst). Which in guile would _still_ be slower than a named let since I don't think it does any inlining of the fold to be able to remove the function call. <manumanumanu>(loop ((for elt (in-list lst)) (for c (summing 1 (if (pred? elt))))) => c). Still longer, but not nearly as bad. I am racketifying it to provide subloops and loop/sum-styled loops, which means you could potentially write (loop/sum ((for elt (in-list lst)) (when (pred? elt)) 1) <manumanumanu>i leave it as an exercise to the reader to figure out why <civodul>stis: this is roughly the run-time support library of python-on-guile, right? <stis>yes, I have a macro layer in scheme so I figure it would be nice to have it in a repo of it's own as python-on-guile is heavy <stis>it's also heavy on goops <leoprikler>manumanumanu: (let ((count 0)) (for-each (lambda (elt) (when (pred elt) (set! count (1+ count)))))) <stis>(let lp ((l l) (c 0)) (if (pair? l) (lp (cdr l) (+ c (if (f (car l)) 1 0)) <stis>(let lp ((l l) (c 0)) (if (pair? l) (lp (cdr l) (+ c (if (f (car l)) 1 0)) c) <stis>(for ((x : l)) ((c 0)) (+ c (if (f x) 1 0)) #:final c) <leoprikler>can be made into (+ c (f x)) if x is supposed to return C-style booleans ;) <stis>yes, assuming intify we can use (for ((x : l)) ((c 0)) (+ c (intify (f x))) #:final c) <stis>yes, assuming intify we can use (for ((x : l)) ((c 0)) (+ c (int (f x))) #:final c) <stis>assuming f retruns only bool values <dsmith>Can you define "1/0" ? That's syntactially (lexically?) a rational, though not a valid one. 