Re: [fpc-devel] Michael: 0033917: TSQLQuery.CreateParams - override param class

Em qui, 28 de jun de 2018 às 05:45, Ondrej Pokorny escreveu: > Therefore I wrote that I don't need #33918 and #33917 any more. > @Ondrej Can you look at the comment of Michael Van Canneyt in https://bugs.freepascal.org/view.php?id=33918 ? About reverting the patch Luiz

Re: [fpc-devel] TJSONDeStreamer can't handle such date format 'yyyy-MM-dd"T"hh:nn:ss"Z"'

2016-07-19 5:47 GMT-03:00 Michael Van Canneyt : > > > On Tue, 19 Jul 2016, Dimitrios Chr. Ioannidis wrote: > > Exception class: EAssertionFailedError >> Exception message: "Correct extended value" expected: <5,67> but was: >> <6> >> at $0043241F

Re: [fpc-devel] FPC 3.0.2 release target

2016-06-08 15:40 GMT-03:00 Dimitrios Chr. Ioannidis : > I know that I'm probably late, but ... > > Sven, > > currently fpc is ahead of Delphi in Linux platform but this will > probably change ( if this time, they keep their Road Map that is) . > > Plz, think again

Re: [fpc-devel] Installing fpc 32bit on a linux 64bit system - library needed by fpcmkcfg

2016-06-04 21:45 GMT-03:00 Luiz Americo Pereira Camara < luizameri...@gmail.com>: > So far i have no problems installing fpc with the binary installer > > Today i tried to install fpc 32bit on a 64bit OS (Ubuntu Mate 16.4) > > It installed, fpc is running but the cfg was not

[fpc-devel] Installing fpc 32bit on a linux 64bit system - library needed by fpcmkcfg

So far i have no problems installing fpc with the binary installer Today i tried to install fpc 32bit on a 64bit OS (Ubuntu Mate 16.4) It installed, fpc is running but the cfg was not written. Running fpcmkcfg gives: bash: /usr/bin/fpcmkcfg No such file or directory Looking in the internet i

Re: [fpc-devel] Split advancedipc and advancedsingleinstance

Em 11 de mai de 2016 05:13, "Michael Van Canneyt" <mich...@freepascal.org> escreveu: > > > > On Tue, 10 May 2016, Luiz Americo Pereira Camara wrote: >> Any chance to split TAdvancedSingleInstance class into a separated unit so >> no extra code for

[fpc-devel] Split advancedipc and advancedsingleinstance

Hi, I'm looking for a ipc to send log messages between processes. Advancedipc recently added to trunk seems to do the job. I noticed that TAdvancedSingleInstance lives in the same unit as the ipc classes Any chance to split TAdvancedSingleInstance class into a separated unit so no extra code

Re: [fpc-devel] FPC 3.0.2 release target

2016-04-12 5:03 GMT-03:00 Marco van de Voort : > In our previous episode, Michael Van Canneyt said: > > > > I also think so, we've already been merging the necessary fixes to > > fixes_3_x > > For people that missed this hint: PLEASE retest your issues with the fixes > Fixes

Re: [fpc-devel] simpleipc issues

2015-09-29 10:35 GMT-03:00 Michael Van Canneyt : > > > On Tue, 29 Sep 2015, Juha Manninen wrote: > > On Tue, Sep 29, 2015 at 2:50 PM, Michael Van Canneyt >> wrote: >> >>> I am not proposing to make a new class. >>> I want a property "SingeInstance"

Re: [fpc-devel] simpleipc issues

2015-09-29 11:50 GMT-03:00 Luiz Americo Pereira Camara < luizameri...@gmail.com>: > > > It can be used without the component. The component is just a convenience. > See the examples > https://github.com/blikblum/luipack/blob/master/uniqueinstance/testr

Re: [fpc-devel] simpleipc issues

Unit uniqueinstanceraw Please look carefully Luiz Em 29/09/2015 12:01, "Michael Van Canneyt" <mich...@freepascal.org> escreveu: > > > On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote: > > 2015-09-29 11:50 GMT-03:00 Luiz Americo Pereira Cam

Re: [fpc-devel] simpleipc issues

