Frescobaldi with LilyPond in WSL (was: Fatal error compiling large project (Win10/2.19.82))

[Urs Liska]

Am 19.12.18 um 21:56 schrieb Michael Gerdau:

First step would be running Frescobaldi from its Git repository
(and at that occasion test if the description is accurate and also works
for Windows 10):
https://github.com/wbsoft/frescobaldi/wiki/Run-Frescobaldi-3-from-Git-on-Windows

Commenting as I go:
These are the discrepancies so far:
I'm on a 64bit Windows 10, the copy commands needs to be:
cp /c/Program\ Files\ \(x86\)/Frescobaldi/...



Do you think it would be sufficient to state something like "adjust 
paths to your actual installation"?





There is a directory /c/Program\ Files\ \(x86\)/Frescobaldi/printsupport
Is that copied as well or ignored?



I have no idea if that directory wasn't there when I tried this out or 
if I simply missed it when writing the rules. I would say this qualifies 
as "everything except the frescobaldi_app directory", so I'd say yes, 
copy it.





Which custom branch am I supposed to check out as well?



None so far, there's no relevant code up yet.

The first milestone is having Frescobaldi run from Git at all (which you 
can see from the "Git" menu appearing between "Session" and "Help").


I must say in advance that I'm not very likely to be able to follow 
through on this "project". I'm interested in it and can make a few tests 
to start with, in order to get an idea whether it can work at all. 
Providing a proper solution is something I can't afford going after at 
the moment since I'm already busy with several other intrusive projects 
on Frescobaldi.


One thing you should prepare if Frescobaldi runs at all is register one 
(and only one) LilyPond instance that should probably point to a regular 
Windows LilyPond. I'm asking for this because when I'll write any code 
for this it will be more or less blindsided, and I want to be sure that 
I don't get confused by Frescobaldi trying to determine the appopriate 
LilyPond to be used.


Urs



Kind regards,
Michael


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

Re: Fatal error compiling large project (Win10/2.19.82)

[Michael Gerdau]

> First step would be running Frescobaldi from its Git repository
> (and at that occasion test if the description is accurate and also works 
> for Windows 10): 
> https://github.com/wbsoft/frescobaldi/wiki/Run-Frescobaldi-3-from-Git-on-Windows

Commenting as I go:
These are the discrepancies so far:
I'm on a 64bit Windows 10, the copy commands needs to be:
cp /c/Program\ Files\ \(x86\)/Frescobaldi/...

There is a directory /c/Program\ Files\ \(x86\)/Frescobaldi/printsupport
Is that copied as well or ignored?

Which custom branch am I supposed to check out as well?

Kind regards,
Michael
-- 
Michael Gerdau email: m...@qata.de
GPG-keys available on request or at public keyserver

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Urs Liska]

OK, great.

First step would be running Frescobaldi from its Git repository
(and at that occasion test if the description is accurate and also works 
for Windows 10): 
https://github.com/wbsoft/frescobaldi/wiki/Run-Frescobaldi-3-from-Git-on-Windows


Am 19.12.18 um 18:54 schrieb Saul Tobin:

I'd be happy to help test as well.

On Wed, Dec 19, 2018, 9:32 AM Michael Gerdau  wrote:



> Indeed, it's not a real problem to compose a special command
line for WSL Windows - if we know exactly how it should look like.
> Testing would be a little bit awkward, though

I‘d be happy to test it.

Kind regards,
Michael
___
lilypond-user mailing list
lilypond-user@gnu.org 
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Saul Tobin]

I'd be happy to help test as well.

On Wed, Dec 19, 2018, 9:32 AM Michael Gerdau 
> > Indeed, it's not a real problem to compose a special command line for
> WSL Windows - if we know exactly how it should look like.
> > Testing would be a little bit awkward, though
>
> I‘d be happy to test it.
>
> Kind regards,
> Michael
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fatal error compiling large project (Win10/2.19.82)

