Re: [fpc-devel] Curious about the effect of all the new optimizations....

On 3/1/23 8:53 AM, Mattias Gaertner via fpc-devel wrote: On Wed, 1 Mar 2023 14:10:28 +0100 Sven Barth via fpc-devel wrote: [...] I can't remember the proverb that Florian used, but it essentially boils down to very small changes, individually not amounting to much, but which accumulate into

Re: [fpc-devel] Why: "Can't take the address of constant expressions" here?

On 1/13/23 5:35 AM, Bart via fpc-devel wrote: On Fri, Jan 13, 2023 at 11:13 AM wkitty42--- via fpc-devel wrote: First of all, adding a 'end;" for the "with" compiles under Linux. That's because widestring=unicodestring on Linux. i'm a little surprised there is no "

Re: [fpc-devel] Why: "Can't take the address of constant expressions" here?

On 1/12/23 10:29 AM, Mattias Gaertner via fpc-devel wrote: On Wed, 11 Jan 2023 23:58:34 +0100 Bart via fpc-devel wrote: [...] begin with WideStringManager do begin writeln(1); Wide2AnsiMoveProc(pwidechar(WSource),RawByteString(ADest), CP_UTF8, Length(WSource));

Re: [fpc-devel] Building trunk of today fails on Windows: Error:Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

On 8/22/21 1:56 AM, J. Gareth Moreton via fpc-devel wrote: It might be to do with the order that directories are searched. If it finds the 64-bit version ghost, then it will throw an error. I've requested to change the error to a warning instead in the post, but was shot down. if that

Re: [fpc-devel] ConsoleIO and flushing buffered output

On 6/9/20 2:55 AM, Christo Crause via fpc-devel wrote: for c := 'A' to 'Z" do write(c); oops! i failed to note that the above is character by character whereas what i spoke of in my previous post is line by line :/ -- NOTE: No off-list assistance is given without prior approval.

Re: [fpc-devel] ConsoleIO and flushing buffered output

On 6/9/20 2:55 AM, Christo Crause via fpc-devel wrote: I will of course submit a patch once I'm satisfied it is good enough.  My concern with the current patch is that a low level flush is called after every write statement, so a simple loop like the following: for c := 'A' to 'Z" do

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

On 5/1/20 10:50 AM, Bart via fpc-devel wrote: On Fri, May 1, 2020 at 3:59 PM Sven Barth wrote: Bart had only replied to me, thus I fully quote his mail here. There is something fishy going on with this ML. Whenever I click on reply in this list, the reply doesn't go to the list, but to th

Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!

On 1/29/20 8:54 AM, Ozz Nixon via fpc-devel wrote: Would/Could, LANG/LOCALE affect socket output? wouldn't they affect what the server decides to transmit based on the selected "character set"? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing

Re: [fpc-devel] Looking for some general clarification on how exactly revision #43175 "fixes" bugtracker issue #0036139

On 10/12/19 7:54 PM, Ben Grasset wrote: Generally speaking, I would expect any compiler that is *capable* of realizing that the while loop has zero chance of *ever being entered at all* in the first place to remove the loop from its final codegen entirely, because there's no logical reason for

Re: [fpc-devel] Undesirable attachment to issue #29332

