<lloda>amz3: did you fix that issue 'I assume the 0xffffffff is the negative number, but (array-ref integer 0) returns a postive number' <amz3>lloda: I tried to setup a s64vector and use s64vector-ref but it did not change anything <lloda>yeah, that should give exactly the same result as array-ref. The bytevector->pointer call looks ok, would you show the C side? <amz3>the thing is that there is various implementation of this method, but they should all look the same <lloda>I assume the bytevector->pointer is int * exact? int is typically 4 bytes, so s32 not s64. Should use int32_t / int64_t in these cases <amz3>the library only works on 64bit machine, doesn't that force int * exact to be 64bit? <amz3>I do not support other architecture yet <lloda>no, at least on Linux int is still 32 bits even on amd64 <lloda>you'd need long int to get 64 bit int <lloda>you can check on the Scheme side with (import (system foreign)) (sizeof int), which will be 4 <lloda>it's better all around to just use int32_t / int64_t, really :-/ <civodul>wingo: i'll try a Gnulib update the way Paul Eggert suggested, if that's fine with you <lloda>amz3: try your example with s32 instead of s64 <wingo>i already did the mktime one if it was that <wingo>--conditional-dependencies or whatever <amz3>lloda: I'll try, but not right now. Thanks for the feedback <civodul>so the commit that removed unistr also does the mktime thing, right? <wingo>with --conditional-dependencies <wingo>it was just the problem with libunistring 0.9.3 <wingo>which i think seems to be fine <wingo>yeah gnulib updates are somewhat inscrutable; i should log those a bit better i guess <civodul>that's fine, it's just that i wasn't fully operational yet ;-) <wingo>so i think we can release if we want to <civodul>yes, i'm rebuilding things here to see <wingo>once we are more or less convinced that it builds on the major platforms we can do it, we can always roll a 2.0.13 directly afterwards <wingo>there are some pending bugs still of course but we have to move forward somehow... <wingo>i don't know what to make of eli / mark_weaver 's mingw thing tho <civodul>i think we should commit it because we had agreed to do so earlier <civodul>though maybe we shouldn't leave the noops for setuid/setgid <wingo>we can remove that from the patch <wingo>too bad this isn't in gnulib <wingo>though i guess the fork/exec thing is pretty hard to get into gnulib, dunno <civodul>trying to see if i messed with something, but nothing obvious so far <wingo>you have GUILE_LOAD_COMPILED_PATH set <wingo>and the early boot is seeing that your .go files are older than the .scm files in your checkout <wingo>i thought i patched that out <wingo>so that when we build, we clobber GUILE_LOAD_COMPILED_PATH instead of extending it <civodul>well it's not complaining about older .scm files <wingo>i think it's complaining about the .go file that it finds in your guix-profile or whatever <wingo>anyway, my point is that it shouldn't be finding such a thing <wingo>or is the problem that your module/ice-9/boot-9.go is old? <wingo>i guess we should exhibit a not-so-bad error message there <civodul>ah yes, it's trying to display "source file newer than compiled file" but segfaulting because it's not fully initialized yet <wingo>so which file is it finding? :) <wingo>if it is in the GUILE_LOAD_COMPILED_PATH then that is a bug that we are looking in GUILE_LOAD_COMPILED_PATH; if it is in module/ then i guess we need to change the code somehow <civodul>it's stating boot-9.{scm,go} from builddir <civodul>and since i did "make -C libguile", boot-9.go may be stale <civodul>but libguile is built before 'module' anyway <wingo>in master, the current warning port is just a fluid <wingo>i don't know why we didn't make it just a normal fluid in 2.0 <civodul>if i remove boot-9.go from $builddir, then it looks for it in $GUILE_LOAD_COMPILED_PATH, which is not good <wingo>you might need to ./config.status meta/build-env <wingo>once you do that, run "meta/build-env env" and check that GUILE_LOAD_COMPILED_PATH doesn't point outside the builddir/srcdir <civodul>yes, that part is fine; i was wrongfully checking with meta/guile, which uses uninstalled-env <civodul>using 'simple-format' instead of 'format' in 'load-in-vicinity' isn't enough <civodul>"make clean -C module" works around the problem <wingo>civodul: AFAIU this is a problem but not a release blocker because the problem only occurs when you have stale .go files; wdyt? <civodul>wingo: in a sense yes, but it looks like a regression, no? <wingo>it was you who wanted the feature :P <wingo>it is certainly a regression tho <civodul>you mean the feature of skipping invalid .go files, right? <civodul>wingo: so, what about posting a tarball somewhere to get more feedback, and then release it in a couple of days if nothing goes wrong? <wingo>that is fine with me. i am also fine with releasing right now and then following up with another release if needed. <civodul>well either way is fine, i'm happy you made all this work <civodul>can you take care of the release process? <wingo>heh, i checked out after 2.0.something, most of the real work was yours and mark's and other folks's :) <wingo>civodul: from your pov, what needs to happen before 2.2.0 ? <wingo>what would it take to use it in guix? <civodul>this is twofold: providing a 2.2 variant of the packages that depend on Guile, and then building Guix with it, and then using 2.2 for derivations <civodul>the first part should be easy now that invalid .go files are skipped <civodul>and the rest should not cause problems either, AFAICS <amz3>lloda: indeed s32vector procedure work as expected, thanks again! ***amz31 is now known as amz3
<lloda>wingo: civodul: I'd like to merge my branch lloda-array-support before 2.2, a review would be great :) <wingo>i might have time this afternoon <wingo>lloda: would you mind sending a batch of patches from that branch to the list? there are some that should be squashed, some that can apply directly, and the c99 one probably needs separate discussion; i would apply that after the next prerelease and also possibly change all of our scm_t_uint8 and related api types to just alias c99 types, etc... <wingo>anyway what i mean to say is that c99 is a larger topic :) <lloda>wingo: I can work on squashing, can I rely on C99 for the other patches? so my patches would be on top of the C99 one, in whatever form it takes? <lloda>also do you agree on adding the new functions array-from/array-amend!/array-for-each-cell, that's my primary concern. <lloda>I've been thinking for a while that the whole array type and library needs to be moved to Scheme, so those implementations will eventually be replaced <wingo>lloda: array-from / array-amend! sound fine though i find the names odd, i have some nits about their implementations which we will discuss over mail <wingo>haven't looked at array-for-each-cell yet <wingo>but i want to figure out how to make array functions work better in scheme. <lloda`>wingo: so you don't like macros eh ;-) <lloda`>the name 'from' is in Iverson's 'A Dictionary of APL', 'amend' is from J. I think those are good sources, and in the tradition of things like iota. But I don't mind having other names. <lloda`>I did propose generalizing array-ref and array-set!, but mark_weaver didn't like the idea <lloda`>so for the implementation of the array type, everything about it (and the array handle) is opaque even from C, so we could replace everything by Scheme and no one will notice. <lloda`>The only think that matters is that the storage is preserved, and that is not in the array but in the root vectors, so we're good. ***masoudd is now known as msdd
<dsmith-work>wingo: No problems building v2.1.3-65-g867316f on 64bit for me <sapientech>hi everyone, recently been using chicken since it has a module i wanted to try out. i was impressed by their package installer, and was wondering what guiles default package manager is? <sapientech>ive been using guildhall, which seems pretty solid, but there aren't a ton of packages <ijp>guildhall is on life support, and no-one comes to visit <wingo>yeah we keep saying 'guix' these days <wingo>but it's a strange answer in many ways <ijp>the external daemon being the biggest one <wingo>i guess, yeah, though for a developer it's not a huge problem i guess <davexunit>I'd say the bigger "problem" is that it's GNU/Linux only <ijp>davexunit: I don't see it being easy to get people to do all the setup needed for guix just for guile <wingo>i think guix can make great containers / vms / binary installs <wingo>there is some work to do but i don't see any barrier between guix and binary distribution, dunno <wingo>i wish we had a nice answer to this problem <paroneayea>wingo: nix works on OSX through a series of hacks <sapientech>ijp: i think guildhall is pretty sweet as a simple developer focused manager apart from guix, id be down to help add more packages if the guile group thinks its something they want <ijp>if you have packages I'll add them, but I'm not really excited by it any more <paroneayea>in theory it would be possible to run guix on osx, right? but it couldn't make use of the same substitutes that are built for /gnu/store/ <sapientech>ijp: in theory, if one wanted to use wak-foof-loop, could we add it to guix? <sapientech>ijp: or is there a reason why only having it in guildhall is better? <ijp>I'm hardly an expert here. rotty wrote it, wingo ported it, I just tried to get people to use it <rotty>sapientech: isn't this kinda the same topic as with e.g. Haskell's cabal vs. the Debian repository? <ijp>oh wow, he's still alive <sapientech>rotty: sounds like it would, but i am not familiar with that topic <rotty>if so, I'd guess the best approach is to make the "importing" of upstream (guildhall in this case) packes into guix as seamless as possible, so importing a guildhall package into guix is a no-brainer <rotty>i'm not familiar how the Haskell Debian team works, but from what I gathered from some soundbites, it seems they have pretty much automated the process. <sapientech>so if im hearing you correctly, guildhall will be more of a developer's space, working with bleeding edge versions, and then we would have a easy way to add stable packages to guix? <paroneayea>guix supports bleeding edge pretty well too though ;) <paroneayea>ACTION has plenty of packages running from bleeding edge git as dependencies with some "guix environment" based hacking environments <amz3`>actually searching is not a solved problem in hyper, I was foolish! <amz3`>I had a look at whoosh, and only whoosh since the definitive answer might be in the hand of java lucene <amz3`>and there is much I can do to improve search <amz3`>but the good thing is that all my wiredtiger test pass again :) <rotty>sapientech: i think there is an important feature distros add which is in part orthogonal (or detrimental) to being bleeding-edge: having a set of packages that work well together, and on/or on quite a few architectures. <rotty>in general, i'd expect packages from a distro to have gone through an additional QA cycle, even if a not very comprensive one <rotty>(depending on distro, maintainer, current phase of the moon...)