2015-09-29 16:12 GMT-03:00 Michael Van Canneyt <mich...@freepascal.org>: > > > On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote: > > Unit uniqueinstanceraw >> > > >> Please look carefully >> > > My sincere apologies, > > No probl

[fpc-devel] Ambiguity between function result and overloaded function

I have the following methods. I was expecting that Result := Save; would call Save method but in fact Save refers to the function result variable. Is it by design? function TSqlite3JSONObjectResource.Save(IdValue: Variant): Boolean; begin if not VarIsEmpty(IdValue) then begin [..] end

[fpc-devel] RTL development cycle

Hi, Until now, when i make changes to RTL units in trunk, i take two pathes to test and compile: 1) If the unit is self contained, i go to source directory and compile directly 2) If the unit is a dependency of other RTL parts, i rebuild all the compiler and RTL I tried improve this cycle. So

Re: [fpc-devel] Signals

2014-09-26 6:37 GMT-03:00 Sven Barth pascaldra...@googlemail.com: Am 26.09.2014 10:58 schrieb Michael Van Canneyt mich...@freepascal.org : If you want asynchronous, or if you want the signal executed in the context of a thread in case of multiple threads, that is another matter.

[fpc-devel] Order of Observer notification (fpObserver)

Hi, I just notice that the observers are notified in reverse order (see TPersistent.FPONotifyObservers), i.e., last attached observer is notified first. Is this the intended behavior? Any special reason? It was expecting that the observers were notified in attached order Luiz

Re: [fpc-devel] Order of Observer notification (fpObserver)

Em 21/04/2014 14:26, Michael Van Canneyt mich...@freepascal.org escreveu: On Mon, 21 Apr 2014, luiz americo pereira camara wrote: Hi, It was expecting that the observers were notified in attached order You should not expect anything. No order is guaranteed. Ok. I suggest to add

Re: [fpc-devel] Class property and virtual getter

2014-02-27 5:25 GMT-03:00 Sven Barth pascaldra...@googlemail.com: Am 27.02.2014 04:36, schrieb luiz americo pereira camara: Is this a bug or by design? As Michael said this is by design. If you want to use a non-static class procedure you must not use class property, but only property (yes

Re: [fpc-devel] Class property and virtual getter

2014-02-27 12:35 GMT-03:00 Jonas Maebe jonas.ma...@elis.ugent.be: On 27 Feb 2014, at 12:40, luiz americo pereira camara wrote: Technically there's some obstacle to allow such construct? Class properties should be accessible from within static class methods. Got it. Thanks Luiz

[fpc-devel] Class property and virtual getter

TSimpleModel = class(TPersistent) protected class function GetResourceClient: IResourceClient; virtual; class property ResourceClient: IResourceClient read GetResourceClient; public end; Trying to compile the above code i get the following error: Error: Illegal symbol for property

Re: [fpc-devel] Performance of string handling in trunk

2013/6/21 Sergei Gorelkin sergei_gorel...@mail.ru: I've profiled the code and found no conversions taking place. All the slowdown appears to be caused by other reasons, hard to tell the topmost contributor. What catches the eye is the large amount of calls to UniqueString, and the fact that

Re: [fpc-devel] Performance of string handling in trunk

2013/6/21 Michael Schnell mschn...@lumino.de: On 06/20/2013 05:31 PM, luiz americo pereira camara wrote: Maybe in that example there's going an (unneeded) conversion? If you use the same string type all over the place it would be a severe bug if _any_ conversion is done. Please check

[fpc-devel] Performance of string handling in trunk

I looked at http://forum.lazarus.freepascal.org/index.php/topic,21223.0.html There's a significant performance drop in fpc trunk The difference of generated code is a call to fpc_ansistr_assign and a different implementation of fpc_AnsiStr_Concat AFAIK there should be significant performance

Re: [fpc-devel] Performance of string handling in trunk

2013/6/20 Sergei Gorelkin sergei_gorel...@mail.ru: 20.06.2013 16:15, luiz americo pereira camara пишет: I looked at http://forum.lazarus.freepascal.org/index.php/topic,21223.0.html There's a significant performance drop in fpc trunk Is there anything wrong or this is the expected result

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

2013/3/4 Martin Schreiber mse00...@gmail.com: On Monday 04 March 2013 00:29:51 Vittorio Giovara wrote: Could be interesting to see the speed and size of the binary produced by the two compilers, slower compilation time over faster or smaller code is something I would pick any time! Please

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

2013/3/4 Daniël Mantione daniel.manti...@freepascal.org: Op Mon, 4 Mar 2013, schreef luiz americo pereira camara: Is the bigger code just a side effect of a cross platform RTL or the generated code is really bigger / slower? [..] Code generation quality is another factor. While FPC has

Re: [fpc-devel] for-in-index loop

2013/1/26 Sven Barth pascaldra...@googlemail.com: On 26.01.2013 12:52, Alexander Klenin wrote: On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth pascaldra...@googlemail.com wrote: Generics was implemented without my knowledge. I only found out when suddenly the classes unit had been changed to

Re: [fpc-devel] for-in-index loop

2013/1/27 Sven Barth pascaldra...@googlemail.com: On 27.01.2013 16:27, luiz americo pereira camara wrote: I did some test with generics last year: http://lazarusroad.blogspot.com.br/2012/06/cost-of-using-generics.html I would not use in classes unit That's mostly about the duplication

Re: [fpc-devel] Forwarded message about FPC status

2012/12/25 Sven Barth pascaldra...@googlemail.com: On 25.12.2012 19:30, Dimitri Smits wrote: - Oorspronkelijk e-mail - Van: Florian Klaempfl flor...@freepascal.org I'm guessing that is NOT on a Windows platform? Every full build (it has been a while) I've ever done of the

Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]

