<bandali>hey folks, anyone know how i could access a post's metadata in footer, when using haunt? <bandali>i'd like to have different license years per posts/pages ***jao is now known as Guest23569
<daviid>str1ngs: I pushed a series of patches, code, doc and tests, so g-golf can import namespace constants (on demand, see %g-priorities in (g-golf hl-api glib) for ane example, then added this optional argument T was refering to, to g-idle-add, g-timeout-add, g-timeout-add-seconds and g-unix-fd-add <sneek>Welcome back daviid, you have 1 message. <sneek>daviid, str1ngs says: looks good thanks. <rlb>Any thoughts about what might cause (begin-thread #t) to hang? It doesn't from a prompt, but it does in a case here during a module's compilation (though there are a lot of other moving parts -- but no other intentional threads/concurrency). <wingo>rlb: is there forking involved? <zig>rlb: did you try to pre-compile all the files before executing your program? <zig>rlb: previously my program was crashing because of the module system involved in posix threads <zig>I think I figured the bug with my for-each-par-map, I need to manage the job queue, instead of expecting some magic to happen in the channel. ***sneek_ is now known as sneek
<lloda>how about we put srfi-1 iota in core and reexport that? the iota in core is incompatible and not documented :-/ <davidl_>Why can't I use ~/.guix-profile/bin/guile as the shebang for my guile-scripts? Also, using /usr/bin/env guile -s -e main doesn't work either unfortunately. Is this fixable? <wingo>~ doesn't get expanded in shebang lines <davidl_>wingo: correct, it's perhaps more of a bash/shell issue than a guile one. <davidl_>I am using Guix on a foreigh distro, so I don't have /run/current-system/profile/bin/guile and I don't want to hardcode which user's guile-binary to use either; so really Im just looking for some kind of workaround. <lloda>technically an incompatible change I guess b/c the old (iota -9) => () <lloda>suite passes and I think it's right for that to be an error as in srfi-1 <roelj>I used “dynamic-func” to call the C function. Now I only need to pass it two numbers that were originally defined as #DEFINE macros in C. How does that work? Can I create a bytevector and then bytevector->pointer, and pass a call to dereference-pointer of that pointer to the C function? <zig>if the number were original defined as #define, then they are not part of the shared library. <zig>you need to copy those number scheme side. <roelj>zig: Right, and how do I specify the numbers on the Scheme side? Must it be a bytevector, or can it be just (define number 3)? <zig>roelj: it depends on what the function expects as arguments. If it expects some kind for char ** you can use a bytevector, otherwise just pass a scheme integer. <zig>s/some kind for/some kind of/ <wingo>lloda: sgtm; please add a NEWS entry tho, and wait to commit until after the release (in progress) <roelj>RhodiumToad: First I do: (define my-func (pointer->procedure '* (dynamic-func ...) ...)), and then I call it as (my-func 1 2 3). <RhodiumToad>ok. so as the docs say, " arguments and return values from foreign functions are represented as Scheme values." <RhodiumToad>you will have to specify the argument type as expected by the C function in the arg types parameter to pointer->procedure <lloda>when I call fortran I need to do (bytevector->pointer (s64vector x)) or w/e since all fortran args are pointers <roelj>I'm only puzzling now how to pass a pointer to the number. <lloda>I think that's what you need <roelj>RhodiumToad: LDAP_F( int ) ldap_set_option LDAP_P((LDAP *ld, int option, LDAP_CONST void *invalue)); <RhodiumToad>so the "option" parameter is not a pointer, and you don't pass it as such <RhodiumToad>the "invalue" parameter is a pointer, and what you pass depends on what the option expects? <roelj>RhodiumToad: In the source code it indeed handles the type per "option". <roelj>RhodiumToad: For the option I want to use it does: int vers = * (const int *) invalue; <roelj>RhodiumToad: So I suppose I need to create a signed integer, but how do I know which length? <roelj>RhodiumToad: Is it always 32-bit? <roelj>And.. How can I determine the endianness? <RhodiumToad>you could use make-c-struct to make a struct containing one int, and pass that <RhodiumToad>since it so happens that in C, a pointer to a struct is the same thing as a pointer to its first element <roelj>RhodiumToad: That's very clever! <roelj>So if I want to pass the value 3, I could do: (make-c-struct (list int) (list 3)) ? <roelj>And “make-c-struct” gives a pointer to that struct, so I can just pass the value of (make-c-struct ...) directly to that int* parameter? <roelj>Should I “free” it afterwards? <roelj>RhodiumToad: Thanks a lot! I wouldn't have thought of using make-c-struct myself. Very clever! <RhodiumToad>the other way would be to make a one-element bytevector of a type chosen based on (sizeof int) <roelj>SRFI-4 makes it a bit easier.. <roelj>But I have more faith in the C struct, because I can understand how that works. <lloda>oh I'm sorry about the whitespace :-( <lloda>I was getting warnings like WARNING: (guile-user): imported module (srfi srfi-1) overrides core binding `iota' even with the #:replace <lloda>this fixes it, but I'm not sure why it happened before tbh <wingo>humm if that were the concern it could indicate a bug somewhere <lloda>there are ther :replace'd functions like map for-each etc. <wingo>yes but i was working in that area recently and i need to know if i caused bugs <wingo>i.e. the #:re-export-and-replace things <lloda>I'll see if I can get a test case pre-patch <wingo>(does guile-devel take a while to deliver? usually not but i changed somemthing about my mail setup that makes it maybe slow) <wingo>weird, my messages to guile-devel are taking a while to go thru <lloda>that's a bit better wingo, but why is Guile slower than 2.0 there? it's just vector-ref vector-set! etc <wingo>just for context, guile 2.9.6 is faster than 2.2.6 in almost all benchmarks. there are about 4 for which it's slower <wingo>if you look at the generated bytecode, this is a case where we see more instructions in 3.0 vs 2.2 because its instructions are lower-level <wingo>2.2 actually compiles really nice loops for these, for its vm <wingo>and one of the instructions is vector-set!, which is something of a macro-instruction <wingo>so it effectively benefits from better register allocation, whereas between the more numerous instructions for 3.0 we are always storing to the stack <wingo>and then there's an optimization that fails in 3.0; we can't hoist the in-bounds check, because the range inferrer can't say "I don't know what the range of X is but I do know it's always lower than whatever Y is" <wingo>if it were a "normal" loop forward to the vector length it would have worked, but it's a loop counting down <wingo>but, i don't know exactly what to do there yet <lloda>we can fix the benchmark to count upwards :-D <lloda>I can see that sophisticated range analysis is a larger task <wingo>i am sure there are textbook approaches that we could just take <lloda>if you use array map etc. the bound checks are all done outside and aren't necessary <lloda>but you cannot tell the xxx-ref function that's the case <lloda>so the compiler has to be smarter like that <lloda>that you convert the map to a loop and then the compiler has to figure out that the loop was a map <jonsger>oke, at least the git:// link still works for cloning :) <wingo>apparently gnu servers are being hit by a botnet and so everything savannah-related is slow. apparently mail delivery also. <bandali>a bunch of others things like debbugs are also down <bandali>the fsf sysadmins have been notified <lloda>I have a test for the bogus :replace warning wingo <jonsger>I know. I'm just happy that there is still a way for fetching :) <lloda>on 2.9.6 before my iota patch <wingo>your iota patch removes the export from srfi-1 <lloda>it moves iota from :replace to :re-export <wingo>ok so it is a problem with the interfaces made by `import` *wingo sent a guile 2.9.6 release mail but it hasn't arrived yet :P *chrislck would like to ask for code review..... one inefficiency I see in gnucash is the GList <-> scm_list conversion <chrislck>the glib g_list is traversed, building scm_cons cells in reverse and scm_reverse() <chrislck>I'm exploring creating a C struct splitpair_s with car/cdr/nullp <chrislck>and instead of C Glist -> SCM list traversal, we traverse these mycons cells in scm <chrislck>the question is whether anyone has any example similar code I can peek <lloda>Warning: Unwind-only stack overflow exception; skipping pre-unwind handler. <wingo>is the stack overflow a bug in guile? <wingo>or is it in your code somehow, like in a macro or something <lloda>I'm checking it now, it worked before tho <lloda>looks like a normal function (?) <lloda>I need to revert to make it work, will have to look at it later <zig>the + lambda I defined in the let, is translated into ((lambda ((name . +)) (lambda-case (((a b) ... I understand the purpose of lambda-case but what is the purpose of (lambda ((name . +)) <zig>the s-expr immediatly following `lambda` symbol, is an association list of properties. in the above case it means the 'name of the lambda is the symbol '+ <zig>that is explained in the manual. <wingo>dsmith-work: it's actually 2.9.6 <wingo>it's that thing where you don't autoreconf and it doesn't regen your version :P <ArneBab>That’s a pretty nice speedup! Is there something that can be done to fix those 4 slowdowns? <rlb>wingo, zig: no explicit forking involved, but maybe that's it i.e. (as a hack) I was trying to get the class of a future so I could use it in a method specialization, i.e. (define <future> (class-of (future #t))) (since it's not normally provided?). And that would be happening at compile time by default. <rlb>So potentially not ok to use threads during compilation? (Ignoring for the moment whether or not I should have been attempting what I was attempting.) <rlb>(And I'm not even sure that was going to work right -- I seem to recall noticing that record-derived classes might not always play nice with goops.) <jonsger>where are the logs for test-suite/tests/*.test saved? <jonsger>version.test fails but there's only "FAIL: version.test: version reporting works" in the log. No backtrace <wingo>jonsger: are you building from git or from the release <wingo>then you need to autoreconf again <jonsger>wingo: I do run autogen.sh before `make check` <wingo>i guess that should be sufficient. weird that you are seeing those errors 