On Sat, 23 Apr 2011, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
IMHO it is the long term solution. Anything else would be madness, or minor
damage control at best.
Most of the more "recent" or "new" languages I know do not have generics,
What do you mean, C++,C#, Java ?
No, they are "old" languages too. I was more thinking in terms of
PHP, Ruby, Python, Javascript (and its variations). I haven't come
accross generics for these languages. Yet they are widely adopted.
Ah, I don't considered those languages. At least not where any discussions
about performance or efficiency apply ;_)
The topic was the availability of generics.
In that field, all languages are viewed.
It eases some cases where that strictness hurts. There are multiple
solutions for such cases, e.g. in the database world, people went for
variants.
I have a database with over 7000 fields, another with 3000, for neither
variants are used. Maybe I misunderstand your statement.
The point was about that not every relaxation of the typed regime is generic
based. It is about choosing the right relaxation for the right application.
.. or is your database layer entirely strong typed? If so, you might want to
talk to Frank H. of GPC, he is afaik also strongly in favour of such
approach. (and that is not meant in disrespectful way, though it is a bit a
specialty IMHO)
I don't know what you mean by 'strongly typed database layer', but the contents
and type of each field is known. Elementary RDBMS and some level 3 normalization.
No 'no sql' for me.
They are as subjective as a one person mandated ban on generics. Even long
term.
Exactly, which is why the discussion was leading nowhere :-)
There never was a discussion. Apparently the result was preset.
You asked about my motivations, I gave them.
Not the healthies of principles btw. I counted in SVN btw, 20 commits for you,
17
for me in fcl-image, though several of mine will probably mostly touch makefiles
and fpmake restructures.
Discarding initial design (there is no trace of that in SVN for obvious
reasons),
here is how I made my count:
home: >cd fpc/packages/fcl-image/src/
home: >foreach f ( *.* )
foreach? svn log $f >>log
foreach? end
home: >grep '^r' log | sort | uniq | wc -l
69
home: >grep '^r' log | sort | uniq | grep michael |wc -l
34
home: >grep '^r' log | sort | uniq | grep marco | wc -l
14
In each case, I think I have an approach which should speed things up, and still
sticks to the design principles of fpImage.
I checked your code, and it throws overboard much if not all that fpImage was designed
for. I'm aware that I'll probably never match what you had in speed terms, but then
you made some very limiting design choices which I simply don't want in fpImage.
The price of more generality is some speed loss, it is always so.
I would appreciate getting the really slow images if possible.
If there are still bugs in bottom-up images, I'd like to hear about them too,
but they are an issue separate of the loading times issue; Probably a reader problem.
As far as I know, bottom-up reading is supported for BMP.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