[Michael Gerdau]

> Indeed, it's not a real problem to compose a special command line for WSL 
> Windows - if we know exactly how it should look like.
> Testing would be a little bit awkward, though

I‘d be happy to test it.

Kind regards,
Michael
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fatal error compiling large project (Win10/2.19.82)

[Urs Liska]

Am 19.12.18 um 17:12 schrieb Michael Gerdau:

The Windows program "wsl.exe" is the interop program that ties things
together.  You can call it and pass it a command to be executed within
the WSL environment.

So, while I can simply say "lilypond" in a WSL shell, under a Windows
shell I need to say "wsl lilypond" to have the same effect.  Note then
that I am technically running "wsl.exe", not "lilypond"; but "lilypond"
will end up a child process of "wsl.exe" with standard input/output
properly routed.

Interesting...
...so cd'd into a directory with simpl LP files and there issued
wsl -e lilypond -- voice-choir-satb.ly
and it worked!
[upon reading further I realize, you already wrote that]

Note:
I already had the linux version of LP installed on my maschine and sometimes 
use it from within a WSL bash shell.

[stuff on paths and mount points snipped]


…which is rather wordy, but would get the job done.  For Frescobaldi,
however, we'd would likely need an intermediate script that translates
file paths.  But this is probably non-trivial, as there are a few cases
where paths could show up and need conversion (e.g.
"-dinclude-settings=" would need to be handled).

I think that should not be a problem since Frescobaldi composes the cmdline 
anyway and does know all the bits and pieces. After all on windows Frescobaldi 
invokes the windows version of lily in a separate process already.



Indeed, it's not a real problem to compose a special command line for 
WSL Windows - if we know exactly how it should look like.

Testing would be a little bit awkward, though

Urs





(Side note: I mainly use Bash on Windows, which follows the "proper" way
to work with paths.

That's exactly my main use of WSL too.

Kind regards,
Michael


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

Re: Fatal error compiling large project (Win10/2.19.82)

[Michael Gerdau]

> The Windows program "wsl.exe" is the interop program that ties things 
> together.  You can call it and pass it a command to be executed within 
> the WSL environment.
> 
> So, while I can simply say "lilypond" in a WSL shell, under a Windows 
> shell I need to say "wsl lilypond" to have the same effect.  Note then 
> that I am technically running "wsl.exe", not "lilypond"; but "lilypond" 
> will end up a child process of "wsl.exe" with standard input/output 
> properly routed.

Interesting...
...so cd'd into a directory with simpl LP files and there issued
wsl -e lilypond -- voice-choir-satb.ly
and it worked!
[upon reading further I realize, you already wrote that]

Note:
I already had the linux version of LP installed on my maschine and sometimes 
use it from within a WSL bash shell.

[stuff on paths and mount points snipped]

> …which is rather wordy, but would get the job done.  For Frescobaldi, 
> however, we'd would likely need an intermediate script that translates 
> file paths.  But this is probably non-trivial, as there are a few cases 
> where paths could show up and need conversion (e.g. 
> "-dinclude-settings=" would need to be handled).

I think that should not be a problem since Frescobaldi composes the cmdline 
anyway and does know all the bits and pieces. After all on windows Frescobaldi 
invokes the windows version of lily in a separate process already.

> (Side note: I mainly use Bash on Windows, which follows the "proper" way 
> to work with paths.

That's exactly my main use of WSL too.

Kind regards,
Michael
-- 
Michael Gerdau email: m...@qata.de
GPG-keys available on request or at public keyserver

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

Re: Fatal error compiling large project (Win10/2.19.82)

[David Kastrup]

Aaron Hill  writes:

> On 2018-12-18 9:26 pm, Saul Tobin wrote:
>> 1) Is there a technical obstacle or other reason preventing a Windows
>> 64-bit build?
>
> I would presume that GUB can target 64-bit MinGW,

I should be surprised, given just when GUB was under active development.
It probably is not a significant amount of additional work in lines of
code to make it support that, but figuring out the necessary steps is
likely going to take a whole lot of effort and learning for someone not
intimately acquainted with the current Windows target.

Certainly desirable.

-- 
David Kastrup

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Aaron Hill]

