Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Thomas Morley]

2016-01-16 21:40 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> 2016-01-12 0:22 GMT+01:00 David Kastrup :
>>> Thomas Morley  writes:
>>>
 2016-01-11 23:14 GMT+01:00 David Kastrup :

>> Btw, it wasn't entirely clear to me that guilev2.x changes essential
>> stuff that often.
>> Exactly which guile-version are we aiming for?
>
> The non-existing 2.0.12.  Currently, the stable-2.0 branch.  The main
> challenge currently seems to be compiling LilyPond with a Guile version
> that is not installed on your system.

 To be sure, the exercise is:

 (1) checkout the marked branch

 ~/guile (master)$ git branch -a
 * master
>>> [...]
   remotes/origin/stable-2.0
 ^^
>>> [...]
>>>
 (2) Compile it
 (3) Build LilyPond with this guile somehow

 Correct?
>>>
>>> It's the basis for making more tangible progress. [...]
>>
>> I've now checked out branch origin/stable-2.0, derived a local branch
>> and compiled it.
>>
>> ~/guile/meta (my-stable-2.0)$ ./guile
>> GNU Guile 2.0.11.170-4d08e
>> [...]
>>
>> Should be the version we aim at.
>>
>> Though, how to compile LilyPond with this guile-version?
>> Which commands do you actually use for it?
>
> That question is easy to answer: I never built with anything but the
> Ubuntu Guile versions.  So this would appear to be of the "look at what
> options "./configure --help" offers for this" kind.  And if it's silent
> about that, see what kind of environment variables might be interpreted.
>
> I mean, Gub has to do the same here: build its own library version and
> use/link it.  So there must be a way.
>
> --
> David Kastrup

"./configure --help" offers some options, eg.
--with-python-include=DIR
--with-python-lib=NAME
but nothing directly for guile.

There are several environment variables like
CFLAGS
but I don't know how to use them or the syntax they expect.

Full output of "./configure --help" attached.

I really hope someone can demonstrate how to point configure to a
self-compiled guile.


Cheers,
  Harm
`configure' configures this package to adapt to many kinds of systems.

Usage: ../configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help  display this help and exit
  --help=shortdisplay options specific to this package
  --help=recursivedisplay the short help of all the included packages
  -V, --version   display version information and exit
  -q, --quiet, --silent   do not print `checking ...' messages
  --cache-file=FILE   cache test results in FILE [disabled]
  -C, --config-cache  alias for `--cache-file=config.cache'
  -n, --no-create do not create output files
  --srcdir=DIRfind the sources in DIR [configure dir or `..']

Installation directories:
  --prefix=PREFIX install architecture-independent files in PREFIX
  [/usr/local]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
  [PREFIX]

By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIRuser executables [EPREFIX/bin]
  --sbindir=DIR   system admin executables [EPREFIX/sbin]
  --libexecdir=DIRprogram executables [EPREFIX/libexec]
  --sysconfdir=DIRread-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
  --localstatedir=DIR modifiable single-machine data [PREFIX/var]
  --libdir=DIRobject code libraries [EPREFIX/lib]
  --includedir=DIRC header files [PREFIX/include]
  --oldincludedir=DIR C header files for non-gcc [/usr/include]
  --datarootdir=DIR   read-only arch.-independent data root [PREFIX/share]
  --datadir=DIR   read-only architecture-independent data [DATAROOTDIR]
  --infodir=DIR   info documentation [DATAROOTDIR/info]
  --localedir=DIR locale-dependent data [DATAROOTDIR/locale]
  --mandir=DIRman documentation [DATAROOTDIR/man]
  --docdir=DIRdocumentation root [DATAROOTDIR/doc/PACKAGE]
  --htmldir=DIR   html documentation [DOCDIR]
  --dvidir=DIRdvi documentation [DOCDIR]
  --pdfdir=DIRpdf documentation [DOCDIR]
  --psdir=DIR ps documentation [DOCDIR]

System types:
  --build=BUILD configure for building on BUILD [guessed]
  --host=HOST   cross-compile to build 

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[David Kastrup]

Thomas Morley  writes:

> 2016-01-12 0:22 GMT+01:00 David Kastrup :
>> Thomas Morley  writes:
>>
>>> 2016-01-11 23:14 GMT+01:00 David Kastrup :
>>>
> Btw, it wasn't entirely clear to me that guilev2.x changes essential
> stuff that often.
> Exactly which guile-version are we aiming for?

 The non-existing 2.0.12.  Currently, the stable-2.0 branch.  The main
 challenge currently seems to be compiling LilyPond with a Guile version
 that is not installed on your system.
>>>
>>> To be sure, the exercise is:
>>>
>>> (1) checkout the marked branch
>>>
>>> ~/guile (master)$ git branch -a
>>> * master
>> [...]
>>>   remotes/origin/stable-2.0
>>> ^^
>> [...]
>>
>>> (2) Compile it
>>> (3) Build LilyPond with this guile somehow
>>>
>>> Correct?
>>
>> It's the basis for making more tangible progress. [...]
>
> I've now checked out branch origin/stable-2.0, derived a local branch
> and compiled it.
>
> ~/guile/meta (my-stable-2.0)$ ./guile
> GNU Guile 2.0.11.170-4d08e
> [...]
>
> Should be the version we aim at.
>
> Though, how to compile LilyPond with this guile-version?
> Which commands do you actually use for it?

That question is easy to answer: I never built with anything but the
Ubuntu Guile versions.  So this would appear to be of the "look at what
options "./configure --help" offers for this" kind.  And if it's silent
about that, see what kind of environment variables might be interpreted.

I mean, Gub has to do the same here: build its own library version and
use/link it.  So there must be a way.

-- 
David Kastrup

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Thomas Morley]

2016-01-12 0:22 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> 2016-01-11 23:14 GMT+01:00 David Kastrup :
>>
 Btw, it wasn't entirely clear to me that guilev2.x changes essential
 stuff that often.
 Exactly which guile-version are we aiming for?
>>>
>>> The non-existing 2.0.12.  Currently, the stable-2.0 branch.  The main
>>> challenge currently seems to be compiling LilyPond with a Guile version
>>> that is not installed on your system.
>>
>> To be sure, the exercise is:
>>
>> (1) checkout the marked branch
>>
>> ~/guile (master)$ git branch -a
>> * master
> [...]
>>   remotes/origin/stable-2.0
>> ^^
> [...]
>
>> (2) Compile it
>> (3) Build LilyPond with this guile somehow
>>
>> Correct?
>
> It's the basis for making more tangible progress. [...]

I've now checked out branch origin/stable-2.0, derived a local branch
and compiled it.

~/guile/meta (my-stable-2.0)$ ./guile
GNU Guile 2.0.11.170-4d08e
[...]

Should be the version we aim at.

Though, how to compile LilyPond with this guile-version?
Which commands do you actually use for it?

Cheers,
  Harm

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Thomas Morley]

2016-01-11 23:14 GMT+01:00 David Kastrup :

>> Btw, it wasn't entirely clear to me that guilev2.x changes essential
>> stuff that often.
>> Exactly which guile-version are we aiming for?
>
> The non-existing 2.0.12.  Currently, the stable-2.0 branch.  The main
> challenge currently seems to be compiling LilyPond with a Guile version
> that is not installed on your system.
>
> --
> David Kastrup

To be sure, the exercise is:

(1) checkout the marked branch

~/guile (master)$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/branch_release-1-4
  remotes/origin/branch_release-1-6
  remotes/origin/branch_release-1-8
  remotes/origin/cky-hygienic-macros
  remotes/origin/historical/wip-1-8-mingw-build
  remotes/origin/lloda-array-cleanup
  remotes/origin/lloda-array-support
  remotes/origin/lua
  remotes/origin/master
  remotes/origin/nan-boxing
  remotes/origin/r7rs-wip
  remotes/origin/stable-2.0
^^
  remotes/origin/ttn-back-in-the-saddle
  remotes/origin/wip-bpt-elisp
  remotes/origin/wip-closure-conversion
  remotes/origin/wip-compiler
  remotes/origin/wip-cps-bis
  remotes/origin/wip-dwarf
  remotes/origin/wip-ethreads
  remotes/origin/wip-finalizers
  remotes/origin/wip-generalized-vectors
  remotes/origin/wip-goops-refactor
  remotes/origin/wip-nj-locks-nc
  remotes/origin/wip-nj-thread-safety
  remotes/origin/wip-raeburn-misc
  remotes/origin/wip-retagging
  remotes/origin/wip-rtl-cps
  remotes/origin/wip-rtl-dwarf
  remotes/origin/wip-rtl-halloween
  remotes/origin/wip-rtl-may-2013
  remotes/origin/wip-rtl-prompts
  remotes/origin/wip-sassy
  remotes/origin/wip-source-info
  remotes/origin/wip-stime
  remotes/origin/wip-streams
  remotes/origin/wip-threaded-http-server
  remotes/origin/wip-threads-and-fork
  remotes/origin/wip-uri-reference
  remotes/origin/wip-utf16-debugging

