Re: [fpc-pascal] FPC for Win64

[Florian Klaempfl]

Am 04.07.2020 um 20:02 schrieb Graeme Geldenhuys:

On 02/07/2020 9:30 pm, Evert van Dijken via fpc-pascal wrote:

I see a WIN32 compiler and a WIN64 cross
compiler. How it works is a mystery for me.


I never understood the choice FPC made to not create a native 64-bit
compiler, but rather stay with a cross-compiler. *shrug*


The main reason is: a win64 hosted compiler cannot cross compile 
properly to any other x86-64 target due to missing extended support.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Extended type under Win64

[Florian Klaempfl]

Am 08.03.2020 um 16:03 schrieb Ched via fpc-pascal:


Well, well... Does it means that if one have scientific computations 
needing the extended type available on an Intel based processor with 
time constraints forbiding software emulation, one have to rest under a 
32 bits version of windows ?


All modern "number crunching" approaches (e.g. GPUs or AVX-512 do not 
support the extended type, so I doubt there is really a relevant number 
of use cases for the extended type.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpc trunk = Operator is not overloaded: "Class Of TBlobField" and "Boolean"

[Florian Klaempfl]

Am 08.03.2020 um 15:42 schrieb fredvs via fpc-pascal:

Can point out a link to the whole source code containing this line?


More than welcome!

https://github.com/mse-org/mseide-msegui/blob/master/lib/common/db/msesqlquery.pas

At line 1719:

  if fld1 is tblobfield and (self.fblobintf <> nil) then begin


You wrote before the code is:
if fld1 is tblobfield then
?

https://wiki.freepascal.org/User_Changes_Trunk#Precedence_of_the_IS_operator_changed
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpc trunk = Operator is not overloaded: "Class Of TBlobField" and "Boolean"

[Florian Klaempfl]

Am 08.03.2020 um 14:29 schrieb fredvs via fpc-pascal:

Hello.

I did try last fpc trunk and get that error message when compiling a program
(mseide):

---> Error: Operator is not overloaded: "Class Of TBlobField" and "Boolean"

This comes from that line:

---> if fld1 is tblobfield then // here error.



Can point out a link to the whole source code containing this line?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ppc64le ABI problem

[Florian Klaempfl]

Am 26.08.2019 um 20:52 schrieb Jonas Maebe:
> On 26/08/2019 14:22, Florian Klämpfl wrote:
>> Am 26. August 2019 14:08:39 schrieb Sven Barth via fpc-pascal 
>> :
>>
>>> Florian Klämpfl  schrieb am Mo., 26. Aug. 2019,
>>> 14:01:
>>>
 Try to change the 48 in fpc/compiler/powerpc64/cpupara.pas line to 32 as a
 temporary test.
>>>
>>> Line 302 in case anyone is wondering (thankfully that's the only "48" in
>>> that fike (plus its preceeding comment) ^^')
>>
>> Indeed :-) If it works, it must be made dependent on the target ABI.
> 
> It's indeed like that, see section 2.2.2 of
> https://openpowerfoundation.org/wp-content/uploads/2016/03/ABI64BitOpenPOWERv1.1_16July2015_pub4.pdf

Yes, I checked the docs as well :) I don't know though why it is only 32
for elf_abi_v2 ...

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementation of variant records

[Florian Klaempfl]

Am 05.07.2019 um 13:53 schrieb Ralf Quint:
> On 7/5/2019 3:27 AM, Marco van de Voort wrote:
>>
>> Op 2019-07-05 om 11:49 schreef Bernd Oppolzer:
>>>
>>> IMO, the variants in a variant record should always overlay correctly
>>> (like unions in C),
>>> so the variant part should start at offset 32 in this case, and this
>>> is where all three
>>> variants should start.
>>
>> This is not a guarantee case in the Pascal language, afaik many old
>> compilers don't even try, but make fields sequential.
>>
>> As soon as you have expections of overlaying, you are dialect and
>> architecture specific. 
> 
> Shouldn't a PACKED Record guarantee that values are aligned at the byte
> level?

It does in TP, but the ISO says only that it shall be economised.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Florian Klaempfl]

Am 17.07.2018 um 12:07 schrieb Michael Van Canneyt:
If of course you write routines of several hundreds of lines (or 
thousands),

then you probably would need to have such a feature.

But I would fire any programmer that writes such code anyway, since it 
indicates he cannot think structured.




You should fire the whole compiler development team then ;)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Loss of precision when using math.Max()

[Florian Klaempfl]

Am 09.07.2018 um 19:55 schrieb g...@wolfgang-ehrhardt.de:


Zitat von Martok :
To make sure this works, one has to manually make the const expression 
be of the

type required:
const
  e: Extended = Extended(1.0) / 3.0;

I seem to remember that this was once documented somewhere for Delphi. 
Can't
seem to find it though, so maybe it was a 3rd-party book? There is no 
hint of it

in the FPC documentation, anyway.


As already noted, it is not necessary in Delphi

D:\Work\TMP>D:\DMX\M18\DCC32 -b exttest.dpr
Embarcadero Delphi for Win32 compiler version 25.0
Copyright (c) 1983,2013 Embarcadero Technologies, Inc.
exttest.dpr(14)
15 lines, 0.00 seconds, 20816 bytes code, 13864 bytes data.
D:\Work\TMP>exttest
   0.333433  0.333433
     0.    0.
     0.    0.

And with Delphi Tokio 10.2.3 Starter

G:\TMP>bds -b exttest.dpr
G:\TMP>exttest.exe
   0.333433  0.333433
     0.    0.
     0.    0.


I am happy to implement this in delphi mode, but it requires some 
documentation references how delphi evaluates such expressions (which 
precision is used when and why) and how they are handled in expressions.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Error when trying to make tests for target AVR

[Florian Klaempfl]

Am 07.01.2018 um 06:12 schrieb Christo:
> On Sun, 2018-01-07 at 05:59 +0200, Christo wrote:
>> __missing_command_FPCMAKE -p -Tavr-embedded Makefile.fpc
> 
> Adding fpc_baseinfo to the make command revealed that FPCMAKE was not defined 
> (I guess it should
> have been obvious from the error message in the first place). I added the 
> path to fpcmake
> (FPCMAKE=path_to_fpcmake) to the make command line and the tests are now 
> running.

Do you have an fpcmake somewhere in your path?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Florian Klaempfl]

Am 24.08.2017 um 23:45 schrieb Ched:
> And under "modern" Windows, the extended type, which is fully supported
> by the FPU, is *degraded* to double. So, I can't do high precision
> computation with fpc even if the native hardware permits such
> computations. 

FP permits it too, just recompile it with
FPC_SUPPORT_X87_TYPES_ON_WIN64. But be aware: MS might disable extended
support at any time on 64 bit windows as the types are marked as deprecated.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[Florian Klaempfl]

Am 10.07.2017 um 15:00 schrieb Sven Barth via fpc-pascal:
> Am 10.07.2017 13:19 schrieb "Michael Van Canneyt"
> mailto:mich...@freepascal.org>>:
>>
>>
>>
>> On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote:
>>
>>> On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt
>>> mailto:mich...@freepascal.org>> wrote:

 The code is definitely not the same. In each case, it was measured.
> There is
 a 10% performance loss.
>>>
>>>
>>> I'd love a source on this one. I guess you mean in Free Pascal?
>>
>>
>> Obviously.
>>
>> The classes unit can be recompiled to use the fgl (well, that used to
> be so)
>> as a basis. When using the resulting list and stringlist, there was a 10%
>> performance loss. The main reason - If I recall correctly - was that
> the fgl needs to resort to move() operations instead of direct assignments.
> 
> The fgl classes don't use Move(), but they have a virtual method that
> does the assignment between the specialized parameters that's inherited
> from the non-generic parent list type.

... which is done to avoid bloat. fgl specialized only a wrapper around
an internal list. So the slightly slower code in some cases reduced
executable size.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Underscores in numerical literals - grouping

[Florian Klaempfl]

Am 22.11.2016 um 15:29 schrieb Mattias Gaertner:
> You forgot to consider how scanners work, i.e. how they check and
> skip spaces.
> 
> Here are some numbers:
> 
> Compiling Lazarus sources 'make clean all' 1249309 lines 3 times
> 0m51.682s
> 0m51.415s
> 0m51.698s
> 
> Lazarus uses indentation of 2, so replacing each double space with one
> tab saves 3.7mb. Compiling 3 times:
> 0m52.003s
> 0m51.294s
> 0m51.452s
> 
> This is a desktop system, so there is always a bit of noise. As you can
> see, the time difference is not measurable.
> 
> To estimate the potential speed up:
> Replacing all multi spaces with one space saves 6.1mb. Compiling 3
> times:
> 0m51.064s
> 0m50.733s
> 0m51.120s
> 
> It seems scanning the spaces costs about 1%.

In case somebody is interested, the main loop for reading spaces is in
compiler/scanner.pas, procedure tscannerfile.skipspace;

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Smart Pointers

[Florian Klaempfl]

Am 10.05.2016 um 22:57 schrieb Maciej Izak:
> 2016-05-10 21:18 GMT+02:00 Florian Klämpfl  >:
> 
> Aren't there several bug reports open which must be fixed first?
> 
> 
> There is one critical bug related to class var and generics, but as Sven
> said it need wait to "packages branch"...
> 
> With other bugs we can +/- live. ;)
> 
> btw I've started to fix few of them...

Good :) If existing features are reasonable bug free and completed, we
can discuss new featueres.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] History of the Cardinal data type?

[Florian Klaempfl]

Am 30.03.2016 um 03:06 schrieb Graeme Geldenhuys:
> Thanks Marco, interesting history lesson. ;-)
> 
> On 2016-03-29 22:16, Marco van de Voort wrote:
>> Moreover since shorter types are not always faster, I think it is better to
>> forget all this, and in new code use INTEGER for the variable types, where
>> range doesn't matter (much) and (u)int for the rest.
> 
> I already tend to use Integer for most code, but the code I'm currently
> working on has an extensive amount of record structures used to read a
> complex binary data file. The documentation for the data file is
> primarily in C 

In this case, you should probably use the types from the ctypes unit.

> and uses types like SHORT, USHORT, LONG etc. These
> translated easily to the SmallInt, Word, LongWord etc types, 



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Florian Klaempfl]

Am 14.02.2016 um 12:47 schrieb Giuliano Colla:
> Il 14/02/2016 11:12, Graeme Geldenhuys ha scritto:
>> But then, I think such non-realword tests don't prove much.
> 
> Except that the implementation of inc(something) should be given a look,
> as it's always been sold as faster than something:=something+1
> 

No really. It is not a matter of +1 vs. inc but how it is compiled: as
add or lea. And the decision add vs. lea is not straight forward. It
depends on the surrounding code and the exact core. So without a
detailed analysis of the generated assembler with regard to the used
core any tests about it are useless. In theory, a compiler could decide
very good if add or lea is better. But this decision applies only to a
certain core and not in general. So for a all-purpose compiler this
makes little sense. If your application really depends on this, rewrite
the hotspots in C and use the icc to compile it. It knows about these
detais.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Florian Klaempfl]

Am 14.02.2016 um 11:12 schrieb Graeme Geldenhuys:
> 
> The "-O4 -Ooloopunroll" options produced the fastest executable out of
> the above tests.
> 
> But then, I think such non-realword tests don't prove much.

-O4 is always useful, if your programs work with it (as it contains
-Oofastmath) and if you can life with the fact that -gl is completely bogus.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Florian Klaempfl]

Am 14.02.2016 um 10:45 schrieb Mattias Gaertner:
> On Sun, 14 Feb 2016 10:35:22 +0100
> Florian Klaempfl  wrote:
> 
>> [...]
>> Do you think people will bother? Nobody mentioned to the original poster
>> so far:
>> - that the used FPC is outdated
>> - that only -O2 is used instead of -O3 (or -O4 with 3.0.0)
>> - that even FPC 2.6.4 has a -Ooloopunroll option which is never enabled
>> by default and which is worth a try
>>
>> I do not know if the points above really effect the example, but it
>> tells me enough not to bother either :)
> 
> Maybe documentation helps here.

You mean something like the page Size Matters? See the post of Martin
Schreiber how much such pages help.

> 
> Is there already a page "pimp my fpc"?

In this case even fpc -h would have helped :)

But actually, before bothering randomly with command line options, I
would just rewrite the inner loop. Something like
  for n7 := 0 to 9 do
if n1 + n2 + n3 + n4 - n5 - n6 - n7 in [0..9] then
  Inc(TicketsCount);
should be much better.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Florian Klaempfl]

Am 14.02.2016 um 10:23 schrieb Mattias Gaertner:
> On Sun, 14 Feb 2016 10:11:54 +0100
> Florian Klaempfl  wrote:
> 
>> [...]
>> For the record: with a few changes in the compiler I could reduce the
>> execution time of the example significantly . But I won't commit it
>> probably (maybe parts of it): extensive loop unrolling and loop
>> invariant search has normally little advantages in real world programs
>> and increases only compilation times.
> 
> If it is easy to implement could it be optional?

Do you think people will bother? Nobody mentioned to the original poster
so far:
- that the used FPC is outdated
- that only -O2 is used instead of -O3 (or -O4 with 3.0.0)
- that even FPC 2.6.4 has a -Ooloopunroll option which is never enabled
by default and which is worth a try

I do not know if the points above really effect the example, but it
tells me enough not to bother either :)


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Florian Klaempfl]

Am 13.02.2016 um 11:44 schrieb Serguei TARASSOV:
> Hello,
> 
> Here is my little brute-force test for FPC, C and C# compilers.
> http://arbinada.com/main/en/node/1532
> 
> The results are not so good with FPC but I cannot use Delphi to compare
> on Linux.
> 
> Could anyone make the series on Windows with FPC, Delphi and MS .Net?
> The test of FPC 3.0 and any other comments are welcome.

For the record: with a few changes in the compiler I could reduce the
execution time of the example significantly . But I won't commit it
probably (maybe parts of it): extensive loop unrolling and loop
invariant search has normally little advantages in real world programs
and increases only compilation times.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] AVR Busy Wait implementation

[Florian Klaempfl]

Am 18.01.2016 um 23:04 schrieb Simon Ameis:
> Thanks for the hint! I've had declared delay_loop_1 and delay_loop_2
> just inside the implementation section.
> 
> Maybe these points should be added to documentation for inlining?

I am against documenting this:
- inline is only a hint to the compiler
- the exact rules are very subtile and might differ between platforms/abi
- the behaviour might change between different compiler versions
So it is hard to document this precisely.

IMO the only proper solution is to implement delaying as compiler
intrinsics as it is done by gcc as well.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?

[Florian Klaempfl]

Am 18.12.2015 um 12:16 schrieb R. Diez:
> 
> I see. Based on that information, and on the issue of function calls
> crossing units, I guess you could rephrase that in much less-friendly
> way. I'm playing evil advocate now: "FreePascal is so simple it can only
> optimise properly the kind of hand-written tight loops that you normally
> find in artificial benchmarks."  }8-)
> 

Actually, it is the other way round: FPC is not interested in
optimziations taking a lot of time and mainly having a purpose in
artifical benchmarks. E.g. spending a lot of time in optimizing globals
variable access is for real world programs normally not really usefull
as the number of global variables in good programs is really low.

Of course, if you are interested in highly optimized code squeezing out
every processor cycle, you do not care about compilation times and you
are only interested in embedded programming, FPC is not the right tool
for you and this will not change.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 3.0.0-rc1 release

[Florian Klaempfl]

Am 27.08.2015 um 02:08 schrieb Ched:
> Hello,
> 
> I strongly discourage the use of {$optimization deadstore} which induced
> strong numerical errors on our solar system calculations (i386 linux).
> The other new ones
>{$optimization deadvalues}
>{$optimization orderfields}
>{$optimization fastmath}
>{$optimization constprop}
> seem to be ok.
> 
> Unfortunately, deadstore will be difficult to debug with the actual code
> (>10 lines).
>

Since it shouldn't affect too much code, it would be worth a try to
compare the generated assembler with and without {$optimization
deadstore}. With a tool like WinMerge this can be normally done pretty easy.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 3.0.0-rc1 release

[Florian Klaempfl]

Am 29.08.2015 um 14:54 schrieb Jonas Maebe:
> On 29/08/15 14:49, Florian Klämpfl wrote:
>> Am 29. August 2015 1:58:06 nachm. schrieb Jonas Maebe
>> :
>>
>>> On 29/08/15 13:40, Florian Klämpfl wrote:
 Am 29. August 2015 12:00:26 nachm. schrieb Jonas Maebe
 :
>
> In any case: you should have to pass OPT="-dFPC_ARMHF" to get an armhf
> compiler (even if you already start with an armhf compiler).

 This should not be necessary?
>>>
>>> I also used to think so, but I can't find where FPC_ARMHF
>>
>> compiler/fpcdefs.inc:155
> 
> Damn grep ARMHF *.pas :)

Nevertheless, it does not explain why the OPT=-dFPC_ARMHF is needed.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Issue with Linking

[Florian Klaempfl]

Am 21.08.2015 um 10:08 schrieb Jonas Maebe:
> Chris Moody wrote:
>> Seems it compiles but still complains about linking.
>>
>> Free Pascal Compiler version 3.0.0rc1 [2015/08/20] for arm
>> Copyright (c) 1993-2015 by Florian Klaempfl and others
>> Target OS: Linux for ARMHF
>> 
>> Assembling dentist
>> Linking Dentist
>> Dentist.pas(106) Warning: "crtbegin.o" not found, this will probably
>> cause a linking failure
>> Dentist.pas(106) Warning: "crtend.o" not found, this will probably cause
>> a linking failure
> 
> These are gcc files. When performing a regular installation of FPC, the
> path to these files is added to fpc.cfg using the -Fl parameter.

