<jgart>is there a way to reload ~/.guile from within the guile repl without using emacs and without exiting the repl? <jgart>I'm looking for a short command I can run like ,q <str1ngs>jgart: (load (string-append (getenv "HOME") "/.guile")) should work <str1ngs>jgart: also ,l "/home/<user>/.guile" replace user and assuming HOME is in /home <jgart>I tried the following: (define ll (load (string-append (getenv "HOME") "/" "test.scm"))) <jgart>now I can load that file with ll but it doesn't seem to update <jgart>Is there an easy way for me to add another meta command instead of polluting my environment? <jgart>or a custom meta command I should say <jgart>is there currently a meta command for going to the top repl (for example in gambit if one is in the 3rd nested repl they can type ,t to go to the top repl <daviid>lisbeths: display, write, simple-format or format <lisbeths>it says something like 'img is wrong type for map <daviid>ok, in the 'future', can you use debian or gnome paste, not pastebin, nor any not tro-friendly/tracker 'system', tx <str1ngs>rlb: hello, do you know the policy on debian for adding /usr/local to search paths? for guile it might be nice if say export GUILE_LOAD_PATH="/usr/local/share/guile/site/2.2" where included in a /etc/profile.d/guile-2.2.sh. <str1ngs>that would break with multi guile's though never mind me. <guix-vits>Hello. Are 'module-ref' and '@@' a same thing? <str1ngs>guix-vits: (@@ (srfi srfi-1) map) and module-ref (resolve-module '(srfi srfi-1)) 'map) both return the samething. <str1ngs>as for the underlying mechanics I can not say. <str1ngs>err (module-ref (resolve-module '(srfi srfi-1)) 'map) <str1ngs>guix-vits: try on unexported bindings as well <guix-vits>str1ngs: Yes, tried, bu still wonder if (module-ref is "more 'correct'" way to force-pet the unexported make-linux-libre*. <guix-vits>The manual didn't shown any warnings about module-ref approach (i want to be a good boy). <catonano>jgart: did you receive any info about how to extend the commands set of the repl ? <jgart>I'd love to figure that one out <jgart>I'd also love a way to exit to the top repl from a series of nested debugger repls <jgart>is there anything like decompile in guile? ***sneek_ is now known as sneek
***catonano_ is now known as catonano
<str1ngs>simendsjo: hello, glad you got it working. ***guix-vits is now known as guix-vitscivodul
***guix-vitscivodul is now known as guix-vits
***guix-vits is now known as vits-no-x-aarch6
***vits-no-x-aarch6 is now known as guix-vits
<str1ngs>have any ideas how I might look into this? <rlb>str1ngs: offhand something like that doesn't sound unreasonable - though I do tend to try to favor upstream defaults. Looking at the default %load-path, I could imagine having a versioned an non-versioned local pair "somehow", but ideally that'd be something we settled on and arranged upstream. And as I think you may have been referring to, there'd be questions about what ordering (if any) might be sensible. <rlb>I believe emacs puts local fairly close to the "front", fwiw. <rlb>...which is fine as long as /usr/local/ has appropriate permissions. <str1ngs>I guess the reason I bring it up is for example there were dependencies for guix in say ubnuntu 20.04. but now guile-zlib an guile-lzib are new dependacies. this would help users who install manually with the defualt GNU configure --prefix=/usr/local just a musing on my part. <str1ngs>also ran into this helping someone install g-golf/nomad on a debian system where dependencies have no package yet. <rlb>might also want to mirror the current VERSIONED NON-VERSIONED pair. <rlb>but I suspect it'd be worth some discussion on guile-devel (or similar) first. i.e. if it's appropriate then maybe it's not just a debian thing, and if it's not appropriate, then... <str1ngs>I guess mainly if emacs adds /usr/local for search paths it would be a quality of life improvement for guile users as well. <str1ngs>hmm good idea, are you suggesting maybe adding this as a default to %load-path? <str1ngs>that would probably have to be back ported though. but actually more elegant solution rlb <rlb>either always or maybe via configure option --with-local-dirs or... <rlb>and wrt ver/non-ver, e.g. ("/usr/local/share/guile/3.0" "/usr/share/guile/3.0" "/usr/share/guile/site/3.0" "/usr/local/share/guile" "/usr/share/guile/site" "/usr/share/guile") <rlb>And sure, once it's decided, could always implement it in say debian "early" or at least discuss that (depending on how much we want to "just track upstream"). But even if not, we can just suggest a trivial wrapper for people to use in the interim. <str1ngs>that's the only real issue I've had with guile on ubuntu atleast. other then that it's pretty top notch. and mainly that's from supporting a end user perspective. <str1ngs>as a note could use guile-zlib and guile-lzip in the repos. <str1ngs>wish I was was more proficient with package for debina. <str1ngs>also guile-3 variants like guile-git etc. not to much of big deal there since guile-2 works <rlb>I'm currently poking at some clojure related packaging questions and depending on how that pans out, I might learn more about debhelper plugins, if if that pans out, and isn't too difficult, we might contemplate some kind of dh_guile helper -- which might make it much easier to package (some) guile modules. <rlb>But I've been reasonably overcommitted recently, so "we'll see". <str1ngs>I wish I had more time to work on this. it's somewhat easier to work on guix package then debian. <rlb>Haven't tried guix, but wouldn't be surprised. <rlb>I use git-dpm, but in some ways that *increases* the initial complexity in exchange for being able to use git to manage the debian patches. <joshuaBPMan>Trying to build a static site with haunt...seems tough. <str1ngs>might help if you are looking for an example. <joshuaBPMan>str1ngs: thanks. The guix.gnu.org site is impressive, and confusing. <joshuaBPMan>str1ngs: have you ever read Gardens of the moon? Your alias reminds me of one of the characters... <joshuaBPMan>str1ngs: I'm confused...that 8sync/website.git seems to be an empty repo... <str1ngs>joshuaBPMan: I have not read that book, my nick is in reference to guitar strings :) <joshuaBPMan>str1ngs: ahhh. bummer. Strings is also known is fiddler in my book. He's pretty bad a*s. *str1ngs probably going to get beat up by fiddlers now. <joshuaBPMan>str1ngs: nah. Fiddler ended fights. if you've got his name, you'll do the same. <dsmith>There are guitars and then there are guitars.