***nckx is now known as PotentialUser-93
***PotentialUser-93 is now known as nckx
***V is now known as Guest7215
<dadinn>I am getting a weird compilation error complaining about an unbound variable, but the script still runs <dadinn>this is the definition: (define current-dir (dirname (current-filename))) <dadinn>I use it in a call right after it: (add-to-load-path current-dir) <dadinn>this is because I have some modules in a git submodule, and want to use them <dadinn>but i think the error comes after this, at the end of the file I am referring to it again <dadinn>tried to compile the script with guild also, which gives a bit more of the backtrace, but it is not really useful ***V_ is now known as V
<dadinn>hmm, actually it seems that it fails right at the add-to-load-path call :/ <daviid>dadinn: could you try (add-to-load-path (dirname (current-filename))) instead, and also call (dirname (current-filename)) at the other places, instead of refering to current-dir, and see if that works <sneek>daviid, you have 3 messages! <sneek>daviid, peanutbutterandc says: I tried to take a quick poke at running the hello-world g-golf script and then ran into the following issues: 1. g-golf isn't guile3.x ready yet. worked around that issue using: `guix environment --ad-hoc guile@2.2.7 g-golf` but then encountered 2. this error: https://termbin.com/myt5 (I also had to make a small change to how the script itself was called: https://termbin.com/cjds ) <sneek>daviid, peanutbutterandc says: sorry false alarm `guix environment --ad-hoc guile@2.2.7 g-golf gtk+` worked just great (thanks to leoprikler for pointing my foolish mistake). Shiny! <sneek>daviid, dsmith-work says: I never got to the bottom of the mising for-each issue. I assumed it was some interaction with the way bobot++ was messing with modules. I just used srfi-1 and moved on. <dadinn>daviid: yes it was like that before, and it used to work. I extracted the current-dir, because I would need it later in the script :/ <daviid>dadinn: ok, the problem is add-to-load-path does its job at compile and runtime times, if you want to define a variable, you need to make it bound at expand load and eval, try this: <daviid>(eval-when (expand load eval) (set! current-dir (dirname (current-filename)))) <dadinn>the set! call seems to make it unset again <dadinn>this must be some serious black magic! :) <dadinn>Geiser doesn't seem to find docs for expand... are you sure it should be like that? <daviid>sneek: later tell peanutbutterandc you need to install, on guix, what correspond on debian to the gir1.2-gtk-3.0:amd64 (or another arch of course, i pasted what is on my computer ..) <daviid>dadinn: i don't understand 'to make it unset again' <dadinn>sorry, I meant undefined... (define current-dir #f) sets it to #f, but the eval-when call makes it undefined again <daviid>dadinn: i think you should stick to (add-to-load-path (dirname (current-filename))) - but i'll try here, so far i was just maiking assumptions ... <sneek>Welcome back daviid, you have 1 message! <daviid>hum, weirtd it didn't catch the realier message <daviid>sneek: later tell peanutbutterandc yes, you need 2.0 or 2.2, and yes, you need to install the Gtk typelib, on debian, it would be the gir1.2-gtk-3.0:amd64 (or what ever postfix for your acrch of course) ... <daviid>dadinn: what version of gule are you using? <dadinn>daviid: i didn't quite understand the add-to-load-path doing its thing bit... also I have no clue what the (eval-when (expand load eval)... ) bit does... where could i read up on these? <dadinn>daviid: I am using guile-2.2 on Debian buster <dadinn>specifically the version is 2.2.4 <daviid>but in 'general terms', it's because both the eval-when ... and the add-to-load-path (which calls eval-when ...)) tries to access the variable at expand load eval time ... you should stick to the (add-to-load-path (dirname (current-filename))) <dadinn>daviid: yeah, read it... wow! Is my cat going to die? :D <daviid>dadinn: well, i hope you only did void your warranty :) <daviid>dadinn: hum, the example is a bit diff there can you try it? i mean the same but for your use: <daviid>(eval-when (expand load eval) (define current-dir ...)) - i personally would still stick to (add-to-load-path (dirname (current-filename))), but would use that 'example' to define current-dir 'for later use' as you said ... <dadinn>daviid: yeah, with all 3 (expand, load, eval) it seems to work <daviid>dadinn: ok, keep that in mind for the other 6 lives of your cat :):) <dadinn>I never heard about the separate contex/steps between load and eval... is this because the byte compiled code executes differently from an eval call (like in the REPL)? <dadinn>an eval call I suppose have to byte-compile the expression beforehand, and then load it? What does "run-time" mean then? <daviid>dadinn: i'll let others answer those questions, i am a bit busy, i wanted to quick help you ... <dadinn>hmm, never went this deep down the rabbit-hole before... possibly I should have choosen the blue pill! :D <dadinn>daviid: No worries, thanks for the help... learned something useful it seems! :P <daviid>dadinn: you really want to understand that rabbit-hole :) otherwise it will catch you gain <daviid>make sure you undertand the date example in the manual, if not ask here, i hope someone can explain ... <dadinn>daviid: yeah, the date example is good, I don't quite get it yet... evaluating it in my head... Does not compute! ***drakonis- is now known as drakonis
<dadinn>daviid: Not sure how many lifes my cat has left with, but it seems if I only use (eval-when (expand) (define (current-dir ...))) that works fine. The load, and eval wasn't needed <dadinn>does this mean that add-to-load-path itself is a macro? :P <daviid>dadinn: that won't work if you change the plce of the module ... you really want to always use expand load eval ,until you really really know what's going on ... <daviid>add-to-load-path is a syntax, look at its definition, in (ice-9 boot-9) <dadinn>daviid: actually that was I wanted to ask: I see that the .go file is in a cache, so if I move the scm script to a different dir, would this fail? <daviid>dadinn: you're putting your cat in danger :) <daviid>try and siplay (use peek to make a quick trest <daviid>anyway - you've been warned ... be on the safe side when you uswe/have to use eval-when ... use (expand load eval) ... <dadinn>daviid: thanks again, I think I will not dig deeper for now... cat's lives matter! :P <jgart>how can I give this as input '(1 1 1 1) and get this as output '(0 1 2 3) <jgart>I want to construct a list from intervals <jgart>my input list above shows the intervals between adjacent integers in the output list <jgart>any suggestions/tips are greatly appreciated <brendyyn>thats 4 intervals so it would be 5 numbers in the output, not 4? else the first one is starting at -1 <jgart>sorry, the input list should be '(1 1 1) brendyyn, it builds the intervals from a "root" i.e. integer 0 <jgart>brendyyn, and yes you are correct <jgart>if the input list is of length 4 then it outputs a list of size 5 <daviid>dsmith-work: answering the quiz you wrote to str1ngs, because it is not str1ngs 'fault' <daviid>dsmith-work: str1ngs 'faces' a situation which is 'created' by the use of a re-export macro, in a way as i described in the snipset ... so not gona repeat, pease read and try the snipśet (in the log ... ping me if you can't find it), try both with 2.2.x nd 3.0.4 (may be it fails with 3.0.3 as well, but it did work with 2.9.x and 3.0.0 ...) <daviid>dsmith-work: str1ngs is merely a 'victim' here :), that g-golf not only exte4nsively uses the re-export macro, but it does to also re-export sfri-1 public interface, which triggers the problem, but it has nothig to do with g-golf 'per se', not with str1ngs programs, it is a consequence of some 3.0.4 compiler optimazation technique, which expects some name(s) to be immutable - <justin_smith>daviid: so the error is provably in the incompatible assumptions of the codebase and the new compiler, and pragmatically can be solved on either side or both <daviid>I want to understand and hopefully patch that so one can re-export the public iterface of any module, srf-1 is just a 'pretext' and a good/easy way to reproduce the problem <daviid>justin_smith: I don't understand that sentence, sorry - if you think you understand the problem (I mean if you know guile's source code deep down to ... please use the snipset, patch module-use! or fix the macro ... many thanks if you can and the free time to do so, i'm on sonmething else for now and would greatly apreciate a fix from one of our expert guierls 'out there' ... tx <justin_smith>daviid: I should have phrased it as a question - I think I recognize a familiar architectural problem, and hoping I can help by articulating it <justin_smith>daviid: in older guile, re-export is safe. In guile 3 (as designed), immutable macros are safe. The combination is an error. If we had access to both the app codebase and the guile codebase and could change either, there's two ways to fix the issue. <justin_smith>pragmatically, as a political choice, how many codebases re-export and are therefore broken by this new guile behavior? is the benefit of immutable macros great enough to risk the breakage? <justin_smith>that's the question I was rather incoherently starting to ask <daviid>justin_smith: ah ok - I don't have time to go with this the way you wish to, please use the snipset with 2.2, then 3.0.4, if you can fix it, perfect if not, well too bad <justin_smith>OK, I'll see if I have time to help, I was hoping the low effort path of asking some questions would make the answer obvious :D <daviid>there is nothing esle but running a 10 lines snpset and fix it ... the rest is a complete lost of time ... afaic, thanks for help if you can ... <chrislck>jgart: (let lp ((in in) (out '(0)) (start (car in))) <lloda>what i was looking for the other day to look up the backtrace manually is <lloda>(frame-arguments (vector-ref (debug-frames (repl-debug (car (fluid-ref *repl-stack*)))) 0)) <lloda>which is from backtrace in (system repl command) <lloda>you don't really need to use call-with-error-handling since the default repl already prepares the debug stack for you ***dddddd_ is now known as dddddd
<dsmith>daviid: Sorry if I came across wrong. I was merely asking str1ngs what is the sequence of events that casues the failure to happen. Tryting to get to a minimal test case. <dsmith>daviid: Do you have a minimal test case? ***daviid is now known as Guest58294
***gal is now known as galex-713
***nckx is now known as facebook
***facebook is now known as nckx
***Server sets mode: +nt
***jonsger1 is now known as jonsger