Re: [fpc-pascal] child units (was: dot within unit file name)
On Monday 21 January 2008 18:45, Marco van de Voort wrote:
> > I think it would be fantastic if Free Pascal could add child units
> > as a language extension (of course this would reduce portability --
> > although on the other hand it might make porting Ada programs
> > easier). It's difficult trying to describe the benefits to someone
> > who has never used them (how do you know you're missing something
> > if you've never used it and therefore never felt a need for it?)
>
> I've used Modula2, and know nested modules. However I haven't missed
> them.
Well, I've missed them. (Although I don't remember Modula-2 too well, so
I can't say how much similar they are to Ada's child packages).
But child packages are really great for extending and adding
functionality without even touching existing source code.
> I have missed opague types and forcedly qualified importing (from
> M2)
Well, I miss them too. As I'll show you in a moment that they even go
hand in hand with child packages.
> M2 doesn't have the nested module "put in arbitrary other file"
> system though. Such system would have the same problems with M2 as
> with Pascal.
Well, you'd definitely need to store not only the information about the
interface part in the .ppu file, but also the implementation part, so
that any child package can access and use this information.
Because without separate compilation(-units), child packages are
relatively useless. After all the real big advantage is that you can
extend a package without touching the existing one.
The classic example from the Ada95 Rationale, for your convinience
converted into "Pseudo Pascal":
--- 8< ---
unit
ComplexNumbers;
interface
type
Complex; // Incomplete (opaque) type.
// Further specified in implementation part.
operator + (Left, Right: Complex) : Complex;
// similarly "-", "*" and "/"
function CartesianToComplex (Real, Imag : Double) : Complex;
function RealPart (X : Complex) : Double;
function ImagPart (X : Complex) : Double;
implementation
...
end {ComplexNumbers}.
--- 8< ---
Now the only ways to add functionality to the unit would be to
1) make "Complex" a non-opaque type, and add another
unit "ComplexNumbersPolar", or
2) change the original "ComplexNumbers" unit by adding the newly needed
funtionality, thus forcing recompilation or - even worse - possibly
introducing bugs to already tested code.
Approach 1) has the disadvantage that I still can't use internal
subroutines declared in the original "ComplexNumbers" unit.
This usually forces me to add another package which exposes this
formerly private part and declare that this private package *should*
only be used by this, or that, or any extending unit, but not "normal"
user code. As with any such suggestions, they can't be forced to other
developers. ;)
Now, if we had child packages all this could be avoided, we simply add a
subpackage like this:
--- 8< ---
unit
ComplexNumbers.Polar;
interface
function PolarToComplex (R, Theta : Double) : Complex;
function Abs (Right : Complex) : Double;
function Arg (X : Complex) : Double;
implementation
...
// This part now has access to the (opaque) type
// "Complex" just like "ComplexNumbers" has.
// IOW: Like it was declared in here.
end {ComplexNumbers.Polar}.
--- 8< ---
No touching of the original "Complex_Numbers", no recompilation for
units already using it and the knowledge that the original code has not
changed a bit. Additionally the inner working of the type "Complex" is
still not exposed to any other unit.
And yes, I miss that.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Problem using fpc
Cause of problem located. In certain cases compiling 'xx.pas' failed because object files, ppu files etc from previous compilations already existed and had somehow become set as 'read only'. Apologies for being so dumb as to not find this. -- View this message in context: http://www.nabble.com/Problem-using-fpc-tp15011490p15011490.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] PathOnly is left empty in fpc 2.2.0
Switching from 2.0.4 to 2.2.0 I found that (in Linux environment) the field PathOnly of TSearchRec isn't filled anymore. Of course my app which relies on it doesn't work any more. Is that an upgrade (?) or a bug? In Mantis I only saw a reference for non Unix platforms, where this field isn't supported. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
Graeme Geldenhuys wrote: On 21/01/2008, Vinzent Höfler <[EMAIL PROTECTED]> wrote: Yes, that's what I figured. What I don't get is how the editor extracts the information _back_ from the file after the "tabstop" information has been deleted (that's what it does once it gets replaced with spaces). I don't know! It just does! :-) Actually on a serious note, it uses pixel calculations based on the ET parameters you can specify: MinimumWidth, PaddingWidth etc... When viewed with a ET enabled editor, the text might shift by a few pixels (not spaces) but all alignment will still be intact. It's just that clever! :) Hmm. That either means it stores additional information about the file (something that also needs to get versioned then - which is problematic given that this data may even be plugin/editor specific) or it uses some heuristics based on the file/language. As it is the case with all heuristics it can go wrong - and Murphy dictates if it can, it will. So I don't know if it's of so much use unless I start using proportional fonts just for the fun of it. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
Florian Klaempfl wrote: Imo that plugin discussion is pretty useless. I'am coding in at least four different editors pascal (fp ide, joe, lazarus, ultraedit) and I fear there is no plugin for all editors I use :) Same here, although the editors' names are a bit different. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
Graeme Geldenhuys schrieb: > On 21/01/2008, Vinzent Höfler <[EMAIL PROTECTED]> wrote: > > I'm breaking my own promise and replying again... :) > > >>> I hope this will be my last reply. Please take a look at the flash >>> video on the ET website. >> I don't have flash, so I am bound to check out the Java example. > > Ask a friend, it's worth seeing.. > > >>> There he uses two editors (gvim and gedit). >> With appropriate plugins/scripts, I suppose. > > I guess, though his gedit plugin doesn't work with the latest gedit > anymore. It seems gedit changed some or other API call (what I can > gather from the console output error message). > >> Yes, that's what I figured. What I don't get is how the editor extracts >> the information _back_ from the file after the "tabstop" information has >> been deleted (that's what it does once it gets replaced with spaces). > > I don't know! It just does! :-) Actually on a serious note, it uses > pixel calculations based on the ET parameters you can specify: > MinimumWidth, PaddingWidth etc... When viewed with a ET enabled > editor, the text might shift by a few pixels (not spaces) but all > alignment will still be intact. It's just that clever! :) Imo that plugin discussion is pretty useless. I'am coding in at least four different editors pascal (fp ide, joe, lazarus, ultraedit) and I fear there is no plugin for all editors I use :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On 21/01/2008, Vinzent Höfler <[EMAIL PROTECTED]> wrote: I'm breaking my own promise and replying again... :) > > I hope this will be my last reply. Please take a look at the flash > > video on the ET website. > > I don't have flash, so I am bound to check out the Java example. Ask a friend, it's worth seeing.. > > There he uses two editors (gvim and gedit). > > With appropriate plugins/scripts, I suppose. I guess, though his gedit plugin doesn't work with the latest gedit anymore. It seems gedit changed some or other API call (what I can gather from the console output error message). > Yes, that's what I figured. What I don't get is how the editor extracts > the information _back_ from the file after the "tabstop" information has > been deleted (that's what it does once it gets replaced with spaces). I don't know! It just does! :-) Actually on a serious note, it uses pixel calculations based on the ET parameters you can specify: MinimumWidth, PaddingWidth etc... When viewed with a ET enabled editor, the text might shift by a few pixels (not spaces) but all alignment will still be intact. It's just that clever! :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] child units (was: dot within unit file name)
> I think it would be fantastic if Free Pascal could add child units as > a language extension (of course this would reduce portability -- > although on the other hand it might make porting Ada programs easier). > It's difficult trying to describe the benefits to someone who has > never used them (how do you know you're missing something if you've > never used it and therefore never felt a need for it?) I've used Modula2, and know nested modules. However I haven't missed them. I have missed opague types and forcedly qualified importing (from M2) M2 doesn't have the nested module "put in arbitrary other file" system though. Such system would have the same problems with M2 as with Pascal. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
Graeme Geldenhuys wrote: I hope this will be my last reply. Please take a look at the flash video on the ET website. I don't have flash, so I am bound to check out the Java example. There he uses two editors (gvim and gedit). With appropriate plugins/scripts, I suppose. And for the last time, tabs are NOT insert tabs into the source code - when you press the TAB key the editor creates a TabStop. TabStops are like what you get in OpenOffice or MS Office for aligning text. As the flash example on the ET website shows - once you save, it replaces the tabstops with spaces so that if you had to open it with another non-ET enabled editor, alignment would still be correct. Yes, that's what I figured. What I don't get is how the editor extracts the information _back_ from the file after the "tabstop" information has been deleted (that's what it does once it gets replaced with spaces). All this fuzz is of no use if you can't restore the information from the file. IOW, how does it know that I set tabstops at those locations marked with |function Foo (const A :String) :Integer; |function Foobar(const B :String) :Integer; after it has been replaced with |function Foo(const A : String) |function Foobar (const B : String) For me there's no way telling anymore. But probably this editor is so much smarter than a rock. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On 21/01/2008, Vinzent Hoefler <[EMAIL PROTECTED]> wrote: > The only difference seems to me, that without tabs the source code still > looks the same, no matter if I look at it in "vi", "gedit", "kate", > or "notepad". Once you start using tabs this isn't guaranteed > anymore... I hope this will be my last reply. Please take a look at the flash video on the ET website. There he uses two editors (gvim and gedit). And for the last time, tabs are NOT insert tabs into the source code - when you press the TAB key the editor creates a TabStop. TabStops are like what you get in OpenOffice or MS Office for aligning text. As the flash example on the ET website shows - once you save, it replaces the tabstops with spaces so that if you had to open it with another non-ET enabled editor, alignment would still be correct. I've had better conversations with a rock. ;-) Either way, every developer for himself. Use the tools you prefer, it's your right! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] child units (was: dot within unit file name)
On Jan 21, 2008 1:05 AM, Vinzent Hoefler <[EMAIL PROTECTED]> wrote: > On Friday 18 January 2008 20:12, John Stoneham wrote: > [snip] > So, the only difference is that Ada plays it safe and complains about > ambiguities while a Pascal compiler tries to resolve the ambiguity by > itself Perhaps that's true with regard to name resolution, but Ada's package system has a significant feature which Pascal's module system lacks: child packages. Conceptually, a child package is the same thing as a nested package: package Parent is ... package Child is ... end Child; ... end Parent; Now, the nested "Child" can be referenced outside "Parent" as "Parent.Child". This has much more to offer than simply another level (sometimes very necessary) of organization to a complex program. For example, the private part of a child package has access to it's parent's private members as well. The visibility rules are similar to those that relate to inheritance (via private, protected, and public sections). This adds a level of encapsulation that is very desirable in a complex program. Normally, child packages are not defined simply as nested packages within the parent itself (although they can be). Usually, they are defined in their own file. The dot-notation in the package declaration tells the compiler that "Child" is a child package of "Parent": package Parent.Child is ... end Parent.Child; When you have a lot of Ada programming experience, the flexibility of child packages adds enormously to program structure and design. In contrast, the single-level module system of Pascal feels very limiting (however, Ada is so much more restrictive in other areas that Pascal is overall a breath of fresh air). I think it would be fantastic if Free Pascal could add child units as a language extension (of course this would reduce portability -- although on the other hand it might make porting Ada programs easier). It's difficult trying to describe the benefits to someone who has never used them (how do you know you're missing something if you've never used it and therefore never felt a need for it?) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] property or public
On Jan 21, 2008, at 4:47 PM, Joao Morais wrote: Matt Emson wrote: Joao Morais wrote: Damien Gerard wrote: On Jan 21, 2008, at 2:52 PM, Joao Morais wrote: Damien Gerard wrote: I have (it would seem) a stupid question :) We have TStringList vars. User can do what he want with it. Which one is the stupid or the better way to do it ? TMyClass = class(TObject) public List1: TStringList; List2: TStringList; end; or TMyClass = class private FList1: TStringList; FList2: TStringList; public property List1: TStringList read FList1; property List2: TStringList read FList2; end; The later, *much* better. You should never use class members outside the private area. Thanks ! What is the reason ? I am happy I was right but I need some reason :) Encapsulation, on behalf of the integrity of the instance. Implementation detail is also a good example. Then: TMyClass = class private FList1: array of string; //convoluted, but uses a different storage mechanism FList2: array of string; protected function GetList1: TStringList; virtual; function GetList1: TStringList; virtual; public property List1: TStringList read GetList1; property List2: TStringList read GetList2; end; You can implement the storage for GetList1 and GetList 2 any way that you wish internally, but give a uniform external interface. Exact, polymorphism is also a reason. You can have abstract methods and no class members if the design requires. The interface continues the same. That is what I thought too. But I wanted external advice. Thanks to all ! -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Monday 21 January 2008 15:59, Marco van de Voort wrote: > > On Monday 21 January 2008 14:31, Marco van de Voort wrote: > > > > Oh, come on. What if you encounter an enum that does *not* > > > > require such "tabbing" inside the same source file. > > > > > > Well, "require" or not is relative to begin with. > > > > Let me rephrase it: A tool would have destroyed information if it > > would have reformatted such code. That's simply not tolerable. > > Let me rephrase mine too, is it a requirement to have such code meta > information in your system? It is a requirement that the code should as self-explainable as possible, yes. > For me it is only a base readability line, but I have no desire what > so ever to go into detail. Ok, let me show you a real life example of "deviations from the rule": 1) | Ksi := Ksi + self.Weight[Pred (Layer), j, k] * |self.Value[Pred (Layer), j]; 2) | Ksi := Ksi + self.Weight[Pred (Layer), j, k] * | self.Value[Pred (Layer), j]; What is more readable? Usually the next line should be aligned, true, but with the operator precedence the first variant just makes more sense. > If you find one, please notify me. Somehow developers can only be > disciplined on schemes they thought up themselves. No, they're usually disciplined on schemes they found senseful. That's different. > > That's what the guy told us, too. It never worked out. Coders wrote > > code, checked it into CVS and it came out differently. The didn't > > even know their own code anymore, just five seconds after they > > committed it. > > Well, I never said I put it in a post commit event. Well, that's what he tried to do to us. And not even because he was the senior software engineer, but because he happened to be the server admin. Of course, the source code quality didn't match up. If you know that your code gets destroyed once you commit it, you don't take much care to do it right. > I just do (did is > a better word, currently I'm on my own again) it regularly by hand > with an automated tool. As I expressed already: I have nothing against tools *checking* given guide-lines. But in the end it's the developers responsibility to follow those. So if the developer decides to let the tool reformat his code and manually tweak those couple of lines where the tool gets it wrong, it's ok. > The developers are supposed to keep it basically readable, and > periodically the automated tool over it catches their glitches, It's not a glitch if code is laid out to be better understandable: A matrix based filter calculation as written by the developer: |Summe := | Prev_D^[i - 1] + 2 * Prev_D^[i] + Prev_D^[i + 1] + | 2 * Cent_D^[i - 1] + 4 * Cent_D^[i] + 2 * Cent_D^[i + 1] + | Next_D^[i - 1] + 2 * Next_D^[i] + Next_D^[i + 1]; The same code raped by "ptop" with default config: |Summe := | Prev_D^[i - 1] + 2 * Prev_D^[i] + Prev_D^[i + 1] + | 2 * Cent_D^[i - 1] + 4 * Cent_D^[i] + 2 * Cent_D^[i + 1] + | Next_D^[i - 1] + 2 * Next_D^[i] + Next_D^[i + 1]; The whole layout is totally lost. Its definitely not readable anymore. > > > You only do it > > > periodically (e.g. on a big release), and for the rest you don't > > > enforce, but just keep it minimally readable by hand. > > > > That's what an editor is for. > > The editor is primarily to get work done. Work is done with paper and pencil. :P > Amelioration is a cost > factor, and it should be minimized. Most of the gains are in the > simplest of things And as only 10% of a software project involves actually writing code, there's not much optimization potential here, anyway. Being able to read the code is much more important after all. > Yes. But there are two, maybe three reasons I don't want that, at > least not in normal business code: See the example above. It's not about the decision if you should two, three, or four spaces or rather use tabs, or if the line length should be limited to 72, 80, 127, or even 4095 chars or if you put spaces around parentheses or not. Those are details you get accustomed to more or less (although it pays to not deviate too much from normal written text). The point is: if I already have trouble reading code, how much trouble would I have actually understanding it? > - People constantly correcting minor glitches in style and committing > those, poluting the RCS history. Oh come on. History can be filtered. And I'd rather have a "typo and coding-style fixed" commit only, than this typo and code-style fix commited *together* with a totally unrelated change. This does not only pollute the history, it pollutes the diff which is much more important. > - In general, don't spend too much time on style. Better invested on > actual code quality commenting and readability than in how it is > formatted. You would wonder how much quality *can* be in formatting. > > > Per enum decision to tabbed or not is not simple. > > > > Yes, it
Re: [fpc-pascal] property or public
Matt Emson wrote: Joao Morais wrote: Damien Gerard wrote: On Jan 21, 2008, at 2:52 PM, Joao Morais wrote: Damien Gerard wrote: I have (it would seem) a stupid question :) We have TStringList vars. User can do what he want with it. Which one is the stupid or the better way to do it ? TMyClass = class(TObject) public List1: TStringList; List2: TStringList; end; or TMyClass = class private FList1: TStringList; FList2: TStringList; public property List1: TStringList read FList1; property List2: TStringList read FList2; end; The later, *much* better. You should never use class members outside the private area. Thanks ! What is the reason ? I am happy I was right but I need some reason :) Encapsulation, on behalf of the integrity of the instance. Implementation detail is also a good example. Then: TMyClass = class private FList1: array of string; //convoluted, but uses a different storage mechanism FList2: array of string; protected function GetList1: TStringList; virtual; function GetList1: TStringList; virtual; public property List1: TStringList read GetList1; property List2: TStringList read GetList2; end; You can implement the storage for GetList1 and GetList 2 any way that you wish internally, but give a uniform external interface. Exact, polymorphism is also a reason. You can have abstract methods and no class members if the design requires. The interface continues the same. -- Joao Morais ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] property or public
Joao Morais wrote: Damien Gerard wrote: On Jan 21, 2008, at 2:52 PM, Joao Morais wrote: Damien Gerard wrote: I have (it would seem) a stupid question :) We have TStringList vars. User can do what he want with it. Which one is the stupid or the better way to do it ? TMyClass = class(TObject) public List1: TStringList; List2: TStringList; end; or TMyClass = class private FList1: TStringList; FList2: TStringList; public property List1: TStringList read FList1; property List2: TStringList read FList2; end; The later, *much* better. You should never use class members outside the private area. Thanks ! What is the reason ? I am happy I was right but I need some reason :) Encapsulation, on behalf of the integrity of the instance. Implementation detail is also a good example. Then: TMyClass = class private FList1: array of string; //convoluted, but uses a different storage mechanism FList2: array of string; protected function GetList1: TStringList; virtual; function GetList1: TStringList; virtual; public property List1: TStringList read GetList1; property List2: TStringList read GetList2; end; You can implement the storage for GetList1 and GetList 2 any way that you wish internally, but give a uniform external interface. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
> On Monday 21 January 2008 14:31, Marco van de Voort wrote: > > > Oh, come on. What if you encounter an enum that does *not* require > > > such "tabbing" inside the same source file. > > > > Well, "require" or not is relative to begin with. > > Let me rephrase it: A tool would have destroyed information if it would > have reformatted such code. That's simply not tolerable. Let me rephrase mine too, is it a requirement to have such code meta information in your system? For me it is only a base readability line, but I have no desire what so ever to go into detail. > > Well, I'd say group of source files yes. And I wouldn't bother with > > it in the first place (which is the point with making it an artform). > > Well, it doesn't need an artist, it needs disciplined developers. If you find one, please notify me. Somehow developers can only be disciplined on schemes they thought up themselves. > > > Also to be checked in into version control in case the source file > > > somehow changes and its formatting configuration needs to be > > > adjusted. > > > > That's the big advantage of doing it automatedly. > > That's what the guy told us, too. It never worked out. Coders wrote > code, checked it into CVS and it came out differently. The didn't even > know their own code anymore, just five seconds after they committed it. Well, I never said I put it in a post commit event. I just do (did is a better word, currently I'm on my own again) it regularly by hand with an automated tool. Usually on what a human judges is a junction in the development ( a major release, addition of a major subsystem etc). Some files might be excepted from the process etc. The developers are supposed to keep it basically readable, and periodically the automated tool over it catches their glitches, and erases artwork and other mistakes. This also means that a new developer can start without too much instruction (put begin and end always on a new line, indent two spaces, camel case identifiers but don't over do it, and don't do hungarian notation except for form components and exceptions. Ok, you can start now. If they have Delphi experience, it usually doesn't even generate questions) > > You only do it > > periodically (e.g. on a big release), and for the rest you don't > > enforce, but just keep it minimally readable by hand. > > That's what an editor is for. The editor is primarily to get work done. Amelioration is a cost factor, and it should be minimized. Most of the gains are in the simplest of things > It helps you to keep the general coding style by "suggesting" how to > layout the code, but it should not force you. It should allow you to > deviate from the usual rule - if that's justified (of course, *this* is a > human decision). Running automated tools over the code destroys the > information put in there exactly *by* deviating from the rule. If I did > that, I did it for a reason. Yes. But there are two, maybe three reasons I don't want that, at least not in normal business code: - the endless feuding over what constitutes the proper style (including writing complete books over coding style that nobody ever reads, except the person that wrote it in the first place) - People constantly correcting minor glitches in style and committing those, poluting the RCS history. - In general, don't spend too much time on style. Better invested on actual code quality commenting and readability than in how it is formatted. > > > I didn't say, it's a requirement. But I don't want a tool to > > > reformat code, which has been explicitely logically ordered for > > > readability, a better overview over the instruction set, and for > > > easier extensionby the coder. > > > > Well, that is the problem indeed. You WANT too much :-) > > Oh, common sense is too much already? :D Yes. Common sense is to variant amongst people. It is usually just a way to make "I'm right" sound like "we all agree on this" > > Per enum decision to tabbed or not is not simple. > > Yes, it is: If it's done that way, it's probably meant to be that way, > so don't touch it. The tool may check if the colums are correctly > aligned then, though. ;) > > But in no case it should reformat it. _If_ I really encountered such a remote case, I'd extract it to an .inc (something so perfect warrants an own file), and exclude it from the automatic run, and assign its maintenance to one single person. > > If it requires > > human interpretation, it is not simple (and worse, will lead to > > differing opinions in a Team and possible style-wars). > > As I said, code is for humans. If it doesn't require human > interpretation it's probably auto-generated and then I don't care about > the formatting. Yes. But you seems to assume that the amount of time invested in making it readable is linear with the benefit you get from it. It isn't. > If humans come in contact with the code, it should be formatted for > humans So? Why can't machine generat
Re: [fpc-pascal] FreePascal Coding style
Graeme Geldenhuys schrieb: On 21/01/2008, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: No, there isn't. I follow Borland coding style, but some others don't. You cannot force everyone to use the same style. And you should not. That's why we need a editor that supports 'elastic tab stops'. ;-) It's a brilliant idea, but might make your processor work a bit harder (but considering that most CPU's sit at idle 90% of their life, that's not really an issue). For more information on 'elastic tab stops' see the following website. He has a simple java demo editor showing it in action. http://nickgravgaard.com/elastictabstops/ I tried the example in action and its awefull. I tried this: if x = 1 then begin// my comment on ifs y:= 2;//yes y gets 2 end; this was NOT what I wanted - to make it "better" i changed to: if x = 1 then begin// my comment on ifs y:= 2;//yes y gets 2 end; not nice eighter - I am to stupid for those smart elastic tabs. cheers, Adrian. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Monday 21 January 2008 14:31, Marco van de Voort wrote: > > On Monday 21 January 2008 13:54, Marco van de Voort wrote: > > > > | Push, Pop, > > > > | ...); > > > > > > > > Now, as you can see, the instructions are laid out tabular (a > > > > lot of tools [yes, including "elastic tabstops"] I've seen so > > > > far are unable to handle even that simple case). > > > > > > Then you'll add a tool switch to make enums tabbable. That's > > > actually an easier example than Graeme's original. > > > > Oh, come on. What if you encounter an enum that does *not* require > > such "tabbing" inside the same source file. > > Well, "require" or not is relative to begin with. Let me rephrase it: A tool would have destroyed information if it would have reformatted such code. That's simply not tolerable. > Well, I'd say group of source files yes. And I wouldn't bother with > it in the first place (which is the point with making it an artform). Well, it doesn't need an artist, it needs disciplined developers. > > Also to be checked in into version control in case the source file > > somehow changes and its formatting configuration needs to be > > adjusted. > > That's the big advantage of doing it automatedly. That's what the guy told us, too. It never worked out. Coders wrote code, checked it into CVS and it came out differently. The didn't even know their own code anymore, just five seconds after they committed it. > You only do it > periodically (e.g. on a big release), and for the rest you don't > enforce, but just keep it minimally readable by hand. That's what an editor is for. It helps you to keep the general coding style by "suggesting" how to layout the code, but it should not force you. It should allow you to deviate from the usual rule - if that's justified (of course, *this* is a human decision). Running automated tools over the code destroys the information put in there exactly *by* deviating from the rule. If I did that, I did it for a reason. > > I didn't say, it's a requirement. But I don't want a tool to > > reformat code, which has been explicitely logically ordered for > > readability, a better overview over the instruction set, and for > > easier extensionby the coder. > > Well, that is the problem indeed. You WANT too much :-) Oh, common sense is too much already? :D > Per enum decision to tabbed or not is not simple. Yes, it is: If it's done that way, it's probably meant to be that way, so don't touch it. The tool may check if the colums are correctly aligned then, though. ;) But in no case it should reformat it. > If it requires > human interpretation, it is not simple (and worse, will lead to > differing opinions in a Team and possible style-wars). As I said, code is for humans. If it doesn't require human interpretation it's probably auto-generated and then I don't care about the formatting. If humans come in contact with the code, it should be formatted for humans. The computer doesn't care about the number of spaces, blank, or comment lines... and it doesn't even care about the actual meaning of the code. > That is btw also the reason why I tend to choose some tool, configure > it once, and then declare it gold as far as configuring goes. And my previous paragraph is the reason, why I would never auto-format any code. I may use some tool to "preformat" code (code coming from a third-party using a totally different coding style or some terrible, historically grown, legacy code), but I would never try to destroy the original intend of the developer. > And > also discourage purely style guide related commits/thunks. If it > ain't broke, then don't fix. If it's not understandable, it's broke. If it clearly violates an important guide-line of the coding-style, it's broke. Code is not only pure functionality in terms of bits and bytes. It's an intend expressed by someone. > Everybody can check what the tool produces for themselves, > end-of-discussion. Aspirant sourcecode-artists in my team can pick up > painting in their own free time. It doesn't have to do with art. It's fricking documentation. > > The only problem with those simple rules is that they can bend and > > there's no tool yet which knows how far it may bend the rule for > > formatting a certain piece of code... ;) > > And worse, no person either, if you have several. Well, as long as they obey the rules... > > There's only one: You need to easily understand it when you read > > it. Even if you read it 10 or 15 years after it has been written. > > And contrary to popular beliefs, there's a substantial amount of > > visual appearance involved. > > Yes. But I go for the 80%, not the 100% in this case. So why need the tool? If you can't trust the developers to maintain a certain style, how trustworthy is their code? > > In other words: Sexy code is easier to understand. ;) > > If you are attracted to THAT kind of sexy alone. Tastes vary. I did it on purpose. Usually
Re: [fpc-pascal] property or public
Damien Gerard wrote: On Jan 21, 2008, at 2:52 PM, Joao Morais wrote: Damien Gerard wrote: I have (it would seem) a stupid question :) We have TStringList vars. User can do what he want with it. Which one is the stupid or the better way to do it ? TMyClass = class(TObject) public List1: TStringList; List2: TStringList; end; or TMyClass = class private FList1: TStringList; FList2: TStringList; public property List1: TStringList read FList1; property List2: TStringList read FList2; end; The later, *much* better. You should never use class members outside the private area. Thanks ! What is the reason ? I am happy I was right but I need some reason :) Encapsulation, on behalf of the integrity of the instance. -- Joao Morais ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Monday 21 January 2008 14:23, Graeme Geldenhuys wrote: > On 21/01/2008, Vinzent Hoefler <[EMAIL PROTECTED]> wrote: > > Yes, that's what I figured. But that's wrong. Only legasthenic > > retards[1] put spaces at the inside of parentheses. > > Padding can be adjusted in the editor supports ET customization so > you wouldn't see the space. I would see it in "vi", for example. No use to me, I often have to work on a plain console with no fancy UI. (That's the reason why I hate lines longer than 79 chars.) And hell, once I'm starting to format code for a specific editor, I might as well start using binaries which are interpreted and turned into code by an editor which supports the "binary tabbed" feature. (Yes, I know, I'm exaggerating now. But I've had this kind of discussion many times already, so I'm kind of tired of it. Each time I proved the tool could be tricked to do something I didn't want it to do, he tweaked the options again (then the tool simply failed at a different location), or he tried to convince me to change my coding style to suit the tool's needs. Then I explained him that a tool is something that I want to work /with/, not /against/. > > And when it reloads, everything "semantic" you put in with the tab > > stops, got lost. Effort wasted, file needs to be reformatted. > > Nope, on reopening the file, formatting is exactly like it was the > last time you edited it. I doubt that. As far as I can see, the semantics is all in the tabs and if it does convert the tabs into spaces prior to saving the file, it will simply lose the semantics and may - at best - start guessing again. > As for slowing you down. Using your code example, you would have had > to type many spaces to align the code. Actually, no. What kind of editors are you using? Any decent editor stays in the column where the previous line begins, so after the second line I only need to press enter and I'm right there. > ET would only need one keystroke. No. It wouldn't know where I want to align it. How? I'd need another keystroke a line before already. That means, my brain even needs to type ahead. No problem there, but if you want to count keystrokes... In the end it's probably the same with or without "ET". Once I'm in the right column, I still only press Enter to jump to the next line (properly aligned already). > And as you insert more code in line above or below, all > columns will shift together, whereas using spaces, you would manually > have to realign all your columns. Then you have the wrong editor. In my editor I can shift in or out any selected block as I want to. So, all things you describe would be possible (or even faster) with those magic "elastic tabstops" - I am doing already without them. And before we get carried away to much, as long as you use your single favourite editor, ET doesn't matter (except when you want to use proportional fonts for source code). Most, if not all indentation magic an editor does today, works with tabs, and spaces, or without them, no matter if those tabs are elastic, plastic or hard as a pen^Wstone. The only difference seems to me, that without tabs the source code still looks the same, no matter if I look at it in "vi", "gedit", "kate", or "notepad". Once you start using tabs this isn't guaranteed anymore... Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] property or public
On Jan 21, 2008, at 2:52 PM, Joao Morais wrote: Damien Gerard wrote: I have (it would seem) a stupid question :) We have TStringList vars. User can do what he want with it. Which one is the stupid or the better way to do it ? TMyClass = class(TObject) public List1: TStringList; List2: TStringList; end; or TMyClass = class private FList1: TStringList; FList2: TStringList; public property List1: TStringList read FList1; property List2: TStringList read FList2; end; The later, *much* better. You should never use class members outside the private area. Thanks ! What is the reason ? I am happy I was right but I need some reason :) -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] property or public
Damien Gerard wrote: I have (it would seem) a stupid question :) We have TStringList vars. User can do what he want with it. Which one is the stupid or the better way to do it ? TMyClass = class(TObject) public List1: TStringList; List2: TStringList; end; or TMyClass = class private FList1: TStringList; FList2: TStringList; public property List1: TStringList read FList1; property List2: TStringList read FList2; end; The later, *much* better. You should never use class members outside the private area. -- Joao Morais ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] property or public
I have (it would seem) a stupid question :) We have TStringList vars. User can do what he want with it. Which one is the stupid or the better way to do it ? TMyClass = class(TObject) public List1: TStringList; List2: TStringList; end; or TMyClass = class private FList1: TStringList; FList2: TStringList; public property List1: TStringList read FList1; property List2: TStringList read FList2; end; -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
> On Monday 21 January 2008 13:54, Marco van de Voort wrote: > > > | Push, Pop, > > > | ...); > > > > > > Now, as you can see, the instructions are laid out tabular (a lot > > > of tools [yes, including "elastic tabstops"] I've seen so far are > > > unable to handle even that simple case). > > > > Then you'll add a tool switch to make enums tabbable. That's actually > > an easier example than Graeme's original. > > Oh, come on. What if you encounter an enum that does *not* require > such "tabbing" inside the same source file. Well, "require" or not is relative to begin with. > Of course you can do it all configurable until the tool formats as you > would like it to format, but in the end this leads to one tool > configuration per source file. Well, I'd say group of source files yes. And I wouldn't bother with it in the first place (which is the point with making it an artform). The only exception that I make is if the source is your actualy product (if you sell components with source, or publish FPC RTL). And e.g. FPC already has a metafile per sourcefile in the documentation, so having some formatting options there is not _THAT_ strange. Verbatim (don't touch) is then also an option. (not that I plan to add this anytime soon) > Also to be checked in into version control in case the source file somehow > changes and its formatting configuration needs to be adjusted. That's the big advantage of doing it automatedly. You only do it periodically (e.g. on a big release), and for the rest you don't enforce, but just keep it minimally readable by hand. > > Note that this is the first time that I actually saw this enum > > formatting as an requirement. Do you have a criterium for this? > > I didn't say, it's a requirement. But I don't want a tool to reformat > code, which has been explicitely logically ordered for readability, a > better overview over the instruction set, and for easier extensionby > the coder. Well, that is the problem indeed. You WANT too much :-) > > > And even if the tool is a bit more intelligent and detects the > > > tabular design, how is it supposed to know which instructions are > > > more similar to the other and should appear in a row and which ones > > > not? > > > > If you make coding standards an artform, you'll need an artist. > > No. A simple set of rules is sufficient. Per enum decision to tabbed or not is not simple. If it requires human interpretation, it is not simple (and worse, will lead to differing opinions in a Team and possible style-wars). That is btw also the reason why I tend to choose some tool, configure it once, and then declare it gold as far as configuring goes. And also discourage purely style guide related commits/thunks. If it ain't broke, then don't fix. Everybody can check what the tool produces for themselves, end-of-discussion. Aspirant sourcecode-artists in my team can pick up painting in their own free time. > The only problem with those simple rules is that they can bend and there's > no tool yet which knows how far it may bend the rule for formatting a > certain piece of code... ;) And worse, no person either, if you have several. > > The only exception I can see is documentation, but then you'll need > > meta info to the formatter. Either in source, or out source > > (unitname.enumx.style:=tabular or something in some metafile) > > Yeah, great. Just like /*INDENT-OFF*/ in each and every C-source file > I've ever checked into the company's CVS before we threw out the whole > auto-formatting on check-in. See above. I despise in-source metadata, which is why I like fpdoc so much. > > > Code is primarily written for humans. Otherwise we wouldn't care > > > about the formatting. Interestingly, to format code properly you'd > > > need to understand it. And that's something that currently only a > > > human can do. > > > > Depends on your definition of "properly". > > There's only one: You need to easily understand it when you read it. > Even if you read it 10 or 15 years after it has been written. And > contrary to popular beliefs, there's a substantial amount of visual > appearance involved. Yes. But I go for the 80%, not the 100% in this case. And safe 50% in discussion in the process. > In other words: Sexy code is easier to understand. ;) If you are attracted to THAT kind of sexy alone. Tastes vary. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On 21/01/2008, Vinzent Hoefler <[EMAIL PROTECTED]> wrote: > > Yes, that's what I figured. But that's wrong. Only legasthenic > retards[1] put spaces at the inside of parentheses. Padding can be adjusted in the editor supports ET customization so you wouldn't see the space. > To be more clear on the subject: Parentheses are not operators, although > a lot of people like to treat them so in source code while they miss to > put the spaces around the real operators.[2] I know, Lazarus IDE does (or did) that. I had to tweak my editor settings to get it 'right'. > And when it reloads, everything "semantic" you put in with the tab > stops, got lost. Effort wasted, file needs to be reformatted. Nope, on reopening the file, formatting is exactly like it was the last time you edited it. As for slowing you down. Using your code example, you would have had to type many spaces to align the code. ET would only need one keystroke. And as you insert more code in line above or below, all columns will shift together, whereas using spaces, you would manually have to realign all your columns. ET would bu much faster it that case. Either way, Lazarus (which is my favourite programming editor) internal editor doesn't support TabStops, so I can't implement ET anyhow. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Monday 21 January 2008 13:54, Marco van de Voort wrote: > > On Monday 21 January 2008 11:59, Marco van de Voort wrote: > > > > Nor does an editor. It can only help. I also think being to focussed > on coding standards (to the point of enforcing) is counterproductive. > > > As an example where most tools just put out nonsense, consider this: > > |type > > | CPU_Ins = (Add, Sub, Mul, Div, > > | Jnz, Jz, Jnc, Jc, > > | Call, Ret, > > | Push, Pop, > > | ...); > > > > Now, as you can see, the instructions are laid out tabular (a lot > > of tools [yes, including "elastic tabstops"] I've seen so far are > > unable to handle even that simple case). > > Then you'll add a tool switch to make enums tabbable. That's actually > an easier example than Graeme's original. Oh, come on. What if you encounter an enum that does *not* require such "tabbing" inside the same source file. Of course you can do it all configurable until the tool formats as you would like it to format, but in the end this leads to one tool configuration per source file. Also to be checked in into version control in case the source file somehow changes and its formatting configuration needs to be adjusted. > Note that this is the first time that I actually saw this enum > formatting as an requirement. Do you have a criterium for this? I didn't say, it's a requirement. But I don't want a tool to reformat code, which has been explicitely logically ordered for readability, a better overview over the instruction set, and for easier extensionby the coder. > > And even if the tool is a bit more intelligent and detects the > > tabular design, how is it supposed to know which instructions are > > more similar to the other and should appear in a row and which ones > > not? > > If you make coding standards an artform, you'll need an artist. No. A simple set of rules is sufficient. The only problem with those simple rules is that they can bend and there's no tool yet which knows how far it may bend the rule for formatting a certain piece of code... ;) The first universal rule is that the code needs to be readable. This overrules any other rule anyway. > The only exception I can see is documentation, but then you'll need > meta info to the formatter. Either in source, or out source > (unitname.enumx.style:=tabular or something in some metafile) Yeah, great. Just like /*INDENT-OFF*/ in each and every C-source file I've ever checked into the company's CVS before we threw out the whole auto-formatting on check-in. Ok, GNU-indent is probably not the best auto-formatter (in fact, it's one of the worst I've ever seen), but you get the idea, I suppose. > > Code is primarily written for humans. Otherwise we wouldn't care > > about the formatting. Interestingly, to format code properly you'd > > need to understand it. And that's something that currently only a > > human can do. > > Depends on your definition of "properly". There's only one: You need to easily understand it when you read it. Even if you read it 10 or 15 years after it has been written. And contrary to popular beliefs, there's a substantial amount of visual appearance involved. In other words: Sexy code is easier to understand. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
> On Monday 21 January 2008 11:59, Marco van de Voort wrote: > > > I personally would spend my time improving source beautifiers like > > our own ptop (and you could make them to automatically find these > > tabstops). > > Waste of time. Automated tools have never worked so far. Depends on you requirements. > Sure, they can turn totally unreadable, terribly formatted code into > something more understandable, but they can never *enforce* any kind of > coding standard. Nor does an editor. It can only help. I also think being to focussed on coding standards (to the point of enforcing) is counterproductive. > As an example where most tools just put out nonsense, consider this: > > |type > | CPU_Ins = (Add, Sub, Mul, Div, > | Jnz, Jz, Jnc, Jc, > | Call, Ret, > | Push, Pop, > | ...); > > Now, as you can see, the instructions are laid out tabular (a lot of > tools [yes, including "elastic tabstops"] I've seen so far are unable > to handle even that simple case). Then you'll add a tool switch to make enums tabbable. That's actually an easier example than Graeme's original. Positioning comments, specially over block border is what these tools are generally bad at. Note that this is the first time that I actually saw this enum formatting as an requirement. Do you have a criterium for this? > And even if the tool is a bit more intelligent and detects the tabular > design, how is it supposed to know which instructions are more similar > to the other and should appear in a row and which ones not? If you make coding standards an artform, you'll need an artist. For me it is mainly meant functional, and a tool suffices. My main gripe with ptop and h2pas are comment positioning. The rest pretty much suffices. The only exception I can see is documentation, but then you'll need meta info to the formatter. Either in source, or out source (unitname.enumx.style:=tabular or something in some metafile) > Code is primarily written for humans. Otherwise we wouldn't care about > the formatting. Interestingly, to format code properly you'd need to > understand it. And that's something that currently only a human can do. Depends on your definition of "properly". ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Monday 21 January 2008 13:27, Graeme Geldenhuys wrote: > On 21/01/2008, Vinzent Hoefler <[EMAIL PROTECTED]> wrote: > > But how would it solve > > > > |type > > | FooBar = (Foo, > > | Bar); > > Look at the flash demo on the website for an example of this! > Lets say gEdit (linux editor) has support for ET. > > You would type > > type > FooBar = (Foo, > Bar ); Yes, that's what I figured. But that's wrong. Only legasthenic retards[1] put spaces at the inside of parentheses. > type >FooBar = ( Foo, > Bar ); Yes. And that's precisely what I *DON'T* want: Spaces to break the reading flow. To be more clear on the subject: Parentheses are not operators, although a lot of people like to treat them so in source code while they miss to put the spaces around the real operators.[2] > The other nice thing is, it's font independent. You can even use > variable width fonts and it will still line up correctly. I know. I've read about this before (I think it was mentioned on the "Embedded Muse" a while ago). >> Whenever > you press TAB, it tries to find the closest TabStop (a tabstop is NOT > a tab character) normally from the lines before it. Then when you > save, it can convert the alignment to spaces. And when it reloads, everything "semantic" you put in with the tab stops, got lost. Effort wasted, file needs to be reformatted. > As I said, it took me a while to fully understand ET as well. :) All I understood so far is the same as with all the other tools: If you write your code like a moron to suite the tool, the tool suits you.[3] To put it more bluntly: Code formatting does not follow strict rules, there are always some heuristics involved. So even two different formatting of the same code may not violate coding style. Now, a tool can choose whatever heuristic it wants, there *will* be corner cases where the tool will fail, no matter what heuristics it chooses. That's inherent to heuristics. Following stricter rules only leads to harder-to-read code (like the code with the misplaced parentheses). Vinzent. [1] No offense, it's not meant personally. But as someone who reads a whole Tom Clancy on a 5-hour train ride, I'm accustomed to a certain style. And that also means, any deviation from that slows me down considerably. [2] Now that I know whose tool is responsible for that I can go and shoot the author. ;) [3] Also see [1]. I don't need tools to slow me down. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On 21/01/2008, Vinzent Hoefler <[EMAIL PROTECTED]> wrote: > > But how would it solve > > |type > | FooBar = (Foo, > | Bar); Look at the flash demo on the website for an example of this! Lets say gEdit (linux editor) has support for ET. You would type type FooBar = (Foo, Bar ); That would result in (if you email shows monospaced fonts): type FooBar = ( Foo, Bar ); The other nice thing is, it's font independent. You can even use variable width fonts and it will still line up correctly. Whenever you press TAB, it tries to find the closest TabStop (a tabstop is NOT a tab character) normally from the lines before it. Then when you save, it can convert the alignment to spaces. If the editor fully support ET then you can set the MinimumWidth (defaults to 40 pixels I think) and PaddingWidth (defaults to 16 pixels I think). As you can see it uses pixels and not character widths. ET changes the visual appears in the editor and it does this with editor TabStops and not inserted characters. As I said, it took me a while to fully understand ET as well. :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Monday 21 January 2008 13:01, Graeme Geldenhuys wrote: > On 21/01/2008, Vinzent Hoefler <[EMAIL PROTECTED]> wrote: > > As an example where most tools just put out nonsense, consider this: > > |type > > | CPU_Ins = (Add, Sub, Mul, Div, > > | Jnz, Jz, Jnc, Jc, > > | Call, Ret, > > | Push, Pop, > > | ...); > > This is so easy to accomplish with 'elastic tabstops' (ET). No, it ain't. > ET is > all about keeping alignment of text in columns. Trailing comments, > column in code like you shown above etc..Just watch the flash demo of > ET or try the Java example (though a bit dated I believe). I tried the Java example and the first thing which struck me was this: |int someDemoCode( int fred, | int wilma) ^^ To accomplish it's task of detecting tabular design, it inserts tabstops where no tabstops belong. Tests: 1) If I remove the tab before "int fred", the "int wilma" is not even aligned anymore. Even worse. 2) If I put the tabstop "typographically correct" as it should be (that means: right before the parentheses)[1], it aligns "int wilma", but of course right after the tab stop, so it doesn't start below "int fred", but right below the parentheses. Wrong, again. And that's what the Eclipse auto-formatter already did for years and the reason why we disabled it. We simply came to the conclusion, that if we manually format with spaces we'll be typing faster, because we wouldn't have to fight the "tool" anymore. Further, all this even bites with the "it only saves spaces". If it does in the end, then there's no way to detect where the tabs were supposed to be. So, as I've mentioned already, that's another tool that fails the task. Not to mention, that I initially talked about automated tools, not mere "editor-plugins", that even seem to even fail on the first try to reload a saved file and display it the same as before I saved it. Vinzent. [1] In normal text( you don't write parentheses like that ), do you? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Monday 21 January 2008 12:40, Graeme Geldenhuys wrote: > alignment as pretty as can be. But once you save, it inserts the > correct amount of spaces to keep that same alignment on file or > (preferred) inserts the minimum spaces for standard indentation > (Object Pascal uses two spaces for indentation). I still fail to see how it decides between new line of code (same indentation level) and continuation line (exceeded 80 characters on a line). Both case require different indendation. > It doesn't use tab characters. At least. ;) But how would it solve |type | FooBar = (Foo, | Bar); ? The three spaces before FooBar are surely standard indendation (I use three, yes), so I assume it can handle that, but the rest has to be filled up with spaces. So what happens if I insert a "soft" tab after the equal-sign? Would it automatically detect, that "Bar" should be aligned precisely below the "Foo", but without the parentheses? Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On 21/01/2008, Vinzent Hoefler <[EMAIL PROTECTED]> wrote: > > As an example where most tools just put out nonsense, consider this: > > |type > | CPU_Ins = (Add, Sub, Mul, Div, > | Jnz, Jz, Jnc, Jc, > | Call, Ret, > | Push, Pop, > | ...); This is so easy to accomplish with 'elastic tabstops' (ET). ET is all about keeping alignment of text in columns. Trailing comments, column in code like you shown above etc..Just watch the flash demo of ET or try the Java example (though a bit dated I believe). > So what does the tool do? Reformat it to some kind of coding standard > like that: > > type CPU_Ins = (Add, Sub, Mul, Div, Jnz, Jz, Jnc, > Jc, Call, Ret, Push, Pop, ...) ET doesn't do this! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On 21/01/2008, Marco van de Voort <[EMAIL PROTECTED]> wrote: > > Such schemes have been tried before, but usually fail since that makes > source only (practically) editable with one editor, which most users loath. > I don't see what's so different about this one. > > Also think about e.g. the trouble with RCS, patch systems etc. Okay, but did you actually try the example application to see how it works? I'll explain, as it was a bit confusing for me as well - I could see the point either (in the beginning). Elastic tabstops saves the files with spaces, NOT tabs. So if you load those files with any editor that doesn't support Elastic Tabstops, they are formatted as normal, using spaces. If you open that file with a editor supporting Elastic Tabstops if inserts tabstops to keep alignment correct. My inserting tabstops, I mean in the editor window, NOT the source code. It's like editing a document in OpenOffice or Word and using Left or Right Align tabstops. So for Elastic Tabstops to work, you need a editor component which supports tabstops - the Lazarus editor doesn't, so I couldn't implement it. So while you work with the file in the editor, tabstops are inserted, removed or move around to keep text alignment as pretty as can be. But once you save, it inserts the correct amount of spaces to keep that same alignment on file or (preferred) inserts the minimum spaces for standard indentation (Object Pascal uses two spaces for indentation). It doesn't use tab characters. The later option works best when you have people that prefer different indentation levels as the editor will automatically replace the two space indentation with a tabstop in the editor at the correct indentation level. Version control software can all handle spaces without issue. Elastic Tabstops works on the *visual appearance* of code in the editor window only, whereas other people tried the visual appears _and_ the saved appearance. Elastic Tabstops is actually a very cleaver idea. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Monday 21 January 2008 11:59, Marco van de Voort wrote: > I personally would spend my time improving source beautifiers like > our own ptop (and you could make them to automatically find these > tabstops). Waste of time. Automated tools have never worked so far. Sure, they can turn totally unreadable, terribly formatted code into something more understandable, but they can never *enforce* any kind of coding standard. At best you can use them as tool to check against given guidelines and spit out a warning where the tool thinks some of the guidelines are violated (things like: "subprograms are not in alphabetical order", "wrong indendation", "comment starts at wrong column"). As an example where most tools just put out nonsense, consider this: |type | CPU_Ins = (Add, Sub, Mul, Div, | Jnz, Jz, Jnc, Jc, | Call, Ret, | Push, Pop, | ...); Now, as you can see, the instructions are laid out tabular (a lot of tools [yes, including "elastic tabstops"] I've seen so far are unable to handle even that simple case). So what does the tool do? Reformat it to some kind of coding standard like that: type CPU_Ins = (Add, Sub, Mul, Div, Jnz, Jz, Jnc, Jc, Call, Ret, Push, Pop, ...) to destroy the programmer's initial intent - which was to put similar CPU instructions into a single row and also set them out in a tabular way to make them more distinct? And even if the tool is a bit more intelligent and detects the tabular design, how is it supposed to know which instructions are more similar to the other and should appear in a row and which ones not? Code is primarily written for humans. Otherwise we wouldn't care about the formatting. Interestingly, to format code properly you'd need to understand it. And that's something that currently only a human can do. At least to my knowledge. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
> On 21/01/2008, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > No, there isn't. I follow Borland coding style, but some others don't. > > You cannot force everyone to use the same style. And you should not. > > That's why we need a editor that supports 'elastic tab stops'. ;-) > It's a brilliant idea, but might make your processor work a bit harder > (but considering that most CPU's sit at idle 90% of their life, that's > not really an issue). > > For more information on 'elastic tab stops' see the following website. > He has a simple java demo editor showing it in action. > http://nickgravgaard.com/elastictabstops/ Such schemes have been tried before, but usually fail since that makes source only (practically) editable with one editor, which most users loath. I don't see what's so different about this one. Also think about e.g. the trouble with RCS, patch systems etc. I personally would spend my time improving source beautifiers like our own ptop (and you could make them to automatically find these tabstops). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On 21/01/2008, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > No, there isn't. I follow Borland coding style, but some others don't. > You cannot force everyone to use the same style. And you should not. That's why we need a editor that supports 'elastic tab stops'. ;-) It's a brilliant idea, but might make your processor work a bit harder (but considering that most CPU's sit at idle 90% of their life, that's not really an issue). For more information on 'elastic tab stops' see the following website. He has a simple java demo editor showing it in action. http://nickgravgaard.com/elastictabstops/ Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: -Xg flag and lineinfo/lnfodwrf support
Hi, 2008/1/21, Peter Vreman <[EMAIL PROTECTED]>: > > We have a compiled file with debug info (ex: using -gl flag) of 10Mb (about > > 8Mb are Debug). > > > > Currently you use: > > > > objcopy --only-keep-debug $EXE $DBG (read from disk 10Mb from $EXE and > > write 8Mb for create $DBG) > > objcopy --add-gnu-debuglink=$DBG $EXE (read from disk 10Mb from $EXE and > > 8Mb from $DBG, for calculate CRC32, and wrote 10Mb of modifyed $EXE) > > strip --strip-unneeded $EXE (read from disk $10Mb from $EXE and write to > > disk 2Mb of modified $EXE) > > > > TOTAL: > > Read from disk: 10+10+8+10 = 38 Mb > > Write to disk : 8+10+2 = 20 Mb > > > > -- > > > > My new method is: > > > > mv $EXE $DBG (read 0, write 0) > > strip --strip-unneeded $DBG -o $EXE (read from disk 10Mb from $DBG and > > write 2Mb to create stripped $EXE) > > objcopy --only-keep-debug $DBG $DBG (read from disk 10Mb from $DBG and > > write 8Mb of stripped $DBG) > > objcopy --add-gnu-debuglink=$DBG $EXE (read from disk 2Mb from $EXE and > > 8Mb from $DBG, for calculate CRC32, and wrote 2Mb of modifyed $EXE) > > > > TOTAL: > > Read from disk: 10+10+2+8 = 30 Mb > > Write to disk : 2+8+2 = 12 Mb > > > > > > As you can see using my new method is possible reduce the read access of > > about 20% and the write access of about the 40% (the great improvement). > > > > > > What do you think about? ;) > > It is just changing the order "strip --strip-unneeded" and "objcopy > --add-gnu-debuglink" not the > same? Do you think to apply this change? :) -- Best regards... Fabio Dell'Aria. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: -Xg flag and lineinfo/lnfodwrf support
Hi, 2008/1/21, Peter Vreman <[EMAIL PROTECTED]>: > > We have a compiled file with debug info (ex: using -gl flag) of 10Mb (about > > 8Mb are Debug). > > > > Currently you use: > > > > objcopy --only-keep-debug $EXE $DBG (read from disk 10Mb from $EXE and > > write 8Mb for create $DBG) > > objcopy --add-gnu-debuglink=$DBG $EXE (read from disk 10Mb from $EXE and > > 8Mb from $DBG, for calculate CRC32, and wrote 10Mb of modifyed $EXE) > > strip --strip-unneeded $EXE (read from disk $10Mb from $EXE and write to > > disk 2Mb of modified $EXE) > > > > TOTAL: > > Read from disk: 10+10+8+10 = 38 Mb > > Write to disk : 8+10+2 = 20 Mb > > > > -- > > > > My new method is: > > > > mv $EXE $DBG (read 0, write 0) > > strip --strip-unneeded $DBG -o $EXE (read from disk 10Mb from $DBG and > > write 2Mb to create stripped $EXE) > > objcopy --only-keep-debug $DBG $DBG (read from disk 10Mb from $DBG and > > write 8Mb of stripped $DBG) > > objcopy --add-gnu-debuglink=$DBG $EXE (read from disk 2Mb from $EXE and > > 8Mb from $DBG, for calculate CRC32, and wrote 2Mb of modifyed $EXE) > > > > TOTAL: > > Read from disk: 10+10+2+8 = 30 Mb > > Write to disk : 2+8+2 = 12 Mb > > > > > > As you can see using my new method is possible reduce the read access of > > about 20% and the write access of about the 40% (the great improvement). > > > > > > What do you think about? ;) > > It is just changing the order "strip --strip-unneeded" and "objcopy > --add-gnu-debuglink" not the > same? Yes! ;) -- Best regards... Fabio Dell'Aria. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: -Xg flag and lineinfo/lnfodwrf support
> We have a compiled file with debug info (ex: using -gl flag) of 10Mb (about > 8Mb are Debug). > > Currently you use: > > objcopy --only-keep-debug $EXE $DBG (read from disk 10Mb from $EXE and > write 8Mb for create $DBG) > objcopy --add-gnu-debuglink=$DBG $EXE (read from disk 10Mb from $EXE and > 8Mb from $DBG, for calculate CRC32, and wrote 10Mb of modifyed $EXE) > strip --strip-unneeded $EXE (read from disk $10Mb from $EXE and write to > disk 2Mb of modified $EXE) > > TOTAL: > Read from disk: 10+10+8+10 = 38 Mb > Write to disk : 8+10+2 = 20 Mb > > -- > > My new method is: > > mv $EXE $DBG (read 0, write 0) > strip --strip-unneeded $DBG -o $EXE (read from disk 10Mb from $DBG and > write 2Mb to create stripped $EXE) > objcopy --only-keep-debug $DBG $DBG (read from disk 10Mb from $DBG and > write 8Mb of stripped $DBG) > objcopy --add-gnu-debuglink=$DBG $EXE (read from disk 2Mb from $EXE and > 8Mb from $DBG, for calculate CRC32, and wrote 2Mb of modifyed $EXE) > > TOTAL: > Read from disk: 10+10+2+8 = 30 Mb > Write to disk : 2+8+2 = 12 Mb > > > As you can see using my new method is possible reduce the read access of > about 20% and the write access of about the 40% (the great improvement). > > > What do you think about? ;) It is just changing the order "strip --strip-unneeded" and "objcopy --add-gnu-debuglink" not the same? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: -Xg flag and lineinfo/lnfodwrf support
Hi Peter, 2008/1/20, Peter Vreman <[EMAIL PROTECTED]>: > > Ok Peter, > > I'm waiting for your news. > > Finished, see r9813 I think to have found a best method to implement -Xg flag on Linux: To explain my method I need compare your currently method with my new. To do this I use an example: We have a compiled file with debug info (ex: using -gl flag) of 10Mb (about 8Mb are Debug). Currently you use: objcopy --only-keep-debug $EXE $DBG (read from disk 10Mb from $EXE and write 8Mb for create $DBG) objcopy --add-gnu-debuglink=$DBG $EXE (read from disk 10Mb from $EXE and 8Mb from $DBG, for calculate CRC32, and wrote 10Mb of modifyed $EXE) strip --strip-unneeded $EXE (read from disk $10Mb from $EXE and write to disk 2Mb of modified $EXE) TOTAL: Read from disk: 10+10+8+10 = 38 Mb Write to disk : 8+10+2 = 20 Mb -- My new method is: mv $EXE $DBG (read 0, write 0) strip --strip-unneeded $DBG -o $EXE (read from disk 10Mb from $DBG and write 2Mb to create stripped $EXE) objcopy --only-keep-debug $DBG $DBG (read from disk 10Mb from $DBG and write 8Mb of stripped $DBG) objcopy --add-gnu-debuglink=$DBG $EXE (read from disk 2Mb from $EXE and 8Mb from $DBG, for calculate CRC32, and wrote 2Mb of modifyed $EXE) TOTAL: Read from disk: 10+10+2+8 = 30 Mb Write to disk : 2+8+2 = 12 Mb As you can see using my new method is possible reduce the read access of about 20% and the write access of about the 40% (the great improvement). What do you think about? ;) -- Best regards... Fabio Dell'Aria. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] find the "List index (1) out of bounds" error
Hi, Anybody got an idea how I can trace the location of a "List index (1) out of bounds" error. I can't seem to find where this error occurs. Is there any extra fpc parameters I can use to give me more information. I have placed writeln()'s in every damn location I can think of. I've tried to run it via GDB but the output is simply numbers relating to the TList class... I've narrowed it down to one fpGUI component, the TfpgComboBox. It only occurs if I open/close the combobox dropdown and then exit the application. If I don't touch the ComboBox, the program exits fine - without errors. From the backtrace I gather it's got todo with the internal TStringList used inside the TfpgComboBox. This is the actual error message I get when I quit my application. -[ cut ] << TMainForm.MsgClose >> TfpgComboBox.Destroy Freeing off the ComboBox items << TfpgComboBox.Destroy An unhandled exception occurred at $08077EBF : EListError : List index (1) out of bounds $08077EBF -[ end ]--- Here is the backtrace information: Breakpoint 1, 0x08055fe6 in fpc_raiseexception () (gdb) bt #0 0x08055fe6 in fpc_raiseexception () #1 0x08078288 in CLASSES_TFPLIST_$__ERROR$ANSISTRING$LONGINT () #2 0x08077ebf in CLASSES_TFPLIST_$__RAISEINDEXERROR$LONGINT () #3 0x08077ee2 in CLASSES_TFPLIST_$__GET$LONGINT$$POINTER () #4 0xb7c010e0 in ?? () #5 0xb7c011a0 in ?? () #6 0x08078a6a in CLASSES_TLIST_$__DELETE$LONGINT () #7 0xb7f5da60 in ?? () #8 0xb7c011a0 in ?? () #9 0x in ?? () (gdb) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Jan 21, 2008, at 9:31 AM, Tiziano De Togni wrote: Damien Gerard ha scritto: Is there a standard Coding style for FreePascal (Pascal) available which programmers should use ? It is for my boss :) these are the FPC documents: http://wiki.freepascal.org/Coding_style http://wiki.freepascal.org/DesignGuidelines but since FreePascal is Object Pascal, the Delphi guidelines should be equivalent: There are a couple of docs in the codegear repository, this is one: http://dn.codegear.com/it/article/10280 Anyway, this nice document is still online: Delphi 4 Developer's Guide Coding Standards Document http://www.econos.de/delphi/cs.html try a google search like this: pascal delphi "guidelines", and you will surely find something interesting... Thanks. -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
Damien Gerard ha scritto: Is there a standard Coding style for FreePascal (Pascal) available which programmers should use ? It is for my boss :) these are the FPC documents: http://wiki.freepascal.org/Coding_style http://wiki.freepascal.org/DesignGuidelines but since FreePascal is Object Pascal, the Delphi guidelines should be equivalent: There are a couple of docs in the codegear repository, this is one: http://dn.codegear.com/it/article/10280 Anyway, this nice document is still online: Delphi 4 Developer's Guide Coding Standards Document http://www.econos.de/delphi/cs.html try a google search like this: pascal delphi "guidelines", and you will surely find something interesting... tiziano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Jan 21, 2008, at 9:15 AM, Michael Van Canneyt wrote: On Mon, 21 Jan 2008, Damien Gerard wrote: Is there a standard Coding style for FreePascal (Pascal) available which programmers should use ? It is for my boss :) No, there isn't. I follow Borland coding style, but some others don't. You cannot force everyone to use the same style. And you should not. I follow Borland coding style too but we need the same coding style. Thanks. Just to be sure. -- Damien Gerard [EMAIL PROTECTED] Le temps n'a pas d'importance. Seul le code est important -- (f00ty) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Mon, 21 Jan 2008, Damien Gerard wrote: > > Is there a standard Coding style for FreePascal (Pascal) available which > programmers should use ? > It is for my boss :) No, there isn't. I follow Borland coding style, but some others don't. You cannot force everyone to use the same style. And you should not. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