Actually, FPC has also some default locations hard coded in the compiler.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Delphi mode for new features?

[Florian Klaempfl]

Am 02.07.2015 um 12:37 schrieb Serguei TARASSOV:
> 
> Be honest, I have doubts about "Pascal spirit" of this genre.

FPC tries to support all flavours of pascal, even ISO. If you are
interested only in one flavour, just add the appropriate mode switch to
your config and be done. If FPC limited itself only to one flavour, it
wouldn't probably exist anymore/being dead.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Where is the 'write' function defined and how is it different from 'writeln'?

[Florian Klaempfl]

Am 21.03.2015 um 11:13 schrieb vfclists .:
> I need to get the output of a program which uses a lot of Write and
> Writeln commands into the GUI in realtime, by that I not having to
> output it to a text file and reading it afterwards, but by capturing the
> output of each Write command into a variable and displaying it in the
> GUI immediately.
> 
> If each Write or Writeln could trigger an event, I could use the event
> to capture the output. My other option is to replace the calls to write
> with my own function, but Write has different number of call parameters
> and it may require as many variants of the function as are used in the
> program, assuming that the call syntax is regular, not something like
> this one - write(JSValToDouble(cx,pom^)):1:scale).

Check the implementation of the FPC CRT unit how a unit can hook into
the write(ln) mechanisms:

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/rtl-console/src/unix/crt.pp?revision=26372&view=markup

Have a look at AssignCrt and CrtOpen, how it is done.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Google Code closing down

[Florian Klaempfl]

Am 14.03.2015 um 12:45 schrieb Graeme Geldenhuys:
> On 2015-03-14 11:38, Mark Morgan Lloyd wrote:
>> [Sigh] I feel like I'm being pushed onto git rather than Subversion.
> 
> Then don't resist it. As 99% of developers would tell you,

[...]

> is simply
> the better product. [Graeme runs and hides :-P]

Please make the same poll about C++ and Pascal ;)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] MIPS32 support

[Florian Klaempfl]

Am 06.01.2015 23:46, schrieb Graeme Geldenhuys:
> Hi,
> 
> Anybody know the status of MIPS32 support with Free Pascal?
> 
> To be used on something like this board:
> 
>   http://shop.imgtec.com/uk/product/mips-creator-ci20/
> 

Regression tests show that mipsel is working reasonably with linux:
http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?os=1&cpu=12&version=0&date=&submitter=&machine=&comment=&cond=&Category=3

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] High() and Low() for empty dynamic arrays

[Florian Klaempfl]

Am 08.02.2014 17:35, schrieb Jürgen Hestermann:


 > Unfortunatly you posted not a complete example which shows the
behaviour but only uncompilable code snippts.
 > Post always complete examples when discussing strange behaviour.

You mean I should post thousands of code lines?


Of course not, just a small example as I did.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] High() and Low() for empty dynamic arrays

[Florian Klaempfl]

Am 08.02.2014 16:56, schrieb Jürgen Hestermann:


because otherwise I would get an error in case the length is 0
because Low() and High() both give back 0.
The result of both functions is the same as if the array had exact one
element.


Here:

var MyArray : array of longint;

begin
  writeln(low(MyArray));
  writeln(high(MyArray));
end.

prints

0
-1

Unfortunatly you posted not a complete example which shows the behaviour 
but only uncompilable code snippts. Post always complete examples when 
discussing strange behaviour.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Test, please ignore

[Florian Klaempfl]

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Free Pascal 2.6.4-rc1 released!

[Florian Klaempfl]

Am 26.12.2013 18:03, schrieb Pierre Free Pascal:

   Sorry,
I did not realize that the upload did not complete.
The correct size is above 40 MB.

I uploaded it again on ftp.freepascal.org

$ md5sum fpc-2.6.4rc1.i386-win32.exe
132d4777b5d98cca13418ae0460a0b32 *fpc-2.6.4rc1.i386-win32.exe

$ ls -al fpc-2.6.4rc1.i386-win32.exe
-rwxr-xr-x 1 Pierre None 42136156 16 nov.  16:14 fpc-2.6.4rc1.i386-win32.exe

   Please test again.

Sorry for the mistake.


Could you please build win64 and wince cross compilers with the same 
version of inno setup as wel?


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Wince_arm: the naive approach

[Florian Klaempfl]

What source tree do you use? Trunk? Works here


Yes, trunk.


I thought you talk about fpc, anyways, the attached patch might help for 
lazarus.




[1]
Free Pascal Compiler version 2.7.1 [2013/08/04] for arm
..
Target OS: WinCE for ARM
..
Assembling themes
C:\development\lazarus\lcl\include\graphic.inc(155,66) Error:
Incompatible type for arg no. 3: Got "PChar", expected "PWideChar"
C:\development\lazarus\lcl\include\graphic.inc(171,62) Error:
Incompatible type for arg no. 3: Got "PChar", expected "PWideChar"
C:\development\lazarus\lcl\include\custombitmap.inc(510,13) Error:
Incompatible types: got "PWideChar" expected "PChar"
..
C:\development\lazarus\lcl\include\icon.inc(1336,13) Error: Incompatible
types: got "PWideChar" expected "PChar"
C:\development\lazarus\lcl\include\cursorimage.inc(55,13) Error:
Incompatible types: got "PWideChar" expected "PChar"
C:\development\lazarus\lcl\graphics.pp(2812) Fatal: There were 5 errors
compiling module, stopping


4b567ed86fa32bf389dcec63ffecb5009acaef4c
 lcl/controls.pp | 4 ++--
 lcl/lcltype.pp  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lcl/controls.pp b/lcl/controls.pp
index 570b2e5..0de2057 100644
--- a/lcl/controls.pp
+++ b/lcl/controls.pp
@@ -2829,8 +2829,8 @@ begin
   Result:='';
   for cst:=low(TControlStyleType) to high(TControlStyleType) do
 if cst in cs then begin
-  if Result<>'' then Result+=',';
-  Result+=dbgs(cst);
+  if Result<>'' then Result:=Result+',';
+  Result:=Result+dbgs(cst);
 end;
   Result:='['+Result+']';
 end;
diff --git a/lcl/lcltype.pp b/lcl/lcltype.pp
index 8fcf8de..03e55c5 100644
--- a/lcl/lcltype.pp
+++ b/lcl/lcltype.pp
@@ -2166,7 +2166,7 @@ const
 // Predefined Resource Types
 //==
 type
-  {$ifdef UNICODE}
+  {$if defined(FPC_OS_UNICODE) or (defined(VER2_6) and defined(UNICODE))}
   TResourceType = PWideChar;
   {$else}
   TResourceType = PChar;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Lazarus produces Fatal: Internal error 200602035

[Florian Klaempfl]

Am 30.07.2013 09:34, schrieb Bart:

On 7/30/13, Sven Barth  wrote:

Please ensure that you attach a complete example that should be
compileable.


There is already a bugreport about that Internal Error:
http://bugs.freepascal.org/view.php?id=18967

It is resolved as "Probably fixed in the mean time".
It should be re-opened (by someone who can do that), rather than
creating a new bugreport.


It makes no sense to reopen it if no complete example how to reproduce 
it is provided.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: JVM backend and language restrictions

[Florian Klaempfl]

Am 11.07.2013 15:07, schrieb Graeme Geldenhuys:
> On 2013-07-11 11:34, Reinier Olislagers wrote:
>>
>> Has that person read this:
>> http://wiki.lazarus.freepascal.org/FPC_JVM/Language
> 
> 
> Wow, things are really hard to find in the wiki.
> 
>  * No link to that page mentioned, from it's parent page
> http://wiki.lazarus.freepascal.org/FPC_JVM
>  * No mention of that link in the JVM category
> http://wiki.lazarus.freepascal.org/Category:JVM
> etc...
> 
> No wonder we hear of so many people frustrated with not finding
> information about FPC (or Lazarus). 

Is it so hard to google "fpc jvm language limitations" ?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] http://www.freepascal.org/future.var

[Florian Klaempfl]

Am 29.05.2013 06:25, schrieb Reinier Olislagers:

On 28-5-2013 19:16, Sven Barth wrote:

On 28.05.2013 17:41, Reinier Olislagers wrote:

Going by the discussions on this mailing list I'm having trouble
believing LLVM backend support would be in the plans. Should this line
perhaps be removed.


Where in the discussions did we mention that we do not want a LLVM
backend?

Florian saying he didn't want an LLVM backend.


Actually, I meant/said I'am not interested in working on one. For me the 
backend work is the interesting work, everything else is just boring duty :)


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Firebird embedded supported on Windows 64 by SEH patch

[Florian Klaempfl]

Am 09.03.2013 08:49, schrieb Reinier Olislagers:

