"m...@mikesolomon.org" writes:
> It is true that line-breaking is a centralized option based on what
> the toplevel-book-handler is, but it should be as lightweight as
> possible. I think that the smaller we can keep paper-book.cc and
> paper-score.cc, the better. I've been saying this for a co
On 30 sept. 2012, at 14:29, David Kastrup wrote:
> "m...@mikesolomon.org" writes:
>
>> On 30 sept. 2012, at 14:16, Janek Warchoł wrote:
>>
>>> Hi,
>>>
>>> interesting discussion, i learn a lot.
>>>
>>> On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup wrote:
Basically, a grob says "I w
"m...@mikesolomon.org" writes:
> On 30 sept. 2012, at 14:16, Janek Warchoł wrote:
>
>> Hi,
>>
>> interesting discussion, i learn a lot.
>>
>> On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup wrote:
>>> Basically, a grob says "I want to have this and that information for
>>> making my positioni
On 30 sept. 2012, at 14:16, Janek Warchoł wrote:
> Hi,
>
> interesting discussion, i learn a lot.
>
> On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup wrote:
>> Basically, a grob says "I want to have this and that information for
>> making my positioning" and LilyPond says "You can't get it ri
Hi,
interesting discussion, i learn a lot.
On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup wrote:
> Basically, a grob says "I want to have this and that information for
> making my positioning" and LilyPond says "You can't get it right now".
> Then the grob says "ok, I'll do a tentative position
On 30 sept. 2012, at 11:39, David Kastrup wrote:
> David Kastrup writes:
>
>> "m...@mikesolomon.org" writes:
>>
>>> On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote:
>>>
>>>On 29 sept. 2012, at 19:53, "Keith OHara"
>>>wrote:
>>>
>>>On Sat, 29 Sep 2012 10:30:32 -0700,
David Kastrup writes:
> "m...@mikesolomon.org" writes:
>
>> On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote:
>>
>> On 29 sept. 2012, at 19:53, "Keith OHara"
>> wrote:
>>
>> On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org
>> wrote:
>>
>>
"m...@mikesolomon.org" writes:
> On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote:
>
> On 29 sept. 2012, at 19:53, "Keith OHara"
> wrote:
>
> On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org
> wrote:
>
>
> The way
On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote:
>
> On 29 sept. 2012, at 19:53, "Keith OHara" wrote:
>
>> On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org
>> wrote:
>>
>>>
>>> The way you're using "tentative" is almost exactly how pure properties are
>>> used in LilyPond.
On 29 sept. 2012, at 19:53, "Keith OHara" wrote:
> On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org
> wrote:
>
>>
>> The way you're using "tentative" is almost exactly how pure properties are
>> used in LilyPond.
>
> Specifically, 'pure-height being the estimated vertical extent be
On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org
wrote:
The way you're using "tentative" is almost exactly how pure properties are used
in LilyPond.
Specifically, 'pure-height being the estimated vertical extent before
line-breaking, while 'height is its extent after line-breaking
On 29 sept. 2012, at 18:34, Keith OHara wrote:
> Han-Wen Nienhuys gmail.com> writes:
>
>> I think it is a much clearer abstraction to decide that each property
>> can only be evaluated once, and that everything should be driven by
>> callbacks. In fact, one thing I would suggest looking at is
Han-Wen Nienhuys gmail.com> writes:
> I think it is a much clearer abstraction to decide that each property
> can only be evaluated once, and that everything should be driven by
> callbacks. In fact, one thing I would suggest looking at is removing
> {before,after}_line_breaking which breaks this
On Sat, Sep 29, 2012 at 11:35 AM, m...@mikesolomon.org
wrote:
>
> On 29 sept. 2012, at 10:59, Han-Wen Nienhuys wrote:
>
>> On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup wrote:
>>> Han-Wen Nienhuys writes:
>>>
In order to do cache invalidation, you will have to construct the
reverse
On 29 sept. 2012, at 10:59, Han-Wen Nienhuys wrote:
> On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup wrote:
>> Han-Wen Nienhuys writes:
>>
>>> In order to do cache invalidation, you will have to construct the
>>> reverse graph. If A.x depends on B.y, now A points to B. For proper
>>> cache i
On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
>> In order to do cache invalidation, you will have to construct the
>> reverse graph. If A.x depends on B.y, now A points to B. For proper
>> cache invalidation, if B.y changes, then A.x becomes invalid. This
>>
Mats Bengtsson writes:
> On 09/27/2012 08:36 AM, lilypond-devel-requ...@gnu.org wrote:
>>> A typical example of this is NoteCollision of N NoteColumns. The
>>> >NoteColumns have to all move in a coordinated way, and the easiest way
>>> >is to have a function (with local variables) that determines
On 09/27/2012 08:36 AM, lilypond-devel-requ...@gnu.org wrote:
A typical example of this is NoteCollision of N NoteColumns. The
>NoteColumns have to all move in a coordinated way, and the easiest way
>is to have a function (with local variables) that determines what has
>to happen. You might get
On 26 sept. 2012, at 21:51, Han-Wen Nienhuys wrote:
> On Wed, Sep 26, 2012 at 9:17 PM, m...@mikesolomon.org
> wrote:
>
>> Another way to think of this is that, in general, we'd try to eliminate
>> grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do
>> traffic-coppery. Or,
Han-Wen Nienhuys writes:
> In order to do cache invalidation, you will have to construct the
> reverse graph. If A.x depends on B.y, now A points to B. For proper
> cache invalidation, if B.y changes, then A.x becomes invalid. This
> means that A has to store a back-reference to B. Hence all poin
On Wed, Sep 26, 2012 at 12:17 PM, m...@mikesolomon.org wrote:
> On 26 sept. 2012, at 17:38, Joe Neeman wrote:
>
> On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org <
> m...@mikesolomon.org> wrote:
>
>
> To start this process, I'd like to expand the role of the
>> side-position-interface sign
On Wed, Sep 26, 2012 at 9:17 PM, m...@mikesolomon.org
wrote:
> Another way to think of this is that, in general, we'd try to eliminate
> grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do
> traffic-coppery. Or, inversely, we'd say that positioning only happens via
> traffi
On 26 sept. 2012, at 17:38, Joe Neeman wrote:
> On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org
> wrote:
> Hey all,
>
> As was the case in a few of my previous projects, before I start something
> new I make architecture changes that facilitate my work. Working on 2801,
> I've realize
On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org
wrote:
> Hey all,
>
> As was the case in a few of my previous projects, before I start something
> new I make architecture changes that facilitate my work. Working on 2801,
> I've realized that any multi-pass algorithm for the spacing of grobs
2012/9/26 m...@mikesolomon.org :
>
> On 26 sept. 2012, at 14:13, David Kastrup wrote:
>> Conceptually simple problems need to map to conceptually simple
>> solutions. If they don't, our APIs suck.
>
> We don't have APIs,
Sounds like we found the reason they suck.
Couldn't reseist, sorry.
--
Fr
On 26 sept. 2012, at 14:13, David Kastrup wrote:
>> What we need to arrive at is a situation where somebody without a clue
> starting to write stuff will more likely than not get a whole lot of
> things working right without realizing it, rather than getting a whole
> lot of things working wrong
"m...@mikesolomon.org" writes:
> On 26 sept. 2012, at 13:39, David Kastrup wrote:
>
>> It sounds to me like it would make more sense that we improve our
>> cache invalidation strategy where it goes wrong
>
> There is currently no cache invalidation strategy.
Sounds like we found the place where
On 26 sept. 2012, at 13:39, David Kastrup wrote:
> "m...@mikesolomon.org" writes:
>
>> As was the case in a few of my previous projects, before I start
>> something new I make architecture changes that facilitate my work.
>> Working on 2801, I've realized that any multi-pass algorithm for the
"m...@mikesolomon.org" writes:
> As was the case in a few of my previous projects, before I start
> something new I make architecture changes that facilitate my work.
> Working on 2801, I've realized that any multi-pass algorithm for the
> spacing of grobs is difficult because results of callback
29 matches
Mail list logo