On 2018-12-19 3:43 am, Urs Liska wrote:
Am 19. Dezember 2018 11:53:26 MEZ schrieb Aaron Hill 
:

But if Frescobaldi needs to have a path to the LilyPond installation,
then it can never be made to work with WSL.  There is no* path to the
WSL file system that a Windows program can access.  Instead, it is the
Windows file system that is mounted so that Linux programs can
read/write to it from the WSL environment.  This is the only supported
method for data transfer.


How does one launch Linux programs then? Is that some specific "WSL
Shell" that you start and then have a bash or something? And this does
mean theWSL can only be used to do stuff on the Linux command line, no
way to use Linux commands triggered from Windows applications?


The Windows program "wsl.exe" is the interop program that ties things 
together.  You can call it and pass it a command to be executed within 
the WSL environment.


So, while I can simply say "lilypond" in a WSL shell, under a Windows 
shell I need to say "wsl lilypond" to have the same effect.  Note then 
that I am technically running "wsl.exe", not "lilypond"; but "lilypond" 
will end up a child process of "wsl.exe" with standard input/output 
properly routed.


(Related to this, you can run any Windows binary from a WSL shell 
directly without needing any interop program.  So "wsl.exe" is just for 
executing Linux binaries from Windows.)



Is there something like a $PATH to look for Linux commands? Then it
might be possible to create an invocation from Frescobaldi. I wasn't
clear about it: the default in Frescobaldi is to simply call
"lilypond" if no specific path is given, and we can of course do
anything that can be done in the given set-up.


Running "wsl echo $PATH" should return that value from the WSL 
environment.  Be aware that WSL will automatically forward the current 
Windows environment path to the Linux environment, so that "wsl echo 
$PATH" will include entries from the Windows side of life.  These are 
appropriately converted from the Windows path format to something that 
is valid in WSL:


D:\path\to\folder -> /mnt/d/path/to/folder

In theory, all we should need is for Frescobaldi to spawn a process like 
this:


wsl.exe /path/to/lilypond file.ly

(Of course, /path/to/lilypond is only needed if it is not already in the 
path.  For instance, I installed LilyPond globally using sudo so it 
created entries in /usr/local/bin for me.)


One challenge, though, is that Frescobaldi will invariably pass as 
arguments paths to files that are in Windows format, since it is after 
all running on Windows.  These paths will need to be converted.  
"wslpath" is a command in the WSL environment for this exact purpose.


I never hit this issue in my own use as I only ever run…

wsl lilypond file.ly

…for a file in the current directory.  But I could not, for instance, 
say…


wsl lilypond "D:\path\to\file.ly"

…which would be rejected by Linux lilypond as an invalid path.  I could, 
however, say…


wsl lilypond `wslpath "D:\path\to\file.ly"`

…which is rather wordy, but would get the job done.  For Frescobaldi, 
however, we'd would likely need an intermediate script that translates 
file paths.  But this is probably non-trivial, as there are a few cases 
where paths could show up and need conversion (e.g. 
"-dinclude-settings=" would need to be handled).


(Side note: I mainly use Bash on Windows, which follows the "proper" way 
to work with paths.  This helps greatly, as it means I can do relative 
paths on Windows and have the slashes pointing the right direction 
automatically.  I had tried using PowerShell for a long time but gave up 
after continually fighting issues like pathing, ultimately determining 
that PS is not intended to be an interactive shell.  Great for 
scripting, but that's about it.)


To Michael's point about running Linux in a VM, I would also agree that 
it is more likely the sensible option if you are going to go as far as 
set up a desktop environment and try to get Frescobaldi running in WSL.  
Aside from the fact that it is not really an intended use case for WSL, 
virtualization makes some things much easier.


And to reply to Saul: I would probably look at WSL LilyPond as a CLI 
approach only.  Think of it as the final build tool.  While iterating on 
your score, continue to use Frescobaldi on Windows with the Windows 
build of LilyPond.  Despite the 32-bit constraint, hopefully no single 
part of a score is so big as to run out of memory.  And then when you 
need to do the complete build, that is when you'd shell out to WSL and 
let 64-bit Linux LilyPond do the work.  With this strategy, it is no 
longer important that Frescobaldi be able to directly work with WSL.



-- Aaron Hill

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Michael Gerdau]