Sergei Gorelkin enabled Win64 SEH support in trunk r23732:

* Make Win64 SEH support enabled by default. If necessary to disable,
compiler should be cycled with OPT=-dDISABLE_WIN64_SEH. Mantis #24012.



Is it usefull to make DISABLE_WIN64_SEH a command line switch?


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

[Florian Klaempfl]

Am 05.03.2013 22:36, schrieb Dimitri Smits:



- Oorspronkelijk e-mail -

Van: "Florian Klämpfl"  Aan: "FPC-Pascal
users discussions"  Verzonden:
Maandag 4 maart 2013 21:00:10




And how does this change the fact that it is an external cg not
written in pascal?


the front-end would still be written in pascal.


But the back end not, right ;)?



as a matter of fact, when you use the binutils and ld etc, you aren't
exactly using a full pascal toolchain either, no?


Of course I do. My desktops run all windows and fpc for win32/win64 has 
no need of as or ld (guess why ;)). fpc contains an assembler and linker 
for win32/win64. Actually, fpc even supported win64 before binutils for 
it were available due to this.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Refr Bruhl

[Florian Klaempfl]

Am 22.02.2013 15:36, schrieb Refr Bruhl:

http://www...p2t




Please do not click the link in this mail, it is probably malware/spam.
I have set the moderation flag for Refr Bruhl. Sorry for any
inconvenience caused by this.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: RE : RE : [fpc-pascal] Variable alignment in arm-embedded

[Florian Klaempfl]

Am 11.06.2012 13:46, schrieb alrieckert:

Hi Jeppe,

I've been using the actual ROM based interrupt table for the past
month now in freepascal ad it seems to work great. No need to declare
a block of RAM and pointing the interrupt table to it.

You can code any procedure and just give it the interrupt keyword
with an address index.

For example:



There are 3 patches you need to apply to your compiler. I'll try to
submit the patches to the Freepascal mailing list and hopefully
someone will accept them, but in the mean time you can find them
here.


Better submit a bug tracker entry. This way it cannot get lost.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: RE : RE : [fpc-pascal] Variable alignment in arm-embedded

[Florian Klaempfl]

Am 12.06.2012 09:50, schrieb Koenraad Lelong:

On 08-06-12 14:37, Jeppe Græsdal Johansen wrote:

Den 08-06-2012 14:28, Ludo Brands skrev:

Thanks Ludo,

I'll take that as a starting point. I hope I will not need the "lost"
256 bytes in the future.

I could be wrong but AFAIK if the compiler would do the alignment, the
loss
can also be up to 255 bytes. Here you lose 256 bytes in all cases.

Yes, but this would allow the linker to place other stuff there which
fits in less than 255 bytes.

Wasting 255 bytes is a lot on systems that only has a few kilobytes of
RAM. I wonder if the restriction of 32 bytes on the align directive
could just be removed, or will we need some sort of linker script
changes?


Hi,

I'm still struggling to get interrupts (or even inputs) work but I
wanted to comment on the size of the table. Reading the manuals I found
it's actually on a 512 byte boundery. The VTOR (Vector Table Offset
Register) masks off the last 9 bits (8..0).
If I need that space I will modify the start of RAM location and use the
first bytes of RAM for the vector-table.
It would be nice to have "external" linker scripts. That way you could
more easily add processors,


I think extending t_embedded.pas is the more clean solution to add new 
controllers, especially because it makes it easier for other people to 
use the added controllers.



or use custom bootloaders.

Regards,

Koenraad Lelong.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpimage reader for jpeg2000

[Florian Klaempfl]

Am 11.06.2012 12:03, schrieb Mattias Gaertner:

Hi,

Has someone already implemented a fpimage reader for jpeg2000?


Probably not due to the patent situation?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: RE : RE : [fpc-pascal] Variable alignment in arm-embedded

[Florian Klaempfl]

Am 08.06.2012 14:37, schrieb Jeppe Græsdal Johansen:

Den 08-06-2012 14:28, Ludo Brands skrev:

Thanks Ludo,

I'll take that as a starting point. I hope I will not need the "lost"
256 bytes in the future.

I could be wrong but AFAIK if the compiler would do the alignment, the
loss
can also be up to 255 bytes. Here you lose 256 bytes in all cases.

Yes, but this would allow the linker to place other stuff there which
fits in less than 255 bytes.

Wasting 255 bytes is a lot on systems that only has a few kilobytes of
RAM. I wonder if the restriction of 32 bytes on the align directive
could just be removed, or will we need some sort of linker script changes?


It could be removed but I'am pretty sure that the linker does not use 
the alignment space for other stuff.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiling from and to memory

[Florian Klaempfl]

Am 26.04.2012 14:57, schrieb OBones:

Jonas Maebe wrote:


OBones wrote on Mon, 23 Apr 2012:


And because I have to split my generated files so that FPC does not
hit the 2GB memory limit (which it does for a 15M source file)


What is the structure of that source code? (a few giant routines,
large constant arrays, ... ?)

Thousands of small routines. Splitting them across multiple units allows
to compile, with the "write to disk" issue.


You can use a compiler compiled with EXTDEBUG to get some statistics 
where the memory goes.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiling from and to memory

[Florian Klaempfl]

Am 19.04.2012 14:11, schrieb OBones:

Hello all,

I'm currently creating a build chain where FPC is the last step, the one
producing a DLL for Windows, x86 and x64.
In front of it in the chain, I have designed a generator that creates a
program and a set of units from its own representation.
Right now, the program and units are written to disk and then FPC is
called on those files.
This works fine but is somewhat slow because of disk writing and reading.
I was thus wondering if there was a way to send the program and unit
contents directly to FPC without writing to disk, and then get FPC to
output the final DLL to a memory location as well. The last part is
optional, being able to send the program and units without disk access
would be a nice thing.
I looked around in the documentation for "standard input", "pipe", but
apart from ways to access them from within a program, I was not able to
find any information.
Is this possible? If yes, how should I proceed?


Do you have any proof that writing/reading to the files to disk is an 
issue? On modern harddisks and OSes the plain I/O speed is normally not 
the issue when compiling.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiling from and to memory

[Florian Klaempfl]

Am 19.04.2012 14:11, schrieb OBones:

Hello all,

I'm currently creating a build chain where FPC is the last step, the one
producing a DLL for Windows, x86 and x64.
In front of it in the chain, I have designed a generator that creates a
program and a set of units from its own representation.
Right now, the program and units are written to disk and then FPC is
called on those files.
This works fine but is somewhat slow because of disk writing and reading.
I was thus wondering if there was a way to send the program and unit
contents directly to FPC without writing to disk, and then get FPC to
output the final DLL to a memory location as well. The last part is
optional, being able to send the program and units without disk access
would be a nice thing.
I looked around in the documentation for "standard input", "pipe", but
apart from ways to access them from within a program, I was not able to
find any information.
Is this possible? If yes, how should I proceed?


Do you have any proof that writing/reading to the files to disk is an 
issue? On modern harddisks and OSes the plain I/O speed is normally not 
the issue when compiling.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Spam

[Florian Klaempfl]

Am 11.03.2012 12:29, schrieb Jonas Maebe:
> Hi,
> 
> Sorry about this spam message. This person simply subscribed to the
> list and then sent the message. I've now changed the list options so
> that new members are moderated by default. This may result in some
> new members' first real posts to be accidentally discarded along with
> the spam that's held for moderator approval, but I don't know of
> another way to defend against this sort of abuse.
> 
> 

If too much gets moderated, we could install spam assassin on scenergy
and moderate only messages above a certain treshhold.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?

[Florian Klaempfl]

Am 09.12.2011 09:02, schrieb Vincent Snijders:
> 2011/12/7 Graeme Geldenhuys :
>> Hi,
>>
>> I did a simple GetTickCount() timing around this loop. Delphi executes
>> the loop in 20 ticks. FPC 2.6.0-rc2 takes 10585 ticks The outer
>> loop runs 200400 iterations. The types for BitValue, ByteValue and
>> RandSeed is of type Byte.
>>
>> 01  for Index := 1 to Length(Source) do
>> 02  begin
>> 03OrdValue := Ord(Source[Index]);
>> 04for BitCount := 0 to 7 do
>> 05begin
>> 06  BitValue := Byte(OrdValue and (1 shl BitCount) = 1 shl BitCount);
>> 07  RandSeed := ByteValue;
>> 08  ByteValue := (((Random(255) + 1) div 2) * 2) + BitValue;
>> 09  Result[(Index - 1) * 8 + BitCount + 1] := AnsiChar(ByteValue);
>> 10end;
>> 11  end;
>>
> 
> I have one question about this code, why is RandSeed set inside the
> loop and not outside the loop or even at the program start?
> If you change the randseed, then the random number generator has to be
> initialized and that is more costly for a stateful RNG as the mersenne
> twister.

Oops, mails crossed. The assignment to randseed is indeed the problem.
Why is it done? Bad random generator of delphi :)?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?

