<tohoyn>avp_: are you sure IP address 127.0.0.1 is correct? ***rekado_ is now known as rekado
<rekado>avp_: the problem is a wrong redirect <rekado>remove the extra /guile and it should be fine <rekado>I’ve been meaning to fix this, but there’s always something else to be done… ***apteryx_1 is now known as apteryx
<manumanumanu>apteryx: if that approach becomes a bottleneck, you could try transducers. They merge (remove (map (filter ...))) into one pass over the list, which - if the list is large - might become expensive. (list-transduce (compose (tremove string-null?) (tmap string-trim-both) (tfilter (node-typeof? '*text*))) rcons (cdr node)). It is included in guile-3 as (srfi srfi-171). <manumanumanu>the overhead is pretty small, and even on "cheap" lists of things like chars or integers it is usually beneficeal to use transducers if you have more than one step, ie: replacing (map ... (filter ....)) means faster code. Replacing a single (map ...) is not. <manumanumanu>apteryx: the caveat is that some transducers have hidden mutable state where the list tools do not, making them not multi-shot-continuation safe. Instantiating a transducer(like: ((tmap 1+) rcons) and using it over several threads is also not a good idea. As long if you are not using multi-shot continuations, or using the same transducer simultaneously over different threads you are fine, though. <wingo>eww, multi-shot continuations ;-) *wingo finally fixed blog spam issue <civodul>wingo: hey! when were you planning to release? *civodul adds a "guile-next" package to Guix <wingo>civodul: hi :) dunno, maybe two weeks? have to finalize the gmp issue, then make a sweep of patches on guile-devel, and possibly pull in mingw stuff from spk121, notably regarding dlopen <civodul>i'll try to do some testing and bug reporting/fixing by then <spk121>hey wingo, civodul: on the topic of mingw, the two other things in that mingw branch are having read-line handle CRLF and a hack to file tree walker for when inodes are useless. MinGW's a long way from feature parity, but, it would at least be capable of running the test suit w/o hanging or crashing <wingo>sounds like things that would be good to push to master! <ArneBab>wingo: do we already have a note from lilypond folks how the change affects their performance? <wingo>ArneBab: do you refer to the reader? no we do not <wingo>i don't know if they are on guile 3 tho <ArneBab>there are some who tried it, shall I ask for testing? <wingo>anyway i think it will be fine. we are within 1x of optimized C and there are some more optimizations to make <wingo>well. i mean to say if C runs at 15 MB/s we are within that order of magnitude <wingo>currently like 10 MB/s or so <wingo>but will get better over time <civodul>really nice, and probably a pretty good "C vs. JITted Guile" kind of benchmark <wingo>civodul: dunno, i think we might take different tactics to get it faster (get-chars-while, drop-chars-while) <wingo>like there are some aspects related to the optimizer and code generation, and some aspects related to being able to think of different solutions <rlb>wingo: yeah, seems plausible - I might try to follow along a bit (i.e. rewrite along similar lines) the edn reader I wrote. And I'm almost certainly going to rework it away from the string readers given your other observations. <rlb>(for now the clj reader is still just C -- worry about that later) <manumanumanu>leoprikler: I don't think the srfi-171 spec disallows visible mutable state. I experimented with it when writing the reference implementation (before standardisation), and visible mutable state was too slow in many implementations. Visible immutable state is of course also doable, but without something like C++ move semantics it becomes hideously expensive <manumanumanu>immutable, visible state without giving up much (any?) performance. Juanpe used to hang out here iirc. He also wrote Immer, the c++ persistent vector library which has a super efficient rrb-tree implementation. <civodul>manumanumanu: yeah Immer is quite impressive and it may be a case where we can't achieve the same performance without the static typing and templating machinery <wingo>civodul: apparently there has been some activity on the 1.8 branch :) <civodul>i suppose they have upload rights, too <wingo>an attempted revival of the 1.8 branch would be a bad thing for guile, that's for sure <wingo>not sure how much i care about it if it's just those patches, tho. perhaps mail ttn ? <wingo>otherwise we can revert & revoke commit rights if you feel strongly enough about it; certainly after such a long hiatus, an email would be the polite thing <civodul>wingo: did you see ttn's messages on guile-user a month ago or so? <civodul>an email sounds like the right first step, yes <civodul>well, i understand LilyPond/TeXmacs might want to update 1.8 for their own use <wingo>does lilypond still default to guile 1.8 ? <civodul>but... i feel this is no longer "Guile", or not the same Guile <wingo>funny that when we were on 1.8, ttn was on 1.4 :) <civodul>it's Conway's law: these tools use 1.8 for technical reasons, but probably also for a lack of will to cooperate <civodul>anyway, for now an email to ttn sounds right, so we at least know where we're going <wingo>i think that a new 1.8 release would be bad for the guile project. i am unhappy that ttn is pushing on the release branch without getting approval from you or me <wingo>let's assume ttn would like to work on a guile 1.8 fork. where should that happen? <wingo>in some other repo, or in a branch in guile git? <civodul>i think it's okay to use that branch on the Savannah repo <civodul>but i wouldn't want to see a 1.8 release at ftp.gnu.org & co. <civodul>so it would probably make more sense to have a separate source code hosting solution <wingo>you think it's ok to use the official release branch? i wonder <civodul>well yeah, it'd be more consistent to do everything elsewhere, i guess <wingo>right, like there are api/abi guarantees to ensure, etc <wingo>i don't think it's a branch for development or maintenance any more. only hotfixes if necessary and i don't think it is necessary <wingo>if ttn wants to open a new dev cycle, it doesn't really fit in guile plans, so i think hosting elsewhere is the right thing <civodul>it's a project, not just a code hosting site, after all :-) <wingo>and i think any release they might make would not be official. i don't see a need for one atm <wingo>so it would not be gnu guile 1.8.x. fine of course to be nongnu guile 1.8.x <wingo>& maybe some users switch to nongnu guile 1.8.x if that's useful to them. no problem there <civodul>no obligation but it'd be nice to promote it that way <civodul>(and thanks again for organizing it!) <manumanumanu>regarding texmacs, I helped someone port an old guile1.8 file to 3.0. The complete lack of phases was a fantastic mindeff: a macro expansion refering to a function that would have only been available at compile-time in anything post-2.0. "So... you ... expect this to work????" <wingo>"you can unquote function values into the macro output????" <wingo>but having the reader be on the hotpath for program startup?? ughhhh <manumanumanu>Hey, who is it that has the good implementation of srfi-64 that actually follows the spec? <manumanumanu>I am tired of having to re-implement test-runner-simple every time :( <wingo>doesn't guile follow the spec ?? <manumanumanu>test-runner-simple should not write a file. yet it does. <manumanumanu>in every scheme. Someone fixed it, but I can't remember who <manumanumanu>wingo: (test-runner-simple) is the default, and is only specified to write to stdout. It is not forbidden to write files, though <manumanumanu>The spec says the default is implementation defined, but that (test-runner-simple) should write to stdout. <manumanumanu>(test-runner-simple) writes files. In every implementation I have used, because everyone uses the reference implementation. <wingo>spk121: civodul: fixed the mini-gmp exposed to users issue i think <dsmith-work>../../guile/libguile/numbers.c:176:40: error: 'SCM_ENABLE_MINI_GMP' undeclared here (not in a function); did you mean 'SCM_SNARF_INIT'? <dsmith-work> int scm_install_gmp_memory_functions = SCM_ENABLE_MINI_GMP;