IRC channel logs
2017-06-15.log
back to list of logs
<janneke>it will be clear when the new build process is in place i guess <reepca>Question - when the manual says "the directory name contains a hash of all the inputs used to build that package", is that a hash of the hashes of the inputs or the hash of a directory containing all the inputs? <OriansJ>janneke: we will talk more about this tomorrow <reepca>just grep-ing through the nix directory for "hash" produces a ton of results to look through <rain1>im just working on my scheme compiler a bit <rain1>what's new with the mes/stage0 project? :) <OriansJ>rain1: janneke has finished the hex2 output functionality and I am writing a M0 macro definition file for all useful x86 opcode encodings <rain1>that's great! we will basically have bootstrapped a x86 assemble from nothing by this point <OriansJ>rain1: plus I'm making a reduced version that only covers the x86 opcodes required by mes, which is looking like it'll only be about 60ish lines long <OriansJ>rain1: I am also working on a META II compiler, to perhaps simplify the bootstrap of a C compiler even further <OriansJ>rain1: also I'd love a link to see your scheme compiler <rain1>what a good idea, META will be a winner for sure <rain1>I have been thinking about the gap from x86 to mes a bit <rain1>well, you might not like this idea <rain1>but languages like scheme require quite an involved runtime, whereas when I studied jonesforth it has absolutely minimal runtime (basically just a linked list dictionary, loader and reader) <rain1>so i am thinking quite a reasonable approach could be to build a simple forth up from asm, then perhaps implement a VM interpreter and a trivial scheme interpreter, in order to compile a scheme->vm compiler <rain1>but i had forgot about META II, that may actually fill that gap better than forth <OriansJ>rain1: certainly ambitious, I'll give you that <OriansJ>rain1: however a little bit overkill <OriansJ>rain1: an easier approach is take jones forth, reduce its build requirements <rain1>yeah its a single page of code so very easy to just go through and translate <OriansJ>rain1: actually jones forth abuses assembler macros <rain1>it is very heavy on the macros <rain1>so this path is significantly harder than i though <OriansJ>only some minor changes are required to port it to x86 if you wished <OriansJ>((foo prim_foo) (bar prim_bar) ... (baz prim baz)) <OriansJ>rain1: the big problem is that every idea is possible but no one knows the most efficient way to solve the complete bootstrapping problem <rain1>thats true but there may be value in having multiple paths too! <OriansJ>most have given up and simply said "These binaries are trusted and we are leaving it at that" <rain1>probably the toughest part is still getting off the ground with C compilers <OriansJ>rain1: well janneke has already shown it can be done in scheme <OriansJ>history has shown it can be done with B and Meta II <OriansJ>but making B require BCPL, which requires CPL, which requires mum, which requires shout.... <OriansJ>I've decided to say "Fuck it, assume this thing" <OriansJ>I'll encourage and help anyone who wants to work on this problem but as alway my time is quite limited <OriansJ>people told me, write a forth and we'll help. So I went and wrote a working forth. <OriansJ>Then they said great, now use it to do all this other work we think you should do... <OriansJ>rain1: if you truly believe in the forth route, help me make my forth better so that we can use it to reach the goal. <OriansJ>I'll take patches, bug reports, test cases or feature requests but show me something <buenouanq>I wish I had the time to dedicate to become proficient in using it. <OriansJ>buenouanq: it is also one of only two languages that can be bootstrapped from a 280byte hex monitor in 60 seconds <OriansJ>buenouanq: perhaps you could work with rain1 to expand your experience with forth and perhaps help us solve the bootstrapping problem forever <OriansJ>buenouanq: 10 minutes a day is enough to make a difference <OriansJ>and with that M0 x86 definitions has reached 2360 <reepca>OriansJ: How close is your forth to ANS? <OriansJ>reepca: only about 6 primitives short if I remember correctly <reepca>Neat. I've actually been looking at doing some compiler-related stuff in forth since awhile ago - got a bit tired of searching manually through headers when using C libraries (stuff like OpenGL saying "well, a float is at least 32 bits" is maddening when you're not using a C compiler) <OriansJ>reepca: I look forward to seeing that. <OriansJ>if you look at line 121, you'll see how trivial it is to add a primitive <reepca>Hm, on running "./bin/vm --rom roms/forth" I get a "invalid state reached after 19 instructions" message. <OriansJ>reepca: that is because you need to specify that you want more than 16kb <OriansJ>I'll have to add that to the makefile <reepca>is there any particular environment I should be running it in? In an emacs shell it just echoes out the first character of each line I enter and doesn't seem to do much else, and in a terminal it doesn't do anything as far as I can tell. <OriansJ>reepca: no, it is just a primitive forth <OriansJ>it read/executes tape_01 and then it reads tty <reepca>Oh, okay, so I should write input in tape_01? <reepca>Hm, that doesn't seem to be working either. I put "2 ." in tape_01, but don't get any output on running "./bin/vm --rom roms/forth --memory 1M" <OriansJ>KEY gets key presses, EMIT pops a value off the stack and puts it to the tty, WRITE8 pops a value off the stack and writes it to tape_02 <OriansJ>literally it is about at the same level of functionality as jones forth assembly implementation <reepca>I think I'm a bit spoiled by gforth. I put 42 EMIT in tape_01 and ran the same command, but didn't get any output. <OriansJ>reepca: did you remember to put a newline or space after the command? <reepca>Ahhh, nope. That would explain it. Also, I can confirm it doesn't work well with an emacs shell buffer - 42 EMIT did work in terminal, but not in shell. <OriansJ>reepca: that may have to do with the x11 buffer flushing to prevent readline from buffering the line up to the newline character <OriansJ>reepca: make vm-production will build bin/vm-production that doesn't turn off readline <reepca>Ah, that's better, thanks. But now I notice that 42 DUP EMIT seems to emit a NUL <reepca>and 42 DUP EMIT EMIT emits a NUL and then a * <OriansJ>reepca: I haven't looked at it since November but I will see what is wrong and fix it <reepca>I think the stack offsets might be off - OVER is getting the top of stack. <reepca>Yep, changed DUP to -4 and OVER to -8 and now it seems to be working <OriansJ>reepca: excellent catch, patching the master now <OriansJ>reepca: patches are up and all other stack peeks are fixed <OriansJ>reepca: thank you very much for taking the time :D <reepca>Thanks for taking the time to introduce me - I forgot about case sensitivity for awhile there... <OriansJ>reepca: anytime, I'm always willing to help <OriansJ>rain1: minor warning, stage0 vm allows any register to function as a stack via push and pop. <OriansJ>for call and return too, if one wanted to go crazy with exotic variable and function scoping <OriansJ>and now the missing input file bug will be caught and a more useful error message will be displayed from now on <reepca>OriansJ: Is there any way to manipulate HERE at a byte level (rather than cell level) currently? <OriansJ>reepca: no but I can add it rather quickly <OriansJ>reepca: how would you like to manipulate HERE? <OriansJ>for example, I can add a function that will set HERE to whatever value is at the top of the stack <OriansJ>how does SET_HERE work for you reepca? <OriansJ>reepca: or are you looking for something more like writing out a byte to the address pointed by here? <OriansJ>reepca: on second though, looking at the forth standard CREATE is supposed to do that. <reepca>OriansJ: sorry for the delay, the most flexible would probably be SET_HERE like you said, though the traditional term I think is DP! or something like that. <reepca>DP! probably. The standard words ALLOT and C, can be built from that. <Apteryx>I'm having some woes with wicd-client. The DNS servers are often (always?) not auto-discovered. I think most connection managers are able to get those from the gateway (I'm not sure by which means/protocole). <Apteryx>So I have to input those manually as "static DNS" otherwise most pages are not found --> err, IPv4 pages aren't found (IPv6 such as Google, Facebook are found OK). Maybe the problem has to do with DNS servers supporting IPv6 and wicd not. <Apteryx>Another strange thing is that if I try restarting the networking service using "sudo herd restart networking", wicd-client cannot reconnect to my wifi. <OriansJ>reepca: UPDATE_HERE is done, looking up DP! definition now <reepca>DP! is just another name for UPDATE_HERE <reepca>I don't think it's technically standard. I know Gforth, for example, has a variable DP which can be modified just like any other. <OriansJ>reepca: patches are up, you now have your DP! <OriansJ>reepca: if you keep this up, I'll soon have enough new forth features to have to bump the version number :D <OriansJ>oh well back to the salt mines of x86 opcode encoding pain and suffering <catonano>I have an ad hoc environment with the gcc nad Freexl in it. I try to compile one of te Freexl example programs and I get: <catonano>"gcc: error trying to exec 'as': execvp: File o directory non esistente" <catonano>what should I add to the environment ? What's this "as" ? <efraim>do you have gcc or gcc-toolchain in your environment? <catonano>efraim: I don't know. I did "guix environment --ad-hoc gcc freexl" <catonano>so: ave I gcc or gcc-toolchain ? I guuess I have gcc <efraim>so it looks like its gcc, you need gcc-toolchain to really be able to use it <catonano>now it doesn't ffind freexl but that's anoter story <catonano>II am trying to compile a simple example script in C <reepca>Hey OriansJ, does the dictionary in your forth grow down or up? <catonano>ah i see. reexl should provide a .pc file <catonano>uuh that's marvelous. I just did pkg-config --cflags freexl <catonano>and got -I/gnu/store/7d13kzdjyiqwbms1rrrp1f1jy9lkqs6l-freexl-1.0.2/include <reepca>Ahhh I understand now, the subtraction is backwards compared to how it usually is in forth. Usually the thing being subtracted from is the second thing on the stack, and the thing being subtracted is on the top. <reepca>OriansJ: Also, the HIDDEN flag isn't currently being honored by FIND <rekado>“herd restart guix-daemon” stops all dependent services, then stops “guix-daemon” and then starts it again. <rekado>but all dependent services are now stopped. <rekado>should shepherd restart the dependent services instead of leaving them stopped? <efraim>isn't that an ongoing bug, that services that depend on a restarted service don't also restart? <rekado>I have never used “M-x debbugs-gnu” on this machine. When I run it for the first time it tries to do this: <rekado>soap-load-wsdl("/home/rwurmus/.guix-profile/share/emacs/site-lisp/guix.d/debbugs-0.14/Debbugs.wsdl") <rekado>(error "url-expand-file-name confused - no default?") <rekado>AFAIU Debbugs.wsdl ought to be looked up online, not locally <civodul>rekado: at one point our emacs-debbugs package was broken: it did not include that wsdl file, leading to an error like the one above <civodul>could it be that you just need to upgrade it? <catonano_>rekado: this happened to me too. Just guix pull, it fixes it <reepca>OriansJ: Also, 46 46 < is true for some reason... <reepca>OriansJ: But on the bright side, I got IF, THEN, ELSE, BEGIN, WHILE, AGAIN, and REPEAT all working. <reepca>OriansJ: And it turns out 46 46 <= is false. Looks like something got switched up there. <OriansJ>reepca: stack grows towards infinity and I'll get those fixed shortly <OriansJ>reepca: and I really appreciate the time you are spending finding my mistakes <reepca>OriansJ: It's actually a really comfortable way to get experience with forth internals <OriansJ>reepca: looking at 42 42 < ; the ANS specification says the value of true is to be all 0 and the value of false is to be all 1. Which is actually the reverse of the instruction set. That being said, I have absolutely no problem switching that around <reepca>Which ANS specification are you looking at? I see "A true flag returned by a standard word shall be a single-cell value with all bits set. A false flag returned by a standard word shall be a single-cell value with all bits clear." from http://lars.nocrew.org/dpans/dpans3.htm#3.1.3 <OriansJ>reepca: no problem, flipping it around for all comparisons now <reepca>OriansJ: Good stuff. There's still the issue with subtraction being backwards, though <jsierles>rekado: i've found for installing various R packages, i also need linux-libre-headers, gzip, sed, etc. have you found that? <jsierles>for example, just supporting installing 'tidyxl' from github with devtools. <rekado>I installed “gwascat” from Bioconductor using the manifest <rekado>it has quite a few dependencies and all of them could be built within that environment <jsierles>rekado: ok. maybe the correct solution is to install the imported package first, then from github <jsierles>but i don't see sed/gzip listed as deps for devtools or tidyxl. still, it requires them <jsierles>mainly i'm wondering if it's possible that some packages have dependencies that aren't mentioned in CRAN since they are usually available on a system somewhere (gzip etc) <rekado>jsierles: yes, DESCRIPTION files often do a bad job at listing system dependencies. <rekado>often the sys deps are listed as free-form text. <rekado>there’s not much the importer can do. <rekado>civodul, catonano Thanks, I’ll upgrade. <rekado>civodul: re sablevm: oh, I’ll try to fix this <rekado>civodul: there are configure flags to disable the use of the bundled libs (libffi and libpopt). <jsierles>rekado: fair enough. do you usually add them to the guix package definitions? <rekado>I don’t have to add gzip because it’s provided with the build system. <rekado>same for linux-libre-headers and the like <jsierles>rekado: ah. so what should i include to get the build system? <jsierles>rekado: i see what you meant now. but if i'm installing using install_github, i'll need all those deps in my profile too <jsierles>guess the solution is to not use install_github :P <rekado>I suppose you’re right. If you want to use install_github you may need to add these things to your environment. <rekado>too bad sablevm won’t build with the current version of popt. <jsierles>i added linux-libre-headers but still cant find linux/errno.h <rekado>jsierles: have you checked the environment variables? <rekado>jsierles: things like C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, etc <jsierles>rekado: i haven't set them, and they aren't set. <rekado>jsierles: I think they should be set. Don’t you have “gcc-toolchain” in the profile? <rekado>civodul: I built sablevm with our regular popt and libffi packages, and I fixed a reproducibility bug. <rekado>I’ll build the JDK to be sure that it all still works; if it does I’ll push the fix directly. <jsierles>rekado: ah yeah. sorry i'm not using the profile, but rather a docker image. so R is being called directly without any path settings <jsierles>been using .Renviron for that, so I'll have to add that as well <civodul>rekado: i managed to achieve NFS-like super-slowness using PRoot to "bind-mount" an sshfs :-) <rekado>that’s a curious thing to achieve. <efraim>I need a bit of help with Gemma on aarch64, I have to add a test for aarch64 in the makefile <civodul>efraim: looks like something for rekado or roelj no? :-) <efraim>civodul: not specifically, I just want to use substitute* to add in something like [ `uname -m` != aarch64 ] to override a flag without actually using a patch <efraim>For some reason aarch64 doesn't like -m64 <efraim>It works on x86_64 and apparently Mac, not so much on i686 or arm <efraim>I'll think about a patch, there should be a way to figure out 'uname -e(?)' In a portable fashion <jsierles>rekado: is there any plan to make 'guix pack' work with manifests? <efraim>civodul: I think the guix not building on aarch64 fixed itself <janneke>my system test (adding to make check-system) gets hit by the OOM killer <janneke>i can't seem to find how to increase the qemu memory size (or add swap), or even find the responsible qemu command <civodul>janneke: you mean the code that runs inside QEMU gets killed? <civodul>if so, you need to pass "-m 1234" to have more memory in QEMU <janneke>civodul: i thought i found it in system-qemu-image/shared-store-script <janneke>and added a memory-size parameter...but it seems still not to work, hmm <janneke>my first encounter with marionette-eval etc, very nice <janneke>i still suspect i'm not adding -m to the right qemu command, :-( <janneke>civodul: yeah, apart from my current oom woes it's great <civodul>sneek: later tell janneke look for "-m" in (gnu tests install) <thomassgn>is there any way to make guix delete the files for a package/derivation or forde a rebuild? <bavier>thomassgn: you can 'guix gc' the store path <thomassgn>humm, I get "guix build: error: build failed: repairing is not supported when building through the Nix daemon" from guix build and guix gc gives me "guix gc: error: build failed: path `claws-mail' is not in the Nix store" <thomassgn>I have nixbld in my groups, but nothing else, not even the nix derivation... <sneek>Welcome back janneke, you have 1 message. <sneek>janneke, civodul says: look for "-m" in (gnu tests install) <janneke>sneek: later tell civodul: thanks, my system tests now work beautifully, patch to configure memory-size submitted <janneke>thomassgn: you mean a file-name? guix gc -d file-name <thomassgn>janneke: yes, but it tells me the path cannot be deleted because it lives <janneke>weird, in GNU a path is a list of directories <janneke>anyway, then it must be referenced in a profile i guess <thomassgn>yes, but this is because the derivation in the path is in a profile, yes. But I don't understand how to remove it from a profile. <thomassgn>it's been removed from everything that is current, and is not in my PATH <janneke>thomassgn: delete the generation that references it <thomassgn>I also gc'd everything older than 1 month, which should this program, but it is still alive... <thomassgn>just tried gc on the profile referred to by the derivation, and it is also alive... <ryanwatkins>Hey, I am having some problems doing a pip install in GuixSD, should I make a guix package to handle these types of packages? <janneke>thomassgn: you can try: guix gc --references file-name <thomassgn>janneke: yes, it gives me a long list of store paths <janneke>thomassgn: why? you'll need no remove or clear all references before gc -d will work <thomassgn>janneke: ok, are you sure you didn't mean --referrers? <thomassgn>cause the list references gives me looks like dependencies of the package <thomassgn>but the list of referrers looks like stuff that depends on the package <janneke>thomassgn: oops, it should be --referrers indeed <thomassgn>mm, I tried removing the profile listed in the referrers, but it is also alive... <thomassgn>It might be the pango package that is missing though. <thomassgn>or some such. Cause it's the fonts that are just showing as squares. or some fonts. <janneke>thomassgn: you ask how to remove a directory in the store, and now you mention font problems -- it does not compute over here <janneke>how do i get to a package's source in the store? <janneke>i can do (with-store store (package-source-derivation store hello)) <janneke>and (derivation-inputs ..) on that, but then i get a flat list of inputs and yeah, the source is amongst it <janneke>possibly i need to do (package-source hello) and build the derivation of that? <janneke>how to turn a source into a derivation? there's no source->derivation <janneke>(with-store store (package-source-derivation store (package-source hello))) <janneke>why is there no -> in package-source->derivation? <janneke>(derivation-output-path (assoc-ref (derivation-outputs (with-store store (package-source-derivation store (package-source hello)))) "out")) <janneke>=> $26 = "/gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz" <thomassgn>janneke: you're right about that. I run claws-mail, and after a system upgrade a bunch of fonts were showing squares instead of symbols. I assumed this to be a problem with what claws was linked to or something, so I want to rebuild it. Which is where you arrived. When I pasted the output of guix gc I saw the same behaviour in icecat, which is when I started wondering about the fonts. <thomassgn>installing pango pulled in some ghostscript and other things, but the fonts are still not showing correctly. <civodul>thomassgn: does "fc-cache -fv" help? <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, janneke says: thanks, my system tests now work beautifully, patch to configure memory-size submitted <janneke>civodul: i'm starting to feel a bit bad about sending patches and not doing reviews...how do i get started with that? should i? <civodul>janneke: don't feel bad, but feel welcome to do reviews as you see fit :-) <civodul>i guess you could keep an eye on guix-patches and pick things that look easy or that you know well, for instance <janneke>civodul: thanks, Guix is *so* friendly! <janneke>i guess one of the first things to learn is who has push access <janneke>it's just, i get such good feedback on my patches, i am creative but often sloppy even when i try to do it right <civodul>janneke: at the same time i'm really happy to see how far you're going with Mes! <civodul>i wouldn't want Guix patch review to hinder that ;-) <janneke>i really hope and believe that OriansJ and myself will have something to show that really works, pretty soon <OriansJ>reepca: no problem, just finished patching that and patches are up. Thank you for your help improving stage0 forth <OriansJ>janneke: well, we both have done LISPs, you have a C compiler and I've written a Forth. So effectively we did hit the internet bootstrap meme trifecta <janneke>and i should also mention rain1, they're doing great things with simple c compilers too <OriansJ>janneke: absolutely, it was entirely thanks to rain1 that we now have TCC able to compile GCC <bavier>ACTION has been terrible at reading email lately <OriansJ>bavier: absolutely, reepca has been wonderfully helpful and with it lots of improvements <OriansJ>also a user friendliness patch for the stage0 vm <thomassgn>civodul: so the fc-cache -fv did some caching. But the fonts still show up as squares. I tried installing pango to no avail. The error messages points at font-inconsolata. Uninstalled it to see if that would make claws use a different font, but no. <OriansJ>bavier: stage0 forth only moves forward when someone: reports a bug, requests a feature or submits a patch. As I am currently focused on improving the MES bootstrap <civodul>thomassgn: what do the error messages look like? <bavier>OriansJ: my bootstrap path is based on Forth, so there might be some patches from me <OriansJ>bavier: I welcome all contributions* (* FSF approved licenses only) <bavier>of course ;) all my stuff is gplv3+ <OriansJ>bavier: works for me, I just grew so frustrated by a few forth devs who kept demanding I make it public domain and do a bunch of free consulting work for them too.... <civodul>thomassgn: does that happen if you run it as "guix environment --ad-hoc claws-mail --pure -- claws-mail"? <ng0>offloading question which is maybe implied in the manual: Do I have to explictly include guix in (packages) of a GuixSD system to get the (guix config) module? <ng0>I had offloading working once <bavier>OriansJ: heh, yeah, that would be frustrating. I have no such demands. :) <civodul>ng0: the 'guix' package always gets installed globally <ng0>expect that it isn't <civodul>normally you also have 'guile', so GUILE_LOAD_PATH is set <ng0>I have the guile load path, but the test fails for me <OriansJ>bavier: I look forward to your work :D <ng0>without installing guile there was no GUILE_LOAD_PATH <ng0>hence my bug I reported earlier <thomassgn>civodul: allright, so I uninstalled font-inconsolata, installed it again and then ran fc-cache -fv. now fonts are back no problem. <civodul>ng0: i would check if /run/current-system/profile/bin/{guile,guix} exist, and then check whether GUILE_LOAD_PATH contains /run/current-system/profile/share/guile/site/2.2 <thomassgn>it seems the font installed/did something more than reestablishing its store path link when I reinstalled it <ng0>civodul: for 2: yes. for 1: yes <ng0>I can send outputs to the bug report <thomassgn>thanks for helping civodul & janneke; even though I'm not sure what was wrong in the end. I see I can make the problem appear again by uninstalling inconsolata. Which is a bit strange seeing as claws looks like it's using fontconfig... <Muto>Just ordered a Guix T-shirt, that'll be nice to wear. <ng0>It could also be that I discovered some more oddities of using E21 <ng0>for example I ran all of this in gnome-terminal, which is the only sudo supporting terminal in our E21 currently. <ng0>I will repeat this in terminology now <ng0>okay, same error… good :) <ennoausberlin>Hello guix. I can not build the clisp derivation. I get Makefile:1434: Interpreted.mem Aborted <ng0>for some wicked reason my one GuixSD thinks it has to look in /usr/local/… for the machines.. maybe that's part of the problem <ennoausberlin>ng0: Dont know if this is related. I am going to sleep. Good night <ng0>It was a problem I mentioned earlie,r not related to yours