> How does one launch Linux programs then? Is that some specific "WSL Shell" 
> that you start and then have a bash or something? And this does mean theWSL 
> can only be used to do stuff on the Linux command line, no way to use Linux 
> commands triggered from Windows applications?

Yes.

As the name suggests, it is a (complete?) subsystem. As Aaron said you'd have 
to install a Linux version of Frescobaldi that runs inside the subsystem. Yes 
that's possible but I'd say in that case you're better of with a Linux system 
in a VM.

> Is there something like a $PATH to look for Linux commands?

No, at least not that I'm aware. There is quite some environment setup and 
switching required. After all inside the WSL you have a complete Linux runtime 
environment. Inside the WSL you can run regular Linux commands as opposed to 
Linux executables specifically prepared for this environment (ala cygwin).

The WSL comes in many different Linux distro flavours. However IMO it is not a 
replacement for a proper Linux system. Even a local Linux VM is better suited 
for most tasks IMO.

Kind regards,
Michael
-- 
Michael Gerdau email: m...@qata.de
GPG-keys available on request or at public keyserver

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Urs Liska]

Am 19. Dezember 2018 11:53:26 MEZ schrieb Aaron Hill :
>On 2018-12-19 2:17 am, Michael Gerdau wrote:
>>> Not really.
>>> What I *can* say is this:
>>> 
>>>   * LilyPond installations are registered in Frescobaldi by pointing
>
>>> to
>>> their executable.
>>>   * Frescobaldi calculates a path relative to that executable and
>adds
>>> that to the library path in the LilyPond process's environment
>>> 
>>> I have no idea how invoking external scripts works with the WSL, so
>I
>>> can't comment any further, but as said, Frescobaldi is only looking 
>>> for
>>> an absolute path to the executable.
>> 
>> I seriously doubt that Frescobaldi could run WSL lilypond w/o being
>> run itself from inside WSL.
>
>Regarding the last comment, that is a possibility.  Microsoft
>officially 
>does not support GUI applications from WSL; however, there are several
>X 
>servers that can run on Windows.  Folks online have reported that you 
>can set up X on WSL and have it connect to the Windows-hosted server.  
>The rest is the usual Magic™.
>
>But if Frescobaldi needs to have a path to the LilyPond installation, 
>then it can never be made to work with WSL.  There is no* path to the 
>WSL file system that a Windows program can access.  Instead, it is the 
>Windows file system that is mounted so that Linux programs can 
>read/write to it from the WSL environment.  This is the only supported 
>method for data transfer.

How does one launch Linux programs then? Is that some specific "WSL Shell" that 
you start and then have a bash or something? And this does mean theWSL can only 
be used to do stuff on the Linux command line, no way to use Linux commands 
triggered from Windows applications?

Is there something like a $PATH to look for Linux commands? Then it might be 
possible to create an invocation from Frescobaldi. I wasn't clear about it: the 
default in Frescobaldi is to simply call "lilypond" if no specific path is 
given, and we can of course do anything that can be done in the given set-up.

Urs

>
>(* When I say there is "no path", this is a technically convenient and 
>necessary lie.  WSL uses special extensions in NTFS to be able to host 
>the Linux-compatible file system.  You can technically browse to the 
>files from Windows, but no sane Windows program would even know how to 
>properly handle the extra file attributes without corrupting the file 
>system.)
>
>
>-- Aaron Hill
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Aaron Hill]

