***sajith is now known as Guest32735
<paroneayea>wingo: mark_weaver: did you see this R7RS email from Freja which landed today? <paroneayea>it looks like pure scheme implementation of r7rs-small <civodul>wingo: replacing scm_inline_{cons,cell} with the non-inline variant didn't make any difference <civodul>i went as far as commenting out code that relates to freelists, to no avail <wingo>civodul: wow, that's irritating isn't it! <wingo>also i wonder why the REPL is a factor <wingo>why guile -c '(pk (length (iota #e80e6)))' doesn't show the same behavior <civodul>yeah i thought this had to do with the number of registered Scheme threads, but no <civodul>while looking at threads.c and thread_mark, i wondered if we weren't marking things twice <civodul>like the scm_t_thread is allocated in a scanned area, but then thread_mark adds it again <wingo>isn't scm_t_thread allocated with a GC kind? <wingo>well, it's slightly different in 2.0 i think <wingo>yeah hard to page everything in :) <wingo>i just don't get why bdw-gc decides to do so many collections <wingo>also we should check if we get similar behavior with GC_MARKERS=1 <wingo>ACTION does not want parallel marking bugs <wingo>civodul: i just had a bad idea and i mailed it to the list :) <wingo>in response to lloda's truncating exception print stuff <civodul>wingo: just replied in pure conservative style as usual ;-) <wingo>so i think i'll cut a new prerelease <wingo>maybe we have another one before 2.2.0, we'll see <ArneBab>wingo: I just sent the mail with the script where the while loop fails with 2.1.7 but not with 2.0 <wingo>civodul: i have an error about store names embedded in the tarball <wingo>do i need to update my guix? ugh <wingo>honestly i have no idea how to fix that <wingo>heh as it is a generated file and not in git, i can just change the header to /bin/sh <civodul>wingo: right, just change the header <civodul>the header should definitely be correct in the first place <civodul>ISTR there's a fix for that in core-updates <wingo>as long as this is a short-term thing, ok :) <wingo> /home/wingo/.guix-profile/bin/texi2dvi: tex exited with bad status, quitting. <civodul>wingo: do you have a recent build-aux/texinfo.tex? <civodul>i mean texinfo.tex must be in $srcdir/build-aux <wingo>\\def\\texinfoversion{2013-02-01.11} <wingo>it's something about something i did recently <wingo>we had bad info rendering of syntax for 'foo and `foo <wingo>the ' was being rendered as ` <wingo>so i changed to @verb{|'|} and that is making texinfo unhappy <wingo>@verb apparently just doesn't work. <wingo>i wonder why that texinfoversion is so old <civodul>yeah there's a more recent one available that you should copy to build-aux <civodul>\\def\\texinfoversion{2016-09-18.18} <wingo>I just copy it in??? i guess it's automake doing the copying <civodul>maybe "automake -a" does that, who knows :-) <wingo>patching build-aux stuff feels like the bad old days <wingo>apparently the issue is that @verb was inside a @nicode which for dvi aliases @code <wingo>and you can't have @verb inside an argument to something else. for now i just reverted the patch, will poke later <civodul>i thought "perf report -g" would allow me to see whether GC is most often invoked from <wingo>civodul: how about looking for "run_before_gc_hook" ? <wingo>ACTION kicks off his 6th distcheck <wingo>ok uploading, should be there shortly <wingo>ACTION can't remember which way is + <wingo>assuming + is generally west of from UTC :) <spk121>wingo: definitely early in the morning. <spk121>wingo: any idea what I can do about this? BOOTSTRAP GUILEC ice-9/eval.go Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind handler. <wingo>i would do a find . -name '*.go' | xargs rm <wingo>but i dunno, maybe you want to keep prebuilt/ <spk121>wingo: New things include trying out mmap loader and 64k block on Cygwin, plus regenerated psyntax-pp. <wingo>perhaps try the release tarball? if that works then a clean build should work, i would think <wingo>we need to add more prebuilt/ symlinks <spk121>That's a good idea. I'll try the tarball. <civodul>wingo: according to GC_PRINT_STATS, 2.2 (with REPL) defines a lot of finalizers, more than 2.0 <civodul>and i suspect it could partly explain our problem <civodul>GC_PRINT_STATS shows: 555 finalization-ready objects; 0/0 short/long links cleared <civodul>whereas in 2.0 it's: 0 finalization-ready objects; 0/0 short/long links cleared <wingo>you could be right but that may just be a detail. <wingo>finalizers aren't *that* slow. ~500 finalizers shouldn't cause GC to run more often. <civodul>those finalizers come to early calls to scm_make_weak_key_hash_table <wingo>you could try disabling the logic in scm_i_register_weak_gc_callback that installs the finalizer <civodul>wingo: if i comment out the body of scm_i_register_weak_gc_callback, the problem is gone <wingo>i updated the manual online too <wingo>pleased that we finally have thread-local variables <civodul>fluids are thread-local in 2.0, aren't they? <wingo>they can propagate to other threads via call-with-new-thread or with-dynamic-state <wingo>sometimes you don't want threads to inherit fluids <wingo>that's the case with the current exception handler -- the prompt associated with any exception handler is naturally thread-local <wingo>some programs similarly need thread-local database connections, etc <wingo>and of course it's nice to be able to access a thread-local knowing that you don't need a mutex to prevent concurrent access from another thread <wingo>something you can't really rely on with vanilla parameters/fluids <civodul>or you could rely on it if you don't use with-dynamic-state, i guess <wingo>dunno, making new threads inherit dynamic states <wingo>i made my peace with dynamic states :) <ArneBab>wingo: did I already send you an email with newspapers? <wingo>i meant to reply -- would you be interested in taking up that task? for myself i think i will have my hands full. obviously if anyone else wants to do it, that's great :) <wingo>if it slips us by, that's also fine of course <ArneBab>wingo: I used that list with an emacs macro via mu4e, but I fear my email is running into lots of spam filters. <ArneBab>it would have to be a @gnu.org email, I think <ArneBab>the release notes in guile-devel are already pretty good, by the way <janneke>mescc can finally compile a subset of mes.c that can run programs with cons/car/cdr/quote, like: (car (cdr (cons 9 (cons 7 (quote ()))))) <jmd>How do I append an item to an array? <jmd>(yes I have read the manual) <lloda>jmd: you can't. You have to create a new array and copy the old pieces into it. <lloda>OrangeShark: srfi-43 has vector-append, even though vectors are also fixed size <OrangeShark>lloda: true, it likely creates a new vector and copies it over? <lloda>jmd: I have a library called guile-ploy that lets you do (cat 0 arr item) or (cat 0 arr1 arr2 ...) <lloda>the 0 is for the dimension --it works for rank > 1 <lloda>OrangeShark: yes, I imagine that's what it does <janneke>civodul, wingo: thanks! been working hard and steadily towards a 0.5 release of mes, that should feature a somewhat useful C compiler in scheme together with scheme interpreter in C; much more work than i hoped and still many more hacks/rough edges than I'd like to release <janneke>i haven't looked at the r7rs-in-scheme code, that sounds real interesting too! <amz3>I've sent a massive mail to guile user mailling list <amz3>I should have created a new title like with: Primary, yet another package manager for guile <amz3>meh, I failed at my spam attempt <amz3>sorry, my mail client doesn't handle text only formatting, this is irritating! <taylan>huh, guile's utf16->string doesn't accept the third argument specified by the R6RS <taylan>the 'endianness-mandatory' argument. same with utf32->string. I wonder if it has a reason. <spk121>amz3: if I were still in startup land, I might say that your plan is not focussed on the "minimum viable product" <spk121>amz3: but there is much to admire about what you wrote <amz3>spk121: I aim for the stars :) <amz3>spk121: why do you think that in particular? <spk121>Well, first off, my humble opinions, grains of salt, yadda yadda <spk121>The problem with all attempts at previous package managers, which to be honest i never really investigated, it that they never reached "demo or die" <spk121>A webpage to list some packages. A method to download and upload them. This is all you need, and then work the problems as it becomes unworkable. <spk121>You've taken on the projects of dependency resolution, DB bindings, it is a lot. You'll burn out before other people get excited. <spk121>Also, as someone who has done a lot of non-FFI compiled bindings, really they aren't so bad. <spk121>But one this that is absolutely necessary, which you mention, is that the problem of installing a package in Guile site directories is a mess. <amz3>it's not just about changing GUILE_LOAD_PATH? <spk121>It used to be just GUILE_LOAD_PATH. Now there are three env variables. <spk121>GUILE_LOAD_COMPILED_PATH,and the extension dir as well. <amz3>unworkable, I already have the DB bindings. I use wiredtiger it's because it's much easier for me to deal with it. I don't have configuration to do. like sqlite. My website is small, benchmark show I can handle it with sqlite. but I prefer to use wiredtiger... <amz3>Yes, dependency resolution is extra! <amz3>Ok, I will just do uploading/download/installing and see how to work with GUILE_LOAD_PATH and do another mail <amz3>I will leave dependency resolution for later <daviid>ACTION thinks it would be better to fix guildhall, asking for help on the ml for the difficulties raised by the tons of macros and scheme-fu misteries it guildhalls :) <spk121>daviid: did guildhall ever reach the point where upload / download / list packages? how far did it get? <daviid>spk121: it works perfecty with 2.0 <spk121>daviid: how does one guildhall? Is it a website, a CLI? <daviid>spk121: a command line of course, it adds to the guild script <daviid>spk121: do you still have 2.0 around? <daviid>git clone git://github.com/ijp/guildhall.git; then the make danse... install <daviid>add .config/guildhall/config.scm file with these lines <daviid>(destination shift-reset (fhs "/opt")) <daviid>you may change the destination above for your taste of course <daviid>david@capac:~ 13 $ guild list-packages <daviid>i pfds 0.3 Purely Functional Data Structures <daviid>i srfi 0-2011.2.28-4 portable SRFI collection <daviid>i wak-common 0.1.1 common infrastructure for the Wak ports <daviid>i wak-fmt 0.7-2 formatting combinator library <daviid>i wak-foof-loop 0-2010.4.27-2 extensible looping library <daviid>i wak-riastreams 0-2007.6.8-2 lazy streams <daviid>i wak-syn-param 0-2010.4.27-2 operators with extended parameter syntax <daviid>i wak-trc-testing 0-2009.9.5-2 simple testing facility <daviid>spk121: the problem (appart from make it run with 2.2) is that packages must updated, presumably by the person who created the package ... debian or guix would not be wat they are if packages would not be updated when upstream releases are out ... <amz3>there is not interface yet, to submit pure guile project to guix <amz3>maybe that's what should be done? dunno <daviid>guildhall is perfect (for pure guile scheme packages, it is unable to compile C dependencies, so guile-gnome could not be there...) <amz3>my issue with guildhall, is maintenability also <daviid>so, if we want a package manager for guile, imo it must be guildhall, then guildhall must be improved so packages that depends on C libs could also ne handled, such as guile-gnome ... <amz3>daviid: I did not thing about that <daviid>amz3 i understood that, but it can be fixed <daviid>amz3 just ask for help, rewrite the foof-loop if you prefer not to use that ... but with help, you can fix it <daviid>amz3 did you at leasttried it? try the above ... <amz3>well, I did want to ask for help, that's why I created another plan <amz3>well, I did *not* want to ask for help, that's why I created another plan <daviid>amz3 the other plan is not good plan imo, sorry <daviid>the best plan is to fix guildhall then raise its capabiblities to handle project that depends on external libs <daviid>web interfac is, at this point, a total loss of time, as well as rewritting a totally new manager, yet another ... to me that is not a good route <daviid>for a user, who already knows guild, being able to use guild to list and install other guile packages is a must <spk121>daviid: But does a user know guild? I mean, I never use it for anything except when it shows up in makefiles for compiling. I can't say I've ever actually typed "guild" at a prompt. <spk121>but now I'm being another grumpy greybeard. haha. <daviid>spk121: if, as a user, you want to precompile your own module, you'll ask here, dig in the manual, the guile ml, in the end, you will know guild, try guild help ... then if, as a user, youre looking for a guile scheme package installer, you'll find guildhall, with a manual, a tutorial, which will tell it is based on guile's script guild ... there is no way out :) even grumpy greybeard will finally come to guild <daviid>amz3 we have to unify our effort and reuse others work: guildhall represent quite a lot of human resources already, and among the guilers did participate to it <daviid>amz3 it has been very carefully designed, well written... <daviid>if we had guildhall fixed an improved (tyhe external libs was a known and to be fixed 'limitation', due to human resource, not impossibilities from guildhall itrself) i would package all projects I contribute/maintain <dsmith>Yeah, there have been *many* attempts over the years to have some common central place to collect guile code. <dsmith>guild and the guidhall happened with the 2.0 release, iirc <dsmith>Lately, guix seems to be happening. <daviid>but guix is another beast, and 'per user', where as guildhall still has a niche and the instllation is per machine, or local area network, which is what I need for example <amz3>prolly! I don't know what I will do right now <spk121>dsmith: Guix also requires some agreement from the maintainers to push an update to one's own package, as does the current state of guildhall as I understand it. <spk121>dsmith: It is an old conflict between a curated collection with some barrier to entry, and chaos. I stand on the side of chaos, generally. :-) <daviid>chaos is a nightmare per definition :) <daviid>package have to be supervised, signed ... it would be just crasy to use any from anyone from anywhere... totally crasy imo <amz3>still requires thinking because it could be patched in guildhall too <daviid>sure, then you install my 'havefun' package, which grabs your hd content ans saend it to fb ... <amz3>that's how it works in Python, you download and run stuff and complain later <amz3>I should add a review system to each packages