2012/11/29 michael.vancann...@wisa.be: On Thu, 29 Nov 2012, Sven Barth wrote: Am 29.11.2012 03:59, schrieb luiz americo pereira camara: As is today, if you have a reference to a IFPObserver is not possible to use it to attach to, e.g., child objects. This occurs because AFAIK you can't

Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]

2012/11/29 michael.vancann...@wisa.be: On Wed, 28 Nov 2012, luiz americo pereira camara wrote: Given the considerations i did about the observer feature, here are some simple projects that supports my concerns and therefore the request i made to change the interface of two functions

Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]

2012/11/29 michael.vancann...@wisa.be: On Thu, 29 Nov 2012, luiz americo pereira camara wrote: Well i have at least two situations, with code that is already running, that the observer pattern would fit as i described. - I implemented a Wizard Page component where i can attach a page

Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]

2012/11/29 Graeme Geldenhuys gra...@geldenhuys.co.uk: Hi Luiz, First off, thanks for take the trouble it creating test projects. Thanks for looking at them ;-) On 2012-11-29 02:59, luiz americo pereira camara wrote: Test1 As is today, if you have a reference to a IFPObserver

Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]

2012/11/29 Graeme Geldenhuys gra...@geldenhuys.co.uk: Hello luiz, Thursday, November 29, 2012, 12:31:41 PM, you wrote: BTW: Graeme already pointed, that the Observer methods should be public. Does not makes sense to protect methods that are exposed by an interface. When did I say

Re: [fpc-devel] win64 calling convention

2012/11/29 Martin laza...@mfriebe.de: Just to confirm my observations. (again trying to get pascal script to work) 64 bit windows Recently, i faced similar situation (porting assembly to 64bit). You can look there how i managed:

Re: [fpc-devel] off topic: win 64 stack align.

2012/11/29 Martin laza...@mfriebe.de: I noted that for example on Mac the stack needs to be aligned on 16 byte (32 bit) Is there anything like that on win 64 intel? http://blogs.embarcadero.com/abauer/2011/10/10/38940 Luiz ___ fpc-devel maillist -

Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]

2012/11/29 michael.vancann...@wisa.be: On Thu, 29 Nov 2012, luiz americo pereira camara wrote: Yes. I still do not see how your example shows this ? Your wizard knows it can observe. It attaches itself to the frame. The code frame does not need to know the observing object ? Yes, you

Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]

2012/11/29 luiz americo pereira camara luiz...@oi.com.br: There's a more concrete example about the duplicate typecast. I'm developing a model manager that would be responsible to easily create LCL forms/frames, html forms, LazReport reports etc with the same set of data/models Each

Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]

