IRC channel logs
2024-10-12.log
back to list of logs
<cpli>mwette: why don't you roll the `decl-filter` and renamer into one? i.e. if you return #f as the name, don't include the def <cpli>as it stands decl-filter currently doesn't get e.g. enum variants, so i can't remove the WGPUBackendType_Force32 variants that ensure that all webgpu variants are at least a u32.. <cpli>lastly, decl-filter gets different type information from the renamer.. where the renamer just gets: `type`, decl-filter enjoys knowing if something is a struct, enum, or union.. <cpli>are struct fields still immutable? <mwette>cpli: approach is to make types structs immutable <ArneBab>sneek: later tell dthompson: sadly I don’t know enough about lightening to review patches to it. <ekaitz_>ArneBab: the patch we were talking about is just 4 or 5 ifdefs <ekaitz_>more than knowing how lightening works it needs checking if it works and approving <ekaitz_>mine yeah, that requires some knowledge <ArneBab>sneek: later tell mwette: since I gote no vetos, I now merged your patch allowing to silence diagnostics into origin/main. <mwette>cpli: for structs you could try Guile's object properties; for decl-filter, I believe enum (and structs) will be fed to decl-filter as a form like '(enum . "foo") <sneek>Welcome back mwette, you have 1 message! <sneek>mwette, ArneBab says: since I gote no vetos, I now merged your patch allowing to silence diagnostics into origin/main. <mwette>ArneBab: great, and thanks. I hope you are satisfied with this implementation. <ArneBab>mwette: it doesn’t directly address my needs (I still use my GUILE_QUIET patch), but it resolves a very long standing problem, so once this is released I can remove lots of hacks from other code. <mwette>ArneBab: got it. I'm glad to be of some help. <ArneBab>mwette: I’m pretty sure that lots of people are happy about your change. <graywolf>Hello :) If I have a list of thunks, is there a way to apply them in for-each? Currently I do (for-each (cut <>) lst). I tried apply, that that requires at least two arguments. The current way works, but I am curious if there is a more "built-in" way to do this. This I miss some apply-thunk of something? <cpli>mwette: decl-filter does not receive enum *variants* i.e. a library doing: `enum Color { red, green, blue, Color_ENSURE_32BIT = 0x7FFFFFFF };` now means i have a <enum>_ENSURE_32BIT symbol for every enum in a library :/ <lampilelo>graywolf: i guess just (lambda (f) (f)), there's no funcall in scheme <graywolf>Yeah funcall was what I was looking for (I did not expect apply to require at least one argument), so wanted to make sure I did not miss it. Thanks <mwette>cpli: I have no desire to add tweaks for editing C code like that. Maybe you can add fixup code into your .ffi to fix the enum defs: (set! enum-Color (code to edit enum-Color). <mwette>I think so, it may take a little work, but extract the syms and values from the existing cenum and generate a new one with `(cenum <fixed-entries>) <cpli>but the top-level only gets run after the .scm file is written <mwette>Assuming your machine is using 32bit ints: that would be the default size for enums <cpli>mwette, yeah.. i have no clue why the webgpu people add it everywhere.. <mwette>to protect against using `gcc --short-enums' I guess <mwette>cdata's `cenum' procedure takes an optional packed? arg that implements that for enums defined with __packed__ attribute <cow_2001>there's read-string and there's get-string-all <cpli>doesn't `read-string` take a bounding `n`? <cow_2001>guile -q; read-string => unbound-variable <cpli>it's part of (srfi :152) <mwette>I need to fix some code generation w/ the change to cenum. You may also need to fix the enum wrappers and unwrappers. <cow_2001>it's in (ice-9 documentation), which is strange. <mwette>ACTION pushed fix to nyacc dev-2.01 branch <cpli>mwette, doesn't (cenum '((A 0) (B 1) (Z 4294967295))) still end up in the .scm? or do we only care about the .go file? (btw, where is that written to?) <cpli>oh! i thought that additional top-level code in the `ffi` file would be executed during generation, not simply added onto the .scm file! this makes sense now <mwette>you might even be able to write a macro that loops through ffi-webgpu-types, filtering w/ (and (pair? ent) (eq? 'enum (car pair))) and generating the update form <ekaitz>mwette: something weird happened with your latest commits <mwette>I wonder if it's a buffering issue with another port using stderr (was error-port warning-port; now error-port, warning-port and info-port). <mwette>ekaitz: you are not using `-I' command flag, I assume. <ekaitz>i see all your commit message in one line <mwette>Oh, it's the commit message? Not with guile itself then. <mwette>I see why. I submitted a format-patch. That rolls all the commit messages into the subject line. <mwette>I think it may have worked if I made second line blank. <ekaitz>format-patch normally works so idk <ArneBab>ekaitz: that might have been that I applied them wrongly? Sorry! <ArneBab>but I fear I cannot fix that after pushing … <ArneBab>(I only checked the diff and committer after applying the patch in magit <ArneBab>I guess *that* would get me lynched ☺ <ArneBab>Or does git already have an equivalent of the cooperative rewriting of Mercurial? (evolve extension) <ArneBab>Then I’ll note that as learning experience and write an excuse to guile-devel. <ekaitz>ArneBab: good, but don't be hard on yourself <ArneBab>I know that mistakes happen. Still I must make sure that people know when they assemble release notes. <mwette>I just performed a test: One needs to leave a blank line after the first in the commit message. That was my bad. Sorry, all. <ekaitz>just as a reminder: thank you both for your commits <ArneBab>mwette: no gripes from me: thank you for your work! 