date:20171023

Re: compiling lilypond in debian stretch with self-compiled guile-1.8

2017-10-23 Thread Federico Bruni



Il 23 ottobre 2017 19:07:19 CEST, Federico Bruni  ha 
scritto:

>Actually, I ran `sudo ldconfig`, right after building guile, in a 
>postinst script while building a debian container.
>I started the container, launched the configure in lilypond source and 
>got the usual error:
>

Stupid me, it was not a postinst script but a build script, which only copies 
the generated files.
I know what I have to do 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LaissezVibrerTie and LaissezVibrerTieColumn

2017-10-23 Thread David Kastrup

Thomas Morley  writes:

> So how to proceed with 5220?
> I'm confident I could adapt your change once it is in master

More like "use it".  I don't think you need to do anything with it.

> and maybe even prepare the engravers so that a follow up could
> implement the idea of https://codereview.appspot.com/335910043/#msg2
> easily, though I'm not able to realize this idea myself.

The main thing is listing just what the differences between the two
engravers were.  All those need to be made overridable in whatever will
serve as the base class.

> Btw, why do we redefine LaissezVibrerTie-stencil in output-lib.scm?
> The comment says:
>
> 
> ;;  laissez-vibrer tie
> ;;
> ;;  needed so we can make laissez-vibrer a pure print
> ;;
> (define-public (laissez-vibrer::print grob)
>   (ly:tie::print grob))
>
> Is this (still) true or could it be deleted (and define-grobs.scm
> adjusted, ofcourse)?

This looks like a remnant of
commit 55d4389e74f830d759176867dae44ed0400c3b68
Author: Carl Sorensen 
Date:   Fri May 14 19:51:57 2010 -0600

Fix 881, with Neil's suggestion

Make laisser-vibrez::print a pure function

Add regression test for issue 881

before

commit 74e4d219b24ec6d6f28d663c0285418e6c8e122e
Author: Mike Solomon 
Date:   Tue Mar 5 21:03:55 2013 +0100

Uses only unpure-pure containers to articulate unpure-pure relationships 
(issue 3199)

Previously, LilyPond used several different lists in define-grobs.scm
to define relationships between unpure and pure functions.  This patch
eliminates these lists, using unpure-pure containers to articulate
these relationships.

The modifications required to implement this change are described below:

-) axis-group-interface.cc
A Scheme function is no longer needed to determine pure relevant grobs.
All grobs can have their Y-extents meaningfully pure-evaluated now. The
worst-case scenario is that they evaluate to false. Dead grobs, on the
other hand, are never pure relevant. The calls to is_live are the only
holdovers from the old pure-relevant? scheme function.

-) grob-closure.cc
We allow unpure-pure containers in simple closures.

-) grob-property.cc
call_pure_function no longer looks up a Scheme module. Because there are
no hard-coded lists in Scheme any more, the function is smaller and
writing it in C++ gets slight efficiency gains.

-) grob.cc
pure_stencil_height used to be a Scheme function in define-grobs.scm.
Because it is much simpler (it no longer makes references to lists defined
in Scheme), it can be implemented in C++.

-) pure-from-neighbor-engraver.cc
Similar to axis-group-interface.cc, the pure-relevant distinction is
no longer important.

-) side-position-interface.cc
In order to avoid issues with alterBroken, we only check pure properties
before line breaking.

-) simple-closure.cc
Simple closures were incorrectly evaluated when containing unpure-pure
containers. This rectifies that.

-) stencil-integral.cc
Several pure equivalent functions needed to be written for skylines.

-) define-grobs.scm
Multiple overrides must be changed to unpure-pure containers. Previous
hard-coded lists are all deleted and several functions moved to C++ (see
above).

-) output-lib.scm
Several common unpure-pure containers used in define-grobs.scm are
defined here. Several functions from define-grobs.scm pertaining to
grob offsets are moved to this file.


So I think that at the current point of time, this can likely be
retired.  Or at least, the definition can be simplified to


;;  laissez-vibrer tie
;;
;;  Backward compatibility alias
;;
(define-public laissez-vibrer::print ly:tie::print)


-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LaissezVibrerTie and LaissezVibrerTieColumn

2017-10-23 Thread Thomas Morley

