it.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
hand is doing!! And who suffers,
the FPC users and framework developers.
Thanks Graeme, I wanted to write something similar but do not dare.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
.
TBookMarkStr is now marked deprecated. Revision 21155.
Thank you very much. That means it is not possible to work with fixes_2_6
without deprecated warnings? TDataset.Bookmark is of type TBookmarkStr but
TBookmarkStr is deprecated?
Martin
___
fpc
On Tuesday 01 May 2012 13:50:49 Sven Barth wrote:
On 01.05.2012 13:50, Martin Schreiber wrote:
Anyway, the change is undone, we're back on TBookmarkStr.
TBookMarkStr is now marked deprecated. Revision 21155.
Thank you very much. That means it is not possible to work with fixes_2_6
On Tuesday 01 May 2012 14:48:48 Michael Van Canneyt wrote:
On Tue, 1 May 2012, Martin Schreiber wrote:
On Tuesday 01 May 2012 13:50:49 Sven Barth wrote:
On 01.05.2012 13:50, Martin Schreiber wrote:
Anyway, the change is undone, we're back on TBookmarkStr.
TBookMarkStr is now marked
this is much work for the MSEide+MSEgui users to switch
the warning off before every use of TDataset.Bookmark and switch on again
afterwards.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
in the current release.
Exactly. Thanks DoDi for clarifying my concerns. :-)
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
bookmarkty in order to avoid the warning. FPC and Lazarus probably
can't do the same because of Delphi compatibility. Suggestion:
remove deprecated from TBookmarkStr in fixes_2_6.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
is TDataSet.Bookmark = TBytes.
Thanks. So the decision is to change TDataSet.Bookmark from TBookmarkStr to
TBytes in FPC 2.6.1 which breaks FPC 2.6.0 user and framework code?
Are there other breaking changes planned for FPC 2.6.1? cpstrnew related
maybe?
Martin
___
fpc
On Thursday 26 April 2012 06:58:01 Martin Schreiber wrote:
On Wednesday 25 April 2012 21:43:30 Marco van de Voort wrote:
In our previous episode, Marcos Douglas said:
Done, trunk r21037. Affected were tdataset and bufdataset (conversion
between Pbufbookmark and tbytes).
What about
that he prefers no
change at all to this API did not change.
Correct.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 25/04/2012 21:11, Amir wrote:
I am not sure what you mean be your program is not valid. I am
initializing Result. Modify its content and ...
I already observed that if I use either shortstring or use indices to
modify Result, this problem does not occur. But still I can't see what
note, it affects *all* user code with
TDataset.Bookmark the problem is not internal to the toolkits only.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
of TDataset.Bookmark to a variable.
As intended too?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tuesday 24 April 2012 23:13:26 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6
breaks FPC 2.6.0 compatible code. Is this intended?
Yes. It should not break proper code (since that would
Not sure if that is a known issue. Or considered an issue at all.
But on windows, if you specify the INSTALL_PREFIX with a trailing \
(which afaik is a normal way to specify a directory), install will fail.
make.exe install INSTALL_PREFIX=c:\FPC\tag_2_6_0\
On Saturday 21 April 2012 14:22:45 Jonas Maebe wrote:
On 07 Apr 2012, at 15:32, Martin Schreiber wrote:
Thanks. The normally 711KB MSEgui win32 minimal program is 694KB after
strip with -OWall/-Owall. There is an EAbstractError at startup.
Without symbolliveness it is 697KB
Am 07.04.2012 18:09, schrieb Martin Schreiber:
Am 07.04.2012 11:31, schrieb Martin Schreiber:
Hi,
A minimal MSEgui program compiled with FPC 2.6.0 is 711KB on
i386-win32 and
796KB on i386-linux.
BTW, the same MSEgui minimal program compiled with Delphi 7 has an exe
size of 571KB.
I made
. For Lazarus executable I got about 10% total size decrease.
I can not use FPC 2.7.1 for the testcase because of cpstrnew, sorry.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
at $B7CE9B7A :
Should whole program optimization work with FPC 2.6.0?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Saturday 07 April 2012 12:58:14 Jonas Maebe wrote:
On 07 Apr 2012, at 12:31, Martin Schreiber wrote:
I tried to optimize it with Whole Program Optimization.
On win32 I get:
Free Pascal Compiler version 2.6.0 [2011/12/25] for i386
Copyright (c) 1993-2011 by Florian Klaempfl
On Saturday 07 April 2012 13:23:39 Jonas Maebe wrote:
On 07 Apr 2012, at 13:15, Martin Schreiber wrote:
Thanks, where can I get that nm utility for win32?
Any distribution of the GNU binutils for win32 should include it. I don't
have Windows myself, but I suppose the mingw site would
Am 07.04.2012 11:31, schrieb Martin Schreiber:
Hi,
A minimal MSEgui program compiled with FPC 2.6.0 is 711KB on i386-win32 and
796KB on i386-linux.
BTW, the same MSEgui minimal program compiled with Delphi 7 has an exe
size of 571KB.
Martin
___
fpc
On 20/03/2012 07:41, Paul Ishenin wrote:
20.03.2012 15:39, Graeme Geldenhuys написал:
Maybe I'm not understanding this correctly, but why would you want
visibility restrictions on debug information? Surely when debugging,
you want access to ALL data - thus public visibility across the board
on Win 32
Compiling .\winunits-base\src\typelib.pas
typelib.pas(371,71) Hint: Local variable Handle does not seem to be
initialized
typelib.pas(493,33) Hint: Local variable sl does not seem to be
initialized
typelib.pas(562,48) Hint: Local variable sMethodName does not seem to
be initialized
On 20/03/2012 12:55, Ludo Brands wrote:
typelib.pas(1353,48) Error: range check error while
evaluating constants
(-1 must be between 0 and 4294967295)
Can you raise a mantis issue? I'll fix this. According to msdn
http://msdn.microsoft.com/en-us/library/cc237755%28v=prot.10%29.aspx the
function
Is this an FPC issue or gdb?
Tested with fpc 2.6 / gdb 7.3-2 , win 32
Stabs, seems to have the right sections for fields.
Stabs also shows methods, but they seem to be without any info about
class sections
Dwarf (see below) everything seems to be public:
Dwarf does not seem to show methods
I know -gp works for stabs.
Is there a way for dwarf too?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 08/03/2012 13:34, Martin wrote:
On 08/03/2012 13:08, michael.vancann...@wisa.be wrote:
On Thu, 8 Mar 2012, Martin wrote:
Further more:
the program below, does not crash in delphi (turbo delphi)
I also noticed. I suspect the problem is the owner; If it gets a free
notification
I found a behaviour, of which I am not sure, if it is intended. Maybe
someone can comment
My understanding is that FreeNotification are *always* set up
bi-directional ?
At least
C1.FreeNotification(C2);
will set up for C1 to inform C2, and for C2 to inform C1 whichever is
destroyed first
Further more:
the program below, does not crash in delphi (turbo delphi)
On 08/03/2012 09:56, Martin wrote:
I found a behaviour, of which I am not sure, if it is intended. Maybe
someone can comment
My understanding is that FreeNotification are *always* set up
bi-directional ?
At least
C1
On 08/03/2012 13:08, michael.vancann...@wisa.be wrote:
On Thu, 8 Mar 2012, Martin wrote:
Further more:
the program below, does not crash in delphi (turbo delphi)
I also noticed. I suspect the problem is the owner; If it gets a free
notification, it should pass it to all the children.
I
On 08/03/2012 13:34, Martin wrote:
On 08/03/2012 13:08, michael.vancann...@wisa.be wrote:
On Thu, 8 Mar 2012, Martin wrote:
Further more:
the program below, does not crash in delphi (turbo delphi)
I also noticed. I suspect the problem is the owner; If it gets a free
notification
On 08/03/2012 13:44, Martin wrote:
In the following code, I thing is the problem:
Procedure TComponent.Notification(AComponent: TComponent;
Operation: TOperation);
Var Runner : Longint;
begin
If (Operation=opRemove) and Assigned(FFreeNotifies) then
begin
FFreeNotifies.Remove
overflows nor make code
slower, so it should be fixed.
Agreed, please fix it.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
, PointerString or whatever, too)
allowing for the legacy string operations in an appropriately overloaded
way ?
Or why not let it be as it is in FPC 2.6 and use UnicodeString for
visible GUI purpose?
Martin
___
fpc-devel maillist - fpc-devel
://docwiki.embarcadero.com/RADStudio/en/Declaring_and_Initializing_Strings
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 28.02.2012 09:46, schrieb Sven Barth:
You are right, I checked the code of SetLength for arrays and strings
and only arrays use FillChar. Nevertheless there is no other operation
you can use for arrays.
Same in Delphi?
Martin
___
fpc-devel
Am 28.02.2012 10:10, schrieb Sven Barth:
Am 28.02.2012 09:07, schrieb Martin Schreiber:
Am 28.02.2012 09:46, schrieb Sven Barth:
You are right, I checked the code of SetLength for arrays and strings
and only arrays use FillChar. Nevertheless there is no other operation
you can use for arrays
Am 28.02.2012 10:38, schrieb Marco van de Voort:
In our previous episode, Martin Schreiber said:
I read that we should use TBytes instead of AnsiString in order to
implement combined binary/character buffers with automatic memory
management. With AnsiString we used setlength() in order
Am 28.02.2012 11:59, schrieb Marco van de Voort:
In our previous episode, Martin Schreiber said:
If you care, you can do manual management.
Yup, MSEgui has allocuninitedarray() for the purpose. I don't think it
is more clean or secure than the old ansistring method because it
depends
Am 28.02.2012 12:18, schrieb Marco van de Voort:
In our previous episode, Martin Schreiber said:
think that is still bad though, but if you switch typing string to explicit
ansistring, there is no rush), but I think at least public
programming interfaces should be free of such gotchas
On 29/02/2012 01:40, Paul Ishenin wrote:
28.02.2012 9:11, Martin пишет:
Attached.
It needed 3 units,
accessing Foo in the same unit, in which it is declared (unit2) compiles
(not tested if it runs...)
You found some bug in the compiler. Property can only be declared
inside a structure
On 29/02/2012 02:20, Martin wrote:
On 29/02/2012 01:40, Paul Ishenin wrote:
28.02.2012 9:11, Martin пишет:
Attached.
It needed 3 units,
accessing Foo in the same unit, in which it is declared (unit2)
compiles
(not tested if it runs...)
You found some bug in the compiler. Property can
Defining a property in the interface section (outside a class), that
refers to methods in another unit, gives an *unexpected* error. It may
well be not allowed and then should give an error, but the right error
in the right place.
Btw, only tested with 2.4.4, apologies if that is fixed in
On 28/02/2012 00:46, Paul Ishenin wrote:
28.02.2012 3:01, Martin пишет:
Defining a property in the interface section (outside a class), that
refers to methods in another unit, gives an *unexpected* error. It may
well be not allowed and then should give an error, but the right error
in the right
setlength() fills the buffer with zeros. What should we use instead?
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 28.02.2012 08:06, schrieb Michael Schnell:
On 02/28/2012 05:04 AM, Martin Schreiber wrote:
I read that we should use TBytes instead of AnsiString in order to
implement combined binary/character buffers with automatic memory
management.
Why ?
Because of Delphi compatibility and code
If I have a class TFoo in UnitFoo, then I can :
unit UnitOther;
uses UnitFoo;
interface
type TFoo = UnitFoo.TFoo;
Now people who use UnitOther, can use TFoo, but do nut need to
explicitly use UnitFoo.
I am looking for a way to do that with procedures.
Of course I can declare them
in DWARF too?
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
In light of a recent mail thread on the topic and
http://bugs.freepascal.org/view.php?id=21370
From: rtl\inc\lnfodwrf.pp
function DwarfBackTraceStr(addr : Pointer) : shortstring;
var
...
Success : boolean;
begin
{ reset to prevent infinite recursion if problems inside the code }
I have some code, and an error, that I can not explain (fpc 2.4.4 and 2.6)
the base class defines
public
property Editor: TCustomSynEdit read GetEditor write SetEditor;
in the inherited class, I can access Editor (of course I can)
but I add
published
property Editor:
Any body an idea, in whic context contains may be a keyword?
Original Message
Subject:synedit questiions
Date: Mon, 30 Jan 2012 12:51:00 +0400
From: Anton ast@mail.ru
Reply-To: A.S. ast@mail.ru
Organisation: [AST]
To: Martin laza...@mfriebe.de
On 26/01/2012 13:56, Pierre Free Pascal wrote:
Yes, you are right...
I just committed a fix (together with multi-threaded windows executable
support in trunk)
If you have svn trunk, could you check that revision 20181 fixes
the problem you report?
Thanks in advance,
It looks right from
I ve been playing around with -gc and I found something suspect in heaptrc
procedure CheckPointer(p : pointer); [public, alias : 'FPC_CHECKPOINTER'];
p is a pointer, that should be somewhere *inside* an allocated block
of mem
pp:=loc_info^.heap_mem_root;
while ppnil do
begin
{
Only tested with 2.4.4; so if changed in 2.6
in unit2
TFoo = class(TObject)
private
FBar: integer;
public
property Bar: integer read FBar write FBar;
end;
which means in unit1, it is not allowed to access
TFoo.FBar
But it can be done:
property Num: Integer read
On 04/01/2012 17:27, Jonas Maebe wrote:
On 04 Jan 2012, at 18:13, Martin wrote:
Only tested with 2.4.4; so if changed in 2.6
http://wiki.freepascal.org/User_Changes_2.6.0#Inaccessible_symbols_and_properties
I just upgraded to 2.6.0 - It still compiles (recompiling fpc trunk now,
may
On 04/01/2012 20:01, Pete Cervasio wrote:
On Wednesday, January 04, 2012 01:26:52 pm Martin wrote:
TForm1 = class(TForm)
public
FFoo: TFoo;
property Num: Integer read FFoo.FBar;
end;
Just a 'for your info' note: Kylix doesn't allow the above. Nor does
it allow accessing the property
Florian wrote at http://bugs.freepascal.org/view.php?id=20907
FPC has a good enough dfa, however it is only activated when compiling
with -Oodfa:
c:\fpc\svn\compilerfpc ..\tw20907 -vw -Oodfa
Is that documented somewhere ? Is that production read or beta?
fpc -i only lists:
Supported
: ext1fileinfoty;
extinfo2: ext2fileinfoty;
end;
function getfileinfo(const path: filenamety; var info: fileinfoty): boolean;
//false if not found
As a bonus it works with UnciodeString. ;-)
Martin
___
fpc-devel maillist - fpc
patch for getttimeofday ?
No, I can not use trunk because of cpstrnew. I'll try the file Michael sent.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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
have in a separate thread
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()
Linux
15.29s 3.39s 3.57s
Windows
10.00s
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 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 didn't
change it to UCS-2 when he
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 didn't
change it to UCS-2 when he
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 in
the RTL is slower than what
Is there a maximum number of params that a function can take?
Before the compiler gives the error:
WatchesPrg.pas(274,3) Error: Wrong number of parameters specified for
call to FooFunc
Despite, they are the same number? that is, I f I comment out one param
on both sides (calling, and
to implement a form or any function which uses dynamic types or
common application elements in a dll/so?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 what Delphi-type runtime packages
Is there a known issue on Mac?
The following was observed on 2 different 32 bit Mac:
compiling from lazarus tests/lazutils/testunicode.lpi
with -gs / also entire LCL compiled with -gs / standard fpc 2.4.4
installation (I would assume that does not have dwarf? but I do not know)
info line
On 13/10/2011 09:37, Jonas Maebe wrote:
Is there a table somewhere about which debug info types are default in
each operating system?
No, and such table will not be made because it's an implementation
detail. If you require a particular debug information format, specify
it. Anything else
time FPC needs to catch up
again.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 example.
Or improved
it right that the constants, variables and properties in
classes.pas and db.pas which currently have the type string will be utf-8 on
Unix and utf-16 on Windows?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
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 much GUI on unix, and it would be insane to have
? What is the benefit of non ASCII Pascal identifiers at the
expense of performance and simplicity?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
, and
with code written for earlier Delphi/FPC versions.
Interesting thread:
https://forums.codegear.com/thread.jspa?threadID=61763tstart=0#399861
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc
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 contains utf8, but seems not to be
On 10/10/2011 21:56, Jonas Maebe wrote:
2- It should have (dont know if currently has) a compiler switch to change the
default code page to UTF8 or whatever, so all variables with type String will
map to UTF8String.
I doubt that such a feature will be added. If you want that, declare your own
On 10/10/2011 22:36, Jonas Maebe wrote:
On 10 Oct 2011, at 23:11, Martin wrote:
On 10/10/2011 21:56, Jonas Maebe wrote:
2- It should have (dont know if currently has) a compiler switch to change the
default code page to UTF8 or whatever, so all variables with type String will
map
On 10/10/2011 23:19, Paul Ishenin wrote:
11.10.2011 6:10, Martin wrote:
I wasn't askin for changing the default.
just for how to do
procedure foo(x: utf8string); begin end;
var a: string; //ansistring, but contains already utf8
foo(a); // do not convert
use
foo(x: rawbytestring)
Not good
Just out of curiosity, and without even being sure, if a real use case
for something like this ever exists
With the new strings, the encoding is part of the data, not the type.
However most types force a specific encoding, therefore conversion occurs.
rawbytestring does not force a specific
On 11/10/2011 02:46, Marco van de Voort wrote:
In our previous episode, Martin said:
Now my question.
Is there (or going to be) an encoding, that is unknown and will never
be converted. but can be assigned to any of the types?
Afaik, there is no such thing in Delphi.
Slight change in topic
-gc, is apparently only useful in very limited scenarios, such as
applications, that have no interaction with the OS at all, or can
otherwise gurantee, never to access any memory that was returned by (and
therefore allocated by) the OS.
An LCL app can not guarantee that...
Yet what I am
On 09/10/2011 21:44, Jonas Maebe wrote:
On 09 Oct 2011, at 22:34, Martin wrote:
Every class or dyn array should be in a block of memory allocated by the fpc
heap mgr (probably even always at the start (or fixed offset) of such a block).
That is incorrect: classes can override newinstance
If I run the attached project compiled with fpc trunk (maybe a week
old), it runs 5 times slower than when compiled with fpc 2.4.4
First question, can someone else reproduce that?
I couldn't find much difference in the output of -al (except some naming
convention), so I wonder..
Trying to compile lazarus with trunk fpc:
Any ideas?
make.exe[2]: Entering directory `C:/lazarus_latest/ide'
C:/FPC/trunk_gw/bin/i386-win32/fpc.exe -gl -dlclwin32
-Fu../lcl/units/i386-win32 -Fu../lcl/units/i386-win32/win32
-Fu../components/codetools
/units/i386-win32
exitcode (normal if you did not specify a source file to be compiled)
=thread-exited,id=1,group-id=i1
=thread-group-exited,id=i1,exit-code=01
*stopped,reason=exited,exit-code=01
(gdb)
bt
bt\n
No stack.\n
^done
(gdb)
On 08/10/2011 13:59, Martin wrote:
Trying to compile lazarus with trunk fpc:
Any
On 02/10/2011 14:05, Joost van der Sluis wrote:
On Sat, 2011-10-01 at 09:08 +0200, Joost van der Sluis wrote:
On Sat, 2011-10-01 at 01:05 +0100, Martin wrote:
Ok, seems to have big issues with strings in fields.
Ow, man.. That's probably difficult again. While evaluating values, it
does
On 02/10/2011 15:02, Joost van der Sluis wrote:
btw: I could not reproduce the external-linker and stabs crashes. Can
you give me some more info?
Hm, I have to check what version of the external linker I have.
C:\FPC\trunk\bin\i386-win32ld.exe -v
GNU ld version 2.16.91 20050827
Maybe time to
I noticed, when I build fpc, then I get cpu usage between 70% and 100%.
So it appears that both cores of my pentium are used.
But when a package is compiled using fpmake, then it drops to 50%, so
apparently only one core is used?
Is that correct? Does the old Makefile driven compilation use
On 30/09/2011 10:44, Henry Vermaak wrote:
Hi list
Thinking more about the alignment problems on arm and elsewhere, I was
wondering how hard it would be to implement something like gcc's
-Wcast-align. Here's a description from the man page:
Warn whenever a pointer is cast such that the
on i386 regarding the calling conventions remain, and there
seems to be some problems still with overridden functions)
Please test this gdb-version, and tell me about your experiences.
Especially Martin. ;)
Will do (weekend just ahead, what a coincidence... :) )
Oh, you can download it here
On 30/09/2011 15:45, Joost van der Sluis wrote:
On Fri, 2011-09-30 at 21:47 +0800, Paul Ishenin wrote:
30.09.2011 21:02, Joost van der Sluis wrote:
Hi all,
For all those who are interested in new debug-features of fpc and gdb, I
have cross-compiled a gdb-executable for Windows.
It's based on
On 30/09/2011 16:22, Joost van der Sluis wrote:
On Fri, 2011-09-30 at 15:54 +0100, Martin wrote:
Now reading it again, does it mean:
1) gdb can (magically?) get the return value of a function/method, but
WITHOUT calling/invoking the function (e.g. for properties)
2) gdb can evaluate the type
On 30/09/2011 14:02, Joost van der Sluis wrote:
Please test this gdb-version, and tell me about your experiences.
Especially Martin. ;)
Oh, you can download it here:
http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip
It crashes when -Xe (external linker) was used. Also crashes
On 30/09/2011 23:23, Martin wrote:
On 30/09/2011 14:02, Joost van der Sluis wrote:
Please test this gdb-version, and tell me about your experiences.
Especially Martin. ;)
Oh, you can download it here:
http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip
It crashes when -Xe
On 27/09/2011 16:58, Joost van der Sluis wrote:
Hi all,
I've just committed a fix (r19253) which makes it possible to call
virtual methods within GDB. (Or other Dwarf-debuggers, when they
support that properly)
Only problem is that when GDB is in Pascal mode, it won't work. I have
written a
types like (dynamic) array of byte.
So TBlobField.Value probably should be changed to array of byte and there
should be a TField.AsByteArray property?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman
701 - 800 of 1522 matches
Mail list logo
