<daviid>davexunit: I'd be hapy to try to help, no garantee but i'd be happy to try - it would be easier if '... put together a contrived example that doesn't use all the special library code I have ...', so i can try here ... <daviid>davexunit: the proper route is, imo the mop indeed, exactly what you did, using #:allocation ... <daviid>you don't need to allocate, guile-gnome and g-golf GObject subclass properties are not allocated on the scheme side ... <daviid>*you don't need to allocate using the default goops allocator i mean ... ***metro is now known as metreo
<davexunit>daviid: I feel like I'm on the verge of getting it, but I'll ask a question tomorrow if I'm still stuck. thanks. <spk121>lol. I got a mingw guile 3.0 to run a gtk3 example app. I'm really surprised it actually worked <spk121>davexunit: nah. unthreaded, non-jit, 32-bit only. I think I'm getting close on jit, though <spk121>today, I reimplemented a version of a C procedure called 'ffs' for the jit. I'd never heard of it, but, that's not what I think of when I see those 3 letters. <davexunit>I'm no good at figuring out windows build issues, but a windows build with threads and jit would be great <spk121>janneke figures out the 64-bit problem for guile 2.2 on mingw, but, his patch doesn't apply directly to 3.0, since the VM has changed a bit <davexunit>hmm... <redefinable-class> throws away custom slot init args. <davexunit>it uses the slot args to make a new slot with #:virtual allocation, but it only copies over the standard args. my understanding is that slots should be able to accept arbitrary initargs that metaclasses can use to do custom things. <Sheilong>The datatype of my hash's key is string. But I am getting an error right here <Sheilong>In procedure string-downcase: Wrong type argument in position 1 (expecting string): #\esc <Sheilong>I can't access hashtable elements with single char, it only accepts strings. Is there a way to threat chars as strings? ***dongcarl5 is now known as dongcarl
***Ekho- is now known as Ekho
***aweinsto1k is now known as aweinstock
<dadinn>Is there a way to check a binary is available from Guile using `system`? <dadinn>I am currently using calling (system "which" bin) and checking the result, but I assume there is a more reliable/efficient way to do this without relying on external binaries <spk121>mostly no. It is early in Europe <spk121>I couldn't think of a clever answer to your question <dadinn>spk121: I am in Europe too... early riser it seems, couldn't sleep because this question kept bugging me ;) <dadinn>spk121: I am looking at `execlp` but I am not sure how it really works <dadinn>when using it from REPL, if the executable exists, then it quits from the REPL... if it doesn't then it throws an error, and goes into debug :/ <dadinn>I am using it with no arguments to the executable, like: (execlp "lsblk") <spk121>dadinn: if you want to spawn a new process, you use API like fork, system, or popen. execlp and friends replace the current process with something new. If you want to use execlp and don't want to replace your current process, you do a fork then an exec <spk121>I'd stick with 'system' and 'which'. It is not so bad. Otherwise you could (system "/usr/bin/guile --version"), or you could check if the file exists using 'stat' and friends <dadinn>spk121: stat would be ok, but i need the PATH lookup done via execvp system call :/ <dadinn>spk121: also `which` is not available on some Linux distros <dadinn>spk121: hmm, it seems maybe I should be using (system* "command" "-v" myexecutable) instead of "which" <dadinn>spk121: actually just realised that `which` itself is a just another shell script, at least on Debian! :O <leoprikler>yep, one can implement path lookup pretty easily in a scripting language as well <dadinn>(system* "command" "-v" "lsblk") returns an error saying "In execvp of command: No such file or directory" <dadinn>weird because outside the guile REPL the that works :/ <dadinn>khm, `which command` obviously doesn't work... `type command` says it's a shell built-in! Fuckin shit! <dadinn>of course `type type` is a shell built-in too! <dadinn>spk121: how do I do this fork+execlp thingy? <spk121>dadinn: yes, but, are you trying to actually launch the program? or do you just want to know where it is? <dadinn>spk121: I am just trying to know where it is, or maybe even the fact that it exists, and I could run it with system* <spk121>dadinn: then I'd just go with something like in the paste I did above. Fork/exec is for actually running something <leoprikler>dadinn: if it's a shell built-in, then system* probably won't work, because it's a thin fork/exec wrapper <dadinn>Ahh... when you have this feeling that something is fundamentally wrong with the universe! :( <dadinn>spk121: I will look into the fold solution, it actually might be what I am looking for <leoprikler>I think gash might have command or type, but at that point you're bundling a full shell with your application :) ***rlb` is now known as rlb
<rlb>dadinn: if you just care about finding a file in a path, then there's search-path, but if you want to find the executable that system would run, then yeah, perhaps command -v, which is posix, but you'll have to run it via sh, e.g.: <rlb> (use-modules ((ice-9 popen) #:select (open-pipe*))) <rlb> (use-modules ((ice-9 rdelim) #:select (read-line))) <rlb> (display (read-line (open-pipe* OPEN_READ "sh" "-c" "command -v guile"))) <rlb>Of course you may also want more error handling, close-pipe, etc. *rlb thinks we might want to add a posix compatible string escaping function if we don't already have one. <dadinn>how do I test for an executable file? stat:perms returns 493 for something which should be 755 AFAIK <spk121>dadinn: you have to think of the number as octal. #o755 <spk121>probably the last remaining use of octal numbers, hehe <dadinn>is there a way to convert decimal to octal? :P <dadinn>spk121: actually if the decimal is odd, then the octal will be odd too :/ <spk121>dadinn: true. the executable bit is (logtest 493 #b01000000) <spk121>wait, i need two more zeros #b100000000 <dadinn>spk121: actually I think I would rather need to use (access? "/usr/bin/lsblk" X_OK) <dadinn>spk121: wait, it's almost morning! :D <spk121>shit, 23:30. I've gotta get up in 7 hour <wingo>then we would be responsible for allocation <wingo>would take a bit of time tho <wingo>me and terpri worked on somethign similar in firefox a while back <civodul>would be nice to have a workaround in the meantime, but i've run out of ideas <wingo>mini-gmp supports the nails api afair so there is no risk there <wingo>probably we should switch off the install-allocators thing <civodul>we can't do it in an extension though <wingo>i know it's suboptimal but at least it doesn't bugger your gmp <civodul>i'm afraid it could have a terrible performance impact for things like the compiler <wingo>i'll do a make -j4 with no prebuilt go files ***apteryx is now known as Guest14305
***apteryx_ is now known as apteryx
*davexunit sends mail to guile-user <davexunit>can't tell if I found a goops bug or the problem is me <RhodiumToad>btw I was looking at your metaclass question from yesterday <RhodiumToad>one issue seems to be that the docs are flat wrong about some of the functions <davexunit>I hope what I've found is just a bug in redefinable classes and not a shortcoming of GOOPS itself <davexunit>redefinable classes were introduced in 3, iirc <davexunit>used to be that all classes were redefinable <davexunit>but for performance reasons <class> no longer has that functionality <davexunit>which makes sense, because it's an additional layer of indirection. <davexunit>I have a developer mode flag in my project. when it's set I use <redefinable-class> as the metaclass, otherwise I use <class>. <RhodiumToad>I must say that looking at problems like this makes me miss ephemerons <mdevos>Am I missing something, or does guile not have an equivalent to openat(2)? <davexunit>my problems yesterday were compounded by this redefinable class issue. once I used <class> instead I was able to get a working implementation of what I was after. <davexunit>RhodiumToad: I'm not familiar with ephemerons. I use weak hashes often, though. <RhodiumToad>mdevos: afaik it doesn't have any of the *at() functions in the posix module <RhodiumToad>davexunit: the distinction between a weak hash and an ephemeron is that in an ephemeron, the key is only considered reachable if it can be reached without going through its own value. <mdevos>RhodiumToad: I should use the FFI mechanism then, I presume? <RhodiumToad>mdevos: if you want to use those functions, that would probably be the simplest way, yes <RhodiumToad>davexunit: obviously the snag is that this requires a bit more assistance from the GC than a simple key-weak hash <RhodiumToad>using them lets you associate arbitrary properties with objects without having to worry about creating reference loops <RhodiumToad>I've used them quite a bit in lua (>= 5.2), and find it frustrating when other languages have key-weak hashes but not ephemerons :-) <davexunit>oh lua has them? that's cool. didn't expect such a minimalist language to have something like that. <leoprikler>doesn't guile have completely weak hashes though? <RhodiumToad>an ephemeron differs from a both-weak hash in that the value references are strong as long as the key is reachable <RhodiumToad>and it differs from a key-weak hash in that the key is not considered referenced if all of its references come through its own value <mwette>wingo: Is converting lightning to lightening simple or not simple (e.g., for riscv)? I'm toying with the idea of buying a riscv box. <wingo>mmm, i would not say it is simple. or at least it takes a bit of time. lightning tends to be really macro-heavy and i really tried to get away for that in lightening, which results in quite some refactors <wingo>i can't find a link but you can do "git log" on the other architectures to see what kinds of things need to be done <wingo>would be nice to have a riscv backend <wingo>civodul: i got a thing for you <wingo>will need the dlopen shim from cygwin <wingo>the docs diff is hard to read because of some reorganizations <wingo>another question -- libffi. not strictly necessary for platforms with lightening support. could be implemented directly by JIT code generation <wingo>i wonder if that is worthwhile. *davexunit sent bad example code to guile-user <davexunit>my confidence grows that this is a goops bug <wingo>rlb: sure why not. feel free to commit to guile <rlb>wingo: oh, ok - thanks. <wingo>davexunit: yeah that looks about right <davexunit>wingo: from a design pov: slots are intended to be extendable with new options, right? <civodul>wingo: neat! so there's removing ltdl, and there's also providing new facilities like 'foreign-library-function', right? <civodul>i think the two can be considered independently of one another <civodul>code meant to work with 2.x/3.0 and 3.2 will keep using dynamic-link/dynamic-func i guess <civodul>but anyway, it looks like a good move to me! <davexunit>what would be the path towards getting a patch merged? submit it to guile-devel? I did copyright assignment paper work years ago. *rlb tries the current excise-ltdl <rlb>Is readline expected to work now? <rlb>...I suspect there's history I don't know about, but regarding the recent autotools concerns (the broader discussion), and given that I've observed that languages like python and guile have to figure a lot of that stuff out for themselves anyway, I've wondered if one "nicer" arrangement might be just having a guile (or "guile-core") based tool that could handle configuration in most cases. (Naive, I'm sure...) <civodul>davexunit: prolly; i guess rlb is one of the persons paying the most attention to guile-devel :-) *rlb has likely been more useful lately, but still somewhat intermittent. <davexunit>civodul: I don't know who would be the "owner" of goops that would know if my patch is good or bad. I don't want to send it to a black hole. <civodul>davexunit: as for most things, it's probably wingo <rlb>(I think guile-devel is the right place, but I'm (personally) definitely not a goops internals expert yet.) <rlb>wingo: can verify that excise-ltdl gets further here now (i.e. readline works, and all the tests pass). <davexunit>okay I'll send the patch over to guile-devel <rlb>davexunit: and/or file a bug if it seems that's appropriate now? <Sheilong>Is there a builtin argmax procedure? I have a list with some numbers such that I need to get the index of the biggest one <rlb>(apply max numbers), or do you need more than that? <RhodiumToad>hm, you want the position of the biggest one, not the biggest value? <rlb>oh, oops, didn't read that right. <tohoyn>wingo: are you going to merge the patch fixing #45131 and the patch improving statprof to upstream? <Sheilong>that's right, I need the position, the index in which the biggest happen in the list <RhodiumToad>finding positions of things in lists does rather suggest that maybe it shouldn't have been a list <RhodiumToad>if there are equal largest values, do you care which one you get? <rlb>Sheilong: yeah, haven't thought of anything built-in that's quite right offhand, but could of course use a loop, or fold, or reduce, etc. <RhodiumToad>doing it with a fold or reduce looks like it would require consing on each step <RhodiumToad>in order to keep track of both the current and largest-value index <mwette>(let loop ((mxv -1) (mxi -1) (ix -1) (ls my-list)) (if (null? l) mxi (if (> (car l) mxv) (loop (car l) (1+ ix) (1+ ix) (cdr ls)) (loop mxv mxi (1+ ix) (cdr ls))))) <rlb>In clojure it might be something like <rlb> (second (max-key first (map-indexed #(vec %&) numbers))) <rlb>with "lots of 'consing'" :) <davexunit>bug filed. I guess guile-user just ended up being my rubber duck. sorry for the noise there. <rlb>got that backward... <rlb>lokke@(lokke user)> (first (apply max-key second (map-indexed #(vec %&) '(5 1 7 2)))) <tohoyn>here is a simple implementation for vectors: (let ((res-ind 0)) (do ((i 1 (+ i 1))) ((>= i len)) (if (>= (vector-ref v i) (vector-ref v res-ind)) (set! res-ind i)))) <tohoyn>tohoyn: (vector-ref v res-ind) could be cached in order to improve performance <rlb>wingo: testing the current excise-ltdl after a make install to a random dir (~/opt/guile-ltdl) and augmenting PATH PKG_CONFIG_PATH and ACLOCAL_PATH, I see "guile" crash: <rlb>In ice-9/boot-9.scm: <rlb> 2103:25 0 (in-vicinity #f "guile-readline") <rlb>ice-9/boot-9.scm:2103:25: In procedure in-vicinity: <rlb>In procedure string-length: Wrong type argument in position 1 (expecting string): #f <rlb>Have you tested installed trees yet? i.e. should I expect that to work, or might that still be pending? *rlb double-checks his path settings... <rlb>These were the settings: <rlb>export PATH="$prefix/bin:$PATH" <rlb>export PKG_CONFIG_PATH="$prefix/lib/pkgconfig${PKG_CONFIG_PATH:+:$PKG_CONFIG_PATH}" <rlb>export ACLOCAL_PATH="$prefix/share/aclocal${ACLOCAL_PATH:+:$ACLOCAL_PATH}" <rlb>I *think* that's all you normally need for current guile. ***Aurora_iz_kosmos is now known as Aurora_v_kosmose
<mwette>wingo: sent (untested) riscv patch to guile-devel <Noisytoot>nalaginrut: Why does GNU Artanis's Dockerfile use the non-free repository? <wingo>rlb: fixed that excise-ltdl issue <rlb>wingo: readline works fine now, though I hit that statprof asyncs error again -- will test it against lokke next (later this weekend). <dadinn>can someone please help me understand how the chroot procedure works? <dadinn>It doesn't have an executable argument to execute once chrooted :/ <mdevos>dadinn: chroot changes the root procedure in the *current process*, IIUC <mdevos>you could of course combine it with fork and exec <dadinn>mdevos: so to "exit" the chroot I would have to change back to the original working directory? <dadinn>mdevos: ... I mean, with another chroot call? <mdevos>dadinn: I think so, presuming the original working directory was also the original root / <mdevos>working directory = $PWD, which is often not /. In my case, $PWD is often $HOME <dadinn>mdevos: ah, yes you are right, that's what I meant <mdevos>dadinn: idk if stashing away the old root directory in a file descriptor, to be chrooted back into, is supported. <mdevos>According to the manual, chroot accepts an argument PATH. That doesn't seem like it allows file descriptors <dadinn>mdevos: wait a moment, that would mean that chrooting from / to /mnt/blabla ... then I wouldn't have a way to chroot back to the original / because from /mnt/blala there is no path to refer to the original / <mdevos>dadinn: but perhaps it's possible to play tricks with the /proc filesystem? See open(2) <dadinn>mdevos: ah, I see what you mean, holding a reference with a file descriptor, I could revert back to the original / <dadinn>mdevos: you have mentioned the fork & exec maneuver, i've heard about it couple of times yesterday... how would this look like? Do you happen to have an example maybe? <mdevos>dadinn: I don't have an example. If you're looking for examples in the wild, you could look at guix and shepherd's source code <dadinn>particularily I am replacing the debian-setup shell scripts with a guile implementation, and actually quite happy about it so far... the shell scripts were doing ellaborate shit with chrooting in-and-out... looks much simpler with guile! <dsmith-work>Yeah, one of the purposes of chroot is to keep a process in it's own little bubble univere. <dadinn>hmm, not sure i get that primitive-fork vs call-with-cc example :/ <dadinn>dsmith-work: as mentioned before, in my debian-setup shell script inside the bubble universe have to communicate back to the main process, which is done with ugly FINISH scripts... nasty ugly but kinda worked <dsmith-work>I think the orignal use (what I ever used it for) was for booting from some initial boot filesystem and then chrooting to the "real" root filsystem. <dadinn>dsmith-work: my use-case is that set up a root filesystem using ZFS, bootstrap Debian on it, then chroot into the directory and install the kernel modules and configure grub from inside, then come out, and unmount everything and reboot <dadinn>mdevos: do you happen to have any material on primitive forks?