You can subscribe to this list here.
2007 |
Jan
(24) |
Feb
(85) |
Mar
(32) |
Apr
(1) |
May
(7) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(3) |
Feb
(15) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(20) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
(1) |
Jun
(4) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alan W. I. <Ala...@gm...> - 2020-02-23 22:47:22
|
Orion asked: > I see that plplot git master requires lasi-1.1.4 which does not appear to be released. What is the plan here? Hi Orion: Good question. The plan is to release lasi-1.1.4 first, then the next version of PLplot where lasi is currently closer to release than PLplot. However, an old astrophysical research topic of mine (FreeEOS) has recently become quite interesting again so all my release plans for both lasi and PLplot are currently on hold. That said, I do hope to find some spare time to work on the lasi-1.1.4 release in the next month or so, and when that release occurs I will certainly let you know since I strongly appreciate your on-going Fedora packaging efforts. By the way, lasi-1.1.4 will fix some obvious libLASi underlinking issues that have become exposed by recent versions of GTK+. So I really do view lasi-1.1.4 as the minimum version of that library that is acceptable for PLplot on all platforms (such as Fedora, presumably) that use recent versions of GTK+. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <Ala...@gm...> - 2019-02-14 18:04:51
|
On 2019-02-13 23:31-0500 Ed Trager wrote: > Hi, Alan, > > Please check out the web site, unifont.org/lasi/ > The old site is still available for comparison at unifont.org/lasi_orig/ , > just in case you need to check something. > > Best -- Ed Thanks, Ed, for that update. I wrote you last night before looking at incoming e-mail (which I did just now) so our mails crossed. To summarize that e-mail what you need to do to deal with the additional svn commit from me (that implements margins and a drop shadow for the preview of our example image), execute "svn update", then copy the (slightly changed) index.html and new images/PreviewDropComplexTextLayoutExample.png and images/README_Preview to the unifont.org/lasi file area. I think you will agree this change substantially improves the looks of the preview image of the example that is embedded in the introduction. I have been staring at this new version of the LASi website so much over the last several days on my own local html server that I cannot see remaining flaws (if any) there or in the (now slightly older version) at unifont.org/lasi. That is, other than the preview image in the introduction (which you should address by the steps above) I am satisfied with unifont.org/lasi. However, after you apply the above preview image change, if you spot anything else there that you feel needs further work, please let me know. I did click on both the validation icons at unifont.org/lasi, and both the xhtml and CSS content validate. However, if you attempt validation of unifont.org using the icons there, that particular webpage has a few xhtml validation errors which I assume you will want to address. Furthermore, the CSS icon at unifont.org is not set up properly so it just visits the CSS validation site without automatically validating. So you probably want to copy the relevant html fragment for CSS validation from unifont.org/lasi/index.html to unifont.org/index.html to address that issue. Alan > > > On Wed, Feb 13, 2019 at 5:19 AM Alan W. Irwin <Ala...@gm...> > wrote: > >> Hi Ed: >> >> I have completed my work on the LASi website. >> >> To see all the associated commit messages, and changed >> files, run the commands >> >> svn checkout https://svn.code.sf.net/p/lasi/code/trunk lasi_2019 >> >> (where the lasi_2019 directory should not exist before this command). >> >> Followed by, >> >> cd lasi_2019/www >> svn update >> svn log --verbose --revision HEAD:224 |less >> >> You will see from that log, that my changes consist solely of changes >> to index.html and adding the binary files >> images/ComplexTextLayoutExample.png and images/UniEncWhite.gif. Also, >> you will find in that log my motivation for my changes to index.html, >> and the extensive checking I did of those updated results. >> >> To see my index.html changes in diff form use the command >> >> svn diff --revision 224:HEAD www/index.html |less >> >> which will show the changes have been extensive (almost a complete >> rewrite of the ordinary text in this file, see my motivation remarks). >> >> This is just static content, so you can also look at what the revised >> result looks like in its entirety by using a browser to look at the >> actual new index.html file in your working svn directory. And you can >> simultaneously browse the unchanged unifont.org/lasi in another tab to >> help you to evaluate my changes. >> >> Note, that the style of the revised website should be completely >> unchanged since I changed no CSS-related material in index.html nor in >> the css subdirectory. >> >> Once you are satisfied with these changes, all you have to do to >> update your website is copy index.html and the new files >> images/ComplexTextLayoutExample.png and images/UniEncWhite.gif to the >> lasi subdirectory of your unifont.org site. >> >> I like my rewrite of the text in index.html, and I hope you do as well! >> >> Best wishes, >> >> Alan >> __________________________ >> Alan W. Irwin >> >> Programming affiliations with the FreeEOS equation-of-state >> implementation for stellar interiors (freeeos.sf.net); the Time >> Ephemerides project (timeephem.sf.net); PLplot scientific plotting >> software package (plplot.sf.net); the libLASi project >> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); >> and the Linux Brochure Project (lbproject.sf.net). >> __________________________ >> >> Linux-powered Science >> __________________________ >> >> >> _______________________________________________ >> Lasi-devel mailing list >> Las...@li... >> https://lists.sourceforge.net/lists/listinfo/lasi-devel >> > __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <Ala...@gm...> - 2019-02-14 05:58:10
|
On 2019-02-13 13:50-0000 Trager, Edward wrote: > Great, Alan, > > > I will get to this hopefully this evening. Unfortunately, I only have access to that hosting provider from my laptop at home. Hi Ed: I woke up this (Wednesday) morning with one more website idea which was to add a real preview image of ComplexTextLayoutExample.png that includes margins and drop shadow. I am not that familiar with inkscape so it was a bit of a struggle, but I finally achieved success. And the result is a noticeable improvement over the previous preview (generated via xhtml code to simply scale ComplexTextLayoutExample.png to render the preview so there was no margin or drop shadow for that previous preview). I just committed this change so you should be able to obtain this additional work with svn update (assuming you have already done the checkout command below). But if you haven't gotten that far yet, svn checkout https://svn.code.sf.net/p/lasi/code/trunk lasi_2019 will pick up this change as well. Note this improvement adds two additional files so the total list of files you need to copy to your unifont.org website directory is as follows: updated index.html and the new files images/ComplexTextLayoutExample.png, images/UniEncWhite.gif, images/PreviewDropComplexTextLayoutExample.png, and images/README_Preview. I doubt very much I will come up with any more bright ideas for this website, i.e., I am completely satisfied with it now. :-) I look forward to this new libLASi website going live. Alan > ________________________________ > From: Alan W. Irwin <Ala...@gm...> > Sent: Wednesday, February 13, 2019 5:19:10 AM > To: Trager, Edward > Cc: las...@li...; Lawrence Siden > Subject: My changes to the svn version of the LASi website have now been completed > > External Email - Use Caution > > Hi Ed: > > I have completed my work on the LASi website. > > To see all the associated commit messages, and changed > files, run the commands > > svn checkout https://svn.code.sf.net/p/lasi/code/trunk lasi_2019 > > (where the lasi_2019 directory should not exist before this command). > > Followed by, > > cd lasi_2019/www > svn update > svn log --verbose --revision HEAD:224 |less > > You will see from that log, that my changes consist solely of changes > to index.html and adding the binary files > images/ComplexTextLayoutExample.png and images/UniEncWhite.gif. Also, > you will find in that log my motivation for my changes to index.html, > and the extensive checking I did of those updated results. > > To see my index.html changes in diff form use the command > > svn diff --revision 224:HEAD www/index.html |less > > which will show the changes have been extensive (almost a complete > rewrite of the ordinary text in this file, see my motivation remarks). > > This is just static content, so you can also look at what the revised > result looks like in its entirety by using a browser to look at the > actual new index.html file in your working svn directory. And you can > simultaneously browse the unchanged unifont.org/lasi in another tab to > help you to evaluate my changes. > > Note, that the style of the revised website should be completely > unchanged since I changed no CSS-related material in index.html nor in > the css subdirectory. > > Once you are satisfied with these changes, all you have to do to > update your website is copy index.html and the new files > images/ComplexTextLayoutExample.png and images/UniEncWhite.gif to the > lasi subdirectory of your unifont.org site. > > I like my rewrite of the text in index.html, and I hope you do as well! > > Best wishes, > > Alan > __________________________ > Alan W. Irwin > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ********************************************************** > Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues > __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <Ala...@gm...> - 2019-02-13 10:19:26
|
Hi Ed: I have completed my work on the LASi website. To see all the associated commit messages, and changed files, run the commands svn checkout https://svn.code.sf.net/p/lasi/code/trunk lasi_2019 (where the lasi_2019 directory should not exist before this command). Followed by, cd lasi_2019/www svn update svn log --verbose --revision HEAD:224 |less You will see from that log, that my changes consist solely of changes to index.html and adding the binary files images/ComplexTextLayoutExample.png and images/UniEncWhite.gif. Also, you will find in that log my motivation for my changes to index.html, and the extensive checking I did of those updated results. To see my index.html changes in diff form use the command svn diff --revision 224:HEAD www/index.html |less which will show the changes have been extensive (almost a complete rewrite of the ordinary text in this file, see my motivation remarks). This is just static content, so you can also look at what the revised result looks like in its entirety by using a browser to look at the actual new index.html file in your working svn directory. And you can simultaneously browse the unchanged unifont.org/lasi in another tab to help you to evaluate my changes. Note, that the style of the revised website should be completely unchanged since I changed no CSS-related material in index.html nor in the css subdirectory. Once you are satisfied with these changes, all you have to do to update your website is copy index.html and the new files images/ComplexTextLayoutExample.png and images/UniEncWhite.gif to the lasi subdirectory of your unifont.org site. I like my rewrite of the text in index.html, and I hope you do as well! Best wishes, Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <Ala...@gm...> - 2019-02-02 02:15:26
|
This is an important release because it fixes a major showstopper bug for the library which has recently been exposed because pango/fontconfig now often chooses a pure bitmapped font (such as the popular Noto Color Emoji) to render the glyphs in certain PangoItems (e.g., any such item that include glyphs for one of the signs of the Zodiac such as Aries). This release contains two other important bug fixes and a number of fixes for smaller issues as well. For more details see <https://sourceforge.net/p/lasi/news/2019/02/liblasi-113-has-been-released/>. Larry and Ed: our website for libLASi at <http://www.unifont.org/lasi/> is out of date, and you are the only ones I am aware of with the privileges to update that website. Fortunately, it should be straightforward to fix this problem with the following changes: * Update the release announcement part of <http://www.unifont.org/lasi/> to be consistent with <https://sourceforge.net/p/lasi/news/2019/02/liblasi-113-has-been-released/>. * Update the URL of the latest stable release on that page to https://sourceforge.net/projects/lasi/files/lasi/"1.1.3%20Source/libLASi-1.1.3.tar.gz * Update the generic build, test, and install instructions on that page to the following: 1) CMake 3.13.2 or later is required by the libLASi build system. So if your platform provides such a version of CMake install it. Otherwise, build the latest version of CMake (3.13.3 as of 2019-02-01). Note, you can do that build with an older version of cmake that you have already installed on your platform. Furthermore, on Unix-like platforms (e.g., Linux, Mac OS X, Cygwin, MinGW-w64/MSYS2) if no version of cmake is installed, you can build the latest version of CMake using the bootstrap script provided with the CMake source tree. If such CMake builds are necessary for your platform, you must put the installed result highest on your PATH so that it is used for the subsequent libLASi build. 2) Create an empty libLASi build directory and cd to it using a modern shell such as bash: mkdir build_dir cd build_dir 3) Configure libLASi using cmake: cmake -DCMAKE_INSTALL_PREFIX=</path/to/install/prefix> </path/to/lasi/source/code> >& cmake.out 4) Build the library and its (doxygen-generated) documentation make all >& all.out 5) Test the library ctest >& ctest.out 6) Install the library make install >& install.out N.B. after each of the steps above, check the resulting *.out files for any errors, and make the appropriate changes to overcome those errors. For example, if cmake.out tells you "Build of libLASi requires pkg-config." or "pangoft2, pango, and freetype2 pkg-config module required to build libLASi." then address such issues by installing the appropriate packages or adjusting the PKG_CONFIG_PATH or PATH environment variables appropriately so that CMake finds the necessary software for the libLASi build. * For the Linux platform-specific notes drop the last qualifier sentence: "A possible exception is CMake : be sure to get at least version 2.4.5." since that sentence is fully covered by what I said above about getting access to CMake-3.13.2. * @Larry or Ed: For the Mac OS X platform-specific notes, my impression is those voluminous details concerning workarounds are all outdated since Fink, MacPorts, and HomeBrew should all have considerably improved since you last tried them. So my prediction is the above generic instructions will "just work" on any of those platforms without any of the many caveats you are mentioning now. Anyhow, by all means, please test libLASi-1.1.3 on any/all of these platforms, and if I am right, the remarks for these platforms should all be reduced to one sentence or so. MacPorts and HomeBrew already supply CMake-3.13.3. However, one minor caveat for Fink is that distribution seems a bit behind in the version of CMake that it supplies (3.11.0). So if you use Fink you will have to build the latest CMake. But as in the Linux case there is no need to mention that specifically because that is already covered in the generic build instructions above. * @Arjen: would you be willing to build, test, and install libLASi-1.1.3 on your MinGW/w64/MSYS2 and Cygwin platforms? If that works, your subsequent PLplot tests on those platforms should just work with the psttf and psttfc devices (assuming you adjust your PATH so that the installed version of libLASi can be found for each different platform). Note that libLASi depends on a subset of the GTK+ suite of libraries and that project itself recommends MinGW-w64/MSYS2 on Windows (likely because they are rightly, see below, concerned about the inevitable ABI issues for the MSVC platform). Although you already know plenty about that platform through your reading of all the topics covered by <https://github.com/msys2/msys2/wiki>, you might also want to look at the GTK+ instructions for that platform at <https://www.gtk.org/download/windows.php>. They specifically recommend installing mingw-w64-x86_64-gtk3, mingw-w64-x86_64-toolchain, and several other packages, but I think the first two are the essential ones, and you have likely installed those already because of the PLplot "cairo" device driver needs). Anyhow, once you have your MinGW-w64/MSYS2 done correctly, I think the above generic libLASI build, test, and install directions should "just work" and similarly for Cygwin. Of course, these platforms are subject to the caveat that you will have to build the latest CMake on each platform since (at least for the next little while) MinGW/w64/MSYS2 supplies CMake-3.12.4, and Cygwin supplies 3.13.1, i.e., these rolling releases seem to be behind the latest CMake version (3.13.3) which normally they should supply as a matter of course. Anyhow, if you have time to do such tests in the near future, please report the results here so that Larry or Ed can update the website appropriately, e.g., with any luck reduce the Windows platform-specific notes to one or two sentences for those Unix-like platforms. @ Larry and Ed: I am virtually certain that libLASi will run into ABI consistency issues with the subset of the GTK+ libraries it needs for the MSVC version of the Windows platform so I think we should not bother testing that platform or encourage libLASi users to even try it. Anyhow, regardless of what Arjen reports for the MinGW/w64/MSYS2 and Cygwin platforms, the Windows platform-specific notes on the libLASi website should be updated to specifically exclude the MSVC platform because of that ABI issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Lasi-devel mailing list Las...@li... https://lists.sourceforge.net/lists/listinfo/lasi-devel |
From: Alan W. I. <Ala...@gm...> - 2019-01-19 22:43:27
|
On 2019-01-12 13:52-0800 Alan W. Irwin wrote: > I have made some progress on this bug by eliminating some approaches > to it that I was considering. > > Within the for_each_glyph_do method, I have confirmed that the > outer loop over pango items splits the input string into pieces that > can all be handled with the same face (defined as a freetype2 font of > fixed family, slant, weight, and width). So, for example, for the > Aries glyph that exposes this bug, the inner loop just has one glyph, > and it uses a fixed face with face->family_name of "Noto Color Emoji" > which is, if course, completely unsuitable for the outline font needs > of libLASi. > > One approach I did implement (because it involved minimal changes to > the code) was to call for_each_glyph_do recursively with a > one-character blank (" ") string whenever there was an error in the > inner loop. But that simple and reasonably fast approach (because > the recursion rarely occurs) approach failed with a segfault presumably > because either the for_each_glyph_do method *or one of the methods it > calls* are not recursion-safe. > > That is a lot of code to look through with no guarantee that the > problem would be easy to fix once I found the part that was not > recursion safe. So I have dropped that approach, and I am currently > looking again at the possibility of calculating an ER (Emergency > Response) face corresponding to the ER blank glyph string and > substituting that ER string and face whenever the original face > encounters an error for any glyph. > > I am confident this approach will work and won't cost too much in > terms of efficiency, but the stumbling block is I am just not that > familiar with the pango and freetype2 library calls (much obfuscated > in the current code because of the pango_itemize outer loop) that are > necessary to figure out the ER version of face corresponding to the ER > blank glyph string. And my current level of C++ skills is not exactly > helping. So its going to take me a while to figure this out. Short story: I have finally had success substituting an ER string for those glyphs where the inner loop over glyphs for a given PangoItem errors out. Longer story: I kept running into the same segfault problem no matter what I tried (in fact it was likely the reason why the recursion idea failed above), but today the light finally dawned. When the inner loop that iterates over glyphs errors out for any reason (e.g., due to a missing glyph for a suitable outline font or due to a completely unsuitable pure bitmap font being found by pango), it is necessary to erase the corresponding half-completed glyphmap item for the bad glyph. Once that additional change was made, all memory management issues (other than memory leaks) reported by valgrind drop to zero. I am not happy it took me so long to find this glyphmap erase solution, but at least I know a bit more about C++ maps and other C++ topics now. I plan to follow up on this success by releasing libLASi 1.1.3 with this important ER string substitution fix as soon as possible. (Since no other libLASi developer has yet responded to this discussion I assume you do not want to be involved in testing this release, but if you do want to participate in such testing please get in touch with me immediately.) More later (once that release is out the door). Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <Ala...@gm...> - 2019-01-12 21:52:44
|
I have made some progress on this bug by eliminating some approaches to it that I was considering. Within the for_each_glyph_do method, I have confirmed that the outer loop over pango items splits the input string into pieces that can all be handled with the same face (defined as a freetype2 font of fixed family, slant, weight, and width). So, for example, for the Aries glyph that exposes this bug, the inner loop just has one glyph, and it uses a fixed face with face->family_name of "Noto Color Emoji" which is, if course, completely unsuitable for the outline font needs of libLASi. One approach I did implement (because it involved minimal changes to the code) was to call for_each_glyph_do recursively with a one-character blank (" ") string whenever there was an error in the inner loop. But that simple and reasonably fast approach (because the recursion rarely occurs) approach failed with a segfault presumably because either the for_each_glyph_do method *or one of the methods it calls* are not recursion-safe. That is a lot of code to look through with no guarantee that the problem would be easy to fix once I found the part that was not recursion safe. So I have dropped that approach, and I am currently looking again at the possibility of calculating an ER (Emergency Response) face corresponding to the ER blank glyph string and substituting that ER string and face whenever the original face encounters an error for any glyph. I am confident this approach will work and won't cost too much in terms of efficiency, but the stumbling block is I am just not that familiar with the pango and freetype2 library calls (much obfuscated in the current code because of the pango_itemize outer loop) that are necessary to figure out the ER version of face corresponding to the ER blank glyph string. And my current level of C++ skills is not exactly helping. So its going to take me a while to figure this out. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <Ala...@gm...> - 2019-01-10 22:42:06
|
To my fellow libLASi developers: It has been a long time without posts to this list. The reason of course, is that libLASi has been quite reliable over the years doing its one task quite well. However, a substantial problem has just showed up with it which is whenever fontconfig decides the best font to represent a particular glyph is a pure bitmap font such as Noto Color Emoji (the well-regarded font distributed by google), then libLASi is bound to fail (throws an error and aborts) with that font since its whole approach is based on outline fonts (and should stay that way). See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918774> for the details of how this bug showed up in PLplot and also a simple variant of MissingGlyphExample.cpp for a fairly ordinary single glyph representing the first (Aries) sign of the zodiac, which is Unicode U+2648 = ♈. I think it is worth some effort to deal with this issue if at all possible since libLASi still remains consistently popular. For example, there have been some ~2500 downloads of libLASi from SF since 2014-01-01 with download interest remaining essentially constant at ~40 downloads per month for all of that time. Another way of saying this is libLASi provides a really nice PostScript feature in a convenient way that is still much appreciated, and that language is obviously not dead yet! The relevant part of the code (from psDoc.cpp) that is failing for all-bitmap fonts is if (0 == static_cast<FT_Glyph>(glyphMgr)) { // if glyph is not in map // // access glyph from font face and put it in map // FT_Glyph glyph; // // DEBUG: // //std::cerr << "Glyph Index: " << glyph_index << std::endl; FT_Error error = FT_Load_Glyph(face,glyph_index,FT_LOAD_NO_BITMAP); if(error){ // //DEBUG: // //std::cerr << "PANGO is returning a glyph index of " << std::hex << glyph_index << std::endl; //std::cerr << "but PANGO_GLYPH_UNKNOWN_FLAG is supposed to be: " << 0x10000000 << std::endl; //std::cerr << "and PANGO_GLYPH_EMPTY is supposed to be: " << 0x0FFFFFFF << std::endl; // // Substitute something that works: All fonts are supposed // to handle glyph_index 0 as the default replacement glyph: // evalReturnCode(FT_Load_Glyph(face,0,FT_LOAD_NO_BITMAP),"FT_Load_Glyph"); }else{ evalReturnCode(FT_Load_Glyph(face, glyph_index,FT_LOAD_NO_BITMAP), "FT_Load_Glyph"); } evalReturnCode(FT_Get_Glyph(face->glyph, &glyph), "FT_Get_Glyph"); It's that "evalReturnCode(FT_Load_Glyph(face,0,FT_LOAD_NO_BITMAP),"FT_Load_Glyph");" that is failing, and the reason for that is it returns exactly the same error code as for non-zero glyph_index. That is, by this part of the code face is already set (in this case to Noto Color Emoji) so regardless of glyph_index it will error out the same way. In this case, the error code is 0x24 which from <https://www.freetype.org/freetype2/docs/reference/ft2-error_code_values.html> corresponds to "invalid size handle". But if we addressed that issue, it would simply fail later because of the fundamental issue which is pure bitmap fonts are absolutely no use to libLASi. So I believe a much more reliable approach to deal with *any* unsuitable face found by pango/fontconfig would be to predefine a special face and non-printing glyph corresponding to, say, Unicode U+0000 = ascii null. And always substitute that face and glyph whenever there is an error. So please let me know if you can think of any way the above approach is not robust against unsuitable faces delivered by pango/fontconfig. I suspect implementing the above idea for somebody with good C++ skills would be trivial for them, but if nobody here can interrupt what they are doing to do that, I will try to implement that idea myself even though it will probably take me much longer. Once the above bug fix idea has been implemented and thoroughly tested with the libLASi examples and also PLplot, then I plan to also update the libLASi build system to modern CMake standards, and release libLASi 1.1.3 soon after. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-07-26 23:46:27
|
Sorry this took way too long because I kept being distracted by other things. But at last, I finally got liblasi-1.1.2 released. For the release announcement, see https://sourceforge.net/p/lasi/news/2014/07/liblasi-112-has-been-released. Ed, could you please update the release announcement part of http://www.unifont.org/lasi/ appropriately? Also, please update the URL of the latest stable release on that page to https://sourceforge.net/projects/lasi/files/lasi/"1.1.2%20Source/libLASi-1.1.2.tar.gz Also, replace the extremely dated Windows build instructions on that page by the following (these instructions are essentially what Arjen Markus used to test libLASi-1.1.2): ___________ 1) Follow the directions at http://www.gtk.org/download/win32.php to download the latest all-in-one bundle (currently http://win32builder.gnome.org/gtk+-bundle_3.6.4-20130921_win32.zip). 2) After unpacking that zip file, follow the directions in gtk+*/README.txt (e.g., gtk+-bundle_3.6.4-20130921_win32.README.txt in the above zip archive) to set up gtk+. 3) Set environment variables so that cmake can find all the required files in the gtk bundle. set PKG_CONFIG_PATH=%USER_ROOTDIR%\gtk\lib\pkgconfig set PATH=%USER_ROOTDIR%\gtk\bin;%PATH% where USER_ROOTDIR is the location of the top-level directory for the gtk+ bundle. 4) Build libLASi in a command line environment: cd to the top-level lasi-1.1.2 source tree which you have unpacked from the lasi-1.1.2.tar.gz tarball mkdir build cd build cmake -G "MinGW Makefiles" -DBUILD_SHARED=ON -DCMAKE_INSTALL_PREFIX=%USER_ROOTDIR% ../lasi mingw32-make install Put the dll subdirectory of build on your PATH and run ctest ___________ Thanks in advance for that http://www.unifont.org/lasi/ update. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-07-16 21:01:30
|
On 2014-04-30 13:00-0700 Alan W. Irwin wrote: > Regardless of whether I am using the version of example2 from the > build tree or the installed examples tree, I get different order > of the glyph definitions _every_ time I run > > ./example2 example.ps, e.g., > > software@raven> ./example2 example2.ps > software@raven> grep -n Japanese example2.ps > 152:/IQZNMMRRJOOSCLAR-Droid-Sans-Japanese-Regular-5802 { > 308:/PHYOZVOBFFIBUHBS-Droid-Sans-Japanese-Regular-5959 { > 500:/TZFSUUUAZDBULCMT-Droid-Sans-Japanese-Regular-3752 { > 4670:22 PHYOZVOBFFIBUHBS-Droid-Sans-Japanese-Regular-5959 > 4672:22 IQZNMMRRJOOSCLAR-Droid-Sans-Japanese-Regular-5802 > 4674:22 TZFSUUUAZDBULCMT-Droid-Sans-Japanese-Regular-3752 > software@raven> ./example2 example2.ps > software@raven> grep -n Japanese example2.ps > 86:/CDNJWLWGSMAYFTCE-Droid-Sans-Japanese-Regular-3752 { > 565:/XSANGSXNKHQTFTTE-Droid-Sans-Japanese-Regular-5959 { > 613:/YSUPKCDAETQLDJDA-Droid-Sans-Japanese-Regular-5802 { > 4670:22 XSANGSXNKHQTFTTE-Droid-Sans-Japanese-Regular-5959 > 4672:22 YSUPKCDAETQLDJDA-Droid-Sans-Japanese-Regular-5802 > 4674:22 CDNJWLWGSMAYFTCE-Droid-Sans-Japanese-Regular-3752 Hi Ed: I have finally figured out a fix for this issue! The problem appears to be due to the use of rand in the nameof static function defined in src/psDoc.cpp. (For your information you introduced this code back in 2004 to deal with the case where the glyph has no name entry, and I am sure you remember that fix just like it was yesterday. :-) ) When I replaced rand by rand_r, the above repeatability issue (also documented at <http://sourceforge.net/p/lasi/bugs/5/> completely disappears. See the commit message for revision 191 concerning my working hypothesis for why rand does not generate repeatable sequences for libLASi while rand_r does produce repeatable sequences. Now that all the bug reports have finally been dealt with, I hope to get the libLASi-1.1.2 release process restarted later today or early tomorrow. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-06-24 19:31:36
|
On 2014-06-24 02:18-0700 Alan W. Irwin wrote: > On 2014-06-22 15:42-0700 Alan W. Irwin wrote: > >> (1) to finish PLplot tests (on both Linux >> and Wine) of the psttfc device (which indirectly tests the >> libLASi-1.1.2 internal release candidate I have built), and (2) to >> complete the release process for libLASi-1.1.2 with a big mention of >> this bug and a call for help in fixing it in the release notes. > > I have completed (1) for Linux, but for the Wine version of Windows I > ran into segfaults at run-time for example[012]. > > For those here who want to attempt to replicate this issue on > Microsoft Windows, here is what I did. [...] I also asked Arjen Markus (a PLplot developer with access to Microsoft Windows who is not subscribed to this list) whether he would be willing to attempt to replicate these segfault issues, and he was kind enough to make that attempt. It turns out Arjen encountered no segfaults when using the Microsoft version of Windows. Furthermore, I compared each glyph's text rendering in his PostScript results with the known good results in examples/*.png. His results were perfect (unlike the corresponding Linux PostScript results that are generated by libLASi where pango makes a mess of the first word of the long Thai sentence in example2.ps). Therefore, I have ascribed the segfault issues I encountered to a Wine bug, and it is time for me to finally proceed with (2) above. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-06-24 09:18:20
|
On 2014-06-22 15:42-0700 Alan W. Irwin wrote: > (1) to finish PLplot tests (on both Linux > and Wine) of the psttfc device (which indirectly tests the > libLASi-1.1.2 internal release candidate I have built), and (2) to > complete the release process for libLASi-1.1.2 with a big mention of > this bug and a call for help in fixing it in the release notes. I have completed (1) for Linux, but for the Wine version of Windows I ran into segfaults at run-time for example[012]. For those here who want to attempt to replicate this issue on Microsoft Windows, here is what I did. You can find rather dated Windows build directions at http://www.unifont.org/lasi/ Here are my modifications to those. I. Modifications to the very dated instructions 1-3 for installing prerequisites for libLASi which have lots of complications that are no longer necessary since the gtk+ all-in-one-bundle should provide everything needed. I followed the directions at http://www.gtk.org/download/win32.php to get the latest gtk+ all-in-one bundle, http://win32builder.gnome.org/gtk+-bundle_3.6.4-20130921_win32.zip After unpacking that zip file I followed the directions in gtk+-bundle_3.6.4-20130921_win32.README.txt to setup gtk+. Note, I like my big Windows software bundles to all have unique install prefixes so I can easily remove/replace them without disturbing anything else. So for my case, I modified those directions to use a unique install prefix, and it is obviously a matter of taste whether you do that or use the default install prefix. II. Modifications to instruction 4. I didn't set USER_ROOTDIR, but I did set PATH and PKG_CONFIG_PATH environment variables appropriately. III. Modifications to instruction 5. Those instructions are to configure (with cmake, although it is called make in error), build, and install libLASi. Instead, I just ran cmake, then put the dll directory in the build tree on my PATH then did cd examples make example0 (This builds not only example0, but its prerequisite, libLASi.) I then ran ./example0 example0.ps which produces a segfault. Similarly, make example1 and make example2 build those examples without issues, but attempting to run those examples also generates segfaults. Note, the gtk+ all-in-one bundle described above works fine for me on Wine for the PLplot cairo device driver (where that driver depends on the pango subset of gtk+). But this is the first time in years that I have tried such a downloaded gtk+ bundle, and as far as I can remember my previous attempt to use a much older gtk+ bundle ran into ABI compiler version inconsistency issues for the PLplot cairo device driver. Thus, I am pretty sure I never got around to attempting to build and test libLASi (or the psttf PLplot device driver that depends on libLASi) back then on Wine. So as far as I am aware, the only Windows test our development group has done before was by Werner for our first SourceForge-based release of libLASi, but I presume his test back then were quite thorough since he is the author of all code changes that were required to get libLASi to work on Windows. To proceed further, I think the first obvious step is to eliminate some issue with the Wine version of Windows that I am using or the font setup on that platform as a potential source for the issue by attempting to replicate the above test on a Microsoft version of Windows. So I hope someone here with access to Microsoft Windows is willing to try that. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Ed T. <ed....@gm...> - 2014-06-23 14:45:40
|
Hi, Alan, I wish I had a good guess about what might cause this behavior, but currently I haven't a clue. And unfortunately I have zero time to look at this now. Best - Ed On Sun, Jun 22, 2014 at 6:42 PM, Alan W. Irwin <ir...@be...> wrote: > It appears that for the last month nobody on this list with the > required C++, libLASi, and libpango skills has had the time to > investigate this "random" glyph reordering/renaming bug. So I am going > with the following plan: > > I have just completed a bug report > <https://sourceforge.net/p/lasi/bugs/5/> for libLASi that describes > the problem. If you read that bug report, you will notice I have also > now demonstrated the issue (randomly reordered and renamed glyph > results) for example 24 (the "Peace Flag" example) for PLplot as well > as the example2 application where I originally found the issue. > > The next two steps I have planned (unless someone decides to work on > this bug immediately) are (1) to finish PLplot tests (on both Linux > and Wine) of the psttfc device (which indirectly tests the > libLASi-1.1.2 internal release candidate I have built), and (2) to > complete the release process for libLASi-1.1.2 with a big mention of > this bug and a call for help in fixing it in the release notes. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Lasi-devel mailing list > Las...@li... > https://lists.sourceforge.net/lists/listinfo/lasi-devel > |
From: Alan W. I. <ir...@be...> - 2014-06-22 22:42:35
|
It appears that for the last month nobody on this list with the required C++, libLASi, and libpango skills has had the time to investigate this "random" glyph reordering/renaming bug. So I am going with the following plan: I have just completed a bug report <https://sourceforge.net/p/lasi/bugs/5/> for libLASi that describes the problem. If you read that bug report, you will notice I have also now demonstrated the issue (randomly reordered and renamed glyph results) for example 24 (the "Peace Flag" example) for PLplot as well as the example2 application where I originally found the issue. The next two steps I have planned (unless someone decides to work on this bug immediately) are (1) to finish PLplot tests (on both Linux and Wine) of the psttfc device (which indirectly tests the libLASi-1.1.2 internal release candidate I have built), and (2) to complete the release process for libLASi-1.1.2 with a big mention of this bug and a call for help in fixing it in the release notes. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-05-17 17:39:33
|
On 2014-04-30 15:19-0700 Alan W. Irwin wrote: > The important point, however, is the strange result > (different glyph order each time the application is run) is still > present when libLASi is built against modern versions of > pango/cairo/harfbuzz. If you confirm the above strange result for whatever > versions of pango/cairo/harfbuzz are installed on your platform that > strengthens the case that the issue is with the libLASi code rather > than with the libLASi dependencies. Ed replied to me off list some time ago that he doesn't have time right now even to confirm this issue on the platforms accessible to him. The current status is I have gotten distracted by some PLplot issues that have just come up so the libLASi release still remains on hold in any case. Furthermore, that hold will continue until I can include libLASi in my epa_build-supported comprehensive testing of PLplot and its dependencies both on Linux and Wine. So there is still time to do further investigation of the above issue before the release if anyone in this development team for libLASi is interested in doing so. But if not, my backup plan is to assemble a bug report concerning the above issue based on my results on Debian stable, then go ahead with the release anyway because the current release does solve the issue with linking to modern Freetype. And in the release notes I will refer to the bug report and request help from our users to investigate further. Of course, that is not an ideal result so I hope one of you does have the time to investigate further. For example, I have confirmed the issue exists for widely different versions of the pango/cairo/harbuzz/fontconfig dependencies. But those tests were all done with the same (Debian stable) fonts, and if if it turns out the issue doesn't exist on platforms other than Debian stable, we could write this off as likely due to some issue with Debian stable fonts that has been fixed in more modern Linux distributions. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-04-30 22:19:30
|
On 2014-04-30 16:36-0400 Ed Trager wrote: > My suspicion is that this stems not from libLASi, but from Pango which, one > hopes, is calling HarfBuzz. > > What version of Pango is being used? > What version of HarfBuzz is present on the machine? > > Honestly, I have not looked at Pango in so long I now no longer know the > details of how it is organized. In the old days, HarfBuzz did not exist, > and Pango did it's own thing with respect to layout. In the "new days" > presumably HarfBuzz is slowly if not quickly replacing the older layout > engines (Pango, ICU, and whatever QT was using). Hi Ed: I assume you have dropped las...@li... from the list of recipients by accident. Anyhow, I hope you don't mind that I have restored that since I think it is important we keep everyone on that list informed of how we are progressing with these release issues. To respond to your general comments about library relationships above, I take my knowledge of that from http://en.wikipedia.org/wiki/HarfBuzz which says the following: HarfBuzz (loose Latin transliteration of Persian: حرفباز, "Opentype"[1]) is a software development library for shaping of Unicode text[when defined as?]. The most recent incarnation of HarfBuzz ("New HarfBuzz") targets various font technologies while the first version ("Old HarfBuzz") targeted only OpenType fonts.[2] New HarfBuzz provides only text shaping functionality and not text layout or rendering, which require other libraries. Pango (which incorporates HarfBuzz) can be used for higher-level text layout, and FreeType or Anti-Grain Geometry for text rendering. So in sum, pango is now partially (but not fully) replaced by harbuzz. To answer your specific questions above, Debian stable (my platform) has no HarfBuzz package so its pango package (version 1.30.0) is evidently an old pango standalone version, and that is the version used for the previous tests. Note also the corresponding cairo package on that platform is version 1.12.2. However, I do have my own build of modern pango/cairo/harfbuzz on that machine so I switched the libLASi build to those versions for the following test of glyph order (for what it is worth, done in the examples subdirectory of the build tree). software@raven> ./example2 example2.ps Fontconfig warning: "/home/wine/newstart/build_script/install-linux/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. software@raven> grep -ni fallback example2.ps 221:/QDQTDQUPQFXDGZFI-Droid-Sans-Fallback-Regular-19719 { 412:/TQUDRVWGIKSIDTJT-Droid-Sans-Fallback-Regular-18782 { 591:/WAMZQHPGNMJTMPBG-Droid-Sans-Fallback-Regular-11932 { 4654:22 QDQTDQUPQFXDGZFI-Droid-Sans-Fallback-Regular-19719 4656:22 TQUDRVWGIKSIDTJT-Droid-Sans-Fallback-Regular-18782 4658:22 WAMZQHPGNMJTMPBG-Droid-Sans-Fallback-Regular-11932 software@raven> ./example2 example2.ps Fontconfig warning: "/home/wine/newstart/build_script/install-linux/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. software@raven> grep -ni fallback example2.ps 86:/DXRGIRMPETDBBGYG-Droid-Sans-Fallback-Regular-11932 { 170:/FVQCDUBLMVFOKGBB-Droid-Sans-Fallback-Regular-18782 { 368:/QXVQCLZGHNGNXIDW-Droid-Sans-Fallback-Regular-19719 { 4654:22 QXVQCLZGHNGNXIDW-Droid-Sans-Fallback-Regular-19719 4656:22 FVQCDUBLMVFOKGBB-Droid-Sans-Fallback-Regular-18782 4658:22 DXRGIRMPETDBBGYG-Droid-Sans-Fallback-Regular-11932 Note that for this new test the pango/cairo/harfbuzz versions are 1.35/1.12.14/0.9.19, and for this case "Droid-Sans-Japanese-Regular" has vanished from the Glyph ID's and is replaced by Droid-Sans-Fallback-Regular. Which is why the above test now looks for "fallback". The important point, however, is the strange result (different glyph order each time the application is run) is still present when libLASi is built against modern versions of pango/cairo/harfbuzz. If you confirm the above strange result for whatever versions of pango/cairo/harfbuzz are installed on your platform that strengthens the case that the issue is with the libLASi code rather than with the libLASi dependencies. Anyhow, I still need an informed decision from you on what to do about this issue for this release so I think your first step should be to try to confirm this strange result. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-04-30 20:00:10
|
On 2014-04-30 09:52-0700 Alan W. Irwin wrote: > On 2014-04-29 16:54-0700 Alan W. Irwin wrote: > >> I am going to take a break now, but tomorrow I will first try the >> experiment of editing the PostScript file to reorder the glyphs in the >> same way to confirm (with diff on those modified results) that the >> postscript commands for each glyph are identical as assumed above from >> the identical-looking visual comparison results. > > That hypothesis has now been completely confirmed. In fact it turned > out the order of the 3 Japanese glyph definitions was the only > difference between example2 results for the build tree and installed > examples tree. > > I am now investigating several hypotheses (compile flags?, link > flags?, or glyph delivery order from pango/cairo depends on load?) > to explain those differences. > Hi Ed: I think this issue is going to need some expert attention from you. It turns out compile and link flags have nothing to do with the problem. Regardless of whether I am using the version of example2 from the build tree or the installed examples tree, I get different order of the glyph definitions _every_ time I run ./example2 example.ps, e.g., software@raven> ./example2 example2.ps software@raven> grep -n Japanese example2.ps 152:/IQZNMMRRJOOSCLAR-Droid-Sans-Japanese-Regular-5802 { 308:/PHYOZVOBFFIBUHBS-Droid-Sans-Japanese-Regular-5959 { 500:/TZFSUUUAZDBULCMT-Droid-Sans-Japanese-Regular-3752 { 4670:22 PHYOZVOBFFIBUHBS-Droid-Sans-Japanese-Regular-5959 4672:22 IQZNMMRRJOOSCLAR-Droid-Sans-Japanese-Regular-5802 4674:22 TZFSUUUAZDBULCMT-Droid-Sans-Japanese-Regular-3752 software@raven> ./example2 example2.ps software@raven> grep -n Japanese example2.ps 86:/CDNJWLWGSMAYFTCE-Droid-Sans-Japanese-Regular-3752 { 565:/XSANGSXNKHQTFTTE-Droid-Sans-Japanese-Regular-5959 { 613:/YSUPKCDAETQLDJDA-Droid-Sans-Japanese-Regular-5802 { 4670:22 XSANGSXNKHQTFTTE-Droid-Sans-Japanese-Regular-5959 4672:22 YSUPKCDAETQLDJDA-Droid-Sans-Japanese-Regular-5802 4674:22 CDNJWLWGSMAYFTCE-Droid-Sans-Japanese-Regular-3752 I have focussed just on the line numbers where Japanese glyphs appear because those were the ones I noticed were different from my initial comparison, but, of course, this test does not rule out that other non-Japanese glyphs could also sometimes be reordered as well. I ran valgrind on "./example2 example.ps", and there were no obvious issues other than some possible memory leaks. It is obviously far from ideal to have a gratuitously different PostScript file result each time you run the same command (even though the visual results were identical the only time I tested that). So I looked further at the code to see how that order was defined. It turns out the above results are generated by os << endl << '/' << glyphId.str() << " {" << endl; within PostscriptDocument::write_glyph_routine_to_stream, and that method is apparently called (from PostscriptDocument::write) for each glyph in the UTF-8 string being processed. So it appears to me the order of the glyph definitions should always be fixed (the same as the order encountered in the strings being processed), but that expected fixed order is obviously not happening from the results above so I am likely missing something obvious due to my limited C++ skills. Anyhow, I have come to the end of those skills. So would you be willing to take over to either (a) fix this problem or (b) make an informed decision that we should ignore this peculiar glyph definition order issue (which apparently did not occur for our prior releases) for this release? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-04-30 16:52:27
|
On 2014-04-29 16:54-0700 Alan W. Irwin wrote: > I am going to take a break now, but tomorrow I will first try the > experiment of editing the PostScript file to reorder the glyphs in the > same way to confirm (with diff on those modified results) that the > postscript commands for each glyph are identical as assumed above from > the identical-looking visual comparison results. That hypothesis has now been completely confirmed. In fact it turned out the order of the 3 Japanese glyph definitions was the only difference between example2 results for the build tree and installed examples tree. I am now investigating several hypotheses (compile flags?, link flags?, or glyph delivery order from pango/cairo depends on load?) to explain those differences. More later. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-04-29 23:54:56
|
Just in case you guys were wondering what the hold-up is on the release, I discovered literally ~5 minutes before I uploaded the release tarball to SF that the build tree and installed examples tree PostScript results for the second example are different for that tarball. "diff" shows quite extensive differences. I have done this same diff test for prior releases but never before saw any differences. At minimum, for this release it appears the glyphs are stored in different order and with different names in the build tree and installed examples tree cases. For example, notice how the names of the Japanese glyphs for example2.ps are different and appear in different order for the two cases. software@raven> grep Japanese example2.ps $build_tree_dir/examples/example2.ps example2.ps:/AKTZDVNDACJFMJTH-Droid-Sans-Japanese-Regular-3752 { example2.ps:/RTMWZSBNZFOGFKZN-Droid-Sans-Japanese-Regular-5959 { example2.ps:/UCBBSJILSOMIFHYW-Droid-Sans-Japanese-Regular-5802 { example2.ps:22 RTMWZSBNZFOGFKZN-Droid-Sans-Japanese-Regular-5959 example2.ps:22 UCBBSJILSOMIFHYW-Droid-Sans-Japanese-Regular-5802 example2.ps:22 AKTZDVNDACJFMJTH-Droid-Sans-Japanese-Regular-3752 /home/software/lasi_svn/HEAD/build_dir/tarball_build_dir/examples/example2.ps:/CHXIENJMWCXYJMLE-Droid-Sans-Japanese-Regular-5802 { /home/software/lasi_svn/HEAD/build_dir/tarball_build_dir/examples/example2.ps:/LMISOJCCPPIMJZKM-Droid-Sans-Japanese-Regular-3752 { /home/software/lasi_svn/HEAD/build_dir/tarball_build_dir/examples/example2.ps:/VZBDGBBKOFNFXTRY-Droid-Sans-Japanese-Regular-5959 { /home/software/lasi_svn/HEAD/build_dir/tarball_build_dir/examples/example2.ps:22 VZBDGBBKOFNFXTRY-Droid-Sans-Japanese-Regular-5959 /home/software/lasi_svn/HEAD/build_dir/tarball_build_dir/examples/example2.ps:22 CHXIENJMWCXYJMLE-Droid-Sans-Japanese-Regular-5802 /home/software/lasi_svn/HEAD/build_dir/tarball_build_dir/examples/example2.ps:22 LMISOJCCPPIMJZKM-Droid-Sans-Japanese-Regular-3752 Comparison of these PostScript results using the gv application show no obvious visual differences so I assume the set of PostScript commands stored for each glyph in the two cases is the same. But why would the glyphs be stored in a different order with a different name for the two cases? The principal difference between the two results is one version is built with our CMake-based build system, and one is built using ordinary Makefiles + pkg-config. Obviously, I know every compile and link flag in the two cases. Most of those flags are the same. For example, I have checked the optimization is the same in both cases. I am going to take a break now, but tomorrow I will first try the experiment of editing the PostScript file to reorder the glyphs in the same way to confirm (with diff on those modified results) that the postscript commands for each glyph are identical as assumed above from the identical-looking visual comparison results. Then I will try some experiments with a variety of compile and/or link flags to see if those make a difference. Of course, it is conceivable that the current versions of pango/cairo/fontconfig look up glyphs in a massively parallel way so the order they are stored in the top of the PostScript file is somewhat arbitrary depending on the finishing order in which the glyphs are delivered by pango/cairo/fontconfig each time the PostScript file is generated. So I will attempt to investigate that possibility tomorrow as well. More, tomorrow. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-04-28 22:45:27
|
Hi Ed: On 2014-04-28 17:32-0400 Ed Trager wrote: > Hi, Alan! > > glyphMgr.h defines: > > FreetypeGlyphMgr(); > > FreetypeGlyphMgr(FT_Glyph glyph); > > > These are FreetypeGlyphMgr constructors. The first one is a constructor > with no arguments. The second one is a constructor that takes "glyph" of > type "FT_Glyph" as a constructor. > > So when we go into glyphMgr.cpp, for the first case (no argument) we see: > > FreetypeGlyphMgr::FreetypeGlyphMgr() : _glyph((FT_Glyph)0) { > > _glyph = (FT_Glyph)0; > > } > > ... which says initialize the private member _glyph with a zero cast to > type "FT_Glyph". And that looks good. > > > The second one (initialized with "glyph" of type "FT_Glyph" certainly needs > at least to be: > > FreetypeGlyphMgr::FreetypeGlyphMgr(FT_Glyph glyph) : _glyph(glyph) {} > > But you may ask, why isn't it this instead?: > > FreetypeGlyphMgr::FreetypeGlyphMgr(FT_Glyph glyph) : _glyph(glyph) { > > _glyph = glyph; > > } > > ... which would mirror the syntax that we already saw for the case with > zero arguments. > > The reason is explained here: > > http://stackoverflow.com/questions/1711990/what-is-this-weird-colon-member-syntax-in-the-constructor > > (read down a bit) ... where it explains: > > =================================== > > There is a significant difference between Initializing a member using > Member initializer list and assigning it an value inside the constructor > body. > > When you *initialize* fields via Member initializer list the constructors > will be called once and the object will be constructed and initialized in > one operation. > > If you use *assignment* then the fields will be first initialized with > default constructors and then reassigned (via assignment operator) with > actual values. > > As you see there is an additional overhead of creation & assignment in the > latter, which might be considerable for user defined classes. > > ==================================== > > SO I checked in revision 183: > > svn ci -m "Changed FreeTypeGlyphMgr(FT_Glyph) member initialization for > _glyph to _glyph(glyph) " > > Password: > > Sending src/glyphMgr.cpp > > Transmitting file data . > > Committed revision 183. > > > Hope this helps! Yes, it does. Your change certainly continues to compile here, and the ctest command passes without errors. I have updated bug report 4 accordingly and also closed it as fixed. Thanks very much for your help with this release. One other release topic is the deprecated functions, and here are my research results concerning those. For the first of those, pango_ft2_get_context, the documentation says "pango_ft2_get_context has been deprecated since version 1.22 and should not be used in newly-written code. Use pango_font_map_create_context() instead." pango_ft2_get_context retrieves a PangoContext for the default PangoFT2 fontmap and modifies that to set the X and Y dpi. The suggested replacement has a vastly different argument (a pointer to a PangoFontMap rather than the X and Y dpi values), and it is not at all clear from quick reading through the pango documentation how to populate that PangoFontMap before the call. Furthermore, there is no mention of X and Y dpi so you would have to figure out how to set those when you create the needed PangoFontMap. So converting from using pango_ft2_get_context to pango_font_map_create_context is probably trivial for pango developers, but it is not trivial at all for someone like me who is dependent on the documentation. The other deprecated function that is currently used is pango_ft2_font_get_face but again its suggested replacement has a different argument (PangoFcFont rather than PangoFont) so it might (I have only looked at this for ~5 minutes) be nontrivial to move to the suggested replacement in this case as well. Finally, in the cases of these deprecated functions the wording ("should not be used for new code") probably implies they will keep these deprecated API's around indefinitely for code like libLASi that was written some time ago. Anyhow, because the conversion to newer API is non-trivial and because this old deprecated API might be supported for a long time, my decision is not to worry about these deprecated functions for this release and probably not until there is some indication that pango is actually going to remove these deprecated API's (if they ever decide to do that). Therefore, that concludes my development work on libLASi at this time. In sum, we appear ready for the 1.1.2 release, and I will soon start that process (outlined in README.Release_Manager_Cookbook). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-04-28 20:47:46
|
Hi Ed: I have changed my mind and will try to deal with the deprecation warnings myself. Those warnings do mention the replacement functions that should be used so I will give those replacement functions a try to see how far I get with my minimal C++ skills. But I will continue to leave bug 4 strictly to you because I don't have the knowledge to deal with that one. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-04-28 19:10:20
|
Hi Ed: I have finished with dealing with bugs 2 and 3 and also some other maintenance items (such as updated doxygen configuration files) and bumping the CMake minimum version number. Thanks for your off-list message that you would be working on bug 4 today so as soon as you inform me you are done with that (as well as possibly dealing with the deprecation warnings, see below), I plan to release 1.1.2. Some additional news concerning bug 4 is the following compiler warning message reported by Orion (the Fedora packager and tester for both PLplot and libLASi) for the latest svn trunk version of libLASi. On 2014-04-28 09:37-0600 Orion Poplawski wrote: > /export/home/orion/fedora/lasi/libLASi-1.1.2/src/glyphMgr.cpp: In constructor > 'FreetypeGlyphMgr: > :FreetypeGlyphMgr(FT_Glyph)': > /export/home/orion/fedora/lasi/libLASi-1.1.2/src/glyphMgr.cpp:27:1: warning: > 'FreetypeGlyphMgr:: > _glyph' is initialized with itself [-Winit-self] > FreetypeGlyphMgr::FreetypeGlyphMgr(FT_Glyph glyph) : _glyph(_glyph) {} > ^ So it is still not clearcut this is a bug (for example, perhaps the originator of this code wanted to initiate this way?) but still it is a sufficiently unusual form of code to generate warning messages for various modern g++ compilers. Anyhow, I look forward to your decision about what to do (if anything) about this code. Here are some additional warnings seen by Orion: > > /export/home/orion/fedora/lasi/libLASi-1.1.2/src/contextMgr.h: In constructor > 'ContextMgr::Conte > xtMgr(const char*, int, int)': > /export/home/orion/fedora/lasi/libLASi-1.1.2/src/contextMgr.h:23:12: warning: > 'PangoContext* pan > go_ft2_get_context(double, double)' is deprecated (declared at > /usr/include/pango-1.0/pango/pang > oft2.h:111): Use 'pango_font_map_create_context' instead > [-Wdeprecated-declarations] > _t = pango_ft2_get_context(dpiX, dpiY); > ^ > > /export/home/orion/fedora/lasi/libLASi-1.1.2/src/psDoc.cpp: In member > function 'void LASi::Posts > criptDocument::for_each_glyph_do(const string&, void > (LASi::PostscriptDocument::*)(const value_t > ype&, void*), void*, bool)': > /export/home/orion/fedora/lasi/libLASi-1.1.2/src/psDoc.cpp:223:26: warning: > 'FT_FaceRec_* pango_ > ft2_font_get_face(PangoFont*)' is deprecated (declared at > /usr/include/pango-1.0/pango/pangoft2. > h:125): Use 'pango_fc_font_lock_face' instead [-Wdeprecated-declarations] > const FT_Face face = pango_ft2_font_get_face(pItem->analysis.font); > ^ > /export/home/orion/fedora/lasi/libLASi-1.1.2/src/psDoc.cpp:223:70: warning: > 'FT_FaceRec_* pango_ > ft2_font_get_face(PangoFont*)' is deprecated (declared at > /usr/include/pango-1.0/pango/pangoft2. > h:125): Use 'pango_fc_font_lock_face' instead [-Wdeprecated-declarations] > const FT_Face face = pango_ft2_font_get_face(pItem->analysis.font); > ^ For my own g++ version I get the following equivalent deprecations warnings: In file included from /home/software/lasi_svn/HEAD/lasi_allura/src/psDoc.cpp:17:0: /home/software/lasi_svn/HEAD/lasi_allura/src/contextMgr.h: In constructor ‘ContextMgr::ContextMgr(const char*, int, int)’: /home/software/lasi_svn/HEAD/lasi_allura/src/contextMgr.h:23:12: warning: ‘PangoContext* pango_ft2_get_context(double, double)’ is deprecated (declared at /usr/include/pango-1.0/pango/pangoft2.h:98): Use 'pango_font_map_create_context' instead [-Wdeprecated-declarations] /home/software/lasi_svn/HEAD/lasi_allura/src/contextMgr.h:23:44: warning: ‘PangoContext* pango_ft2_get_context(double, double)’ is deprecated (declared at /usr/include/pango-1.0/pango/pangoft2.h:98): Use 'pango_font_map_create_context' instead [-Wdeprecated-declarations] /home/software/lasi_svn/HEAD/lasi_allura/src/psDoc.cpp: In member function ‘void LASi::PostscriptDocument::for_each_glyph_do(const string&, void (LASi::PostscriptDocument::*)(const value_type&, void*), void*, bool)’: /home/software/lasi_svn/HEAD/lasi_allura/src/psDoc.cpp:223:26: warning: ‘FT_FaceRec_* pango_ft2_font_get_face(PangoFont*)’ is deprecated (declared at /usr/include/pango-1.0/pango/pangoft2.h:112): Use 'pango_fc_font_lock_face' instead [-Wdeprecated-declarations] /home/software/lasi_svn/HEAD/lasi_allura/src/psDoc.cpp:223:70: warning: ‘FT_FaceRec_* pango_ft2_font_get_face(PangoFont*)’ is deprecated (declared at /usr/include/pango-1.0/pango/pangoft2.h:112): Use 'pango_fc_font_lock_face' instead [-Wdeprecated-declarations] /home/software/cmake/install-2.8.12.2/bin/cmake -E cmake_progress_report /home/software/lasi_svn/HEAD/build_dir/CMakeFiles 4 So I assume you will also see equivalent deprecation warnings when you compile the code, and at some point we should deal with these warnings to future-proof libLASi. Of course, such change will likely make libLASi not work with the ancient version of pango that existed when libLASi was written, but I doubt that is a serious issue any more because that ancient pango version (whatever it was) is unlikely to be installed on computers now, and in any case I would far prefer to be ready for the future rather than hanging on to the past. :-) Thus, if you have time/energy today to deal with these warnings after you are done with bug 4, I would encourage that, but if you want to wait to deal with this until sometime after the current maintenance release, that is fine as well with me. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2014-04-26 21:06:35
|
Hi Ed: libLASi continues to have a steady popularity. It is still averaging roughly 30 downloads a month, and it has had almost 1000 downloads since the release of 1.1.1. So continued maintenance of this library is still worthwhile. Therefore, I intend to bring out a maintenance release 1.1.2 tomorrow (Sunday) to fix an issue (change from non-standard to standard way of including freetype headers) that has made libLASi impossible to use with recent freetype versions. At the same time I would like to deal with the two other open bugs on our bugtracker. One of those is a build system feature request which should be easy for me to satisfy. But could you (or anyone else with C++ skills that is subscribed to the lasi-devel list) give me some quick advice on whether the tentative one-line change at <https://sourceforge.net/p/lasi/bugs/4/> to fix an uninitialized variable warning is a correct fix? For what it is worth my own g++ (version 4.7.2) doesn't emit that warning, but I have found that warnings depend very much on g++ version. Another caveat is uninitialized warnings can often be false alarms. The line in question is FreetypeGlyphMgr::FreetypeGlyphMgr(FT_Glyph glyph) : _glyph(_glyph) {} which the guy thinks _maybe_ should be changed to FreetypeGlyphMgr::FreetypeGlyphMgr(FT_Glyph glyph) : _glyph(glyph) {} My C++ skills are weak (i.e., I understand C code, but not C++ syntax like ": _glyph(_glyph)"), but from the C point of view the argument is named glyph so I think the suggested change is at least plausible. But the confusing issue is that in drawGlyph.h, _glyph is defined in the private part of the class which might mean the current form of the code is correct, and the uninitialized warning that guy's compiler delivered was a false alarm. Anyhow, I am not going to change anything here until someone with C++ skills reviews the situation and gives me definitive advice. Note, I have CC'd the list so if someone else here with C++ skills wants to jump in first to advise me what to do here, that would be great, but if nobody responds in the next day I will likely go ahead with the 1.1.2 release without the suggested one-line change above. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2013-03-21 15:56:42
|
On 2012-12-06 23:38-0800 Alan W. Irwin wrote: > [...]Also, > > https://sourceforge.net/p/forge/documentation/svn/ > > tells you some general points about the new svn system including how > to backup the new svn repo via rsync. > > I followed that backup procedure and ended up with a downloaded repo > that was the same size as the old repo I backed up before I made the > request to host the libLASi project with Allura. However, the new > repo differs in a lot of details from the old repo. [...] PLplot core developers already know this, but for the rest of you still subscribed to the lasi-devel list, I followed up by implementing a script (located at scripts/compare_svn_repos within the svn trunk version of PLplot) that would compare results (detailed log file and for 100 different sampled revision checkouts, local directory trees) for the new svn repo versus the old. I ultimately ran this script for 8 different SourceForge projects including libLASi (and PLplot) and in all cases there was no difference in results between the old and new repos even though the binary format of the old and new repos was different. > [...]I encourage you to also do some spot checks of the svn version of > libLASi yourself (using the method documented above so you are > guaranteed to be accessing the new repo version) as well as try some > of the new resources at sf.net/projects/lasi to get a feeling for what > is possible with the new Allura software project hosting platform. That suggestion is still a good one, but for myself I am satisfied with the current post-Allura status of the libLASi project at SourceForge so we should be in good shape if we ever decide to develop libLASi some more. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2012-12-07 07:38:39
|
Hi Andrew (and others still subscribed to the liblasi-devel mailing list): I view the libLASi project as still being quite useful because downloads are still continuing. Nevertheless, I think it's development is done which is why I haven't sent any e-mail for some time to this list. However, I thought I should inform you of an essential bit of sysadmin for that project that I have just requested. That change is to update the software hosting platform for libLASi from the legacy SF set of applications to their new Allura platform. (If I hadn't requested this change now by hitting the appropriate button at sf.net/p/update it appears the SF staff would have done it for us some time in the first quarter of 2013.) Roughly 6 hours after the request, the SF staff (or some automatic procedure there) had finished the conversion of libLASi to the Allura platform. One of the changes for the new platform is that the URL for the svn repo has changed. Look at sf.net/projects/lasi -> files to see how to gain access to the new svn repository. Also, https://sourceforge.net/p/forge/documentation/svn/ tells you some general points about the new svn system including how to backup the new svn repo via rsync. I followed that backup procedure and ended up with a downloaded repo that was the same size as the old repo I backed up before I made the request to host the libLASi project with Allura. However, the new repo differs in a lot of details from the old repo. I assume these differences are because of a different svn server version (and therefore different repo organization) under the Allura platform. I think this change to svn server version was an unfortunate choice on the SF staff's part since cautious developers like me when faced with those repo changes will feel it is necessary to follow up with some tests to make sure everything (such as our tagged releases and all the commit messages) is still accessible from the new version of our svn repository. I plan to do such tests tomorrow. (Andrew, I also recommend such tests for the PLplot case when the time comes but I guess that depends on how cautious you feel about checking whether our svn history history, for example, has been cloberred by the svn repository update.) I encourage you to also do some spot checks of the svn version of libLASi yourself (using the method documented above so you are guaranteed to be accessing the new repo version) as well as try some of the new resources at sf.net/projects/lasi to get a feeling for what is possible with the new Allura software project hosting platform. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |