Hello.
Test, please ignore.
--
Best regards,
Maxim Ganetsky mailto:gan...@narod.ru
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hello,
This is a test e-mail following some listsserver maintenance, please
ignore.
Charlie
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hairy Pixels schrieb am Fr., 24. Juni 2022, 03:45:
>
>
> > On Jun 23, 2022, at 11:52 PM, Sven Barth
> wrote:
> >
> > As you can see at the end (see below) it falls back to 3.2.2 at the end.
> What commands did you execute to build FPC itself?
> >
>
> I have no idea what it did that. I’ve done
> On Jun 23, 2022, at 11:52 PM, Sven Barth wrote:
>
> As you can see at the end (see below) it falls back to 3.2.2 at the end. What
> commands did you execute to build FPC itself?
>
I have no idea what it did that. I’ve done this many times so I’m confused as
to what changed.
I used a
Hairy Pixels via fpc-devel schrieb am Do.,
23. Juni 2022, 04:08:
> I usually solve this by deleting the units folder but for some reason
> after pulling from main it simply won’t build. Can anyone explain why the
> PPU version is wrong? It’s all building from the same source directory so
> the
I usually solve this by deleting the units folder but for some reason after
pulling from main it simply won’t build. Can anyone explain why the PPU version
is wrong? It’s all building from the same source directory so the PPU version
in ppu.pas should be the same. Before I tried this I did
test plz ignore
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
It seems to be working tho--Alexander Grotewohlhttp://dcclost.com___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Jun 15, 2019, at 11:04 AM, J. Gareth Moreton
> wrote:
>
> It works! Everyone's just being very quiet for some reason.
>
> On 15/06/2019 14:40, Florian Klämpfl wrote:
>> Please ignore ...
>> ___
>> fpc-devel maillist -
It works! Everyone's just being very quiet for some reason.
On 15/06/2019 14:40, Florian Klämpfl wrote:
Please ignore ...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
---
Please ignore ...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
So I did try building it manually with the trunk, and for some reason it
failed on that as well, even though it didn't appear in the test suite
as a failure. Definitely confusing, but it tells me that the failure
might not be due to my changes. I'll keep an eye out though to see if
anything
On 03/05/2019 17:48, J. Gareth Moreton wrote:
So I was doing some refactoring work, and ran the test suites to see if
nothing broke. It turned out that I got a single failure in
test/cg/variants/tnofalvarol.pp - seems a little odd because my changes
weren't meant to change the output of
So I was doing some refactoring work, and ran the test suites to see if
nothing broke. It turned out that I got a single failure in
test/cg/variants/tnofalvarol.pp - seems a little odd because my changes
weren't meant to change the output of binary files in any way. But
looking at the test
Op 18-07-18 om 13:39 schreef Michael Van Canneyt:
On Wed, 18 Jul 2018, Bart wrote:
Hi,
Sorry if this is a RTFM question.
Whenever I make some changes to the sourcecode of e.g. a package or an
RTL-file, in order to test these changes I do a make clean/make
install in the root directory.
On Wed, 18 Jul 2018, Bart wrote:
On Wed, Jul 18, 2018 at 1:39 PM, Michael Van Canneyt
wrote:
In general: no.
OK
I pity the compiler devels, especially in the past with slower hardware.
Yes, it can be time-consuming.
But:
* if the package does not have dependencies, you can just
Bart schrieb am Mi., 18. Juli 2018, 23:36:
> On Wed, Jul 18, 2018 at 1:39 PM, Michael Van Canneyt
> wrote:
>
> > In general: no.
>
> OK
> I pity the compiler devels, especially in the past with slower hardware.
>
The compiler devels more often than not only work with the compiler and RTL
On Wed, Jul 18, 2018 at 1:39 PM, Michael Van Canneyt
wrote:
> In general: no.
OK
I pity the compiler devels, especially in the past with slower hardware.
>
> But:
> * if the package does not have dependencies, you can just recompile that
> package.
> cd packages/fcl-registry
> make clean
On Wed, 18 Jul 2018, Bart wrote:
Hi,
Sorry if this is a RTFM question.
Whenever I make some changes to the sourcecode of e.g. a package or an
RTL-file, in order to test these changes I do a make clean/make
install in the root directory.
(e.g. I change one line in
Hi,
Sorry if this is a RTFM question.
Whenever I make some changes to the sourcecode of e.g. a package or an
RTL-file, in order to test these changes I do a make clean/make
install in the root directory.
(e.g. I change one line in packages/flc-registry/src/regini.inc)
This takes several minutes
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Can sb test this program on TP/BP7 and tell me the result? Thank you.
program sometest;
{$ifdef fpc}
{$mode tp}
{$endiof}
Type
PChildThing = ^TChildThing;
TChildThing = object
constructor init;
end;
PSomething = ^TSomething;
TSomething =
BP 7.0 (real)
BP7.0 (protected)
VP2.1b279
all: not assigned
- Original Message -
From: Marco van de Voort mar...@stack.nl
To: fpc-devel@lists.freepascal.org
Sent: Wednesday, May 14, 2014 11:46 AM
Subject: [fpc-devel] test on TP
Can sb test this program on TP/BP7 and tell me
Voort mar...@stack.nl
To: fpc-devel@lists.freepascal.org
Sent: Wednesday, May 14, 2014 11:46 AM
Subject: [fpc-devel] test on TP
Can sb test this program on TP/BP7 and tell me the result? Thank you.
program sometest;
{$ifdef fpc}
{$mode tp}
{$endiof}
Type
PChildThing = ^TChildThing
In our previous episode, Tomas Hajny said:
Indeed (apart from the obvious typo endiof preventing compilation, of
course). Why / how could it give a different result?
I'm hunting down a problem with the TV form editor. (you replied in the
thread on the forum). The problem had this rough
On 14 May 2014, at 13:38, Marco van de Voort wrote:
In our previous episode, Tomas Hajny said:
Indeed (apart from the obvious typo endiof preventing compilation, of
course). Why / how could it give a different result?
I'm hunting down a problem with the TV form editor. (you replied in the
In our previous episode, Jonas Maebe said:
I'm hunting down a problem with the TV form editor. (you replied in the
thread on the forum). The problem had this rough structure, but it could be
this, or that the order of events fired is different. (IOW FV fires certain
events from the
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Am 25.01.2014 17:06, schrieb Florian Klaempfl:
Sorry, I forgot to setup up cleaning up backups so the mailing list
server ran out of disk space. So it stopped working, it should be back
again.
___
fpc-devel maillist -
On 19/01/2014 16:48, Martin wrote:
(Existing tests are still running, but since this is for feedback, the
results can be submitted later)
UNMODIFIED TRUNK rev 26506:
utils/digest output/i386-win32/log
Total = 6874 (24:6850)
Total number of compilations = 4177 (7:4170)
Successfully compiled
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Martin
Envoyé : dimanche 19 janvier 2014 18:42
À : FPC developers' list
Objet : [fpc-devel] test results trunk - Re: probably incorrect debug-
line-info
On 19/01/2014 22:31, Pierre Free Pascal wrote:
if you want to compare to test runs,
you should save at least three files at the end of each run:
output/$fpctarget/faillist
output/$fpctarget/log
and
output/$fpctarget/longlog
The best is to first compare the two log files with
diff utility.
...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
This is a test message to check that the list bot is getting the correct
address now. My apologies for the white noise.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Trying to run test suit out of r21343 results in
C:\prog\FPC_UTIL\make.exe full TEST_FPC=C:\prog\FPC\bin\i386-win32\fpc.exe
...
Free Pascal Compiler version 2.7.1 [2012/05/20] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling dotest.pp
Compiling
Trying to run test suit out of r21343 results in
C:\prog\FPC_UTIL\make.exe full TEST_FPC=C:\prog\FPC\bin\i386-win32\fpc.exe
...
Free Pascal Compiler version 2.7.1 [2012/05/20] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling dotest.pp
Compiling
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Max Nazhalov
Envoyé : dimanche 20 mai 2012 17:37
À : FPC Developers' list
Objet : [fpc-devel] Test suit compilation is broken for win32-i386 after
r21341
Jonas Maebe wrote:
Isn't it easier to simply copy all compiled libraries to the target when
they are compiled (just like compiled test programs are copied)?
this second approach (which works well for me) copies the libraries when
the are compiled. No need to expand the %needlibrary
On 30 May 2011, at 11:04, Bernd Mueller wrote:
Jonas Maebe wrote:
Isn't it easier to simply copy all compiled libraries to the target
when they are compiled (just like compiled test programs are copied)?
this second approach (which works well for me) copies the libraries
when the are
Jonas Maebe wrote:
On 30 May 2011, at 11:04, Bernd Mueller wrote:
Jonas Maebe wrote:
Isn't it easier to simply copy all compiled libraries to the target
when they are compiled (just like compiled test programs are copied)?
this second approach (which works well for me) copies the
On 30 May 2011, at 11:19, Bernd Mueller wrote:
Jonas Maebe wrote:
Why do you limit it to Linux targets?
I am not sure about the other targets.
LibraryFileName:= 'lib' +
ForceExtension(SplitFileName(PPFile[current]), 'so');
The above code builds the library name out of the test program
Jonas Maebe wrote:
On 30 May 2011, at 11:19, Bernd Mueller wrote:
Jonas Maebe wrote:
Why do you limit it to Linux targets?
I am not sure about the other targets.
LibraryFileName:= 'lib' +
ForceExtension(SplitFileName(PPFile[current]), 'so');
The above code builds the library name out
On 30 May 2011, at 11:37, Bernd Mueller wrote:
Jonas Maebe wrote:
Windows is not supported as a remote target, but it's indeed not
correct for all unix targets either. The prefix of a library is
always lib on all targets, afaik. The suffix is available via
dynlibs.SharedSuffix. The
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Bernd Mueller
Envoyé : lundi 30 mai 2011 11:38
À : FPC developers' list
Objet : Re: [fpc-devel] test suite, problem with missing libraries on the
target
Pierre Free Pascal wrote:
Just add a LibExt constant to dotest.pp source
with the same conditionals as for ExeExt, this should be enough.
const
ObjExt='o';
PPUExt='ppu';
{$ifdef UNIX}
ExeExt='';
LibExt='so';
{$else UNIX}
{$ifdef MACOS}
ExeExt='';
LibExt='so';
{$else MACOS}
Jonas Maebe wrote:
Maybe better would be to hardcode .so for Linux and FreeBSD, and use
dynlibs.SharedSuffix for all other targets.
maybe I am missing something, but wouldn't dynlibs.SharedSuffix retrieve
the library suffix for the host? So, when I am crosscompiling from
Windows, I would
On 30 May 2011, at 13:53, Bernd Mueller wrote:
Jonas Maebe wrote:
Maybe better would be to hardcode .so for Linux and FreeBSD, and
use dynlibs.SharedSuffix for all other targets.
maybe I am missing something, but wouldn't dynlibs.SharedSuffix
retrieve the library suffix for the host?
Jonas Maebe wrote:
On 23 May 2011, at 11:49, Bernd Mueller wrote:
I am running the test suite with remote execution (from a Windows
host) on an ARM-Linux target. Some test programs fail at runtime,
because they depend on libraries, which were not automatically copied
to the target. For
On 27 May 2011, at 14:56, Bernd Mueller wrote:
I have enough FLASH memory, so I am not using TEST_DELTEMP=1. I had
a look into the test suite source and I think, that the test suite
is not able to copy the libraries to the target.
I attached a small patch, which could be a solution for
Jonas Maebe wrote:
On 27 May 2011, at 14:56, Bernd Mueller wrote:
If you think, this patch could be the right way to copy the libraries,
I would submit a second patch which expands all required %needlibrary
directives.
Isn't it easier to simply copy all compiled libraries to the target
Hello,
I am running the test suite with remote execution (from a Windows host)
on an ARM-Linux target. Some test programs fail at runtime, because they
depend on libraries, which were not automatically copied to the target.
For example:
Failed to run test/tlib1b.pp 2011/01/21 18:06:08
On 23 May 2011, at 11:49, Bernd Mueller wrote:
I am running the test suite with remote execution (from a Windows
host) on an ARM-Linux target. Some test programs fail at runtime,
because they depend on libraries, which were not automatically
copied to the target. For example:
Failed
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
The conference departure got shifted by one day, so I can answer you
today, but then not until Friday :P
Am 21.09.2010 00:30, schrieb Willibald Krenn:
fpc -Fuunits\x86_64-win64 rtl.ppk
unknown: 12
unknown: 12
rtl.ppk(7) Error: Multiple defined symbol _DLLMainCRTStartup
rtl.ppk(7) Error:
Am 19.09.2010 22:34, schrieb Willibald Krenn:
Hi Sven!
Am 19.09.2010 13:49, schrieb Sven Barth:
and the following for Windows:
pp -Twin32 -Fuunits/i386-win32 rtl.ppk
I tried this with my 64 bit-head version of fpc, but it failed to
produce any output except an .a and an .o file.
fpc
- execute the following command:
fpc -Us -Sg -Fiinc -Fix86_64 -Fiwin -Fiwin64 -FUunits\x86_64-win64
win64\system.pp
Had to change it to
fpc -Us -Sg -Firtl\inc -Firtl\x86_64 -Firtl\win -Firtl\win64
-FUunits\x86_64-win64 rtl\win64\system.pp
but this worked, as expected.
Now you should have
Hello together!
After the previous thread about packages I experimented a bit more with
them.
I tried to compile the following package:
source begin
package rtl;
contains
system;
end.
source end
The system unit was precompiled by me for Win32 and for Linux.
The
Hi Sven!
Am 19.09.2010 13:49, schrieb Sven Barth:
and the following for Windows:
pp -Twin32 -Fuunits/i386-win32 rtl.ppk
I tried this with my 64 bit-head version of fpc, but it failed to
produce any output except an .a and an .o file.
fpc -Twin64 -Fuunits\x86_64-win64 rtl.ppk
unknown: 12
hi,
I'm working on Linux support for code page enabled string types (branch
cpstrnew).
In general, is their a special way that the test projects in
'fpc/tests/test/*' should be run?
Sorry, I'm used to FPCUnit or DUnit2 test cases which gives a clear
indication if a test passed or failed.
On 03 Dec 2009, at 14:31, Graeme Geldenhuys wrote:
In general, is their a special way that the test projects in
'fpc/tests/test/*' should be run?
From fpc/tests/readme.txt:
***
Writing a test
--
A test should have a name on the form t*.pp, to be recognized as a test.
It should
Jonas Maebe wrote:
A test should have a name on the form t*.pp, to be recognized as a test.
It should return 0 on success, any other value indicates failure.
Ah thanks! And that would explain the lines with Halt(1) at the end of
those test projects :-)
No idea how I missed that. :-(
Hi,
Just subscribed, testing system.
Regards,
Nino
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
fpc...@silvermono.co.za wrote:
Hi,
Just subscribed, testing system.
Welcome
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Just a test.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hi
I've check tests for Test suite results for test file
test/units/system/tres2.pp
but I nottice that different fpcres is use to compile
in trunk is ver 2.0{ Note: This program is not the old fpcres by
Simon Kissel }
but is use old :
Log of 35027:
Error: Unknown command-line
it worked!
2008/6/17 Vincent Snijders [EMAIL PROTECTED]:
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
Regards,
- Graeme -
___
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Sorry again, mailman makes trouble.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
test, please ignore
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
test
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
test
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hiya,
This is a test from one of thhe system-administrator of
deadlock.et.tudelft.nl to test if the new mailconfiguration is working.
You can ignore this message.
Greetings,
Erik Noort
member of the systemadministrator team of deadlock.et.tudelft.nl
75 matches
Mail list logo