On 2018-12-19 2:17 am, Michael Gerdau wrote:

Not really.
What I *can* say is this:

  * LilyPond installations are registered in Frescobaldi by pointing 
to

their executable.
  * Frescobaldi calculates a path relative to that executable and adds
that to the library path in the LilyPond process's environment

I have no idea how invoking external scripts works with the WSL, so I
can't comment any further, but as said, Frescobaldi is only looking 
for

an absolute path to the executable.


I seriously doubt that Frescobaldi could run WSL lilypond w/o being
run itself from inside WSL.


Regarding the last comment, that is a possibility.  Microsoft officially 
does not support GUI applications from WSL; however, there are several X 
servers that can run on Windows.  Folks online have reported that you 
can set up X on WSL and have it connect to the Windows-hosted server.  
The rest is the usual Magic™.


But if Frescobaldi needs to have a path to the LilyPond installation, 
then it can never be made to work with WSL.  There is no* path to the 
WSL file system that a Windows program can access.  Instead, it is the 
Windows file system that is mounted so that Linux programs can 
read/write to it from the WSL environment.  This is the only supported 
method for data transfer.


(* When I say there is "no path", this is a technically convenient and 
necessary lie.  WSL uses special extensions in NTFS to be able to host 
the Linux-compatible file system.  You can technically browse to the 
files from Windows, but no sane Windows program would even know how to 
properly handle the extra file attributes without corrupting the file 
system.)



-- Aaron Hill

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Michael Gerdau]

> Not really.
> What I *can* say is this:
> 
>   * LilyPond installations are registered in Frescobaldi by pointing to
> their executable.
>   * Frescobaldi calculates a path relative to that executable and adds
> that to the library path in the LilyPond process's environment
> 
> I have no idea how invoking external scripts works with the WSL, so I 
> can't comment any further, but as said, Frescobaldi is only looking for 
> an absolute path to the executable.

I seriously doubt that Frescobaldi could run WSL lilypond w/o being run itself 
from inside WSL.

W/r to the question about using mingw64 to create the windows build:
You'd have to replace a whole lot of libraries with their 64bit counterpart. 
Last time I looked (possibly 1.5 years ago) that would have required porting a 
few libraries for which at that time the 64bit version did not yet exist.

Things may have changed but my expectation is, someone will have to actually do 
the porting to make it happen.

Kind regards,
Michael
-- 
Michael Gerdau email: m...@qata.de
GPG-keys available on request or at public keyserver

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Urs Liska]

Am 19.12.18 um 08:09 schrieb Aaron Hill:

On 2018-12-18 10:51 pm, Urs Liska wrote:

This UI is populated by running LilyPond with the
-dshow-available-fonts option, so it actually displays what LilyPond
can really use.


Ah, that greatly reduces confusion.

However, my point still stands that one needs to be aware that the 
fonts available are unique between Windows and WSL.  Installing a font 
in Windows will not make it available to WSL LilyPond or vice versa.  
Thankfully, Frescobaldi will show the fonts available to LilyPond, 
which serves as a good tool to confirm that fonts are installed 
properly in its environment.


But all of this is moot if Frescobaldi cannot be configured to use WSL 
LilyPond in the first place.  Urs, I know you have contributed to the 
Frescobaldi project.  Is this something you could speak to?



Not really.
What I *can* say is this:

 * LilyPond installations are registered in Frescobaldi by pointing to
   their executable.
 * Frescobaldi calculates a path relative to that executable and adds
   that to the library path in the LilyPond process's environment

I have no idea how invoking external scripts works with the WSL, so I 
can't comment any further, but as said, Frescobaldi is only looking for 
an absolute path to the executable.


HTH
Urs





-- Aaron Hill

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Aaron Hill]

On 2018-12-18 10:51 pm, Urs Liska wrote:

