Re: [fpc-devel] About modeswitch objectivec2

[Jonas Maebe]

On 21 Jun 2010, at 01:21, Leonardo M. Ramé wrote:

I often read the svn log of the trunk version, and today I noted  
that a mode called "objectivec2" was added. What's the objective of  
this addition?


http://wiki.freepascal.org/FPC_PasCocoa


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OpenSSL bindings improvement

[Inoussa OUEDRAOGO]

Hi

2010/6/2 Felipe Monteiro de Carvalho :
> Hello,
>
> I need some functions of OpenSSL which aren't in
> fpctrunk/packages/openssl/src/OpenSSL.pas
>
> So I am adding them and I will commit after I test.

I just start adding RSA parts and making it Delphi compatible. What
about your porgress ?

Best regards.

-- 
Inoussa O.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Rather large flaw in TJSONConfig component

[Graeme Geldenhuys]

Hi,

Attached is a patch which extents the jsonconf test suite. The new test
highlights a rather big flaw in the workings of the TJSONConfig component.
This issue might even apply to TXMLConfig component too - I haven't looked yet.

This came about in the discussion in the Lazarus mailing list about Lazarus
IDE storing application settings in XML files. I investigated the idea of
replacing my usage of INI files for storing application settings with JSON
files (TJSONConfig) instead. In each of my applications, I store all GUI
Form state (position, size, etc) all in one "application settings" file -
each form has it's own XXXFormState section.

In the test TestConcurrency I simulate two forms being opened - each form
contains a TJSONConfig component. When I close one form it writes the state
information. When I close the second form, it overwrites the whole JSON
file, wiping out the first form's information completely. This is rather
dangerous behaviour!

I see 3 solutions here:

1) Use a Singleton with TJSONConfig so we only have one instance of
   TJSONConfig per application.
2) Extend TJSONConfig so that it is more intelligent when writing to
   a file, and only writes the path information it modified or created.
3) When using one TJSONConfig per form, force the developer to use
   a different .json file for each form.


Any comments or alternative solutions?  I know XMLConfig and JSONConfig are
not documented yet, but if nothing is going to be done about this
concurrency issue I highlighted, then the documentation must clearly state
the dangerous behaviour of these components.


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/



jsonconftest.patch
Description: application/mbox
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Henry Vermaak]

On 21 June 2010 14:20, Graeme Geldenhuys  wrote:
> Hi,
>
> Attached is a patch which extents the jsonconf test suite. The new test
> highlights a rather big flaw in the workings of the TJSONConfig component.
> This issue might even apply to TXMLConfig component too - I haven't looked 
> yet.
>
> This came about in the discussion in the Lazarus mailing list about Lazarus
> IDE storing application settings in XML files. I investigated the idea of
> replacing my usage of INI files for storing application settings with JSON
> files (TJSONConfig) instead. In each of my applications, I store all GUI
> Form state (position, size, etc) all in one "application settings" file -
> each form has it's own XXXFormState section.
>
> In the test TestConcurrency I simulate two forms being opened - each form
> contains a TJSONConfig component. When I close one form it writes the state
> information. When I close the second form, it overwrites the whole JSON
> file, wiping out the first form's information completely. This is rather
> dangerous behaviour!
>
> I see 3 solutions here:
>
> 1) Use a Singleton with TJSONConfig so we only have one instance of
>   TJSONConfig per application.
> 2) Extend TJSONConfig so that it is more intelligent when writing to
>   a file, and only writes the path information it modified or created.
> 3) When using one TJSONConfig per form, force the developer to use
>   a different .json file for each form.
>
>
> Any comments or alternative solutions?  I know XMLConfig and JSONConfig are
> not documented yet, but if nothing is going to be done about this
> concurrency issue I highlighted, then the documentation must clearly state
> the dangerous behaviour of these components.

Seriously, would you try the same thing with a file?  Open it in two
different places and try and write to it from both places and see what
happens.  Programs that want to write to the same json file from
different classes need to handle this properly, just like they would
have to when using files.  The behaviour is completely logical, imho.

Henry
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Mattias Gaertner]

On Mon, 21 Jun 2010 15:20:09 +0200
Graeme Geldenhuys  wrote:

