IRC channel logs

<happy_gnu>hello :)

<happy_gnu>in emacs every time I do M-x scheme-mode or run-geiser it asks for what language guile/racket/etc..

<happy_gnu>is there a way to put a default for always guile?

<daviid>use M-x run-guile

<happy_gnu>oh you are right, scheme-mode does not have it though :/

<happy_gnu>thanks daviid :)

<daviid>welcome

<quigonjinn> happy_gnu you can also (setq geiser-active-implementations '(guile))

<quigonjinn>in your .emacs file

<ArneBab>wingo: when trying to build fibers from git, I get ./env compile -Wunbound-variable -Warity-mismatch -Wformat -o "fibers.go" "fibers.scm"

<ArneBab>./env: line 56: exec: compile: not found

<wingo>i guess it didn't detect guild somehow

<ArneBab>wingo: by the way: using the hello world fiber example I get around 1500 to 3000 connections per second with httperf (using 10 competing httperf processes)

<ArneBab>wingo: is that OK-ish performance?

<ArneBab>this is for 10 httperf competing, each trying to run 1000 connections per second.

<ArneBab>I get unexpected connection failures if I go to 100 httperfs competing.

<ArneBab>total time for 10k connections is around 8 seconds

<ArneBab>wingo: it seems so: if I add guild to the commandline it works.

<ArneBab>now I got ~4800 in 2 seconds.

<ArneBab>wingo: the build works with `make GUILE_TOOLS=guild`

<dsmith-work>Hey hey

<ArneBab>ok, I now found that httperf is saturating my CPU while trying to hammer the fiber webserver …

<ArneBab>ah, much better. I switched to wrk and it throws Guile 23k connections per second

<ArneBab>26k if it only keeps open 100 connections

<ArneBab>wingo: takeaway: guile beats httperf by factor 10, even if only using one core and httperf using 6 cores.

<ArneBab>wingo: looking at the CPU utilization of wrk and guile with fibers, guile might be able to cut even with wrk by using multiple unix threads with one fiber-servers per thread.

<ArneBab>(12% wrk vs. 80% guile)

<wingo>fibers does this i think

<wingo>if i understand what you are saying

<wingo>by default it will run a scheduler per core available to fibers

<ArneBab>ah, so with (run-server handler) it’s already utilizing multiple cores?

<ArneBab>(so it’s not just the garbage collection thread going wild — damn, clearly it’s not: that would then only go up to 50%)

<ijp>up to 70% of the way through boot-9

<ijp>or so I believe, since that's the first call to make-hook I see

<ArneBab>wingo: I see increased memory usage with lots of concurrent connections (i.e. 24MiB after wrk -c 1000 <url>) which persists as the test finishes

<wingo>ijp: nice!

<ijp>wingo: when I'm done with this, we're going to need to have a long hard talk about the vm :)

<wingo>ArneBab: in general if the heap grows it will never go down

<wingo>:)

<ArneBab>wingo: can I limit the maximum number of fibers?

<wingo>ArneBab: no

<wingo>well, you could implement some kind of wrapper for spawn-fiber

<ArneBab>for some reason I got this error earlier, but can’t reproduce it: GC Warning: Failed to expand heap by 13096808448 bytes

<rekado>ArneBab: that sounds like you ran out of memory

<rekado>(I see this when compiling Guix on i686 with 1GB memory)

<ijp>87% currently failing at (define duplicate-handlers ...) due to applicable structs

<ArneBab>rekado: yes, I did. That’s why I thought about a way to limit the memory growth.

<paroneayea>ijp: awesome work

<paroneayea>hello #guile

<cmaloney>hello paroneayea

<catonano>hi paroneayea !

<OrangeShark>hello