2012/11/28 michael.vancann...@wisa.be: On Tue, 27 Nov 2012, luiz americo pereira camara wrote: 2012/11/27 Michael Van Canneyt mich...@freepascal.org: As practical example take a LCL Form that is supposed to be observed. It takes an Observer property and attach it to certain child controls

Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]

2012/11/28 Graeme Geldenhuys gra...@geldenhuys.co.uk: Luiz, could you produce a small sample application (or show the code you are working on for Lazarus) where you think the current FPC Observer implementation doesn't work. Your initial bug report doesn't include any test project to show

Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]

2012/11/28 Jonas Maebe jonas.ma...@elis.ugent.be: Personally, I think a release candidate is too late. A release candidate freezes all interfaces (even a beta release does so already, normally). Generally the only fixes still performed afterwards are for blocking crashers/failures, major

Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]

2012/11/28 Graeme Geldenhuys gra...@geldenhuys.co.uk: On 2012-11-27 16:19, Michael Van Canneyt wrote: If you haven't made other changes to those LCL Mediators since the code you emailed me, I could take a look at updating the code for Lazarus too. That's a perfect example of the FPC

[fpc-devel] Tests of observer feature [was: Considerations about observer]

Given the considerations i did about the observer feature, here are some simple projects that supports my concerns and therefore the request i made to change the interface of two functions. Test1 As is today, if you have a reference to a IFPObserver is not possible to use it to attach to, e.g.,

Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]

On 2012-11-27 16:19, Michael Van Canneyt wrote: Correct. But the design should also not try to cover all possible use cases at any cost. Till now, I have not seen a common use case that will not work. See Test1 in a separate message i sent. It will not work with the current implementation

[fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]

2012/11/13 Marco van de Voort mar...@stack.nl: Hello, We have placed the first release-candidate of the Free Pascal Compiler version 2.6.2 on our ftp-servers. [..] * Support for observer pattern added to fcl-base (and base classes in RTL) Hi, i requested a change to observer interface

Re: [fpc-devel] Observer support in Delphi

2012/10/25 Sven Barth pascaldra...@googlemail.com Am 25.10.2012 01:55 schrieb luiz americo pereira camara luiz...@oi.com.br: Regarding Delphi compatibility, currently fpc already lacks much features in areas like attributes, anounimous methods, generics, interfaces, unicode and some

Re: [fpc-devel] Observer support in Delphi

2012/10/25 Sven Barth pascaldra...@googlemail.com Am 25.10.2012 14:11, schrieb luiz americo pereira camara: - what do you miss for interfaces? Delegation: http://bugs.freepascal.org/view.php?id=4842 I personally don't consider this a missing feature (after all delegation itself works

Re: [fpc-devel] Observer support in Delphi

2012/10/24 Graeme Geldenhuys gra...@geldenhuys.co.uk On 2012-10-24 07:52, michael.vancann...@wisa.be wrote: However, given the total lack of documentation, it is hard to say. +1 I had a look too, the Embarcadero website isn't much help. First some considerations: - Initially i

Re: [fpc-devel] Same 64bit assembly code compiles under windows but not in linux (fpc 260)

2012/10/2 Jeppe Græsdal Johansen jjoha...@student.aau.dk Integer is not a specifically sized type. It might differ based on what platform you are on. For example, it's 16bit on i386-linux when compiled with mode fpc. With mode objfpc on the same platform it's 32bit. The code is compiled

Re: [fpc-devel] Same 64bit assembly code compiles under windows but not in linux (fpc 260)

2012/10/3 Jonas Maebe jonas.ma...@elis.ugent.be On 03 Oct 2012, at 03:29, luiz americo pereira camara wrote: at the line // Load XMM5 with the bias value. MOVDXMM5, [Bias] //Bias = Integer Is it a know issue or a limitation of linux version? Win64 uses

Re: [fpc-devel] Same 64bit assembly code compiles under windows but not in linux (fpc 260)

2012/10/4 luiz americo pereira camara luiz...@oi.com.br 2012/10/3 Jonas Maebe jonas.ma...@elis.ugent.be On 03 Oct 2012, at 03:29, luiz americo pereira camara wrote: at the line // Load XMM5 with the bias value. MOVDXMM5, [Bias] //Bias = Integer Is it a know

