Changed behaviour of 'split-at' with guilev2

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Changed behaviour of 'split-at' with guilev2

Thomas Morley-2
Hi,

I stumbled across different behaviour of 'split-at' in guilev1/2. Doing
(define (foo) (write (split-at '(1 2 3) 1)))
(foo)
returns
in guilev1
#<values ((1) (2 3))>
in guilev2 only
(1)

In guilev2 one could do one of the below codings
(define (buzz)
   (call-with-values
     (lambda () (split-at '(1 2 3) 1))
     list))
(use-modules (srfi srfi-11))
(define (buzz-II)
  (let-values (((x y) (split-at '(1 2 3) 1)))
    (list x y)))

Actually we use split-at two times in our source
(1) In 'split-at-predicate' from lily-library.scm
There the method using call-with-values is already in work.
(2) In 'insert-lyrics*!' from song.scm
This should probably be fixed as well. Or is it already?
I don't understand what's it's all about there. Ok, we have some
regtests about this (and the derived 'festival'), so I my educated
guess would be: it has to do with xml...
But there is _no_ documentation at all, as far as I can tell.
I'm at a loss with this :(

Cheers,
  Harm

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of 'split-at' with guilev2

David Kastrup
Thomas Morley <[hidden email]> writes:

> Hi,
>
> I stumbled across different behaviour of 'split-at' in guilev1/2. Doing
> (define (foo) (write (split-at '(1 2 3) 1)))
> (foo)
> returns
> in guilev1
> #<values ((1) (2 3))>
> in guilev2 only
> (1)

I rather think that Guilev2 just deals a bit differently with multiple
values, dropping additional values in scheme-only contexts with
single-value takers like `write'.

> (define (buzz-II)
>   (let-values (((x y) (split-at '(1 2 3) 1)))
>     (list x y)))
>
> Actually we use split-at two times in our source
> (1) In 'split-at-predicate' from lily-library.scm
> There the method using call-with-values is already in work.
> (2) In 'insert-lyrics*!' from song.scm
> This should probably be fixed as well. Or is it already?

It uses receive, which uses call-with-values.

> I don't understand what's it's all about there. Ok, we have some
> regtests about this (and the derived 'festival'), so I my educated
> guess would be: it has to do with xml...
> But there is _no_ documentation at all, as far as I can tell.
> I'm at a loss with this :(

I vaguely seem to remember that it was stuff in/for the toolbox of a
user with impaired sight, but I haven't really the foggiest in what
respect.  Maybe it was for having a speech synthesizer sing lyrics from
a score?  I'd imagine this to be of slightly appalling appeal.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of 'split-at' with guilev2

Thomas Morley-2
Am So., 14. Okt. 2018 um 11:56 Uhr schrieb David Kastrup <[hidden email]>:

>
> Thomas Morley <[hidden email]> writes:
>
> > Hi,
> >
> > I stumbled across different behaviour of 'split-at' in guilev1/2. Doing
> > (define (foo) (write (split-at '(1 2 3) 1)))
> > (foo)
> > returns
> > in guilev1
> > #<values ((1) (2 3))>
> > in guilev2 only
> > (1)
>
> I rather think that Guilev2 just deals a bit differently with multiple
> values, dropping additional values in scheme-only contexts with
> single-value takers like `write'.

It bombed out one of my codings, before I found the culprit.

>
> > (define (buzz-II)
> >   (let-values (((x y) (split-at '(1 2 3) 1)))
> >     (list x y)))
> >
> > Actually we use split-at two times in our source
> > (1) In 'split-at-predicate' from lily-library.scm
> > There the method using call-with-values is already in work.
> > (2) In 'insert-lyrics*!' from song.scm
> > This should probably be fixed as well. Or is it already?
>
> It uses receive, which uses call-with-values.

Good to know.

> > I don't understand what's it's all about there. Ok, we have some
> > regtests about this (and the derived 'festival'), so I my educated
> > guess would be: it has to do with xml...
> > But there is _no_ documentation at all, as far as I can tell.
> > I'm at a loss with this :(
>
> I vaguely seem to remember that it was stuff in/for the toolbox of a
> user with impaired sight, but I haven't really the foggiest in what
> respect.  Maybe it was for having a speech synthesizer sing lyrics from
> a score?  I'd imagine this to be of slightly appalling appeal.

Well, can't judge about it without diving deep into it, for which I
currently neither have the time nor the energy or motivation.
Needless to say, without any docs probably nobody will ever notice or
even improve this coding unless it breaks.

Thanks,
  Harm

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of 'split-at' with guilev2

James Lowe-3
hello


On 14/10/18 11:11, Thomas Morley wrote:

> Am So., 14. Okt. 2018 um 11:56 Uhr schrieb David Kastrup <[hidden email]>:
>> Thomas Morley <[hidden email]> writes:
>>
>>
>>> I don't understand what's it's all about there. Ok, we have some
>>> regtests about this (and the derived 'festival'), so I my educated
>>> guess would be: it has to do with xml...
>>> But there is _no_ documentation at all, as far as I can tell.
>>> I'm at a loss with this :(
>> I vaguely seem to remember that it was stuff in/for the toolbox of a
>> user with impaired sight, but I haven't really the foggiest in what
>> respect.  Maybe it was for having a speech synthesizer sing lyrics from
>> a score?  I'd imagine this to be of slightly appalling appeal.
> Well, can't judge about it without diving deep into it, for which I
> currently neither have the time nor the energy or motivation.
> Needless to say, without any docs probably nobody will ever notice or
> even improve this coding unless it breaks.
>
> Thanks,
>    Harm
Perhaps see: https://sourceforge.net/p/testlilyissues/issues/1245/

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=d0c106f0391e64451d41db3ed11d1aa27afebbbb
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=1ff8a0cde0e4c604941be4354fe09c0be96e482e
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=a61dccceef1804b6ef2c616b8b04a53446e5d80f

?

James

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of 'split-at' with guilev2

David Kastrup
In reply to this post by Thomas Morley-2
Thomas Morley <[hidden email]> writes:

> Am So., 14. Okt. 2018 um 11:56 Uhr schrieb David Kastrup <[hidden email]>:
>>
>> Thomas Morley <[hidden email]> writes:
>>
>> > Hi,
>> >
>> > I stumbled across different behaviour of 'split-at' in guilev1/2. Doing
>> > (define (foo) (write (split-at '(1 2 3) 1)))
>> > (foo)
>> > returns
>> > in guilev1
>> > #<values ((1) (2 3))>
>> > in guilev2 only
>> > (1)
>>
>> I rather think that Guilev2 just deals a bit differently with multiple
>> values, dropping additional values in scheme-only contexts with
>> single-value takers like `write'.
>
> It bombed out one of my codings, before I found the culprit.

You cannot generally _store_ multiple-value objects in Guilev2 (or
actually Scheme proper) since they are not conceptually proper objects
(C++ programmers will be reminded of references as opposed to pointers).
Basically you can only return them, and functions calling a
multiple-value returning function as the last thing they do will return
the same multiple values.

The only thing guaranteed to do anything with multiple values is
call-with-values and stuff derived from it.

The documentation states:

 -- Scheme Procedure: values arg ...
 -- C Function: scm_values (args)
     Delivers all of its arguments to its continuation.  Except for
     continuations created by the ‘call-with-values’ procedure, all
     continuations take exactly one value.  The effect of passing no
     value or more than one value to continuations that were not created
     by ‘call-with-values’ is unspecified.

     For ‘scm_values’, ARGS is a list of arguments and the return is a
     multiple-values object which the caller can return.  In the current
     implementation that object shares structure with ARGS, so ARGS
     should not be modified subsequently.

and indeed R5RS states the possible implementation of values as

(define (values . things)
  (call-with-current-continuation
    (lambda (cont) (apply cont things))))

Of course, this still requires call-with-values itself for creating a
continuation taking multiple values.  Note that the standard as well as
Guile's documentation itself states

     The effect of passing no value or more than one value to
     continuations that were not created by ‘call-with-values’ is
     unspecified.

and the Guilev1 behavior was to create a multiple-values object while
the Guilev2 behavior is to drop extra values unless the continuation is
a C API call, in which a multiple-values object does get passed.

If this is giving you a headache, rest assured that it is giving
_everyone_ a headache.

--
David Kastrup

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of 'split-at' with guilev2

Thomas Morley-2
In reply to this post by James Lowe-3
Am So., 14. Okt. 2018 um 12:22 Uhr schrieb James Lowe <[hidden email]>:

>
> hello
>
>
> On 14/10/18 11:11, Thomas Morley wrote:
> > Am So., 14. Okt. 2018 um 11:56 Uhr schrieb David Kastrup <[hidden email]>:
> >> Thomas Morley <[hidden email]> writes:
> >>
> >>
> >>> I don't understand what's it's all about there. Ok, we have some
> >>> regtests about this (and the derived 'festival'), so I my educated
> >>> guess would be: it has to do with xml...
> >>> But there is _no_ documentation at all, as far as I can tell.
> >>> I'm at a loss with this :(
> >> I vaguely seem to remember that it was stuff in/for the toolbox of a
> >> user with impaired sight, but I haven't really the foggiest in what
> >> respect.  Maybe it was for having a speech synthesizer sing lyrics from
> >> a score?  I'd imagine this to be of slightly appalling appeal.
> > Well, can't judge about it without diving deep into it, for which I
> > currently neither have the time nor the energy or motivation.
> > Needless to say, without any docs probably nobody will ever notice or
> > even improve this coding unless it breaks.
> >
> > Thanks,
> >    Harm

Hi James,

> Perhaps see: https://sourceforge.net/p/testlilyissues/issues/1245/
>
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=d0c106f0391e64451d41db3ed11d1aa27afebbbb
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=1ff8a0cde0e4c604941be4354fe09c0be96e482e
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=a61dccceef1804b6ef2c616b8b04a53446e5d80f
>
> ?
>
> James

thanks for the links.
Good to know we have a tracker-issue for it.
Regrettable some of the links provided there or in the attached pdfs are broken.

Obviously you already had put up some work for this issue.
Not clear to me if you, Graham or somebody else ever got it to work?

Thanks,
  Harm

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of 'split-at' with guilev2

Thomas Morley-2
In reply to this post by David Kastrup
Am So., 14. Okt. 2018 um 12:31 Uhr schrieb David Kastrup <[hidden email]>:

>
> Thomas Morley <[hidden email]> writes:
>
> > Am So., 14. Okt. 2018 um 11:56 Uhr schrieb David Kastrup <[hidden email]>:
> >>
> >> Thomas Morley <[hidden email]> writes:
> >>
> >> > Hi,
> >> >
> >> > I stumbled across different behaviour of 'split-at' in guilev1/2. Doing
> >> > (define (foo) (write (split-at '(1 2 3) 1)))
> >> > (foo)
> >> > returns
> >> > in guilev1
> >> > #<values ((1) (2 3))>
> >> > in guilev2 only
> >> > (1)
> >>
> >> I rather think that Guilev2 just deals a bit differently with multiple
> >> values, dropping additional values in scheme-only contexts with
> >> single-value takers like `write'.
> >
> > It bombed out one of my codings, before I found the culprit.
>
> You cannot generally _store_ multiple-value objects in Guilev2 (or
> actually Scheme proper) since they are not conceptually proper objects
> (C++ programmers will be reminded of references as opposed to pointers).
> Basically you can only return them, and functions calling a
> multiple-value returning function as the last thing they do will return
> the same multiple values.
>
> The only thing guaranteed to do anything with multiple values is
> call-with-values and stuff derived from it.
>
> The documentation states:
>
>  -- Scheme Procedure: values arg ...
>  -- C Function: scm_values (args)
>      Delivers all of its arguments to its continuation.  Except for
>      continuations created by the ‘call-with-values’ procedure, all
>      continuations take exactly one value.  The effect of passing no
>      value or more than one value to continuations that were not created
>      by ‘call-with-values’ is unspecified.
>
>      For ‘scm_values’, ARGS is a list of arguments and the return is a
>      multiple-values object which the caller can return.  In the current
>      implementation that object shares structure with ARGS, so ARGS
>      should not be modified subsequently.
>
> and indeed R5RS states the possible implementation of values as
>
> (define (values . things)
>   (call-with-current-continuation
>     (lambda (cont) (apply cont things))))
>
> Of course, this still requires call-with-values itself for creating a
> continuation taking multiple values.  Note that the standard as well as
> Guile's documentation itself states
>
>      The effect of passing no value or more than one value to
>      continuations that were not created by ‘call-with-values’ is
>      unspecified.
>
> and the Guilev1 behavior was to create a multiple-values object while
> the Guilev2 behavior is to drop extra values unless the continuation is
> a C API call, in which a multiple-values object does get passed.
>
> If this is giving you a headache, rest assured that it is giving
> _everyone_ a headache.
>
> --
> David Kastrup

Indeed, if I wouldn't have a headache already ...

Nevertheless, good to know that using ‘call-with-values’ will work for
guilev1 and guilev2

Thanks,
  Harm

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of 'split-at' with guilev2

James Lowe-3
In reply to this post by Thomas Morley-2


On 14/10/18 13:41, Thomas Morley wrote:

>
> Hi James,
>
>> Perhaps see: https://sourceforge.net/p/testlilyissues/issues/1245/
>>
>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=d0c106f0391e64451d41db3ed11d1aa27afebbbb
>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=1ff8a0cde0e4c604941be4354fe09c0be96e482e
>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=a61dccceef1804b6ef2c616b8b04a53446e5d80f
>>
>> ?
>>
>> James
> thanks for the links.
> Good to know we have a tracker-issue for it.
> Regrettable some of the links provided there or in the attached pdfs are broken.
>
> Obviously you already had put up some work for this issue.
> Not clear to me if you, Graham or somebody else ever got it to work?
>
> Thanks,
>    Harm
>
I also put up the commit links in case that was where whatever code
additions you were discussing with David were made (the Tracker link was
actually added as 'by the by').

In case you wanted to remove the code to get whatever you needed here
working.

As to if I ever got it to work; the answer is no - I had only just
started helping with LP and Graham was mentoring me, and while looking
for things for me to do, he asked me to follow up with the original
submitter.

That's all.

James



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel