ast for guile-2.0.14).
> Thus I went up, patch by patch, and could identify two patches
> preventing success for `make test-baseline´:
>
> commit 96cdc755b547688c46097ba6a155aa1085ea7ac4
> Author: David Kastrup
> Date: Sun Feb 5 16:43:21 2017 +0100
>
> Issue 5056/2: Do
n't have as comprehensive tests as that and don't really demand
it. One should just be conservative. The cost of a mistake in that
regard may well be a revert or a timely followup patch.
--
David Kastrup
ter discussion on the developer list.
That's for the case of a broken staging not passing the automated test
procedures. It does not apply to a broken master.
--
David Kastrup
Dan Eble writes:
> On Oct 28, 2019, at 08:12, David Kastrup wrote:
>>
>>> I request some help to understand how I can improve my pre-commit
>>> testing procedures, and where my responsibilities begin and end.
>>
>> Responsibilities don't end.
>
would improve confidence in the font creation instructions, but the
real test is whether people complain about the look of the resulting
character.
--
David Kastrup
ipt starts with
"echo no not found -s"
as its interpreter? Note that some underlying problem might not be new:
I have frequently had to start make a second time here (I considered it
a timing problem): it may just be that previously the failure left an
empty file that allowed the nex
Dan Eble writes:
> On Nov 8, 2019, at 09:11, David Kastrup wrote:
>>
>> So how come my lilypond-invoke-editor script starts with
>>
>> "echo no not found -s"
>>
>> as its interpreter? Note that some underlying problem might not be new:
>
Thomas Morley writes:
> Am Fr., 8. Nov. 2019 um 16:34 Uhr schrieb David Kastrup :
>>
>> I got it now. I used to do
>>
>> ./configure --enable-checking
>> GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config
>>
>> but that appears to
Jonas Hahnfeld writes:
> Am Freitag, den 08.11.2019, 22:21 +0100 schrieb David Kastrup:
>> Thomas Morley writes:
>> > Am Fr., 8. Nov. 2019 um 16:34 Uhr schrieb David Kastrup :
>> > > I got it now. I used to do
>> > > ./configure --enable-checking
&g
Jonas Hahnfeld via Discussions on LilyPond development
writes:
> Am Samstag, den 09.11.2019, 12:55 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> >
>> > AFAICS configure requires a guile executable between versions
>> > 1.8.2 to1.9.0 (see conf
Jonas Hahnfeld writes:
> Am Samstag, den 09.11.2019, 13:23 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld via Discussions on LilyPond
>> development writes:
>> > Am Samstag, den 09.11.2019, 12:55 +0100 schrieb David Kastrup:
>> > > Jonas Hahnfeld writes:
uite sure that this version series will stay for many years.
With regard to GUB, 2.7 compatibility makes for a much nicer transition
period. But GUB is not likely involved in uses of that package which
seems to be mainly used in a TeXlive context. I haven't checked, but I
think that TeXlive is pretty much prepared to use Python3.
--
David Kastrup
03d70d4b37a73f19e60c2438112a5a8 is empty
> error: object file
> .git/objects/76/008183503d70d4b37a73f19e60c2438112a5a8 is empty
> fatal: loose object 76008183503d70d4b37a73f19e60c2438112a5a8 (stored
> in .git/objects/76/008183503d70d4b37a73f19e60c2438112a5a8) is corrupt
> [dev@lilydev:lilypond-git]$ fatal: The remote end hung up unexpectedly
Rather sounds like a different problem like a dead server/connection.
Try again?
--
David Kastrup
David Nalesnik writes:
> On Thu, Nov 14, 2019 at 10:21 AM Federico Bruni wrote:
>
>>
>>
>> Il giorno gio 14 nov 2019 alle 10:17, David Nalesnik
>> ha scritto:
>> > On Thu, Nov 14, 2019 at 9:34 AM David Nalesnik
>> > wrote:
>> >>
apt does not have a stable CLI interface. Use with caution in
> scripts.
>
> ca-certificates/oldstable,oldstable,now 20161130+nmu1+deb9u1 all [installed]
>
> But then I can't use git-cl:
>
> [dev@lilydev:~]$ cd $LILYPOND_GIT
> [dev@lilydev:lilypond-git]$ git-cl confi
> with !=
911788f173 Issue 5578: add a button to flip between old and new regtest images
2823ff0e87 Issue 5579: fix stem tremolo on rests crash
3903d2efc7 Issue 5577: scripts/build: Remove unused scripts
> I'd really like to see us get something out as 2.20 by the first of
> the year. What can I do to help?
>
> Thanks,
>
> Carl
>
>
--
David Kastrup
Carl Sorensen writes:
> On 11/16/19, 1:52 PM, "David Kastrup" wrote:
>
> Carl Sorensen writes:
>
> > Dear Team,
> >
> > It seems to me like we are pretty much in shape such that we should
> > release 2.20. I
David Kastrup writes:
> Carl Sorensen writes:
>
>> On 11/16/19, 1:52 PM, "David Kastrup" wrote:
>>
>> Carl Sorensen writes:
>>
>> > Dear Team,
>> >
>> > It seems to me like we are pretty much in shape s
Carl Sorensen writes:
> On 11/16/19, 2:14 PM, "David Kastrup" wrote:
>
> Carl Sorensen writes:
>
> > On 11/16/19, 1:52 PM, "David Kastrup" wrote:
> >
> > Carl Sorensen writes:
> >
> > &
other code
with generics (like overloading existing operators). The performance
for MusicXML conversion itself does not seem critical.
> I did use a lot of define-method, as it is easy this way to be type
> save.
I don't think the cost justifies the effort here. Scheme is not
intended as a "type safe" language.
--
David Kastrup
Thomas Morley writes:
> Am So., 17. Nov. 2019 um 18:13 Uhr schrieb :
>>
>> > -Oorspronkelijk bericht-----
>> > Van: David Kastrup
>> > > I did use a lot of define-method, as it is easy this way to be type
>> > > save.
>> >
>&
the 2.20 release,
>> the newest `texinfo.tex` from texinfo's git master branch should be
>> used.
>
> Sounds like a good plan if we want to have newer features from there.
I prefer cherry-picking the changes since that means that support files
(like for other languages) are not accidentally omitted.
--
David Kastrup
v/jmandereau/stable-2.20-201902 ->
> origin/dev/jmandereau/stable-2.20-201902 (unable to update local ref)
Like Johann said:
git pull -r -p
should do the trick. The problem is that John had reused a branch of
his as a directory of branches and that's a replacement Git will not do
on its own. -p (or --prune) removes non-existent branches before
pulling, so that conflict stops existing.
--
David Kastrup
David Kastrup writes:
> David Nalesnik writes:
>
>> Below is the console output. Any ideas?
>>
>> Thanks,
>> David
>>
>> [dev@lilydev:lilypond-git]$ git pull -r
>> error: cannot lock ref
>> 'refs/remotes/origin/dev/jmandereau/merge
e
properly handled this at the time the code was pulled into LilyPond and
it would be my guess that its author may be the "Ruth" in LilyPond's
DEDICATION file).
At any rate, it should meet our needs. In a similar vein, there seems
no ongoing point in maintaining "flower&quo
Han-Wen Nienhuys writes:
> On Tue, Nov 26, 2019 at 8:51 PM David Kastrup wrote:
>> > What level of respect should I maintain for the integrity of
>> > flower/include/yaffut.h? I think it would be nice to limit the
>> > default output of the unit test prog
Jonas Hahnfeld writes:
> Hi David,
>
> Am Montag, den 18.11.2019, 18:10 +0100 schrieb Jonas Hahnfeld:
>> Am Samstag, den 16.11.2019, 21:52 +0100 schrieb David Kastrup:
>> > Carl Sorensen <
>> > c_soren...@byu.edu
>> >
>> > > writes:
&g
Including a MusicXML file with options:
{%
\parindent 0pt
\noindent
\ifx\preLilyPondExample \undefined
\else
\expandafter\preLilyPondExample
\fi
\def\lilypondbook{}%
\input{include-systems.tex}
\ifx\postLilyPondExample \undefined
\else
\expandafter\postLilyPondExample
\fi
}
\end{document}
which seems inconspicuous.
--
David Kastrup
David Kastrup writes:
> Nothing happens anymore. Process output is the following:
>
> PID TTY STAT TIME COMMAND
> 318 pts/1S+ 0:00 make -j9 test
> 1656 tty1 Ss 0:00 /bin/login -p --
> 2131 pts/1S+ 0:00 make --no-builtin-rules -C
> inpu
David Kastrup writes:
> Looks like a permission problem? "File ignored"? But the PATH looks
> like it does not have any absolute component or .. in it ?
>
> Huh. Maybe the script I used made some bad changes? I'll have to
> check.
Sorry for the false alarm.
"setting it to '%s'\n",
+ id, dir));
+ return dir;
+ }
- string bindir = prefix + "/bin";
-
- prepend_env_path ("PATH", bindir);
+ // otherwise fall back to compile-time value
+ dir = File_name (compile_default).canonicalized ().to_string ();
+ debug_output (_f (" Using compile-time value for %s,\n"
+ "setting it to '%s'\n",
+ id, dir));
+ return dir;
}
- /*
- UGH : this is a complete mess.
- */
void
setup_paths (char const *argv0_ptr)
{
This is so much of a mess that I'd need a very good reason (namely:
won't work otherwise) for trying to fold this in.
--
David Kastrup
; I now made a local patch replacing all relevant occurrencies off '_'
> by 'G_' on top of the other guile2-patches.
If we define _ ourselves, why would we need to replace it with G_ ?
--
David Kastrup
David Kastrup writes:
> Knut Petersen writes:
>
>> On 26.07.19 20:36, David Kastrup wrote:
>>>
>>>> Unless Knut is also running patchy now that he has commit access (and
>>>> perhaps didn't have a clean master?).
>>>>
>>>&
show today; if not, perhaps Monday.
>
> https://codereview.appspot.com/553290043/
A callback function, if necessary due to early evaluation otherwise, a
pure/unpure container ?
--
David Kastrup
for us as long as no
well-performing string-interface is available that would efficiently
facilitate the C/Scheme string passing density of LilyPond.
Maybe we can coordinate something with Thien-Thi Nguyen who has been
keeping the Guile-1.8 branch tip in the official Guile repository from
bitrot due to Texinfo and language changes.
--
David Kastrup
The itty-bitty details mostly concern conversion into/out of the
internal UTF-8 though and don't have much of an impact on the normal
processing.
--
David Kastrup
some time?
By the way, we need to find a solution handling the byte-compiled files
of Guile2. I think that's part of our current slowdown but I may be
wrong.
--
David Kastrup
t the Scheme
level. Most of the inner loops accounting for much of the running time
are pretty C++-heavy.
--
David Kastrup
l clear improvements like typo fixes can usually be bundled. More
extensive additions may warrant separate Emails/patches/commits/issues.
--
David Kastrup
ke-dynamic-script #{ \markup { \normal-text \italic piu f } #})
{ c''1\piu-f }
> (Sorry I'm not trying it out right now, but I'm reading emails, not
> doing lilypond and looking for a piece to check it out on :-)
That's a problem if your mail client is not your LilyPond IDE.
--
David Kastrup
itly (and that's basically
what overrides/sets do) but other than that, there is no automatism. If
I write
<< \new Staff { c' } \new Voice { d' } >>
should the d' insinuate itself into the same staff as the c' ?
> On the other hand, changing this would change how existing scores that
> rely on automatic context creation are engraved. Is a change
> justified either on the grounds that the current behavior is a bug or
> that the NR gives fair warning not to rely on this feature?
I have no idea what behavior you propose instead.
--
David Kastrup
; Python 3.5?
>>
>> Let me know what you think!
>
> So far, I've only received a single (positive) response off-list and a
> bit of feedback on the posted patches. What do others think?
> To make this explicit: The proposal is to drop support for Python 2
> (now EOL), requiring everyone wishing to build LilyPond 'master' to
> have an appropriate version of Python 3 available. This should be
> sufficiently easy (see above), but I'd like to have consensus on this.
When we switch over GUB, we also need to switch over the 2.20 branch.
It's not just master that is affected.
--
David Kastrup
Dan Eble writes:
> On Jan 6, 2020, at 10:57, David Kastrup wrote:
>>> the current result is strange
>>
>> Can you explain why you feel that?
>
> I find it strange that this music produces these diverse results:
>
> music = << c' e' >>
Werner LEMBERG writes:
> This looks interesting!
>
> https://lgtm.com/projects/g/lilypond/lilypond
I'll agree that a number of those (not all) look worth changing.
--
David Kastrup
David Kastrup writes:
> Werner LEMBERG writes:
>
>> This looks interesting!
>>
>> https://lgtm.com/projects/g/lilypond/lilypond
>
> I'll agree that a number of those (not all) look worth changing.
I'll go through some.
--
David Kastrup
important.
>
> Seems like they just mistakenly used square brackets instead of parenthesis
> for grouping in the regular expression.
Ah yes, that makes sense. Of course, those patterns are garbage as well
since the correct names would be banter-chordnames and jazz-chordnames.
But at least it appears like we are getting somewhere.
--
David Kastrup
search/?q=guile>,
> and there seem to be people who use Guile 2.x with LP.
Guile 2.x (or the upcoming 3.x) continues to be a non-sensible option
for using LilyPond. The state is "barely working" and "at least 3 times
slower".
--
David Kastrup
Using a different Scheme interpreter would not be easier
than using Guile-2.x .
--
David Kastrup
ed in AC_INIT and in VERSION are the same.
>
> Ideally, I'd like to get rid of the VERSION completely, but apparently
> you can build the website without configure'ing the project. I wasn't
> sure if that is still used, so I went for this solution.
That doesn't answer my question, does it?
--
David Kastrup
ng it manually in the case it is necessary is not a
large encumbrance compared to the annoyance that may ensue.
So I'd suggest to be able to set the tool up in a manner where it will
not easily delete branches.
--
David Kastrup
for whatever developers and applications LilyPond is going to see in
future.
--
David Kastrup
e not going to fly with LilyPond.
--
David Kastrup
nistration. I don't think
they have Gerrit instances yet.
--
David Kastrup
Jahrme Risner writes:
> On 2020-01-08 at 15:00, David Kastrup d...@gnu.org wrote:
>
>> GitHub is putting our eggs in Microsoft's basket. Not too enthused about that
>> idea. If I remember correctly, GitLab had some size restrictions that clearly
>> are not going t
Erlend Aasland writes:
>> On 19 Jan 2020, at 00:00, David Kastrup wrote:
>>
>> Erlend Aasland writes:
>>
>> GitHub is putting our eggs in Microsoft's basket. Not too enthused
>> about that idea.
>
> Technically, you already did, since the
n text. But...
I decided to delete the following quoted plain text (it's useless
anyway) and append a rendition of the indented HTML text.
Thus spake Erlend:
On 19 Jan 2020, at 18:19, David Kastrup wrote:
What is of concern is the whole metadata about issues and their
h
steam in the self-hosting challenge on Allura:
there is not much of a sense in aiming higher than we can expect to
shoot eventually.
--
David Kastrup
commits that have not yet seen
grand-replace. So while the current time plan would suggest that delays
would not be for all that long, I don't see that the grand-replace could
cause any hassle, and at the very least not any significant one.
So go wild.
--
David Kastrup
do damage,
but any pull request or other magic that happened only at the GitHub
site will be lost.
So better wait at least a week for feedback before going ahead. Sounds
annoying, but it would be a shame to lose work from somebody who thought
contributing via GitHub the right way to proceed.
--
David Kastrup
ledgment led to
patches "in limbo" for weeks without any feedback. I have a Guile core
patch that has not gotten a review or comment by Andy Wingo for about
5 years or so now. In contrast to that, our process is comparably fast
and benign.
--
David Kastrup
effective is something we'll have to see: while our
contribution procedures may appear baroque, the code base to actual work
on is byzantine in comparison.
--
David Kastrup
se for finding "the closest
> enclosing context where a given property is defined," but I am not now
> prepared to elaborate. — Dan
Comments from the EE crowd?
--
David Kastrup
gt;And of course, a big thank you to all of you that do all the great
>work, that I really appreciate! But to attract more developers and /
>or re-animate retired developers, I am pretty sure that the process has
>to be simplified for potential "casual" committers like me that will
>contribute only now and then.
The above does not look all that complex to me.
--
David Kastrup
course Guile has modules. Do we already have a thought about how
to relate to the module system? With regard to namespaces, there may be
something to be said for requiring explicit export in the long run?
--
David Kastrup
rse, this is a temporary measure until Janek finds and
>implements something better (see the Salzburg googledoc file posted
>recently for more).
--
David Kastrup
gs warrant a chance for developers
to take a look at it. "Half a chance" seems an unnecessary
complication.
--
David Kastrup
David Kastrup writes:
> Werner LEMBERG writes:
>
>>>> Han-Wen has recently pushed a bunch of changes directly to
>>>> Rietveld, most of them quite uncontroversial. I assume that this
>>>> is as good as an e-mail :-)
>>>>
>>
Thomas Morley writes:
> Switching to devel,
>
> Am Mo., 20. Jan. 2020 um 21:30 Uhr schrieb David Kastrup :
>>
>> Thomas Morley writes:
>> >
>> > Back at home now.
>> > My trail broke at Plochingen, which is close to the middle of nowhere ..
re may be
>> something to be said for requiring explicit export in the long run?
>>
>
> Although I know this is important I don't feel comfortable having an
> opinion about this type of issue.
Ok. One thing to think about is that we want package files to be
contributed by "ordinary" users. But something like
\exportSymbols transposeSequence,instrumentGroup,scratchMyBack
would be perfectly feasible syntactical sugar.
--
David Kastrup
virtual machine, with the extra challenges of trying to maintain the
> VM image. If the process of making the Docker application would also
> allow a simple set up for a build environment in non-Linux machines, I
> think that would be a huge win.
Not sure where this is getting, but it might just be a case of beer.
Actually, more like a bottle of beer.
--
David Kastrup
good hunch is required.
> In any case, it will take some time before I even can start this work.
> Tomorrow my regular job will occupy most of my time...
Those things happen.
--
David Kastrup
the community, I would be happy
> to submit the scripts for inclusion into the LilyPond repository
> itself. That would also solve another issue with GUB: Currently it's a
> separate repository with no way to keep it in sync with changing
> dependencies for LilyPond...
Maybe we should entertain two branches of GUB matching current stable
and unstable release tracks? Or otherwise deal with a difference in
dependencies for stable/unstable?
--
David Kastrup
Jonas Hahnfeld writes:
> Am Dienstag, den 21.01.2020, 11:28 +0100 schrieb David Kastrup:
>>
>> Windows really is the elephant in the room. MacOSX will cater with
>> native port systems like MacPorts etc and other UNIX-like systems
>> also have working packagers and p
rrent rate of commits and staging tests, disentangling this tends to
be comparatively benign.
As long as nothing, however trivial, gets pushed to master without
testing, the consequences are at least kept in check mostly.
--
David Kastrup
fined
> \context [rehearsalMark] { … } % CSS
> \context [@rehearsalMark] { … }% XPATH
> —
> Dan
The syntax appears not to be a good match to LilyPond even though the
concept may be considered fitting.
--
David Kastrup
Dan Eble writes:
> On Jan 21, 2020, at 14:20, David Kastrup wrote:
>>
>>> Notation borrowed directly from them will not integrate well
>>> into LilyPond, but it might be fruitful to ask how we could modify
>>> expressions like these to fit in.
> ...
>&
Dan Eble writes:
> On Jan 21, 2020, at 14:37, David Kastrup wrote:
>>
>> StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2
>
> OK. It would be an understandable growth on the current face of LilyPond. :)
>
> Questions follow, but
) 'Bottom)
+#(ly:expect-warning (_ "default child context begins a cycle: ~a") 'Score)
+#(ly:expect-warning (_ "cannot find or create context: ~a") 'Bottom)
\header {
texidoc = "A @code{\\defaultchild} cycle does not induce an endless loop.
So why is that patch not in your
input/regression/context-defaultchild-cycle ?
--
David Kastrup
Thomas Morley writes:
> Am Mi., 22. Jan. 2020 um 00:59 Uhr schrieb David Kastrup :
>>
>>
>> #(ly:set-option 'warning-as-error #t)
>> %% not sure why these warnings appear twice [dfe]
>> -#(ly:expect-warning (_ "default child context begins a cy
lt
> as LilyPond does but that parse the package files themselves.
Maybe we should have single-command exports after all and have a
(non-optional ?) documentation string to be used as mouse-over? I think
a unified approach to documentation might go a long way towards basic
usability.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Tue, Jan 21, 2020 at 11:28 AM David Kastrup wrote:
>
>> But the elephant in the room is Windows. Han-Wen says he never wants to
>> touch GUB again (and he actually didn't as far as I remember) but I
Something happened between brain and key
providing an environment where all binaries
> are reproducibly built from source. This is much more ambitious than
> GUB, and seems overkill compared to what we need for LilyPond. I think
> using it also entails many more compilation steps, which would makes
> the release process slow again.
I don't think it has an answer for the elephant in the room: Windows.
--
David Kastrup
Flaming Hakama by Elaine writes:
>> -- Forwarded message --
>> From: David Kastrup
>> To: Dan Eble
>> Cc: lilypond-devel@gnu.org
>> Bcc:
>> Date: Tue, 21 Jan 2020 22:51:29 +0100
>> Subject: Re: Context paths (and the Edition Engrav
t data say?
That data says "humongous slowdown". There is not much more than
speculation what this is caused by as far as I know.
--
David Kastrup
Jan Nieuwenhuizen writes:
> David Kastrup writes:
>
>> Han-Wen Nienhuys writes:
>>> GUIX is Jan's current project. I think it has some similarities to
>>> GUB, but it is focused on providing an environment where all binaries
>>> are reproducibly bu
Han-Wen Nienhuys writes:
> On Wed, Jan 22, 2020 at 12:01 PM David Kastrup wrote:
>
>> Han-Wen Nienhuys writes:
>>
>> > I looked a bit through the GUILE source code to see what is going on.
>> >
>> > I believe our current hypothesis (LilyPond&#
Han-Wen Nienhuys writes:
> On Wed, Jan 22, 2020 at 10:53 PM Han-Wen Nienhuys wrote:
>
>>
>>
>> On Wed, Jan 22, 2020 at 12:01 PM David Kastrup wrote:
>>
>>>
>>> > So, what hard data do we have on GUILE 2/3 slowness, and what does
>>>
Han-Wen Nienhuys writes:
> On Wed, Jan 22, 2020 at 11:43 PM David Kastrup wrote:
>
>> > Actually, the I was comparing the -O2 build with the -O0 build.
>> >
>> > When recompiling, the Scheme init (reading .scm files) takes 0.31s in 1.8
>> > vs. 2.7
If there are extensive changes, we
probably want most of the solution in the main source code or
rebasing/cherry-picking becomes a nightmare.
--
David Kastrup
nt packages wouldn't be an issue.
>
> A user can still do something like
>
> criticalRemark = scholarly.annotate.criticalRemark
>
> as a local shorthand.
No, that would be equivalent to
criticalRemark = #'(scholarly annotate criticalRemark)
--
David Kastrup
like 10 years old and holds 16GB
of RAM.
--
David Kastrup
ge collection.
On a 64bit application, this would be somewhat more tenable, but we'd
need to override operator new for smobs.
Or do we? Maybe the heap is collected by default, and we need to switch
that off?
--
David Kastrup
Han-Wen Nienhuys writes:
> On Thu, Jan 23, 2020 at 10:39 PM David Kastrup wrote:
>
>>
>> > on mozart-hrn-3, over 3 runs, we get
>> >
>> > 2.0.14 - avg 2.1s
>> > 1.8.8 - avg 0.31s
>> >
>> > so the new GC is about 5-10x slowe
probably out of date.
Last time I looked, Guile 2 switched the BGC into Java collection
semantics where it finishes one mark pass (including user-defined hooks)
before it commences to collecting stuff marked with it and calling its
(equivalent of) destructors. That prevents the mark hooks continuing to
get called after the C++ destructor already ran. That is somewhat more
synchronised than its default manner of operating.
--
David Kastrup
the 45W TDP instead of the expected
35W) which takes about 45 minutes for the full test with docs.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Fri, Jan 24, 2020 at 10:51 AM David Kastrup wrote:
>
>>
>> >> On a 64bit application, this would be somewhat more tenable, but we'd
>> >> need to override operator new for smobs.
>> >>
>> >> Or do w
Urs Liska writes:
> Am Freitag, den 24.01.2020, 11:41 +0100 schrieb Han-Wen Nienhuys:
>> On Fri, Jan 24, 2020 at 11:28 AM David Kastrup wrote:
>>
>> > Han-Wen Nienhuys writes:
>> >
>> > > Thanks for keeping track of this.
>> > >
&g
Han-Wen Nienhuys writes:
> On Fri, Jan 24, 2020 at 11:58 AM David Kastrup wrote:
>> >> I guess I am a developer with repository access, but in Salzburg,
>> >> Werner
>> >> offered to me to do the mechanics of shepherding the patches through,
>> >
Han-Wen Nienhuys writes:
> On Fri, Jan 24, 2020 at 11:30 AM David Kastrup wrote:
>> >> >> On a 64bit application, this would be somewhat more tenable, but we'd
>> >> >> need to override operator new for smobs.
>> >> >>
>> >
Han-Wen Nienhuys writes:
> On Fri, Jan 24, 2020 at 10:51 AM David Kastrup wrote:
>
>>
>> > What do you mean with "heap is collected"?
>>
>> "Collected" is probably the wrong expression. Sweeped and marked. The
>> proposed behavior b
101 - 200 of 1137 matches
Mail list logo