On 7/12/19 5:56 AM, Bart wrote: Hi, User tomas platz attached a pdf (119.pdf) to https://bugs.freepascal.org/view.php?id=29332 This attachment seems to be a document that has nothing to do with programming (in freepascal or any other language). It is either some sort of spam or maybe even

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On 7/7/19 10:43 AM, Marģers . via fpc-devel wrote: Well, trunk i use still has no string quote character " . Maybe it's time add that too while Ben Grasset on implementing multi line strings? Just kidding... hahahaha! i guess my memory is worse than i thought! :rotflmao: truth be known, i've

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On 7/6/19 4:50 PM, wkitt...@windstream.net wrote: const MultiLine = `Sentence one. Another sentence. A third sentence. A fourth sentence. A fifth sentence.`; procedure foo   procedure bar     const MultiLine1 =   `Sentence one.    Another sentence.    A third

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On 7/6/19 12:05 PM, Ben Grasset wrote: On Sat, Jul 6, 2019 at 11:51 AM Ryan Joseph wrote: You can of course shift the strings all the way to the left (which is ugly) Is it though? I think it looks fine, personally, if you place the initial backtick on the next line after the equal sign,

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On 7/4/19 9:54 AM, Ben Grasset wrote: On Thu, Jul 4, 2019 at 9:28 AM wrote: personally speaking, i liked the initial idea but i can now easily see why it is only allowed in source code comments... there's a world of difference between them... in one case, the formatting stays put

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On 7/4/19 3:27 AM, Pascal Riekenberg wrote: What about a Lazarus-Addon / Codetools extention that generates an old style multi-line string from a selection and the other way around to make old style multi-line strings editable again, so you can keep indention and trailing and leading whitespaces

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On 7/3/19 12:53 PM, Ben Grasset wrote: On Wed, Jul 3, 2019 at 10:22 AM Marcus Sackrow wrote: I use an operator overload(not for constants but inside the code) because I'm used to our script engine have the '/' as operator for strings as line break. That's certainly a neat use of

Re: [fpc-devel] fphttpclient cannot download a file from w3.org

On 7/1/19 8:10 AM, Ondrej Pokorny wrote: Fails with exception: EHTTPClient Error reading data from socket #0 fpc_raiseexception(0x145fb14, 0x0, 0x) at ..\inc\except.inc:158 #1 FILLBUFFER(0x145fb14) at fcl-web\src\base\fphttpclient.pp:731 #2 READSTRING(0x15e1c30, 0x0) at

Re: [fpc-devel] Initial implementation of a "functional" array helper unit, as suggested by Sven Barth on the Lazarus forums.

On 6/28/19 12:39 PM, Ben Grasset wrote: Yikes, I didn't realize the "preformatted" code from the Lazarus HTML exporter would show up with a bunch of asterisks outside of a real email client. FWIW: it did that because it *BOLD*ed those lines or at least attempted to... yeah, it is another

Re: [fpc-devel] XML node dump feature

On 6/26/19 1:48 AM, J. Gareth Moreton wrote: Maybe I'm misreading this, but does that mean you're not a fan of the "pure" directive, Jonas? i've been quietly reading along on all this "pure function" stuff since it was first brought up but somehow i've missed exactly what "pure" means...

Re: [fpc-devel] Object upgrades (new)

On 6/17/19 4:56 PM, Sven Barth via fpc-devel wrote: Am 17.06.2019 um 19:56 schrieb wkitt...@windstream.net: And yes, both are again different from classes. yeah, i'll have to see if i can figure out what classes are and if they are one of the old-school objects or records... yeah, i'm

Re: [fpc-devel] Object upgrades (new)

On 6/17/19 12:49 PM, Sven Barth via fpc-devel wrote: schrieb am Mo., 17. Juni 2019, 14:15: On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote: > schrieb am Mo., 17. Juni 2019, 02:07: > >     what always confused me these days is that records and objects were one thing

Re: [fpc-devel] Object upgrades (new)

On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote: schrieb am Mo., 17. Juni 2019, 02:07: what always confused me these days is that records and objects were one thing back in the (TP6) day but today they are something quite different... i had to be very careful when i wrote my

Re: [fpc-devel] Object upgrades (new)

On 6/16/19 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. what

Re: [fpc-devel] Object upgrades

On 6/16/19 4:41 PM, Sven Barth via fpc-devel wrote: Am 16.06.2019 um 17:43 schrieb wkitt...@windstream.net: On 6/16/19 10:23 AM, Ryan Joseph wrote: Charlie, I’m still not seeing my own messages posted if gmail can determine that a message coming in from a list is one you sent, it does not

Re: [fpc-devel] Object upgrades

On 6/16/19 10:23 AM, Ryan Joseph wrote: Charlie, I’m still not seeing my own messages posted if gmail can determine that a message coming in from a list is one you sent, it does not pass it on back to you... there's no way to turn this off that i've found... they want you to use their

Re: [fpc-devel] [PATCH] Add support for Hygon Dhyana processor

On 5/23/19 5:10 AM, Jinke Fan wrote: { return base type of processor: 0 - is Unknown, 10 - is AMD (AuthenticAMD), } +{10 - is Hygon (HygonGenuine) } is there a problem here? AMD and Hygon are both listed as 10... {

Re: [fpc-devel] "Case statement does not handle all possible cases" Warning

On 5/18/19 9:42 PM, Ralf Quint wrote: A warning from the compiler is hence an appropriate response, telling the programmer to check the source and make a decision, even if it is adding an empty else clause to the offending case statement. Everything else is just "lazy programming", like it or

Re: [fpc-devel] Unexpected behaviour of bit operators

On 5/17/19 9:44 AM, J. Gareth Moreton wrote: It's a constant set to equal 2^n, or in binary, 1 followed by n zeroes. ugh! yeah, i see that now... the layout confused me as i'm used to CONST being on its own line or prefixed to every constant defined... eg: const n=12; s=1 shl n; OR

Re: [fpc-devel] Unexpected behaviour of bit operators

On 5/17/19 4:47 AM, Marco Borsari via fpc-devel wrote: In the code below program test; const n=12; s=1 shl n; var a,b,c,h1,h2:word; ummm... what is 's'? you've used it before it has been defined... begin a:=77; b:=0; (*c:=(a XOR b)*(a SHL 5+b SHR 2);*) h1:=((a XOR b)*(a SHL 5+b SHR 2))

Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

On 3/24/19 6:21 PM, Bart wrote: Extract from fpc.cfg from 3.0.4 (created by offcial installer) # searchpath for units and other system dependent things -FuC:\devel\fpc\3.0.4/units/$fpctarget -FuC:\devel\fpc\3.0.4/units/$fpctarget/* -FuC:\devel\fpc\3.0.4/units/$fpctarget/rtl Extract from fpc.cfg

Re: [fpc-devel] "Blank slate" next version of FPC

On 3/9/19 1:06 PM, Anton Shepelev wrote: Whenever the programmer grows annoyed of jumping to the declaration section and back to code, he knows it is time to cut his spaghetti into more manageable parts. BINGO! give this man a cigar! FWIW: this annoyance at jumping back and forth is also a

Re: [fpc-devel] "Blank slate" next version of FPC

On 2/20/19 12:58 PM, James via fpc-devel wrote: Someone pointed out that a main goal of Pascal was to keep one from shooting oneself in the foot. It is this spirit that I think should be extended (if possible) to adopt at least the memory safe aspect of Rust. There are other programming

Re: [fpc-devel] "Blank slate" next version of FPC

On 2/20/19 1:28 PM, Giuliano Colla wrote: Keeping all declarations separated from code is just good programming practice. Mixing declaration and code is bad programming practice, IMO, and I appreciate Pascal for not supporting it. this falls in the same line as keeping business logic separate

Re: [fpc-devel] "Blank slate" next version of FPC

On 2/20/19 2:08 PM, Nikolai Zhubr wrote: 20.02.2019 18:24, Dimitrios Chr. Ioannidis via fpc-devel: [...]  I'd like to see an example how this is less safe. Well one of the answer in the Cantu blog has this ( which I changed to lets say a "real world" relative big function ) : How this

Re: [fpc-devel] Compiler directives in getopts unit

On 1/17/19 1:23 PM, Bart wrote: It seems this code at one time needed to be compilable with TP. AFAIK TP however does not support {$IF CONDITION} nor the Declared() macro(?), so the source should not be compilable anymore with TP? if we set TP mode, what will happens if $IF is removed/changed?

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

On 12/16/18 7:01 AM, Marco van de Voort wrote: Op 2018-12-15 om 22:27 schreef wkitt...@windstream.net: i'm guessing that VFP is Virtual Floating Point which i would understand as being emulated kinda like we used to do when a machine didn't have a math co-processor in it... >> No, VFP is

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

On 12/15/18 11:57 AM, Nikolai Zhubr wrote: 15.12.2018 19:09, wkitt...@windstream.net: On 12/15/18 10:36 AM, Nikolai Zhubr wrote: So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ? is this a typo? should it be -CfVPF4_S16 with F and V swapped? No. From ppcrossarm.exe -i:

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

On 12/15/18 10:36 AM, Nikolai Zhubr wrote: So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ? is this a typo? should it be -CfVPF4_S16 with F and V swapped? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

On 12/15/18 9:29 AM, Nikolai Zhubr wrote: I suspect this is an inintended flag set by my arm-linux-as.exe for some reason... Probably have to get rid of it somehow... so the real questions are: 1. is this flag being set erroneously? 2. are the .o files being built properly? 3. should

Re: [fpc-devel] Stringlist customsort

On 12/2/18 8:56 AM, Franz Müller wrote: @Tomas Hajny Ah - thank you. Very strange. I did not expect and did not notice that when I click on "reply to list", the reply uses another mail address than the one the mail was sent to. > Looks like an error of the thunderbird mailprogramm, are you

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

On 11/4/18 10:31 PM, Ben Grasset wrote: It may really truly be the case that you somehow have a codebase that you're still in the process of porting, no one said "still in the process of porting"... porting of those hasn't even started... but in all honesty /just /setting {$mode TP} and

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

On 11/4/18 10:26 PM, Ben Grasset wrote: I'm not young. You're making all kinds of assumptions here. TP7 /is /generally speaking, irrelevant in the fast majority of cases nowadays. FPC is 1000x more advanced in every conceivable way than any version of Turbo Pascal ever was. There is nothing

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

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

Re: [fpc-devel] Graphical RAD IDE in FPC

On 09/17/2018 02:20 AM, Alexander via fpc-devel wrote: I obtain lazarus_1_8_4 sources and make it. See about dependent Lazarus: GTK widgets. GTK is C widgets, but not native Pascal widgets. AFAIK, the term "native" is about OS widget look... not about language vs language... -- NOTE: No

Re: [fpc-devel] Omit hint/warning for a fixed-size array

On 08/31/2018 08:50 AM, Michael Van Canneyt wrote: On Fri, 31 Aug 2018, wkitt...@windstream.net wrote: On 08/30/2018 03:46 AM, Ondrej Pokorny wrote: Hello, is there a way not to get a "Variable xyz does not seem to be initialized" hint/warning for a fixed-size array? program Project1; uses

Re: [fpc-devel] Omit hint/warning for a fixed-size array

On 08/30/2018 03:46 AM, Ondrej Pokorny wrote: Hello, is there a way not to get a "Variable xyz does not seem to be initialized" hint/warning for a fixed-size array? program Project1; uses Classes; var Buffer: array[0..255] of Byte; what about Buffer: array[0..255] of Byte = [0];

Re: [fpc-devel] @Gareth messages thread

On 07/31/2018 02:29 PM, R0b0t1 wrote: On Tue, Jul 31, 2018 at 12:30 PM, wrote: i agree completely and asked him about this a week or so ago... Everything is fine here, can the people reporting an issue describe their email client and service provider? that's really weird, then, since

Re: [fpc-devel] @Gareth messages thread

On 07/31/2018 12:14 PM, J. Gareth Moreton wrote: I've sent a message to my ISP to see if that sheds any light. once upon a time, vote with your feet was a valued option... you can easily set up another free email address and use that with a better reader if needed/desired... you never have

Re: [fpc-devel] @Gareth messages thread

On 07/31/2018 06:10 AM, Dimitrios Chr. Ioannidis via fpc-devel wrote: Hi Gareth,   could you please try again to fix the threading for your messages ? he'll have to switch readers or somehow cause the one he's using to properly use and update the References line(s) in the headers... right

Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?

On 07/30/2018 11:35 AM, Michael Van Canneyt wrote: On Mon, 30 Jul 2018, R0b0t1 wrote: It might be hard to imagine FPC taking that much longer than it does currently but ~30min for a large program is the standard with other compilers. I very much enjoy the speed of FPC. > 30 *Minutes*, is this

Re: [fpc-devel] Pure function Wiki page

sorry for this off-topic post but are you aware that your messages are not threading into the topic under discussion? every one of your posts looks like a separate thread and there's nothing to link it to the message you are actually responding to... looking at them, there's no references

Re: [fpc-devel] Debugging Loop Unroll Optimization

On 05/18/2018 11:16 AM, Thorsten Engler wrote: The for-loop variable is undefined after the loop if the loop ran to completion. It retains its last value if the loop exited in a controlled way (goto, break, exit, ?) before running to completion. speaking from the peanut gallery, FWIW, i like

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

On 04/28/2018 09:33 AM, Thorsten Engler wrote: I've attached the source (I'm using Delphi 10.2.3, 64bit to compile it) in case anyone wants to try it out on different cpus and with different alignments (change the {$CODEALIGN 1} and add nops to the XXX1 .. XXX8 procedures to finetune alignment).

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

On 04/28/2018 07:01 AM, Thorsten Engler wrote: The effects of code alignment beyond a granularity of 16 on such short code is interesting: Code address: Frac1: 00536430 (48) Frac2: 00536480 (0) Frac3: 005364D0 (80) Frac4: 00536520 (32) Frac5: 00536570

Re: [fpc-devel] How do I use this compiler now that I have it?

On 11/23/2017 04:19 AM, NetSpirit wrote: Are you shure? How this is possible? I received email from 'fpc-devel [at] lists.freepascal.org' the original post didn't arrive here like that... it arrived here from the list as from "Gina Hansen " Question author can send

Re: [fpc-devel] fpc-devel Digest, Vol 156, Issue 16

On 04/27/2017 01:26 AM, Michael Van Canneyt wrote: 1) Why not call it 3.0.4? I would also think that we should aim at a quick 3.0.4 then. +1 Just a linux i386 version (where the problem is acute) or all platforms ? personally speaking, i would do them all to maintain version consistency

Re: [fpc-devel] Closures / anonymous methods

On 10/25/2016 10:09 AM, bla...@blaise.ru wrote: On 25.10.2016 16:06, Maciej Izak wrote @ http://lists.freepascal.org/pipermail/fpc-devel/2016-October/037375.html : I'd like to take over work on closures/anonymous methods In theory, that is fine by me (the author). However, if I were to

Re: [fpc-devel] FPC V3.0.0 LocalTimeToUniversal() error

On 06/30/2016 06:01 AM, Henry Vermaak wrote: On Wed, Jun 29, 2016 at 05:09:54PM +0100, Henry Vermaak wrote: On Tue, Jun 28, 2016 at 10:56:30AM +0200, Michael Van Canneyt wrote: [...] So the output is correct in trunk, and the bug has been fixed. I expect the fix to be in 3.0.2. It doesn't

Re: [fpc-devel] compiling fixes_3_0

On 06/29/2016 01:51 PM, Sven Barth wrote: Am 29.06.2016 17:16 schrieb : > ok, thanks! that's what i've used this time... can i assume that 3.0.0 should > also be used to build trunk? That is correct. thanks! -- NOTE: No off-list assistance is given without prior

Re: [fpc-devel] FPC V3.0.0 LocalTimeToUniversal() error

On 06/29/2016 12:09 PM, Henry Vermaak wrote: On Tue, Jun 28, 2016 at 10:56:30AM +0200, Michael Van Canneyt wrote: FPC 3.0 indeed contains a bug. This has meanwhile been fixed. If I compile the program with trunk, I get: home: >fpc tt.pp home: >./tt Offset :-120 Local Time :10:53:16 UTC

Re: [fpc-devel] linux bootstraps

On 06/20/2016 11:02 AM, wkitt...@windstream.net wrote: i cannot find binaries of: x86_64-linux-ppcx64 for fpc 2.6.4 x86_64-linux-ppcx64 for fpc 3.0.0 i've looked in ftp://ftp.freepascal.org/pub/fpc/dist/2.6.4/bootstrap/ ftp://ftp.freepascal.org/pub/fpc/dist/3.0.0/bootstrap/

[fpc-devel] compiling fixes_3_0

which starting compiler should be used to build fixes_3_0? 2.6.4 or 3.0.0? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted.

Re: [fpc-devel] FPC V3.0.0 LocalTimeToUniversal() error

On 06/28/2016 03:18 AM, Michael Van Canneyt wrote: On Tue, 28 Jun 2016, Russ Davies wrote: [...] Comparing dateutil.inc for both versions, in functions UniversalTimeToLocal() and LocalTimeToUniversal() the signs of the offsets have been changed Correct. This was in response to some

[fpc-devel] building current trunk

i'm trying to build trunk with my newly minted fpc 3.0.0 but i'm running into the following... [ 53%] Compiled package utils-fprcp Start compiling package utils-h2pas for target x86_64-linux. Executing command "/home/wkitty42/development/fpc/trunk/bin/plex h2pas/scan.l h2pas/sca

[fpc-devel] linux bootstraps

i cannot find binaries of: x86_64-linux-ppcx64 for fpc 2.6.4 x86_64-linux-ppcx64 for fpc 3.0.0 i've looked in ftp://ftp.freepascal.org/pub/fpc/dist/2.6.4/bootstrap/ ftp://ftp.freepascal.org/pub/fpc/dist/3.0.0/bootstrap/ help?? -- NOTE: No off-list assistance is given without prior

Re: [fpc-devel] A bit of background on compilers exploiting signed overflow

On 05/08/2016 04:34 PM, Jonas Maebe wrote: wkitt...@windstream.net wrote: i thought this was a very interesting discussion... https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759de5a7 thanks to john carmack (@ID_AA_Carmack) for retweeting this from Fabian Giesen ‏(@rygorous)... The

[fpc-devel] A bit of background on compilers exploiting signed overflow

i thought this was a very interesting discussion... https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759de5a7 thanks to john carmack (@ID_AA_Carmack) for retweeting this from Fabian Giesen ‏(@rygorous)... -- NOTE: No off-list assistance is given without prior approval.

Re: [fpc-devel] Twice stored record RTTI data

On 03/02/2016 08:22 AM, Maciej Izak wrote: we should do the things in proper way. that can't be explained as "by design". while i do not understand all the deep reasonings and such, i question the "do things in the proper way" comment... who says that delphi is "doing it in the proper way"??

Re: [fpc-devel] Add {$I %DATETIME%}

On 02/23/2016 10:38 AM, Denis Kozlov wrote: On 23 February 2016 at 15:24, > wrote: is there something wrong with what is already available?? Yes, as highlighted in my original post. ahhh... sorry... i missed all that as it

Re: [fpc-devel] Add {$I %DATETIME%}

On 02/23/2016 06:25 AM, Denis Kozlov wrote: Can someone apply the patch for adding %DATETIME%, if there are no objections? is there something wrong with what is already available?? eg: procedure TMyApplication.DisplayVersion; begin writeln; writeln(prog_name + {$IFDEF DEBUG} ' DEBUG' +

Re: [fpc-devel] Program too long ?

On 01/13/2016 05:01 PM, Mathias wrote: I wanted a test following compile 1'000'000x WriteLn. programProject1; begin WriteLn(1); WriteLn(2); // ... WriteLn(100); end. Then breaks the compiler from the following error. $ fpc

Re: [fpc-devel] Program too long ?

On 01/14/2016 11:22 AM, Mark Morgan Lloyd wrote: wkitt...@windstream.net wrote: On 01/13/2016 05:01 PM, Mathias wrote: I wanted a test following compile 1'000'000x WriteLn. Procedure too complex, it requires too many registers Fatal: Compilation aborted Error: /usr/bin/ppcx64 returned an

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 10/13/2015 04:32 AM, Michael Van Canneyt wrote: On Mon, 12 Oct 2015, wkitt...@windstream.net wrote: On 10/12/2015 03:43 PM, Martin Frb wrote: Actually the above does not represent what the actual feature request is about The "else" is to be executed, after the while (even if the while

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 10/13/2015 09:40 AM, Mark Morgan Lloyd wrote: wkitt...@windstream.net wrote: a... my bad... sorry 'bout that... i've been thinking about this, too... 'else' and 'otherwise' mean the same thing... what they seem to be looking for is 'aswell'... foo := 0; while foo < 100 do begin

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 10/12/2015 01:47 PM, Dmitry Boyarintsev wrote: On Mon, Oct 12, 2015 at 1:35 PM, Ralf Quint wrote: Either the while loop is executed or it isn't, depending in the expression. I don't see an actual use case for any else/otherwise extension to it... You probably

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 10/12/2015 02:02 PM, Dmitry Boyarintsev wrote: The next step would probably be controlled "break", where a user would be able to specify how many nested loops needed to broken from. ROTFLMAO! if you need or desire something like that then set a breakcounter and break... in the next outer

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 10/12/2015 03:33 PM, Dmitry Boyarintsev wrote: On Mon, Oct 12, 2015 at 3:11 PM, > wrote: On 10/12/2015 02:02 PM, Dmitry Boyarintsev wrote: The next step would probably be controlled "break", where a user would be

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 10/12/2015 03:43 PM, Martin Frb wrote: Actually the above does not represent what the actual feature request is about The "else" is to be executed, after the while (even if the while looped ZERO times). But it is to be skipped if the while exited via break (and only then). For that reason

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 10/12/2015 04:10 PM, Dmitry Boyarintsev wrote: On Mon, Oct 12, 2015 at 3:47 PM, > wrote: by checking the value that caused the break ;) deity knows i've done it many times before back in the TP/BP 6&7 days... i did it exactly

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 10/12/2015 05:19 PM, Sven Barth wrote: Am 12.10.2015 22:48 schrieb >: > anyway, it seems that no matter what the discussion, it won't make it into the compiler... that according to another post from a compiler dev ;) I said that I'm

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 10/12/2015 06:15 PM, David W Noon wrote: On Mon, 12 Oct 2015 15:11:18 -0400, Wkitty42 (wkitt...@windstream.net) wrote about "Re: [fpc-devel] Fwd: While - Otherwise Statement" (in <561c05d6.4010...@windstream.net>): On 10/12/2015 02:02 PM, Dmitry Boyarintsev wrote: The

Re: [fpc-devel] new features and facilities

On 10/10/2015 07:12 AM, Mark Morgan Lloyd wrote: One thing that bothers me about these approaches is that sooner or later some awkward cuss (such as myself) will start whining about how much better Pascal would be if there were a decent macro preprocessor so that CaseOf() could be specialised

Re: [fpc-devel] Multithreading under DOS

On Thursday, September 26, 2013 1:24 PM, Leif Ekblad l...@rdos.net wrote: DOS extenders are even worse candidates for multitasking than DOS. And if you aim to use 32-bit anyway, I see no reason to use an DOS extender over a real multitasking OS. does that include old systems like PC-MOS?

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

On Monday, September 9, 2013 8:41 AM, Michael Schnell mschn...@lumino.de wrote: I feel like throwing up when I am supposed to use the Term ANSIString for things potentially being encoded as UTF-8, UTF-16 or such, which for me is the contrary of ANSI. i agree... ANSIstrings should be