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

Leonardo M. Ramé wrote

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

In our previous episode, Sven Barth said:

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.

Besides that there's not a uniform correlation between 16bit and 8bit. See thread

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

It also annoys me, but changing would probably be a huge work. All of the image reader/writers would need to be checked...

Do you care to share some insights about what you did to accelerate it?

Leonardo M. Ramé
http://leonardorame.blogspot.com

In our previous episode, Leonardo M. Ram? said:

- 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 (ppixel<ppixelend) 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.

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.

Thanks Michael and Marco, now I have a *more* clever idea of how to do it.

Leonardo M. Ramé
http://leonardorame.blogspot.com

In our previous episode, said:

This will not accelerate 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.

Marco van de Voort hat am 21. April 2011 um 18:50 geschrieben:

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.
 

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

In our previous episode, Mattias Gaertner said:

Throw away an euro, gain 2 cents.

It is pixel level access, so it won't be optimized. Which is exactly the problem, since currently fcl-image doesn't provide anything but pixel level access.

If I went theoretical, the only advantage is that img could be a generic derivate that implements the exact yuv422 storage class which would have the rgb to yuv conversion inlined for the exact yuv and rgb types. So you would keep the virtual call, but the code in it would be generated for the specific tcolor32 (Tcolor64?) to yuv422 conversion.

HOWEVER, if your procedure actually named the specific type, it would be a lot faster. So if you only generate say RGBA 32-bit images, the above code would _NOT_ call any procedure, since the whole shebang would be inlinable, and in ideal cases could get pretty close to ideal due to cse or hoisting of invariants.

STILL that is not the objective. The main objective is to allow fast line based access using the native types for the "easy" types.

1) providing several speedy base storage sizes (8,16,32,64 bit maybe 24 too) without duplicating code.

2) provide row access for these basic types. Yes, I know. It doesn't exactly provide for 12-bit packed access, which means such types would still follow the slow "generic" way by mapping those to 64bpp.

> 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.

I know. But see above generics class. It is 500 lines, and provides the pretty much same without case statements, virtual procedures, nothing.

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.

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.

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.

Something like that yes. Still duplication for the various formats though.

In our previous episode, Michael Van Canneyt said:

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.

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 ;) )

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.

In our previous episode, Michael Van Canneyt said:

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 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 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.

In our previous episode, Michael Van Canneyt said:

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?

May I ask out of curiosity which problem you mean?

Regards,
Sven

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.

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

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<T> = 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<Integer>;
   TMyComplexClass = specialize TMyClass<Complex>;
end.

but the following does not:

---------------------------------------------------------
unit mya;
interface
type
   Generic TMyClass<T> = 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<Integer>;
   TMyComplexClass = specialize TMyClass<Complex>;
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.

In our previous episode, Michael Van Canneyt said:

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.

Last night, we started a fund raiser on IRC to buy you a more recent Delphi version :_-)

Thank you Michael (and thank you, too, Jonas) for your explanation.

I'll keep an eye on this problem.

Regards,
Sven

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.

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.

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

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).

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

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

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.

Exactly the point I was trying to make.

Michael.

Am 22.04.2011 12:06, schrieb

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.

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.

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.

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

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

Ok... it does not work that way currently... (puh) [I tested using a normal function instead of an operator]

Regards,
Sven

Before I forget it: Why do you think that a hybrid approach is wrong?

Regards,
Sven

In our previous episode, said:

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.

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.

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.

Sven Barth wrote

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).

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?

Which then simply repeats what I already had ?
Very efficient :-)

Michael.

Am 22.04.2011 13:32, schrieb

Speedwise it makes no difference. The difference is to have simple rules which symbols are defined during specialization.

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 have a database with over 7000 fields, another with 3000, for neither variants are used. Maybe I misunderstand your statement.

Exactly, which is why the discussion was leading nowhere :-)

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.

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.

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.

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

At least the last two were news to me O.o

Regards,
Sven

Am 22.04.2011 14:01, schrieb

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.

{$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.

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 ?

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.

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

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...

Ido

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!

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.

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

In our previous episode, said:

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.

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.

That's ok. It works now as expected.
Thank you :-)

The topic was the availability of generics.
In that field, all languages are viewed.

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.

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.

In our previous episode, Michael Van Canneyt said:

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.

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.

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 the costs.

And actually, back in the days, that was not a bad thing to have.

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)

It's a while ago (early last summer), and a bit in fall when XE came out. But soon I'll be picking this up again.

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.