IRC channel logs

2020-08-12.log

back to list of logs

***catonano_ is now known as catonano
***terpri_ is now known as terpri
<pkill9>how do i refer to an #<eof> ?
<daviid>pkill9: eof-object?
<daviid>(eof-object? (eof-object)) -| #t
<pkill9>that's what I wanted, thanks
<daviid>welcome
<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.
<daviid>ok
<str1ngs>daviid: should make distclean remove configure. I did'nt think it should do that.
<str1ngs>just a curious quesiton
<daviid>i think it should
<daviid>not sure
<str1ngs>I'll have to read up on that more.
<str1ngs>daviid: looks good so far.
<daviid>ok great
<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>hi all
<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?
<chrislck>Wednesday greetings, guilers!
<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
<manumanumanu>Ahoy hoy!
<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
<dsmith-work>UGT Greetings, Guilers
<dsmith-work>dadinn: That "var=val command" is a shell thing.
*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
<dsmith-work>RhodiumToad: Agreed
***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>nisstyre: no but I did make a FFI to libc's wordexp. see http://paste.debian.net/1160174. it does word exaction like ~ and lobbing.
<nisstyre>I see, I could use that maybe
<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>thanks for the pointer
<nisstyre>isn't wordexp insecure btw?
<RhodiumToad>wordexp probably does much more than you need
<nisstyre>in my case I think it's fine but in general, I've heard it's gnarly
<RhodiumToad>yes, it's not at all safe
<RhodiumToad>you don't want it just to handle ~
<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.
<guix-vits>str1ngs: No: `C-x f .nomad` steel asks.
<guix-vits>(i started a new emacs.)
<guix-vits>
<guix-vits>/me "YAY, THIS ARMBIAN STUFF BOOTS!"
<str1ngs>guix-vits: I'm assuming it's geiser that is asking?
<str1ngs>guix-vits: which board are you using with armbian?
<guix-vits>str1ngs: IDK :) (but geiser is installed).
<guix-vits>str1ngs: rockpro64
<str1ngs>oh why I was just going to order one of those. like in the next 10min
<str1ngs>is it a pine64?
<guix-vits>Yes.
<str1ngs>nice
<guix-vits>
<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>str1ngs: "Scheme implementation:"
<guix-vits>I've a "#! # -*- mode: scheme; coding: utf-8 -*- !#" (three lines)
<guix-vits>
<str1ngs>guix-vits: I think I gave you a typeop. should be (setq geiser-default-implementation 'guile)
<guix-vits>str1ngs: Thanks, that working.
<str1ngs>sorry about that. mine seemed to work despite the typeo
<guix-vits>hmm.. i didn't see a difference.
<str1ngs>alos you can manager local variables with emacs. M-x: add-file-local-variable <RET> mode <RET> scheme
<str1ngs>my typing when to shit today :(
<guix-vits>implIme..
<guix-vits>got it
<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
<guix-vits>:)
<str1ngs>guix-vits: best place to as is in #emacs
<str1ngs>guix-vits: btw I use these to connect a running nomad. http://paste.debian.net/1160180 . also in ~/.nomad http://paste.debian.net/1160181
<str1ngs>guix-vits: first paste is emacs for geiser of course
<str1ngs>guix-vits: /tmp/nomad-devel works with make run.
<guix-vits>str1ngs: Got it, will examine. Thanks.
<str1ngs>guix-vits: also you can always do M-: (getcwd) use any expression . the REPL server is more advance use case.
<str1ngs>this is in nomad, not emacs :)
<guix-vits>OK
<guix-vits>*yet not in emacs, (lol)
<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
<nisstyre>it works for now though
<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
<the-y-is-wrong>gn
<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>something like => https://gitlab.com/janneke/guile/-/commit/16e21e9a35ac735243d0a5381d72b251b2b8030d
<janneke>hmm, possibly we need long-size and pointer-size in (make-assembler)?
<janneke>oh my
<RhodiumToad>hm
<RhodiumToad>that smells like the wrong approach to me
<RhodiumToad>the issue is that "long" on win64 is only 32 bits?
<janneke>yeah, well
<janneke>what i observe is that a > 32bit number, say (define DT_GUILE_VM_VERSION #x37146003)
<janneke>is read incorrectly from a .go file
<RhodiumToad>ah.
<janneke>so, adding pk's in assembler.scm shows
<janneke>;;; ("DT_GUILE_VM_VERSION" -149659645)
<janneke>after .go compilation
<RhodiumToad>is the guile build actually limiting itself to 32 bits for short fixnums even though 64 bits are available?
<janneke>i don't know...
<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>dsmith-work: OK
<janneke>reading the code in numbers.h
<janneke>typedef long scm_t_inum;
<janneke>#define SCM_I_FIXNUM_BIT (SCM_LONG_BIT - 2)
<janneke>...
<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>yeah
<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>yeah
<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>So from scm.h:
<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>which is what I just said :-)
<dsmith-work>Heh
<dsmith-work>Current guile has
<dsmith-work>typedef uintptr_t scm_t_bits;
<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*
<RhodiumToad>(I know of no such system)
<janneke>yeah -- that code "works" for me
<mwette>What is "native word size" in C. I don't think "int" works.
<dsmith-work>mwette: I think that's what it was intended to be.
<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!
*janneke -> zZzz
<mwette>btw, there's intptr_t
<dsmith-work> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#page=45 paragraph 7:
<dsmith-work>A "plain" int object has the natural size suggested by the architecture of the execution environment
<dsmith-work>para 5, not 7