<pkill9>why does lisp simultaneously make so little sense, yet make so much sense? <pkill9>i did it, i put my CV metadata into a scheme file <daviid>str1ngs: fwiw, i think dsmith-work faced the same or at least a 'similar' problem, while trying to port our bot from using 2.2 to 3.0 - maybe you both can share and enlight us ... in his case, it was for-each that would 'disappear', and i don't think his code uses goops either ... <daviid>but i still on 2.2.7, so i have little to offer here ... <daviid>str1ngs: you could try to snipset this, having just a tiny module a, that import srfi-1, then a module b, that import a but _not_ srfi-1 and check a map call in both module, using 2.2.7, then 3.0.x (the latest preferably ...) and see what that gives you <daviid>str1ngs: just to complete, even using goops, in the a and/or b should not change the expected behavior, which is that both should see a map procedure, a using the srfi-1 and b the guile core one ... my 2c <str1ngs>daviid: I think I hit kinda a edge case. emacsy does some re-exporting which is causing some problems. I at least know what is causing some problem. Also for what it's worth I have working patch for g-golf and guile 3. https://paste.gnome.org/pqz4mmn5h take the patch with a grain of salt. if you have some feedback on how to avoid using #:re-export-and-replace . g-golf suffers the re-export issue emacsy does in regards to srfi-1 and the <daviid>str1ngs: it's only if you import g-golf, and a namspece that defines a map short method name that, in that module, map you be promoted to a generic function, with the default procedure bound to what the module 'sees' (the srfi-1 map proc if srfi-1 is imported, the guile core proc if not) <str1ngs>daviid: that's not what I'm seeing. it's if a module that uses map and imports g-golf were the issues happens. and only with guile 3 of course. <daviid>str1ngs: just importing g-golf? no namspace 'yet' ? <daviid>nothing changes here, just using g-golf does not promote map as a generic functipon <daviid>$2 = #<procedure map (f l) | (f l1 l2) | (f l1 . rest)> <daviid>scheme@(guile-user)> ,use (g-golf) <str1ngs>also it happens with setenv which is weird <daviid>$3 = #<procedure map (f l) | (f l1 l2) | (f l1 . rest)> <daviid>g-golf doesn't use setenv, afaict <daviid>str1ngs: you really should try to talk to dsmith-work <daviid>and built the snipset i mentioned <daviid>i would do it, but i don't have 3.0.x at my finger tips now ... <str1ngs>this has nothing to with a generic function as far as I can see. this has to do with g-golf re-exporting (srfi srfi-1) map which overrides the core binding. it happens with setenv too. <daviid>str1ngs: ok, then in the snip set, you may try to have a b module that just use srfi-1, and another example that re-export srfi-1 <str1ngs>let me see if it does it with one of our examples. I have to many moving parts right now with emacsy . one sec. <daviid>by all mean, re-exporting sfri-1 froma module shuld make it so it disapears in the importer ... and to convinve guile maintainers, you'd rather leavbe g-golf out of tye loop <daviid>sorry my typing is less then optimal :) <daviid>try what i said, just module a, then module b, just that <str1ngs>daviid: if you build g-golf with guile 3. and do ./pre-inst-env guile. ,use (g-golf) and (oop goops describe) . then do (describe map) <str1ngs>as you see this happens without using another module even. <daviid>is it that describe promote map as a generic?, that's a goops code <daviid>it doesn't, afaixct, just checked <daviid>mind you, guile also defines a describe proc somewhere <str1ngs>does not return anything it give Unbound variable: map and warnings of WARNING: (guile-user): imported module (g-golf) overrides core binding `map' <daviid>str1ngs: ok, then you should be able to reproduce this without g-golf, then file a bug report <str1ngs>as I said #:re-export-and-replace (setenv map for-each connect) fixes it <daviid>thyis has nothig to do with g-golf <daviid>str1ngs: but does 3.0 says we must do that? maybe, i don't know <str1ngs>well, you are re export srf1 srfi-1 . so I'm not confident this is a guile bug daviid <str1ngs>I mean I have a fix here also tests pass. so whats your feed back on using re-export-and-replace? <daviid>str1ngs: why would re-exporting srfi-1 or any other module public interface trigger a bug? <daviid>str1ngs: if you re-export the public interface of a module tha defines map, there is no justification that the imported module would not have that name defined ... <str1ngs>if I remove (srfi srfi-1) from re-export-public-interface the problem goes away. <daviid>weither way, thye module b, that imports a (that imports and re-export srfi-1) should see map <daviid>i wish i had 3.0 at my finger tip, this has nothing to o wit g-golf ... <daviid>thry what i suggest, without g-golf <daviid>if module b import and re-export srfi-1, any moduel that import b shold see the map defined in srfi-1 <str1ngs>I don't think so . if you reexport srf1 srfi-1 then its going to override the binding. <daviid>but i know 3.0 made things very complicated with thatc respect <str1ngs>I don't have to time to go over this I have my local fix. I need to fix more important issues with emacsy and guile 3 <str1ngs>the patch a link passes all tests and seems to improve things so looks like there is an improved. don't know if you want to save that for later reference or something. <daviid>but it has nothig to do with g-golf :) - it manifest itself because that's what you use, but with a tiny, just a few lines of code, module a, b ... one woud reproduce the poblem ... <daviid>i'm surprised you didn't had to declare any modules declaratices, lime (g-golf hl-aopi gobject) principaly <str1ngs>daviid every time I post an issue with g-golf it has nothing to do with g-golf. Until I have utterly convinced you. I don't think it takes much to look at my patch provide feedback on re-export-and-replace. I mean it a pretty basic code review. <daviid>str1ngs: importint srfi-1 and re-exporting srfi-1 is not a g-golf 'thing' <str1ngs>please at least look at re-export-public-interface and consider if that might be the culprit then. <str1ngs>because using that on srfi-1 might explain this problem. <daviid>str1ngs: it might be that 3.0 does not let any module re-export their public interface 'as before', yet it hasd nothi8nbg to do with g-golf <daviid>str1ngs: that's not what i mean and never will pretend , never ever - i am saying 3.0 introduces a constraint, that makes it appear g-golf fails, but the symptom involves procedures that are not being (re)defined nor promoted to generic functions, in a senario that perfectly works 2.0 and 2,2 <daviid>and the patch as pasted, will break for users that uses 2.0 opr 2.2 <str1ngs>yes, I said take it with a grain a salt with a caveat for feedback. which you have not provided. <str1ngs>I suspect the best thing to do here is not re export srfi-1. I'm confused to why it needs exporting? <apteryx>why can't I recalled failed expressions at the Geiser REPL? <apteryx>is this behavior configurable? I find it annoying. I just want to recall the same block of expression to edit it, but it seems it's trying to outsmart me (eh, not recalling this, as it failed the last time I evaluated it!). <str1ngs>apteryx: are you using guile readline in the REPL? <str1ngs>I'm assuming by recall you mean history? <str1ngs>and you have readline working in the REPL. arrow up and down work? <apteryx>I'm in Geiser REPL in emacs. let me check if the behavior is the same at the Guile REPL in a terminal <str1ngs>geiser might have it's own command history. <apteryx>yeah, the behavior is OK in Guile itself (I can recall the failed expression) <apteryx>in Geiser, when I do M-r, I can search back, but there's no match for any failed expression. <str1ngs>M-r and M-p work for me. say if I do (dddd) and it back traces in geiser <daviid>str1ngs: not being able to re-export the public interface of a module - or having to manually decide which may or may not, using replace or not is the problem ... i was not criticising your patch, i was trying to tell you that there is no way, as of today, to define a module conditionally <apteryx>str1ngs: OK, I'll debug on my side, must be some other package interaction then. Thank you! <str1ngs>apteryx: try without ~/.guile and restart a REPL. sometimes geiser has issues finding the prompt. <daviid>str1ngs: by thew way connect is promoted as a generic and the module specify to replace the binding, in (g-golf hl-api signal), fwiw <str1ngs>it's actually quite the voodoo finding the guild prompt. <str1ngs>daviid: maybe there is a bug in guile dunno. I'm working on a fix that does not use re-export-and-replace. though like I said it's not apparent to me why srfi-1 needs exporting <apteryx>str1ngs: ah, it seems to occur only with multi-line expressions <str1ngs>does it only happen when it's a expression error? <str1ngs>I know guile REPL can't handle those. <apteryx>I believe it was an expression error? In procedure scm_lreadr: #<unknown port>:33:68: invalid character in escape sequence: #\: <apteryx>I'm trying to define a string literal which contains #\: <apteryx>guix repl is able to cope with that, but Geiser fails to show it in my history. <str1ngs>apteryx: it won't give me history for that either <apteryx>strange :-) perhaps I should open a bug for it. <apteryx>it's not the only occurence I've experienced. I'm often annoyed about it. <daviid>str1ngs: imo not re-exporting sfri-1 would only 'hide the problem', but not fixed it, it would not fix setenv nor connect for example, or does it? that would be very surprising ... but anyway, I need to find a robust solution that allows g-golf to work 'out of the box' for 2.0, 2.2 and 3.x, and I am not going to manually re-export and replace some names, not others ... again, not criticising that you did that, you had to, an that works, <daviid>great, but that can't be a fix for g-golf itself <apteryx>is there an alternative way to write #\: (the colon character literal) so that it could be embedded in a string? <str1ngs>apteryx: are you internally escaping " here? <str1ngs>#\: is fine its the escaped quotes imho <str1ngs>apteryx: also for stuff like this I use a scratch pad and just eval the expression. saves alot of typing :) <str1ngs>geiser-eval-last-sexp or C-x C-e at the end of the expression <str1ngs>apteryx: geiser-eval-last-sexp or C-x C-e at the end of the expression <apteryx>str1ngs: try (display "(string-split (getenv \"LIBRARY_PATH\") #\:)") <str1ngs>(getenv \"LIBRARY_PATH\") should be (getenv "LIBRARY_PATH" e) <str1ngs>eval this (string-split "root:x:0:0:root:/root:/bin/bash" #\:) <apteryx>str1ngs: I want that Guile program to be stored in a string, so I must escape the double quotes of the Guile program. <str1ngs>btw you sould have mention you needed to escape this :P <str1ngs>apteryx: see (eval-string "(string-split \"root:x:0:0:root:/root:/bin/bash\" #\\:) ") <str1ngs>thought don't use eval-string just for testing here. <str1ngs>daviid: setenv is the only thing that leads em to believe this is a bug with guile. though atypically people don't re-export often maybe? which could be why this has been overlooked? <str1ngs>daviid: I don't see anything in g-golf that effect setenv unless it dynamically using something for GI? maybe we should focus on setenv and not srfi-1? <apteryx>str1ngs: sorry, had trouble with my weechat client <str1ngs>you got this message? (eval-string "(string-split \"root:x:0:0:root:/root:/bin/bash\" #\\:) ") <apteryx>so, escaping the backslash in the character literal <str1ngs>actaully that might not be right. I just know it needs to be escaped like that haha <daviid>str1ngs: i'd rather call this a (new) constraint rather then a bug - and a knowned (by maintainers) constraints - iirc, this has also been discussed in guile/guix ml, because it also triggered bugs in guix (which i believe have been all solved) ... as it did for dsmith-work porting his bot (scheme) code to 3.0 ... <str1ngs>daviid: well I always looked at this a being a stricter guile. I'm only leaning toward using the word bug because you brought it up. ***terpri_ is now known as terpri
<daviid>str1ngs: right - if the simple module a and b snispet I described earlier would raise an exception, i'd perso consider it a bug (in guile) <daviid> - for which maybe I can find a hack in/for g-golf, but merely re-exporting the public interface of a module should never lead to an 'undefined name ...' exception, since it is defined and re-exported ... my 2c <daviid>and that it raises an exception for setenv is indeed misterious <str1ngs>that's why I think it's easy to focus on setenv. since it's not something the is normally gets overridden like map does. <str1ngs>though setenv is not as easy to reproduce as map. map you just need to use (g-golf) <daviid>you test this outside g-golf - just a module a, b ... - i think i have aremote access to machine where i did cimpile guile 3, i'll check <daviid>for info, re-export-public-interface was written by wingo himself :), and uses a public guile internface <daviid>str1ngs: (g-golf support modules) merely calls module-use! <str1ngs>emacsy does the same thing. my question is why does srfi-1 need be be re-exported. that should be available to any guile user. if they use srfi-1 explicitly. kthough emacsy does this it o <str1ngs>I got cut off there.... though emacsy reexports it only exports emacsy modules which makes more sense then to export srfi-1 <daviid>re-exporting srfi-1 is perfectlt valid thing to do ... and if we need to or not does not solve the bug ... <daviid>i wana understand why this raises an exception,m i don't want to make the 'thing' disappear <str1ngs>meh seems silly to do something just because you can. that's not a valid reason <str1ngs>hey your call I just can't help but thing it's causing problem where maybe they are not needed. <daviid>str1ngs: does that fix the setenv? andor the connect? <daviid>if you do not re-export srfi-1 i mean <str1ngs>but from my view export srfi-1 is hiding bugs. for example test/gi.scm does not use sirf-1 and it probably should. <str1ngs>if that's the only reason to export srfi-1 why bothter <str1ngs>it's later here my typing has gone to shit :( <daviid>str1ngs: let's focus on one problem at a time - i did see you added srfi-1 to gi, but here, 2.2.7, the test suite pass without that - does that raises an exception in 3.0 as well? <str1ngs>probably not if I re export. but my point is depending on you if you use first or last duplicate handler you might get the wrong map. and then your test heavily relies on g-golf to re export srfi-1 . <daviid>*added sfri-1 to (tests gi) i mean <str1ngs>since I can't replicate setenv like map. they might be unrelated just FYI. also I use a load so that's changed in guile 3 too <str1ngs>ie specially use load that has the setenv. so lets assume that's a nomad issue for now. <str1ngs>well using load from modules to clarify. <daviid>not a 'confortable' access but ok to test a few things ... <str1ngs>(buffer-string) => "What? A" ; *** failed *** <str1ngs>PASS test/minibuffer.scm (exit status: 0) <daviid>with modules being defined as in g-golf <str1ngs>why I just need to do ./pre-inst-env guile ,use (g-golf) and then map <str1ngs>the effect is the same. obviously reexporting srfi-1 map is overriding (guile) map <daviid>str1ngs: I am glad because since you (and neither do I at this point) do not know why nor how to solve the problem <daviid>now we have a 10 lines snisept we can use to ask for help <daviid>but for once, it has nothing to do with g-golf, and two, it does not overide, tht would be the expected behavior (one can argue about the warningsa ... but ok) it fails to overide and raises an unexpected exception ***apteryx_ is now known as apteryx
<str1ngs>daviid: you are telling me what I already told you from the beginning <daviid>i don't think so - but the important thing is to solve the problem, now we have something others can use to help ... <str1ngs>don't be surprised of one of those solution might be don't re-export srfi-1 though. since it's kinda messes with users importing the module. keep in mind this situation. I want to use core map but I want to use g-golf's connect . neither (default-duplicate-binding-handler '(replace warn-override-core warn last)) or (default-duplicate-binding-handler '(replace warn-override-core warn first)) will work in the situation. I use the load <str1ngs>variant for duplicate handling here. <str1ngs>since core is first and connect is later. <daviid> would be very surprised if the aswer would be don't re-export the public interface of any modeule in 3.0.4 <str1ngs>no I think it's okay, I think guile is just saying be polite and re-export only your modules :) <str1ngs>well I"m off to bed. and then I'm away for a some days on vacation. good night. <daviid>so waht, i can't define a module that uses goops, augemnt it, and makes trhings so the user can import my module and use gopps, as well as the augemtned class and methods ... <daviid>that would make absloutely no sense <daviid>str1ngs: yes, good night, i need to eat something and rest as well ***jonsger1 is now known as jonsger
<leoprikler>reexporting SRFI-1 from your own module sounds like it's asking for bugs ***jonsger1 is now known as jonsger
<leoprikler>imo re-export is a tool to form combined APIs, if you have e.g. (foo bar), (foo baz) and (foo qux) with some dependencies between them, you can separate them into modules, whose public interfaces satisfy each other, but also have a (foo) module, which re-exports only what the user would want to see ***jonsger1 is now known as jonsger
<daviid>re-export is a tool to re-export - it should never ever bug <daviid>and it is very likly not th r-export that fails, but the way the new comiler makes some binding immutable, which is against the vry nature of lisp/scheme <daviid>or 'wish to turn' bindings immutable <daviid>anyway, i'll look how to best cope with these new terrible limitations after i complete two more important features and have g-golf in pre alpha mode ***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<manumanumanu>wingo: Nice work on the branch optimization! Funny fun fun optimizations!