IRC channel logs

<fosskers>Hi there again, sorry had to re-login.

<fosskers>What's the best way to run the Scheme tests?

<fosskers>Is it possible to envoke them from `make`?

<chrislck>sneek: botsnack

<sneek>:)

<dsmith>sneek, botsnack

<sneek>:)

<dsmith>goodbot

<mwette>guile tests: make check

<fosskers>mwette: thanks, that does it!

<mwette>yw

<mwette>ACTION is trying to get a patch out for mmap

<lloda>anyone has seen this __thread related error

<lloda> http://paste.debian.net/1264693

<lloda>it went away when i put SCM_INTERNAL in the .c, which makes no sense to me

<lloda>gcc 12 under os x 12.6 if that means anything

<fosskers>Is there a way to target certain tests?

<fosskers>I've also written a test that fails just to see what the output is, and it doesn't look like the nature of the failing test is actually reported. `make check` tells me the pass/fail totals, but nothing else. Am I doing something wrong?

<mwette>there is a way, lemme check ...

<daviid>mwette: indeed, cd <test-suite-location>; ./check-guile numbers.test [for example ...]

<daviid>fosskers: ^^

<mwette>daviid: thanks

<daviid>np!

<fosskers>This worked from the project root: ./check-guile srfi-171.test

<fosskers>...and did just what I was looking for! Thank you

<old>lloda: Something with TLS model is happening during linkage. Looks like the TLS model is not the same every where

<old> https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html#Thread-Local and https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes#tls_model

<old>for the releavant documentations

<old>look for attribute: tls_model

<daviid>fosskers: ah right, from the project root indeed - even better :)

<lloda>old: i saw that but not anything that explains the error. SCM_INTERNAL is just extern and guile doesn't set any explicit tls options that i can see

<lloda>guile builds fine if i add that :-/

<flatwhatson>weird that gcc claims it's "previously defined" in the .c file, not the .h file

<flatwhatson>lloda: it seems like a quirk of "thread_local" defaulting to internal linkage, whereas normal declarations default to external linkage

<flatwhatson>so "extern" is redundant on file-scoped variables but "extern thread_local" is not necessarily redundant with "thread_local"

<flatwhatson>anyway there's no harm in duplicating SCM_INTERNAL in the .c declaration

<haugh>What's going on here? http://vpaste.net/tfJ3Q

<haugh>I understand literals are immutable, so why does lst return a mutated list? Or does it? I would have accepted either behavior, but both is weird.

<haugh>if this is too scheme-agnostic for guile that's okay

<graywolf>Hi :) Is there a way to load file from the same directory the currently running script is in? If you know ruby, I'm basically looking for a way to do `require_relative'.

<haugh>graywolf, it's probably worth your time to learn the module system, but for ad-hoc scripts either check out the command line args in Scripting Examples or use primitive-load-path, string-append, dirname, and current-filename

<haugh>Also I'm new so absolutely not the last word on this

<chrislck>haugh: after your two (use-modules), add ,expand in front of your (match ...)

<graywolf>Thanks for tips, will check it out. My use-case is to load some parts of operating-system from separate file, and I have no idea how guix system reconfigure sets up the module load paths. So just relative load seemed much easier.

<haugh>chrislck, ah.

<haugh>Let me just add ,expand to my list of things to check before i post here

<old>haugh: Guix does not setup module load paths. Guile does

<old>You can use the `-L` switch to add a directory to the load path for all Guix commands I think

<old>So something like: `guix system -L . reconfigure systemc-configuration.scm`

<mwette>graywolf: (current-filename) ??

<old>I meant that Guile is the one who resolve modules. Guix augment the %load-path variable

<graywolf>Ah, thanks everyone. Based on the advices received I think I will check out the guile modules, and the documentation even has an example of `(add-to-load-path (dirname (current-filename)))', so I'll work from that.

<graywolf>I would like to keep external interface the same (so no -L argument to guix), so this seems like a promising approach.

<graywolf>Only thing is, I do not see remote-from-load-path function, in order to write my own I need to manually patch both %load-path and %load-compiled-path, correct?

<graywolf>remove-from*

<old>looking at `add-to-load-path`: (define-syntax-rule (add-to-load-path elt) (eval-when (expand load eval) (set! %load-path (cons elt (delete elt %load-path)))))

<old>So `remove-from-load-path` could be: (define-syntax-rule (remove-from-load-path elt) (eval-when (expand load eval) (set! %load-path (delete elt %load-path))))

<old>lloda: What's guile4 btw?

<lloda>flatwhatson: ty, that helps. Not sure if it makes sense to add the fix if i'm the only one having the problem

<lloda>old: that's just a directory where i build guile

IRC channel logs

2022-12-20.log