IRC channel logs


back to list of logs

<chrislck>(ping wingo). wish to ask advice. we know guile is great and all, but can be too powerful. an idea we have is to script gnucash with a limited DSL but not allow access to the full GnuCash API. e.g. - note the lack of (use-modules (gnucash))
<chrislck>it would be run from $gnucash --run-script=script.scm and allow basic scripting, but with a severely restricted set of save commands.
<chrislck>it would be run from $gnucash --run-script=script.scm and allow basic scripting, but with a severely restricted set of safe commands.
<chrislck>i.e. this would be an upgrade from --run-script=reports.json
<chrislck>the question is how to structure the loader -- would there be a wrapper with macros defining get-report and set-option! etc?
***catonano_ is now known as catonano
<chrislck>(this could be a very gentle introduction to scheme <g>)
<reepca>when a signal handler registered via sigaction is ran, is the signal that triggered it blocked during its execution? Can the handler be re-entered while it's still running? And does it establish a continuation barrier? I'd expect so, since the "safe points" are presumably being ran C-side.
***rekado_ is now known as rekado
<rekado>chrislck: you can set the current module to be one that already includes all the modules you want to provide
<rekado>See and
<rekado>load-workflow* loads some user-provided code in a fresh module where a bunch of modules have been pre-loaded
<rekado>load* creates that environment and evaluates the user code inside of save-module-excursion
<rekado>chrislck: you could use the same mechanism for GnuCash reports
<civodul>wingo: should we aim for a 3.0.3 release soonish?
<wingo>need to merge in the armv7 fixes
<civodul>oh right
<wingo>and i was hoping to get in a compiler optimization that would improve "match" statements, but it has been difficult to find time to think clearly :P
<civodul>heh :-)
<catonano>civodul: I sent a tiny patch with a mention of Guile Hall in the manual. I'd love if it could be in 3.0.3 🙏️
<dsmith-work>Morning Greetings, Guilers
<civodul>catonano: sure, i'll take a look
<civodul>i have that discussion highlighted in my inbox :-)
<catonano>civodul: thanks 😊️
<lloda>the definition of SCM_UNPACK in scm.h doesn't compile under c++20 in gcc 10
<lloda>it looks super crufty to me
<lloda>how about we just change that to something line [inline scm_t_bits SCM_UNPACK(SCM x) { return (scm_t_bits) x; }]
<lloda>have to track that comment about the clang warning tho
<lloda>d9eafa374c was a c&p job so it's a pain to track
<lloda>yeah I have no clue what volatile is doing there
<lloda>also is this SCM_DEBUG_TYPING_STRICTNESS business necessary at all?
<civodul>lloda: it's been useful a few times in the past
<civodul>it was nice to have CI build with SCM_DEBUG_TYPING_STRICTNESS=2
<lloda>why isn't that the default instead of =1
<lloda>performance concern seems off
<lloda>i'd expect the compiler to fold everything
<civodul>well, "historical baggage"
<civodul>wingo: thoughts?
<wingo>no idea!
<wingo>for c++ you really just want reinterpret_cast<> :P
<lloda>replacing the macros with inline fun doesn't work I get 'initializer element isn't constant' down the line in snarf.h
<wingo>yeah :/ if we want to keep c++ compat, probably we will need some c++ ifdefs
<wingo>lloda: regarding "why not strictness 2 by default", istr some platforms won't pass small structs by value in registers ever
<wingo>but it's terrible.
<dsmith-work>IIRC, the strict typing stuff gave the compiler more opportunity to discover errors, at the expense of slower code.
<lloda>the code shouldn't be slower just because of a type check that is done by the compiler :-(
<dsmith-work>I think it was more like certain operations were syntax errors when "strict" but not when "normal".
<dsmith-work>Like taking the address of a bitfield or something.
<lloda>fwiw just compiling with -DSCM_DEBUG_TYPING_STRICTNESS=2 fixes my immediate need. Not a real solution tho.
<lloda>that was 16 years ago and the claim is indirect
<lloda>using -DSCM_DEBUG_TYPING_STRICTNESS=2 made gcc flag all my (I guess broken) uses of SCM_UNSPECIFIED==...
<dsmith-work>Yeah, you are not supposed to compare SCM's directly.
<lloda>also need to use UNPACK/PACK to cast to/from void* now
<chrislck>rekado: thanks looks like it's possible -- using guile as a DSL for configs rather than to access the full API. just need to find a way to load appropriate modules before loading script.
<tohoyn>If I pass an expression (syntax abc) to a macro is the value to be passed a syntax object or expression (syntax abc)?
<reepca>can sigaction handlers be re-entered if the signal they handle is received while they're running?
<civodul>don't tell me about signals
<civodul>reepca: are you talking about "real" handlers at the C level, or Scheme handlers?
<reepca>scheme handlers
<civodul>ok, they run from "asyncs"
<civodul>so not directly from the "real" handler
<civodul>so Guile's signal thread receives the signal
<civodul>it queues an async that invokes the handler
<civodul>"eventually" that async runs and actually invokes the handler
<civodul>it's racy
<reepca>so I'd need to use call-with-blocked-asyncs inside the handler if I wanted it to not be re-entered
<civodul>i think so
<civodul>there are example of that in the Shepherd
<civodul>(and signalfd coming up \o/)
<reepca>getting nonblocking child-reaping to work in fibers is proving a bit tricky
<reepca>simply because as soon as a child is reaped, the process id ceases to have any real meaning
***roptat_ is now known as roptat