[Florian Klaempfl]

Am 09.12.2011 08:59, schrieb Graeme Geldenhuys:
> On 9 December 2011 09:47, Florian Klaempfl wrote:
>>
>> According to measurements of me and other peoples, random is only 7-10
>> times slower (depending on the CPU).
> 
> What do you feed your computer, 

Nothing, but I don't mess with things I don't understand :) Changing
randseed (and makes absolutely no change except if your random generator
might be bad ;)) during random number generation is really a bad idea:

c:\>test
Length(psData) = 200401
ByteValue: 187
Length(Source) = 200401
First Loop
elapsed time: 6751

c:\>test
Length(psData) = 200401
ByteValue: 174
Length(Source) = 200401
First Loop
elapsed time: 60

> because mine differs vastly from yours.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?

[Florian Klaempfl]

Am 09.12.2011 07:27, schrieb Jürgen Hestermann:
> 
> 
> Reimar Grabowski schrieb:
>> The parameter should default to FALSE to not break existing code
>> relying on FPCs random function 
> And what about existing code coming from Delphi/Turbo Pascal? This was a
> strong argument in the past for doing even crap coding.

As said before, this came only up because for every difference somebody
popped up and cried. When random was implemented using MT, we didn't
learn this lesson.

> Just imagine that
> divisions suddenly need 500 times the time because the last digit was
> inaccurate or so.

According to measurements of me and other peoples, random is only 7-10
times slower (depending on the CPU).
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Why is Random(255) some 529x slower compared to Delphi7?

[Florian Klaempfl]

Am 08.12.2011 17:24, schrieb Jürgen Hestermann:
> 
> In other situations the Delphi compatibilty is pulled up even if the
> implementation is outrageous. But suddenly everybody wants to depart
> from Delphi. Strange.

And? The conclusion is what we concluded years ago: be as delphi
compatible as possible else people start to cry soon or later. The funny
thing is only that this time the people cry who didn't draw this
conclusion yet.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?

[Florian Klaempfl]

Am 08.12.2011 09:03, schrieb Graeme Geldenhuys:
> On 8 December 2011 09:50, Florian Klaempfl wrote:
>>
>> Actually those who depend on speed should have spoken up ten years ago
>> when the MT was implemented.
> 
> I for one did not even know about the existence of Free Pascal 10 year
> ago. I don't believe I am alone either.

Indeed, but people depending for years of FPC's random function and
dicussed it years ago might not followed up this mailing list anymore
but just use it so they cannot speak up today either.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?

[Florian Klaempfl]

Am 08.12.2011 08:48, schrieb Graeme Geldenhuys:
> 
> [like what was told to me numerous times before]  They (FPC users)
> should speak up now, 

Actually those who depend on speed should have spoken up ten years ago
when the MT was implemented.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?

[Florian Klaempfl]

Am 08.12.2011 08:25, schrieb Felipe Monteiro de Carvalho:
> On Thu, Dec 8, 2011 at 7:27 AM, Jürgen Hestermann
>  wrote:
>> Fully agree. Especially, because ex Delphi (and ex Turbo Pascal) users would
>> expect it like that. And most of them (coming from Delphi/TP) believe that
>> the randomness is not very reliable. They mainly don't even know (like me)
>> that the FPC random() is much more sophisticated.
> 
> Based on what they expect that?

In this border case they expect delphi compatibility because it effects
their code and not others.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Why is Random(255) some 529x slower compared to Delphi 7?

[Florian Klaempfl]

Am 07.12.2011 16:03, schrieb Graeme Geldenhuys:
> On 7 December 2011 14:54, Jonas Maebe  wrote:
>>
>> That's correct. We use the mersenne twister, Delphi probably a linear
>> congruential generator. The mersenne twister has a much larger period.
> 
> I was reading a bit more about this.  The Mersenne Twister (MT)
> generator has a massive period of 2^19937−1, compared to the XorShift
> generator, which in turn has a period of 2^128-1.
> 
> Most text I read mentions that MT is great for statistical purposes,
> and performs well in its class.
>
> So wouldn't it maybe make more sense to let the standard (read more
> common) Random() call use a higher performance random number
> generator, with a much lower period.

Well, once we thought we try to do things better than Delphi ;) Some
people, I think John Lee, asked for a better random in FPC years ago so
Jonas implemented a MT.

> Then add the MT generator as a
> call to the Maths unit - where more statistical functions are located?
>
> Most applications are not statistical apps, they just want a random
> number here or there, so such high period low performance generator is
> normally not required. Having it in the Maths unit still makes in
> available when needed though - for those specialised apps.
>
> Just a thought...
>

FPC uses MT at least for 10 years and nobody complained about
performance yet. So I suspect the cases might be very rare when random
performance matters and having good random numbers is always a good
thing ... I prefer not to change it but it's fine for me for delphi
compatibility's sake ;)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Delphi's anonymous functions in Free Pascal

[Florian Klaempfl]

Am 08.11.2011 09:37, schrieb Graeme Geldenhuys:
> 2011/11/8 Tomas Hajny :
>>
>> Examples?
> 
> I can list them all, but I'm not going to waist my time on them again.
> Search the mailing list or Mantis.
> 
> But to humour you, here is just one of many examples: THelpEvent in
> the RTL. I proposed a patch to change it to be more in line with FPC's
> goals [being a cross-platform compiler, so requires cross-platform
> solutions]. The change was declined because THelpEvent is a direct
> copy of Delphi's equivalent, and even worse, is very Windows specific
> in its signature. Yes, it's a small and stupid example, but there are
> many more like this. Delphi-compatibility seems to trump everything
> else (as Martin said).

So you wanted to break existing stuff other people probably used? It is
indeed one of FPC's policy to avoid breakage of exisiting code.

Or did you propose a TFPHelpEvent?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Delphi's anonymous functions in Free Pascal

[Florian Klaempfl]

Am 08.11.2011 07:35, schrieb Graeme Geldenhuys:
> On 7 November 2011 20:41, Marco van de Voort wrote:
>>
>> That "current" is added by you. FPC strives to do that of course, but never
>> had the illusion it was near enough to claim something like that. Not now,
>> and not in the past.
> 
> So what exactly is the goals of FPC then? And please don't tell me
> "delphi compatible" because then you need to tell me which version of
> Delphi - and I doubt you can.
> 
> As a core developer of FPC can yo please summarize in one or two
> sentences the actual goal of FPC - that way we are all on the same
> page.

Let me answer:
Writing an (L)GPL'ed pascal (*) compiler being self hosting.

(*) pascal might be replaced by 'wirthian languages' if someone with a
lot of commitment over years pops up and works on this.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Delphi's anonymous functions in Free Pascal

[Florian Klaempfl]

Am 08.11.2011 07:20, schrieb Jürgen Hestermann:
> Jonas Maebe schrieb:
 That's exactly what he said: you are free to create a fork
>>> This argument is pulled out each time someone suggest things that the
> main developers don't like.
>> The reason that this argument is always used is simply because that is
> simply how it is.
> 
> I know that. But still: Why is this argument used like a knee-jerk
> reaction as soon as someone writes unliked opinions? 

The opinion is not unliked but just useless and wastes the time of
people who try to use this mailing list to support others using fpc. If
you want to express opinions again and again without any consequences
like coming up with code just write a blog. You know, "talk is cheap,
show me the code" (Thorvalds).
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Delphi's anonymous functions in Free Pascal

[Florian Klaempfl]

Am 21.10.2011 03:49, schrieb Andrew Pennebaker:
> 
> Lisp used for nuclear fail-safe systems
> I doubt languages without /map/ are up to the job.


Great, why don't you continue to use lisp then? If pascal does not
offers the language concepts you are used to, pascal is the wrong
language for you.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Delphi's anonymous functions in Free Pascal

[Florian Klaempfl]

Am 19.10.2011 23:28, schrieb Andrew Pennebaker:
>>From what I gather, procedure variables can indeed be referenced and
> passed around, etc.
> 
> However, procedures do not return anything, so it's hard to chain them.

They are called procedure variables but can also contain functions.

> In functional languages, it's handy to do several nested map(map(map f
> ... calls.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: operator overloading and counting references / creating / destoying anonymous instances

[Florian Klaempfl]

Am 29.07.2011 13:43, schrieb Bernd:
> 
> With interfaces and their reference counting it can be made to work
> but the cost of doing this seems so immense that I don't believe it is
> justifiable in many real world applications (at least not in my
> application).

The automatic constructor/destructor concept of C++ causes the same
overhead. And the overhead for a function or operator overloading based
approach is the same imo. Or do you have any example where a function
based approach performs better? Overloaded operators are converted into
function calls, there is no real difference.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: operator overloading and counting references / creating / destoying anonymous instances

[Florian Klaempfl]

