On Tuesday 25 December 2012 18:01:50 Florian Klaempfl wrote:
Am 25.12.2012 15:28, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names (up till 10 times slower, even without linking
On Monday 24 December 2012 10:23:00 Sven Barth wrote:
Am 24.12.2012 07:48 schrieb Martin Schreiber mse00...@gmail.com:
On Sunday 23 December 2012 17:44:53 Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Do you know how RTTI will be encoded?
I would
Writing this from my laptop I do not currently have all the various
checkouts to look at the exact changes myself. But enquiring based on
the reports I have read.
http://bugs.freepascal.org/view.php?id=23523
From FPC trunk r23202 log:
* Include regdef.inc only if XMLREG is defined
On 24/12/2012 12:17, Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
too. So if somebody implements non ASCII identifiers because he needs a
second source Delphi compiler it will be merged because the addition does not
break existing code. I assume utf-8 identifiers
On 24/12/2012 13:05, Marco van de Voort wrote:
In our previous episode, Martin said:
Hm that makes it easy to have an incomplete list, that could later
become a problem
half-width spaces etc..., control chars (RTL/LTR...), currently unused
codepoints (that could become anything in future
. Not in the near future but
the primary goals are defined already:
- Back to the roots.
- Add the necessary to build the most productive universal programming
language.
- Remove the not necessary.
- Produce at least as good code as Delphi 7.
- Compile at least as fast as Delphi 7.
Martin
On Monday 24 December 2012 17:45:34 Henry Vermaak wrote:
On Mon, Dec 24, 2012 at 05:19:58PM +0100, Martin Schreiber wrote:
BTW, I actually think about to fork Free Pascal. Not in the near future
but the primary goals are defined already:
- Back to the roots.
What are the roots?
- Add
On Sunday 23 December 2012 11:12:42 Leif Ekblad wrote:
IMO, I wouldn't support wide-character (UnicodeString) strings for anything
new.
I don't like to read that. ;-)
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
On Friday 21 December 2012 13:26:12 Michael Van Canneyt wrote:
After that there will be 2 RTLs:
1. The classical RTL, compatible with what you have now.
2. The unicode-string RTL which will use the namespaces of Delphi.
Do you know how RTTI will be encoded?
Martin
identifiers.
What will FPC do?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Friday 21 December 2012 18:16:06 Florian Klämpfl wrote:
Am 21.12.2012 09:23, schrieb Martin Schreiber:
On Tuesday 18 December 2012 19:07:47 Florian Klämpfl wrote:
Am 17.12.2012 10:36, schrieb Graeme Geldenhuys:
Hi,
Any FPC developer willing to comment on the status of some
to the list by me.
Additionally many members of the Free Pascal community, including me, don't
know English language so writing explicit statements is unavoidable.
[...]
Apart from that, happy Midwinter Solstice everyone.
Yup. :-)
Martin
___
fpc
the quality of MSEide+MSEgui I help independent whether
I like the idea or not.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Saturday 22 December 2012 19:09:27 Florian Klämpfl wrote:
Am 22.12.2012 11:23, schrieb Martin Schreiber:
I propose to extend and render more precisely the mission goals of FPC
and to concentrate the power on the defined goals.
And you think people will work on this defined goals instead
pieces and necessary boring improvements should be done
before adding sexy new things?
Or is FPC simply a playground for the FPC-developers? Then that should be
communicated too and I probably was wrong to invest so much time into the
development of MSEide+MSEgui.
Martin
I am trying to figure out how to do that, or what I do wrong. I found a
page about $codepage, but it did not help
http://wiki.freepascal.org/LCL_Unicode_Support
I didnt find the fpc specific page, if exists (I suspect it does)
I am calling a function function Foo(A:string) {$mode objfpc}{$H+}
On 07/12/2012 13:34, Jonas Maebe wrote:
On 06 Dec 2012, at 22:45, Martin wrote:
I am currently fixing some of the PascalScript issues. When working
with strings, it sometimes needs to inc/dec the refcount (or access
the length)
Current code does calculate the position of that data
Does anyone know how self is passed on PPC or ARM?
On the one hand IRRC I read self is passed as additional param at the
end of the list.
But looking at intel code 32 bit, it looks like it always goes into EAX
(calling method register)
On Intel 64 bit it is RCX or RDI depending on it in
On 07/12/2012 17:03, Jonas Maebe wrote:
On 07 Dec 2012, at 17:51, Martin wrote:
Does anyone know how self is passed on PPC or ARM?
On the one hand IRRC I read self is passed as additional param at the end of
the list.
I don't think that has ever been the case.
Ok then I IIRCed wrong
On 07/12/2012 17:22, Jonas Maebe wrote:
On 07 Dec 2012, at 18:10, Martin wrote:
But today, there is no better way, to use PascalScript in a compiled app. Once
a released FPC offers a better way, well great. But till then, I must go the
risky way (or not go at all).
Mixing dynamically
On 07/12/2012 17:03, Jonas Maebe wrote:
On Intel 64 bit it is RCX or RDI depending on it in Windows or not
What on the others, fixed register, or simply as if it was the last param?
It is *currently* (I don't think we specify anywhere how or in what order
hidden parameters are passed) always
On 07/12/2012 18:53, Martin wrote:
On 07/12/2012 17:03, Jonas Maebe wrote:
On Intel 64 bit it is RCX or RDI depending on it in Windows or not
What on the others, fixed register, or simply as if it was the last
param?
It is *currently* (I don't think we specify anywhere how or in what
order
On 06/12/2012 13:16, Jonas Maebe wrote:
On 06 Dec 2012, at 14:03, Martin wrote:
Yet what I do not understand, is why I get that message as warning
(as opposed to a hint). If I understand it right (I have not tested,
maybe it gives a warning on 64 bit target too, if so ignore the
rest
Not the best thing to do, I know the risks (or I think I do). Also got
some alternative ideas in mind... But in case.
I am currently fixing some of the PascalScript issues. When working with
strings, it sometimes needs to inc/dec the refcount (or access the length)
Current code does
With -WB123400 I can relocate the code. For example to enforce 64
bit addresses, with an upper DWord not equal 0 (and therefore the
ability to find related problems)
But the data segment is not affected. e.g. Objects are still at lower
addresses. Is there a way to force them too?
having a
procedure Foo(var x: TSomeClass);
calling it with
Foo(TSomeClass(ObjOfBaseClassOfTSomeClass));
It compiles with 2.6.0.
Just want to be sure, it wont stop in future versions.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Ok now I am curious
SomePointer := Pointer(PtrInt(SomeNumber))
SomePointer := Pointer(PtrUInt(SomeNumber))
The 2nd gives the warning.
Warning: Conversion between ordinals and pointers is not portable
But the first does not.
Yet PtrInt/PtrUInt are both the size of pointer?
it from same bigger code.
If compiled, with PtrUint (as is below)
Free Pascal Compiler version 2.6.0 [2012/01/04] for i386
Compiling C:\Users\martin\AppData\Local\Temp\project1.lpr
project1.lpr(11,28) Warning: Variable p does not seem to be initialized
project1.lpr(11,11) Warning: Conversion between
On 30/11/2012 14:28, Reimar Grabowski wrote:
On Fri, 30 Nov 2012 01:21:28 +
Martin laza...@mfriebe.de wrote:
Hi,
I need some testers for all the different available platforms.
Trying to run TestScriptProcs I get the following compilation error (along with
a bunch of warnings
Just to confirm my observations. (again trying to get pascal script to work)
64 bit windows
procedure FOO(Sender: TSynEdit; const M: String; const P1, P2: TPoint);
const P1, P2: TPoint versus P1, P2: TPoint
if const is NOT used, then TPoint is put into a register
if const is used, then TPoint
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?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
It does not matter if I compile it with stdcall, cdecl, pascal. The
below on a 32 bit intel mac (fpc 2.6.0) always returns result in 2
registers (eax, edx)
Is there a way to change this (some declaration in the source, some switch)?
function Point(AX, AY: Integer): TPoint;
begin
with Result
On 12/11/2012 12:41, Jonas Maebe wrote:
On 11 Nov 2012, at 20:56, Martin wrote:
See http://forum.lazarus.freepascal.org/index.php/topic,18816.0.html
I did test myself. Same result on win32. (Run any part of the IDE
debugger test suite). Tested versions of gdb 6.3 to 7.5
It works fine
Trying to compile the fixes_2_6 branch rev 22875
Using a 2.6.0 fpc as starter
starting on a clean directory (deleted all non svn files, and make clean )
%PATH% is set to the starting fpc dir only (+includes ; so it is
detected as windows)
Not sure where to look right now. Error below is from
On 11/11/2012 14:06, Jonas Maebe wrote:
On 11 Nov 2012, at 15:02, Martin wrote:
Trying to compile the fixes_2_6 branch rev 22875
Using a 2.6.0 fpc as starter
starting on a clean directory (deleted all non svn files, and make clean )
%PATH% is set to the starting fpc dir only (+includes ; so
See http://forum.lazarus.freepascal.org/index.php/topic,18816.0.html
I did test myself. Same result on win32. (Run any part of the IDE
debugger test suite). Tested versions of gdb 6.3 to 7.5
The filename is recognised (when sending info line
WatchePrg.pas:100). Sending a different filename
.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 15/09/2012 02:19, Martin wrote:
The unit contains 3 declarations (just picking one example, may be
similar for other functions)
function WSASocketA( af, iType, protocol : Longint; lpProtocolInfo :
LPWSAProtocol_InfoA; g : GROUP; dwFlags : DWORD ): TSocket; stdcall;
external WINSOCK2_DLL
The unit contains 3 declarations (just picking one example, may be
similar for other functions)
function WSASocketA( af, iType, protocol : Longint; lpProtocolInfo :
LPWSAProtocol_InfoA; g : GROUP; dwFlags : DWORD ): TSocket; stdcall;
external WINSOCK2_DLL name 'WSASocketA';
function
with gdb and the ATMEL gdb server.
I use it in combination with the AVR ONE! debug interface and the gnu tool
chain.
http://sourceforge.net/projects/mseide-msegui/
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
To start with, I have very sittle info, so this may not lead anywhere.
But then again, I was unable to reproduce it myself. So I would
appreciate any hint what I may be looking for...
I discovered this while debugging a PascalScript issue.
The environment:
- A macbook. 64 bit intel (Owned by
On 06/09/2012 22:18, Jonas Maebe wrote:
On 06 Sep 2012, at 23:00, Martin wrote:
Stopping in the disassemble view (using asm single stepping) the point in
classes had the below asm:
CLASSES_POINT$LONGINT$LONGINT$$TPOINT
0010BAF0 83ec0c sub$0xc,%esp
0010BAF3 890424
From http://bugs.freepascal.org/view.php?id=22801
You should not pass quotes. The quotes are only needed in a shell.
That is not always possible. And the quotes work on most platforms.
I know TProcess changed from a single command-line to a listof
arguments. So I couldn't find the User
For reference http://bugs.freepascal.org/view.php?id=22751
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 05/09/2012 09:55, michael.vancann...@wisa.be wrote:
On non-windows, each element in the params list is passed as-is in the
argv
array; No changes are performed at all.
Does FPC offer a utility function to break a shell style commandline
into the correct arguments?
--foo=abc
On 05/09/2012 09:55, michael.vancann...@wisa.be wrote:
On non-windows, each element in the params list is passed as-is in the
argv
array; No changes are performed at all.
FPC itself supplies a function
function RunCommand(const cmdline:string;var
outputstring:string):boolean; deprecated;
On 05/09/2012 10:38, Martin wrote:
function RunCommand(const cmdline:string;var
outputstring:string):boolean; deprecated;
Sorry seen to late, it is deprecated...
Seems that FPC is missing the functionality for commandline (which is
a property that existed for very long). Seen
Does this
1) prevent functions declared in this unit from being inlined (in this
or other units)
2) functions from other units, that are called in this unit from being
inlined:
I get 1, but not 2:
program project1; {$mode objfpc}{$H+} {$INLINE OFF}
uses Classes, types;
function MyPoint(X,
Does anyone know if that is valid intel style assembler?
push [rdx]
FPC complains (on intel /win 64 bit).
It's from PascalScript code. (Source\x64.inc) I wonder how to get it work...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
this will never happen.
Me too.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I might be doing something wrong.
I was trying to build a cross compiler (well I took a script that is to
build a arm cross, and only did a search and replace... So there is
plenty of room for error on by side.
Before I go and look deeper: Should it work. Or is the below correct and
it is
On 24/08/2012 12:04, Jonas Maebe wrote:
Martin wrote on Fri, 24 Aug 2012:
On 08/08/2012 15:37, Jonas Maebe wrote:
Martin wrote on Wed, 08 Aug 2012:
Out of curiosity. Is there an optimization like this
[removing calculation/load of unused parameters]
No.
Are you sure? It seems
On Wednesday 22 August 2012 02:01:09 Hans-Peter Diettrich wrote:
You still miss the point. Why deal with single characters, by index,
when working with substrings also covers the single-character use?
Why not if it is faster, simpler and more intuitive for beginners?
Martin
On Wednesday 22 August 2012 21:47:53 Felipe Monteiro de Carvalho wrote:
On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber mse00...@gmail.com
wrote:
I am not talking about Unicode. I am talking about day by day programming
of an average programmer where the live is easier with utf-16 than
(the galaxy coverage).
The non-fixed char length UTF-16 (UCS-2 + surrogate pairs) looks less
efficient than UTF-8 almost from any look point.
I disagree. Handling 1..4(6) bytes is less efficient than handling surrogate
*pairs*.
Martin
___
fpc-devel
Am 21.08.2012 09:31, schrieb Graeme Geldenhuys:
On 21 August 2012 09:13, Martin Schreibermse00...@gmail.com wrote:
I disagree. Handling 1..4(6) bytes is less efficient than handling surrogate
*pairs*.
Yet another myth
Ehm, I did both. In the beginning MSEgui switched from Widestring
with the current
approach, then 2.8.0 will use this
- nobody works on it, then 2.8.0 comes with unicodestring=utf-16 always.
IMO unicodestring should be the same on all platforms, because
otherwise the character size switches per platform, which is hard to
test and asking for trouble.
100% agreed.
Martin
in a UnicodeString the program can use the simple approach by character
(code unit) index. It is even possible for known Chinese symbols of the
BMP. And a simple if for surrogate pairs is more efficent as a 4-stage
case for utf-8.
Martin
___
fpc-devel maillist
and Pascal beginners read the
German Lazarus Forum or freepascal.ru. Why should we design programming
so that it complicates the work for them? Anyway, I don't care, do what
you want but please implement Unicode resource strings in FPC compiler.
Thanks, Martin
%40lists.freepascal.org/msg07520.html
http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg03010.html
http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg03018.html
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
better
suit the users needs.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Monday 20 August 2012 11:10:27 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations
which don't need to be strictly Delphi compatible and therefore can
better suit the users needs.
IMHO
that good Unicode support in FPC sounds as if all the
important things of Unicode are in FPC and you don't need extra libs.
True. I actually meant the possibilities of the compiler.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
building the
resource string tables. Another question is the encoding of the *.rst files
we need in the MSEi18n tool.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Monday 20 August 2012 14:32:22 Anton Kavalenka wrote:
Resources from both Windows and Linux EXE are extracted in UTF-8 (not
win1251).
Do you compile with -Fcutf8 or {$codepage utf8}?
Martin
___
fpc-devel maillist - fpc-devel
On Monday 20 August 2012 14:45:34 Anton Kavalenka wrote:
On 20.08.2012 15:45, Martin Schreiber wrote:
On Monday 20 August 2012 14:32:22 Anton Kavalenka wrote:
Resources from both Windows and Linux EXE are extracted in UTF-8 (not
win1251).
Do you compile with -Fcutf8 or {$codepage utf8
/FPC_Unicode_support
which answers such questions?
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Sunday 19 August 2012 09:41:48 Paul Ishenin wrote:
19.08.12, 15:18, Martin Schreiber wrote:
Hi,
In 2008 and 2011 there were threads about FPC and Unicode resource
strings with the conclusion that FPC does not support them.
Are Unicode resource strings implemented in FPC now? I did
Out of curiosity. Is there an optimization like this (or is it possible?
procedure Foo(a:String; B: Integer); inline; // inline is optional
begin
// EMPTY
end;
This is a plain procedure, not a method, not overloaded, not virtual.
And the parameters are both not used in the procedure (But
On 08/08/2012 15:37, Jonas Maebe wrote:
[removing calculation/load of unused parameters]
No.
I assumed that...
(or is it possible?
After the body of the called routine has been parsed, it would be
possible in theory (with indeed all the caveats the compiler would
have to take care of
On 08/08/2012 15:47, michael.vancann...@wisa.be wrote:
On Wed, 8 Aug 2012, Jonas Maebe wrote:
(or is it possible?
After the body of the called routine has been parsed, it would be
possible in theory (with indeed all the caveats the compiler would
have to take care of such as side effects --
CapacityPrivate: PtrInt read FCapacity
write FCapacity; deprecated;
to TMemoryStream?
Thank you very much,
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Sunday 22 July 2012 10:52:33 Michael Van Canneyt wrote:
Numbers, not count. I want to know which bugs are worked around by
crackers.
That's easy: 0 bugs.
Sorry, there where bugs in the past and there probably will be in the future.
Martin needs the crackers for some mse* features
On Sunday 22 July 2012 11:28:22 Michael Van Canneyt wrote:
On Sun, 22 Jul 2012, Martin Schreiber wrote:
On Sunday 22 July 2012 10:52:33 Michael Van Canneyt wrote:
Numbers, not count. I want to know which bugs are worked around by
crackers.
That's easy: 0 bugs.
Sorry, there where
On Sunday 22 July 2012 12:06:31 Jonas Maebe wrote:
On 22 Jul 2012, at 11:50, Martin Schreiber wrote:
Sorry Michael, I do not trust that the effort is worth the outcome for
me.
You're really putting us between a rock and a hard place here. It's quite
tempting to retort with the next time
classes.pp except for TObject is safe?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
not?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
to write into some field, a developer may have reasons
to do so.
Exactly.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 14/07/2012 20:46, Jonas Maebe wrote:
That may actually lead to quite some troubles: if someone recompiles the RTL without
optimizations, then your class crackers also have to change that setting. And there's no
way to detect how the RTL (or in general: units containing classes you are
On 21/07/2012 16:55, Ivanko B wrote:
The problem now is that cracker classes can't be used in future anymore
because of the new class field ordering optimisation, so I dared to ask.
So, is it possible to design the new feature in such way that to have
an option to proceed using cracker
RTL's or the users must compile the RTL for non Lazarus use.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
?
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Wednesday 18 July 2012 08:19:02 Martin Schreiber wrote:
Used in order TParams create tmseparam items instead of TParam:
TCollection:
- FItemClass
Probably can be solved in a forked db.pas
Martin
___
fpc-devel maillist - fpc-devel
On Wednesday 18 July 2012 09:43:16 michael.vancann...@wisa.be wrote:
On Wed, 18 Jul 2012, Martin Schreiber wrote:
On Wednesday 18 July 2012 08:19:02 Martin Schreiber wrote:
Used in order TParams create tmseparam items instead of TParam:
TCollection:
- FItemClass
Probably can
that it is worth the effort...
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
.
If I only could be sure that it is worth the effort...
Does this mean you're not even going to try ?
I'll think about.
Thank you for your time.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman
to work
in FPC trunk?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
) does not support
this. Lazarus artificially forbids this too. Internally most code
supports this.
Correct.
Martin, what do you mean with combination of inherited frames and
inherited forms need special handling ?
I don't remember exactly and I don't want to remember because of too much
:= fieldnamedummy;
try
inherited;
finally
fieldname:= '';
end;
end
else begin
inherited;
end;
end;
Maybe we need a function to decide the class of a string field ?
Probably does not help if the descendant can not access private base fields.
Martin
;
end;
end;
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
for MSE forms too.
MSEGui suppports nesting longer than Lazarus.
Maybe the FCL was fixed in the meantime?
Possible.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Monday 16 July 2012 17:25:58 michael.vancann...@wisa.be wrote:
On Mon, 16 Jul 2012, Martin Schreiber wrote:
On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote:
Well, from your code adding the following to the protected section:
Property ValueBuffer : Pointer Read
big.
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Sunday 15 July 2012 19:21:58 Michael Van Canneyt wrote:
On Sun, 15 Jul 2012, Martin Schreiber wrote:
Currently I need access to the following private FCL class fields because
of MSEide+MSEgui extensions:
I have looked at your list. (I sent my previous mail about this without
having seen
methods/properties protected ?
You are talking seriously? If so I'll provide a list of private FCL fields I
need to access in MSEide+MSEgui.
Thanks Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
but if the FPC RTL
is compiled with it I need to compile my cracker classes with optimization
too.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
).
Is it guaranteed that the local definitions have the same layout as the
definition in the FCL unit?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Saturday 14 July 2012 07:50:58 Martin Schreiber wrote:
On Saturday 14 July 2012 01:44:39 Jonas Maebe wrote:
Hi,
I've implemented an optimization that reorders the instance fields of
Delphi-style classes (and only of Delphi-style classes) to minimise
memory gaps caused by alignment
for bookmark variables.
In Lazarus:
Use string instead of TBookmarkStr for bookmark variables.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
compatibility.
Or maybe Lazarus can define bookmarkty too for those who don't care
about Delphi compatibility?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
601 - 700 of 1522 matches
Mail list logo
