Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, Michael Van Canneyt said: Ah, I don't considered those languages. At least not where any discussions about performance or efficiency apply ;_) The topic was the availability of generics. In that field, all languages are viewed. If you say so. Anyway, while I could try to create debate here (age of those languages, as confirmed by other reply, finding references about generics and generic-equivalent constructs in them), I'm not even interested enough in those languages to bother. At least not in FPC related language design context. .. or is your database layer entirely strong typed? If so, you might want to talk to Frank H. of GPC, he is afaik also strongly in favour of such approach. (and that is not meant in disrespectful way, though it is a bit a specialty IMHO) I don't know what you mean by 'strongly typed database layer', but the contents and type of each field is known. Elementary RDBMS and some level 3 normalization. No 'no sql' for me. Right. Should have said statically strong typed. Not related to RDBMS, but the lack of a generic db layer that requires runtime typing. Usually achieved by generating a lot of source with a preprocessor. Because that was my point. Runtime typing (variants, array of const, idispatch) are IMHO more dangerous and against pascal principles than generics, which are still statically and strong typed. From what I see I do realize generics generally do have a rather difficult implementation. But we didn't hold back to the massive changes of the base Delphi dialect either, so that in itself is IMHO not enough reason to njet it. Exactly, which is why the discussion was leading nowhere :-) There never was a discussion. Apparently the result was preset. You asked about my motivations, I gave them. I haven't seen anything that has relevance in FPC context. In each case, I think I have an approach which should speed things up, and still sticks to the design principles of fpImage. The only design I see in fpimage is a general effort to try to support anything at once. Nevermind the costs. And actually, back in the days, that was not a bad thing to have. I checked your code, and it throws overboard much if not all that fpImage was designed for. I'm aware that I'll probably never match what you had in speed terms, but then you made some very limiting design choices which I simply don't want in fpImage. The price of more generality is some speed loss, it is always so. I don't see the need for that. I just want to keep a handful of generic storage types very fast and seperately usable, just like we essentially have one storage type (64-bit RGBA) now. This for image manipulation. Then expand the readers/writers to optionally operate rowbased, and have a few codepath simplifications in them (e.g. try to avoid the copying of rowdata to local arrays to facilitate compression and filtering in e.g. PNG if you don't use either), so that they essentially get zero-copy possibilities. I'm thinking about png, bmp and maybe jpg here. This also has consequences for reader errorhandling, it should be possible to pass a 16-bit (e.g. RGB555) memory image to a reader, and have the reader throw an exception or terminate with errorcode if the pic to load requires something bigger. (or we need a peek approach, to first open the image and determine the format, then allocate to custom load the memory image, and only then load it). Another annoying one that should be tackled whatever choice is made, is at least being able to override the compression level in the pngwriter. It is now always clmax which is IIRC the slowest way. (and for photo data, the gains are very small and not worth that). All the rarer ones keep working on the 64-bit RGBA16 base type as it is now, pixel oriented etc. I planned to see if something could be done for them after the main restructuring. A problem that I haven't thought up a solution for is autodetection of the format to safe. There have been mantis bugs about this (iirc one by Felipe), namely if you write an image you need to set options, and if you used canvas that might not be the same options as received from the image when read (e.g. a 257th color has been used, making palette impossible) But all this is guesswork, since you don't detail the problems with my approach except that you won't use generics at work, and you haven't detailed your own more than that you plan to accelerate it (but not too much) and use delegation. And of course stick to a design philisophy that is detailed nowhere. I put that crude intentionally. Since we are not going to concur at this point, it seems you'll go ahead, but I hope that it provides an incentive to be more open with it, and have some public resources. (there is a page for fcl-image in the wiki) I would appreciate getting the really slow images if possible. If there are still bugs in bottom-up images, I'd like to hear about them
Re: [fpc-pascal] FPImage and GetDataLineStart
On Sun, 24 Apr 2011, Marco van de Voort wrote: In each case, I think I have an approach which should speed things up, and still sticks to the design principles of fpImage. The only design I see in fpimage is a general effort to try to support anything at once. Nevermind the costs. Not nevermind the costs. For example, the choice for 16 bits per channel was based on the assumption that in the future, most things will be 64-bit anyway. A complete color then fits in a register. Speculative, yes, but I haven't seen anything yet which contradicts that assumption. In fact, Moore's law guarantees it. And yes, I prefer to support everything, at the cost of speed. This is is a conscious design choice. The compiler itself uses the same philosophy, I haven't heard you complain in that case. In fact, you argue for it when people complain about the compiler speed. But equally like the compiler people, I do take speed issues to heart, and I will work on it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Sat, 23 Apr 2011, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: IMHO it is the long term solution. Anything else would be madness, or minor damage control at best. Most of the more recent or new languages I know do not have generics, What do you mean, C++,C#, Java ? No, they are old languages too. I was more thinking in terms of PHP, Ruby, Python, Javascript (and its variations). I haven't come accross generics for these languages. Yet they are widely adopted. Ah, I don't considered those languages. At least not where any discussions about performance or efficiency apply ;_) The topic was the availability of generics. In that field, all languages are viewed. It eases some cases where that strictness hurts. There are multiple solutions for such cases, e.g. in the database world, people went for variants. I have a database with over 7000 fields, another with 3000, for neither variants are used. Maybe I misunderstand your statement. The point was about that not every relaxation of the typed regime is generic based. It is about choosing the right relaxation for the right application. .. or is your database layer entirely strong typed? If so, you might want to talk to Frank H. of GPC, he is afaik also strongly in favour of such approach. (and that is not meant in disrespectful way, though it is a bit a specialty IMHO) I don't know what you mean by 'strongly typed database layer', but the contents and type of each field is known. Elementary RDBMS and some level 3 normalization. No 'no sql' for me. They are as subjective as a one person mandated ban on generics. Even long term. Exactly, which is why the discussion was leading nowhere :-) There never was a discussion. Apparently the result was preset. You asked about my motivations, I gave them. Not the healthies of principles btw. I counted in SVN btw, 20 commits for you, 17 for me in fcl-image, though several of mine will probably mostly touch makefiles and fpmake restructures. Discarding initial design (there is no trace of that in SVN for obvious reasons), here is how I made my count: home: cd fpc/packages/fcl-image/src/ home: foreach f ( *.* ) foreach? svn log $f log foreach? end home: grep '^r' log | sort | uniq | wc -l 69 home: grep '^r' log | sort | uniq | grep michael |wc -l 34 home: grep '^r' log | sort | uniq | grep marco | wc -l 14 In each case, I think I have an approach which should speed things up, and still sticks to the design principles of fpImage. I checked your code, and it throws overboard much if not all that fpImage was designed for. I'm aware that I'll probably never match what you had in speed terms, but then you made some very limiting design choices which I simply don't want in fpImage. The price of more generality is some speed loss, it is always so. I would appreciate getting the really slow images if possible. If there are still bugs in bottom-up images, I'd like to hear about them too, but they are an issue separate of the loading times issue; Probably a reader problem. As far as I know, bottom-up reading is supported for BMP. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, Michael Van Canneyt said: However when implemented using generics you can also directly use the specialized type, and have fairly quick direct access. You don't need generics for that. Any form of an array of bytes will do, since that's what it amounts to in the end anyway. But it has to figure out runtime which to use, or you need to duplicate a class for each storage type and deal with delegation overhead. I've complete understanding for the fact that generics are too early, but IMHO it is the long term solution. Anything else would be madness, or minor damage control at best. The thing will be to parametrize the needed storage formats, and then implement the reader support for them. How will you implement reader support for many memory layouts? I am not that definite in my design. But I'm willing to listen to ideas. (barring the ones relying on the use of generics) Last night, we started a fund raiser on IRC to buy you a more recent Delphi version :_-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 22.04.2011 00:31, Michael Van Canneyt wrote: But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. (BTW. The sources of the docs contain a section about this second problem, but it is commented out in the LaTeX sources) Thank you Michael (and thank you, too, Jonas) for your explanation. I'll keep an eye on this problem. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Fri, 22 Apr 2011, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: However when implemented using generics you can also directly use the specialized type, and have fairly quick direct access. You don't need generics for that. Any form of an array of bytes will do, since that's what it amounts to in the end anyway. But it has to figure out runtime which to use, or you need to duplicate a class for each storage type and deal with delegation overhead. I've complete understanding for the fact that generics are too early, but IMHO it is the long term solution. Anything else would be madness, or minor damage control at best. Most of the more recent or new languages I know do not have generics, which puts a question mark beside the 'long term' and 'madness'. One could argue that generics itself is damage control, on a language level, for the old languages to alleviate the restrictions of strict typing. Generics in FPC are a typing aid, borrowed from C++, no more, no less. This is an old discussion, which I will not repeat. So please stop using nice sounding one-liners like 'madness' and long-term solutions, damage control. They are highly subjective and therefore of no value, as they only put your beliefs against mine. The thing will be to parametrize the needed storage formats, and then implement the reader support for them. How will you implement reader support for many memory layouts? I am not that definite in my design. But I'm willing to listen to ideas. (barring the ones relying on the use of generics) Last night, we started a fund raiser on IRC to buy you a more recent Delphi version :_-) Please dispense with the dialectic tricks. fcl-image is meanwhile more long-lived than many other FPC components out there. Yes, it has a speed issue. I am aware of that since a long time and am willing to work on it. I did the bulk of the design and maintenance in the past, I'll handle this as well. So you can cooperate with me and propose solutions that I'm willing to implement and spend time on, or continue this sterile discussion about something which you know I will not accept anyway. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Am 22.04.2011 00:08, schrieb Jonas Maebe: On 21 Apr 2011, at 23:26, Sven Barth wrote: On 21.04.2011 21:45, Michael Van Canneyt wrote: Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. May I ask out of curiosity which problem you mean? The main problem with generics as they are implemented in FPC, is that they are basically macros. That means if you use a type tsomerecord in a generic implementation, and in a unit in which the generic is specialised another type with that name is visible, this other type will suddenly be used. The same goes for functions and every other identifier, because it's a token record/replay mechanism. No. The symtablestack state is restore. But this leads to other problems like overloaded operators for the current type being ignored. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Am 22.04.2011 11:18, schrieb Florian Klämpfl: Am 22.04.2011 00:08, schrieb Jonas Maebe: On 21 Apr 2011, at 23:26, Sven Barth wrote: On 21.04.2011 21:45, Michael Van Canneyt wrote: Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. May I ask out of curiosity which problem you mean? The main problem with generics as they are implemented in FPC, is that they are basically macros. That means if you use a type tsomerecord in a generic implementation, and in a unit in which the generic is specialised another type with that name is visible, this other type will suddenly be used. The same goes for functions and every other identifier, because it's a token record/replay mechanism. No. The symtablestack state is restore. But this leads to other problems like overloaded operators for the current type being ignored. See http://bugs.freepascal.org/view.php?id=15480 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Am 22.04.2011 00:31, schrieb Michael Van Canneyt: On Thu, 21 Apr 2011, Sven Barth wrote: On 21.04.2011 21:45, Michael Van Canneyt wrote: On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: You can propose whatever you want _but_ generics. Motivation? Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. May I ask out of curiosity which problem you mean? There were several. The first one seems solved (see docs, section on 'A word on scope', the local thing), compiler now gives an error (a debatable solution IMHO, but better than the crash at the time.). Second problem: The following compiles: uses ucomplex; type Generic TMyClassT = Class(TObject) Function Add(A,B : T) : T; end; Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; Type TMyIntegerClass = specialize TMyClassInteger; TMyComplexClass = specialize TMyClassComplex; end. but the following does not: - unit mya; interface type Generic TMyClassT = Class(TObject) Function Add(A,B : T) : T; end; Implementation Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; end. - and program : - program myb; uses mya, ucomplex; Type TMyIntegerClass = specialize TMyClassInteger; TMyComplexClass = specialize TMyClassComplex; end. - Results in: home: fpc -S2 myb.pp mya.pp(16,12) Error: Operator is not overloaded: complex + complex myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping Which is strange to say the least, as the per the definition/intent of generics, the code in mya should not know anything about the types that will be used when specializing. (in this case complex). As per the intent of generics the second program above should compile just as well. But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. It is correct that the second doesn't compile. To make the second compile, the overloaded operators for the complex type must be defined inside complex (which was/is? not possible). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 22.04.2011 11:23, Florian Klämpfl wrote: Am 22.04.2011 00:31, schrieb Michael Van Canneyt: On Thu, 21 Apr 2011, Sven Barth wrote: On 21.04.2011 21:45, Michael Van Canneyt wrote: On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: You can propose whatever you want _but_ generics. Motivation? Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. May I ask out of curiosity which problem you mean? There were several. The first one seems solved (see docs, section on 'A word on scope', the local thing), compiler now gives an error (a debatable solution IMHO, but better than the crash at the time.). Second problem: The following compiles: uses ucomplex; type Generic TMyClassT = Class(TObject) Function Add(A,B : T) : T; end; Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; Type TMyIntegerClass = specialize TMyClassInteger; TMyComplexClass = specialize TMyClassComplex; end. but the following does not: - unit mya; interface type Generic TMyClassT = Class(TObject) Function Add(A,B : T) : T; end; Implementation Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; end. - and program : - program myb; uses mya, ucomplex; Type TMyIntegerClass = specialize TMyClassInteger; TMyComplexClass = specialize TMyClassComplex; end. - Results in: home:fpc -S2 myb.pp mya.pp(16,12) Error: Operator is not overloaded: complex + complex myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping Which is strange to say the least, as the per the definition/intent of generics, the code in mya should not know anything about the types that will be used when specializing. (in this case complex). As per the intent of generics the second program above should compile just as well. But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. It is correct that the second doesn't compile. To make the second compile, the overloaded operators for the complex type must be defined inside complex (which was/is? not possible). It should be possible now, I didn't test it though yet. The question is: should we really restrict the overloads to operators defined inside those structures only? What if the user wants to use a class instead of a record? Or an object? And what if the operators are only defined global like the Variant ones... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Fri, 22 Apr 2011, Florian Klämpfl wrote: mya.pp(16,12) Error: Operator is not overloaded: complex + complex myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping Which is strange to say the least, as the per the definition/intent of generics, the code in mya should not know anything about the types that will be used when specializing. (in this case complex). As per the intent of generics the second program above should compile just as well. But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. It is correct that the second doesn't compile. To make the second compile, the overloaded operators for the complex type must be defined inside complex (which was/is? not possible). 1. The + is not defined 'inside' integer either. Why should it be required for a record ? What kind of strange reasoning is that ? Are we going to redesign operators for records ? (I suspect this is why it is possible to add type restrictions in the Delphi/.Net implementations) 2. If I have my own overloaded version of '+' for a record, the above means that it cannot ever be used for generics, while it will be used for all my other code. Say I define a type, and decide not to put the operators inside the record, for whatever reason. I am happily unaware of generics. Along comes an afficiniado of generics, and wants to use my type in generics, but hits the above problem. He is stuck. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Fri, 22 Apr 2011, Sven Barth wrote: It is correct that the second doesn't compile. To make the second compile, the overloaded operators for the complex type must be defined inside complex (which was/is? not possible). It should be possible now, I didn't test it though yet. The question is: should we really restrict the overloads to operators defined inside those structures only? What if the user wants to use a class instead of a record? Or an object? And what if the operators are only defined global like the Variant ones... Exactly the point I was trying to make. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Am 22.04.2011 12:06, schrieb michael.vancann...@wisa.be: On Fri, 22 Apr 2011, Florian Klämpfl wrote: mya.pp(16,12) Error: Operator is not overloaded: complex + complex myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping Which is strange to say the least, as the per the definition/intent of generics, the code in mya should not know anything about the types that will be used when specializing. (in this case complex). As per the intent of generics the second program above should compile just as well. But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. It is correct that the second doesn't compile. To make the second compile, the overloaded operators for the complex type must be defined inside complex (which was/is? not possible). 1. The + is not defined 'inside' integer either. Why should it be required for a record ? Internal types are special. What kind of strange reasoning is that ? Are we going to redesign operators for records ? For pascal like generics it might be necessary to rethink some design considerations, yes. (I suspect this is why it is possible to add type restrictions in the Delphi/.Net implementations) 2. If I have my own overloaded version of '+' for a record, the above means that it cannot ever be used for generics, while it will be used for all my other code. Say I define a type, and decide not to put the operators inside the record, for whatever reason. I am happily unaware of generics. Along comes an afficiniado of generics, and wants to use my type in generics, but hits the above problem. He is stuck. No. He can define a record helper operator. The question is simple: do we want generics behave like macros or more like .Net generics. Some hybrid approach is imo wrong. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Am 22.04.2011 11:32, schrieb Sven Barth: On 22.04.2011 11:23, Florian Klämpfl wrote: Am 22.04.2011 00:31, schrieb Michael Van Canneyt: On Thu, 21 Apr 2011, Sven Barth wrote: On 21.04.2011 21:45, Michael Van Canneyt wrote: On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: You can propose whatever you want _but_ generics. Motivation? Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. May I ask out of curiosity which problem you mean? There were several. The first one seems solved (see docs, section on 'A word on scope', the local thing), compiler now gives an error (a debatable solution IMHO, but better than the crash at the time.). Second problem: The following compiles: uses ucomplex; type Generic TMyClassT = Class(TObject) Function Add(A,B : T) : T; end; Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; Type TMyIntegerClass = specialize TMyClassInteger; TMyComplexClass = specialize TMyClassComplex; end. but the following does not: - unit mya; interface type Generic TMyClassT = Class(TObject) Function Add(A,B : T) : T; end; Implementation Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; end. - and program : - program myb; uses mya, ucomplex; Type TMyIntegerClass = specialize TMyClassInteger; TMyComplexClass = specialize TMyClassComplex; end. - Results in: home:fpc -S2 myb.pp mya.pp(16,12) Error: Operator is not overloaded: complex + complex myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping Which is strange to say the least, as the per the definition/intent of generics, the code in mya should not know anything about the types that will be used when specializing. (in this case complex). As per the intent of generics the second program above should compile just as well. But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. It is correct that the second doesn't compile. To make the second compile, the overloaded operators for the complex type must be defined inside complex (which was/is? not possible). It should be possible now, I didn't test it though yet. The question is: should we really restrict the overloads to operators defined inside those structures only? No. But during spezialication only the symbols are available: - which were available during definition of the generic - the symbols of the type parameter arguments What if the user wants to use a class instead of a record? Or an object? Those should be allowed to contain operators as well. And what if the operators are only defined global like the Variant ones... Variant might be a problem. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 22.04.2011 11:23, Florian Klämpfl wrote: Am 22.04.2011 00:31, schrieb Michael Van Canneyt: On Thu, 21 Apr 2011, Sven Barth wrote: On 21.04.2011 21:45, Michael Van Canneyt wrote: On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: You can propose whatever you want _but_ generics. Motivation? Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. May I ask out of curiosity which problem you mean? There were several. The first one seems solved (see docs, section on 'A word on scope', the local thing), compiler now gives an error (a debatable solution IMHO, but better than the crash at the time.). Second problem: The following compiles: uses ucomplex; type Generic TMyClassT = Class(TObject) Function Add(A,B : T) : T; end; Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; Type TMyIntegerClass = specialize TMyClassInteger; TMyComplexClass = specialize TMyClassComplex; end. but the following does not: - unit mya; interface type Generic TMyClassT = Class(TObject) Function Add(A,B : T) : T; end; Implementation Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; end. - and program : - program myb; uses mya, ucomplex; Type TMyIntegerClass = specialize TMyClassInteger; TMyComplexClass = specialize TMyClassComplex; end. - Results in: home:fpc -S2 myb.pp mya.pp(16,12) Error: Operator is not overloaded: complex + complex myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping Which is strange to say the least, as the per the definition/intent of generics, the code in mya should not know anything about the types that will be used when specializing. (in this case complex). As per the intent of generics the second program above should compile just as well. But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. It is correct that the second doesn't compile. To make the second compile, the overloaded operators for the complex type must be defined inside complex (which was/is? not possible). I just did a quick test: it works in 2.5.1 when the operators are defined inside the record which is used for specialisation. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 22.04.2011 12:18, Florian Klämpfl wrote: Am 22.04.2011 12:06, schrieb michael.vancann...@wisa.be: On Fri, 22 Apr 2011, Florian Klämpfl wrote: mya.pp(16,12) Error: Operator is not overloaded: complex + complex myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping Which is strange to say the least, as the per the definition/intent of generics, the code in mya should not know anything about the types that will be used when specializing. (in this case complex). As per the intent of generics the second program above should compile just as well. But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. It is correct that the second doesn't compile. To make the second compile, the overloaded operators for the complex type must be defined inside complex (which was/is? not possible). 1. The + is not defined 'inside' integer either. Why should it be required for a record ? Internal types are special. What kind of strange reasoning is that ? Are we going to redesign operators for records ? For pascal like generics it might be necessary to rethink some design considerations, yes. (I suspect this is why it is possible to add type restrictions in the Delphi/.Net implementations) 2. If I have my own overloaded version of '+' for a record, the above means that it cannot ever be used for generics, while it will be used for all my other code. Say I define a type, and decide not to put the operators inside the record, for whatever reason. I am happily unaware of generics. Along comes an afficiniado of generics, and wants to use my type in generics, but hits the above problem. He is stuck. No. He can define a record helper operator. The question is simple: do we want generics behave like macros or more like .Net generics. Some hybrid approach is imo wrong. Oh dear... I have completely forgotton about operators in record helpers in my implementation... Nevertheless I don't think this would help in the current situation. Let's assume he uses a 3rd party record that does not contain operators (only global ones) and he uses a 3rd party generic type. Let's further assume that the user can't or does not want to modify those two types. Then he can't use a record helper during the specialization, because that helper isn't available in that time like the global operators defined along side the record aren't. I must admit though that I have a really bad feeling about my above assumption when I think about my lookup code... so when I enable operators in record helpers it might even work currently by accident O.o Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 22.04.2011 12:36, Sven Barth wrote: On 22.04.2011 12:18, Florian Klämpfl wrote: Am 22.04.2011 12:06, schrieb michael.vancann...@wisa.be: On Fri, 22 Apr 2011, Florian Klämpfl wrote: mya.pp(16,12) Error: Operator is not overloaded: complex + complex myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping Which is strange to say the least, as the per the definition/intent of generics, the code in mya should not know anything about the types that will be used when specializing. (in this case complex). As per the intent of generics the second program above should compile just as well. But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. It is correct that the second doesn't compile. To make the second compile, the overloaded operators for the complex type must be defined inside complex (which was/is? not possible). 1. The + is not defined 'inside' integer either. Why should it be required for a record ? Internal types are special. What kind of strange reasoning is that ? Are we going to redesign operators for records ? For pascal like generics it might be necessary to rethink some design considerations, yes. (I suspect this is why it is possible to add type restrictions in the Delphi/.Net implementations) 2. If I have my own overloaded version of '+' for a record, the above means that it cannot ever be used for generics, while it will be used for all my other code. Say I define a type, and decide not to put the operators inside the record, for whatever reason. I am happily unaware of generics. Along comes an afficiniado of generics, and wants to use my type in generics, but hits the above problem. He is stuck. No. He can define a record helper operator. The question is simple: do we want generics behave like macros or more like .Net generics. Some hybrid approach is imo wrong. Oh dear... I have completely forgotton about operators in record helpers in my implementation... Nevertheless I don't think this would help in the current situation. Let's assume he uses a 3rd party record that does not contain operators (only global ones) and he uses a 3rd party generic type. Let's further assume that the user can't or does not want to modify those two types. Then he can't use a record helper during the specialization, because that helper isn't available in that time like the global operators defined along side the record aren't. I must admit though that I have a really bad feeling about my above assumption when I think about my lookup code... so when I enable operators in record helpers it might even work currently by accident O.o Ok... it does not work that way currently... (puh) [I tested using a normal function instead of an operator] Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, michael.vancann...@wisa.be said: class for each storage type and deal with delegation overhead. I've complete understanding for the fact that generics are too early, but IMHO it is the long term solution. Anything else would be madness, or minor damage control at best. Most of the more recent or new languages I know do not have generics, What do you mean, C++,C#, Java ? which puts a question mark beside the 'long term' and 'madness'. One could argue that generics itself is damage control, on a language level, for the old languages to alleviate the restrictions of strict typing. It eases some cases where that strictness hurts. There are multiple solutions for such cases, e.g. in the database world, people went for variants. Generics are typically for cases where the types are parameterizable. Generics in FPC are a typing aid, borrowed from C++, no more, no less. This is an old discussion, which I will not repeat. So please stop using nice sounding one-liners like 'madness' and long-term solutions, damage control. They are highly subjective and therefore of no value, as they only put your beliefs against mine. They are as subjective as a one person mandated ban on generics. Even long term. willing to work on it. I did the bulk of the design and maintenance in the past, I'll handle this as well. So you can cooperate with me and propose solutions that I'm willing to implement and spend time on, I see no workable solution at this moment. So I'll wait what you have to offer, and see if it matches my own. Otherwise I'll see if I can create some parallel bae library, but that has to wait till generics on FPC are more mature. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 22.04.2011 12:18, Florian Klämpfl wrote: Am 22.04.2011 12:06, schrieb michael.vancann...@wisa.be: On Fri, 22 Apr 2011, Florian Klämpfl wrote: mya.pp(16,12) Error: Operator is not overloaded: complex + complex myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping Which is strange to say the least, as the per the definition/intent of generics, the code in mya should not know anything about the types that will be used when specializing. (in this case complex). As per the intent of generics the second program above should compile just as well. But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. It is correct that the second doesn't compile. To make the second compile, the overloaded operators for the complex type must be defined inside complex (which was/is? not possible). 1. The + is not defined 'inside' integer either. Why should it be required for a record ? Internal types are special. What kind of strange reasoning is that ? Are we going to redesign operators for records ? For pascal like generics it might be necessary to rethink some design considerations, yes. (I suspect this is why it is possible to add type restrictions in the Delphi/.Net implementations) 2. If I have my own overloaded version of '+' for a record, the above means that it cannot ever be used for generics, while it will be used for all my other code. Say I define a type, and decide not to put the operators inside the record, for whatever reason. I am happily unaware of generics. Along comes an afficiniado of generics, and wants to use my type in generics, but hits the above problem. He is stuck. No. He can define a record helper operator. The question is simple: do we want generics behave like macros or more like .Net generics. Some hybrid approach is imo wrong. Before I forget it: Why do you think that a hybrid approach is wrong? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Am 22.04.2011 12:58, schrieb Sven Barth: No. He can define a record helper operator. The question is simple: do we want generics behave like macros or more like .Net generics. Some hybrid approach is imo wrong. Before I forget it: Why do you think that a hybrid approach is wrong? I meant a semantical hybrid approach, not technical because Users want simply rules how things work. So the rule: only symbols available during generic definition time are available during specialization is a simple rule. Every exception like: but operators are available as well are hard to understand for a user. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Am 22.04.2011 12:36, schrieb Sven Barth: Oh dear... I have completely forgotton about operators in record helpers in my implementation... That's the problem with every new language feature: the complexity of the compiler probably increases not with O(n) but something between O(n) and O(n^2). Nevertheless I don't think this would help in the current situation. Let's assume he uses a 3rd party record that does not contain operators (only global ones) and he uses a 3rd party generic type. Let's further assume that the user can't or does not want to modify those two types. Then he can't use a record helper during the specialization, because that helper isn't available in that time like the global operators defined along side the record aren't. Well, that's another semantic question: which helpers are available? What's the reason why the helper should not be available. It is part of the type? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Fri, 22 Apr 2011, Florian Klämpfl wrote: (I suspect this is why it is possible to add type restrictions in the Delphi/.Net implementations) 2. If I have my own overloaded version of '+' for a record, the above means that it cannot ever be used for generics, while it will be used for all my other code. Say I define a type, and decide not to put the operators inside the record, for whatever reason. I am happily unaware of generics. Along comes an afficiniado of generics, and wants to use my type in generics, but hits the above problem. He is stuck. No. He can define a record helper operator. Which then simply repeats what I already had ? Very efficient :-) Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Am 22.04.2011 13:32, schrieb michael.vancann...@wisa.be: On Fri, 22 Apr 2011, Florian Klämpfl wrote: (I suspect this is why it is possible to add type restrictions in the Delphi/.Net implementations) 2. If I have my own overloaded version of '+' for a record, the above means that it cannot ever be used for generics, while it will be used for all my other code. Say I define a type, and decide not to put the operators inside the record, for whatever reason. I am happily unaware of generics. Along comes an afficiniado of generics, and wants to use my type in generics, but hits the above problem. He is stuck. No. He can define a record helper operator. Which then simply repeats what I already had ? Very efficient :-) Speedwise it makes no difference. The difference is to have simple rules which symbols are defined during specialization. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Fri, 22 Apr 2011, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: class for each storage type and deal with delegation overhead. I've complete understanding for the fact that generics are too early, but IMHO it is the long term solution. Anything else would be madness, or minor damage control at best. Most of the more recent or new languages I know do not have generics, What do you mean, C++,C#, Java ? No, they are old languages too. I was more thinking in terms of PHP, Ruby, Python, Javascript (and its variations). I haven't come accross generics for these languages. Yet they are widely adopted. which puts a question mark beside the 'long term' and 'madness'. One could argue that generics itself is damage control, on a language level, for the old languages to alleviate the restrictions of strict typing. It eases some cases where that strictness hurts. There are multiple solutions for such cases, e.g. in the database world, people went for variants. I have a database with over 7000 fields, another with 3000, for neither variants are used. Maybe I misunderstand your statement. Generics are typically for cases where the types are parameterizable. Generics in FPC are a typing aid, borrowed from C++, no more, no less. This is an old discussion, which I will not repeat. So please stop using nice sounding one-liners like 'madness' and long-term solutions, damage control. They are highly subjective and therefore of no value, as they only put your beliefs against mine. They are as subjective as a one person mandated ban on generics. Even long term. Exactly, which is why the discussion was leading nowhere :-) willing to work on it. I did the bulk of the design and maintenance in the past, I'll handle this as well. So you can cooperate with me and propose solutions that I'm willing to implement and spend time on, I see no workable solution at this moment. So I'll wait what you have to offer, and see if it matches my own. Otherwise I'll see if I can create some parallel bae library, but that has to wait till generics on FPC are more mature. Fair enough. Meanwhile you can help by supplying me with a test image file that takes too long to load. I recall you said something about seconds. Since all the ones I use load in acceptible times, I'd like to see one where things go badly wrong. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Fri, 22 Apr 2011, Florian Klämpfl wrote: Am 22.04.2011 13:32, schrieb michael.vancann...@wisa.be: On Fri, 22 Apr 2011, Florian Klämpfl wrote: (I suspect this is why it is possible to add type restrictions in the Delphi/.Net implementations) 2. If I have my own overloaded version of '+' for a record, the above means that it cannot ever be used for generics, while it will be used for all my other code. Say I define a type, and decide not to put the operators inside the record, for whatever reason. I am happily unaware of generics. Along comes an afficiniado of generics, and wants to use my type in generics, but hits the above problem. He is stuck. No. He can define a record helper operator. Which then simply repeats what I already had ? Very efficient :-) Speedwise it makes no difference. The difference is to have simple rules which symbols are defined during specialization. I was not talking about speed efficiency :) I understand the problem; However, I see no logical reason why you would 'see' a helper, when specializing, and 'not see' an operator which does the same. Both identifiers (thats what they are, deep down) are in scope at the time of specialization. If you can see the one, why not the other ? There may be implementation difficulties for the operator, but then these should be solved. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Fri, 22 Apr 2011, Florian Klämpfl wrote: Am 22.04.2011 12:58, schrieb Sven Barth: No. He can define a record helper operator. The question is simple: do we want generics behave like macros or more like .Net generics. Some hybrid approach is imo wrong. Before I forget it: Why do you think that a hybrid approach is wrong? I meant a semantical hybrid approach, not technical because Users want simply rules how things work. So the rule: only symbols available during generic definition time are available during specialization is a simple rule. Every exception like: but operators are available as well are hard to understand for a user. By this rule, the helper class/operator/beast you proposed in the other mail should also not be available, because it is not known during definition. Just as a helper is 'attached' to a type, an operator is equally 'attached' to the type. Both can be attached by a third party that requires it : all that is needed to use it is that it is in your current scope. To me this means that if you allow the one, you should - logically - allow the other. (or vice versa) that this probably presents implementation difficulties, and may require reworking of operator overloading, I readily believe; I'm just considering language design at the moment. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 2011-04-22 14:47, michael.vancann...@wisa.be wrote: On Fri, 22 Apr 2011, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: class for each storage type and deal with delegation overhead. I've complete understanding for the fact that generics are too early, but IMHO it is the long term solution. Anything else would be madness, or minor damage control at best. Most of the more recent or new languages I know do not have generics, What do you mean, C++,C#, Java ? No, they are old languages too. I was more thinking in terms of PHP, Ruby, Python, Javascript (and its variations). I haven't come accross generics for these languages. Yet they are widely adopted. I don't think that either group could be caller newer: JAVA (1995): Sun Microsystems released the first public implementation as Java 1.0 in 1995 (James Gosling, Mike Sheridan, and Patrick Naughton initiated the Java language project in June 1991) C++ (~1980): It was developed by Bjarne Stroustrup starting in 1979 at Bell Labs as an enhancement to the C language and originally named C with Classes. It was renamed C++ in 1983.[3] C# (2000): By the time the .NET project was publicly announced at the July 2000 Professional Developers Conference, the language had been renamed C#, and the class libraries and ASP.NET runtime had been ported to C#. PHP (1995): PHP was originally created by Rasmus Lerdorf in 1995 JavaScript (1995): LiveScript was the official name for the language when it first shipped in beta releases of Netscape Navigator 2.0 in September 1995, but it was renamed JavaScript in a joint announcement with Sun Microsystems on December 4, 1995 Ruby (1990): Ruby originated in Japan during the mid-1990s and was first developed and designed by Yukihiro Matz Matsumoto. Python (1980-89): Python was conceived in the late 1980s [8] and its implementation was started in December 1989[9] by Guido van Rossum at CWI in the Netherlands Regards Žilvinas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 22.04.2011 16:51, Žilvinas Ledas wrote: On 2011-04-22 14:47, michael.vancann...@wisa.be wrote: On Fri, 22 Apr 2011, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: class for each storage type and deal with delegation overhead. I've complete understanding for the fact that generics are too early, but IMHO it is the long term solution. Anything else would be madness, or minor damage control at best. Most of the more recent or new languages I know do not have generics, What do you mean, C++,C#, Java ? No, they are old languages too. I was more thinking in terms of PHP, Ruby, Python, Javascript (and its variations). I haven't come accross generics for these languages. Yet they are widely adopted. I don't think that either group could be caller newer: JAVA (1995): Sun Microsystems released the first public implementation as Java 1.0 in 1995 (James Gosling, Mike Sheridan, and Patrick Naughton initiated the Java language project in June 1991) C++ (~1980): It was developed by Bjarne Stroustrup starting in 1979 at Bell Labs as an enhancement to the C language and originally named C with Classes. It was renamed C++ in 1983.[3] C# (2000): By the time the .NET project was publicly announced at the July 2000 Professional Developers Conference, the language had been renamed C#, and the class libraries and ASP.NET runtime had been ported to C#. PHP (1995): PHP was originally created by Rasmus Lerdorf in 1995 JavaScript (1995): LiveScript was the official name for the language when it first shipped in beta releases of Netscape Navigator 2.0 in September 1995, but it was renamed JavaScript in a joint announcement with Sun Microsystems on December 4, 1995 Ruby (1990): Ruby originated in Japan during the mid-1990s and was first developed and designed by Yukihiro Matz Matsumoto. Python (1980-89): Python was conceived in the late 1980s [8] and its implementation was started in December 1989[9] by Guido van Rossum at CWI in the Netherlands At least the last two were news to me O.o Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Am 22.04.2011 14:01, schrieb michael.vancann...@wisa.be: By this rule, the helper class/operator/beast you proposed in the other mail should also not be available, because it is not known during definition. Just as a helper is 'attached' to a type, an operator is equally 'attached' to the type. Both can be attached by a third party that requires it : all that is needed to use it is that it is in your current scope. IMO a helper is bound closer to a type than an operator. To me this means that if you allow the one, you should - logically - allow the other. (or vice versa) With the same reasoning, one should allow also functions taking the type as parameter. that this probably presents implementation difficulties, Implementation is imo not the problem. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Fri, 22 Apr 2011, Florian Klämpfl wrote: Am 22.04.2011 14:01, schrieb michael.vancann...@wisa.be: By this rule, the helper class/operator/beast you proposed in the other mail should also not be available, because it is not known during definition. Just as a helper is 'attached' to a type, an operator is equally 'attached' to the type. Both can be attached by a third party that requires it : all that is needed to use it is that it is in your current scope. IMO a helper is bound closer to a type than an operator. Please explain ? To my understanding, they're on exactly the same level ? (from a language feature point of view). I mean, what can be more close to a type than a := operator ? To me this means that if you allow the one, you should - logically - allow the other. (or vice versa) With the same reasoning, one should allow also functions taking the type as parameter. Functions are different, because they are not something you attach to a type. A function just happens to have one parameter (out of possibly many) of a particular type. A class helper and operator are explicitly designed for this type, enhancing it to be able to work with it. But that's beside the point: I just think that if you except one and the other not, then that does not look like a very consequent application of generics, more like patchwork instead of a well integrated language feature. I see no reason why you would prefer one language feature above another in such cases. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 2011-04-22 20:05, Michael Van Canneyt wrote: IMO a helper is bound closer to a type than an operator. Please explain ? To my understanding, they're on exactly the same level ? (from a language feature point of view). I mean, what can be more close to a type than a := operator ? From MY point of view operator is a (special) function, that takes (one/two/...) parameters and returns a result. So I would agree that helper is closer than an operator. Regards Žilvinas Ledas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Fri, 22 Apr 2011, Žilvinas Ledas wrote: On 2011-04-22 20:05, Michael Van Canneyt wrote: IMO a helper is bound closer to a type than an operator. Please explain ? To my understanding, they're on exactly the same level ? (from a language feature point of view). I mean, what can be more close to a type than a := operator ? From MY point of view operator is a (special) function, that takes (one/two/...) parameters and returns a result. So I would agree that helper is closer than an operator. I suspect it's a highly indvidual matter. What is higher or Closer, functions or operators ? I would think functions, as they are evaluated first in an expression. Others may use different metrics... The only objective way, I suppose, is to treat all constructs as on the same level. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, michael.vancann...@wisa.be said: IMHO it is the long term solution. Anything else would be madness, or minor damage control at best. Most of the more recent or new languages I know do not have generics, What do you mean, C++,C#, Java ? No, they are old languages too. I was more thinking in terms of PHP, Ruby, Python, Javascript (and its variations). I haven't come accross generics for these languages. Yet they are widely adopted. Ah, I don't considered those languages. At least not where any discussions about performance or efficiency apply ;_) So, I'm afraid I'll have to bounce the earlier request to cut the retoric back to you. It eases some cases where that strictness hurts. There are multiple solutions for such cases, e.g. in the database world, people went for variants. I have a database with over 7000 fields, another with 3000, for neither variants are used. Maybe I misunderstand your statement. The point was about that not every relaxation of the typed regime is generic based. It is about choosing the right relaxation for the right application. .. or is your database layer entirely strong typed? If so, you might want to talk to Frank H. of GPC, he is afaik also strongly in favour of such approach. (and that is not meant in disrespectful way, though it is a bit a specialty IMHO) They are as subjective as a one person mandated ban on generics. Even long term. Exactly, which is why the discussion was leading nowhere :-) There never was a discussion. Apparently the result was preset. Not the healthies of principles btw. I counted in SVN btw, 20 commits for you, 17 for me in fcl-image, though several of mine will probably mostly touch makefiles and fpmake restructures. I see no workable solution at this moment. So I'll wait what you have to offer, and see if it matches my own. (and with these principles I'm 100% positive that it won't btw. This was more the hope that it will at least match enough to use it for secondary goals and/or recycle readers and writers with relative minimal efforts) Otherwise I'll see if I can create some parallel base library, but that has to wait till generics on FPC are more mature. Where I should remark that even D/XE is borderline readiness atm. Meanwhile you can help by supplying me with a test image file that takes too long to load. I recall you said something about seconds. Since all the ones I use load in acceptible times, I'd like to see one where things go badly wrong. The next time I work on my libs, I'll do some testing and see if I can start building a lib of interesting cases. There are several bugs in mantis too btw, mostly dealing with alpha. But IIRC it was converting 4096x7000x8bpp bmps to png. I was compressing our archive of BMPs, and used imgconv to provide a baseline to test my own png writing routines (a line based simplification of the current readers/writers) with. I also have a vague recollection of some troubles with topdown images, probably 16-bit bmp grayscale, but can't remember the exact details. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Am 20.04.2011 22:20, schrieb Leonardo M. Ramé: Hi, I need to write a function that replaces TLazIntfImage by using fpImage, and I can't find an alternative to GetDataLineStart. How can I replace it?. Maybe I get your intention wrong, but TLazIntfImage is already using fpImage and it derives from a TFPCustomImage itself. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, Sven Barth said: Am 20.04.2011 22:20, schrieb Leonardo M. Ram?: Hi, I need to write a function that replaces TLazIntfImage by using fpImage, and I can't find an alternative to GetDataLineStart. How can I replace it?. Maybe I get your intention wrong, but TLazIntfImage is already using fpImage and it derives from a TFPCustomImage itself. True, but TFPCustomImage is abstact wrt memory layout and doens't provide row level access, only pixel level access. Only TFPMemoryImage adds the memory access, but IIRC only 64-bit pixels. (16-bit RGBA) While these abstractions make it easy to make fp/fcl-image somewhat complete, they are also very memory hungry and slow. IIRC I accelerated loading/saving simple 8-bit BMP images 20 to 50 times in my work code. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 21/4/2011 06:41, Marco van de Voort wrote: In our previous episode, Sven Barth said: Am 20.04.2011 22:20, schrieb Leonardo M. Ram?: Hi, I need to write a function that replaces TLazIntfImage by using fpImage, and I can't find an alternative to GetDataLineStart. How can I replace it?. Maybe I get your intention wrong, but TLazIntfImage is already using fpImage and it derives from a TFPCustomImage itself. True, but TFPCustomImage is abstact wrt memory layout and doens't provide row level access, only pixel level access. Only TFPMemoryImage adds the memory access, but IIRC only 64-bit pixels. (16-bit RGBA) While these abstractions make it easy to make fp/fcl-image somewhat complete, they are also very memory hungry and slow. Besides that there's not a uniform correlation between 16bit and 8bit. See thread http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg16506.html the Lazarus implementation does the following to convert TColor (each color channel with 8bit) to TFPColor (16bit channels): 8bit to 16bit : set low and high memory of each 16bit channel to the 8bit counterpart if 8bit Red channel is $0F the 16bit Red will be $0F0F 16bit to 8bit: get the high memory of each 16bit channel 16 16bit Red is $001F the 8bit red will be $00 IMO is just wasting memory at least in the current implementation that takes no advantage of the wider color range. Luiz IIRC I accelerated loading/saving simple 8-bit BMP images 20 to 50 times in my work code. ___ 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] FPImage and GetDataLineStart
It also annoys me, but changing would probably be a huge work. All of the image reader/writers would need to be checked... -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
--- On Thu, 4/21/11, Marco van de Voort mar...@stack.nl wrote: From: Marco van de Voort mar...@stack.nl Subject: Re: [fpc-pascal] FPImage and GetDataLineStart To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Date: Thursday, April 21, 2011, 6:41 AM In our previous episode, Sven Barth said: Am 20.04.2011 22:20, schrieb Leonardo M. Ram?: Hi, I need to write a function that replaces TLazIntfImage by using fpImage, and I can't find an alternative to GetDataLineStart. How can I replace it?. Maybe I get your intention wrong, but TLazIntfImage is already using fpImage and it derives from a TFPCustomImage itself. True, but TFPCustomImage is abstact wrt memory layout and doens't provide row level access, only pixel level access. Only TFPMemoryImage adds the memory access, but IIRC only 64-bit pixels. (16-bit RGBA) While these abstractions make it easy to make fp/fcl-image somewhat complete, they are also very memory hungry and slow. IIRC I accelerated loading/saving simple 8-bit BMP images 20 to 50 times in my work code. Do you care to share some insights about what you did to accelerate it? Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, Leonardo M. Ram? said: IIRC I accelerated loading/saving simple 8-bit BMP images 20 to 50 times in my work code. Do you care to share some insights about what you did to accelerate it? - Made it 8bpp only - introduced linebased writing. - since my images are only 32-bit aligned, just blockwrite their pixeldata in one run. - I've no backwards compatibility limitations. IOW the images are not GDI compatible, since drawing goes via opengl. For me this was all important, since writing bmps was the only non zero copy part in my image processing trajectory. I've a newer set up based on generics that uses one template for 8,16,32 bits images. It is not finished though, and uses Delphi style generics. The code is written for Delphi, but when I need it I port it to FPC too. The generic one hasn't been ported to FPC. Since all these are based on fcl-image code, they are opensourcable, but they need to be extracted and cleaned up. But I put a snapshot here: http://www.stack.nl/~marcov/bimagerelease.zip Notes: - baseimage is the 8bpp class that is in production. Bmp writing is integrated. pnghandler is a simple base class to read/write pngs. - baseimagegen is the same, but redone generic. I use it mostly for experiments, and it is NOT production use, and in Delphi generics dialect. (which FPC doesn't support yet) - pbbyte is a pointer to a one byte value that can be overindexed ( like x[2]). pbyte on Delphi 2009+ and FPC, and pchar on older Delphi's The baseimagegen was mostly proof of concept. It derives a generic class from a non generic baseclass. This allows to use the generic derived classes in performance specific code, and the general base class for cases where it matter less. The generic code has some nested types to allow processing code somewhat independant of pixel size in a way that it is still optimal. Typical code would look like this: procedure something (img :TBW8Image); // 8 bit grayscale var ppixel,ppixelend : img.reft; // pointer type always the same as the parameter expects x, y : integer; pixvalue : img.baseunit; // whatever our pixel type is. begin for y:=0 to img.imageheight-1 do begin ppixel:=img.getimagepointer(0,y); // inlinable in theory, 4-6 instructions ppixelend:=ppixel[img.imagewidth]; while (ppixelppixelend) do // 1 moving var in this loop. begin pixvalue:=ppixel^; // operate on pixvalue or use ppixel^ directly. inc(ppixel); end; end; Note that this walking of the image is independant if the image is stored topdown or not. And the general skeleton of the code (should) remain(s) working if I change the parameter from 8-bit to 16-bit. In reality, the Delphi optimizer doesn't do a absolutely great job when inlining such generalized inline methods. But even halfway is already quite optimal. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Thu, 21 Apr 2011, Leonardo M. Ramé wrote: --- On Thu, 4/21/11, Marco van de Voort mar...@stack.nl wrote: From: Marco van de Voort mar...@stack.nl Subject: Re: [fpc-pascal] FPImage and GetDataLineStart To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Date: Thursday, April 21, 2011, 6:41 AM In our previous episode, Sven Barth said: Am 20.04.2011 22:20, schrieb Leonardo M. Ram?: Hi, I need to write a function that replaces TLazIntfImage by using fpImage, and I can't find an alternative to GetDataLineStart. How can I replace it?. Maybe I get your intention wrong, but TLazIntfImage is already using fpImage and it derives from a TFPCustomImage itself. True, but TFPCustomImage is abstact wrt memory layout and doens't provide row level access, only pixel level access. Only TFPMemoryImage adds the memory access, but IIRC only 64-bit pixels. (16-bit RGBA) While these abstractions make it easy to make fp/fcl-image somewhat complete, they are also very memory hungry and slow. IIRC I accelerated loading/saving simple 8-bit BMP images 20 to 50 times in my work code. Do you care to share some insights about what you did to accelerate it? It is really very easy to accelerate it: * Create a TFPCustomImage descendant that is limited to the bit depth you need. * Do not use palette. * Implement GetPixel and SetPixel so they convert from 64-bit from/to the depth you used * Implement a GetScanLine/SetScanLine specific to your bit depth. You can now load/save the image very fast using the GetScanLine/SetScanLine, and all other FPIMage operations will work equally well. Following prior discussions on the list, I have a sample implementation ready (simple RGB, no alpha), but it is not yet committed. It's maybe 20 lines of code. I'll try and commit it tonight. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, michael.vancann...@wisa.be said: * Create a TFPCustomImage descendant that is limited to the bit depth you need. * Do not use palette. * Implement GetPixel and SetPixel so they convert from 64-bit from/to the depth you used * Implement a GetScanLine/SetScanLine specific to your bit depth. You can now load/save the image very fast using the GetScanLine/SetScanLine, and all other FPIMage operations will work equally well. This will not accelerate reading/writing at all. When writing (or any other form of streaming), there will still be a procedure call per pixel and conversion to/from 64-bit. However I've done some attempts and research to see what it would take to fix this, and within the fcl-image I've found no solution without invalidating the concept. The only sane solution (long term) is to convert fcl-image to a generic class, and make some of the aspects generic. (e.g. for a yuv422 image you need to define a record with several inline static methods and then parameterize some generic yuv class that is a descendant of a generic 8-bit storage class etc) with that record. (the generic yuv class then knows what methods to call, and are somewhat efficient due to the inlining) The fun part is that you can still implement the current way as baseline this way, and then progressively implement quicker variants. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
Marco van de Voort mar...@stack.nl hat am 21. April 2011 um 18:50 geschrieben: In our previous episode, michael.vancann...@wisa.be said: * Create a TFPCustomImage descendant that is limited to the bit depth you need. * Do not use palette. * Implement GetPixel and SetPixel so they convert from 64-bit from/to the depth you used * Implement a GetScanLine/SetScanLine specific to your bit depth. You can now load/save the image very fast using the GetScanLine/SetScanLine, and all other FPIMage operations will work equally well. This will not accelerate reading/writing at all. When writing (or any other form of streaming), there will still be a procedure call per pixel and conversion to/from 64-bit. Yes, it does, because of cache effects. I use it my programs and a 32bit per pixel fpmemoryimage is about twice as fast as a 64bit per pixel. And 24bit RGB or 8bit grayscale is even faster. However I've done some attempts and research to see what it would take to fix this, and within the fcl-image I've found no solution without invalidating the concept. The only sane solution (long term) is to convert fcl-image to a generic class, and make some of the aspects generic. (e.g. for a yuv422 image you need to define a record with several inline static methods and then parameterize some generic yuv class that is a descendant of a generic 8-bit storage class etc) with that record. (the generic yuv class then knows what methods to call, and are somewhat efficient due to the inlining) Can you give an example, how this should work? For example, how would you alter the following routine: procedure PaintSomething(img: TFPCustomImage); var x,y: integer; begin for y:=10 to img.Height-10 do for x:=10 to img.Width-10 do img.Colors[x,y]:=colRed; end; The fun part is that you can still implement the current way as baseline this way, and then progressively implement quicker variants. Note: TLazIntfImage already contains a lot of access functions for many common memory formats. Mattias___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, Mattias Gaertner said: GetScanLine/SetScanLine, and all other FPIMage operations will work equally well. This will not accelerate reading/writing at all. When writing (or any other form of streaming), there will still be a procedure call per pixel and conversion to/from 64-bit.? Yes, it does, because of cache effects. If you declare your class as e.g. TBW32image (RGBA), a pixel assignment is an inline handful of instructions. I think fcl-image with its no-compromise format support was great initial effort. But it is time to at least allow some internal shortcuts for performance's sake. And generics allow a way to put this into a class hierarchy without too much code duplication. You can propose whatever you want _but_ generics. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: * Create a TFPCustomImage descendant that is limited to the bit depth you need. * Do not use palette. * Implement GetPixel and SetPixel so they convert from 64-bit from/to the depth you used * Implement a GetScanLine/SetScanLine specific to your bit depth. You can now load/save the image very fast using the GetScanLine/SetScanLine, and all other FPIMage operations will work equally well. This will not accelerate reading/writing at all. When writing (or any other form of streaming), there will still be a procedure call per pixel and conversion to/from 64-bit. Obviously not if you use the standard reader classes. But if the data is available as scanlines: definitely. That was the implicit assumption. There is no generic way to solve this problem, because you'd need a matrix covering all possible storage memory formats and all possible disk storage formats. The best we can do is create a memory class with some pre-defined memory storages, with appropriate getscanline/setscanline routines and make sure the reader classes can a) detect them b) make use of them if they find one matching the file storage format. c) fall back on the current mechanism if no fitting format is found. If well-chosen, this approach should cover most cases. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, Michael Van Canneyt said: There is no generic way to solve this problem, because you'd need a matrix covering all possible storage memory formats and all possible disk storage formats. Probably. The point is more that mostly only the diagonal of that matrix (dumping the existing memory format to disk) is worth accelerating. IOW the whole point is to make exceptions for a few often used cases. The best we can do is create a memory class with some pre-defined memory storages, with appropriate getscanline/setscanline routines and make sure the reader classes can a) detect them b) make use of them if they find one matching the file storage format. c) fall back on the current mechanism if no fitting format is found. If well-chosen, this approach should cover most cases. Something like that yes. Still duplication for the various formats though. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, Michael Van Canneyt said: If you declare your class as e.g. TBW32image (RGBA), a pixel assignment is an inline handful of instructions. I think fcl-image with its no-compromise format support was great initial effort. But it is time to at least allow some internal shortcuts for performance's sake. And generics allow a way to put this into a class hierarchy without too much code duplication. You can propose whatever you want _but_ generics. Motivation? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: If you declare your class as e.g. TBW32image (RGBA), a pixel assignment is an inline handful of instructions. I think fcl-image with its no-compromise format support was great initial effort. But it is time to at least allow some internal shortcuts for performance's sake. And generics allow a way to put this into a class hierarchy without too much code duplication. You can propose whatever you want _but_ generics. Motivation? Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. b) It's demonstratibly slower than optimized classes. (see the whole debate on core when it was started. The problem is not an optimizer one, but the need to revert to slower but more general programming techniques when using generics) Since the idea is to make things faster, generics are a poor choice. c) I want my own code to be 100% generics-free, and I happen to use fp-image a lot. But if you want to write generics-based image handling classes, feel free to put them in fcl-stl, just not in fp-image. I'll be glad to make some reasonable changes to the base classes to make this possible. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: There is no generic way to solve this problem, because you'd need a matrix covering all possible storage memory formats and all possible disk storage formats. Probably. The point is more that mostly only the diagonal of that matrix (dumping the existing memory format to disk) is worth accelerating. I don't understand, that precludes any line-based storage format like BMP, XPM ? IOW the whole point is to make exceptions for a few often used cases. Yes. I suspect the lazarus people would be very happy to have TColor support included... (well, I hope they will be ;) ) The best we can do is create a memory class with some pre-defined memory storages, with appropriate getscanline/setscanline routines and make sure the reader classes can a) detect them b) make use of them if they find one matching the file storage format. c) fall back on the current mechanism if no fitting format is found. If well-chosen, this approach should cover most cases. Something like that yes. Still duplication for the various formats though. I don't see where the duplication comes in. There may be duplication in your classes (I don't know, but I suspect it is the reason you switched to generics, to save typing), but with the right delegation classes I think there is no need for duplication... The thing will be to parametrize the needed storage formats, and then implement the reader support for them. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, Michael Van Canneyt said: You can propose whatever you want _but_ generics. Motivation? Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. b) It's demonstratibly slower than optimized classes. (see the whole debate on core when it was started. The problem is not an optimizer one, but the need to revert to slower but more general programming techniques when using generics) Since the idea is to make things faster, generics are a poor choice. c) I want my own code to be 100% generics-free, and I happen to use fp-image a lot. But if you want to write generics-based image handling classes, feel free to put them in fcl-stl, just not in fp-image. I'll be glad to make some reasonable changes to the base classes to make this possible. I give you a. To be honest it is still a bit too early for Delphi even. But I don't assume a fully optimized FCL-image is something short term anyway. I don't understand what you mean with b at all. Sure generics is a typed system, and if you focus on the birds-eye of view it is all as fast. (*) The remark about stuffing generics in STL is something that doesn't make sense. Generics are useless when not used. As for c, for me it is totally the opposite. Without some thorough speedup, fcl-image is totally unusuable for my purposes, even on the fringes. So for me such things are totally ununderstandable. If you depend on this so much, and with fcl-image having be pretty much static for the last decade, you simply take a copy for own use ? (*) imgconv takes _seconds_ to do some conversions that coded out in even straight forward pascal take several ms at worst. I can understand some generalising making stuff a bit slower, but a factor 1000 is limiting for a lot of uses, and unnecessary stressing the system for the rest. I hope it is clear I'm not talking about one or two instructions in a loop somewhere here, but magnitudes, magnitudes more. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
In our previous episode, Michael Van Canneyt said: The best we can do is create a memory class with some pre-defined memory storages, with appropriate getscanline/setscanline routines and make sure the reader classes can a) detect them b) make use of them if they find one matching the file storage format. c) fall back on the current mechanism if no fitting format is found. If well-chosen, this approach should cover most cases. Something like that yes. Still duplication for the various formats though. I don't see where the duplication comes in. It allows to address multiple points in the imagesize vs reader/writer class matrix (that you described) in one source. There may be duplication in your classes (I don't know, but I suspect it is delegation classes I think there is no need for duplication... Basically I use delegation for the slow case, where you operate on the base type. However when implemented using generics you can also directly use the specialized type, and have fairly quick direct access. The thing will be to parametrize the needed storage formats, and then implement the reader support for them. How will you implement reader support for many memory layouts? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 21.04.2011 21:45, Michael Van Canneyt wrote: On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: You can propose whatever you want _but_ generics. Motivation? Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. May I ask out of curiosity which problem you mean? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: The best we can do is create a memory class with some pre-defined memory storages, with appropriate getscanline/setscanline routines and make sure the reader classes can a) detect them b) make use of them if they find one matching the file storage format. c) fall back on the current mechanism if no fitting format is found. If well-chosen, this approach should cover most cases. Something like that yes. Still duplication for the various formats though. I don't see where the duplication comes in. It allows to address multiple points in the imagesize vs reader/writer class matrix (that you described) in one source. There may be duplication in your classes (I don't know, but I suspect it is delegation classes I think there is no need for duplication... Basically I use delegation for the slow case, where you operate on the base type. However when implemented using generics you can also directly use the specialized type, and have fairly quick direct access. You don't need generics for that. Any form of an array of bytes will do, since that's what it amounts to in the end anyway. The thing will be to parametrize the needed storage formats, and then implement the reader support for them. How will you implement reader support for many memory layouts? I am not that definite in my design. But I'm willing to listen to ideas. (barring the ones relying on the use of generics) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On 21 Apr 2011, at 23:26, Sven Barth wrote: On 21.04.2011 21:45, Michael Van Canneyt wrote: Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. May I ask out of curiosity which problem you mean? The main problem with generics as they are implemented in FPC, is that they are basically macros. That means if you use a type tsomerecord in a generic implementation, and in a unit in which the generic is specialised another type with that name is visible, this other type will suddenly be used. The same goes for functions and every other identifier, because it's a token record/replay mechanism. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and GetDataLineStart
On Thu, 21 Apr 2011, Sven Barth wrote: On 21.04.2011 21:45, Michael Van Canneyt wrote: On Thu, 21 Apr 2011, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: You can propose whatever you want _but_ generics. Motivation? Threefold: a) The compiler's handling of generics is still beta code in my opinion. As far as I know, the original problem I reported when writing the docs for them is still not solved. May I ask out of curiosity which problem you mean? There were several. The first one seems solved (see docs, section on 'A word on scope', the local thing), compiler now gives an error (a debatable solution IMHO, but better than the crash at the time.). Second problem: The following compiles: uses ucomplex; type Generic TMyClassT = Class(TObject) Function Add(A,B : T) : T; end; Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; Type TMyIntegerClass = specialize TMyClassInteger; TMyComplexClass = specialize TMyClassComplex; end. but the following does not: - unit mya; interface type Generic TMyClassT = Class(TObject) Function Add(A,B : T) : T; end; Implementation Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; end. - and program : - program myb; uses mya, ucomplex; Type TMyIntegerClass = specialize TMyClassInteger; TMyComplexClass = specialize TMyClassComplex; end. - Results in: home: fpc -S2 myb.pp mya.pp(16,12) Error: Operator is not overloaded: complex + complex myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping Which is strange to say the least, as the per the definition/intent of generics, the code in mya should not know anything about the types that will be used when specializing. (in this case complex). As per the intent of generics the second program above should compile just as well. But then different rules will apply for operators and procedure calls: - procedure calls must be resolvable at define time - Operators must be resolvable at specialization time. No principal problem (we can define it so), but strange at least. (BTW. The sources of the docs contain a section about this second problem, but it is commented out in the LaTeX sources) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPImage and GetDataLineStart
Hi, I need to write a function that replaces TLazIntfImage by using fpImage, and I can't find an alternative to GetDataLineStart. How can I replace it?. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
