***sputny1 is now known as sputny
<mwette>mrkotfw: I ran into a dynamic-link issue like that (on Fedora?). The problem is the way libtool works. I think it is fixed in 3.0.2. Ref is https://bugs.gnu.org/21076. ***jonsger1 is now known as jonsger
***wxie1 is now known as wxie
***catonano_ is now known as catonano
***wxie1 is now known as wxie
***wxie1 is now known as wxie
***wxie1 is now known as wxie
<daviid>I pushed a series of patches to g-golf, related to a 'protect' syntax name to be used as generic function names 'mechanism', with three user (re)definable/customizable variables to alter the defaults with that respect. I also documented this as well as I could... those interested, please pull, make, read the doc and try ... <daviid>leoprikler: I have taken your suggestion into consideration, so you may prefix those (syntax names to be protected) using '@ if you wish, and set the postfix to #f ... and for those who wish an even more sophisticated and 'personal' way of protecting syntax names, they may define a renamer <leoprikler>Hmm, could the Guix recipe be outdated w.r.t. packages? <leoprikler>I'm trying to build inside "guix environment g-golf", but that results in: dynamic-link: file: "libgirepository-1.0", message: "file not found" <roelj>Can I get the return value of a command when run using ‘open-input-pipe’? <roelj>Ah nevermind, that's done using close-pipe. <leoprikler>daviid`: syntax-name->method-name is missing the case for begin != #f, but suffix = #f <leoprikler>Either require both to be symbols always or do (or [prefix|postfix] '#{}#) <roelj>I'm running a Guile program in a container (made with Guix), and it cannot seem to resolve addresses, backtracing with: (getaddrinfo "some.address" "https" 0 #<undefined> #<u?> ?). <roelj>What does Guile need to resolve addresses? <leoprikler>I'm not sure whether Guix containers are allowed to use networking <roelj>leoprikler: Well, curl works fine :) <roelj>Perhaps I omitted the most important error message poart: In procedure getaddrinfo: Servname not supported for ai_socktype <roelj>leoprikler: I make a "pack" with guix pack, and imported that in Docker, and then run it in Docker.. :/ <leoprikler>okay, (getaddrinfo "gnu.org" "https") works from environment -C -N <roelj>I don't know how this works, but should "https" be translated to a port number? <leoprikler>name service hint_flags hint_family hint_socktype hint_protocol <leoprikler>I'm pretty certain you can get getaddrinfo to work as intended in `guix pack` tarballs <roelj>Hm, so I reduced it to the following: scheme@(guile-user)> (http-get "http://gnu.org") => In procedure getaddrinfo: Servname not supported for ai_socktype <roelj>And the same error for (getaddrinfo "gnu.org" "https") <leoprikler>I believe, this might be a docker-specific issue <roelj>leoprikler: It being a docker-specific issue was a very helpful suggestion :) <roelj>Just running "ntpd" doesn't have any effect. <weinholt>roelj, symbolic service names like "https" are defined in /etc/services, you might be missing that file <roelj>weinholt: Yeah, I found that in the strace output as well, so I'm trying by including the "net-base" package in the container. <roelj>That was it -- missing /etc/services. Thanks weinholt and leoprikler! <ArneBab>Guile 3.0.4 is seriously closing in on racket, and in the gcbench even on gerbil und chez! <ArneBab>wingo: ^ I thought the results might interest you :-) <ArneBab>I also did a check of the standard deviation of the data (using 4 runs provided by ecraven), and the ranking looks mostly robust. From what I saw I would expect the rank to change by at most 1 between different runs. <ArneBab>In many tests Guile 3 already bridged the gap between the slower and the seriously fast schemes and is typically less than factor 2 slower than racket — and in some cases faster. <ArneBab>I also just compared the Guile results to the fastest implementation for each test: using the raw CSV data, the geometric mean slowdown compared to the respective fastest implementation went down from 16x slower to 6x slower. <civodul>i mean the figures are there, just not easy to look at <ArneBab>3.0 is faster on every test than 2.2 <ArneBab>and the geometric mean shows that 3.0 is twice as fast as 2.2 when you compare against the limits that can be reached on any test. <ArneBab>the slowdown above (7x): For racket it’s 5x and for chez it’s 2.6x. <ArneBab>So Guile is now only 40% slower than Racket (factor 1.4); getting closer to the goal of catching up on racket. <civodul>i have the uneducated intuition that there are low-hanging fruits in our run-time <civodul>we should investigate the benchmarks where Guile doesn't perform so well to see what the reason is <ArneBab>There are two main pain points: ctak (doesn’t actually complete on time) and equal (fails on circular datastructures) <ArneBab>the biggest slowdown is on fibc (103), ack (30), and string(29) ***dddddd__ is now known as dddddd
<ArneBab>then there are some between 13 and 6, worst first: cat wc browse tail deriv cpstak mbrot graph read1 sumfp puzzsle pnpoly <ArneBab>(I ignore two outliers where the fastest scheme is ridiculously fast (0.1 or 0.) <ArneBab>I now checked the data on the page for ack again: it’s because cyclone is crazy fast on this. Guile 3 is as fast as racket and factor 2 slower than chez. <ArneBab>so from the worst three, only string is a serious worry. <ArneBab>it’s string-length, string-append and substring. <ArneBab>Just the part for which avoiding it made string-replace-substring much faster. <ArneBab>looks like it’s in libguile/strings.c <dsmith-work>There was some recent string improvements by moving C to Schme (string-for-each I think) <ArneBab>… hm, no, the fast string-replace-substring still contains substring <ArneBab>running this with ,profile, I see 94.62% of the runtime in %after-gc-thunk <ArneBab>my most plausible guess is that it’s string-append <ArneBab>depending on memory pressure, time shifts between %after-gc-hunk and string-append <ArneBab>I tried switching to an implementation of string-append in pure scheme, but that’s much slower. Maybe one of you knows of an efficient way to do this. I used plain string->list and then (append ...) on char lists. <civodul>there's something fishy going on with %after-gc-hunk <ArneBab>the code does lots of appending of short strings <civodul>not really, i posted something to guile-user, but no solid explanation <civodul>for string-append in Scheme, you should mimick what the C code does, accessing the stringbufs directly <civodul>(system base types) has code for that, though it's not meant to be used in this way <civodul>one is for hooks written in C, the other is a C function to call hooks <civodul>so there are two naming conventions very similar <ArneBab>ah, makes sense, but looks pretty strange :-) <civodul>besides, string-append benchmarks are mostly measuring GC efficiency <civodul>so it could be that we lose just because libgc doesn't do as well as the others <civodul>however, Bigloo also uses libgc, so it's a good point of comparison <civodul>i'm not sure whether Racket still does <dsmith-work>That C code for string-append doesn't look that bad. Total up the lengths, alloc the new string, memcopy the pieces (or loop for wide chars). <civodul>my impression is that calling subrs is quite expensive <civodul>because we have to leave and then reenter the VM <civodul>though i think wingo was skeptical about this hypothesis <dsmith-work>So it's not that string-append is slow, it's calling it in a Scheme loop that' <civodul>which is "expected" in a way, because there's little more than overhead when you do that <ArneBab>why does the gc take so much time? in the gcbench Guile does really well <ArneBab>So I don’t understand why it’s so expensive here <ArneBab>I also got problems with using string-append for the string-replace-substring proc <ArneBab>IIRC removing that gave quite some speedbump