***catonano_ is now known as catonano
<sneek>Welcome back daviid, you have 2 messages! <sneek>daviid, str1ngs says: I was just explaining how setenv was both related and not related to the guile 3 issue. It's still an issue for me in regards guile 2.2.7 and I will be using %gi-method-short-names-skip with setenv. The issues being I rather be explicit when it comes to setting environment variables. <daviid>dsmith-work: I don't mind, thanks., I hope one of our maintainer fixes module-use! in 3.0.4, let's see ... <daviid>str1ngs: there is no 'issue' in g-golf and guile 2.x wrt setenv, nor any other short name methods that needs to 'promote' a guile core procedure to a generic function having the guile core procedure as its default method - that is a g-golf feature, not an issue :) - and the feature is customizable, you may either no build any short name method, or having some, not others ... so we are talking about your personal preference here, which <daviid>is perfectly fine, but definitely not an issue <daviid>str1ngs: the other conments I added were to better describe, not only for you, but others that may follow and wish to understnd, how import works and why one can end up importing class(es) and method(s) that do not pertain to the original namespace manually imported by a user ... ***terpri_ is now known as terpri
<str1ngs>daviid: you seem to be correcting me on an issue that I was just informing you about. Last we checked setenv was an outlier to the map issue. I'm simply being courteous and give letting you know what precisely what I discovered. <leoprikler>I don't think the problem is necessarily with module-use! <leoprikler>module-use! for interfaces happened to work in Guile 2.2.7, but don't ask me to find the portion of code, that made it work <leoprikler>One drawback of the Guix package manager is, that it lacks super cow powers :( <pkill9>there is cow-store, maybe that could be considered a super cow poewr <str1ngs>pkill9: I alway though it would be amusing to name cow store to barn :) <civodul>good day, Mr/Mrs peanutbutterandc :-) <civodul>i won't look at it today, but as long as it's in the bug tracker, it won't be lost <peanutbutterandc>civodul, Ah, I see. Thank you very much. I just couldn't help myself, seeing that you were here (in #guix). A good day to you too, sir! (: <ArneBab_>wingo: a heatfelt welcome to your child in this bright and harsh but beautiful world! <ArneBab_>chrislck: and a lovely welcome to your child, too :-) <civodul>the phrase "the Guile family" makes even more sense :-) ***terpri__ is now known as terpri
<ArneBab_>mwette`: this doesn’t cover installation of the package itself (since it uses the trivial-build-system), only installation of dependencies via guix environment <ArneBab_>mwette`: I tested it with guix environment --pure -l guix.scm <leoprikler>Yeah, I don't think guile-gnome is a good source for research on modern Guile code ;) <leoprikler>The last change to this file was in 2014, to the repository in general in 2017. <dsmith-work>leoprikler: Right. daviid was looking for a replacment or a fix. <dsmith-work>using #:re-export (srfi srfi-1) in the use-modules form works fine. <str1ngs>dsmith-work: #:re-export shoudl work for guile 2.2.7 as well right? <leoprikler>#:export, #:re-export etc. export symbols, not modules <dsmith-work>Ok, I'm working from memory. It was some #:re-* thing. <str1ngs>re g-golf I experimented with #:re-export-and-replace (setenv map for-each connect). but that's not backwards compatible, also I was not sure of the impact overall. <leoprikler>the only difference between guile 2 and 3 is that 3 will warn about overrides with re-export <dsmith-work>I think what they want/need is re-export whole public interface(s). <str1ngs>is #:re-export proffered over module-re-export!? <str1ngs>but it only works on symbols so that would be tedious I guess. <leoprikler>#:re-export and re-export! are both syntax, whereas module-re-export! is a generic procedure <leoprikler>btw module-re-export! wants a list of symbols also, so... <str1ngs>right but you can loop over that with module-for-each <str1ngs>I guess the real issue is somewhere in this process core bindings not just have a warning but become unbound. <leoprikler>again, that's because you're trying to export a module by modifying something other than the obarray <str1ngs>aye I didn't think re-exporting (srfi srfi-1) was a good idea other. but daviid thought that is should be allowed and the problem should not exist. so maybe maybe there is ignorance on my part. <leoprikler>Well, the thing is there is a significant difference between re-exporting the module (srfi srfi-1), vs. the contents of (srfi srfi-1). <leoprikler>One of those doesn't really make sense in most interpretations whereas the other does. <manumanumanu>ArneBab_: my son just made me write his first program. It was a simple (display "bajs"). Bajs means poop in swedish. He apparently shares my sense of humour. <leoprikler>Someone should write a JS interpreter called bajs <mwette>bajs = "Bad Ass JavaScript" (pun intended) <str1ngs>leoprikler: does'nt node already exist :P <leoprikler>sounds like the name for an exciting new frontend <manumanumanu>as everyone reading xkcd knows, moving the implicit hyphenation is a source of neverending fun! <leoprikler>don't make fun of me! Soon, the entire industry will use it... for about five minutes, before they hop onto the next <dsmith-work>Someone will use it to write a js build tool. Because there are just not enough of them yet. <dsmith-work>And then it will be baked in to CI processes everywhere. <ArneBab_>mwette: ah, yes, you already merged it — sorry for the noise :-) <ArneBab_>how can I resolve ~ in a filename as home? Is there a readymade proc or do I have to roll my own? <leoprikler>there's no "expanduser" as in emacs lisp or python <leoprikler>we had that discussion a while ago; that's not what POSIX does <leoprikler>for ~arnebab, you'd want (passwd:dir (getpw "arnebab")) <leoprikler>but for ~<NULL>, (getenv "HOME") is the mandated behaviour <ArneBab_>Can we just do this right once and create (resolve-filename filename)? <ArneBab_>I expected (open-file …) to just do this — a 5 minute hack just blew up to >30min <leoprikler>Hmm, I do think it would fit better into guile-file-names <leoprikler>basically, since this thing splits file names into lists, you'd want something that expands "~[.*]" inside that list <ArneBab_>isn’t that a huge dependency just to get the resolution that’s common in bash? <leoprikler>perhaps, but in python you'd also pull in os.path for that <ArneBab_>or is the hidden intrinsic complexity enough to warrant that? <dsmith-work>Hmm. Not entirely serious, but kind of: If you want bash behavior, how about shelling out to bash? <dsmith-work>As a larger issue: instead of duplicating functionality, use what already exists? <ArneBab_>I thought about just making a bash-script, but I didn’t want to … <leoprikler>The thing is, if you do this via string manipulation and regexp, you'll inevitably reinvent the wheel <ArneBab_>guile-file-names is packaged in guix, so I’ll go that way — thank you <ArneBab_>shelling out to bash is often a security risk. <dsmith-work>Off on a rabbit trail: Does bash provide a library for such things? <str1ngs>it would be nice to have something like Emacs 'expand-file-name in guile. <leoprikler>file-names does have a large number of valuable procedure (including glob apparently) <ArneBab_>What I’d prefer is to have canonicalize-filename resolve these <leoprikler>hmm, just noticed it is only packaged for guile2 <ArneBab_>not the quick hack I can do at this time of the year <ArneBab_>sounds like moving away from GOOPS, but looking at the latest commit that might have been done already <leoprikler>I think this is rather because of overriding issues <dsmith-work>Filenames can be troublesome, with different encodings and all. <ArneBab_>I decided to avoid complexity and just treat ~/ in the first cond-statement <ArneBab_>would be safer by just replacing the first char <ArneBab_>and I can go down to string-replace from Guile proper <str1ngs>yep that's one of the draw backs getenv. <ArneBab_>or /tmp? (but that might throw away user input) <str1ngs>ArneBab_: passwd:dir like glibc does. but that could fail too <str1ngs>you need passwd:dir to handle ~$USER and ~other-user anyeays <str1ngs>~userdoes not exist should probably not expand and be treated as path literally. so not found <str1ngs>probably good to check posix spec on that one. <dsmith-work>ls: cannot access '~nouseratall': No such file or directory <ArneBab_>damn, getpw throws an error if the user doesn’t exist <str1ngs>forgive my ignorance, but doesnt CL have a type just for paths? <ArneBab_>would be great if someone could take it up and for example … guile-lib … <dsmith-work>Hmm. Never noticed before, but glibc seems to have an expansion function <leoprikler>ArneBab_: why not take the length of the match in case 2? <str1ngs>dsmith-work: I wrote this FFI to wordexp. http://paste.debian.net/1161190 nice thing is it does globbing too. though not that secure. actually leoprikler was instrumental with some of the FFI bit. <leoprikler>yeah, that's pretty much the same i would have written <ArneBab_>should/can I mention you in the file (want to submit to guile-lib; it’s 90 min of hacking after all) <str1ngs>ArneBab_: I think guile-lib is a great candidate for this. <ArneBab_>yepp, that’s where I got the getlogin from <ArneBab_>(the bugs found before submission are the best bugs :-) ) *str1ngs quick! grabs his flyswatter <ArneBab_>Deepest thanks to magit for making git-format patch usable :-) <ArneBab_>leoprikler: I also added some docstrings with texinfo (because guile-lib has that at other places) <ArneBab_>leoprikler: followup-thought: I put both procedures under LGPL to allow easy inclusion into Guile — was that OK (if not I’ll write a followup-email to David) <daviid>ArneBab_, leoprikler, str1ngs, dsmith-work nice! <daviid>ArneBab_, can I ask you to email guile-user, subject something like 'guile-lib: new (string posix) module, filename resolution procedures - proposal for inclusion' or 'something like that', and ask for review/objection, so this gives a chance to anyone who's interested to 'raise their voice' ... not sure aboutr the lice4nse, please ask opinionate3d opnion in the email to, I suggest, tx! <leoprikler>ArneBab_: yes, I meant to apply the same license to both. Since you already used LGPL, I'm fine with adding the rest under it. <daviid>ArneBab_: excellent, I don't think anyone will object, but I feel it is the right thing to do, guile-lib is 'to all of us' - I just happen to be one of the (not very good so far) co-mainainer