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 TMyClass = Class(TObject) > Function Add(A,B : T) : T; > end; > > > Function TMyClass.Add(A,B : T) : T; > > begin > Result:=A+B; > end; > > > Type > TMyIntegerClass = specialize TMyClass; > TMyComplexClass = specialize TMyClass; > > end. > > but the following does not: > > - > unit mya; > > interface > > type > Generic TMyClass = 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 TMyClass; > TMyComplexClass = specialize TMyClass; > > 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:19, Florian Klämpfl wrote: 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 Ok, thanks. What about the folling idea (this might not sound ideal yet, but it's a first idea - at least for me ^^): * scan all symtables for operators for the types that are used for specialisation * add these operators to a temporary symtable * insert this symtable into the restored stack (currently I don't know the best location to put it in though) * free the temporary symtable (without freeing the operator symbols of course) when the stack is reset 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 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 TMyClass = Class(TObject) Function Add(A,B : T) : T; end; Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; Type TMyIntegerClass = specialize TMyClass; TMyComplexClass = specialize TMyClass; end. but the following does not: - unit mya; interface type Generic TMyClass = 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 TMyClass; TMyComplexClass = specialize TMyClass; 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 TMyClass = Class(TObject) >>> Function Add(A,B : T) : T; >>>end; >>> >>> >>> Function TMyClass.Add(A,B : T) : T; >>> >>> begin >>>Result:=A+B; >>> end; >>> >>> >>> Type >>>TMyIntegerClass = specialize TMyClass; >>>TMyComplexClass = specialize TMyClass; >>> >>> end. >>> >>> but the following does not: >>> >>> - >>> unit mya; >>> >>> interface >>> >>> type >>>Generic TMyClass = 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 TMyClass; >>>TMyComplexClass = specialize TMyClass; >>> >>> 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 TMyClass = Class(TObject) Function Add(A,B : T) : T; end; Function TMyClass.Add(A,B : T) : T; begin Result:=A+B; end; Type TMyIntegerClass = specialize TMyClass; TMyComplexClass = specialize TMyClass; end. but the following does not: - unit mya; interface type Generic TMyClass = 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 TMyClass; TMyComplexClass = specialize TMyClass; 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
[fpc-pascal] [HOW TO] Create a shared object (SO) with FP
{$linklib c}
uses
dynlibs;
procedure hello(const x: double); cdecl; external 'libmylib.so';
var
lHandle: TLibHandle;
v: double;
begin
lHandle := LoadLibrary('./libmylib.so');
if lHandle <> nilHandle then
begin
v := 3.14159;
hello(v);
end else
writeln('Cannot load "mylib.so"')
end.
It is compiled without error but when I run it it throws:
./testlib: error while loading shared libraries: libmylib.so: cannot
open shared object file: No such file or directory.
What I did I miss?.
Thank you.
--
Jilani KHALDI
** Architectura Vindex
http://www.vindexa.org
___
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] [HOW TO] Create a shared object (SO) with FP
On Fri, Apr 22, 2011 at 19:31, Jilani Khaldi wrote:
> {$linklib c}
>
> uses
> dynlibs;
>
> procedure hello(const x: double); cdecl; external 'libmylib.so';
>
> var
> lHandle: TLibHandle;
> v: double;
> begin
> lHandle := LoadLibrary('./libmylib.so');
> if lHandle <> nilHandle then
> begin
>v := 3.14159;
>hello(v);
> end else
>writeln('Cannot load "mylib.so"')
> end.
>
> It is compiled without error but when I run it it throws:
> ./testlib: error while loading shared libraries: libmylib.so: cannot open
> shared object file: No such file or directory.
>
> What I did I miss?.
>
You do not have the library path on the system LD_LIBRARY_PATH variable or
at the ldconfig path.
BTW, why don't you load it dynamically instead of statically if you are
going the next mile to test it.
Your program will not be executed if the library is not found either way...
> Thank you.
>
> --
> Jilani KHALDI
> ** Architectura Vindex
> http://www.vindexa.org
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
Ido
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [HOW TO] Create a shared object (SO) with FP
You do not have the library path on the system LD_LIBRARY_PATH variable or at the ldconfig path. I have set it manually and it works. How to set it inside "fpc.cfg" file? BTW, why don't you load it dynamically instead of statically if you are going the next mile to test it. How to do this? Thanks! -- Jilani KHALDI - ** Architectura Vindex http://www.vindexa.org ___ 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] [HOW TO] Create a shared object (SO) with FP
On 22.04.2011 18:31, Jilani Khaldi wrote:
{$linklib c}
uses
dynlibs;
procedure hello(const x: double); cdecl; external 'libmylib.so';
var
lHandle: TLibHandle;
v: double;
begin
lHandle := LoadLibrary('./libmylib.so');
if lHandle <> nilHandle then
begin
v := 3.14159;
hello(v);
end else
writeln('Cannot load "mylib.so"')
end.
You are mixing two different approaches here:
By using "external 'libmylib.so'" you tell the compiler to link the
library at compiletime, so you can call "hello" without the "LoadLibrary".
For using LoadLibrary you need to follow a different approach:
===source begin===
type
THelloProc = procedure(const x: Double); cdecl;
var
hello: THelloProc;
lHandle: TLibHandle;
begin
lHandle := LoadLibrary('./libmylib.so');
if lHandle <> NilHandle then begin
hello := THelloProc(GetProcAddress(lHandle, 'hello'));
if not Assigned(hello) then
Writeln('Cannot find ''hello'' function')
else
hello(3.14159);
end else
Writeln('Cannot load ''mylib.so''');
end.
===source end===
It is compiled without error but when I run it it throws:
./testlib: error while loading shared libraries: libmylib.so: cannot
open shared object file: No such file or directory.
It might not be the LoadLibrary that fails, but the statically linked
function. You need to add the path to your LD_LIBRARY_PATH and (to
answer your second mail) no, you can't add this to fpc.cfg, because this
is not a problem of the compiler, but of the runtime/the operating
system. A linux system searches by default only in the directories that
are mentioned in LD_LIBRARY_PATH for libraries.
What I did I miss?.
Thank you.
Btw: You don't need to include "linklib c".
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: > >>> 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] [HOW TO] Create a shared object (SO) with FP
On 22/04/2011 22.36, Sven Barth wrote:
On 22.04.2011 18:31, Jilani Khaldi wrote:
{$linklib c}
uses
dynlibs;
procedure hello(const x: double); cdecl; external 'libmylib.so';
var
lHandle: TLibHandle;
v: double;
begin
lHandle := LoadLibrary('./libmylib.so');
if lHandle <> nilHandle then
begin
v := 3.14159;
hello(v);
end else
writeln('Cannot load "mylib.so"')
That's ok. It works now as expected.
Thank you :-)
--
Jilani KHALDI
-
** Architectura Vindex
http://www.vindexa.org
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
