IRC channel logs

***karlosz_ is now known as karlosz

<tohoyn>sneek, botsnack

***apteryx is now known as Guest80643

***apteryx_ is now known as apteryx

<leoprikler>I think, I found a bug in Guile.

<leoprikler>It appears `false-if-exception' does not catch exceptions when used inside `with-exception-handler' (but it does inside `with-throw-handler').

<RhodiumToad>I'm guessing this is in guile 2.2 ?

<leoprikler>3.0.2

<leoprikler>Try the following:

<leoprikler>(with-exception-handler (lambda _ (display (false-if-exception (error "moo")))) (lambda () (error "meow")))

<leoprikler>(with-throw-handler #t (lambda () (error "meow")) (lambda _ (display (false-if-exception (error "moo")))))

<leoprikler>The first will backtrace on "moo", the second on "meow"

<leoprikler>(you can skip the display if you want)

<lampilelo>what's up with this "#define FUNC_NAME s_function_name" it's not documented in the info manual but is required for some macros that are documented there (like SCM_ASSERT_TYPE)

<dsmith>It's so some error messages can show the current C function

<lampilelo>ah, no' its not for SCM_ASSERT_TYPE, it's required for internal macros

<lampilelo>so what would I give SCM_ASSERT_TYPE as a subr argument in normal code not internal to guile? just "function-name"?

<lampilelo>or should I define FUNC_NAME?

<dsmith>You could put a literal string.

<dsmith>#define SCM_ASSERT_TYPE(_cond, _arg, _pos, _subr, _msg)

<dsmith>For _subr

<dsmith>Since a SCM can be any type, those ASSERT's are usually used on entry to a C function to ensure that the args are what the function can handle.

<dsmith>Usually called right at the entry to the function.

<lampilelo>yes, that part is clear

<dsmith>the _pos is the argument number.

<lampilelo>what i'm really asking is what is this s_function_name thing? i see now that snarfing my SCM_DEFINE created an entry that uses it

<dsmith>Oh. That's a static string with the function name.

<lampilelo>i'm interested because in reality I tried to use SCM_VALIDATE_HOOK macro and it requires FUNC_NAME

<lampilelo>but it's not documented so i'm assuming it's considered an internal macro and isn't designed to be used outside guile

<lampilelo>ah, ok, i found where it's defined, so it just assigns scheme function name to it

<leoprikler>I think the convention is to use {\n#define FUNC_NAME ...\n...\n#undef FUNC_NAME\n}

<lampilelo>i wondered if it's something more than that

<dsmith>Well, if you look at just about any source file in libguile, you can see that FUNC_NAME is #define'ed and #undef'ined for every C func.

<dsmith>Right

<lampilelo>leoprikler: sure, it's a convention in a guile source tree but it's not documented so, like i said, i'm assuming it isn't meant to be used outside

<leoprikler>perhaps not the nicest interface for extensions, but probably not one that's going to collide with other stuff

<leoprikler>well, neither is the SCM_VALIDATE_HOOK macro, so...

<lampilelo>and that's why i started looking for an alternate way, but SCM_ASSERT_TYPE requires a _subr

<lampilelo>so i wanted to know how it all falls together

<dsmith>While useful for external C modules, I don't think those assert macros (and snarfing macros) where written with *external* modules in mind. More to just make libguile code eaiser to manage.

<leoprikler>Snarfing is partially documented for external modules.

<lampilelo>ok, so since you guys know guile's internals maybe you can tell me if there's a more idiomatic way to define a hook than that: https://paste.debian.net/plain/1147305

<dsmith-work>Hey Hi Howdy, Guilers

<rekado>I’m running a debug build of Guile Emacs in gdb to analyze some segfaults and other bugs, but I don’t understand exactly what I’m looking at.

<rekado>this is the gdb session with backtrace: https://paste.centos.org/view/raw/c7c0d475

<dsmith-work>rekado: I'm guessing #15 is where the problem starts:

<dsmith-work>handler=<error reading variable: ERROR: Cannot access memory at address 0x2>0x7ffff31614c0

<rekado>it already happens in #18

<dsmith-work>address 0x2 ?

<rekado>Cannot access memory at address 0xfffffffffffffe00

<dsmith-work>AH yes

<dsmith-work>Whis is what, -2048?

<dsmith-work>More like -512

<dsmith-work>yep

<rekado>this looks like it happens really early, right after using scm_with_guile

<rekado>I wonder where this comes from

<dsmith-work>So #21 is in the GC. Maybe that's looking somewhere it shouldn't?

<dsmith-work>It's probing the stack?

<dsmith-work>Looking for stack boundaries.

<dsmith-work>Is savannah down? I'm getting a 502 on a pull

<rekado>hmm, I’ll rebuild with libgc 7 instead of 8.

<lampilelo>it seems like it segfaults while catching an error inside a finalizer

<lampilelo>funny

<dsmith-work>Unfortuantely, that happens a lot. A segfault within an error handler.

<dsmith-work>main code: Ooo look! I got an error trying to read this address!

<dsmith-work>error handler: Ok, let's print out what's at that address..

<dsmith-work><segfault>

<dsmith-work>Or something along those lines

<mwette>Hey guys, 0xfffffffffffffe00 looks like it could be -1 immediate value. How many bits does Guile use for marking values?

<mwette>Look at the section "Faster Integers" in the Guile Ref Manual.

<mwette>Ah, 3 bits. That's not -1 methinks.

<mwette>Never mind.

<lloda>I think I'm going to remove the bug list & new bug tabs in the guile-cairo website and just direct people to guile-user. This thing is pretty stable and we don't get many bugs. All the bugs in the old tracker are fixed. Wdyt wingo?

<RhodiumToad>mwette: effectively only 2 bits for integers.

<mwette>RhodiumToad: thanks.

<wingo>lloda: :thumbs_up:

<catonano>can I build just the Guile manual and not Guile itself ?

<wingo>catonano: after configuring i would guess "make -C doc"

<catonano>wingo: thanks. Configuring right now

<tohoyn>sneek, botsnack

<sneek>:)

<lampilelo>hmm, is string-titlecase supposed to turn "i'm" into "I'M"?

<lampilelo>string-locale-titlecase handles it correctly and turns it to "I'm"

<lloda>curious

<lloda>what is your locale?

<lampilelo>it doesn't seem to matter but i have LANG set to en_US.UTF-8, but the LC_* pl_PL

<lampilelo>but when i overwrite it and run it again it doesn't change

<lampilelo>on srfi.schemers.org they specify "if c is preceded by a cased character, it is downcased; otherwise it is titlecased", so i guess it's right

<lampilelo>' isn't cased

<lampilelo>afaiu

*dsmith-work acivates his portable snarkulator

<dsmith-work>You mean "," is not lowercase "'" ?

<lampilelo>:D

<lampilelo>of course not! "," is a lowercase for "`"

<dsmith-work>Ahhh!

<rekado>guile-emacs fails with the same kind of error when linked with libgc-7.6.12

***jao is now known as Guest77108

<dsmith-work>sneek: seen bipt ?

<sneek>I think I remember bipt in (here?) 9 months ago, saying: i saw that your guile-emacs package made it into a guix release :).

<ZombieChicken>anyone know if Guix is working on the Pinebook Pro?