Am 19.04.2011 12:27, schrieb Daniël Mantione:
Op Tue, 19 Apr 2011, schreef Florian Klämpfl:
It's just that the documentation tells you not to use the x87.
Yes, because it's strange programming model should be really dropped.
Agree, but the 80 bit support makes some people want to use it.
Am 19.04.2011 15:18, schrieb Marco van de Voort:
In our previous episode, Dani?l Mantione said:
By the way, recent GCC versions calculate the goniometric functions in
software using SSE3, and I checked that this is indeed slightly faster
than the x87. So we can get rid to the x87 stuff, should
Am 07.04.2011 03:52, schrieb Skybuck Flying:
The code typecasts this 9 byte record towards an 8 byte qword
This wouldn't work and cause a compiler error.
and then
takes the first byte from that and type casts it to a char.
The cast tconstexprint - qword is overloaded.
Am 05.04.2011 04:27, schrieb Paul Ishenin:
We probably can extend these tricks for other types and may be speedup
the compiler.
I think your branch should be reviewed either by Florian or by Jonas
before the merge.
I can review the coding style etc. but not if the semantics or syntax of
the
Am 05.04.2011 10:09, schrieb Paul Ishenin:
05.04.2011 14:26, Florian Klaempfl пишет:
Am 05.04.2011 04:27, schrieb Paul Ishenin:
We probably can extend these tricks for other types and may be speedup
the compiler.
I think your branch should be reviewed either by Florian or by Jonas
before
Am 05.04.2011 04:27, schrieb Paul Ishenin:
I think your branch should be reviewed either by Florian
I did a quick review and found nothing important, only a few remarks:
- current_syssym: is it really needed? Can't the type checking be done
during the type check pass? If it's needed, it
Am 25.03.2011 22:33, schrieb Sven Barth:
2. In Delphi helpers are based on classes and in FPC they are a seperate
type. I've choosen the later, because it has reduced the need for some
checks and also simplified the code.
I noticed the difference when checking the RTTI parent reference of a
Wouldn't it be better to run automatically
git svn show-ignore .gitignore
and commit it if something changed
on the git svn mirror?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 09.03.2011 09:19, schrieb Sven Barth:
Am 09.03.2011 08:39, schrieb Florian Klaempfl:
Am 09.03.2011 02:17, schrieb Paul Ishenin:
4. The syntax that was introduced by Borland is not very pascalish
in my
opinion. So I'd like to change the syntax for mode ObjFPC a bit (sadly
this won't
Am 09.03.2011 02:17, schrieb Paul Ishenin:
4. The syntax that was introduced by Borland is not very pascalish in my
opinion. So I'd like to change the syntax for mode ObjFPC a bit (sadly
this won't simplify the parser anymore because of the Delphi
compatibility).
Delphi syntax:
Am 02.03.2011 14:01, schrieb Marco van de Voort:
In our previous episode, Tomas Hajny said:
Ok. Then I don't know why they are stuck at 2.15, I got that answer then
(at
the Fosdem LLVM talk), but didn't check it further. I'll ask around.
But anyway, 8.2 is days old, so migrating to 2.17 is
Am 13.02.2011 16:28, schrieb Armin Diehl:
short question regarding the internal assembler:
with as i can access .text, .data and .bss like:
movl$.data,%eax
movl$.text,%eax
movl$.bss,%eax
this does not seem to work with the internal assembler like:
function __getBssStart :
Am 29.01.2011 13:25, schrieb Sven Barth:
Do you (especially @Devs) think that this is a sufficient approach or
should this be done another way? (Note: I have not yet profiled
compiling the compiler once with that search enabled and once without)
Profile compiler compilation first, then we can
Am 21.01.2011 05:03, schrieb Michel Catudal:
On 20/01/2011 05:14, Florian Klaempfl wrote:
Am 20.01.2011 04:01, schrieb Michel Catudal:
In the Makefile I see these after I do a fpcmake -Tall. I looked all
over the project and cannot find where I would put the information
so fpcmake would
Am 20.01.2011 11:01, schrieb Bernd Mueller:
Henry Vermaak wrote:
On 20/01/11 08:20, Michael Schnell wrote:
On 01/19/2011 05:13 PM, Henry Vermaak wrote:
it's really expensive to trap the illegal instructions and emulate
them.
AFAIK, the trapping is done by the ARM CPU, anyway, providing the
Am 20.01.2011 04:01, schrieb Michel Catudal:
In the Makefile I see these after I do a fpcmake -Tall. I looked all
over the project and cannot find where I would put the information
so fpcmake would generate a Makefile with : ifeq
($(FULL_TARGET),avr32-embedded)
Makefile:ifeq
Am 19.01.2011 16:56, schrieb Michael Schnell:
On 01/19/2011 12:03 PM, Felipe Monteiro de Carvalho wrote:
Some phones have hardware floating point, the majority not.
I'm not in a position to estimate the counts of Android devices that
have an FPU vs those that don't, or suggest that all
Am 12.01.2011 06:29, schrieb Jeppe Johansen:
What do you think about this proposal?
Is the current solution of using procedure variables so bad? Or what
does it lack?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 16.12.2010 07:50, schrieb Sergei Gorelkin:
Martin пишет:
Never used variants much.
But the below compiles, and then gives a SigSegV (w32).
Is that to be expected? Or ?
program Project1;
{$mode objfpc}{$H+}
uses
Classes;
procedure Foo(v1,v2: Variant; constref v3,v4: Variant);
Am 03.12.2010 16:11, schrieb Thaddy:
On 3-12-2010 15:50, Daniël Mantione wrote:
Could you maybe specify what you want to achieve and in what way FPC
requires you to use workaround hacks?
Daniël
Yes,
In FPC the console IO is *always* redirected, be it through a handle or
a named file.
Am 30.11.2010 09:04, schrieb Marco van de Voort:
In our previous episode, Michael Van Canneyt said:
Seems Delphi XE has deprecated all separate variables, and after ten years
did the same as FPC, use an absolute trick. And of course they named it
differently (FPC: defaultformatsettings
Am 30.11.2010 13:55, schrieb Felipe Monteiro de Carvalho:
Hello,
Looking at: http://www.freepascal.org/down/arm/linux-austria.var
There is no download for 2.4.2
Was the page not updated or is something needed to get this working?
There is no release for arm-linux.
Am 24.11.2010 00:02, schrieb Joshua Phillips:
Hello.
I'm trying to understand fpc's assembler's internals.
In fpcsrc/compiler/i386/cpubase.inc the enumertaion topsize is defined.
The elements S_B, S_W, S_L and S_Q correspond to byte, word, longword
and quadword. The elements S_IB, S_IW,
Am 18.11.2010 15:27, schrieb Thaddy:
On 18-11-2010 13:21, Žilvinas Ledas wrote:
But it might be an advantage for some projects as the discussions
over the years implied.
What about using GC for fpc itself? If it is usable for fpc, then the
problem of fpc leaking memory when compilation
Am 12.11.2010 08:51, schrieb Graeme Geldenhuys:
Creating developer tools has another problem of it's own. Unlike Delphi,
there is no stable, long term shipment of compiled units and specific FPC
version, so in the world of FPC, developers tools must ship as source code.
This again raise the
Am 11.11.2010 15:19, schrieb Sergei Gorelkin:
Hello,
Two questions I wanted to ask:
1) There are two variant type defintions (varxxx constants): one in
compiler/symdef.pas, another one in rtl/inc/varianth.inc. Worse, they
are out of sync. Is it really necessary to have a separate set of
Am 10.11.2010 10:42, schrieb Graeme Geldenhuys:
Op 2010-11-10 11:30, Michael Van Canneyt het geskryf:
It depends. You're not supposed to make assumptions on when an interface
goes out of scope.
I'll search the mailing list archives for those explanations, thanks. I
don't immediately
Am 10.11.2010 12:09, schrieb Martin Schreiber:
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
Am 10.11.2010 16:13, schrieb Graeme Geldenhuys:
Original Message
Subject: Interface scope incompatibility with Delphi
Date: Wed, 10 Nov 2010 16:57:13 +0200
Op 2010-11-10 15:01, Michael Van Canneyt het geskryf:
This is open source: essentially a hobby project for us.
Am 27.10.2010 23:50, schrieb Andrew Brunner:
My current largest issue is that due to source from from x86_64.inc
function InterLockedIncrement64 (var Target: int64) : int64; assembler;
asm
{$ifdef win64}
movq%rcx,%rax
{$else win64}
movq%rdi,%rax
{$endif win64}
Am 28.10.2010 10:02, schrieb Jeppe Johansen:
Den 27-10-2010 23:14, Florian Klämpfl skrev:
Am 27.10.2010 22:52, schrieb Andrew Brunner:
My SCS project which is a scalable unified collaboration and
communication server that uses counting for transactions and network
consumption across all
Am 27.10.2010 01:49, schrieb Dimitri Smits:
Hi,
I was wondering why on several occasions in discussions regarding
compiler design and parser branches it was mentioned (especially by
Florian) that FPC is in need of a faster FillChar.
The reason for this bewonderment is that I see code
Am 27.10.2010 05:15, schrieb Andrew Brunner:
Interlocked features for Int64 are bound to {$ifdef cpu64}
While Int64 data type is supported under i386 FPC the interlocked
features aren't included in FPC RTL.
Can I writeup a bug for this or is this due to another problem?
32 bit CPUs can do
Am 22.10.2010 09:18, schrieb Graeme Geldenhuys:
Hi,
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
Am 20.10.2010 10:07, schrieb Michael Schnell:
but this would be a lot better than the
current situation where linking FPC and C++ is completely impossible due
to the different ABI.
Really? How does accessing Qt then work? Do you know more than me? Did I
dream that Lazarus has a Qt widget set?
Am 21.10.2010 09:14, schrieb Marco van de Voort:
In our previous episode, Florian Klaempfl said:
to the different ABI.
Really? How does accessing Qt then work? Do you know more than me? Did I
dream that Lazarus has a Qt widget set? Even more: who does the
compilation of e.g.
(euh
Am 21.10.2010 09:22, schrieb Marco van de Voort:
In our previous episode, Florian Klaempfl said:
Really? How does accessing Qt then work? Do you know more than me? Did I
dream that Lazarus has a Qt widget set? Even more: who does the
compilation of e.g.
(euh, it doesn't link to C
Am 21.10.2010 09:51, schrieb Sven Barth:
Am 21.10.2010 08:54, schrieb Florian Klaempfl:
Am 20.10.2010 10:07, schrieb Michael Schnell:
but this would be a lot better than the
current situation where linking FPC and C++ is completely impossible due
to the different ABI.
Really? How does
Am 20.10.2010 09:23, schrieb Alexander Klenin:
Benchmarking included 3*10^6 calls to Add and Find methods
with the arguments of various lengths.
Average string length 5 characters:
ShortString: 1.15 s
AnsiString: 1.56 s
Average string length 45 characters:
ShortString: 12.0 s
AnsiString:
Am 20.10.2010 10:50, schrieb Graeme Geldenhuys:
PS:
Is there a make command to only compile the RTL and compiler? Excludes the
FCL. Would that be the 'make cycle' from inside the src/compiler/
directory?
Yes.
___
fpc-devel maillist -
Am 20.10.2010 11:21, schrieb Alexander Klenin:
On Wed, Oct 20, 2010 at 19:16, Florian Klaempfl flor...@freepascal.org
wrote:
Am 20.10.2010 09:23, schrieb Alexander Klenin:
Also Add is probably broken. I cannot see where AddStr does proper ref.
counting.
Indeed. And after I fixed
Am 20.10.2010 12:27, schrieb Alexander Klenin:
This sub-thread was started by mentioning the series of errors
my student made when trying to implement case of string.
Most of them was due to the fact the code used pchars and records
instead of strings and (hierarchy of) objects.
Surely, a
Am 20.10.2010 13:44, schrieb Alexander Klenin:
On Wed, Oct 20, 2010 at 22:33, Florian Klaempfl flor...@freepascal.org
wrote:
Am 20.10.2010 12:27, schrieb Alexander Klenin:
This sub-thread was started by mentioning the series of errors
my student made when trying to implement case of string
Am 19.10.2010 09:32, schrieb Graeme Geldenhuys:
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is Unicode string support.
What Hans-Peter meant is that even if he does implement Unicode String
support, that would require changes in the compiler. Florian apparently
Am 19.10.2010 10:20, schrieb Sven Barth:
Am 19.10.2010 10:12, schrieb Florian Klaempfl:
Am 19.10.2010 09:32, schrieb Graeme Geldenhuys:
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is Unicode string support.
What Hans-Peter meant is that even if he does implement
Am 19.10.2010 12:18, schrieb Graeme Geldenhuys:
Like I've said a million times before, the management of the FPC project
seems a bit off (sorry if this offends some of you, don't take it
personally). Hardly anybody looks at the various branches, so to truly test
something new
Indeed, it's
Am 19.10.2010 14:02, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 22:44, Florian Klaempfl flor...@freepascal.org
wrote:
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
Am 19.10.2010 12:07, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 17:59, Paul Ishenin i...@kmiac.ru wrote:
19.10.2010 14:49, Vincent Snijders wrote:
So maybe you cannot do anything for FPC, except creating an Enhanced FPC.
About a year ago I created a document which describes what
Am 19.10.2010 14:48, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl flor...@freepascal.org
wrote:
Am 19.10.2010 14:02, schrieb Alexander Klenin:
The topic of this thread and the patch was/is alternative parsers. As
you worked on the case of string stuff (or your
Am 19.10.2010 13:54, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 22:41, Florian Klaempfl flor...@freepascal.org
wrote:
Am 19.10.2010 12:07, schrieb Alexander Klenin:
I personally wanted to do some things for FPC (although Unicode was
not one of them),
but hesitated, because
Am 19.10.2010 14:38, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 23:02, Florian Klaempfl flor...@freepascal.org
wrote:
Am 19.10.2010 13:54, schrieb Alexander Klenin:
from fixing case and reformatting of Math unit
This does not help anybody ;)
See, you have already rejected
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?
In the first
step the semantic code simply reflects the actions in the existing code,
i.e. *how* something is done. In further
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 questions. What
Am 14.10.2010 14:09, schrieb Adriaan van Os:
Jonas Maebe wrote:
On 04 Oct 2010, at 12:17, Adriaan van Os wrote:
I wonder if there is anything special that hinders the implementation
of non-local goto’s and nested exits in macpas mode.
Afaik it's mainly a matter of no one caring enough
Am 14.10.2010 14:12, schrieb Florian Klaempfl:
Am 14.10.2010 14:09, schrieb Adriaan van Os:
Jonas Maebe wrote:
On 04 Oct 2010, at 12:17, Adriaan van Os wrote:
I wonder if there is anything special that hinders the implementation
of non-local goto’s and nested exits in macpas mode.
Afaik
Am 12.10.2010 01:04, schrieb Willibald Krenn:
Hi,
On my Win64 machine, gdb kept crashing whenever I tried to step into
fpc_raiseexception with an error saying that the reg '-1' wasn't
defined. And yes, stabs info showed:
4943 FUN0 18700408710 66408
Am 06.10.2010 05:57, schrieb Adem:
I did a global search on trunk\compiler and found the following numbers:
GetMem(): 212 hits
FillChar(): 362 hits
I haven't checked any other fpc folder, but I am sure those figures
would multiply.
What I did notice was that GetMem() and FillChar()
Am 05.10.2010 10:13, schrieb Jonas Maebe:
On 05 Oct 2010, at 10:05, Mark Morgan Lloyd wrote:
When running 2.4.0 on an ARM system (Debian v5 Lenny, armel) with
limited memory (32Mb RAM + 768Mb swap) and using it to compile a large
project (Lazarus 0.9.28.2) I'm seeing intermittent failures
Am 30.09.2010 02:38, schrieb Hans-Peter Diettrich:
Florian Klämpfl schrieb:
In the past months I've been working on several aspects of such
refactoring:
- moving global variables into objects (mainly current_module)
- turning back-ends into classes
The fpc back end is completly OOP?
To
Am 30.09.2010 11:32, schrieb Hans-Peter Diettrich:
No idea how long it would take to get it down to the current level.
All refactoring steps can be verified immediately, using make all and
compiler/make fullcycle.
Well, and running the regression tests on all targets
Am 30.09.2010 11:29, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
and prevent the use of
multiple back-ends in one binary.
... which has no use.
Lazarus allows to switch targets on the fly, what currently prevents an
incorporation of the compiler into the IDE.
Define
Am 30.09.2010 13:06, schrieb Žilvinas Ledas:
On 2010-09-30 12:57, Jonas Maebe wrote:
Mantis does not keep information about the evolution of that over
time, but you can always look at the current average at
http://bugs.freepascal.org/summary_page.php (under Time Stats For
Resolved Issues
Am 30.09.2010 14:15, schrieb Mattias Gärtner:
Zitat von Jonas Maebe jonas.ma...@elis.ugent.be:
On 30 Sep 2010, at 13:32, Mattias Gärtner wrote:
Ehm, are you saying, that the compiler must be restarted when there
were errors, because it does not clean up properly?
As far as allocated
Am 29.09.2010 01:17, schrieb Hans-Peter Diettrich:
A last note on the NoGlobals branch, and parallel processing in the
compiler:
I couldn't find any way to move global variables from globals.pas into
e.g. fmodule (tmodule, current_module), without breaking ppudump
dependencies. As long as
Am 15.09.2010 17:05, schrieb Nikolay Nikolov:
On 09/15/2010 05:48 PM, Florian Klaempfl wrote:
Am 15.09.2010 16:39, schrieb Nikolay Nikolov:
and then introduce TP7-compatible MaxColors, PaletteType and
procedures/functions. They'll be made optionally hookable (so the go32v2
implementation
Am 15.09.2010 16:39, schrieb Nikolay Nikolov:
and then introduce TP7-compatible MaxColors, PaletteType and
procedures/functions. They'll be made optionally hookable (so the go32v2
implementation will be able to implement them with the real EGA palette
registers for maximum compatibility), with
Am 13.09.2010 14:51, schrieb Willibald Krenn:
Well, it's the Delphi way of creating a new type rather than an
alias.
Since they are still assignment compatible, I don't consider it as
a really new type.
Are you sure they are assignment compatible?
I don't have a delphi here, but I'am
Am 13.09.2010 17:10, schrieb Dimitri Smits:
- Florian Klaempfl flor...@freepascal.org schreef:
Am 13.09.2010 13:47, schrieb Martin Schreiber:
On Monday, 13. September 2010 13.24:18 Florian Klaempfl wrote:
Am 13.09.2010 11:15, schrieb Martin Schreiber:
Delphi 7
Am 14.09.2010 01:26, schrieb Willibald Krenn:
[lots of useful information snipped]
- The ability to import/export functions, procedures AND variables
from binaries (although export from shared library only should be
sufficient). This works on Windows, but on Linux I had problems.
Packages
Am 14.09.2010 01:13, schrieb Leonardo M. Ramé:
Hi, does anyone knows what the error Fatal: Internal error 200111022 means?.
Something happened which should not happen ;) Looks like an error with
overloading. Can you create a cut down example?
___
I don't know whether it is still the case but there was a time the 'is'
operator relied on RTTI. So as soon as you have two different RTTI
entries for, e.g., TMyListinteger (which could happen if you compile
with packages) the operator needs some 'repair'.
This is why FPC has specialize
Am 13.09.2010 11:44, schrieb Willibald Krenn:
This is why FPC has specialize (to emphasis this): only class
instances having the same specialized generic type are considered
being equal: type TList1 = specialize TListLongint; TList2 =
specialize TListLongint;
var l1a,l1b : TList1; l2 :
Am 13.09.2010 12:31, schrieb Willibald Krenn:
OTOH 'specialize' is an additional (unfamiliar) keyword and has
semantics totally unknown to the world. So why not take what's
already in the language?
As I said, to emphasis that a new type is created, generic
specialization is something
Am 13.09.2010 11:15, schrieb Martin Schreiber:
Delphi 7 FPC
Exe size: 3131392 3689304
Code: 2128524 2138240
Data: 752085 1541256
Do you use a lot of resource strings?
Am 13.09.2010 13:47, schrieb Martin Schreiber:
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
Am 13.09.2010 14:02, schrieb Sven Barth:
Am 13.09.2010 11:44, schrieb Willibald Krenn:
But enough about generics, back to packages: I'll start doing an
implementation for the non-generic part first. Let's see how this
goes. Since I need to read into fpc source (and do this in my spare
time),
Am 10.09.2010 02:41, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
1. Ancient code, keep in mind, most code not being back end code was
written ~10 years ago. At this time we even could not depend on
perfectly working ansistrings.
I'm talking about nowadays situation.
You asked
Am 09.09.2010 13:27, schrieb Dimitri Smits:
My angle (besides from the obvious dynamic pluginsystem
This is why there is no work on a packages system for FPC: there are
simply too much different versions around. While Delphi has at most one
release per year, FPC/Lazarus has more or less every
Am 09.09.2010 14:02, schrieb Willibald Krenn:
This is why there is no work on a packages system for FPC: there
are simply too much different versions around. While Delphi has at
most one release per year, FPC/Lazarus has more or less every day a
new version.
Well, but not that much stable
Am 09.09.2010 15:52, schrieb Hans-Peter Diettrich:
When dynamic strings are used all around, is the use of pointers to
ShortString still recommended? (fmodule contains a lot of them)
1. Ancient code, keep in mind, most code not being back end code was
written ~10 years ago. At this time we even
Am 09.09.2010 16:05, schrieb Hans-Peter Diettrich:
IMO the implementation of Delphi packages in FPC depends on two things:
the resources required for such an implementation, and the chance for
closed-source libraries. When we want to disallow or even discourage
closed-source FPC projects
I
IMO the implementation of Delphi packages in FPC depends on two things:
the resources required for such an implementation, and the chance for
closed-source libraries. When we want to disallow or even discourage
closed-source FPC projects, I see no urgent need for implementing Delphi
Am 09.09.2010 16:37, schrieb Marco van de Voort:
In our previous episode, Florian Klaempfl said:
I don't see any connection why the situation with packages would be any
different, licensewise, from the current situation with EXEs.
... Most notably since a EXE+packages is essentially just
Am 08.09.2010 03:10, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
I stopped searching after finding such code in aasmtai, aoptbase,
aoptobj, assemble, globals, nadd, ncgutil, nld, ogcoff, options,
optloop, pdecsub, pmodules, psub, symdef, systems.
Well, I see no problem
Am 05.09.2010 18:30, schrieb Hans-Peter Diettrich:
Jonas Maebe schrieb:
* I assume
that all the code you added in psystem.pas is with the long term view
of making the parser independent. However, that is a separate project
and not part of removing global variables from the compiler
Both
Am 07.09.2010 09:49, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
Am 06.09.2010 16:12, schrieb Hans-Peter Diettrich:
Another more recent experiment was to convert the back-ends into
classes. It turned out that much target-specific code resides in the
general compiler units, whose
Am 06.09.2010 05:29, schrieb Hans-Peter Diettrich:
5) Some (parser) procedures modify current_tokenpos/filepos temporarily,
and restore the old values later. What's the purpose of such changes?
To get correct file positions in debugging code and error messages.
So every temporary change of
Am 06.09.2010 09:47, schrieb Graeme Geldenhuys:
On 5 September 2010 19:36, Florian Klämpfl wrote:
Indeed. And the features of git gui are just ridiculous. It misses even
basic stuff like good explorer integration.
That's a matter of opinion I guess. I much prefer stand-alone tools,
Yes, I
Replied on fpc-other.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 06.09.2010 14:30, schrieb Michael Schnell:
What's the problem with using threadvars
As discussed some days ago, the current implementation of Threadvars is
quite slow (doing a libc call on each access to a threadvar).
And? Those variables aren't used very often. And if needed, it can be
Am 06.09.2010 16:12, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
I have no real idea, how in such a model the initialization of the
threadvars has to be implemented. That's why I try to assign all
state-related variables to a definite object, whose reference can be
easily copied
Am 20.08.2010 12:39, schrieb Hans-Peter Diettrich:
Jonas Maebe schrieb:
Such complications can be eliminated by a refactoring of the
targets, into dedicated classes. This can be done in the same
branch, because the existing units (in the target directories) have
conflicting names, and
Am 12.08.2010 00:28, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
It is not yet clear, however, whether the
parser or entire modules can be destroyed before the end of compilation
- if memory requirements are of interest at all.
I don't think that a parser and a scanner instance
Am 12.08.2010 07:42, schrieb Hans-Peter Diettrich:
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
How would you count an level, when multiple concurrent parser threads
create further threads concurrently?
Hmm, I think a producer/consumer system with a queue
Am 12.08.2010 08:12, schrieb Hans-Peter Diettrich:
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
How would you count an level, when multiple concurrent parser threads
create further threads concurrently?
Hmm, I think a producer/consumer system with a queue
Am 12.08.2010 09:13, schrieb Graeme Geldenhuys:
Hi,
[...just curious...]
As far as I understand, the Windows version of FPC has an internal linker
which greatly improved the speed of building/linking software on that
platform.
Yes.
Why doesn't the Linux version of FPC (or any other
Am 11.08.2010 16:09, schrieb Hans-Peter Diettrich:
After the problems with the global variables, I started another branch
for removing global variables and fixing compiler states.
In the NoGlobals branch I already could make the scanner/parser a child
object, owned by the module.
This
Am 27.07.2010 18:24, schrieb Hans-Peter Diettrich:
I just had to chase an strange bug, in a local (nested) subroutine. When
I made several functions (if_statement() ...) local subroutines of
method statement(), they stopped to work properly :-(
After many tries I concluded, that every
Am 28.07.2010 15:10, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
IMO we should have at least an option, that a function name can *not* be
used for the function result any more, for the result we have the Result
variable. Then we can safely distinguish between function calls
Am 27.07.2010 08:33, schrieb Graeme Geldenhuys:
Op 2010-07-27 00:13, Marc Weustink het geskryf:
Florian asked about rejected *compiler* patches, not RTL.
And I spoke about code contribution to the FPC project - as a whole.
Well, the syntax addition is about the compiler, right? Or do you
101 - 200 of 1078 matches
Mail list logo
