IRC channel logs

2025-10-25.log

back to list of logs

<dpk> https://man.scheme.org/fixnums.7scm says that Guile runs generic arithmetic faster than fixnum arithmetic, and my testing bears this out
<dpk>what’s the deal with that?
<identity>dpk: fx+ is defined as something like (define (fx+ . ls) (assert (every fixnum? ls)) (apply + ls)), same with other fixnum procedures
<identity>guile can optimize out (+ 2 2) but not (fx+ 2 2)
<identity>really (define (fx+ fx1 fx2) (assert-fixnum fx1 fx2) (let ((r (+ fx1 fx2))) (or (inline-fixnum? r) (raise (make-implementation-restriction-violation))) r)), it seems the optimizer can not handle that for some reason
<dpk>none of the magic needed-bits optimization for fixnums? :-(
<kestrelwx>rgherdt: Hi! I'll take a bit to go through the spec, I was making best efforts to avoid reading it :D.
<rgherdt>kestrelwx: Nice! I'm actually not really familiar with it either, I just wrote the parser but never used the results. Are you planning to generate WebGL2 bindings for hoot?
<rgherdt>I'll take a look at the new bug you reported, thanks
<rgherdt>which files are you using as inputs?
<rgherdt>I pushed a fix.
<rgherdt>I'll try to go through the spec too and improve test coverage
<kestrelwx>Yes, I want to make bindings for the upcoming jam.
<kestrelwx>I'm using their specs from here. https://registry.khronos.org/webgl/specs/latest/
<kestrelwx>For WebGL.
<rgherdt>thx. I gave it a shot, no errors, but the resulting model might still be incomplete
<rgherdt>I noticed there are still incomplete parts in tree->model regarding constant values, will try to fix it
<apteryx>eh, the bytevector-s8-set! setter is documented as a getter: https://paste.guixotic.coop/_Geiser_Guile_REPL_guix_-600691-600841.html
<apteryx>how would I write a string at some offset in a bytevector ?
<apteryx>do I need to transform the string to utf8 codes, then write them one by one with bytevector-s8-set! in a loop?
<kestrelwx>rgherdt: For `const type num = 0;` I only get "type" now.
<rgherdt>yes, thx. I noticed that for non-attribute and non-operation members the conversion is incomplete. I'm figuring out how I should model that
<rgherdt>originally I started that parse-to-model stuff only to showcase how one could traverse the parse tree, but perhaps we can complete it. If you show the parse tree all the elements are there
<rgherdt>besides <operation> and <attribute> we need more data structures to model interface members, I'm trying to figure out from the spec and webidl.js what would make more sense
<rgherdt>I guess just a <constant> record
<kestrelwx>I thought I'd need to traverse the tree myself, but then I figured, since the model is already there what sense is there to write one again?
<apteryx>oh, bytevector-copy!
<rgherdt>kestrelwx: yes, that makes sense. It's just not complete yet, and can definitely be improved.
<rgherdt>kestrelwx: pushed a fix, now we have a <constant> type for interface/mixin members
<kestrelwx>rgherdt: Looks right to me, thank you!
<rgherdt>you're welcome. Thx for testing and reporting.
<kestrelwx>I'll close the issue for now.
<rgherdt>ok