IRC channel logs
2025-01-11.log
back to list of logs
<lechner>mwette / you are one the jpl saviors feted in the press! <lechner>mwette / Thanks for your help earlier! Guile-PAM was ported to Nyacc 2.01.4. It works and is already deployed locally. Due to my difficulties, it doesn't include callbacks yet---it is otherwise feature-complete---but I am more comfortable working on them now. <mwette>Good to hear. I'll take a look later. <lechner>Hi, anyone know how to get the first string from a char** with cdata? <mwette>(pointer->string (cdata-ref x 0)) ? <mwette>good to hear about the callbacks; is the implementation cleaner? <ttz>How complex would it be to associate some optional contract-style information to functions to help the optimizer? Has this ever been an objective for Guile? <ttz>I mean Guile currently has no concept of contract if I am not mistaken. Some function usually require inputs of statically known types, but if my understanding is correct those types are checked at runtime. One could make them explicit using an (unless (some-pred? some-arg) (error ...)), as demonstrated in https://dthompson.us/posts/optimizing-guile-scheme.html. But how much confidence can I have in the fact that the compiler will take <ttz>them into account? Also these checks if written like that are not extractable to be used for example in automated testing. <Arsen>do you mean something like the ftype declaration of elisp? <ttz>I really couldn't as I have basically zero knowledge of elisp... <ttz>I was thinking of something similar to Racket contracts, also this https://codeberg.org/dpk/tinycontract which seems interesting. But the objective would be more modest: guiding compiler optimizations and automated test generation. <dpk>(that code should probably not be used as a serious example of anything whatsoever) <ttz>works for illustration purpose imho :) <dpk>also, Guile does not have continuation marks, so the trick used there to ensure tail calls work as expected won’t be applicable to Guile <ttz>yes, but if contract does not enforce output checks this is not a problem <ttz>which would not be optimal but would already be something to work on <ttz>what I was thinking about initially was a way to partially automatize PBT <ttz>If input/output properties are "attached" to procedures then a PBT framework should be able to extract them and produce test-suites <ttz>but that couldn't be used by the compiler as hint <ttz>thus my question about Guile's road-map <dthompson>taking a quick look at defined-type I see that it allocates at least 3 lists to type check the args and a fourth for the return values list. if the goal is increased performance and not just type checking then I don't think define-typed fits the bill. <ttz>its functionality is close to what I would like nonetheless <dthompson>the general problem space is that sure, you can do arg and return checking just fine. you can make a define-typed that uses syntax-case and gets rid of most or all of the allocation. but what you really want to ensure is that a call between two define-typed procedures incurs *no* runtime overhead because the types can be checked statically at compile-time. <ttz>well, ideally static flow analysis should be able to remove predicate checks when it can prove the caller's is stricter than the callee. I don't know if all runtime overhead can be removed. <ttz>And anyway, if these kind of checks are important from a correctness point of view, then they should already be written somewhere and their price paid at runtime. <dthompson>is there a specific project that all this micro analysis of performance characteristics is being motivated by? <ttz>well I am trying to understand how to write efficient Guile code generally <ttz>also, I was trying to understand how to make data-structure implementations faster <mwette>wrt Guile's optimization, is #:optional as effective as case-lambda? <dthompson>if both the callee and optional/keywords args are known at compile time then an optimization is applied <dthompson>my understanding is that keyword args should be basically free at runtime if those conditions are met <mwette>That's great to hear. I had been running on assumption that keywords were expensive, requiring essentially a dict-lookup. <mwette>Maybe Guile could have a `gassert' syntax that would work with a Guile flag 9e.g., --debug) to enable/disable checking at runtime, but would serve as hint to the compiler for optimization. <mwette>(define (fp-add x y) (gassert (float? x) (float? y)) (+ x y)) <ttz>well these checks must be made at runtime at some point, otherwise you have to type all your code to prove it is correct <ttz>the idea was rather to do they once per function for example when doing a lot or arithmetic, rather than per operator application. Could make the job of the optimizer easier to specialize those operators <dthompson>guile will already unbox and optimize your arithmetic if you guard the code with the proper predicates <ttz>yes, the second part of it was to allow reifying those guards to use them for test generation <ttz>Then large portions of code could be checked naively without much more input from the developer <ttz>I don't know how far this could go (i.e. how complex the guard properties could be while allowing automated test generation), but the idea of automatically testing code and in the same time helping the compiler is appealing. <ttz>yes, I guess this is the best way to implement it efficiently <ttz>Is there a Guile's road-map somewhere? I would like to know where the language is heading, if such thing has ever been made explicit <ttz>(I follow the wingolog so I got the wasm and gc things) <dsmith>I suspect a new GC is on guile's roadmap, based on recent content in the wingolog ... <dthompson>hopefully the wasm backend will become part of guile eventually, too <rgherdt>the second example errors out with: "While compiling expression: In procedure =: Wrong type argument in position 1: #<unspecified>" <mwette>put test2 in a file test2.scm and type `guild compile test2.scm'. It points to type-fold.scm, line 897 (for guile-3.0.10-72-ebbb1) <mwette>sorry , line 28 in materialize-constant <dthompson>yeah this looks like a legit bug. a silly one! <dodoyada>I'm working on a multi-module project and keep getting bit by what I think is a different in what is compiled and what isn't. For example, I'll change a file then realize my repl isn't started, start the repl, then have to `geiser-compile-current-buffer` or otherwise invoke the module before my change will be reflected. I know I could write something to make sure everything is compiled during repl startup but I'm wondering if the <dodoyada>are already options to do that or if I could insist on an interpreted mode for the repl <dthompson>guile autocompiles by default so when you import the module it will be compiled <dodoyada>that makes sense, I wonder how I'm running into this issue <mwette>I think there may be issues if you import foo, and foo imports bar, and then you edit bar. <dthompson>gnutls and async i/o play together very poorly... when you call open-socket-for-uri you may not get back a socket at all but a soft port that wraps a socket. however that means you can't set socket flags like O_NONBLOCK. <mwette>Does port->fdes on the softport give anything useful?