On Friday 10 September 2010 17:43:59 Adem wrote:
> Sometime ago, there was a brief mention of multi-threading FPC would be
> counter productive because compilation process was mostly disk IO bound
> --this is what I understood anyway.
>
> I wanted to check to see if disk IO was really limiting FPC/
On Saturday, 11. September 2010 11.32:38 Jonas Maebe wrote:
>
> So yes, FPC is slower than Delphi. Would parallelising FPC reduce the speed
> gap?
Because the gap is so big I think not substantial.
Given that (please correct me if I am wrong):
- FPC bottleneck is disk IO and not compiler logic a
On Saturday, 11. September 2010 12.25:14 Juha Manninen (gmail) wrote:
> > One would think Delphi and FPC need the same disk IO?
>
> I read the threads. My guess is also that the slowness comes from searching
> and writing many files in big directory structures. It is slow even if the
> files are ca
On Saturday, 11. September 2010 18.37:49 Graeme Geldenhuys wrote:
> On 11 September 2010 16:12, Mattias Gaertner wrote:
> > Martin, can you give a comparison between win32 and Linux 32?
>
> Add to that Martin, I know MSEgui is compilable with FPC and
> Delphi. Is MSEgui compilable with Kylix 3
On Saturday, 11. September 2010 16.12:10 Mattias Gaertner wrote:
>
> Maybe dcc32 likes the MSEgui sources.
>
Or maybe FPC does not like MSEgui sources. ;-)
> Martin, can you give a comparison between win32 and Linux 32?
>
I don't have a working Kylix 3 environment at the moment. IIRC dcc32 on Linu
On Saturday 11 September 2010 20:27:46 Florian Klämpfl wrote:
>
> What machine? Because with hot disk cache, I just build MSEide in about
> 10 s (15 s cold) on W7 64 Bit:
>
The same as for all other tests,
win2000, AMD Athlon XP 3000+, 1GB RAM
> ...
> Linking mseidefp.exe
> 308574 lines compiled,
On Sunday, 12. September 2010 01.31:43 Dimitri Smits wrote:
> >
> > And why does the Delphi commandline compiler (dcc32) not need this IDE
> >
> > assistance?
>
> it does. Delphi IDE passes extra assumptions/directories that the
> commandline tool does not know about (for instance $(DELPHI)/Project
On Saturday, 11. September 2010 21.10:20 Florian Klämpfl wrote:
>
> Anyways, before this ends in an endless discussion: if anybody is
> interested in improving FPC compilation speed (for my needs is
> sufficient) and have a look at fillchar and, have a look at FPC's unit
> loading algorithm (not th
Am 12.09.2010 00:20, schrieb Graeme Geldenhuys:
Now this is weird! Anybody else spotted the difference? Delphi seems
to compile +-28000 lines less that FPC! Florian, I presume it's the
same machine with the same MSEgui source code revision? What would be
the reason for that?
Would that (lines c
On Sunday, 12. September 2010 10.12:59 Florian Klämpfl wrote:
> >
> > Agreed. My opinion is that before we start to implement difficult and
> > error-prone multi-threading into FPC we should find out why the hell
> > Delphi 7 can compile so much faster
>
> Because of the same reason why it seems to
On Sunday, 12. September 2010 10.29:32 Florian Klämpfl wrote:
> >
> > And that results in a discrepancy of factor 5..10? I can't believe it.
>
> Digging out 1.0.10 and using some extreme example:
>
> C:\fpc\tests\webtbs>"c:\pp 1.0.10\bin\win32\ppc386.exe" tw2242 -O2
> Free Pascal Compiler version 1
Am 12.09.2010 10:12, schrieb Florian Klämpfl:
The 2.x register allocator is more robust (no more internalerrors 10),
it is small (basically 2k lines, compiler/rgobj.pas) and it generates
reasonable register allocations on all types of CPUs (remember, FPC
supports CPUs with high register pressure
On Sunday, 12. September 2010 18.29:34 Florian Klämpfl wrote:
>
> > Please take it with humor. :-)
>
> As long as the compiler itself builds on a reasonable machine in less
> than 10 seconds, I'am happy :)
Yup, I know. But there are people who use FPC for other tasks than compiling
FPC and there
Hi,
Some numbers about the MSEide exes compiled as testcase in
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html
System:
win2000, AMD Athlon XP 3000+, 1GB RAM
Delphi 7 FPC
Exe size: 3131392 3689304
Code: 21285
On Monday, 13. September 2010 12.57:14 Adem wrote:
> Martin,
>
> Could I have a copy of this exact setup --unless it is too big to send.
>
What do you need?
The source is here:
http://developer.berlios.de/svn/?group_id=11520
The compiler commands are here:
http://www.mail-archive.com/fpc-devel%40
On Monday, 13. September 2010 13.24:18 Florian Klaempfl wrote:
> Am 13.09.2010 11:15, schrieb Martin Schreiber:
> > Delphi 7 FPC
> > Exe size: 3131392 3689304
> > Code: 2128524 2138240
> >
On Monday, 13. September 2010 14.12:38 Graeme Geldenhuys wrote:
> Op 2010-09-13 13:47, Martin Schreiber het geskryf:
> > I can not use resource strings because FPC resource strings are not
> > unicode capable AFAIK.
>
> Probably related to your choice of UCS-2 - I don'
lass1(theclassinstance) do begin
end;
"
On 9/14/10, Florian Klaempfl wrote:
> Am 13.09.2010 17:10, schrieb Dimitri Smits:
>>
>> - "Florian Klaempfl" schreef:
>>
>>> Am 13.09.2010 13:47, schrieb Martin Schreiber:
>>>> On Monday, 13. Sept
On Tuesday 05 October 2010 00:37:44 José Mejuto wrote:
> Hello FPC,
>
> I find a problem that I'm unable to resolve, with my limited skills.
> In TReader when a property is a TClass it is being added to be
> resolved after all components are loaded, but the "Loaded" call is
> performed before this
On Tuesday 05 October 2010 13:55:53 José Mejuto wrote:
>
> if not Assigned(GlobalLoaded) then begin <--
> for i := 0 to FLoaded.Count - 1 do
> TComponent(FLoaded[i]).Loaded;//
> end;
>
> finally
> if n
On Tuesday, 5. October 2010 17.24:09 José Mejuto wrote:
> Hello FPC,
>
> Tuesday, October 5, 2010, 4:08:08 PM, you wrote:
> >> As you can see the "Loaded" event is called (marked with some //-)
> >> before calling "GlobalFixupReferences",
>
> MS> Not if GlobalLoaded is set.
>
> Yes, but it is n
On Wednesday, 6. October 2010 13.49:59 José Mejuto wrote:
> Hello FPC,
>
> I think I can see your point, but from the "end user" point of view
> this is not a possibility. How to tell to the user, "Remeber you must
> call beginglobal... and notifyglobal... and finally endglobal... when
> you create
On Thursday, 7. October 2010 17.25:28 José Mejuto wrote:
> Hello FPC,
>
> Thursday, October 7, 2010, 8:27:23 AM, you wrote:
>
> MS> Maybe you mix up component creation order and form/datamodule creation
> order? MS> I wrote about form/datamodule creation order.
>
> The datamodule is created just in
On Thursday, 7. October 2010 20.46:54 José Mejuto wrote:
> Thank you, I'll try to gather more information from Lazarus list, but
> if that's the case it completly defeats the advantages of a datamodule
> and/or the presence of a published Active property in the SQLQuery (as
> it is only valid if i
On Friday, 8. October 2010 11.16:44 José Mejuto wrote:
>
> Relationship
>
>
> MainSecond form Datamodule
> +--+ +--++---+
>
> | | | SQLQuery |+---> SQLConnection --+
> |
> |Button-->|| || | | |
>
> +--+ +---
On Friday, 8. October 2010 17.55:55 José Mejuto wrote:
> Attached is the example. One form that load a "menu" which opens a new
> form which display a table in a grid. You will need to change the
> password setup, and maybe database (I'm using aliases instead full
> path), and of course the sql lin
On Monday, 11. October 2010 11.15:15 José Mejuto wrote:
> MS> I converted the example to MSEgui, works OK.
>
> So or the problem is in LCL or I'm suffering some kind of poltergeist.
Or in SQLDB. MSEgui has a forked SQLDB which has completely rewritten parts.
Martin
___
Am 19.10.2010 09:37, schrieb Michael Van Canneyt:
[...]
Currently all we got from Hans Peter were unmanageable patches
supposedly fixing things that were not broken or in need of fixing.
If he had first done some smaller things - take your pick in the bugtracker
- and we had seen that this g
On Tuesday, 19. October 2010 15.42:30 Alexander Klenin wrote:
> 2) I'd say that at least half of his mistakes could be avoided
> by better code structure of FPC -- he was really uncomfortable
> using strange records and pchars instead of normal objects and strings.
Hmm, strange records and pchars
On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
> 1) I have serious suspicions that compile time on modern processors
> is dominated by linking and I/O.
> At least this is certainly true for FPC on Windows case.
Do you remember the factor 10 compiling speed advangage of Delphi7 comp
On Tuesday, 19. October 2010 16.42:19 Alexander Klenin wrote:
> > Do you remember the factor 10 compiling speed advangage of Delphi7
> > compared with FPC 2.4?
> > http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html
>
> I do. I also remember that one of the goals of DoDi's pre
On Tuesday, 19. October 2010 17.17:04 Graeme Geldenhuys wrote:
> Op 2010-10-19 17:06, Martin Schreiber het geskryf:
> > core aware compiler without a team of highest skilled fulltime developers
> > working several years...
>
> Why do you think we are not that already? :-)
&g
On Friday, 22. October 2010 22.40:55 Andrew Brunner wrote:
> Looking to get some resolution to an immediate problem with postgres
> component I have...
>
Have a look to MSEgui lib/common/db/mpqconnection.pp, it supports blobs by
mapping to bytea.
http://developer.berlios.de/projects/mseide-msegui
On Saturday, 23. October 2010 13.11:01 Michael Van Canneyt wrote:
> On Fri, 22 Oct 2010, Andrew Brunner wrote:
> > Looking to get some resolution to an immediate problem with postgres
> > component I have...
> >
> > Field definitions for blob can be mapped to bytea and enable support
> > for blob d
On Tuesday, 26. October 2010 13.22:27 Anton Kavalenka wrote:
>
> Yes, windows only.
> But they fully understand bonuses from FPC and Lazarus but really hate GDB.
> Their last argument - we need assembly-line stepping debugger like in
> Delphi.
???
Works with gdb, see MSEide example:
http://mseide-
On Tuesday, 26. October 2010 13.47:22 Graeme Geldenhuys wrote:
> Op 2010-10-26 13:22, Anton Kavalenka het geskryf:
> > Their last argument - we need assembly-line stepping debugger like in
> > Delphi.
>
> This is actually supported in MSEide, I did it the other day ("View >
> Assembler" and use 'Ne
On Tuesday, 26. October 2010 15.07:31 Graeme Geldenhuys wrote:
> The CPU
> window doesn't work at all though, where it did under 32-bit Linux.
>
> http://opensoft.homeip.net/~graemeg/mseide_debug_windows.png
>
Plase check if 'Project'-'Options'-'Debugger'-'Target'-'Processor' is set
to 'i386' in
On Tuesday, 26. October 2010 16.14:50 Graeme Geldenhuys wrote:
> The problem is then in the MSEide template projects (issue is probably in
> svn repository too, because the default ones are not changed locally). I
> went "Project > New > From Template > console.prj". By default it is set it
> i386
On Wednesday, 10. November 2010 11.24:52 Michael Van Canneyt wrote:
>
> >> Nowhere is the Delphi behaviour guaranteed, not even by Delphi.
> >
> > Well, I can always argue that FPC tries to clone/mimic Delphi behaviour
> > in many ways... it's that little FPC design goal called "delphi
> > compatib
On Tuesday, 16. November 2010 14.52:12 Paul Breneman wrote:
>
> I'd like to take the minimal distros and add a simple option to use
> MSEide and it supports debugging from what I understand. Then maybe
> extending that with remote debugging would be the next item.
>
MSEide is ready to work with re
On Monday, 10. January 2011 16.27:19 Marco van de Voort wrote:
>
> And there are three such cases
>
> - normal FPC and Delph 2007- code : ansistring(0)
> - Lazarus : ansistring=utf8
> - Delphi 2009+ UTF16.
>
- fpGUI: ansistring = utf-8
- MSEgui: existing FPC UnicodeString = utf-16
Martin
___
On Wednesday, 12. January 2011 09.45:47 LacaK wrote:
>
> So where is error ?
> 1. Is it wrong expectation by LCL, that TField.Text is always UTF8 string
> -or-
> 2. Is it wrong in implementation of TSQLConnectors, which write data
> into record buffer (of TStringField) and do not convert them alway
On Wednesday, 12. January 2011 14.27:14 LacaK wrote:
>
> Yes, sounds logicaly to me.
> Then you propose same way for TStringField ? (internaly store as
> UnicodeString UTF-16 and also TStringField.Text should return
> UnicodeString instead of String ?
It is done so in MSEgui fork of sqldb.
In case
On Wednesday, 12. January 2011 23.05:02 Juha Manninen wrote:
> Martin Schreiber kirjoitti maanantai 10 tammikuu 2011 19:22:49:
> > On Monday, 10. January 2011 16.27:19 Marco van de Voort wrote:
> > > And there are three such cases
> > >
> > > - normal FPC
On Thursday, 13. January 2011 18.57:00 Hans-Peter Diettrich wrote:
>
> The implementation can choose any model. Different models can be
> implemented as well, so that the final decision about the new standard
> can be delayed, until the models can be tested in real world applications.
>
> One model
On Sunday, 30. January 2011 12.13:21 Florian Klämpfl wrote:
>
> Actually I think anything about a ten percent slower compiler will
> people make cry ... And as far as I understand, for projects with a lot
> of units it will be even worse, right?
>
I cry if FPC doesn't compile at least ten percent *
On Thursday 24 February 2011 08:02:20 LacaK wrote:
> So also here we can see, that FieldDef.Size is expected to be number of
> characters not bytes.
>
> So IMHO logical conclusion will be say, that TFieldDef.Size for string
> fields has same menaing as Field.Size, so it is number of characters
> (s
On Thursday 24 February 2011 09:49:51 michael.vancann...@wisa.be wrote:
> > Agreed. In MSEgui tmsestringfield.size is the maximum allowed character
> > count for the field. 0 = no limit. tmsebufdataset stores string data as
> > UnicodeString instead to use a fixed record layout.
>
> But here you im
On Thursday 24 February 2011 10:16:43 michael.vancann...@wisa.be wrote:
> >> But here you implicitly assume that you have a fixed number of bytes per
> >> character. You should always be explicit about such things, since this
> >> is a non-trivial assumption.
> >
> > I don't understand.
>
> "tmseb
On Thursday 24 February 2011 11:05:50 michael.vancann...@wisa.be wrote:
> On Thu, 24 Feb 2011, Martin Schreiber wrote:
> > On Thursday 24 February 2011 10:16:43 michael.vancann...@wisa.be wrote:
> >>>> But here you implicitly assume that you have a fixed number of bytes
&
On Thursday 17 March 2011 09:54:02 Jonas Maebe wrote:
> Hello,
>
> Finally I'm not alone anymore in repeating this over and over again:
> http://twitter.com/kylix_rd/statuses/48210052770836480
>
Byvalue or byreference for const parameters is defined in Delphi 7 language
manual on page 12-1, it see
Am 04.04.2011 07:29, schrieb Michael Van Canneyt:
On Mon, 4 Apr 2011, LacaK wrote:
But It seems to me, that DataChanged is now called 2 times
First in TDataSet descendants in SetFieldData method (see
bufdataset.pas, dbf.pas, paradox.pp, meds.pp) and second in above
mentioned place.
So it wo
Hi,
In 2008 there was a thread about FPC and Unicode resoure strings with the
conclusion that FPC does not support them.
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg10327.html
Has the situation changed in the meantime?
Does anybody know if Delphi supports Unicode resource strings
Am 29.04.2011 08:52, schrieb Jonas Maebe:
On 29 Apr 2011, at 09:43, Martin Schreiber wrote:
In 2008 there was a thread about FPC and Unicode resoure strings with the
conclusion that FPC does not support them.
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg10327.html
Has the
Hi,
I compiled MSEide with FPC 2.4.4 and Delphi 7 for comparison.
Delphi 7:
Borland Delphi Version 15.0
Copyright (c) 1983,2002 Borland Software Corporation
[...]
303079 lines, 5.31 seconds, 2256556 bytes code, 820297 bytes data.
Exe size: 3.2MB
FPC:
Free Pascal Compiler version 2.4.4 [2011/04/2
Am 30.05.2011 11:41, schrieb Alexander Klenin:
On Mon, May 30, 2011 at 03:26, Martin Schreiber wrote:
Delphi 7:
303079 lines, 5.31 seconds, 2256556 bytes code, 820297 bytes data.
FPC:
302251 lines compiled, 45.2 sec , 2257728 bytes code, 1688152 bytes data
So Delphi is 9 times faster
Am Montag 30 Mai 2011, 13:21:39 schrieb Mattias Gaertner:
>
> Do you know, how much is compiling and how much is linking?
>
Linking is 3..4 seconds.
>
> Why are kernel and serialcomm given twice?
>
kernel is once -Fi and once -Fu, second serialcomm is copy paste error.
>
> How to compile
Am Montag 30 Mai 2011, 14:30:44 schrieb Mattias Gaertner:
> Martin Schreiber hat am 30. Mai 2011 um 13:59
geschrieben:
> > Am Montag 30 Mai 2011, 13:21:39 schrieb Mattias Gaertner:
> > > Do you know, how much is compiling and how much is linking?
> > >
> &
On Wednesday 15 June 2011 01:58:05 Skybuck Flying wrote:
> Solved:
>
> The solution required one little line fixed:
>
> {ifopt b+}
>
[...]
The CHECKPOINTER directive can be used with DEFAULT:
"
{$CHECKPOINTER ON}
[...]
{$CHECKPOINTER DEFAULT}
"
Maybe that method can be implemented for other direct
On Thursday 07 July 2011 19:22:27 Florian Klämpfl wrote:
>
> Why? 2) is exactly the same? The const contract with the compiler is
> broken.
>
> Besides this, people like Martin Schreiber won't be happy if a procedure
> suddently eats hundreds of extra clock cycles for nothi
On Monday 11 July 2011 19:55:25 Ludo Brands wrote:
>
> I don't think zeoslib uses prepared statements for mysql either.
>
MSEgui tmysqlconnection uses prepared statements and binary parameters.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal
Am 10.09.2011 15:42, schrieb Jeff Duntemann:
If a "mini-FPC" were to be created to help popularize the Pascal
language and get beginners interested and up to speed, it would be more
useful to provide a simple IDE than a stripped-down compiler. The
console FP IDE has never worked well for me (cras
On Monday 12 September 2011 12:23:44 Martin wrote:
> > - watchpoints. break when data at memory address changed. Very
> >
> > handy to debug those procedural programs that loves to use global
> > variables. MSEide supports this (but it is actually a GDB feature)
>
> Yes indeed.
>
>
On Monday 12 September 2011 12:45:40 Nikolai Zhubr wrote:
> 12.09.2011 11:08, Graeme Geldenhuys:
> [...]
>
> > If anybody with the know how is interested in implementing a Object
> > Pascal based debugger (or extending Duby specifically for use with FPC),
> > please let me know. I am more than wil
On Monday 12 September 2011 13:08:31 Michael Schnell wrote:
> On 09/12/2011 12:10 PM, Graeme Geldenhuys wrote:
> > - watchpoints. break when data at memory address changed. Very
> >
> > handy to debug those procedural programs that loves to use global
> > variables. MSEide supports th
On Monday 12 September 2011 13:12:11 Graeme Geldenhuys wrote:
> On 12/09/2011 13:00, Martin Schreiber wrote:
> > True. And maintaining all platforms is a fulltime job too.
>
> Maintenance should be MUCH less work than the initial implementation. So
> I don't consider this
On Monday 12 September 2011 13:16:58 Graeme Geldenhuys wrote:
> On 12/09/2011 12:45, Nikolai Zhubr wrote:
> > I'd also happily contribute $300 or so (in case there is a reasonable
> > chance to actually get it working at least on windows/linux/bsd)
> >
> > However, the effort needed is probably mu
On Monday 12 September 2011 13:16:21 Paul Ishenin wrote:
> 12.09.2011 19:00, Martin Schreiber wrote:
> > True. And maintaining all platforms is a fulltime job too. And a FPC
> > only debugger can not debug linked c libraries which we can do
> > currently with gdb. And think of
On Monday 12 September 2011 13:36:43 Graeme Geldenhuys wrote:
> On 12/09/2011 13:32, Martin Schreiber wrote:
> > I think it is better to invest time into gdb support instead into a FPC
> > debugger which probably never will reach a usable state.
>
> [sarcasm on]
> Wit
On Monday 12 September 2011 14:20:06 Michael Schnell wrote:
> On 09/12/2011 01:15 PM, Martin Schreiber wrote:
> > gdb uses hardware watchpoint support if available.
>
> That seems hard to beat when doing a new multi-arch debugger
>
Co
Hi,
I compiled MSEide with FPC 2.4.4, FPC fixes_2_6 and Delphi 7 for comparison.
Delphi 7:
Borland Delphi Version 15.0
Copyright (c) 1983,2002 Borland Software Corporation
[...]
308390 lines, 6.20 seconds, 2279788 bytes code, 827729 bytes data.
Exe size: 3.23MB
FPC 2.4.4:
Free Pascal Compiler ve
Am 14.09.2011 04:22, schrieb Felipe Monteiro de Carvalho:
Is this possible in UNIX? I can see that in Windows you can use the
trick to use W versions which are identical except for the string type
and drop Windows 9x support, but is this really possible for the UNIX
syscalls? They expect UTF-8 n
Am 14.09.2011 07:50, schrieb Felipe Monteiro de Carvalho:
On Wed, Sep 14, 2011 at 5:50 AM, Martin Schreiber wrote:
Linux expects an array of bytes in filenames (no encoding, no utf-8) AFAIK.
That's a nice theory, but:
All Linux distributions that I know use utf-8
Android uses utf-8
On Wednesday 14 September 2011 17:02:14 Hans-Peter Diettrich wrote:
> Felipe Monteiro de Carvalho schrieb:
> > On Tue, Sep 13, 2011 at 9:23 PM, Michael Van Canneyt
> >
> > wrote:
> >> One with unicode string, one with ansistring. They will have the same
> >> code, but will be compiled twice, each
On Thursday 15 September 2011 10:27:28 Graeme Geldenhuys wrote:
>
> And considering the amount of text processing apps I have written
> (plenty of them), indexed character access is really not a top priority
> or a often used feature.
>
Graeme, please have look into:
http://www.lazarusfor
On Thursday 15 September 2011 11:06:00 Felipe Monteiro de Carvalho wrote:
> On Thu, Sep 15, 2011 at 10:59 AM, Martin Schreiber
wrote:
> > There are plenty of user problems with utf-8 character access and string
> > length. I assume 100% of them would be solved with utf-16.
>
On Thursday 15 September 2011 11:15:22 Graeme Geldenhuys wrote:
> > And now there should be an even more complex string type implemented?
>
> UTF-8 is not more complex at all.
A new encoding aware FPC string type is more complex.
Martin
___
fpc-devel m
Hi,
TField.SetData() in fixes_2_6 calls TField.Validate().
2.4.4 does not, trunk neither.
What are the plans for the upcoming release? Will FPC 2.6.0 call
TField.Validate() in TField.SetData()?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepasca
On Sunday 18 September 2011 10.50:26 Sven Barth wrote:
>
> Well... you can now take a look at trunk as well, because the changes
> from cpstrnew have been merged yesterday.
>
[...]
make[7]: Entering directory `/home/mse/packs/standard/svn/fp/trunk/rtl/linux'
/home/mse/packs/standard/svn/fp/trunk/
On Sunday 18 September 2011 12.44:26 Jonas Maebe wrote:
> On 18 Sep 2011, at 12:26, Sven Barth wrote:
> > For now you can apply the following patch as a workaround. The compiler
> > (and fpmake) will depend on the C-library then (which should not be the
> > case in the final solution).
>
> Not onl
On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote:
>
> Recently strings behavior was changed, they are now codepage-aware. The
> compiler can now implicitly convert strings from one encoding to another.
> To handle non-string data, you should use RawByteString type, or better
> yet non-st
On Friday 23 September 2011 16.32:21 Hans-Peter Diettrich wrote:
> >> So TBlobField.Value probably should be changed to array of byte and
> >> there should be a TField.AsByteArray property?
> >
> > Yes, Certainly. Or better even Stream objects.
>
> Why not use (or introduce) an TBlob type, match
Am 17.09.2011 10:18, schrieb Joost van der Sluis:
On Sat, 2011-09-17 at 10:56 +0200, Michael Van Canneyt wrote:
On Sat, 17 Sep 2011, Martin Schreiber wrote:
Hi,
TField.SetData() in fixes_2_6 calls TField.Validate().
2.4.4 does not, trunk neither.
Strange that 2.6 does this if trunk does
On Wednesday 12 October 2011 09.50:33 Marco van de Voort wrote:
>
> Undecided. But I'm very strongly against utf16 default on unix. I don't do
> much GUI on unix, and it would be insane to have a string type that is
> totally different from all other string types that I touch.
Do I understand it
On Wednesday 12 October 2011 11.13:45 Sven Barth wrote:
> Am 12.10.2011 10:59, schrieb Martin Schreiber:
> > On Wednesday 12 October 2011 09.50:33 Marco van de Voort wrote:
> >> Undecided. But I'm very strongly against utf16 default on unix. I don't
> >> do muc
On Wednesday 12 October 2011 14.17:57 Graeme Geldenhuys wrote:
>For those unfamiliar with Firemonkey, would you mind explaining further.
Read here for example:
https://forums.embarcadero.com/forum.jspa?forumID=380
> As for you statement regarding "do we need Unicode support everywhere?"
> Well
On Wednesday 12 October 2011 14.32:38 Jonas Maebe wrote:
> On 12 Oct 2011, at 14:17, Graeme Geldenhuys wrote:
> > eg: UTF-8 as native string type under *nix systems, and
> > UTF-16 under Windows. Why must some platforms get a speed penalty and
> > others not, when you force only one encoding on all
On Thursday 13 October 2011 13.41:24 Marco van de Voort wrote:
> > It's time to cut the gordian knot and take a decision.
> > All pros and contras have been discussed at great length meanwhile.
>
> Exactly. That's why a decision that is futureproof should be made, and not
> just start hacking, an
On Thursday 13 October 2011 13.56:50 Marco van de Voort wrote:
> In our previous episode, Martin Schreiber said:
> > Suggestion: Let it be as it is in fixes_2_6, add support for Unicode
> > resource strings and invest power into development of Delphi like
> > packages for ex
On Friday 14 October 2011 14.19:35 Michael Schnell wrote:
> On 10/14/2011 10:30 AM, Hans-Peter Diettrich wrote:
> > BTW2, the Lazarus IDE has big problems with the lack of dynamically
> > loadable packages, which still are *not* supplied by FPC. This will
> > possibly make impossible above separati
On Friday 14 October 2011 15.42:38 Michael Schnell wrote:
> On 10/14/2011 02:51 PM, Martin Schreiber wrote:
> > Ever tried to implement a form or any function which uses dynamic types
> > or common application elements in a dll/so?
>
> I understand that this is exactly wha
On Wednesday 02 November 2011 17.13:49 Jonas Maebe wrote:
> Yes, the result slower, but it's also correct (as in "it makes sure
> that the actual local time is returned"). Just like all UTF-16 code in
> the RTL is slower than what Martin Schreiber would like, and we did
On Wednesday 02 November 2011 17.46:07 Jonas Maebe wrote:
> Martin Schreiber wrote on Wed, 02 Nov 2011:
> > On Wednesday 02 November 2011 17.13:49 Jonas Maebe wrote:
> >> Just like all UTF-16 code in
> >> the RTL is slower than what Martin Schreiber would like, and we d
On Wednesday 02 November 2011 17.43:56 Martin Schreiber wrote:
> On Wednesday 02 November 2011 17.13:49 Jonas Maebe wrote:
> > Yes, the result slower, but it's also correct (as in "it makes sure
> > that the actual local time is returned"). Just like all UTF-16 code
On Thursday 03 November 2011 07.44:47 zeljko wrote:
> >
> > The results with 10'000'000 calls:
> >
> > FPC Now() MSEgui nowutc() MSEgui nowlocal()
> >
> > Linux
> >
> > 15.29s 3.39s 3.57s
> >
> > Windows
> >
> > 10.00s 1.22s 1.37s
>
> Have you
On Thursday 03 November 2011 08.11:16 Paul Ishenin wrote:
> 03.11.2011 15:04, Martin Schreiber wrote:
> > No, I can not use trunk because of cpstrnew. I'll try the file Michael
> > sent.
>
> If it is not difficult please explain exact problems with cpstrnew you
> hav
On Thursday 03 November 2011 08.04:17 Martin Schreiber wrote:
> On Thursday 03 November 2011 07.44:47 zeljko wrote:
> > > The results with 10'000'000 calls:
> > >
> > > FPC Now() MSEgui nowutc() MSEgui nowlocal()
> > >
> > > Lin
On Thursday 03 November 2011 09.08:35 zeljko wrote:
>
> That's pretty big difference. Can you compare NowReal() from attached
> program with your functions ?
>
Linux
FPC Now() MSEgui nowutc() MSEgui nowlocal() NowReal()
10.28s 3.45s 3.55s 9.86s
Martin
___
On 12/15/2011 07:52 AM, Felipe Monteiro de Carvalho wrote:
> In lazarus/components/lazutils/fileutil.pas there is:
>
> function FileSize(const Filename: string): int64;
>
> And as a bonus it works only with UTF-8
>
MSEgui has lib/common/kernel/msefileutils.pas:
"
type
ext1fileinfoty = record
Hi,
32 bit FPC default debug info (I assume STABS) shows the classname and the
function name in gdb stack traces which is very useful to navigate in
inherited calls for example.
64 bit FPC default debug info (I assume DWARF) shows the function names only.
Is it possible to list the classnames i
1 - 100 of 584 matches
Mail list logo
