[fpc-pascal] function param and TVarRec
Hi There, If you declare this: procedure proc(param: array of const); Then you can pass any type of varaible to param, however, only in an array, such as proc([1, 2]); Is it possible to achieve the effect of the code below (which is wrong): procedure proc(p1: const; p2: const); So that: 1) p1 and p2 is translated by the compiler to TVarRec inside the function; 2) I do not need to pass an array to the function, in another word, the number of params for the procedure is *fixed*, but the *type* of each param is not. Regards, Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 9/23/13, Martin laza...@mfriebe.de wrote: So the question is, what does or should do RomanToInt for invalid input? Probably return 0. Romans seemed to have no zero at all. It also will not break backwards compatibility, current implementatiosn returns zero if an invalid character is found (docs say otherwise though). We could also leave things as they are and have a new TryRomanToIntStrict() function added to StrUtils. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 9/23/13, Alberto Narduzzi albertonardu...@yahoo.com wrote: Are you sure regarding M considering there is no symbol for 5000? Or didn't Romans count to more than 5000 - 1? yes I am. as 5000 - 1 would need to be written CMXCIX, which has the 4-M-in-a-row, that is invalid, as a maximum of three is allowed. It's more or less common practice to allow 3 M's if you need values 3999. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
In our previous episode, Martin said: they are not ambiguous, they are simply INVALID. So the question is, what does or should do RomanToInt for invalid input? Raise an exception and have a try* version to avoid the exception, just like all other str*tonumeric functions. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 9/23/13, Alberto Narduzzi albertonardu...@yahoo.com wrote: But IsValidRoman is as good as a solution too, indeed... Trying to determine if it is valid is 90% of calculating the output. Hence my previous approach of TryRomanToInt. It returns FALSE if the string isn't a legal Roman numeral. And it is compliant with our other conversion routines like TryStrToInt etc. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] function param and TVarRec
On Tue, 24 Sep 2013, Xiangrong Fang wrote: Hi There, If you declare this: procedure proc(param: array of const); Then you can pass any type of varaible to param, however, only in an array, such as proc([1, 2]); Is it possible to achieve the effect of the code below (which is wrong): procedure proc(p1: const; p2: const); So that: 1) p1 and p2 is translated by the compiler to TVarRec inside the function; 2) I do not need to pass an array to the function, in another word, the number of params for the procedure is *fixed*, but the *type* of each param is not. Use variants: Procedure Proc (Var A,B : variant); Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 9/24/13, Marco van de Voort mar...@stack.nl wrote: Raise an exception This will break existing implementations that either expect IM to be 999, or ABC to be 0 (indicating failure), and that certainly do not expect that this function throws an exception at them. and have a try* version to avoid the exception, just like all other str*tonumeric functions. You beat me by a few minutes Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
In our previous episode, Bart said: Raise an exception This will break existing implementations that either expect IM to be 999, or ABC to be 0 (indicating failure), and that certainly do not expect that this function throws an exception at them. Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. Moreover I don't think that first attempts should fixate interfaces and behaviour forever. And let's not beat about the bush: the main reason for the routine is to show beginning programmers that their homework can be done using a fixed function :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] function param and TVarRec
Thanks, this works, sort of. But does not meet my needs, I will pass in either an int value or an object, but Variant is not compatible with TObject. Alternatively, this also does NOT work: array [0..1] of const; no matter it is a type definition or used as function parameter. This is a trivial problem, I can just go with array of const, I am just curious if pascal can do this, because it will make the function definition more strict and my code cleaner. Regards, Xiangrong 2013/9/24 Michael Van Canneyt mich...@freepascal.org On Tue, 24 Sep 2013, Xiangrong Fang wrote: Hi There, If you declare this: procedure proc(param: array of const); Then you can pass any type of varaible to param, however, only in an array, such as proc([1, 2]); Is it possible to achieve the effect of the code below (which is wrong): procedure proc(p1: const; p2: const); So that: 1) p1 and p2 is translated by the compiler to TVarRec inside the function; 2) I do not need to pass an array to the function, in another word, the number of params for the procedure is *fixed*, but the *type* of each param is not. Use variants: Procedure Proc (Var A,B : variant); Michael. __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] function param and TVarRec
On Tue, 24 Sep 2013, Xiangrong Fang wrote: Thanks, this works, sort of. But does not meet my needs, I will pass in either an int value or an object, but Variant is not compatible with TObject. You could make it so using a custom variant manager or operator overloading, but this requires additional work. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: StrUtils.RomanToInt oddities
On 24/09/2013 08:57, Bart wrote: On 9/23/13, Martin lazarus-ort+dvltiveelga04la...@public.gmane.org wrote: So the question is, what does or should do RomanToInt for invalid input? Probably return 0. Romans seemed to have no zero at all. It also will not break backwards compatibility, current implementatiosn returns zero if an invalid character is found (docs say otherwise though). Yes, I agree that returning 0 is a good solution. The docs can be changed. We could also leave things as they are and have a new TryRomanToIntStrict() function added to StrUtils. As there are no issues with compatibility that would IMO only make the solution needlessly more complex. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Socket error messages
How does one convert from the numeric value returned by SocketError to the name of the error (specifically, to e.g. EsockEINVAL rather than EsysEINVAL, i.e. to be in line with the definition of functions like fpbind)? I notice that the example for fpconnect at http://lazarus-ccr.sourceforge.net/docs/rtl/sockets/fpconnect.html actually describes a variant of Connect that's not documented for fpconnect. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 9/24/13, Marco van de Voort mar...@stack.nl wrote: And let's not beat about the bush: the main reason for the routine is to show beginning programmers that their homework can be done using a fixed function :-) LOL Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: StrUtils.RomanToInt oddities
On 24/09/2013 09:09, Marco van de Voort wrote: In our previous episode, Bart said: Raise an exception This will break existing implementations that either expect IM to be 999, or ABC to be 0 (indicating failure), and that certainly do not expect that this function throws an exception at them. Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. I would rather choose for maintaining backward compatiblity, the *de facto behaviour* (return 0 on invalid values) as it is quite sensible for this kind of numbers. Moreover I don't think that first attempts should fixate interfaces and behaviour forever. It's quite strange though that Delphi compatibility is quite insistently adhered to (BTW a good decision IMO). The function has been in FPC stable (for presumably a while?) so I would really think hard before changing it. And let's not beat about the bush: the main reason for the routine is to show beginning programmers that their homework can be done using a fixed function :-) Nice going to show beginning programmers how to break backward compatibility then ;) However, this is all just me 2c so it's up to the FPC devs to decide Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: StrUtils.RomanToInt oddities
On 23/09/2013 23:34, Alberto Narduzzi wrote: I don't believe though Romans knew negative numbers. Well, they could subtract, couldn't they :) But I'm certainly not an expert on the matter. never though about, but if the only matter is DEBT, then just write positive numbers under the DEBT column, and everybody shall be happy too, provided they know the meaning of such a column ;-) You just described an alternative indication of a negative number... only instead of a minus sign, you use column position as an indicator ;) To calculate net equity, you'd still have to subtract the debts from the possessions, i.e. deal with the debt as negative numbers. P.S. Have no clue of roman arithmetics, thou', which looks a little more weird to implement, or just to think about :-O I would be very careful in definining too many restrictions on what you accept as Roman numerals as the number of fixed rules is rather small and there are a lot of exceptions, especially in later years (i.e. Bart's example of bigger numbers). In other words, the system of Roman numerals was not fixed; it changed over time, it was mostly based on conventions that fell short of actual rules. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
2013/9/24 Reinier Olislagers reinierolislag...@gmail.com On 23/09/2013 23:34, Alberto Narduzzi wrote: I don't believe though Romans knew negative numbers. Well, they could subtract, couldn't they :) But I'm certainly not an expert on the matter. never though about, but if the only matter is DEBT, then just write positive numbers under the DEBT column, and everybody shall be happy too, provided they know the meaning of such a column ;-) You just described an alternative indication of a negative number... only instead of a minus sign, you use column position as an indicator ;) To calculate net equity, you'd still have to subtract the debts from the possessions, i.e. deal with the debt as negative numbers. Not quite. The mathematical result would be the same, but try explaining what a negative number is to a kid :-) You may have forgotten it, but there was a time when you had to be explained that a - b = a + (-b) (which is not exactly using a negative number but closely related to it). In the above example, the debt is to be subtracted, this does not automatically trigger the abstract concept of negative number in the user's mind. I even think that if the romans really had the concept of negative numbers, they would have devised a notation for it allowing them to include them in texts. Does such a notation exist? P.S. Have no clue of roman arithmetics, thou', which looks a little more weird to implement, or just to think about :-O I would be very careful in definining too many restrictions on what you accept as Roman numerals as the number of fixed rules is rather small and there are a lot of exceptions, especially in later years (i.e. Bart's example of bigger numbers). In other words, the system of Roman numerals was not fixed; it changed over time, it was mostly based on conventions that fell short of actual rules. You are probably right: see http://www.web40571.clarahost.co.uk/roman/howtheywork.htm -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
2013/9/24 Reinier Olislagers reinierolislag...@gmail.com On 24/09/2013 09:09, Marco van de Voort wrote: In our previous episode, Bart said: Raise an exception This will break existing implementations that either expect IM to be 999, or ABC to be 0 (indicating failure), and that certainly do not expect that this function throws an exception at them. Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. I would rather choose for maintaining backward compatiblity, the *de facto behaviour* (return 0 on invalid values) as it is quite sensible for this kind of numbers. Moreover I don't think that first attempts should fixate interfaces and behaviour forever. It's quite strange though that Delphi compatibility is quite insistently adhered to (BTW a good decision IMO). The function has been in FPC stable (for presumably a while?) so I would really think hard before changing it. I could not find any trace of it on the embarcadero web site. Wouldn't we be taking into account a compatibility with something which does not exist, by any chance? And let's not beat about the bush: the main reason for the routine is to show beginning programmers that their homework can be done using a fixed function :-) Nice going to show beginning programmers how to break backward compatibility then ;) Well, the alternative would be showing how to maintain buggy implementations because you don't want to break backward compatibility :-) Or it could show that sometimes rules have to be infringed. Or it could show the merits of exploring thoroughly the limits of a problem before committing code which could later place you in such a conflicting situation (I am not throwing stones to the developer who committed this function first, I have too often done the same mistake myself) -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
In our previous episode, Reinier Olislagers said: Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. I would rather choose for maintaining backward compatiblity, the *de facto behaviour* (return 0 on invalid values) as it is quite sensible for this kind of numbers. It is non-orthogonal. Moreover I don't think that first attempts should fixate interfaces and behaviour forever. It's quite strange though that Delphi compatibility is quite insistently adhered to (BTW a good decision IMO). Because that has an use. The internal FPC compatability, specially in the more fringe areas like this, service no use than fattening maillist archives IMHO. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Is it possible to know the data type of a specialized generics class?
Hi All, say, I have a class TTreeT; in the destructor of that class, is it possible to know the actual type of T? I want to do things like: generic TTreeT = class public Data: T; destructor Destroy; override; end; destructor TTree.Destroy; begin ... ... if Data is TObject then Data.Free; end; But is does not work with generic types. Regards, Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
Am 24.09.2013 11:07, schrieb Frederic Da Vitoria: 2013/9/24 Reinier Olislagers reinierolislag...@gmail.com mailto:reinierolislag...@gmail.com On 24/09/2013 09:09, Marco van de Voort wrote: In our previous episode, Bart said: Raise an exception This will break existing implementations that either expect IM to be 999, or ABC to be 0 (indicating failure), and that certainly do not expect that this function throws an exception at them. Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. I would rather choose for maintaining backward compatiblity, the *de facto behaviour* (return 0 on invalid values) as it is quite sensible for this kind of numbers. Moreover I don't think that first attempts should fixate interfaces and behaviour forever. It's quite strange though that Delphi compatibility is quite insistently adhered to (BTW a good decision IMO). The function has been in FPC stable (for presumably a while?) so I would really think hard before changing it. I could not find any trace of it on the embarcadero web site. Wouldn't we be taking into account a compatibility with something which does not exist, by any chance? When there is no Delphi-compatibility needed there is still backwards compatibility to code developed in FPC. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Socket error messages
On Tue, 24 Sep 2013, Mark Morgan Lloyd wrote: How does one convert from the numeric value returned by SocketError to the name of the error (specifically, to e.g. EsockEINVAL rather than EsysEINVAL, i.e. to be in line with the definition of functions like fpbind)? use the errors unit. (specific for unix) It has a functiun strerror() Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 24/09/2013 11:07, Frederic Da Vitoria wrote: 2013/9/24 Reinier Olislagers reinierolislag...@gmail.com mailto:reinierolislag...@gmail.com On 24/09/2013 09:09, Marco van de Voort wrote: In our previous episode, Bart said: Moreover I don't think that first attempts should fixate interfaces and behaviour forever. It's quite strange though that Delphi compatibility is quite insistently adhered to (BTW a good decision IMO). The function has been in FPC stable (for presumably a while?) so I would really think hard before changing it. I could not find any trace of it on the embarcadero web site. Wouldn't we be taking into account a compatibility with something which does not exist, by any chance? Ave Frederice ;) Just to be clear: I'm talking about backward compatibility with FPC code. I think Bart is, too. I haven't seen found any Delphi equivalent for the function either. Nice going to show beginning programmers how to break backward compatibility then ;) Well, the alternative would be showing how to maintain buggy implementations because you don't want to break backward compatibility :-) Nice one ;) .. and TBH, breaking implementations is sometimes necesary. However, see below for why I don't think the returning 0 part is buggy. Or it could show that sometimes rules have to be infringed. Or it could show the merits of exploring thoroughly the limits of a problem before committing code which could later place you in such a conflicting situation (I am not throwing stones to the developer who committed this function first, I have too often done the same mistake myself) Remember though that we're talking about choosing between: If invalid [2] input is found: 1. returning 0 - as the function already does, it's just not documented as such. 2. raising an exception like a lot of other conversion functions Keeping in mind that there is no Roman number symbol for zero [1], option 1 seems quite valid and obvious. I don't deeply care which choice is made. It's just that I don't think the additional work and possible impact on changing code outweigh the benefits. Others obviously disagree, fine ;) [1] Unless, yes, another exception, you think of Bede's use of N... [2] Ignoring the discussion about what's invalid as that has little to doe with the choice mentioned here. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it possible to know the data type of a specialized generics class?
Am 24.09.2013 11:19, schrieb Xiangrong Fang: Hi All, say, I have a class TTreeT; in the destructor of that class, is it possible to know the actual type of T? I want to do things like: generic TTreeT = class public Data: T; destructor Destroy; override; end; destructor TTree.Destroy; begin ... ... if Data is TObject then Data.Free; end; But is does not work with generic types. Short answer: No Long answer: You could try to use TypeInfo(Data) or TypeInfo(T) and use the returned PTypeInfo to find out the type... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it possible to know the data type of a specialized generics class?
Am 24.09.2013 11:25, schrieb Sven Barth: Am 24.09.2013 11:19, schrieb Xiangrong Fang: Hi All, say, I have a class TTreeT; in the destructor of that class, is it possible to know the actual type of T? I want to do things like: generic TTreeT = class public Data: T; destructor Destroy; override; end; destructor TTree.Destroy; begin ... ... if Data is TObject then Data.Free; end; But is does not work with generic types. Short answer: No Long answer: You could try to use TypeInfo(Data) or TypeInfo(T) and use the returned PTypeInfo to find out the type... But it's not a good idea as you'd still need to convert Data to a TObject (e.g. by using a cast), but that will fail if Data is something else than a pointer-like type... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 24/09/2013 11:11, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. I would rather choose for maintaining backward compatiblity, the *de facto behaviour* (return 0 on invalid values) as it is quite sensible for this kind of numbers. It is non-orthogonal. What is non-orthogonal? I'm indicating that I value backward compatiblity higher than breaking compatibility to match existing structures. I also indicate why this compatiblity is not such a bad decision in the first place. I have a bit of trouble understanding what you mean by it's non-orthogonal Moreover I don't think that first attempts should fixate interfaces and behaviour forever. It's quite strange though that Delphi compatibility is quite insistently adhered to (BTW a good decision IMO). Because that has an use. The internal FPC compatability, specially in the more fringe areas like this, service no use than fattening maillist archives IMHO. If you don't see a use for backward compatibility for existing code... let's just say I'll stop fattening maillist archives right now. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to stop a HttpApp via request?
On 23/09/13 21:03, silvioprog wrote: How do I stop the socket before finishing my application? I've been unsuccessful with that myself, and mentioned it to Michael van Canneyt. I tried everything I could thing of, and nothing worked. I was using Windows. I haven't tested under Linux or FreeBSD yet. In the mean time I switched my app to using Synapse's HTTP Server instead of the Free Pascal one. With Synapse and Indy components I can stop the HTTP Server without problems. Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to stop a HttpApp via request?
On Tue, 24 Sep 2013, Graeme Geldenhuys wrote: On 23/09/13 21:03, silvioprog wrote: How do I stop the socket before finishing my application? I've been unsuccessful with that myself, and mentioned it to Michael van Canneyt. I tried everything I could thing of, and nothing worked. I was using Windows. I haven't tested under Linux or FreeBSD yet. I am working on it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it possible to know the data type of a specialized generics class?
But it's not a good idea as you'd still need to convert Data to a TObject (e.g. by using a cast), but that will fail if Data is something else than a pointer-like type... This worked in my TTree class (destructor): if PTypeInfo(TypeInfo(Data))^.Kind = tkObject then TObject(Data).Free; I don't know in what case it will fail? I tested with a TStringTree, could you please give an example that it will fail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Socket error messages
How does one convert from the numeric value returned by SocketError to the name of the error (specifically, to e.g. EsockEINVAL rather than EsysEINVAL, i.e. to be in line with the definition of functions like fpbind)? use the errors unit. (specific for unix) It has a functiun strerror() But aren't those EsysEINVAL rather than EsockEINVAL etc.? I notice that the example for fpconnect at http://lazarus-ccr.sourceforge.net/docs/rtl/sockets/fpconnect.html actually describes a variant of Connect that's not documented for fpconnect. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Socket error messages
On Tue, 24 Sep 2013, Mark Morgan Lloyd wrote: How does one convert from the numeric value returned by SocketError to the name of the error (specifically, to e.g. EsockEINVAL rather than EsysEINVAL, i.e. to be in line with the definition of functions like fpbind)? use the errors unit. (specific for unix) It has a functiun strerror() But aren't those EsysEINVAL rather than EsockEINVAL etc.? They are the same values. Sockets existed before the unix unit. All these values are simply the POSIX error codes. (some special cases notwithstanding) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] does Advanced Record constructor automatically zero all the memory space of that record?
if not, is there a clean and easy way to initialize the entire record memory space to zeros e.g. constructor TMyRecord.Create(TheValue : Integer); begin FillChar(self, sizeof(Self), 0); Value := TheVal; end; Is there a Self variable for advanced record methods/constructors ? By the way, is there an ultimate inherited constructor Create for all advanced record types? I cannot find any info by googling, so had to ask for your help here. Thanks in advanced. Dennis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] does Advanced Record constructor automatically zero all the memory space of that record?
If in doubt, why not to use the old-school records and an init-value procedure. thanks, Dmitry On Tuesday, September 24, 2013, Dennis Poon wrote: ** if not, is there a clean and easy way to initialize the entire record memory space to zeros e.g. constructor TMyRecord.Create(TheValue : Integer); begin FillChar(self, sizeof(Self), 0); Value := TheVal; end; Is there a Self variable for advanced record methods/constructors ? By the way, is there an ultimate inherited constructor Create for all advanced record types? I cannot find any info by googling, so had to ask for your help here. Thanks in advanced. Dennis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: StrUtils.RomanToInt oddities
On 23/09/13 17:18, Bart wrote:
On 9/23/13, Lukasz Sokol el.es...@gmail.com wrote:
function TryRomanToInt(AInput:String; out AResult: integer):boolean;
var i, Len, N, Np1 : integer;
[snip]
if N = Np1 then AResult := AResult + N
else AResult := AResult - N;
end;
else // i = Len-1 = last char we just add (consider : MCM : add 1000,
Compiler doesn't like the else here. I removed the ; after the end 1 line
above.
I said below it's only mind-compiled ;)
sub 100, add 1000 = 1900)
begin
AResult := AResult + N;
end;
end; // for
// if the above, after all characters are through, has resulted in 0 or
less,
// we invalidate everything at the end (consider : CMLM, IIIM )
Result := AResult 0;
if not Result then AResult := 0;
end;
(only mind-compiled ;) tests welcome ;) )
It produces odd output though:
C:\Users\Bart\LazarusProjecten\ConsoleProjectentest
Enter Roman numeral: LL //should be illegal
TryRomanToInt('LL') - 50
StrUtils.RomanToInt('LL') = 100
Oh I see the loop needs to run from 0 to Len-1 ? it missed the last (or
first) char
Enter Roman numeral: MM
TryRomanToInt('MM') - 1050 //obviously should be 2000
But this looks like you're adding the results? Or are you reusing the
same variable ? In that case stick AResult := 0 at the top of the function
please
StrUtils.RomanToInt('MM') = 2000
Enter Roman numeral: II
TryRomanToInt('II') - 1051 // nice one!
Yeah totally added to former Aresult, and missed last char ...
StrUtils.RomanToInt('II') = 2
So, it's a little bit flawed.
:)
function TryRomanToInt(AInput:String; out AResult: integer):boolean;
var i, Len, N, Np1 : integer;
function TryRomanCharToInt(AIn: Char; out AOut: integer): boolean;
begin
case AIn of
'M' : AOut := 1000;
'D' : AOut := 500;
'C' : AOut := 100;
'L' : AOut := 50;
'X' : AOut := 10;
'V' : AOut := 5;
'I' : AOut := 1;
else
AOut := 0;
end;
Result := (AOut 0);
end;
begin
// if it looks like shameless cp, it's because it is ;)
Result := False;
AResult := 0; // here you've reused the variable passed to AResult
somewhere
AInput := UpperCase(AInput); //don't use AnsiUpperCase please
Len := Length(AInput);
if (Len = 0) then Exit;
//
i := 1;
for i := 0 to Len-1 do // which char am I actually missing here???
begin
if not TryRomanCharToInt(AInput[i], N) then
begin
AResult := -1; // invalidate everything
exit;
// writeln('Not a valid roman numeral at position ',i);
end;
if (i Len-1) then
begin
if not TryRomanCharToInt(AInput[i+1], Np1) then
begin
AResult := -1; // invalidate everithing
exit;
// writeln('Not a valid roman numeral at position ',i+1);
end;
// according to wikipedia, .
if not (((N = 100) and (Np1 100)) or // C can be placed before L or M
((N = 10) and (Np1 10) and (Np1 = 100)) or // X can be
placed before L or C
((N = 1) and (Np1 1) and (Np1 = 50))) // I can be placed
before V and X here too
then
begin
AResult := -1; // invalidate everithing: catches MDCLXVIVXLDM
exit;
// writeln('Not a valid roman numeral combination at position ',i,
' and ',i+1);
end;
if N = Np1 then AResult := AResult + N
else AResult := AResult - N;
end // i Len-1, you're right about the ;
else // i = Len-1 = last char we just add (consider : MCM : add 1000, sub
100, add 1000 = 1900)
begin // alternatively this should exit the loop maybe on the N-1th
character
AResult := AResult + N;
end;
end; // for
// if the above, after all characters are through, has resulted in 0 or less,
// we invalidate everything at the end (consider : CMLM, IIIM )
Result := AResult 0;
if not Result then AResult := 0;
end;
Anyhow, let's not focus upon what the new code should be.
The question was: is current behaviour (accepting IIMIIC etc.) a bug or not.
Bart
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it possible to know the data type of a specialized generics class?
Am 24.09.2013 11:53, schrieb Xiangrong Fang: But it's not a good idea as you'd still need to convert Data to a TObject (e.g. by using a cast), but that will fail if Data is something else than a pointer-like type... This worked in my TTree class (destructor): if PTypeInfo(TypeInfo(Data))^.Kind = tkObject then TObject(Data).Free; I don't know in what case it will fail? I tested with a TStringTree, could you please give an example that it will fail? Try something that is not a Pointer, e.g. a Shortstring, a record, or an ordinal datatype like QWord. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
Am 24.09.2013 11:27, schrieb Reinier Olislagers: On 24/09/2013 11:11, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. I would rather choose for maintaining backward compatiblity, the *de facto behaviour* (return 0 on invalid values) as it is quite sensible for this kind of numbers. It is non-orthogonal. What is non-orthogonal? I'm indicating that I value backward compatiblity higher than breaking compatibility to match existing structures. I also indicate why this compatiblity is not such a bad decision in the first place. I have a bit of trouble understanding what you mean by it's non-orthogonal Non-orthogonal means in this case that RomanToInt behaves different than e.g. StrToInt. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] does Advanced Record constructor automatically zero all the memory space of that record?
does Advanced Record constructor automatically zero all the memory space of that record? No, it does not. Neither in Delphi nor in FPC. Am 24.09.2013 12:36, schrieb Dennis Poon: if not, is there a clean and easy way to initialize the entire record memory space to zeros e.g. constructor TMyRecord.Create(TheValue : Integer); begin FillChar(self, sizeof(Self), 0); Value := TheVal; end; You can use either FillChar as you did or use Self := Default(TTest); (default is a compiler intrinsics that returns a 0 value of the type you passed in, e.g. Nil for classes, '' for strings, 0 for ordinals and for records all fields are set to 0) Is there a Self variable for advanced record methods/constructors ? Yes. By the way, is there an ultimate inherited constructor Create for all advanced record types? No. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Problems reading some of the messages from this mailing list
Sorry, Philippe, but I can't read your messages. :( Date: Mon, 23 Sep 2013 10:39:20 -0300 From: Philippe phili...@quarta.com.br Subject: Re: [fpc-pascal] Re: Problems reading some of the messages fromthis mailing list To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Message-ID: be7b9e7555bc1ffc125e004ea97a0...@quarta.com.br Content-Type: text/plain; charset=utf-8 ICAKCkkgY2hhbmdlZCB0aGUgd2VibWFpbCBjb25maWd1cmF0aW9uIHRvIE1JTUUgLyA4IGJpdHMg Li4uIEkgaG9wZSBpdApoZWxwcyEgCgpQaGlsaXBwZSAKCk9uIE1vbiwgMjMgU2VwIDIwMTMgMTU6 MDY6MDAgKzAyMDAsIEd1aWxsZXJtbwpNYXJ0w61uZXogd3JvdGU6IAoKPiBGcm9tOiAiVG9tYXMg SGFqbnkiIAo+IAo+PiBUaGF0IHNob3VsZCBub3QgYmUgYW4KaXNzdWUgYnkgaXRzZWxmLiBUaGUg bW9yZSBsaWtlbHkgcmVhc29uIGlzIHByb2JhYmx5IHVzZSBvZiA4LWJpdCBtZXNzYWdlCih1dGYt OCkgd2l0aG91dCBlbmNvZGluZyBpbiB1cy1hc2NpaSAoNy1iaXQpIGNvbXBhdGlibGUgImVudmVs b3BlIiAtCnR5cGljYWxseSBNSU1FIFF1b3RlZCBQcmludGFibGUgKGFzIGFscmVhZHkgdXNlZCBm b3IgdGhlIEhUTUwgc2VjdGlvbiwKYnV0IG5vdCBmb3IgdGhlIHBsYWluIHRleHQgdmVyc2lvbiku IFNvbWUgbWFpbCBzZXJ2ZXJzIG1heSBub3QgYWxsb3cKdGhhdCBhbmQgcmVjb2RlIHRoZSBtZXNz YWdlIGluIE1JTUUgQmFzZTY0IGVuY29kaW5nICh3aGljaCBpcyBtb3N0Cmxpa2VseSB0aGUgdGV4 dCBiZWxvdyk7IHdoaWxlIGRvaW5nIHRoYXQsIHRoZXkgc2hvdWxkIGluY2x1ZGUgdGhpcwppbmZv cm1hdGlvbiBpbiB0aGUgaGVhZGVyLCBidXQgSSBzdXNwZWN0IHRoYXQgdGhpcyBoYXNuJ3QgaGFw cGVuZWQgaW4KdGhlIGNhc2Ugb2YgR3VpbGxlcm1vICh0aGlzIGNvdWxkIGJlIGNoZWNrZWQgaWYg aGUgZm9yd2FyZHMgdGhlIHJlY2VpdmVkCm1lc3NhZ2UgaW4gYXR0YWNobWVudCAtIGRvaW5nIHRo aXMgdmlhIGZwYy1vdGhlciB3b3VsZCBiZSBtb3JlCmFwcHJvcHJpYXRlIHRoYW4gaGVyZSkuIE5l dmVydGhlbGVzcywgdGhlIHJlYWwgc29sdXRpb24gaXMgcHJvYmFibHkgZm9yClBoaWxpcHBlIHRv IGNvbmZpZ3VyZSBoaXMgZS1tYWlsIGNsaWVudCBub3QgdG8gc2VuZCA4LWJpdCBtZXNzYWdlcwp3 aXRob3V0IDctYml0ICJzYWZlIiBlbmNvZGluZykuIFRvbWFzCj4gCj4gU28gSSBjYW4ndCBkbyBh bnl0aGluZywgY2FuCkk/Cj4gCj4gVW5mb3J0dW5hdGVsbHkgdGhlcmUgYXJlIG1vcmUgdXNlcnMg dGhhdCBzZW5kcyB0aGVpciBlLW1haWwgdGhhdAp3YXksCj4gc3BlY2lhbGx5IGNoaW5lc2Ugb25l cy4KPiAKPiBUaGFua3MuCj4gR3VpbGxlcm1vICLDkXXDsW8iCk1hcnTDrW5lei4KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IGZwYy1wYXNjYWwKbWFp bGxpc3QgLSBmcGMtcGFzY2FsQGxpc3RzLmZyZWVwYXNjYWwub3JnIFsyXQo+Cmh0dHA6Ly9saXN0 cy5mcmVlcGFzY2FsLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZwYy1wYXNjYWwgWzNdCgoKCkxpbmtz OgotLS0tLS0KWzFdIG1haWx0bzpYSGFqVDAzQGhham55LmJpegpbMl0KbWFpbHRvOmZwYy1wYXNj YWxAbGlzdHMuZnJlZXBhc2NhbC5vcmcKWzNdCmh0dHA6Ly9saXN0cy5mcmVlcGFzY2FsLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ZwYy1wYXNjYWwKLS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0tLS0t LS0tLS0tLS0tCkFuIEhUTUwgYXR0YWNobWVudCB3YXMgc2NydWJiZWQuLi4KVVJMOiBodHRwOi8v bGlzdHMuZnJlZXBhc2NhbC5vcmcvbGlzdHMvZnBjLXBhc2NhbC9hdHRhY2htZW50cy8yMDEzMDky My9mYjMwNzQyNC9hdHRhY2htZW50LTAwMDEuaHRtCg== ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
Just a guess here, but I would think there have now been more posts in this thread than the total number of programs to use this function. Probably by a wide margin. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Problems reading some of the messages from this mailing list
Am 24.09.2013 13:26, schrieb Guillermo Martínez: Sorry, Philippe, but I can't read your messages. :( Could you send the complete source code of such a mail to - at best - fpc-other (additionally zipped to avoid any conversion)? So that Tomas or someone else can have a look at it. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: StrUtils.RomanToInt oddities
On 24/09/2013 13:13, Sven Barth wrote: Am 24.09.2013 11:27, schrieb Reinier Olislagers: On 24/09/2013 11:11, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. I would rather choose for maintaining backward compatiblity, the *de facto behaviour* (return 0 on invalid values) as it is quite sensible for this kind of numbers. It is non-orthogonal. What is non-orthogonal? I'm indicating that I value backward compatiblity higher than breaking compatibility to match existing structures. I also indicate why this compatiblity is not such a bad decision in the first place. I have a bit of trouble understanding what you mean by it's non-orthogonal Non-orthogonal means in this case that RomanToInt behaves different than e.g. StrToInt. Sorry, but I'd rather hear that from Marco himself. Your explanation doesn't make sense either; IMO it was sufficiently clear in the discussion that we all agree that RomanToInt's behaviour is different from many/all other conversion routines. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
Am 24.09.2013 13:47, schrieb Reinier Olislagers: On 24/09/2013 13:13, Sven Barth wrote: Am 24.09.2013 11:27, schrieb Reinier Olislagers: On 24/09/2013 11:11, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. I would rather choose for maintaining backward compatiblity, the *de facto behaviour* (return 0 on invalid values) as it is quite sensible for this kind of numbers. It is non-orthogonal. What is non-orthogonal? I'm indicating that I value backward compatiblity higher than breaking compatibility to match existing structures. I also indicate why this compatiblity is not such a bad decision in the first place. I have a bit of trouble understanding what you mean by it's non-orthogonal Non-orthogonal means in this case that RomanToInt behaves different than e.g. StrToInt. Sorry, but I'd rather hear that from Marco himself. Your explanation doesn't make sense either; IMO it was sufficiently clear in the discussion that we all agree that RomanToInt's behaviour is different from many/all other conversion routines. You want to hear it from Marco? Here: Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC happily eats wrong parameters
Hi, When calling fpc -d foo test.pas there are two mistakes: First the -d parameter is missing a value, which fpc silently ignores. And second there are two files to compile. FPC ignores that too, gives a hint, but compiles anyway. Design or bug? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC happily eats wrong parameters
On 24 Sep 2013, at 14:17, Mattias Gaertner wrote: When calling fpc -d foo test.pas there are two mistakes: First the -d parameter is missing a value, which fpc silently ignores. And second there are two files to compile. FPC ignores that too, gives a hint, but compiles anyway. Design or bug? By design, FPC gives a warning (not a hint) when two file names are specified. Accepting an empty -d parameter sounds like a bug though. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
In our previous episode, Reinier Olislagers said: facto behaviour* (return 0 on invalid values) as it is quite sensible for this kind of numbers. It is non-orthogonal. What is non-orthogonal? RomanToInt uses 0 to signal error, other xxxtoint functions throw exceptions. Because that has an use. The internal FPC compatability, specially in the more fringe areas like this, service no use than fattening maillist archives IMHO. If you don't see a use for backward compatibility for existing code... I see it only as an starting point, not as a rigid unbendable rule. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC happily eats wrong parameters
Am 24.09.2013 14:17, schrieb Mattias Gaertner: Hi, When calling fpc -d foo test.pas there are two mistakes: First the -d parameter is missing a value, which fpc silently ignores. And second there are two files to compile. FPC ignores that too, gives a hint, but compiles anyway. Design or bug? The '-d' argument is written explicitely to do something only if it has a (directly following) argument. Otherwise it does nothing. If this should be considered a bug or not is up to discussion, but the code is this way at least since the migration to SVN. That FPC warns if multiple files are supplied is by design as there is a specific warning about this. FPC will always use the last filename given as mentioned here: http://www.freepascal.org/docs-html/user/userse70.html#x182-189000C.11 Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC happily eats wrong parameters
On Tue, 24 Sep 2013 14:23:52 +0200 Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 24 Sep 2013, at 14:17, Mattias Gaertner wrote: When calling fpc -d foo test.pas there are two mistakes: First the -d parameter is missing a value, which fpc silently ignores. And second there are two files to compile. FPC ignores that too, gives a hint, but compiles anyway. Design or bug? By design, FPC gives a warning (not a hint) when two file names are specified. You are right, it is a warning. Why not an error? In what case do you need to pass two files to the compiler? Accepting an empty -d parameter sounds like a bug though. ok Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC happily eats wrong parameters
On 24 Sep 2013, at 14:34, Mattias Gaertner wrote: On Tue, 24 Sep 2013 14:23:52 +0200 Jonas Maebe jonas.ma...@elis.ugent.be wrote: By design, FPC gives a warning (not a hint) when two file names are specified. You are right, it is a warning. Why not an error? FPC used to silently ignore multiple file names, so I added a warning to remain backward compatible but make debugging such issues easier. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to stop a HttpApp via request?
2013/9/24 Graeme Geldenhuys gra...@geldenhuys.co.uk On 23/09/13 21:03, silvioprog wrote: How do I stop the socket before finishing my application? I've been unsuccessful with that myself, and mentioned it to Michael van Canneyt. I tried everything I could thing of, and nothing worked. I was using Windows. I haven't tested under Linux or FreeBSD yet. In the mean time I switched my app to using Synapse's HTTP Server instead of the Free Pascal one. With Synapse and Indy components I can stop the HTTP Server without problems. Regards, Graeme I'm using Windows too. In TcpIpComp (https://github.com/silvioprog/tcpipcomp) I had to add a property to indicate that the program was ending. This fixed the problem. -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to stop a HttpApp via request?
2013/9/24 Michael Van Canneyt mich...@freepascal.org On Tue, 24 Sep 2013, Graeme Geldenhuys wrote: On 23/09/13 21:03, silvioprog wrote: How do I stop the socket before finishing my application? I've been unsuccessful with that myself, and mentioned it to Michael van Canneyt. I tried everything I could thing of, and nothing worked. I was using Windows. I haven't tested under Linux or FreeBSD yet. I am working on it. Michael. Thanks you Michael, I'll wait for this fix. (y) -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 24/09/2013 14:11, Sven Barth wrote: Am 24.09.2013 13:47, schrieb Reinier Olislagers: On 24/09/2013 13:13, Sven Barth wrote: Am 24.09.2013 11:27, schrieb Reinier Olislagers: On 24/09/2013 11:11, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: Yes, but since the routine probably has low utilisation I choose for structuring all conversion routines all the same. I would rather choose for maintaining backward compatiblity, the *de facto behaviour* (return 0 on invalid values) as it is quite sensible for this kind of numbers. It is non-orthogonal. What is non-orthogonal? I'm indicating that I value backward compatiblity higher than breaking compatibility to match existing structures. I also indicate why this compatiblity is not such a bad decision in the first place. I have a bit of trouble understanding what you mean by it's non-orthogonal Non-orthogonal means in this case that RomanToInt behaves different than e.g. StrToInt. Sorry, but I'd rather hear that from Marco himself. Your explanation doesn't make sense either; IMO it was sufficiently clear in the discussion that we all agree that RomanToInt's behaviour is different from many/all other conversion routines. You want to hear it from Marco? Here: snip earlier quote Depends on what he meant by it and non-orthogonal, doesn't it? I had trouble believing Marco thought just repeating his point about the function not fitting in with the rest of the conversion functions would be any use - especially because we both agreed about that point. Now it seems Marco cannot appreciate that I was discussing weighing various arguments pro and con changing the function, and was just stating and maintaining a black and white position that looks extremely odd to me (backward compatibility is irrelevant). That's why I asked him what he meant. All in all, this *is* really getting useless. I'll leave this thread for what it is. I think everything that could usefully have been said has already been said. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC happily eats wrong parameters
On Tue, 24 Sep 2013 14:28:42 +0200 Sven Barth pascaldra...@googlemail.com wrote: Am 24.09.2013 14:17, schrieb Mattias Gaertner: Hi, When calling fpc -d foo test.pas there are two mistakes: First the -d parameter is missing a value, which fpc silently ignores. And second there are two files to compile. FPC ignores that too, gives a hint, but compiles anyway. Design or bug? The '-d' argument is written explicitely to do something only if it has a (directly following) argument. Otherwise it does nothing. If this should be considered a bug or not is up to discussion, but the code is this way at least since the migration to SVN. Well, maybe the word bug is too strong. It would be a nice feature, if fpc does not let the user shoot his foot this way. That FPC warns if multiple files are supplied is by design as there is a specific warning about this. FPC will always use the last filename given as mentioned here: http://www.freepascal.org/docs-html/user/userse70.html#x182-189000C.11 Yes, it is this way since at least 2000. I assumed that eventually fpc will support compiling multiple files. But I guess this will not happen, so maybe it would be better to change the warning to an error. A warning is defined as something that is probably wrong, but may be needed in some cases. Where is the need for passing files that the compiler ignores? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 24/09/2013 14:25, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: snip Because that has an use. The internal FPC compatability, specially in the more fringe areas like this, service no use than fattening maillist archives IMHO. If you don't see a use for backward compatibility for existing code... I see it only as an starting point, not as a rigid unbendable rule. _ There is just *no* way the second and the first statements can possibly match. Furthermore you ignore any nuanced response I post and just repeat some point you stated earlier. Yes, I suppose it's an exchange of views but it is not useful at all. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Problems reading some of the messages from this mailing list
On Tuesday, September 24, 2013 7:26 AM, Guillermo Martínez gmarti...@burdjia.com wrote: Sorry, Philippe, but I can't read your messages. :( Date: Mon, 23 Sep 2013 10:39:20 -0300 From: Philippe phili...@quarta.com.br Subject: Re: [fpc-pascal] Re: Problems reading some of the messages fromthis mailing list To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Message-ID: be7b9e7555bc1ffc125e004ea97a0...@quarta.com.br Content-Type: text/plain; charset=utf-8 this one, like the other(s) you have quoted, is missing the content-transfer-encoding line that states what type of encoding is used... this one, like the others, should have a header line of content-transfer-encoding: base64 to go along with the content-type header line... someone has a broken messaging application implementation... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Incompatible type for generics?
Hi Sven,
2013/9/23 Xiangrong Fang xrf...@gmail.com
Short answer: you can't. The same would happen with normal classes.
Long answer: You could add an additional method Next to your TIntTree
which returns a TIntTree and just do Result := TIntTree(inherited
Next); there.
I still have problem with this strange issue. See the demo program below:
program test;
{$mode objfpc}{$H+}
uses treap;
type
TStringMapper = class(specialize TTreapstring, string)
end;
var
sm1, sm2: TStringMapper;
n: TStringMapper.PNode;
begin
sm1 := TStringMapper.Create;
for n in sm1.Reversed do WriteLn(n^.Key); -- but NOT here
sm2 := sm1.Reversed;-- error here
end.
Why is this? Also, I found that the keyword specialize is recognized in
fpc mode, but class is only valid in objfpc mode, is that correct?
Regards,
Xiangrong
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] RTTI Attributes
I did some google searching which turned up very little so I decided to ask
my question here.
What is the current status of custom RTTI attributes in fpc trunk? Fot
those who don't understand what I am asking about, here is an example.
type
[AttrWithConstructor('Added text value!')]
TRecord = record
FField: Integer;
end;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Incompatible type for generics?
Am 24.09.2013 15:50, schrieb Xiangrong Fang:
Hi Sven,
2013/9/23 Xiangrong Fang xrf...@gmail.com mailto:xrf...@gmail.com
Short answer: you can't. The same would happen with normal
classes.
Long answer: You could add an additional method Next to your
TIntTree which returns a TIntTree and just do Result :=
TIntTree(inherited Next); there.
I still have problem with this strange issue. See the demo program
below:
program test;
{$mode objfpc}{$H+}
uses treap;
type
TStringMapper = class(specialize TTreapstring, string)
end;
var
sm1, sm2: TStringMapper;
n: TStringMapper.PNode;
begin
sm1 := TStringMapper.Create;
for n in sm1.Reversed do WriteLn(n^.Key); -- but NOT here
sm2 := sm1.Reversed;-- error here
end.
How is PNode declared? What is the exact error?
Why is this? Also, I found that the keyword specialize is
recognized in fpc mode, but class is only valid in objfpc mode, is
that correct?
specialize is used in all modes except mode Delphi for
specializations. class is available in all modes except iso, tp
and fpc, but can be enabled there using {$modeswitch class}.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RTTI Attributes
Am 24.09.2013 16:13, schrieb Anthony Walter:
I did some google searching which turned up very little so I decided
to ask my question here.
What is the current status of custom RTTI attributes in fpc trunk? Fot
those who don't understand what I am asking about, here is an example.
They are not implemented in trunk. Joost is working on them in a branch
though:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/joost/classattributes/
type
[AttrWithConstructor('Added text value!')]
TRecord = record
FField: Integer;
end;
AFAIK in that branch they are currently only supported for classes.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] does Advanced Record constructor automatically zero all the memory space of that record?
Sven Barth wrote: does Advanced Record constructor automatically zero all the memory space of that record? No, it does not. Neither in Delphi nor in FPC. Am 24.09.2013 12:36, schrieb Dennis Poon: if not, is there a clean and easy way to initialize the entire record memory space to zeros e.g. constructor TMyRecord.Create(TheValue : Integer); begin FillChar(self, sizeof(Self), 0); Value := TheVal; end; You can use either FillChar as you did or use Self := Default(TTest); (default is a compiler intrinsics that returns a 0 value of the type you passed in, e.g. Nil for classes, '' for strings, 0 for ordinals and for records all fields are set to 0) Is there a Self variable for advanced record methods/constructors ? Yes. By the way, is there an ultimate inherited constructor Create for all advanced record types? No. Regards, Sven Thanks for your help. Are the above info. available anywhere in FPC's web site that I overlooked? If not, maybe it should be added to its wiki. Dennis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] does Advanced Record constructor automatically zero all the memory space of that record?
Am 24.09.2013 16:40, schrieb Dennis Poon: Sven Barth wrote: does Advanced Record constructor automatically zero all the memory space of that record? No, it does not. Neither in Delphi nor in FPC. Am 24.09.2013 12:36, schrieb Dennis Poon: if not, is there a clean and easy way to initialize the entire record memory space to zeros e.g. constructor TMyRecord.Create(TheValue : Integer); begin FillChar(self, sizeof(Self), 0); Value := TheVal; end; You can use either FillChar as you did or use Self := Default(TTest); (default is a compiler intrinsics that returns a 0 value of the type you passed in, e.g. Nil for classes, '' for strings, 0 for ordinals and for records all fields are set to 0) Is there a Self variable for advanced record methods/constructors ? Yes. By the way, is there an ultimate inherited constructor Create for all advanced record types? No. Regards, Sven Thanks for your help. Are the above info. available anywhere in FPC's web site that I overlooked? If not, maybe it should be added to its wiki. Both points should be added to the documentation, but since they both are implemented only in trunk this is not the case yet. Default() is also mentioned here: http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#New_compiler_intrinsic_Default Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Incompatible type for generics?
2013/9/24 Sven Barth pascaldra...@googlemail.com How is PNode declared? What is the exact error? PNode is declared inside TTreap generic class, the source is here: https://github.com/xrfang/fpcollection/blob/master/src/units/treap.pas The exact error is: Error: Incompatible types: got TStringMapper.TTreap$AnsiString$AnsiString expected TStringMapper ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Incompatible type for generics?
Am 24.09.2013 17:14, schrieb Xiangrong Fang: 2013/9/24 Sven Barth pascaldra...@googlemail.com mailto:pascaldra...@googlemail.com How is PNode declared? What is the exact error? PNode is declared inside TTreap generic class, the source is here: https://github.com/xrfang/fpcollection/blob/master/src/units/treap.pas The exact error is: Error: Incompatible types: got TStringMapper.TTreap$AnsiString$AnsiString expected TStringMapper The error is exactly the same as the one in your TIntTree, because the return type of TTreapString, String.Reversed is TTreapString, String and nothing else. Thus the solution is the same as for TIntTree.Next: either none or a new Reversed function. And again: This problem would also occur with non generic classes. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Incompatible type for generics?
Am 24.09.2013 17:32, schrieb Xiangrong Fang: I know it is same but why no error on the line: for n in sm1.reversed... n is of type TStringMapper.PNode whereby PNode is declared inside TTreapString, String and thus the type is in reality a TTreapString, String. sm1.reversed returns a TTreapString, String which has an enumerator that works on a TTreapString, String.PNode. So everything is well. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Incompatible type for generics?
I know it is same but why no error on the line: for n in sm1.reversed... regards. 在 2013-9-24 下午11:23，Sven Barth pascaldra...@googlemail.com写道： Am 24.09.2013 17:14, schrieb Xiangrong Fang: 2013/9/24 Sven Barth pascaldra...@googlemail.com How is PNode declared? What is the exact error? PNode is declared inside TTreap generic class, the source is here: https://github.com/xrfang/fpcollection/blob/master/src/units/treap.pas The exact error is: Error: Incompatible types: got TStringMapper.TTreap$AnsiString$AnsiString expected TStringMapper The error is exactly the same as the one in your TIntTree, because the return type of TTreapString, String.Reversed is TTreapString, String and nothing else. Thus the solution is the same as for TIntTree.Next: either none or a new Reversed function. And again: This problem would also occur with non generic classes. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] record byte alignment
Hi There, I wonder what is the byte alignment of a NON-packed record? Is it always 4-byte, or 4-byte on 32-bit platform, 8-byte or 64-bit platform? Regards, Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: record byte alignment
2, according to the docs -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/record-byte-alignment-tp5716788p5716789.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
