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 th
> 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 mod
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 PP
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 build
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 - fpc-devel@lists.freepasc
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 c
Thanks Jonas.
On 03/05/2019 17:28, Jonas Maebe wrote:
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
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 binary
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 in
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.
(e
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 recomp
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
direct
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 al
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 packages/flc-registry/src/re
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
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
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 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 struc
t; - Original Message -
> From: "Marco van de Voort"
> To:
> 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
BP 7.0 (real)
BP7.0 (protected)
VP2.1b279
all: "not assigned"
- Original Message -
From: "Marco van de Voort"
To:
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.
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 = obj
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 - fpc-devel@lists.freepascal.org
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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.
In
> -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: prob
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 =
...
___
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
> -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
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 re
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 red
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?
Y
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 ge
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}
Ex
> -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 w
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 down
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 of
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 n
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 libraries
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 com
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 directive
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 when
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 the
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 examp
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 to
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 (16
___
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: U
- 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 a
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 -Twin6
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
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 follo
Please ignore.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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. :-(
Regard
On 03 Dec 2009, at 14:31, Graeme Geldenhuys wrote:
In general, is their a special way that the test projects in
'/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 retur
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
'/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.
Regards,
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
Hi,
Just subscribed, testing system.
Regards,
Nino
___
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 paramet
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
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
test, please ignore
___
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
Mailinglists are being migrated.
Daniël Mantione___
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
Please ignore
___
fpc-devel maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
send with pascalive via web
__
Acabe com aquelas janelinhas que pulam na sua tela.
AntiPop-up UOL - É grátis!
http://antipopup.uol.com.br/
___
fpc-devel maillist - [EMAIL PROT
Hiya!
This is a test from one of the systemadminstrator of
deadlock.et.tudelft.nl, which is hosting lists.freepascal.org, to test the
new mailconfiguration. As of now the fpc lists are only accessible through
lists.freepascal.org and no longer through deadlock.et.tudelft.nl.
Greetings,
Erik Noo
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
Hello,
Testing new configuration files.
Daniël
___
fpc-devel maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
82 matches
Mail list logo