<paroneayea>`(,@'beep) => beep

<paroneayea>interesting :)

<paroneayea>ACTION abuses syntax

<civodul>heheh :-)

<ijp>that looks like a bug

<ijp>which reminds me, I wonder if racket ever fixed that quasiquote bug of mine. The one that affects precisely no-one who isn't a spec pedant

<paroneayea>in case you were wondering, I'm not planning on abusing it as in using it in my code ;)

<paroneayea>just abusing it at the repl :)

<paroneayea>heh :)

<paroneayea>speaking of bugs, I'm still not sure my return values optimization arity bug is worth filing or not

<paroneayea>probably not :)

<cmaloney>Just do ",L ecmascript" and be done with it. ;)

<cmaloney>planning on using this instead of node.js

<cmaloney>(note: not really)

<ijp>here we are, still unfixed, and didn't even make it to the new tracker

<ijp> http://bugs.plt-scheme.org/query/gnatsweb.pl?cmd=view%20audit-trail&database=default&pr=13984&return_url=http%3A%2F%2Fbugs.plt-scheme.org%2Fquery%2Fgnatsweb.pl%3Fdatabase%3Ddefault%3Bdebug%3D%3Bcmd%3Dsubmit%2520query%3BState%3Dany%3Bignoreclosed%3DIgnore%2520Closed%3BSynopsis%3Dquasiquote%3Bmultitext%3D%3Bcolumns%3DState%3Bcolumns%3DSynopsis%3Bcolumns%3DCategory%3Bcolumns%3DLast-Modified%3Bcolumns%3DRelease%3Bsortby%3DNumber

<cmaloney>paroneayea: Trying to understand `(,@'beep)

<paroneayea>cmaloney: so ` is quasiquote, right?

<cmaloney>Right. Not 100% familiar with that, but I can look that up

<paroneayea>`(a b c 1 2 ,(+ 1 2)) => (a b c 1 2 3)

<paroneayea>and

<paroneayea>if you want you can also use ,@ for splicing in a list

<paroneayea>eg

<paroneayea>`(a b c ,@(list 1 2 3)) => (a b c 1 2 3)

<paroneayea>as opposed to, without the @

<paroneayea>it would be

<paroneayea>`(a b c ,(list 1 2 3)) => (a b c (1 2 3))

<paroneayea>see?

<cmaloney>Got it

<cmaloney>Clever

<cmaloney>Thank you. :)

<paroneayea>np :)

<paroneayea>now you see the bug probably, since I was unsplicing a non-list

<cmaloney>unfortunately I couldn't get guile to spit out an error message for @ (said it was a meta command, which didn't seem to point me in the right direction)

<ijp>how did you discover this one? I got mine when I was writing QUASIQUOTE for myself

<cmaloney>THat doesn't seem like a bug though

<paroneayea>ijp: I ran into it because I was trying to remember what happened when you did

<paroneayea>`(foo ,@#f bar)

<paroneayea>for example if you did

<paroneayea>`(foo ,@(and=> (blah) 1+))

<paroneayea>would it only include the second one if it was non-#f?

<paroneayea>I ran into some weird hack in the past that was sort of like this

<paroneayea>ijp: btw if you enjoy such bugs

<paroneayea>you will probably enjoy this recent favorite of mine

<paroneayea> http://paste.lisp.org/display/349715

<paroneayea>it's taking advantage of two "features"

<ijp>cmaloney: per the spec "If an (unquote-splicing <expression> ...) form appears inside a <qq template>, then the <expression>s must evaluate to lists"

<paroneayea> - the fact that if we can optionally only accept one value from multi-value-return depending on the continuation's arity

<cmaloney>ijp: Ah

<paroneayea> - and that we have a let-rewriting optimization

<paroneayea>without the optimization, it would work.