(2) Compile it
(3) Build LilyPond with this guile somehow

Correct?
  Harm

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[David Kastrup]

David Kastrup  writes:

> Thomas Morley  writes:
>
>> 2016-01-11 23:14 GMT+01:00 David Kastrup :
>>
 Btw, it wasn't entirely clear to me that guilev2.x changes essential
 stuff that often.
 Exactly which guile-version are we aiming for?
>>>
>>> The non-existing 2.0.12.  Currently, the stable-2.0 branch.  The main
>>> challenge currently seems to be compiling LilyPond with a Guile version
>>> that is not installed on your system.
>>
>> To be sure, the exercise is:
>>
>> (1) checkout the marked branch
>>
>> ~/guile (master)$ git branch -a
>> * master
> [...]
>>   remotes/origin/stable-2.0
>> ^^
> [...]
>
>> (2) Compile it
>> (3) Build LilyPond with this guile somehow
>>
>> Correct?
>
> It's the basis for making more tangible progress.  You can, of course,
> try finding yet another route around all the problems ailing 2.0.11, but
> it's unlikely to continue working in 2.1.

By the way: stable-2.0 is the branch where general development happens.
If you take a look at the commits in master (2.1 development) that
weren't cherry-picks from stable-2.0, the statistics look like:

dak@lola:/usr/local/tmp/guile$ git shortlog -n -s --cherry --since "6 months 
ago" origin/stable-2.0...origin
   163  Andy Wingo
 2  Mark H Weaver
dak@lola:/usr/local/tmp/guile$ 

2.1 is Andy Wingo's playground.  If you take a look at the Guile
developer list, you'll notice that he does not bother discussing
_anything_ he is doing there.  Sometimes he tells a bit of what he's
doing on his personal blog.

Consequently, all non-compiler and all publicly discussed work is done
in the "stable-2.0" branch.  And that's the one we have to target.

-- 
David Kastrup

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Thomas Morley]