> Hi,
> 
> Attached is a patch which extents the jsonconf test suite. The new test
> highlights a rather big flaw in the workings of the TJSONConfig component.
> This issue might even apply to TXMLConfig component too - I haven't looked 
> yet.

TXMLConfig reads by default the old config.
You can switch this off to start with a clean config.
Unless you use the same paths, no value is lost.

Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Graeme Geldenhuys]

Op 2010-06-21 15:34, Henry Vermaak het geskryf:
> 
> Seriously, would you try the same thing with a file?

Seriously, you would want to tell developers in todays times that they
can't concurrently access a file?


> Programs that want to write to the same json file from
> different classes need to handle this properly, just like they would
> have to when using files.

Unfortunately TJSONConfig and TXMLConfig encapsulates the file handling -
it's not available to the developer to change. So the file handling fix
needs to occur in these components themselves.

Lazarus IDE even makes the TXMLConfig component available to developers on
the System component palette - ready to be dropped on any form. All without
the warning of potential data loss (even with StartEmpty = False)!


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Graeme Geldenhuys]

[...Sorry, I think my first message's attachment was too big. This one
is smaller...]

On 21/06/2010, Mattias Gaertner wrote:
>
> TXMLConfig reads by default the old config.
> Unless you use the same paths, no value is lost.


Op 2010-06-21 15:38, Mattias Gaertner het geskryf:
> Unless you use the same paths, no value is lost.

Sorry Mattias, but you are wrong. TXMLConfig shows the exact same issue as
TJSONConfig. Here is the output after the test run. I attached the
xmlconfig test suite.

Test is simple:
 - load form 1
 - load form 2
 - close form 1 > which saves settings
 - close form 2 > which saves settings and overwrites everything.


---
$ ./testxmlconf --format=plain -a
 Time:00.001 N:1 E:0 F:1 I:0
 TTestXMLConfig Time:00.001 N:1 E:0 F:1 I:0
   00.000  TestConcurrency  Failed: Failed on 1 expected: <400> but was: <100>

Number of run tests: 1
Number of errors:0
Number of failures:  1

List of failures:
 Failure:
   Message:   TTestXMLConfig.TestConcurrency: Failed on 1
expected: <400> but was: <100>
   Exception class:   EAssertionFailedError
   Exception message: Failed on 1 expected: <400> but was: <100>



$ cat concurrency.xml


 


---

-- 
Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/


testsuite_xmlconf.tar.gz
Description: GNU Zip compressed data
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OpenSSL bindings improvement

[Felipe Monteiro de Carvalho]

Hello,

I just commited my changes, because otherwise our work would conflict.
Please work on top of this new version.

I checked a lot of functions against OpenSSL 1.0.0 and it attested
that they work fine. I added many structures and in added a mechanism
to display which routines couldn't be found in the library. This can
be useful because of the plethora of OpenSSL versions available which
may not have all functions.

In terms of functions I removed some functions which don't exist in
v1.0.0 and added the following:

