Mattias Gaertner schrieb:
Compiler errors in macros are often confusing/misleading, because the
user does not see the expanded code.
That's where a compiler listing comes into the play, generated e.g. by
the preprocessor option (-m).
Same for debugger positions and handling.
Not really
Michael Van Canneyt schrieb:
In short: No, it is better to keep that particular box of pandora closed.
It may be worth a try.
None of the more modern languages implement macros, and this is for
good reason.
Right, preprocessor support can be *added* to every language,
introducing macros,
Joerg Schuelke schrieb:
So, why not? In the further reading the main thesis.
1. As far as possible simple syntax, which fits into the up to
date implemented language.
2. Maximal implementation of this syntax. No needless
restrictions.
3. Effectiveness in view of
Florian Klaempfl schrieb:
I really thing we should first collect use cases and maybe improve
existing solutions if needed instead of opening another can.
ACK. Here a first example:
We often have enumerated types, with arrays of strings or other
associated information, that must be kept in
Michael Schnell schrieb:
What a bout a compiler directive to optionally call the gnu C
preprocessor ? I would have wanted used this some time ago for a very
special project.
IMO you can do that with build macros. But note that you'll have to use
the C macro syntax (#define...), for such
kingbiz...@gmail.com schrieb:
I would like to be able this:
[ some code after begin ]
DoSomething;
var I: Integer;
for I := 0 to 1000 do
DoAnotherThing(I);
[ inside the code ]
That's not good practice, in no programming language.
Better move the loop into a local procedure, where you can
Joerg Schuelke schrieb:
Am Tue, 10 May 2011 23:50:29 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
The syntax would look like:
Block = BEGIN [Declarations] {Statement} END .
Yea, it looks like C, but it is not. The difference in C like languages
is that an declaration is just
kingbiz...@gmail.com schrieb:
I don't see any disadvantage writting a code with /C-like with pascal
keywords/, shortcuts are always welcome in order to code faster (also
this is the objective of the High-Level Languages, isn't?). I like
Pascal and I don't see why to resist against some
Joerg Schuelke schrieb:
To decide that a declaration is a statement and can occur everywhere
where a statement is required, is not that small you think. This has
many consequences, influencing the whole code generation process.
Think about exceptions and stack rewinding.
Right, but a
Michael Schnell schrieb:
IMHO the reason is reusing the variable name, which in C can be
essential with complex macro declarations. You can reintroduce any
variable name in a {-} block without harming the variable with the same
name declared outside and used before and after the block .
Joerg Schuelke schrieb:
Ok, not the reason. But coding security is the reason, you should do
so, if you can. Look at Stroustrup. The reason for pascal not to do so,
is what follows from that, a really complicated stack unwinding, for
example.
Stack unwinding is not an argument, IMO. C++ and
Joerg Schuelke schrieb:
Am Wed, 11 May 2011 00:23:13 +0200
schrieb Vinzent Höfler jellyfish.softw...@gmx.net:
I would. FPC already has interfaces.
There are good reasons why most languages didn't adopt the C++-way
of doing MI.
I think we have two concepts
- inheritance
- interface
You
Joerg Schuelke schrieb:
Hmmm, I think about macros for pascal with parameters for some time, and
ask you now: where is the debugging macro used inside the whole
compiler sources? Nowhere, because it is nearly impossible to write
some really useful.
The parameters are not the problem.
They are
kingbiz...@gmail.com schrieb:
*I have been playing on other languages sometimes and I see some
features that speed-up a lot the code creating. I'm posting here one, I
want to see what you think about it.
*
*Good:* fast algorithm testings, code creating
*Bad?:* not a standard of the pascal
michael.vancann...@wisa.be schrieb:
But what is the cleaner way? To defer the expansion of {$I %xxx%}
inside macros, or to define c-like macros __LINE__ and __FILE__, maybe
with nicer names?
Defer expansion. The use of {$I } is mandatory, since __LINE__ and
friends are valid
pascal
Martin Schreiber schrieb:
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
Joerg Schuelke schrieb:
First i will note that what i state is not an error or bug in free
pascal, but it is somehow unclean implemented.
The bug resides in the dirty Delphi OPL definition.
DoDi
___
fpc-devel maillist -
Skybuck Flying schrieb:
I copied arm folder to sky folder to try and use it as basis for
adding a new target to free pascal.
Okay, so far.
Fatal: Internal error 2004121202
Fatal: Compilation aborted
Now I am wondering what the number behind the internal error means ?
It's error #02
Skybuck Flying schrieb:
I copied arm folder to sky folder to try and use it as basis for
adding a new target to free pascal.
Okay, so far.
Fatal: Internal error 2004121202
Fatal: Compilation aborted
Now I am wondering what the number behind the internal error means ?
It's error #02
Florian Klämpfl schrieb:
Am 20.04.2011 00:05, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
Using extended typically hides only bad numerical algorithms. There
might be some corner cases where extended is usefull but I general I
think it's a matter of bad algorithms.
Some
Pocket MicroTechnics Support schrieb:
Hello,
I have just a little question about expressions and types/cast management
in FreePascal.
if I have a mixed expression with:
i, j, n : byte
k : word
n := i + k - j;
IMO the compiler converts operands to the bigger (wider) of the
involved operand
Nikolai Zhubr schrieb:
Originally MS spread info it wouldn't work at all under Windows, but
that proved to be false,
the FPU works technically. Now MS just states it is unsupported.
And deprecated:
http://msdn.microsoft.com/en-us/library/ee418798(VS.85).aspx#Porting_to_64bit
Thanks. I
Florian Klaempfl schrieb:
Using extended typically hides only bad numerical algorithms. There
might be some corner cases where extended is usefull but I general I
think it's a matter of bad algorithms.
Some algorithms convert faster with increased accuracy.
DoDi
Jonas Maebe schrieb:
On 18 Apr 2011, at 10:13, Daniël Mantione wrote:
Originally MS spread info it wouldn't work at all under Windows, but
that proved to be false,
the FPU works technically. Now MS just states it is unsupported.
And deprecated:
Leonardo M. Ramé schrieb:
TMyType = (mtOne, mtTwo, mtThree);
var lMyType: TMyType;
begin lMyType := TMyType(GetEnumValue(TypeInfo(TMyType), 'mtTwo'));
// lMyType is 1 instead of mtTwo
How do you know? Since ord(mtTwo)=1, you seem to be fooled by the debugger.
DoDi
Skybuck Flying schrieb:
However pascal's string types, seem more of a special type, one could
consider this a software type which is not really implemented by the
instruction set and therefore requires some kind of software routines to
make it work.
Right. Some (dynamic...) data types
Some time ago I've heard a rumor that the Extended type is not supported
by x86_64 targets. But AFAIK the x87 FPU continues to exist in 64 bit
machines, and is still accessible by the well known coprocessor
instruction set.
So what's the current state of floating point types in FPC?
DoDi
Sven Barth schrieb:
On Windows 64-bit you must not use the x87 FPU, because Microsoft wants
it so.
Can you be a bit more concrete?
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Skybuck Flying schrieb:
Before looking at your code, I'd know the role that your project plays
at all. Is it only about making the FPC code compilable by Delphi, as
the first stage in the FPC bootstrap?
Yes.
Okay, so far.
3. Once the RTL is compiled use the original RTL sources and/or
Marco van de Voort schrieb:
When you want to use FPC as an alternative compiler for Delphi, then
you'll have to make it output binaries in a way that the Delphi linker
can use. In order to make use of further targets, as already supported
by FPC but not by Delphi, you'll have to update the
Skybuck Flying schrieb:
Anyway if somebody could take a look at all of this and make some sense
of it that would be great/nice, saves me some time and could clear some
confusion (?) ;)
Before looking at your code, I'd know the role that your project plays
at all. Is it only about making the
Skybuck Flying schrieb:
I have a little question about these subfolders in the compiler folder,
they are called:
'i386' and 'x86'
What are these folders, they seem samiliar ?
The x86 targets are splitted into 4 directories, AFAIR
i386 for 32 bit,
ia64 for Intel IA-64 architecture
Skybuck Flying schrieb:
(This posting/reply is mostly ment for: Hans-Peter Diettrich)
I saw you mentioned you are working on the front end part of the
compiler.
I also saw you want to introduce either syntaxes or perhaps even
languages (?)
Both, but this project is OT here.
Have a look
Skybuck Flying schrieb:
First of all free pascal compiler is not a multi-target cross
compiler but it is a dual-target cross compiler (dual meaning host
and target can be different ;))
FPC is a single target cross compiler. cross indicates that the target
can be different from the host
Skybuck Flying schrieb:
So this is my biggest question and hunch: At some point during this
whole step/phase the RTL needs to be switched/swapped with the new
RTL...
No swapping required. The host-RTL is linked *into* the compiler itself,
the target-RTL is used (read, compiled) *by* the
Joost van der Sluis schrieb:
That's why I mentioned or any other structured format.
It's not a bad idea to see if we can make a structured (and readable)
format to create our fpmake.pp files.
I was also thinking about letting fpmake detect from the compiler-output
if a dependency is missing,
Marco van de Voort schrieb:
In a new approach I'd provide the interpretation of existing MakeFiles,
and extend it to the specific needs and capabilities of the FPC/Lazarus
project (package...) model.
Personally I don't think the core makefile principles are worth preserving
at all:
ACK. A
LacaK schrieb:
So as long as users
can't make tables with numeric fields that support more then 15 numbers,
we don't have to support bcd-fields. So map decimal to BCD (not float,
it will be invalid for values within the supported precision range). If
users want to store numbers with an higher
Darius Blaszyk schrieb:
fpmake's intended use is to compile your FPC code. I can see the
use of trying to run a testsuite, build docs and a binary zip for
distribution: they are all FPC related things.
But it is not intended as a general build system (i.e. replace make
or ant or rpm or deb).
Paul Ishenin schrieb:
I noticed today that if I want to allocate 0 bytes I get not a nil but a
valid pointer. Why?
This will allow for a following Realloc.
Even in Delphi the behaviour may be subject to the installed memory manager.
DoDi
___
Paul Ishenin schrieb:
For some reason the visibility is completely ignored here. I can add a
class helper to the strict private or even move it to another unit - it
is always visible.
IMO class helper methods always should become visible as part of the
class, regardless of where they are
Sven Barth schrieb:
Sorry, I don't understand what you want to tell here.
Sorry2, I'll retry.
I personally expect a class helper that is defined inside a private
section of a class not to be available in another unit like I can't
access a field or another type defined in there as well.
Jonas Maebe schrieb:
An alternative solution could be to add a hashtable (tfphaslist) to
tmodule whose entries are hashed on the qualified class names
(unit$classname, since different units can contain classes with the
same name). The value of such an entry would a tfpobjectlist of class
Sven Barth schrieb:
Widestring will also grind the application to a halt due to being COM
based
on Windows.
How that?
WideString on Windows has no reference counting, thus everytime a
WideString is assigned it needs to be copied.
I'm not so sure of that. AFAIR the field exists, but
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
non-native strings, it can also be a performance win).
IMO a single encoding, i.e. UTF-8, can cover all cases.
Well, for starters, it doesn't cover the existing Delphi/unicode codebase.
Because it's bound to UTF
kingbiz...@gmail.com schrieb:
I come here humbly to ask for a new implementation, the IIF ?:, the
IIF is a shortcut that make the coding a little faster, it works by
returning a true or a false part of a condition, a more detailed
information can be found there:
LacaK schrieb:
...: the new ansistring type has a hidden element size field (in
addition to the reference count, length and codepage), and from what I
can see at page 10 of
http://edn.embarcadero.com/article/images/38980/Delphi_and_Unicode.pdf,
Delphi 2009's unicodestring is simply an
Jeff Wormsley schrieb:
On 01/11/2011 11:10 AM, Hans-Peter Diettrich wrote:
UTF-8 combines an single (byte-based) storage type with lossless
encoding of full Unicode. Ansi and UCS2 (really UTF-16) only *look*
easier to handle in user code, but both will fail and require special
code whenever
Michael Schnell schrieb:
+= does work for variables, even Strings.
AFAIR, there already has been a discussion about += and friends for
properties.
In fact I don't see why the compiler not just generates x.a := x.a + y
from x.a += y before doing any code generating,
This would result in
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
memory management and the occasional code page conversion (and since
this may reduce the number of code page conversions when working with
non-native strings, it can also be a performance win).
IMO a single
Marco van de Voort schrieb:
Btw, while looking up rawbytestring I saw this in the Delphi help:
Declaring variables or fields of type RawByteString should rarely, if ever,
be done, because this practice can lead to undefined behavior and potential
data loss.
IIRC RawByteString should be used
Jonas Maebe schrieb:
This has the advantage that you always have all optimal implementations
available, regardless of the platform or default string encoding. It
does not require extra work because we have to write all those versions
also if we want the RTL to be compilable for different
Jonas Maebe schrieb:
And we have to deal with Windows, where the default is UTF16.
... since Delphi 2009 uses (unicode)string everywhere, we need at least also
unicode versions.
Since the generic Delphi string type can be any Unicode encoding now,
it IMO would be legal to use UTF-8 or
Jonas Maebe schrieb:
In current Delphi is String synonym for base type UnicodeString UTF-16
AFAIU ATM in FPC is String synonym for AnsiString (as in previos
versions of Delphi)
Are there any plans to change meaning of String type ?
(like Delphi to UnicodeString , or UTF8String?)
If/when
Joost van der Sluis schrieb:
I've done some more tests with -gw2. 'p classinstance' gives you the
address of the class-instance and not the values within the class.
That's a big issue to me. To show the class, you have to use 'p
classinstance^', which is nonsense in a Pascal-way of view.
Alexander Klenin schrieb:
No, this example is not the reason to duplicate methods, since
C++ has a special mutable modifier to get around this specific problem.
Ah, this modifier was not yet available when I was coding C++ in the
early 90s. Good to know that we'll have implement the same
Max Vlasov schrieb:
drdiettri...@aol.com mailto:drdiettri...@aol.com wrote:
My experience with const methods in C++ often resulted in a bunch
of cloned methods, with only calls to other non-const methods
removed - a maintenance nightmare :-(
Just curious, was it a fight with
Max Vlasov schrieb:
An idea here is to introduce a directive (maybe something else, but
directive looks more straightforward), let's call it readonly that
forces the method to be able only to read the fields and properties of
the object it belongs to and forbid any writing. Sure in this case
michael.vancann...@wisa.be schrieb:
The task itself is easy. The consequences of this may not be so easy:
TComponent is a basic class. Many many instances are created during the
lifetime of an application. Adding a field that adds 4/8 bytes to such a
class is something we're not eager to do,
Andrew Brunner schrieb:
That would not be an issue as Int64 is available under all flavors of FPC.
I don't see the hold up in adding a patch for Data field. There is just
one unit to change. What makes this so complicated that it hasn't be
accomplished yet???
First we have to agreee about
michael.vancann...@wisa.be schrieb:
I was looking at the code for Tag property in classes unit and noticed
I can't safely use Tag to keep runtime pointers (at least on a 64 bit
compile). What is the likelihood of getting tags changed to support
universal access under 64/32 bit compiles?
michael.vancann...@wisa.be schrieb:
The logic is that it is bad programming to use an integer to store a
pointer.
That's why handles are used for that purpose, and on a 64 bit system
handles can have 64 bits as well.
Handles are equally bad. They are *not* pointers.
A user cannot know,
Jonas Maebe schrieb:
Const is a pascal keyword which can mean for pascal pass records
by reference.
Making it mean that would make a lot of code less efficient. It
doesn't have that meaning for the i386 register calling convention
either (and it cannot be made to mean that there, because that
Paul Ishenin schrieb:
Well, it could be done since const is implementation-dependent, but
it would force all non-x86 platforms to pass all const parameters by
reference by default, which may not be desirable from an efficiency
point of view.
As I understand not all const parameters are passed
Marco van de Voort schrieb:
It's an users own choice to not be unicode compliant in his apps (e.g. if he
knows he never goes to the Eastern Asiatic market etc), but a runtime should
be as unicode compliant as reasonably possible.
IMO there exist levels of compliance.
The bottom level
Marco van de Voort schrieb:
Yes, but the realisation should be that the holding on array indexing is
what makes it expensive. The problem could be strongly reduced by removing
such array indexing skeleton from all routines where it is not necessary.
Why fall from one extreme into the other
Thaddy schrieb:
The rants about finalizers versus destructors in the context of GC are a
many.
Let me make it clear that these discussions almost invariably presume
the context of the C(++) language.
The main thing being that C++ allocates objects/classes from the stack
by default. In
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
Yes, but the realisation should be that the holding on array indexing is
what makes it expensive. The problem could be strongly reduced by removing
such array indexing skeleton from all routines where
Marco van de Voort schrieb:
At least the example code has to be made work, i.e. the nonsense statement
DoSomething(ch(i));
has to be changed into something like
DoSomething(GetUTF8char(s,i));
before we can can talk honestly about the order of the loop.
The other of the algorithm is then
Alexander Klenin schrieb:
The total order will be something between O(n^1) and O(n^2), depending on
many factors (what is n?...).
Huh? O(f(n)) has a precise definition, and of course we are talking worst-case
complexity here (although average complexity would be the same in this case).
n is
Thaddy schrieb:
Actually, I am *calling* the destructor in the finalizer, not copying
it. AFAIK this should take care of it.
IMO destructors and finalizers are mutually exclusive, I remember a note
like Why a garbage collector never should call an destructor, that at
least applies to
Thaddy schrieb:
The comparison in the UTF-8 string example is very questionable. First
ch(i) is not equivalent to ch, not even closely related, and the claim
of O(N^2) operations deserves an proof - IMO it's simply wrong.
Yes, this caught my eye as well: O(N^2) seems only the case if length
Marco van de Voort schrieb:
A more grave reason though is that Delphi does not have low() and high() on
sets and a request to add it by me in 2006 was closed with their equivalent
of won't fix.
I wonder how FPC defines low() and high() for sets. The static bounds
can be obtained from the
Vincent Snijders schrieb:
2010/11/14 Thaddy tha...@thaddy.com:
On 13-11-2010 20:56, Hans-Peter Diettrich wrote:
The comparison in the UTF-8 string example is very questionable. First
ch(i) is not equivalent to ch, not even closely related, and the claim of
O(N^2) operations deserves an proof
Marco van de Voort schrieb:
we have placed a new major release of the Free Pascal
Compiler, version 2.4.2 on our ftp-servers.
Great :-)
Some highlights are:
Compiler:
* Support D2006+ FOR..IN, with some FPC specific enhancements. Refer to
http://wiki.freepascal.org/for-in_loop for
Sven Barth schrieb:
Perhaps somewhere a new type section begins between the declaration of
the pointer (Foo = ^Bar) and the declaration of the real type (Bar =
XYZ)? This could easily be the case when includes are used and those
aren't clean ^^ (e.g. packages\sqlite\src\sqlite.inc had a end.
Graeme Geldenhuys schrieb:
Op 2010-11-08 11:48, Michael Van Canneyt het geskryf:
It gets only really interesting when you start comparing how browsers react
on this DTD reference. In theory, they should react the same. Practice shows
different...
And that's why I stay away from web apps and
Michael Schnell schrieb:
On 10/30/2010 03:43 PM, Hans-Peter Diettrich wrote:
How can I add this directory to the git repository, so that it is
available as a self-contained project/branch?
Why not fork the branches after these files are added ? I suppose GIT
allows to add them in a way
Graeme Geldenhuys schrieb:
On 30 October 2010 09:59, Alexander Klenin wrote:
Are you sure you do not want to use Github?
There is nothing wrong with SourceForge.net't git setup, it works just
as good as GitHub. The benefit of SourceForge is that they give you
plenty of other project related
The SourceForge fpcext project http://sourceforge.net/p/fpcext/home/
shall allow to customize and extend the FPC compiler, with e.g.
alternative components and languages.
After some tries I got at least the git repository work, but I'm not
sure whether I did it the right way. The repository
Here's a final note on my FPC branches. While I could gather much
information about the FPC implementation, during these experiments, I
understand now that FPC - as a production compiler - will not undergo
much refactoring. So I'll discontinue work on these branches, and
continue further
Andrew Brunner schrieb:
I have a 64bit cpu here running 32bit Windows 7. I was compiling my
project under Windows 7 to do some debugging when I came across the
problem when trying to lock increment int64 variables for transactions
and bytecounts (general counter purposes).
Why must such
Jonas Maebe schrieb:
What is constref,
A const parameter that is always passed by reference.
What's the guarantee, that (in detail external) subroutines will honor
the const attribute?
AFAIK constref was invented for passing values to external
subroutines, that expect a reference. In
Graeme Geldenhuys schrieb:
If the source code only contains tabs characters, instead of spaces,
does... that means the source code files are a lot smaller. Does that also
result in the compiler parsing those files faster? After all, there is a
lot less characters to parse.
Anybody actually
Jonas Maebe schrieb:
What's the guarantee, that (in detail external) subroutines will honor
the const attribute?
None. const (and constref) is a hint from the programmer that the
argument can be considered by the compiler as constant inside the
called routine.
What about reference
Marco van de Voort schrieb:
Still, C would be doable, for porting SOME existing code to co-operarate
directly with pascal code. If the C code uses lots of library calls it can't
be used directly. But, there is code for math and compression etc. which don't
call libraries much.
The
Marco van de Voort schrieb:
I personally think that fully automated C header conversion is not possible.
It is, but at the same cost of e.g. fully automated Delphi project
conversion. In an FPC project the related items (modes, targets, search
paths...) are configurable in several ways - the
Dimitri Smits schrieb:
as for the linking of C++/FPC:
good argument, but then your fpc-compiled c++ will be incompatible with
everything else. Come to think of it, no 2 C++ compilers mangle the same due to
VMT and other abi-stuff anyway.
+1
C++ is not only a different syntax, it also comes
Marco van de Voort schrieb:
PChars, on the other hand, require manual memory management
which is the source of bugs.
Point out the example of bugs. (ones that matter, not the stylistic ones)
The usage of PString essentially is using an crippled AnsiString,
without reference counting. I did
Martin Schreiber schrieb:
This is a typical showcase for the premature micro-optimization --
for a few percentages of speed in the short term,
you pay in reduced code maintainability,
which precludes high-level optimizations in the long term.
IIRC one of the goals are to enable muti threaded
Florian Klaempfl schrieb:
and refactorings are not welcome.
Who says this? Usefull refactoring *is* welcome.
Umm, please specify what you understand by refactoring.
Something that does not move code around, or into new subroutines?
Something that can be achieved in a sequence of only
Florian Klämpfl schrieb:
Well, DoDi is not willing to fix the flaws of his patches so they were
rejected, see e.g.: http://bugs.freepascal.org/view.php?id=17584
You're kidding. The same result in a branch, with intermediate steps,
would be rejected as well (NoGlobal branch). Why break one
Florian Klaempfl schrieb:
Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
First Pascal-like languages and later C.
FPC's main developer doesn't see a need for it.
Indeed. Please tell what a C front end to FPC helps? FPC has no
advantage over existing C compilers except being a pascal
Alexander Klenin schrieb:
Actually, I certainly think (and hope) that DoDi's goal is _not_ a C frontend,
but to find _any_ possible venue to upgrade the code structure of FPC code.
Well - both ;-)
I would like to see my C parser working as an FPC front-end, instead of
producing intermediate
Florian Klaempfl schrieb:
One goal of this refactoring is the determination and documentation of
the actions, required in certain pieces of the grammar.
Why should we need these actions?
Yes, that's one of the big questions. What is that funny call to XYZ
good for, in this particular
Florian Klaempfl schrieb:
Am 18.10.2010 14:01, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
One goal of this refactoring is the determination and documentation of
the actions, required in certain pieces of the grammar.
Why should we need these actions?
Yes, that's one of the big
Hans-Peter Diettrich schrieb:
Now I started another branch, that is not as intrusive as my other
branches. The AltParser branch makes multiple parsers available, each of
which sits in its own class derived from TParser.
After some tries I've arrived at a working model. The semantic actions
Florian Klämpfl schrieb:
Am 17.10.2010 11:19, schrieb Hans-Peter Diettrich:
Further development should be synced better with the trunk. Please let
me know about the chances, that the required hooks are merged into the
trunk.
I won't merge it and take the burden to be responsible for a broken
Florian Klämpfl schrieb:
Am 17.10.2010 17:45, schrieb Hans-Peter Diettrich:
Florian Klämpfl schrieb:
Am 17.10.2010 11:19, schrieb Hans-Peter Diettrich:
Further development should be synced better with the trunk. Please let
me know about the chances, that the required hooks are merged
And3mD schrieb:
I added bug report about using Tag as Pointers in IDE
http://bugs.freepascal.org/view.php?id=17642
For some reason (read-only???) I could not add a note there, so I'll
present my ideas here:
IMO Tag should become an int64 for all components, to overcome platform
and
601 - 700 of 951 matches
Mail list logo
