<wingo>civodul: regarding EBADF: the intention is fport_close is called at most once. it shouldn't be possible for it to close a bad file descriptor <wingo>there were some changes in 2.2 to ensure this, at least from guile's side <wingo>civodul: so i am thinking that in your case, you extracted the file descriptor and somehow caused it to be closed outside of the port <wingo>EBADF is a bad error because it is the nicer of two possibilities: <wingo>it means the file descriptor was not reused. but it could have been, and in that case fport_close would be closing some random file descriptor <wingo>civodul: does this make any sense? i would imagine your bug is hard to repro in a small test case but i'm interested in any case <civodul>wingo: i think there are 2 issues: one is the incompatibility with previous Guile versions, and another one is whether the previous behavior made sense <wingo>i was thinking that the previous ignore-ebadf behavior was because previous guile had a bug where the close function could be called multiple times. <civodul>basically you pass an open fd to gzopen, and zlib eventually closes it for you (whether you like it or not ;-)) <wingo>ah yes :) in that case i would use "dup" to create a new fd for zlib to use <civodul>it's not clear that it's a bug, it just means 'close-port' is idempotent <wingo>i think (guix zlib) was simply buggy. <wingo>the reason being, any other thread could have opened another file after zlib closed its file <wingo>and then that would mean that closing the file port would close that third party's fd. <civodul>i think that zlib closes FDs on your behalf is not great <wingo>it's not a problem if you give it a fresh fd, no? <civodul>but (guix zlib) explicitly relied on the fact that close-port is idempotent, there's even a comment ;-) <civodul>it's not entirely clear to me that this is the right move for close-port in general, though <wingo>fport_close will be called at most once <wingo>close-port can be called multiple times <civodul>so you'd get EBADF only when the fd was closed behind your back <wingo>tx for walking through it with me :) <civodul>ok, let me see what i can do in (guix zlib) :-) <wingo>civodul: hey question for you, or for other wizards <wingo>you know prebuilt has prebuilt binaries <wingo>and the idea was to make symlinks for other architectures <wingo>in the end what i am doing is making a symlink for 32-bit-big-endian etc <wingo>anyway that dir contains prebuilt .go files for three concrete architectures and three generic symlinks pointing to them <wingo>the symlinks were not getting disted before; doh <wingo>now i added them to EXTRA_DIST but extracting the tarball creates real directories. <wingo>however the tarball itself isn't proportionally larger <wingo>is this a problem? is there a way to make sure that the extracted tarball has symlinks too? <wingo>humm i guess the links end up in the tarball, that's fine i guess <wingo>seems automake arranges to add the --dereference (h) argument to tar <wingo>so it effectively puts hard links into the tarball, and extracts copies <civodul>wingo: the tarball should preserve the symlinks so no problem <lloda>I have random failures of FAIL: gc.test: gc: after-gc-hook gets called <lloda>have had them for a while now <wingo>lloda: weird. not really sure what the deal is <lloda>it's all I have :-/ it doesn't mean much to me. I just repeated it and it passed. Really seems random. <wingo>ACTION starts a guix guile-next build for that prerel <webshinra>scm_from_uint64(reinterpret_cast<uint64_t> (this)) <webshinra>^ the only way I found to pass a pointer to scheme :D <wingo>in c++ yeah :/ someone should write a nice thin c++ wrapper for libguile <peterbrett_work>wingo: It's definitely something that I would like to have for gEDA development <wingo>maybe with guile 2.2 someone will do it :) <webshinra>(or if we get enough money so I could put one of my subordinate on it as a side project :P) <ArneBab_>wingo: I get a configure error on solaris: checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t <ArneBab_>on SunOS imksunth5 5.11 oi_151a7 i86pc i386 i86pc <ArneBab_>wingo: I still get the (string #<eof>) error with 2.2 <ArneBab_>on illumos hipster the socklen_t test succeeds <webshinra>amz3`: «Openspace Simulator: a french simulator»; it will be a strategy videogame in the spirit of «theme hospital» where you should exploit people to satisfy shareholders <webshinra>(the title being a pastiche for «german's simulators» where your supposed to «play to work») <civodul>after changing the name from "guile-next" to "guile" <spk121>Good (UTC-7) morning Guile. Last night I hacked a master Guile on Cygwin that ran test-suite without crashing. I'm rather pleased. <spk121>probably will end up being 4 more patches <davexunit>I hope to one day be able to make windows builds of games written in guile. <wingo>after changing guile-next to guile! neat :) <wingo>ArneBab_: i think you might have a stale .go file somewhere <civodul>wingo: that gives me differences in the 2nd round in srfi/srfi-18.go, weird <davexunit>civodul: odd, guile 2.1.8 built for me and was reproducible <civodul>davexunit: yeah, sometimes it's scheduling-sensitive <wingo>it does seem like the linker makes some gensyms for section names <wingo>maybe that gensym just goes away tho <wingo>ACTION was just doing a grep for gensym <wingo>that would seem to be module-gensym from psyntax <civodul>that seems to happen in stuff related to define-record-type <wingo>civodul: guix pack is nice :) one thing, i couldn't -S /opt/guile-2.2.0= but I could -S /opt/guile-2.2.0=/ <wingo>23 MB for the closure in xz format, i reckon that's all right <wingo>wingo@wingonode:/$ /opt/guile-2.2.0/bin/guile <wingo>guile: warning: failed to install locale <wingo>warning: failed to install locale: Invalid argument <wingo>Copyright (C) 1995-2017 Free Software Foundation, Inc. <wingo>on the other, the guix locale issue <civodul>but since when Guile complains about locales? <wingo>guile 2.2 installs the locale by default <civodul>right, but the warning itself, that's just at the REPL maybe? <wingo>it's in libguile/guile.c i think <wingo>in 2.0 as well i think, just that should_install_locale() in 2.0 is false by default <civodul>so we could add glibc-utf8-locale to the tarball, or something smaller <civodul>but then we still need to set GUIX_LOCPATH somehow :-/ <wingo>this is for making a binary release; do all interesting targets have lzip? <wingo>just extract in /. it adds to /gnu/store and makes /opt/guile-2.2.0 symlink into the store, that's all <wingo>civodul: is it a problem if you add a file to the store on a guix system and don't add it to the db? <wingo>like later if you build that file on guix, will it conflict? <civodul>wingo: anything not in the ValidPaths table of the DB is considered invalid <efraim>building guile-2.2.0 on aarch64 now <wingo>civodul: so if you gc'd, they would go away. cool <civodul>wingo: re lzip, i think it's ok to rely on it, it's relatively widespread now and it's portable <wingo>it does better than xz too which is pleasing <efraim>lzip isn't included by default in guix's unpack phase <civodul>efraim: right, we should change that <wingo>i guess i will start migrating the manual on the web site then <civodul>make sure to use the latest gendocs.sh from Gnulib <wingo>civodul: regarding the locale stuff, i guess we should just include glibc-utf8-locales and tell users to set GUIX_LOCPATH if the locale thing bothers them. would have been nice to fall back to some well-known locale support but oh well. <wingo>i think first i need to move 2.0 docs away <wingo>which will take a little time <wingo>aaah this is so cool, i can make binary releases of guile+fibers <wingo>i think my goal would be to have everything already written and just do the ftp.gnu.org upload, fire off the release mails, and commit to the web site tomorrow morning <wingo>maybe i blog too. yall should too of course :) <wingo>hopefully with this docs thing i won't have to touch cvs very much tomorrow :P <wingo>ACTION currently in a long "cvs commit" to update docs <dsmith-work>wingo: What's the windows support like for symlinks in tarballs? <dsmith-work>I've heard rumors that ntfs does suport something like a symlink. <wingo>anyway, just prepping things for tomorrow. <wingo>the old "development series" link was to 2.2 <wingo>so to my mind it should be either 2.4 or 3.0 <wingo>ecraven: did the benchmark run complete? :) <wingo>does it take a while to update? <wingo>i still see the 2016-12-01 date <civodul>Guile 3.0, Phoronix should pick this :-) <ecraven>my fault, I stopped using branch gh-pages, but still pushed to it <[df]_>racket didn't finish any tests? <wingo>and i reckon the gc bug that was just fixed relates to the guile timeout in ctak <paroneayea>should maybe we/I email someone at LWN about it? <wingo>indeed! maybe you can pitch an article, if that's your thing :) <wingo>otherwise they'll pick up the release note in any case, i imagine <wingo>probably not lucky enough to get a feature article, but who knows <paroneayea>feature highlights? dsmith-work and I wrote some up yesterday, are we missing anything? <paroneayea><dsmith-work> So what's the major changes in 2.2? Register VM instead of stack VM. Go files are now elf. What else? <paroneayea><paroneayea> dsmith-work: goops rewrite from C -> Scheme <paroneayea><paroneayea> dsmith-work: some types were unboxed (floats, ???) <paroneayea>(I guess bipt's elisp stuff probably isn't landing in 2.2.0... maybe 2.2.1? :)) <wingo>i think some of bipt's old elisp stuff is there but yeah, need to land the new stuff <ArneBab_>in many of the tests by ecraven, Guile is now in-between the really fast schemes and the medium speed schemes \\o/ <paroneayea>** Complete Emacs-compatible Elisp implementation <paroneayea>Thanks to the work of BT Templeton, Guile's Elisp implementation is now fully Emacs-compatible, implementing all of Elisp's features and quirks in the same way as the editor we know and love. <paroneayea>was the previous stuff also fully emacs-compatible? I thought that was only true in the newer branch that emacs was actually able to run with it <dsmith-work>ecraven: Would be nice if the different implementations could be grouped by: interpreted, native, vm <dsmith-work>ecraven: But I should say up front you have done an incredible job putting all that together. Well done. <wingo>paroneayea: there was a previous batch of work that landed there <wingo>ecraven: yeah, really cool stuff. i like playing the ecraven-benchmarks game :) <wingo>^ release notes for web site <wingo>i find the goops rewrite not so compelling a feature, thinking about non-guilers but that's just me perhaps <wingo>i don't know if i can link to fibers from gnu.org since it's on github <paroneayea>wingo: hm. you can at least mention that the asynchronous programming facilities are available <wingo>paroneayea: i did with the "lightweight threading libraries" i think <wingo>maybe a link is OK, i think github works fine with librejs <civodul>perhaps in the last paragraph you could add that many(?) Guile libraries and tools are already available for 2.2 <civodul>wingo: FWIW i get the srfi-18.go difference even when building "entirely" (after rm -rf prebuilt) <davexunit>wingo: heh, this shows that there's a bug in haunt. <civodul>not a release-critical bug though :-) <davexunit>rather than expecting one tag to enclose them all, I should just keep calling xml->sxml until eof <davexunit>wingo: "<div> <!-- needed to placate Haunt's 'html-reader' -->" <civodul>davexunit: the bug might be in the sxml stuff i wrote though <wingo>i just copy that from previous entries <wingo>also civodul wdyt about that release note for gnu.org? <civodul>wingo: should we publish a Docker image in addition to the binary tarball? <civodul>(i'm thinking of ftp.gnu.org, not DockerHub) <dsmith-work>wingo: v2.1.8-12-gda9dee0 failed make check for me. Looking to see where... <civodul>dsmith-work: you can ignore this one :-) <wingo>civodul: yeah that would be great! i don't have a means of testing docker tho <wingo>unless guix has it already of course <wingo>actually i guess i have some servers with docker... anyway yeah <wingo>civodul: regarding 2.2.0 -- should we upload it already? would Hydra have time to build it? <wingo>if not, no big deal, i don't plan on revving the tarball <civodul>wingo: Guix has Docker support in 'guix archive -f docker' currently <civodul>the plan is to move it to 'guix pack', which could happen real soon <civodul>wingo: so you'd send the announcement tomorrow noon CET? <wingo>civodul: yeah i was referring to the "running docker image" side of things <wingo>anyway yeah tomorrow noon CET sounds good to me <akkad>is ice-9 the package manager for guile? <akkad>and can guile deliver standalone bins? <OrangeShark>akkad: ice-9 is just a collection of guile modules that comes with guile <wingo>guile can't deliver standalone binaries right now. <wingo>also what OrangeShark said is right too :) <taylan>wingo: concretely speaking, what prevents the utfX->string patch from getting applied? <wingo>taylan: i am busy with the release is one factor :) <wingo>the other is that i feel like we should be able to set the encoding e.g. in the utf16 case to one of utf-16be or utf16-le if the endianness is specified, or utf-16 if not, and rely on the code in ports to DTRT <wingo>if we can avoid two places in guile that do BOMs, then i want that. so we need to look for that solution if it exists <ecraven>dsmith-work: the entire presentation could use a lot of love ;-) if I ever find a bit of time, I'll work on it some more <paroneayea>> In April 1981, ARPA called a "Lisp Community Meeting", in which the implementation groups got together to discuss the future of Lisp. ARPA sponsored a lot of AI research, and their goal was to see what could be done to stem the tide of an increasingly diverse set of Lisp dialects in its research community. <paroneayea>> The day before the ARPA meeting, part of the Interlisp community got together to discuss how to present a situation of a healthy Interlisp community on a variety of machines. The idea was to push the view of a standard language (Interlisp) and a standard environment existing on an ever-increasing number of different types of computers. <paroneayea>> The day of the meeting, the Interlisp community successfully presented themselves as a coherent group with one goal and mission. <paroneayea>> The MacLisp-descended groups came off in a way that can be best demonstrated with an anecdote. Each group stood up and presented where they were heading and why. Some questions arose about the ill-defined direction of the MacLisp community in contrast to the Interlisp community. Scott Fahlman said, "the MacLisp community is not in a state of chaos. It consists of four welldefined groups going in four well-defined directions." There <paroneayea> was a moment's pause for the laughter to subside [Steele, 1982]. <paroneayea>... at the time, InterLisp and MacLisp were kind of the two big lisps, but each was fractured in many ways ***dje_ is now known as xdje
<paroneayea>(after this, work began to start standardizing the fractured maclisps, and that's how Common Lisp happened) <paroneayea>> "the MacLisp community is not in a state of chaos. It consists of four well-defined groups going in four well-defined directions." There was a moment's pause for the laughter to subside. <taylan>heh. sounds better than the RnRS situation to me :P <paroneayea>also reminds me of trying to coordinate federation standards :P <taylan>wingo: oh, feel free to neglect until 2.2 is out ^^ regarding the other, I guess this works to reuse existing BOM handling: (get-string-all (transcoded-port (open-bytevector-input-port bv) (make-transcoder (utf-16-codec)))). not sure if there's a simpler way. <amz3>I had brillant idea, I will write my own scheme interpreter:) <amz3>I was saying that as joke, but now you say it, maybe there is an interest we writing a tiny toy scheme interpreter to understand how things are implemented <wingo>you might be interested in ice-9/eval.scm :) <OrangeShark>amz3: wrote it in Java, using ANTLR for parsing, and just creating a AST and interpreting it. <amz3>the only similar thing I did, was using Python and ply library a tiny c interpreter & compiler at the same time <OrangeShark>a lot of scheme and lisp books tend to have a chapter on writing one <amz3>ACTION read no (scheme) book <amz3>I did not even start SICP <amz3>eval.scm seems so alien to me right now <paroneayea>amz3: You'll like SICP's treatment of writing an interpreter in lisp <paroneayea>because they modify the interpreter to do various experiments <paroneayea>including dynamic scope, and even a prolog / minikanren like language layer <paroneayea>amz3: and i know you're interested in the latter <taylan>is there a way to set the default endianness of a textual port with a utf-16 or utf-32 transcoder? <amz3>I am trying to learn minikaren by hearth even if I don't understand some procedures <paroneayea>amz3: I recommend both going through the SICP book and watching the SICP video lectures concurrently <amz3>I don't do videos... at least nowdays <paroneayea>ok! well, you don't have to, but I found them helpful <OrangeShark>amz3: yeah, I think you would like the interpreter chapter as well in SICP <amz3>I will try to read it tomorrow while in the transports <paroneayea>I'm only going to go into a small fraction of it in my talk <taylan>I also think core language plus optional modules is a good idea, don't really understand why people oppose it. (that said, I've had major issues with individual modules (and the lack of some) that are on the path to become R7RS-large, but that's another topic) <paroneayea>I think it's a good idea, that in many ways is hard because it is happening so "late in the game" for many schemes <amz3>so what's the solution? abandon standardization work? <paroneayea>well, I'm not sure how many rnrs things are needed, but I do think standards are both important, but forever warty <paroneayea>my gosh the common lisp section of this book is so full of juicy history I just want to quote the whole thing <paroneayea>also interesting, after the section about "The Critique of Common Lisp" <paroneayea>> This theme reappeared in the history of Common Lisp--the emergence of a number of "unCommon" Lisps, straining, perhaps, the tolerance of even the most twisted lovers of overused puns. Each unCommon Lisp proclaimed its better approaches to some of the shortcomings of Common Lisp. <paroneayea>> Examples of Lisp dialects that officially or unofficially declare themselves "unCommon Lisps" are Lisp370, Scheme, EuLisp, and muLisp. This is clearly an attempt to distance themselves from the perceived shortcomings of Common Lisp, but, less clearly, their use of this term attests to the apparent and real strength of Common Lisp as the primary Lisp dialect. To define a Lisp as standing in contrast to another dialect is to admit the <paroneayea> supremacy of that other dialect. (Imagine Ford advertising the Mustang as "the unCorvette".) <paroneayea>> More than any other single phenomenon, this behavior demonstrates one of the key ingredients of Lisp diversification: extreme--almost juvenile--rivalry between dialect groups. <wingo>taylan: re default endianness, "utf-16be" vs "utf-16" <amz3>> rivalry between dialect groups. <paroneayea>personally, I think if you're using a lisp day to day, you're pretty lucky :) <paroneayea>eg the lisp-1 vs lisp-2 war, while I have opinions on it, hey, if i'm still writing in a lisp, it doesn't bother me so much. At least it's lisp! <amz3>I read an interesting thing about on "indie web camp" community, where they basically say, if you don't build something that is useful for you, don't do it. Also they write code first and then standardize. <amz3>I tend to think similarly, somewhat.So, IMO, rnrs happens as long as some people are interested to debate what a scheme SHOULD be, and then implementers can build whatever they want <paroneayea>"implementers can build whatever they want"... yes, but if you are hoping for interop <paroneayea>you do have to kind of sit down and make sure you're speaking the same thing <paroneayea>and the indieweb people do shoot for interop, just more late in the game :) <void_pointer>Yeah, interop gets hard quickly. Have some code I wanted to make sure would work on Guile, Vicare, and Chicken and it was bloody hard and involved a few hacks since not all followed the standards exactly in certain places. <amz3>yes, they nevertheless shoot for interop <amz3>right now, I use both biwascheme and guile and interop happens over the network <paroneayea>too late, and convincing people to break their own old decisions will be a tough battle <amz3>basically they are different programs. But they participate the same software. Picking biwascheme was easy once i knew guile <paroneayea>"interop over the network through message passing" is always an option, but then you're agreeing on a different standard... the syntax and ontology of the messages :) <void_pointer>Haven't tried biwascheme yet. Might look into it when I got some other things finished. <amz3>void_pointer: it's slow :( <taylan>wingo: what I need is "heed the BOM if present, otherwise fall back to <given endianness>" <void_pointer>Not an issue. I am aiming to make sure my code works on as many implementations as possible. It is easiest for those that follow R6RS or R7RS-small to the letter <amz3>void_pointer: what is your code doing? <void_pointer>Unit testing code. You've seen it before, actually, back in November/December <amz3>void_pointer: TAP thing? <void_pointer>SRFI-64 replacement. I still have some major work to do to actually make it a convincing replacement <amz3>void_pointer: I have question for you! <paroneayea>void_pointer: oh! are you the one who sent the r7rs scheme edition thing? :) <amz3>void_pointer: I what I meant to say, is that if a procedure does throw instead of returning it should be marked as failed <void_pointer>every single parameter for a test case is evaluated inside guard essentially <void_pointer>That is what I did, unless it is expected to throw an exception but that is a different test circumstance <amz3>void_pointer: does it, differenciate ERROR from FAIL? <amz3>as in ERROR is an unexpected failure, whereas FAIL is an "assert" failing <void_pointer>paraneayea: yeah, I wanted the r7rs libraries pretty badly, whether or not I had the r7rs syntax. They are straightforward to build form the r6rs libraries except for a few procedures and guile shored up a few of those so I set out from there. Figured might break the r7rs problem into pieces basically. Libraries are the easiest part, so a scheme newbie like me can make progress on that. Syntax stuff is much harder, so I didn't att <void_pointer>amz3: remembering the best I can, on the normal test cases, it marks ones that threw exceptions as FAILs but then in the details for the test case says that an exception did happen and it tries to extract as much information as can be done about it <paroneayea>void_pointer: cool, well your efforts are appreciated <void_pointer>for the test macro looking for an expected error, if it is thrown it is a PASS and if it isn't or a different one is thrown that is a FAIL (which one happened is given in the details) <paroneayea>mainly I want to see Show (formerly fmt) and irregex nicely supported in Guile <void_pointer>Honestly, most of the libraries were just selectively importing the right stuff from the right modules and occassionally renaming. Only had to write a few functions from scratch and most of the other ones were just wrappers around Guile or r6rs ones that worked a bit differently. Spent a lot of time with both standards documents open and the guile manual and tinkering <void_pointer>Just a lot of time and reading the documentation closely. Not much programming skill required. <void_pointer>Suspect the versions of the libraries in the r7rs-wip branch are better <void_pointer>Though, I might have written more complete documentation (or perhaps not) <void_pointer>A few parts were ugly. Bytevector output ports. If they had been implemented in Guile like string ports were from the SRFI, it would have been easy (that is what r7rs does), but they were done the r6rs way which made things hard <void_pointer>No builtin procedure to read the output, just the reading thunk provided by the creating procedure. <void_pointer>Don't care if none of what I wrote gets included. It started a discussion and maybe helped get the ball rolling after 2.2.0 is done, which matters a lot more for everyone. <civodul>wingo: so BTW yes, if you upload now, we can update the Guix package and get hydra to build it <void_pointer>Will be curious to see how r7rs-large turns out in the end. Heard a lot of people worrying. <void_pointer>Honestly, with it being modular the way it is, if it gets screwed up, there can always be an r8rs to come up with replacement modules. <void_pointer>Making a few mistakes in r7rs-large might make a better r8rs than if r7rs-large was too conservative <paroneayea>The Revised, Revised, Revised, Revised, Revised, Revised, Revised, Revised, Report on Scheme <void_pointer>Look at CPython for example. So many libraries in the CPython implementation have come, been replaced, and gone <paroneayea>well, we're not at the point where it's most efficient to number in hex yet at least <void_pointer>If there are a lot of libraries in r7rs-large, even if they are not the best choices, it will lead to more codes out there that are compatible with multiple implementations and targetted at many different ones which will in turn will get things figured out and inform r8rs <void_pointer>The SRFIs have done this to a great extent based on how much discussion in r6rs and r7rs was about which SRFIs to include, which ones not to, which ones to change, which ones inspired pieces, etc. <void_pointer>Unless I am greatly misunderstanding Scheme history (likely since I only started last September) <amz3>void_pointer: much better than me, tx for the summary <void_pointer>amz3: I looked at biwascheme. Very interesting. Definitely going to remember that one. Sadly, I won't be able to get my unit testing library to run on it since it doesn't have syntax-rules and trying to go to defmacro would be a really big undertaking. <void_pointer>A javascript based scheme might be useful sometime. Actually have an idea for its use already, especially if it supports slib. Was needing a good way to basically have a web page that has some code where the user sets some things up interactively and it generates a PDF of it formatted exactly the right way for them to keep. Would prefer not to learn javascript and woudl rather not do server-side scripting so as to avoid security p <void_pointer>Sorry about the messy commit logs. First GNU project I've contributed to and I've spent too many years as a lone-wolf programmer (yeah, this leads to a lot of bad practices I am working to unlearn). <wingo>i am not the best either, i usually just try to follow what civodul does <wingo>hoo, my dsl upload is slowwww <void_pointer>wingo: by the way, I will clean up the r7rs library patch I submitted earlier some time next week. Not sure if any of it is useful, but I can at least make it cleaner and easier to figure out its utility or lack thereof <paroneayea>would be nicer to have something like guile -> WASM <wingo>void_pointer: no rush; for review purposes i would like to go module-at-a-time i think if that's possible; i guess we'd start with "leaf" modules <wingo>i know there have been other efforts in this area and that's cool but ultimately what we need is a bit of follow-through, however it is that that happens <wingo>paroneayea: yeah i was thinking about that. i can't remember if wasm does tail calls <wingo>if it does, then that's great; we could compile guile without resumable delimited continuations <wingo>of course wasm includes no gc at this point :P <wingo>but i guess that's a separate issue <wingo>civodul: the xz and gz are there, putting the lz too <paroneayea>wingo: if it doesn't, couldn't that be handled through a trampoline? <wingo>ack, lz upload failed due to a premature C-c, that will come tomorrow <wingo>paroneayea: yes but that means overhead on every function <void_pointer>wingo: that sounds like a good idea going module by module with the leaves. <paroneayea>> Some types of control flow (especially irreducible and indirect) cannot be expressed with maximum efficiency in WebAssembly without patterned output by the relooper and jump-threading optimizations in the engine. Target uses for more expressive control flow are: <void_pointer>paroneayea: I had heard about that one a bit earlier. Wondering if there are others, ones that have syntax-rules <paroneayea>> Functional language support, where guaranteed tail call optimization is expected for correctness and performance. <paroneayea>void_pointer: ah, biwa doesn't have syntax-rules? too bad <void_pointer>paroneayea: mostly just looking for more scheme implementations to test a module I wrote on once I get the module polished up a bit more. Got it working on Guile, Chicken, and Vicare which is enough for now. Shouldn't sink more into porting it further till the actual features are improved a bit <void_pointer>on wasm not having a gc, someone will surely port Boehm-Demers-Weiser GC to it at some point <paroneayea>wingo: another argument for porting to wasm, even with an inefficient trampoline approach, is it might give us more credentials to argue *for* TCO in WASM <wingo>these are complicated committee things <paroneayea>ACTION goes back to reading about lisp standards history ;) <wingo>people have already ported bdw-gc to asm.js <wingo>absolutely bonkers and apparently it works fine <void_pointer>a lot of it depends just on how much wasm resembles a traditional processor whether it would be easy or not <void_pointer>reading up on it, it has linear memory so porting bdw-gc to wasm wouldn't be as ugly as it could be, though depending on the virtualization it could get really nasty <wingo>civodul: regarding the guix pack, i would like to upload one <wingo>or rather i would like for one to be uploaded ;) <wingo>do you think ftp.gnu.org is the right place? <wingo>i was thinking just "guix pack -C lzip -S /opt/guile-2.2.0=/ guile-next glibc-utf8-locales" <civodul>or "guile@2.2" instead of "guile-next" if you rename it <civodul>i guess "guile-binary-2.2.0.tar.gz" or something like that <dsmith-work>Sorry for the off-topic question, but what is the name the service on freenode to list a subset of channels? <wingo>civodul: guile-binary-x86_64-2.2.0.tar.gz ? <wingo>i guess my question is, is the cpu sufficient <madsy>dsmith-work: It is /list, though I don't remember the parameters <wingo>i guess having "pack" in the name is nice, or "guix-pack" or something <wingo>i like the idea that a guix pack is like a flatpak :) <wingo>but maybe that's too premature <civodul>yeah having "pack" in the name is fine too <wingo>ok i upload as guile-2.2.0-pack-x86_64-pc-linux-gnu.tar.xz if that is ok ? <wingo>at least that way it sorts well too <madsy>dsmith-work: Seems like the list service is named "alis" <civodul>wingo: or you can remove "-pc", but otherwise perfect! :-) <wingo>civodul: if i rename guile-next to guile in the package name will that make it rebuild? :) <paroneayea>sorry, I gotta stop dropping quotes from this book/paper in here, but one more <paroneayea>· In a stupidly valiant effort, Gabriel tries to approach the Scheme community about merging, but they back away real fast. Clinger is one of the few who is sympathetic to the idea, but the combination of him and Gabriel is not enough. About this time, the Scheme community starts denying that Scheme is a dialect of Lisp, claiming closer bonds to Algol. <paroneayea>· Gabriel and Pitman, with the aid of Clinger and Sussman/Abelson, produce a report detailing the technical issues involved in macros and 1-lisps. There is a thesis by Kohlbecker [Kohlbecker, 1986b] that offers hope, and several alternatives are considered in the paper. This paper is published in LASC [Gabriel, 1988]. The idea for merging dies. <wingo>paroneayea: wasn't it you who expressed abhorrence at the idea of taking more racket things? :) <wingo>or of some future in which we were the same even <paroneayea>so a) initially scheme did not have macros or a macro facility officially, and b) I wonder if lisp-1 and lisp-2 could have been mended if hygenic macros in scheme were understood at this point and c) I wonder if this is why sometimes people call scheme as if it were not a lisp (though clearly in SICP, it's called lisp) <paroneayea>wingo: ah, hm! I think davexunit and I both said some things; davexunit said something like "if guile is built on racket what's the point of having invested myself in guile all this time" or something (sorry, putting words in mouth) <wingo>civodul: given that store names don't matter much i would upload my guile-next+glibc-utf8-locales patch; but if you prefer and you have a build for package=guile, would you like to upload? <paroneayea>and I think I expressed that it could be interesting, but I didn't want to lose the mutable toplevel for live hacking <wingo>so, just have those thoughts in mind when thinking of historic lisp splits :) <civodul>wingo: i think it's ok even if the store name is "guile-next" <paroneayea>though the conversation moved from there towards "maybe the goal is that racket should choose Guile instead of Chez for its underlying VM" <paroneayea>wingo: oh yes, I'm having those things in mind for sure :) <wingo>-r--r--r-- 1 wingo users 22816220 Mar 15 23:33 guile-2.2.0-pack-x86_64-linux-gnu.tar.lz <wingo>^ that's what i'm looking at uploading <paroneayea>wingo: I have sympathy both towards efforts to standardize, and why it's hard to convince people to give up things <wingo>oddly it doesn't actually need the "gnu" part as it includes gnu in the tarball <paroneayea>partly I'm finding it all so fascinating having dumped a huge part of my life now into a standards process to look at other peoples' attempts ;) <paroneayea>I'm supposed to be spending time on that *right now* <paroneayea>so conveniently, reading about it in the meta is a good escape! 
