Re: [RFC,PATCH] Do not GC_INIT the Boehm GC if already initialized

[Hans Åberg]

> On 20 Feb 2023, at 11:06, Ludovic Courtès  wrote:
> 
>> According to the Boehm GC documentation, this 'conditional
>> initialisation' is unnecessary:
>> 
>> /* Portable clients should call this at the program start-up.  More   */
>> /* over, some platforms require this call to be done strictly from the*/
>> /* primordial thread.  **Multiple invocations are harmless.** */
>> #define GC_INIT() [...]
>> 
>> (emphasis added).
> 
> The “Multiple invocations” bit isn’t in libgc 8.0.4.  Which version are
> you looking at?

It is in MacPorts boehmgc @8.2.2 (devel), which Guile lists as a dependency.

Re: Unicode procedure names

[Hans Åberg]

> On 16 Jul 2019, at 14:41, Ricardo Wurmus  wrote:
> 
> Arne Babenhauserheide  writes:
> 
 Now, I don't know if this is something you think would be nice to have
 baked into Guile, but I really liked the idea, and thought to share it
 in the case you would, too (and have't thought of it yet). :)
>>> 
>>> I think this could be implemented as a library of aliase and thus
>>> wouldn’t need to have any privileged access to Guile itself.
>> 
>> All you need to do is
>> 
>> (define ≥ >=)
> 
> Yes, that’s what I had in mind.  A whole bunch of these aliases could be
> distributed as a tiny library.

I have used such symbols for math for some time now, and I think it helps 
readability.

The quickest input method that I have found, both to create and use, is text 
substitutions, like Emacs abbrevs, though I use a MacOS service.

Re: C calling Scheme and garbage collection

[Hans Åberg]

> On 27 Jun 2019, at 21:52, Greg Troxel  wrote:
> 
> I have been down this path before, with guile and with lua.  Basically,
> if C (or non-scheme) has a pointer to a scheme object, then you need to
> hold a logical reference for it and protect the scheme object, and when
> the C pointer is dropped decrease the refcnt.
> 
> I am unclear on the details of how you have a ref that gc is made aware
> of.

If one allocates with the underlying Boehm GC, is the SCM object kept alive?

Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3

[Hans Åberg]

> On 8 Jun 2019, at 11:08, Chris Vine  wrote:
> 
> On Sat, 08 Jun 2019 10:07:45 +0200
> Arne Babenhauserheide  wrote:
> [snip]
>> Wow, I didn’t know that you could do that.
>> 
>> However: "The details of that allocation are implementation-defined, and
>> it's undefined behavior to read from the member of the union that wasn't
>> most recently written." https://en.cppreference.com/w/cpp/language/union
>> 
>> Can you guarantee that this works?
> 
> This is C and not C++ and the provision to which you refer does not
> apply.
> 
> Reading from a member of a union other than the one last written to is
> implementation defined in C89/90, and defined in C99 (with Technical
> Corrigendum 3) and above, although it might include a trap
> representation (but wouldn't on any platform supported by guile).  You
> might want to see in particular footnote 95 of C11 (which isn't
> normative but is intended to explain the provisions of §6.2.6.1 which
> are).
> 
> gcc and clang have always supported type punning through unions.

FYI, the site mentioned above also covers C (there is a link the bottom of the 
C++ page above):
  https://en.cppreference.com/w/c/language/union

Re: speedup of modifying return values

[Hans Åberg]

> On 29 Aug 2018, at 20:46, Taylan Kammer  wrote:
> 
> Stefan Israelsson Tampe  writes:
> 
>> Hi all, I'm trying to make a python clone in guile. Currently the code is 
>> slow and one of  the reasons is the following,
>> 
>> in my pythoon
>> 
>> return 1,2
>> 
>> returns a (values 1 2) in order to get python and scheme to interoperate. 
>> but for python if you use
>> 
>> x = 1,2
>> 
>> then x is the tupple '(1 2) and in guile it is 1. So therefore we wrap the 
>> result for
>> 
>> x=f(10)
>> 
>> as
>> (set! x (call-with-values (lambda () (f x)) (case-lambda ((x) x) (x x
>> 
>> This can be compiled to efficient bytecode but is not done so in guile. In 
>> stead a closure is created at each assignment site and creating ineficient 
>> code.
>> 
>> Any ideas how to improve this (I don't want "return a,b" to mean (list a b) 
>> which is a quick solution
>> if we want to just stay in python and not interoperate with scheme at all on 
>> this level.
> 
> Sounds like a fun project. :-)
> 
> Idea:
> 
> Make Python tuples a new data type, instead of multi-values.
> 
> The fact that they can be stored in a single storage location in Python
> means that they are actually a data type, only special-handled for
> automatic destructuring in some places...

Indeed, the problem is that in Scheme, (list f x₀ …), using normal infix tuple 
notation, creates the deferred function object f(x₀, …), and I found it hard to 
write a normal function call language on top of that.

Re: multi-lingual guile: language strictness

[Hans Åberg]

> On 14 Jul 2018, at 20:45, Matt Wette  wrote:
> 
> On 07/14/2018 09:22 AM, Hans Åberg wrote:
>>> On 14 Jul 2018, at 15:53, William ML Leslie 
>>>  wrote:
>>> 
>>> On 14 July 2018 at 12:57, Brett Gilio 
>>> 
>>>  wrote:
>>> 
>>>> Is this possibility for making Guile multi-lingual a promised feature,
>>>> or more of a wishlist type thing? I'll have to think about some ways
>>>> that might be good to approach this, because the limiting
>>>> volunteer-community is definitely going to be an issue.
>>>> 
>>> It's already a thing.
>>> 
>>> https://www.gnu.org/software/guile/manual/html_node/Other-Languages.html
>> Is it possible to call them at the same time, via the C interface?
>> 
> I would think so.  In general all languages see the same name space.
> 
> scheme@(guile-user)> ,L ecmascript
> Happy hacking with ECMAScript!  To switch back, type `,L scheme'.
> ecmascript@(guile-user)> function foo(x) { return x + 1; };
> ecmascript@(guile-user)> foo(1);
> $1 = 2
> ecmascript@(guile-user)> ,L scheme
> Happy hacking with Scheme!  To switch back, type `,L ecmascript'.
> scheme@(guile-user)> (foo 1)
> $2 = 2

Yes, that is what I asked for, to be able to create objects in one language and 
interact with the same objects in another.

Re: multi-lingual guile: language strictness

[Hans Åberg]

> On 14 Jul 2018, at 15:53, William ML Leslie  
> wrote:
> 
> On 14 July 2018 at 12:57, Brett Gilio  wrote:
>> Is this possibility for making Guile multi-lingual a promised feature,
>> or more of a wishlist type thing? I'll have to think about some ways
>> that might be good to approach this, because the limiting
>> volunteer-community is definitely going to be an issue.
>> 
> 
> It's already a thing.
> 
> https://www.gnu.org/software/guile/manual/html_node/Other-Languages.html

Is it possible to call them at the same time, via the C interface?

Re: c99 support

[Hans Åberg]

> On 29 Jun 2018, at 17:35, Chris Vine  wrote:
> 
> On Fri, 29 Jun 2018 12:34:07 +0200
> Hans Åberg  wrote:
>>> If, say, uint8_t is available in stdint.h for C, it
>>> will be available for C++.  §21.4.1/2 of C++17 makes this even more
>>> explicit: "The [cstdint] header defines all types and macros the
>>> same as the C standard library header ".
>> 
>> Which C version? In g++7, __STDC_VERSION__ is not defined, only __STDC__.
> 
> In C++17, references to "C" are to ISO/IEC 9899:2011.  References to the
> C standard library are to "the library described in Clause 7 of ISO/IEC
> 9899:2011".  In C++11 and C++14, the references are to ISO/IEC
> 9899:1999.  

Good.

> By default (if you don't use the -std=c++xx flag) g++-7
> compiles according to C++14.

I am using C++17. And gcc7 defaults to C11, so there is an incompatibility with 
the default g++ C version it seems.

Re: c99 support

[Hans Åberg]

> On 29 Jun 2018, at 12:10, Chris Vine  wrote:
> 
>> For C++, these are only optional, cf. [1], as they require no padding. So an 
>> alternative is to typedef the obligatory int_fast<2^k>_t types, perhaps 
>> leaving the API unchanged.
>> 
>> 1. https://en.cppreference.com/w/cpp/types/integer
> 
> The fixed size integer types are optional in C99/11 also, depending on
> whether the platform provides a fixed size integer of the type in
> question without padding and (for negative integers) a two's complement
> representation.  

Yes, I saw that, too. It is important to ensure two's complement, too, which 
the other types do not.

> If, say, uint8_t is available in stdint.h for C, it
> will be available for C++.  §21.4.1/2 of C++17 makes this even more
> explicit: "The [cstdint] header defines all types and macros the
> same as the C standard library header ".

Which C version? In g++7, __STDC_VERSION__ is not defined, only __STDC__.

> I imagine guile will not run on any platform that does not support 8
> and 32 bit fixed size integers.

I would think all CPUs support those types nowadays, so it is rather 
theoretical.

Re: c99 support

[Hans Åberg]

> On 29 Jun 2018, at 09:39, Andy Wingo  wrote:
> 
> It would seem that the first four
> features of C99 are OK for all platforms that we target, with the
> following caveats:
> 
> * We should avoid using C++ keywords (e.g. throw) in Guile API files.
> 
> * We might want to avoid mixed decls and statements in inline functions
>   in Guile API files.
> 
> We should probably avoid stdbool.h and compound literals, for C++
> reasons.

You might make a separate C++ header: It turned out too complicated for Bison 
to maintain the compile as C++ generated C parser.

> In Guile 3.0 (master branch), the types "scm_t_uint8" and so on are now
> deprecated.  My recommendation is that all users switch to use
> e.g. "uint8_t", "ptrdiff_t", etc from  instead of the
> scm_t_uint8, etc definitions that they are now using.  The definitions
> are compatible on all systems, AFAIU, and on GNU, scm_t_uint8 has long
> been a simple typedef for uint8_t.

For C++, these are only optional, cf. [1], as they require no padding. So an 
alternative is to typedef the obligatory int_fast<2^k>_t types, perhaps leaving 
the API unchanged.

1. https://en.cppreference.com/w/cpp/types/integer

Re: Rename GNU fdisk to GUILE diskutils

[Hans Åberg]

> On 9 Dec 2017, at 14:46, Christian Brunello  wrote:
> 
> I would like to rename the GNU fdisk
> package. ... we consider
> using the name "Guile Diskutils".

FYI, there is a MacOS program differing only in that it is not a plural:
  diskutil — modify, verify and repair local disks

Re: Mark procedures and LilyPond

[Hans Åberg]

> On 6 Nov 2015, at 13:32, Mark H Weaver  wrote:

>> We should fix Guile so to "null out" the SMOB typecode when the SMOB
>> finalizer is called.  If our mark procedure sees a SMOB that has already
>> been finalized, it just returns.
> 
> Unfortunately, I doubt this will be sufficient for LilyPond.  The small
> example case in , which is apparently
> representative of how things are typically done in LilyPond, has
> structures like this:
> 
>   ____
>  Objects in  |  |  |  |
>  GC-managed  |  SMOB 1  |  |  SMOB 2  |
> heap |__|  |__|
> |   ^ |   ^
> .|...|.|...|..
>   __v___|___  _ __v___|___
>  Objects in  |  ||   STL   |   |  |
>  normal heap |C++ object|--->|container|-->|C++ object|
>  (not scanned|__||_|   |__|
> by GC)
> 
> 
> The SMOB finalizers free the associated C++ objects below them.  Now,
> suppose that none of the objects above are reachable, so both SMOBs are
> queued for finalization.  Now suppose that SMOB 2 is finalized first,
> thus freeing the C++ object below it.  Suppose further that we null out
> the SMOB 2 typecode.
> 
> Now another GC occurs and the marker is called on SMOB 1.  It's typecode
> has not yet been nulled, so the user-specified mark procedure is called.
> The mark procedure for SMOB 1 iterates over the STL container, and for
> each C++ object within, marks the corresponding SMOB via the upward
> pointer, in this case SMOB 2.  Although SMOB 2's typecode has been
> zeroed out, the discovery of the fact is too late, because the (freed)
> C++ object below it has been referenced.
> 
> As far as I can tell, this way of doing things depends on the old 1.8 GC
> finalization semantics, where all of the finalizers are called before
> the mutator resumes execution.

Is Guile 2 doing its own finalization, not synced withe the Boehm GC?