From: Alan W. I. <ir...@be...> - 2005-05-24 18:28:00
|
On 2005-05-24 00:19-0700 Alan W. Irwin wrote: > [...] So it (fontconfig) > might be the answer we need to substantially simplify our environment > variable > requirements, and I hope someone investigates it further. I should also mention that on Debian systems (which a lot of our developers have), there is a nice overview of what fontconfig does in /usr/share/doc/fontconfig/README.Debian. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Per P. <per...@ma...> - 2005-05-22 19:23:01
|
On May 22, 2005, at 19:26, Alan W. Irwin wrote: > On 2005-05-22 08:55-0700 Alan W. Irwin wrote: > > >> >> I will go ahead and make the proposed PL_FCI_MARK change soon as >> well as >> warning about this specific API change in README.release. >> >> > > Done. Also, I performed some superficial Linux build and installed > examples > tests. Please test this series of commits yourselves (especially > Hazen and > Arjen since I cannot test changes to drivers/aqt.c and > sys/win32/msdev/src/plplot.h). > > Alan > ______ AFAICT, x23c and x24c works as expected with your changes on Mac OS X 10.4, AquaTerm 1.0.b3 haven't tested any other combination. /Per |
From: Rafael L. <rla...@us...> - 2005-05-23 07:06:01
|
* Alan W. Irwin <ir...@be...> [2005-05-22 08:55]: > On 2005-05-22 11:34+0200 Rafael Laboissiere wrote: > > > I agree with Maurice's considerations. I think we are allowed to > > introduced backward incompatible changes for features introduced in > > the 5.5.x series. > > I think that is a good policy. Maurice and Rafael, do you think we > should state this policy in general in the 5.5.x release announcements > (README.release)? If so, please go ahead and put in the wording that > you like. BTW, this is one of the reasons why I uploaded the Debian packages to the experimental distribution and not unstable (sid). When the 5.5.x will be approaching 5.6.0, I will consider uploading to unstable. -- Rafael |
From: Rafael L. <rla...@us...> - 2005-05-12 19:01:32
|
* Thomas J. Duck <to...@fi...> [2005-05-12 14:22]: > Per has provided us with a nice bit of code that allows us to avoid > libunicode altogether. I have made a few adjustments to it, and have > removed the unnecessary section invoking libunicode from plcore.c. Look > for the block beginning with the words "Per Persson". Note that I > changed the indentation for all of plP_text because I just couldn't deal > with it anymore. ;^) > > I have tested the results for many examples (including x24c) on > the png and gcw drivers, and they appear to be good. I would like to hear > if others accept this patch. If so, then maybe we can apply it for > tomorrow's release. It fixes a *nasty* bug. Please advise. With your reindentation of the code it is virtually impossible to evaluate your patch. The best thing to do is to immediately commit it such that we can check if everything is okay. -- Rafael |
From: Rafael L. <rla...@us...> - 2005-05-12 20:05:09
|
* Rafael Laboissiere <rla...@us...> [2005-05-12 21:01]: > With your reindentation of the code it is virtually impossible to > evaluate your patch. The best thing to do is to immediately commit it > such that we can check if everything is okay. I wrote the above without reading Alan comments before. I agree with what Alan said, we should avoid last-minute changes. I vote for releasing 5.5.3 as scheduled and commit the change just after. -- Rafael |
From: Arjen M. <arj...@wl...> - 2005-05-13 06:23:39
|
"Thomas J. Duck" wrote: > > Hi, > > I understand what Per is on about, and it's important. > > I have been struggling with x24c as well. The problem is that our > unicode implementation currently requires that you have libunicode > installed. If you don't have libunicode (like on my system presently), > then a vital section of code in plcore.c that translates utf8 to ucs4 > does not get executed. ACK!! > > Per has provided us with a nice bit of code that allows us to avoid > libunicode altogether. I have made a few adjustments to it, and have > removed the unnecessary section invoking libunicode from plcore.c. Look > for the block beginning with the words "Per Persson". Note that I > changed the indentation for all of plP_text because I just couldn't deal > with it anymore. ;^) > > I have tested the results for many examples (including x24c) on > the png and gcw drivers, and they appear to be good. I would like to hear > if others accept this patch. If so, then maybe we can apply it for > tomorrow's release. It fixes a *nasty* bug. Please advise. > I am all for that - if such an external dependency can be avoided by a fairly small piece of code, then go for it, I'd say. Note: I may be biased by the Windows platform - I can not rely on such libraries to be present. In fact I need to assume they are not there at all and as there is no particular place reserved for static/import libraries on Windows - c:\windows\system only contains DLLs - they can be anywhere! Regards, Arjen |
From: <mj...@ga...> - 2005-05-13 07:36:01
|
Thomas J. Duck writes: > Per has provided us with a nice bit of code that allows us to avoid > libunicode altogether. I have made a few adjustments to it, and have > removed the unnecessary section invoking libunicode from plcore.c. Look > for the block beginning with the words "Per Persson". Note that I > changed the indentation for all of plP_text because I just couldn't deal > with it anymore. ;^) As far as whitespace/indentation is concerned, there is of course no one way that works for everyone, so in general it's best to stick to the plplot "standard" of 4 spaces per indentation level. Since everyone has their own development style I'm not particularly anal about this, but if I find myself wanting to work on a section of code that isn't indented in accordance with the rest of the code base, I will reformat it. It just gets too confusing otherwise, what with different choices used in different places. Consistency is a good thing. I recognize the standard argument against 4 spaces is that it handles many levels of nesting poorly, and my counter is that if you're at the 5th or 6th indentation level (or worse), it's already become too unwieldy as purely inline code and it's time start splitting logic off into helper functions. Typically static to avoid pollution of the namespace. Also instead of constructions like for (stuff) if (foo) { ... } you can do for (stuff) { if (!foo) continue; ... } (or "return" as applicable) and shave off an indentation level. Finally, mixing code changes with format changes is iffy, as has been pointed out on the list (note I've been as guilty of this as anyone). The preferable way to do this is to reformat first, commit, then bug fix, or vice versa. That way the commit that just changes whitespace can be safely ignored. -- Maurice LeBrun mj...@ga... |
From: Rafael L. <rla...@us...> - 2005-05-13 08:11:07
|
* mj...@ga... <mj...@ga...> [2005-05-13 01:30]: > I recognize the standard argument against 4 spaces is that it handles many > levels of nesting poorly, and my counter is that if you're at the 5th or > 6th indentation level (or worse), it's already become too unwieldy as purely > inline code and it's time start splitting logic off into helper functions. > Typically static to avoid pollution of the namespace. This reminds me the Linux Kernel Coding Style (e.g., found at http://pantransit.reptiles.org/prog/CodingStyle.html). The kernel folks are even more radical than what Maurice wrote above. Here is the relevant excerpt of the document: Chapter 1: Indentation Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations. Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning. -- Rafael |
From: <mj...@ga...> - 2005-05-13 08:55:23
|
Rafael Laboissiere writes: > * mj...@ga... <mj...@ga...> [2005-05-13 01:30]: > > > I recognize the standard argument against 4 spaces is that it handles many > > levels of nesting poorly, and my counter is that if you're at the 5th or > > 6th indentation level (or worse), it's already become too unwieldy as purely > > inline code and it's time start splitting logic off into helper functions. > > Typically static to avoid pollution of the namespace. > > This reminds me the Linux Kernel Coding Style (e.g., found at > http://pantransit.reptiles.org/prog/CodingStyle.html). The kernel folks > are even more radical than what Maurice wrote above. Here is the > relevant excerpt of the document: Ah, leave it to those radical hippie kernel folks. :) I think by now I've practically seen it all. The only real rule that seems to work is tradition -- the creator of the (sub)project dictates how it will be formatted, unless of course it's so universally despised that the developers stage a revolt and tickle him/her into submission. At DejaNews we had several different styles in widespread use, and as an aid to consistency I set up some emacs "style" files in the code base -- when editing a file, emacs would recursively search upwards until it found the relevant one and use that to set indentation parameters. Kind of a long way to go to make everyone happy tho. -- Maurice LeBrun mj...@ga... |
From: Rafael L. <rla...@us...> - 2005-05-14 07:26:12
|
* mj...@ga... <mj...@ga...> [2005-05-13 02:49]: > I think by now I've practically seen it all. The only real rule that > seems to work is tradition -- the creator of the (sub)project dictates > how it will be formatted, unless of course it's so universally despised > that the developers stage a revolt and tickle him/her into submission. > At DejaNews we had several different styles in widespread use, and as > an aid to consistency I set up some emacs "style" files in the code > base -- when editing a file, emacs would recursively search upwards > until it found the relevant one and use that to set indentation > parameters. Kind of a long way to go to make everyone happy tho. I fully agree with you on that. As long as the original author is actively participating to the development, her initial style should be respected. I am just wondering how to make it easier for the other developers to follow the conventions of the original author. I use Xemacs here most of the time (no Emacs, although I also use jed sometimes) and I discovered that adding the following lines to the end of a PLplot C source file: /* Local Variables: eval: (c-set-offset 'statement-block-intro 4) End: */ allows me to edit files in the 4-spaces indentation style. Maurice, could you please confirm that it works in Emacs for you? In the case it does, do you think it is a good idea to add such sections to all C source files? Notice also that (X)Emacs c-mode has a quite sophisticated indentation mechanism allowing fine control of syntactical indentation through different arguments to c-set-offset. -- Rafael |
From: Rafael L. <rla...@us...> - 2005-05-14 07:31:29
|
* Rafael Laboissiere <rla...@us...> [2005-05-14 09:26]: > /* > Local Variables: > eval: (c-set-offset 'statement-block-intro 4) > End: > */ I just discovered that the following also works: /* Local Variables: c-basic-offset: 4 End: */ -- Rafael |
From: <mj...@ga...> - 2005-05-19 09:44:33
|
Just wanted everyone to know I'm about to disappear for a couple weeks while I deal with an important job-related project. Will continue to read email & try to catch up in a few weeks, earlier if plans go as expected :). Thankfully traffic on the list has been slow lately.. -- Maurice LeBrun mj...@ga... |
From: Rafael L. <rla...@us...> - 2005-05-19 13:24:07
|
* mj...@ga... <mj...@ga...> [2005-05-19 03:38]: > Just wanted everyone to know I'm about to disappear for a couple weeks > while I deal with an important job-related project. Great! Time to get all those nasty backward incompatible changes we have been planning for years sneaked into PLplot core. Let us hurry up! Just kidding... Have a good leave, Maurice. -- Rafael |
From: <mj...@ga...> - 2005-05-13 08:38:23
|
mj...@ga... writes: > Finally, mixing code changes with format changes is iffy, as has been pointed > out on the list (note I've been as guilty of this as anyone). The preferable > way to do this is to reformat first, commit, then bug fix, or vice versa. > That way the commit that just changes whitespace can be safely ignored. After a little more thought on this, I realized some generalization is in order. It's useful to break down development, especially on some old code that needs some serious TLC, into three phases: 1. initial refactoring Doesn't change any of the functionality, just makes the design & code "easier to see", and thus modify. 2. redesign and/or bug fixing (self explanatory) 3. final refactoring Often, you learn something about the design in steps 1 & 2 that give you insight into how it should "really" be structured. You can give later viewers of the code the benefit of your experience if you tidy things up a bit here. Again, no actual change in functionality. By breaking development into these three distinct phases (i.e. commits), others can ascertain the actual algorithmic change by looking at 2) only. -- Maurice LeBrun mj...@ga... |