[fpc-devel] Same 64bit assembly code compiles under windows but not in linux (fpc 260)

Hi, I'm porting some Delphi assembly code. It worked fine with fpc 2.6.0 i386-64bit windows compiler When i tried the same code with fpc 2.6.0 i386-64bit for linux it failed to compile with the following error: Error: Asm: 16 or 32 Bit references not supported at the line // Load

Re: [fpc-devel] Recent added support for Observer pattern in FCL

Em 28/8/2012 04:50, michael.vancann...@wisa.be escreveu: On Mon, 27 Aug 2012, Luiz Americo Pereira Camara wrote: I ask to change to a mechanism that could allow customizable operations (more than one) That is why you have ooCustom. I'm asking that because i have implemented a similar

Re: [fpc-devel] Recent added support for Observer pattern in FCL

Em 28/8/2012 09:15, michael.vancann...@wisa.be escreveu: On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote: Why not let TFPObservedOperation as integer and define constants. It could define a constant like ooUser = 32 Below ooUser is reserved for future default constants Above ooUser

Re: [fpc-devel] Recent added support for Observer pattern in FCL

Em 28/8/2012 12:46, michael.vancann...@wisa.be escreveu: On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote: Em 28/8/2012 09:15, michael.vancann...@wisa.be escreveu: On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote: Why not let TFPObservedOperation as integer and define

[fpc-devel] Recent added support for Observer pattern in FCL

Back in 2010, in the thread about observer support in fcl, i asked if the actions would be customizable so i could, e.g., notify/observe if a child was added or removed in a tree structure. The answer was yes. Looking at the recent added support, it limit the actions (called operations) to 5

Re: [fpc-devel] Class field reordering

Em 18/7/2012 03:19, Martin Schreiber escreveu: Thank you. There are more items in the db.pas list... But I think first we should concentrate on classes.pas because I really don't want to fork it. Forking db.pas is less problematic and I probably prefer it in place of an endless discussion and in

Re: [fpc-devel] Request to apply patch of bug 21905 to trunk

Em 2/6/2012 20:41, Marco van de Voort escreveu: In our previous episode, Luiz Americo Pereira Camara said: Link: http://bugs.freepascal.org/view.php?id=21905 That commit also causes a merge conflict with r20882 btw. Can you undo the commit to fixes and apply it to trunk or should michael do

Re: [fpc-devel] Request to apply patch of bug 21905 to trunk

Em 29/5/2012 04:24, Marco van de Voort escreveu: In our previous episode, Luiz Americo Pereira Camara said: Can someone apply it to trunk? Link: http://bugs.freepascal.org/view.php?id=21905 That commit also causes a merge conflict with r20882 btw. Can you undo the commit to fixes and apply

[fpc-devel] Request to apply patch of bug 21905 to trunk

Hi the patch from the cited bug report was applied to 2.6 branch Can someone apply it to trunk? Link: http://bugs.freepascal.org/view.php?id=21905 Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

[fpc-devel] Memory corruption running fcl-db test suite

Hi, today i hit a strange bug while running the fcl-db test suite. I'm using fpc from trunk rev 21150 windows xp 32 bit. I'm compiling trunk with fpc 260. Attached the script i use. I compiled and ran packages\fcl-db\tests\dbtestframework.pas All the tests run fine, but in testsuite

Re: [fpc-devel] Request to review patch from 21530

Em 12/4/2012 04:12, michael.vancann...@wisa.be escreveu: On Wed, 11 Apr 2012, Luiz Americo Pereira Camara wrote: Hi, Can someone review the patch of http://bugs.freepascal.org/view.php?id=21530 ? I applied the patch, but I don't see what the reason is for having it read-only. I can

[fpc-devel] Request to review patch from 21530

Hi, Can someone review the patch of http://bugs.freepascal.org/view.php?id=21530 ? Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Interchangeability between array of Const and array of TVarRec. Bug?

Hi, I can pass an array of TVarRec to a procedure that expects an array of const like below: procedure Test(Args: array of const); begin //do something with args end; var a: array of TVarRec; s: String; begin SetLength(a, 2); a[0].VType := vtInteger; a[0].VInteger := 3;