2017-10-23 15:29 GMT+02:00 David Kastrup :
> David Kastrup  writes:
>
>>> Is this appropiate?
>>
>> "cause" here is the actual tie event triggering the column.  I think
>> that it should rather be the first tie, making the
>> LaissezVibrerTieColumn a grob with ultimately identifiable cause but not
>> a directly caused grob.  Then it should be ignored by the
>> Parenthesis_engraver.  This would involve changing
>>
>>   SCM cause = tie_ev->self_scm ();
>>
>>   if (!lv_column_)
>> lv_column_ = make_item ("LaissezVibrerTieColumn", cause);
>>
>>   Grob *lv_tie = make_item ("LaissezVibrerTie", cause);
>>
>> into
>>
>>   SCM cause = tie_ev->self_scm ();
>>
>>   Grob *lv_tie = make_item ("LaissezVibrerTie", cause);
>>
>>   if (!lv_column_)
>> lv_column_ = make_item ("LaissezVibrerTieColumn", lv_tie->self_scm ());
>>
>> I don't think that it would be a problem to have the tie created before
>> its column.
>
> Tracker issue: 5222 (https://sourceforge.net/p/testlilyissues/issues/5222/)
> Rietveld issue: 331080043 (https://codereview.appspot.com/331080043)
> Issue description:
>   Stop \parenthesize\laissezVibrer causing programming errors
>
> I don't think I'd have an issue with fast-tracking this one once it
> passed the regtests.
>
> --
> David Kastrup

So how to proceed with 5220?
I'm confident I could adapt your change once it is in master and maybe
even prepare the engravers so that a follow up could implement the
idea of
https://codereview.appspot.com/335910043/#msg2
easily, though I'm not able to realize this idea myself.


Btw, why do we redefine LaissezVibrerTie-stencil in output-lib.scm?
The comment says:


;;  laissez-vibrer tie
;;
;;  needed so we can make laissez-vibrer a pure print
;;
(define-public (laissez-vibrer::print grob)
  (ly:tie::print grob))

Is this (still) true or could it be deleted (and define-grobs.scm
adjusted, ofcourse)?


Cheers,
  Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: compiling lilypond in debian stretch with self-compiled guile-1.8

2017-10-23 Thread Federico Bruni




Il giorno lun 23 ott 2017 alle 18:34, Federico Bruni 
 ha scritto:



Il giorno ven 20 ott 2017 alle 21:52, David Kastrup  ha 
scritto:

Federico Bruni  writes:


 I have my own Guile 1.8 libraries.  I use something like

 GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config 
./configure

 ...

 I got the same problem.  However, this appears to be because 
avoiding
 the check for guile-config in this manner appears to _also_ 
disable

 the
 check (and any useful default) for Guile.  So I have to do

 GUILE=/usr/bin/guile GUILE_CONFIG=... ./configure ...

 to get this working smoothly.  /usr/bin/guile happens to be a
 Guile-2.0
 provided by Ubuntu.  It's fine since it is used for the scripts 
which

 run ok under Guile-2.0.




 This did not help, unfortunately. I keep getting the same error.

 Now I've removed guile-2.0.
 I've built and installed guile-1.8 in /usr/local. /usr/local/bin 
is

 in my path.

 But I get this error:

 checking for guile-config... no


If your configure script is _checking_ for guile-config, you don't 
have

GUILE_CONFIG set.



Ok, I thought that it was not necessary as I have now, after removing 
guile-2, only one guile-config in my PATH.
I found out that there's another requirement needed: running ldconfig 
after guile-1.8 installation.




Actually, I ran `sudo ldconfig`, right after building guile, in a 
postinst script while building a debian container.
I started the container, launched the configure in lilypond source and 
got the usual error:


checking guile compile flags... /usr/local/bin/guile: error while 
loading shared libraries: libguile.so.17: cannot open shared object 
file: No such file or directory


So I ran `sudo ldconfig` and then the configure, which was now 
successful.

Do you know why?

For the records, these are the commands that worked well to build and 
install guile-1.8 system wide on debian stretch:


git clone https://git.savannah.gnu.org/git/guile.git
cd guile
git checkout branch_release-1-8
./autogen.sh
./configure --disable-error-on-warning --prefix=/usr/local
make
sudo make install
sudo ldconfig

echo "GUILE_CONFIG=/usr/local/bin/guile-config" >> ~/.bashrc




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: compiling lilypond in debian stretch with self-compiled guile-1.8

2017-10-23 Thread Federico Bruni




Il giorno ven 20 ott 2017 alle 21:52, David Kastrup  ha 
scritto:

Federico Bruni  writes:


 I have my own Guile 1.8 libraries.  I use something like

 GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config ./configure
 ...

 I got the same problem.  However, this appears to be because 
avoiding
 the check for guile-config in this manner appears to _also_ 
disable

 the
 check (and any useful default) for Guile.  So I have to do

 GUILE=/usr/bin/guile GUILE_CONFIG=... ./configure ...

 to get this working smoothly.  /usr/bin/guile happens to be a
 Guile-2.0
 provided by Ubuntu.  It's fine since it is used for the scripts 
which

 run ok under Guile-2.0.




 This did not help, unfortunately. I keep getting the same error.

 Now I've removed guile-2.0.
 I've built and installed guile-1.8 in /usr/local. /usr/local/bin is
 in my path.

 But I get this error:

 checking for guile-config... no


If your configure script is _checking_ for guile-config, you don't 
have

GUILE_CONFIG set.



Ok, I thought that it was not necessary as I have now, after removing 
guile-2, only one guile-config in my PATH.
I found out that there's another requirement needed: running ldconfig 
after guile-1.8 installation.


For the records, these are the commands that worked well to build and 
install guile-1.8 system wide on debian stretch:


git clone https://git.savannah.gnu.org/git/guile.git
cd guile
git checkout branch_release-1-8
./autogen.sh
./configure --disable-error-on-warning --prefix=/usr/local
make
sudo make install
sudo ldconfig

echo "GUILE_CONFIG=/usr/local/bin/guile-config" >> ~/.bashrc




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCHES - Countdown for October 20th

2017-10-23 Thread James Lowe

Hello,

Here is the current patch countdown list. The next countdown will be on
October 23rd.

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/



Push:

4981 Web: Remove links to gmane throughout Website - James Lowe
https://sourceforge.net/p/testlilyissues/issues/4981
http://codereview.appspot.com/333900043


Countdown:

4927 Performance of 2.17.6 convert-ly rule - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/4927
http://codereview.appspot.com/330620043


Review: No patches in Review at this time.


New: No new patches at this time.


Waiting:

4603 change all occurences of ‘partcombine’ to ‘partCombine’. - James Lowe
https://sourceforge.net/p/testlilyissues/issues/4603
http://codereview.appspot.com/323040043


Regards

James   Hello,
   Here is the current patch countdown list. The next countdown will be on
   October 2nd.
   A quick synopsis of all patches currently in the review process can be
   found here:
   http://philholmes.net/lilypond/allura/
   
   Push:
   5203 Don't let event-chord-reduce bomb on empty chords - David Kastrup
   https://sourceforge.net/p/testlilyissues/issues/5203
   http://codereview.appspot.com/327480043
   5202 Add regtest for issue 5181 - David Kastrup
   https://sourceforge.net/p/testlilyissues/issues/5202
   http://codereview.appspot.com/327470043
   5198 Add command for Thin Aiken noteheads - Karlin High
   https://sourceforge.net/p/testlilyissues/issues/5198
   http://codereview.appspot.com/326510043
   5190 NR: Update Clef styles Appendix - James Lowe
   https://sourceforge.net/p/testlilyissues/issues/5190
   http://codereview.appspot.com/324420043
   5176 2.20 - re-organize Changes.tely into Topics - James Lowe
   https://sourceforge.net/p/testlilyissues/issues/5176
   http://codereview.appspot.com/326400043

   Countdown:
   5200 display-lily-tests.ly: Remove unused lily-string->markup - David
   Kastrup
   https://sourceforge.net/p/testlilyissues/issues/5200
   http://codereview.appspot.com/324490043

   5201 Use -b together with -dgs-never-embed-fonts - Knut Petersen
   https://sourceforge.net/p/testlilyissues/issues/5201
   http://codereview.appspot.com/325630043

   Review:
   5205 \chordmode { c:sus } should be , not - David Kastrup
   https://sourceforge.net/p/testlilyissues/issues/5205
   http://codereview.appspot.com/326610043
   5204 Remove white-space from storePredefinedDiagram input-string -
   Thomas Morley
   https://sourceforge.net/p/testlilyissues/issues/5204
   http://codereview.appspot.com/330340043
   New:

   No new patches at this time.

   Waiting:
   4603 change all occurences of âpartcombineâ to âpartCombineâ. - James
   Lowe
   https://sourceforge.net/p/testlilyissues/issues/4603
   http://codereview.appspot.com/323040043


   Regards

   James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LaissezVibrerTie and LaissezVibrerTieColumn

2017-10-23 Thread David Kastrup

David Kastrup  writes:

>> Is this appropiate?
>
> "cause" here is the actual tie event triggering the column.  I think
> that it should rather be the first tie, making the
> LaissezVibrerTieColumn a grob with ultimately identifiable cause but not
> a directly caused grob.  Then it should be ignored by the
> Parenthesis_engraver.  This would involve changing
>
>   SCM cause = tie_ev->self_scm ();
>
>   if (!lv_column_)
> lv_column_ = make_item ("LaissezVibrerTieColumn", cause);
>
>   Grob *lv_tie = make_item ("LaissezVibrerTie", cause);
>
> into
>
>   SCM cause = tie_ev->self_scm ();
>
>   Grob *lv_tie = make_item ("LaissezVibrerTie", cause);
>
>   if (!lv_column_)
> lv_column_ = make_item ("LaissezVibrerTieColumn", lv_tie->self_scm ());
>
> I don't think that it would be a problem to have the tie created before
> its column.

Tracker issue: 5222 (https://sourceforge.net/p/testlilyissues/issues/5222/)
Rietveld issue: 331080043 (https://codereview.appspot.com/331080043)
Issue description:
  Stop \parenthesize\laissezVibrer causing programming errors

I don't think I'd have an issue with fast-tracking this one once it
passed the regtests.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LaissezVibrerTie and LaissezVibrerTieColumn

2017-10-23 Thread David Kastrup

Thomas Morley  writes:

> Hi all,
>
> here:
> https://sourceforge.net/p/testlilyissues/issues/5220/#f5aa/ed76
> I wrote that \parenthesize\laissezVibrer does not work because
> LilyPond tries to parenthesize LaissezVibrerTieColumn as well.
>
> And indeed, with the code below _two_ grobs are affected:
> LaissezVibrerTieColumn and LaissezVibrerTie
>
> {
>   c'1
>  -\tweak after-line-breaking #(lambda (grob) (write grob))
>  -\laissezVibrer
> }
>
> This looks fishy.
> While the proposed check for interval-sane? at the tracker may be a
> good thing at its own, I found changing laissez-vibrer-engraver.cc
>
> -  if (!lv_column_)
> -lv_column_ = make_item ("LaissezVibrerTieColumn", cause);
>
> +  if (!lv_column_)
> +{
> +  lv_column_ = make_item ("LaissezVibrerTieColumn", SCM_EOL);
> +}
>
> seems to cure it.
> Though, I'm hardly knowing what I'm doing here...
>
> Is this appropiate?

"cause" here is the actual tie event triggering the column.  I think
that it should rather be the first tie, making the
LaissezVibrerTieColumn a grob with ultimately identifiable cause but not
a directly caused grob.  Then it should be ignored by the
Parenthesis_engraver.  This would involve changing

  SCM cause = tie_ev->self_scm ();

  if (!lv_column_)
lv_column_ = make_item ("LaissezVibrerTieColumn", cause);

  Grob *lv_tie = make_item ("LaissezVibrerTie", cause);

into

  SCM cause = tie_ev->self_scm ();

  Grob *lv_tie = make_item ("LaissezVibrerTie", cause);

  if (!lv_column_)
lv_column_ = make_item ("LaissezVibrerTieColumn", lv_tie->self_scm ());

I don't think that it would be a problem to have the tie created before
its column.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

LaissezVibrerTie and LaissezVibrerTieColumn

2017-10-23 Thread Thomas Morley

Hi all,

here:
https://sourceforge.net/p/testlilyissues/issues/5220/#f5aa/ed76
I wrote that \parenthesize\laissezVibrer does not work because
LilyPond tries to parenthesize LaissezVibrerTieColumn as well.

And indeed, with the code below _two_ grobs are affected:
LaissezVibrerTieColumn and LaissezVibrerTie

{
  c'1
 -\tweak after-line-breaking #(lambda (grob) (write grob))
 -\laissezVibrer
}

This looks fishy.
While the proposed check for interval-sane? at the tracker may be a
good thing at its own, I found changing laissez-vibrer-engraver.cc

-  if (!lv_column_)
-lv_column_ = make_item ("LaissezVibrerTieColumn", cause);

+  if (!lv_column_)
+{
+  lv_column_ = make_item ("LaissezVibrerTieColumn", SCM_EOL);
+}

seems to cure it.
Though, I'm hardly knowing what I'm doing here...

Is this appropiate?

Cheers,
  Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: compiling lilypond in debian stretch with self-compiled guile-1.8

Re: LaissezVibrerTie and LaissezVibrerTieColumn

Re: LaissezVibrerTie and LaissezVibrerTieColumn

Re: compiling lilypond in debian stretch with self-compiled guile-1.8

Re: compiling lilypond in debian stretch with self-compiled guile-1.8

PATCHES - Countdown for October 20th

Re: LaissezVibrerTie and LaissezVibrerTieColumn

Re: LaissezVibrerTie and LaissezVibrerTieColumn

LaissezVibrerTie and LaissezVibrerTieColumn

9 matches

Site Navigation

Mail list logo

Footer information