Dr. Rolf Jansen wrote:
since some days I am no more able to make all the latest and greatest
fpc from SVN sources, because there are compilation errors for h2pas.pas.
Here comes a log of a session which reproduces the error:
PBRJ:~/Programmieren/Xcode/Pascal/fpc Rolf$ svn update
At revision
On Sat, 27 Feb 2010 19:17:48 +0530, Nataraj S Narayan natara...@gmail.com
wrote:
Jonas
#make distclean crosszipinstall CPU_TARGET=arm CROSSOPT='-CfSOFT -darm
-dFPC-ARMEL -gl'
As I said multiple times, only OPT=-dFPC_ARMEL is needed. No -CfSOFT, no
-darm, especially not in CROSSOPT.
Marco van de Voort schrieb:
In our previous episode, Marco van de Voort said:
At least according to Linus, the kernel api/syscall interface will never
break.
They will just not implement new calls on new archs ? :-)
Euh, old calls obviously.
Well, adding a new arch is not breaking old
Den Jean schrieb:
Hi,
I noticed this change log on fpc svn:
florian 15472
* don't build a native compiler for embedded targets
I sometimes build a native fpc on N900,
(sometimes because it takes some time)
Will this affect me if I do a 'svn up fpc' on the N900 ?
When is a
Den Jean schrieb:
On Tuesday 22 June 2010 22:27:59 Florian Klämpfl wrote:
Devices without any operating system, i.e. mainly microcontrollers.
thx Jonas and Florian, updating and compiling now.
fpc on arm related question,
when installing fpc, I need to install to /opt,
because /opt
Michael Schnell schrieb:
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
No, SWP is atomic, so the implementation looks good (at a glance).
Seemingly not on all ARM sub-archs:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You
Due to lack of resources which might have caused some of the repostories
damages, I had to turn off the fpc svn mercurial mirrors. If there is
enough interested, we can look for an alternative machine hosting it.
___
fpc-devel maillist -
Hans-Peter Diettrich schrieb:
Since some time I'm trying to separate the syntax from the semantics
processing in the parser. It turned out to be quite complicated, so that
I want to use some methodology. (Yes, I've been warned ;-)
For profiling and debugging I want to have both the old and
Alexander Klenin schrieb:
On Sat, Jul 17, 2010 at 20:12, Florian Klämpfl flor...@freepascal.org wrote:
For first results see the dodi/parser_rewrite branch.
Generally speaking, long-lived feature branches should be avoided in SVN,
since the merging is incredibly painful.
Why? As long
Adem schrieb:
About that 64bit/32bit issue..
I don't really see what all that fuss was about.
Here are the timings:
FPC_x64: 489.4
FPC_x86: 632.7
.. which sounds very unlikely to me. Almost all benchmarks so far showed
FPC 32 bit being in front of the 64 bit version.
Jonas Maebe schrieb:
Florian Klaempfl wrote on Fri, 16 Jul 2010:
One of the bottlenecks the common user encounters, is unit loading:
especially projects like the lazarus suffer from the time spent into
unit loading while I suspect that it narrows down also to procedures
like fillchar which
Am 24.07.2010 13:42, schrieb Nikolai Zhubr:
use them to implement this special management so as exceptions and
threadvars can be actually used without explicitely using OS APIs.
Delphi does not use a segment register for threadvar handling but OS calls.
Am 25.07.2010 12:05, schrieb Hans-Peter Diettrich:
It looks to me as if a ppu reader can provide the information for
previously compiled modules, so that a scanner/parser is not always
required to load a used module?
Probably no.
Parser
now is derived from the tscannerfile class.
This is
Am 26.07.2010 22:15, schrieb Graeme Geldenhuys:
Just offering negative comments and shooting down ideas, do not help
this or any other discussion. If you give negative comments, try back
it up with an additional suggestion or two.
I've enough great ideas and suggestions but not enought to
Am 26.07.2010 22:36, schrieb Marcos Douglas:
and if we send the code and, even like that, it
will not approved?
Within 17 years of FPC, no contribution to the compiler was completely
rejected, so no need to worry. And if one still worries: just write a
paper/wiki page explaining what shall be
Am 26.07.2010 22:51, schrieb Graeme Geldenhuys:
Otherwise I would have implemented many things already
- but I doubt any of those would be applied.
What makes you think so? Which compiler patches did we reject so far?
___
fpc-devel maillist -
Am 26.07.2010 23:00, schrieb Graeme Geldenhuys:
On 26 July 2010 22:47, Florian Klämpfl flor...@freepascal.org wrote:
The person who implementes, decides, so most of the discussion is a
waste of time.
Then please send that memo to Macro, he clearly didn't get it
Where? I didn't read
Am 28.07.2010 23:18, schrieb Daniël Mantione:
Op Wed, 28 Jul 2010, schreef Hans-Peter Diettrich:
Daniël Mantione schrieb:
If I understand it well this patch will disable not only the fpc
externsion:
writeln(name_of_function);
... but also the standard Pascal:
name_of_function:=value;
Am 30.07.2010 20:55, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
The first version of the OO rewrite branch is ready for alpha testing
:-)
Well, the alpha test revealed some problems, that have been fixed
(except one).
Now the differences between branch and updated trunk
Am 31.07.2010 02:23, schrieb Marco van de Voort:
In our previous episode, Hans-Peter Diettrich said:
As a first step, I consider the result of
cd compiler
time make cycle
with a hot disk cache before and after a change as good enough to see if
a change hurts performance.
What's the Windows
Am 31.07.2010 02:06, schrieb Sergei Gorelkin:
Hello,
I have discovered that the pointer returned by typeinfo() builtin in FPC
is very different from one returned in Delphi. What Delphi returns
points to rough equivalent of FPC's INIT$_typename structure, so one
may examine the structure to
Am 05.08.2010 22:19, schrieb _-jan...@web.de:
Hello everybody,
I would like to propose an enhanced replacement for the special assignment
operators += -= *= and /= :
More pascal-like would be constructs of the form operator := such as
a + := 1;
a div := 3;
a or := b;
a xor := 3;
Am 06.08.2010 05:05, schrieb Alexander Klenin:
On Fri, Aug 6, 2010 at 08:29, Michael Van Canneyt
mich...@freepascal.org wrote:
Pascal as it is, is a very readable language as opposed to C. Proposals such
as this diminish the readability.
FWIW, while migrating to FPC/newer Delphi,
I
Am 19.08.2010 21:39, schrieb Jonas Maebe:
On 19 Aug 2010, at 22:33, Hans-Peter Diettrich wrote:
Even if the code generation has not been touched, other targets still may
deserve minor updates, related to the changed types of some previously
global variables (pointers instead of direct
Am 20.08.2010 20:29, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
Currently the introduction of a new target CPU requires to update many
parts of the existing general compiler units,
E.g.?
I just greped for ifdef sparc in the general compiler directory:
11 hits:
Try the
Am 28.08.2010 13:54, schrieb Hans-Peter Diettrich:
Several type redefinitions are reported in compiling the compiler, can
these be removed?
Yes.
Most types (PByte...) are declared in systemh.inc and objpash.inc. I'm
not sure, but can't these redefinitions be excluded conditionally, for
Am 04.09.2010 19:41, schrieb Hans-Peter Diettrich:
Every parallel processing requires that all related data is private to
every thread. Since some time I'm trying to eliminate such (currently)
global variables.
What's the problem with using threadvars (I did not look at your code
yet, I were
Am 05.09.2010 14:17, schrieb Juha Manninen (gmail):
On Sunday 05 September 2010 13:29:38 Graeme Geldenhuys wrote:
Reading Jonas's comments and your reply above, it seems a git mirror
(or a subversion/git dual setup) would be much better suited for your
working style. git allows local commits
Am 05.09.2010 15:34, schrieb Hans-Peter Diettrich:
Some questions about tfileposinfo position variables:
1) What's the difference between current_tokenpos and current_filepos?
Normally the scanner updates both vars to the same value...
Current_tokenpos means the scanner position,
Am 05.09.2010 05:04, schrieb Hans-Peter Diettrich:
Jonas Maebe schrieb:
On 04 Sep 2010, at 19:41, Hans-Peter Diettrich wrote:
Every parallel processing requires that all related data is private
to every thread. Since some time I'm trying to eliminate such
(currently) global variables. Now
Am 05.09.2010 17:40, schrieb Graeme Geldenhuys:
On 5 September 2010 15:08, Florian Klämpfl wrote:
+1
I can recommend it, too.
In some earlier mail I mentioned it would solve DoDi's problems with merging
his branch with trunk after they have deviated much from each other.
The problem
Am 05.09.2010 19:04, schrieb Graeme Geldenhuys:
but rather features and
Indeed. And the features of git gui are just ridiculous. It misses even
basic stuff like good explorer integration.
usability.
Yes, unfortunatly, git gui is basically unusable on windows: most of the
time it's hanging.
Am 11.09.2010 19:50, schrieb Martin Schreiber:
On Saturday, 11. September 2010 16.12:10 Mattias Gaertner wrote:
Maybe dcc32 likes the MSEgui sources.
Or maybe FPC does not like MSEgui sources. ;-)
Martin, can you give a comparison between win32 and Linux 32?
I don't have a working Kylix
Am 11.09.2010 20:50, schrieb Martin Schreiber:
On Saturday 11 September 2010 20:27:46 Florian Klämpfl wrote:
What machine? Because with hot disk cache, I just build MSEide in about
10 s (15 s cold) on W7 64 Bit:
The same as for all other tests,
win2000, AMD Athlon XP 3000+, 1GB RAM
Am 11.09.2010 22:04, schrieb Jonas Maebe:
On 11 Sep 2010, at 21:10, Florian Klämpfl wrote:
Anyways, before this ends in an endless discussion: if anybody is
interested in improving FPC compilation speed (for my needs is
sufficient) and have a look at fillchar and, have a look at FPC's
Am 12.09.2010 07:33, schrieb Martin Schreiber:
On Saturday, 11. September 2010 21.10:20 Florian Klämpfl wrote:
Anyways, before this ends in an endless discussion: if anybody is
interested in improving FPC compilation speed (for my needs is
sufficient) and have a look at fillchar and, have
Am 12.09.2010 01:20, schrieb Graeme Geldenhuys:
On 11 September 2010 21:10, Florian Klämpfl flor...@freepascal.org wrote:
FPC
---
Linking mseidefp.exe
308574 lines compiled, 10.6 sec , 2577952 bytes code, 1618920 bytes data
Delphi
-
mseide.pas(63)
280491 lines, 2.18
Am 12.09.2010 10:21, schrieb Martin Schreiber:
On Sunday, 12. September 2010 10.12:59 Florian Klämpfl wrote:
Agreed. My opinion is that before we start to implement difficult and
error-prone multi-threading into FPC we should find out why the hell
Delphi 7 can compile so much faster
Because
Am 12.09.2010 10:39, schrieb Martin Schreiber:
On Sunday, 12. September 2010 10.29:32 Florian Klämpfl wrote:
And that results in a discrepancy of factor 5..10? I can't believe it.
Digging out 1.0.10 and using some extreme example:
C:\fpc\tests\webtbsc:\pp 1.0.10\bin\win32\ppc386.exe tw2242
Am 12.09.2010 18:24, schrieb Dimitri Smits:
- Marco van de Voort mar...@stack.nl schreef:
I partially agree with you in the fact that the exact reasons are
not known.
I'm no expert on profiling the compiler, but if I read the various
threads over the years I see defensive and
Am 12.09.2010 14:50, schrieb Martin Schreiber:
FPC:
E:\FPC\svn\fixes_2_4\tests\webtbfppc386 tw2242x.pp
Free Pascal Compiler version 2.4.0 [2009/12/18] for i386
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Win32 for i386
Compiling tw2242x.pp
tw2242x.pp(16386,7) Fatal: Procedure
Am 12.09.2010 18:39, schrieb Martin Schreiber:
On Sunday, 12. September 2010 18.29:34 Florian Klämpfl wrote:
Please take it with humor. :-)
As long as the compiler itself builds on a reasonable machine in less
than 10 seconds, I'am happy :)
Yup, I know. But there are people who use FPC
Am 14.09.2010 19:39, schrieb Leonardo M. Ramé:
Sorry Florian, the error happened trying to compile some auto-generated code
with wrong property assignments, with overloaded setters. It's fixed now.
In FPC or your code?
Leonardo M. Ramé
http://leonardorame.blogspot.com
--- On Tue,
Am 14.09.2010 21:31, schrieb Leonardo M. Ramé:
My code, don't worry.
Well, I worry because no code to compile should be able to trigger an
internal error.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 29.09.2010 17:26, schrieb Alexander Klenin:
On Thu, Sep 30, 2010 at 00:05, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Florian Klaempfl schrieb:
Now I'll resume my original work on multiple front-ends, this time using
a git repository
Well, I wonder what the advantage of this will
Am 29.09.2010 19:42, schrieb Florian Klämpfl:
too much supported platforms and
features and too few developers working on bug fixing.
Just as a side node, development of open bugs during the last years:
summary_graph_cumulative_bydate.php.png
___
fpc
Am 29.09.2010 19:49, schrieb Florian Klämpfl:
Am 29.09.2010 19:42, schrieb Florian Klämpfl:
too much supported platforms and
features and too few developers working on bug fixing.
Just as a side node, development of open bugs during the last years:
summary_graph_cumulative_bydate.php.png
Am 29.09.2010 20:00, schrieb Mattias Gaertner:
Hi fpc devels,
I did some test with an integrated fpc (e.g. in an IDE) and sharing
redirecting the file access. For example FPC could use the files
of the IDE. This would allow to compile without saving to disk, so the
compiler could be used
Am 29.09.2010 22:05, schrieb Hans-Peter Diettrich:
Florian Klämpfl schrieb:
too much supported platforms and
features and too few developers working on bug fixing.
Just as a side node, development of open bugs during the last years:
summary_graph_cumulative_bydate.php.png
This situation
Am 30.09.2010 19:12, schrieb Adem:
On 2010-09-30 19:39, Michael Van Canneyt wrote:
If you want to move the *global variables* (as in: unit scope)
CExportLib,ExportLib to globals, you must add export to the globals unit.
Not only do I think they should be moved to globals.pas, I also think
Am 30.09.2010 19:53, schrieb Adem:
On 2010-09-30 06:59, Florian Klämpfl wrote:
Am 30.09.2010 19:12, schrieb Adem:
On 2010-09-30 19:39, Michael Van Canneyt wrote:
If you want to move the *global variables* (as in: unit scope)
CExportLib,ExportLib to globals, you must add export
Am 30.09.2010 20:21, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
All refactoring steps can be verified immediately, using make all and
compiler/make fullcycle.
Well, and running the regression tests on all targets
For what purpose? When both changes to the trunk and branches
Am 30.09.2010 21:06, schrieb Hans-Peter Diettrich:
Jonas Maebe schrieb:
The basic problem is that his rewrite made ppudump dependent on the
code generator, not that ppudump's independence of the code generator
is enforced by the build system.
Then *ppudump* must be hacked further, since
Am 02.10.2010 20:07, schrieb Hans-Peter Diettrich:
Some notes on the compiler API/interface for external tools, based on my
observation of the ppudump program.
When this API *really* shall be target independent, as some people
believe it already is,
There is no official API neither it is
Am 03.10.2010 11:37, schrieb Sven Barth:
Hello together!
While I looked for a solution for the bug report about external threads
on Windows ( http://bugs.freepascal.org/view.php?id=17300 ), I found the
following code in SysRelocateThreadVar in rtl/win/systhrd.inc:
begin
Am 03.10.2010 20:06, schrieb Sven Barth:
Willibald can get access to a branch to commit his work.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 03.10.2010 22:30, schrieb Marco van de Voort:
In our previous episode, Hans-Peter Diettrich said:
[...]
-K File[ File]*
Command line arg to tell fpc to compile
program/dll with runtime package support.
I don't like the Delph
Am 09.10.2010 15:22, schrieb Hans-Peter Diettrich:
Now I hope that this patch will be applied to the trunk soon.
No. It's a mess and I won't sort it out. Not to mention the indentation
style not following the style used in the surrounding code, comments I
made about the older patch are ignored,
Am 10.10.2010 00:32, schrieb Hans-Peter Diettrich:
Florian Klämpfl schrieb:
Now I hope that this patch will be applied to the trunk soon.
No. It's a mess and I won't sort it out.
What do you feel a need for sorting out?
Splitting the patch in understandable parts which can be committed
Am 10.10.2010 06:56, schrieb Hans-Peter Diettrich:
Florian Klämpfl schrieb:
Am 10.10.2010 00:32, schrieb Hans-Peter Diettrich:
Florian Klämpfl schrieb:
Now I hope that this patch will be applied to the trunk soon.
No. It's a mess and I won't sort it out.
What do you feel a need for sorting
Am 10.10.2010 15:41, schrieb Hans-Peter Diettrich:
Florian Klämpfl schrieb:
What do you feel a need for sorting out?
Splitting the patch in understandable parts which can be committed
separately with appropriate commit messages,
I.e. one patch for every single moved variable???
If needed
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
compiler for no gain.
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 into the
trunk.
I won't merge
Am 19.10.2010 16:42, schrieb Alexander Klenin:
On Wed, Oct 20, 2010 at 01:30, Martin Schreiber mse00...@gmail.com wrote:
On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
1) I have serious suspicions that compile time on modern processors
is dominated by linking and I/O.
At least
Am 22.10.2010 23:17, schrieb Dariusz Mazur:
full source in attachment (should I prepare it different?)
The best would be a diff against compiler sources.
Second: when I review assembler list I've notice some strange lines (all
optimizations are enabled):
# [124] dec(ii);
movl
Am 23.10.2010 22:46, schrieb Dariusz Mazur:
W dniu 2010-10-22 23:30, Florian Klämpfl pisze:
Am 22.10.2010 23:17, schrieb Dariusz Mazur:
full source in attachment (should I prepare it different?)
The best would be a diff against compiler sources.
OK. First I find better computing of hash
Am 23.10.2010 15:47, schrieb Willibald Krenn:
Hi!
I stumbled accross a bug in fpc that manifests itself when working with
bitpacked records that have fields with pos and size mod 8 == 0; For
example:
type
TField = bitpacked record
case boolean of
true: (value : integer);
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 implemented protocols. Bytes, when aggregated
can clearly exceed the 2GB limitation within
Am 20.11.2010 14:30, schrieb Marco van de Voort:
In our previous episode, Sergei Gorelkin said:
2. THandleStream has a field FHandle which is defined as Integer. Now
this handle is filled either by the constructor which takes an Integer
as well or by e.g. TFileStream which gets its handle
Am 20.11.2010 16:43, schrieb Paul Ishenin:
Moreover those who need to port
their projects to FPC will need to review their assember anyway because
as I know assember is not compatible.
Delphi assembler is supposed to work?
___
fpc-devel maillist -
Am 23.11.2010 20:18, schrieb Aleksa Todorovic:
Hi!
I've attached several patches regarding generics some time ago
(http://bugs.freepascal.org/view.php?id=15875,
http://bugs.freepascal.org/view.php?id=11777), but there was no
response regarding them. Is anyone from fpc developers working on
Am 29.01.2011 19:04, schrieb Paul Ishenin:
30.01.2011 0:50, Sven Barth wrote:
Should I add the flag set to TSymtable or tstoredsymtable? (only the
latter can write/save itself to ppu)
I would add it to TSymTable.
I really wonder that symtables have no flag set yet. Please move
Am 29.01.2011 17:58, schrieb Sven Barth:
This is one of those moments where I need to restrain myself to not
swear for the whole world to hear...
Ok, you'll really swear as soon as people test their code with your
implementation :)
___
fpc-devel
Am 29.01.2011 23:22, schrieb Sven Barth:
Here are the new results with the search for class helpers enabled (only
two runs this time):
Run 1:
real2m22.980s
user0m47.140s
sys0m4.333s
Run 2:
real2m15.362s
user0m47.274s
sys0m4.140s
With which times are those
Am 30.01.2011 12:37, schrieb Martin Schreiber:
On Sunday, 30. January 2011 12.13:21 Florian Klämpfl wrote:
Actually I think anything about a ten percent slower compiler will
people make cry ... And as far as I understand, for projects with a lot
of units it will be even worse, right?
I cry
Am 06.03.2011 22:46, schrieb Jeppe Johansen:
As I wrote a while back, I would like to make it easier to handle
interrupts when using fpc for embedded work
After reading the related discussion, I think the approach is fine.
Further, a future benefit of using the interrupt keyword could be
Am 13.03.2011 11:26, schrieb Sven Barth:
I'd like to know how I should proceed
regarding these (and possible also the first two, as they might take
their time as well ^^ ).
Implement things as those were fixed.
As I don't think it's a good idea to put the handling in TSymtableStack
itself I
Am 13.03.2011 22:14, schrieb Sven Barth:
Am 13.03.2011 16:40, schrieb Florian Klämpfl:
Am 13.03.2011 11:26, schrieb Sven Barth:
I'd like to know how I should proceed
regarding these (and possible also the first two, as they might take
their time as well ^^ ).
Implement things as those were
Am 09.04.2011 20:08, schrieb Sergei Gorelkin:
Hello,
I wonder whether it is possible to assign a priority (or order) of
registers for FPC's register allocator. Currently registers are
allocated in the order of ordinals defined in cpubase.pas. On i386 it
doesn't make any difference, but on
Am 09.04.2011 21:04, schrieb Sergei Gorelkin:
09.04.2011 22:26, Sergei Gorelkin пишет:
09.04.2011 22:13, Jonas Maebe пишет:
Simply changing the register order in the array to trgcpu.create in
Tcgx86_64.init_register_allocators should do it.
Hmm, that was the first thing I tried, but it
Am 09.04.2011 21:34, schrieb Daniël Mantione:
I think the challenge is do design some generic infrastructure to tell
the register allocator about biasing it should do, and then to add some
heuristics somewhere else (like leaf/non-leaf) to give the register
allocator the proper instructions.
Am 09.04.2011 22:22, schrieb Sergei Gorelkin:
09.04.2011 23:10, Florian Klämpfl пишет:
Problem is, this might hurt non leaf functions. Maybe the register
allocators can be initialized differently for leave and non-leave
functions?
I understand the concern, but it should be handled somehow
Am 10.04.2011 12:38, schrieb Sergei Gorelkin:
By now I had run the test suite in x86_64-linux, without regressions.
Feel free to commit it then.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 10.04.2011 18:30, schrieb Sergei Gorelkin:
AFAIK every 64-bit capable x86 has at least SSE2 available, so SSE2 code
is safe to be the default one
Yes.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 11.04.2011 14:29, schrieb Jonas Maebe:
On 11 Apr 2011, at 02:31, Paul Ishenin wrote:
Looks like some random byte is generated at this address.
Maybe r17285? Although I don't immediately see a problem with it, I
can't see any other revision from yesterday that could introduce such a
Am 11.04.2011 02:31, schrieb Paul Ishenin:
Hello, FPC developers' list.
I can't build FPC today. Executable is always differ by one byte with
the previous and cmp don't let me continue after make cycle:
D:/programming/fpc_2_4/bin/i386-win32/cmp.exe -i218 ppc3.exe ppc386.exe
ppc3.exe
Am 13.04.2011 12:11, schrieb Sven Barth:
Am 12.04.2011 21:41, schrieb Sven Barth:
The latter change is not yet commited (I will do that tomorrow), but the
implementation of the flag and the removing of current_syssym are
already commited.
Done.
Looks good to me now. So imo it can be
Am 15.04.2011 11:39, schrieb Sven Barth:
Am 14.04.2011 22:29, schrieb Florian Klämpfl:
Am 13.04.2011 12:11, schrieb Sven Barth:
Am 12.04.2011 21:41, schrieb Sven Barth:
The latter change is not yet commited (I will do that tomorrow), but
the
implementation of the flag and the removing
Am 16.04.2011 15:27, schrieb Florian Klämpfl:
Am 15.04.2011 11:39, schrieb Sven Barth:
Am 14.04.2011 22:29, schrieb Florian Klämpfl:
Am 13.04.2011 12:11, schrieb Sven Barth:
Am 12.04.2011 21:41, schrieb Sven Barth:
The latter change is not yet commited (I will do that tomorrow
Am 19.04.2011 12:12, schrieb Daniël Mantione:
Op Tue, 19 Apr 2011, schreef Nikolai Zhubr:
ms (supposedly) decided to just not preserve FPU/MMX state between
64-bit processes.
MS does preserve FPU states between processes. You can use the x87 on
Windows, nothing prevents you from doing
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 algorithms convert faster with
Am 20.04.2011 10:01, schrieb Pocket MicroTechnics Support:
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;
in this case, how does the compiler handle this
Am 20.04.2011 11:26, schrieb Michael Schnell:
On 04/19/2011 03:14 PM, Florian Klaempfl wrote:
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.
Doing things like
Am 20.04.2011 15:04, schrieb Hans-Peter Diettrich:
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
Am 21.04.2011 21:14, schrieb Micha Nelissen:
Florian Klaempfl wrote:
Am 19.04.2011 15:18, schrieb Marco van de Voort:
You'll need to runtime test for SSE3 though. Since the first
generation of
athlon64's (clawhammer and friends, socket 751 or so) doesn't have SSE3.
For such a relatively
Am 13.05.2011 20:09, schrieb Joerg Schuelke:
Any example where it makes really a difference?
The same effect can be achieved by an invocation like
dp(x,[y,z]);
just as in Format().
I think only in this special case, because of the ellipsis in that
array of const, which is build-in.
Am 13.05.2011 17:41, schrieb Martin:
On 13/05/2011 15:19, Hans-Peter Diettrich wrote:
Replacement of $IFs. (Around DebugLn...)
That one is solved already, with existing macros.
rtl\inc\lnfodwrf.pp
{$MACRO ON}
//{$DEFINE DEBUG_DWARF_PARSER}
{$ifdef DEBUG_DWARF_PARSER}
{$define
Am 14.05.2011 01:23, schrieb Joerg Schuelke:
A third one.
It is a further single and isolated solution to prevent the use of a
macro. How many of them are there around? A hundert, a thousand in 5
years?
It simply shows that in a modern programming language macros has few
real use cases
Am 14.05.2011 00:06, schrieb Joerg Schuelke:
A macro processor is the simplest way to generate such pieces of source
code. If it is that simple doing it another way you say, why can I
find in the compiler sources more then one example of this.
Because a lot of code in the compiler is very
Am 14.05.2011 14:43, schrieb Hans-Peter Diettrich:
Florian Klämpfl schrieb:
It simply shows that in a modern programming language macros has few
real use cases because there are a lot of other constructs which serve a
similiar purpose.
ACK
Nonetheless I wonder which efforts had
1 - 100 of 795 matches
Mail list logo
