On Tuesday 05 October 2010 00:37:44 José Mejuto wrote:
Hello FPC,
I find a problem that I'm unable to resolve, with my limited skills.
In TReader when a property is a TClass it is being added to be
resolved after all components are loaded, but the Loaded call is
performed before this fixup,
On Tuesday 05 October 2010 01:00:19 Willibald Krenn wrote:
Hi,
I just tried and can reproduce this with fpc rev. 16078 on win64.
Same thing here on Linux , AMD64, few days old FPC trunk version.
Juha
___
fpc-devel maillist -
Mark Morgan Lloyd wrote:
I can confirm that I can build FPC 2.4.0 to run under Debian Lenny on
an ARM-based system (Cisco/Linksys NSLU2 Slug) using
make 'NOGDB=1' 'OPT=-dFPC_ARMEL -CfSOFT' all
This appears to be OK to the extent that it can compile Lazarus
0.9.28.3, although my initial
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
which go away if the make is restarted.
Jonas Maebe wrote:
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 which go
away if the make
Jonas Maebe wrote:
I've requested an account on the GCC compile farm
(http://gcc.gnu.org/wiki/CompileFarm, anyone contributing to any free
software project can do so), and I guess that at least one of their ARM
machines will also support OABI binaries.
If you don't get anywhere I might be
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
Hi!
Am Dienstag, den 05.10.2010, 10:50 +0300 schrieb Juha Manninen (gmail):
On Tuesday 05 October 2010 01:00:19 Willibald Krenn wrote:
Hi,
I just tried and can reproduce this with fpc rev. 16078 on win64.
Same thing here on Linux , AMD64, few days old FPC trunk version.
Thank you for
On 05 Oct 2010, at 11:38, Johann Glaser wrote:
Thank you for trying and confirming. Should I submit a bug report?
Somebody else already did: http://bugs.freepascal.org/view.php?id=17546
Jonas
___
fpc-devel maillist -
Hello Martin,
Tuesday, October 5, 2010, 9:56:41 AM, you wrote:
I find a problem that I'm unable to resolve, with my limited skills.
In TReader when a property is a TClass it is being added to be
resolved after all components are loaded, but the Loaded call is
performed before this fixup, so
On Tue, 5 Oct 2010, José Mejuto wrote:
Hello Martin,
Tuesday, October 5, 2010, 9:56:41 AM, you wrote:
I find a problem that I'm unable to resolve, with my limited skills.
In TReader when a property is a TClass it is being added to be
resolved after all components are loaded, but the Loaded
Hello FPC,
Tuesday, October 5, 2010, 1:10:43 PM, you wrote:
I do not have too much experience with components, but calling
Loaded several times does not look very fine.
MVC To the best of my knowledge: it should be called once only, after the
fixups.
MVC If it isn't so, this is a bug.
On Tue, 5 Oct 2010, José Mejuto wrote:
Hello FPC,
Tuesday, October 5, 2010, 1:10:43 PM, you wrote:
I do not have too much experience with components, but calling
Loaded several times does not look very fine.
MVC To the best of my knowledge: it should be called once only, after the
On Tuesday 05 October 2010 13:55:53 José Mejuto wrote:
if not Assigned(GlobalLoaded) then begin --
for i := 0 to FLoaded.Count - 1 do
TComponent(FLoaded[i]).Loaded;//
end;
finally
if not
Hello FPC,
Tuesday, October 5, 2010, 4:08:08 PM, you wrote:
As you can see the Loaded event is called (marked with some //-)
before calling GlobalFixupReferences,
MS Not if GlobalLoaded is set.
Yes, but it is not set, because BeginGlobalLoading is not called at
all from any point in the
Hi
It looks like the __caddr_t type in packages/libc/src/typesh.inc is declared
incorrectly.
In C, it is declared as typedef char *__caddr_t;, but in FPC, it is
declared as char, not PChar.
This is most obvious when using the ifc_ifcu.ifcu_buf field of the ifconf
structure in nifh.inc.
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() were being used in
pairs most of the time
17 matches
Mail list logo