+  // RAND functions
+  TRAND_set_rand_method = function(const meth: PRAND_METHOD): cint; cdecl;
+  TRAND_get_rand_method = function(): PRAND_METHOD; cdecl;
+  TRAND_SSLeay = function(): PRAND_METHOD; cdecl;
+  TRAND_cleanup = procedure(); cdecl;
+  TRAND_bytes = function(buf: PByte; num: cint): cint; cdecl;
+  TRAND_pseudo_bytes = function(buf: PByte; num: cint): cint; cdecl;
+  TRAND_seed = procedure(const buf: Pointer; num: cint); cdecl;
+  TRAND_add = procedure(const buf: Pointer; num: cint; entropy:
cdouble); cdecl;
+  TRAND_load_file = function(const file_name: PChar; max_bytes:
clong): cint; cdecl;
+  TRAND_write_file = function(const file_name: PChar): cint; cdecl;
+  TRAND_file_name = function(file_name: PChar; num: csize_t): PChar; cdecl;
+  TRAND_status = function(): cint; cdecl;
+  TRAND_query_egd_bytes = function(const path: PChar; buf: PByte;
bytes: cint): cint; cdecl;
+  TRAND_egd = function(const path: PChar): cint; cdecl;
+  TRAND_egd_bytes = function(const path: PChar; bytes: cint): cint; cdecl;
+  TERR_load_RAND_strings = procedure(); cdecl;
+  TRAND_poll = function(): cint; cdecl;
+
+  // RSA Functions
+  TRSA_new = function (): PRSA; cdecl;
+  TRSA_new_method = function (method: PENGINE): PRSA; cdecl;
+  TRSA_size = function (arsa: PRSA): cint; cdecl;
+  TRsaGenerateKey = function(bits, e: cInt; callback: PFunction;
cb_arg: SslPtr): PRSA; cdecl;
+  TRSA_generate_key_ex = function (arsa: PRSA; bits: cInt; e:
PBIGNUM; cb: PBN_GENCB): PRSA; cdecl;
+  TRSA_check_key = function (arsa: PRSA): cint; cdecl;
+  TRSA_public_encrypt = function (flen: cint; from_buf, to_buf:
PByte; arsa: PRSA; padding: cint): cint; cdecl;
+  TRSA_private_encrypt = function (flen: cint; from_buf, to_buf:
PByte; arsa: PRSA; padding: cint): cint; cdecl;
+  TRSA_public_decrypt = function (flen: cint; from_buf, to_buf:
PByte; arsa: PRSA; padding: cint): cint; cdecl;
+  TRSA_private_decrypt = function (flen: cint; from_buf, to_buf:
PByte; arsa: PRSA; padding: cint): cint; cdecl;
+  TRSA_free = procedure (arsa: PRSA); cdecl;
+  TRSA_flags = function (arsa: PRSA): Integer; cdecl;
+  TRSA_set_default_method = procedure (method: PRSA_METHOD); cdecl;
+  TRSA_get_default_method = function : PRSA_METHOD; cdecl;
+  TRSA_get_method = function (prsa: PRSA): PRSA_METHOD; cdecl;
+  TRSA_set_method = function (arsa: PRSA; method: PRSA_METHOD):
PRSA_METHOD; cdecl;
+
+  // X509 Functions
+
+  Td2i_RSAPublicKey = function (arsa: PPRSA; pp: PPByte; len: cint):
PRSA; cdecl;
+  Ti2d_RSAPublicKey = function (arsa: PRSA; pp: PPByte): cint; cdecl;
+  Td2i_RSAPrivateKey = function (arsa: PPRSA; pp: PPByte; len: cint):
PRSA; cdecl;
+  Ti2d_RSAPrivateKey = function (arsa: PRSA; pp: PPByte): cint; cdecl;
+
+  // ERR Functions
+
+  TErr_Error_String = function (e: cInt; buf: PChar): PChar; cdecl;
+
+  // Crypto Functions
+
+  TSSLeay_version = function(t: cint): PChar; cdecl;
+
+  // EVP Functions
+
+  TOpenSSL_add_all_algorithms = procedure(); cdecl;
+  TOpenSSL_add_all_ciphers = procedure(); cdecl;
+  TOpenSSL_add_all_digests = procedure(); cdecl;
+  //
+  TEVP_DigestInit = function(ctx: PEVP_MD_CTX; type_: PEVP_MD): cint; cdecl;
+  TEVP_DigestUpdate = function(ctx: PEVP_MD_CTX; const data: Pointer;
cnt: csize_t): cint; cdecl;
+  TEVP_DigestFinal = function(ctx: PEVP_MD_CTX; md: PByte; s:
pcuint): cint; cdecl;
+  //
+  TEVP_get_cipherbyname = function(const name: PChar): PEVP_CIPHER; cdecl;
+  TEVP_get_digestbyname = function(const name: PChar): PEVP_MD; cdecl;
+  //
+  TEVP_CIPHER_CTX_init = procedure(a: PEVP_CIPHER_CTX); cdecl;
+  TEVP_CIPHER_CTX_cleanup = function(a: PEVP_CIPHER_CTX): cint; cdecl;
+  TEVP_CIPHER_CTX_set_key_length = function(x: PEVP_CIPHER_CTX;
keylen: cint): cint; cdecl;
+  TEVP_CIPHER_CTX_ctrl = function(ctx: PEVP_CIPHER_CTX; type_, arg:
cint; ptr: Pointer): cint; cdecl;
+  //
+  TEVP_EncryptInit = function(ctx: PEVP_CIPHER_CTX; const chipher_:
PEVP_CIPHER;
+   const key, iv: PByte): cint; cdecl;
+  TEVP_EncryptUpdate = function(ctx: PEVP_CIPHER_CTX; out_: pcuchar;
+   outlen: pcint; const in_: pcuchar; inlen: cint): cint; cdecl;
+  TEVP_EncryptFinal = function(ctx: PEVP_CIPHER_CTX; out_data: PByte;
outlen: pcint): cint; cdecl;
+  //
+  TEVP_DecryptInit = function(ctx: PEVP_CIPHER_CTX; chiphir_type: PEVP_CIPHER;
+   const key, iv: PByte): cint; cdecl;
+  TEVP_DecryptUpdate = function(ctx: PEVP_CIPHER_CTX; out_data: PByte;
+   outl: pcint; const in_: PByte; inl: cint): cint; c

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Henry Vermaak]

