Re: [fpc-pascal] dynamic array contents and system.move
David Emerson schrieb: I *am* checking sizes before the move, which is why it surprised me that things were going out of bounds -- the trouble is I forgot the array index [0] Yes, that happens quite often. Unfortunately, Borland gave up the clear und predictable context independend Pascal syntax when implementing dynamic data structures. Dynamic arrays are actually *pointers* to the data while static arrays are the data itself. But the pointers of dynamic arrays are dereferenced automatically when used except for fundamental byte functions like move or fillchar. It would have been better to dereference the pointer for these functions too. I don't know why Borland did not do that. Now we have to live with this mess only because of Delphi compatibility. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Jürgen Hestermann schrieb: >> David Emerson schrieb: >> I *am* checking sizes before the move, which is why it surprised me >> that things were going out of bounds -- the trouble is I forgot the >> array index [0] > > Yes, that happens quite often. Unfortunately, Borland gave up the clear > und predictable context independend Pascal syntax when implementing > dynamic data structures. Simply because dereferencing a dyn. arrays makes no sense because it is more than just a simply data collection. > Dynamic arrays are actually *pointers* to the > data while static arrays are the data itself. But the pointers of > dynamic arrays are dereferenced automatically when used except for > fundamental byte functions like move or fillchar. This is plainly wrong. When indexing a dyn. array, the compiler generates the correct code to access the data, no more no less. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Florian Klaempfl schrieb: Simply because dereferencing a dyn. arrays makes no sense because it is more than just a simply data collection. Realy? What else is happening in the background? This is plainly wrong. When indexing a dyn. array, the compiler generates the correct code to access the data, no more no less. So what is the difference between 'MyArray[0]' and 'MyArray^'? Don't they mean the same address? Isn't it possible to use 'MayArray^' as a parameter for move or fillchar? I thought so. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Jürgen Hestermann schrieb: >> Florian Klaempfl schrieb: >> Simply because dereferencing a dyn. arrays makes no sense because >> it is more than just a simply data collection. > > Realy? What else is happening in the background? Reference counting (also of the stored data), automatic length storage. >> This is plainly wrong. When indexing a dyn. array, the compiler >> generates the correct code to access the data, no more no less. > > So what is the difference between 'MyArray[0]' and 'MyArray^'? MyArray[0] enforces range checking if it is enabled, further differences, see below. > Don't > they mean the same address? I would expect to get @MyArray[0]-sizeof(pointer)*2 when doing MyArray^ (which is not allowed), because this is the start of the actual array information. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
> This is plainly wrong. When indexing a dyn. array, the compiler > generates the correct code to access the data, no more no less. It would be possible to allow this syntax : move(data ... in addition to the current : move(data[0] ... There is no fundamental reason why it wouldn't be possible. The compiler would generate the correct code as you mentioned. Every newbie is struggling with this syntax. I remember struggling with it myself. It is not intuitive at all. Regards, Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Juha Manninen schrieb: >> This is plainly wrong. When indexing a dyn. array, the compiler >> generates the correct code to access the data, no more no less. > > It would be possible to allow this syntax : > move(data ... > in addition to the current : > move(data[0] ... > > There is no fundamental reason why it wouldn't be possible. There is: there is no reason why move should be handled differently than other procedures. > The compiler would > generate the correct code as you mentioned. > Every newbie is struggling with this syntax. I remember struggling with it > myself. It is not intuitive at all. If you mess with move and have no clue about internals, then you get burned. Period. Proper dyn. array code uses copy(...) instead of move. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
It would be possible to allow this syntax : move(data ... in addition to the current : move(data[0] ... There is no fundamental reason why it wouldn't be possible. There is: there is no reason why move should be handled differently than other procedures. But currently move *does* handle dynamic arrays differently than other procedures. You can use an array as parameter for a function or procedure and it does not matter whether it's dynamic or not. So the identifier means the array in both cases. But this does *not* apply to move or fillchar! That's illogical. If you mess with move What do you mean with "mess". It's a standard function since decades. The only thing that was "messed up" was the syntax of dynamic arrays. and have no clue about internals, then you get burned. Period. Proper dyn. array code uses copy(...) instead of move. That's nonsense. The only thing that is wrong here is that the identifier for an dynamic array means different things dependend from the context. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Simply because dereferencing a dyn. arrays makes no sense because it is more than just a simply data collection. Realy? What else is happening in the background? Reference counting (also of the stored data), automatic length storage. But that has nothing to do with the fact that the identifier "MyArray" should have the same address as "MyArray[0]" so that both should be usable for move or fillchar. The first means the whole array while the latter means the first element only. So what is the difference between 'MyArray[0]' and 'MyArray^'? MyArray[0] enforces range checking if it is enabled, further differences, see below. Still this is not relevant when using MyArray^ instead of MyArray[0]. Both should mean the same address (and that's the only thing that move/fillchar need). In case the used pointer is nil a runtime error could occur when trying to dereference it (as is done for other pointers too). Don't they mean the same address? I would expect to get @MyArray[0]-sizeof(pointer)*2 when doing MyArray^ (which is not allowed), because this is the start of the actual array information. I don't. I think it is the same as for AnsiStrings: The pointer points to the first element and the reference counter is stored at lower addresses. So you should be able to move x bytes from the beginning of MyArray without the need to know the first element number. The identifier of a dynamic array should either be a pointer (so that it has to be dereferenced with ^ when accessing elements) or it should mean the beginning of the array (starting with the first element) *in all cases* (not only in some as it's now). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] dynamic array contents and system.move
Hello FPC-Pascal, Sunday, April 25, 2010, 5:38:48 PM, you wrote: JH> But currently move *does* handle dynamic arrays differently JH> than other procedures. You can use an array as parameter for a JH> function or procedure and it does not matter whether it's dynamic JH> or not. So the identifier means the array in both cases. But this JH> does *not* apply to move or fillchar! That's illogical. I think there is a great difference between normal arrays and dynamic ones, in normal arrays: A: array [0..1] of integer; move (a[0],somewhere^,8); is OK, but in dynamic arrays it should be: A: array of integer; SetLength(A,2); move (a[0],somewhere^,4); move (a[1],(somewhere+4)^,4); Because I think dynamic arrays does not garantee that all elements are together in a big chunck. So something like "move (A,somewhere^,Length(A)*sizeof(AElement))" is nonsense. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
On 25 Apr 2010, at 17:38, Jürgen Hestermann wrote: >>> It would be possible to allow this syntax : >>> move(data ... >>> in addition to the current : >>> move(data[0] ... >>> There is no fundamental reason why it wouldn't be possible. >> There is: there is no reason why move should be handled differently than >> other procedures. > > But currently move *does* handle dynamic arrays differently than other > procedures. It handles it exactly the same as any other function/procedure that takes a untyped/formal "var" parameter. Formal var parameters always take on the address of whatever you pass. The confusion comes from the fact that a dynamic array, just like ansi/wide/unicodestrings and a Delphi-style classes/interfaces, is an implicit pointer to the actual data. Hence, if you pass a variable of such type to a formal var parameter, you are passing a pointer to this implicit pointer as the parameter value (rather than a pointer to the actual data). >> If you mess with move > > What do you mean with "mess". It's a standard function since decades. fillchar() and move() are equivalent to direct assembly level programming as far as the abstraction level is concerned because they ignore all type info. The fact that they ignore all type info is a mess. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
But currently move *does* handle dynamic arrays differently than other procedures. It handles it exactly the same as any other function/procedure that takes a untyped/formal "var" parameter. Formal var parameters always take on the address of whatever you pass. That's not true! There is a lot of ambigouity with dynamic arrays. Although an underlying pointer is used internally you use it as if it was the array this pointer is pointing to in your code. If you first have a static array "MyArray" then convert it to a dynamic array you don't have to change your code (except if you use fillchar and/or move). Why that? What exactly does "MyArray" mean? You can't tell because it is context dependent. That's not in the spirit of Pascal. The confusion comes from the fact that a dynamic array, just like ansi/wide/unicodestrings and a Delphi-style classes/interfaces, is an implicit pointer to the actual data. Hence, if you pass a variable of such type to a formal var parameter, you are passing a pointer to this implicit pointer as the parameter value (rather than a pointer to the actual data). True. As I said: There is no common logic what the identifier "MyArray" means if it is a dynamic array (but there is for static arrays). fillchar() and move() are equivalent to direct assembly level programming as far as the abstraction level is concerned because they ignore all type info. The fact that they ignore all type info is a mess. It's true that it ignores all *type* info. Still there was no ambigouity about the starting address of a variable you give as parameter until dynamic arrays were introduced (including AnsiStrings). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
I think there is a great difference between normal arrays and dynamic ones Yes, but it should not be like that. If you first declare a static array and then decide to make it a dynamic array then *no* code change should be required. But now it is for move and fillchar. is OK, but in dynamic arrays it should be: A: array of integer; SetLength(A,2); Why change the array length here? The array has a length already. What if the array had 10 elements before? move (a[0],somewhere^,4); move (a[1],(somewhere+4)^,4); Because I think dynamic arrays does not garantee that all elements are together in a big chunck. I think that this *is* guaranteed. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Jürgen Hestermann schrieb: > > >>> But currently move *does* handle dynamic arrays differently than >>> other procedures. >> It handles it exactly the same as any other function/procedure that >> takes a untyped/formal "var" parameter. Formal var parameters always >> take on the address of whatever you pass. > > That's not true! There is a lot of ambigouity with dynamic arrays. > Although an underlying pointer is used internally you use it as if it > was the array this pointer is pointing to in your code. If you first > have a static array "MyArray" then convert it to a dynamic array you > don't have to change your code (except if you use fillchar and/or move). > Why that? What exactly does "MyArray" mean? See below. > You can't tell because it is > context dependent. That's not in the spirit of Pascal. File types are also less or more opaque. As soon as you start using move/fillchar on them without knowing exactly what you do, you're in trouble. > > True. As I said: There is no common logic what the identifier "MyArray" > means if it is a dynamic array (but there is for static arrays). It means the whole array (which is an opaque type). No more no less. > >> fillchar() and move() are equivalent to direct assembly level >> programming as far as the abstraction level is concerned because they >> ignore all type info. The fact that they ignore all type info is a mess. > > It's true that it ignores all *type* info. Still there was no ambigouity > about the starting address of a variable you give as parameter until > dynamic arrays were introduced (including AnsiStrings). The same applies to classes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
On 25 Apr 2010, at 18:24, Jürgen Hestermann wrote: >>> But currently move *does* handle dynamic arrays differently than other >>> procedures. >> It handles it exactly the same as any other function/procedure that takes a >> untyped/formal "var" parameter. Formal var parameters always take on the >> address of whatever you pass. > > That's not true! Well, it is. > There is a lot of ambigouity with dynamic arrays. There certainly is if you expect them to work like regular arrays. They are a quite different datatype. > Although an underlying pointer is used internally you use it as if it was the > array this pointer is pointing to in your code. If you first have a static > array "MyArray" then convert it to a dynamic array you don't have to change > your code (except if you use fillchar and/or move). Or any other routine that takes an untyped var (or out, or const) parameter. Or if you assign one array to another and modify elements (assigning dynamic arrays creates shallow copies, and unlike with ansistrings these are not made unique when you change individual elements). Dynamic arrays are different from regular arrays in several respects. >> fillchar() and move() are equivalent to direct assembly level programming as >> far as the abstraction level is concerned because they ignore all type info. >> The fact that they ignore all type info is a mess. > > It's true that it ignores all *type* info. Type info is quite important when type-deendent implicit dereferencing enters the picture. > Still there was no ambigouity about the starting address of a variable you > give as parameter until dynamic arrays were introduced (including > AnsiStrings). And classes. And interfaces (although these don't really point to any data, other than internal stuff). Jonas PS: could you correct the clock of your system? Several of your replies have time stamps that predate the mails your are replying to (not this one, but others).___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
True. As I said: There is no common logic what the identifier "MyArray" means if it is a dynamic array (but there is for static arrays). It means the whole array (which is an opaque type). No more no less. Then it should be possible to use "MyArray" as a parameter for move/fillchar but obviously this is not the case. It's true that it ignores all *type* info. Still there was no ambigouity about the starting address of a variable you give as parameter until dynamic arrays were introduced (including AnsiStrings). The same applies to classes. Maybe, but why not simply use the starting address of the array when using "MyArray" as parameter for fillchar/move? It would have avoided a lot of trouble. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Jürgen Hestermann schrieb: >>> True. As I said: There is no common logic what the identifier "MyArray" >>> means if it is a dynamic array (but there is for static arrays). >> It means the whole array (which is an opaque type). No more no less. > > Then it should be possible to use "MyArray" as a parameter for > move/fillchar but obviously this is not the case. No. Because it does not mean the *array's data* but the *array*. > >>> It's true that it ignores all *type* info. Still there was no ambigouity >>> about the starting address of a variable you give as parameter until >>> dynamic arrays were introduced (including AnsiStrings). >> The same applies to classes. > > Maybe, but why not simply use the starting address of the array when > using "MyArray" as parameter for fillchar/move? It would have avoided a > lot of trouble. If people don't pretent to be clever and just use copy instead of the low level procedure move, this would avoid *real* trouble. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
But currently move *does* handle dynamic arrays differently than other procedures. It handles it exactly the same as any other function/procedure that takes a untyped/formal "var" parameter. Formal var parameters always take on the address of whatever you pass. That's not true! Well, it is. In the help for fillchar it says: "Fillchar fills the memory starting at X with Count bytes or characters with value equal to Value." So what should a user think if he uses the identifier "MyArray" of a dynamic array as parameter? How should he know that *in this case* "MyArray" is taken as the pointer to the array while in all other cases (indexing etc.) it is meant to be the array itself? There is a lot of ambigouity with dynamic arrays. There certainly is if you expect them to work like regular arrays. They are a quite different datatype. At least it should always mean the same independent from context. Although an underlying pointer is used internally you use it as if it was the array this pointer is pointing to in your code. If you first have a static array "MyArray" then convert it to a dynamic array you don't have to change your code (except if you use fillchar and/or move). Or any other routine that takes an untyped var (or out, or const) parameter. In all these cases the meaning of the identifier of a variable should stay the same. Only handling is different. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Then it should be possible to use "MyArray" as a parameter for move/fillchar but obviously this is not the case. No. Because it does not mean the *array's data* but the *array*. So it doesn't mean anything? What exactly is the *array* if not it's data? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
On 25 Apr 2010, at 19:32, Jürgen Hestermann wrote: >>> There is a lot of ambigouity with dynamic arrays. >> There certainly is if you expect them to work like regular arrays. They are >> a quite different datatype. > > At least it should always mean the same independent from context. It does always mean the same, just like a class instance always means the same. It's just that implicit dereferencing is applied as soon as you try to access an element (again, like with classes). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Jürgen Hestermann schrieb: >>> Then it should be possible to use "MyArray" as a parameter for >>> move/fillchar but obviously this is not the case. >> No. Because it does not mean the *array's data* but the *array*. > > So it doesn't mean anything? What exactly is the *array* if not it's data? A variable with a certain type where certain operations can be applied. To access the array's data, you've to use [...], to set the length of the data, pass it to setlength etc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] dynamic array contents and system.move
Hello FPC-Pascal, Sunday, April 25, 2010, 6:29:26 PM, you wrote: >> I think there is a great difference between normal arrays and dynamic ones JH> Yes, but it should not be like that. If you first declare a JH> static array and then decide to make it a dynamic array then *no* JH> code change should be required. But now it is for move and JH> fillchar. And many more are not identical: A: array of integer; B: array of integer; setlength(A,1); A[0]:=12; B:=A; A[0]:=13; writeln(B[0]); Which values will be printed ? 12 or 13 ? >> is OK, but in dynamic arrays it should be: >> A: array of integer; >> SetLength(A,2); JH> Why change the array length here? The array has a length JH> already. What if the array had 10 elements before? Because if had defined the array in the line just before "SetLengh" and I need to give it a size. >> move (a[0],somewhere^,4); >> move (a[1],(somewhere+4)^,4); >> Because I think dynamic arrays does not garantee that all elements are >> together in a big chunck. JH> I think that this *is* guaranteed. In fact I'm quite sure that it is not garanteed in none of both arrays, static and dynamic, but it happends always in static as it is convenient in all terms. In fact I think this code in static arrays is wrong: A: array [0..1] of byte; move(a,somewhere,2); It could or could not work in different architectures. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] State of FPC docs.rant
Okay, Since there hasn't been a clear response on this I've started my own website, to start documenting more of the use of each library. However doing so I am finding some clear issues, and that is some of these units are not finished all the way. Is there some list of missing functionality somewhere for these units? Knowing this would help contributers figure out what units need help. http://fpc-docs.gorilla3d.com/built-in-units fcl-image - Ability to write text on canvas has 'NotImplemented" So trying to use any text operations will fail, but there is place holders on type type fonts. sqlite - Every single query has "Testing: (Query)" outputted in the console. I looked in the unit and found its clearly there with WriteLn(). I also trying to figure out what the second parameter of Query does, Its a TStrings... maybe a prepared statement. I have to read the source code a bit more to find out. I find it weird that both 2.2 and 2.4 have this test print. Does anyone use the unit sqlite included with FPC? On Thu, Apr 22, 2010 at 11:12 PM, Thierry Coq wrote: > Joseph, Vincent, > > <+1> > > Add me to the list here. > > I also offer to help, especially for writing UML diagrams to help people > visualize, including use cases, class diagrams and scenarios. Every > component I publish has unit testing and UML diagrams, if only a few. > > Thierry > ___ > fpc-pascal maillist - fpc-pas...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > -- Joseph Montanez Web Developer Gorilla3D Design, Develop, Deploy ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] State of FPC docs.rant
On 25 April 2010 21:48, Joseph Montanez wrote: > Since there hasn't been a clear response on this I've started my own > website, to start documenting more of the use of each library. The class documentation generated by fpdoc has support for examples. FPC's policy is to only publish documentation on units that have been fully documented. Your mileage my vary on what "fully documented" means. ;-) This is different to the documentation style of for example Lazarus LCL, where automated "template" documentation is generated for all units - most being undocumented. Looking at your website, that is exactly the kind of code examples that should be included with the official documentation. I think the preferred location should be with the existing RTL and FCL documentation. I don't see a benefit in having fragmented documentation over various websites and locations. This makes it near impossible for a end-user to find help. I would suggest you checkout the latest copy of the documentation SubVersion repository: http://svn.freepascal.org/svn/fpcdocs/trunk Then submit code examples for the various units. Here is an example of fpdoc documentation generated with images and examples, for another open source project I work on, called tiOPF (Object Persistent Framework). http://opensoft.homeip.net/tiopf/core/titokenlibrary/index.html http://opensoft.homeip.net/tiopf/core/titokenlibrary/ttokens.html Image support inside fpdoc was added a few months ago, but I don't think RTL or FCL docs take advantage of it yet. This could be useful for UML or Class diagrams as well - being part of the official documentation. I'm sure I am speaking for the whole FPC community, that it is great to see people other than Michael van Canneyt help out with the documentation. But I still think we must try to keep documentation together and part of the official documentation as much as possible. The end-users and developers using FPC which find it [the help with examples] easier and be more helpful in the long run. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] State of FPC docs.rant
> I don't see a benefit in having fragmented documentation over various > websites and locations. This makes it near impossible for a end-user to find > help. The language itself is even worst, this is the biggest pitfall of Pascal in general. I can't tell you how hard it is to find anything on google, and I do mean anything. http://community.freepascal.org:1/search/search?q=list+of+strings&t=Search <-- big fail why is everything highlighted (gah!) it gave me a function but nothing on how to use it. Lets use google, freepascal.org has nothing useful: "free pascal string list" <-- nothing useful "free pascal list of strings" <-- nothing useful "free pascal array of strings" <-- nothing useful "free pascal array of strings" <-- nothing useful "pascal array of strings" <-- getting closer, but there has to be something on TStringList, right? "delphi tstringlist" <-- PERFECT Pascal's presents on Google is piss poor because you have to guess which dialect to use, Pascal, Free Pascal, Delphi, Object Pascal, for searches. > I would suggest you checkout the latest copy of the documentation > SubVersion repository: > > http://svn.freepascal.org/svn/fpcdocs/trunk > > Then submit code examples for the various units. Are you seriously want everyone that wants to help out be forced into SVN and learn FPDoc syntax, submit patches, wait for integration? I'll be more then happy to move my work onto Free Pascal Wiki, but I think its a bad idea to funnel anyone that wants to add to docs even if its a typo change into that sort of process. At least in a wiki if someone wanted to make a quick change they could sign in and make it. You look at something like http://zendframework.com/manual/en/ were most of the time I don't know what functions I need, but I do know basic topic. I.E I need to implement OAuth, it will walk me through the entire process. Their OAuth example is a bit poor since that will fit into an "Overview" of FPDoc, but their others are a greater example more of a walk through. Code examples are the most important but there is a LOT more that make documentation great. So the last thing you want is a tall wall in front before you can even help out. -- Joseph Montanez Web Developer Gorilla3D Design, Develop, Deploy ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fcl-passrc example program, and a couple of bugreports
All the talk about the Pascal parser in fcl-passrc got me interested recently. I did some experiments, and I thought I mention here: 1. I added a simplest example how to use fcl-passrc to the wiki: http://wiki.freepascal.org/fcl-passrc 2. And reported a couple of bugs found in fpdoc (tested on PasDoc's testsuite): http://bugs.freepascal.org/view.php?id=16340 http://bugs.freepascal.org/view.php?id=16341 http://bugs.freepascal.org/view.php?id=16342 http://bugs.freepascal.org/view.php?id=16343 http://bugs.freepascal.org/view.php?id=16344 http://bugs.freepascal.org/view.php?id=16345 http://bugs.freepascal.org/view.php?id=16346 http://bugs.freepascal.org/view.php?id=16347 Some other failures were found (see the testcase: ok_dispid_method.pas, ok_dot_unitname.pas in pasdoc svn), but these were language features not handled by the FPC at all for now. Also, program files are not parsed by fcl-passrc, it's limited to units for now. We would like to be able to eventually parse program files too. Yes, they make sense even in a documentation generator, since you can then e.g. gather all units used by the program and get your list of units to make docs from there. An optional, sure (in general, we could pick too few or too many units) but for some situations a useful feature (not finished in PasDoc, but planned). fcl-passrc is quite capable already, it successfully parsed a lot of quirky sources, so it's really great already :) Hope my reports hope to push it even better :) Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Florian Klaempfl wrote: > If you mess with move and have no clue about internals, then you get > burned. Period. Proper dyn. array code uses copy(...) instead of move. I wish there was a type-checked equivalent to what move does. copy creates a new array, and I don't want to do that: I already have a big block of memory reserved in the dynarray. I just want to move some data into that space -- sometimes only a part of it. Is there any alternative? It would be nice if move would give a compiler warning or note if it receives a pointer-pointer. I guess that would require move doing type-checking... but at compile-time, is there anything wrong with move doing such a type-check and issuing a warning? ~D. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] State of FPC docs.rant
On 26/04/2010 8:23 AM, Joseph Montanez wrote: I would suggest you checkout the latest copy of the documentation SubVersion repository: http://svn.freepascal.org/svn/fpcdocs/trunk Then submit code examples for the various units. Are you seriously want everyone that wants to help out be forced into SVN and learn FPDoc syntax, submit patches, wait for integration? I'll be more then happy to move my work onto Free Pascal Wiki, but I think its a bad idea to funnel anyone that wants to add to docs even if its a typo change into that sort of process. At least in a wiki if someone wanted to make a quick change they could sign in and make it. On the one hand, Graeme is probably right, in that putting it in the docs is the *best* thing to do. On the other hand, Joseph has a point - I have worked out most bits of FPC over the course of a few years, but the documentation system is certainly a notable exception. After several reasonably serious attempts to understand it, I still have not got the faintest notion *. However, I do really agree that the last thing to do is to put it on yet another site. My suggestion would be to just put it on the Lazarus wiki, if you are comfortable with wikis. I did that with some database documentation I wrote, not realising at that stage that it really applied to FPC RTL rather than Lazarus. Not one deleted it, no one - sorry, only one person - was rude, and I think a few people have used it since. Significantly, the people who REALLY need it probably won't have worked out that it is technically in the wrong place (under Lazarus instead of FPC) because it seems to take most people a little while to get the difference sorted out anyway. * If anything is in need of some user level documentation, it is the documentation system it self. I suspect that all the details are documented, but no-one has written the overview, because the people who wrote it knew it so well, they did not see the need. Or perhaps I just have not ever found it. cheers John Sunderland ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Is there anyone will answer my questions
Dear FreePascal,
I have some questions when I am using Free Pascal
>> firstly , I find that I Can't use hot-key "Ctrl+N" to add
a new line in the IDE.
and I think the Free Pascal's ide is not very stable,
I am using fpc under a MS-DOS 7.1, sometimes when I am editing
my sourse code(I chosed Microsoft Convention (Ctrl+X,Ctrl+V,Ctrl+C) )
if I pressed Ctrl+C
sometimes the ide will terminate and said like this:
" The ide is terminated , save your soure code and restart the ide"
And sometimes if I use Alt+F and Commend Shell
the ide is still in my sight . Maybe it is because "Out of Memory"?
>> secondly, if I want to debug my program when I use "step over F8"
the ide will display the user screen when I press F8. It is not the
same as Turbo Pascal. I really dislike it ,but I don't know what to
do.
>> Tirdly, once I was programming a program (the source code is below)
when I input about 100 data the program occured a error ,then it
terminated. I don't why ,and I can't understand the Error Code it gives
to me.Can you find my error and fix it for me?
{===The source code is below === }
program ElementTable ;
{this program's purpose is to input The Periodic Table of Element }
type
yuansu=record
En_name:string[3];
mole:real;
period:1..7;
group:string[5];
end;
var
i:integer;
dat:file of yuansu;
jilu:array [1..112] of yuansu;
BEGIN
for i:=1 to 2 do
jilu[i].period:=1; (* Here is a input example :*)
for i:= 3 to 10 do(* En_name:= 'C'*)
jilu[i].period:=2; (* mole:=12.0107*)
for i:= 11 to 18 do (* period:=2*)
jilu[i].period:=3; (* group:='IVA' *)
for i:= 19 to 36 do
jilu[i].period:=4;
for i:=37 to 54 do
jilu[i].period:=5
for i:=55 to 71 do
jilu[i].period:=6;
for i:=72 to 112 do
jilu[i].period:=7;
for i:=1 to 112 do
begin
write('name:');
readln(jilu[i].EN_name); {it terminated when it }
write('mole:'); { runs to somewhere }
readln(jilu[i].mole);{ around here}
write('group:');
readln(jilu[i].group);
end;
assign(dat,'dat.bin');
{$i-} reset(dat);{$i+}
if ioresult <>0 then
rewrite(dat);
for i:=1 to 112 do
write(dat,jilu[i]);
close(dat);
write(' ':10,'OK!');
readln
END.
Sincenrely
Andy Scout
2010.4.17___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
On 26 Apr 2010, at 03:27, David Emerson wrote: It would be nice if move would give a compiler warning or note if it receives a pointer-pointer. I guess that would require move doing type- checking... but at compile-time, is there anything wrong with move doing such a type- check and issuing a warning? Yes: a) the compiler has no idea about "move" in particular, so it would give this warning for all pointers passed to formal var/const/out parameters b) this warning would also be triggered if you'd use move on a regular array of pointers, which would be wrong Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
