***catonano_ is now known as catonano
***terpri_ is now known as terpri
<daviid>(eof-object? (eof-object)) -| #t <daviid>str1ngs: I pushed an important patch - related to short method names, no rush, but when you can, please pull, make, check ... and let me know if everything is ok ... <str1ngs>daviid: I can do that now since I'm working on nomad anyways. <str1ngs>daviid: should make distclean remove configure. I did'nt think it should do that. <str1ngs>I'll let you know if I run into any issues. I suspect it's okay so far though. <RhodiumToad>make distclean should not remove configure, and configure should be included in the distribution. <RhodiumToad>I don't know about other projects, but for postgres we even commit ./configure to the repo and maintainer-clean doesn't remove it either ***apteryx_ is now known as apteryx
<dadinn>How can I pass environment variables to a `system*` call? <dadinn>normally in shell scripting I can do: `FOO=BAR myscript my args` <kahiru>wouldn't a combination of primitive-fork and execle work instead of that? <dadinn>kahiru: not sure how execle works... can it do that? <kahiru>according to the docs it executes the arguments passed to it in the same process with a new environment, that's why I suggested forking before that. But this is probably the most DIY and least preferable solution, even if it is the only one I'm aware of <RhodiumToad>annoyingly, posix does not define an execlpe() function or any close equivalent, though you can implement one using execve() and some looping ***terpri_ is now known as terpri
<RhodiumToad>I should probably port the spawn module that I wrote for lua to guile, it'll be even more useful there because of eliminating threading issues with fork, but it only works on freebsd ***sneek_ is now known as sneek
*janneke hacks bytevectors.c for mingw-x86_64 <RhodiumToad>dsmith-work: yes, but it's not unusual to want to add env vars to a spawned subprocess ***ftknox_ is now known as ftknox
<nisstyre>is there a guile procedure for expanding a directory path containing ~ ? <nisstyre>I'm trying to automatically load a file from ~/.config but the tilde is interpreted as a directory name <str1ngs>though this returns a list not a single string right now. <nisstyre>str1ngs: I'm already embedding in C actually so I could just write it in C and expose it to Guile <nisstyre>just wanted to know if there was a pure guile way <nisstyre>in my case I think it's fine but in general, I've heard it's gnarly <RhodiumToad>which is a simple string manipulation (unless you want it to work on windows too) <nisstyre>ideally yeah but I have no idea what it should be on windows <str1ngs>nisstyre: potentially I would definitely pass WRDE_NOCMD flag. which I have not added yet here. if you just want ~ expansion there could be a safer way. I'm primarily using wordexp because it does globbing as well. <RhodiumToad>windows has an API to get their equivalent of a home directory, but while you could probably do it via the ffi I'm pretty sure there's no native support for it in guile <str1ngs>ideally what guile could use is something like emacs expand-file-name <str1ngs>which is complicated because it support windows :P <guix-vits>Hello, Hello str1ngs. Is it simple to prevent emacs from asking about scheme implementation? I need to say "guile" when opening the .nomad. ***grant is now known as dead10cc
<str1ngs>guix-vits: hello, yes you can do (setq geiser-active-implementations '(guile)) <str1ngs>guix-vits: err this as well. (setq geiser-default-implimentation 'guile) <str1ngs>ignore the first one if you use other schemes of course. <str1ngs>guix-vits: I'm assuming it's geiser that is asking? <str1ngs>guix-vits: which board are you using with armbian? <str1ngs>oh why I was just going to order one of those. like in the next 10min <guix-vits>Heatsink didn't arrived at first time (maybe due to our post), The fan isn't working (yet :), but DARN! :))) <str1ngs>I want to replace my jetson with a rockpro64. will go nicely with my pinebook and pinephone. <str1ngs>guix-vits: what is the exact message emacs give you when asking for which guile to use? <guix-vits>I've a "#! # -*- mode: scheme; coding: utf-8 -*- !#" (three lines) <str1ngs>guix-vits: I think I gave you a typeop. should be (setq geiser-default-implementation 'guile) <str1ngs>sorry about that. mine seemed to work despite the typeo <str1ngs>alos you can manager local variables with emacs. M-x: add-file-local-variable <RET> mode <RET> scheme <guix-vits>str1ngs: Do You know by chance, also, how to prevent Gnus from messing up the newlines in attachments? <str1ngs>guix-vits: I don't know gnus very well. I used it for awhile it was always a PITA. so now I use mu4e <str1ngs>guix-vits: best place to as is in #emacs <str1ngs>guix-vits: first paste is emacs for geiser of course <str1ngs>guix-vits: /tmp/nomad-devel works with make run. <str1ngs>guix-vits: also you can always do M-: (getcwd) use any expression . the REPL server is more advance use case. <leoprikler>nisstyre: for just handling ~, you could try regexp matching and use (getenv "HOME") <nisstyre>leoprikler: I did end up using (getenv "HOME") but I'm sure there's a better way <leoprikler>If you're looking for a pythonesque os.path.expanduser, I think I must disappoint you <leoprikler>btw. getenv "HOME" is also what your shell does to expand ~ in case you're wondering ***guix-vits is now known as the-y-is-wrong
<janneke>hmm word-size and pointer-size are used intermingled'ly <janneke>i guess we need to switch to (sizeof long) for x86_64-mingw <janneke>hmm, possibly we need long-size and pointer-size in (make-assembler)? <janneke>what i observe is that a > 32bit number, say (define DT_GUILE_VM_VERSION #x37146003) <janneke>so, adding pk's in assembler.scm shows <janneke>;;; ("DT_GUILE_VM_VERSION" -149659645) <RhodiumToad>is the guile build actually limiting itself to 32 bits for short fixnums even though 64 bits are available? <janneke>guild compile --target=x86_64-w64-mingw32 yields the same as without target <janneke>and i'm wondering if that's OK, or that 64bit mingw .go files should be different <dsmith-work>janneke: There are 4 kinds of .go files. {BE,LE}{32,64} <dsmith-work>I'm fairly certain guile assumes a pointer and the native word size are the same. A SCM needs to look like either at different times. <janneke>#define SCM_I_FIXNUM_BIT (SCM_LONG_BIT - 2) <janneke>it seems to me that the size of LONG is used for the immediate number layout in the SCM <RhodiumToad> * In the current implementation, Inums must also fit within a long <RhodiumToad> * because that's what GMP's mpz_*_si functions accept. */ <janneke>so upon reading the .go on mingw, "someone" should translate the linux-like-64bit .go from immediats to bignums? <RhodiumToad>so on LLP64 platforms like windows, guile can't use half the available bits for fixnums <janneke>that's why i thought the .go may have to be different <RhodiumToad>uh, given that restriction, I don't see how an LP64-compiled .go could ever be compatible with an LLP64 platform <janneke>so many options if you don't know how things work :) <janneke>that was my thought, but dsmith-work asserts that must not be so? <janneke>i'll try adding a fixnum-size or long-size to (make-assembler) etc. <janneke>changing word-size to 4 on mingw is NOT okay <RhodiumToad>guile's SCM type must be exactly the size of a void* <dsmith-work>" - sizeof (scm_t_bits) <= sizeof (void*) and sizeof (SCM) <= sizeof (void*) <dsmith-work> In some parts of guile, scm_t_bits and SCM variables are passed to <dsmith-work> functions as void* arguments. Together with the requirement above, <dsmith-work> this requires a one-to-one correspondence between the size of a <dsmith-work> void* and the sizes of scm_t_bits and SCM variables." <RhodiumToad>so as it stands the code in bytevectors.c is definitely wrong on LLP64, and your fix for that looks almost reasonable, though it would break on a system where long is bigger than void* <mwette>What is "native word size" in C. I don't think "int" works. <mwette>on my x86_64 box, sizeof(int)=4, sizeof(long)=8, sizeof(void*)=8 *janneke stubbornly tries adding 'fixnum-size" to target and assembler <janneke>thanks a lot, more for/from me tomorrow! <dsmith-work>A "plain" int object has the natural size suggested by the architecture of the execution environment