On 21 June 2010 15:10, Graeme Geldenhuys  wrote:
> Op 2010-06-21 15:34, Henry Vermaak het geskryf:
>>
>> Seriously, would you try the same thing with a file?
>
> Seriously, you would want to tell developers in todays times that they
> can't concurrently access a file?

No, that's not what I'm saying.  You need to make it work.  Your
complaint is like saying the write syscall doesn't do the right thing
when I use it on the same file from two different places.  It _can_
work, but it's your job to do it correctly.

>> Programs that want to write to the same json file from
>> different classes need to handle this properly, just like they would
>> have to when using files.
>
> Unfortunately TJSONConfig and TXMLConfig encapsulates the file handling -
> it's not available to the developer to change. So the file handling fix
> needs to occur in these components themselves.

You can create a class that wraps all the json operations, and
therefore handle concurrency in one place.  You're only using one json
file after all.

Henry
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Mattias Gaertner]

On Mon, 21 Jun 2010 16:17:32 +0200
Graeme Geldenhuys  wrote:

> [...Sorry, I think my first message's attachment was too big. This one
> is smaller...]
> 
> On 21/06/2010, Mattias Gaertner wrote:
> >
> > TXMLConfig reads by default the old config.
> > Unless you use the same paths, no value is lost.
> 
> 
> Op 2010-06-21 15:38, Mattias Gaertner het geskryf:
> > Unless you use the same paths, no value is lost.
> 
> Sorry Mattias, but you are wrong. TXMLConfig shows the exact same issue as
> TJSONConfig. Here is the output after the test run. I attached the
> xmlconfig test suite.
> 
> Test is simple:
>  - load form 1
>  - load form 2
>  - close form 1 > which saves settings
>  - close form 2 > which saves settings and overwrites everything.

Now I understand.
Yes, TXMLConfig has the same "design flaw" as
TStringList.LoadFromFile/SaveToFile.
It is strange how you get used to such flaws and think it is normal.


Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Michael Van Canneyt]

On Mon, 21 Jun 2010, Graeme Geldenhuys wrote:


Hi,

Attached is a patch which extents the jsonconf test suite. The new test
highlights a rather big flaw in the workings of the TJSONConfig component.
This issue might even apply to TXMLConfig component too - I haven't looked yet.

This came about in the discussion in the Lazarus mailing list about Lazarus
IDE storing application settings in XML files. I investigated the idea of
replacing my usage of INI files for storing application settings with JSON
files (TJSONConfig) instead. In each of my applications, I store all GUI
Form state (position, size, etc) all in one "application settings" file -
each form has it's own XXXFormState section.


The same happens if you use .INI files. I don't see this as a problem.

The best way to avoid it is to create/destroy the config object after use.
When the form is opened, you create an ini/json/whatever file object and
read the data. Then destroy. When The form is closed, again create the file
object (it should read the latest version of the file then) and then save 
changed values and destroy.


Likewise for a database application. Unless you take care of transaction
support, 2 users editing a record will overwrite each other's changes,
unless the programmer explicitly takes care of this.

In 12 years that our apps run, we used the system 'last writer wins' and 
no single user has complained yet about this.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Graeme Geldenhuys]

Op 2010-06-21 16:29, Henry Vermaak het geskryf:
> 
> You can create a class that wraps all the json operations, and
> therefore handle concurrency in one place.