<ijp>cmaloney: the reason it should be an error, IMO, is that the only reason it works is because it is coincidentally in the last position of the list. It leaks the implementation, just like my bug report to racket about `#(1 unquote 3)

<cmaloney>ijp: right. I'm starting to understand. Thank you.

<ijp>paroneayea: in this case, I'd say the optimised behaviour is right

<paroneayea>ijp: is that because you oppose guile's "extension" to multi-value-return?

<ijp>yes

<paroneayea>I figured :)

<paroneayea>common lisp also has behavior like that extension

<ijp>I'm on the record as being against that behaviour, but civodul & mark_weaver outrank me

<ijp>I forget where wingo stands, probably with them

<paroneayea>but I'd agree it isn't very "schemey" as in it seems "impure" (but it is convenient)

<paroneayea>particularly

<paroneayea>it makes the argument for multi-value return a lot easier for division operators which return both a while number and a remainder, etc

<paroneayea>whole number

<paroneayea>but

<paroneayea>it does seem less pure :)

<civodul>ijp: talking of multiple-value truncation, right?

<civodul>i think i was slightly against at the very beginning and then quickly started to enjoy it :-)

<paroneayea>personally I like using it. (but I do agree that it could cause bugs... as in the one I just demo'ed :))

<bavier`>it's slightly annoying when writing higher-level functions that you might need to worry about the passed procedure returning multiple values

<cmaloney>How is this different than returning a list?

<cmaloney>I mean, I'm sensing some strangeness... :)

<paroneayea>cmaloney: indeed python does do something *like* multi-value-return by unpacking python-lists but...

<paroneayea>you could say two thins

<paroneayea>things

<paroneayea>assuming you're the type of person who thinks in continuations, now you can think of all your continuations of being able to accept the same range of values that any other function can ;)

<paroneayea>and the other argument might even be

<paroneayea>the common lisper argument might actually be that *because* you can do multi-value-truncation, you can return several values, the first being the most important, and the rest being supplementary values of possible use

<civodul>yes, it's the dual of optional arguments

<ijp>cmaloney: incidentally, "just pass a list" is one of the arguments against multiple values

<civodul>QED

<paroneayea>cmaloney: at any rate, the bug I demonstrated could be avoided with let-values

<cmaloney>Yeah, I think I have too my Python on the brain because I see lists and immediately I think of tuples

<cmaloney>and they become the bento-box of stuff to put in there. :)

<paroneayea>ACTION finds let-values to be a very verbose structure structure though

<paroneayea>cmaloney: well multiple values here are also a bit more powerful than python's unpacking

<cmaloney>let is something I'm struggling with

<ijp>srfi 8x is much nicer than let-values

<paroneayea>in that it doesn't have to be a strict number of values returned even

<paroneayea>you could even do this :)

<paroneayea>ijp: 8x?

<paroneayea>(call-with-values

<paroneayea> (lambda ()

<paroneayea> (values 'monkey 'banana #:koopa 'troopa))

<paroneayea> (lambda* (animal fruit #:key koopa)

<dsmith-work>cmaloney: Mark did a wonderful email about values recently

<paroneayea> ...))

<ijp>my bad, it's 71

<paroneayea>;)

<paroneayea>ijp: ooh this is nice, I've never seen it before.

<daviid>fwiw, I also believe the optimizer is right, and i prefer and use receive rather then call-with-values

<paroneayea>much easier to read.

<paroneayea>daviid: the same bug would happen with receive btw

<paroneayea>well, if you think it's a bug :)

<paroneayea>and receive is nice, depending on your structure

<ijp>weirdly I went off RECEIVE a few years back, mark_weaver too I think

<cmaloney>dsmith-work: Which mailing list?

<cmaloney>I just subscribed to guile-users

<dsmith-work>cmaloney: http://lists.gnu.org/archive/html/guile-user/2017-06/msg00073.html

<dsmith-work>Explaining multiple value in terms of continuations was very enlightening to me.

<daviid>paroneayea: yes, i would never write the inner let (foo (values ...)) anyway, I was responding to 2 things in 1 sentence

<paroneayea>daviid: :)

<paroneayea>daviid: well the example *was* about the conflation of two things

<paroneayea>so no wonder :)

<daviid>receive is perfect for the job, imo

<paroneayea>dsmith-work: thanks for the link