Am 30.07.2011 17:05, schrieb Jürgen Hestermann:
>> > Say for instance you are working on Galois fields and you have to do
> arithmetic on the elements like this:
>> > g1 + g2 / g3
>> > If you don't have operator overloading, you have to do it with
> functions, like this:
>> > gf_add(g1, gf_div(g2, g3))
>> > This is not very readable, I'm sure you will agree.
>> No, I don't agree at all. The procedure call clearly shows me that a
> complex calculation
>> is done instead of an (atomic) add and division command on numbers.
> 
> 
> And there is another advantage of using procedures/functions instead of
> overloading operators:
> You can search for the procedure to look what it actualy does.

Not if you use function/procedure overloading. Then the situation is
exactly the same as for operators.

> How do you find the code that overloaded an operator?


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Availability of RawByteString

[Florian Klaempfl]

Am 14.04.2011 10:57, schrieb Jean-Marc BOTTURA:
> Hello,
> we need to use RawByteString with FreePascal and I saw it's implemented in
> cpstrnew which is in progress.
> Do you know when this branch will be integrated into a fpc release ?

No.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Forward type not resolved

[Florian Klaempfl]

Am 04.03.2011 01:46, schrieb waldo kitty:
> On 3/3/2011 17:15, Leonardo M. Ramé wrote:
>> Sorry, the error was here:
>>
>> TOnSqueeze = procedure (AQuote: TQuote); of object;
>>
>> This line should be:
>>
>> TOnSqueeze = procedure (AQuote: TQuote) of object;
> 
> amazing what a misplaced semi-colon will do, eh? ;)
> 
> i would have thought that there would have been an additional error
> concerning the trailing "of object"... was there? did it give a clue as
> to the actual error of the misplaced semi-colon?

c:\fpc>fpc test.pp
Free Pascal Compiler version 2.4.2 [2010/11/10] for i386
Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: Win32 for i386
Compiling test.pp
test.pp(7,12) Error: Forward type not resolved "TQuote"
test.pp(9,44) Fatal: Syntax error, "BEGIN" expected but "OF" found

Unfortunatly, Leonardo did not post a complete example but this is what
I get by guessing the missing parts.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Embedded web server

[Florian Klaempfl]

Am 25.02.2011 11:38, schrieb michael.vancann...@wisa.be:

> unless we
> include
> lnet in FPC. 

Well, fppkg uses it for years already, see utils/fppkg/lnet
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Embedded web server

[Florian Klaempfl]

Am 25.02.2011 11:18, schrieb michael.vancann...@wisa.be:
> 
> 
> On Fri, 25 Feb 2011, Ben wrote:
> 
>> Op 2011-02-25 11:47, Jorge Aldo G. de F. Junior het geskryf:
>>> iirc aservia was an experiment.
>>
>> Oh. So what everything is the different between Aservia vs nYume?
>>
>>
>>> why would you choose aservia over lightwebserver ?
>>
>> I was just looking at what aservia can do. I haven't played with
>> lightwebserver either. What I like about nYume, is the no dependency on
>> external code/libraries/components. nYume only uses what is included
>> with FPC already.
> 
> I just downloaded it. It is extremely leightweight and has no external
> dependencies; Since it looks like it is abandoned, I will see if we can
> incorporate it in FPC. It will make testing a lot easier for fpWeb.
> 

fphttpd is no abandoned :)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] trunk/packages/libxml/src/xmlxsdparser.pas

[Florian Klaempfl]

Am 05.02.2011 13:49, schrieb José Mejuto:

Hello FPC-Pascal,

Browsing recent changes in compiler I saw that xmlxsdparser has been
updated with some timezone functions conversion. This conversions
seems wrong to me as they are performed using "today" conditions not
given date/time conditions, so if today the computer is in daylight
saving mode and the date is 6 months away the result date will be one
hour wrong.

Check http://wiki.lazarus.freepascal.org/PascalTZ for further data
about this "problem".



Please create a bug report about this.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Correct use of var in function calls?

[Florian Klaempfl]

Am 05.02.2011 10:46, schrieb Bo Berglund:

But that is not what I am doing at all, so I can stick with a simple:

FillArr(Arr: TByteArr)

and be sure that I will not get back a different array, but instead
get my array filled as requested...



As soon as you call SetLength, this will break havoc. Then a deep copy 
is generated and it gets ref. count of 1 and it is destroyed at callee exit.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

OS independent packages was Re: [fpc-pascal] The new Delphi 2010 RTTI

[Florian Klaempfl]

Am 10.01.2011 11:16, schrieb alexv...@mail.ru:
> 10.01.2011 13:05, michael.vancann...@wisa.be пишет:
>>
>>
>> On Mon, 10 Jan 2011, Vincent Snijders wrote:
>>
>>> 2011/1/10 alexv...@mail.ru :
>
 But I want packages to be binary portable between OS (on target
 processor
 architecture)
>>>
>>>
>>> I don't think that is feasible, unless you don't use any OS features.
>>
>> Exactly.
>>
>> Even just because FPC supports multiple CPUs; You can't use an i386
>> package on SPARC or ARM.
>>
>> So you'll always have to recompile your package for all platforms that
>> you want to support.
>>
>>
> But only for all processors, not for all existing combinations of
> processor and OS.

The rtl package is OS specific anyways and as soon as you depend on the
rtl package (an fpc package will always depend on it), you need to build
your package for any FPC version, processor and OS combination.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] More Win CE

[Florian Klaempfl]

Am 17.11.2010 16:26, schrieb Felipe Monteiro de Carvalho:
> On Wed, Nov 17, 2010 at 12:11 PM, Matt Emson
>  wrote:
>> There is little chance that will happen as it assumes Nokia will focus on
>> Meego... Nokia can't focus on a blade of grass on a sunny day - they will
>> carry on as is IMO and be shamed in to releasing cheap and shoddy hardware
>> in a few years when it will be too little too late to save their business.
> 
> Which smartphone platform do you recommend then?
> 

There is none anymore :( I'am a long time WM user but WM7 is no option
for me. Neither Android (Java, version mess and Google) or iPhone (too
expensive and Apple).
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Is it posible to implement more than one interface in a class defination?

[Florian Klaempfl]

Sven Barth schrieb:

* No name resolution (function aliases) of conflicting interfaces


Ehhh... the following code compiles with 2.4.2 and even 2.4.0:


Typical FUD tactics: mix something people know being true with something 
wrong and they believe you the wrong statement.



var
  t: TMyInterfacedObject;
  i: IMyInterface;
begin
  t := TMyInterfacedObject.Create;
  try
i := t;
t.Foo;
i.Foo;
  finally
t.Free;
  end;
end.

 source end 

Output is:

 output begin 

Foo
Bar
An unhandled exception occurred at $08056B71 :
EInvalidPointer : Invalid pointer operation
  $08056B71

 output end 

(I don't know currently where exactly that EInvalidPointer comes 
from even a "t.AddRef" doesn't solve this...)


Releasing TInterfacedObject descendants by Free is a bad idea ;) It 
destroys the instance without checking if there are still queried 
interfaces.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Corba Interfaces and IInterface query

[Florian Klaempfl]

Graeme Geldenhuys schrieb:

On 14 November 2010 18:44, Florian Klaempfl wrote:

... and as soon as we do such a logical decision, you start whining, whining
about the bad fpc developers destroying your business plans.


Bo hoo... It's called being able to maintain code in the long run.


Oh, I forgot, depending on implementation details keeps your code 
maintainable ...


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Corba Interfaces and IInterface query

[Florian Klaempfl]

Graeme Geldenhuys schrieb:

FPC's designs should stay logical
and clean, and it's up to the developers to maintain their application
code and fixe such bad/broken code.  



... and as soon as we do such a logical decision, you start whining, 
whining about the bad fpc developers destroying your business plans. See 
the recent thread on fpc-devel about immediate release of unused 
temporary interfaces and not keeping them for an unlogical long time. Or 
did you forget about it already? I fear you did again ...

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] IntList

[Florian Klaempfl]

Am 04.11.2010 14:59, schrieb Marco van de Voort:
> In our previous episode, Florian Klaempfl said:
>>> Sorry,
>>>
>>> This was meant to be a private message.
>>>
>>> For those interested: the idea is to have a standard set of generics
>>> definitions that implement some commonly-used templates. A kind of STL
>>> in pascal.
>>
>> You are aware of the fgl unit in the rtl? It is supposed to be something
>> like this.
> 
> The fgl unit seems more targeted at implementing base Delphi types (which
> all map to arrays) using generics.

Currently yes, but it was supposed to contain more types (Micha didn't
continue ;)).
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] IntList

[Florian Klaempfl]

Am 04.11.2010 13:23, schrieb Michael Van Canneyt:
> 
> Sorry,
> 
> This was meant to be a private message.
> 
> For those interested: the idea is to have a standard set of generics
> definitions that implement some commonly-used templates. A kind of STL
> in pascal.

You are aware of the fgl unit in the rtl? It is supposed to be something
like this.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Widestring Questions

[Florian Klaempfl]

