On 2010/07/18 09:08:19, Valentin Villenave wrote:
if you don't mind me asking, where are we wrt this patch?
If it only comes down to a coding style problem, I'm pretty sure I've
already
seen worse in existing source code :)
I've prepared a patch which I'll push later.
Cheers,
Neil
http:
On 2010/07/11 04:08:30, Carl wrote:
If we get these cleared up, then I'll push.
Hello guys,
if you don't mind me asking, where are we wrt this patch?
If it only comes down to a coding style problem, I'm pretty sure I've
already seen worse in existing source code :)
Cheers,
Valentin
http://c
Neil has approved. He mentioned some style nitpicks. I went through
looking for style nitpicks, and found two.
If we get these cleared up, then I'll push.
http://codereview.appspot.com/1345041/diff/2001/3004
File lily/include/lily-parser.hh (right):
http://codereview.appspot.com/1345041/diff
On 2010/07/02 15:55:27, Carl wrote:
I'm not sure where we are on this patch; we've had some philosophical
discussion
whose end I'm not sure I understand.
Is this OK to push?
LGTM, save a few style nitpicks.
http://codereview.appspot.com/1345041/show
__
On 2 July 2010 23:47, Benjamin Peterson wrote:
> If you accept this patch, I will also provide one to ban ly:parser-parse-file
> in
> times that it segfaults.
That sounds like a fair deal. :)
The patch looks fine to me (there are just a few minor style nits
which can be squelched when it's app
gmail.com> writes:
>
> I'm not sure where we are on this patch; we've had some philosophical
> discussion whose end I'm not sure I understand.
If you accept this patch, I will also provide one to ban ly:parser-parse-file in
times that it segfaults.
_
I'm not sure where we are on this patch; we've had some philosophical
discussion whose end I'm not sure I understand.
Is this OK to push?
http://codereview.appspot.com/1345041/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gn
Le 7 juin 2010 à 21:35, reinhold.kainho...@gmail.com a écrit :
> On 2010/06/07 19:17:27, Neil Puttock wrote:
>> On 2010/06/07 13:59:45, Reinhold wrote:
>> > However, I fail to see where this is actually used...
>
>> It's called whenever Guile encounters the character sequence #{ for
> parsing
>>
On 2010/06/07 19:17:27, Neil Puttock wrote:
On 2010/06/07 13:59:45, Reinhold wrote:
> However, I fail to see where this is actually used...
It's called whenever Guile encounters the character sequence #{ for
parsing
LilyPond expressions inside scheme (i.e., inside music functions).
Ah, tha
On 2010/06/07 13:59:45, Reinhold wrote:
The only occurrence where it might make sense to have a separate
parser is in
scm/parser-ly-from-scheme.scm in the function read-lily-expression,
which calls
parse-string-result. However, I fail to see where this is actually
used...
It's called whene
2010/6/4 :
> > Note that this description isn't correct anymore. This patch doesn't
>>
>> actually prevent those functions from segfaulting but adds a new
>> interface ly:parser-include-string. I think ly:parser-parse-string and
>> ly:parser-parse-file should actually be banned in .ly files.
>
>
> Note that this description isn't correct anymore. This patch doesn't
actually prevent those functions from segfaulting but adds a new
interface ly:parser-include-string. I think ly:parser-parse-string and
ly:parser-parse-file should actually be banned in .ly files.
If ly:parser-include-strin
Thanks, I've changed the description.
http://codereview.appspot.com/1345041/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2010/6/3 :
> Reviewers: ,
>
> Message:
> Benjamin has sent a revised patch that addresses Neil's concerns.
>
> Please review the patch.
>
> THanks,
>
> Carl
>
>
> Description:
> fix ly:parser-parse-file in an ly file
> This switches to using the flex buffer stack.
Note that this description isn't
14 matches
Mail list logo