Re: LilyDev4 and Guile2.2 ?
2017-04-14 6:44 GMT+02:00 Paul : > On 04/13/2017 02:23 PM, Thomas Morley wrote: > >> Hi Paul, >> >> meanwhile I do most on my host, not in the VB. >> >> I compiled guile-1.8 and guile-2.0.14 from the released tarball and >> 2.2.0 from the guile-repository. >> Once compiled it's pretty unexpensive to do 'make install' on the >> guile-version you wish. >> >> Also, I have three times the lilypond-repository, each compiled with a >> different guile-version. >> >> So I can check quickly whatever I need with different versions of >> lilypond/guile. >> >> >> Probably not the way for you, but very convenient in my eyes. > > > Hi Harm, Thanks for the info. I thought there were problems with having > guile1 and guile2.x installed at the same time? Indeed I can _install_ only one guile version at the same time system wide. But I _compiled_ the mentioned three guile-versions, which takes some time. But once compiled 'make install' is fairly fast. So my workflow is: (1) - Compile guile-1.8 from the tarball* - install it via 'make install' - build LilyPond as usual with from a git repository, I call it "lilypond-git" (2) - Compile guile-2.0.14 from the tarball - install it via 'make install' (this throws out previous installed guile)** - build LilyPond as usual with from a git repository, I call it "lilypond-git-guile-2.0.14" (3) - Compile guile-2.2 from the guile-repository - install it via 'make install' (this throws out previous installed guile)** - build LilyPond as usual with from a git repository, I call it "lilypond-git-guile-2.2" This gets me LilyPond-versions with three different guile-versions. [*] guile-1.8. from the tarball needs to be done with the configure-option: ./configure --disable-error-on-warning [**] at least I never experienced any drawback doing so There may be a way to point LilyPond to a certain guile-version without the need to install this guile system-wide, but I never found it. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES - Countdown for April 15th
Hello, There are currently no patches in the queue today. The next countdown will be on April 16th. Happy Easter. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES - Countdown for April 15th
Hello On Sat, 15 Apr 2017 09:14:42 +0100 James wrote: > Hello, > > There are currently no patches in the queue today. > > The next countdown will be on April 16th. Sorry that was a typo. The next countdown will be on April 18th. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Add a work to "we wrote" list
Thanks James for waiting for me to get home. 2017-04-07 16:56 GMT+02:00 Han-Wen Nienhuys : > This links to https://cloud.paconet.org/tesis/tesis.pdf, which is 404. > I think you mean https://paconet.org/tesis/tesis.pdf ? This is the deep link but I'd rather link to a wiki page containing some meta info. From here, https://paconet.org/wiki/index.php?title=Tesis (note the https) links correctly to the wiki a 200 OK result, whereas http://paconet.org/wiki/index.php?title=Tesis (note the http) gives 301, then 404, but on a browser it redirects to the https, furthermore: https://www.paconet.org/wiki/index.php?title=Tesis (note the www) gives problems with my cheesy, temporary certificate config, but this is not the link I posted, and http://www.paconet.org/wiki/index.php?title=Tesis (note the http and www) also gives 301, then 404 and on a browser it also redirects to the https and www and therefore to the problem. In short, if the original link does work I'd like to maintain it. If not, the deep link is suboptimal but also acceptable. Thanks for your time. -- Francisco Vila. Badajoz (Spain) paconet.org , csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [guile-2.2] threads
2017-04-05 19:58 GMT+02:00 Han-Wen Nienhuys : > LilyPond has no thread-safety anywhere. It would be actively harmful > if anybody ever tried to run something on a different thread. If > anything, you should find a way to forbid importing the threads > package. > > On Sun, Mar 26, 2017 at 2:40 PM, Thomas Morley > wrote: >> Hi all, >> >> guile-2.2 prints a warning, if module (ice-9 threads) is not imported. >> (This does not happen with guile-1.8 or guile-2.0) >> Import (ice-9 threads) to have access to `call-with-new-thread'. >> Import (ice-9 threads) to have access to `current-thread'. >> >> As suggested by Arne Babenhauserheide from the guile-mailing list, in >> memory-trace.scm we could do something at the lines of >> >> ;; TODO if lilypond moves to guile-2.2 merge the next two settings >> (use-modules (lily) >> (ice-9 format)) >> (if guile-v2 (use-modules (ice-9 threads))) >> >> This would even be compatible with guile-1.8 (ofcourse one would do it >> with a little different coding) >> >> Though, I think we currently have no need for it. So importing (ice-9 >> threads) would be pointless. >> If I'm right in this, would there be any other way to avoid this >> warning-messages? >> >> >> Cheers, >> Harm My purpose was only to get rid of the annoying warning with guile-2.2. Though, meanwhile I have to state memory-trace.scm is broken since guile-2.0 anyway, because trap-set! and trap-enable seems gone since then. Also, tbh, I've no clue about "enter-frame-handler"... $ lilypond-git-guile-2.2 -dtrace-memory-frequency=1 ../lilypondH/Test/forum/atest-55.ly GNU LilyPond 2.19.58 Processing `../lilypondH/Test/forum/atest-55.ly' Parsing...In ice-9/eval.scm: 619:8 4 (_ #(#(#))) 619:8 3 (_ #(#(#))) 182:19 2 (proc #(#(#))) 142:16 1 (compile-top-call _ (7 . trap-set!) ((13 15 7 . #) #)) In unknown file: 0 (%resolve-variable (7 . trap-set!) #) ERROR: In procedure %resolve-variable: ERROR: Unbound variable: trap-set! Looks like memory-trace.scm should be rewritten... Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
