Re: uninterned symbols as Tree-IL constants

Hi, BT Templeton skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Hi, >> >> BT Templeton skribis: >> >>> I noticed that when uninterned symbols are used as Tree-IL constants, >> >> I thought literal (constant) symbols in Elisp were interned. You seem >> to imply this isn’t always the cas

Re: uninterned symbols as Tree-IL constants

l...@gnu.org (Ludovic Courtès) writes: > Hi, > > BT Templeton skribis: > >> I noticed that when uninterned symbols are used as Tree-IL constants, > > I thought literal (constant) symbols in Elisp were interned. You seem > to imply this isn’t always the case; can you explain? Since Elisp lacks h

Re: uninterned symbols as Tree-IL constants

Hi, BT Templeton skribis: > I noticed that when uninterned symbols are used as Tree-IL constants, I thought literal (constant) symbols in Elisp were interned. You seem to imply this isn’t always the case; can you explain? Thanks, Ludo’.

Re: [bug #33996] 2.0.2: Crash related to ports and threads

Hi! Andy Wingo skribis: > Oh dear, this is a nasty one. The issue is that Guile's ports are not > threadsafe. I hadn't thought about this one... > > I am adding guile-devel to the Cc for input. Any fix to this will be > pretty big, I think. I think that the right fix here is probably what >

Re: Cross compiling guile 2.0.2 on openwrt MIPS architecture.

Hi Jiva, I’ve reproduced the error message you posted below: --8<---cut here---start->8--- i18n.c: In function 'str_upcase_l': i18n.c:874:12: error: dereferencing pointer to incomplete type i18n.c:874:12: error: dereferencing pointer to incomplete type i18n.c:

Re: Parallel Guile code called from parallel C code

Hi, pablo skribis: > The Guile doc says "Internally, a fixed-size pool of threads is used > to evaluate futures, (...) the pool contains one thread per available > CPU core, minus one, to account for the main thread." > > Then how does this work in the situation I described? Do the two > concurr

Re: Difference letrec & environment binding (again)

Hello! Hans Aberg skribis: > So letrec is transformed to something else. What might that be? I believe you’re seeing the “Fixing letrec” algorithm in action (see the paper of that name by Dybwig et al.) Thanks, Ludo’.