IRC channel logs
2024-11-14.log
back to list of logs
<daviid>*write a tcl/tk canvas 'model' using nyacc/ffi-helper, iirc <daviid>mwette: no big deal either, just wanted to port it to g-golf, for fun and bug tracking in case it would reveal a bug ... <mwette>Oh, the tcl/tk thing. I've been working on that, but I don't have any cairo in there. I'm working on the (tk-like) Packer (subclassed from GtkContainerClass). <daviid>ok tx - no url i can follow, if you still work on it ... <lechner->Hi, how may I trigger a vhanghup syscall from Guile, please? <lechner->old / i'm so dumb! that will work with ioctl too. thanks! <ekaitz>wingo: i found the error with the calls <ekaitz>but I think these are easier to solve than that one <ArneBab>dthompson: I mostly care about that hoot doesn’t cause pressure on regular Guile to worsen algorithmic complexity of things that already work. Changing string performance (even if some parts get faster in exchange for others getting slower) could badly break lilypond, and that must not happen. <ArneBab>dthompson: is there a way to create backend-specific implementations? “if this is run on hoot, use string-flavor-hoot, otherwise use string-flavor-c”) <ArneBab>Damn, I created an unfixable unbalanced paren ☺ <dthompson>ArneBab: I don't think that's an issue but also it's a two way street. guile should be allowed to change sometimes. <dthompson>the issue being strings in hoot vs. strings in guile. they're two separate implementations. one doesn't affect the other. <rlb>fwiw, and depending on what we're talking about, the utf-8 stuff I've been doing has/had nothing to do with hoot, i.e. I started and did that independently (as far as I know). <rlb>My impression has been that the intention to move to utf-8 internally is "long-standing" (fsvo long-standing), and that almost certainly means notable change in algorithmic complexity. <rlb>(But I may also have misunderstood.) <ekaitz>the line 14 shows a jump that is not jumping to an aligned address, but the instructions are aligned <dsmith>ekaitz, Where *should* it be jumping to? <ekaitz>dsmith: idk but surely not to an address that ends in A <ekaitz>0, 4, 8 and c are the valid endings <ekaitz>it's simply because it's jumping to the center of an instruction <dsmith>I guess what I'm asking is what is the intended target of that jump? Some code that already exits? Something that is currently being generated? <ekaitz>that jump should jump over the literal pool <ekaitz>which is right after the veneers in the example <ekaitz>because the emit_literal_pool adds the jump, then all the literal pool and then patches the jump to point to the end, so yeah <dsmith>So sounds like it calculating the size of the literal pool incorrectly? <ekaitz>or maybe the jump is patched incorrectly <dsmith>Maybe something like not multiplting by the size of a pool item? <dsmith>Any nice budget friendly risc-v boards? Like a beaglebone or rpi type of board? <rlb>There's also the pine-something (no idea how it fares), and just saw the announcement of a motherboard for the framework, but that's ~200 I think... <ekaitz>also if you don't want to run an OS the rpi pico 2 is a riscv machine i think <ekaitz>or has some subprocessor or something <dsmith>Thinking about eventually moving the bot to a new home. Currently on a beaglebone. Something risc-v would be cool. <ekaitz>the visionfive2 has served me well during the guix bootstrapping work for riscv <rlb>(ahh, it was the star64 that I saw mentioned on the pine front...) <rlb>yeah, there's an 8g version too maybe? <rlb>(No real experience with pine.) <dsmith>I don't think that runs Linux. (Yet?) <ekaitz>dsmith: exactly was some kind of pointer magic I did wrong! <ekaitz>i need to fix a couple of small details but guile runs with the JIT active for RISC-V <ekaitz>dsmith: i think we can run guix in the visionfive2 <lechner->mwette / Hi, do callbacks work with Nyacc's FFI Helper? <dsmith>ekaitz, I haven't gone down the guix rabbit hole (yet?) Been pretty much stuck to Debian since 1.0 <ekaitz>i can be your shaman if you want <dsmith>I'd prefer to hang on to what little shreads remain <ekaitz>dsmith: you can still `apt install guix` <ekaitz>so i have some last issue to fix: get_callr_temp was added to lightening after i did this support and it's failing <ekaitz>it uses LD register in Aarch but I don't know what to use in riscv <ekaitz>i tried with RA register, but it's failing the associated test <ekaitz>wingo: i just need to fix that thing and it should work <ekaitz>but i don't know how to fix at the moment <dpk>rlb: one thing i’m concerned about performance-wise with string-set! in a UTF-8 implementation like yours is the R6RS custom ports API <dpk>custom input ports more or less depend on O(1) string-set! to be performant <dpk>for R7RS Large i’m proposing a do-over where they use u32vectors instead, acknowledging that existing R6RS code using the R6RS API might just be very slow <dpk>does Guile have some kind of native custom textual port functionality that has a better API? <rlb>In general, of course, with utf-8 you likely need to switch to "string builder" or "join fragments" or... style approaches. <rlb>or other bulk "all in one" transformations/filters/etc. <dpk>right, for building up a string from chunks that’s a good idea anyway to avoid quadratic re-allocations <rlb>I did a lot of that sort of thing in the proposed changes, but as you say, doesn't help if your chosen primitive is string-set! <rlb>can't really do that anymore <dpk>that uses a string as a buffer where the consumer of this API is required required to write n characters into n consecutive positions in the string <rlb>right, some apis aren't really compatible with utf-8. <dpk>(only one ‘required) <dpk>(also a closing quotation mark, sigh) <dpk>possibly the solution here is to special-case the creation of the string that’s passed in so it has 4 times as many bytes ready in its buffer as the count argument, but that might complicate the implementation generally … <dpk>or you just accept R6RS custom ports are going to be slow, but hence my question: does Guile have some other way to create a custom textual input port that doesn’t already depend on this particular access pattern being fast? <dpk>if the R6RS way is slow, i at least want an implementation-specific way that’s fast <rlb>I may not be a likely candidate to answer that -- not sure I've done much with custom ports yet. <dpk>(i = programmers constructing custom textual I/O ports in general)