IRC channel logs


back to list of logs

<sarna>thanks all! :)
<sarna>does anyone here use guile-hall? I'm having some trouble generating a package.. it complains with `configure: error: 'guild' binary not found; please check your guile-2.x installation.`
<sarna>I have guile 3 :(
<leoprikler>you might want to check the whether it mentions guile 3.0 and patch it if it doesn't
<leoprikler>hmm… GUILE_PKG([3.0 2.2 2.0])
<lampilelo>sarna: maybe you have a version of guile-hall that's linked to guile-2.2 and it wants to use that? i don't know how guile-hall works, never used it, just throwing hypotheticals
<lampilelo>maybe this will help?
***chris is now known as Guest2604
<leoprikler>what does thread/async-safety mean in the context of finalizers?
<wingo>leoprikler: what do you mean? do you mean, can finalizers run asyncs?
<leoprikler>the Guile manual states, that finalizers must be both async and thread-safe
<leoprikler>does this mean, that two threads may both try to finalize the same object or something along those lines?
<wingo>so, in a guile configured without threads, finalizers are run via asyncs.
<wingo>this is a bad situation because you don't know what locks the continuation has
<wingo>it is a similar situation to signals, where you don't know what locks the "main" program has when you are processing a signal
<wingo>to be async safe is to never take a lock that might be held when an async runs
<wingo>(see asyncs in the manual)
<wingo>however......... you might just assume that you're deploying on a guile with threads
<leoprikler>which brings me to thread-safety in the context of finalizers…
<wingo>in that case finalizers are run not from an async, but from a separate thread. so the property that you need is thread-safety, that if you go to grab a lock in a finalizer, that you are guaranteed to eventually get it
<leoprikler>here it is probably not the locks being held, which are problematic, right?
<wingo>and also that you don't mutate shared data structures (those that are referenced by the finalized object but themselves are reachable) in a thread-unsafe way
<leoprikler>so if I just call free() on a bunch of data, that's owned by my struct and supposedly invisible to Guile, everything ought to be fine?
<leoprikler>*supposedly invisible in that the user could get to that data through pointer arithmetic, but shouldn't do that
<sarna>lampilelo: it finds guile 3 in my case, but I get the same error as in the issue. `./configure GUILE=/usr/bin/guile` helped, now I'm getting a different error!
<leoprikler>what if you autoreconf -vif first?
<sarna>leoprikler: well, the full command I'm running is `autoreconf -vif && ./configure GUILE=/gnu/store/0r5qh5wyb2cp6799l8wph1k1zqvx9vnh-profile/bin/guile && make && exit`
<sarna>this time it worked???
<sarna>I didnt change anything!
<wingo>leoprikler: yeah, should be fine
<wingo>free is threadsafe
***xws is now known as wxie
<sarna>when I try to install my package with guix though, I'm getting this error from hall -
<sarna>why is this so cryptic :((((
<leoprikler>because of cutoff, you don't see which directory doesn't exist
<leoprikler>it's probably an issue in how hall generates the recipe tho
<sarna>can I somehow make it spew whole lines?
<sarna>because the path that I see from here exists, it has to be some part near the end
<sarna>well now I can't even run `hall clean`, it crashes every time
<tricon>sarna: What the hall...
<sarna>Grieg should be playing in the background as we debug it
<leoprikler>sarna: life hack: call find-files on the destination directory before the crash
<leoprikler>that should give you a list of what already exists
***Guest2604 is now known as chrislck
<vijaymarupudi>I'm trying to include a .scm file relative to a r7rs library (not in current directory) and it doesn't seem to work
<vijaymarupudi>However,, seems to state that this is possible
<vijaymarupudi>"If file-name is a relative path, it is searched for relative to the path that contains the file that the include form appears in. "
<vijaymarupudi>Using strace, I found this syscall
<vijaymarupudi>"openat(AT_FDCWD, "containers/./queue_impl.scm", O_RDONLY)" which is not the relative path. I assume this is a bug?
<leoprikler>in which way is it not the relative path?
<leoprikler>containers/./ looks somewhat relative to me
<vijaymarupudi>I'm in /a and running test.scm. I have on my guile load path /libraries, which contains /libraries/containers/queue.scm that wants to include /libraries/containers/queue_impl.scm. Importing (containers queue) works for the queue.scm file, but the include then does not work.
<leoprikler>in that case containers/./queue_impl.scm is the correct (albeit not canonical) path, I'm afraid
<leoprikler>does this openat fail?
<vijaymarupudi>Yep, the openat fails, because there is no /a/containers/./queue_impl.scm
<vijaymarupudi>That syscall would be correct is CWD was /libraries, but it is not
<vijaymarupudi>And "If file-name is a relative path, it is searched for relative to the path that contains the file that the include form appears in." seems to suggest that it would be relative to the directory of queue.scm
<leoprikler>let's see if I can get a MWE going
<vijaymarupudi>fingers crossed :)
<leoprikler>yeah, you'll have to make do with include-from-path, sadly :)
<leoprikler>it's probably not an issue if you byte-compile, but it trips the interpreter up
<vijaymarupudi>Looks like you were able to reproduce it?
<vijaymarupudi>How does one do that?
<leoprikler>"Also, the particular form of include, which requires an absolute path, or a path relative to the current directory at compile-time, is not very amenable to compiling the source in one place, but then installing the source to another place."
<leoprikler>so yeah, it's known :P
<leoprikler>guild compile
<vijaymarupudi>I feel like the docs contradict themselves on that page
<maximed>Did someone see this build warning for guile before? <>
<vijaymarupudi>Personally, the earlier mentioned behavior "If file-name is a relative path, it is searched for relative to the path that contains the file that the include form appears in." is more intuitive and r7rs recommended
<vijaymarupudi>guild compile appear to work as a duct tape fix
<vijaymarupudi>Would you consider this a bug leoprikler, given the docs? If so, I can try to see if I can find where the fix would have to be
<leoprikler>The issue is not that the file is not relative to the path of the file with the include form.
<leoprikler>The issue is that the path of the file with the include form itself is a relative path, which is interpreted as relative to the current directory.
<leoprikler>This is completely fine when doing compilation, but it's not fine when not doing compilation
<leoprikler>hence include-from-path.
<vijaymarupudi>Wouldn't canonicalizing the paths after find them be sufficient to fix that?
<vijaymarupudi>The syscall to find /libraries/containers/queue.scm uses the correct absolute path for example
<vijaymarupudi>I feel like the same can be done for the relative path
<leoprikler>I'm not so sure.
<leoprikler>call-with-include-port uses the syntax form to find the dirname, and paths within that are relative instead of absolute
<leoprikler>which makes sense, you wouldn't want the syntax to change post install
<vijaymarupudi>I'm having trouble with the concept of pre and post install because my library has always been where it is
<civodul>maximed: i've seen it like you when building on 32-bit platforms
<dsmith-work>{appropriate time} Greetings, Guilers
<leoprikler>well, that's one problem with people nowadays, they can't imagine actually installing their programs :P
<maximed>civodul: was that an i{3,4,5,6}86 system, or another 32-bitplatform
<vijaymarupudi>leoprikler: haha, that's fair, but for library development, it's nice to test and hack stuff quickly, without reinstalling for each change, that's the spirit of the REPL, right :)
<leoprikler>perhaps, but when it's time to load stuff from directories that's not the working directory, one really ought to think about include-from-path instead :P
<vijaymarupudi>that would definitely work, but would restrict my code to just guile. I'm trying to switch from racket to guile, but currently need both to run the same code
<vijaymarupudi>besides the way the docs are worded, and the way r7rs discusses include, this sounds like it has to work!
<civodul>maximed: i686 i think
<vijaymarupudi>(to explore this, is there a way to run guile from the build directory of the git repo, without installing it?)
<leoprikler>note that the thing you want to patch is not C source tho
***apteryx_ is now known as apteryx
<vijaymarupudi>leoprikler, thanks! I think I'll start with call-with-include-port
<leoprikler>can autotools build shared libraries without libtool?
<leoprikler>this is particularly interesting in the context of 3.0.7, in which guile supports shared libraries built differently
<civodul>leoprikler: you can always do things by hand in
<civodul>that's no fun though
<leoprikler>what would that roughly look like? adding some -DPIC -fPIC to a LIBRARIES' LDFLAGS?
<leoprikler>I imagine not
<rlb>To some extent it probably depends on how portable you need it to be. When I recently changed bup to handle it manually, in addition to the pkgconfig pythonN-cflags I think I just needed -fPIC, and so far haven't heard complaints, but we also haven't had a release with that in it yet, and I've only tested it personally on linux, some of the bsds, and macos.
<rlb>(previously we were relying on one of python's tools to build them)
<leoprikler>can guile arrays do reinterpret_casts?
<leoprikler>e.g. bytevector to native f64?
<maximed>leoprikler: (bytevector->pointer ...), use the resulting pointer?
<maximed>If this is pure Scheme code, bytevector-ieee-double-native-ref
<leoprikler>pure Scheme, how do I get the memory-backed f64vector from that pointer?
<maximed>leoprikler: I don't know what a f64vector is
<maximed>srfi-4, it apppears
<leoprikler>a vector of 64bit floats (i.e. doubles)
<maximed>You could use the FFI to make bindings to scm_c64vector_elements and scm_c64vector_writable_elements?
<RhodiumToad>no need?
<RhodiumToad>you can just pass a bytevector to the srfi-4 functions
<RhodiumToad>(define a #vu8(0 0 0 0 0 0 240 63 0 0 0 0 0 0 0 0)) (f64vector-ref a 0) (f64vector-ref a 1)
<RhodiumToad>(returns 1.0 and 0.0)
<leoprikler>true, but what I want is to cast the #vu8 to an #f64, so that (array-ref a 1) == (f64vector-ref a 1)
<maximed>(if you do low-level type-punning, remember that guile does some optimisations based on types)
<maximed>Guile has a kind of ‘strict aliasing’ rule
<leoprikler>though tbf it probably wouldn't matter much to write a wrapper…
<RhodiumToad>you could create an #f64 initially and access it as a bytevector?
<leoprikler>nah, can't do that
<leoprikler>I'm already using make-c-struct, which returns a raw pointer
<leoprikler>I *could* use that raw pointer and section it though
<leoprikler>if I knew how
<RhodiumToad>isn't the "Foreign structs" part of the FFI doc what you're looking for?
<leoprikler>that only does the (make-c-struct ...) and (parse-c-struct ...) thing
<leoprikler>however, I want to modify the structure produced by make-c-struct in-place
<RhodiumToad>but the parse-c-struct can handle various C types?
<leoprikler>sure, but I don't want to always make and parse to change a single field
<leoprikler>that's a bit wasteful in terms of memory
<leoprikler>probably also in terms of runtime
<RhodiumToad>ok, so you have a bytevector created by make-c-struct, and you want to alias it as a typed array?
<maximed>leoprikler: I though I saw a C function somewhere to turn a C (float / u64 / ...) array into a Guile array but I can't find it anymore
<leoprikler>well, a pointer generated by make-c-struct, but I'm currently wrapping it in a bytevector
<leoprikler>I could skip the bytevector, though if there was a direct way to do what I want
<leoprikler>hmm, I could use (array-copy! ) tho…
<RhodiumToad>that's making a copy though
<leoprikler>oh, sure, but under the assumption that I can't alias, memcpy is the next best thing
<leoprikler>(particularly for a struct that holds a fixed sized array)
<leoprikler>but I guess there'd be problems with how guile interprets that array-copy
<leoprikler>although if invoking memcpy directly does what I want…
<leoprikler>okay, I just noticed the uvec_type on pointer->bytevector
<vijaymarupudi>After some investigating of troubles with relative include, I think the problem is that syntax-source returning the path relative to the load-path, but call-with-input-port using that path as relative to the current directory.
<vijaymarupudi>This mostly restates what you said leoprikler, but I think I understand it now
<leoprikler>we're all beginners :)
<vijaymarupudi>looking to contribute to guile eventually, so this was a nice exercise
<vijaymarupudi>When compiling a file, guile does know the absolute path of the file, so I need to find where that is and use that instead
<vijaymarupudi>Because include's behavior right now makes no sense
<vijaymarupudi>Any pointers to where that would be?
<vijaymarupudi>A git blame shows that wingo wrote the docs for local inclusion, can you clarify whether it is supposed to be relative to the current directory guile is begin run in, or the current file being compiled? Because the docs say both things here;
<vijaymarupudi>Sorry if I'm being a nuisance, just trying to contribute :)
<leoprikler>again, as I explained, it's relative to the current file, which is relative to the current directory
<leoprikler>double relativity
<vijaymarupudi>I guess I'm motivated by r7rs ( pg 14 which talks about include
<vijaymarupudi>If it is relative to the current file, then the path to the library should be ../libraries/containers/queue.scm and then the relative include should be ../libraries/containers/queue_impl.scm which would be great
<vijaymarupudi>I'm fine with include being relative to the current directory, but maybe check for a file relative to the current file being compiled first
<leoprikler>vijaymarupudi: *apply an implementation-specific algorithm to find corresponding files*
<vijaymarupudi>yep, I'm not saying guile is not compliant
<vijaymarupudi>The current algorithm I feel is confusing
<vijaymarupudi>I'm more inspired by the note: section
<leoprikler>be more inspired by the latter half
<leoprikler>provide a way for users to specify other directories to search.
<leoprikler>Guile does that
<leoprikler>it's called include-from-path
<leoprikler>use it
<leoprikler>be happy
<leoprikler>if you want it to be portable, use cond-expand
<leoprikler>(next page in the r7rs)
<vijaymarupudi>I'm all for making it just work, I just want to make sure the current behavior is intentional
<vijaymarupudi>I'm trying to think of use case when a library would want to include a path relative to the user's current directory, when there is a similar file relative to the libraries path.
<vijaymarupudi>I think I'm coming off as annoying, I'll take it easy now
***xws is now known as wxie
<leoprikler>Again, Guile discourages the use of plain include, probably because its semantics are weird and there are better ways of specifying what you want.
<leoprikler>It tolerates you includeing stuff if everything is within one directory tree.
<vijaymarupudi>Right, which makes sense. I think I was suggesting a minor semantics change, in which it checks relative to the file being compiled first, before going back to the usual behavior.
<vijaymarupudi>I'll stick to cond-expand and forget about this for now
<vijaymarupudi>I feel like the text in the docs: "If file-name is a relative path, it is searched for relative to the path that contains the file that the include form appears in." is misleading, I would change that if I could.
***xws is now known as wxie
<dsmith-work>Anyone have a log of when the bot went away?
<RhodiumToad>there were some server restarts and temporary loss of sasl auth
<dsmith-work>RhodiumToad: Thanks.
<vijaymarupudi>I'm trying to use include-from-path in an define-library environment and I'm getting an unbound variable error. Is there a module I have to import?