Hi,
I am currently digging back and forth regarding implementation of our
Smobs (Scheme objects) and garbage collection and STL, and I think I am
converging on the realisation that we'll have to end up duplicating
those parts of STL that we are using.
One reason is that we want to get rid of fi
Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
> I am currently digging back and forth regarding implementation of our
> Smobs (Scheme objects) and garbage collection and STL, and I think I am
> converging on the realisation that we'll have to end up duplicating
> those parts of ST
Jonas Hahnfeld writes:
> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>> I am currently digging back and forth regarding implementation of our
>> Smobs (Scheme objects) and garbage collection and STL, and I think I am
>> converging on the realisation that we'll have to end up d
> On 5 May 2020, at 17:09, David Kastrup wrote:
>
> One reason is that we want to get rid of finalisers particularly in
> connection with the Boehm GC. Finalisers are called when garbage is
> collected, the collection of garbage is typically indicative of the
> expected lifetime of our objects
Hans Åberg writes:
>> On 5 May 2020, at 17:09, David Kastrup wrote:
>>
>> One reason is that we want to get rid of finalisers particularly in
>> connection with the Boehm GC. Finalisers are called when garbage is
>> collected, the collection of garbage is typically indicative of the
>> expecte
On May 5, 2020, at 11:09, David Kastrup wrote:
> I'd like to come up with an allocator/container programming model
> comparatively similar to the STL one so that one could mostly steal the
> implementations and "just" add the required Scheme awareness while
> removing of destruction/deallocation t
> On 5 May 2020, at 18:57, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 5 May 2020, at 17:09, David Kastrup wrote:
>>>
>>> One reason is that we want to get rid of finalisers particularly in
>>> connection with the Boehm GC. Finalisers are called when garbage is
>>> collected, the
Dan Eble writes:
> On May 5, 2020, at 11:09, David Kastrup wrote:
>> I'd like to come up with an allocator/container programming model
>> comparatively similar to the STL one so that one could mostly steal the
>> implementations and "just" add the required Scheme awareness while
>> removing of d
On May 5, 2020, at 13:37, David Kastrup wrote:
>
> What I have ready-to-use is something that stores like an SCM value but
> behaves like a Smob pointer with regard to -> and * usage.
Oh. I believe I have some of that too. Excerpt:
// specialization for pointers
template
class ly_scm_t
{
pri
Dan Eble writes:
> On May 5, 2020, at 13:37, David Kastrup wrote:
>>
>> What I have ready-to-use is something that stores like an SCM value but
>> behaves like a Smob pointer with regard to -> and * usage.
>
> Oh. I believe I have some of that too. Excerpt:
>
> // specialization for pointers
David Kastrup writes:
> Dan Eble writes:
>
>> On May 5, 2020, at 13:37, David Kastrup wrote:
>>>
>>> What I have ready-to-use is something that stores like an SCM value but
>>> behaves like a Smob pointer with regard to -> and * usage.
>>
>> Oh. I believe I have some of that too. Excerpt:
>>
On May 5, 2020, at 17:48, David Kastrup wrote:
>
> One thing here is that being under control of a wrapper, one can use
> unchecked unsmobs.
This is a good idea. I considered this briefly, but I wanted to focus first on
making it natural to deal robustly with potentially improper or heterogene
On May 5, 2020, at 18:03, David Kastrup wrote:
>
> If everything can be represented/mapped in similar manner, the Scheme
> garbage collector does not need any interaction with user-written code
> for doing its job.
I would not like to see the STL go, but if the getting rid of all the explicit
G
On 5/5/20, 4:04 PM, "lilypond-devel on behalf of David Kastrup"
wrote:
David Kastrup writes:
If everything can be represented/mapped in similar manner, the Scheme
garbage collector does not need any interaction with user-written code
for doing its job.
And I really think that's where we
On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld wrote:
>
> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
> > I am currently digging back and forth regarding implementation of our
> > Smobs (Scheme objects) and garbage collection and STL, and I think I am
> > converging on the reali
> On 6 May 2020, at 08:21, Han-Wen Nienhuys wrote:
>
> Regarding GC, once we leave behind GUILE 1.x, we could adorn all SCM
> containing structures with a operator new/operator delete, which calls
> scm_gc_alloc()/scm_gc_free(). That would get rid of marking functions.
> For vectors, we could i
Han-Wen Nienhuys writes:
> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld wrote:
>>
>> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>> > I am currently digging back and forth regarding implementation of our
>> > Smobs (Scheme objects) and garbage collection and STL, and I think
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld wrote:
>>>
>>> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>>> > I am currently digging back and forth regarding implementation of our
>>> > Smobs (Scheme objects) and garbage
On Wed, May 6, 2020 at 11:42 AM David Kastrup wrote:
> > Or, we could globally map new/delete to GC_malloc and GC_free.
>
> That would vastly increase the amount of GC-scanned memory, and GC
> scanning is already slow.
I'd first measure this carefully before spending time on a complex
rewrite. Th
Am Donnerstag, den 07.05.2020, 07:57 +0200 schrieb Han-Wen Nienhuys:
> In my mind, supporting GUILE 2.x means supporting byte compilation
> because we'd otherwise regress startup speed by a second or so.
>
> That is currently blocked on your proposed alternative to
> https://codereview.appspot.com
Jonas Hahnfeld writes:
> Am Donnerstag, den 07.05.2020, 07:57 +0200 schrieb Han-Wen Nienhuys:
>> In my mind, supporting GUILE 2.x means supporting byte compilation
>> because we'd otherwise regress startup speed by a second or so.
>>
>> That is currently blocked on your proposed alternative to
>
David Kastrup writes:
> David Kastrup writes:
>
>> Han-Wen Nienhuys writes:
>>
>>> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld wrote:
Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
> I am currently digging back and forth regarding implementation of our
>
22 matches
Mail list logo
