<roptat>PotentialUser-70, you're welcome :) don't hesitate to come and ask questions here if you have any :) <phil>Hi guix, I'm running guixsd via qemu and I can't seem change my resolution from 1024x768. <phil>I'm using the option -vga virtio <phil>and I've used xrandr to no avail <phil>xrandr -s 1440x900 is the command I thought would do the trick <lfam>phil: I haven't tried it, but some web searches suggest that using '-vga std' allows for higher resolutions. However, I don't have much experience with graphical QEMU so I'm not sure <lfam>Are you starting QEMU from the command-line? Or are you using a GUI tool? <lfam>Within the VM, does xrandr report any higher resolutions as being available? <phil>from what I read I think -vga virtio is currently recommended over -vga std <lfam>In general, virtio is the best for hardware that supports it <GNUtoo>it depends, -vga virtio is more efficient but it needs specific drivers (which are probably already compiled in linux-libre) <lfam>phil: Some results of my google search for 'qemu vga virtio resolution' suggest the use of `cvt` and then adding a new mode with xrandr <phil>hmm I don't have cvt on my system <phil>thanks for your help though <lfam>phil: It's part of the xorg-server package <lfam>`echo /gnu/store/*xorg-server*/bin/cvt` <lfam>I assume you have an xorg-server store item, since you are using X <lfam>That command will print the path of the cvt executable <phil>darn the instructions on reddit didn't end up working <lfam>When all else fails... check the QEMU manual :) <GNUtoo>phil: you could also try other -vga to see if it works, in order to narrow down the issue <phil>-vga std didn't work either <phil>it think it's just guix trying to tell me it wants to be running on metal :) ***Guest46587 is now known as txgvnn
<lle-bout>it seems that using --with-source=guix=$(pwd) on a guix checkout with offloading doesnt work because of permission errors, the file transfer must be preserving my local user permissions, sad <lle-bout>trying to achieve that using offload compute power: $ guix environment --with-source=guix=$(pwd) --ad-hoc guix <txgvnn>Does ibus input method work well on Guix system? <txgvnn>After migrating Debian to Guix few days ago. <txgvnn>I built ibus-unikey and install it. <txgvnn>Seems ibus loaded ibus-unikey engine <txgvnn>But after enabling it, I can not type Vietnamese <bdju>I searched emacs-ranger and didn't see it <bdju>wew, got nervous I didn't see a license file. they have the license at the top of the .el file <sneek>vagrantc was last seen in #guix one day and 1 hour ago, saying: baryluk: well, they'll need support in upstream guix before adding more ... arm64/aarch64 doesn't build on debian because guile-gnutls with guile-3.0 didn't successfully build for arm64. <efraim>sneek: later tell vagrantc dpkg and reprepro pushed! my pbuilder package is still a WIP. haven't looked at apt yet. <rekado>txgvnn: ibus has one or two stateful files that may refer to invalid locations. This is very frustrating to me whenever I want to use a Chinese input method. The “solution” here is to remove those files and configure the ibus settings once more. <txgvnn>rekado: Thanks, which files do you mention? <leoprikler>txgvnn: Assuming a fairly standard Guix system with gnome-desktop-service, you need to set GUIX_GTK3_IM_MODULE_FILE to have GNOME pick up ibus. From there onwards things should work fine using the language picker from GNOME. <leoprikler>I have the following in my zprofile to do that: export GUIX_GTK3_IM_MODULE_FILE="/run/current-system/profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache" <leoprikler>You might have to use "/home/…/.guix-profile/" instead of "/run/current-system/profile" and bash_profile instead of zprofile depending on where you've put ibus and which shell you're using <rekado>txgvnn: ~/.cache/ibus and ~/.config/ibus <txgvnn>leoprikler: I'm using sddm service with i3 :( <txgvnn>rekado: Ya, I removed those files and restart, ibus-unikey is showed in engine list <txgvnn>I think ibus-unikey doesn't work on ibus-1.5.22 (because on Debian buster, I use ibus-1.5.19) <txgvnn>is possible to install ibus-1.15.19? <txgvnn>I try to setup channels of guix point to `1e72a23d49` <txgvnn>that commit include ibus-1.15.19, then after guix pull <txgvnn>After `guix pull`, I still see ibus-1.5.22 when `guix package -s ibus` <leoprikler>Okay, so you installed both that plus ibus to your ~/.guix-profile, am I right? <txgvnn>On my user(id: 1000) I ran `guix package -i ibus` and `guix package -f ibus-unikey.scm` <txgvnn>And I have ibus-unikey is showed in `ibus list-engine` <leoprikler>I sadly know little about ibus on i3. How would you activate it? <txgvnn>in i3 config I have a line `exec --no-startup-id ibus-daemon --xim -d -r` <txgvnn>I tried to run a GNOME version from guix homepage, seems other engine works <txgvnn>But ibus-unikey is not, so I think about downgrade ibus to 1.5.19 to see. <leoprikler>Do you have other engines working with your setup? <leoprikler>While I know ibus-anthy to work with GNOME, it might be that your setup is broken. <leoprikler>Particularly XIM had a security issue a while ago and has been patched to no longer be reliable. <txgvnn>Could you show me how to use ibus-anthy? I've just installed it <txgvnn>Oh, homepage provide a XFCE verison in VM, not GNOME. I remember wrong <leoprikler>Before that, do you have `export XMODIFIERS=@im=ibus` in your i3 config? <txgvnn>ya, I have 3 lines export that ibus-setup say in my bashrc <txgvnn>I try `Geek` input method, I doesn't work on my I3, it works on XFCE. <leoprikler>I sadly don't know how the VM is set up, you'd have to ask someone else for that. <leoprikler>You could try just setting up xfce and checking whether it works <leoprikler>Or you could set up GNOME and `export GUIX_GTK3_IM_MODULE_FILE=...` <txgvnn>Ah, It works after I un-tick `Use system keyboard layout` <txgvnn>but my ibus-unikey doesn't still work :( <leoprikler>So you do have some input methods working now, right? <txgvnn>I tried to package this package, but I don't master guile <txgvnn>this repo doesn't have configure file <leoprikler>Instead of #:configure-flags, you'll have to set #:make-flags to set PREFIX <leoprikler>also you need to delete the configure phase, which goes like this: <leoprikler>#:phases (modify-phases %standard-phases (delete 'configure)) <leoprikler>[if you need to add or remove more phases, you just add those commands into modify-phases <txgvnn>Right now, I have to use Emacs to write Vietnamese then copy paste to send =)) <leoprikler>Well, you won't be able to use ibus in Emacs anyway, so you'd better get used to that ;) <txgvnn>Actually I hate use ibus, maybe ibus-unikey is not good for us. That why we have some engine as ibus-bogo (I don't try it yet) <rekado>leoprikler: I remember using ibus in Emacs in the past. Has that changed? <txgvnn>But Emacs have vietnamese-telex built-in, that is amazing. <txgvnn>I don't use ibus in emacs, I use vietnamese-telex input in Emacs. <leoprikler>rekado: How did you do it? ibus.el? XIM is currently broken AFAIC. <rekado>it’s been a long while; I don’t remember. <rekado>but I’ve never touched the built-in input methods Emacs provides <leoprikler>I challenge you to ibus-libpinyin into Emacs right now <rekado>leoprikler: my ibus setup has been borked for a while, so there’s little sense in trying it in Emacs now :) <rekado>I think it’s been like this since a Gnome upgrade that integrated ibus more tightly <leoprikler>Well, I have a working GNOME ibus, but within that year XIM broke, so… <rekado>any idea how it broke so we can unbreak it? <leoprikler>rekado: With regards to GNOME ibus, I wrote 44354. <leoprikler>As for XIM, I do have a vague idea, but I don't know if it'll work. <janneke>dannym: i have hard reset mes@wip and gitlab/tinycc@mes-0.23, added test-compare.c and updated ROADMAP <leoprikler>rekado: The problem is, that 72c5f71cd45c860299950cd058d8e13b87375741 totally disables XIM for Emacs. <leoprikler>Whereas my patch, which Guix does apply to the source but is disabled by 72c5... creates a XIC style with XIMPreeditNothing | XIMStatusNothing. <PotentialUser-76>I have packaged bandwhich and all its dependencies (which are numerous). I wanted to make it ready for submit but i didnt make the time yet. Before I completeley forget about it and it goes into obscurity, maybe someone else already worked on the same thing and can re-use stuff https://github.com/doncatnip/guix-packages ***zap is now known as zzappie
<wehlutyk>is anybody else having trouble building julia 1.5.3? <nixo_>wehlutyk: Hi! It did work for me <wehlutyk>I'm on 1f9bf4e893165485cbfee51af1c0dcfffc8ec147 (pulled yesterday night) <nixo_>yeah the output path matches mine (/gnu/store/in3vdhdc6vbn1pgjwws8zhgrkxpn5hnv-julia-1.5.3) <nixo_>(My second build is now running tests, it will take some time) <bqv>So I want to have an adapter sort of thing, so the guix store is actually just my nix store under the hood, I guess that's insane, right? <leoprikler>bqv: not quite, the guix store was forked from the nix store <leoprikler>there might be differences in their implementation (there likely are) <bqv>But they are now incompatible <bqv>The nix store configure flag breaks, iirc <bqv>I'm not entirely sure what the incompatibility is though, beyond the daemons <bqv>My curiosity comes from that I have a guix store in my home directory <bqv>And I'm thinking I could have it in a nix derivation <janneke>dannym: so, the mescc-compiled mes-tcc cannot compile (0 < -1) correctly <bqv>That, obviously, is insane, so split it by storepath <bqv>Thats just an adapter <dannym>janneke: Yeah, we'll probably have to put some prints into the compile-time constant evaluator (which I what I think this uses). Eventually this thing makes a mistake somewhere <nixo_>(wehlutyk: running LinearAlgebra/addmul) <dannym>janneke: (Right now my Internet crapped out so this laptop is on cellphone internet via USB tethering which means I cannot reach banana (via dynv6 host); working on it) <vits-test>is gnome de uses xorg by default so far, in guix? <dannym>I have local tinycc sources on the laptop though <dannym>There, the token for '<' is TOK_LE <dannym>And that's used in arm-gen.c and il-gen.c and tccasm.c and tccgen.c <janneke>was hesitating to recompile with lotsa debug printing, to find the instructions/path <dannym>The integer constant optimization is in tccgen.c, function gen_opic <dannym> case TOK_LT: l1 = gen_opic_lt(l1, l2); break; <dannym>static int gen_opic_lt(uint64_t a, uint64_t b) <dannym> return (a ^ (uint64_t)1 << 63) < (b ^ (uint64_t)1 << 63); <dannym>Did we break that when we assumed that we can use a 32 bit register for that? ;) <civodul>we'd add a build phase that runs ldconfig <luis-felipe>leoprikler: I can use ibus-anthy in Emacs launched with emacs -nw in GNOME Terminal, but it does not work in Emacs GTK+. <janneke>dannym: it was my intention to move all 64bit stuff behind #if HAVE_LONG_LONG <janneke>dannym: and in the #else just use a 32bit variant <janneke>dannym: see "540ba0b4 bootstrappable: HAVE_LONG_LONG." <janneke>oh that's shorter than i remembered...hmm <dannym>Alternative would be to substitute 63 by (sizeof(uint64_t) * 8 - 1), but that would be a little... magical, and people would be tempted to simplify it back ;) <dannym>In both mescc and non-mescc, I mean <dannym>So better to also do a HAVE_LONG_LONG check here, to be explicit about it <leoprikler>luis-felipe: no, you have to install anthy at system level for 44354. 35610 wants user-level installation <janneke>i would love to have upstream #if HAVE_LONG_LONG... <dannym>janneke: Yeah, it would be better to have such a check upstream. <dannym>According to the C99 standard (ISO/IEC 9899:1999), long long needs to be "at least 64 bit wide" <dannym>I'm trying to find whether it's mandatory <nixo_>wehlutyk: it surupassed core without segfaulting <dannym>What I'm saying is I think that they are wrong in assuming it's bit 63 in general <dannym>Or is it? uint64_t is perhaps different to unsigned long long *dannym loads C99 standard via cell phone internet... <janneke>hehe, yeah i saw banana go away a couple of hours ago... <dannym>Aha, C99 7.18.1.1 specifies uint64_t to be *exact*-width integer types <dannym>So since we can't do that I think we shouldn't have uint64_t in our header files at all. This way we'd find problems much easier <dannym>So I'd comment out from mes include/stdint.h (with comment on why) <efraim>brettgilio: according to 'guix lint' et and eternalterminal are the same package, just at different versions and different modules. want to fix it up? <dannym>/ typedef unsigned long long uint64_t; we cannot provide this type in mescc <dannym>/ typedef long long int64_t; we cannot currently provide this type in mescc *efraim checks all the things <janneke>dannym: eh...that's OK for now, possibly, but we can't do that for real? <dannym>janneke: Well, either that or we implement 64 bit integers in mes <brettgilio>Should I just mark it deprecated in favor of eternalterminal? <janneke>dannym: a properly compiled tcc, using HAVE_LONG_LONG, should have uint64_t <dannym>If uint64_t is specified to be 64 bit (it is) and we give users a 32 bit integer, that's not going to end well <dannym>Where in the bootstrap chain is the problem? <efraim>brettgilio: probably? but check (somehow) for recursive module imports <dannym>Is it tcc compiling tcc that messes up? <efraim>I guess it'd be better to move it first and then mark it deprecated. I'm not sure actually <janneke>mes-tcc compiles itself -> boot0-tcc .... -> boot6-tcc (fixpoint) <janneke>defining HAVE_FLOAT and HAVE_LONG_LONG eventually <janneke>so, the mes C library needs to support some 64bit for the rest of the bootstrap chain <janneke>we could move all uint64 behing HAVE_LONG_LONG, that could help (but that's some work ;) <dannym>Ok then I would suggest to check whether unsigned long long is big enough before doing the "typedef unsigned long long uint64_t" in stdint.h <dannym>#if sizeof(unsigned long long) == 8 <dannym>typedef unsigned long long uint64_t; <dannym>Or if that doesn't work, there should be <dannym>#if __SIZEOF_UNSIGNED_LONG_LONG__ <dannym>#if __SIZEOF_UNSIGNED_LONG_LONG__== 8 <dannym>Otherwise we are just asking for trouble I think <janneke>yes, this isn't a "bug" as such, this is caused by lack of oversight/vision <vits-test>can't wait for next guix-days' beard contest <vits-test>brettgilio: wow, another cluster-funk domain :) <brettgilio>vits-test its just a front-facing domain for my media uploads since I have a few people using this IRC client and dont want my personal domain tied to anything they might post :) <dannym>(it's __SIZEOF_LONG_LONG__ in gcc) <bqv>Maybe I'll just try run guix with /nix/store, see where it chokes <janneke>nice, we can add that to preprocess.scm <bqv>Whats the storedir variable? <dannym>Apparently we don't provide those in mescc... at least not in mescc/preprocess.scm <wehlutyk>nixo_: thanks, I'll try again this evening <bqv>Nevermind... whats a command I can run that doesn't attempt to edit the store? <dannym>p.s. gcc -dM -E - </dev/null |grep __SIZEO <bqv>ice-9/boot-9.scm:829:9: In procedure catch: 'guix-daemon' is too old, please upgrade () <bqv>Any guix devs, is there a difference between the on-disk formats? <bqv>E.g. Could I run guix-daemon with a nix-store <bqv>And nobody's gonna respond so I'm gonna have to just test it aren't I... <bqv>Yeah but then my stuff gets buried, and I don't expect people to read scrollback... <brettgilio>To answer your question. No you cant use the nix-store with the guix daemon system. Our derivation system is not identical <mroh>wtf, builder for `ymq6971vxd8k1vhx8qp13al2lp3y11rc-gnutls-dane-3.6.12.drv' failed with "You need openssl to run this test." <bqv>brettgilio: I might ask, what is the difference? And when did the two diverge? I presumed the on-disk system at least would remain the same *chrislck is a gnucash hacker and would be keen to assist updating the gnucash package. but very little guix skills. off to bed soon, so, anyone please write a short summary and i'll pick up in the morning <mroh>haha, the guix repl: "Reciprocation, Evaluation, Procrastination, Loop"... I can't stop laughing ;) <blendergeek>I just tried to install the new Guix 1.2 release. I get an exception when it attempts to partition the drives. <wehlutyk>When trying to debug a failing build (in my case: `./pre-inst-env guix build python-pyside-2 --keep-failed`), I create an env to explore failing commands: `./pre-inst-env guix environment --pure python-pyside-2 -C`, but the paths of some dependencies don't match the paths used in the build container (i.e. running `ctest` fails because the /gnu/store/... path is differente to the build one). How can I get the exact same <roptat>wehlutyk, maybe try with --no-grafts <dannym>janneke: I think __SIZEOF_LONG_LONG__ < 8 is not allowed by C99, so we should not define it at all in mescc for the time being <roptat>blendergeek, not sure how to help... if you don't get an answer here, consider sending a bug report to bug-guix@gnu.org <roptat>"which unlike French wine, did not age well with time" :) <zimoun>roptat: cool! Do I tweak in place? <nckx>blendergeek: If you report the bug, please include the output of ‘fdisk -l /dev/sdX’. <civodul>bqv: guix-daemon and nix-daemon are similar but incompatible so this won't work <bqv>civodul: so I heard. I'm curious how they diverged? <vits-test>brettgilio: ah, 8081 -> 81. i constantly mess router's and box's. so beard's on 80 for now. <nckx>vits-test: Time to add ‘beard’ to /etc/services. <civodul>bqv: different builtin derivation builders, new RPCs, interfacing with Scheme bits of the daemon, things like that <brettgilio>bqv They diverged with the implementation of Guix's derivation calculator in Guile. <nckx>(Why are we sending brettgilio beard photos now?) <nckx>You're a day too late buddo. <brettgilio>I don't think we can say hard when they became incompatible bqv, more so that they were never meant to maintain cross-compatibility with each other <vits-test>nckx: *proudly* i use 'sleep 3, or .jpg downloads only partially. <nckx>vits-test: I noticed, had to try 3 times. Figured you were using netcat in a loop. <zimoun>roptat: parfait! j’ai ajouté 2-3 liens dans le chapeau et rephraser un paragrapge qui me paraissait bizarre à la lecture. Bon, il y a des traductions qui me font bizarres mais bon c’est la bonne traduction; comme «chaîne logistique logicielle». <nckx>Shame. But then that would need a much longer beard to pull off. <vits-test>i'd read about reuseport, and other things, like 'poll. but not more. <rekado>civodul: this looks like a reasonable change. Can __strdup return NULL? If so, we may need to check and return LD_SO_CACHE instead. <rekado>I suppose it’s unproblematic if $ORIGIN/../etc/ld.so.cache doesn’t exist *rekado prepares screenshots for the blog post <nckx>blendergeek: ...and your mail arrived immediately. Thanks. <nckx>ss2: Did your mail ever make it through? <leoprikler>PotentialUser-32: ad 44870 `guix package -i polari -u` <leoprikler>Though the hint should be rewritten to "Try upgrading lollypop first." <nckx>That doesn't cover all cases, but ‘simultaneously’ should. <roptat>zimoun, c'est bon pour toi ? je soumets ? <leoprikler>rekado: w.r.t. Emacs and XIM. I just tested emacs-next-pgtk and as you'd expect, GtkIMContext works great <helaoban>hey guix! I'm unable to build guix on master: "ice-9/eval.scm:293:34: In procedure allocate-struct: Wrong number of initializers when instantiating #<record-type <gexp>>" <helaoban>that's what running `make` gets me. any ideas? <vits-test>helaoban: idk. did u tried make clean + ./bootstrap && ... again? <dannym>raghavgururajan: I think I'll merge your large patchset 42958 to master next week on Monday or so, now that Guix is released. <helaoban>vits-test: ah, I didn't run clean, I'll try that now. <lfam>helaoban: Also, make sure the Git tree is "clean". That is, without any local changes <raghavgururajan>dannym: Thanks a lot. Sorry for not getting back to you on Telegram. I got pre-occupied. <nojr>hello, I just watched several Guix day videos, they were excellent. <helaoban>lfam: ok I'll run `git-clean` as well, I do have some crap lying around. <nojr>the one that stood out the most was the maven build system one <nojr>at least for me, since the goal is to build android apps. this may not be related but does anyone know if it's possible to build android apps with kawa scheme? <boer>good day! new guix user here, I'm a few hours in, and am not Guile/Scheme coder. I'm trying to upgrade Elixir (I really need 1.11, that's the whole reason I'm trying out guix, to build a portable environment as a CI artefact). 'guix refresh elixir' says "guix refresh elixir ✘ 20-11-25 19:40:39 <boer>gnu/packages/elixir.scm:36:13: elixir would be upgraded from 1.10.4 to 1.11.2" so that's good. I though it might be as simple as copying said elixir.scm, bumping the version number, and running 'guix package install -f /path/to/my/modified/elixir.scm' <boer>alas, it says "guix package: error: install: extraneous argument". It does that even with the original elixir.scm from /gnu/store <nojr>I feel that an ideal setup would be to build/distribute android apps with guix and kawa scheme <boer>Is there some kind of processing step that must be applied to the definitions in gnu/packages/*.scm? <boer>(before they become guix-installable) <helaoban>vits-text, lfam: make clean did the trick. looks like i'm just too dirty for guix. <dannym>janneke: I improved stdint.h a little bit more on mes wip <lfam>It takes a few minutes to get started but will pay dividends in the long run <lfam>The basic idea is 1) clone the Git repo 2) build Guix from the Git repo 3) make your changes 4) Use Guix from the Git repo <vits-test>boer: `guix package -f file`, `guix install` is shorthand for `guix package -i` <boer>Hmmm yes I saw those but I was thinking it's just a version bump, won't it do all the build magic for me? <boer>so those scheme files I've been looking at (elixir.scm) isn't really a ready to go package. <boer>not in the way that /gnu/store/kbff9bh68q1s1mcra6v3sa3ip83xah0s-doc/package-hello.scm is. Because that one can be installed straight through `guix package -f`. <vits-test>boer: -f needs the last thing in the file to be a "package object" <vits-test>cat file.scm -| (define package ...) package <janneke>dannym: thanks, i was wondering about that <boer>I see. there's indeed a difference between package-hello.scm and elixir.scm in that respect <boer>the former indeed has a package object as its last thing, while in the elixir file, it's some magic "(define-public elixir" that's enclosing the package object. or generating it, or something. I'm very new to scheme/guile/lisp ***flor_ is now known as flor
<boer>I was getting my hopes up when 'guix refresh elixir' said "sure, totally upgrade". I'll go read the developer manual then ;-) Thanks <vits-test>boer: also packages can be manipulated: (package (inherit emacs) ...) <vits-test>chances are, u can replace some lines with hash and version this way, then package -f. but refresh supposed to make things easier (for custom channels? idk). <boer>i was also getting my hopes up with this: guix refresh -u elixir bt it said "elixir.scm:34:2: error: cannot download for this method: #<procedure git-fetch (ref hash-algo hash #:optional name #:key system guile git)>" <boer>thanks vits-test and lfam. <lfam>Please feel free to ask for more help or advice :) <boer>well, I skimmed the "how to build guix itself" manual but that didn't make me much wiser about why there is this `elixir.scm` file lying around that looked so promising for a quick hackbump but doesn't work that way. what is it for, then? *vits-test (*pretends that used 'refresh' himself*) <lfam>boer: I'm curious, where did you find an elixir.scm file? <helaoban>I'm trying to insert some unicode characters in a package description (emojis, they are part of upstream description) using the @U{hex} texinfo command, but guix no likey. <helaoban>./pre-inst-env guix search <my-package> fails with "Throw to key `parser-error' with args `(#f "Unknown command" U)'." <nikita`>who uses emojis in package descriptions <nikita`>that's really meta because I don't see it on one screen but on the other I do :D i mean, even when someones does I leave them out (not for guix nowadays) <helaoban>I'm not going to spend more than 2 minutes on this, I can just remove the emojis, I'm more curious about texinfo under guix not supporting certain texinfo commands, if that is indeed the problem... <lfam>I guess I am not seeing the emojis on that page... <lfam>In any case, if they are really germane to the description, we can dig in, but if they are extra, it's fine to leave them out <lfam>Yeah, not sure what's up there helaoban <lfam>You could try adding them to the Guix manual 'doc/guix.texi' and then `make doc/guix.texi` or `make doc/guix.html` to check the rendering <roptat>we use texinfo for the manual, but we use (texinfo) for the descriptions I think <roptat>meaning, the guile implementation, which is lacking support for a lot of commands <roptat>so we're actually limited to a subset of texinfo in the descriptions <helaoban>kewl, so I'm just going to murder those emojis and get on with my life. <nikita`>if I'd ever want it on my work laptop, is there a copr for guix now? <lfam>We would not need that in the description anyways helaoban ***amiloradovsky1 is now known as amiloradovsky
<nckx>No blessed ‘community channel’ though. We encourage users to contribute anything remotely sane to Guix proper. <nikita`>no i mean that's one way you install software on fedora. <nikita`>i stopped working on guix around the time channels came around, I'm aware of them :) <nikita`>basically what i'm asking is if there is a semi official way to get guix on fedora or if it's just instralling from source now <lfam>`tar xf && mv gnu / && mv var/guix /var` ;) <lfam>Maybe there is a better way! I love that way, however <nckx>I'd recommend the installer script, it's easier for us to support than ‘hi im using rando lantw pkg’. <nckx>nikita`: That's twice what I found. <nckx>Apart from ‘probably personal do not use’ one. *nckx new to this copr thing, so it's basically the FUR. The fuzz. I guess I get the name. <roptat>I installed guix with the installation script on my fedora at work, worked well <nikita`>I'm new to fedora, didn't use it since its very first version and now I use it because someone gifted me a less broken laptop with it. <nckx>nikita`: AUR for Fedora. <roptat>although, you need additional steps if you use SELinux <luis-felipe>rekado: Sorry to bother you, but are the lyrics licensed or in the public domain? (I'd like to print them in the back of my shirt) <vits-test>luis-felipe: a shirt: "... is free software: you can redistribute it and/or modify it under ..." and a bit of text. <user_oreloznog>luis-felipe: I think that Guix is under the GPL license, and derivative productions should inherit the same license... But if anyone can confirm? <lfam>I think it's a stretch to say that a song about Guix is derivative of it in this sense <luis-felipe>For example, Wurmus said the song could be CC-BY-SA or public domain, but I don't know about the lyrics... <user_oreloznog>luis-felipe, do you know how is licensed your own work? I mean the picture... <leoprikler>I have seen GPL'd artwork in the wild. It happens. <rekado>luis-felipe: at least my part of the lyrics can be CC-BY-SA or CC-SA or public domain <luis-felipe>user_oreloznog: it's CC-BY-SA 4.0. The source SVG has license information as metadata. <rekado>luis-felipe: for the typo poem you’d have to ask vagrantc; if the spelling of the words were considered derivatives of the Guix sources (which is highly doubtful) then you’re still in the clear to copy them. <rekado>I think the threshold of originality here is rather low (no offence intended), so from the point of view of copyright this is not really worth the discussion. <rekado>the creative act here was the idea (which in and of itself is independent of the actual words) and the rearrangement of the words to lines. <luis-felipe>rekado: I thought better safe than sorry, specially because I'll print them in stuff for sale. <roptat>I have an alist of key-values, and a guix record type that I want to fill in from that alist. Say I have the fields a and b, so if the alist is ((a . 1) (b . "a")), I want (my-record (a 1) (b "a")). I also want to make sure the alist doesn't contain keys that are not in the record type, and most fields in the record type have a default value. <roptat>like if the alist has a key that is not a field in the record, I want some sort of exception <rekado>luis-felipe: great idea to put this on t-shirts and sell them! I hope one day I’ll see one in the wild :) <roptat>especially since in the record construction, I don't think a and b are symbols, are they? <luis-felipe>sneek: Later tell vagrantc: Sorry to bother you, but what's the license of the poem you contributed to "Ode to One Two Oh"? I'd like to print the lyrics in apparel for sale... <civodul>roptat: there's an alist->record procedure in (guix records) <civodul>but no, you can't "transform" an alist that exists at run time to code that needs to exist at compilation time <civodul>(if i understand correctly what you wrote) <lfam>My ideal shirt would include the drawing and the funny "REPL" acronym <lfam>Oh, I suppose that's the whole song, plus the poem :) <civodul>rekado: BTW, will the post also include pictures of the stick, the pile of cables, and you hacking in the dark with a pile of stuff on your laps? :-) <rekado>but I already started cleaning up the mess that was once called a room, so it’ll be uncharacteristically neat <roptat>so... how could I fill in the record from the alist? <roptat>I could use the make function, but that means I need to specify every field <janneke>dannym: i have a hacky patch for tcc that uses HAVE_LONG_LONG to remove all *int64 things <janneke>dannym: it's much bigger than i hoped, but maybe it's a good thing, i'm still not 100% convinced <janneke>dannym: it seems though that they indeed only use *int64 if the code needs 64 bits, so it could be a very good thing <janneke>however, tinycc does not define __SIZEOF_LONG_LONG__, so ... for the bootstrap to finish with long longs, (testing on x86 now), we need to help tcc define that somewhere <roptat>oh, I could use a macro that creates the record type and the alist-> procedure <dannym>janneke: Even if we don't keep it like that, at least it lets us see all the places needing 64 bit ints in the source code of the compiler, and hopefully remember it ;) <dannym>So I think all in all it's still fine. <dannym>And for the places where tinycc does bitshuffling tricks using uint64_t it's not going to work with a 32 bit type substituted anyway <janneke>right; pushing to gitlab, still pretty hacky but it bootstraps on x86 <dannym>I have to say I'm surprised to see it use uint64_t in that way--must be a pretty new compiler that wasn't written with 32 bit systems and older compilers in mind--those totally *don't* have a long long. <janneke>yes...OR...someone patched that in later <janneke>it's a shame, in a way, to depend on 64bits <dannym>I mean you can kinda fake 64 bit on 32 bit systems, but it still makes everything more complicated <dannym>But x86 were *16* bits in the beginning <dannym>(faking 64 bits on 16 bits is going to suck) <dannym>It wasn't? I thought it supports all kinds of weird systems <janneke>iwbn to support long long on mescc, get rid of all this hackery... <dannym>As I said, a lot of compilers did that by using a struct they were copying around and operator overloads at runtime :) <dannym>A lot of funny alignment requirements on windows were because of those structs <dannym>typedef struct { unsigned long low, high; } long_long; <dannym>unsigned_long_long operator+(unsigned_long_long a, unsigned_long_long b); <dannym>That way the compiler needs only to support struct return and struct copying on call and then long longs magically work :) <dannym>Without the compiler knowing anything about how they work <dannym>Even in 2020, mrustc uses a trick like that to do 128 bit integers right now :) <dannym>The only downside is that the alignment is wrong <dannym>But we don't support that alignment anyway :) <dannym>C alignment is basically done as if the struct containers were not there, so an unsigned_long_long field used somewhere (like struct foo { char c; unsigned_long_long l; };) is gonna be aligned to a 4 Byte boundary (instead of 8 Byte boundary as SysV expects for unsigned long long) <janneke>hmm but mescc doesn't do struct-by-value as parameters; sort of for the very same reason <dannym>Yeah, it still complicates things <dannym>I wouldn't add 64 bit ints to a bootstrap compiler if at all possible <civodul>roptat: there's a few uses of alist->record, you can check whether it's to your taste <dannym>But I guess it depends on what tinycc source code uses... <Formbi>dannym: I heard somewhere that GNU decided not to support 16 bits right from the start <janneke>dannym: okay, (0 < -1) now compiles correctly <roptat>when I try to do something like (alist->record '() make-my-record '()) I get "wrong number of arguments" for make-my-record (I would like it to simply fill the record with default values), and when I use my-record instead, I get a syntax error <janneke>itoa.c still doesn't (and compiling boot0-tcc still segfaults) <janneke>so, not the last bug, but good progress <janneke>dannym: and it could very well be that one of my #if HAVE_LONG_LONG alternatives is incorrect; i should look into that <janneke>gcc-compiled ./arm-unknown-linux-gnueabihf-tcc has the same problem; i guess that's good for us <dannym>janneke: In tccasm.c you imo made a mistake <dannym> /* GAS compare results are -1/0 not 1/0. */ <dannym>So the reason for their cast was to make it signed, not to change the size <dannym>In tccgen.c you have the following thing that I would make more paranoid: <dannym> uint64_t l1 = c1 ? v1->c.i : 0; <dannym> uint64_t l2 = c2 ? v2->c.i : 0; <dannym> int shm = (t1 == VT_LLONG) ? 63 : 31; <dannym>+ uint32_t l1 = c1 ? v1->c.i : 0; <dannym>+ uint32_t l2 = c2 ? v2->c.i : 0; <dannym>I think in the #else I would make it fail if t1 == VT_LLONG--it's still valuable information <dannym>Maybe that's being too paranoid--but otherwise I forsee a bug the other way around: it's getting a 64 bit value (from somewhere (?)) and then it's checking bit 31 for the sign ;) <janneke>i think paranoid is good, esp. now that we're hunting for bugs 