This UI is populated by running LilyPond with the
-dshow-available-fonts option, so it actually displays what LilyPond
can really use.


Ah, that greatly reduces confusion.

However, my point still stands that one needs to be aware that the fonts 
available are unique between Windows and WSL.  Installing a font in 
Windows will not make it available to WSL LilyPond or vice versa.  
Thankfully, Frescobaldi will show the fonts available to LilyPond, which 
serves as a good tool to confirm that fonts are installed properly in 
its environment.


But all of this is moot if Frescobaldi cannot be configured to use WSL 
LilyPond in the first place.  Urs, I know you have contributed to the 
Frescobaldi project.  Is this something you could speak to?



-- Aaron Hill

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Urs Liska]

Am 19.12.18 um 07:49 schrieb Aaron Hill:

On 2018-12-18 10:39 pm, Urs Liska wrote:

I have no idea about the WSL, but in general I can't imagine there
should be any source of confusion here. Frescobaldi wouldn't need to
access anything font-like when it comes to LilyPond…


But doesn't Frescobaldi have a UI for enumerating/previewing available 
fonts? 



Yes and no.


While it doesn't affect what LilyPond ultimately does, it still would 
show potentially conflicting information if there are fonts only 
installed on the Windows or WSL sides of life.



This UI is populated by running LilyPond with the -dshow-available-fonts 
option, so it actually displays what LilyPond can really use.


Urs





-- Aaron Hill

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


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

Re: Fatal error compiling large project (Win10/2.19.82)

[Aaron Hill]

On 2018-12-18 10:39 pm, Urs Liska wrote:

I have no idea about the WSL, but in general I can't imagine there
should be any source of confusion here. Frescobaldi wouldn't need to
access anything font-like when it comes to LilyPond…


But doesn't Frescobaldi have a UI for enumerating/previewing available 
fonts?  While it doesn't affect what LilyPond ultimately does, it still 
would show potentially conflicting information if there are fonts only 
installed on the Windows or WSL sides of life.



-- Aaron Hill

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Urs Liska]

Am 19.12.18 um 07:17 schrieb Aaron Hill:

2) Is it possible to run Lilypond under WSL from Frescobaldi?


Possibly; however I do not use Frescobaldi, so I cannot speak from 
experience.  Theoretically, you should only need to configure 
Frescobaldi to launch LilyPond as "wsl /path/to/lilypond" so that it 
uses the WSL instance.


You would need to make sure the WSL environment is configured properly 
for things like fonts.  There is no automatic sharing of fonts, so 
anything you have installed in Windows would not be immediately 
available to WSL LilyPond.  And since Frescobaldi can only enumerate 
fonts on the Windows side, there could be some confusion.


I have no idea about the WSL, but in general I can't imagine there 
should be any source of confusion here. Frescobaldi wouldn't need to 
access anything font-like when it comes to LilyPond, only LilyPond does, 
and in that set-up LilyPond would run completely within the WSL, isn't 
it? Of course when you select alternative text fonts in the LilyPond 
document these would have to be accessible from LilyPond.


Urs

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Aaron Hill]

On 2018-12-18 9:26 pm, Saul Tobin wrote:

1) Is there a technical obstacle or other reason preventing a Windows
64-bit build?


I would presume that GUB can target 64-bit MinGW, but I gather that this 
has not been a priority to deliver.  Perhaps one of the developers could 
speak to this more competently than I can.



2) Is it possible to run Lilypond under WSL from Frescobaldi?


Possibly; however I do not use Frescobaldi, so I cannot speak from 
experience.  Theoretically, you should only need to configure 
Frescobaldi to launch LilyPond as "wsl /path/to/lilypond" so that it 
uses the WSL instance.


You would need to make sure the WSL environment is configured properly 
for things like fonts.  There is no automatic sharing of fonts, so 
anything you have installed in Windows would not be immediately 
available to WSL LilyPond.  And since Frescobaldi can only enumerate 
fonts on the Windows side, there could be some confusion.



