<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.` <leoprikler>you might want to check the configure.ac whether it mentions guile 3.0 and patch it if it doesn't <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 ***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>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! <sarna>leoprikler: well, the full command I'm running is `autoreconf -vif && ./configure GUILE=/gnu/store/0r5qh5wyb2cp6799l8wph1k1zqvx9vnh-profile/bin/guile && make && exit` <wingo>leoprikler: yeah, should be fine ***xws is now known as wxie
<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 <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>"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>"openat(AT_FDCWD, "containers/./queue_impl.scm", O_RDONLY)" which is not the relative path. I assume this is a bug? <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 <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>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 <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." <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>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 <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 <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 <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! <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 Makefile.am <leoprikler>what would that roughly look like? adding some -DPIC -fPIC to a LIBRARIES' LDFLAGS? <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) <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>You could use the FFI to make bindings to scm_c64vector_elements and scm_c64vector_writable_elements? <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) <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>I'm already using make-c-struct, which returns a raw pointer <leoprikler>I *could* use that raw pointer and section it though <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 <leoprikler>sure, but I don't want to always make and parse to change a single field <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>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 <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 <leoprikler>again, as I explained, it's relative to the current file, which is relative to the current directory <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* <leoprikler>provide a way for users to specify other directories to search. <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. ***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 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
<RhodiumToad>there were some server restarts and temporary loss of sasl auth <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?