|
From: | Urs Liska |
Subject: | Re: OLL-core and Win10 [was Re: edition-editor usage] |
Date: | Mon, 8 Jan 2018 14:16:40 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 |
Hi Trevor Am 27.12.2017 um 14:33 schrieb Urs Liska:
Done; here's the log output: Starting lilypond-windows.exe 2.19.80 [Untitled]... Processing `C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmp4_jxjpvb/document.ly' Parsing... location: #<location C:/Users/tdani/openlilylib/oll-core/package.ily:57:2> initial path: C:/Users/tdani/openlilylib/oll-core/package.ily this file: (C:/Users/tdani/openlilylib/oll-core/package.ily)OK, here we are. This should be a list with the path elements, but it has the whole path in*one* list element. And throws an error when trying to access the second-to-last element. With this information I can debug the function.
I've now had the chance to look into this issue, and it's clear what happens. I could easily fix that *for you*, but I'm not sure about the *proper* fix.
The path handling functions in oll-core work in an OS dependent way and define an OS path separator of "\" (Windows) or "/" (otherwise). But in your log "/" is used on Windows as well.
I know that by now Windows can handle both forward and backward slashed.But it would be important for me to know if I can rely on (*location*) returning forward slashes in all Windows versions.
Could people on different Windows versions please compile the following file and tell me about the output?
\version "2.19.80" loc = #(define-void-function ()() (display (*location*))) \loc Thanks Urs
Best Urs
[Prev in Thread] | Current Thread | [Next in Thread] |