-- Aaron Hill

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Saul Tobin]

Thanks so much for the confirmation. A couple questions:

1) Is there a technical obstacle or other reason preventing a Windows
64-bit build?
2) Is it possible to run Lilypond under WSL from Frescobaldi?

On Tue, Dec 18, 2018 at 8:36 PM Aaron Hill  wrote:

> On 2018-12-18 7:24 pm, Saul Tobin wrote:
> > It looks like the Fatal realloc error happens after the score finishes
> > compiling while it's being written to a temporary file. At that point,
> > the
> > Lilypond process is using ~1.8 G of RAM. Is it possible I'm running
> > into a
> > 32 bit size limitation in Guile or something like that?
>
> Very likely.  There have been a number of issues reported before
> regarding memory pressure.  The Windows build of LilyPond is 32-bit
> only.  Also, I do not believe it is "large-address aware" either, so
> that means the address space is strictly 2GiB.  When you factor in DLLs
> and other resources, 1.8GiB is probably a reasonable upper bound for the
> working set.
>
> Due to a number of factors (bit-ness being one of them), I switched to
> using the 64-bit Linux build of LilyPond, running it under the Windows
> Subsystem for Linux (WSL).  This strategy, however, is not for the faint
> of heart.  You can search the mailing list for some posts I made on the
> subject; but if you are not already using WSL, it may not make sense to
> set it up just for LilyPond.
>
> To work within the limits of the existing Windows build, you will
> ultimately have to simplify the score in some way.  Manually segmenting
> it could allow you to compile each section without running out of
> memory, leaving you with the (hopefully) trivial task of stitching
> together the individual outputs into a single result.
>
>
> -- Aaron Hill
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fatal error compiling large project (Win10/2.19.82)

[Aaron Hill]

On 2018-12-18 7:24 pm, Saul Tobin wrote:

It looks like the Fatal realloc error happens after the score finishes
compiling while it's being written to a temporary file. At that point, 
the
Lilypond process is using ~1.8 G of RAM. Is it possible I'm running 
into a

32 bit size limitation in Guile or something like that?


Very likely.  There have been a number of issues reported before 
regarding memory pressure.  The Windows build of LilyPond is 32-bit 
only.  Also, I do not believe it is "large-address aware" either, so 
that means the address space is strictly 2GiB.  When you factor in DLLs 
and other resources, 1.8GiB is probably a reasonable upper bound for the 
working set.


Due to a number of factors (bit-ness being one of them), I switched to 
using the 64-bit Linux build of LilyPond, running it under the Windows 
Subsystem for Linux (WSL).  This strategy, however, is not for the faint 
of heart.  You can search the mailing list for some posts I made on the 
subject; but if you are not already using WSL, it may not make sense to 
set it up just for LilyPond.


To work within the limits of the existing Windows build, you will 
ultimately have to simplify the score in some way.  Manually segmenting 
it could allow you to compile each section without running out of 
memory, leaving you with the (hopefully) trivial task of stitching 
together the individual outputs into a single result.



-- Aaron Hill

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

Re: Fatal error compiling large project (Win10/2.19.82)

[Saul Tobin]

It looks like the Fatal realloc error happens after the score finishes
compiling while it's being written to a temporary file. At that point, the
Lilypond process is using ~1.8 G of RAM. Is it possible I'm running into a
32 bit size limitation in Guile or something like that?

On Sun, Dec 16, 2018 at 4:14 PM Saul Tobin 
wrote:

