IRC channel logs


back to list of logs

***sajith is now known as Guest32735
<paroneayea>speaking of conversations of today
<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
<wingo>morning civodul
<civodul>moin wingo!
<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
<civodul>to be continued!
<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?
<civodul>oh right
<civodul>well i forgot
<civodul>already, getting old ;-)
<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>apparently it is the same
<wingo>that's good i guess :)
<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
<wingo>sound good to you civodul ?
<wingo>ACTION does a distcheck
<ArneBab>wingo: I just sent the mail with the script where the while loop fails with 2.1.7 but not with 2.0
<ArneBab>(couldn’t finish it earlier)
<wingo>cool tx
<wingo>civodul: i have an error about store names embedded in the tarball
<wingo>in build-aux/
<wingo>what's that about?
<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
<wingo>that is terrible :)
<civodul>kindof :-)
<civodul>the header should definitely be correct in the first place
<civodul>ISTR there's a fix for that in core-updates
<wingo>ah i see
<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?
<wingo>my guix is from a month ago
<civodul>but is this file present?
<wingo>texinfo 6.3
<civodul>i mean texinfo.tex must be in $srcdir/build-aux
<wingo>yes it is there
<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
<wingo>I just copy it in??? i guess it's automake doing the copying
<wingo>so weird
<civodul>maybe "automake -a" does that, who knows :-)
<civodul>but at worst copy it from texinfo
<wingo>so weird :)
<wingo>patching build-aux stuff feels like the bad old days
<wingo>oh well
<wingo>bah, doesn't work
<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>ok, i've never used @verb
<civodul>i thought "perf report -g" would allow me to see whether GC is most often invoked from
<civodul>but it didn't :-/
<wingo>civodul: how about looking for "run_before_gc_hook" ?
<wingo>ACTION kicks off his 6th distcheck
<wingo>and again!
<ArneBab>I feel with you …
<wingo>oh yay it worked this time
<wingo>ok uploading, should be there shortly
<wingo>ACTION lunch
<wingo>greets spk121
<spk121>wingo: good UTC+8 morning
<wingo>v early there :)
<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>spk121: is it new?
<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>finalizers slow down GC in general
<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.
<civodul>yeah, hard to tell
<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>ACTION nod
<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>wow :)
<civodul>we may be making progress ;-)
<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>sorta but not exclusively
<civodul>ok :-)
<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
<civodul>but yeah, i see what you mean
<wingo>dunno, making new threads inherit dynamic states
<wingo>so yeah.
<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 email, I think
<ArneBab>the release notes in guile-devel are already pretty good, by the way
<wingo>good to hear
<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 ())))))
<janneke>hoping to be fully self-hosting rsn
<jmd>How do I append an item to an array?
<jmd>(yes I have read the manual)
<OrangeShark>jmd, aren't arrays fixed size?
<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
<jmd>lloda: ok. Thanks.
<civodul>janneke: sounds like good news!
<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
<lloda> it requires master, at least 2.1.6 or something like that
<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!
<dsmith>Hey Hi Howdy, Guilers!
<daviid>hello *
<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.
<amz3>what's the purpose of this page
<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
<spk121>amz3: good luck
<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?
<spk121>daviid: sure
<daviid>ok, then try this
<daviid>git clone git://; then the make danse... install
<daviid>add .config/guildhall/config.scm file with these lines
<daviid>(repository shift-reset "")
<daviid>(destination shift-reset (fhs "/opt"))
<daviid>you may change the destination above for your taste of course
<daviid>then 'guild help'
<daviid>guild list-packages
<daviid>guild install
<daviid>guild reinstall ... and so on
<daviid>david@capac:~ 13 $ guild list-packages
<daviid>i dorodango-support 0
<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
<spk121>daviid: thanks for the info
<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>anyway, back to hack
<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
<daviid>* among the best guilers
<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
<amz3>I will think about it
<amz3>I posted an update on HN, about my work on the frontend side
<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>I stand on the former
<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>I disagree on that
<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>yeah I know
<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
<amz3>anyway, I am tired
<amz3>good night
<daviid>good night
<spk121>amz3: good night.