Re: Racket REPL not working
Simon Tournier writes: > Hi, > > Sorry for the late reply. > > On Sun, 02 Jul 2023 at 15:57, "Philip McGrath" > wrote: > >>> ck@brak ~ $ guix shell --no-grafts racket -- racket --version >>> Welcome to Racket v8.8 [cs]. > >> I'm not exactly sure how to do this, but can we determine which grafts >> are otherwise being applied to `racket` in your environment? Hopefully >> knowing what is being grafted will help to narrow down how grafting >> might be going wrong. > > What about > > guix shell -C racket -- racket --version > > ? > Hello, I cannot test anymore because my Racket is on 8.9 now. Good thing is that I don't have any segfaults anymore though :). Chris
Re: Racket REPL not working
Hi,
Sorry for the late reply.
On Sun, 02 Jul 2023 at 15:57, "Philip McGrath" wrote:
>> ck@brak ~ $ guix shell --no-grafts racket -- racket --version
>> Welcome to Racket v8.8 [cs].
> I'm not exactly sure how to do this, but can we determine which grafts
> are otherwise being applied to `racket` in your environment? Hopefully
> knowing what is being grafted will help to narrow down how grafting
> might be going wrong.
What about
guix shell -C racket -- racket --version
?
Well, about the grafts part,
$ guix build racket -d
/gnu/store/c0255s7y8f4ajzvspx8v9qbm1g3id3xb-racket-8.8.drv
$ guix build racket -d --no-grafts
/gnu/store/np4dqp1bqxwpbzdjmji81bsddygfzf81-racket-8.8.drv
then let open the first derivation,
--8<---cut here---start->8---
Derive
([("out","/gnu/store/k70zkb4r4y2lixr4bpf48hd33xldyb2a-racket-8.8","","")]
,[("/gnu/store/476wh1gii4ijga8cw24nxp6q4jc9x4hl-gtk+-3.24.37.drv",["out"])
,("/gnu/store/cgdn2v19i6qwy0kisnykv9zvphl5lhxa-gtk+-3.24.37.drv",["out"])
,("/gnu/store/jday1gpvdk3ccf034vcja567bjp0n4z1-glibc-utf8-locales-2.35.drv",["out"])
,("/gnu/store/n34gnfqh8zn72z0lra59rgv6skm47i39-guile-2.0.14.drv",["out"])
,("/gnu/store/np4dqp1bqxwpbzdjmji81bsddygfzf81-racket-8.8.drv",["out"])
,("/gnu/store/xg9dfhixaw5fb36g7jz222jl99gr4dxz-module-import-compiled.drv",["out"])]
,["/gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import","/gnu/store/jww1rq3s54m6k3yf0ixqqqs2rn86hh32-racket-8.8-builder"]
,"x86_64-linux","/gnu/store/4p1l5bdxxbyyqc3wh0d07jv9rp1pdcy7-guile-2.0.14/bin/guile",["--no-auto-compile","-L","/gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import","-C","/gnu/store/yk897hj2p5mdx6hw47s90n8x9pn6s36c-module-import-compiled","/gnu/store/jww1rq3s54m6k3yf0ixqqqs2rn86hh32-racket-8.8-builder"]
,[("allowSubstitutes","0")
,("guix properties","((type . graft) (graft (count . 1)))")
,("out","/gnu/store/k70zkb4r4y2lixr4bpf48hd33xldyb2a-racket-8.8")
,("preferLocalBuild","1")])
--8<---cut here---end--->8---
Ok, there is /gnu/store/np4dqp1bqxwpbzdjmji81bsddygfzf81-racket-8.8.drv
which is the non grafted derivation. Now, let open the builder,
--8<---cut here---start->8---
(begin
(use-modules
(guix build graft)
(guix build utils)
(ice-9 match))
(define %outputs
(list
(cons "out"
((@
(guile)
getenv)
"out"
(begin
(setenv "GUIX_LOCPATH"
"/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-2.35/lib/locale")
(setlocale LC_ALL "en_US.utf8"))
(let*
((old-outputs
(quote
(("out" . "/gnu/store/z0a42imbmy6563wvdavapb6c8vbi1s1z-racket-8.8"
(mapping
(append
(quote
(("/gnu/store/2n2kprz35a19ibs5kbjsb3k4cdl69q2w-gtk+-3.24.37" .
"/gnu/store/c1vhs1874xiqmx0789jinrpbx63ks35y-gtk+-3.24.37")))
(map
(match-lambda
((name . file)
(cons
(assoc-ref old-outputs name)
file)))
%outputs
(graft old-outputs %outputs mapping)))
--8<---cut here---end--->8---
and thus racket is grafted with gtk+. However, it seems the same
version, and thus, I do not know if it is similar as #47064 [1].
It works for me on foreign distro as Ubuntu.
1: https://issues.guix.gnu.org/47064
Cheers,
simon
How to find what grafts have been applied? [Was: Racket REPL not working]
Can anyone offer advice on how to debug a potential grafting problem? (It seems like it might be something similar to <https://issues.guix.gnu.org/47064>.) Unfortunately I haven't been able to reproduce the crashes on my system. Philip On Wed, Jul 5, 2023, at 12:16 AM, Chris Keschnat wrote: > Sorry, I would not know how to find that out. > > "Philip McGrath" writes: > >> On Sun, Jul 2, 2023, at 12:12 PM, Chris Keschnat wrote: >>> This works >>> >>> ck@brak ~ $ guix shell --no-grafts racket -- racket >>> --version >>> Welcome to Racket v8.8 [cs]. >>>> >> >> That's very useful! >> >> I'm not exactly sure how to do this, but can we determine which grafts >> are otherwise being applied to `racket` in your environment? Hopefully >> knowing what is being grafted will help to narrow down how grafting >> might be going wrong.
Re: Racket REPL not working
Sorry, I would not know how to find that out. "Philip McGrath" writes: > On Sun, Jul 2, 2023, at 12:12 PM, Chris Keschnat wrote: >> This works >> >> ck@brak ~ $ guix shell --no-grafts racket -- racket >> --version >> Welcome to Racket v8.8 [cs]. >>> >> > > That's very useful! > > I'm not exactly sure how to do this, but can we determine which grafts > are otherwise being applied to `racket` in your environment? Hopefully > knowing what is being grafted will help to narrow down how grafting > might be going wrong.
Re: Racket REPL not working
On Sun, Jul 2, 2023, at 12:12 PM, Chris Keschnat wrote: > This works > > ck@brak ~ $ guix shell --no-grafts racket -- racket > --version > Welcome to Racket v8.8 [cs]. >> > That's very useful! I'm not exactly sure how to do this, but can we determine which grafts are otherwise being applied to `racket` in your environment? Hopefully knowing what is being grafted will help to narrow down how grafting might be going wrong.
Re: Racket REPL not working
This works ck@brak ~ $ guix shell --no-grafts racket -- racket --version Welcome to Racket v8.8 [cs]. > "Philip McGrath" writes: > On Sat, Jul 1, 2023, at 7:41 AM, Chris Keschnat wrote: >> "Philip McGrath" writes: >>> Are any of you able to reproduce the problem consistently at this point? >> >> Jup. I can provide info if anyone wants/asks, but I have no idea how to >> debug this myself unfortunately. >> >> #+begin_src sh >> ck@brak ~ $ racket >> Segmentation fault >> ck@brak ~ :( $ which racket >> /home/ck/.guix-profile/bin/racket >> ck@brak ~ $ /home/ck/.guix-profile/bin/racket >> Welcome to Racket v8.8 [cs]. >> > >> #+end_src > > Could you try something like `guix shell --no-grafts racket -- racket > --version`? If that succeeds, this could be a reprise of something > like <https://issues.guix.gnu.org/47064>. > > Thanks.
Re: Racket REPL not working
On Sat, Jul 1, 2023, at 10:31 PM, Philip McGrath wrote: > On Sat, Jul 1, 2023, at 7:41 AM, Chris Keschnat wrote: >> "Philip McGrath" writes: >>> Are any of you able to reproduce the problem consistently at this point? >> >> Jup. I can provide info if anyone wants/asks, but I have no idea how to >> debug this myself unfortunately. >> >> #+begin_src sh >> ck@brak ~ $ racket >> Segmentation fault >> ck@brak ~ :( $ which racket >> /home/ck/.guix-profile/bin/racket >> ck@brak ~ $ /home/ck/.guix-profile/bin/racket >> Welcome to Racket v8.8 [cs]. >> > >> #+end_src > > Could you try something like `guix shell --no-grafts racket -- racket > --version`? If that succeeds, this could be a reprise of something like > <https://issues.guix.gnu.org/47064>. > > Thanks. Matthew Flatt pointed out that Racket 8.9 contains a fix for at least one problem that could cause a crash at startup, though I wouldn't expect the problem to be triggered as long as `/proc/self/exe` is available: https://github.com/racket/racket/commit/2f1535ad37f09e23aaf8b640aeebd47a7439a577 You could see if the pending update fixes the problem for you by running: `guix time-machine --url=https://git.guix-patches.cbaines.net/git/guix-patches --branch=issue-64247 -- shell racket -- racket`
Re: Racket REPL not working
On Sat, Jul 1, 2023, at 7:41 AM, Chris Keschnat wrote: > "Philip McGrath" writes: >> Are any of you able to reproduce the problem consistently at this point? > > Jup. I can provide info if anyone wants/asks, but I have no idea how to > debug this myself unfortunately. > > #+begin_src sh > ck@brak ~ $ racket > Segmentation fault > ck@brak ~ :( $ which racket > /home/ck/.guix-profile/bin/racket > ck@brak ~ $ /home/ck/.guix-profile/bin/racket > Welcome to Racket v8.8 [cs]. > > > #+end_src Could you try something like `guix shell --no-grafts racket -- racket --version`? If that succeeds, this could be a reprise of something like <https://issues.guix.gnu.org/47064>. Thanks.
Re: Racket REPL not working
"Philip McGrath" writes: > Are any of you able to reproduce the problem consistently at this point? Jup. I can provide info if anyone wants/asks, but I have no idea how to debug this myself unfortunately. #+begin_src sh ck@brak ~ $ racket Segmentation fault ck@brak ~ :( $ which racket /home/ck/.guix-profile/bin/racket ck@brak ~ $ /home/ck/.guix-profile/bin/racket Welcome to Racket v8.8 [cs]. > #+end_src
Re: Racket REPL not working
Hi, On Fri, Jun 30, 2023, at 12:52 AM, Chris Keschnat wrote: > Hi, > to me/on my machine this seems to be some environment issue. > > Locations are the same: > #+begin_src sh > ck@brak ~ $ guix shell racket -- which racket > /gnu/store/36ckdvyykaz3y5xbcvsbjqj4c7sazgsm-profile/bin/racket > > ck@brak ~ $ which racket > /home/ck/.guix-profile/bin/racket > ck@brak ~ $ ll /home/ck/.guix-profile/bin/racket > lrwxrwxrwx 1 root root 65 01.01.1970 01:00 > /home/ck/.guix-profile/bin/racket -> > /gnu/store/z0a42imbmy6563wvdavapb6c8vbi1s1z-racket-8.8/bin/racket > #+end_src > > > I can run racket in a guix shell: > #+begin_src sh > ck@brak ~ $ guix shell racket -- racket > Welcome to Racket v8.8 [cs]. > > > #+end_src > > > And also when I use the full path: > #+begin_src sh > ck@brak ~ $ ll /home/ck/.guix-profile/bin/racket > lrwxrwxrwx 1 root root 65 01.01.1970 01:00 > /home/ck/.guix-profile/bin/racket -> > /gnu/store/z0a42imbmy6563wvdavapb6c8vbi1s1z-racket-8.8/bin/racket > > ck@brak ~ $ /gnu/store/36ckdvyykaz3y5xbcvsbjqj4c7sazgsm-profile/bin/racket > Welcome to Racket v8.8 [cs]. > > > #+end_src > > > Just using ~racket~ segfaults. > #+begin_src sh > ck@brak ~ $ racket > Segmentation fault > #+end_src > > > Maybe this help? > > Chris > I just noticed this thread. As it happens, I may have hit upon the issue a few days ago: ``` $ realpath $(command -v racket) /gnu/store/c9l5fwhfmdspnyn5ch2g522ssxkh530a-racket-8.8/bin/racket $ racket --version free(): invalid pointer Aborted (core dumped) $ guix describe --format=channels (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git";) (branch "master") (commit "6bc3e3f9baa52beb318dde77d1773ae83aa8683e") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA") $ raco cross --workspace 20230612-5c15ebc0da/ racket -e- "(require (submod \ "indent.rkt\" cli))" --generate-from-nat 0 >> Cross configuration Target:x86_64-linux [native] Host: x86_64-linux Version: current VM:cs Workspace: /home/philip/code/21.10-bastet/tmp/racket/pkgs/racket-test/t ests/json/20230612-5c15ebc0da/ # # #<11-count-enum: #\tab 1 2 3 4 5 6 7 8...> # # # # ``` I haven't been been able to reproduce since: IIRC, it was only happening within a single Konsole tab, and it was a session in which I'd done a bunch of interactive changes that I assumed had broken something. However, I did keep a copy of the core dump, and I'll see if I can find anything from that or ask upstream for help. Are any of you able to reproduce the problem consistently at this point? I'd also be interested to know if the problem persists when using the pending 8.9 update: https://issues.guix.gnu.org/64247 Philip
Re: Racket REPL not working
Hi, to me/on my machine this seems to be some environment issue. Locations are the same: #+begin_src sh ck@brak ~ $ guix shell racket -- which racket /gnu/store/36ckdvyykaz3y5xbcvsbjqj4c7sazgsm-profile/bin/racket ck@brak ~ $ which racket /home/ck/.guix-profile/bin/racket ck@brak ~ $ ll /home/ck/.guix-profile/bin/racket lrwxrwxrwx 1 root root 65 01.01.1970 01:00 /home/ck/.guix-profile/bin/racket -> /gnu/store/z0a42imbmy6563wvdavapb6c8vbi1s1z-racket-8.8/bin/racket #+end_src I can run racket in a guix shell: #+begin_src sh ck@brak ~ $ guix shell racket -- racket Welcome to Racket v8.8 [cs]. > #+end_src And also when I use the full path: #+begin_src sh ck@brak ~ $ ll /home/ck/.guix-profile/bin/racket lrwxrwxrwx 1 root root 65 01.01.1970 01:00 /home/ck/.guix-profile/bin/racket -> /gnu/store/z0a42imbmy6563wvdavapb6c8vbi1s1z-racket-8.8/bin/racket ck@brak ~ $ /gnu/store/36ckdvyykaz3y5xbcvsbjqj4c7sazgsm-profile/bin/racket Welcome to Racket v8.8 [cs]. > #+end_src Just using ~racket~ segfaults. #+begin_src sh ck@brak ~ $ racket Segmentation fault #+end_src Maybe this help? Chris Giovanni Biscuolo writes: > [[PGP Signed Part:Undecided]] > Hello, > > Efraim Flashner writes: > > [...] > >> I was able to run 'guix shell racket -- racket --version' with it >> segfaulting. Same thing when I switched to using the same commit that >> you're using. > > I'm using this Guix commit: > > > Generation 149 May 08 2023 13:31:35(current) > guix e118b92 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: e118b92cfe7a598b71dbbda2622b7551f4a72104 > > > > I'm on a foreign distro (Debian 11), I've tested racket in a > pure/not-pure guix shell and it is working, no segfaulting > >> Can you paste the output of 'lscpu'? I suspect that there might be some >> optimizations being applied during build time and it's been optimized >> with features not available in your CPU. > > This is my lscpu output: > > > giovanni@roquette: lscpu > Architecture:x86_64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Little Endian > Address sizes: 36 bits physical, 48 bits virtual > CPU(s): 8 > On-line CPU(s) list: 0-7 > Thread(s) per core: 1 > Core(s) per socket: 8 > Socket(s): 1 > NUMA node(s):1 > Vendor ID: GenuineIntel > CPU family: 6 > Model: 77 > Model name: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz > Stepping:8 > CPU MHz: 1899.896 > CPU max MHz: 2400, > CPU min MHz: 1200, > BogoMIPS:4799.73 > Virtualization: VT-x > L1d cache: 192 KiB > L1i cache: 256 KiB > L2 cache:4 MiB > NUMA node0 CPU(s): 0-7 > Vulnerability Itlb multihit: Not affected > Vulnerability L1tf: Not affected > Vulnerability Mds: Mitigation; Clear CPU buffers; SMT disabled > Vulnerability Meltdown: Mitigation; PTI > Vulnerability Spec store bypass: Not affected > Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and > __user pointer sanitization > Vulnerability Spectre v2:Mitigation; Full generic retpoline, IBPB > conditional, IBRS_FW, STIBP disabled, RSB filling > Vulnerability Srbds: Not affected > Vulnerability Tsx async abort: Not affected > Flags: fpu vme de pse tsc msr pae mce cx8 apic sep > mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall nx rdtscp lm constant_tsc arch_pe > rfmon pebs bts rep_good nopl xtopology > nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 > ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popc > nt tsc_deadline_timer aes rdrand lahf_lm > 3dnowprefetch cpuid_fault epb pti ibrs ibpb stibp tpr_shadow vnmi > flexpriority ept vpid tsc_adjust smep erms dtherm arat > md_clear > > HTH! Gio'
Re: Racket REPL not working
Hello, Efraim Flashner writes: [...] > I was able to run 'guix shell racket -- racket --version' with it > segfaulting. Same thing when I switched to using the same commit that > you're using. I'm using this Guix commit: --8<---cut here---start->8--- Generation 149 May 08 2023 13:31:35(current) guix e118b92 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: e118b92cfe7a598b71dbbda2622b7551f4a72104 --8<---cut here---end--->8--- I'm on a foreign distro (Debian 11), I've tested racket in a pure/not-pure guix shell and it is working, no segfaulting > Can you paste the output of 'lscpu'? I suspect that there might be some > optimizations being applied during build time and it's been optimized > with features not available in your CPU. This is my lscpu output: --8<---cut here---start->8--- giovanni@roquette: lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 36 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 1 Core(s) per socket: 8 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 77 Model name: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz Stepping:8 CPU MHz: 1899.896 CPU max MHz: 2400, CPU min MHz: 1200, BogoMIPS:4799.73 Virtualization: VT-x L1d cache: 192 KiB L1i cache: 256 KiB L2 cache:4 MiB NUMA node0 CPU(s): 0-7 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Mitigation; Clear CPU buffers; SMT disabled Vulnerability Meltdown: Mitigation; PTI Vulnerability Spec store bypass: Not affected Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2:Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_pe rfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popc nt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch cpuid_fault epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm arat md_clear --8<---cut here---end--->8--- HTH! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Racket REPL not working
On 5/15/23 18:18, Efraim Flashner wrote: On Sun, May 14, 2023 at 09:56:35PM +, Zelphir Kaltstahl wrote: Hello Guix users / package maintainers, I updated guix today using `guix pull && guix package -u`, but even before that, I had an issue starting a Racket REPL simply entering `racket`: $ racket Segmentation fault (core dumped) I am currently at guix: $ guix describe --format=channels (list (channel (name 'guix) (url"https://git.savannah.gnu.org/git/guix.git";) (branch "master") (commit "c5fa9dd0e96493307cc76ea098a6bca9b076e012") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA") $ guix describe Generation 42 Mai 14 2023 23:45:08(current) guix c5fa9dd repository URL:https://git.savannah.gnu.org/git/guix.git branch: master commit: c5fa9dd0e96493307cc76ea098a6bca9b076e012 Not sure what is up, or whether it is only on my end for some reason. Also cannot call `racket --version`: $ racket --version Segmentation fault (core dumped) I was able to run 'guix shell racket -- racket --version' with it segfaulting. Same thing when I switched to using the same commit that you're using. Can you paste the output of 'lscpu'? I suspect that there might be some optimizations being applied during build time and it's been optimized with features not available in your CPU. Hello Efraim, Here is the output of `lscpu`: $ lscpu Architecture:x86_64 CPU op-mode(s):32-bit, 64-bit Address sizes: 39 bits physical, 48 bits virtual Byte Order:Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Vendor ID: GenuineIntel Model name:Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz CPU family: 6 Model: 142 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 1 Stepping:9 CPU max MHz: 3500, CPU min MHz: 400, BogoMIPS:5799.77 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mc a cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_ tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cp l vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsav e avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust sgx bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx sma p clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dt herm ida arat pln pts hwp hwp_notify hwp_act_window hwp _epp md_clear flush_l1d arch_capabilities Virtualization features: Virtualization:VT-x Caches (sum of all): L1d: 64 KiB (2 instances) L1i: 64 KiB (2 instances) L2:512 KiB (2 instances) L3:4 MiB (1 instance) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-3 Vulnerabilities: Itlb multihit: KVM: Mitigation: VMX disabled L1tf: Mitigation; PTE Inversion; VMX conditional cache flushe s, SMT vulnerable Mds: Mitigation; Clear CPU buffers; SMT vulnerable Meltdown: Mitigation; PTI Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable Retbleed: Mitigation; IBRS Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp Spectre v1:Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2:Mitigation; IBRS, IBPB conditional, RSB filling, PBRSB- eIBRS Not affected Srbds: Mitigation; Microcode Tsx async abort: Not affected -- repositories:https://notabug.org/ZelphirKaltstahl
Re: Racket REPL not working
On 5/15/23 02:20, Felix Lechner wrote: Hi Zelphir, On Sun, May 14, 2023 at 2:57 PM Zelphir Kaltstahl wrote: I updated guix today using `guix pull && guix package -u`, but even before that, I had an issue starting a Racket REPL simply entering `racket`: Following your lead, I just updated Racket to the latest version (via Guix Home). It works fine locally. > racket --version Welcome to Racket v8.8 [cs]. At the bottom you can see what I saw when I did not realize that I was in the Racket REPL. My Emacs Eshell uses the same prompt symbol. I use Guix as the base system. Are you using the Guix package manager while you are in another Linux distribution? This machine runs a Xubuntu: lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 22.04.2 LTS Release:22.04 Codename: jammy I am no longer sure, whether I installed it as a Ubuntu or Xubuntu right away. -- repositories:https://notabug.org/ZelphirKaltstahl
Re: Racket REPL not working
On Sun, May 14, 2023 at 09:56:35PM +, Zelphir Kaltstahl wrote: > Hello Guix users / package maintainers, > > I updated guix today using `guix pull && guix package -u`, but even before > that, I had an issue starting a Racket REPL simply entering `racket`: > > > $ racket > Segmentation fault (core dumped) > > > I am currently at guix: > > > $ guix describe --format=channels > (list (channel > (name 'guix) > (url"https://git.savannah.gnu.org/git/guix.git";) > (branch "master") > (commit > "c5fa9dd0e96493307cc76ea098a6bca9b076e012") > (introduction > (make-channel-introduction > "9edb3f66fd807b096b48283debdcddccfea34bad" > (openpgp-fingerprint > "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA") > > $ guix describe > Generation 42 Mai 14 2023 23:45:08(current) > guix c5fa9dd > repository URL:https://git.savannah.gnu.org/git/guix.git > branch: master > commit: c5fa9dd0e96493307cc76ea098a6bca9b076e012 > > > Not sure what is up, or whether it is only on my end for some reason. > > Also cannot call `racket --version`: > > > $ racket --version > Segmentation fault (core dumped) > I was able to run 'guix shell racket -- racket --version' with it segfaulting. Same thing when I switched to using the same commit that you're using. Can you paste the output of 'lscpu'? I suspect that there might be some optimizations being applied during build time and it's been optimized with features not available in your CPU. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Racket REPL not working
Hi Zelphir, On Sun, May 14, 2023 at 2:57 PM Zelphir Kaltstahl wrote: > > I updated guix today using `guix pull && guix package -u`, but even before > that, > I had an issue starting a Racket REPL simply entering `racket`: Following your lead, I just updated Racket to the latest version (via Guix Home). It works fine locally. > racket --version Welcome to Racket v8.8 [cs]. At the bottom you can see what I saw when I did not realize that I was in the Racket REPL. My Emacs Eshell uses the same prompt symbol. I use Guix as the base system. Are you using the Guix package manager while you are in another Linux distribution? Kind regards, Felix * * * > racket Welcome to Racket v8.8 [cs]. > help Sending to web browser... file: /gnu/store/svrzd7cvjlcanwa46msdvdh1l28m6x5m-racket-8.8/share/doc/racket/index.html > racket --version racket: undefined; cannot reference an identifier before its definition in module: top-level [,bt for context] --version: undefined; cannot reference an identifier before its definition in module: top-level [,bt for context] > racket racket: undefined; cannot reference an identifier before its definition in module: top-level [,bt for context]
Racket REPL not working
Hello Guix users / package maintainers, I updated guix today using `guix pull && guix package -u`, but even before that, I had an issue starting a Racket REPL simply entering `racket`: $ racket Segmentation fault (core dumped) I am currently at guix: $ guix describe --format=channels (list (channel (name 'guix) (url"https://git.savannah.gnu.org/git/guix.git";) (branch "master") (commit "c5fa9dd0e96493307cc76ea098a6bca9b076e012") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA") $ guix describe Generation 42 Mai 14 2023 23:45:08(current) guix c5fa9dd repository URL:https://git.savannah.gnu.org/git/guix.git branch: master commit: c5fa9dd0e96493307cc76ea098a6bca9b076e012 Not sure what is up, or whether it is only on my end for some reason. Also cannot call `racket --version`: $ racket --version Segmentation fault (core dumped) But I can list all packages in my main guix profile: font-anonymous-pro 1.002 out /gnu/store/pinnddv228zqk8a3z2nnk2s4pwysvlnn-font-anonymous-pro-1.002 font-anonymous-pro-minus1.003 out /gnu/store/c453r8sfcrsz89q9hi7x0kw0n43nwj6s-font-anonymous-pro-minus-1.003 font-bitstream-vera 1.10out /gnu/store/580viqfg1c9dn5xhz570ssx3cn6h46pm-font-bitstream-vera-1.10 font-dejavu 2.37out /gnu/store/zan3d655r50cv5gxvj2l5yybwhy6x3n4-font-dejavu-2.37 font-dosis 1.7 out /gnu/store/7szhdm0bzns68xcj9r0x7868a72w8lk9-font-dosis-1.7 font-inconsolata3.000 out /gnu/store/aph6hhgg238a1327vaarfnxpqj9h5h17-font-inconsolata-3.000 font-lato 2.015 out /gnu/store/5p92xbqjlqd6jwcvf3lkl8xqrbqq83sq-font-lato-2.015 font-wqy-microhei 0.2.0-beta out /gnu/store/j42pppx2yzyxmw1k8qjs6b3yaqkfkg5g-font-wqy-microhei-0.2.0-beta font-wqy-zenhei 0.9.45 out /gnu/store/2wjdb6dwych39fil9h68zggy7pwbd5av-font-wqy-zenhei-0.9.45 font-fira-mono 3.206 out /gnu/store/7b03arxqxaq1ry3l7qrs747qvzbzhl0f-font-fira-mono-3.206 font-fira-code 6.2 out /gnu/store/kx03zx59dz839c2qnl8wzkkainlv1jzk-font-fira-code-6.2 scheme481.9.2 out /gnu/store/i8c1swanyzlmx4nk0222kcq9qra1mgp0-scheme48-1.9.2 font-libertinus 7.040 out /gnu/store/97cfzqy9ab38dn3q91876nh9yfcwxcw0-font-libertinus-7.040 font-blackfoundry-inria 1.200 out /gnu/store/za2jpj8fvl61ijy4dgc0qz34p7slq8l9-font-blackfoundry-inria-1.200 font-fira-sans 4.203 out /gnu/store/mbaza24dscbnd3cqwcfpjyf2wznicng6-font-fira-sans-4.203 hunspell1.7.0 out /gnu/store/xbw5xvbq2n7phla9xrcanpziqg2jm08h-hunspell-1.7.0 font-mononoki 1.3 out /gnu/store/i72zfyli3j263zdnbgw294883knadjyp-font-mononoki-1.3 font-liberation 2.1.5 out /gnu/store/cga9fam84752fwd1ccz0j219sv01bbm0-font-liberation-2.1.5 font-ibm-plex 6.1.1 out /gnu/store/drf18n9al1gxm0d955i5bhh8fqx7wm8s-font-ibm-plex-6.1.1 guile 3.0.9 out /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9 font-iosevka-term 20.0.0 out /gnu/store/gm8x2li0si9x7qbb6747dk6xhxdr2bqx-font-iosevka-term-20.0.0 font-iosevka-term-slab 20.0.0 out /gnu/store/n4kbk4rskfi48gysczyk4a9kpmp99x04-font-iosevka-term-slab-20.0.0 font-iosevka-slab 20.0.0 out /gnu/store/bdj4z0hlf93xwxvycqfp0l3aji29j9mh-font-iosevka-slab-20.0.0 font-iosevka-etoile 20.0.0 out /gnu/store/0ihc5d4c25a45m62as1rdgai3xpmqkd0-font-iosevka-etoile-20.0.0 font-iosevka20.0.0 out /gnu/store/dzxbvjaqpkilhiznsszpw075q630w9ij-font-iosevka-20.0.0 font-linuxlibertine 5.3.0 out /gnu/store/5425x6qcbvf2z04h5gbwki8anl2sq7by-font-linuxlibertine-5.3.0 hunspell-dict-de20161207out /gnu/store/yf2nac51kjbb97y4krd7npz8jp91h2zl-hunspell-dict-de-20161207 gnutls 3.7.7 out /gnu/store/yr4lbvdyc4dgs76yij1dw2w2z8s84af8-gnutls-3.7.7 sicp20180718-3.bda03f7 out /gnu/store/sbzr80wq0fgr7ngc7yha9vkdwn75kg1a-sicp-20180718-3.bda03f7 pandoc 2.19.2 out /gnu/store/rgp6zar671zp703ll0ji7ffhg0qhv1i3-pandoc-2.19.2 imagemagick 6.9.12-4out /gnu/store/v9fjv
Re: Want to test Racket/Chez on powerpc64le?
Hi, On Mon, Aug 1, 2022, at 5:02 PM, Efraim Flashner wrote: > On Mon, Aug 01, 2022 at 03:46:21PM -0400, Philip McGrath wrote: >> Hi folks, >> >> I have a patch series at https://gitlab.com/philip1/guix-patches/-/tree/zuo >> for the Racket 8.5.900 release candidate for the imminent Racket 8.6 >> release.[1] The patch series also enables Racket CS and the >> 'chez-scheme-for-racket' package on systems they haven't supported until >> now, such as powerpc64le-linux—at least, I think it does: I'm hoping some of >> you can test it. The riscv64-linux, mips64el-linux, and i586-gnu are >> similarly situated: I ask particularly about powerpc64le-linux because >> Matthew Flatt has tested it upstream (thanks to the GCC Compile Farm). >> >> If you just want to help quickly, try this: >> >> guix time-machine --url=https://gitlab.com/philip1/guix-patches --branch=zuo >> --disable-authentication -- build chez-scheme-for-racket racket >> >> and let me know how it goes, either here or at [2]. Allow about an hour for >> the build. (So, not *that* quickly …) >> >> [...] >> >> [2]: >> https://racket.discourse.group/t/chez-for-architectures-without-native-backends/950 FYI, I've sent the series as <https://issues.guix.gnu.org/57050>, and I also updated the branch above. Testing on real hardware would still be very welcome, though! >> (There's still a problem with i586-pc-gnu, probably some missing/different C >> flag.) I ended up adding support for the Hurd as a native backend. -Philip
Re: Want to test Racket/Chez on powerpc64le?
On Mon, Aug 01, 2022 at 03:46:21PM -0400, Philip McGrath wrote: > Hi folks, > > I have a patch series at https://gitlab.com/philip1/guix-patches/-/tree/zuo > for the Racket 8.5.900 release candidate for the imminent Racket 8.6 > release.[1] The patch series also enables Racket CS and the > 'chez-scheme-for-racket' package on systems they haven't supported until now, > such as powerpc64le-linux—at least, I think it does: I'm hoping some of you > can test it. The riscv64-linux, mips64el-linux, and i586-gnu are similarly > situated: I ask particularly about powerpc64le-linux because Matthew Flatt > has tested it upstream (thanks to the GCC Compile Farm). > > If you just want to help quickly, try this: > > guix time-machine --url=https://gitlab.com/philip1/guix-patches --branch=zuo > --disable-authentication -- build chez-scheme-for-racket racket > > and let me know how it goes, either here or at [2]. Allow about an hour for > the build. (So, not *that* quickly …) > > Some more background about what's new: > > The systems I listed above are ones for which Racket's variant of Chez Scheme > doesn't (yet!) have backends to generate machine code. With these changes, > they instead can now use "pbarch" backends added to Racket's variant of Chez > Scheme: a "portable bytecode" mode specialized to word size and endianness, > with core bytecode additionally compiled to C. > > I've cross-compiled 'chez-scheme-for-racket' and 'racket-vm-cs' successfully > for the Linux-based systems. (There's still a problem with i586-pc-gnu, > probably some missing/different C flag.) Unfortunately, I ran into a QEMU > error [3] when I tried an emulated build, possibly related to Racket BC's use > of SIGSEGV to implement the GC write barrier, and I don't have access to any > of the relevant hardware myself. So, I'm hoping people who do might be able > to give it a try! > > Thanks, > Philip > > [1]: https://racket.discourse.group/t/racket-v8-6-release-thread/1091 > [2]: > https://racket.discourse.group/t/chez-for-architectures-without-native-backends/950 > [3]: > https://racket.discourse.group/t/chez-for-architectures-without-native-backends/950/13 In general I should be able to help with the riscv64-linux for testing. Unfortunately I'm working remotely for the next few weeks and a power outage at home brought down my machines, so I won't be able to for a while yet. For mips64el, Guix used the Loongson2F as a build machine and target while Debian targets the Loongson3A. I do have one of the retired Lemote machines we used, but I haven't had it powered up for a few years and isn't currently prepared for building packages. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Want to test Racket/Chez on powerpc64le?
Hi folks, I have a patch series at https://gitlab.com/philip1/guix-patches/-/tree/zuo for the Racket 8.5.900 release candidate for the imminent Racket 8.6 release.[1] The patch series also enables Racket CS and the 'chez-scheme-for-racket' package on systems they haven't supported until now, such as powerpc64le-linux—at least, I think it does: I'm hoping some of you can test it. The riscv64-linux, mips64el-linux, and i586-gnu are similarly situated: I ask particularly about powerpc64le-linux because Matthew Flatt has tested it upstream (thanks to the GCC Compile Farm). If you just want to help quickly, try this: guix time-machine --url=https://gitlab.com/philip1/guix-patches --branch=zuo --disable-authentication -- build chez-scheme-for-racket racket and let me know how it goes, either here or at [2]. Allow about an hour for the build. (So, not *that* quickly …) Some more background about what's new: The systems I listed above are ones for which Racket's variant of Chez Scheme doesn't (yet!) have backends to generate machine code. With these changes, they instead can now use "pbarch" backends added to Racket's variant of Chez Scheme: a "portable bytecode" mode specialized to word size and endianness, with core bytecode additionally compiled to C. I've cross-compiled 'chez-scheme-for-racket' and 'racket-vm-cs' successfully for the Linux-based systems. (There's still a problem with i586-pc-gnu, probably some missing/different C flag.) Unfortunately, I ran into a QEMU error [3] when I tried an emulated build, possibly related to Racket BC's use of SIGSEGV to implement the GC write barrier, and I don't have access to any of the relevant hardware myself. So, I'm hoping people who do might be able to give it a try! Thanks, Philip [1]: https://racket.discourse.group/t/racket-v8-6-release-thread/1091 [2]: https://racket.discourse.group/t/chez-for-architectures-without-native-backends/950 [3]: https://racket.discourse.group/t/chez-for-architectures-without-native-backends/950/13
Re: Racket (require gregor)
yasu writes: > Hi! > I am tring to use the gregor package using my Racket program: > #lang racket(require gregor) > But it fails with fthe ollowing error: > Unable to locate the zoneinfo database on this computer. We searched > for it in the following places: - /usr/share/zoneinfo - > /usr/share/lib/zoneinfo - /etc/zoneinfo > There is a suggestion at: > https://lists.gnu.org/archive/html/help-guix/2018-08/msg00073.html of > installing tzdata > After installig it with: raco pkg install tzdata, > It did not help (I still get exact same error). If there are users of > Racket..., would you please try the same and see if it works for you? > Cheers, > Yasu > A bit late for the party, but one way to do it would be to run Racket in a container, and as usual export the necessary certs: --8<---cut here---start->8--- # Create the container and expose the zoneinfo ./pre-inst-env guix environment -N -C --expose=/usr/share/zoneinfo --ad-hoc racket-minimal nss-certs coreutils libedit export SSL_CERT_DIR="$GUIX_ENVIRONMENT/etc/ssl/certs" && export SSL_CERT_FILE="$GUIX_ENVIRONMENT/etc/ssl/certs/ca-certificates.crt" --8<---cut here---end--->8--- I do things that way since there's a racket program[0] I ran in a server; and it's convenient on that regard... [0] http://git.genenetwork.org/GeneNetwork/feedanalyser.git -- Bonface M. K. <https://www.bonfacemunyoki.com> Humble GNU Emacs User / Bearer of scheme-y parens Curator: <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Racket (require gregor)
Yasuaki Kudo writes: > If no one is working on it or has any plan to do > so, maybe I can volunteer in the future 😊 But I > am still learning both Guix and Racket… 😊 > > (I am thinking of starting a “worker cooperative” > that specializes in legacy enterprise software > replacement projects. Both Guix and Racket will > be important tools of trade I imagine 😊) > > -Yasu > I wouldn't mind collaborating on this! I could share some of my notes with you if you don't mind ... -- Bonface M. K. <https://www.bonfacemunyoki.com> Humble GNU Emacs User / Bearer of scheme-y parens Curator: <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
Re: Racket (require gregor)
"jgart" writes: > There is not a racket-build-system for guix yet, atleast to my knowledge. > > I see we just got a chicken-build-system though :). > > Is anyone working on a racket-build-system? > Yep I am. But I've put a pause on it for now. Couldn't really work out how to resolve the dependencies--- Racket is stateful with how it manages dependencies which has made it very difficult to have a working buid system. Nix seems to have, that sorted out, but IIRC it's really inefficient... [...] -- Bonface M. K. <https://www.bonfacemunyoki.com> Humble GNU Emacs User / Bearer of scheme-y parens Curator: <https://upbookclub.com> / Twitter: @BonfaceKilz GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F signature.asc Description: PGP signature
RE: Racket (require gregor)
If no one is working on it or has any plan to do so, maybe I can volunteer in the future 😊 But I am still learning both Guix and Racket… 😊 (I am thinking of starting a “worker cooperative” that specializes in legacy enterprise software replacement projects. Both Guix and Racket will be important tools of trade I imagine 😊) -Yasu From: jgart Sent: Sunday, December 13, 2020 3:43 AM To: help-guix@gnu.org Subject: Re: Racket (require gregor) There is not a racket-build-system for guix yet, atleast to my knowledge. I see we just got a chicken-build-system though :). Is anyone working on a racket-build-system? December 12, 2020 12:01 PM, help-guix-requ...@gnu.org wrote: > Send Help-Guix mailing list submissions to > help-guix@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/help-guix > or, via email, send a message with subject or body 'help' to > help-guix-requ...@gnu.org > > You can reach the person managing the list at > help-guix-ow...@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Help-Guix digest..." > > Today's Topics: > > 1. Re: Racket (require gregor) (yasu) > > -- > > Message: 1 > Date: Sat, 12 Dec 2020 17:52:02 +0900 > From: yasu > To: Tobias Geerinckx-Rice > Cc: help-guix@gnu.org > Subject: Re: Racket (require gregor) > Message-ID: > <93b54a78bcdf382d85d785dc8afc79a29ef968dc.ca...@yasuaki.com> > Content-Type: text/plain; charset="UTF-8" > > Thank you Tobias, it worked! > > I ended up modifying below section as shown: > > ~/.racket/7.9/pkgs/tzinfo/tzinfo/private$ nvim zoneinfo.rkt > > (define default-zoneinfo-search-path > > (list > (path->string > (build-path > (string-replace > (with-output-to-string > (lambda () > (system "guix build tzdata"))) "\n" "" ) > "share" "zoneinfo")) > "/usr/share/zoneinfo" > "/usr/share/lib/zoneinfo" > "/etc/zoneinfo")) > > But surely this is not the way to do it in Guix... > > I wonder if there is a proper Guix integration for Racket's raco > package manager? > > -Yasu > > On Fri, 2020-12-11 at 15:24 +0100, Tobias Geerinckx-Rice wrote: > >> Hi Yasu, >> >> Yasuaki Kudo 写道： >> Damn HTML doesn't work😅 >> >> Yes. Please don't send HTML e-mail to mailing lists: most people >> don't like receiving it (e.g., sending me HTML mail is guaranteed >> to land you in my Spam bin) & you never know how your mail will >> appear to others. >> >> (Resending, my html email keeps failing... Is this mailing list >> automatically converting HTML messages to Plain Text or >> something??) >> >> Yes. We have enabled both ‘convert text/html parts to plain text’ >> and ‘collapse multipart/alternative to its first part content’. >> >> If there are users of >> Racket..., would you please try the same and see if it works for >> you? >> >> I get the same error, with the tzdata Racket (and Guix, just in >> case) package install. >> >> If I manually add $(guix build tzdata)/share/zoneinfo to >> pkgs/tzinfo/tzinfo/private/zoneinfo.rkt's >> default-zoneinfo-search-path, it works. >> >> However, I didn't notice a $TZDIR-like mechanism to do so >> ‘properly’. >> >> Kind regards, >> >> T G-R > > -- > > Subject: Digest Footer > > ___ > Help-Guix mailing list > Help-Guix@gnu.org > https://lists.gnu.org/mailman/listinfo/help-guix > > -- > > End of Help-Guix Digest, Vol 61, Issue 21 > *
Re: Racket (require gregor)
There is not a racket-build-system for guix yet, atleast to my knowledge. I see we just got a chicken-build-system though :). Is anyone working on a racket-build-system? December 12, 2020 12:01 PM, help-guix-requ...@gnu.org wrote: > Send Help-Guix mailing list submissions to > help-guix@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/help-guix > or, via email, send a message with subject or body 'help' to > help-guix-requ...@gnu.org > > You can reach the person managing the list at > help-guix-ow...@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Help-Guix digest..." > > Today's Topics: > > 1. Re: Racket (require gregor) (yasu) > > -- > > Message: 1 > Date: Sat, 12 Dec 2020 17:52:02 +0900 > From: yasu > To: Tobias Geerinckx-Rice > Cc: help-guix@gnu.org > Subject: Re: Racket (require gregor) > Message-ID: > <93b54a78bcdf382d85d785dc8afc79a29ef968dc.ca...@yasuaki.com> > Content-Type: text/plain; charset="UTF-8" > > Thank you Tobias, it worked! > > I ended up modifying below section as shown: > > ~/.racket/7.9/pkgs/tzinfo/tzinfo/private$ nvim zoneinfo.rkt > > (define default-zoneinfo-search-path > > (list > (path->string > (build-path > (string-replace > (with-output-to-string > (lambda () > (system "guix build tzdata"))) "\n" "" ) > "share" "zoneinfo")) > "/usr/share/zoneinfo" > "/usr/share/lib/zoneinfo" > "/etc/zoneinfo")) > > But surely this is not the way to do it in Guix... > > I wonder if there is a proper Guix integration for Racket's raco > package manager? > > -Yasu > > On Fri, 2020-12-11 at 15:24 +0100, Tobias Geerinckx-Rice wrote: > >> Hi Yasu, >> >> Yasuaki Kudo 写道： >> Damn HTML doesn't work😅 >> >> Yes. Please don't send HTML e-mail to mailing lists: most people >> don't like receiving it (e.g., sending me HTML mail is guaranteed >> to land you in my Spam bin) & you never know how your mail will >> appear to others. >> >> (Resending, my html email keeps failing... Is this mailing list >> automatically converting HTML messages to Plain Text or >> something??) >> >> Yes. We have enabled both ‘convert text/html parts to plain text’ >> and ‘collapse multipart/alternative to its first part content’. >> >> If there are users of >> Racket..., would you please try the same and see if it works for >> you? >> >> I get the same error, with the tzdata Racket (and Guix, just in >> case) package install. >> >> If I manually add $(guix build tzdata)/share/zoneinfo to >> pkgs/tzinfo/tzinfo/private/zoneinfo.rkt's >> default-zoneinfo-search-path, it works. >> >> However, I didn't notice a $TZDIR-like mechanism to do so >> ‘properly’. >> >> Kind regards, >> >> T G-R > > -- > > Subject: Digest Footer > > ___ > Help-Guix mailing list > Help-Guix@gnu.org > https://lists.gnu.org/mailman/listinfo/help-guix > > -- > > End of Help-Guix Digest, Vol 61, Issue 21 > *
Re: Racket (require gregor)
Thank you Tobias, it worked! I ended up modifying below section as shown: ~/.racket/7.9/pkgs/tzinfo/tzinfo/private$ nvim zoneinfo.rkt (define default-zoneinfo-search-path (list (path->string (build-path (string-replace (with-output-to-string (lambda () (system "guix build tzdata"))) "\n" "" ) "share" "zoneinfo")) "/usr/share/zoneinfo" "/usr/share/lib/zoneinfo" "/etc/zoneinfo")) But surely this is not the way to do it in Guix... I wonder if there is a proper Guix integration for Racket's raco package manager? -Yasu On Fri, 2020-12-11 at 15:24 +0100, Tobias Geerinckx-Rice wrote: > Hi Yasu, > > Yasuaki Kudo 写道： > > Damn HTML doesn't work😅 > > Yes. Please don't send HTML e-mail to mailing lists: most people > don't like receiving it (e.g., sending me HTML mail is guaranteed > to land you in my Spam bin) & you never know how your mail will > appear to others. > > > (Resending, my html email keeps failing... Is this mailing list > > automatically converting HTML messages to Plain Text or > > something??) > > Yes. We have enabled both ‘convert text/html parts to plain text’ > and ‘collapse multipart/alternative to its first part content’. > > > If there are users of > > Racket..., would you please try the same and see if it works for > > you? > > I get the same error, with the tzdata Racket (and Guix, just in > case) package install. > > If I manually add $(guix build tzdata)/share/zoneinfo to > pkgs/tzinfo/tzinfo/private/zoneinfo.rkt's > default-zoneinfo-search-path, it works. > > However, I didn't notice a $TZDIR-like mechanism to do so > ‘properly’. > > Kind regards, > > T G-R
Re: Racket (require gregor)
Hi Yasu, Yasuaki Kudo 写道： Damn HTML doesn't work😅 Yes. Please don't send HTML e-mail to mailing lists: most people don't like receiving it (e.g., sending me HTML mail is guaranteed to land you in my Spam bin) & you never know how your mail will appear to others. (Resending, my html email keeps failing... Is this mailing list automatically converting HTML messages to Plain Text or something??) Yes. We have enabled both ‘convert text/html parts to plain text’ and ‘collapse multipart/alternative to its first part content’. If there are users of Racket..., would you please try the same and see if it works for you? I get the same error, with the tzdata Racket (and Guix, just in case) package install. If I manually add $(guix build tzdata)/share/zoneinfo to pkgs/tzinfo/tzinfo/private/zoneinfo.rkt's default-zoneinfo-search-path, it works. However, I didn't notice a $TZDIR-like mechanism to do so ‘properly’. Kind regards, T G-R signature.asc Description: PGP signature
Re: Racket (require gregor)
Damn HTML doesn't work😅 My program is: #lang racket (require gregor) > On Dec 11, 2020, at 21:16, yasu wrote: > > (Resending, my html email keeps failing... Is this mailing list > automatically converting HTML messages to Plain Text or something??) > > > Hi! > > I am tring to use the gregor package using my Racket program: > > #lang racket(require gregor) > > > But it fails with fthe ollowing error: > > Unable to locate the zoneinfo database on this computer. We searched > for it in the following places: - /usr/share/zoneinfo - > /usr/share/lib/zoneinfo - /etc/zoneinfo > > There is a suggestion at: > https://lists.gnu.org/archive/html/help-guix/2018-08/msg00073.html > of installing tzdata. > > After installig it with: raco pkg install tzdata, > > It did not help (I still get exact same error). > > If there are users of > Racket..., would you please try the same and see if it works for you? > > Cheers, > Yasu > >
Re: Racket (require gregor)
(Resending, my html email keeps failing... Is this mailing list automatically converting HTML messages to Plain Text or something??) Hi! I am tring to use the gregor package using my Racket program: #lang racket(require gregor) But it fails with fthe ollowing error: Unable to locate the zoneinfo database on this computer. We searched for it in the following places: - /usr/share/zoneinfo - /usr/share/lib/zoneinfo - /etc/zoneinfo There is a suggestion at: https://lists.gnu.org/archive/html/help-guix/2018-08/msg00073.html of installing tzdata. After installig it with: raco pkg install tzdata, It did not help (I still get exact same error). If there are users of Racket..., would you please try the same and see if it works for you? Cheers, Yasu
Racket (require gregor)
Hi! I am tring to use the gregor package using my Racket program: #lang racket(require gregor) But it fails with fthe ollowing error: Unable to locate the zoneinfo database on this computer. We searched for it in the following places: - /usr/share/zoneinfo - /usr/share/lib/zoneinfo - /etc/zoneinfo There is a suggestion at: https://lists.gnu.org/archive/html/help-guix/2018-08/msg00073.html of installing tzdata After installig it with: raco pkg install tzdata, It did not help (I still get exact same error). If there are users of Racket..., would you please try the same and see if it works for you? Cheers, Yasu
racket question
Is there any way to define function in #rash and use it in #racket? I can create file myfunc.rkt: #lang racket (define func (+ 1 1)) And require it in ... main.rkt: #lang rash (require "myfunc.rkt") echo $func Like in bash (not sure about syntax, wrote it using touchscreen). And, well, i had many bash scripts i would like convert to rash, and i want to find a way to define funcs in rash and then import them in racket
Re: racket
Benjamin Slade writes: > When run Racket, in the REPL, the first command I execute runs fine. But > the second (no matter what it is, even if it's just the first again) > always produces: > > ; ptr-ref: contract violation > ; expected: (and/c cpointer? (not/c (lambda (p) (pointer-equal? p #f > ; given: #f > ; argument position: 1st > ; [,bt for context] > ; ptr-ref: contract violation > ; expected: (and/c cpointer? (not/c (lambda (p) (pointer-equal? p #f > ; given: #f > ; argument position: 1st > ; [,bt for context] > > And it doesn't accept any more input after that point (including ",bt"). Hello, I fixed it with commit 26700cae. A 'guix pull' and then install racket again should work. Thank you for the report!
Re: racket
Benjamin Slade writes: > When run Racket, in the REPL, the first command I execute runs fine. But > the second (no matter what it is, even if it's just the first again) > always produces: > > ; ptr-ref: contract violation > ; expected: (and/c cpointer? (not/c (lambda (p) (pointer-equal? p #f > ; given: #f > ; argument position: 1st > ; [,bt for context] > ; ptr-ref: contract violation > ; expected: (and/c cpointer? (not/c (lambda (p) (pointer-equal? p #f > ; given: #f > ; argument position: 1st > ; [,bt for context] > > And it doesn't accept any more input after that point (including ",bt"). Huh... I'm getting this too. I hadn't noticed it because I use racket-mode for all my REPL hacking, where it isn't appearing (probably because racket-mode has its own REPL protocol code).
racket
When run Racket, in the REPL, the first command I execute runs fine. But the second (no matter what it is, even if it's just the first again) always produces: ; ptr-ref: contract violation ; expected: (and/c cpointer? (not/c (lambda (p) (pointer-equal? p #f ; given: #f ; argument position: 1st ; [,bt for context] ; ptr-ref: contract violation ; expected: (and/c cpointer? (not/c (lambda (p) (pointer-equal? p #f ; given: #f ; argument position: 1st ; [,bt for context] And it doesn't accept any more input after that point (including ",bt"). -- Benjamin Slade - https://babbagefiles.xyz `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19)) '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org ) `(Choose Linux ,(Choose Freedom) . https://linux.com )
Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)
Christopher Lemmer Webber writes: > Timothy Sample writes: > >> Christopher Lemmer Webber writes: >> >>> Likewise, Gregor and Raart do not install: >>> >>> [...] >> >> This is a timezone issue. The “tzinfo” package cannot find the >> “zoneinfo” directory in GuixSD. If you install the “tzdata” Racket >> package, things seem to settle down. (It would be better to tell >> “tzinfo” to use the system database, but that’s harder to do.) > > Oh that's true. I guess this was multiple issues. Anyway, horray, that > one seems ok now! I’m glad to hear it! >>> ... install raart, lots of "cannot open output file" error messages ... >>> [...] >> >> I got better results with “raart” when “gcc-toolchain” was available >> (i.e., “guix environment --ad-hoc gcc-toolchain”). I guess it has to >> compile a bit of native code, so it needs a compiler. It still brakes >> due to a syntax error, but I get the same error on Debian, so I guess >> that’s something. :) > > Yep... that seems to have fixed the install of that issue. Cool! >> Also, I checked all of this from Racket without grafts, and it never >> complained about compiling OpenSSL stuff. Running “raco setup” gives >> some other errors, though. > > You're right... without grafts it doesn't have the openssl error. The > other writing to the store issues still seem to persist, but it doesn't > block running "raco setup" (after a "raco pkg install", a step I had > omitted earlier). Okay. I was confused about the “raco setup” example, but the other step makes more sense now. I will say that even on Debian, with an regular user, I have seen “permission denied” errors because Racket tries to update files in “/usr/share”. > ISTM that this is a separate bug. In fact I'm afraid I've polluted this > bug with what I thought were all the same bug but turned out to be > several different bugs, of which a couple are fixed now thanks to your > help. > > PS: About the bounty, my thoughts are that some of these smaller issues > being resolved are already worth a smaller amount of compensation (and > thanks!), but there are *two different* larger issues of which probably > either is worth the full amount (though I can only afford to pay for > one)... one of them is the issue of the grafts breaking eg openssl > (which maybe we should file as a separate bug?), and the other is this > original bug (30680) about the attempts to compile to the store (which > does not seem as big of a blocker as it did previously, but is still > very annoying). Does that seem fair? (Feel free to contact me > off-list.) Actually I think there is only one bug, which is the grafts thing. This bug was originally about compiling OpenSSL files to the store. Grafting doesn’t break OpenSSL it just makes Racket try to recompile its OpenSSL FFI wrappers. I have a patch, too. I sent it to guix-patches, but I must have made a mistake because it ended up in bug-guix attached to this bug report. The patch can be found at <https://debbugs.gnu.org/30680>. Also, the attachment didn’t get sent to the list, but did make it to the bug page. Hm Sorry for the goof!
Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)
Timothy Sample writes: > Christopher Lemmer Webber writes: > >> Likewise, Gregor and Raart do not install: >> >> $ mv ~/.racket ~/.racket-borked >> $ raco pkg install gregor # lots of errors during install >> $ racket >> racket@> (require gregor) >> explode-path: contract violation >> expected: (or/c path-for-some-system? path-string?) >> given: #f >> context...: >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:116:0: >> do-explode-path >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:126:0: >> find-relative-path7 >> /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:117:2: >> for-loop >>/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:107:0: >> read-tzids >>/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:70:0: >> make-zoneinfo-source >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18 >>/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/main.rkt:63:0: system-tzid >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18 >>/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/moment.rkt: >> [running body] >>/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/generics.rkt: >> [traversing imports] >>/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/clock.rkt: >> [traversing imports] >>/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/main.rkt: [traversing >> imports] >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7 > > This is a timezone issue. The “tzinfo” package cannot find the > “zoneinfo” directory in GuixSD. If you install the “tzdata” Racket > package, things seem to settle down. (It would be better to tell > “tzinfo” to use the system database, but that’s harder to do.) Oh that's true. I guess this was multiple issues. Anyway, horray, that one seems ok now! >> ... install raart, lots of "cannot open output file" error messages ... >> racket@> (require raart) >> get-module-code: no such file: >> # >> context...: >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:120:0: >> get-module-path54 >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:225:0: >> get-module-code82 >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 >>standard-module-name-resolver >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 >>standard-module-name-resolver >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 >>standard-module-name-resolver >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/require-transform.rkt:266:2: >> expand-import >>parse-reprov-spec1 >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/wrap-modbeg.rkt:46:4 >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 >>standard-module-name-resolver >> >> /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7 > > I got better results with “raart” when “gcc-toolchain” was available > (i.e., “guix environment --ad-hoc gcc-toolchain”). I guess it has to > compile a bit of native code, so it needs a compiler. It still brakes > due to a syntax error, but I get the same error on Debian, so I guess > that’s something. :) Yep... that seems to have fixed the install of that issue. > Also, I checked all of this from Racket without grafts, and it never > complained about compiling OpenSSL stuff. Running “raco setup” gives > some other errors, though. You're right... without grafts it doesn't have the openssl error. The other writing to the store issues still seem to persist, but it doesn't block running "raco setup" (after a "raco pkg install", a step I had omitted earlier). ISTM that this is a separate bug. In fact I'm afraid I&#x
Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)
Timothy Sample ezt írta (időpont: 2018. aug. 12., V, 4:03): > Christopher Lemmer Webber writes: > > > Likewise, Gregor and Raart do not install: > > > > $ mv ~/.racket ~/.racket-borked > > $ raco pkg install gregor # lots of errors during install > > $ racket > > racket@> (require gregor) > > explode-path: contract violation > > expected: (or/c path-for-some-system? path-string?) > > given: #f > > context...: > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:116:0: > do-explode-path > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:126:0: > find-relative-path7 > > > /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:117:2: > for-loop > > > /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:107:0: > read-tzids > > > /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:70:0: > make-zoneinfo-source > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18 > > /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/main.rkt:63:0: > system-tzid > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18 > >/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/moment.rkt: > [running body] > > > /home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/generics.rkt: > [traversing imports] > >/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/clock.rkt: > [traversing imports] > >/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/main.rkt: > [traversing imports] > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7 > > This is a timezone issue. The “tzinfo” package cannot find the > “zoneinfo” directory in GuixSD. If you install the “tzdata” Racket > package, things seem to settle down. (It would be better to tell > “tzinfo” to use the system database, but that’s harder to do.) > > > ... install raart, lots of "cannot open output file" error messages ... > > racket@> (require raart) > > get-module-code: no such file: > # > > context...: > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:120:0: > get-module-path54 > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:225:0: > get-module-code82 > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 > >standard-module-name-resolver > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 > >standard-module-name-resolver > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 > >standard-module-name-resolver > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/require-transform.rkt:266:2: > expand-import > > parse-reprov-spec1 > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/wrap-modbeg.rkt:46:4 > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 > >standard-module-name-resolver > > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7 > > I got better results with “raart” when “gcc-toolchain” was available > (i.e., “guix environment --ad-hoc gcc-toolchain”). I guess it has to > compile a bit of native code, so it needs a compiler. It still brakes > due to a syntax error, but I get the same error on Debian, so I guess > that’s something. :) > > Also, I checked all of this from Racket without grafts, and it never > complained about compiling OpenSSL stuff. Running “raco setup” gives > some other errors, though. > In the Actually this problem resembles me to another one, it's similar to why gdb is not working when grafting is used. I believe that the correct solution to these types of issues would be to recompute the hashes, and provide the updated hashes to the packages relying on them, so that they know the correct hash of the grafted file. In the gdb case this seems to be easier to solve, as the problem occurs inside a single package.
Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)
Christopher Lemmer Webber writes: > Likewise, Gregor and Raart do not install: > > $ mv ~/.racket ~/.racket-borked > $ raco pkg install gregor # lots of errors during install > $ racket > racket@> (require gregor) > explode-path: contract violation > expected: (or/c path-for-some-system? path-string?) > given: #f > context...: > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:116:0: > do-explode-path > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:126:0: > find-relative-path7 >/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:117:2: > for-loop >/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:107:0: > read-tzids >/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:70:0: > make-zoneinfo-source > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18 >/home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/main.rkt:63:0: system-tzid > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18 >/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/moment.rkt: > [running body] >/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/generics.rkt: > [traversing imports] >/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/clock.rkt: > [traversing imports] >/home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/main.rkt: [traversing > imports] > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7 This is a timezone issue. The “tzinfo” package cannot find the “zoneinfo” directory in GuixSD. If you install the “tzdata” Racket package, things seem to settle down. (It would be better to tell “tzinfo” to use the system database, but that’s harder to do.) > ... install raart, lots of "cannot open output file" error messages ... > racket@> (require raart) > get-module-code: no such file: > # > context...: > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:120:0: > get-module-path54 > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:225:0: > get-module-code82 > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 >standard-module-name-resolver > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 >standard-module-name-resolver > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 >standard-module-name-resolver > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/require-transform.rkt:266:2: > expand-import >parse-reprov-spec1 > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/wrap-modbeg.rkt:46:4 > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 >standard-module-name-resolver > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7 I got better results with “raart” when “gcc-toolchain” was available (i.e., “guix environment --ad-hoc gcc-toolchain”). I guess it has to compile a bit of native code, so it needs a compiler. It still brakes due to a syntax error, but I get the same error on Debian, so I guess that’s something. :) Also, I checked all of this from Racket without grafts, and it never complained about compiling OpenSSL stuff. Running “raco setup” gives some other errors, though.
Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)
Nils Gillmann writes: > Christopher Lemmer Webber transcribed 3.3K bytes: >> BTW, some examples of packages where I've had trouble, in case it helps >> with testing: >> >> - Raart >> - Gregor >> - crypto (seemed to work last time, not sure why it wasn't working before) >> >> Though at this point I also can't do just "raco setup" on a local >> package either, but maybe resolving this issue will fix that. >> > From what I've learned in the last couple of hours, the last problem could > be due to leftovers in your raco / dotRacket folder from an older > installation. Would be nice if it were so simple, but: Having removed ~/.racket, try: $ git clone https://github.com/cwebber/racket-linkeddata.git $ cd racket-linkeddata/linkeddata cwebber@jasmine:~/devel/racket-linkeddata/linkeddata$ raco setup open-output-file: cannot open output file path: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340298121534029812614 system error: Read-only file system; errno=30 context...: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/more-scheme.rkt:261:28 /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/file.rkt:199:0: call-with-atomic-output-file20 /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:363:0: compile-zo* /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:572:26 /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:564:42 /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:635:0: compile-root /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:688:15 /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:635:0: compile-root /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:688:15 /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:635:0: compile-root /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:688:15 /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:635:0: compile-root /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/compiler/cm.rkt:782:4: compilation-manager-load-handler standard-module-name-resolver /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/setup/main.rkt: [running body] /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/raco/main.rkt: [running body] cwebber@jasmine:~/devel/racket-linkeddata/linkeddata$ Likewise, Gregor and Raart do not install: $ mv ~/.racket ~/.racket-borked $ raco pkg install gregor # lots of errors during install $ racket racket@> (require gregor) explode-path: contract violation expected: (or/c path-for-some-system? path-string?) given: #f context...: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:116:0: do-explode-path /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/path.rkt:126:0: find-relative-path7 /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:117:2: for-loop /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:107:0: read-tzids /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:70:0: make-zoneinfo-source /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18 /home/cwebber/.racket/6.12/pkgs/tzinfo/tzinfo/main.rkt:63:0: system-tzid /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18 /home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/moment.rkt: [running body] /home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/generics.rkt: [traversing imports] /home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/private/clock.rkt: [traversing imports] /home/cwebber/.racket/6.12/pkgs/gregor-lib/gregor/main.rkt: [traversing imports] /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/racket/private/misc.rkt:88:7 ... install raart, lots of "cannot open output file" error messages ... racket@> (require raart) get-module-code: no such file: # context...: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.rkt:120:0: get-module-path54 /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/syntax/modcode.
Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)
Christopher Lemmer Webber transcribed 3.3K bytes: > Timothy Sample writes: > > > Christopher Lemmer Webber writes: > > > >> Konrad Hinsen writes: > >> > >>> In my tests, all packages ended up working, but performance is indeed > >>> worse than with a Racket installation outside of Guix. > >>> > >>> It would be nice if someone with more knowledge of Racket internals > >>> could give a hint or two for debugging this issue! > >>> > >>> Konrad. > >> > >> I'm posting a bug bounty on this issue: if someone can fix this I will > >> pay them $250 USD. I don't have the time or knowledge enough of Racket > >> internals to do so myself. > > > > I have discovered a few things, but I’m not sure how to fix the > > underlying problem(s). > > > > The reason Racket is trying to recompile the OpenSSL files is because of > > a hash mismatch. This can be seen by enabling debugging output: > > > > $ PLTSTDERR=debug raco setup openssl > > > > Which says a lot of things, but most interestingly it says: > > > > > > ... > > compiler/cm: checking: > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt > > compiler/cm: different src hash... > > (5d9ca57f3e267d956c7b5e62578467beb8ccc1d2 > > 4d21ac412723fbf33f97669c2f73f0e9367f4510) > > compiler/cm: maybe-compile-zo starting > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt > > compiler/cm: start-compile: > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt > > compiler/cm: compiling > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt > > open-output-file: cannot open output file > > path: > > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340167971534016797570 > > system error: Read-only file system; errno=30 > > context...: > > ... > > -------- > > > > This hash mismatch is caused by grafting. When the package is built, > > the path to OpenSSL gets hard-coded in a source file. The SHA-1 hash > > for this file is stored in its “.dep” file. When the output is > > grafted, the source file gets updated with a new OpenSSL path, but the > > hash does not get updated. This makes Racket think that the cached > > bytecode file is incorrect (even though it was likely grafted too), > > and it tries to recompile it. It fails because it tries to write this > > new bytecode file to the store. > > Interesting... I hadn't even considered grafting. (I still wonder why > it's even trying to open *any* file in the store for output though...) > > > I double checked this by trying with an ungrafted Racket, and got better > > results. (There was still a warning about writing to the store, but it > > seemed less significant.) > > Cool! > > > The only thing I can think of for a fix would be to patch Racket to be > > more lenient with bytecode files in the store. That is, ignore hash > > mismatches in store-files. I might give this a try later tonight if > > nobody has any better ideas. > > > > -- Tim > > BTW, some examples of packages where I've had trouble, in case it helps > with testing: > > - Raart > - Gregor > - crypto (seemed to work last time, not sure why it wasn't working before) > > Though at this point I also can't do just "raco setup" on a local > package either, but maybe resolving this issue will fix that. > From what I've learned in the last couple of hours, the last problem could be due to leftovers in your raco / dotRacket folder from an older installation.
Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)
Timothy Sample writes: > Christopher Lemmer Webber writes: > >> Konrad Hinsen writes: >> >>> In my tests, all packages ended up working, but performance is indeed >>> worse than with a Racket installation outside of Guix. >>> >>> It would be nice if someone with more knowledge of Racket internals >>> could give a hint or two for debugging this issue! >>> >>> Konrad. >> >> I'm posting a bug bounty on this issue: if someone can fix this I will >> pay them $250 USD. I don't have the time or knowledge enough of Racket >> internals to do so myself. > > I have discovered a few things, but I’m not sure how to fix the > underlying problem(s). > > The reason Racket is trying to recompile the OpenSSL files is because of > a hash mismatch. This can be seen by enabling debugging output: > > $ PLTSTDERR=debug raco setup openssl > > Which says a lot of things, but most interestingly it says: > > > ... > compiler/cm: checking: > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt > compiler/cm: different src hash... (5d9ca57f3e267d956c7b5e62578467beb8ccc1d2 > 4d21ac412723fbf33f97669c2f73f0e9367f4510) > compiler/cm: maybe-compile-zo starting > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt > compiler/cm: start-compile: > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt > compiler/cm: compiling > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt > open-output-file: cannot open output file > path: > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340167971534016797570 > system error: Read-only file system; errno=30 > context...: > ... > > > This hash mismatch is caused by grafting. When the package is built, > the path to OpenSSL gets hard-coded in a source file. The SHA-1 hash > for this file is stored in its “.dep” file. When the output is > grafted, the source file gets updated with a new OpenSSL path, but the > hash does not get updated. This makes Racket think that the cached > bytecode file is incorrect (even though it was likely grafted too), > and it tries to recompile it. It fails because it tries to write this > new bytecode file to the store. Interesting... I hadn't even considered grafting. (I still wonder why it's even trying to open *any* file in the store for output though...) > I double checked this by trying with an ungrafted Racket, and got better > results. (There was still a warning about writing to the store, but it > seemed less significant.) Cool! > The only thing I can think of for a fix would be to patch Racket to be > more lenient with bytecode files in the store. That is, ignore hash > mismatches in store-files. I might give this a try later tonight if > nobody has any better ideas. > > -- Tim BTW, some examples of packages where I've had trouble, in case it helps with testing: - Raart - Gregor - crypto (seemed to work last time, not sure why it wasn't working before) Though at this point I also can't do just "raco setup" on a local package either, but maybe resolving this issue will fix that.
Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)
Christopher Lemmer Webber writes: > Konrad Hinsen writes: > >> In my tests, all packages ended up working, but performance is indeed >> worse than with a Racket installation outside of Guix. >> >> It would be nice if someone with more knowledge of Racket internals >> could give a hint or two for debugging this issue! >> >> Konrad. > > I'm posting a bug bounty on this issue: if someone can fix this I will > pay them $250 USD. I don't have the time or knowledge enough of Racket > internals to do so myself. I have discovered a few things, but I’m not sure how to fix the underlying problem(s). The reason Racket is trying to recompile the OpenSSL files is because of a hash mismatch. This can be seen by enabling debugging output: $ PLTSTDERR=debug raco setup openssl Which says a lot of things, but most interestingly it says: ... compiler/cm: checking: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt compiler/cm: different src hash... (5d9ca57f3e267d956c7b5e62578467beb8ccc1d2 4d21ac412723fbf33f97669c2f73f0e9367f4510) compiler/cm: maybe-compile-zo starting /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt compiler/cm: start-compile: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt compiler/cm: compiling /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt open-output-file: cannot open output file path: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340167971534016797570 system error: Read-only file system; errno=30 context...: ... This hash mismatch is caused by grafting. When the package is built, the path to OpenSSL gets hard-coded in a source file. The SHA-1 hash for this file is stored in its “.dep” file. When the output is grafted, the source file gets updated with a new OpenSSL path, but the hash does not get updated. This makes Racket think that the cached bytecode file is incorrect (even though it was likely grafted too), and it tries to recompile it. It fails because it tries to write this new bytecode file to the store. I double checked this by trying with an ungrafted Racket, and got better results. (There was still a warning about writing to the store, but it seemed less significant.) The only thing I can think of for a fix would be to patch Racket to be more lenient with bytecode files in the store. That is, ignore hash mismatches in store-files. I might give this a try later tonight if nobody has any better ideas. -- Tim
Re: [racket-users] Using Racket's raco on on Guix(SD)
Konrad Hinsen writes: > On 22/05/2018 15:42, Christopher Lemmer Webber wrote: > >> Unfortunately when I try to install packages with "raco pkg install" >> I get errors like the following: > > I filed a bug report about this problem a while ago: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30680 > > Quote: > > I traced this back as far as I could by looking at the Racket compiler > source code. Compilation generates a temporary file in the same > directory where the result is supposed to go. If no errors occur, the > temporary file is then renamed to become the output. The partial stack > traces point to locations in the code that do a recursive traversal of > a library in order to compile everything. Unfortunately, the part that > decides where the output goes is not referenced in the stack trace. > >> I seem to remember a couple of packages failing altogether, though in >> the present moment I think the result is bad performance due to not >> being properly compiled, but I'm not really sure. > > In my tests, all packages ended up working, but performance is indeed > worse than with a Racket installation outside of Guix. > > It would be nice if someone with more knowledge of Racket internals > could give a hint or two for debugging this issue! > > Konrad. I'm posting a bug bounty on this issue: if someone can fix this I will pay them $250 USD. I don't have the time or knowledge enough of Racket internals to do so myself.
Re: racket patch not found
Marco van Hulten writes: > Hi Mark, others— > > Je 14 jul 16:38 skribis Mark: >> Marco van Hulten writes: >> >> > When I install the package `racket' through >> > >> > guix pull &&\ >> > guix package -i racket >> > >> > I get this error: >> > >> > guix package: error: racket-fix-xform-issue.patch: patch not found >> >> This was fixed in commit 57ac5261fec345b16cf80f87aa03212abc2c5a11, >> pushed a few days ago. >> >> >> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=57ac5261fec345b16cf80f87aa03212abc2c5a11 >> >> If you "guix pull" and try again, hopefully it will work now. > > Yes, it does! > > It did warn me about no readline support: > > $ racket > Welcome to Racket v6.12. > ; Warning: no readline support (ffi-lib: couldn't open > "libedit.so.3" (libedit.so.3: cannot open shared object file: No such > file or directory)) > > > > So I installed libedit, but the warning stays and I have still no > readline support. > > Maybe I have to do add it to my LD_LIBRARY_PATH or something. Instead, > I went looking for libedit.so.3, but it wasn't in ~/.guix-profile/lib/. > When I started racket from that working directory, the warning wasn't > given and I had readline support. According to my experience binaries > indeed look in the working directory for libraries. Apparently racket > finds the useful library in ~/.guix-profile/lib/. But what file is it, > and why does it not need to be "libedit.so.3"? > > —Marco > This sounds like a bug in the way we have packaged racket. If that's the case, then somebody probably needs to change the package definition so that we build in readline support. It shouldn't be necessary for you to install readline into your profile after the fact. Similarly, it shouldn't be necessary for you to meddle with LD_LIBRARY_PATH to get things working. -- Chris signature.asc Description: PGP signature
Re: racket patch not found
Hi Mark, others— Je 14 jul 16:38 skribis Mark: > Marco van Hulten writes: > > > When I install the package `racket' through > > > > guix pull &&\ > > guix package -i racket > > > > I get this error: > > > > guix package: error: racket-fix-xform-issue.patch: patch not found > > This was fixed in commit 57ac5261fec345b16cf80f87aa03212abc2c5a11, > pushed a few days ago. > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=57ac5261fec345b16cf80f87aa03212abc2c5a11 > > If you "guix pull" and try again, hopefully it will work now. Yes, it does! It did warn me about no readline support: $ racket Welcome to Racket v6.12. ; Warning: no readline support (ffi-lib: couldn't open "libedit.so.3" (libedit.so.3: cannot open shared object file: No such file or directory)) > So I installed libedit, but the warning stays and I have still no readline support. Maybe I have to do add it to my LD_LIBRARY_PATH or something. Instead, I went looking for libedit.so.3, but it wasn't in ~/.guix-profile/lib/. When I started racket from that working directory, the warning wasn't given and I had readline support. According to my experience binaries indeed look in the working directory for libraries. Apparently racket finds the useful library in ~/.guix-profile/lib/. But what file is it, and why does it not need to be "libedit.so.3"? —Marco
Re: racket patch not found
Hi, Marco van Hulten writes: > When I install the package `racket' through > > guix pull &&\ > guix package -i racket > > I get this error: > > guix package: error: racket-fix-xform-issue.patch: patch not found This was fixed in commit 57ac5261fec345b16cf80f87aa03212abc2c5a11, pushed a few days ago. https://git.savannah.gnu.org/cgit/guix.git/commit/?id=57ac5261fec345b16cf80f87aa03212abc2c5a11 If you "guix pull" and try again, hopefully it will work now. Mark
racket patch not found
Hi— When I install the package `racket' through guix pull &&\ guix package -i racket I get this error: guix package: error: racket-fix-xform-issue.patch: patch not found Cheers, —Marco
Re: [racket-users] Using Racket's raco on on Guix(SD)
On 22/05/2018 15:42, Christopher Lemmer Webber wrote: Unfortunately when I try to install packages with "raco pkg install" I get errors like the following: I filed a bug report about this problem a while ago: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30680 Quote: I traced this back as far as I could by looking at the Racket compiler source code. Compilation generates a temporary file in the same directory where the result is supposed to go. If no errors occur, the temporary file is then renamed to become the output. The partial stack traces point to locations in the code that do a recursive traversal of a library in order to compile everything. Unfortunately, the part that decides where the output goes is not referenced in the stack trace. I seem to remember a couple of packages failing altogether, though in the present moment I think the result is bad performance due to not being properly compiled, but I'm not really sure. In my tests, all packages ended up working, but performance is indeed worse than with a Racket installation outside of Guix. It would be nice if someone with more knowledge of Racket internals could give a hint or two for debugging this issue! Konrad.
