[fpc-devel] LCL accessibility inconsistencies
Hi, I'm not sure whether I'm right here, if not, so please apologize my question! I think I detected an error in the LCL accessibility implementation - at least the TControl.AccessibleRole has inconsistencies so a screenreader software doesn't work correctly. How can I get contact with the responsible developers to solve this problem? Thanks, Frank ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] suggestion: virtual method co-variance
On 15.10.2014 04:21, Hans-Peter Diettrich wrote: Sven Barth schrieb: At least at first sight there don't seem to be any real (technical) reasons to not covariance for return values. Parameters would be a different topic though... Just so I get the idea right: === code begin === type TBar = class function Test: TObject; virtual; end; TFooBar = class(TBar) function Test: TStrings; override; end; //... I just wonder about the purpose and use of such refinement. Should the compiler relate on an more specific return type, based on the *static* type of an object reference? I'd use different names for specialized methods/properties instead. The compiler should take into account the type of the variable on which the method is called. See the example code which you have snipped away. ;) And btw: the compiler even already does that! :) OTOH it would be nice to have specialized lists without much coding, i.e. without writing getters (and setters) which only do typecasts of their results. Something like type TBar = class property Test: TObject ...; virtual; end; TFooBar = class(TBar) property Test: TStrings; override; end; Please note that this kind of override should not require to override the getters/setters, it only would enforce (static) type checks/casts, as doable at compile time. But here the compiler can't guarantee that the Getter behind the property is really a TStrings instead of a TObject. And for the setter we would have the same problem as for methods: if I call the property using a TBar variable and pass something else than a TStrings than the inherited Setter will be called and then (to use the example of a list) a foreign object will reside in the list. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] suggestion: virtual method co-variance
On 14.10.2014 15:34, Jonas Maebe wrote: On 14 Oct 2014, at 14:21, Sven Barth wrote: At least at first sight there don't seem to be any real (technical) reasons to not covariance for return values. Delphi and/or FPC already support it to a certain extent, and the compiler contains some code for it (see compatible_childmethod_resultdef in defcmp.pas and its use in nobj.pas). I don't know the exact scenario under which it currently works in though. I just tested my example code (filled in the holes I left of course) and it works. So... we already have covariance support for result types! ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] suggestion: virtual method co-variance
Sven Barth schrieb: At least at first sight there don't seem to be any real (technical) reasons to not covariance for return values. Parameters would be a different topic though... Just so I get the idea right: === code begin === type TBar = class function Test: TObject; virtual; end; TFooBar = class(TBar) function Test: TStrings; override; end; //... I just wonder about the purpose and use of such refinement. Should the compiler relate on an more specific return type, based on the *static* type of an object reference? I'd use different names for specialized methods/properties instead. OTOH it would be nice to have specialized lists without much coding, i.e. without writing getters (and setters) which only do typecasts of their results. Something like type TBar = class property Test: TObject ...; virtual; end; TFooBar = class(TBar) property Test: TStrings; override; end; Please note that this kind of override should not require to override the getters/setters, it only would enforce (static) type checks/casts, as doable at compile time. But that smells like Generics, which already have their place in OPL... Parameters would require different handling, because a single type mismatch would defer to the base class implementation, with possibly strange effects when this results in an bypass of the modified code in the overridden methods. That's another argument for my above suggestion, which should not only eliminate the need for overriding related methods, but should *disallow* explicit getter/setter overrides - so we were back again at generics? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] suggestion: virtual method co-variance
On Tue, Oct 14, 2014 at 7:40 AM, Marco van de Voort wrote: > > I recently had to dive a bit into C++ again, and reconnected with a feature > I liked at first sight, the C++ covariance of virtual methods (changing the > return type of a overriden method to a descendant of the original type). > Googling a bit it seems that some languages(C#) also seem to allow this for > parameters. (not just return types) > > I suddenly wondered why it was never proposed or talked about for FPC, > since it seems such a nice feature. Is there something particularly wrong > with it? > > To a certain degree it can be emulated with generics, but that it > requires a generic for every type, and must be prepared in the library code. > Actually this was kind of talked ;-) http://lists.freepascal.org/pipermail/fpc-devel/2014-February/033394.html Best regards, Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] suggestion: virtual method co-variance
On 14 Oct 2014, at 14:21, Sven Barth wrote: At least at first sight there don't seem to be any real (technical) reasons to not covariance for return values. Delphi and/or FPC already support it to a certain extent, and the compiler contains some code for it (see compatible_childmethod_resultdef in defcmp.pas and its use in nobj.pas). I don't know the exact scenario under which it currently works in though. jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] suggestion: virtual method co-variance
In our previous episode, Sven Barth said: > At least at first sight there don't seem to be any real (technical) reasons > to not covariance for return values. Parameters would be a different topic > though... Specially since afaik we can't overload on returnvalue and require override, so there is no ambiguity. > Would this be the correct equivalent in Object Pascal? Yes, that is about it. Mostly useful for layered frameworks, so that you can add a bit of typing on every level. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] suggestion: virtual method co-variance
Am 14.10.2014 12:41 schrieb "Marco van de Voort" : > > > I recently had to dive a bit into C++ again, and reconnected with a feature > I liked at first sight, the C++ covariance of virtual methods (changing the > return type of a overriden method to a descendant of the original type). > Googling a bit it seems that some languages(C#) also seem to allow this for > parameters. (not just return types) > > I suddenly wondered why it was never proposed or talked about for FPC, > since it seems such a nice feature. Is there something particularly wrong > with it? At least at first sight there don't seem to be any real (technical) reasons to not covariance for return values. Parameters would be a different topic though... Just so I get the idea right: === code begin === type TBar = class function Test: TObject; virtual; end; TFooBar = class(TBar) function Test: TStrings; override; end; //... var b: TBar; f: TFooBar; s: TStrings; begin f := TFooBar.Create; b := f; // this would work s := f.Test; // but this not s := b.Test; end. === code end === Would this be the correct equivalent in Object Pascal? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Buffer error in TDecompressionStream when decompressing some data without deflate header
Hello!
My original task is to make GZIP stream compression/decompression
(preferably without external libraries).
I read zlib specification in http://www.zlib.net/manual.html and tried
to use WindowBits = 16 for automatic GZIP wrapping, but in FPC it does
not works too (in Delphi XE2 works fine).
Also I tried to use simple Deflate mode (DeflateInit and InflateInit
instead of DeflateInit2 and InflateInit2). In this case I can extract
raw zlib data from compressed stream by myself. But when I try to
decompress, I have to emulate simple deflate wrapper, but I have no
adler32 checksum. From GZip I can get only crc32 checksum. When I try
to decompress data with zero adler checksum or without adler checksum
I get error in FPC (but in Delphi XE2 this case works fine too).
Decompression with valid adler32 checksum works fine both in FPC and Delphi XE2.
It is very strange.
2014-10-13 13:08 GMT+04:00 Marco van de Voort :
> In our previous episode, ??? said:
>>
>> SimpleZipTest('zdeafalatasddfas') - works!
>> SimpleZipTest('lalalalalalalala') - does not work! buffer error!
>>
>> In Delphi XE2 both strings compressed and decompressed without errors.
>
> I quickly checked the bugreport last week and had the following conclusions:
>
> 1. the compressed stream is the same. So the problem is in the
> decompression.
> 2. Probably the first string doesn't compress, so it is stored instead of
> deflated, so that is pretty normal.
> 3. I checked in the paszlib source and skipheader does the same as windows
> bits, but it seems that it was meant to work for both large and small window
> sizes, while -15 is the value for large windowsizes (small buffers are useful
> on
> embedded, but the origins are in 16-bit dos/win3.x systems).
>
> The code looks roughly sane, but it isn't clear where exactly the error
> shows. I haven't really debugged in detail.
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
--
Regards,
Vladmir Arkhipov
arkinf...@gmail.com
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
On 10/14/2014 11:50 AM, Sven Barth wrote: It's a proof of concept implementation to have real code to work with instead of just theories. Also it's in a separate branch, so it doesn't interrupt any existing code except one explicitly uses that branch. Sounds good. -Michael (curious...) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] suggestion: virtual method co-variance
I recently had to dive a bit into C++ again, and reconnected with a feature I liked at first sight, the C++ covariance of virtual methods (changing the return type of a overriden method to a descendant of the original type). Googling a bit it seems that some languages(C#) also seem to allow this for parameters. (not just return types) I suddenly wondered why it was never proposed or talked about for FPC, since it seems such a nice feature. Is there something particularly wrong with it? To a certain degree it can be emulated with generics, but that it requires a generic for every type, and must be prepared in the library code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Am 14.10.2014 09:09 schrieb "Michael Schnell" : > > On 10/13/2014 04:14 PM, hinsta...@yandex.ru wrote: >> >> I thought Svan Barth said that he considered implementing it >> > Regarding this, Maybe, "Success" in implementing should be preceded by a decision if and how this feature does make sense regarding the possible addition danger it offers (see the other contributions in this thread). It's a proof of concept implementation to have real code to work with instead of just theories. Also it's in a separate branch, so it doesn't interrupt any existing code except one explicitly uses that branch. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
On 10/13/2014 04:14 PM, hinsta...@yandex.ru wrote: I thought Svan Barth said that he considered implementing it Regarding this, Maybe, "Success" in implementing should be preceded by a decision if and how this feature does make sense regarding the possible addition danger it offers (see the other contributions in this thread). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
On 10/13/2014 04:14 PM, hinsta...@yandex.ru wrote: Maybe; however I am asking about reference counted objects feature. Sorry for the fuzz. (Your contribution was a direct reply to my mail about parallel loops.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
