<davexunit>I started using guile in august of 2012 I believe. <davexunit>just wanted to write a silly video game, instead I wrote a lot of guix packages and a static site generator. <paroneayea>davexunit: I just wanted to... actually it's hard to tell which thing it was that got me into Guile initially ;) <paroneayea>I think I wanted to some-vague-combination-of: a) play with a lisp that I could use for hopefully useful things b) have a lisp that could maybe export to javascript, and Guile's compiler tower appeared good for it c) use it as a language basis to write a deployment system (which later on, I gave up on writing my own because Guix was just too good of an existing foundation) <paroneayea>a) and in the mutated version of c) have paid off though! <void_pointer>I myself had done a few small dabblings in a few lisps a while ago (2012-2013). Decided I wanted to get serious on one, and scheme was the smaller language and was a lot cleaner than common lisp and I really liked recursion (don't get me wrong, I liked the common lisp and clojure I learned, but scheme seemed a better choice for getting serious) <void_pointer>And guess what, I end up spending a lot of time trying to get autotools to work for me to on guile an other scheme implementations instead of actually programming scheme <paroneayea>void_pointer: well hopefully you'll continue to contribute to guile, and less time can be spent on the autotools side :) <void_pointer>But we will see. Big issues really are time and health (kind of why I disappeared last December and didn't reappear till a couple weeks ago) <void_pointer>wingo: by the way, as an academic researcher, I will tell you that the sort of stuff you have been doing does contribute, whether or not total knowledge is increased or not (would say it is increased since each attempt at implementing an idea adds to the knowledge of it if for no other reason than providing examples) <void_pointer>on string, it is 0.2 (Guile 2.1.8) and 0.43 (Guile 2.0.14) vs. 1.71 (Chez) <void_pointer>though to be fair, on that benchmakr, the times are very small (sensitive to various things) and Chez is beaten by many implementations <akkad>guile use bytecode? or interpreted? <wleslie>I think. but normally it uses a bytecode. <akkad>so there are modules for gunzip and parsing json? <wleslie>guix must be using a gzip library, not sure what <dsmith>akkad: not built in, but available <akkad>porting a CL project to scheme. working out benchmarks to figure out what sort of speed <rlb>How does guile handle fs paths, users, groups, and other C char* data these days. i.e. does it have a way to get at the raw bytes, or does it shoehorn everything into unicode like python? <rlb> $ echo -e '\\xc3\\x28' > "$(echo -e '\\xc3\\x28')" <rlb> scheme@(guile-user)> (let ((x (opendir "."))) (readdir x) (readdir x) (readdir x)) <rlb>Assuming I read that right, and if there's not some alternate API, then I'm wondering how you'd write a solid system utility in guile now, without having to wrap all the relevant C calls yourself (say a tool like like tar/rsync, or anything that has to work with any user/group name, etc.). <rlb>Though I suppose I don't know the range for user/group names as well for paths. <wingo>rlb: there was a recent thread on this. guile decodes command line args and file names according to the locale, by default <wingo>you can use ISO-8859-1 of course as a workaround <wingo>but a good solution for invalid encodings of file names, command line args, and env vars is still missing <ArneBab>paroneayea: it could be useful to have a "strict-r7rs" mode in Guile which gives warnings whenever I use something which is not in r7rs-large (or even r7rs-small). <wingo>--r7rs will offer that i think <ArneBab>akkad: for speed, do take the time to optimize. Codes I wrote often got faster by factor 10 with help I got here. <ArneBab>does "will offer" mean I need to use the wip-r7rs branch? <ArneBab>wingo: regarding contribution to the state of human knowledge, I like to remember "Academia vs. Business": https://xkcd.com/664/ ← however Free Software is taking this apart nowadays: people actually get credit for solving hard problems <ArneBab>wingo: and the situation in academia is changing to "… oh, and do it in your free time, since your funding will run out next quarter and you still need to finish that other thing you actually get paid for." <ArneBab>and it is really cool to see what you’re building with Guile! <ArneBab>(in my opinion, the kind of communication you do in your blog is what academic communication should be like: You’re citing those you learn from, you explain what you do so others can more easily learn from you, and you provide the full implementation) <ArneBab>reproducible binary from guix … does that mean, I could do that for any other guix package, too? <ArneBab>… said: yay! congrats for the release and for the great blog post! <wingo>announcement and tag coming shortly <wingo>and yeah, you can do that for any guix package or set of packages :) <wingo>i think it's going to kill the guildhall <wingo>but it looks like a really promising deployment mechanism both for full applications and for "SDK"-like things <ArneBab>so why shouldn’t guildhall just use that? It has the advantage of autotools (upstream can run the full suite and create something which downstream can execute without needing the full suite) <wingo>ArneBab: i suspect that in the future guildhall will become just a channel or layer of packages for guix <wingo>with an automated system to add new releases to that channel <wingo>to use guildhall, you would add its packages in some way to your guix <wingo>but i expect that the guildhall tool itself goes away <ArneBab>at least most of its implementation would be obsolete <ArneBab>did it get easier to run Guix on top of another distribution? <ArneBab>(I used it for some time, but often ran into issues like updates not working or the locales not being set up) <ArneBab>ACTION is now reading guix reference manual again <wingo>humm, i don't know. i think it's just as good and bad as it was :) <wingo>but i never used "guix pull" which probably i should have been using <ArneBab>guix pull is what regularly broke for me <civodul>wingo: 6 years and 1 months no? i think 2.0.0 was released on Feb. 16th :-) <civodul>wingo: the announcement looks perfect to me <civodul>if hydra was on time, you could also include packs for i686 and armhf <wingo>ah that would be cool, but yeah, next time <wingo>ACTION pushing tag and sending mail; what the hell :) ***civodul changes topic to 'Welcome to #guile. See https://gnu.org/s/guile for more information. Guile 2.2 is out! <https://gnu.org/s/guile/news/gnu-guile-220-released.html>. This channel is logged, see <https://gnunet.org/bot/log/guile>. Bug database at <https://bugs.gnu.org/guile>.'
<civodul>i've witnessed your hacking journey over the last 6 years and i'm super impressed <civodul>i'm sure some of your work would be worth publishing in some academic conferences <civodul>you know related work pretty well in those areas you hacked on <wingo>yeah totes, i just have to make time for it! <efraim>if you help me with the command I can make a pack for aarch64 :) <wingo>efraim: cool! you doing it on the device or cross-compiled? <wingo>"guix pack -C lzip -S /opt/guile-2.2.0=/ guile-next glibc-utf8-locales" <efraim>wingo: ok, command issued, now for it to start building <wingo>if you have guile-next built, it should be pretty quick <wingo>it basically just makes a tarball and that's that <efraim>i built it before with --with-source, so it's probably going to strip out the prebuilts and start compiling from there <wingo>nice to hear that the prebuilt stuff worked tho <Grisha>I’m wondering if there is anyone with a bit of SICP reading experience <rekado_>congratulations on the 2.2.0 release! <snape>guile 2.2.0 #1 on HN, congrats :) <OrangeShark>congrats to all the guile devs :) Thanks for all the hard work. <OrangeShark>Grisha: there should be several people who have gone through SICP here. I have gone through it a bit. <rekado_>wingo: as usual, a very interesting blog post! <Grisha>OrangeShark: thanks! do you happen to remember the type-tag-based polymorphism? in the context of two parallel representations (polar vs cartesian) of complex numbers? <OrangeShark>Grisha: ya I remember that, they would create a table for a lookup <Grisha>ok, my question is quite technical <Grisha>they use a list with a single symbol as a key to that table <Grisha>and say in the footnote that it’s about multi-arg funcs <OrangeShark>yes, it cause those were functions with one arguments <Grisha>but at the same time, they tag their constructors like make-complex-* with a symbol, not a list <Grisha>ok, I see - the arguments of constructors are not tagged <Grisha>so there is no need to dispatch on their type <Grisha>but what’s the point of (put ‘make-from-real-imag ‘polar (lambda (x y) (tag (….)))? <OrangeShark>if you want to create a constructor for that. You can't really dispatch on the constructor argument because both are the same <Grisha>it’s towards the end of Alyssa’s and Ben’s (install-*-package) code <ArneBab>ecraven: what happened to racket in your benchmark? <Grisha>so the ‘polar argument in the above put expression is dummy? <OrangeShark>you can implement a constructor which takes the return type <OrangeShark>but there is no way to dispatch on a return type like the other functions <Grisha>it’s the last four lines of code before exercise 2.73 <Grisha>now this part starts making sense <Grisha>it’s just a convention that keys for n-ary ops are lists with n elements <Grisha>and for unitary ops they decided to go for length-1 lists instead of symbols <Grisha>the table lookup key for (add-complex ‘(polar r a) ‘(rectangular x y)) would be ‘(polar rectangular) <Grisha>I understand now: they new that apply-generic would build the lookup key by pulling all type tags to a list <Grisha>OrangeShark: thanks a lot, I think it makes much more sense to me now <OrangeShark>Grisha: no problem. The table is pretty generic and can be used for different things, they mention how to implement it in another chapter <Grisha>OrangeShark: I looked a bit further, but was uneasy about being not able to understand the older stuff <Grisha>I’m glad I’m going through them step by step <Grisha>OrangeShark: btw, do you say `pull smth into a list` or `pull smth to a list` as a native speaker? Already English sometimes seems a bit too confusing to me <civodul>jackdaniel: yup, it's a great day for Guile! <russruss>Hello all; congrats on the 2.2 release! I’m wondering if I can use guile yet for my use case - I’m a plug-in loaded into another process; in the past I haven’t been able to use guile because it couldn’t have multiple independent contexts. Is this still the case? <civodul>what do you mean by "independent contexts"... in this context? <russruss>hah! I guess I mean, can one process have multiple completely independent guile programs running with in it. I’m looking for something like v8::context if you’re familiar with V8. <civodul>threads can be put in "guile mode" individually <civodul>but then guile mode is for the whole thread <civodul>i'm not familira with v8 though, so i don't know how v8::context works <civodul>but i guess wingo is having a party right now ;-) <wingo>heh, catching up on other work actually ;) <Xe>is there a guile ORM for databases? <wingo>russruss: no, guile just has one heap. for better and for worse :) <wingo>obviously for worse in your use case i think <wingo>so i think in your use case maybe guile is not the thing to use. interesting tho, we haven't gotten that feature request before <russruss>haha yeah; I understand how obscure plug-ins are - I write audio applications and it’s a quite common thing there <russruss>well, congrats again! hope I can find an excuse to use guile soon :-) <Xe>wingo: does guile support UTF-8 variable names? <rlb>wingo: OK, thanks. My current 2 cents - (at a minimum, Linux) paths aren't strings, and any interpretation should be left to a layer above the lowest, or optional. i.e. (readdir #:raw t) or a lower-level readdir, or... <rlb>ACTION hit this will poking at porting bup from python 2 to 3... <rlb>Which made me go look at the current, relevant apis in guile, imagining how I wouldn't have that problem there ;> <rlb>wingo: not immediately, but might be something I'd be interested in helpingh with later, if it's still an issue, and if we can figure out what's preferred. <wingo>it is a delicate area because people have really strong opinions <wingo>but it's clear that we need to fix things somehow :) <rlb>well, if for example, someone provides dual apis, then I wonder if each camp can just ignore the other? ;> <rlb>Not entirely serious - realize it's tricky. <rlb>Though I suspect some of the people on the "must be strings" side are either not on the "must not be anything else" side, or haven't really understood all the relevant issues yet. <paroneayea>promoted the release on pump.io and t****** social networks <rlb>i.e. you have a dir full of files collected from 20 systems, and want to archive them. <rlb>But mostly: you always want a tool like tar to reliably reproduce the data. <rlb>(or at least preserve it) <rlb>(Also wonder how often people know about the effects of normalization and/or canonicalization on the underlying path byte sequences, i.e. that the path might change in a way that makes it no longer match what's in ext4, and now you can't open your file.) <wingo>rlb: yes i agree. i am wary of shoehorning everything into strings. but maybe emacs shows it can work? i do not know. <rlb>Nice! Hadn't noticed yet. Guess I know what I'll be up to soon. (Might not even have to go into experimental, since it'll be new packages.) <rlb>wingo: oh, hah, right - I wasn't even referring to the python pep-383 trick. <rlb> (by "shoehorning" earlier) <rlb>But yeah, that might work, though it means that for any tool like a fs utility, you're going to be wasting CPU/code -- even worse in guile if all the strings are utf-32 now, i.e. if you're trying to churn through 3m paths in a big fs. <wingo>there's also the emacs encode-into-invalid-utf8 truck <wingo>i think path sizes in memory is not a significant issue. syscall latency and i/o latency outweigh that significantly. <rlb>Oh, I'd assuemed that's what eamcs was doing (based on bits I've seen), and roughly what python 3's now doing via that pep. <wingo>and in guile strings are either 1-byte-per-char if all codepoints <= 255 or 4 bytes per char otherwise <wingo>i think that PEP involved reserved codepoints, no? <wingo>emacs's thing AFAIU actually makes invalid utf-8 sequences (too-long sequences) that end up evaluating to the "right" bytes <rlb>wingo: oh, right - I forgot about that - the one byte case (read it last night right before going to sleep ;>). <rlb>wingo: oh, ok - didn't mean to be too specific there, mostly just assumed emacs was shoving the bytes in the string rep reversably "somehow". And without knowing the details, I could certainly imagine that emacs' approach might be a plausible contender for guile. <wingo>yeah but string-ref etc would start to get gnarly.... that would be irritating :) but maybe ok <rlb>I suppose one of those approaches might be fine too - and as compared to a mirrored lower-level api, or a #:raw (or whatever) option, it'd be cleaner, and suppose in the common cases, you'd still end up with the same bytes in ram., i.e. "foo" would still be "foo". Also, that same trick would "just work" for other system apis like users and groups. <rlb>Though you'd also have to make sure to have some way to allow people to completely avoid normalization/canonicalization for all the important string manipulation calls. <rlb>For existing path/whatever fragments. <rlb>Otherwise, you're still stuck. <rlb>wingo: anyway thanks for the discussion. It's not an immediate concern for me, but I might try to help later. Oh, and congratulations on the release. I'll try to see about packaging it soonish, though it might be a week or two. <wingo>great, help appreciated :) & tx! <roelj>wingo: I just came here to say congratulations on the 2.2 release. <roelj>It looks like a lot of work went into it. Awesome! <dsmith-work>Hmm. Major Guile releases seem to come out just *after* a Debian freeze. <davexunit>they'll always have very out of date software unless they make some major changes to their workflow. <davexunit>I mean "doomed" very lightly. doomed to have old software, which is really not all that doomed. ;) <rlb>Hey, I'm just glad we were *finally* able to get 1.8 out, so it won't be in stretch. <rlb>i.e. so we won't ship 2.0 and 1.8 again. <rlb>I'm likely to be a lot more aggressive about 2.2 if it goes well. <rlb>I generally run testing, though -- and for those who do that, things are usually fairly recent. Not perfect, but not untenable (for me at least). <wingo>yeah i think the change to 2.2 should be much smoother than the change to 2.0 <rlb>(or something with a good bit of testing in it for my main dev system(s) -- servers may be more conservative) <wingo>besides all the debian-related factors, 2.0 and 2.2 are just much more similar than 1.8 and 2.0 <rlb>wingo: I'm just *really* happy to not have to split the doc packages anymore. <rlb>That still makes me smile. <rlb>And it's still non-trivial work for emacs. <wingo>glad we could resolve that :) <rlb>I understand both sides, and happy to do it while it remains necessary, but will be happier still if/when it's not. <paroneayea>GuixSD brings a lot of things to the table and I'm an advocate of it, but I don't think Debian is doomed in the near term at least... imperative distros will be around for a while, and Debian's community is pretty incredible and valuable! we have a lot to gain by collaborating, as reproducible builds work shows :) <dsmith-work>rlb: What happened about the doc packages? (what happend that allows you not have to split them?) <rlb>(And there's no reason Debian can't adjust if people come up with a better approach that the developers can agree on.) <rlb>In that case, Guile's doc licence changed. <paroneayea>GFDL probably isn't nonfree but it sure is complicated :) <rlb>I'd just love to see us get out of this situation, however we do it. I'm still optimistic it'll be resolved. <rlb>Though no idea how long it'll take. <paroneayea>I think debian permits GFDL without invariant sections, right? <paroneayea>I do think invariant sections are nonfree, personally. <davexunit>but the invariant sections aren't technical works <davexunit>ah what am I doing, I don't want to start a war. I shouldn't be on IRC as much as I am right now. <paroneayea>davexunit: you'll be there for my talk at LP I hope? <paroneayea>davexunit: feel free to heckle me if I get things obviously wrong ;) <davexunit>that weekend got a bit complicated because my fiance's mother is flying up to visit. <davexunit>don't want to miss seeing people I only get to see at LP <paroneayea>davexunit: well I'm glad you're making it anyway, I look forward to seeing you again :) <paroneayea>Morgan will be there too! so you can meet Morgan finally :) <davexunit>I'd love to bring Andrea along to LP but it's just not gonna work this time. <paroneayea>would be cool to meet her! she's a software dev also right? <davexunit>she just stopped in while we were having lunch to say hi while she was going to stores in the area <paroneayea>davexunit: you're correct though, less IRC, more doing things! <paroneayea>I should probably turn off the intarwebs for a bit <davexunit>apologies for the off-topic chatter, guilers! ;) <stis>hey guilers and congrats to 2.2. Amazing work! <davexunit>yeah it seems to be the first thing people ask about when guile is discussed <wingo>well, pretty good day for guile on the webs ***dje_ is now known as xdje
<paroneayea>wingo: janneke: sometimes I think to myself, "maybe I should contact Jonathan Rees and ask about the verifiable lisp stuff, and how hard it would be to get scheme48 verifiable, and then whether or not that would be a good point to start bootstrapping guile from" <paroneayea>I know vlisp (the verified lisp) started with scheme48 and its pre-scheme <davexunit>I must say I am pretty impressed by guile's performance in these benchmarks <wingo>i feel like the precise perf has a bit of variance; we'll see if it's similar in future iterations <wingo>like maybe things weren't so great in the past, yet not much changed, know what i mean? <Kooda>Just wait until we release 5.0 ;) <davexunit>well either way it seems that guile performs pretty well <wingo>Kooda: bring it on :) more seriously i think any new growth in scheme systems is good for us all <Kooda>Indeed :) 5.0 will bring us to R7RS land :) <wingo>chicken is great and eggs are wonderful <wingo>i really like the energy there <wingo>davexunit: is that because you have chickens <Kooda>It’s annoying us more than you know :Þ <wingo>i dunno, i think it's all right <davexunit>but I didn't know there were chicken people in here. don't want to offend. <Kooda>davexunit: hey no problem ;) <wingo>"guix is the guildhall that we always wanted"! <paroneayea>I think what Guile might need is not another package manager, but a "simple" non-autotools build system for just-scheme modules <Kooda>We have a new declarative system for extensions in CHICKEN 5.0, that might interest you :) ***Kooda is now known as Kooda[b]
<davexunit>wingo: I definitely agree that guix is the guildhall we've always wanted <davexunit>the practical examples with your fibers library really slam the point home, though <wingo>this "guix pack" thing is really amazing <davexunit>I haven't used it but I'm digging the UI for it <wingo>i know it's just a hack in a way, but wow. a tarball that works on any x86_64 machine. <wingo>and one that i don't have to really worry about -- it's not going to link to anything outside the store. <wingo>and not going to trample over anything on my system. <amz3>wingo: tx for getting into the conversation about guildhall <wingo>yeah, you have to extract as root in /. oh well <davexunit>wingo: yeah not being relocatable is the only real downside. <davexunit>but considering that it doesn't clash with anything else, it's not a big deal in practice. <davexunit>but someone might be scared having to extract as root. <wingo>davexunit: yeah. surely we should be able to integrate with whatever flatpak is using to do the sudo + namespaces dance <wingo>but we can do that in the future as an incremental step <wingo>(flatpak uses a helper sudo binary to manage its namespaces) <wingo>and as flatpak is being more deployed these days we should be able to take advantage of it <wingo>also docker of course, for what that's worth; we can make docker images but i find the seamlessness of guix packs to be really nice <davexunit>some systems a setuid binary wouldn't be needed because they allow unprivileged user namespaces <davexunit>but others there would need to be some solution <davexunit>I'm not up-to-date on it. haven't checked in awhile. <wingo>i mean there have been many clownshoes security bugs here in the past <wingo>k. my understanding is that the "production" thing is a privileged daemon or suid binaries. <davexunit>the issue with a setuid binary is that we'd have to distribute one <davexunit>I think the user would have to run *something* as root first to bootstrap the whole thing. <davexunit>but boy is 'guix pack' so much nicer than a stack of docker images. <davexunit>I think about all the resources that are being poured into developing specialized layering file systems to deal with the duplication issues in docker... <amz3>indeed guix pack is nice <taylan>is 'guix dock' just a new user interface for things you could previously do with 'guix archive', or is it more/different than that? <davexunit>taylan: seems to be roughly that plus a few more convenient things <janneke>paroneayea: i'm *very* close to having mes+mescc self-hosting <janneke>i.e.: mes.c: a scheme interpreter that can run a scheme program: mescc <mirage335>Trying to create an AppImage package of gEDA, which uses guile. Program does not run when the local usr/share/guile files have a timestamp newer than the system files in /usr/share/guile. <mirage335>How can I compile the local usr/share/guile files? <janneke>mescc: a scheme program that can compile a c program (mes.c) <amz3> wingo re guildhall 2.2, how do you resolve dependencies using your model? <amz3>reading a bit of SICP chapter an meta-evaluation made clearer what mes is <amz3>maybe I should answer the manifesto <amz3>I think guix pack will answer the question I have <amz3>davexunit: that's what I was thinking too <davexunit>it's a conscious design choice to not do that <amz3>I read the guix pack documentation, I already buy guix, that's not the issue <davexunit>ohhhh now I know why that guile jit is named nash <wingo>here i was thinking that hn thread was actually pretty good for not mentioning 'sonic boom' :P <davexunit>someone always says that "guile goes with everything" <wingo>amz3: say you have your package. it depends on guile, cairo, and guile-cairo from guix, and guile-present from guildhall <wingo>at the top of your package.scm, you do (use-package-modules guile cairo) or whatever it is that you need to import the definitions from guix's packages <wingo>and of course you name guile, guile-cairo, and so on in the package's dependencies <wingo>and additionally i guess you use-modules (guildhall packages) or something to give you all guildhall packages (?) <wingo>and then you depend on guildhall-guile-present <wingo>which will have been exported by the mega-module (guildhall packages) <wingo>(other solutions are possible but that's the general idea) <madsy>ArneBab: Nope, I'm not on HN :) <madsy>ArneBab: If you want to reply to them (I don't have an account), you could refer them to my github project <amz3>madsy: sorry, what's your github project? <madsy>amz3: Doesn't build Guile 2.2 though (Or I haven't tried since a year ago) <amz3>I don't use windows, i just follow guile users on github <madsy>Back then the new object binary format based on ELF was very recent and not done for Windows <janneke>paroneayea: i hope to release within 2 weeks or so. when mes is self-hosting, it's time to take a step back and think a bit about how to go forward; that's where your contact with Rees would be quite valuable <janneke>paroneayea: self-hosting is nice, but still utterly useless... it starts becoming more interesting when mescc can compile another C program, such as tinyc, gcc, guile(?) <ArneBab>madsy: do you plan to update your scripts for 2.2? <wingo>janneke: what is your goal? :) <janneke>wingo: that's the most obvious path, i think -- but i'm open to suggestions <janneke>i was just inspired by (derailed a bit?) civodul's stray remark @fosdem: "...apps that are not written in guile yet" <janneke>i could imagine that compiling (a subset of) guile could be easier than compiling gcc <amz3>I did a quick post about my work related to dynamic web pages written in scheme <paroneayea>janneke: maybe Mes could replace the "half-strap" compiler that Guile currently has as an early test <paroneayea>I don't know how C dependent that thing is though <janneke>paroneayea: i'm not aware of half-strap... <wingo>janneke: i suspect that is the right path fwiw <wingo>the tcc -> gcc -> guile path <janneke>but obviously, wingo's musings about compiling bits to native post-2.2 may have some overlap of interest <wingo>yeah, hard to tell. definitely we want to compile scheme to native code but we will still have the c interpreter for bootstrap so a c boostrap is still valuable <wingo>and i also think we will have some bits of the runtime in c for the foreseeable future too <wingo>so, a path that goes through c first makes sense to me <paroneayea>mes -> tcc -> gcc -> guile seems like a cool future :) <amz3>ACTION goes to follow his own lullaby <paroneayea>wasn't gcc going to switch to C++ at some point? <paroneayea>I wonder if that would make it hard for tcc to bootstrap gcc <civodul>paroneayea: GCC switched to C++ in 4.9 <civodul>and yes, that is bad news for bootstrapping :-/ <paroneayea>needing to bootstrap C++ to bootstrap gcc seems worrying :\\ <paroneayea>mes -> tcc -> old gcc -> new gcc -> guile -> the universe :) <amz3>this would be a perfect time for my "computability of the world dilemma" story :) <janneke>ACTION has been wondering for about 20y why the hell gcc wasn't written in c++...and now that i finally see that it's a bad idea (because of bootstrapping), now they switched...*sigh* <civodul>janneke: GCC was really written in a lispy C before that, lots of fun <paroneayea>civodul: are you saying it should have been written in common lisp instead of scheme? ;) <paroneayea>does every scheme implement a buggy and partially implamented common lisp too? ;) <janneke>scheme is for academic teaching purposes only, right? <paroneayea>oops, here I was using it for practical purposes this whole time <civodul>paroneayea: i don't know, we'd have to ask a lisp historian ;-) <paroneayea>yeah I should go back to writing my amateur hour talk :) <amz3>maybe I should go back not to doing talk at all <amz3>paroneayea: btw, tx for telling my how minikanren is significant, I made some good discoveries recently <madsy>ArneBab: If it's at all possible. I'm not updated on the current state of 2.2 <amz3>I will port minikanren to biwascheme at some point <amz3>ArneBab: it was released today or yesterday <paroneayea>which cuts down minikanren to an even smaller kernel <amz3>paroneayea: that's what I am using :) <amz3>minikanren is very big compared to microkanren <amz3>the maintainer of microkanren created a program that can guess procedures based on examples <madsy>Does guile 2.2 successfully build against x86-32? <amz3>I can't find the name of that software <civodul>madsy: i suspect nobody tried, but in theory, it should <wingo>that's the one with 64-bit registers and 32-bit pointers, right? <madsy>wingo: I don't remember which one was which :) <madsy>But I was asking due to sizeof(long) <madsy>64-bit builds of Guile will never work until gnump modifies their public api <madsy>Gah.. 64-bit guile builds for Windows <daviid>hello * congrats indeed, great time for guilers! <paroneayea>mengu: I'm pretty good! Excited about the release, and working on a talk for LibrePlanet :) <mengu>paroneayea: that's great, good luck with it <daviid>wingo: I did see your answers to my 2 goops related emails thanks, but they came at an exact time I could not even read them :(, will answer in short... ***water is now known as Guest44009
<daviid>wingo: 2 guilers/guixers sent an email to contribute to guile-lib, Alex and Matt... I did not answer because I thought you would shime in... as you are the project admin, also modules in guile-lib have been written by top notch schemers, with the idea of latter inclusion in guile... although I've helped maintaining it and released (mainly because of guile-gnome, guile-clutter using the test-auite and apicheck modules, now I also use the <daviid>test-suite for my projects) I did not feel confortable to answer whether yes or no we could add their respective contrib module(s)... what would you like (or would you like me?) to do? I think we should answer ...