<buenouanq>sneek: later tell civodul but doesn't a swap partition take care of that? <g_bor>bavier: I've also noticed that. We also had some discussion about having that phase modified. It would be desirable, if we could finally have the same permissions we started with, but modify them here if we need to write a file. <g_bor>bavier: I also think that maybe it does not worth the complexity, and a simple one-line patch that adds make-file-writeable is also good. When installed into the store the permission is revoked automatically. <OriansJ>sneek: later tell rain1 that I really appreciate their help with finding bugs in M2-Planet and writing tests <CharlieBrown>My root parition is full even after garbage collecting, and I can't update any software. <buenouanq>have you tried turning it off and on again? ;3 <CharlieBrown>doing guix package --delete-generations guix package: error: expat-CVE-2016-0718-fix-regression.patch: patch not found <buenouanq>so after failing to install guixsd a number of times, I went and picked up that friend"s computer today and am currently trying to on my own. <buenouanq>if stuff keeps going wrong with it i'll have no idea what to do <buenouanq>now that I'm doing it in person I'll hopefully know more if it fails again <buenouanq>when might some sort of graphical installer be a thing? <buenouanq>it's hard to get normal people onboard when the install itself is completely boggling and unnavigable to them <buenouanq>personally, I prefer the install as it currently is - So whatever's to come, I hope this always remains at least an option. <efraim>buenouanq: I'll be in and out all day but I'd like to hear about your macbook install <buenouanq>but the refind config step is a little different <buenouanq>what's been bizarre and lame for me is, after the GuixSD install completes and you've edited the refind config, on reboot, it can't find any boot loaders <buenouanq>so what I've had to do is reset the parameter RAM (hold C+M+p+r on boot), this then forgets about refind and just boots to OSX <buenouanq>so then you have to reinstall refind (the partition already exists and it doesn't overwrite the config you edited during the install, so I'm not exactly sure why this step is necessary...) <buenouanq>\\emph{then} you can reboot and it will see both OSX and GuixSD <buenouanq>\\emph{then} you can remove the OSX partition (but with how weird this is, it might be preferable to keep it (at least for a while) just to be able to recover if something goes wrong) <buenouanq>I know very little about EFI and these other low level things, if someone has better ways to go about this, please speak up <buenouanq>like, are the paths to bzImage and initrd what they should be? <buenouanq>I'm trying to not even do efi, so I don't get why this matters. <buenouanq>is the answer to do the dumb hated efi thing? <buenouanq>the ...grub-2.02/lib/grub/i386-pc/modinfo.sh exists <efraim>I think what I did, since I was having trouble installing on btrfs, was install debian, binary guix install, install rEFInd, and then guix system reconfigure <buenouanq>ok, I'm giving in and going to try dumb evil efi madness for the first time <buenouanq>suggestion for the manual: there are two commands back to back both referring to setting up an efi partition <buenouanq>but the partition numbers used are different <buenouanq>unless I'm misunderstanding something, it would be clearer if they were both the same (either sda1 or sda2) <marusich>buenouanq, I think you're right; I think that for clarity that section should say sda1 <marusich>The section is not incorrect. If the FAT32 file system is in the second partition, which usually shows up as /dev/sda2, then /dev/sda2 is correct. However, it's strange to say this here because the paragraph right above it, as you point out, talks about making the FIRST partition the EFI system partition. <marusich>I think probably we forgot to update the preceding paragraph when we added the text that said sda2. <buenouanq>the commands are correct, it just switches numbers without reason <buenouanq>alrighty, a 2GB drive is no longer big enough to complete the GuixSD install (;-___-) <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, buenouanq says: but doesn't a swap partition take care of that? <buenouanq>do I have to manually mount the efi partition at /boot/efi before running system init, or does it take care of that on it"s own? assuming it is properly mounted in the config.scm <civodul>buenouanq: you have to manually mount it <buenouanq>what it says could mean just `mounted in the file-systems declaration' <ng0>hi! could anyone help me to debug what's wrong with offloading on my side? I would like to offload a long build and need this computer otherwise for work today <ng0>I've sent an email a couple of days ago, wasn't able to figure it out myself so far <ng0>to me it looks like there's a problem with package 'iso-codes', but without offloading it builds just fine <ng0>yes. now I have a new error, which is good :) <ng0>it was just 2 days ago, it's okay. <ng0>I've sent an update now <ng0>guix offload test works <ng0>just actual building doesn't <ng0>seems like machine A can send to machine B and machine B can receive, but machine B can not send to A <ng0>A has pubkey of B authorized and B has pubkey of A authorized <ng0>the short error at the moment is: guix offload: error: corrupt input while restoring archive from #<input: channel (open) 1da8c40> <ng0>shortly after A tries to retrieve the build from B <ng0>did you apply any changes recently that would require a more recent Guix version on the build node than aeed74f3709446e94a87809ddd465517738921e0 ? <ng0>the machine I'm offloading from is on HEAD <civodul>ng0: ah yes, i'm getting that as well now, and mbakke reported the same thing a couple of days ago <civodul>i pushed a couple of fixes recently but that didn't fix it, apparently <ng0>ok :) guess I'll just copy store items for now <civodul>it seemed that reverting 896fec476f728183b331cbb6e2afb891207b4205 helped <ng0>hm. did you push this? <ng0>oh, I meant the revert. <civodul>the strange thing is that "guix copy --from" works fine, but the equivalent operation during offloading doesn't <ng0>wished I could help a bit, but I don't want to mix up Java and Guile today, need to work on some Java now. <ng0>thanks for your help :) It's already good to know that it occurs on more machines. <civodul>oh, looks like the return of the bug described in 2e009ae7cdaee4ce871b3a79d50118762ee29fb6 <civodul>rekado_: maybe we should use qemu-binfmt on one or two machines behind berlin and use them as ARM build machines? <ng0>we could experiment with it. I've seen some (very old) comments on how bad the performance can be wrt building inside qemu <ng0>"building at the speed of snails with 1 CPU" wrote "some person on the internet" in 2014 <ng0>maybe it's not that bad <civodul>it's definitely slow, but then low-end ARM boxes are just as slow or even slower <ng0>maybe we could look into how some of the other projects do it. like slackware ARM etc. slackware arm just has a bunch of images on their homepage, no technical details <catonano>I'm just curious: I remember reading about cross compilation, in the past. Why isn't it available for porting Guix on Arm architectures ? <roptat>maybe because you need a different compiler, so a different set of inputs, so you get a different output when you cross-compile? ***Digitteknohippie is now known as Digit
<amz3>my undestanding is that cross compiling is an issue, in every distro <ng0>is #:test-exclude new on core-updates? <amz3>catonano: cross compiling is a pain in any distro <amz3>catonano: in gentoo, it's not even documented how to bootstrap another architecture for instance <catonano>I don't know so much about the issue, I was ust wondering <ng0>I think there are hints and notes somewhere.. but that's it. on the public side <catonano>amz3: I remember reading the NetBSD docs about how many platfforms thheir thing could run on. I even used their scripts to use a pc to compile an installation image for an Apple laptop. This was several yearrs ago. Because they used the autotools ffor everything, I was wondering why this isn't more common <catonano>I reiterate that I don't know so much about this though <str1ngs>autotools though good a cross compiling relies on the project to configure it properly. many things break when testing host system vs target system <buenouanq>ok, Installation finished. No error reported. <buenouanq>looks like I maybe did the efi stuff correctly <str1ngs>so you end up having to have a bunch of small patches just to get things to cross compile. <buenouanq>is this on your end or mine and how do I tell? <str1ngs>buenouanq: check users section maybe? <buenouanq>are capital letters not allowed or something? <amz3>last time i tried to bootstrap a gentoo for another distro, I used proot, getting the autotools cross compilations of every package working was too painful and requires much knowledge <amz3>s/for another distro/for another architecture/ <ng0>buenouanq: what's the content of the string? reading is better than guessing. Or even betrter, share the config somewhere to read <str1ngs>amz3: I once worked through the CLFS cross linux from scratch book... never again <str1ngs>buenouanq: your home directory should probably be /home/Shrimp <buenouanq>if that's the problem that's a serious bug I think <str1ngs>actually it's possible user shortname can only be shrimp <buenouanq>so the name field can't have capitals? for real? <civodul>buenouanq: you should perhaps email the details to help-guix, it may be easier to investigate <str1ngs>I don't recall use shornames ever having caps <ng0>there's GECOS. which can have capitals as the description <ng0>but login names, idk. <buenouanq>the issue is, to find out if that was really the problem is going to take me another 2 hours as I wait for guix pull and system init to do their thing again <ng0>hostnames can contain unicode last time I checked. maybe someone should read into usernames <buenouanq>unless you can tell me how to fix it as it is <ng0>you don't really need to pull each time? <OriansJ>well generally for legacy reasons you should limit user names to lowercase <str1ngs>buenouanq: are you using a USB installer? <ng0>if you already have guix you can create an up-to-date install-image <OriansJ>also, debian limits usernames to 16chars and RedHat limits usernames to 32chars. <buenouanq>this is the super cool inner workings of guix magic i've yet to touch <OriansJ>buenouanq: well the limit is generally done by the tool creating the user account, eg adduser <civodul>buenouanq: you don't have to run 'guix pull' before 'guix system init' (i'd recommend not doing that) <OriansJ>another fun bug I found was the shadow-utils has an issue where passwords can't contain some of the high ASCII <OriansJ>I mustly just stumbled upon these when setting up systems. (you wouldn't believe the bugs that occur when your username is 4096chars long) <OriansJ>TTY's crashing when you dump a 1MB password <str1ngs>buenouanq: I think the short answer your problem is . it would be better to have "use login names" in lower case <OriansJ>buenouanq: you could force guix to create uppercase usernames but you will end up breaking many things. (Many programs downcase the username and will fail on matching with /etc/passwd) <ng0>the actual bug I see here with buenouanq's problem is that we should describe this in the Manual and if possible catch in the operating-system <OriansJ>it is more of an input validation bug than anything else <str1ngs>I think the issue is pam, if you used samba it might be OK <ng0>OriansJ: no, I think we should recommend this in the Manual. <str1ngs>it is possible guix is making some assumptions and converting to lower case? <ng0>what is described here is a bug wrt Manual. <ng0>not everyone will read the Manuals of all GNU tools. We can day dream all day about this, but it won't happen. So we have to describe good usage, like "use an lowercase name for user-name" or catch it via input validation of the file <str1ngs>documenting might be a better thing. since if someone add ldap support . mix case sensitivity could change. so input validation then becomes more complex. <str1ngs>you will probably want to guix pull and reconfigure once the system is up. but you now the config works <buenouanq>that totally needs to be mentioned somewhere <buenouanq> thanks as always for all your help everyone <amz3>tx for guile-bytestructures. wrt gnunet-guile, I have working bindings for download, I will work on publish tonight and this week end <amz3>I will try to make 0.1 release with that <t0167641>hi, someone have a example of a package configuration with a tarfile.tar.gz local and not with a url-fetch <adfeno>Is someone working on adding Pitivi and Shotcut? <rekado_>t0167641: you’d still use url-fetch but use a “file://” url. <ng0>adfeno: I'm working on pitivi <ng0>debugging it, I'm a bit slow iwth it atm <adfeno>ng0: First: Thank you very much for the work, all of you! ;) . Second: what is the status of it so far? <adfeno>... is there any thing that needs doing? <ng0>technically it builds, but there's post-build issues <ng0>I guess I can work more relaxed now, same chipset in the new laptop as before but I haven't experience the i915 cursed bug here. <ng0>cursed as in 'f this glitch', not as in Ncurses <ng0>How many lines made it through? <ng0>I thought I sent about the status of it <t0167641>what is the command for build a package from scheme file <ng0>you could check out the pitivi branch in my repo to experience the bugs live <t0167641>because when i do a guix build -f file.scm <ng0>that is, the main dev repo, not the package repos <t0167641>they just say uix build: error: #<unspecified>: not something we can build <adfeno>t0167641: Unless I'm mistaken, the file passed to -f mustn't use "#:use-module", but "(use-modules ...)", perhaps this is a start. <ng0>adfeno: in theory I'm getting paid for the work on pitivi, so collab on it wouldn't be fair. but it amounts to so little (when you consider workhours divided by payment) that in theory collab would be okay. <ng0>ACTION wondering with all the lag if anything is getting send through <ng0>adfeno: p-package/pitivi is the branch <adfeno>ng0: don't worry, I read all the messages ;) including the last one about collab and paid work hours ;) <rekado_>t0167641: the file must end on a value, e.g. “my-package”. It cannot just contain definitions. <adfeno>and the ones about the repo, branch and so on. <ng0>commit date doesn't equal the date worked on it iirc. <ng0>there's at least this comment: <ng0>+ `(#:tests? #f ;The testsuite behaves strange <ng0>ah yeah now I remember <ng0>there's an error where GES can't be found <ng0>after install that is <ng0>well there are more messages lined up.. high latency here <ng0>someone else wants Docker and Flowblade, so there's two more applications lined up after/in parallel to pitivi. For Flowblade we have almost everything. For Docker I'd just mentor the packaging process. <ng0>of course if you want to work on Flowblade, go ahead. it would work now :) <adfeno>I don't know about you, but I'm not that sympathetic to Docker ;) <adfeno>... unless we can use it to Guix's advantage, and not to bundle stuff ;) <ng0>some people need it for their work. <ng0>Docker would of course be build from source, which has beend achieved before, this is just mapping the previous method to Guix. <adfeno>Yeah... I see... I just hope they get a better tool .;) (tip: starts with G and ends with X) ;) <adfeno>I wish mainstream would notice the advantages of Guix over Docker .;) <bavier>rekado_: I'm having trouble packaging a texlive-latex-xkeyval package, I was wondering if you had some tips <rekado_>I believe that’s the same package that I last attempted to package before giving up again. <bavier>I tried adding some font inputs, since it tries to run mktexpk to create the cmr10 font, but it still tries to create it <bavier>and often there is no error diagnostics printed upon failure <rekado_>yeah, that’s a bug in the smaller texlive. <bavier>I didn't expect to be diving into texlive land when I went to package guile-cv <bavier>I got vigra-c, texlive-fonts-iwona, and a couple other texlive-latex packages working <rekado_>you can get better output by changing “batchmode” to “nonstopmode” in guix/build/texlive-build-system.scm <bavier>rekado_: definitely. do you mind if I continue working on it? <rekado_>I probably wouldn’t look at it before the end of February anyway. <bavier>rekado_: ok, I'll see what kind of progress I can make <adfeno>ng0 buenouanq rekado_: Re: Docker and Guix: What about `guix vm', is't it the same as a docker image? <ng0>the two can't be compared <ng0>I'm not a Docker user myself, but someone who's working with it explained it to me in relative comparison to Guix*SD* <rekado_>guix vm builds a virtual machine image. <ng0>Docker is not just a VM <rekado_>Docker expects a Docker image, which is an archive containing files. <rekado_>it then uses Linux features to mount the image and run executables in an isolated namespace. <rekado_>we can do this with Guix as well, but we don’t read Docker images. <rekado_>so if all someone has is a bunch of Docker images, then they won’t be able to just switch to Guix. <rekado_>Docker images are also supported by Docker competitors. Guix also supports exporting Docker images. <rekado_>I have a package for a poorly written bioinfo tool, but it segfaults in conditions where the same package from conda does not segfault. <amz3>adfeno: my understanding, is that docker, among other things, help people that don't want to package their software, which is not the approach taken by guix which a package manager <rekado_>…but then I look at the code and wonder how it could ever *not* segfault! <amz3>adfeno: when you use guix, you can freeze the dependencies in binary form, just like people do with docker, mind the fact that guix can generate docker images but except if your hosting service is using docker images there is no point in doing that <rekado_>this segfaults when you call “salmon quant” without any further arguments, because argv2 doesn’t have a 1st element. <rekado_>it’s really frustrating because it looks to my colleagues as if this is a problem with Guix. <rekado_>but it really is by accident that the conda package does not segfault. <amz3>conda package is patched? <rekado_>they use gcc 4.8 and an old version of boost <rekado_>of course, the conda people don’t unbundle libraries <rekado_>so I’ve got separate jellyfish-for-salmon and rapmap-for-salmon and bwa-for-salmon packages. <amz3>to get started, it's a very bad idea to write its own cli options parser in C++ <amz3>it's not a suprise there is bug in this kind of code <adfeno>./pre-inst-env: substitute: Failed to autoload make-session in (gnutls) <ng0>hwo's thta related to my repo? <adfeno>Because I have to use the ./configure; make check; ./pre-inst-env procedures in your repo too, don't I? <adfeno>sorry: replace "procedures" with "steps" <ng0>guix environment --fallback --no-build-hook --pure guix followed by ./bootstrap; ./configure --localstatedir=/var --sysconfdir=/etc; make <civodul>ACTION squashed the offload bug \\o/ <ng0>silly question, but where does (use-modules) come from? use-service-modules etc are in gnu.scm ... but without any middle word? <adfeno>^ note: no S there, only one #:use-module per module. <ng0>you just answered my question. I didn't see it before :D too obvious <catonano>amz3: did you publish and then download the GPL text ? <amz3>catonano: yes, all in guile :) <daviid>bavier: rekado_ the gule-cv latex dependency is because I use latex to create images for both gray and colored histograms... whe find some time, i'll use cairo (guile-cairo) but it was a lot easier(fatser) for me to do it in latex ... <daviid>it does not depend on texlive itself, any modern latex distro will do. however, I use iwona fonts (which admittedly could be perceived as a bit too much, but I love that font and the 'look' of the results matters ... oh well <ng0>this is more of a guile question, but I'm asking it in a Guix context: where can I find the reason for guile modules always having a maximum length of 3 words in their path / name? I've tried 4 before and this is not recognized. The guile documentation doesn#t give much insight either. <daviid>bavier: rekado_ ping me anytme if you need help ... <bavier>I think the packaging of those latex modules would need to be done eventually anyhow <daviid>bavier: guile-cv configure.ac lists the packages it depends upon ... <amz3>ng0: what do you mean by "maxium length of 3 words" like you can't nest more that 3 level deep modules? <ng0>for example (define-module (templates foo 0 bar-baz)) <amz3>ng0: that's the module 0 that might not work, that not an issue with how deep the module is <ng0>so (define-module (templates foo zerok bar-baz)) would be possible. just '0' in the middle would not work <amz3>I think numbers are not valid module name <ng0>0 has a special value I remember reading.. correct? <ng0>that makes more sense than the error message guile has for this <adfeno>ng0: Question: does testing your guix repository require root? Can I add "sudo" (the package) to the guix environment? <ng0>uh.. usually it doesn't <amz3>btw ng0 gnunet-guile works :) <amz3>btw ng0 gnunet-guile publish works :) <ng0>adfeno: all the things that apply for the normal dev setup apply <ng0>can't really stick around, I guess I'll be back tomorrow <adfeno>ng0: Yes, numbers are values by themselves, can't define them this way unless you use some other mechanism to tell that "0" should be a module. <amz3>I think 0 is not a valid variable identifier, that's why it's not accepted as module name <rekado_>amz3: neat! How much of the existing Guile bindings were in a usable state? <bavier>but you could use #{0}# in define-module <amz3>rekado_: i restarted from scratch, it might have been usable, but Idid not like the code anyway <adfeno>But even then, telling the interpreter that a number should be a procedure sounds like a dirty way to code stuff :) <rekado_>pity, but great that you got it going so quickly. <amz3>well, it was much easier for me because of guile-bytestructures <daviid>bavier: fyi, guile-cv latest is 0.1.8 (the paste from rekado_ mentions 0.1.7, because he started to work on it before the latest release...) <bavier>daviid: yeah, I was working with 0.1.8 <rekado_>yeah, that’s right. The texlive thing really threw a wrench in the works… <bavier>daviid: btw, I think one of the webpage's needs to be updated yet... <daviid>0.1.8 is nw as fast as imagej (it's about 20 to 100x faster then 0.1.7) <daviid>bavier: what page? I may have forgotten ... <bavier>still links to 0.1.7 as the latest release <daviid>rekado_: though, to present it to the bioinformatic friends, we really need guile maintainers to patch guile's default repl and raised exception 'systems' ... I hope they will find some time soon to proccess my bug reports (request for improvments actually) ... <rekado_>isn’t that only important when using it with a REPL? <daviid>for the very brave, the way to localy patch is very well (I hope) described in the manual 2.1 Configuring Guile for Guile-CV <rekado_>imagej people don’t use their software interactively, do they? <daviid>bavier: if you happen to try it before to publish the guix package, do read and configure your guile before any attempt to even load a small image ... <daviid>bavier I see the install page ... will patch now! thanks! <bavier>daviid: as a guix package, though, we'd need to patch either our guile package, or provide a modified private guile package for guile-cv <rekado_>maybe guile-cv should have its own IDE…? <rekado_>(it’s puzzling to me, but not everyone likes to use Emacs+Geiser) <daviid>rekado_: it could, but not me :), emacs+geiser is a lot better (and faster) <daviid>octave image, mathlab, opencv ... do not have 'on the fly' ide either <adfeno>I really hope my little experiment works... can't seem to get ng0's `./pre-inst-env guix-daemon ...' to work with the guix environment he told me to use, so I decided to go on and do `./pre-inst-env guix build pitivi' directly instead of trying to start daemon. <adfeno>.... and I just hope I don't endup rebuilding the world. ;D <daviid>rekado_: but I know, it is difficult to convince people to use emacs+geiser (and in the ip/cv world, almost none know scheme ... so it will take some time, if I ever succeed, to get 'real users' ... but then you will help me :) and talk to your collegue ... once guile is patched, or if you patch guile for them ... <daviid>guile-cv is very cool to use, I should write a tutorial for kids even, in the picture programming language 'spirit' <rekado_>I guess we’ll need some convincing short examples, e.g. how to implement recognition of hand-drawn numbers. <daviid>rekado_: could do, but I more interested in the scientific use in the field of mineral and biology microscopy image processing <daviid>bavier: I'm afraid guile-cv won't fit your dream :) it really is dedicated to 'science' image processing and analysis <bavier>was only a small dream amonst many ;) <daviid>bavier: another thing to be very carefull about are the flags used to compile vigra and vigra_c <daviid>bavier: both _must_ be compiled using ‑DCMAKE_BUILD_TYPE=RELEASE <daviid>bavier: I pateched and uploaded the new install page, thanks again! <daviid>rekado_: civodul I never took the time to answer to guix 'guile-libification' now a bit 'old' thread, but I 'm interested and thought you might talk a bit about that at fosdem (I won't be there) and select, say, one functionality that would be a good fit to land in guile-lib, they I would do it as a test ... wdyt? <daviid>there are tons of things that are in guix but could benefit guile based projects ... (not depending o guix) <civodul>daviid: yes we should do something about it <civodul>first candidate is guile-gcrypt, which may well be almost ready; dustyweb? :-) <daviid>civodul: ok, will look into guile-gcrypt then, is it on noteabug? (can't remember) <dustyweb>yeah I think mostly right now it needs a release :) <daviid>ok! to add it to guile-lib, we definitely need doc, but i hope by the time I will have worked on it, you'll have the doc ready ... :) <daviid>dustyweb: how are you by the way? you are very quite these days ... :) <dustyweb>I just got hired by Digital Bazaar half time today! <dustyweb>daviid: however lately I've been a bit of a traitor! <dustyweb>I am spending a lot more time in Racket lately... <dustyweb>daviid: well my spouse and I started working on a "digital humanities" course using Racket, DrRackett, and especially Scribble <dustyweb>and I was teaching her with DrRacket and was kind of floored by all the tooling that came out of the box... <dustyweb>and then I started using a lot of it myself... <dustyweb>Racket is pretty incredible in its batteries-includedness... a lot less yak shaving, though I do like shaving yaks <dustyweb>they could use a better package manager though... we can help with that :) <dustyweb>I miss the live hack'iness of GOOPS though! <dustyweb>expect to see some work on Racket packages in Guix from me soon, probably :) <daviid>interesting, i tried once drracket (I had to teach a young intern scheme intro...) and I found it terrible! :) emacs+geiser is so much better for me :) <daviid>anyway, they don't have goops, which is a blocker (for me) <dustyweb>though it isn't as nice as Guile's emacs + geiser <daviid>i see, a real trahison then :):) <daviid>dustyweb: we will really miss your participation to guile! what batteries does racket has that guile does not have? for your use I mean, just curious <dustyweb>daviid: especially because of Guix, Guile's killer application :) <dustyweb>daviid: but some things that Racket has which are pretty incredible IME: <dustyweb> - the picture language and overal drawing toolkit <dustyweb> - the builtin GUI system is mostly pretty nice :) <rekado_>the picture language really is great. <dustyweb> - scribble is incredible... like Skribe but inverted... text by default but you escape into code <dustyweb> - the documentation is really great, and very friendly to newcomers <dustyweb>CompanionCube: it can be used for that, but I wouldn't say it's "just" that <dustyweb>my favorite thing, language-wise, which Guile could have too <rekado_>dustyweb: do you think a Galvanic Guile would be a useful thing to have? <dustyweb>hashmaps are part of the default read/write syntax <dustyweb>rekado_: I mean, Guile does ship with some batteries, but not quite as many <dustyweb>rekado_: I'm not sure the libraries need to necessarily be included <dustyweb>but Racket does have more libraries that I want already written by the community off the bat I've found <dustyweb>I'm not sure what we can do about that in Guile other than keep writing libraries <rekado_>maybe a more coordinated effort is needed there; dunno. <dustyweb>I'm not trying to get everyone down and make people feel bad about the state of Guile! I've just been having a really nice time in Racket :) <dustyweb>I do miss GOOPS though, and I'm not sure how to do something like Mudsync in Racket <dustyweb>since live hacking doesn't really work the same way <amz3>CompanionCube: in scribble, you can call scheme via a special syntax which can take formatted text as argument IIRC <amz3>Isn't DrRacket very slow? <dustyweb>but my spouse uses DrRacket, and she loves it <amz3>yes, understand DrRacket is nice to get it <dustyweb>I decided to make myself use DrRacket only for a couple of days to make sure I would be able to teach others using it <daviid>dustyweb: too bad yu did not 'progess' more with guile-squee <dustyweb>and it's the only editor I've been able to stand that isn't emacs ;) <dustyweb>daviid: yeah... I was planning to get back to it <dustyweb>maybe I will still but maybe not. It depends on where my projects go in the next few months. <dustyweb>one thins is sure, I will keep hacking hacking Guix :) <daviid>then we have guile-sqlite3 as well... what sql binding does racket has that we d'ont have? or sql functionality? <amz3>anyway, skribble is just stellar <dustyweb>which I planned but dreaded eventually exploring in Squee <amz3>it's the best tool around the Internet <daviid>dustyweb: it's too bad you 'switched' to racket, all your time helping us to get more battereis, precisely, will be really missing, and your patches for goops ... 8sync ... <dustyweb>and Guile still does have something very exciting on the horizon: <dustyweb>especially if it leads to a path for WASM compilation <dustyweb>wingo at one point suggested that maybe 3.0 could get Guile to the point where it's a more interesting backend target for Racket than Chez... that would be one interesting way to combine scheme powers :) <dustyweb>(Matthew Flatt is currently working on moving Racket's VM away from its C engine to a Scheme one with Chez) <amz3>dustyweb: did you read the new book about racket web dev? <amz3>(this is rather OT but...) <dustyweb>Guile has nicer tools for parsing HTML headers <dustyweb>(though, I think Guile's web server should be more robustness-principle about accepting them) <adfeno>and HTML in general ;) (if one assumes HTML as similar to XML) <daviid>I wonder if we could have a doc css from texinfo -> 'racket like doc' <dustyweb>daviid: a better CSS style for texinfo out of the box you mean? <daviid>very badely expressed, but you get the dea guess :) <dustyweb>rekado_ worked on that and kind of got shut down iirc :( <amz3>skribble is verrry powerful, but at the end of the day it's just code.. <daviid>guile-cv has and intalls its own css, but that still does not make our doc browsable 'a la racket' <rekado_>yeah, that was no pleasant interaction, but I can’t say it wasn’t expected. <rekado_>BTW: the new info.js is pretty neat. <rekado_>Too bad it takes extra effort to include it. <daviid>I'm lost now: what did rekado do for documentation? texinfo -> ?? <rekado_>I wrote what I considered a prettier default stylesheet for texinfo->HTML output. <daviid>rekado_: where is it? based on the gnulib one (I based my few modifications on the gnulib css) <dustyweb>lots of GNU projects are very cranky when it comes to such things... happily I think Guile and Guix are both on the friendlier side of GNU projects there :) <daviid>maybe one could write a texinfo -> scribble <daviid>dustyweb: gnu projects must have their doc in texinfo, which I really like by the way, but i see the -> browser doc is better in scribble then texinfo <dustyweb>daviid: however GNU projects are allowed to do FOO -> texinfo <dustyweb>it's the info that's required, not texinfo <daviid>dustyweb: guile-squee could be as good as racket sql binding ... <dustyweb>I know this because that's how GNU MediaGoblin does it :) <daviid>dustyweb: i thnk texinfo is mandatory <dustyweb>though I think texinfo is an intermediate step <adfeno>doesn't guile already has something->texinfo conversion? <daviid>which I like, but i wouldn't mind. so yes, like sxml, stexinfo ... <daviid>we need more contributors for guile... and guile-cv :) <daviid>but i think guile-3.0 will be a scheme killer <daviid>the all world will start to use guile, and goops <amz3>once the migration is done ;) <amz3>Python 3 almost killed Python <bavier>I think it'd be great for guile-3.0 to have some more polished language compilers <daviid>rekado_: why did you mentioned node.js in our conversation, I got lost there as well :)