Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
32bit on Windows 64-bit uses Wow64.. which has a bit of overhead as an emulation layer. I believe it's the same one they use for ARM64 too. I can only guess at how optimally it works performance-wise, but compiling a couple thousand-liner utils was annoying. You could (at least on the machine I was using at the time) watch it just sit there briefly before any compiler output happened. Your test would probably have similar results, but the nuisance for me was the delay in the 32bit version actually starting. From: fpc-devel on behalf of Nikolay Nikolov via fpc-devel Sent: Thursday, January 13, 2022 1:40:33 AM To: fpc-devel@lists.freepascal.org Cc: Nikolay Nikolov Subject: Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC website for the next release? On 1/13/22 02:31, Ben Grasset via fpc-devel wrote: On Wed, Jan 12, 2022 at 7:38 AM Martin Frb via fpc-devel mailto:fpc-devel@lists.freepascal.org>> wrote: The downloads provided by Lazarus are also NOT a "pure, native 64-bit download". Only the "fpc.exe" and the non-cross "ppc64.exe" are native 64 bit. As I said, I do not know, what is currently provided by the Fpc "combined 32-/64-bit download". No Idea, if any of the fpc/ppc executable in this download are already 64-bit. Every single executable that actually originates from the FPC toolchain (so like `fpc.exe`, `ppcx64.exe`, `ppudump.exe`, `pas2js.exe`, `h2pas.exe`, and so on) contained in the current "lazarus-2.2.0-fpc-3.2.2-win64.exe" installer that the Lazarus website directs to when you click "Download Now" on a system running 64-bit Windows IS currently 64-bit. I just verified this myself. That particular installer does not include any cross compilers at all, also (the ones to target 32-bit Windows from 64-bit come in the smaller "lazarus-2.2.0-fpc-3.2.2-cross-i386-win32-win64.exe" installer. On Wed, Jan 12, 2022 at 7:55 AM Tomas Hajny via fpc-devel mailto:fpc-devel@lists.freepascal.org>> wrote: Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux (supported by the same compiler targetting 64-bit code) supports extended. This means that compiling source code with this compiler may result in a different binary as soon as there's e.g. an extended contstant included in the source code, or any compile-time calculations in this precision need to be performed. Isn't this specifically the kind of thing that the `FPC_SOFT_FPUX80` define solves? FPC does not even let you go from 64-bit Windows to 32-bit targets if that define isn't active IIRC, so presumably the same thing could be made the case in other scenarios if it's something people are widely concerned about. In any case, people who want native 64-bit Windows toolchains want them pretty much exclusively for use on 64-bit Windows to target 64-bit Windows, and will install any cross-compilers secondarily if they have a use for them. The 32-bit-to-64-bit Windows FPC toolchain is not a perfect drop-in replacement. Based on testing I did locally previously, it's not as fast as the native 64-bit one, Really? Are you sure, because I just tested make cycle on Linux and the results are: i386: real1m1.032s user0m53.194s sys0m5.572s x86_64: real1m32.651s user1m21.486s sys0m9.414s So, the 64-bit compiler is 50% slower. This is on an AMD Ryzen 9 5900X 12-core processor, 128 GB RAM and an SSD. I haven't tested in Windows, but it would be very strange and suspicious if the results are very different. I would double check if that's really the case and also try some things, like disabling any antivirus programs that might be slowing down your computer by scanning every exe file, produced by the compiler. and additionally there are other things to keep in mind like the 4GB RAM limit on 32-bit (which I have in fact seen more than one user on the Lazarus forums run into with larger projects, none of whom were using the 32-bit executables "on purpose"). A bug report with steps to reproduce would probably be nice. Nikolay ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] function GetCurrentThreadId vs variable ThreadID
looks like threadid is assigned to getcurrentthreadid in an initthread() function in thread.inc. but: getcurrentthreadid looks to be mapped to a changeable thread manager which is why that might seem weird in the docs.. -- Alexander Grotewohl https://dcclost.com From: fpc-devel on behalf of Martin via fpc-devel Sent: Sunday, March 28, 2021, 3:35 PM To: fpc-devel Cc: Martin Subject: [fpc-devel] function GetCurrentThreadId vs variable ThreadID I looked at the doc https://www.freepascal.org/docs-html/rtl/system/getcurrentthreadid.html https://www.freepascal.org/docs-html/rtl/system/threadid.html But the entry for ThreadId only says "Current Thread ID." Which is not distinguishing it from GetCurrentThreadId. So what is the difference? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Might need some help with this one
"break" is a windows built-in. explains the first attempt. -- Alexander Grotewohl https://dcclost.com From: fpc-devel on behalf of Tomas Hajny via fpc-devel Sent: Friday, November 27, 2020 11:16:26 AM To: FPC developers' list Cc: Tomas Hajny Subject: Re: [fpc-devel] Might need some help with this one On 2020-11-27 15:34, Bart via fpc-devel wrote: > On Thu, Nov 26, 2020 at 11:10 PM Tomas Hajny via fpc-devel > wrote: > >> Typing 'break.exe' in cmd.exe _does_ make a difference here (it >> executes >> as expected unlike when typing just 'break'). And obviously running >> break.exe using some other 'shell' (e.g. your preferred OFM ;-) ) >> works >> as well. > > Well, at my machine it did not. > I also called it from a batchfile (as break.exe) to see if I could > catch the errorlevel (I let it crash with a division by zero). > The errorlevel is set, but absolutely no output to screen or pipe. Understood. Haven't I already mentioned something about MS approach towards compatibility here recently? :/ --- D:\TEMP>cmd Microsoft Windows [Version 10.0.18363.1082] (c) 2019 Microsoft Corporation. Všechna práva vyhrazena. D:\TEMP>break D:\TEMP>break.exe I am Break D:\TEMP>.\break I am Break D:\TEMP> === Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler message colour scheme
I would probably do something like this:
const
ansi_colors: array[0..7] of char = ('0', '4', '2', '6', '1', '5', '3', '7');
procedure PrintColor(fg, bg: byte; s: string);
var
tmp: string;
begin
tmp:=#27+'[0;3'+ansi_colors[fg]+';4'+ansi_colors[bg]+'m'+s+#27+'[0m';
writeln(tmp);
end;
begin
PrintColor(2, 0, 'derp');
end.
Easy enough to remember pascal style color numbers.
--
Alexander Grotewohl
https://dcclost.com
From: fpc-devel on behalf of J. Gareth
Moreton via fpc-devel
Sent: Sunday, November 22, 2020 7:59 PM
To: Ryan Joseph via fpc-devel
Cc: J. Gareth Moreton
Subject: Re: [fpc-devel] Compiler message colour scheme
I'm getting there. I keep getting distracted or lost though! Hardware
failures don't help!
I'm trying a different approach this time and writing a whitepaper like
I've done with my more major changes for Free Pascal, so I can describe
its uses and how it works etc. It can be updated of course, but it
means I have something to refer to if I lose my way, and others can
better add to the concept.
In the case of that PrintColor example, I don't think it could be
inlined, for example, due to the call to IntToStr, among other things
(like if you call PrintColor with a non-constant actual parameter), but
if IntToStr were a pure function as well (and there's no reason why it
can't), then logically GenerateColorCode could easily be pure.
I'm glad there's still interest in pure functions. It may be a while
though, and I'm being tempted with a bounty and Patreon pledges to
implement "static single assignment" into the Free Pascal Compiler.
That will take some research to see if it's even possible and not prone
to completely breaking things!
First things first though, I've got a bug to fix in AArch64, and on the
same platform, I'm almost finshed implementing the optimisation that
turns division by a constant into a multiplication and shift.
Gareth aka. Kit
On 22/11/2020 21:37, Ryan Joseph via fpc-devel wrote:
>
>> On Nov 22, 2020, at 10:09 AM, J. Gareth Moreton via fpc-devel
>> wrote:
>>
>> Personally I'd write the function as something like "function
>> GenerateColorCode(codes: array of Byte): ansistring;", mostly in
>> anticipation of pure functions, because then the compiler can just replace
>> the call with the relevant string at compile time, but that's a long way off!
> That would great. Hopefully this gets finished some day.
>
> Regards,
>Ryan Joseph
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Binary size discrepancy with -a
would -a disable optimizations? i guess it'd depend on the intended use of the listings it generated -- Alexander Grotewohl https://dcclost.com From: fpc-devel on behalf of J. Gareth Moreton Sent: Saturday, July 18, 2020 11:09:29 PM To: FPC developers' list Subject: [fpc-devel] Binary size discrepancy with -a Hi everyone, I've noticed something a bit weird with the Free Pascal Compiler when you use the the -a option to dump the compiled assembly files... the resultant binaries are sometimes smaller. I recently tried it with Lazarus under x86_64-win64 (using "make distclean all install" with FPCOPT): (-O4 -OoCONSTPROP) 241,010,289 bytes - lazarus.exe (-a -O4 -OoCONSTPROP) 235,655,062 bytes - lazarus.exe Anyone else noticed this? Logically, shoudn't the EXE files be completely identical? Gareth aka. Kit -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows Console App
you're not using the crt unit are you? first because i think it doesn't support utf8 and second because i think you can cause this by doing "if keypressed.." without then doing readkey before exit. -- Alexander Grotewohl https://dcclost.com From: fpc-devel on behalf of Ozz Nixon via fpc-devel Sent: Saturday, April 25, 2020 8:21:13 PM To: FPC developers' list Cc: Ozz Nixon Subject: [fpc-devel] Windows Console App Anyone ever experience making a console app (cross-platform), but, on windows when the app finishes, it appears to have put an uppercase C or D in the keyboard buffer, so the Prompt now has C:\>D ??? Every time I run my app, be it show help screen and end, or actually execute - when it finishes I end up with a letter sitting at the prompt. (A few months ago, I was having a problem, and it was related to compiling all of the methods with cdecl. That build would leave a stray "C" at the start of the prompt upon exiting. Now, I ran into a new problem where I needed to recompile with -FcUTF8 to track down which units it thought were having a UTF-8 mismatch... it was showing the wrong unit until I used the -FcUTF8 compile option, then it actually showed what file had '' strings ... so I switched to # and it compiles, but, the prompts have "D" at the start of them now.(hopefully I described that understandable). Environment: Windows XP 32bit C:\FPC\3.0.4\bin\i386-Win32\fpc.exe If no one else has experienced/has a solution, I will sit down and bang out test cases until I find what combination (units, code, whatever) is producing this result. Ozz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC now supports Windows 33-bit
Congrats to the FPC team for being a bit above the rest ;) -- Alexander Grotewohl https://dcclost.com From: fpc-devel on behalf of Bart via fpc-devel Sent: Wednesday, April 22, 2020 4:21:03 PM To: fpc-devel Cc: Bart Subject: [fpc-devel] FPC now supports Windows 33-bit Hi, Please don't feel offended, but this typo just made me smile: (And a smile is what we need in these harsh times) Revision 44996 "Moved the common interface part of the win33 and win64 System units to the syswinh.inc include file." -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possible error in generated code for arm?
same.. lol -- Alexander Grotewohl https://dcclost.com From: fpc-devel on behalf of Michael Ring via fpc-devel Sent: Wednesday, April 22, 2020 8:21:55 AM To: fpc-devel@lists.freepascal.org Cc: Michael Ring Subject: Re: [fpc-devel] Possible error in generated code for arm? Arg... I feel completely stupid! Thank you for the Hint Jonas, using pxBuffer^ did the trick! Michael Am 22.04.20 um 11:15 schrieb Jonas Maebe: > On 22/04/2020 00:09, Michael Ring via fpc-devel wrote: >> function memset(pxBuffer:pointer; value : byte; count : Tsize):pointer; >> cdecl; >> begin >>FillChar(pxBuffer,count,value); >>Result := pxBuffer; >> end; > You need pxBuffer^ instead of pxBuffer (you want to fill the block to > which pxBuffer points, not the 4 bytes of pxBuffer itself). > > > Jonas > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possible error in generated code for arm?
Can you run gdb on there? When you break inside memset does the pxBuffer
pointer make sense (not 0x0)? Do the other two variables come in correctly?
Do you call memset or does an api in the OS call it? Perhaps it's a pointer to
a pointer on accident?
If you are required to provide memset are you also providing other memory
functions, for example to allocate? Is it passing a valid pointer back (one
that eventually gets to memset)?
Just a bit of a brainstorm.. sorry if I've oversimplified or missed the mark
entirely :)
--
Alexander Grotewohl
https://dcclost.com
From: fpc-devel on behalf of Michael
Ring via fpc-devel
Sent: Tuesday, April 21, 2020 6:09:57 PM
To: fpc-devel@lists.freepascal.org
Cc: Michael Ring
Subject: [fpc-devel] Possible error in generated code for arm?
I have the following code in a unit (I need to provide a memset function to be
able to link to freertos):
function memset(pxBuffer:pointer; value : byte; count : Tsize):pointer; cdecl;
begin
FillChar(pxBuffer,count,value);
Result := pxBuffer;
end;
When I look at the assembler code generated by latest Trunk fpc something is
very odd @08000970, I'd expect to see
LDR R0, [R11, #-0x30]
but in fact I see:
08000970 SUB.W R0, R11, #0x30
which makes no sense to me and later the code crashes inside of the FillChar
routine.
Compiler Bug? Or me overlooking something? I tried to compile with -O- and -O1,
with -O2 the generated code is a little different but there the SP is loaded to
R0 which I do not understand, I'd expect R0 to be set to address of pxBuffer.
(this is for armv7em, for armv6 also looks odd.
Thank you for your help,
Michael
FREERTOS_$$_MEMSET$POINTER$BYTE$LONGWORD$$POINTER
DEBUGSTART_$FREERTOS
memset
$Thumb
begin
08000958 MOVR12, SP
0800095A PUSH.W {R11, LR}
0800095E SUB.W R11, R12, #4
08000962 SUBSP, SP, #0x48
08000964 STRR0, [R11, #-0x30]
08000968 STRB R1, [R11, #-0x34]
0800096C STRR2, [R11, #-0x38]
FillChar(pxBuffer,count,value);
08000970 SUB.W R0, R11, #0x30
08000974 LDRB R2, [R11, #-0x34]
08000978 LDRR1, [R11, #-0x38]
0800097C BL SYSTEM_$$_FILLCHAR$formal$LONGINT$BYTE ; 0x080002
Result := pxBuffer;
08000980 LDRR0, [R11, #-0x30]
08000984 STRR0, [R11, #-0x3C]
Am 21.04.20 um 23:07 schrieb Joao Schuler:
just as point for consideration, I'm not sure if data alignment will improve
speed on future processors:
https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/
Food for thought: imagine if we had single (32 bits floating point) values
dynamic arrays with 1 million values each: a b and c. I would love to have
something like this:
a := b + c;
___
fpc-devel maillist -
fpc-devel@lists.freepascal.org<mailto:fpc-devel@lists.freepascal.org>
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows 32bit - FPC 3.0.4 Gets an Error - but not on Linux or Mac...
or maybe don't use the variable name "result" because it might point to the special delphi "result" var and not yours?--Alexander Grotewohlhttp://dcclost.comOn Sep 28, 2019 4:15 PM, Alexander Grotewohl wrote:don't know off the top of my head but does the ord() bit segfault without assigning it to anything? like if the function only had writleln(ord())! or does the result:= section segfault using ord() without the pointers?my guess is it works on linux/mac purely by luck. but i could be wrong.--Alexander Grotewohlhttp://dcclost.comOn Sep 28, 2019 3:21 PM, Ozz Nixon wrote:When I evaluate the code - it is perfect. However, when I run the code, it raises a SIGSEGV - Segmentation fault. Yet, the code runs perfectly on Linux 64bit machine, and Mac 32bit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows 32bit - FPC 3.0.4 Gets an Error - but not on Linux or Mac...
don't know off the top of my head but does the ord() bit segfault without assigning it to anything? like if the function only had writleln(ord())! or does the result:= section segfault using ord() without the pointers?my guess is it works on linux/mac purely by luck. but i could be wrong.--Alexander Grotewohlhttp://dcclost.comOn Sep 28, 2019 3:21 PM, Ozz Nixon wrote:When I evaluate the code - it is perfect. However, when I run the code, it raises a SIGSEGV - Segmentation fault. Yet, the code runs perfectly on Linux 64bit machine, and Mac 32bit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Case else allows multiple statements
I'm assuming that's what the 'statementlist' means in the documentation
(rather than just 'statement')
On 9/19/2019 3:33 PM, Sven Barth via fpc-devel wrote:
Am 19.09.2019 um 21:07 schrieb Kirinn:
I've stumbled on a situation where a case statement compiles when I
wouldn't expect it to. I would expect the below code to produce a
compile error:
program test;
var i : byte = 5;
begin
case i of
0..4: writeln('value is ', i);
else writeln('Else!');
i := 3;
writeln(i);
end;
end.
This compiles without errors or warnings on FPC 3.0.4 and produces
the output:
Else!
3
None of the documentation I've looked at suggests that a case-else is
implicitly a block. All examples in the documentation show only a
single statement in any else clause, or an explicit begin-end block.
Is this expected behavior? If yes, the reference guide (13.2.2) would
benefit from mentioning this.
That is indeed by design (at least Delphi compiles it as well). You
can file a bug report against the documentation so that it isn't
forgotten.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
I miss the sushi in Japan too my dude.--Alexander Grotewohlhttp://dcclost.comOn Jun 16, 2019 6:44 PM, Ryan Joseph wrote: > On Jun 16, 2019, at 6:00 PM, Benito van der Zander wrote: > > Objects are much more useful than classes or records Now that’s an inflammatory statement! :) But seriously, I do miss record inheritance from C++, C#, Swift when I’m in Pascal. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test
It seems to be working tho--Alexander Grotewohlhttp://dcclost.com___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] When will the next version of FPC be released?
can't you just use an untyped parameter in a clearmem procedure you make yourself?procedure ClearMem(var m);--Alexander Grotewohlhttp://dcclost.com___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo
Not to mention the users who pick up FPC and have to port what they've previously learned. That information is useful even if the code isn't already written. On 11/4/2018 7:41 AM, wkitt...@windstream.net wrote: On 11/3/18 7:09 PM, Ben Grasset wrote: (The same could be said about the various other wildly outdated bits of information on the overall site and the fact that it gives now-hugely-irrelevant topics like "porting from TP7" such precedence, but that's a different issue.) porting from TP/BP 6/7 is still fairly relevant... maybe not in your part of the universe but it is definitely relevant for others... in one development directory here there are well over 500 pas and inc files needing porting... no clue at this time the number of LoC in those files but it is a lot more than those with the porting task really want to know about else it set a daunting task ahead of them... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dangerous optimization in CASE..OF
To be honest I agree with what he's saying. We're bending enums to do things normal people just wouldn't (and shouldn't) do. And seriously, "Delphi, Delphi, Delphi!" .. why don't we strive for something a little better and make the people porting from Delphi bend a little this way than us their way. Alex On 04/21/2018 08:12 AM, Thorsten Engler wrote: -Original Message- From: fpc-devel On Behalf Of Martok Sent: Saturday, 21 April 2018 21:39 To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF Am 20.04.2018 um 21:35 schrieb Ondrej Pokorny: Sven (or anybody else), could you please comment on https://bugs.freepascal.org/view.php?id=33603 ? I feel I am getting crazy. That bug became a textbook example of Cipolla's fourth law, sorry. I only have two questions really. Who the fudge is "Thaddy de Koning" and should he continue to have access to the bug tracker? I did a search in the issue for "Thaddy de Koning", and the ones I checked, I didn't see a single actually constructive or helpful note, and the language was pretty much generally very aggressive and insulting, to the point that if there was a function to report notes with inappropriate language, I would be using that for the majority of his notes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Wrong docs: not initialized global variables
https://www.freepascal.org/docs-html/ref/refse20.html#x50-680003.9 On 04/04/2018 01:32 PM, Ondrej Pokorny wrote: On 04.04.2018 18:53, Jonas Maebe wrote: On 04/04/18 18:44, Ondrej Pokorny wrote: I want to stress that the compiler emits a warning on code that does not have (and also cannot have) an error An error is wrong code behaviour. If you do not initialise a variable with the correct value, then you can have an error. No, no, no and again no. Do you try to convince me that I cannot rely on well documented compiler behavior? Even Sven stated earlier in this thread that the FPC docs are correct in case of managed variables: "Managed types are an exception to this rule: Managed types are always initialized: in general this means setting the reference count to zero, or setting the pointer value of the type to Nil." and "It should be stressed that initialized variables are initialized when they come into scope" https://www.freepascal.org/docs-html/ref/refse24.html Again, the code procedure Test; var S: string; I: Integer; begin for I := 0 to 1 do S := S + '1'; Writeln(S); end; does not have an error, cannot have an error and the behavior is guaranteed and well documented => no warning should be here. + Do you try to convince me that the code below can have an error and should emit a warning as well because it does not initialize the FS and FI fields? program Project1; type TMyObject = class private FS: string; FI: Integer; public property S: string read FS write FS; property I: Integer read FI write FI; end; begin with TMyObject.Create do begin Writeln(S); Writeln(I); Free; end; end. It's the same case - object fields are documented to be initialized. You mean I should not rely on this feature and it is an error that I did not initialize them with the correct values? This correct value can be different from "empty string" or "nil". If I want to have a different value from "empty string" or "nil" I know I have to initialize it by myself. I don't need a warning for it. For the same reason, we also warn about uninitialised global variables (if this can be detected without interprocedural analysis, i.e., if they are only used in the main program code; but that is merely due to a limitation of the analysis). Uninitialised global variables are the same case: the compiler should not emit a warning here because again, it is well documented that they are implicitely initialized (at least in the Object Pascal Language Guide from Borland from 2002 it is documented). Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Multiple variable initialization - YES
uses SysUtils; // inttostr
procedure blank(a: array of pointer);
var
i: longint;
begin
for i:=low(a) to high(a) do
// string(a[i]^):='';
string(a[i]^):='silly ~~~ '+IntToStr(i);
end;
var
s, i, l, {l,} y: string;
begin
blank([@s, @i, @l, {@l,} @y]);
writeln(s); writeln(i);
writeln(l); writeln(l);
writeln(y); // !!
end.
On 4/2/2018 9:38 AM, Péter Gábor wrote:
Hi!
I have bean read all of the emails in this topic and now I have to write
:) :
If multiple type declaration (A, B: Integer) are allowed then this new
feature would not make difficulty to learn. Especially if we compare it
to generics, what is already in the language and required/requires to
learn a new (and non-conventional) syntax.
If the question is (as Jonas said) that "Is it really necessary to allow
this"? - NOT necessary, we can live without it BUT...
BUT if ask the sub-questions (by Jonas):
- Does it make things much easier to read? - YES
- Less error prone to write? - YES
- Increase productivity a lot? - YES
Sum of answers are absolutely YES!
The requested language feature is a good idea that can make our favorite
language better in all manners.
You can see it if you (all) take a look at at the examples (from Ondrej)
below:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
OLD:
procedure Test(const A: Integer = 0; const B: Integer = 0; const C:
Integer = 0; const D: Integer = 0);
NEW:
procedure Test(const A, B, C, D: Integer = 0);
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
OLD:
procedure Test;
var
A, B, C, D, E, F: string;
begin
A := '';
B := '';
C := '';
D := '';
E := '';
F := '';
end;
NEW:
procedure Test;
var
A, B, C, D, E, F: string = '';
begin
end;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
OLD-MIXED:
procedure Test(const A: Integer = 0; const B: Integer = 0; const C:
Integer = 0; const D: Integer = 0);
var
E, F, G, H,,I, J: string;
begin
E := '';
F := '';
G := '';
H := '';
I := '';
J := '';
end;
NEW-MIXED:
procedure Test(const A, B, C, D: Integer = 0);
var
E, F, G, H, I, J: string = '';
begin
end;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
And again, the requested language feature is a good idea that can make
our favorite language better in all manners.
2018-03-24 11:46 keltezéssel, Ondrej Pokorny írta:
Is there a reason why multiple variable initialization is forbidden?
program Test;
var
A: Integer = 0; // allowed
B, C: Integer = 0; // not allowed
begin
end.
Regards
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Multiple variable initialization
It sounds more like you're making a case for all integers to be initialized to zero by default. I still fail to see any practical uses other than wanting to not type "integer" twice. Alex On 03/24/2018 11:20 AM, Ondrej Pokorny wrote: On 24.03.2018 15:46, Alexander Grotewohl wrote: The patch is to put them on separate lines. Preferably with meaningful comments for each. If FPC was changed at the whim of every programmer we'd end up with a huge mess that no longer resembles pascal. Please tell me who decides about the borderline between whim and usefulness. E.g. FPC supports initializing local variables, which Delphi and (if I am not mistaken) ISO Pascal don't support: procedure Test; var A: Integer = 0; begin end; Is it a whim as well? If FPC has this extension, why not to support procedure Test; var A, B: Integer = 0; begin end; ? Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
