On Sun, 24 Apr 2011, Marco van de Voort wrote:
In each case, I think I have an approach which should speed things up, and
still sticks to the design principles of fpImage.
The only design I see in fpimage is a general effort to try to support
anything at once. Nevermind the costs.
Not "nev
In our previous episode, Michael Van Canneyt said:
> > Ah, I don't considered those languages. At least not where any discussions
> > about performance or efficiency apply ;_)
>
> The topic was the availability of generics.
> In that field, all languages are viewed.
If you say so. Anyway, while
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 yo
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
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
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
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
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'
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 understand
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
earl
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
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
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 w
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
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
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
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 m
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
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 c
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 err
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
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 ca
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
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
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 i
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 kno
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 ca
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
cod
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 w
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
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 wri
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 wil
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
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 t
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 handlin
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.
>
>
On Thu, 21 Apr 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
The best we can do is create a memory class with some pre-defined memory
storages,
with appropriate getscanline/setscanline routines and make sure the reader
classes
can
a) detect them
b) make
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 opin
In our previous episode, Michael Van Canneyt said:
> >> The best we can do is create a memory class with some pre-defined memory
> >> storages,
> >> with appropriate getscanline/setscanline routines and make sure the reader
> >> classes
> >> can
> >> a) detect them
> >> b) make use of them if th
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
>
On Thu, 21 Apr 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
There is no generic way to solve this problem, because you'd need a matrix
covering all possible storage memory formats and all possible disk storage
formats.
Probably. The point is more that
On Thu, 21 Apr 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
If you declare your class as e.g. TBW32image (RGBA), a pixel assignment is
an inline handful of instructions.
I think fcl-image with its no-compromise format support was great initial
effort. B
In our previous episode, Michael Van Canneyt said:
> > If you declare your class as e.g. TBW32image (RGBA), a pixel assignment is
> > an inline handful of instructions.
> >
> > I think fcl-image with its no-compromise format support was great initial
> > effort. But it is time to at least allow so
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
(dum
On Thu, 21 Apr 2011, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
* Create a TFPCustomImage descendant that is limited to the bit depth you need.
* Do not use palette.
* Implement GetPixel and SetPixel so they convert from 64-bit from/to the depth
you u
On Thu, 21 Apr 2011, Marco van de Voort wrote:
In our previous episode, Mattias Gaertner said:
>> GetScanLine/SetScanLine,
>> and all other FPIMage operations will work equally well.
>
> This will not accelerate reading/writing at all. When writing (or any other
> form of streaming), there wi
In our previous episode, Mattias Gaertner said:
> > > GetScanLine/SetScanLine,
> > > and all other FPIMage operations will work equally well.
> >
> > This will not accelerate reading/writing at all. When writing (or any other
> > form of streaming), there will still be a procedure call per pix
Marco van de Voort hat am 21. April 2011 um 18:50
geschrieben:
> In our previous episode, michael.vancann...@wisa.be said:
> > * Create a TFPCustomImage descendant that is limited to the bit depth you
> > need.
> > * Do not use palette.
> > * Implement GetPixel and SetPixel so they con
In our previous episode, michael.vancann...@wisa.be said:
> * Create a TFPCustomImage descendant that is limited to the bit depth you
> need.
> * Do not use palette.
> * Implement GetPixel and SetPixel so they convert from 64-bit from/to the
> depth you used
> * Implement a GetScanLine/SetScanLin
--- On Thu, 4/21/11, michael.vancann...@wisa.be
wrote:
> From: michael.vancann...@wisa.be
> Subject: Re: [fpc-pascal] FPImage and GetDataLineStart
> To: "FPC-Pascal users discussions"
> Date: Thursday, April 21, 2011, 11:09 AM
>
>
> On Thu, 21 Apr 2011, Leonar
On Thu, 21 Apr 2011, Leonardo M. Ramé wrote:
--- On Thu, 4/21/11, Marco van de Voort wrote:
From: Marco van de Voort
Subject: Re: [fpc-pascal] FPImage and GetDataLineStart
To: "FPC-Pascal users discussions"
Date: Thursday, April 21, 2011, 6:41 AM
In our previous episode, Sven
In our previous episode, Leonardo M. Ram? said:
>> IIRC I accelerated loading/saving simple 8-bit BMP images
>> 20 to 50 times in
>> my work code.
>>
> Do you care to share some insights about what you did to accelerate it?
- Made it 8bpp only
- introduced linebased writing.
- since my images ar
--- On Thu, 4/21/11, Marco van de Voort wrote:
> From: Marco van de Voort
> Subject: Re: [fpc-pascal] FPImage and GetDataLineStart
> To: "FPC-Pascal users discussions"
> Date: Thursday, April 21, 2011, 6:41 AM
> In our previous episode, Sven Barth
> said:
>
It also annoys me, but changing would probably be a huge work. All of
the image reader/writers would need to be checked...
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/lis
On 21/4/2011 06:41, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
Am 20.04.2011 22:20, schrieb Leonardo M. Ram?:
Hi, I need to write a function that replaces TLazIntfImage by using fpImage,
and I can't find an alternative to GetDataLineStart. How can I replace it?.
Maybe
In our previous episode, Sven Barth said:
> Am 20.04.2011 22:20, schrieb Leonardo M. Ram?:
> > Hi, I need to write a function that replaces TLazIntfImage by using
> > fpImage, and I can't find an alternative to GetDataLineStart. How can I
> > replace it?.
>
> Maybe I get your intention wrong, bu
Am 20.04.2011 22:20, schrieb Leonardo M. Ramé:
Hi, I need to write a function that replaces TLazIntfImage by using fpImage,
and I can't find an alternative to GetDataLineStart. How can I replace it?.
Maybe I get your intention wrong, but TLazIntfImage is already using
fpImage and it derives f
57 matches
Mail list logo
