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
__
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 TTESTJSONDESTREAMER__TESTFLOAT4
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 regarding the proposition at
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
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 f
Em 11 de mai de 2016 05:13, "Michael Van Canneyt"
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 those that dont use it?
>&g
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 f
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 branch is missing pac
2015-09-29 16:12 GMT-03:00 Michael Van Canneyt :
>
>
> On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:
>
> Unit uniqueinstanceraw
>>
>
>
>> Please look carefully
>>
>
> My sincere apologies,
>
>
No problem.
To be clear, i don't
Unit uniqueinstanceraw
Please look carefully
Luiz
Em 29/09/2015 12:01, "Michael Van Canneyt"
escreveu:
>
>
> On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:
>
> 2015-09-29 11:50 GMT-03:00 Luiz Americo Pereira Camara <
>> luizameri...@gmail.com>:
>
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
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" in CustApp which activates this
>>> automaticall
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
2014-11-26 5:21 GMT-03:00 Michael Van Canneyt :
> On Tue, 25 Nov 2014, luiz americo pereira camara wrote:
>
>> I went to \packages\fcl-base dir and run make PP="my271compilerpath" and
>> i got:
>>
>> Start compiling package fcl-base fo
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 a
2014-09-26 6:37 GMT-03:00 Sven Barth :
> Am 26.09.2014 10:58 schrieb "Michael Van Canneyt" >:
> >
> > 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.
> >
> > Although I am having difficulty seeing how y
Em 21/04/2014 14:26, "Michael Van Canneyt"
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
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
_
2014-02-27 12:35 GMT-03:00 Jonas Maebe :
>
> 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 met
2014-02-27 5:25 GMT-03:00 Sven Barth :
> 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 onl
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 ac
2013/6/21 Sergei Gorelkin :
> 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 SetCodePage goes thro
2013/6/21 Michael Schnell :
> 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 d
2013/6/20 Sergei Gorelkin :
> 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
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 hit
2013/3/4 Daniël Mantione :
>
>
> 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 fac
2013/3/4 Martin Schreiber :
> 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 note that
2013/1/27 Sven Barth :
> On 27.01.2013 20:46, luiz americo pereira camara wrote:
>>>
>>> What would have been more
>>> interesting is the performance of the generated code compared with e.g. a
>>> TStringList or a TObjectList.
>>
>>
>&
2013/1/27 Sven Barth :
> 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
>
>
&g
2013/1/26 Sven Barth :
> On 26.01.2013 12:52, Alexander Klenin wrote:
>>
>> On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
>> wrote:
Generics was implemented without my knowledge. I only found out when
suddenly
the classes unit had been changed to use them. After a horrible
2012/12/25 Sven Barth :
> On 25.12.2012 19:30, Dimitri Smits wrote:
>>
>>
>>
>> - Oorspronkelijk e-mail -
>>>
>>> Van: "Florian Klaempfl"
>>
>> I'm guessing that is NOT on a Windows platform? Every full build (it has
>> been a while) I've ever done of the compiler on windows was at least a
2012/11/29 luiz americo pereira camara :
>
> 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/m
2012/11/29 :
>
>
> 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 ?
2012/11/29 Martin :
> 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 - fpc-devel@lis
2012/11/29 Martin :
> 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:
http://lazarus-ccr.svn.sourceforge.net/viewvc/lazarus-ccr/components/virtualtr
2012/11/29 Graeme Geldenhuys :
> 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 that? [Though my
2012/11/29 Graeme Geldenhuys :
> 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
2012/11/29 :
>
>
> 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 Pa
2012/11/29 :
>
>
> 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 f
2012/11/29 :
>
>
> 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.
>>> 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 impleme
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., ch
2012/11/28 Graeme Geldenhuys :
> 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 Observers support being
2012/11/28 Jonas Maebe :
>
>
> 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 security holes or build
2012/11/28 Graeme Geldenhuys :
> 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 the issue.
Yes. I'll
2012/11/28 :
>
>
> On Tue, 27 Nov 2012, luiz americo pereira camara wrote:
>
>> 2012/11/27 Michael Van Canneyt :
>> 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
>>
2012/11/27 Michael Van Canneyt :
>
>
> On Tue, 27 Nov 2012, luiz americo pereira camara wrote:
>
>>
>> Hi, i requested a change to observer interface with some
>> considerations in http://bugs.freepascal.org/view.php?id=23394
>
>
> It will not happen.
&g
2012/11/13 Marco van de Voort :
>
> 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 with some
2012/10/25 Sven Barth
> 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 delegat
2012/10/25 Sven Barth
> 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
2012/10/24 Graeme Geldenhuys
> 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 questioned the fpc obsev
While looking for the new TextHint property in Delphi docs, i found that
recent Delphi implements Observer support. See:
http://docwiki.embarcadero.com/Libraries/XE3/en/System.Classes.TComponent.Observers
http://docwiki.embarcadero.com/Libraries/XE2/en/System.Classes.TObservers_Methods
Recently
2012/10/4 luiz americo pereira camara
>
>
> 2012/10/3 Jonas Maebe
>
>>
>> On 03 Oct 2012, at 03:29, luiz americo pereira camara wrote:
>>
>>
>> at the line
>> // Load XMM5 with the bias value.
>>MOVDXMM5, [Bias] //B
2012/10/3 Jonas Maebe
>
> 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?
>
>
2012/10/2 Jeppe Græsdal Johansen
> 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 under mode Delphi both
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 XMM5
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
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
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 si
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 t
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
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
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
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
http://lists.freepascal.org/mailman/l
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 finalizat
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.
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
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;
a[1].VT
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 - fpc-devel@lists.freep
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 behal
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 c
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 "strin
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
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 (wh
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
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 imp
On 18/9/2011 17:04, Hans-Peter Diettrich wrote:
Luiz Americo Pereira Camara schrieb:
Can you give me a link? I checked the XE documentation and RTL, and
could not find that RawByteString can hold UTF-16, and my test
confirms that:
http://edn.embarcadero.com/article/38980
You may read
On 18/9/2011 10:07, Hans-Peter Diettrich wrote:
Luiz Americo Pereira Camara schrieb:
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
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
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 u
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 rtl
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 auxili
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, filegeta
On 16/9/2011 02:36, cobines wrote:
2011/9/16 Luiz Americo Pereira Camara:
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 conversion
On 15/9/2011 23:11, Luiz Americo Pereira Camara wrote:
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
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 be
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? Not
On 14/9/2011 06:41, Felipe Monteiro de Carvalho wrote:
On Wed, Sep 14, 2011 at 11:32 AM, Luiz Americo Pereira Camara
wrote:
Because if someone for some reason, like porting Delphi code, stays with a
UTF16 string, under windows, when using RTL functions TWO conversions will
be made:
User Code
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 motiva
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 t
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.
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
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
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=17199&r2=17220
) fixed the missing call of Validate for some dataset descendants but
introduced a new bug: in other dataset descendants like Zeos Validate is
bein
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
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 http://bugs.freepa
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
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
ShowMessageFmt('Error
On 1/4/2011 18:15, Joost van der Sluis wrote:
Hi all,
If you are really stuck, the old Makefile.fpc is copied to Makefile.org.
Copy the Makefile.org to Makefile.fpc, and run 'fpcmake -TAll' in the
fcl-web directory. And don't forget to report your problems.
Trying to compile svn 251 (rev1726
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 ?
1 - 100 of 217 matches
Mail list logo
