Re: GSoC-2020 update: Jul 31
Well, there's a good reason that gitlab has a big, fat 'rebase' button... >> >> Not sure about the meaning of your message: this button shows up >> because we enabled it as a project-wide setting. To my knowledge, >> the default and most common strategy is merging. Exactly! It's our policy to prefer rebasing over merging. >> [...] rebasing now means less error-prone work in the future. > > That sounds reasonable. Yes. > However, it means everybody should expect commits to change after > having looked at rhem. So: always pull again (well, that's clear) > and never add commits to Owen's branch wirhout clarifying the state > directly with him. Agreed. Right now, it's Owen's private branch, and nobody should ever do that. Werner
Re: GSoC-2020 update: Jul 31
Am 1. August 2020 23:31:32 MESZ schrieb Jean Abou Samra : >Hi everyone, > >Le 01/08/2020 à 18:19, Urs Liska a écrit : >> Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG : > Another issue: Maybe it makes sense if you try to rebase your > branch from time to time. Really rebase? >>> Yes, I favour rebasing over merging since the former causes a >>> `prettier' git commit tree. This would be a case where "general wisdom" argues against >modifying pushed commits. Typically you'd rather merge master into your working branch here. >>> Well, there's a good reason that gitlab has a big, fat 'rebase' >>> button... > >Not sure about the meaning of your message: this button shows up >because >we enabled it as a project-wide setting. To my knowledge, the default >and most common strategy is merging. > >> Yes, but that is meant to deal with integrating the final result into > >> master. Rebasing during work means that Owen's commits don't match >> those pulled by others. I don't have a strong opinion here but it >> should be an agreed-upon procefure for all. > >While I generally prefer merging over rebasing, since we enforce an >all-fast-forward policy for merging to master, I think we should rebase > >here. My reasoning is that you put in more information when resolving >conflicts during a rebase: merging means you unify two diverging >histories, thus you get prompted once and for all, but rebasing forces >you to resolve conflicts for each intermediary commit. As far as my >understanding extends, if Owen merges now, there will still be work >left >for rebasing at the end of the project, part of which will be >duplicated. By contrast, rebasing now means less error-prone work in >the >future. That sounds reasonable. However, it means everybody should expect commits to change after having looked at rhem. So: always pull again (well, that's clear) and never add commits to Owen's branch wirhout clarifying the state directly with him. Urs > >Best, >Jean -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: GSoC-2020 update: Jul 31
Hi everyone, Le 01/08/2020 à 18:19, Urs Liska a écrit : Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG : Another issue: Maybe it makes sense if you try to rebase your branch from time to time. Really rebase? Yes, I favour rebasing over merging since the former causes a `prettier' git commit tree. This would be a case where "general wisdom" argues against modifying pushed commits. Typically you'd rather merge master into your working branch here. Well, there's a good reason that gitlab has a big, fat 'rebase' button... Not sure about the meaning of your message: this button shows up because we enabled it as a project-wide setting. To my knowledge, the default and most common strategy is merging. Yes, but that is meant to deal with integrating the final result into master. Rebasing during work means that Owen's commits don't match those pulled by others. I don't have a strong opinion here but it should be an agreed-upon procefure for all. While I generally prefer merging over rebasing, since we enforce an all-fast-forward policy for merging to master, I think we should rebase here. My reasoning is that you put in more information when resolving conflicts during a rebase: merging means you unify two diverging histories, thus you get prompted once and for all, but rebasing forces you to resolve conflicts for each intermediary commit. As far as my understanding extends, if Owen merges now, there will still be work left for rebasing at the end of the project, part of which will be duplicated. By contrast, rebasing now means less error-prone work in the future. Best, Jean
Re: GSoC-2020 update: Jul 31
Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG : >>> Another issue: Maybe it makes sense if you try to rebase your >>> branch from time to time. >> >> Really rebase? > >Yes, I favour rebasing over merging since the former causes a >`prettier' git commit tree. > >> This would be a case where "general wisdom" argues against modifying >> pushed commits. Typically you'd rather merge master into your >> working branch here. > >Well, there's a good reason that gitlab has a big, fat 'rebase' >button... Yes, but that is meant to deal with integrating the final result into master. Rebasing during work means that Owen's commits don't match those pulled by others. I don't have a strong opinion here but it should be an agreed-upon procefure for all. Urs > > >Werner -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: 2,21,4 released
> That was also my understanding, but "dir /x" already shows a short name > of "D15A~1.LY" for "ä.ly". Maybe I'm doing something wrong? (not used > Windows at that technical level for a few years now...) Sorry, I have no idea because I'm not familiar with non-Japanese Windows. At least in Japanese Windows, it is easy to create the file that `stat ()` in msvcrt.dll raises the error.
Re: 2,21,4 released
>> Do you have an example of a file name that should not work? I now have >> three versions from GUB (one with MoveFileExW; one without but with >> wstat; and one without wstat) and all work correctly on a recent >> Windows 10. Does that mean the issue is gone with a recent update? > > Might it be dependent on which VC++ package you have installed (or > not) that determines which definition is used by Windows? > > i.e. (from Hosoda-san) > >> `stat ()` in newer UCRTs than msvcrt.dll does not have the problem. > > I won't pretend to know the internals here but my work laptop has a > number of different iterations of the older VC++ components installed, > some of them go back to 2013 (for old internally made tools we still > use now and again) and they seem to co-exist but I don't know what it > is LP calls in this case. Some were installed manually and some by the > various software installers I have run. If I understand correctly, lilypond.exe generated by GUB uses msvcrt.dll instead of UCRT. The recent Visual C++ generated executables use UCRT. The executables generated by MinGW normally use msvcrt.dll. The recent MinGW can generate executables that use UCRT by a special configuration. However, GUB contains older MinGW that can not be configured as such.
Re: GSoC-2020 update: Jul 31
>> Another issue: Maybe it makes sense if you try to rebase your >> branch from time to time. > > Really rebase? Yes, I favour rebasing over merging since the former causes a `prettier' git commit tree. > This would be a case where "general wisdom" argues against modifying > pushed commits. Typically you'd rather merge master into your > working branch here. Well, there's a good reason that gitlab has a big, fat 'rebase' button... Werner
Re: 2,21,4 released
Am Samstag, den 01.08.2020, 22:15 +0900 schrieb Masamichi Hosoda: > > Thanks for all the explanation, I think I'm slowly starting to > > understand the problem. I've tried to get short names with special > > characters, but failed so far (maybe you need a setting for this?). > > I'm giving up on this for now and will keep the code path with > > MoveFileExW unless you feel strongly about removing it. > > Do you use German Windows? I set up a virtual machine for testing LilyPond. > Is its ANSI encodings CP1252? Yes, German should be CP-1252, but "chcp" says that cp-850 is active. Which is not a problem by itself because cp-850 also supports some special characters that need multiple bytes in UTF-8. > If so, maybe `.ly` should not work with `stat ()` in msvcrt.dll. > If I understand correctly, `Ä` is 1 byte in CP1252 and is 2 bytes in UTF-8. > `.LY` is 8 bytes + 2 bytes in CP1252 and 16 bytes + 2 bytes in UTF-8. That was also my understanding, but "dir /x" already shows a short name of "D15A~1.LY" for "ä.ly". Maybe I'm doing something wrong? (not used Windows at that technical level for a few years now...) signature.asc Description: This is a digitally signed message part
Re: 2,21,4 released
> Thanks for all the explanation, I think I'm slowly starting to > understand the problem. I've tried to get short names with special > characters, but failed so far (maybe you need a setting for this?). > I'm giving up on this for now and will keep the code path with > MoveFileExW unless you feel strongly about removing it. Do you use German Windows? Is its ANSI encodings CP1252? If so, maybe `.ly` should not work with `stat ()` in msvcrt.dll. If I understand correctly, `Ä` is 1 byte in CP1252 and is 2 bytes in UTF-8. `.LY` is 8 bytes + 2 bytes in CP1252 and 16 bytes + 2 bytes in UTF-8.
Re: 2,21,4 released
Am Samstag, den 01.08.2020, 20:23 +0900 schrieb Masamichi Hosoda: > >> `stat ()` in msvcrt.dll has a problem with some Unicode file names. > >> So we use `_wstat ()` instead of `stat ()` if msvcrt.dll is used. > >> To use `_wstat ()`, we need a wide string, > >> so we use `MultiByteToWideChar ()` to convert it. > > > > Do you have an example of a file name that should not work? I now have > > three versions from GUB (one with MoveFileExW; one without but with > > wstat; and one without wstat) and all work correctly on a recent > > Windows 10. Does that mean the issue is gone with a recent update? > > The file name that should not work depends on the language of Windows. > If a short file name exceeds 8 bytes + 3 bytes when written in UTF-8, > `stat ()` in msvcrt.dll cause an error. > > In Windows, most files have a short file name > in addition to the normal file name. > The short file names are up to 8 bytes + 3 bytes in length > and are stored in a Windows language-dependent encoding. > > For example, on Japanese Windows, > the short file name `インスト.LY` is stored in CP932 encoding > with 8 bytes + 2 bytes. > If the name is written in UTF-8 encoding, it is 12 bytes + 2 bytes. > So the short file name `インスト.LY` in Japanese Windows should not work. > However, in other languages Windows, it may work. > > If the normal file name, such as `☃.ly`, > cannot be written in CP932, the problem does not occur > because the short file name is given in US-ASCII only. Thanks for all the explanation, I think I'm slowly starting to understand the problem. I've tried to get short names with special characters, but failed so far (maybe you need a setting for this?). I'm giving up on this for now and will keep the code path with MoveFileExW unless you feel strongly about removing it. Thanks, Jonas signature.asc Description: This is a digitally signed message part
Re: 2,21,4 released
>> `stat ()` in msvcrt.dll has a problem with some Unicode file names. >> So we use `_wstat ()` instead of `stat ()` if msvcrt.dll is used. >> To use `_wstat ()`, we need a wide string, >> so we use `MultiByteToWideChar ()` to convert it. > > Do you have an example of a file name that should not work? I now have > three versions from GUB (one with MoveFileExW; one without but with > wstat; and one without wstat) and all work correctly on a recent > Windows 10. Does that mean the issue is gone with a recent update? The file name that should not work depends on the language of Windows. If a short file name exceeds 8 bytes + 3 bytes when written in UTF-8, `stat ()` in msvcrt.dll cause an error. In Windows, most files have a short file name in addition to the normal file name. The short file names are up to 8 bytes + 3 bytes in length and are stored in a Windows language-dependent encoding. For example, on Japanese Windows, the short file name `インスト.LY` is stored in CP932 encoding with 8 bytes + 2 bytes. If the name is written in UTF-8 encoding, it is 12 bytes + 2 bytes. So the short file name `インスト.LY` in Japanese Windows should not work. However, in other languages Windows, it may work. If the normal file name, such as `☃.ly`, cannot be written in CP932, the problem does not occur because the short file name is given in US-ASCII only.
Re: removing regtest profiling
Am Samstag, den 01.08.2020, 12:08 +0200 schrieb Han-Wen Nienhuys: > did you get started on (title) ? If not I can start. No, didn't get there yet. Note that this involves some doc editing because it's mentioned in a few places (both Usage and CG). signature.asc Description: This is a digitally signed message part
Re: 2,21,4 released
On 01/08/2020 10:06, Jonas Hahnfeld via Discussions on LilyPond development wrote: Am Samstag, den 01.08.2020, 15:39 +0900 schrieb Masamichi Hosoda: Testing with Frescobaldi would be appreciated, and also with special characters in file names. I tried to model this after the code Masamichi-san wrote in March, but I'm not sure I understand what it's really needed for? `stat ()` in msvcrt.dll has a problem with some Unicode file names. So we use `_wstat ()` instead of `stat ()` if msvcrt.dll is used. To use `_wstat ()`, we need a wide string, so we use `MultiByteToWideChar ()` to convert it. Do you have an example of a file name that should not work? I now have three versions from GUB (one with MoveFileExW; one without but with wstat; and one without wstat) and all work correctly on a recent Windows 10. Does that mean the issue is gone with a recent update? Might it be dependent on which VC++ package you have installed (or not) that determines which definition is used by Windows? i.e. (from Hosoda-san) `stat ()` in newer UCRTs than msvcrt.dll does not have the problem. I won't pretend to know the internals here but my work laptop has a number of different iterations of the older VC++ components installed, some of them go back to 2013 (for old internally made tools we still use now and again) and they seem to co-exist but I don't know what it is LP calls in this case. Some were installed manually and some by the various software installers I have run. I don't know how or what Windows patches in this case. Yours (probably getting it completely wrong). James
removing regtest profiling
did you get started on (title) ? If not I can start. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: 2,21,4 released
Am Samstag, den 01.08.2020, 15:39 +0900 schrieb Masamichi Hosoda: > > Testing with Frescobaldi would be appreciated, and also with special > > characters in file names. I tried to model this after the code > > Masamichi-san wrote in March, but I'm not sure I understand what it's > > really needed for? > > `stat ()` in msvcrt.dll has a problem with some Unicode file names. > So we use `_wstat ()` instead of `stat ()` if msvcrt.dll is used. > To use `_wstat ()`, we need a wide string, > so we use `MultiByteToWideChar ()` to convert it. Do you have an example of a file name that should not work? I now have three versions from GUB (one with MoveFileExW; one without but with wstat; and one without wstat) and all work correctly on a recent Windows 10. Does that mean the issue is gone with a recent update? > `stat ()` in newer UCRTs than msvcrt.dll does not have the problem. > Therefore, if `_UCRT` is defined, > we do not use `_wstat ()` and `MultiByteToWideChar ()`. > > If I understand correctly, > `MoveFileExA ()` and `CopyFileA ()` do not have the problem. > So we do not necessarily need to use `MoveFileExW ()` and `CopyFileW ()`. signature.asc Description: This is a digitally signed message part
Re: 2,21,4 released
> Testing with Frescobaldi would be appreciated, and also with special > characters in file names. I tried to model this after the code > Masamichi-san wrote in March, but I'm not sure I understand what it's > really needed for? `stat ()` in msvcrt.dll has a problem with some Unicode file names. So we use `_wstat ()` instead of `stat ()` if msvcrt.dll is used. To use `_wstat ()`, we need a wide string, so we use `MultiByteToWideChar ()` to convert it. `stat ()` in newer UCRTs than msvcrt.dll does not have the problem. Therefore, if `_UCRT` is defined, we do not use `_wstat ()` and `MultiByteToWideChar ()`. If I understand correctly, `MoveFileExA ()` and `CopyFileA ()` do not have the problem. So we do not necessarily need to use `MoveFileExW ()` and `CopyFileW ()`.
Re: Make doc and ghostscript warnings - cannot find TexGyre/Emmentaler
On 31/07/2020 22:04, Daniel Benjamin Miller wrote: It's actually quite fine. It's basically saying it can't find Gyre or Emmentaler in GhostScript's bundled fonts. Which it shouldn't, since they're not included with GS. It finds it instead in the LilyPond build directory, where it well should be found. DBM Well I guessed that, the point was that should it be posting those warnings at all? Having built full doc for the last 8 years pretty much every other day, I get twitchy when I 'suddenly' see things posted that I didn't the week before. Maybe those warnings have been there for a 'while' but maybe not. Now that we've moved the doc check over to automation, I worry sometimes that these warnings creep in unnoticed and then, a few months down the line, something suddenly breaks and it goes all the way back to some innocuous change made by a well meaning dev that now means we have to fix things. Not that I sit and pore over the entire stdout while compiling but, hey! ;) James