Correct, that's one possible solution like I mentioned with the Singleton
design pattern. But this still leaves the door wide open for others to have
this problem because the actual TXXXConfig component doesn't do the
"singleton/concurrency" by itself - and not many developers seem to know
about this issue or know about the Singleton design pattern.



Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Henry Vermaak]

On 21 June 2010 15:35, Graeme Geldenhuys  wrote:
> Op 2010-06-21 16:29, Henry Vermaak het geskryf:
>>
>> You can create a class that wraps all the json operations, and
>> therefore handle concurrency in one place.
>
> Correct, that's one possible solution like I mentioned with the Singleton
> design pattern. But this still leaves the door wide open for others to have
> this problem because the actual TXXXConfig component doesn't do the
> "singleton/concurrency" by itself - and not many developers seem to know
> about this issue or know about the Singleton design pattern.

My point is that this is the wrong place to build such functionality
in.  How do you propose this should work from different files or
processes?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Graeme Geldenhuys]

Op 2010-06-21 16:31, Mattias Gaertner het geskryf:
> 
> Now I understand.
> Yes, TXMLConfig has the same "design flaw" as
> TStringList.LoadFromFile/SaveToFile.
> It is strange how you get used to such flaws and think it is normal.

Like I said, if nothing gets changed in the TXXXConfig components, then
Lazarus IDE leaves the door wide open for developers to make this mistake.
Why, because Lazarus IDE has a TXMLConfig component on the component
palette. Developers wouldn't think twice that they are not allow to drop
one component on each form and have a data loss issue.

Possible solutions:

* Fix TXXXConfig components to handle concurrency (multiple instances).
  More intelligent file handling.
* Implement a Singleton for each TXXXConfig component which is ready to
  use for by the developer. Just like Application and Screen are single
  instances in a application without the developer needing to do anything.
* Lazarus could maybe warn the developer (with a popup message) if they
  drop more than one TXXXConfig component in a project with same Filename
  value.
* Or TXMLConfig must be removed from Lazarus component palette as it's
  not like all other components that can handle multiple instances without
  problems.
* Or remember to add clear documentation (when it is written) about this
  pitfall with TXXXConfig components.


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Graeme Geldenhuys]

Op 2010-06-21 16:33, Michael Van Canneyt het geskryf:
> 
> The best way to avoid it is to create/destroy the config object after use.
> When the form is opened, you create an ini/json/whatever file object and

So then it's not wise to have TXMLConfig in the Lazarus component palette.
Because dropping a component on a form doesn't give the behaviour you
described.


> Likewise for a database application. Unless you take care of transaction
> support, 2 users editing a record will overwrite each other's changes,
> unless the programmer explicitly takes care of this.

Doesn't Delphi's TClientDataset popup a 'conflict resolution dialog' in
such a cases. I remember seeing such dialogs years ago (when I still used
Delphi).


> In 12 years that our apps run, we used the system 'last writer wins' and 
> no single user has complained yet about this.

Because they don't get notified about their data (last saved) being lost. :-)


Michael, how does documentation work in FCL? Can we start documentation on
these units and include these usage warnings - then not let them appear in
official documentation until the FCL-json or FCL-xml packages are 100%
documented? I know FPC has the policy that it doesn't allow "partial"
documentation. I just fear that not documenting it now (somewhere) - this
information will be forgotten when the docs are eventually written.

Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Rather large flaw in TJSONConfig component

[Michael Van Canneyt]

On Mon, 21 Jun 2010, Graeme Geldenhuys wrote:


Op 2010-06-21 16:33, Michael Van Canneyt het geskryf:


The best way to avoid it is to create/destroy the config object after use.
When the form is opened, you create an ini/json/whatever file object and


So then it's not wise to have TXMLConfig in the Lazarus component palette.
Because dropping a component on a form doesn't give the behaviour you
described.


It does if you set 'active' or 'enabled' to false, no ?





Likewise for a database application. Unless you take care of transaction
support, 2 users editing a record will overwrite each other's changes,
unless the programmer explicitly takes care of this.


Doesn't Delphi's TClientDataset popup a 'conflict resolution dialog' in
such a cases. I remember seeing such dialogs years ago (when I still used
Delphi).


Only if you program it so. I program with UpdateMode=upWhereKeyOnly, and
then all updates go through, unless the record was deleted.





In 12 years that our apps run, we used the system 'last writer wins' and
no single user has complained yet about this.


