On 2010-05-19 10:33, Graeme Geldenhuys wrote:
Florian Klaempfl het geskryf:
At least we try to avoid it to make it people too easy to shoot themself
into the foot.
Developers should be free to shoot themselves wherever they want! It should
be their choice, not yours. :-)
Graeme,
arguement to 'Delphi mode', but
allow it in FPC native mode?
--
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
o that lib than it's taking now.
Given that all these projects have been going on for so long, it may not
even have to be called beta.
--
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
se.]
If there's not one, I wonder if people here think it would be a good
idea to have one?
--
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 2010-06-10 00:11, German Gentile wrote:
2010/6/9 Adem <mailto:listmem...@letterboxes.org>>
So, what I am getting at is this: Is there such a list/platform
where only architectural/design issues (no commit details, no
coding minutea etc.) are discussed?
I always th
?
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
en regular PC’s have
these days. "
There were a couple of charts showing how enredibly useful TopMemory
could be when speed is the overriding factor, but no indication about
how hungry it is for memory.
Any comments on that?
Cheers,
Adem
__
(plus the
much higher bandwidths of SATA3, USB3) is it feasible to further
optimize IO speeds for the compiler at this stage?
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
use our enhanced RTL, and make thread by yourself (not using the
TThread object), you'll have th e best multi-thread performance possible.
From this, I gather TopMM is a "GOOD THING"; and from Ivo's TopMM site,
he seems to have in
I did some rough + emprical (i.e. non-exhaustive + non-authoritative)
tests with the native memory managers of
-- x64 FPC (v2.4.3)/Lazarus (v0.9.29-26670),
-- Delphi (2010),
-- FastMM4 v4.94
-- TopMemory v3.54.
Test application is fairly simple: Using a double-linked list, it
generated 1,000,0
On 2010-07-17 09:33, Micha Nelissen wrote:
Adem wrote:
I did some rough + emprical (i.e. non-exhaustive +
non-authoritative) tests with the native memory managers of
-- x64 FPC (v2.4.3)/Lazarus (v0.9.29-26670),
-- Delphi (2010),
So this is 32 bit vs 64 bit?
Windows 7, x64.
Delphi: 32-bit
On 2010-07-17 10:37, Florian Klämpfl wrote:
Adem schrieb:
Windows 7, x64.
Delphi: 32-bit.
FPC: 64-bit.
So one of the most useless benchmarks I ever saw.
Focus of that 'test' was to see how TopMM compares with FastMM (both
Delphi only), which turned out that FastMM is 50% f
On 2010-07-17 11:15, Thaddy wrote:
That's not a test. A) 32/64 and B)
It's not as if 32bit is faster than 64bit --well, not at least on my
machine here; in fact 32bit is 30% slower.
You should test parallelization, i.e. threads over multi processors
(pref quadcore or more) to see the effect of
And, the code I used was this.
Now, I'd like to ask why every now and then (something like 1 in 10) I
get a negative value for Time3 under FPC. Delphi never exhibits that
behavior.
function GetCPUTicks: Int64;
asm
RDTSC;
end
procedure TForm1.ButtonPerformanceClick(Sender: TObject);
Const
On 2010-07-17 14:27, Marco van de Voort wrote:
In our previous episode, Adem said:
Now, I'd like to ask why every now and then (something like 1 in 10) I
get a negative value for Time3 under FPC. Delphi never exhibits that
behavior.
Afaik Delphi does so too, iirc the timestamp counter
On 2010-07-17 16:00, Florian Klämpfl wrote:
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
On 2010-07-17 17:37, Hans-Peter Diettrich wrote:
Can you show the time for Node1.Free as well?
Fast allocation can result in slow deallocation...
*FPC_x86*
Time to Create: 632.7
Time to Destroy: 471.69
*FPC_x64*
Time to Create: 489.4
Time to Destroy: 468.94
__
Correction.
*FPC_x64*
Time to Create: 471.41
Time to Destroy: 300.57
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 2010-07-17 23:08, Mattias Gaertner wrote:
That's not needed.
Use fpc.exe and it will call the right compiler. Make sure your fpc.cfg
contains macros and the paths are right.
This is what I did:
I installed 32bit version in folder C:/FPC_Lazarus_x86 and 64bit version
in C:/FPC_Lazarus_x64,
On 2010-07-17 19:27, Juha Manninen wrote:
Adem wrote:
BTW, is there some way of having both 32bit and 64bit FPC/Lazarus
coexist in the same machine?
With Lazarus it is easy. You just compile it and rename the binary. It does
not need to be installed.
With respect, this is a clumsy and painful
On 2010-07-18 11:41, Mattias Gaertner wrote:
/usr/lib/fpc/2.4.1/units/i386
Translate this to some windows paths you like and adapt your fpc.cfg.
Quick question. I took a look at 'Installing Lazarus' [
http://wiki.lazarus.freepascal.org/Installing_Lazarus ] and all the
examples for paths have
[Please bear with me while I am trying to formulate this question; it
is a tough one to do succinctly]
If I am not mistaken, a version X of FPC is guaranteed to be compilable
with version (X - 1).
If that is so, I am assuming, one would not have to 'make' version X;
meaning you could compil
On 2010-07-23 4:41 PM, Marco van de Voort wrote:
In our previous episode, Joost van der Sluis said:
I think that fpmake.pp is exactly what you want. Only it doesn't work
fully yet.
If fpmake works, we don't need make anymore.
It is not, since it requires an installed RTL + fpmkunit to create
On 2010-07-23 8:38 PM, Marco van de Voort wrote:
In our previous episode, Adem said:
Now, what I'd like to know is what generates those 'fpmake.pp' files, so
that I might take a shot altering it to generate 'fpmake.pp.inc' files
the way I wanted.
They are not generate
I am using the latest TortoiseSVN to get a full local copy of FPC, but
--even thought I tried several times, with 'cleanup's-- I keep getting
this error:
GET of '/svn/fpc/!svn/bc/9386/trunk/rtl/inc/wustrings.inc': Checksum
invalid for compressed stream (http://svn.freepascal.org)
and, it fa
On 2010-07-24 1:28 PM, Graeme Geldenhuys wrote:
This is easy to do with a few IFDEF lines...
{$IFDEF APROGRAM}
{...}
{$ENDIF}
{$IFDEF APROGRAM}
{...}
{$ENDIF}
Now if APROGRAM is defined, they act as self-contained programs. If
not, they act as include files and can be combined.
There are
On 2010-07-25 7:36 PM, Jonas Maebe wrote:
On 24 Jul 2010, at 13:28, Adem wrote:
I am using the latest TortoiseSVN to get a full local copy of FPC,
but --even thought I tried several times, with 'cleanup's-- I keep
getting this error:
GET of '/svn/fpc/!svn/bc/938
On 2010-07-25 11:15 PM, Florian Klämpfl wrote:
Why don't you use separate parser classes for different purposes?
Declarations, Function bodies, expressions etc.?
First hurdle is to find a comprehensive enough descriptions of each and
every construct there is --including interfaces and generics.
I am not sure if this has been proposed, but wouldn't it make life a
lot easier if we considered the 'namespaces' metaphor as something that
resembles to URLs.
Here is an example:
In the project file, I'd like to have these declarations:
namespace Lazarus readonly url 'C:/Program Files/Lazar
On 2010-07-26 11:31 PM, Marcos Douglas wrote:
Please, see that:
http://lists.freepascal.org/lists/fpc-devel/2010-July/020699.html
http://lists.freepascal.org/lists/fpc-devel/2010-July/020791.html
http://lists.freepascal.org/lists/fpc-devel/2010-July/020856.html
http://lists.freepascal.org/lists/
On 2010-07-27 1:08 AM, Graeme Geldenhuys wrote:
2010/7/27 Adem :
I wouldn't have much of an issue with something like
uses
zip IN '/units/my/zip.pas' AS myzip;
zip IN '/units/lib/zip/zip.pas' AS ziplib;
And if you have multiple developers working on the same proj
On 2010-07-27 4:14 AM, Martin wrote:
And, it seem you did not read the rest of my post (including the
first one with this subject line) :)
Yes.
I am with Graeme on this one, as in I do not see what you may have
written, that solved the above
To be sure: this mail ?:
http://lists.freep
Correction:
You would make a NOTE of that in a cfg file --either a global one, or
per project.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 2010-07-27 5:06 AM, Martin wrote:
You would make a notE of that in a cfg file --either a global one, or
per project.
You mean as in a namespace to path translation?
so I write in my cfg
C:\laz_svn\ = C:\lazarus
?
Can we please think out of the box of how you would fit that in the cfg
file
On 2010-07-27 8:49 AM, Martin wrote:Yes, in that example, 'laz_svn'
would be a central indirection identifier to your 'C:\lazarus'.
It is helpfull, if something looking like a path to the file, is wrong
pointing to the wrong location for at least half of the developpers
working on a project??
On 2010-07-27 1:10 PM, Joost van der Sluis wrote:
I don't know what you want,
Wel... it all started here [
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg17986.html ].
In short, I was trying to test/benchmark a FPC/Lazarus generated exe
against one with Delphi, but I kept havi
On 2010-07-27 3:22 PM, Marc Weustink wrote:
IOW, both versions wouldn't coexist under the same OS (Windows 7).
If you don't use the installer but build lazarus yourself from the
sources, both 32 an 64 bit version of lazarus can run side by side.
No problems with that. (ok, you need to rename la
On 2010-08-06 1:23 PM, Alexander Klenin wrote:
Correct.
I agree.
That is why reducing it to a required minimum is a good thing.
I agree with the idea.
But, not with the proposal.
Not the way it is made, anyway.
Why not come up with a small application/utility that caters for the
oppositio
On 2010-08-07 6:17 PM, Martin wrote:
The data in MyObj.PointArrayField belongs to MyObj => so why not tell
MyObj what to do with that data?
First I thought it meant 'therefore', 'hence' or 'thus', but replacing
'=>' in the sentence above did not make much sense.
What is it supposed to mean?
Sometime ago, there was a brief mention of multi-threading FPC would be
counter productive because compilation process was mostly disk IO bound
--this is what I understood anyway.
I wanted to check to see if disk IO was really limiting FPC/Lazarus
compile performance.
The only quick way I
On 2010-09-10 06:54 PM, Jonas Maebe wrote:
On 10 Sep 2010, at 17:43, Adem wrote:
SSD: 103,060 ms (1 min 43 sec)
RAMDisk: 105,463 ms (1 min 46 sec)
This doesn't make sense. FPC/Lazarus compiles on the faster medium
longer (albeit only 3 sec.).
I am sorry, but what you've
On 2010-09-10 07:16 PM, Daniel wrote:
This happens because the time it takes to SWITCH between one file to
another is significant. Ending one operation (a single file transfer)
and begining another takes a time slice. Summing up all these start
and finish ops takes a significant time slice.
I wo
On 9/12/2010 12:41 PM, Jonas Maebe wrote:
In discussions with Hans, it is said that I/O is not a factor, since after
one run everything is cached anyway, and then in this thread I/O is to blame
for a huge difference in speed.
Disk throughput doesn't really matter. Reading directory contents, ge
On 9/12/2010 12:53 PM, Jonas Maebe wrote:
On 12 Sep 2010, at 11:41, Jonas Maebe wrote:
There's a free profiler for Windows by AMD:
http://developer.amd.com/cpu/codeanalyst/Pages/default.aspx
And by Microsoft: http://msdn.microsoft.com/en-us/performance/cc825801.aspx
It's a 2.5G download --
On 9/12/2010 8:14 PM, Jonas Maebe wrote:
Besides, FPC on Windows does not start any other executables when compiling
programs
You might be making a distinction (between compiling and building) here,
but when I press 'rebuild lazarus' on that menu, here the list
executables of executables cal
Martin,
Could I have a copy of this exact setup --unless it is too big to send.
Cheers,
Adem
On 9/13/2010 12:15 PM, Martin Schreiber wrote:
Hi,
Some numbers about the MSEide exes compiled as testcase in
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html
System
While trying to update my local SVN copy, I get this error: "Can't
find a temporary directory: Internal error"
I looked it and it seems the SVN server has run out of disk space.
Either that or there's an access problem for /tmp.
___
fpc-devel maillis
On 2010-09-29 02:17, Hans-Peter Diettrich wrote:
I couldn't find any way to move global variables from globals.pas into
e.g. fmodule (tmodule, current_module), without breaking ppudump
dependencies.
I suspect you have thought about this, but let me try anyway.
If globals.pas is where twins a
On 2010-09-29 11:47, Michael Van Canneyt wrote:
On Wed, 29 Sep 2010, Adem wrote:
While trying to update my local SVN copy, I get this error: "Can't
find a temporary directory: Internal error"
I looked it and it seems the SVN server has run out of disk space.
Either tha
tions.") it's not clear to me why ppudump
must be a strictly independent stand-alone executable.
Could you elaborate why you think it should be.
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailm
code generator, not that ppudump's independence of the code generator
is enforced by the build system.
Could it not be the other way around?
That, it turned out that ppudump wasn't as independent as had been thought?
--
Cheers,
Adem
___
fpc
On 2010-09-30 16:07, Jonas Maebe wrote:
On 30 Sep 2010, at 14:43, Adem wrote:
On 2010-09-30 15:03, Jonas Maebe wrote:
And the reason I said that is because Hans-Peter's wants to move it
inside the compiler so that making ppudump depend on the code
generator would no longer break the
reeBSD},SysCtl,{$endif} which could
easily be added to the uses section (or the body) of globals.pas.
-- cpuinfo.pas
Uses no external units. Comprises of a few type/constant declarations.
IOW, all these units could be combined into globals.pas
[ Curious: Why does every
ould like to know is why seem to think this is a bad idea?
Further, I think the NoGlobals brach is a very good starting point
before moving on to multiple front-ends etc.
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://
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 to the globals unit.
Not only do I think they
On 2010-09-30 20:56, Florian Klämpfl wrote:
Am 30.09.2010 19:53, schrieb Adem:
It is only more logical/sensible to bring together all these
one-instance global objects into a one-instance global object,
instead of having them scattered all around the place.
I hope you are joking ...
I have
On 2010-09-30 21:21, Andrew Brunner wrote:
2010/9/30 Adem:
It is only more logical/sensible to bring together all these
one-instance global objects into a one-instance global object, instead of
having them scattered all around the place.
I hope you are joking ...
I have read the above
More hit data:
fpc/trunk/packages/
GetMem(): 1464 hits
FillChar(): 608 hits
trunk/lazarus/
GetMem(): 522 hits
FillChar(): 1366 hits
--
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
identify the caller) easier.
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 2010-10-09 17:50, Andrew Brunner wrote:
2010/10/9 Adem:
Would you consider turning those structured types into objects?
Properties with getter/setter pairs would make tracing (placing a breakpoint
in the getter/sertter would help identify the caller) easier.
The only problem with that
this:
In a (self) compile operation, how many times are either of these these
routines called?
--
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
project, it fails saying winTools32 is
missing. This is in the uses section of winDbgProc.pas
Any idea where I can locate winTools32.pas?
--
Cheers,
Adem
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 2010-10-28 10:23, Graeme Geldenhuys wrote:
Op 2010-10-28 03:19, Adem het geskryf:
Any idea where I can locate winTools32.pas?
I just had a look at the repository history of duby. wintools32.pas
was
removed in r230. The commit comment was that it had to be replaced by FCL.
I'm not su
On 2011-04-11 14:49, Felipe Monteiro de Carvalho wrote:
On Sun, Apr 10, 2011 at 4:46 PM, Skybuck Flying wrote:
This project is about "porting" the Free Pascal Compiler to Delphi XE.
I am curious: What is the use for this?
The last time (a year or so ago) I played with the compiler code (und
On 2011-06-30 17:07, Hans-Peter Diettrich wrote:
The idea is a merge of reference counting and thread synchronization,
which I could not find in any other language yet (dunno about ADA in
detail), but which can be implemented easily in OPL/FPC. Inspiration
came from TThreadList and Interfaces.
On 2011-07-01 18:49, Hans-Peter Diettrich wrote:
Such a beast would deserve many coding efforts, which are unlikely to be
ever taken. It's much simpler to control existing references to an
object, since every use of an object deserves an object reference.
In a double-linked list (or a treeview
On 2011-07-02 02:29, Andrew Brunner wrote:
2011/7/1 Adem:
There is no thread-safe way to write to those variables safely without
blocking access to each and every object in the entire collection as
demonstrated.
Why each and every object? I thought (b)locking only those touched in
the Attach
67 matches
Mail list logo
