IRC channel logs
2023-05-08.log
back to list of logs
<RhodiumToad>ACTION wonders why (identity) doesn't seem to be inlinable, or otherwise optimized out <lloda>it's not defined as inlinable <lloda>is it optimized if you replace (define (identity x) x) by (define-inlinable (identity x) x) ? <RhodiumToad>ACTION writing a macro to generate a bunch of methods that are basically wrappers, and mostly the parameters need a transform function to be called, <RhodiumToad>(think passing a string to a foreign function using string->pointer, but an integer just gets passed as-is) <RhodiumToad>I already did it by defining my own inlinable function, but was just wondering if there was a reason why (identity) itself wasn't optimized <lloda>i don't think the compiler knows anything about (identity) the way it knows about some other functions like apply etc. <RhodiumToad>obviously it'll get called out-of-line a lot, because you often pass it as a parameter to other functions <RhodiumToad>after all, there's no actual reason to write (identity foo) in normal code, unless it's coming from a macro <lloda>optimizing macro output can be important <lloda>idk if you'd need to add identity to tree-il to handle this <lloda>that's true. You could just use values instead RhodiumToad <flatwhatson>it sounds like we're working on similar stuff, i've been playing with foreign function wrappers lately too <flatwhatson>FFI boilerplate which is just a bunch of repetitive wrap/unwrapping between scheme & foreign types sucks, even if we have some decent tools to autogenerate some of it <flatwhatson>(the stuff below there is a wishlist of patterns to be supported; output params & converting error codes into exceptions) <flatwhatson>but eg. the cstring type handles converting arguments & returns with pointer->string and string->pointer, the enum types are symbol<->int, pointers are wrapped/unwrapped, etc. <lloda>why do assoc and assoc-ref have reversed arguments grrr <lloda>i wish this could be fixed somehow. Move the old functions to a module, make a new module with fixed defs, idk <mwette>flatwhatson: ffi-helper in nyacc automatically generates pointer->procedure calls, enum symbol<->int conversions etc. You feed it the name of a dot-h file. <mwette>some parts need updates; a big job coming some day <elevenkb>hello there, i'm trying to import a package which calls (current-filename) <elevenkb>the issue is that this evaluates to #f, and I have no clue how to let it know where the file comes from. <old>elevenkb: are you in a REPL? <old>guile test.scm => test.scm <elevenkb>old: thanks... i ended up patching the source code to the module so that I manually set the value for a certain variable that depends on (current-filename). <lloda>it's shorthand for, you run what's on the left and you get what's on the right <elevenkb>lloda: thanks for the clarification though, i intially thought it was shell related. <old>elevenkb: nope just a way so say that's the output you get :-) <daviid>lloda: do you prefer alist key or key alist? <mirai>how can I find out what kind of exception was raised within a REPL? <acrow>I went to run scheme48 in a shell and it went horribly wrong. 'guix shell scheme48', seems to go wrong for me. Anyone else? I see it on two different instances of guix system; so, hmmmm... <acrow>Sorry -- posted to the wrong channel. <mirai>is (addrinfo:addr (car (getaddrinfo "::" #f AI_NUMERICHOST ))) supposed to return #(10 0 0 0 0) ? <mirai>the first element in that vector corresponds to addrinfo:fam, is that intentional? <flatwhatson>mirai: it's a sockaddr "object", which is represented as a vector instead of being opaque