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
>
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
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
>
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.
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
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
> 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
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
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
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
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
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:
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
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
{
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
> 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,
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
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
>>
> 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
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
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
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
22 matches
Mail list logo