2016-01-10 21:26 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
>> 3. We have a branch
>> remotes/origin/dev/guilev2
>> Makes sense to checkout it?
>> (It should, ofcourse, I'll test tomorrow)
>
> I've rebased it now, basically chucking one superseded commit.  It now
> contains two commits that likely don't hurt, but I am also skeptical
> that either will help.  Both concern trouble when loading utf-8 files.
>
> So you can git fetch again and then give origin/dev/guilev2 another try

Hmm, no success for make. In LilyDev I did whats listed below
(nonrelating stuff deleted). Did I something wrong?

[build (dev/my-guilev2)]$ history 20
   53  cd lilypond-git/
   54  git fetch
   55  git branch -a
   56  git checkout origin/dev/guilev2

   60  git branch dev/my-guilev2
   61  git checkout dev/my-guilev2

   67  ./autogen.sh --noconfigure
   68  mkdir build/
   69  cd build/
   70  ../configure --enable-guile2
   71  make -j3

I've got:
[...]
/home/harm/lilypond-git/stepmake/stepmake/c++-rules.make:4: recipe for
target 'out/source-file.o' failed
make[1]: *** [out/source-file.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/home/harm/lilypond-git/build/lily'


Btw, it wasn't entirely clear to me that guilev2.x changes essential
stuff that often.
Exactly which guile-version are we aiming for?

Cheers,
  Harm

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[David Kastrup]

Thomas Morley  writes:

> 2016-01-10 21:26 GMT+01:00 David Kastrup :
>> Thomas Morley  writes:
>>
>>> 3. We have a branch
>>> remotes/origin/dev/guilev2
>>> Makes sense to checkout it?
>>> (It should, ofcourse, I'll test tomorrow)
>>
>> I've rebased it now, basically chucking one superseded commit.  It now
>> contains two commits that likely don't hurt, but I am also skeptical
>> that either will help.  Both concern trouble when loading utf-8 files.
>>
>> So you can git fetch again and then give origin/dev/guilev2 another try
>
> Hmm, no success for make. In LilyDev I did whats listed below
> (nonrelating stuff deleted). Did I something wrong?
>
> [build (dev/my-guilev2)]$ history 20
>53  cd lilypond-git/
>54  git fetch
>55  git branch -a
>56  git checkout origin/dev/guilev2
>
>60  git branch dev/my-guilev2
>61  git checkout dev/my-guilev2
>
>67  ./autogen.sh --noconfigure
>68  mkdir build/
>69  cd build/
>70  ../configure --enable-guile2
>71  make -j3
>
> I've got:
> [...]
> /home/harm/lilypond-git/stepmake/stepmake/c++-rules.make:4: recipe for
> target 'out/source-file.o' failed
> make[1]: *** [out/source-file.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory '/home/harm/lilypond-git/build/lily'
>
>
> Btw, it wasn't entirely clear to me that guilev2.x changes essential
> stuff that often.
> Exactly which guile-version are we aiming for?

The non-existing 2.0.12.  Currently, the stable-2.0 branch.  The main
challenge currently seems to be compiling LilyPond with a Guile version
that is not installed on your system.

-- 
David Kastrup

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[David Kastrup]

Thomas Morley  writes:

> 2016-01-11 23:14 GMT+01:00 David Kastrup :
>
>>> Btw, it wasn't entirely clear to me that guilev2.x changes essential
>>> stuff that often.
>>> Exactly which guile-version are we aiming for?
>>
>> The non-existing 2.0.12.  Currently, the stable-2.0 branch.  The main
>> challenge currently seems to be compiling LilyPond with a Guile version
>> that is not installed on your system.
>
> To be sure, the exercise is:
>
> (1) checkout the marked branch
>
> ~/guile (master)$ git branch -a
> * master
[...]
>   remotes/origin/stable-2.0
> ^^
[...]

> (2) Compile it
> (3) Build LilyPond with this guile somehow
>
> Correct?

It's the basis for making more tangible progress.  You can, of course,
try finding yet another route around all the problems ailing 2.0.11, but
it's unlikely to continue working in 2.1.

If you look in the Guile bug database, you'll find a number of bug
reports from me over the last years.  More often than not, I gave up at
some point of time and picked up only once a problem was fixed in
released packages of Guile.

The current release frequency of Guile, if nothing else, makes that a
bad bargain.  If we continue digging up problems in comparable number,
waiting for another release to trickle down into Ubuntu for every single
problem is just no sensible plan.  So we'll need a way to get bug fixes
in Guile back into LilyPond as they get done rather than waiting for a
full official release each time and its adoption by Ubuntu.

-- 
David Kastrup

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Thomas Morley]

Current state:

2016-01-08 23:06 GMT+01:00 Thomas Morley :
>> 2016-01-05 21:54 GMT+01:00 David Kastrup :
[...]
>> I don't know what the current Guile-2.0 situation is, but compiling
>> Guile-2.1 (namely master) is insane.  It takes about a day on my
>> computer.
>
> Took me ~8h
>
> Now I'm at:
>
> ~$ cd ../../usr/lib/x86_64-linux-gnu/guile-2.0/bin
> [...]@[...] /usr/lib/x86_64-linux-gnu/guile-2.0/bin$ ./guile
> GNU Guile 2.0.11
[...]

Correction. The above mentioned guilev2 is _not_ the one I compiled
myself. Don't know where it comes from.

I found the correct one in:

~$ cd guile/meta/
[...]@[...] ~/guile/meta (master)$ ./guile
GNU Guile 2.1.1.90-4137c
[...]

Ofcourse.


> Next step would be (trying) to compile LilyPond with guilev2, right?
> There is an option to do that, I vaguely remember. Let's see, if I find it ...


2016-01-08 23:52 GMT+01:00 David Kastrup :
>
> --with-guilev2 I think, but it's mentioned when doing ./configure --help
>
> But you have to point it to your guilev2 libraries somehow.

Up to now I couldn't figure how to do so.

Thus, and to avoid any 64-bit-problems I've set up newest LilyDev.
Installing guilev2 there.

$ guile-2.0
GNU Guile 2.0.11
[...]

I managed to run
../configure --enable-guile2
without error and got a successful build with simple `make'


The very first file I then tried to compile contained nothing else then:

\version "2.19.36"
{ c''1 }

And already a problem. See attached cut-off png.

I think it's one of the encoding problems you already mentioned,
causing ly:wide-char->utf-8 not to work properly.

ly:wide-char->utf-8 is directly used in markup-commands \char (as
already said) and \concat, as well as in \tagline and (but commented)
in some definitions of chord-modifiers-init.ly.

ly:wide-char->utf-8 seems to be defined in lily/general-scheme.cc


Questions:
1. Does it make sense to proceed with GNU Guile 2.0.11 or should I try
to get GNU Guile 2.1.1.90-4137c to work?
2. What does the patch you mentioned cure already?
3. We have a branch
remotes/origin/dev/guilev2
Makes sense to checkout it?
(It should, ofcourse, I'll test tomorrow)


Well, that's my current state, to tired to continue today.

So far, cheers,
  Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[David Kastrup]

Thomas Morley  writes:

> 3. We have a branch
> remotes/origin/dev/guilev2
> Makes sense to checkout it?
> (It should, ofcourse, I'll test tomorrow)

I've rebased it now, basically chucking one superseded commit.  It now
contains two commits that likely don't hurt, but I am also skeptical
that either will help.  Both concern trouble when loading utf-8 files.

So you can git fetch again and then give origin/dev/guilev2 another try.

The last commit is pretty much guaranteed to stop having an effect with
Guile-2.1 at the latest.  Mark Weaver claims that Guile-2.0 should still
have the previous behavior (where the patch helped) but I'm skeptical.
What I remember is that it worked at some point of time (Guile-2.0.8 or
something) and then stopped in 2.0.10 or 2.0.11.  It's possible I got
versions or symptomes mixed up at some point of time: at least a cursory
grep and glance at the respective range of changes in Guile did not turn
up any likely candidate for trouble.

-- 
David Kastrup

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[David Kastrup]

Thomas Morley  writes:

> Current state:

> $ guile-2.0
> GNU Guile 2.0.11
> [...]
>
> I managed to run
> ../configure --enable-guile2
> without error and got a successful build with simple `make'
>
>
> The very first file I then tried to compile contained nothing else then:
>
> \version "2.19.36"
> { c''1 }
>
> And already a problem. See attached cut-off png.
>
> I think it's one of the encoding problems you already mentioned,
> causing ly:wide-char->utf-8 not to work properly.
>
> ly:wide-char->utf-8 is directly used in markup-commands \char (as
> already said) and \concat, as well as in \tagline and (but commented)
> in some definitions of chord-modifiers-init.ly.
>
> ly:wide-char->utf-8 seems to be defined in lily/general-scheme.cc

That one looks actually ok I think.  The problem is likely everything
else.  Cough, cough.

> Questions:
> 1. Does it make sense to proceed with GNU Guile 2.0.11 or should I try
> to get GNU Guile 2.1.1.90-4137c to work?

Neither.  Check out the stable-2.0 branch.

> 2. What does the patch you mentioned cure already?

Reading utf-8 directly from files.

> 3. We have a branch
> remotes/origin/dev/guilev2
> Makes sense to checkout it?
> (It should, ofcourse, I'll test tomorrow)

See "followup" mail.  I could have sworn I had already sent _this_ mail,
so the followup mail may be a bit confusing without this one.

-- 
David Kastrup

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[David Kastrup]

David Kastrup  writes:

> Thomas Morley  writes:
>
>> 3. We have a branch
>> remotes/origin/dev/guilev2
>> Makes sense to checkout it?
>> (It should, ofcourse, I'll test tomorrow)
>
> I've rebased it now, basically chucking one superseded commit.  It now
> contains two commits that likely don't hurt, but I am also skeptical
> that either will help.  Both concern trouble when loading utf-8 files.
>
> So you can git fetch again and then give origin/dev/guilev2 another try.
>
> The last commit is pretty much guaranteed to stop having an effect with
> Guile-2.1 at the latest.  Mark Weaver claims that Guile-2.0 should still
> have the previous behavior (where the patch helped) but I'm skeptical.
> What I remember is that it worked at some point of time (Guile-2.0.8 or
> something) and then stopped in 2.0.10 or 2.0.11.  It's possible I got
> versions or symptomes mixed up at some point of time: at least a cursory
> grep and glance at the respective range of changes in Guile did not turn
> up any likely candidate for trouble.

Ok, I rebased and pushed the last work I did on the encoding stuff to
dev/guilev21.  This (single commit) is the code that will be necessary
for Guile-2.1 and it was the one that, again, failed working with any
Guile version at the time I wrote it following advice of Mark Weaver.
Which was what finally made me give up on the last try.

The responsible bug is now claimed to be fixed, but the fix will only
appear in Guile-2.0.12 so one currently needs to work with the
stable-2.0 branch instead of anything released yet.

-- 
David Kastrup

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[David Kastrup]

Thomas Morley  writes:

> 2016-01-08 23:52 GMT+01:00 David Kastrup :
>> Thomas Morley  writes:
> [...]
>>
>> I seem to remember you had to run meta/guile in order to have it find
>> its modules.
>
> Not sure what you mean.
>
> scheme@(guile-user)> (use-modules (srfi srfi-1))
> scheme@(guile-user)> last
> $1 = #
> scheme@(guile-user)> (last '(1 2 3))
> $2 = 3
> scheme@(guile-user)>
>
> Looks ok.

Huh.  There is meta/guile but it doesn't seem to exist in 1.8, and I
don't see any documentation referring to it in either 2.0 (where it is
present) or 2.1.  It is used in various Makefiles of Guile.

So no idea where my information is originally from and what its
relevance may even be.

-- 
David Kastrup

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Thomas Morley]

2016-01-08 23:52 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
[...]
>
> I seem to remember you had to run meta/guile in order to have it find
> its modules.

Not sure what you mean.

scheme@(guile-user)> (use-modules (srfi srfi-1))
scheme@(guile-user)> last
$1 = #
scheme@(guile-user)> (last '(1 2 3))
$2 = 3
scheme@(guile-user)>

Looks ok.

>
>> Next step would be (trying) to compile LilyPond with guilev2, right?
>
> Sure.
>
>> There is an option to do that, I vaguely remember. Let's see, if I find it 
>> ...
>
> --with-guilev2 I think, but it's mentioned when doing ./configure --help

Found it.

>
> But you have to point it to your guilev2 libraries somehow.

Here I got stucked. Done in a fresh cloned git-repository:

~/lilypond-git/build (master)$ ../configure --enable-guile2

complains:

ERROR: Please install required programs:  guile-config >= 2.0.7
(installed: 1.8.8) (guile-devel, guile-dev or libguile-dev package)

Well, no surprise. But how to point to my guilev2?

Or should I redo all in lily-dev?
Right now I'm on 64-bit. If I ever proceed far enough to touch GUB ...
I seem to remember it works 32-bit only, not sure though.

Cheers,
  Harm

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Ricardo Wurmus]

David Kastrup  writes:

> Ricardo Wurmus  writes:
>
 I don't know what the current Guile-2.0 situation is, but compiling
 Guile-2.1 (namely master) is insane.  It takes about a day on my
 computer.
>>>
>>> Took me ~8h
>>
>> There is a “guile-next” package for GNU Guix, which makes it possible
>> to get a binary build of Guile 2.1.1 (built from the 2.1.1 snapshot on
>> ftp://alpha.gnu.org).
>
> Absolutely no point in fighting with Guile 2.1 yet.

I just meant to comment on “compiling Guile-2.1 [...] is insane”.  If
you want to test against Guile 2.1 for some reason, it may make more
sense to install the binary with Guix rather than waiting for a day for
the build to succeed.

As Paul mentioned, there also is a package for Guile 2.0.11 in Guix.

~~ Ricardo


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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Ricardo Wurmus]

>> I don't know what the current Guile-2.0 situation is, but compiling
>> Guile-2.1 (namely master) is insane.  It takes about a day on my
>> computer.
>
> Took me ~8h

There is a “guile-next” package for GNU Guix, which makes it possible to
get a binary build of Guile 2.1.1 (built from the 2.1.1 snapshot on
ftp://alpha.gnu.org).

GNU Guix can be used as a package manager on top of any GNU+Linux
system.  This should make it a little easier to experiment with a more
recent version of Guile.

~~ Ricardo


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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[David Kastrup]

Ricardo Wurmus  writes:

>>> I don't know what the current Guile-2.0 situation is, but compiling
>>> Guile-2.1 (namely master) is insane.  It takes about a day on my
>>> computer.
>>
>> Took me ~8h
>
> There is a “guile-next” package for GNU Guix, which makes it possible
> to get a binary build of Guile 2.1.1 (built from the 2.1.1 snapshot on
> ftp://alpha.gnu.org).

Absolutely no point in fighting with Guile 2.1 yet.  It's unstable and
has changed the string semantics around _again_.  And every few weeks,
Andy Wingo rewrites essential parts of the compiler without coordinating
with anybody else.

-- 
David Kastrup

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Paul Morris]

> On Jan 9, 2016, at 12:44 PM, Ricardo Wurmus  wrote:
> 
> There is a “guile-next” package for GNU Guix, which makes it possible to
> get a binary build of Guile 2.1.1 (built from the 2.1.1 snapshot on
> ftp://alpha.gnu.org).

Looks like there’s a Guile 2.0.11 package too:

https://www.gnu.org/software/guix/package-list.html

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

guilev2-work [was: LilyPond boolean syntax? \true and \false]

[Thomas Morley]

2016-01-05 21:54 GMT+01:00 David Kastrup :
> Thomas Morley  writes:
>
[...]
>
>> Btw, you complained repeatedly about noone else but you cares about
>> moving to guilev2.  Otoh, I remember you wrote, all low hanging fruits
>> are done already.
>>
>> I always felt I wouldn't have the needed depth to help, I never asked
>> expecitely, though.
>
> The one thing that needs to be done next is seeing where current Guile
> stable-2.0 sits with respect to encoding problems.  I think I have a
> patch somewhere that is supposed to work with current versions.  But
> 2.0.12 (?) has not been released yet and anyway will take some time to
> make it into Ubuntu, so one needs to work with one's own compilations.
> And I was just too tired to pick this up again after the last round of
> fixes.
>
> At any rate, the encoding problems concern the C/Scheme interplay
> mostly.  So it's indeed not really a field where you specifically would
> not be likely to make progress once you did get stuck.
>
> Once the encoding business is past, the next stretches to be covered
> would likely be mostly Scheme-only, and then trying to bring a sensible
> way for precompiling/installing the Scheme files to bytecode into the
> Makefiles and cross-compilations.
>
> I don't know what the current Guile-2.0 situation is, but compiling
> Guile-2.1 (namely master) is insane.  It takes about a day on my
> computer.

Took me ~8h

> I don't really have much of a clue about Gub: it might be
> that this only needs to be done once per platform and then you can keep
> the stuff around for the next releases.
>
> --
> David Kastrup

Now I'm at:

~$ cd ../../usr/lib/x86_64-linux-gnu/guile-2.0/bin
[...]@[...] /usr/lib/x86_64-linux-gnu/guile-2.0/bin$ ./guile
GNU Guile 2.0.11
Copyright (C) 1995-2014 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (version)
$1 = "2.0.11"
scheme@(guile-user)>

Looks ok?
Next step would be (trying) to compile LilyPond with guilev2, right?
There is an option to do that, I vaguely remember. Let's see, if I find it ...

Then start tackling problems.

Cheers,
  Harm

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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

[David Kastrup]

Thomas Morley  writes:

> [...]@[...] /usr/lib/x86_64-linux-gnu/guile-2.0/bin$ ./guile
> GNU Guile 2.0.11
> Copyright (C) 1995-2014 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (version)
> $1 = "2.0.11"
> scheme@(guile-user)>
>
> Looks ok?

I seem to remember you had to run meta/guile in order to have it find
its modules.

> Next step would be (trying) to compile LilyPond with guilev2, right?

Sure.

> There is an option to do that, I vaguely remember. Let's see, if I find it ...

--with-guilev2 I think, but it's mentioned when doing ./configure --help

But you have to point it to your guilev2 libraries somehow.

>
> Then start tackling problems.

The files using utf-8 in the input bomb out or do nonsensical things.
Once you get there, I should have some patch here that might now work
better than before, using binary string streams from R6RS which
previously lost proper position in connection with #{ #}.

The \char markup's internal work function does not do the correct thing
in Guilev2 and probably needs some #ifdef for an alternate approach.
There is something ly_scm2string or the other way round that likely
needs to be split into several different variants (for latin1 which is a
euphemism for binary and for utf8, and possibly even for locale) and its
uses need to be checked and distributed among the appropriate version.

Copying of fonts into PDF files had some encoding problem I think, at
least for some fonts (either OTF or Type1 I think).

-- 
David Kastrup

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