> Hi Ben,
>
> I did see that thread, but I don't think it can be directly related to my
> issue, since in my case there is no single line of my code that is
> triggering the compile error. Each score compiles correctly on its own and
> in combination with any of the others, but when I compile all together it
> fails. I am also not using strftime anywhere.
>
> Saul
>
>
>
> On Sun, Dec 16, 2018 at 2:38 PM Ben  wrote:
>
>> On 12/16/2018 5:32 PM, Saul Tobin wrote:
>>
>> Hi all,
>>
>> I'm getting a fatal error when I compile all of the movements of a large
>> project on 2.19.82 on Windows 10. I can compile the movements individually
>> and in smaller combinations with no problems. There is no Lilypond error in
>> the debug output, just "FATAL: memory error in realloc."
>>
>> I had no issues with this project on 2.18.2, and the only changes between
>> versions were running convert-ly and changing a couple variable names.
>>
>> Totally stumped here. Ideas?
>>
>> Saul
>>
>>
>> Hi Saul,
>>
>> I believe it's a Windows only bug/issue/problem/headache, sorry :(
>>
>> See here for a similar problem:
>>
>> http://lilypond.1069038.n5.nabble.com/Fatal-bug-in-strftime-td145721.html
>>
>> There may be a workaround for you, aside from going through the trouble
>> of setting up a virtual machine just to compile ;)
>>
>> Do you have any concerns with file names or other things that could be
>> triggering the memory error? Any other log info?
>>
>>
>>
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fatal error compiling large project (Win10/2.19.82)

[Saul Tobin]

Hi Ben,

I did see that thread, but I don't think it can be directly related to my
issue, since in my case there is no single line of my code that is
triggering the compile error. Each score compiles correctly on its own and
in combination with any of the others, but when I compile all together it
fails. I am also not using strftime anywhere.

Saul



On Sun, Dec 16, 2018 at 2:38 PM Ben  wrote:

> On 12/16/2018 5:32 PM, Saul Tobin wrote:
>
> Hi all,
>
> I'm getting a fatal error when I compile all of the movements of a large
> project on 2.19.82 on Windows 10. I can compile the movements individually
> and in smaller combinations with no problems. There is no Lilypond error in
> the debug output, just "FATAL: memory error in realloc."
>
> I had no issues with this project on 2.18.2, and the only changes between
> versions were running convert-ly and changing a couple variable names.
>
> Totally stumped here. Ideas?
>
> Saul
>
>
> Hi Saul,
>
> I believe it's a Windows only bug/issue/problem/headache, sorry :(
>
> See here for a similar problem:
>
> http://lilypond.1069038.n5.nabble.com/Fatal-bug-in-strftime-td145721.html
>
> There may be a workaround for you, aside from going through the trouble of
> setting up a virtual machine just to compile ;)
>
> Do you have any concerns with file names or other things that could be
> triggering the memory error? Any other log info?
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fatal error compiling large project (Win10/2.19.82)

[Ben]

On 12/16/2018 5:32 PM, Saul Tobin wrote:

Hi all,

I'm getting a fatal error when I compile all of the movements of a 
large project on 2.19.82 on Windows 10. I can compile the movements 
individually and in smaller combinations with no problems. There is no 
Lilypond error in the debug output, just "FATAL: memory error in realloc."


I had no issues with this project on 2.18.2, and the only changes 
between versions were running convert-ly and changing a couple 
variable names.


Totally stumped here. Ideas?

Saul



Hi Saul,

I believe it's a Windows only bug/issue/problem/headache, sorry :(

See here for a similar problem:

http://lilypond.1069038.n5.nabble.com/Fatal-bug-in-strftime-td145721.html

There may be a workaround for you, aside from going through the trouble 
of setting up a virtual machine just to compile ;)


Do you have any concerns with file names or other things that could be 
triggering the memory error? Any other log info?




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

Fatal error compiling large project (Win10/2.19.82)

[Saul Tobin]

Hi all,

I'm getting a fatal error when I compile all of the movements of a large
project on 2.19.82 on Windows 10. I can compile the movements individually
and in smaller combinations with no problems. There is no Lilypond error in
the debug output, just "FATAL: memory error in realloc."

I had no issues with this project on 2.18.2, and the only changes between
versions were running convert-ly and changing a couple variable names.

Totally stumped here. Ideas?

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