are a different game.
> However, I'd like to stress that we are (or at least should be) talking
> about several different things when saying "package" and "loading":
>
> 1)
> Loading a package/module *file*, parsing its code and making elements
> available to clients
>
> 1a)
> One question is how to address these includable files
> 1b)
> The other question is where the elements and which elements of the
> loaded files are visible.
>
> 2)
> Loading/using a package in a more conceptual sense, like "edition-
> engraver" or "scholarLY". Here all the stuff about option handling
> becomes (more) relevant, and the questions of 1) are prerequisites.
>
> ###
>
> So when talking about new commands to "load packages" we are actually
> talking about two different things that *both* have to be done.
For now, we just have to address the case of loading a single scm file
with its own module and exported symbols.
--
David Kastrup
cess all the tests.
If you managed to get the change out before it went to master, you
should be good.
Process and scripts have seen some refinement over the years...
--
David Kastrup
ling problems.
>
> My thought was to separate the two different types of .scm files in
> that directory, and that could of course also be achieved by moving the
> *other* files, those that are loaded with ly:load from lily.scm to a
> different directory.
>
> Or - of course - I can simply drop this and add new modules to that
> same directory for now.
>
>>
>
>
>
--
David Kastrup
Dan Eble writes:
> On Jan 31, 2020, at 08:31, David Kastrup wrote:
>> -fexcess-precision=style
>> This option allows further control over excess precision on
>> machines where floating-point operations occur in a format
>> with m
the
Guile code paths do not change from one call to the next. So unless
just-in-time compilation comes into play, I don't think that Guile
behavior should be a problem concerning our non-reproducibility problem.
--
David Kastrup
" to
be defined.
This option is not turned on by any -O option besides -Ofast
since it can result in incorrect output for programs that
depend on an exact implementation of IEEE or ISO
rules/specifications for math functions. It may, however,
yield faster code for programs that do not require the
guarantees of these specifications.
--
David Kastrup
mechanism was incompatible with the stream event
recorder and was ultimately replaced by me with
commit 314743a9769d8094d23cd45eb307b1485b41cb44
Author: David Kastrup
Date: Tue Sep 15 20:50:13 2015 +0200
Issue 4609/4: Move \once action from iterators to listeners
This ends the dependency of the events ge
Dan Eble writes:
> On Jan 30, 2020, at 14:57, David Kastrup wrote:
>>
>> os.symlink ("../../../out-baseline/share",
>> "out-www/offline-root/input/regression/out-test-baseline/share")
>>
>> What has the test baseline to do with make d
Dan Eble writes:
> On Jan 30, 2020, at 13:39, David Kastrup wrote:
>>
>>> I just had a successful mage -j5 doc as of commit
>>> 8a05312fd8d2a56ec724a793b313949db0cfe729
>>
>> Current stable/2.20 which failed on my system.
>
> I also am not able
Dan Eble writes:
> On Jan 30, 2020, at 13:39, David Kastrup wrote:
>>
>>> I just had a successful mage -j5 doc as of commit
>>> 8a05312fd8d2a56ec724a793b313949db0cfe729
>>
>> Current stable/2.20 which failed on my system.
>
> I also am not able
Jean-Charles Malahieude writes:
> Le 30/01/2020 à 19:46, David Kastrup a écrit :
>> Oops.
>> dak@lola:/usr/local/tmp/lilypond$ git checkout origin
>> error: The following untracked working tree files would be overwritten by
>> checkout:
>> Documentation
David Kastrup writes:
> David Kastrup writes:
>
>> Jean-Charles Malahieude writes:
>>
>>> Le 30/01/2020 à 19:08, David Kastrup a écrit :
>>>> Dan Eble writes:
>>>>
>>>>> On Jan 30, 2020, at 11:39, David Kastrup wrot
David Kastrup writes:
> Jean-Charles Malahieude writes:
>
>> Le 30/01/2020 à 19:08, David Kastrup a écrit :
>>> Dan Eble writes:
>>>
>>>> On Jan 30, 2020, at 11:39, David Kastrup wrote:
>>>>> That's not a new development, so the
Jean-Charles Malahieude writes:
> Le 30/01/2020 à 19:08, David Kastrup a écrit :
>> Dan Eble writes:
>>
>>> On Jan 30, 2020, at 11:39, David Kastrup wrote:
>>>> That's not a new development, so there is no point in me to refrain from
>>>> c
Dan Eble writes:
> On Jan 30, 2020, at 11:39, David Kastrup wrote:
>> That's not a new development, so there is no point in me to refrain from
>> cherry-picking further material: the last version of the branch I
>> checked was from early December and it failed in the same m
'd be glad to hear about possible
causes.
Thanks!
--
David Kastrup
hove, giving a slight delay to
2.19.84). This is kind of an important thing to have fixed in the
stable release if we see a chance of doing so, and having that two-week
window would be a good thing.
I haven't yet looked at the patch/discussion yet: this is just my first
reaction rather than an LGTM.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Mon, Jan 27, 2020 at 11:33 AM David Kastrup wrote:
>> >
>> > When calling the macro twice, we'll define add-session-variable twice,
>> > which seems fishy.
>>
>> I think you got confused here. A macro is just an ordinary
Han-Wen Nienhuys writes:
> On Mon, Jan 27, 2020 at 11:33 AM David Kastrup wrote:
>> >
>> > When calling the macro twice, we'll define add-session-variable twice,
>> > which seems fishy.
>>
>> I think you got confused here. A macro is just an ordinary
il that a
package user should not need to bother about, and that hopefully should
not significantly complicate things for people wanting to provide
packages with either or both .ly and/or .scm components.
--
David Kastrup
Urs Liska writes:
> Am Dienstag, den 28.01.2020, 00:34 +0100 schrieb David Kastrup:
>> Urs Liska writes:
>>
>> So basically there is long-term potential for efficiency to mostly
>> become a non-issue.
>
> I'm sorry, but I don't fully understand what you are
ecome interesting for custom data storage.
> We have a tree implementation in oll-core at
> https://github.com/openlilylib/oll-core/blob/master/scheme/oll-core/tree.scm
> Would that be something to use here?
Whatever we do, it should be an implementation detail the user _and_ the
package programmers do not really need to know about. There should be
accessors hiding the organisation.
--
David Kastrup
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Mon, Jan 27, 2020 at 11:49 AM David Kastrup wrote:
>>> > I want to propose to move to automated formatting for our C++ code.
>>> >
>>> > I put up a .clang-format code that
Han-Wen Nienhuys writes:
> On Mon, Jan 27, 2020 at 11:49 AM David Kastrup wrote:
>> > I want to propose to move to automated formatting for our C++ code.
>> >
>> > I put up a .clang-format code that mostly mimicks our style at
>> >
>> > http
sole in the local locale independent
from what it does on file-I/O. In practice, I think it would be a long
haul to get LilyPond to work in non-UTF8 console locales.
--
David Kastrup
Dan Eble writes:
> On Jan 27, 2020, at 09:33, David Kastrup wrote:
>>
>>> I would like to replace the following with standard types (uint8_t
>>> etc.). The standard types are portable, but these are not.
> ...
>>> * flower-proto.hh:typedef unsigned U32;
has seen a formal end of cherry-picking
in order not to complicate it. The style changes can happen in parallel
on both release branches. With regard to the somewhat more invasive
type frobbing, I think I'd wait for it until 2.21.0 has already been
out.
--
David Kastrup
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> I want to propose to move to automated formatting for our C++ code.
>>
>> I put up a .clang-format code that mostly mimicks our style at
>>
>> https://codereview.appspot.com/561340043
>>
>>
/docs/ClangFormatStyleOptions.html
> for further options.
>
> Obviously, reformatting code makes patches harder to transport, so
> we'd have to do it on all active branches at the same time.
--
David Kastrup
is the symbol to be defined which must
not be evaluated before define-session is being called.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Sonntag, den 26.01.2020, 17:30 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Sonntag, den 26.01.2020, 16:25 +0100 schrieb David Kastrup:
>> > > > OK. So w
Jonas Hahnfeld writes:
> Am Sonntag, den 26.01.2020, 16:25 +0100 schrieb David Kastrup:
>>
>> > OK. So what is your proposal for how to proceed with Jonas' patch?
>>
>> Different possibilities. Probably easiest is to have different GUB
>> setups for LilyP
Han-Wen Nienhuys writes:
> On Sun, Jan 26, 2020 at 3:45 PM David Kastrup wrote:
>>
>> Han-Wen Nienhuys writes:
>>
>> > Can we fast-track the submission of
>> >
>> > http://codereview.appspot.com/571430046
>> >
>> > I otherwise h
Han-Wen Nienhuys writes:
> On Sun, Jan 26, 2020 at 3:33 PM David Kastrup wrote:
>> >> What David is concerned about (as far as I understand) is that we need
>> >> to modify the spec for LilyPond to require the new python3 package as a
>> >> dep
Jonas Hahnfeld writes:
> Am Sonntag, den 26.01.2020, 15:45 +0100 schrieb David Kastrup:
>> Han-Wen Nienhuys <
>> hanw...@gmail.com
>> > writes:
>>
>> > Can we fast-track the submission of
>> >
>> > http://codereview.appspot.co
Han-Wen Nienhuys writes:
> On Sun, Jan 26, 2020 at 3:45 PM David Kastrup wrote:
>>
>> Han-Wen Nienhuys writes:
>>
>> > Can we fast-track the submission of
>> >
>> > http://codereview.appspot.com/571430046
>> >
>> > I otherwise h
nly does something for GUILEV2.
I'm puzzled about the std::exception thing (why should that come up now
when it didn't do so before?) but that does not look like being able to
_cause_ rather than fix a problem. Ok for you if I split this into
separate commits? Or want to do this on your own?
--
David Kastrup
ff stacking up on the 2.22 slate right now
regarding platform support alone, that is likely going to be a while.
I don't think that Python3 will port to PowerPC, so a backport of
Py3-only code would entail cutting its support in the middle of the 2.20
lifetime. To be honest, I already had suggested cutting it before 2.20
but was met with resistance.
--
David Kastrup
pkx1...@posteo.net writes:
> On 25/01/2020 14:26, David Kastrup wrote:
>> ...
>> 16.04 is all very nice, but relying on non-updated legacy systems for
>> proscribing the dependencies of a hot-of-the-presses release is not
>> providing much of value.
>
> Talking
Han-Wen Nienhuys writes:
> On Sat, Jan 25, 2020 at 8:16 PM David Kastrup wrote:
>> > $ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
>> > -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
>> > -dAutoRotatePages=/None -dPri
Han-Wen Nienhuys writes:
> On Sat, Jan 25, 2020 at 3:50 PM David Kastrup wrote:
>> > That patch is papering over a problem rather than fixing it. It might
>> > be a reoccurence of something like
>> >
>> > commit c01a2a757e3c59727bdfa8d77568bf42525fbe05
&g
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> With https://codereview.appspot.com/551390047/
>
> That patch is papering over a problem rather than fixing it. It might
> be a reoccurence of something like
>
> commit c01a2a757e3c59727bdfa8d77568bf42525fbe05
&
Jonas Hahnfeld writes:
> Am Samstag, den 25.01.2020, 15:26 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld via Discussions on LilyPond development
>> <
>> lilypond-devel@gnu.org
>> > writes:
>>
>> > Am Samstag, den 25.01.2020, 14:45 +0100 schrieb T
ter and future major versions
> of LilyPond.
16.04 is all very nice, but relying on non-updated legacy systems for
proscribing the dependencies of a hot-of-the-presses release is not
providing much of value.
--
David Kastrup
Dan Eble writes:
> On Jan 25, 2020, at 07:26, David Kastrup wrote:
>>
>> - Interval hex = head->extent (common_[X_AXIS], X_AXIS);
>> + Interval head_ext = head->extent (common_[X_AXIS], X_AXIS);
> ...
>>
>> That last part applies part of a p
ly.
Current batch is through. Whatever rocks your boat.
--
David Kastrup
on that as the clearly more
tedious one.
> Even if we wouldn't recoup all the overhead of GC, I think the reduced
> complexity of using BGC for GC might be worth it.
>
> I think it is clear that we should not be targeting GUILE 2.0, but
> GUILE 2.2.
Well, not much of a point in targeting an old stable version except
possibly for checking the new stable for regressions.
--
David Kastrup
cessary using
git reset --hard
Took me about half an hour of head-scratching to figure out why the
diffs would differ here.
--
David Kastrup
Thomas Morley writes:
> Am Fr., 24. Jan. 2020 um 22:28 Uhr schrieb Thomas Morley
> :
>>
>> Am Fr., 24. Jan. 2020 um 22:16 Uhr schrieb Dan Eble :
>> >
>> > On Jan 24, 2020, at 15:13, David Kastrup wrote:
>> >
>> >
>> > Thomas
Dan Eble writes:
> On Jan 24, 2020, at 15:13, David Kastrup wrote:
>>
>> Thomas Morley mailto:thomasmorle...@gmail.com>>
>> writes:
> ...
>>> In member function 'std::string Interval_t::to_string() const':
>>> /home/hermann/gub/target/freeb
source code assumes more or less C++11 I think, and GUB
compilers might not be up to it?
Another possibility is that std::to_string is defined by accident (by
some include file including another file) and this does not work for all
implementations of the library.
--
David Kastrup
> // to-be-freed pointer, and we can't guarantee that the pointer
> // actually comes from GC_MALLOC.
> }
That looks rather crude. Should be ok for a rough profiling guess, though.
--
David Kastrup
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Fri, Jan 24, 2020 at 12:45 PM David Kastrup wrote:
>>> >> No. Since much of LilyPond's data containing SCM values is stored in
>>> >> STL containers, it would require serious messing with alloca
Peter Toye writes:
> Friday, January 24, 2020, 3:29:54 PM, David Kastrup wrote:
>
>> Peter Toye writes:
>
>>> Friday, January 24, 2020, 1:32:32 PM, David Kastrup wrote:
>>>
>
>>> But if bash can't find the app in the first place,
>>&
Peter Toye writes:
> Friday, January 24, 2020, 1:32:32 PM, David Kastrup wrote:
>
>> Peter Toye writes:
>
>>> Friday, January 24, 2020, 11:34:24 AM, Peter Toye wrote:
>>>
>>> That's easier said than done. I found the relevant package name and
>>&
does apt-get put the
> installed package? Or do I have to do something else first?
Should be installed where it's getting found as long as your shell is
not convinced otherwise from previous tries.
--
David Kastrup
quot;Rational" type exploding for certain
denominators that the "new complexity" composers love to be dealing
with, and removing size mismatches at least lets them explode at a time
when their actual capacity rather than a fraction of it gets exhausted.
--
David Kastrup
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
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 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,
>> >
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 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 we? M
th the 45W TDP instead of the expected
35W) which takes about 45 minutes for the full test with docs.
--
David Kastrup
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
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
ion.
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
ears old and holds 16GB
of RAM.
--
David Kastrup
s 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
here are extensive changes, we
probably want most of the solution in the main source code or
rebasing/cherry-picking becomes a nightmare.
--
David Kastrup
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
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 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's
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 built f
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
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
om 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
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 keybo
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
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 cycle:
)
+#(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
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
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.
> ...
>&
y is defined
> \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
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
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
lyPond 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
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
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
g 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
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 ..
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 :-)
>>>>
>>
for developers
to take a look at it. "Half a chance" seems an unnecessary
complication.
--
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
y 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
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
ding "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
ing 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
ed 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
at 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
:
there is not much of a sense in aiming higher than we can expect to
shoot eventually.
--
David Kastrup
901 - 1000 of 6030 matches
Mail list logo
