***hhao is now known as oahong
<Apteryx>sneek: later tell civodul: never mind, everything seems to work as expected even in guix environments upon further testing. If you find anything strange let me know! I'll be AFK for the next week or so due to traveling. <Apteryx>sneek: later tell civodul: (in regards to man-db database hook) <ZombieCh1cken>Does Guix have any way to determine how many packages are left to build? <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, Apteryx says: never mind, everything seems to work as expected even in guix environments upon further testing. If you find anything strange let me know! I'll be AFK for the next week or so due to traveling. <sneek>civodul, Apteryx says: (in regards to man-db database hook) ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | videos: https://gnu.org/s/guix/help/#talks | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: http://paste.lisp.org | log: https://gnunet.org/bot/log/guix'
<marusich>What's the recommended workflow for submitting patches to guix-patches via git send-email? <marusich>If I just ask git send-email to send a patch series to guix-patches@gnu.org, won't it create multiple "bug" entries in guix-patches? <civodul>marusich: you have to first send the "cover letter" for the patch series <civodul>then wait for a number to be assigned <civodul>and then email the rest to that number <civodul>not as convenient as we'd like, but okay <wingo>if i wonder why it makes multiple bugs if there is a reply chain <wingo>you would think that could be solved by debbugs <civodul>yeah in some cases it does seem to just DTRT <civodul>but maybe that only works once the initial message has been processed <marusich>civodul, do you mean, manually send a cover letter first? (i.e., do not use the 'cover letter' feature provided by git send-email) <civodul>use the cover letter feature of 'git format-patch', but then do "git send-email 0000*.patch", wait, and then "git send-email --in-reply-to... 000[0-9]*.patch" ***MatthewAllan93_ is now known as MatthewAllan93
<thomasd>the guix configure script in my ‘guix environment guix’ is misdetecting the C preprocessor: “checking how to run the C preprocessor... /lib/cpp” -> configure: error. what am I doing wrong? :) <marusich>thomasd, maybe it's because of an impurity? Does this happen if you try 'guix environment --pure guix' or 'guix environment --container guix'? <thomasd>ok, ‘--pure’ seems to have solved it :) <thomasd>it had been a while since I last bootstrapped my git checkout. Probably I installed some conflicting packages in my user profile since then. <thomasd>anyone here familiar with building common lisp packages? <civodul>thomasd: perhaps config.log had useful details <civodul>and no, not really familiar with CL packages :-) <thomasd>(un-)fortunately, the problem is fixed. my old config.log is now gone. All I remember from when I looked at it, are the preprocessor errors. <thomasd>and blame paroneayea for making me want to explore common lisp :) <thomasd>I've already made some progresss: adding a '-' inside the package version string is a bad idea :) (could be a small bug in the asdf/cl build system) <civodul>this build system does seem to be making assumptions about input labels and such <catonano>thomasd: that listener thing is astounding ! <catonano>reado posted links to a liisp machine thing <rekado>I’m working on updating all of Bioconductor and CRAN today. After that I hope to find some time to review patches on guix-patches. <catonano>like a REPL but able to show grapically pictures, graphs... <rekado>civodul: I have this big stash of java packages here and I’m only making progress slowly. Do you think it would be okay to share this as wip-java or should I publish it elsewhere? <catonano>thomasd: without hhaving to represent averything as text <rekado>civodul: I just don’t want people to redo all of this work <civodul>along with a message to guix-devel i guess <thomasd>catonano: I think I missed that post, do you have the link somewhere? <rekado>bleh, the armadillo project no longer publishes old tarballs. <rekado>instead you get a tarball containing a README.txt that tells you to upgrade :( <rekado>so, I need to change r-rcpparmadillo to use the bundled armadillo sources or else there’s no way to build it reliably <paroneayea>thomasd: you may have heard me talk about this in my talk... you can have a REPL type thing where the listener can take commands (maybe in lisp, maybe in some other dsl on top of lisp), and imagine a command line where it can show *more* than just text... imagine if ls could output preview icons of all the files in there <paroneayea>thomasd: or maybe you're building up a procedural image; every time you modify the image object or compose a new derivation <paroneayea>that's because the object is able to give a description through some generic method specifications of how it should render <paroneayea>also, the objects in this "shell" are also interfacable with a mouse and do mouse-sensitive things <paroneayea>so wait a minute, if that's all that powerful, why not build your entire UI out of lisp objects that are able to render and be interfaced with and be clicked on, not just have a rich shell? <paroneayea>One reasons Rainer Joswig gave me a hard time for calling emacs a "poor man's lisp machine" (though I still think it's kind of true) is because in GNU, Emacs is a program <paroneayea>in lisp machines, Emacs was a subroutine, which could be embedded in any other program <paroneayea>and of course the emacs you embedded could also be extended <paroneayea>and that's exactly how Symbolics' Concordia document preparation system worked; a full fledged word processor inside an "emacs" (here, "zmacs") <paroneayea>if you want to see a good example of a lisp listener in action, https://www.youtube.com/watch?v=o4-YnLpLgtk is decent; I'm sure there are better examples that could be given but it's hard to find material of people showing these things off. Still, shows a REPL which is showing and modifying images, etc <paroneayea>anyway, if we made GOOPS good enough, and added a CLIM type layer, there's no reason we couldn't have something like this in Guile, but yeah for now Common Lisp is the place to go explore these I guess <paroneayea>thomasd: rekado had remarked upon seeing McCLIM that this is how they wished emacs worked (I agree) <paroneayea>don't get me wrong, I love GNU Emacs (which someone pointed out yesterday that hacking emacs is kind of like editing Logo for text, where the turtle is your cursor) <paroneayea>but it would be pretty cool if someone used EIEIO to implement the CLIM spec or something <paroneayea>but this shows off how those interfaces looked, with a pretty advanced program, a 3d graphics program <paroneayea>in contrast, Blender, which is complimentable for trying to allow you to play with any operation you can see on your screen in python <paroneayea>where you could jump into the lisp definition and inspect at any layer of the program, all the way to the bottom of the machine <paroneayea>and every piece of that UI is a live lisp object <catonano>paroneayea: I had nevers seen a Lisp Machine but it reminds me of the Squeak Smalltalk <catonano>the menus, the way of calling things obects... <catonano>of course squeak amslltalk had no d capabilities. At least I don't remember those <paroneayea>catonano: and yeah I heard smalltalk environments, like lisp machines, were similarly immersive <thomasd>paroneayea: I was away for a minute there ;) thanks for the overview. so many directions to explore... <paroneayea>thomasd: indeed, too many! happy spelunking, but don't get lost down there... <rekado>paroneayea: whenever someone talks about implementing something new in Emacs I wonder if maybe it should be implemented in Guile instead (and then an Emacs interface could be added for it). <rekado>I’m at this point with the browser stuff in Emacs. <rekado>maybe it would be better to implement this with Guile, because Elisp isn’t the best language when it comes to domains other than Emacs buffers. <catonano>McCLIM looks interesting. I wonder ow hard it would be to have it run on some LISP implementation <ZombieCh1cken>Hopefully silly question; does Guix replace the current contents of /boot with it's own stuff, or will it leave hand installed kernels and such in there? <ng0>Yesterday I learned about the grand end goal of a project of people located around where I live. They are working on making a secure, distributed, version control system :3 Sadly their website is so terrible that I can't point to it at the moment, and despite being very active I still have to poke them until they give me the source urls <snape>ng0: isn't git a secure, distributed version control system? <ng0>okay, distributed as in decentrailzed and makes use of a distributed network <ng0>so that you can work wherever the hell you are without depending on a particular server or anyone running .onions etc <CcxWrk>ng0: Personally I'm quite interested in Pijul when it manages to become more mature. <ZombieCh1cken>ng0: Is it an entirely new VCS, or is it building ontop of something already in use, like git? <ng0>I asked surim to keep me in the loop so that I can direct people at them (autotools champion needed to replace what they have now), and to be informed about more details and when we can start the system integration <CcxWrk>I think tahoe-lafs guys were making a git backend plugin. <ng0>ZombieCh1cken: my guess is entirely new. I'm only picking up information through delayed message exchange :) <ng0>sha3 and all the shizzles <ng0>started in Ruhruniversität Bochum, but as its funded by no one now, they are just hacking on it whenever they can. currently surim works 4 hours a day in addition to the day job, which sounds like making lots of progress since last time I learned about it ***ryanpcmcquen_ is now known as ryanpcmcquen
<thomasd>ZombieCh1cken: about boot: I think it depends on what you mean. I have some separate partitions where a Ubuntu still lives, but if you choose your existing boot partition to serve as GuixSD's boot, I suppose GuixSD will overwrite the existing boot/grub etc? <ng0>can we still say that GuixSD is based on NixOS or is it now more accurate to say that it has parallels to NixOS? There's Nix as the origin, and there are some C parts where a GSoC project which was offered is to replace it with Guile. <rekado>ng0: not even Guix is based on Nix. <ng0>somewhere on the website we use that expression <davexunit>we definitely don't say that GuixSD is based on NixOS <davexunit>because they are entirely different and we all really want people to stop saying that we are "just" a Scheme layer on top of Nix. <rekado>there are two things that Guix(SD) and Nix(OS) have in common: the idea of functional package management and the daemon. <ng0>I have to read it again, now that I look at it again I don't see the sentence I meant to show you <ng0>I know by now what the common ideas are. what I meant was this in "Help > Papers" the text for the original Nix whitepaper adds this, which point to the acknoledgements in the Documentation: … "about the Nix package manager, which Guix is based on." <thomasd>The Guix manual's acknowledgements section also start with “Guix is based on the Nix package manager”. <rekado>I think “based on” is an unfortunate choice of words. <thomasd>yes, it can be interpreted in different ways <davexunit>yeah I think we have grown to regret that choice of words <davexunit>it gives people the wrong idea and makes it seems as if we are a derivative <ng0>ludovic said that over the years a comparison section was hoped to be avoided, but said it looks like it is necessary. Maybe a simple change of words there will work. To just explain what is meant by "based on" <rekado>I still think there shouldn’t be a comparison section. <rekado>I don’t think Guix should be defined in terms of Nix. <rekado>“based on” could be replaced with a more accurate statement. <thomasd>something along the lines of “Guix builds on ideas first implemented in ...”? <rekado>I think we went with something like “Guix is an implementation of the functional package management paradigm pioneered by Nix” in other places. <ng0>I like the icecat package build change. minutes instead of hours to build it really rocks :) <efraim>i can't wait to try it on my aarch64 machine when it comes back up, last time it took 10 hours <ng0>30 minutes on an i7 :) <civodul>what would it take/would it be useful to add AppImage output to 'guix pack'? <bavier>civodul: would seem useful to me <bavier>I haven't tried AppImages before, but none of them work on my ancient workstation because of system library version dependencies <bavier>idk, maybe I'm doing things wrong <bavier>haha: "each AppImage has no dependencies other than what is included in the targeted base operating system(s)" <[df]_>no dependencies except for its dependencies <paroneayea>though I fear if it's going to happe, it should demonstrate itself sooner than later, before emacs settles into this JIT route that I think is a mistake <bavier>civodul: this might be tricky for us: "Your binary, myapp, must not contain any hardcoded paths that would prevent it from being relocateable." <civodul>bavier: ouch, not just for "us" i guess! <paroneayea>CharlieBrown: but some changes are happening in Emacs that might be hard to reconcile with Guile <paroneayea><catonano> McCLIM looks interesting. I wonder ow hard it would be to have it run on some LISP implementation <CharlieBrown>...which means Guile Emacs will have to fight against Emacs, which means it's basically impossible after that. Fighting with upstream is hopeless. <paroneayea>catonano_: http://bauhh.dyndns.org:8000/clim-spec/index.html there's also a standard, which could be followed if porting to another lisp (Guile?) were desirable. I don't know if today you would make exactly all the same decisions... it seems to have some nice things (most classes / structures seem to be immutable) but some I'm not sure if nice things (one thread per window?) <paroneayea>catonano_: occasionally I think about how nice it would be to have a WM that had widgets that were CLIM-like in design, but which followed the kind of design that davexunit's sly had, which seems like it would work well with a WM <catonano_>paroneayea: I never sow any example of the design sly had <catonano_>I was thinking that it would be nice to have the Gnome design on top of such a thing <catonano_>I think the first step would be to port in in guix, to see it running and have people see it <paroneayea>I guess it might be a challenge to see if anyone can create a CLIM style application that looks relatively modern ;) <paroneayea>it would be great to have more CL packages in Guix. <catonano_>maybe there' s a group of us interested in working on implementing that protocol (standard ) in Guile scheme ? <catonano_>this is exactly what tomasd was discussing a short while ago <catonano_>having more common lisp packages ported in guix <paroneayea>catonano_: I'd love to see it if someone wanted to play with building it. But yes, I think having McCLIM in Guix would allow Guilers to more easily explore what ideas are good or not before starting such an attempt... not to mention how nice it would be to have more Common Lisp packages in Guix as its own reward :) <paroneayea>catonano_: btw there's a #clim channel here on freenode if you like to hang out there. It's usually pretty quiet but sometimes some interesting history drops in there. <paroneayea>catonano_: the main takeaway I think taht matters is that objects can choose how to represent and be interfaced with <paroneayea>I'm not sure if the whole of (Mc)CLIM is a good design, because I haven't used it enough <paroneayea>catonano_: but yeah not sure how hard it is to package in Guix <catonano_>I could use some diagrams of the architecture <catonano_>of McCLIM. Please don't pull in ASDF just yet ;-) <paroneayea>like much of lisp history seems to be going.....! <bavier>paroneayea: cool writeup on Gush <bavier>reminds me of an esoteric language I read about/implemented called FALSE <bavier>paroneayea: and in a rather functional manner they named your "exec" stack the "continuation" stack <bavier>and there were ways to manipulate the continuation stack so you could do things like implement while-loops <paroneayea>bavier: cool, yeah it doesn't really use a continuation stack per se but it does allow you to build up expressions of code to evaluate later <paroneayea>and (borrowing from experience in PushGP) tries to allow building up those expressions to be loosey goosey enough to where a program could even incidentally develop the right structures <paroneayea>Gush is also the first "real language design" endeavour I feel like I've gone down, where I thought about language design issues I was myself making <paroneayea>but it might be resilient enough to survive a lot of mutation :) <bavier>yeah, I'd be excited to see what fun things you can do with it <paroneayea>the actual evolution of the program and its state all done using immutable datastructures <paroneayea>so at one point I was saying to a friend that you could replay things because there was no mutation of the fundamental state <paroneayea>and then I realized how strange that is to say about a genetic programming oriented language :)