Because they don't get notified about their data (last saved) being lost. :-)


Well, I prefer that over bugging our users with dialogs that they don't 
understand
anyway. Additionally, it drastically degrades performance.




Michael, how does documentation work in FCL? Can we start documentation on
these units and include these usage warnings - then not let them appear in
official documentation until the FCL-json or FCL-xml packages are 100%
documented? I know FPC has the policy that it doesn't allow "partial"
documentation. I just fear that not documenting it now (somewhere) - this
information will be forgotten when the docs are eventually written.


You can start documenting them if you wish. But they won't be included
in the official docs till fully finished. (Actually, I started on fcl-json
to get it included on www.json.org. Documentation is a prerequisite)

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OpenSSL bindings improvement

[Inoussa OUEDRAOGO]

2010/6/21 Felipe Monteiro de Carvalho :
> Hello,
>
> I just commited my changes, because otherwise our work would conflict.
> Please work on top of this new version.

Your changes include mostly mine. I will check the Delphi
compatibility ( ctypes.pp has to be modified ).

Thanks.

-- 
Inoussa O.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Two fpimage questions

[theo]

Hello

Can I resample / resize an TFpMemoryImage without losing the alpha channel?
If I use StretchDraw, the resulting image is no longer 
alpha-transparent.  Am I missing sth.?


Ist it possible to unregister / replace an fpimagereader?
I saw they are registered in the initialization section using
ImageHandlers.RegisterImageReader (..


Thank you
Best regards
Theo

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OpenSSL bindings improvement

[Felipe Monteiro de Carvalho]

thanks, applied in rev15469

-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Two fpimage questions

[Michael Van Canneyt]

On Mon, 21 Jun 2010, theo wrote:


Hello

Can I resample / resize an TFpMemoryImage without losing the alpha channel?
If I use StretchDraw, the resulting image is no longer alpha-transparent.  Am 
I missing sth.?


It probably depends on the default stretching algorithm ?



Ist it possible to unregister / replace an fpimagereader?
I saw they are registered in the initialization section using
ImageHandlers.RegisterImageReader (..


You cannot. A workaround is maybe to keep references to all registered handlers,
free the manager, recreate it and re-register all handlers except the one
you want removed.

Please file a bugreport (feature request) so a handler can be un-registered.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Two fpimage questions

[theo]

>You cannot. A workaround is maybe to keep references to all registered 
handlers,



free the manager, recreate it and re-register all handlers except the one
you want removed.



Please file a bugreport (feature request) so a handler can be un-registered.




Thanks. I've tried that, and it works. But I saw that Lazarus is not 
using these registered handlers, so it doesn't really help me.

For the record:

 Om:=ImageHandlers;
 ImageHandlers:=TImageHandlersManager.Create;
 for i:=0 to Om.Count-1 do
   begin
 tn:=Om.TypeNames[i];
 ext:=Om.Extentions[tn];
 ir:=Om.ImageReader[tn];
 iw:=Om.ImageWriter[tn];
 if tn<>'JPEG Graphics'then if ir<>nil then 
ImageHandlers.RegisterImageReader(tn,ext,ir);

 if iw<>nil then ImageHandlers.RegisterImageWriter(tn,ext,iw);
   end;
 Om.Free;

Thank you Michael!

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Two fpimage questions

[theo]

>You cannot. A workaround is maybe to keep references to all registered 
handlers,



free the manager, recreate it and re-register all handlers except the one
you want removed.



Please file a bugreport (feature request) so a handler can be un-registered.




Thanks. I've tried that, and it works. But I saw that Lazarus is not 
using these registered handlers, so it doesn't really help me.

For the record:

 Om:=ImageHandlers;
 ImageHandlers:=TImageHandlersManager.Create;
 for i:=0 to Om.Count-1 do
   begin
 tn:=Om.TypeNames[i];
 ext:=Om.Extentions[tn];
 ir:=Om.ImageReader[tn];
 iw:=Om.ImageWriter[tn];
 if tn<>'JPEG Graphics'then if ir<>nil then 
ImageHandlers.RegisterImageReader(tn,ext,ir);

 if iw<>nil then ImageHandlers.RegisterImageWriter(tn,ext,iw);
   end;
 Om.Free;

Thank you Michael!

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel