IRC channel logs


back to list of logs

<bandali>hey folks, anyone know how i could access a post's metadata in footer, when using haunt?
<bandali>(i.e. in my site #:layout)
<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 :-/
<bandali>hey rekado, are you around?
<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>but still
<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?
<roelj>Can I just pass it numbers?
<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/
<roelj>thanks zig!
<wingo>lloda: sgtm; please add a NEWS entry tho, and wait to commit until after the release (in progress)
<lloda>thx wingo, will do.
<RhodiumToad>roelj: how exactly are you calling the function?
<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
<RhodiumToad>roelj: how is the C function declared?
<roelj>RhodiumToad: LDAP_F( int ) ldap_set_option LDAP_P((LDAP *ld, int option, LDAP_CONST void *invalue));
<roelj>So number to void*
<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?
<RhodiumToad>ah. I think I see the issue.
<RhodiumToad>you're trying to pass LDAP_OPT_ON / LDAP_OPT_OFF ?
<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>I guess not :)
<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)
<RhodiumToad>more complex, and seems no obvious advantage
<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>wingo: pushed
<lloda>oh I'm sorry about the whitespace :-(
<lloda>I'll fix it
<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>well more like the trigger
<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>i looked into that today
<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>for array1, the code is here:
<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
<lloda>nested loops etc. as well
<wingo>i am sure there are textbook approaches that we could just take
<wingo>there's something called "abcd" that is apparently the thing:
<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's a bit frustrating
<lloda>that you convert the map to a loop and then the compiler has to figure out that the loop was a map
<wingo>hehe yeah
<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>ah i see, cool.
<wingo>ok so it is a problem with the interfaces made by `import`
<bandali>debbugs is back
*wingo sent a guile 2.9.6 release mail but it hasn't arrived yet :P
<bandali>yeah something's fishy
*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.e. beautiful but obviously O(2N)
<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
<chrislck>because my attempt (which works well btw) is at
<chrislck>anyone done anything similar?
<wingo>lloda: fixed
<lloda>thx wingo :-)
<wingo>tx for the report :)
<lloda>While compiling expression:
<lloda>Warning: Unwind-only stack overflow exception; skipping pre-unwind handler.
<lloda>this is new
<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
<dsmith-work>Happy Friday, Guilers!!
<zig>happy friday :)
<chrislck>happy Friday all
<zig>I am trying to understand tree-il, in the following snippet:
<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.
<dsmith-work>That graph is for 2.9.5, not 2.9.6?
<dsmith-work>wingo: ^
<wingo>dsmith-work: it's actually 2.9.6
<wingo>will fix
<dsmith-work>Very nice
<wingo>it's that thing where you don't autoreconf and it doesn't regen your version :P
<davidl_>join #jq
<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.)
<zig>wasm became w3c recommendation ref:
<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
<jonsger>wingo: from current master
<wingo>then you need to autoreconf again
<jonsger>wingo: I do run before `make check`
<wingo>i guess that should be sufficient. weird that you are seeing those errors