Re: [fpc-pascal] Lazarus settings and roaming profiles in Windows
On Thursday 16 July 2009, Jürgen Hestermann wrote: I am not sure having a 100 MB lazarus *roaming* profile by default would be a good idea. That's true (although my settings are only 130 kB but they may grow). Therefore it would be the best of all worlds to save the Lazarus settings to the Lazarus directory. No. A sane environment shouldn't even grant you write permissions there. Then you would not have any problems when using roaming profiles (neither losing settings nor performance impact when copying data on logon). But you would lose your settings when changing the machine, because then the settings aren't part of your profile anymore. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus settings and roaming profiles in Windows
On Thursday 16 July 2009, Luca Olivetti wrote: En/na Vinzent Hoefler ha escrit: But you would lose your settings when changing the machine, because then the settings aren't part of your profile anymore. Well, this is happening now, since CSIDL_LOCAL_APPDATA isn't roamed. Yes. So what's the advantage in using the Lazarus directory instead? ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus settings and roaming profiles in Windows
On Thursday 16 July 2009, Jürgen Hestermann wrote: Well, this is happening now, since CSIDL_LOCAL_APPDATA isn't roamed. Yes. So what's the advantage in using the Lazarus directory instead? ;) I wouldn't lose my settings on logoff. ;-) Then don't. ;) Usually I just locked the machine overnight. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The reason why linus torvalds hate-pascal
On Sunday 20 April 2008 19:21, Andreas Berger wrote: About break. I would like to see an implementation of Break(x) where x is the number of loops to break out of. Correction: I would not like this, I would LOVE it. Oh, another Adaism trying to creep into Pascal...? :D But let me revisit your proposal: Of course, break with such a number of level argument breaks your code (hence the name?), once you add another loop somewhere around it. In that case I'd rather go with goto. At least there's a label and a definite target to jump to. The alternative is the named loop as in Ada, which makes it possible to break out of more than just one loop, but wouldn't have the hassles of a where does this 'break (3)' lead us?. At least you name the loop you want to abandon at the point of exit and you can look up the label in the code, instead of counting the number of levels (and maybe even missing one). Sorry, but as much as you might think, you'd love this; if you really need something like that, rather use goto or throw a bloody exception. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hmm 64 bit instructions for visual studio 2008 slower than doubles too ?
On Monday 10 March 2008 21:02, Skybuck Flying wrote: Also when I set it to release, something strange happens and it only take 7 ticks or so... while normally it takes 5 million ticks ? It's called optimizing. Obviously it calculates the final result at compile time already. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] class constants
On Friday 25 January 2008 12:30, Peter Vreman wrote:
Regarding class constants: I missed them, too, already, although
not too much. ;)
Maybe you should read the documentation. Static fields are supported
already for 10 years:
~/fpc/compiler cat p.pp
{$mode objfpc}
{$static on}
type
cl=class
l : longint;static;
end;
var
c1,c2 : cl;
begin
c1:=cl.create;
c2:=cl.create;
c1.l:=2;
writeln(c2.l);
c2.l:=3;
writeln(c1.l);
end.
[EMAIL PROTECTED]
~/fpc/compiler ./p
2
3
[EMAIL PROTECTED]
~/fpc/compiler
Well, once upon a time I learned that there's a difference between a
variable and a constant, but ok; Borland might have changed that a bit
when they introduced the notion of a typed constant. ;)
More interesting here is that not only c1.L and c2.L works, but you
can even access the variable without an instance at all: cl.L, just
like it should. So at least there are class variables.
(It might prove a bit tricky to correctly initialize them, though.
AFAICS you can't give them initial values, can you? So to be on the
safe side, you're probably back to doing it in the initialization
section of the unit where the class is declared. This is a bit nasty.)
Still, something like
|cl =
|class
| const VersionId = '1.3.9a';
|end;
seems not possible. Of course, this is easily modeled by a simple class
method returning a constant value. That's why I said, I didn't miss
that feature too much.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] class constants
On Thursday 24 January 2008 20:27, Marco van de Voort wrote: On 24 Jan 2008, at 19:45, Marco van de Voort wrote: constants. A constant is already in a scope, the unit. So are constants local to a function. Being able to restrict the scope to a certain function or group of functions is nevertheless useful. To be honest, if we wouldn't be able to do that now, and a request for implementation came, my answer would be pretty much the same. Oh, well. That would make my logging much harder. |unit | Foo; | | ... | |const | MODULE_PREFIX = 'Foo.'; | |procedure Foobar; |const | PROC_PREFIX = MODULE_PREFIX + 'Foobar'; |begin | ... I would have to declare a different name for each subroutine and they wouldn't have the local scope (in case the subroutine gets refactored, the log name should also be changed). Names of nested subroutines would be almost impossible to maintain. Of course, this is of no practical use. It's just in about 70K lines of code of a real world project. Yes, I'm being a bit cynic here. Regarding class constants: I missed them, too, already, although not too much. ;) Vinzent. ___ 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)
On Tuesday 22 January 2008 09:48, Marco van de Voort wrote: Maybe. Keep in mind that opague is roughly comparable with type tmyopaguetype = type pointer; Since the interface must 100% define the interface so that it can be used, which is a hard rule with Pascal and Modula2. Hmm, what if --- 8 --- interface type tMyOpaqueType; // Incomplete. private type // Complete type declaration, but privately. tMyOpaqueType = record ... end; --- 8 --- would be possible? The type is still declared in the interface part; yet, because it's in the private part of the interface, no other module can use it's inner structure. This makes e.g. the operator overloading already hard, since it can't be a record (even variant). Well, yes and no. As I wrote, you'd need to store that information in the unit file. And it just implies that the type will always be a reference type, because that's about the only way to ensure consistent usage across multiple compilation units. Of course, at the low level, this means pointer. It is a bit the .NET class helper (partial classes) trick in a modular setting. From what I understood, those partial classes are different. They don't extend functionality, they split it (or maybe, the call it delegation of responsibility). It seems like a concept to both avoid the classic multiple inheritance problems and the issues with interfaces implementation. Maybe I got that totally wrong, but the name implies that I can't use a partial class in real world code, because it's, well, partial. That's not the case here. Each module provides its very own set of (working) functionality. Of course, any child package depends on its respective parent package, but it's not that you need both to do something useful. I don't like that either. The gain you get from your old and trusted code, you loose in complexity and clarity of overview in the module system Actually I don't understand that part of your argument. Any software system that contains more than a couple of lines of code is complex or is going to be. That's why modularization was invented in the first place: To be able to fight and handle that complexity in some way. I mean, I'm quite sure, you're not argueing for an all source in one large file approach... so instead of (shared) include files, child package would provide compiler checked extensibility. IMO, it's much like the package system for the compiler. At least how it's laid out: You have FCL that consists of FCL.Base, FCL.XML, ... (an import of complexnumbers in one place might suddenly react differently due to the partial module/classhelper) But that's the case already. Even the order of imports is semantically relevant (or well, it might be). Or what's with that reuse keywords for the uses clause? Not to say that it also hugely complicates the compiler, since it has to factor the possible existance of these slave units in any unit usage. Hmm. I don't see that. If I'd put the implementation all in the interface part, the compiler can handle it well already. The only difference would be some sort of flag that this or that information can only be used if it's a child package... Don't get me wrong, I don't want to say that it would be easy to change the compiler to handle this, but I wouldn't say hugely complicated, neither. It does most of the work already. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
On Tuesday 22 January 2008 15:18, mm wrote: Vinzent Hoefler a écrit : 2) If I put the tabstop typographically correct as it should be (that means: right before the parentheses)[1], [...] [1] In normal text( you don't write parentheses like that ), do you? And what about math functions? Is f (x) more typographically correct than f(x)? ;-) Due to the lack of differently spaced spaces, yes. ;) However, the function name and the parameters should also be visually distinct, so the former variant is to be preferred. Especially if we start the tabular layout again, then |function Random (l : LongInt) : LongInt; |function Random (l : Int64) : Int64; |function Random : Extended; looks better than |function Random(l : LongInt) : LongInt; |function Random(l : Int64) : Int64; |function Random : Extended; because in the first variant there's a clear visual distinction between the function name and the parameter name. But, either variant is still superior to f( x ). Vinzent. ___ 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)
On Tuesday 22 January 2008 21:36, Marco van de Voort wrote: type tmyopaguetype = type pointer; Since the interface must 100% define the interface so that it can be used, which is a hard rule with Pascal and Modula2. Hmm, what if --- 8 --- interface type tMyOpaqueType; // Incomplete. private type // Complete type declaration, but privately. tMyOpaqueType = record ... end; --- 8 --- would be possible? The type is still declared in the interface part; yet, because it's in the private part of the interface, no other module can use it's inner structure. No. Completely defines (most notably its size, probably also its alignment if it applies). In practice, nearly all M2 compilers only support pointers Yes, but that's what it does, defining it, I mean. The private keyword would only mark it as can't use, if you're not a child unit. It is still in the interface, and thus completely defined AFAICS. This makes e.g. the operator overloading already hard, since it can't be a record (even variant). Well, yes and no. As I wrote, you'd need to store that information in the unit file. You can't. Sb might already be needing the interface before the implementation is compiled. Yes, I know that. (Ada is a lot more strict about it, where interface (spec) and implementation (body) are even in different files and you can actually compile your code without the body available.) You may have overlooked it, but the incomplete type is already completed while still in the interface part. To be more clear on the subject, let me try a more complete example again: --- 8 --- unit Foo; interface type Bar = record; // Incomplete for now. procedure FooBar (Arg : Bar); private type Bar = record X : Integer; Y : Double; end; implementation ... end; --- 8 --- So it's still in the interface, the compiler has all the information it needs (even if only the interface is available at time of compilation), only that the inner working of the type is marked as sort of non-public. It's more a question of the type system, rather than trickery with the symbol tables. Or you may view it as a special form of a forward declaration. It is a bit the .NET class helper (partial classes) trick in a modular setting. From what I understood, those partial classes are different. They don't extend functionality, they split it (or maybe, the call it delegation of responsibility). As far as I see it they add functionality to a base container. In partial classes case a class, and in Ada's case a module. Maybe. I'm not a .NET-expert, but then the name is confusing at least. I understood that a class could be implemented in several different modules (I understood functionality sets) and only upon completion of all modules/functionality, the resulting class as a whole is usable. If that understanding is wrong, then I fail to see what partial classes do differently than a normal class. In the end, classes are there for extending them, that's more or less the whole point of OOP. Both also seem to require to include the relevant helper module explicitely to unlock the extension. Well, in Ada there are no helper modules, so this must be wrong for at least this case. ;) I don't like that either. The gain you get from your old and trusted code, you loose in complexity and clarity of overview in the module system [...] I mean, I'm quite sure, you're not argueing for an all source in one large file approach... so instead of (shared) include files, child package would provide compiler checked extensibility. I don't like the idea of modules being mutable (even if it only means extension of the container) The modules do *not* change in any way. You can extend them only by declaring it that way and need to put them in the uses clause if you want to use that extended functionality. It's no more mutable than adding Math_Complex as another unit to your source file as extension to the Math unit. Actually, it only takes the modularization to another level and makes it even more flexible. IMO, it's much like the package system for the compiler. At least how it's laid out: You have FCL that consists of FCL.Base, FCL.XML, ... I don't see any relation. Well, I do. YMMV. FCL only exists as parts of names and in documentation. On src level there are only the packages, and they are not spelled above (where they imply some hierarchic system), but with dashes that aren't separators. Yes, I tried to make an example, how such a system would look at source level. For me, I 1:1 relation between the documentation of an intended hierarchy and its appropriate source would be a good thing. (an import of complexnumbers in one place might suddenly react differently due to the partial module/classhelper) But that's the case already. Even the order of
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 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 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 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 tabFooBar = (tabFoo, tabBar ); 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 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 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] 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 a discussion gets more attention after sex has been thrown into it. ;) Vinzent.
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 is: If it's done that way, it's probably meant to be that way, so don't touch it.
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
Re: RES: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 20:12, John Stoneham wrote: [Ada package system] However, you can also do: with Unit_1; use Unit_1; This imports the namespace of Unit_1 into the current file so that now you *can* refernce foo without a qualifier. It's as if all the identifiers in Unit_1 were defined in the current file (and so yes, you can get conflicts). Yes, and that's what uses Unit_1; in Pascal does. The only difference between Pascal and Ada is that Ada complains about ambiguities (same identifier in different modules) while Pascal's scope model just uses the identifier from the last used module (while you're still able to overwrite that behaviour by prefixing the identifier just like you're required to do in Ada in case of ambiguities). 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 (and sometimes fails in a horrible way - I still remember the issue I once had, when I just reordered the used units and without changing any code, the application suddenly started crashing, because it used a different DisposeStr then. BTW, that's one of the reasons why I always use prefixed notation in Pascal now, just like I do in Ada). (As written before, this explanation is more from a user's point of view than from the view of a compiler writer.) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 12:35, Bee wrote: Well, the statements so far went like this sub.sub.unit stuff is just .NET crap, we won't implement any of those. ;) I don't like that kind of attitude either. .Net is not crap as a whole, it does have some good features and ability. Yeah, right. Nothing of that is new. It just wasn't hyped and backed by a big $ company before. If some of them are really good, then why not implement some of them in FPC too? *If*, yes. Don't get me wrong, I am not against this syntax (on the contrary, I'm even a strong supporter for easily extensible units), but I am against the (so far) suggested semantics. Namespaces are too flat and simply not powerful enough to justify the implementation and maintenance effort. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 12:16, Michael Fuchs wrote: Vinzent Hoefler schrieb: I think more interesting are dots in unit name for making better namespaces. Actually, I'm thinking child units. You mean like in Ada? Yes, this would be great. Are there any plans to implement this in future versions? Well, the statements so far went like this sub.sub.unit stuff is just .NET crap, we won't implement any of those. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 12:17, Matt Emson wrote: Vinzent Hoefler wrote: But even so, it still wouldn't help Bee, because he's not using it for namespaces, he's using it as special names for version control. This was the part I was attacking, if anyone else wondered. No problem, I just didn't get that from the glib you should learn how to program reply. That's not what I said. If at all I said you should learn how to engineer software. That's quite a difference. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 11:44, ik wrote: Personally I do not want to see this feature in Pascal, because it will just complicate things, because there is a use for dot in the Pascal language... Think records. If you can have unit.identifier.record_field ad infinitum (any record may contain another record), it's not too far fetched to extend that concept to unit.sub_unit. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 11:48, Michael Fuchs wrote: Bee schrieb: Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)? I think more interesting are dots in unit name for making better namespaces. Actually, I'm thinking child units. Namespaces don't even have the appropriate scoping rules. The Java language's package is a perfect example for that: No matter where you put the class, it only sees it's own package. There they missed a perfect opportunity to enforce scoping rules with the compiler instead of letting the programmer decide it all over again just like they did back in the 70s, where all programs were written in FORTRAN and never crossed the 1023 lines of code boundary. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 12:01, Matt Emson wrote: Vinzent Hoefler wrote: On Friday 18 January 2008 11:39, Bee wrote: I used to use this feature on Turbo Delphi Explorer. But since I totally switch to FPC/Laz and Ubuntu, I really missed this feature on FPC. :( No offense, but maybe this is a good time to start becoming a serious developer now? I think you are missing the point. No, I don't. Bee may indeed be misguided, but the feature is in Delphi[.Net] in general. Screw Delphi. That feature was in ISO-standardized Ada back in 1995 already. And there it's called child units. Name spaces have too flat scoping rules to be really useful. And yes, I'd like to have implemented that (child units) in FPC. But even so, it still wouldn't help Bee, because he's not using it for namespaces, he's using it as special names for version control. This was the part I was attacking, if anyone else wondered. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 11:16, Bee wrote: Why cant FPC use unit that has (some) dot(s) within the file name? Can FPC support it in the next release (2.2.2)? Probably not. And if at all, it wouldn't accomplish what you want to do. Sometimes I need to have some units for example: unit1.ori.pas and unit1.modif.pas, which I need to switch to one of them but never use them both. Then use the branch/switch feature of your favourite version control system. That's one thing it was designed for. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 14:06, Bee wrote: The more features it has, the better for the users. No. It's more like: The nice thing about standards is that you have so many to choose from. -- Andrew S. Tanenbaum (And yes, that was meant ironically.) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 14:56, Matt Emson wrote: I would say, remove unit replace with Namespace and all would be fine. And the same as before, just with a different syntax. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dot within unit file name
On Friday 18 January 2008 13:22, Matt Emson wrote: Vinzent Hoefler wrote: On Friday 18 January 2008 12:35, Bee wrote: Namespaces are too flat and simply not powerful enough to justify the implementation and maintenance effort. And units are better because...? *Child* units are better, because they provide both _compiler checked_ namespaces and clearly defined visibility rules. Namespaces don't. Namespaces are ugly C++ hacks from the time where the only namespace lied in the hope that a 6 letter identifier (where the first 2 letters were the initials of the programmer, two digits the project number and with the remaining two significant characters freely available to the programmer with the first one required to be an underscore[1]) would still link with the third party library from the vendor without having duplicate symbols to resolve. Vinzent. [1] All this naming convention may sound like a joke. Actually, it isn't.[2] [2] It may be a bit exaggerated, though. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Accessing ROM BIOS Font in Linux.
On Thursday 17 January 2008 01:27, [EMAIL PROTECTED] wrote: The question. Is this font accessible from linux; do I have to be root ? Yes. Yes. /dev/mem should be the raw memory device (where even the BIOS image can be read from), but this device which is only accessible to root. How do I make the 16 bit segment/offset address into a 32 bit pointer to access these fonts ? The same as in the old days: Multiply the segment with 16 and add the offset, which gives you the 32 bit (absolute/physical) address. This is basically the offset into the /dev/mem device file and thus can be fed to the (f)seek... Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Notice: Possible copyright infringements in FPC code base
On Thursday 17 January 2008 11:54, Jonas Maebe wrote: On 17 Jan 2008, at 08:02, Vinzent Hoefler wrote: On Wednesday 16 January 2008 17:49, Roberto Padovani wrote: Given that I don't have Delphi, suppose that company X ask me to make a software for them. I might give them the software, with full source code and a GPL licence note every here and there, and ask money for the _design_ of the software, instead of the software itself. Another misunderstanding of the GPL. Of course you are allowed to charge money for your software. But given it is GPL your customer may decide to redistribute the source, as you gave him explicit permission with the GPL to do so. It would simply put all your other code under GPL, too. And that is yet another misunderstanding of the GPL: it would *not* automatically make all the other code of that program GPL. Well, well, I didn't say *that*. But with and a GPL licence note every here and there I would have assumed it, of course. If you do not license the rest of the source code under the GPL (or under a GPL-compatible license), you are simply infringing on the copyright of the author(s) of the GPL code: your are using that code in a way which is not allowed by the GPL. Ok, yes. If you read it this way. OTOH it said with full source code, so as a customer I'd assume at least, that everything is GPLed here, even if it does not say so explicitely in each single source file. And even then, you would be allowed to give it to the customer as is, as you're providing the full source code as required by the GPL. In any case, whoever receives a program containing a mixture of GPL and GPL-incompatible code, is not allowed to further distribute it either (because he would infringe on the copyright of author(s) of the GPL code just as much as the initial distributor). Sorry, but that's not true per se. I *am* allowed to use GPL code in an internal project without redistributing it. Ok, the next paragraph can be considered quite cynical, so if you don't like, don't read it. AFAICS I am allowed to use GPL code in a bomb's flight control program and I am certainly not required to distribute the source code to the enemy together with the bomb, am I? Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Accessing ROM BIOS Font in Linux.
On Thursday 17 January 2008 11:47, Michael Van Canneyt wrote: On Thu, 17 Jan 2008, Vinzent Hoefler wrote: On Thursday 17 January 2008 01:27, [EMAIL PROTECTED] wrote: The question. Is this font accessible from linux; do I have to be root ? Yes. Yes. /dev/mem should be the raw memory device (where even the BIOS image can be read from), but this device which is only accessible to root. But you cannot use this font to write to the screen directly ? Probably not, no. ;) But well, I don't read I wrote text output routines using putpixel and the ROM fonts. as write to the screen directly. Rather more like if I did't know which font to use, I'd use the BIOS font. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Notice: Possible copyright infringements in FPC code base
On Wednesday 16 January 2008 17:49, Roberto Padovani wrote: Given that I don't have Delphi, suppose that company X ask me to make a software for them. I might give them the software, with full source code and a GPL licence note every here and there, and ask money for the _design_ of the software, instead of the software itself. Another misunderstanding of the GPL. Of course you are allowed to charge money for your software. But given it is GPL your customer may decide to redistribute the source, as you gave him explicit permission with the GPL to do so. It would simply put all your other code under GPL, too. But there's absolutely *nothing* in the GPL that prevents you from charging money for your work. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OOT: fpc 2.2.1 breaks laz 9.25
On Thursday 06 December 2007 13:00, Bee wrote: Easy way to check: svn up -r 9290 $(FPCDIR)/packages/paszlib/src/zstream.pp Next 'svn up' updates zstream.pp back to HEAD revision. Here's what I got... [EMAIL PROTECTED]:/svn/fpc-2.2.1$ svn update -r9290 packages/paszlib/src/zstream.pp Dpackages/paszlib/src/zstream.pp Updated to revision 9290. So it seems there the file does not exist in revision 9290 of the repository you are using. In Andrey's version it does, so my best guess is that both of you are using different SVN paths and the file was moved in yours. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Why this evaluates on if wrong ? (GMP)
On Tuesday 30 October 2007 17:31, Inga Petuhhov wrote: A copy-paste from Python Shell: a = 1 a 1 a = a + 0.4 a 1.3999 a = a - 0.4 a 0.99989 a == 1 False Or a bit more simple (and for some maybe even more surprising): 1.0 == 0.4 - 0.4 + 1.0 True 1.0 == 1.0 + 0.4 - 0.4 False Floating points are not reals. Even simple commutative laws don't hold. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Speed
On Wednesday 31 October 2007 12:35, Daniël Mantione wrote: Further, it is unknown how well the GCC backend optimizes Ada language constructs as it is primarily designed for the C language. Well enough. In other words, optimization is about the same - given fairly equivalent code. The main difference is that the Ada compiler gets its knowledge from the variable declarations, while the C compiler gets it from the code. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fast text processing
On Wednesday 31 October 2007 14:19, Bee wrote: Sure, but as Jonas pointed out it is better to use a good library than the write a bad library yourself. And someone would claim that the speed comes from the library (c?), not from pascal. :P It's a LANGUAGE shootout btw, not LIBRARY shootout. Maybe you had forgotten that. ;) Well, considering that perl's or Python's speed greatly rely on the underlying C-implementation of (at least) particular functionality, all those comparisons basically boil down to C vs. C, anyway. Or don't they? ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RTL events
On Friday 19 October 2007 15:10, [EMAIL PROTECTED] wrote: I'm studing RTL Events and TEvent class under Unix. RTL Event don't keep the state of event after an RTLEventWaitFor or RTLEventWaitForTimeout (after this the event is reseted). This reset after an RTLWaitFor is a rule for RTL Events? Yes. You've first waited for the event to happen, then it happened, so now you should wait for the next event. Basically, RTLEventWaitFor; RTLEventWaitFor; should require two distinct events to get through. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] notify and notigyall
On Friday 24 August 2007 07:55, Michael Van Canneyt wrote: On Fri, 24 Aug 2007, Vinzent Hoefler wrote: On Thursday 23 August 2007 19:47, Jonas Maebe wrote: On 23 Aug 2007, at 21:29, Luca Olivetti wrote: How are these different to the TEventObject,TSimpleEvent classes in syncobjs? Just curious, since I usually do with syncobjs, and I don't see a big difference between MyEvent.SetEvent/MyEvent.WaitFor and RTLEventSetEvent/RTLEventWaitFor If you look at the source of syncobjs, you'll notice teventobject is just an OO coat for tbasicrtlevent. Last time I looked this is only true for Win32, the Unix version seems to be very different and is implemented with semaphores. Is there a reason why those routines are not simply based POSIX condition variables? Yes: a single source base. All 'basic' threading routines are in the system unit, all the rest is based on that. Yes, I figured that this was the idea. I don't have access to the current SVN version (not before this evening when I am back home) to adequately show what I mean, but - from my bad memory - the question remains why 1) the Unix version makes so strange and wild efforts to support WaitFor with timeouts if there is pthread_cond_timed_wait() (and this is used elsewhere already) and 2) why the SyncObjs tEvent objects uses those semaphore stuff instead of the fixed RTLEvents. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] notify and notigyall
On Friday 24 August 2007 08:53, Jonas Maebe wrote: tbasicrtlevent for Unix is still not based on condition variables, because Windows events are persistent and condition variables are not. Call me stupid, but I was under the impression that this has been fixed by inserting the IsSet member in the IntRTLEvent structure (this fix also made RTLEventStartWait disappear for exactly that reason). Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] notify and notigyall
On Thursday 23 August 2007 17:02, ik wrote: Hi, Is there an equivalent for Java's sleep and notify/notifyAll in FPC's rtl ? The SetEvent methods of RtlWaitEvent (notify) and RTLSimpleEvent (notify all), IIRC. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] notify and notigyall
On Thursday 23 August 2007 19:47, Jonas Maebe wrote: On 23 Aug 2007, at 21:29, Luca Olivetti wrote: How are these different to the TEventObject,TSimpleEvent classes in syncobjs? Just curious, since I usually do with syncobjs, and I don't see a big difference between MyEvent.SetEvent/MyEvent.WaitFor and RTLEventSetEvent/RTLEventWaitFor If you look at the source of syncobjs, you'll notice teventobject is just an OO coat for tbasicrtlevent. Last time I looked this is only true for Win32, the Unix version seems to be very different and is implemented with semaphores. Is there a reason why those routines are not simply based POSIX condition variables? Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Incorrect hint message ? ( Hint: Local variable b does not seem to be initialized )
On Wednesday 22 August 2007 06:30, Skybuck Flying wrote: project1.lpr(21,5) Hint: Local variable b does not seem to be initialized [...] However when looking at the source code this hint message seems inaccurate. B is initialized by the procedure test. No, it's not. It says var, so according to the contract the procedure test is supposed to get an already initialized value (and may change it when executing). [...] procedure test( var b : byte ); begin b := 5; end; [...] If you want test to really initialize the variable and not care about its incoming value, you should use parameter mode out instead. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Competitive advantage in showing proof of correctness
On Wednesday 15 August 2007 00:40, mm wrote:
there would not be much places where I could set {$R+} without having
to reset {$R-} almost immediately.
[EMAIL PROTECTED]:/opt/mdc/dtg/src grep \$R *.pas
mdc0lzw.pas: {$IFOPT R+} {$DEFINE OPT_R} {$R-} {$ENDIF}
mdc0lzw.pas: {$IFDEF OPT_R} {$UNDEF OPT_R} {$R+} {$ENDIF}
Hmm. Here it is rather the other way around. ;)
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Competitive advantage in showing proof of correctness
On Tuesday 14 August 2007 06:14, Daniël Mantione wrote: Lastly, pre and post conditions are just another runtime check. No. If you can prove that the conditions always hold, you don't even need to compile to the program to prove its correctness. There's a company already doing that: http://www.praxis-his.com/sparkada/intro.asp Unfortunately the language is rather limited in terms of dynamic, hard-to-prove constructs like exceptions, pointers or gotos. For the ones who are interested, according to Lockheed: - Code quality improved by a factor of 10 over industry norms for DO 178B Level A software. - Productivity improved by a factor of 4 over previous comparable programs. - Development costs half of that typical for non safety-critical code. -- http://www.praxis-his.com/sparkada/pdfs/spark_c130j.pdf The most interesting sentence is probably the last. Doing it correct right from the start is actually cheaper. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Competitive advantage in showing proof of correctness
On Tuesday 14 August 2007 06:49, Daniël Mantione wrote: Op Tue, 14 Aug 2007, schreef Vinzent Hoefler: On Tuesday 14 August 2007 06:14, Daniël Mantione wrote: Lastly, pre and post conditions are just another runtime check. No. If you can prove that the conditions always hold, you don't even need to compile to the program to prove its correctness. This isn't feasible. Ok. I'll tell Rod what his company is doing for years now, just ain't possi^Wfeasible. ;) Of course, you won't have much success with a language like Object Pascal, but I'd suggest reading a bit about SPARK before. And yes, FPC as it is is unprovable (first through all the language constructs used and second the problem most projects will suffer from: it isn't written with proving it in mind). OTOH, AFAIK, the correctness of the SPARK Examiner is proven. And those are a little bit more than just a dozen lines of code. Of course, it goes nowhere near a couple of millions of lines of code, but FPC does neither, if you just talk about the compiler. And correctness of stuff like the RTL can be proven independently from the compiler itself. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Competitive advantage in showing proof of correctness
On Tuesday 14 August 2007 21:26, Daniël Mantione wrote: You almost never ship a binary with range checking, since a range check crash is for a end user generally as usefull as the protection fault that can happen when you disable range checking. Hmm. [EMAIL PROTECTED]:/opt/mdc/dtg/src grep options Makefile.fpc options=-CiorR -gl -vbehinw -OG3p3r Well, almost. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] splitting string into array
On Thursday 12 July 2007 07:30, Michael Van Canneyt wrote: Can you, BTW, explain the reference to Knuth ? I know who Donald Knuth is, but fail to see the link... ? http://www.brainyquote.com/quotes/quotes/d/donaldknut181625.html Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
On Wednesday 27 June 2007 07:55, Jonas Maebe wrote: On 27 jun 2007, at 08:13, Vinzent Hoefler wrote: There also seemed to be some issues with the reference counting: if I passed a local AnsiString to a thread constructor as argument and left the routine then, this seemed to confuse the thread throwing SIGSEGVs occasionally. Maybe the parameter was declared as const? I think so. I always do that. ;) In that case, the refcount of the ansistring you pass isn't increased, Meaning that the string will be freed once I leave the routine that called the constructor? That would explain it for sure. Regards, Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threads and runtime errors
On Friday 22 June 2007 06:27, Carsten Bager wrote: In the small threads program below I force a runtime error in a thread. How do I get access to the output from the thread when it stops? This program does not write anything to the terminal when the thread stops. In case a runtime error occurs, the thread object stores the exception which occured, so before destroying the threads try something like: |if Assigned (t1.FatalException) do | WriteLn (StdErr, t1.FatalException.ClassName, |t1.FatalException.Message); Alternatively you can embrace the Execute method with a try-except statement. Regards, Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TFPTimer component.
On Friday 22 June 2007 07:28, Michael Van Canneyt wrote:
- Don't use synchronize to fire the timer, because that limits
the use of timers to the main thread.
This one is harder, and I must confess I don't have a clue
on how to implement this in a platform independent manner...
Well, independently from Graeme I implemented something like that
already, closely resembling the Ada2005 Ada.Real_Time.Timing_Events
package. Implemented targets would be Win32 and Unix (tested for Linux,
but as I am only using POSIX-functionality it should run on any other
Unix, too).
Problems are:
1) All fired events are currently executed in a single thread, meaning,
the can quite easily block out each other. Could be easily changed,
although starting thousand of threads may turn out to be a bad idea. ;)
Currently I am thinking about getting away from a global scheduler and
setting up several ones, this would cut down the number of threads in
case of many timing events being active and could be used to implement
a sort of user defined priorization (fast executing/important vs. slow
executing/less important events).
2) Event execution is always independent (outside) of the main thread,
so a user must take care of all the multi-threading hassles.
3) With the current implementation you can't use Destroy on such a
Timing_Event, because those objects are used in another thread, so
instead of calling Destroy you'd have to used Finalize to mark such
an event as done. It will be freed later from the scheduling loop.
4) On Unix it uses a signal to wake up the thread on changes in the
timing event queue, so someone must ensure that this signal is blocked
in all other threads and may not be used otherwise.
6) It uses some more modules (especially some Calendar unit which uses
integers for duration types to avoid drifting issues you'd have if
you'd used the floating point TDateTime).
7) As I am currently rewriting the stuff for the priority queue I am
going to be using, I won't post any sourcecode yet, apart from the
interface:
-- 8 --
//-- @abstract(Provides a (crude) scheduling object to install handlers
//-- to be executed at some future point in time.)
//-- It closely resembles the @code(Ada2005 Ada.Real_Time.Timing_Events)
//-- package, so for the correct semantics of the operations (which are
//-- currently not 100% guaranteed in this implementation) you may also
//-- refer to the Ada2005 language reference manual.
unit
Timing_Events;
interface
uses
Calendar,
SyncObjs;
type
Timing_Event = class; // Forward declaration for criss-cross type
// dependency.
type
//-- @abstract(Type for the event handler @italic(callback).)
Timing_Event_Handler =
procedure (const Event : Timing_Event) of object;
type
//-- @abstract(The base type indicating a timing event.)
//-- It stores the next scheduled execution and the handler to be
//-- executed.
Timing_Event = class (tObject)
public
{/= Create =\}
{}
{\==/}
//-- @abstract(The usual constructor. Initializes all the needed
//-- internals.)
constructor Create;
{/= Destroy \}
{}
{\==/}
//-- @abstract(Cleans up object internals.)
//-- Due to its inherent asynchronous usage, DO NOT call @code(
//-- Free) or even @code(Destroy) directly. Leave the freeing up
//-- to the @link(Finalize) subroutine.)
destructor Destroy; override;
{/= Finalize ===\}
{}
{\==/}
//-- @abstract(Marks the object for finalization.)
//-- This is a replacement for @code(Free) which can not be used
//-- in this asynchronous context. Instead if you call @code(
//-- Finalize) the event will be marked for deletion and @code(
//-- Free) will then be called on the next run of the scheduler.
//-- Basically this just means that the freeing will be deferred
//-- an indefinite time. In case the event in currently scheduled
//-- to run in a moment, this subroutine will not return until the
//-- run is over.
//--
//-- @bold(Do NOT) call any methods of the instance after having
//-- called @code(Finalize)!
procedure Finalize; virtual;
{/= Set_Handler \}
{}
Re: [fpc-pascal] Metaware
On Wednesday 20 June 2007 06:55, Mark Wood wrote: [iterator functions with yield()] It strikes me that whilst it may not be the best programming form, the same thing could be done readily with a global variable? Not if you call such an iterator several times at once (in nested loops for example): |for i in LoopStep (1, 10, 1) ... | for j in LoopStep (2, 20, 3) ... Correct me, if I'm wrong, but AFAICS each function retains its own set of local variables and thus return sets. This would be very hard to accomplish with global variables. Regards, Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Metaware
On Tuesday 19 June 2007 11:48, memsom wrote: '?' indeed! I am fascinated! What does yield do exactly... presumably it returns a result from the function without closing down that instance of the function? Amazing concept. I suspect - given the word DOS in some of the code, it allows a DOS event loop to continue in a single threaded co-operative multitasking environment. Nope. It's that what Mark thinks, and more like (Python's) generator thingie (link posted by Luca): -- 8 -- Some high level languages support iterators in exactly this fashion. For example Metaware's Professional Pascal Compiler for the PC supports iterators[14]. Were you to create a code sequence as follows: iterator OneToFour:integer; begin yield 1; yield 2; yield 3; yield 4; end; and call it in the main program as follows: for i in OneToFour do writeln(i); -- 8 -- -- Found in: http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/ Volume/Chapter_12/CH12-6.html Regards, Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] writing device driver using FPC
On Thursday 05 April 2007 07:36, Michael Van Canneyt wrote: On Thu, 5 Apr 2007, Bisma Jayadi wrote: Writing device driver for windows using Delphi is almost impossible since Delphi can't produce .sys files. Is it the same case for FPC? Can FPC produce .sys file and write device drivers for any OSes (not just windows)? TIA. Well. FPC can be used to write an operating system, so writing a device driver is in theory possible. Mostly, this would mean writing an RTL which runs inside a kernel, which means writing routines to handle IO and routines to handle memory management from the kernel interfaces. And it would mean writing a C to Pascal conversion of an ever changing kernel interface. I think for Unix-type interfaces that would be enough. No. Especially with a Linux 2.6 kernel where you are supposed to link with some kernel object file and an ever changing binary interface mostly defined as C-macros. At least you need an additional C-wrapper or you're really lost. For Windows, there is the additional problem of producing a .sys file, which would mean some changes to the internal linker. In which way are they special? I don't have a working objdump here, so I can't say in which they are different from the normal executable files on Windows. I mean, they're still called .sys but other than in the old DOS-days they're also PE-executables or whatever they're called. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] writing device driver using FPC
On Thursday 05 April 2007 08:14, Felipe Monteiro de Carvalho wrote: On 4/5/07, Vinzent Hoefler [EMAIL PROTECTED] wrote: And it would mean writing a C to Pascal conversion of an ever changing kernel interface. All interfaces change when a new version is released, Well, I was not talking about justified architectural changes (like those from 2.4 to 2.6), but rather about those deliberate changes of the Linux driver ABI sometimes from kernel patch to kernel patch where important structures get reordered and such stuff. Without the actual C macros you are lost. And yes, it's done on purpose to discourage the use of binary only drivers. Additionally it discourages the use of other languages than C when writing device drivers. I did one in Ada a couple of years ago, but trying that these days would be close to suicide or at least get you to the madhouse. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Equivalent of Delphi map files...
On Friday 02 March 2007 08:19, Jonas Maebe wrote: On 02 Mar 2007, at 09:03, m utku wrote: Hello again :), I just forgot to ask; Delphi has an option to generate a so called map file that contains the function addresses matched with the function names when an executable compiled. What would be the equivalent FPC functionality for this? man ld - search for map - there is a --print-map option - tell FPC to pass this option to ld using FPC's -k option: -k--print-map Hmm. And then how to redirect the linker's standard output to a file named the same as a the source? Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal is alive!!??
On Monday 26 February 2007 10:13, Matt Emson wrote:
I had a fairly quick glance through; I think you missed the point.
Most of your arguments point to something like VB3, not Pascal, ADA
or C. You mention the syntax of the Java class - Pacal and ADA are
both more complicated.
Well, let's do the standard:
Pascal:
program
Hello_World;
begin
WriteLn ('Hello world.');
end.
Ada:
with Ada.Text_IO;
procedure Hello_World is
begin
Ada.Text_IO.Put_Line (Hello World.);
end Hello_World;
Java:
public class HelloWorld {
public static void main(string[] args) {
System.out.println (Hello World.);
}
}
Java in that respect is definitely harder to grasp. You learn a lot of
keywords in one lesson, though.
Pascal (okay, mainstream Borland dialect
Pascal) has the Program and Unit constructs and ADA its Package
body/specification (which IIRC you could skip, but still needed the
Program construct similar to the Pascal/Modula3 one.) The Java class
with a Main function is no more complex than a tradiditional Pascal
Program.
So, it isn't? A full bunch of keywords wrapped inside a class to make it
OOP and it's not even close to *any* OOP is *easy*?
Somewhere on the web floats around a HelloWorld.java example that is
supposed to do it the correct (Java) OOP way. Now then you scare
novices ;), but at least they'll get OOP from the very first beginning.
situations. The difference between program and unit. The sections in
the unit (interface, implementation) the way the uses clause works.
Well, at that point programming ends and software engineering starts to
emerge. The latter Java already lacks by mixing interface and
implementation into one holy mess.
Pointers - no, no, no. Java passes by reference. This is not anything
to do with pointers
That's why it's called NullPointerException instead of
NoneReferenceException, I'd suppose?
Well, it's a minor technicality, if you call it pointer or reference.
To express my very personal point of view on that matter: The only
difference is that a reference is guaranteed to be non-NIL by
definition. If it can become NIL/NULL/0, it's a pointer.
to know about at a beginners level. Passing by reference passes the
actual typed object reference, passing a pointer in C does not.
Yeah, right. And Ada does not have pointers either, because it's called
access type? Actually, some of it's inner workings make clear, that's
it's not just an address as in C - still it's a pointer with all the
implications you get with it.
different to Java? If you wish to pass integral types by reference,
box them. It's not exactly rocket science ;-)
It's damn hard rocket science, because even if you do that it's still
not clear, what sort of parameter mode it is supposed to have. :P
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal is alive!!??
On Monday 26 February 2007 12:07, Matt Emson wrote:
Well, let's do the standard:
Pascal:
program
Hello_World;
begin
WriteLn ('Hello world.');
end.
Class: What does program mean?
That this unit is supposed to be a program. (Still, you can leave it
out in most dialects.)
Does the name matter?
It should matter for you. Naming your program grzbmpfl does not help
memorizing what it was done for.
Does it have to be the same as the executable?
To be more precise, it should be the same as your sourcefile.
Why is there a colon at the end of the
line - isn't the begin end at the bottom part of it -
Because this tells the compiler that this is the end of the source.
Just like the colons in your textbook indicates end of sentence,
although a few spaces and commas would do, too.
What does begin and end mean?
Precisely what they say. 'begin' some code and 'end' it. It's called
block.
Where does writeln come from?
From the 'System' unit.
Why is the System unit hidden?
It's compiler automatism to aid you getting some useful stuff without
telling the compiler. Unlike C, Pascal compiler's are intelligent and
know you want to get something done.
Ada:
with Ada.Text_IO;
procedure Hello_World is
begin
Ada.Text_IO.Put_Line (Hello World.);
end Hello_World;
Wow.. I forgot how horrible ADA was ;-)
Class: is what?
The procedure *is* the following code block. In the next lessons you
see how you can put variables and types declaration local to such
subroutines.
Why do I need to repeat the name of the procedure?
You don't have to, but it is strongly advised to do so, because once
programs get larger it is fairly easy to lose track of where a
subroutine 'begin's and 'end's.
If I use with why do I need to put the whole line in again?
Because there's a strong difference between telling the compiler to
look for something and telling your fellow readers where you have it
from.
For the advanced: If you really want to pollute your whole namespace you
can put a 'use Ada.Text_IO;' right after the 'with' and you don't need
to repeat yourself.
Why can't I leave out with but can leave out uses?
Because 'with' is for the reader. 'Use' is for the writer. In Ada the
emphasis is on easily readable code. So only one writer has to work
more hard to simplify the job of 1000 readers used trying to figure out
what
'while (str() != -1) a = lngcmpw();'
meant to be and if it was correct.
Where does the put put it?
Look up the specification of the 'Ada.Text_IO' package. Now you know
where the routine comes from you can easily look at the spec what it
does.
Java:
public class HelloWorld {
public static void main(string[] args) {
System.out.println (Hello World.);
}
}
Thins that are simpler to explain:
1) void - the procedure and function paradimn often confuses
students. With Java/C./C++/C# the syntax is completely consistent.
In Ada the paradigm has gotten further. Functions are not allowed to
alter their arguments (only in parameters allowed), so the notion of
do_something and calculate_something is perfectly reasonable.
2) public - try explaining unit syntax to a beginner.
Hmm. Never had a problem with that. Maybe people who try writing code
before thinking about a spec do.
The difference between interface and implementation and the
argument for public and private are already on a par.
So what does protected mean? And why there's no package visibility
keyword?
3) static, easily glossed over as a feature you will find useful
later on. No more complex than explaining the entry point in a
pascal program or how on earth ADA works out what the entry point
is in the firtst place.
Entry point (last time I heard that I still used TASM3.2)? Who needs
an entry point? You compile something and either it is executable from
the context or it isn't. Why the hell should someone need a function
called main each time? On the contrary, what's against different
entry points depending on the context?
4) System.out how is this any more complex than the Ada example. In
fact, if you imported System.out it would actually be *simpler*
than the ADA example.
Well, I don't import. I DON'T pollute namespace. And I'd teach any
beginner not to try. Especially in Java, where you can import
wildcards.
5) The string[] array of arguments.. again, it's a fairly simple
you'll find this useful in the future, but it's simply and array of
the parameters passen on the command line.
What command line? Tell me where the command line in a web application
is? Tell me where on a bare metal system which doesn't even have an OS?
Do I need to tell you that Java was targeted to such systems?
The way Pascal handles
this is far, far more complicated to explain that the, quite frankly
up front, way Java does. ParamStr(), ParamCount and all that
business... is not intuitive at all.
Re: [fpc-pascal] Is it necessary to protect passed passwords in memory?
On Wednesday 01 November 2006 15:55, Marc PERTRON wrote:
dictionary attacks';
pwd := md5('My Secret Password' + salt);
end;
And where do you think the phrase 'My Secret Password' would be stored
other than memory?
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Low level disc access under windows with FPC
On Sunday 08 October 2006 12:08, Pianoman wrote: Hello, I'd like to ask if someone has experiences with low level disk operations in windows with FPC. The program should be able to copy entire diskete to one single image file and for example extract a single file from that image or view its contents. http://www.winmag.com/library/1995/0695/06howtoc.htm: -- 8 -- snip -- To open a disk for direct access, you use the Win32 CreateFile function with a special format to specify the name of the disk (a floppy or a partition on a hard disk): .\\a: to open the a: floppy and \\\. \\c: to open the c: partition on a hard disk. On hard disks, you can even get direct access at the physical device level, bypassing the partition structure. This is done with the special name .\\PhysicalDriveN, where N is the number of the hard disk, starting with 0. If you have only one physical hard disk, it's PhysicalDrive0, no matter how many partitions you have. -- 8 -- snip -- So creating a floppy image seems fairly easy (provided you have the rights to access the disk in that way at all), but extracting a file from a disk image may be harder because that would require knowledge of the file system in question unless Windows has some sort of mount feature for such image files. HTH, Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] variant part of a record
On Wednesday 20 September 2006 08:26, Пётр Косаревский wrote:
I use
{$A-}
abc= record
something: byte;
case byte of
1: (a,b: byte);
2: (c: word);
end;
{$A+} // or even a: byte; rsrvd1: array[1..3] of byte; b: word; ...
{$IF sizeof(abc)1234}
{$FATAL Неверный размер записи для заголовка (sizeof(abc)1234).} //
I think, there is no need to translate:) {$ENDIF}
because I read binaries generated by other programs. So it's mostly
portable: if it was supposed to be really portable, I'd add
endianness checking.
You should also realign the data to their native boundaries then. :)
Some processors just don't like data being accessed the wrong way, so
either you trust fpc to workaround for you (and this could be rather
slow) or you accept that your program may raise SIGBUS or similar
processor exceptions on certain architectures.
What am I thinking of is a construction like
xyz= object
raw: abc;
function GetA: byte;
function GetB: byte;
function GetC: word;
property something: byte READ raw.something;
I don't know if it is possible to define a property accessing only a
part of a structure, and I'm too lazy to check it, so maybe you have to
use a function like GetSomething instead. But apart from that I don't
understand your problem with the Pascal syntax of discrimants in a
variant record. It would work precisely as you expect, even if the
syntax is a little bit different than your expectation about it are.
But it's somewhat bulky (in the case of many types), so I hoped there
is a language feature for my convenience (I don't know pascal very
well and didn't understand corresponding documentation in the one
way).
Yes, there is a language feature called object orientation. But still
that means you would have to translate the binary structure into a
class instance somehow.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] variant part of a record
On Wednesday 20 September 2006 11:25, Jonas Maebe wrote: On 20 sep 2006, at 13:20, Пётр Косаревский wrote: I'm vague: for the first time I hoped that when you access the variant part, if the case variable was named, program checks it run-time. Hoping that it was implemented this way, I asked about control over the relative place in the memory of that named variable. Oh, well, there are no run-time checks, so that's all... It's on my todo list to implement such checks (when enabled by a command line switch, of course). It's not that easy as it may look at first sight though. Maybe you should take a look at the GNAT source code, Ada Compiler's do that sort of checks since 1983. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] memory layout of arrays
On Thursday 14 September 2006 09:20, Jerry wrote: however. Beware of 2D arrays in C because there seems to be no requirement in C that all of the data be allocated in contiguous memory; Most probably yes. This applies to all mutidimensional arrays in C. The reason is simple, arrays and pointers are handled quite the same way, so there's an automatic dereferencing for each array subscript... Described in Pascalish terms it would be a N-dimensional array of pointers to an (N-1)-dimensional array of pointers to an (N-2)-dimensional array ... Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Wednesday 26 July 2006 10:05, Andreas Berger wrote: Steve Williams wrote: Michael Van Canneyt wrote: Which is why I think that it's better to have them as local functions, instead of having to introduce a lot of new functions. Local functions are very pascal-ish. C doesn't have it, which is why they can't use it. Let's use the language features to their full extent. *procedure* SubTask(*var* x : *array of* Float); *var* /// Variables declared here have /|*private*|/ context./ iam : Integer; nt : Integer; ipoints : Integer; *parallel* iam := OMP.Get_Thread_Num; /// OMP library calls./ nt := OMP.Get_Num_Threads; ipoints := Length (x) *div* nt; /// size of partition/ istart := iam * ipoints; /// starting array index/ *if* iam = Pred (nt) *then* ipoints := Length (x) - istart; /// last thread may do more/ SubDomain (x, istart, ipoints); *end*; Wouldn't it be better to write it like this: procedure SubTask(var x: array of Float); *parallel*; var ... begin ... end; Actually no. I thought about it, but I didn't get through all that stuff yesterday evening or else I would have updated the WiKi already. The problem I see is that the parallel directive has more meanings (basically it is the main directive). For that reason, I wouldn't want to put in on the callee, but rather on the caller. I think it would also be easier for the compiler then to detect alls those parallel regions. Let's see. Anyway, there was already more response I would have expected after the days of silence. :) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unknown runtime error 202
On Thursday 27 July 2006 12:05, Wolfram Kläger wrote: Vinzent wrote: .. According to the documentation, the size of the local variables (allocated on the stack) should not exceed 32 KiBytes for portability reasons. Thanks a lot. And I thought, I did RTFM often enough ... BTW, do you know why exceptions donŽt return a line number? Because you forgot to include the -gl switch for automatically including the line info unit? If you do that, the backtrace usually consists of procedure names and line numbers instead of just addresses. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Thursday 27 July 2006 12:53, Alexandre Leclerc wrote: Then we could very simply have: parallel procedure ParallelBlock; parallel function ParallelFunction; //if this can happen... Yes. I thought of something like that, because it could quite easily match with a parallel for construct. That's why I don't like the idea of a function modifier. But pleeeaaase, people. This was only one single and little example and it's not nearly close to what the spec says. It just scratched the surface of it. So it's a bit early to hang on this only parallel keyword in that particular example. In the end, *all* constructs should nicely match together. What about those parallel section and parallel workshare constructs? The latter bothers me a lot (section might prove to be quite easy) plus all the /parameters/ those stuff can have: You don't want to write |parallel (Num_Threads := 3, ...) |function or something similar, do you? Or think of this reduction keyword... Also, I read that in example 1: Variables declared here should have shared context. Yes, if they're declared outside of the parallel block, they can be seen by every single one, so shared would IMO be a more natural visibility rule here. This could remove the need for another keyword. In fact by default they have private context and to me it looks like more normal. What do you mean by default? The OpenMP spec? Well, I wasn't trying to copy the idiocies mainly caused by the chosen base language(s). :- Thread private variables don't make sense outside of the parallel block, especially *after* it, so why should the default be private here? Maybe we should have a way to do the contrary: specify that a variable has shared context... What others think? The approach allowed both in a (I think, logical way, because of the implied scoping rules). The problems begin with the firstprivate and such directives. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Wednesday 26 July 2006 08:17, Micha Nelissen wrote: Vinzent Hoefler wrote: Well, I just added some stuff there, yesterday. It's far from being complete yet (it just covers a basic parallel construct), nor is it really thought through yet, but well, it might be a start; something to begin with. Any suggestions are welcome, of course. Does parallel mean all the statements in the block can be executed in parallel, or that multiple copies of the block of statements can be started in parallel ? The latter. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Wednesday 26 July 2006 09:07, Micha Nelissen wrote: Vinzent Hoefler wrote: On Wednesday 26 July 2006 08:17, Micha Nelissen wrote: Does parallel mean all the statements in the block can be executed in parallel, or that multiple copies of the block of statements can be started in parallel ? The latter. Strange. That somehow applies to the whole original specification. :) How many copies ? Omp.Get_Num_Threads(), AFAICS. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Wednesday 26 July 2006 09:00, Michael Van Canneyt wrote: On Wed, 26 Jul 2006, Vinzent Hoefler wrote: On Wednesday 26 July 2006 08:17, Micha Nelissen wrote: Vinzent Hoefler wrote: Well, I just added some stuff there, yesterday. It's far from being complete yet (it just covers a basic parallel construct), nor is it really thought through yet, but well, it might be a start; something to begin with. Any suggestions are welcome, of course. Does parallel mean all the statements in the block can be executed in parallel, or that multiple copies of the block of statements can be started in parallel ? The latter. Which is why I think that it's better to have them as local functions, instead of having to introduce a lot of new functions. Hey, it's only *one* new keyword yet. :) Admitted, local blocks are more Adaish, but with this approach, I was trying to avoid introducing a lot more keywords. There still probably will be some, because there are more constructs like barrier, workshare (which I didn't fully understand yet) and section. And well, such blocks are already known in Object Pascal. Just look at them as in object declarations the public/protected/private modifiers. Local functions are very pascal-ish. C doesn't have it, which is why they can't use it. Let's use the language features to their full extent. Yes. I agree with that. The problem is that there are more variable types than just shared and private (like firstprivate), so it might prove to be quite difficult to do that if you only have local functions. I just didn't come to that part yet. I'll probably update the WiKi this evening/night (can't do that from work, where freepascal.org still times out). Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Wednesday 26 July 2006 09:25, Micha Nelissen wrote: Vinzent Hoefler wrote: On Wednesday 26 July 2006 09:07, Micha Nelissen wrote: How many copies ? Omp.Get_Num_Threads(), AFAICS. Ah the number of threads is determined by the RTL, and any parallel block must be written flexible, so that it can work for any given number of threads ? Yes and no. I think, there are constructs to set a specific number of threads. And as I tried to say, the specification is quite large. If not to say even convoluted. I've seen easier to read stuff recently. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Wednesday 26 July 2006 09:28, Steve Williams wrote:
Steve Williams wrote:
*begin*
SubTask(x);
*end* /{Sub}/;
*var*
arr = *array*[0 .. ] *of* Float;
*begin* / // Main program/
Sub (arr);
*end*.
Damn Thunderbird.
Well, it tried to mimic my syntax highlighting. :) Apart from that, your
change is quite nice, yes. That's what Michael meant, I guess.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Wednesday 26 July 2006 09:46, Michael Van Canneyt wrote: It seems obvious to me that a global function can be called in parallel at any time. The compiler can perfectly detect whether a global function writes to variables outside it's own scope, in which case it's probably a no-no to paralellize the function. Hey, you're trying to put more burden on the compiler here as the spec even allows, I'd say. Don't go on or you'll end up with the requirement for compile time dead-lock detection. :) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Wednesday 26 July 2006 10:00, Michael Van Canneyt wrote: On Wed, 26 Jul 2006, Vinzent Hoefler wrote: On Wednesday 26 July 2006 09:46, Michael Van Canneyt wrote: It seems obvious to me that a global function can be called in parallel at any time. The compiler can perfectly detect whether a global function writes to variables outside it's own scope, in which case it's probably a no-no to paralellize the function. Hey, you're trying to put more burden on the compiler here as the spec even allows, I'd say. Don't go on or you'll end up with the requirement for compile time dead-lock detection. :) Well, my statement is moderate in the sense that the compiler does this anyway already (see the hints/warnings about unused params/vars); let's use this information as much as we can. True. Using information that's already there, can't be wrong. I second that. We're not C, where everything is standardized to be the programmer's problem. So yes, if concurrency will ever be implemented in the language, no matter how, some decent warnings/hints/notes about several questionable constructs would be nice. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler Warning and Notices like unused variables etc.
On Wednesday 26 July 2006 12:49, Graeme Geldenhuys wrote:
MyVariable:=MyVariable; // this is a workaround in rare cases.
Can anybody that knowns the internals of FPC confirm if this will
create extra work/code for the compiler?
It does create an assignment. At least with the fpc2.0.2 version I just
checked:
Compiled with -al for source lines and -O3:
|.Ll2:
|.stabn 68,0,10,.Ll2 - P$TEST_ASSIGN
|# [10] x := x;
|movl-4(%ebp),%eax
Without optimization it even generates:
|.stabn 68,0,10,.Ll2 - P$TEST_ASSIGN
|# [10] x := x;
|movl-4(%ebp),%eax
|movl%eax,-4(%ebp)
Depending on the view point and application it might be negligible. It's
probably not a good idea to do that inside a tight loop, but in most
other cases those couple of bytes won't hurt.
Although, well ... I wouldn't depend on that behaviour, because the
variable still *is* as uninitialized as before, because the right hand
side of the expression assigned to it is. So if someone cares to write
code for a more stricter data flow analysis, the warning may at some
time reappear.
So this is no clean way to do it I'd say.
What is needed is a way to tell the compiler: Trust me. I know what I'm
doing.[1] ;)
Vinzent.
[1] {$SLEDGE_HAMMER ON}?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
Vinzent Höfler wrote:
because we assume it's non-recursive, that was the whole point. So
we should *first* check the count and then may lock/unlock the
mutex accordingly.
Note that these two actions must be atomic.
Oh, really?
This is what the TryLock is for.
No, that's what the Owner_Check_Lock in my posted code would be for in
the first place. But you're right, TryLock makes it possibly easier to
detect/handle failures.
So the code from
// Now try locking the real mutex.
should actually be more like:
|// First encounter? So lock it actually.
|if self.Count = 0 then
|begin
| // This should *always* succeed, because we're the owning
| // thread (we've just checked it, right?) and we didn't lock it
| // yet according to Count.
| // Thinkable ways how this can fail is if somebody has direct
| // access to the actual pthread mutex inside here or we
| // fuc^Wmessed up the counter somehow ...
| if pthread_mutex_trylock (self...) 0 then
| // Our real mutex couldn't be locked!? This *is* strange.
| exit (FAILURE);
|end {if};
|
|// Alright, we got it. Mutex is locked (or at least, it *should* be
|// already), so count up.
|self.Count := self.Count + 1;
|self.Owner_Check.Unlock;
|exit (SUCCESS);
A pthread_mutex_trylock alone wouldn't actually help on a non-recursive
real mutex. Because: if it's already locked I still don't know if it
belongs to the current thread, but precisely that knowledge is needed
to implement the recursive one on top of a non-recursive.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
On Tuesday 25 July 2006 07:46, Micha Nelissen wrote: Vinzent Hoefler wrote: On Tuesday 25 July 2006 06:40, Micha Nelissen wrote: Vinzent Höfler wrote: because we assume it's non-recursive, that was the whole point. So we should *first* check the count and then may lock/unlock the mutex accordingly. Note that these two actions must be atomic. Oh, really? Ehm, no. Ehm, yes. I was being ironic here. Of course, the action of checking the counter and locking/unlocking the associated mutex must be atomic. Got confused a bit :-). Reread the thread, and think your latest implementation as posted here is ok. No, it's not. As usually I should sit down with pencil, paper, a cup of coffee and a cigarette before writing code. Anything else is hacking and takes more time and changes. (Why the hell don't I listen to myself?) Despite the fact that some minor details may be still missing, like setting the owner's ThreadId, for example, this implementation has one very major flaw. It doesn't suspend the calling thread if it's not already owned by it and if it is, it doesn't do that either, becaus it shouldn't. That makes it kind of useless, I think. :) Instead of exiting with (NOT_OWNED) the mutex should be locked, of course. But before doing that, the Owner_Check_Lock must be released. And now I start smelling a race condition. Back to the drawing board, I guess. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
On Tuesday 25 July 2006 09:04, Burkhard Carstens wrote:
Am Dienstag, 25. Juli 2006 10:46 schrieb Micha Nelissen:
function Recursive_Mutex.Lock:...;
begin
// Owned by current thread?
if CurrentThreadId self.ThreadId then
begin
result := pthread_mutex_lock (self...);
if result 0 then exit;
self.ThreadId := CurrentThreadId;
self.Count := 1;
end else begin
Inc(self.Count);
end;
result := SUCCESS;
end {Mutex.Lock};
function Recursive_Mutex.Unlock: ...;
begin
if CurrentThreadId self.ThreadId then
exit(ENOTOWN);
assert(self.Count 0);
dec(self.Count);
if self.Count = 0 then
begin
self.ThreadId := 0; // a threadid that does not occur in system
pthread_mutex_unlock(self...);
end;
result := SUCCESS;
end;
I don't see the need for Owner_Check_Lock anymore ? :-)
You have to prevent that 2 concurrent threads call lock
simultanously,
No. That's not a problem. See the explanation below.
Perhaps the line if result 0 then exit; may be kind of superfluous,
or even dangerous, because it would return from the lock operation
without actually locking it, but well - if it goes wrong here, we're
screwed anyway. At least the caller could check, if it did.
so you have to take an internal lock before touching
internal vars like self.ThreadID ?
First I thought that, too. But after looking at and thinking about it a
while, the race you mention could only occur if the *same* thread would
call Lock() simultaneously, and that can't happen.
In the case two different threads enter here, they may both still see
0 and are trying to continue then, but only one of them will acquire
the mutex sucessfully, leaving the other suspended. Once the suspended
thread continues, it actually owns the mutex, so everything's ok then.
Ok, there's a glitch: The read and write of self.ThreadId is required to
be atomic, so that a thread entering may either see 0 or the owner's
thread id when checking, otherwise it could be possible, it sees its
own thread_id due to a partial update and *then* it goes really wrong.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
On Tuesday 25 July 2006 08:46, Micha Nelissen wrote: Vinzent Hoefler wrote: Ehm, no. Ehm, yes. I was being ironic here. Of course, the action of checking the counter and locking/unlocking the associated mutex must be atomic. But here they are not associated, they're protected by owner_lock, as you said. Yes. That's what would have made the whole operation atomic. I mean the idea for the recursive locking is ok. Well, in the end it's functionality that counts. Ideas I got. Lots. I was confused by the whole 'owning' part. Locks don't own threads in my mind, so I assumed you got that right. Yes, that's right, locks don't own threads. But threads own locks. :) Alas, no :-). Also problematic is posting only partly updates to a function. Then we forget the other, also critical part. Yepp. It wasn't yet meant to be committed to svn, you know? ;) function Recursive_Mutex.Lock:...; [...] function Recursive_Mutex.Unlock: ...; [...] I don't see the need for Owner_Check_Lock anymore ? :-) Yes, that looks about right. ;-) Except perhaps for the possible glitch I mentioned in my other mail. Don't know, if we can ignore it for now or simply assume that (up to) 32-Bit-variables always *are* atomic types. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Initializing threading
On Tuesday 25 July 2006 14:18, Andreas Berger wrote: In order to initialize threading under DOS I must create a separate unit since I need the initialization and finalization clause. I thought of using a cthreads.pp unit like in unix. However, the TThread implementation resides in the TThread.inc file which is an include in the implementation section of the system.pp unit which is always loaded. AFAIR the TThread implementation makes use of the ThreadManager (it calls BeginThread and all that stuff). This causes the following problem: If someone creates a TThread, the constructor does not know if threading has been initialized (via cthreads) since I can not add a uses cthreads clause in the .inc file. Does anyone have any idea how I can resolve this? Initialize is it in the BeginThread subroutine of your ThreadManager as it is done for all other targets that need special initialization. There is a global variable System.IsMultThread for exactly that purpose, I think. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
On Tuesday 25 July 2006 14:51, Micha Nelissen wrote: Vinzent Hoefler wrote: Ok, there's a glitch: The read and write of self.ThreadId is required to be atomic, so that a thread entering may either see 0 or the owner's thread id when checking, otherwise it could be possible, it sees its own thread_id due to a partial update and *then* it goes really wrong. It's not a glitch but an assumption I'd say. Well, it will become a glitch, if the assumption about the atomic read/ write turns out to be wrong. ;-) The compiler devels should be able to answer whether we can assume this, or not ? Well, I suppose so. But in the end it depends on the target architecture, not the compiler in general. That's BTW, one of the reasons I'd like to have a Pascal's equivalent of Ada's Pragma Atomic(...) and Pragma Volatile(...) for certain types and variables. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Semaphore problems
On Monday 24 July 2006 10:21, Graeme Geldenhuys wrote:
procedure TtiPool.CreatePoolSemaphore;
begin
{$IFDEF MSWINDOWS}
if FSemaphore 0 then
CloseHandle( FSemaphore ) ;
FSemaphore := CreateSemaphore( nil, FiMaxPoolSize, FiMaxPoolSize,
nil ); {$ENDIF MSWINDOWS}
{$IFDEF LINUX}
sem_destroy( FSemaphore );
if sem_init(FSemaphore, 0, 1) 0 then
raise Exception.Create('Failed to create the semaphore');
{$ENDIF LINUX}
end;
What is FiMaxPoolSize? I assume, it's something like a number of request
being allowed inside the semaphore-protected region at once?
So in the linux version only one thread is allowed being there.
I suppose you wrote something like
|for i := 0 to 9 do
|begin
| Lock;
| WriteLn ('Ping');
|end {for};
|
|for i := 0 to 9 do
|begin
| WriteLn ('Pong');
| Unlock;
|end {for};
In that case you're experiencing the lock-up when the semaphore is being
entered/locked the second time inside your loop. The counter is zero
after the first sem_wait and remains that way, because there's nobody
there to call the sem_post() operation. Well, it may seen as a kind of
a classical deadlock situation, although there's nothing classical in
here. ;)
That's what you're experiencing. Although it might appear similar, a
semaphore is *not* a mutex.
What I don't understand is why you don't use the SyncObjs unit where
almost all the stuff someone ever needs is nicely laid out in a
portable and object-oriented way.
if sem_wait(FSemaphore) 0 then
raise
EtiOPFInternalException.Create(cErrorTimedOutWaitingForSemaphore);
BTW, sem_wait() never returns anything else than zero, so checking is
sort of useless here. There's sem_trywait() for that, if you really
need to go so low-level.
To the question, what are semaphores. It's quite easily explained:
Atomic counters, you can only get past if they're non-zero and in that
case the counter is decremented.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
On Monday 24 July 2006 13:34, Marco van de Voort wrote: When I run the Unit Tests and create a single Lock and the Unlock it, all works fine. If I then iterrate that test by creating 10 locks and then call unlock 10 times, the Unit Tests freeze on the following line with the second iteration: Sounds like some recursion property is not set. I don't think, semaphores have recursion properties. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
On Monday 24 July 2006 14:09, Michael Van Canneyt wrote: On Mon, 24 Jul 2006, Vinzent Hoefler wrote: On Monday 24 July 2006 13:34, Marco van de Voort wrote: When I run the Unit Tests and create a single Lock and the Unlock it, all works fine. If I then iterrate that test by creating 10 locks and then call unlock 10 times, the Unit Tests freeze on the following line with the second iteration: Sounds like some recursion property is not set. I don't think, semaphores have recursion properties. They do, in some implementations. Ok, granted. :) But not in POSIX, AFAICS. And they were never designed that way. I think, that's why someone invented the mutex. ;) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Semaphore problems
On Monday 24 July 2006 14:57, Burkhard Carstens wrote: I vote for more pascal based versions of TMutex, TSemaphore and TEvent, that behaves just like the ones in Delphi and use the system specific functions (like pthread stuff) only internally in their simplest/most portable form. I'd vote for a more abstract version. :) The more or less basic things needed in multi-threaded programing are - semaphore - persistent signal - transient signal (pulse) - event There's some more higher level stuff (like broadcasts, for example), but that's about all you usually need. Currently we have the semaphore (more or less as SyncObjs.tCriticalSection), the persistent and the transient signal (SyncObjs.tEvent), although without timeouts (at least when trying to be portable), the event is somewhat implemented, but IIRC it misses a Toggle property, which can be used for simple intertask communication (Now I'm blocking, you're on.). Currently, I have the problem to get a working TEvent: - The one in syncobjs returns wrError, when it's waitfor is called with anything else tah infinite timeout Yes, that's not implemented, although it should be easily added by using condition variables of pthreads. - the rtlEvent works even with timeout (with my patch posted on mantis), but this one clears the signaled state, when wait is called. *oh* Before the wait? That's not good. This cries for race conditions and subtle deadlock situations. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Trying to make a small makefile with fpcmake
On Thursday 13 July 2006 14:49, Alexandre Leclerc wrote: Now when I execute, I get a problem: make clean makefile:1341: *** missing separator. Stop. This is GNUmake. You need TAB chars instead of spaces in your rule-commands: clean: clean $(MAKE) -C bin clean ^ about here Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Trying to make a small makefile with fpcmake
On Thursday 13 July 2006 14:58, Alexandre Leclerc wrote: You won a piece of robot! Oh man. And I was just two minutes late. ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threading in FPC DOS
On Wednesday 12 July 2006 09:15, Tomas Hajny wrote: Well, multitasking multithreading. I'm not sure if DV or Win 3.x provide special multithreading support for DOS applications... Nope, not really (at least for Win3.x). There are some services to aid multi-tasking-aware applications at the multiplexer interrupt Marco mentioned, but multi-threading is simply not supported by the underlying DOS-Kernel because of its non-reentrancy. In contrary to Marco's suggestion, I can imagine the multithreading support could be general and included by default for GO32v2 (similarly to Win32). However, it certainly depends on whether a general solution (not requiring special support like DV, etc.) is really feasible and practical. Well, once you manage to encapsulate each and every system call you've done the most work. ;) Basically I only see the solution that the thread manager intercepts int21h and probably some more others (int10h comes to mind), and blocks any multiple system calls from occuring at the same time. But it's too hot to think right now. All in all, I'd say, it's not *that* hard to do it, especially if you have a multi-threading aware RTL already, but it's certainly not done in a couple of hours. The thing is, I'd really love to do that, but as anyone here might have noticed, I already did a pi*s-poor job just maintaining the GO32V2 target... Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threading in FPC DOS
On Wednesday 12 July 2006 09:58, Marco van de Voort wrote: On 12 jul 2006, at 11:25, Marco van de Voort wrote: sleep(0) is quite bad, because it may not necessarily give up any timeslice. At least very short nanosleeps seem to be implemented as spinning loops on Mac OS X, so maybe sleep(0) is the same. Do you know a correct way of doing this on *nix? sched_yield()? Seems to be POSIX, so I suppose it's available on most Unices. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threading in FPC DOS
On Wednesday 12 July 2006 10:57, Tomas Hajny wrote:
I certainly don't know a general solution for *nix. However, even old
single-task DOS provides such a function and it's a great help that
can be provided by programmer to scheduler in the underlying OS, so
*nix systems should provide such function too, right? If they don't,
you probably don't have anything better than sleep(0) anyway.
Bad thing with Sleep(0) on those systems is that it does about the same
as coding {null};, with the disadvantage of needing infinitely more
code and being infinitely slower. ;-)
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threading in FPC DOS
On Wednesday 12 July 2006 11:10, Marco van de Voort wrote:
spinning loops on Mac OS X, so maybe sleep(0) is the same.
Do you know a correct way of doing this on *nix?
sched_yield()? Seems to be POSIX, so I suppose it's available on
most Unices.
Yes, and not so recent ('93) that it is risky. At least FreeBSD seems
to have it.
Footer of the man-page here says:
|Linux 1.3.811996-04-10 SCHED_YIELD(2)
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threading in FPC DOS
On Wednesday 12 July 2006 11:34, Andreas Berger wrote: save and restore the floating point unit. I will need to do this for FPC, so if someone knows how to save and restore the FPU, I would apreciate the help. F(X)SAVE/F(X)RSTOR The X-Versions are more efficient, but only available on newer CPUs. Ideally I could also discover (via an exception on first FPU usage?) if a thread needs to save/restore the FPU. Well, I'd say, this is quite hard to do in an efficient way, because you need to detect the usage of MMX instructions, too. As you may recall, Intel decided to implement another brain damaged design and mapped the MMX registers onto the FPU registers. I have to dig deep in my memory now, so take the following paragraphs with caution, I may be wrong (it's just too long ago): In theory it is possible to do, but only if you have write access to the EFLAGS register (where you could temporarily set a flag to raise an exception on MMX usage). But the usual DOS-target means DPMI, which means privilege level 3 which means: You're just not allowed to fiddle around with those. IIRC, there's a ring0-mode DPMI-Host available (should be CWSDPR0.EXE), but this only works in real plain DOS, so the option to run the program inside a Windows-DOS-Box would be out completely, I guess. Depending on your needs this might be ok, but as a general solution for FPC/GO32V2 this wouldn't be acceptable, I think. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] spin_lock
On Wednesday 31 May 2006 01:04, Felipe Monteiro de Carvalho wrote: 0.1 miliseconds is a lot of time for a modern computer. Depends. Here[tm] it's still just about 100 I/O-cycles. My experience is that even running on a graphical environment with other processes running, you can get 0.1 milisecond precision without trouble. You can, yes. But only most of the time, not always. The latter is called real time and no plain vanilla OS can give you that. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ioctl
On Tuesday 16 May 2006 16:18, Alain Michaud wrote: Do I need open a file deccriptor in order to communicate using IOCTL? Yes, you have to open the device before talking to it. Or what the hell do you think, the Handle parameter of |Function FpIOCtl (Handle:cint;Ndx: culong;Data: Pointer):cint; is for? As always: RTFM, reading the man page (man 2 ioctl) actually might help too: |DESCRIPTION | [...] The argument d must be an open file descriptor. | |RETURN VALUE | Usually, on success zero is returned. A few ioctls use | the return value as an output parameter and return a non | negative value on success. On error, -1 is returned, and | errno is set appropriately. BTW, I agree - writing device drivers sucks. I know. :-) But checking out http://www.freesoftwaremagazine.com/articles/drivers_linux may be worth a try. Regards, Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Typecasting by accident
Just found a bug of mine I was wondering about since about three days,
and wanted to share the fun with you:
-- 8 --
// How to raise the wrong exception or
// Why automatic type conversion really sucks
{$MODE OBJFPC}
program
Exception_Fun;
uses
SysUtils;
function Exception_Message : AnsiString;
begin
exit ('Will never show up, of course.');
end {Exception_Message};
type
Not_Now = class (SysUtils.Exception);
begin
try
raise Not_Now (Exception_Message);
except
on e : Not_Now do
WriteLn (StdErr, 'Caught it! Strange.');
end {try};
end {Exception_Fun}.
-- 8 --
No error, no warning, no note, no hint: Of course, a class type is just
a pointer, AnsiStrings can be pointers. Pointers can be converted to
any other pointer type... *crash*
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Division by Zero - not raised exception
On Wednesday 19 April 2006 16:32, L505 wrote: I didn't say pure pascal programmers with no other skills. Of course you didn't say *that*. But it still sounds like you are very focused on language skills. Language skills are much less important than people usually think. most pascal programmers know databases, Assembly, and C. They also usually know at least one scripting language such as PHP. It is *not* about knowing a language (or two, or more). Knowing about stones won't give you the ability to build a house. Unfortunately most people in the software business seem to think it does. It doesn't. It's that simple. Software development is not about *where* to put this or that statement, it is much more about the *why*: In the end it's math, logic and abstraction (among some others). A particular language is just one way to express those. Of course, having some knowledge helps to get a project started, but this is too short-term thinking. I even learned by observation that having knowledge (especially about C-like languages) actually seems to hurt. And hell, I practically learned Java in a couple of days. Anything else from that point on consists in looking up the documentation on which class I may need. Well, I don't consider being able to successfully scan a telephon book for a particalur name a special skill. I just expect people to be bright enough to do *that*. Are my expectations set way too high here? I plan to hire/pay Pascal programmers at some point for future commercial projects. Who will I hire? Probably the folks that have worked with me on open source projects before. Yes, that might be a good start. But you miss the main point: that these people showed motivation and you may even be able to judge their general software-engineering abilities (how they designed their projects, modularized it, how they managed it, etc.pp). Any specific language skills are just /not/ important, believe. Of course, the willingness to do it in a different language might be. Regards, Vinzent. -- Yet a warning is nothing more than the compiler, which knows far more about the language than most of us, saying hey, you're scaring me, man. -- Jack Ganssle, Embedded Muse 129 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Division by Zero - not raised exception
On Tuesday 18 April 2006 17:24, L505 wrote: sense to me.). Or maybe you mean a foundation, like a non-profit organization? Obviously FPC is not out for profit, but out to help the developer. So I can see a non-profit organization working - but this would mean that FPC team would spend more time on things like Accounting, Lawyers, etc. Look how free software foundation is spending time hiring lawyers and etc. for their foundation. Not to mention that a foundation only works with funding, which means money. Especially when we're talking about hiring lawyers. Trust me. :-) And I don't think that there is awful lot of that where we are from. it a better compiler. I'm sure lots of people rely on GCC and PHP at their jobs every day - and this helps make it better because it must be high quality at work, higher quality than just hobby. Well, well. A lot of people rely on Java on the job and it didn't get better yet, did it? ;- I use FPC for some of my work (websites, misc tools), but not experienced enough to be a development team member yet. And I do not have the time because of work. (Sorry, and yes, I'm still looking at the DOS stuff from time to time. But currently there's absolutely no chance here...) I'm guessing there are a few others that use FPC in their real jobs. Yes. But that's just circumstantial luck. The decision between Grab 120'000 lines of C++ and grab 70'000 lines of Turbo Pascal and make it work on a decent system was mine to take. If you can't find jobs out there that use Pascal then you have to be really brave and start your own business and start hiring people with Pascal skills. Yeah right. Sorry to bring that up again, but if I would do that I would never hire people that claim to have such specialized skills. What is needed are people who can actually engineer software and that particular skill has nothing to do with language skills (of course, if all else fails, I'd rather hire a Pascal guy than a There *are* other languages than C?-guy, because the Pascal guy might grasp the concepts much easier). How to balance a clash of free vs open vs closed vs commercial? I'd vote for open source. And you can sell it, basic argumentation goes like this: Even if we are out of business for some reason, you still have the source code.. Regards, Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] opendelphi.org
On Thursday 16 March 2006 04:17, Bisma Jayadi wrote: IMO, .Net is just a bussiness buzz from M$ to attract their customers and prevent them from switching to Un*x systems. Speaking technically, I saw nothing new in the .Net technology. It's just a combination of Java (on the system architecture) and Delphi technology (on the system language), with extra resource requirements as the consequences. :p Frankly, all that stuff is still early 80s technology at best. Back then they just hadn't the computing power to actually do it. Information technology hasn't changed too much since then. They just invented a lot of new TLAs[0]. The only question is who has the better sales people hired. Vinzent. [0] TLA: Three Letter Acronym. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] opendelphi.org
On Thursday 16 March 2006 08:24, Marco van de Voort wrote: While I'm not a .NET lover (I wrote the FPC section on .NET), but while we all know that .NET is at best M$'s copy of Java, Well, it may be a copy, but if you take a closer look at it, it's actually better than Java, at least on the technical side. that doesn't mean that .NET is not a danger: I never said that. :) But that also depends on what you define as danger. If you want to attract former Delphi-Developers who already embraced .NET, it is, yes. But OTOH, if your target audience gets a little bit broader and would include developers that just need to get the job done, it's not, I guess. - it is reasonably well implemented and integrated. Yes. Although most people don't seem to care about such things. (Remembering the rumours that the Java Hotspot Compiler has been written in about 3.5 million lines of nasty C++ code, I'd say, it could be even much worse and nobody would notice or even care.) - the framework is huge. This is more important than it seems. Less components to buy, more people using a standarised set of components. It has its attraction. Agreed. But from my experience, once you're basing the whole discussion on that, frameworks can never be large enough. First: Technically, at some point, frameworks can actually tend to be too large, latest when you spend more time looking for the right thing that that you'd need to implement it by yourself. Second: As a programmer, you usually only need a _very_ small subset of any large framework. With the current project here at work (ported some ten years old Turbo-Pascal based software), I already have quite a set of classes, but if I take a look on what I needed from the FCL, it was not much more than the TStringList, TStream and the TThread class. :-) It's amazing what you can do if you have the right simple building blocks. For me, software development at the end is nothing more than a good planned Lego(tm). All the parts just have to fit together... And now that I have some more inside data, I can even prove that I have been no less efficient than my fellow Java coders who have a much larger framework already at hand. Well, I believe to know why: For instance, it took them about the same time to figure out how to use the logging classes in Java the right way as if I needed to implement my own thread safe logger class in object pascal. - Managers still believe in managed languages, and might for some time to come Nope. In fact, managers don't care about languages or everybody would've used Ada since years already. Usually managers don't even know that there's more than one to choose from. Or if they do then they just know the usual myths like too old, too complex, ... BTST. If you'd ask a manager about programming languages, I would be surprised if they could name much more than the usual suspects like C, C++, Java. But the same guy will tell you, that their developer are very efficient and they all do CORBA, MDA, OOA, OOD, OOP, RUP, UML, XML, ... -technology. - training and sales Yeah right. You mean like giving away 50'000+ bucks for a proprietary version control system when you can get a more or less standard one for free, but then they can't afford a decent language. ;-) - About each and other shrinkwrap development tools vendor is dead or nearly dead. The few left are into .NET and M$ can easily keep them at arms length technically forever Depends on the viewpoint. I know some vendors that don't care about MS and .NET too much. But, well, they earning their money mostly with real-time embedded and safety-critical stuff like military, air-planes, nuclear power-plants. Hopefully it will be a long way until MS gets accepted as a tool vendor and such in that area. Of course, it's not getting you very big bucks, but it still seems to pay the rent. - Microsoft hardly has to do sales anyway. As OS and Office vendor it already has a foot in the door. Strategic developers and educational institutions are given licenses often near free - Legalized software piracy, yes. Also the massive MS training operations automatically generate MS developer tools sales. Still, a lot of people seem to like Java better. IMHO it is less .NET itself, but the alarming conversion rates of businesses to MS tools (and that is often not a technical choice). Converting to MS tools has never been a technical choice. :- (Oh, and the fact that memory prices have sunk much lately also doesn't propel my enthusiasm for .NET) Well. I have 20 times more RAM now, than my first harddrive had and Windows2000 still isn't starting up faster than my Windows 3.1 was. That's called progress, I think. Time will tell. But after having a 25 years old technology that some guy hacked up in a garage still being the most used desktop system, I don't have much hope. But I'm really getting away from the
Re: [fpc-pascal] opendelphi.org
On Thursday 16 March 2006 16:35, memsom wrote: Pascal on Linux etc is niche. Yeah, that has always been my problem. Programming for environments and in languages that are usually both considered niche. Nonetheless I do it. And I even get fucking paid for it. And most important: It really works. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