<rekado>srfi-71 looks great… but it’s not in guile :(

<paroneayea>daviid: the place where receive falls short, in my experience

<paroneayea>is where you end up doing multiple things in a row that have multiple values

<paroneayea>then suddenly you've got a receive in a receive in a

<cmaloney>dsmith-work: Thank you.

<paroneayea>let*-values (and apparently srfi-71) handles that nicely

<daviid>yes, but same with call-with-values right?

<paroneayea>daviid: but I agree that if that's *not* the case, (receive) is good

<paroneayea>daviid: oh yeah, I don't use call-with-values often though :)

<paroneayea>I did it because it demonstrated the continuation bug more clearly here, as a continuation.

<ijp>civodul: btw, do you know where the code that calls applicable structs is?

<daviid>receive in a receive is fine, like match in a match is also fine, imo, and guile-cv extensively use match in match

<ijp>maybe apply_non_program

<paroneayea>daviid: it's "fine", in the same way that let in a let is fine

<paroneayea>but sometimes you want to use let* instead :)

<paroneayea>rekado: ah!

<paroneayea>too bad.

<paroneayea>I wonder how hard it would be to get in... it would make my life a lot easier...

<civodul>ijp: apply_non_program sounds like the right place

<ijp>paroneayea: I doubt there would be much objection

<ijp>the macro would presumably only need to parse args and spit out a let(\\*|rec)?-values

<paroneayea>> My original motivation for writing this SRFI is my unhappiness with the current state of affairs in Scheme with respect to multiple values. Multiple values are mandatory in the Revised^5 Report on the Algorithmic Language Scheme (R5RS), and they are fully available in all major Scheme implementations. Yet there is often a painful hesitation about using them.

<paroneayea>> The reason for this hesitation is that multiple values are nearly fully integrated into Scheme---but not quite. (Unlike for example in the languages Matlab, Octave, or the computer algebra system Magma, in which returning multiple values from a function is the most natural thing in the world: q, r := quo_rem(x, y);)

<paroneayea>amen

<cmaloney>Wonder ig Magma was related to Macsyma / Maxima

<paroneayea>> The major limitation of receive is that it can only handle a single expression, which means programs dealing with multiple values frequently get deeply nested. [...] Moreover, let-values suffers from "parenthesis complexity", despite Scheme programmers are tolerant to braces.

<paroneayea>yeah those are my frustrations with the existing syntax forms

<paroneayea>srfi-71 seems to fix them

<daviid>paroneayea: let's get srfi-71 in then :)

<ijp>weird, I think guile tells if a struct is a vtable by looking at the structs vtable to see if its children are vtables

<daviid>or receive*

<ijp>ditto for applicable & setter

<ijp>I suppose this makes sense when you consider that vtables are really the "type" of the struct, and if you are storing the vtable then there is no need to duplicate this info in structs themselves

<dsmith-work>ijp: I though wingo cleaned up a lot of that vtable recursivness a while ago.

<ijp>dsmith-work: this isn't really an issue of recursion, just info not where I expect it

<civodul>ijp: in JS one cannot create new disjoint types, right?

<ijp>afaik still no, since the classes they add are just sugar over the prototype stuff

<dsmith-work>ijp: Ah. And I don't remember stuff so good

<dsmith-work>Wow!. 2008! https://wingolog.org/archives/2008/04/11/allocate-memory-part-of-n

<ijp>okay, applicable-structs are there

<ijp>and boot-9 "finishes" running

<ijp>a hell of a lot of stubs need to be filled in, but it's done

<paroneayea>well

<paroneayea>ijp: wow! cool

<paroneayea>well I tried adding srfi-71 to guile but I couldn't figure out how to do the exporting in a way that didn't break things

<ijp>ah, wait, false alarm. I was tricked by an early return :(

<ijp>paroneayea: what do curried defines do?

<paroneayea>ijp: I don't know?

<ijp>I think (ice-9 curried-definitions) has a similar issue since it rebinds define & co

<paroneayea>oh

<daviid>... define procedures that return procedures, up to any desired depth

<paroneayea>there's a #:replace form

<ijp>daviid: I know what they do, I meant how did they deal with this issue

<daviid>ah ok sorry

<paroneayea>nice that worked :D

<paroneayea>yay

<paroneayea>cool I think I can submit this upstream

IRC channel logs

2017-06-29.log