<vagrantc_>rlb: well... one issue down, but now i get some presumably non-deterministic segfaults in various test suites: https://buildd.debian.org/guile-ssh ... so far only ppc64el, s390x, riscv64 and ppc64 ... but they're segfaulting in different tests *vagrantc_ wonders if running tests in parallel could be an issue <vagrantc_>oh, apparently i run the tests in serial already... <rlb>vagrantc_: note that there's a current known issue exposed by gnutls. <rlb>not sure if it's related, hang on... <rlb>Might have nothing to do with the current issue, though. <vagrantc_>i can try to schedule a giveback, but that seems poor form :/ <rlb>I suppose if you have the time, might try to reproduce it in a loop on one of the porterboxes or similar... <fnstudio>it seems to work, as it configures/builds/install with no errors <fnstudio>however, there might be something fundamental that i'm missing <rlb>vagrantc_: since s390x is a segfault, if we can reproduce it, suppose gdb might be able to tell us something more interesting, if we're lucky... <fnstudio>at the end of the installation i see a hello.go file is save in and made available from a lib folder in my home; should i expect a `hello` binary to be also saved anywhere? <vagrantc_>wonder why they're not getting this issue on guix's guile ... <vagrantc_>oh, i guess if it's actually architecture-specific... they test on fewer architectures ... but i suspect it is more non-deterministic than architecture related ... maybe specific architectures might trigger the issue <vagrantc_>i'm going to try in a loop on x86_64 and see if i can trigger it ... <rlb>fnstudio: I don't know anything about those project setup recommendations, but no, I wouldn't think you'd end up with a binary. You'll generally run your program via a #!/.../guile script. <rlb>vagrantc_: suppose x86 does have some substantially different memory/cache/etc. behaviors from say arm64, so it may be notably different on some fronts. <fnstudio>rlb: oh i see, excellent, thanks - i'll have a look at some other project to see how this is handled when things are packaged <daviid>rlb: back to trying vagrant, I try to follow the steps you kindely pasted, quite blindingly I must say, didn't have time to look at any doc yet, here is what happens <daviid>rlb: after vagrant init debian/testing64, i edit the file but can't find any entry for vm.memory, nor vm.cpus (which were optional, but can't find them ...) <daviid>rlb: then vagrant ssh fails ==> default: Domain is not created. Please run `vagrant up` first. <daviid>i 'have' ssh the .ssh/id_rsa file exist, and the ssh daemon is running, fwiw <daviid>rlb: (or any vagrant user who would know ...) i'll read/search (not exactly now, but will do) to solve this (small) problem of course, just reporting that i prob miss some (libvirt ?) set-up here ... but in case you'd be 'here' and know the missing step(s) let me know ... <rlb>daviid: sorry, right, I forgot the vagrant up command, and it's vb.memory and vb.cpus (not vm) -- you should see a section commented out near the bottom of the Vagrantfile that includes vb.memory, and you can just add vb.cpus there too if you want to. <rlb>daviid: oh, and sorry, another assumption, I'm using virtualbox (the default vagrant provider here), i.e. "apt install vagrant virtualbox", though that might require (in debian) testing or sid -- iirc one of them might not be in stable... So I suppose it could be this is more hassle than it's worth for you, depending on your situation. <rlb>I don't know that I've ever used vagrant with libvirt/kvm/qemu -- I do use kvm/qemu/libvirt for less throwaway servers (mostly just use vagrant for testing), but in those cases, I use kvm/virsh/etc. more directly. <rlb>And if you don't have virtualbox available to vagrant, I guess that might be why you didn't see the section in the config file (didn't realize that's how it works). <fnstudio>briefly following up on my question re packaging a guile executable with the GNU Build System / Autotools, i understand i need to add a script that wraps my guile program, as it's done here for instance https://github.com/alezost/guile-daemon <fnstudio>(the project comes with a lot of useful docs and comments, by the way, very useful to understand what's going on with the different files) <fnstudio>i still need to understand how it can make it away without importing the guile.m4 file that seems to be used in all other packaging-guile-with-the-GNU-Build-System projects i've looked at <fnstudio>where it explains that, in certain circumstances, the file guile.m4 is automatically copied over from the system by aclocal <fnstudio>although that doesn't seem to apply to guile-daemon... as it doesn't make use of GUILE_FLAGS... <fnstudio>if i understand it correctly, the script above has to figure out the paths where the guile module has been installed <fnstudio>if i simply use (use-modules (my-mod)), then the script doesn't seem to be able to find the library <fnstudio>i'll go and see if i can find another simple guile program (not a library) that i can get some insight from <mwette>you'll want to look in etc/ directory <fnstudio>mwette: this is priceless, thanks so much!! <tohoyn>I have had problems with guile.m4. It does not detect the guile version correctly when both guile 2.2 and 3.0 are installed. <ATuin>Hi, I have a weird problem when creating a binding for libzip, seems to be GC related. Basicaly i create a source from a bytevector to be added later into the resulting zip. When the script is compiled first time, it works properly but when i run it a second time the output produced by that source is messed up (a mix between txt from other files and random characters) <ATuin>is there anyway to debug the GC <ATuin>if i register those bv in a hasmap before creating the source seems to work fine when running it several times so it looks for me like a GC tihng ***leoprikler_ is now known as leoprikler
<ATuin>yeah, seems to be the GC, when using a guardian on the data before adding it to the source record it works. <ATuin>why is guile not knowing that i have a reference for that bv as a field in the record <source>? <tohoyn>ATuin: are you using g-wrap for the library bindings? <ATuin>i pass a bv, i get the pointer for it and i pass it to a ffi function <ATuin>then i save the pointer returned by that function (and the bv to keep a reference to the original guile data) into record (kind of wrapper basically) <ATuin>but for some reason guile is not aware of that data and it collects the bytevector <ATuin>ttps://paste.debian.net/1185466/ <ATuin>see there the function bytevector->source <ATuin>lzip/source-buffer-create is a call to the c library <tohoyn>ATuin: g-wrap has type qualifier "aggregated" for this kind of situations <ATuin>maybe i can take a look at it <ATuin>but still why guile is not aware of the bv field in the record? <ATuin>or is just that the whole source is GC <tohoyn>ATuin: warning: I'm not sure if g-wrap is actively maintained anymore <mwette>guile allocates space for bytevectors using scm_gc_malloc_pointerless <ATuin>interesting, adding the guardian to the whole source record (the one that wraps the bytevector and the low level pointer) makes it work as well <mwette>so if the bytevector is not referenced the contents will be freed, I believe <ATuin>so i guess the whole source record is GC (and whatever is inside) <ATuin>mwette: yeah, that makes sense but i save it as a field inside the wrapper <mwette>"space for" => "space for payload" <ATuin>seems that it's the wrapper the one that is collectec then <mwette>the bytevector itself or the pointer? <ATuin>i store the bytevector itself <ATuin>and the pointer returned by the c call <ATuin>I guess the problem is that the function that adds the source to the resulting zip does not keep a reference to the source, so when the zip is closed (it's then when the sources are saved) then some data has been collected. Interesting :D <ATuin>finally I added a reference to each source added into the archive record (everytime archive-add-source! is called), seems to work as well <mwette>and you are saving the returned "source" record I guess? <ATuin>mwette: yes, the archive record keeps track now of the sources added to it <ATuin>that was the main problem, since i was doing everything in one rec funcion i was not saving the sources and they are used when the zip is closed <ATuin>once i implement replace and delete I will made the code to remove them or replace them from the hash-map <wingo>my reader seems to work?? weird <wingo>haha i was testing the wrong thing, n/m :) <wingo>interesting production in guix/scripts/lint.scm: (cons* #\\ #\"result) <wingo>ok now (ice-9 read) has the same results as C read for all scm files in my ~/src/ <wingo>soon will make sure errors are same. source locations would be a bit gnarly to get exactly the same tho