Re: [fpc-pascal] FPC for Win64

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 wi

Re: [fpc-pascal] Extended type under Win64

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 ?

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

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) th

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

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 er

Re: [fpc-pascal] ppc64le ABI problem

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

Re: [fpc-pascal] Implementation of variant records

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

Re: [fpc-pascal] Syntax changes suggestions

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.

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

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

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

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

Re: [fpc-pascal] Freepascal Floating Point Issue

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

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

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...@freepas

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

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

Re: [fpc-pascal] Smart Pointers

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

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

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

Re: [fpc-pascal] Happy tickets benchmark

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:=somet

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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 commi

Re: [fpc-pascal] Happy tickets benchmark

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 Window

Re: [fpc-pascal] AVR Busy Wait implementation

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

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

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-w

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

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} >{$optimizat

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

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 shou

Re: [fpc-pascal] Issue with Linking

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:

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

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 itse

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

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 vari

Re: [fpc-pascal] Google Code closing down

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

Re: [fpc-pascal] MIPS32 support

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: ht

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

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, ju

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

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(

[fpc-pascal] Test, please ignore

___ 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!

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

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

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\gra

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

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 tim

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

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

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

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. Whe

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

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 co

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

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

Re: [fpc-pascal] Refr Bruhl

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 -

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

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 inter

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

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

Re: [fpc-pascal] fpimage reader for jpeg2000

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/mailm

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

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 t

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

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, larg

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

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

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

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

Re: [fpc-pascal] Spam

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

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

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

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

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

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

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 doin

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

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 po

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

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 F

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

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-pa

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

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

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

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 Mersen

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

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

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

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

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

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 be

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

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.

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

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 functi

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

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/destruct

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

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,

Re: [fpc-pascal] Availability of RawByteString

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-pasc

Re: [fpc-pascal] Forward type not resolved

\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

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

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/li

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

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 cho

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

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 i

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

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.

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

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)

Re: [fpc-pascal] More Win CE

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 s

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

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: TMyInt

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

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.

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

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 b

Re: [fpc-pascal] IntList

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 >>> d

Re: [fpc-pascal] IntList

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 i

Re: [fpc-pascal] Widestring Questions

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 1

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

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 A

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

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 fou

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

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 h

Re: [fpc-pascal] code optimization

> > 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 1

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

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

Re: [fpc-pascal] ARM-Cortex port

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 hap

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

> 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

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

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 Mak

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

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 w

Re: [fpc-pascal] Licensing issue: Subclassing

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

[fpc-pascal] Test

___ 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

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

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

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

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

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 vir

Re: [fpc-pascal] Generic enumerators

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 an

Re: [fpc-pascal] about dynamic array

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 >>> refere

Re: [fpc-pascal] about dynamic array

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 count

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

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 ema

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

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 t

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

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 pos

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

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 sti

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

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

Re: [fpc-pascal] Bridging FPC and Delphi

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 argu

Re: [fpc-pascal] Bridging FPC and Delphi

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 cha

  1   2   3   4   5   6   7   8   >