Re: [fpc-devel] Trunk rev 19505 dont compile (fails at fpvectorial)

On 17/10/2011 17:27, Jonas Maebe wrote: You should have only deleted the units directory under fpvectorial. Do an svn update to restore the missing fpvectorial directory. Thanks. That worked Luiz ___ fpc-devel maillist -

Re: [fpc-devel] new string - question on usage

On 13/10/2011 04:55, Michael Schnell wrote: On 10/13/2011 02:05 AM, Hans-Peter Diettrich wrote: There is no Raw source ID. The Delphi doc says the RawByteString Type is type ANSIString($). So the RawByte encoding ID in fact is $ (if FPC wants to be Delphi compatible in that behalf

Re: [fpc-devel] new string - question on usage

On 10/10/2011 14:12, Martin wrote: With fpc trunk strings are now codepage aware. I currently face the issue, that lot's of old code just use var foo: string. or sometimes explicit ansistring. No idea what encoding that stores, put it does not seem to be utf8. If I pass such a string (which

Re: [fpc-devel] new string - question on usage

On 10/10/2011 17:56, Jonas Maebe wrote: On 10 Oct 2011, at 22:11, Luiz Americo Pereira Camara wrote: 1- Most of LCL must be code page agnostic, so not use UTF8String/AnsiString directly (keep String) There is no difference between ansistring and string in {$mode delphi} and {$mode objfpc

Re: [fpc-devel] new string - question on usage

On 10/10/2011 19:18, Jonas Maebe wrote: . In a future delphiunicode mode or something like that string will be unicodestring What about the Marco proposition of having separated versions of RTL/Classes for UTF8 / UTF16? Or did i miss something? That would not change the meaning of the

Re: [fpc-devel] new string - question on usage

On 10/10/2011 19:18, Jonas Maebe wrote: On 11 Oct 2011, at 00:06, Luiz Americo Pereira Camara wrote: What about the Marco proposition of having separated versions of RTL/Classes for UTF8 / UTF16? Or did i miss something? That would not change the meaning of the string type. The code in rtl

[fpc-devel] Request to merge revision 19247 to fixes branch (2.6)

In the cited revision i fixed a bug in Sqlite*Dataset that can cause data corruption in some circumstances Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TField.Validate in FPC 2.6

On 24/9/2011 01:32, Martin Schreiber wrote: Am 17.09.2011 10:18, schrieb Joost van der Sluis: There were some changes regarding this, and I still didn't look at them. I will and decide how to solve this. (I think I'll revert it all) Has a decision been made already? I should know if I must

Re: [fpc-devel] Unicode support (yet again)

On 17/9/2011 11:46, Hans-Peter Diettrich wrote: Luiz Americo Pereira Camara schrieb: The codepage of a RawByteString at runtime will keep the previous CodePage (65001 for UTF8, 1200 for UTF16) as opposed to change to the RawbyteString CodePage (65535) as a though previously Delphi defines

Re: [fpc-devel] Unicode support (yet again)

On 16/9/2011 02:36, cobines wrote: 2011/9/16 Luiz Americo Pereira Camaraluiz...@oi.com.br: Lazarus can continue to use UTF-8. Just there will be an implicit conversion when using those functions. The overhead is minimum. Currently UTF8String is just an alias for AnsiString, i.e., the implicit

Re: [fpc-devel] Unicode support (yet again)

On 16/9/2011 09:36, Marco van de Voort wrote: In our previous episode, Luiz Americo Pereira Camara said: Take the example of FileExists: The current LCL implementation - the UTF8 - UTF16 conversion is done with the need of auxiliary code: All the routines you name (fileexists, filegetattr

Re: [fpc-devel] Unicode support (yet again)

On 16/9/2011 14:03, Luiz Americo Pereira Camara wrote: On 16/9/2011 09:36, Marco van de Voort wrote: In our previous episode, Luiz Americo Pereira Camara said: Take the example of FileExists: The current LCL implementation - the UTF8 - UTF16 conversion is done with the need of auxiliary code

Re: [fpc-devel] Unicode support (yet again)

On 16/9/2011 07:38, Marco van de Voort wrote: Most simple RTL routines that accept a string, but are not string type specific (think fileopen createdir etc) accept rawbytestring, a type that accepts all ansistring types and unicodestring. IOW you can also pass an UTF8 to it, even in the UTF16

Re: [fpc-devel] Unicode support (yet again)

On 16/9/2011 14:24, Luiz Americo Pereira Camara wrote: On 16/9/2011 14:03, Luiz Americo Pereira Camara wrote: On 16/9/2011 09:36, Marco van de Voort wrote: he UTF8 - UTF16 conversion is done All the routines you name (fileexists, filegetattr etc) will become rawbytestring and accept both utf8

Re: [fpc-devel] Unicode support (yet again)

On 15/9/2011 12:21, Felipe Monteiro de Carvalho wrote: Lazarus is literally being forced to implement it's own RTL... With the currently planned Unicode RTL it will just get worse, we will then need to either migrate to UnicodeString No. Lazarus can continue to use UTF-8. Just there will

Re: [fpc-devel] Unicode support (yet again)

On 14/9/2011 03:40, Graeme Geldenhuys wrote: On 14/09/2011 03:56, Luiz Americo Pereira Camara wrote: I propose that the above behavior be implemented as a type named RTLString The Object Pascal language already has enough damn string types. I really don't think we should be adding fuel

Re: [fpc-devel] Unicode support (yet again)

On 14/9/2011 03:48, Felipe Monteiro de Carvalho wrote: [..] Of course one path is migrating everything, the LCL, the IDE, SynEdit, all packages, etc, to UTF-16, but that's a huge, immense work with zero advantages over what we are doing up to now, it's just migrate to migrate, who will be

Re: [fpc-devel] Unicode support (yet again)

On 14/9/2011 06:41, Felipe Monteiro de Carvalho wrote: On Wed, Sep 14, 2011 at 11:32 AM, Luiz Americo Pereira Camara luiz...@oi.com.br wrote: Because if someone for some reason, like porting Delphi code, stays with a UTF16 string, under windows, when using RTL functions TWO conversions

Re: [fpc-devel] Unicode support (yet again)

On 14/9/2011 06:48, Graeme Geldenhuys wrote: On 14/09/2011 11:19, Luiz Americo Pereira Camara wrote: This is not desirable simply because at each platform (windows / unix) the user code of the same program will have a different encoding increasing the possibility of subtle errors. Why

Re: [fpc-devel] Unicode support (yet again)

On 13/9/2011 17:14, Graeme Geldenhuys wrote: On 13 September 2011 21:25, Marcos Douglas wrote: Graeme Geldenhuys, sometime, written that string type shoud be depended of plataform. I agree with him, but I don't know if this is +1 ;-) the easiest way... but this is be best way to codify our

Re: [fpc-devel] Unicode support (yet again)

On 13/9/2011 22:56, Luiz Americo Pereira Camara wrote: On 13/9/2011 17:14, Graeme Geldenhuys wrote: the easiest way... but this is be best way to codify our programs, don't you think? UnicodeString should meant UTF-8 on Linux, *BSD, MacOSX etc Unicodestring should mean UTF-16 on Windows. I

Re: [fpc-devel] Request to apply (and merge) patch from bug 19313

On 28/8/2011 05:07, Marco van de Voort wrote: In our previous episode, Luiz Americo Pereira Camara said: http://bugs.freepascal.org/view.php?id=19313 that fix the cited regression (notice that the fixes branch also has this bug) Done. Thanks Luiz

[fpc-devel] Request to apply (and merge) patch from bug 19313

Hi, In the 2.5.1 cycle, revision 17220 ( http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-db/src/base/fields.inc?r1=17199r2=17220 ) fixed the missing call of Validate for some dataset descendants but introduced a new bug: in other dataset descendants like Zeos Validate is

Re: [fpc-devel] FPC 2.6.x branched, trunk becomes 2.7.1

On 5/8/2011 03:05, LacaK wrote: Luiz Americo Pereira Camara wrote / napísal(a): On 4/8/2011 09:21, LacaK wrote: Is this branching somehow related to preparation of release some next version of FPC (2.5.x ? or so) ? I am asking because, there are waiting some bugs/features which I would

Re: [fpc-devel] FPC 2.6.x branched, trunk becomes 2.7.1

On 4/8/2011 09:21, LacaK wrote: Is this branching somehow related to preparation of release some next version of FPC (2.5.x ? or so) ? I am asking because, there are waiting some bugs/features which I would be happy see fixed before any major release. Me too. Specifically

[fpc-devel] fpjson/jsonparser: EJSONScanner vs EScannerError

I found that to handle error while parsing json through TJSONParser is necessary to consider two types of exceptions: EJSONScanner from jsonparser EScannerError from jsonscanner This has the drawback of need to duplicate code like: on E: EJSONScanner do begin

Re: [fpc-devel] fpjson/jsonparser: EJSONScanner vs EScannerError

On 29/5/2011 18:57, Michael Van Canneyt wrote: On Sun, 29 May 2011, Luiz Americo Pereira Camara wrote: I found that to handle error while parsing json through TJSONParser is necessary to consider two types of exceptions: EJSONScanner from jsonparser EScannerError from jsonscanner Well

Re: [fpc-devel] Recent changes to TField.SetData

On 5/4/2011 02:41, LacaK wrote: Then please move approprate code at least into TCustomBufDataset.SetFieldData Thanks This code was already there. Should the 'Validate' code be moved there too ? Yes. TDataset descendants are responsible to calling Validate, e.g., zeos call it inside

Re: [fpc-devel] Recent changes to TField.SetData

On 5/4/2011 04:38, michael.vancann...@wisa.be wrote: On Tue, 5 Apr 2011, LacaK wrote: --or-- introduce any new method (ValidateFieldData ? ;-))) and let tdatsset descendants use it: {$IFDEF FPC} ValidateFieldData(Field: TField; Buffer: Pointer); {$ENDIF} --or-- some smarter solution ?

