Re: [fpc-devel] Re: [fpc-l] type discussion
P.S.: BTW: Never heard of anybody doing serious programming in GNU Pascal (and I know many a programmer doing serious programming in FPC and even VP) As far as I can see (from their maillists), most serious GPC users are academics working with large numeric-related legacy ISO codebases. VP had some serious apps in the BBS time, but nothing serious in the half-decade, except maintenance of those apps. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc-svn177-units-Mysql broken
At 08:09 3-6-2005, you wrote:
there is an inconsistency:
TDateTimeRec = record
case TFieldType of
ftDate: (Date: Longint);
ftTime: (Time: Longint);
ftDateTime: (DateTime: TDateTimeAlias);
end;
TTimeStamp = record
Time: integer; { Number of milliseconds since midnight }
Date: integer; { One plus number of days since 1/1/0001 }
end ;
TTimeStamp,Date is integer, and TDateTimeRec.ftDate is longint.
on AMD 64 integerlongint?
integer is 32 bit.
Peter
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to manually control debug information
Peter Vreman wrote: At 19:36 2-6-2005, you wrote: Hello, I'm writting a custom preprocessor and I would like that the line number information maps to the original file. An example (not real, only an example): ...original.pas... 21 procedure AddFive(var a, b: Integer); 22 begin 23 a := ++b; 24 end; After preprocessor: ...processed.pas... 25 procedure AddFive(var a, b: Integer); 26 begin 27 Inc(b); 28 a := b; 29 end; I would like that stepping in the debugger through AddFive showed original.pas in lines 21 to 24, not processed.pas in lines 25 to 29. How could I do that? That is not possible with fpc Since preprocessed code isn't read by human, why don't change it into procedure AddFive(var a, b: Integer); begin Inc(b); a := b; end; The compiler don't care and you get correct line numbers. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] How to create a local copy of sources by SVN (WinXP) ?
I have install the TortoiseSVN and try to make local copy via checkout... But error 400 was occured. I _can_ view or save any file via Repo-Browser, why I can not save them all? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to manually control debug information
I'm writting a custom preprocessor and I would like that the line number information maps to the original file. An example (not real, only an example): ...original.pas... 21 procedure AddFive(var a, b: Integer); 22 begin 23 a := ++b; 24 end; After preprocessor: ...processed.pas... 25 procedure AddFive(var a, b: Integer); 26 begin 27 Inc(b); 28 a := b; 29 end; I would like that stepping in the debugger through AddFive showed original.pas in lines 21 to 24, not processed.pas in lines 25 to 29. How could I do that? If you have a preprocessor, you will also need a binary postprocessor to edit the linenumbers. IOW the preprocessor should keep track that original.pas:21 becomes processed.pas:25, and your binary postprocessor should parse all stabs and patch these occurances. Maybe you need a few dummy units with the same names as the included ones to create entries for these units. However a binary postprocessor is a bit complicated. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to manually control debug information
El Viernes, 3 de Junio de 2005 09:56, Marco van de Voort escribió: If you have a preprocessor, you will also need a binary postprocessor to edit the linenumbers. In the executable? Isn't there any previous step to hook into? Anyway, where could I find information about the structures that should be edited? -- saludos, Nico Aragón ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc-svn177-units-Mysql broken
Jan Ruzicka wrote: Hi the latest version (177) of fpc in svn does not compile on Mac OS X 10.3.9. The make all ends with following: /Users/j/fpc/fpc-svn/compiler/ppcppc -Xs -O1 -n -S2 -Fu/Users/j/fpc/fpc-svn/rtl/units/powerpc-darwin -Fu/Users/j/fpc/fpc-svn/packages/base/ibase/units/powerpc-darwin -Fu/Users/j/fpc/fpc-svn/packages/base/postgres/units/powerpc-darwin -Fu/Users/j/fpc/fpc-svn/packages/base/mysql/units/powerpc-darwin -Fu/Users/j/fpc/fpc-svn/packages/base/sqlite/units/powerpc-darwin -FE. -FU/Users/j/fpc/fpc-svn/fcl/units/powerpc-darwin -dpowerpc -dRELEASE db.pp dataset.inc(468,54) Error: Incompatible type for arg no. 1: Got TDateTimeAlias, expected Int64 db.pp(2025) Fatal: There were 1 errors compiling module, stopping db.pp(2025) Error: Compilation aborted make[3]: *** [db.ppu] Error 1 make[2]: *** [db_all] Error 2 make[1]: *** [fcl_all] Error 2 make: *** [build-stamp.powerpc-darwin] Error 2 I don't understand the code exactly. (It seems to assume that the DateTime field contains miliseconds since a certains startdate?) It is about this line: TimeStamp := MSecsToTimeStamp(Source.DateTime); DataTime is a double. MSecsToTimeStamp expects a comp. Maybe a double can be converted to a comp on i386, but not on powerpc. Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to manually control debug information
El Viernes, 3 de Junio de 2005 09:56, Marco van de Voort escribi?: If you have a preprocessor, you will also need a binary postprocessor to edit the linenumbers. In the executable? Isn't there any previous step to hook into? Yes. The generated assembler. Anyway, where could I find information about the structures that should be edited? gcc docs mainly (stabs) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to manually control debug information
Nico Aragón wrote: El Viernes, 3 de Junio de 2005 09:12, Florian Klaempfl escribió: Since preprocessed code isn't read by human, why don't change it into procedure AddFive(var a, b: Integer); begin Inc(b); a := b; end; The compiler don't care and you get correct line numbers. Clever! But won't the compiler care if a line gets too long? No. The compiler itself doesn't care about line length. I should still change the file name. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to manually control debug information
El Viernes, 3 de Junio de 2005 11:44, Marco van de Voort escribió: El Viernes, 3 de Junio de 2005 09:56, Marco van de Voort escribi?: If you have a preprocessor, you will also need a binary postprocessor to edit the linenumbers. In the executable? Isn't there any previous step to hook into? Yes. The generated assembler. Anyway, where could I find information about the structures that should be edited? gcc docs mainly (stabs) Thank you, also Florian and Peter, of course. It seems that I have more than enough options :-) -- saludos, Nico Aragón ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
Angelo Bertolli wrote: What makes python interesting are the many classes it offers by default to perform standard tasks, especially in the text treatment department; regular expression stuff etc. The same goes for most languages; Mostly it's not the language syntax that determines the productivity factor; it's the number of standard available routines. Exactly! Thanks for brining this up. If you just want more people to use Pascal, just 1) Make it simple 2) Have lots of nice tools 3) And most of all, have lots of units to do different thing It's the libraries, functions, objects, etc. that really attract people. Why do you think Java got so popular? It certainly wasn't because it was lightning fast or easy to write. It was because the standard libraries that come with Java (despite Sun's insistance to try to talk about the two synonomously) were so extensive. Ever since C and its concept of including libraries, it's been obvious that this is the main attraction for people. Okay, agreed. But what is there that can be done? I mean, yes -- there are many things that can be done by Pascal guru's, but is there anything to be done by a typical Pascal programmer? (without the knowledge of similar C libraries) I'm a FreePascal programmer that would really like to contribute to the project (for all it has given me) -- but with the lack of compiler/linux related skills I don't see much I could do. -- At your service, Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl/doom/] It's much easier to make an army of dumb good people than to make one single smart good guy... -- DarkGod ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
Kornel Kisielewicz wrote: Angelo Bertolli wrote: What makes python interesting are the many classes it offers by default to perform standard tasks, especially in the text treatment department; regular expression stuff etc. The same goes for most languages; Mostly it's not the language syntax that determines the productivity factor; it's the number of standard available routines. Exactly! Thanks for brining this up. If you just want more people to use Pascal, just 1) Make it simple 2) Have lots of nice tools 3) And most of all, have lots of units to do different thing It's the libraries, functions, objects, etc. that really attract people. Why do you think Java got so popular? It certainly wasn't because it was lightning fast or easy to write. It was because the standard libraries that come with Java (despite Sun's insistance to try to talk about the two synonomously) were so extensive. Ever since C and its concept of including libraries, it's been obvious that this is the main attraction for people. Okay, agreed. But what is there that can be done? I mean, yes -- there are many things that can be done by Pascal guru's, but is there anything to be done by a typical Pascal programmer? (without the knowledge of similar C libraries) I'm a FreePascal programmer that would really like to contribute to the project (for all it has given me) -- but with the lack of compiler/linux related skills I don't see much I could do. - create good container classes (map, hash, trees etc.) - write a bcd classes - extend e.g. the convutils stuff - look at your own work which could be abstracted and being interesting for fpc - write docs for the already existing packages Just a few ideas :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Re: [fpc-l] type discussion
listmember wrote: -- Class Contracts I like the 'require/ensure' aproach. It makes the code more robust and more debuggable, IMHO I think the checks you can do there are to limited. I also wonder what will happen if a require isn't met. Personally I don't want exeption in my released app. No, these are assertions not as exceptions. OK, what to do if an invalid input is met ? Continue ? Skip ? Abort ? IMO you still need some code which takes proper action -- Generics I am not sure if Generics could be done in FPC. There were some discussions about it here and AFAIK some are trying to implement. Any links? http://www.freepascal.org/wiki/index.php/Generics -- Virtual Properties and Events The examples given there are not very different of what is possible now. Make SetWith virtual and you have almost the same. What however would be nice is if you could override the getter or setter. Something like property Width write MySetWidth I think you missed a few things here. type TMyClass = class ... property Width: integer read write; virtual; abstract; end; As you can see, getters and setters are not in the picture at all. Which means, you have all the freedom you want in the derived class. Which is allmost the same as a virtual abstract Getter and Setter (almost, read/write from a field isn't covered) Plus, I like the idea that I could have a base class with read-only property that can not be overriden to be read-write later. property Width: integer read; virtual; abstract; That makes some sense (but it would be incompatible with existing code) OK, while I like the idea, I can not think of how I would use it though :-) Can someone help me out here G :-) -- Enhanced Multicast Events This is not really new. You can implement it yourself like property OnChange: TNotifyList; and then OnChange.Add(Notifyproc) or OnChange.Remove(Notifyproc) OK. Nice to be able to do that. Do I have to write my TNotifyList every time I need it? Not if you have generics ;) Inline variable initializers, such as: [snip] var Integer1: Integer = 15; Boolean1: Boolean = False; String1: String = 'SOME TEXT'; Hmm.. sometimes usefull. You can put it as first lines in your constructor/codeblock, but keep it thogheter in say large classes can be handy. Yes, and it improved the readability, IMHO. Plus, there is no reason for you to alter that in constructor/codeblock too. Not too. It is still edited at one place. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Marc Weustink wrote:
Jamie McCracken wrote:
[snip]
would become under Rad Pascal:
uses
Classes, SysUtils;
TMyObject = class (Tobject)
private
count : integer;
public
constructor create; override;
inherited Create(AnOwner);
inc (count);
destructor destroy; override;
inherited Destroy;
Notice its at least 50% less code to write.
Hmm less to write... and maintain ?
Go for example to the lazarus project and try to write the controls.pp
unit this way. Do you still think it is a good idea ? When all code is
put in the class header itself, can you still tell what methods a class
has ?
not a problem for an IDE - it can extract the methods and in fact visual
studio does that for c#. And likewise with the code explorer in lazarus.
Besides, when we are at Lazarus (or Delphi), when you have typed
TMyObject = class (Tobject)
private
count : integer;
public
constructor create; override;
destructor destroy; override;
end;
and press ctrl+shift+c it will generate the whole body. Which is already
less typing :)
You have to type even less if you start with
classf
and then press ctrl+j
So what is the point to make the language less clear, while there tools
exist which do most of the annoying typing for you ?
It makes it more clear IMO not less. having all that interface code and
having to jump between it and the implementation does not aid
legibility. Having it all nicely tied up in my proposed Rad Pascal, C#
and python does.
Those lazarus tools are great but they require advance knowledge of
those tools that new users wont have (at least somebody using lazarus
for the first time is not going to know all the keyboard shortcuts). Not
having to rely on hacks around the coding inefficiency of a language
with keyboard shortcuts is always a plus in my book too.
At the end of the day, if you dont like my new dialect then dont use it
- stick to {$mode objfpc} in your code. I want to offer you a new
dialect that should hopefully make your life easier but if it does not
then fair enough.
jamie.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
Florian Klaempfl wrote: Kornel Kisielewicz wrote: Okay, agreed. But what is there that can be done? I mean, yes -- there are many things that can be done by Pascal guru's, but is there anything to be done by a typical Pascal programmer? (without the knowledge of similar C libraries) I'm a FreePascal programmer that would really like to contribute to the project (for all it has given me) -- but with the lack of compiler/linux related skills I don't see much I could do. - create good container classes (map, hash, trees etc.) That could be done... but it needs some common FPC standard -- via interfaces? Like ITreeElement, I HashElement? Anyway, I'm not good at one cycle less stuff, so such units would still need a lot of optimizing by someone else... I think I'd pass up on this one. - write a bcd classes BCD? - extend e.g. the convutils stuff Havn't seen that one yet. - look at your own work which could be abstracted and being interesting for fpc Oh my... I've got a huge library of my own things, usualy needing a lot of optimization, but mostly roguelike-games related :-/. I also have a few libraries written using Jedi-SDL. - write docs for the already existing packages This could work. But I guess the set standard for that documentation would be fpcdoc? Still need to figure out how to use that one... :-/ -- At your service, Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl/doom/] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Friday 03 June 2005 10:47, Jamie McCracken wrote: It makes it more clear IMO not less. having all that interface code and having to jump between it and the implementation does not aid legibility. It encourages reading code instead of interface specifications. Often there is a big discrepancy between what the code is supposed to do and what it really does. If a fellow programmer relies on the latter this is known to break sooner or later. Of course, this implies that there *is* a specification. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote:
At the end of the day, if you dont like my new dialect then dont use it
- stick to {$mode objfpc} in your code. I want to offer you a new
dialect that should hopefully make your life easier but if it does not
then fair enough.
Thanks for the offer, where can I download the patch? I would like to
try this too.
Vincent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
On Thursday 02 June 2005 16:12, Marco van de Voort wrote: Begin..End is redundant - you have to indent them to make em readable anyways. No. This makes the code more readable like normal english text. It states much more clearly what it intents, at least much more than just indenting or putting curly braces around it. Not every syntax is about minimizing code or readability. The latter it should. Some are also to simply simplify parsing (and that is about compiler developer, but to make the language more internally consistent) and avoid long lookaheads. These things combined also improve quality of error messages a lot. Well, it is still named begin, end, not x0x0x0 0x0x0x, is it? ;-) And for the compiler: it wouldn't make a difference if you'd parse begin end or curly braces tokens, would it? Maintenance is easier as their is less redundancy. It simply depends on the kind of redundancy. For instance, type and var keywords are just redundant, the compiler could figure it out by itself, still they serve a useful purpose. See above. Yes, it might make the compiler writer's job easier. But typically you don't design a language around a compiler. And I strongly doubt that Wirth did. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Vincent Snijders wrote:
Jamie McCracken wrote:
At the end of the day, if you dont like my new dialect then dont use
it - stick to {$mode objfpc} in your code. I want to offer you a new
dialect that should hopefully make your life easier but if it does not
then fair enough.
Thanks for the offer, where can I download the patch? I would like to
try this too.
Patience! Its vapour ware at the moment.
Im just familiarising myself with the compiler source at the moment so
give me a few months to implement it. Once I have something I will post
a patch here.
Glad to see some of you are interested in it :)
jamie.
Vincent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Marc Weustink wrote: -- Class Contracts I like the 'require/ensure' aproach. It makes the code more robust and more debuggable, IMHO I think the checks you can do there are to limited. I also wonder what will happen if a require isn't met. Personally I don't want exeption in my released app. No, these are assertions not as exceptions. OK, what to do if an invalid input is met ? Continue ? Skip ? Abort ? IMO you still need some code which takes proper action You have a point here. That, I suppose could be handled through runtime options. But, a construct something like require [...] otherwise [...] end; ensure [...] otherwise [...] end; would be needed. -- Generics I am not sure if Generics could be done in FPC. There were some discussions about it here and AFAIK some are trying to implement. Any links? http://www.freepascal.org/wiki/index.php/Generics Thanks. -- Virtual Properties and Events The examples given there are not very different of what is possible now. Make SetWith virtual and you have almost the same. What however would be nice is if you could override the getter or setter. Something like property Width write MySetWidth I think you missed a few things here. type TMyClass = class ... property Width: integer read write; virtual; abstract; end; As you can see, getters and setters are not in the picture at all. Which means, you have all the freedom you want in the derived class. Which is allmost the same as a virtual abstract Getter and Setter (almost, read/write from a field isn't covered) Plus, I like the idea that I could have a base class with read-only property that can not be overriden to be read-write later. property Width: integer read; virtual; abstract; That makes some sense (but it would be incompatible with existing code) Why would it. Existing code does not have virtual properties. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
- Original Message - From: Hans-Peter Diettrich [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, June 02, 2005 3:27 PM ... More important: Unicode literals. But I know that this would require a very big change to the scanner, and to all code editors and other tools. Perhaps somebody has another idea how to solve this problem? How should they look like? (example please) Or do you think about writing the programs in Unicode text files? gs ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to manually control debug information
gcc docs mainly (stabs) Thank you, also Florian and Peter, of course. It seems that I have more than enough options :-) For an simple stabs parser see rtl/inc/lineinfo.pp ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to manually control debug information
Since preprocessed code isn't read by human, why don't change it into procedure AddFive(var a, b: Integer); begin Inc(b); a := b; end; The compiler don't care and you get correct line numbers. Clever! But won't the compiler care if a line gets too long? No. The compiler itself doesn't care about line length. Only you'll get wrong values for the column if the line is longer than 65535 chars. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
Florian Klaempfl wrote: - write docs for the already existing packages You mean that writing a fpcdoc for the opengl headers for example would be useful for somebody? Myself, I always was uncontent with the fact that there was no opengl section in the rtl docs... -- At your service, Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl] Well, the philosophy of the World of Shadows is based on most of the degenerate, immoral and foremost amoral philosophical beliefs of our world exagarated to the maximum. --Anubis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
Kornel Kisielewicz wrote: Florian Klaempfl wrote: - write docs for the already existing packages You mean that writing a fpcdoc for the opengl headers for example would be useful for somebody? Myself, I always was uncontent with the fact that there was no opengl section in the rtl docs... Well, OpenGL is only an API interface unit I'm more thinking about units containing real stuff written in FPC. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fixes for win32 dlls smartlink
Hello Florian and all FPC team, I finished patchs in pexports.pas and pmodules.pas fixing win32 dlls smartlink. These patchs are based on latest 1.9 sources which differs from current 2.0 and 2.1 only by bigger logs, therefore they should be applicable for both branchs. Applied to 2.1. Can be merged to 2.0.x if it works fine. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
On Fri, 3 Jun 2005, Kornel Kisielewicz wrote: Florian Klaempfl wrote: - write docs for the already existing packages You mean that writing a fpcdoc for the opengl headers for example would be useful for somebody? Myself, I always was uncontent with the fact that there was no opengl section in the rtl docs... We document only units that are written in FPC itself, not import units for system or third-party libraries. Otherwise I'd have to document the whole Win32 API, X, C library etc. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
Michael Van Canneyt wrote: On Fri, 3 Jun 2005, Kornel Kisielewicz wrote: Florian Klaempfl wrote: - write docs for the already existing packages You mean that writing a fpcdoc for the opengl headers for example would be useful for somebody? Myself, I always was uncontent with the fact that there was no opengl section in the rtl docs... We document only units that are written in FPC itself, not import units for system or third-party libraries. Otherwise I'd have to document the whole Win32 API, X, C library etc. Michael, maybe you can write a short description (wiki?) how to create documentation for units not yet documented. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extend the libraries people!
On Fri, 3 Jun 2005, Vincent Snijders wrote: Florian Klaempfl wrote: Michael Van Canneyt wrote: On Fri, 3 Jun 2005, Kornel Kisielewicz wrote: Florian Klaempfl wrote: - write docs for the already existing packages You mean that writing a fpcdoc for the opengl headers for example would be useful for somebody? Myself, I always was uncontent with the fact that there was no opengl section in the rtl docs... We document only units that are written in FPC itself, not import units for system or third-party libraries. Otherwise I'd have to document the whole Win32 API, X, C library etc. Michael, maybe you can write a short description (wiki?) how to create documentation for units not yet documented. Maybe this page can help too: http://lazarus-ccr.sourceforge.net/kb/index.php/Lazarus_Documentation_Editor I couldn't do it better myself :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] David Intersimone Interview about Freepascal and Lazarus!!!
David Intersimone Interview about Freepascal and Lazarus!!! http://www.bitwisemag.com/media/video/iv/davidi_june2005/davidi_interview_delphi.wmv go to 3:32 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] David Intersimone Interview about Freepascal andLazarus!!!
What's about the text version of this interview? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] was: type discussion
I think we're mostly offtopic now, maybe we should EOT or move to private Vinzent Hoefler wrote: Of course C is much worse than contemporary C++ (C++ + std::). Only in theory. Look at typical projects in the industry. I have close look at the projects in my company. And the difference is snignificant. Count separate apps not separate instalations. Doesn't change the count much, I think. Every f*cking microwave oven has its own control program these days. I suspecct that owens from the same manufacturer have the same program or their programs differ only minmally. Then how complex those programs are? Now look how many different general computing apps are out there? The count goes in millions, i think. I'm just asking because somebody from a car company claimed that one bug per 1000 SLOC would be the normal expected amount and I got a study here that claims a bug rate of less then a tenth (0.096 defects/KSLOC [and even for their C-Code, they had 0.676 defects/KSLOC]) for just a compiler and related tools, not for potentially life-critical systems as you'd expect in the 70 or more microprocessors a modern car has built in. Which seems quite surprising considering that the bug rate should be practically independent of the language (ok, this statement is not valid for C99, of course, it's the only exception there). Sarcasm included. Depends how the bugs were counted. In the study I talk, AFAIR there was quite a variation between solutins, but no correlation of defects/kLoC to programming language was found. Smaller programs are easier to maitain. Yes, but small programs are not the typical project. Even small projects break through the 100 KSLOC barrier very quick. Smaller small. But it's generally easier to mainatin 100 kSLoC vs 200 kSLoC system. You can do most of apps withing time bugget even in pure machine code if you'll assume huge enough budget and long enough time. Considering that it wasn't government money they had to waste, instead they took the risk of the whole development theirselves, this certainly wasn't the case here. Lokheed-Martin not wasting goverment money!?! That's something new ;) Yes, true. Funny thing is, that those companies are now almost able to deliver software cheaper than the mainstream. If they would cut the testing completely, they definitely could and the software wouldn't even be as worse. (BTW, that's my own observation, not some study.) The same functionality? Yes. MULTOS/CA had 0.04 defects per KSLOC with an average productivity of 28 lines of code per developer per day, if I remember the figures correctly. But kSLoC kSLoC. What amount of functionality was there is also important. No. Simply preventing some failure is economically viable if cost_of_failure * probality_of_filure const_of_prevention. Yes. But Cost_Of_Failure sometimes seems to be a negative amount while Cost_Of_Prevention never is. That's true only in some special cases, and mostly if you're monopoly. But even MicroSoft had to improve their soft. Sales lost due to customet dissatisfaction are also cost of failure. Nope. There was enough time to develop the app in all but some ackward joke languages. Problem was simple well understood. Yeah. The latter may be the problem. Most real world problems are neither simple nor they are well understood just until after you solved them. :-) Well, I'd say that most of the software is doing the well understood stuff only slightly differing from things already done. That's the reality. Just look at properly designed languages, not Java. I'm looking at the stuff that gets used most often, because it must be superior then, otherwise nobody would use it. You're joking, right? But i.e. Python's automatic memory system didn't convince me any bit more, although it seems more effective to me. Pyhton is not very concerned with performance. Besides there are dynamically typed languages much faster than it (Dylan for example). See comparison with C. They're more or less equal performance wise. What? http://shootout.alioth.debian.org/ benchmark.php?test=alllang=icclang2=ocamlsort=fullcpu doesn't look much *equal* to me. Maybe, my feeling for numbers is screwed up. The difference is not big. It's allmost the same as with C++ vs C. |function Foo (const I : Integer) : Integer; |begin | ... |end; in Ada looks |function Foo (I : in Integer) return Integer is |begin | ... |end Foo; But what is that '...' is what matters. Yes, of course. But we were talking about verbosity in general and not on the amount of standard libraries. Hmmm... Verbosity is not important. Expresiveness is. You can have language with verbose or not verbose constructs, but wether those constructs are expressive or not is an orthogonal matter. C constructs are typilcally non-expressive and not verbose. Standard Pascal construct are verbose but not too expressive. Object
RE: [fpc-devel] David Intersimone Interview about Freepascal andLazarus!!!
Well, he does not say anything about the project specifically, just that Borland is committed to Delphi, surprise, surprise :-) Micha Actually, when asked if Lazarus, FPC, etc are competitors to Delphi he says: I think they're just other languages or other projects for people to take a look at. I.E. Yes, it's called competition. He's also afraid to admit that FPC + Laz actually IS the same language as Delphi and tries to make people believe it's not the same language... It's NOT the same IDE, but it IS the same LANGUAGE. -Tony -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.5.2 - Release Date: 6/3/2005 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Fixes for win32 dlls smartlink
Was that why when I created a DLL it only worked with smartlinking off?
Was: When you create DLL with -CX option or with {$SMARTLINK ON} in main module
-
the DLL was have no exports section in binary.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
