Re: Looking for help in configuring LilyDev in VirtualBox
Am 23.01.2020 um 11:45 schrieb Peter Toye: Re: Looking for help in configuring LilyDev in VirtualBox Wednesday, January 22, 2020, 10:35:45 PM, Michael Käppler wrote: Am 22.01.2020 um 14:03 schrieb Peter Toye: > Yes, I would suggest that you start from scratch again. That's because the keyboard-layout package is not installed in LilyDev v1 by default. In LilyDev v2, it will be there. I hadn't realised that your new instructions were for the next issue of LilyDev. Are there any other missing bits? I noticed that some of the utilities for listing hardware like lsusb aren't there. Do you think that 'lsusb' could be necessary? I think Federico's intention was to keep the image as small as possible, because one can easily install every debian package in the stretch repo afterwards. Best regards, Michael
Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)
On 2020/01/23 20:49:01, hanwenn wrote: > I mean, if we were writing a new SSL library, I surely would want scrutiny on > every cast, but we aren't. The question is, do you want scrutiny of any cast? If you do, then keeping the warnings enabled and keeping the signal-to-noise ratio high by casting only where it is well justified is the right approach. If you don't care, disable the warnings. > Can you point me to a conversion warning in LilyPond which could cause a > genuine, user-visible problem? I'm not going to spend the time to sift through past commits, current warnings, and existing casts to answer this properly. One involving a shorter integer that sticks in my mind (because I was recently working on resolving it) involves MIDI track number, a 16-bit number. It would not surprise me to find places in the MIDI code where conversions to 8-bit numbers occur; perhaps there's a questionable one in there somewhere. Now, I would prefer to leave off defending my stance on this, and let the senior contributors decide what is going to happen in this project. https://codereview.appspot.com/557190043/
Re: GUILE 2/3 and string encoding cost
Han-Wen Nienhuys writes: > On Wed, Jan 22, 2020 at 10:53 PM Han-Wen Nienhuys wrote: > >> The GUILE 2.0 release >> >> https://lwn.net/Articles/428288/ >> >> has one big red flag for me. >> >> * Switch to the Boehm-Demers-Weiser garbage collector >> > > We can easily measure this, by adding the following to > > #(display (version)) > #(display " gc time taken: ") > #(display (* 1.0 (/ (cdr (assoc 'gc-time-taken (gc-stats))) > internal-time-units-per-second))) > #(display "\n") > > on mozart-hrn-3, over 3 runs, we get > > 2.0.14 - avg 2.1s > 1.8.8 - avg 0.31s > > so the new GC is about 5-10x slower than the old one. With GUILE 1.8, > garbage collection covers typically is 10% of the runtime, so all things > equal, the Boehm GC would cause a 1.5-2.0x slowdown in the total. > > It would be good to see how the JITting of code impacts Scheme > execution. Boehm GC can work in a background thread I think. And Guile-v2 applications typically just let all their data be treated as pointers rather than using a smob-marking algorithm like we do, and it is conceivable that Boehm GC's individual mark function does not scale. However, considering everything a pointer for a 32bit application that can eat a significant ratio of the total address space is a nightmare: there would be just too much memory pinned down due to conservative garbage collection. On a 64bit application, this would be somewhat more tenable, but we'd need to override operator new for smobs. Or do we? Maybe the heap is collected by default, and we need to switch that off? -- David Kastrup
Re: GUILE 2/3 and string encoding cost
On Wed, Jan 22, 2020 at 10:53 PM Han-Wen Nienhuys wrote: > The GUILE 2.0 release > > https://lwn.net/Articles/428288/ > > has one big red flag for me. > > * Switch to the Boehm-Demers-Weiser garbage collector > We can easily measure this, by adding the following to #(display (version)) #(display " gc time taken: ") #(display (* 1.0 (/ (cdr (assoc 'gc-time-taken (gc-stats))) internal-time-units-per-second))) #(display "\n") on mozart-hrn-3, over 3 runs, we get 2.0.14 - avg 2.1s 1.8.8 - avg 0.31s so the new GC is about 5-10x slower than the old one. With GUILE 1.8, garbage collection covers typically is 10% of the runtime, so all things equal, the Boehm GC would cause a 1.5-2.0x slowdown in the total. It would be good to see how the JITting of code impacts Scheme execution. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Looking for help in configuring LilyDev in VirtualBox
Il giorno gio 23 gen 2020 alle 18:30, Michael Käppler ha scritto: We figured out, that the clipboard service /usr/bin/VBoxClient --clipboard is not running on Peter's LilyDev instance. I could not reproduce this on my v1 image. What we both noticed was that startup occassionally fails with a console prompt "Enter Maintenance mode...". Have you ever noticed this behaviour, too? I was not able to reproduce it reliably, so it's hard to track down. No, but I tested VirtualBox just a few times. I will let you know when v2 is released.
Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)
hanw...@gmail.com writes: > In LilyPond, the bulk of the warnings come from unsigned 64 bit sizes, > ie. vector and list sizes. > > In order to cause an error, you would have to create vector or list of > over 2G of > elements (on 32 bit architecture), so the unsigned size would be > converted to a negative integer. Since our objects > are all larger than a single byte, there isn't enough memory for this to > be possible. (The same holds for 64 bit, > except that you can't buy machines with that much RAM) Reality check: my laptop is something like 10 years old and holds 16GB of RAM. -- David Kastrup
Re: New branch guile-v3-work ?
Am Do., 23. Jan. 2020 um 10:48 Uhr schrieb Thomas Morley : > > Am Do., 23. Jan. 2020 um 10:35 Uhr schrieb David Kastrup : > > > > Thomas Morley writes: > > > > > Hi, > > > > > > I once pushed the /dev/guile-v2-work-branch to our repo. > > > Would it be of help to have a /dev/guile-v3-work as well? > > > If so, I'd need to do some clean up, currently my lily-guile3-build is > > > a bit messy. > > > > Can you summarize the differences? If there are extensive changes, we > > probably want most of the solution in the main source code or > > rebasing/cherry-picking becomes a nightmare. > > > > -- > > David Kastrup > > From my local branch, mostly on top of guile-v2-work (with comments): > > hermann@kasten ~/lilypond-git-guile-3.0 (dev/21-1-2020-test-guile3)$ > git log --oneline > >probably in master soon: > 16df8129ba (HEAD -> dev/21-1-2020-test-guile3) Han-Wens patch about > ly_scm_write_string > > gettext-changes for recently added/modified regtests: > fe3fd55f95 Changes for recent regtests > > 47595f0f31 Let aclocal.m4 and configure.ac accept guile-config with version 3 > > a8485e226d Guile-3 uses G_ for gettext instead of previous _ > > 114b337d02 Let configure work with guile 3.0 > > 26cbcda51a Work-around to fix utf-8-meta-data for >= guile-2.2.4 > > 1ab8714f8b Initialize locale in lily.scm > > Suggestion by Arne Babenhausen form the guile-list about > "ly:encode-string-for-pdf" > and After Issue 5665 Remove broken and undocumented tracing features https://sourceforge.net/p/testlilyissues/issues/5665/ this is superfluous: > adding (ice-9 threads)) to the used modules in memory-trace.scm > 6a497e2b58 Suggestions by Arne > > Simply commenting all previous functionality of ly:protects > 1a688b3103 ly:protects doesn't work with guilev2 > > Cheers, > Harm
Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)
On 2020/01/23 20:02:58, Dan Eble wrote: > On 2020/01/22 10:18:48, hanwenn wrote: > > alternately, we could just do -Wno-conversion in the makefile, and we wouldn't > > have to do any work here at all. > > These warnings weren't implemented just to irritate us. They were implemented > because C is the basement of C++ and there are bugs hiding in its dark corners. That is a beautiful metaphor, but can you be a little more concrete? The integer conversion is the same between C and C++, and the warnings are applied to all C code. That doesn't mean that our C code would has the same kind of problems, and that the impact of those problems warrant investment to address them. I mean, if we were writing a new SSL library, I surely would want scrutiny on every cast, but we aren't. In LilyPond, the bulk of the warnings come from unsigned 64 bit sizes, ie. vector and list sizes. In order to cause an error, you would have to create vector or list of over 2G of elements (on 32 bit architecture), so the unsigned size would be converted to a negative integer. Since our objects are all larger than a single byte, there isn't enough memory for this to be possible. (The same holds for 64 bit, except that you can't buy machines with that much RAM) Similarly, for causing a problem by converting 64-bit size_t to a 32-bit int, you'd have to create something with a size of over 2e9. What kind of score do you have in mind that would cause this problem? > My answer would be different if this were one of those categories of warnings > with a significant number of false positives, but it isn't, as far as I've seen. Can you point me to a conversion warning in LilyPond which could cause a genuine, user-visible problem? https://codereview.appspot.com/557190043/
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)
OK, point taken. Thanks for all the responses. Well, then the ugly way :-) https://codereview.appspot.com/579240043/
Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)
On 2020/01/22 10:18:48, hanwenn wrote: > alternately, we could just do -Wno-conversion in the makefile, and we wouldn't > have to do any work here at all. These warnings weren't implemented just to irritate us. They were implemented because C is the basement of C++ and there are bugs hiding in its dark corners. My answer would be different if this were one of those categories of warnings with a significant number of false positives, but it isn't, as far as I've seen. https://codereview.appspot.com/557190043/
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)
> On 23 Jan 2020, at 13:43, lemzwerg--- via Discussions on LilyPond development
> wrote:
>
>> Why is this ugly? std::string is really the name of the class.
>
> No question, but I would prefer
>
> struct xxx {
>using std:string;
>
>string foo;
>string bar;
>string baz;
> }
> }
>
> to
>
> struct xxx {
>std::string foo;
>std::string bar;
>std::string baz;
> }
>
> for example, to increase legibility if there are many strings.
When using ones own namespace reusing names of std, then the external object
must be qualified. For example,
namespace lly {
class string {
public:
string(const std::string&);
explicit operator std::string() const;
};
…
inline string operator+(string& x, string& y) {
return std::string(x) + std::string(y);
}
} // namespace lly
Re: Looking for help in configuring LilyDev in VirtualBox
Am 23.01.2020 um 12:11 schrieb Federico Bruni: If it helps, I can release v2 tomorrow. Michael, let me know if you have other PRs to send. Yes, I have some, but did not have the time to test them thoroughly. But they are completely unrelated to Peter's recent problems. I'd like to to test Dan's changes relating to Docker, too, but did not found enough time. My PRs would also fit into v3, IMHO, so I'm completely happy with a v2 release tomorrow. Then I can post my CG patch for review which reduces the risk that I will forget about it. So the basic question is: why isn't it starting up? I used to be a Solaris sysadmin, but that ended 20 years ago and my copy of Frisch is long gone. I don't really know because I can't reproduce this behaviour on my machine. Peter, I skipped most of your previous emails because of the poor quoting which made them unreadable. Now the quoting is correct and I'm reading again. What is not starting up? AFAIK, the shared clipboard does not work. Peter did install from scratch, with nearly the same setup I have (Win 10 as host os, VirtualBox 6.1 - I use 6.0), to no avail. We figured out, that the clipboard service /usr/bin/VBoxClient --clipboard is not running on Peter's LilyDev instance. I could not reproduce this on my v1 image. What we both noticed was that startup occassionally fails with a console prompt "Enter Maintenance mode...". Have you ever noticed this behaviour, too? I was not able to reproduce it reliably, so it's hard to track down. Cheers, Michael
PATCHES - Countdown for January 23rd
Hello, Here is the current patch countdown list. The next countdown will be on January 25th A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5665 Remove broken and undocumented tracing features - Jonas Hahnfeld https://sourceforge.net/p/testlilyissues/issues/5665 http://codereview.appspot.com/577320043 5660 Doc: Added documentation for fill-line line-width - davidsg https://sourceforge.net/p/testlilyissues/issues/5660 http://codereview.appspot.com/583340043 Countdown: 5676 remove obsolete lines from lily-guile-macros.hh - hanwen https://sourceforge.net/p/testlilyissues/issues/5676 http://codereview.appspot.com/555170043 5675 Document C++ structs for slur scoring - hanwen https://sourceforge.net/p/testlilyissues/issues/5675 http://codereview.appspot.com/571380043 5673 Remove implicit evaluation of the ".twy" file - hanwen https://sourceforge.net/p/testlilyissues/issues/5673 http://codereview.appspot.com/551380043 5672 Clean up and document include file searching - hanwen https://sourceforge.net/p/testlilyissues/issues/5672 http://codereview.appspot.com/573400043 5671 lily/page-breaking: pass vector by reference - hanwen https://sourceforge.net/p/testlilyissues/issues/5671 http://codereview.appspot.com/581510043 5669 Document why System::rank_type is int16 - hanwen https://sourceforge.net/p/testlilyissues/issues/5669 http://codereview.appspot.com/559370043 5668 Documentation: fix typo in German spacing.itely file - hanwen https://sourceforge.net/p/testlilyissues/issues/5668 http://codereview.appspot.com/581490043 5667 Documentation: fix typos in tool naming - hanwen https://sourceforge.net/p/testlilyissues/issues/5667 http://codereview.appspot.com/581480043 5666 ly_scm_write_string: call scm_write directly - hanwen https://sourceforge.net/p/testlilyissues/issues/5666 http://codereview.appspot.com/545450043 4550 Avoid "using" directives in included files - Dan Eble https://sourceforge.net/p/testlilyissues/issues/4550 http://codereview.appspot.com/579240043 Review: 5670 lily: fix some type conversion warnings - hanwen https://sourceforge.net/p/testlilyissues/issues/5670 http://codereview.appspot.com/557190043 New: 5678 l -> lilne - hanwen https://sourceforge.net/p/testlilyissues/issues/5678 http://codereview.appspot.com/581470047 *** Regards, James
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)
On 2020/01/23 14:36:26, dak wrote:
> On 2020/01/23 12:43:34, lemzwerg wrote:
> > > Why is this ugly? std::string is really the name of the class.
> >
> > No question, but I would prefer
> >
> > struct xxx {
> > using std:string;
> >
> > string foo;
> > string bar;
> > string baz;
> > }
> > }
> >
> > to
> >
> > struct xxx {
> > std::string foo;
> > std::string bar;
> > std::string baz;
> > }
> >
> > for example, to increase legibility if there are many strings.
>
> In my book, local types _decrease_ legibility since they force you to
hunt
> around for the definition in order to know what one is actually
talking about.
But it's not actually an opinion contest. The question is what use is
predominant in current C++ programming. And most particularly in
_libraries_, one does not introduce arbitrary type aliases without very
good reason.
https://codereview.appspot.com/579240043/
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)
On 2020/01/23 12:43:34, lemzwerg wrote:
> > Why is this ugly? std::string is really the name of the class.
>
> No question, but I would prefer
>
> struct xxx {
> using std:string;
>
> string foo;
> string bar;
> string baz;
> }
> }
>
> to
>
> struct xxx {
> std::string foo;
> std::string bar;
> std::string baz;
> }
>
> for example, to increase legibility if there are many strings.
In my book, local types _decrease_ legibility since they force you to
hunt around for the definition in order to know what one is actually
talking about.
https://codereview.appspot.com/579240043/
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh
File flower/include/file-name.hh (right):
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh#newcode47
flower/include/file-name.hh:47: std::string root_;
On 2020/01/23 11:33:11, lemzwerg wrote:
> This is very ugly.
I sympathize, but it is unambiguous.
> What about using the `std` namespace within a group instead?
It is possible to define a type alias File_name::string that can be used
as "string" in the body of the class definition, in the parameter lists
of File_name member functions (but not in the return values), and in the
bodies of File_name member functions. It would look like this:
class File_name
{
using string = std::string; // C++11
// or in the old style: typedef std::string string;
...
Of course, you would need to do the same for each type or function that
you wanted to avoid qualifying, and you would still have a bad time if
you tried to use it in particular cases where it creates ambiguity.
In a professional setting, I wouldn't advocate using this technique in
such a simple case, but if I had colleagues who loved it, I would put up
with it to keep the peace. I'd ask them not to demand that I follow
their example in subsystems that were my responsibility.
I expect that switching to this style consistently in LilyPond would
require an amount of labor that I am not currently willing to devote.
Thankfully, it seems the consensus on this patch is starting to point
toward "take it" rather than "leave it."
https://codereview.appspot.com/579240043/
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh File flower/include/file-name.hh (right): https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh#newcode47 flower/include/file-name.hh:47: std::string root_; On 2020/01/23 11:33:11, lemzwerg wrote: > This is very ugly. What about using the `std` namespace within a group instead? Why is this ugly? std::string is really the name of the class. See this SO thread on my "using namespace" is considered back practice: https://stackoverflow.com/q/1452721/10606944 https://codereview.appspot.com/579240043/
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)
> Why is this ugly? std::string is really the name of the class.
No question, but I would prefer
struct xxx {
using std:string;
string foo;
string bar;
string baz;
}
}
to
struct xxx {
std::string foo;
std::string bar;
std::string baz;
}
for example, to increase legibility if there are many strings.
https://codereview.appspot.com/579240043/
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)
On 2020/01/23 11:33:11, lemzwerg wrote: > I'm quite sure that you have more experience with C++ than me, however, I'm not > really happy with this change since it makes the code substantially uglier. > Isn't there another solution for the problem? > > https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh > File flower/include/file-name.hh (right): > > https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh#newcode47 > flower/include/file-name.hh:47: std::string root_; > This is very ugly. What about using the `std` namespace within a group instead? I'd say that ship has sailed by virtue of the C++ standard committee. Most current changes of Dan are supposed to bring the LilyPond code base in line with what C++ programmers are used to experiencing. And for better or worse, std:: most certainly has become part of that experience. So I am with Dan here. https://codereview.appspot.com/579240043/
Re: Packages/modules
Am Mittwoch, den 22.01.2020, 11:43 +0100 schrieb Urs Liska: > Am Mittwoch, den 22.01.2020, 11:06 +0100 schrieb David Kastrup: > > Urs Liska writes: > > > > > Am Dienstag, den 21.01.2020, 11:19 +0100 schrieb Urs Liska: > > > > > Ok. One thing to think about is that we want package files > > > > > to > > > > > be > > > > > contributed by "ordinary" users. But something like > > > > > > > > > > \exportSymbols > > > > > transposeSequence,instrumentGroup,scratchMyBack > > > > > > > > > > would be perfectly feasible syntactical sugar. > > > > > > > > > > > > > I'll be more verbose than probably necessary, just to make sure > > > > we're > > > > talking about the same thing. > > > > > > > > ... > > > > > > > > If I got you right then from my experience with openLilyLib and > > > > creating project environments (which basically are the same as > > > > packages), I would say: > > > > > > > > * I'm all for hiding names in packages by default and having > > > > to > > > >explicitly expose/export the package's interface > > > > > > > > > > One more implication: If variables and functions have to be > > > explicitly > > > exported it will be easier for external tools (like Frescobaldi) > > > to > > > add > > > proper support for extensions. > > > > > > I assume that at one point Frescobaldi will > > > > > > * know about available (core and external) extensions > > > * provide ways to "use" an extension (as part of the Score > > > wizard > > > and > > >locally) > > > * at that point know about the options that can be passed to > > > that > > >package > > > * provide autocompletion and highlighting for available symbols > > >exported from extensions > > > * provide actions to generate the code for getting and setting > > > package > > >options > > > > > > So when planning the syntax of that export it would be good to > > > take > > > the > > > needs/interest of IDEs into account that will not work with the > > > result > > > as LilyPond does but that parse the package files themselves. > > > > Maybe we should have single-command exports after all > > You mean that a package has to export every function or variable > separately? I think that would be good wrt self-documentation. > This gave me another idea: How would it be if elements (functions, variables, whatever) exported by packages would have to be addressed through a package namespace: * scholarly.annotate exports \criticalRemark * this can't be used with \criticalRemark but (syntax of course up to the parser maintainer ;-) ) \scholarly.annotate.criticalRemark That way the global namespace would be less pollutable, and identical names in different packages wouldn't be an issue. A user can still do something like criticalRemark = scholarly.annotate.criticalRemark as a local shorthand. Urs
Re: Packages/modules
Urs Liska writes: > Am Mittwoch, den 22.01.2020, 11:43 +0100 schrieb Urs Liska: >> >> You mean that a package has to export every function or variable >> separately? I think that would be good wrt self-documentation. >> > > This gave me another idea: How would it be if elements (functions, > variables, whatever) exported by packages would have to be addressed > through a package namespace: > > * scholarly.annotate exports \criticalRemark > * this can't be used with \criticalRemark but (syntax of course up to > the parser maintainer ;-) ) \scholarly.annotate.criticalRemark The implementation of \x.y.z is not robust enough for that, it's a nuisance, and judging from LaTeX experience, it does not seem to be problem in practice. > That way the global namespace would be less pollutable, and identical > names in different packages wouldn't be an issue. > > A user can still do something like > > criticalRemark = scholarly.annotate.criticalRemark > > as a local shorthand. No, that would be equivalent to criticalRemark = #'(scholarly annotate criticalRemark) -- David Kastrup
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)
I'm quite sure that you have more experience with C++ than me, however, I'm not really happy with this change since it makes the code substantially uglier. Isn't there another solution for the problem? https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh File flower/include/file-name.hh (right): https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh#newcode47 flower/include/file-name.hh:47: std::string root_; This is very ugly. What about using the `std` namespace within a group instead? https://codereview.appspot.com/579240043/
Re: Looking for help in configuring LilyDev in VirtualBox
Il giorno gio 23 gen 2020 alle 10:45, Peter Toye ha scritto: Wednesday, January 22, 2020, 10:35:45 PM, Michael Käppler wrote: Am 22.01.2020 um 14:03 schrieb Peter Toye: Yes, I would suggest that you start from scratch again. That's because the keyboard-layout package is not installed in LilyDev v1 by default. In LilyDev v2, it will be there. I hadn't realised that your new instructions were for the next issue of LilyDev. Are there any other missing bits? I noticed that some of the utilities for listing hardware like lsusb aren't there. If it helps, I can release v2 tomorrow. Michael, let me know if you have other PRs to send. So the basic question is: why isn't it starting up? I used to be a Solaris sysadmin, but that ended 20 years ago and my copy of Frisch is long gone. I don't really know because I can't reproduce this behaviour on my machine. Peter, I skipped most of your previous emails because of the poor quoting which made them unreadable. Now the quoting is correct and I'm reading again. What is not starting up?
Re: Looking for help in configuring LilyDev in VirtualBox
Wednesday, January 22, 2020, 10:35:45 PM, Michael Käppler wrote: Am 22.01.2020 um 14:03 schrieb Peter Toye: > Yes, I would suggest that you start from scratch again. That's because the keyboard-layout package is not installed in LilyDev v1 by default. In LilyDev v2, it will be there. I hadn't realised that your new instructions were for the next issue of LilyDev. Are there any other missing bits? I noticed that some of the utilities for listing hardware like lsusb aren't there. So the basic question is: why isn't it starting up? I used to be a Solaris sysadmin, but that ended 20 years ago and my copy of Frisch is long gone. I don't really know because I can't reproduce this behaviour on my machine. Oh dear. It looks as if I'll have to work out how to do it myself. I know there's a way of starting up programs on boot, but I've completely forgotten what it is. Will do some research. Best regards, Peter
Re: New branch guile-v3-work ?
Am Do., 23. Jan. 2020 um 10:48 Uhr schrieb Thomas Morley : > > Am Do., 23. Jan. 2020 um 10:35 Uhr schrieb David Kastrup : > > > > Thomas Morley writes: > > > > > Hi, > > > > > > I once pushed the /dev/guile-v2-work-branch to our repo. > > > Would it be of help to have a /dev/guile-v3-work as well? > > > If so, I'd need to do some clean up, currently my lily-guile3-build is > > > a bit messy. > > > > Can you summarize the differences? If there are extensive changes, we > > probably want most of the solution in the main source code or > > rebasing/cherry-picking becomes a nightmare. > > > > -- > > David Kastrup > > From my local branch, mostly on top of guile-v2-work (with comments): > > hermann@kasten ~/lilypond-git-guile-3.0 (dev/21-1-2020-test-guile3)$ > git log --oneline > >probably in master soon: > 16df8129ba (HEAD -> dev/21-1-2020-test-guile3) Han-Wens patch about > ly_scm_write_string > > gettext-changes for recently added/modified regtests: > fe3fd55f95 Changes for recent regtests > > 47595f0f31 Let aclocal.m4 and configure.ac accept guile-config with version 3 > > a8485e226d Guile-3 uses G_ for gettext instead of previous _ > > 114b337d02 Let configure work with guile 3.0 > > 26cbcda51a Work-around to fix utf-8-meta-data for >= guile-2.2.4 > > 1ab8714f8b Initialize locale in lily.scm > > Suggestion by Arne Babenhausen form the guile-list about > "ly:encode-string-for-pdf" > and > adding (ice-9 threads)) to the used modules in memory-trace.scm > 6a497e2b58 Suggestions by Arne > > Simply commenting all previous functionality of ly:protects > 1a688b3103 ly:protects doesn't work with guilev2 > > Cheers, > Harm >From guile-v2-work I used: 0829f6afad XXX reset the locale when building index.html 0e661bb5ec XXX don't override LANG globally in the build process fe8949b609 XXX add support for itexi files to the vim config 1ba0d71c37 Fix ly_scm2string() to work with guile-2.0 5b7913fbb4 Fix formatting floating point variables with guile-2.0 c0748149d4 Use the UTF-8 encoding for SVG files 45f4d2e8ee Fix wide characters support in embedded SCM with guile-2.0 3a9576b9cc Fix the encoding of the postscript output 5e65df7ae2 XXX Avoid the lockup in ly_scm_write_string 7fd5838326 Update changes from commit 122525f (Keep GUILEv2 from redecoding string input) da912ad4cc Source_file::init_port: Keep GUILEv2 from redecoding string input 671fb886b6 Initialize locale in GUILEv2
Re: New branch guile-v3-work ?
Am Do., 23. Jan. 2020 um 10:35 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > Hi, > > > > I once pushed the /dev/guile-v2-work-branch to our repo. > > Would it be of help to have a /dev/guile-v3-work as well? > > If so, I'd need to do some clean up, currently my lily-guile3-build is > > a bit messy. > > Can you summarize the differences? If there are extensive changes, we > probably want most of the solution in the main source code or > rebasing/cherry-picking becomes a nightmare. > > -- > David Kastrup >From my local branch, mostly on top of guile-v2-work (with comments): hermann@kasten ~/lilypond-git-guile-3.0 (dev/21-1-2020-test-guile3)$ git log --oneline probably in master soon: 16df8129ba (HEAD -> dev/21-1-2020-test-guile3) Han-Wens patch about ly_scm_write_string gettext-changes for recently added/modified regtests: fe3fd55f95 Changes for recent regtests 47595f0f31 Let aclocal.m4 and configure.ac accept guile-config with version 3 a8485e226d Guile-3 uses G_ for gettext instead of previous _ 114b337d02 Let configure work with guile 3.0 26cbcda51a Work-around to fix utf-8-meta-data for >= guile-2.2.4 1ab8714f8b Initialize locale in lily.scm Suggestion by Arne Babenhausen form the guile-list about "ly:encode-string-for-pdf" and adding (ice-9 threads)) to the used modules in memory-trace.scm 6a497e2b58 Suggestions by Arne Simply commenting all previous functionality of ly:protects 1a688b3103 ly:protects doesn't work with guilev2 Cheers, Harm
Re: New branch guile-v3-work ?
Thomas Morley writes: > Hi, > > I once pushed the /dev/guile-v2-work-branch to our repo. > Would it be of help to have a /dev/guile-v3-work as well? > If so, I'd need to do some clean up, currently my lily-guile3-build is > a bit messy. Can you summarize the differences? If there are extensive changes, we probably want most of the solution in the main source code or rebasing/cherry-picking becomes a nightmare. -- David Kastrup
New branch guile-v3-work ?
Hi, I once pushed the /dev/guile-v2-work-branch to our repo. Would it be of help to have a /dev/guile-v3-work as well? If so, I'd need to do some clean up, currently my lily-guile3-build is a bit messy. Cheers, Harm
Re: GUILE 2/3 and string encoding cost
Han-Wen Nienhuys writes:
> On Wed, Jan 22, 2020 at 11:43 PM David Kastrup wrote:
>
>> > Actually, the I was comparing the -O2 build with the -O0 build.
>> >
>> > When recompiling, the Scheme init (reading .scm files) takes 0.31s in 1.8
>> > vs. 2.7s in 2.0, a 9x slowdown.
>>
>> The Guile-2 compiler is doing a lot of optimisations, and LilyPond's
>> startup code switches off byte compilation because the dependencies are
>> hard to get under control.
>
>
> where does this happen?
lily/main.cc: sane_putenv("GUILE_AUTO_COMPILE", "0", true); // disable
auto-compile
Took me a while to find again.
>> The current codebase at least manages to
>> avoid to compile code with as-yet undefined macros, something that
>> Guile-1.8 had no problems with but Guile-2.0 refuses.
>>
>
> Do you mean that we don't have them anymore, or is there something else
> going on?
The source code has been rearranged so that macros are defined before use.
>> So the Scheme loading speed is sort-of expected due to Guile relying on
>> byte compilation for speed and we switch it off.
>>
>>
> Much to the contrary. Byte-compiling is slow (but running it should be
> faster), something you can see from building guile. If it is switched off,
> we are getting the "fast" experience.
There is a difference between file-level compilation and other stuff.
But I don't know the details well.
--
David Kastrup