Re: [fpc-devel] Behavior of conversion between vardate variants and string in fpc and delphi

On 4/4/2011 04:34, LacaK wrote: So, what should be done? 1) Be totally compatible with Delphi: convert date to string with hardcoded format and raise exception when doing the conversion back? 2) Use the hardcoded format used to convert from vardate variant to string and vice versa? 3) Use

Re: [fpc-devel] Recent changes to TField.SetData

On 4/4/2011 10:28, michael.vancann...@wisa.be wrote: On Mon, 4 Apr 2011, LacaK wrote: Michael Van Canneyt wrote / napísal(a): On Mon, 4 Apr 2011, LacaK wrote: Then please move approprate code at least into TCustomBufDataset.SetFieldData Thanks This code was already there. Should

[fpc-devel] Behavior of conversion between vardate variants and string in fpc and delphi

Hi, As pointed in bug http://bugs.freepascal.org/view.php?id=19075 converting from vardate variants (variants with TDateTime values) to string is done differently in Delphi and fpc. According to http://support.embarcadero.com/article/35913 the conversion is done with the default OS format

Re: [fpc-devel] TFPCustomCanvas drawing routines

On 31/1/2011 09:00, Felipe Monteiro de Carvalho wrote: Hello, I decided to put the patch here since it is so small. It is rather trivial, just adds a bunch of virtual markers and some methods with empty implementations, as to make them optional. I think the behavior looks ok for me, if the

Re: [fpc-devel] Component FTag and Tag should be int64

michael.vancann...@wisa.be escreveu: On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote: Andrew Brunner schrieb: That would not be an issue as Int64 is available under all flavors of FPC. I don't see the hold up in adding a patch for Data field. There is just one unit to change. What makes

Re: [fpc-devel] Component FTag and Tag should be int64

Michael Van Canneyt escreveu: On Tue, 23 Nov 2010, Luiz Americo Pereira Camara wrote: michael.vancann...@wisa.be escreveu: On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote: Andrew Brunner schrieb: That would not be an issue as Int64 is available under all flavors of FPC. I don't see

Re: [fpc-devel] Types.IntersectRect(), probably bug or misusage VERY URGENT

Mattias Gaertner escreveu: On Tue, 26 Oct 2010 17:31:48 +0200 zeljko zel...@holobit.net wrote: One note: IntersectRect in lazarus worked OK until we decided to use Types.IntersectRect, old implementation from GraphType looks much better than current fpc one. Then it is probably

  1   2   >