Am 26.10.2010 10:55, schrieb Tobias Giesen:
>> A bug may show anytime anywhere, but the built in ref counted string
>> types are AFAIK thread safe what concerns the ref count per se. I
>> suspect a subtle flaw in the client code is more probable.
> 
> No, it is a compiler bug. The same code works 100% perfectly on 
> Windows using Delphi, as well as on Mac OS X using FPC 2.2. Starting
> with FPC 2.4, it loses memory, which can be fixed by using

So without ref. counting it works.

> 
> UniqueString
> 
> in a number of spots in the code. That is proof enough that the
> compiler has a bug.

It is possible, but it depends on the usage of the string.

> I am trying to isolate it today by finding out
> where exactly the UniqueString is necessary.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Can variables be declared within a block?

[Florian Klaempfl]

Am 18.10.2010 14:58, schrieb Frank Church:
> 
> 
> On 18 October 2010 07:49, Florian Klaempfl  <mailto:flor...@freepascal.org>> wrote:
> 
> Am 18.10.2010 08:17, schrieb Zaher Dirkey:
> >
> >
> > On Thu, Oct 14, 2010 at 11:21 AM, Michael Van Canneyt
> > mailto:mich...@freepascal.org>
> <mailto:mich...@freepascal.org <mailto:mich...@freepascal.org>>> wrote:
> >
> >
> >
> > On Thu, 14 Oct 2010, Frank Church wrote:
> >
> > Can variables be declared within a begin end block?
> >
> >
> > No.
> >
> 
> 
> That is a rather emphatic no :).
>  Is there some performance or other related reason why it is a bad idea?

It's just a matter of readability, e.g. having a variable declared in
two blocks with the same name can cause you a lot of headache:

procedure p;

begin
  ...
  begin
var i : integer;
...
...
...
i:=12341234;
...
...
...
...
  end;
  ...
  ...
  ...
  begin
var i : integer;
...
writeln(i); <--- this i is not the same as above so i does not
contain 12341234 but it contains probably some garbage.
  end;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Can variables be declared within a block?

[Florian Klaempfl]

Am 18.10.2010 08:17, schrieb Zaher Dirkey:
> 
> 
> On Thu, Oct 14, 2010 at 11:21 AM, Michael Van Canneyt
> mailto:mich...@freepascal.org>> wrote:
> 
> 
> 
> On Thu, 14 Oct 2010, Frank Church wrote:
> 
> Can variables be declared within a begin end block?
> 
> 
> No.
> 
> 
> That found in Gnu Pascal
> Can we ask to be feature request?
> 

No.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64

[Florian Klaempfl]

Am 13.10.2010 00:51, schrieb Andrew Brunner:
> 
> This test case illustrates a FPC memory leak.  

What makes you think so? Internally freed memory is not immediatly
released to the OS as well.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] code optimization

[Florian Klaempfl]

> 
> So to better optimise the original program with regular optimisation
> options, I guess we need a) full SSA support

Yes.

> b) better (node) CSE
> support

Enabling node cse on loadparentfpn nodes helps already slightly:

diff a/compiler/ncgld.pas b/compiler/ncgld.pas
index 028e51e..1ab6f11 100644
--- a/compiler/ncgld.pas
+++ b/compiler/ncgld.pas
@@ -410,7 +410,7 @@ implementation
 if assigned(left) then
   begin
 secondpass(left);
-if left.location.loc<>LOC_REGISTER then
+if not(left.location.loc in
[LOC_REGISTER,LOC_CREGISTER]) then
   internalerror(200309286);
 if vs.localloc.loc<>LOC_REFERENCE then
   internalerror(200409241);
diff a/compiler/nutils.pas b/compiler/nutils.pas
--- a/compiler/nutils.pas
+++ b/compiler/nutils.pas
@@ -703,6 +703,8 @@ implementation
 end;
   loadn:
 begin
+  if assigned(tloadnode(p).left) then
+inc(result,node_complexity(tloadnode(p).left));
   { threadvars need a helper call }
   if (tloadnode(p).symtableentry.typ=staticvarsym) and
  (vo_is_thread_var in
tstaticvarsym(tloadnode(p).symtableentry).varoptions) then
diff a/compiler/optcse.pas b/compiler/optcse.pas
--- a/compiler/optcse.pas
+++ b/compiler/optcse.pas
@@ -65,7 +65,7 @@ unit optcse;
   cseinvariant : set of tnodetype =
[loadn,addn,muln,subn,divn,slashn,modn,andn,orn,xorn,notn,vecn,
 derefn,equaln,unequaln,ltn,gtn,lten,gten,typeconvn,subscriptn,

inn,symdifn,shrn,shln,ordconstn,realconstn,unaryminusn,pointerconstn,stringconstn,setconstn,
-isn,asn,starstarn,nothingn,temprefn {,callparan}];
+isn,asn,starstarn,nothingn,temprefn,loadparentfpn {,callparan}];

 function searchsubdomain(var n:tnode; arg: pointer) :
foreachnoderesult;
   begin

Enabling it on dyn. array expressions could help further in theory,  if
the compiler would know that no addref/decref code is needed in this
case for the temp. dyn. array variables :)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Obtain Class hierarchy (in MacPas mode)

[Florian Klaempfl]

Am 21.09.2010 13:42, schrieb Adriaan van Os:
> Michael Van Canneyt wrote:
>>
>>
>> On Tue, 21 Sep 2010, Adriaan van Os wrote:
>>
>>> I am looking for a way to obtain the class hierarchy of a program in
>>> MacPas mode (where there are no published properties). TObject has
>>> ClassParent, so a list of Class types would be sufficient, I think. I
>>> can't find however a routine in the RTL to obtain such a list.
>>
>> There is no such routine in the RTL, to my knowledge.
> 
> Can I add it ? I guess a low-level pointer to a list of VMT's would be
> sufficient to implement it ? 

Problem is: it breaks smartlinking.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ARM-Cortex port

[Florian Klaempfl]

Am 24.08.2010 11:53, schrieb Geoffrey Barton:
> 
> using Jonas and Jeppe's answers to my idiot questions in this forum, and
> Jeppe's startup code for the STM32F, I have FPC cross-compiling for the
> LM3S9B92, one of the TI Luminary processors. 

If you've any reusable startup code, we would be happy to include it in
official fpc.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: Reason for Win64 instead of Win32 [Was: Re: [fpc-pascal] windows 32bit cross to 64 ?]

[Florian Klaempfl]

> Because I consider Win32 and Win64 as one type of operating system. One
> "OS target". Just as Linux is one operating system for all those
> available platforms.
> 
> Maybe it would have been better to name the target "windows" instead of
> "win32" and "win64" from the beginning so there would be no confusion
> regarding this...

In the beginning there was win16 which was really different so it was
needed to call the 32 bit api win32. And don't forget, the win64 api has
slight differences from the 32 bit api e.g. regarding exception handling.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: Reason for Win64 instead of Win32 [Was: Re: [fpc-pascal] windows 32bit cross to 64 ?]

[Florian Klaempfl]

Am 17.08.2010 09:54, schrieb Sven Barth:
> Am 09.08.2010 22:36, schrieb Jonas Maebe:
>>
>> On 09 Aug 2010, at 22:32, Martin wrote:
>>
>>> Unfortunately it doesn't work. I get the following error:
>>>   make.exe all  CPU_TARGET=x86_64   FPC=c:\FPC\SVN\ppc386_2_4_0.exe
>>>   makefile:199: *** The Makefile doesn't support target x86_64-win32,
>>> please run fpcmake first.  Stop.
>>
>> Add OS_TARGET=win64
>>
>>
>> Jonas___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> 
> Does anyone know the reason why 64-bit Windows was added as win64
> instead of (x86_64-)win32? With Linux it was done the ${platform}-linux
> way as well.

MS calls it Win64 api, see e.g.
http://technet.microsoft.com/en-us/library/bb496995.aspx
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: Reason for Win64 instead of Win32 [Was: Re: [fpc-pascal] windows 32bit cross to 64 ?]

[Florian Klaempfl]

Am 17.08.2010 10:11, schrieb Sven Barth:
> Am 17.08.2010 10:03, schrieb Marco van de Voort:
>> In our previous episode, Sven Barth said:
>>>
>>> Does anyone know the reason why 64-bit Windows was added as win64
>>> instead of (x86_64-)win32? With Linux it was done the ${platform}-linux
>>> way as well.
>>
>> It's afaik microsofts own designation.
> 
> If that's the only reason then that sounds a bit lame in my opinion...
> but what's done is done.
> 

Why? It would only cause confuse to name it different than it is
officially called.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Licensing issue: Subclassing

[Florian Klaempfl]

Am 27.07.2010 14:32, schrieb Vladimir Zhirov:
> 
> So this seems unclear whether application that subclasses from
> RTL/FCL/LCL is a derived work of RTL/FCL/LCL and must itself be
> licensed under Modified LGPL, making source code open.
> 
> BTW, LGPL v3 explicitly allows subclassing:
> "Defining a subclass of a class defined by the Library is deemed a mode
> of using an interface provided by the Library."
> (http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html#SEC3),
> but Modified LGPL is based on LGPL v2.
> 
> I understand that the whole point of Modified LGPL is to allow creating
> closed-source products using FPC/Lazarus. But in the above aspect it
> seems not clear enough.

Well, the point of the Modified LGPL above is not complete: the goal is
also that one has to release changes like bug fixes to the RTL/FCL
sources. So the thumb rule is pretty simple: as long as you use
unmodified rtl/fcl sources/code, you don't have to release any source
code. If you use modified rtl/fcl sources, you've to release the patches
to the rtl/fcl sources.

> 
> Would someone of the core team please comment on this?

Subclassing a class which is under the modified LGPL used by FPC does
not require to release any sources of the subclasses under the modified
LGPL.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Test

[Florian Klaempfl]

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12

[Florian Klaempfl]

Graeme Geldenhuys schrieb:

Op 2010-06-04 15:45, Florian Klaempfl het geskryf:
of stuff. Of course, a patch breaking existing stuff will be accepted 
less likely.


And yet Embarcadero is ok with breaking compatibility - if it means
improving the product. Yet core developers from FPC and its "hobby project"
can't get over that hurdle??


You might judge on what's improving fpc and what not if you break the 
border of 500 resolved fpc bug reports. Then you know what average users 
really want (and not only the criers on mailing lists). The bug tracker 
is full with examples like: http://bugs.freepascal.org/view.php?id=16618

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pascal dialect -- was: Re: fpc-pascal Digest, Vol 72, Issue 12

[Florian Klaempfl]

The other problem with Delphi Compatibility is that not even the FPC
team knows which version of Delphi we are supposed to be Delphi
compatible with. 


Of course we know: given infinite time, we would support all. Given the 
limited time we have, we support the stuff we think being important. If 
you think something else is important: submit a patch like Paul did with 
the foreach stuff or Alexander Klenin's student with the case  
of stuff. Of course, a patch breaking existing stuff will be accepted 
less likely.



Oh, and we even have a bit of Kylix in the mix.  Compatibility with
Delphi is drastically declining, but still no improved design or other
goods ideas are allowed (most of the time). 


Most current Delphi code still compiles. Very little code uses the new 
features.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Text relocation in x86 binary lib

[Florian Klaempfl]

According to SELinux, this is a security issue..


I guess that it may prevent some address space randomization features. I very 
much doubt that it opens up security holes by itself though.


The .so should be still relocatable? The point about pic is that one 
page can be mapped on different virtual addresses in different 
processes, i.e. the page can be reused.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic enumerators

[Florian Klaempfl]

Anthony Walter schrieb:
> Is the keyword "generic" really needed here:

Yes, I explained it multiple times to you alreay.

> 
> type generic TEnumerator = class
> 
> - should be -
> 
> type TEnumerator = class
> 
> It looks completely unnecessary and I've never seen a situation in
> pascal where anything but an identifier follows the keyword type.
> Whomever came up with the idea was probably more interested in making
> the feature easy to implement in the compiler rather than more natural
> for pascal programmers.

Compared to you, the person who did it, did at least anything. You did
nothing so far.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] about dynamic array

[Florian Klaempfl]

José Mejuto schrieb:
> Hello FPC-Pascal,
> 
> Thursday, May 6, 2010, 4:58:41 PM, you wrote:
> 
>>> c> TList wraps TFPList, which is based internally on an array. So access
>>> c> is fast; insertion, deletion not.
>>>
>>> But it is faster than inserting elements in a dynamic array (unless
>>> reference counted ones) because it usually moves less amount of data
>>> (4/8 bytes per element).
>>>
> FK> Why do you think so? You can also create dyn. arrays of pointers.
> 
> I know, but I think this user is looking for a general purpose ordered
> list accesible by index and TList more or less matches the request and
> keep a more user friendly interface. Is quote "unless referenced
> counted ones" because as referenced counted are pointers, a dyn array
> of strings would be more or less as fast as a TList, well, a bit
> faster in fact. If the user plans to use a record (which is my
> suspect) with TList he must "new" and "dispose" the elements and he
> will end up with a dyn array of pointers after all, which is a TList.

A dyn. array of records requires no new/dispose as well as no type casts
as TList does.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] about dynamic array

[Florian Klaempfl]

José Mejuto schrieb:
> Hello FPC-Pascal,
> 
> Thursday, May 6, 2010, 3:53:59 PM, you wrote:
> 
> c> TList wraps TFPList, which is based internally on an array. So access
> c> is fast; insertion, deletion not.
> 
> But it is faster than inserting elements in a dynamic array (unless
> reference counted ones) because it usually moves less amount of data
> (4/8 bytes per element).
> 

Why do you think so? You can also create dyn. arrays of pointers.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] dynamic array contents and system.move

[Florian Klaempfl]

Vinzent Höfler schrieb:
>> I fear you've simply no clue about the usage,
>> internals and purpose of dyn. arrays so I stop this discussion.
> 
> As you always do once someone does not share your point of view,

Indeed, because I don't want to waste too much of my "fpc time" with
writing useless emails.

> The dynamic array simply fails the principle of least surprise. No
more, no less.

If you think so, don't waste time with writing emails, just don't use
them. Period.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Is this a reference counting bug?

[Florian Klaempfl]

Bihar Anwar schrieb:
> I found that the last element of a dynamic array starts with
> reference count = 2 in FPC, but in Delphi is 1. Is this an FPC bug,
> or FPC implements reference counting differ from Delphi?

FPC and Delphi handle code generation for ref. counted types slightly
different, so there might be cases where the ref. counter differs. As
long as there is no memory leak when the vars are properly used, we
don't consider it as a bug.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] deprecated syntax is inconsistent.

[Florian Klaempfl]

Graeme Geldenhuys schrieb:
> On 29 April 2010 14:51, Florian Klaempfl  wrote:
>> Having a bigger lookahead makes a lot more things far more complex
>> epecially in combination with include files, macros, generics.
> 
> Why?  

Because you've always to take care of the possible extra lookahead. The
scanner knows nothing about syntax.

> You only apply the extra lookaheads where needed (code that
> could be ambiguous). All other parts of the code will be parsed as
> normal - as it is done now.
> 
> So far I know of only two examples where extra lookaheads need to be used.
>   * wiki example where 'default' is used
>   * my example to fix the inconsistent syntax for hint directives 
> (deprecated).
> 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] deprecated syntax is inconsistent.

[Florian Klaempfl]

Michael Van Canneyt schrieb:
> 
> 
> On Thu, 29 Apr 2010, Graeme Geldenhuys wrote:
> 
>> On 29 April 2010 12:39, Jonas Maebe  wrote:
>>>
>>> The compiler uses only a single lookahead token, while disambiguating
>>> your
>>> example would require two.
>>
>> I did look at the links you posted and still couldn't see the problem.
>> The paragraph above gives the key information -  the FPC parses only
>> uses a single lookahead.
> 
> As far as I remember, this was one of the key strengths of the Pascal
> Language: that parsing is possible using a single lookahead token.

Having a bigger lookahead makes a lot more things far more complex
epecially in combination with include files, macros, generics.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fcl-passrc example program, and a couple of bugreports

[Florian Klaempfl]

Michael Van Canneyt schrieb:
> 
> 
> On Tue, 27 Apr 2010, Marco van de Voort wrote:
> 
>> In our previous episode, Michael Van Canneyt said:
>>>
>>> As soon as I get around to some bugfixing, I'll have a look at these.
>>
>> Shouldn't we create some testsuite for fcl-passrc? (or have a flag in the
>> existing testsuite to exclude tests from fcl-passrc or real compiler
>> tests
>> or so?)
> 
> I created a VERY small test sample in utils/fpdoc, it tests 'strange'
> cases. It would indeed be a good idea to create a testsuite in
> fcl-passrc itself.

Wouldn't it be enough just to let it scan/parse the whole fpc test suite :)?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Bridging FPC and Delphi

[Florian Klaempfl]

Anthony Walter schrieb:
> Graeme:
> 
> "To be honest, this is a slightly unfair case, saying Free Pascal must
> become Delphi compatible, when Free Pascal had generics support
> *before* Delphi did. Maybe Delphi should become more Free Pascal
> compatible."
> 
> I've preemptively disabled this argument so many times in the past. 

Really? I didn't see a single patch of you so far.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Bridging FPC and Delphi

[Florian Klaempfl]

Anthony Walter schrieb:
> Technical limitations aside, at this point what would be needed from the
> community to get the generic syntax changed? 

1) Delphi mode only
2) not breaking old code i.e. accepting both variants
3) more Delphi generic compatibility

> Supposing I had the soruce
> code changes to accommodate the change to remove the "generic" keyword,
> what would be needed from the community to approve moving that change
> into the language?
> 
> 
> 
> 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal