Re: [fpc-devel] Using Macros for IInterface
On 2012-09-27 19:16, Florian Klämpfl wrote: > > You care about Delphi compatibility? :) I was waiting for that. I care about coding not having IFDEF yes - so it stays readable. tiOPF is the only project I work on that is a shared code base. Graeme. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
Guys, I'm sorry if this has re-opened old memories of the "NNTP wars" and the "Great Listserv Battle", and caused flashbacks and "post-http-stress-disorder"! :) That wasn't my intention, I swear! Of course, it would be naïve of me to think that any urge to fix and update (or "change", as it's called :) things wouldn't cause some conflict Having said that, if I can inject my own experiences I remember long nights with my mates running uucp and 2400 baud modems and writing connect scripts and resetting ttys frantically trying to recycle serial ports And that was leading-edge technology, oh my! That was so much fun, and it was "only" a hobby, I had to go and do paid work the next day. The one thing I do know for sure is that technology has got to the point now where it isn't just one thing that will be what we (and by "we" I mean you guys, and eventually, hopefully, me as well) will use to do what we need to with fpc and lazarus. So I think there's a good chance that we'll use listserv technology to do what we need to communicate to people, and a choice of nntp and http clients for anyone who's more comfortable that way. We don't need to go completely one way OR the other, and most modern forum software acknowledges that. Bottom line, we call sendmail() to notify, isamdb() (or whatever) for storage, and probably http for ui and management. My hope is that we get to meet and maybe even exceed people's expectations for help with problems, looking after the data in the archives and making that available to anyone who needs it, regardless of the interface we provide. But, in reality, people these days find listserv difficult to understand, set up, and keep on top of. Especially when messages are more easily and safely stored where they'll do the most good - in a globally-accessible searchable relational database (which is still pretty old technology - maybe not smoking jacket-and-pipe old, but it's been around for a while). You can still download and store the data you need if you still want to do that. The same goes (I'm sorry to say) for nntp servers and clients. Just saying clients and servers takes me back to the good ol' days of users respectfully requesting bits of information from the Acolytes and Maintainers of the Archive There are better and far more easily and securely available protocols that no-one has to install clients for, or configure passwords and ports and ssl hashes, or try and come up with a hierarchical structure that makes sense to them, and only them The bottom line is, what we're used to (and I still have my CP/M and Borland news server lists updated every week, trust me!) isn't necessarily what new users are going to expect. They're not even going to ask for that information - they're going to expect it to be provided for them, in a format that is secure, infinitely searchable, fast, nice-looking (that always helps) and that they don't have to download, install, configure, test, and maintain. That's most definitely what we're used to, I agree, but it's not how things work these days, except for a valiant few. (That's us). One thing I've learned from these interesting discussions is that whatever form the site morphs into, it will need to be able to at least allow a couple of different ways of getting that information. If that means we have to build an nntp servlet interface for people most comfortable with nntp clients, let's at least try to include that as part of the service. I don't know of any modern server software that provides multiple protocol access to the same datastore, but you guys know more about that than I do! If it's possible, why not build it in? Then at least you get to compare access types and see what really works for you. I'm truly not just a forum-promoting hyper-unrealistic change monkey. I'm too old and way too tired for that these days, trust me! :) But the thing that's drawn me in to this whole situation, is that the way it works now *can* be improved (hopefully without degrading any part of the community interaction), and by improving it, we make it easier and "funner" for new users of fpc to come onboard and ask, contribute, whine, and discuss. I suspect that's a good thing, but it's not up to me, I'm just the spanner in the works! I sound like a real estate developer. Kill me now, please. -Pete ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 27.09.2012 19:33, Marco van de Voort wrote:
In our previous episode, Marcos Douglas said:
- Records... "R" (?)
- Constants... UPPER_CASE? cSomething?
At least we would have a good and unique style.
IMHO, that's taking it too far. Usually there is only made a difference between
scopes (e.g. field and parameter, or global symbol and field), that could
cause confusion. Within the same scope, duplicate identifiers are already
excluded.
The Delphi notation is not entirely consistent though, the interface "I"
prefix convention e.g. is therefore not that logical, and probably
inherited.
Enums are also commonly prefixed, but I wouldn't mind an option to turn
enums into a different scope (so that you can only use them qualified).
IIRC a recent Delphi adds such switch, but I'm already used to it from my M2
days.
{$scopedenums on/off} already works in FPC 2.6.0.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 2:43 PM, Michael Van Canneyt wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > >>> >>> I hope not :-) >> >> >> Of course the second is (a little) better. >> >> But, If you permits: >> for i := StardValue to EndValue do >> MyArray[i] := i; >> >> Now is more readable. More verbose than the first but less verbose >> than second. ;) >> >>> And it's not about the size of variable names. It's just about avoiding >>> duplicate names which can lead to confusion. >> >> >> You right but: >> - prefix increases the size :P >> - variables abbreviated are more easy to programmers do not use the >> same names to, objects, primitives variables, etc. > > > Once we had the following code in Delphi: > > Procedure TMyComponent.DoSomething; > > Var > B : String; > begin > // complex code to calculate B. Prop is a property of the component. > Prop:=B > end; > > Someone, while fixing a bug, introduced then > > Procedure TMyComponent.DoSomething; > > Var > B : String; > Prop : String; > > begin > // complex code > Prop:=B > end; > > And all of a sudden, our program no longer worked. It took us a long time to > find the error, namely an newly introduced local variable. > > This kind of error is simply impossible in objfpc mode. Ok, I'm convinced. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Using Macros for IInterface
Am 26.09.2012 13:27, schrieb Graeme Geldenhuys: > On 2012-09-26 11:40, Marco van de Voort wrote: >> >> It means the interface will always be constref, and thus no ifdefing >> in FPC >> (if you don't support <2.6.0) will be necessary. > > For fpGUI, I only support the latest stable release of FPC, so that > would be 2.6.0. So I should be fine with removing that IFDEF then. > > >> But users don't need to ifdef if they don't use compilers that >> don't support constref (FPC 2.4 series and delphi) > > Umm, so here might be a problem. tiOPF is a shared code base between FPC > and Delphi. Does the compiler mode (we use mode delphi in tiOPF) not > affect the constref? After all, it seems Delphi doesn't have a constref > correct? So in mode delphi the IInterface should always be defined in a > Delphi compatible manner? You care about Delphi compatibility? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: I hope not :-) Of course the second is (a little) better. But, If you permits: for i := StardValue to EndValue do MyArray[i] := i; Now is more readable. More verbose than the first but less verbose than second. ;) And it's not about the size of variable names. It's just about avoiding duplicate names which can lead to confusion. You right but: - prefix increases the size :P - variables abbreviated are more easy to programmers do not use the same names to, objects, primitives variables, etc. Once we had the following code in Delphi: Procedure TMyComponent.DoSomething; Var B : String; begin // complex code to calculate B. Prop is a property of the component. Prop:=B end; Someone, while fixing a bug, introduced then Procedure TMyComponent.DoSomething; Var B : String; Prop : String; begin // complex code Prop:=B end; And all of a sudden, our program no longer worked. It took us a long time to find the error, namely an newly introduced local variable. This kind of error is simply impossible in objfpc mode. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 2:26 PM, Michael Van Canneyt wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > However we can use "poor names" -- very difficult to happen a collision -- to represent a variable like A, J, D... but I do not think this is a good practice and you? >>> >>> >>> >>> I do think this is good practice. I will seldom use variable names of >>> more >>> than 2 characters. >> >> >> So, just a letter "J" tell us everything we need about the variable? >> IMHO this contradicts the spirit of Pascal, a beautiful and readable >> language, but I guess I will lost this discussion. > > > I do not think it is that black and white :) Maybe grey. Equilibrium. :) > I agree that parameter names and global constants should have clear names, > (so code completion is actually useful) but for local variables, I do not > think this is necessary. > > Do you think this > > For MyVeryClearName := StartValue to EndValue do > MyVerLargeArray[MyVeryClearName]:=MyVeryClearName; > > Is better than this: > > For I:=S to E do > A[i]:=I; > > I hope not :-) Of course the second is (a little) better. But, If you permits: for i := StardValue to EndValue do MyArray[i] := i; Now is more readable. More verbose than the first but less verbose than second. ;) > And it's not about the size of variable names. It's just about avoiding > duplicate names which can lead to confusion. You right but: - prefix increases the size :P - variables abbreviated are more easy to programmers do not use the same names to, objects, primitives variables, etc. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
In our previous episode, Marcos Douglas said: > > - Records... "R" (?) > - Constants... UPPER_CASE? cSomething? > > At least we would have a good and unique style. IMHO, that's taking it too far. Usually there is only made a difference between scopes (e.g. field and parameter, or global symbol and field), that could cause confusion. Within the same scope, duplicate identifiers are already excluded. The Delphi notation is not entirely consistent though, the interface "I" prefix convention e.g. is therefore not that logical, and probably inherited. Enums are also commonly prefixed, but I wouldn't mind an option to turn enums into a different scope (so that you can only use them qualified). IIRC a recent Delphi adds such switch, but I'm already used to it from my M2 days. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: However we can use "poor names" -- very difficult to happen a collision -- to represent a variable like A, J, D... but I do not think this is a good practice and you? I do think this is good practice. I will seldom use variable names of more than 2 characters. So, just a letter "J" tell us everything we need about the variable? IMHO this contradicts the spirit of Pascal, a beautiful and readable language, but I guess I will lost this discussion. I do not think it is that black and white :) I agree that parameter names and global constants should have clear names, (so code completion is actually useful) but for local variables, I do not think this is necessary. Do you think this For MyVeryClearName := StartValue to EndValue do MyVerLargeArray[MyVeryClearName]:=MyVeryClearName; Is better than this: For I:=S to E do A[i]:=I; I hope not :-) And it's not about the size of variable names. It's just about avoiding duplicate names which can lead to confusion. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012 13:52:53 -0300 Marcos Douglas wrote: > On Thu, Sep 27, 2012 at 12:34 PM, Graeme Geldenhuys > wrote: > > On 2012-09-27 16:08, michael.vancann...@wisa.be wrote: > >> > >> The compiler helps you by forcing you to use a prefix in objfpc mode in > >> case you forgot. > > > > The change in FPC mode objfpc was definitely a good thing. I had code > > where a class had an Index property, and other methods of that class had > > an Index parameter name. Even though it was my own code, I had to triple > > check the method's implementation to find the real meaning when I used > > the Index identifier somewhere in that method. > > > > Now with the new language rule, I don't have such issues any more. Index > > will be the property name, AIndex will be the parameter, lIndex will be > > a local variable. Much simpler for my brain to process. :) > > I never said this is wrong. I just said that could be a compiler > directive or something like that. > > I agree that is much simpler... but why nobody, in another language, > do the same? Does not worth it? I do not know. Just an example: In Java the name clash is allowed. In the courses I attended many students confuse their variables so much that they think they must always prepend "this" to all member variables. So instead of prepending the parameters, they prepend the members. This is one of the most confused "features" of Java. I'm glad objfpc is less ambiguous than mode Delphi. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 1:58 PM, Graeme Geldenhuys wrote: > On 2012-09-27 17:52, Marcos Douglas wrote: >> >> I agree that is much simpler... but why nobody, in another language, >> do the same? Does not worth it? I do not know. > > Well, other languages have there own quirks like case sensitive > identifiers. Thank God, Object Pascal doesn't have that. > > Just imagine. > > var > MyName: string; > MYNAME: string; > MYName: string; > myName: string; > myname: string; > begin > ... > end; > > :-D Ok. But, even in Pascal, if you have the same variable written in many styles you can have confusion too. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 1:55 PM, Graeme Geldenhuys wrote: > On 2012-09-27 17:46, Marcos Douglas wrote: >> >> This "feature" have the origin in a bug in compiler. > > Yeah, but it takes a human to debug such issues. The compiler might have > no problem understanding complex scopes, but the same could not always > be said for programmers. > > My code was affected by this change too, but all-in-all, I think it was > a good move. Promote the idea of "easier to read and understand" code - > the original goals of Pascal. I agree. But because the same feature I see programmers using poor names in local variables. Ok, just say: use a prefix. But each one programs using the own style! See FPC code, Lazarus code, etc. Even in the same project, you see many styles. Maybe would be better to force everyone (no sarcarm) to use: - Classes should have the prefix "T"; - Arguments should have the prefix "A"; - Local variables should have the prefix "L" or "l" - Pointer..."P"; - Interfaces... "I"; - Records... "R" (?) - Constants... UPPER_CASE? cSomething? At least we would have a good and unique style. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 1:48 PM, Michael Van Canneyt wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > >> On Thu, Sep 27, 2012 at 12:08 PM, wrote: >>> >>> >>> >>> On Thu, 27 Sep 2012, Marcos Douglas wrote: >>> > > Yes, it's always possible. In practice, I haven't seen this happen a > single > time in the 10+ years that the compiler has had this feature. That > doesn't > mean that it's impossible, but it's another factor in the "good to > have" > versus "causes more harm than good" equation. Well, happened on the own compiler. ;-) IMHO, these collisions happen a lot and because of this many programmers use prefixes in local variables, see: lNet, fpGUI, tiOPF2, Indy, and even Delphi (DateUtils unit eg.). >>> >>> >>> >>> Exactly. >>> >>> The compiler helps you by forcing you to use a prefix in objfpc mode in >>> case >>> you forgot. >> >> >> The collisions exist because the compiler give us an error. If the >> compiler respect the scope, the collisions would not exist. > > > I know there is no collision in the strict sense of the word. There is just > the very real possibility of making human mistakes. > > >> However we can use "poor names" -- very difficult to happen a >> collision -- to represent a variable like A, J, D... but I do not >> think this is a good practice and you? > > > I do think this is good practice. I will seldom use variable names of more > than 2 characters. So, just a letter "J" tell us everything we need about the variable? IMHO this contradicts the spirit of Pascal, a beautiful and readable language, but I guess I will lost this discussion. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 17:52, Marcos Douglas wrote: > > I agree that is much simpler... but why nobody, in another language, > do the same? Does not worth it? I do not know. Well, other languages have there own quirks like case sensitive identifiers. Thank God, Object Pascal doesn't have that. Just imagine. var MyName: string; MYNAME: string; MYName: string; myName: string; myname: string; begin ... end; :-D Graeme. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 17:46, Marcos Douglas wrote: > > This "feature" have the origin in a bug in compiler. Yeah, but it takes a human to debug such issues. The compiler might have no problem understanding complex scopes, but the same could not always be said for programmers. My code was affected by this change too, but all-in-all, I think it was a good move. Promote the idea of "easier to read and understand" code - the original goals of Pascal. Graeme. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 12:34 PM, Graeme Geldenhuys wrote: > On 2012-09-27 16:08, michael.vancann...@wisa.be wrote: >> >> The compiler helps you by forcing you to use a prefix in objfpc mode in >> case you forgot. > > The change in FPC mode objfpc was definitely a good thing. I had code > where a class had an Index property, and other methods of that class had > an Index parameter name. Even though it was my own code, I had to triple > check the method's implementation to find the real meaning when I used > the Index identifier somewhere in that method. > > Now with the new language rule, I don't have such issues any more. Index > will be the property name, AIndex will be the parameter, lIndex will be > a local variable. Much simpler for my brain to process. :) I never said this is wrong. I just said that could be a compiler directive or something like that. I agree that is much simpler... but why nobody, in another language, do the same? Does not worth it? I do not know. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Parser problems with C-Data and Character Encoding
On 2012-09-27 14:50, michael.vancann...@wisa.be wrote: > I did some benchmarking. Using XML (well, SOAP) makes a typical > application 6 times slower than a comparative binary transmission > mechanism. Just curious, did you even do that test with JSON as well? Probably still slower than binary, but how much faster than XML? tiOPF has normal XML and "compact XML" for remote persistence layer. The "compact XML" is the default, more cryptic names and values, but reduces network traffic a lot. I still want to add JSON support too. Cheers, G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: On Thu, Sep 27, 2012 at 12:08 PM, wrote: On Thu, 27 Sep 2012, Marcos Douglas wrote: Yes, it's always possible. In practice, I haven't seen this happen a single time in the 10+ years that the compiler has had this feature. That doesn't mean that it's impossible, but it's another factor in the "good to have" versus "causes more harm than good" equation. Well, happened on the own compiler. ;-) IMHO, these collisions happen a lot and because of this many programmers use prefixes in local variables, see: lNet, fpGUI, tiOPF2, Indy, and even Delphi (DateUtils unit eg.). Exactly. The compiler helps you by forcing you to use a prefix in objfpc mode in case you forgot. The collisions exist because the compiler give us an error. If the compiler respect the scope, the collisions would not exist. I know there is no collision in the strict sense of the word. There is just the very real possibility of making human mistakes. However we can use "poor names" -- very difficult to happen a collision -- to represent a variable like A, J, D... but I do not think this is a good practice and you? I do think this is good practice. I will seldom use variable names of more than 2 characters. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 12:26 PM, Graeme Geldenhuys wrote: > On 2012-09-27 15:48, Marcos Douglas wrote: >> problem, IMHO, is that I can't choose when we talk about local >> variables. > > Just like there is a coding style (not language rule) that classes start > with the "T" prefix, and class field variable start with a "F" prefix, I > applied that same coding style to parameters and local variables. > > "L" prefix for local variable - though I prefer the lowercase 'l' for > this for some add reason. The exception being counter variables like x, > y, i, j etc. Because "l" is more beautiful than "L" because is less "verbose". ;-) > "A" prefix for parameter variables. > > Using this simple coding style makes things even more logical and less > confusing, even though I use mode objfpc for 90% of my code. I do the same: https://github.com/mdbs99/Greyhound/blob/master/src/gh_db.pas But I do not like inconsistencies: a) I can use unit names in properties 2) I can use the same name in methods and procedures... etc... but I can not use local variables with the same name as a property(!) Almost everything is Ok and beautiful -- well still lacks "namespace" feature that you also agree with me -- but not this design using local variables. This "feature" have the origin in a bug in compiler. Well... "If you have a fever, it is best to break the thermometer?" Marcos Douglas Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 12:08 PM, wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > >>> >>> Yes, it's always possible. In practice, I haven't seen this happen a >>> single >>> time in the 10+ years that the compiler has had this feature. That >>> doesn't >>> mean that it's impossible, but it's another factor in the "good to have" >>> versus "causes more harm than good" equation. >> >> >> Well, happened on the own compiler. ;-) >> IMHO, these collisions happen a lot and because of this many >> programmers use prefixes in local variables, see: >> lNet, fpGUI, tiOPF2, Indy, and even Delphi (DateUtils unit eg.). > > > Exactly. > > The compiler helps you by forcing you to use a prefix in objfpc mode in case > you forgot. The collisions exist because the compiler give us an error. If the compiler respect the scope, the collisions would not exist. However we can use "poor names" -- very difficult to happen a collision -- to represent a variable like A, J, D... but I do not think this is a good practice and you? Marcos Douglas Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 16:08, michael.vancann...@wisa.be wrote: > > The compiler helps you by forcing you to use a prefix in objfpc mode in > case you forgot. The change in FPC mode objfpc was definitely a good thing. I had code where a class had an Index property, and other methods of that class had an Index parameter name. Even though it was my own code, I had to triple check the method's implementation to find the real meaning when I used the Index identifier somewhere in that method. Now with the new language rule, I don't have such issues any more. Index will be the property name, AIndex will be the parameter, lIndex will be a local variable. Much simpler for my brain to process. :) Graeme. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 15:48, Marcos Douglas wrote: > problem, IMHO, is that I can't choose when we talk about local > variables. Just like there is a coding style (not language rule) that classes start with the "T" prefix, and class field variable start with a "F" prefix, I applied that same coding style to parameters and local variables. "L" prefix for local variable - though I prefer the lowercase 'l' for this for some add reason. The exception being counter variables like x, y, i, j etc. "A" prefix for parameter variables. Using this simple coding style makes things even more logical and less confusing, even though I use mode objfpc for 90% of my code. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 15:30, michael.vancann...@wisa.be wrote: > For me, it has become second nature never ever to have a variable with the > same name as a property, even in Delphi. +1 G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: Yes, it's always possible. In practice, I haven't seen this happen a single time in the 10+ years that the compiler has had this feature. That doesn't mean that it's impossible, but it's another factor in the "good to have" versus "causes more harm than good" equation. Well, happened on the own compiler. ;-) IMHO, these collisions happen a lot and because of this many programmers use prefixes in local variables, see: lNet, fpGUI, tiOPF2, Indy, and even Delphi (DateUtils unit eg.). Exactly. The compiler helps you by forcing you to use a prefix in objfpc mode in case you forgot. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 11:53 AM, wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > >> >> But this is a programmer's choice, ie, using or not the Self. The >> problem, IMHO, is that I can't choose when we talk about local >> variables. > > > You can: Use delphi mode. As I said, I know this is works in delphi mode. But I ask: In delphi mode this feature is Ok, but not in objfpc mode? Why not exists a compiler directive and leave the programmer make your own choice? ;-) Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 11:33 AM, Jonas Maebe wrote:
>
> On 27 Sep 2012, at 16:18, Marcos Douglas wrote:
>
>> On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe
>> wrote:
>>>
>>>
>>> Yes, but the human brain is very good at confusing such things, and it's
>>> very easy to accidentally assign something to a local variable instead of
>>> to
>>> a field.
>>
>>
>> Only Pascal uses that way?
>> How this works on Java, for example?
>
>
> Java doesn't put any restrictions on things like that. And it's not "Pascal"
> that works this way, it's FPC-specific. At least Ada most likely has
> something similar though.
>
>
>>> Because the compiler only checks for identifiers defined in the current
>>> unit. You also cannot assign anything to a "unit", nor "read" from it, so
>>> there is generally less ambiguity (it still can exist in case the field
>>> is a
>>> record/class/object and contains fields that have the same name as global
>>> variables declared in the unit, but that's not exactly common).
>>
>>
>> And this is normal, ie, use unit names like a property of classe?
>
>
> I don't know how common that is, but as mentioned: it is much less likely to
> result in errors than having local variables with the same name as
> properties/fields/methods.
>
>
>>> Because {$mode objfpc} makes different trade-offs compared to {$mode
>>> delphi}. You can pick the one you like best.
>>
>>
>> I agree that should be different, but I think this broke the logical
>> syntax.
>
>
> It's a trade-off: it has both good and bad aspects. We believe the good ones
> outweigh the bad ones. It was introduced after a bug was discovered in the
> compiler itself that was caused by such a problem.
>
>
>> Another: You always use a common name to represent a local variable,
>> like Task. If tomorrow you implement a property called Task, you need
>> to replace all Task local names. You can use the IDE to do this,
>> ofcourse, but you would replace others identifiers inside of strings,
>> for example.
>
>
> Yes, it's always possible. In practice, I haven't seen this happen a single
> time in the 10+ years that the compiler has had this feature. That doesn't
> mean that it's impossible, but it's another factor in the "good to have"
> versus "causes more harm than good" equation.
Well, happened on the own compiler. ;-)
IMHO, these collisions happen a lot and because of this many
programmers use prefixes in local variables, see:
lNet, fpGUI, tiOPF2, Indy, and even Delphi (DateUtils unit eg.).
Marcos Douglas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: But this is a programmer's choice, ie, using or not the Self. The problem, IMHO, is that I can't choose when we talk about local variables. You can: Use delphi mode. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 11:30 AM, wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > >> On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe >> wrote: >>> >>> >>> On 27 Sep 2012, at 15:51, Marcos Douglas wrote: >>> >>> What is the advantages to the compiler return the error bellow? >>> ERROR: unit1.pas(31,3) Error: Duplicate identifier "FooVar" >>> >>> Why the compiler do not respect the scope, ie, the local variable >>> should have the preference, I'm not right? >>> >>> >>> Yes, but the human brain is very good at confusing such things, and it's >>> very easy to accidentally assign something to a local variable instead of >>> to >>> a field. >> >> >> Only Pascal uses that way? > > > No, the brain works that way. > > The FPC team decided to protect you from accidental mistakes by forbidding > this special case in $mode objfpc. > > For me, it has become second nature never ever to have a variable with the > same name as a property, even in Delphi. How do you know if you are using a function or method? For example, I can code a StrToInt method in my class. You can extend it. The "StrToInt method" is now in other unit and you "can't see it". Now you code: blablabla i := StrToInt(x); blablabla Which StrToInt are you using? How our brains could help here? BUT, if you use: Self.StrToInt(x) ... you know what is happening. But this is a programmer's choice, ie, using or not the Self. The problem, IMHO, is that I can't choose when we talk about local variables. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 27 Sep 2012, at 16:18, Marcos Douglas wrote:
On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe > wrote:
Yes, but the human brain is very good at confusing such things, and
it's
very easy to accidentally assign something to a local variable
instead of to
a field.
Only Pascal uses that way?
How this works on Java, for example?
Java doesn't put any restrictions on things like that. And it's not
"Pascal" that works this way, it's FPC-specific. At least Ada most
likely has something similar though.
Because the compiler only checks for identifiers defined in the
current
unit. You also cannot assign anything to a "unit", nor "read" from
it, so
there is generally less ambiguity (it still can exist in case the
field is a
record/class/object and contains fields that have the same name as
global
variables declared in the unit, but that's not exactly common).
And this is normal, ie, use unit names like a property of classe?
I don't know how common that is, but as mentioned: it is much less
likely to result in errors than having local variables with the same
name as properties/fields/methods.
Because {$mode objfpc} makes different trade-offs compared to {$mode
delphi}. You can pick the one you like best.
I agree that should be different, but I think this broke the logical
syntax.
It's a trade-off: it has both good and bad aspects. We believe the
good ones outweigh the bad ones. It was introduced after a bug was
discovered in the compiler itself that was caused by such a problem.
Another: You always use a common name to represent a local variable,
like Task. If tomorrow you implement a property called Task, you need
to replace all Task local names. You can use the IDE to do this,
ofcourse, but you would replace others identifiers inside of strings,
for example.
Yes, it's always possible. In practice, I haven't seen this happen a
single time in the 10+ years that the compiler has had this feature.
That doesn't mean that it's impossible, but it's another factor in the
"good to have" versus "causes more harm than good" equation.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe wrote: On 27 Sep 2012, at 15:51, Marcos Douglas wrote: What is the advantages to the compiler return the error bellow? ERROR: unit1.pas(31,3) Error: Duplicate identifier "FooVar" Why the compiler do not respect the scope, ie, the local variable should have the preference, I'm not right? Yes, but the human brain is very good at confusing such things, and it's very easy to accidentally assign something to a local variable instead of to a field. Only Pascal uses that way? No, the brain works that way. The FPC team decided to protect you from accidental mistakes by forbidding this special case in $mode objfpc. For me, it has become second nature never ever to have a variable with the same name as a property, even in Delphi. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe wrote:
>
> On 27 Sep 2012, at 15:51, Marcos Douglas wrote:
>
> What is the advantages to the compiler return the error bellow?
> ERROR: unit1.pas(31,3) Error: Duplicate identifier "FooVar"
>
> Why the compiler do not respect the scope, ie, the local variable
> should have the preference, I'm not right?
>
>
> Yes, but the human brain is very good at confusing such things, and it's
> very easy to accidentally assign something to a local variable instead of to
> a field.
Only Pascal uses that way?
How this works on Java, for example?
> Not? Why I can use a unit name as a property in my class, so? (see
> bellow the "StdCtrls" property name).
>
>
> Because the compiler only checks for identifiers defined in the current
> unit. You also cannot assign anything to a "unit", nor "read" from it, so
> there is generally less ambiguity (it still can exist in case the field is a
> record/class/object and contains fields that have the same name as global
> variables declared in the unit, but that's not exactly common).
And this is normal, ie, use unit names like a property of classe?
> If I use {mode delphi} I can compile... I know. Why not in {mode objfpc}
> too?
>
>
> Because {$mode objfpc} makes different trade-offs compared to {$mode
> delphi}. You can pick the one you like best.
I agree that should be different, but I think this broke the logical syntax.
Another: You always use a common name to represent a local variable,
like Task. If tomorrow you implement a property called Task, you need
to replace all Task local names. You can use the IDE to do this,
ofcourse, but you would replace others identifiers inside of strings,
for example.
Marcos Douglas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 27 Sep 2012, at 15:51, Marcos Douglas wrote:
What is the advantages to the compiler return the error bellow?
ERROR: unit1.pas(31,3) Error: Duplicate identifier "FooVar"
Why the compiler do not respect the scope, ie, the local variable
should have the preference, I'm not right?
Yes, but the human brain is very good at confusing such things, and
it's very easy to accidentally assign something to a local variable
instead of to a field.
Not? Why I can use a unit name as a property in my class, so? (see
bellow the "StdCtrls" property name).
Because the compiler only checks for identifiers defined in the
current unit. You also cannot assign anything to a "unit", nor "read"
from it, so there is generally less ambiguity (it still can exist in
case the field is a record/class/object and contains fields that have
the same name as global variables declared in the unit, but that's not
exactly common).
If I use {mode delphi} I can compile... I know. Why not in {mode
objfpc} too?
Because {$mode objfpc} makes different trade-offs compared to {$mode
delphi}. You can pick the one you like best.
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Local variable names and colision with attributes/properties names
Hi,
What is the advantages to the compiler return the error bellow?
ERROR: unit1.pas(31,3) Error: Duplicate identifier "FooVar"
Why the compiler do not respect the scope, ie, the local variable
should have the preference, I'm not right?
Not? Why I can use a unit name as a property in my class, so? (see
bellow the "StdCtrls" property name).
If I use {mode delphi} I can compile... I know. Why not in {mode objfpc} too?
See an example code:
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ private declarations }
public
FooVar: string;
StdCtrls: string;
end;
var
Form1: TForm1;
implementation
{$R *.lfm}
procedure TForm1.Button1Click(Sender: TObject);
var
FooVar: string;
begin
FooVar := 'foo';
StdCtrls := 'Is that right?';
end;
end.
Best regards,
Marcos Douglas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Parser problems with C-Data and Character Encoding
On Thu, 27 Sep 2012, Andrew Brunner wrote: On 09/27/2012 04:19 AM, Mattias Gaertner wrote: Have you tried setting the right encoding in the xml? > http://mantis.freepascal.org/view.php?id=22990 I have, and it did and it did work (thanks Sergei :-) Maybe you can explain what you are trying to do? I have a cloud social virtual operating system and each read/write operation is done via XML. So adding content encoding mechanism for comparing each byte is extremely costly from a client/server standpoint. Just imagine 1M+ users and having to encode/decode each xml fragment just to get the parser to parse the data - unwanted latency. AFAIK such statements have seldom a positive effect on volunteer projects. My frustration is not with FPC team, because they are drawing code from projects like firefox. To my knowledge, we are not ? I am extremely sensitive towards wasted cpu cycles as efficiency in scale is maximized by reducing things like byte encoding. Some of my stream fragments can be as large as 1.4MB deflated from 8MB. Multiply that number by say 100 concurrent users on that 1 node and you'll begin to see my frustration. If you are sensible to that, drop XML and use JSON. It will parse much faster, contains far less overhead (smaller packet size). It was invented exactly because XML became too heavyweight. I did some benchmarking. Using XML (well, SOAP) makes a typical application 6 times slower than a comparative binary transmission mechanism. To me, an XML parser is just looking for "<>" etc. Once it hits a CDATA section it should only look for ]]. Therefore I was surprised to learn that it required the encoding tag (which in itself just increased the average network packet size) that I must transmit from client to my server nodes. You cannot just choose which parts of XML to use, and which not. XML is highly standardized, and so are XML parsers. That is why people have standards. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Parser problems with C-Data and Character Encoding
On 09/27/2012 04:19 AM, Mattias Gaertner wrote: Have you tried setting the right encoding in the xml? > http://mantis.freepascal.org/view.php?id=22990 I have, and it did and it did work (thanks Sergei :-) Maybe you can explain what you are trying to do? I have a cloud social virtual operating system and each read/write operation is done via XML. So adding content encoding mechanism for comparing each byte is extremely costly from a client/server standpoint. Just imagine 1M+ users and having to encode/decode each xml fragment just to get the parser to parse the data - unwanted latency. AFAIK such statements have seldom a positive effect on volunteer projects. My frustration is not with FPC team, because they are drawing code from projects like firefox. I am extremely sensitive towards wasted cpu cycles as efficiency in scale is maximized by reducing things like byte encoding. Some of my stream fragments can be as large as 1.4MB deflated from 8MB. Multiply that number by say 100 concurrent users on that 1 node and you'll begin to see my frustration. To me, an XML parser is just looking for "<>" etc. Once it hits a CDATA section it should only look for ]]. Therefore I was surprised to learn that it required the encoding tag (which in itself just increased the average network packet size) that I must transmit from client to my server nodes. A good XML parser would not care what is between core essentials. Content encoding is for human readability it is not for computers nor should it ever be a concern to something as low level as an XML parser. This is best for the Internet and it's servers - not my opinion. Well, whatever you try, you must at least encode all < > and & characters. Right. I guess when it comes to my assertions regarding all this - I am looking for an AHH OK notion as to why my servers have to decode/encode/stamp each XML fragment just so a parser - that is a machine that does not care what a euro looks like - can process it correctly. I suppose we could talk about interoperability here. And of course it seems like an a-ha moment. But these are XML fragments that were created in my system. And I think for the sake of the developer of an app - should have tweaks for efficiency aside from the content encoding de'joure (UTF8). I realize my poignancy could be harsh but this is an expensive problem for me. Each server can cost as much as $4,000 US. -- Andrew Brunner Aurawin LLC 512.574.6298 http://aurawin.com/ Aurawin is a great new place to store, share, and enjoy your photos, videos, music and more. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Is this a compiler bug ?
> -Message d'origine- > De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- > boun...@lists.freepascal.org] De la part de ik > Envoyé : jeudi 27 septembre 2012 15:05 > À : FPC developers' list > Objet : [fpc-devel] Is this a compiler bug ? > > Hello, > > While trying to compile FPC r22471: > make CROSSOPT="-O2 -g -FD/usr/share/java/" CPU_TARGET=jvm > OS_TARGET=android INSTALL_PREFIX=/usr/ FPC=/usr/bin/ppcx64 all > zipinstall > > I get the following message: > > > /home/ik/projects/foss/fpc/fpc/compiler/ppc -Ur -Xs -O2 -n -Fujvm > -Fusystems -Fu/home/ik/projects/foss/fpc/fpc/rtl/units/x86_64-linux > -Fijvm -FE. -FUjvm/units/x86_64-linux -Cg -dRELEASE -djvm -dGDB > -dBROWSERLOG -Fujvm -dNOOPT -Sew pp.pas > hlcgcpu.pas(2392,28) Warning: Constructing a class "thlcgjvm" with > abstract method "g_overflowcheck" > hlcgcpu.pas(2392,28) Warning: Constructing a class "thlcgjvm" with > abstract method "g_overflowCheck_loc" > hlcgcpu.pas(2397) Fatal: There were 2 errors compiling module, stopping > > > The Compiler display two warnings and then it report them as 2 errors. > > I'm using Free Pascal Compiler version 2.6.0 [2012/05/17] for x86_64 > that arrives with Arch-Linux > > Is this a bug of the compiler (reporting errors as warnings), a bug in > the code itself, or something else ? It is a feature of both the compiler capabilities itself and of the fact that we consider that correct code should not generate warnings. -Sew is the option that transforms any warning into an error it is a feature of the compiler that is used by default when cycling (In the sense do a 'make cycle') the compiler. For java target it is known that there are warnings left, but you can still use the Makefiles by adding ALLOW_WARNINGS=1 to the 'make cycle' command line. Pierre Muller ... who's responsible for adding -Sew to the default compiler cycling! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is this a compiler bug ?
On 27 Sep 2012, at 15:05, ik wrote: The Compiler display two warnings and then it report them as 2 errors. I'm using Free Pascal Compiler version 2.6.0 [2012/05/17] for x86_64 that arrives with Arch-Linux Is this a bug of the compiler (reporting errors as warnings), a bug in the code itself, or something else ? The compiler makefile passes the -Sew option to the compiler, which instructs it to treat all warnings as errors. As documented at http://wiki.freepascal.org/FPC_JVM/Building#Building_the_compiler_and_RTL , you currently have to pass ALLOW_WARNINGS=1 to make in order to build the jvm compiler. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Is this a compiler bug ?
Hello, While trying to compile FPC r22471: make CROSSOPT="-O2 -g -FD/usr/share/java/" CPU_TARGET=jvm OS_TARGET=android INSTALL_PREFIX=/usr/ FPC=/usr/bin/ppcx64 all zipinstall I get the following message: /home/ik/projects/foss/fpc/fpc/compiler/ppc -Ur -Xs -O2 -n -Fujvm -Fusystems -Fu/home/ik/projects/foss/fpc/fpc/rtl/units/x86_64-linux -Fijvm -FE. -FUjvm/units/x86_64-linux -Cg -dRELEASE -djvm -dGDB -dBROWSERLOG -Fujvm -dNOOPT -Sew pp.pas hlcgcpu.pas(2392,28) Warning: Constructing a class "thlcgjvm" with abstract method "g_overflowcheck" hlcgcpu.pas(2392,28) Warning: Constructing a class "thlcgjvm" with abstract method "g_overflowCheck_loc" hlcgcpu.pas(2397) Fatal: There were 2 errors compiling module, stopping The Compiler display two warnings and then it report them as 2 errors. I'm using Free Pascal Compiler version 2.6.0 [2012/05/17] for x86_64 that arrives with Arch-Linux Is this a bug of the compiler (reporting errors as warnings), a bug in the code itself, or something else ? Ido ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-26 14:36, Andrew Brunner wrote: Interoperability seems to have lost luster recently. +1 I think it should at least be professional looking. Taking a minimalist view would only bring the same complaints. Hey, minimalist is the "flavour of the month", just look at Microsoft's Metro apps and latest Visual Studio. See, I just had to wait long enough, and then my work from 7 years ago is "cool" again. ;-) In reality, I'm not a graphic artist or web designer, so I'll leave that to them. I have no problem adding more HTML hooks in the generated output though, so CSS could do an even better job with greater ease. Graeme. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-27 09:56, Marco van de Voort wrote: So having a preference is not the problem (and I prefer NNTP too), but pushing it when it is a lost cause is. So you give up that easy. Personally, I don't tend to be a lemming and always follow the "flavour of the month". G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Parser problems with C-Data and Character Encoding
Andrew Brunner hat am 26. September 2012 um 21:21 geschrieben: >[...] > If c-data contains any character whose ordinal value is greater than 127 > the XML parser raises an exception. Have you tried setting the right encoding in the xml? >[...] > Is there a ANY case where dropping c-data is OK just because a user > hasn't entered it? I'm just curious... I can't seem to find any good > reason as to why this happened other than to force UTF or some other > encoding on everyone. > > The XML parser already has options for Validation. I'm hoping to get > someone on the team to add a one line if Validation=true then check the > values else just parse it already. > > http://mantis.freepascal.org/view.php?id=22990 Sergei's note is correct: ---snip--- This is unrelated to validation. XML parser always checks that its input data conforms to the specified encoding. The XML data should either be in utf8 encoding, or in utf16 with a BOM character at the beginning, or it should be labeled with 'encoding' attribute (additionally xmliconv unit must be added to uses clause if encoding is different from iso8859-1). ---snap--- > Another thing would be to have an exception level event. There is an > event there, but still the exception is raised the event is called - > stopping the parsing and throwing a wrench in my streaming application > logic. Maybe you can explain what you are trying to do? > In a world where XML is just about the primary choice for data > transmission - I think we take speed as the ut-most priority and don't > use such a pivotal technology as a tool to get what someone else wants. AFAIK such statements have seldom a positive effect on volunteer projects. > The bottom-line inference here is that WE ALL must encode ALL DATA > before it can be streamed / parsed. That's bad news and EXPENSIVE. Well, whatever you try, you must at least encode all < > and & characters. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] XML Parser problems with C-Data and Character Encoding
From time to time I get XML parsing exceptions even though I disabled data validation. If c-data contains any character whose ordinal value is greater than 127 the XML parser raises an exception. I realize fpc's parser is not the only one with this problem. So who's infinite wisdom decided that C-Data cannot have non-keyed input!?! Is there a ANY case where dropping c-data is OK just because a user hasn't entered it? I'm just curious... I can't seem to find any good reason as to why this happened other than to force UTF or some other encoding on everyone. The XML parser already has options for Validation. I'm hoping to get someone on the team to add a one line if Validation=true then check the values else just parse it already. http://mantis.freepascal.org/view.php?id=22990 Another thing would be to have an exception level event. There is an event there, but still the exception is raised the event is called - stopping the parsing and throwing a wrench in my streaming application logic. In a world where XML is just about the primary choice for data transmission - I think we take speed as the ut-most priority and don't use such a pivotal technology as a tool to get what someone else wants. The bottom-line inference here is that WE ALL must encode ALL DATA before it can be streamed / parsed. That's bad news and EXPENSIVE. Therefore, any help would be greatly appreciated. -- Andrew Brunner Aurawin LLC 512.574.6298 http://aurawin.com/ Aurawin is a great new place to store, share, and enjoy your photos, videos, music and more. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problems with data validation in XML streams namely CDATA
There is no way to have CDATA with charaters past 127. Anyone know the
rationale?
Is there anyway to get the parser to respect Validate=false for
charaters beyond 127?
Thanks,
--
Andrew Brunner
Aurawin LLC
512.574.6298
http://aurawin.com/
Aurawin is a great new place to store, share, and enjoy your
photos, videos, music and more.
program invalid;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes, DOM, XMLRead, XMLReader;
procedure Test;
var
FParser:TDOMParser;
FDoc : TXMLDocument;
FSource : TXMLInputSource;
sData:string;
begin
FParser:=TDOMParser.Create();
Try
FParser.Options.Validate:=false;
sData:=Concat(
'',
'',
'',
''
);
// sData:=AnsiToUTF8(sData);
FSource:=TXMLInputSource.Create(sData);
Try
FParser.Parse(FSource,FDoc);
Try
finally
FDoc.Free();
end;
finally
FSource.Free();
end;
finally
FParser.Free();
end;
end;
begin
Test();
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On Sep 26, 2012, at 8:24 AM, Graeme Geldenhuys wrote: > > Why not do the best of both worlds. Setup a NNTP server, then use fpWeb (or > even plain CGI will do) to create a NNTP Web Client (aka Web Forum). Now all > based are covered - users can use the communication medium they prefer, and > fpWeb (if used) gets another nice "real world" demo. It is great when you showcase your work. Another benefit is when you adopt industry standards like nnntp. Interoperability seems to have lost luster recently. > The WebNews HTTP front-end I use for my NNTP server is a very simple (and > rather small - 1063 line of perl including code comments) Perl script. It > acts as an ordinary NNTP client (so the NNTP server doesn't know the > difference), and the HTML in generates is rather plain too. I simply > dressed-up the HTML some basic CSS, to make it that little bit prettier. I think it should at least be professional looking. Taking a minimalist view would only bring the same complaints. > Hell, I don't even mind writing the CGI NNTP Client frontend, because I have > long been wanting to replace my Perl implementation with an Object Pascal > version. Again it would be best to get a team together and do something nice rather than simple. Andrew Brunner, Aurawin LLC http://aurawin.com/ A great place to store and share your pictures, videos, and more, featuring a rich cloud social computing platform. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
In our previous episode, Martin Schreiber said: > > > > > I'm not ready yet to declare FPC/Lazarus as an oldtimers only fad. > > > > I'm afraid I don't understand your reply. > > > People who prefer NNTP over a nice and modern WEB-forum are dumb oldtimers. No. People that try to push such preferences into a central role in the modern world are somewhat outside the realities of current times. And then oldtimer is not that bad an designation. So having a preference is not the problem (and I prefer NNTP too), but pushing it when it is a lost cause is. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
Martin Schreiber wrote: I'm not ready yet to declare FPC/Lazarus as an oldtimers only fad. I'm afraid I don't understand your reply. People who prefer NNTP over a nice and modern WEB-forum are dumb oldtimers. So I am a dumb oldtimer too. I hate WEB-forums and think NNTP is the most convenient and productive discussion format for opensource projects. Noting that this discussion needs to move to fpc-other. The one advantage that web-based foramina have is that in principle at least decent message threading can be implemented. Ideally, however, any solution should be able to accept and serve messages in various forms, and I see very little wrong with a system which (a) tags messages with NNTP-like headers, (b) uses an SMTP mailing list for distribution and (c) has a central archive that people can refer to if they lose messages. In short, the existing mailing list setup is not badly broken, and probably is not where effort should be concentrated. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On 2012-09-27 08:22, Martin Schreiber wrote: I'm not ready yet to declare FPC/Lazarus as an oldtimers only fad. I'm afraid I don't understand your reply. People who prefer NNTP over a nice and modern WEB-forum are dumb oldtimers. Then that is me. :) Fine, but I did also mention a "web forum front-end" to the NNTP server. So users/developers have a choice of what they want to use. A traditional NNTP Client (desktop app) or the Web Interface (Forum interface) to the NNTP server. This is exactly what Embarcadero did too. They have loads of newsgroups, but they also knew some developers prefer web forums, so they bought such a solution and modified it to suite there needs. New postings are seen by everybody instantly - no matter if you use NNTP directly, or use the Web Interface. Now what of this did Marco not understand? Then again, I should be use to Macro's odd answers to anything I post. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On Wednesday 26 September 2012 16:02:31 Graeme Geldenhuys wrote: > On 2012-09-26 14:33, Marco van de Voort wrote: > > In our previous episode, Graeme Geldenhuys said: > >> Why not do the best of both worlds. > > > > In whose opinion? > > I thought it would have been obvious. > > > I'm not ready yet to declare FPC/Lazarus as an oldtimers only fad. > > I'm afraid I don't understand your reply. > People who prefer NNTP over a nice and modern WEB-forum are dumb oldtimers. So I am a dumb oldtimer too. I hate WEB-forums and think NNTP is the most convenient and productive discussion format for opensource projects. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
