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 a noticable difference when in large numbers. It's a German proverb: "Mühsam ernährt sich das Eichhörnchen" The squirrel has a hard time feeding itself Maybe more like "Kleinvieh macht auch Mist" ? Small livestock makes crap too both make sense! LOL -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list where it belongs!* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 "mismatched begin/end" error with the caret pointing to the 2nd begin... -- That's a copy/paste error.by me. The original code had about 10 more function calls and then a closing end for the "with WideStringManager do begin " oh! that would explain it :lol: -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list where it belongs!* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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)); writeln(2); Ansi2WideMoveProc(PChar(ASource), CP_UTF8, UDest, Length(ASource)); //<< test.lpr(24,53) Error: Can't take the address of constant expressions (caret behind UDest) end. 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 "mismatched begin/end" error with the caret pointing to the 2nd begin... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list where it belongs!* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 Common.dll file is only valid for 64bit windows builds, perhaps the better thing to do is to wrap the $linklib line in a check to see if you are building 64bit... if 64bit then loadlib otherwise, noop... seems logical at first glance but the question then is if one can determine the bitness of the current build in progress... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list where it belongs!* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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. *Please keep mailing list traffic on the list where it belongs!* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 write(c); will incur the burden of a low level flush after each iteration. /me has tons of code that does this... especially with logging specifically to ensure that all the logging is actually written to disk in case of a crash which could result in hundreds of lines of logging data being lost... no problems of any kind noted... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list where it belongs!* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 private email of the person I respond to. This also happened when I responded to Michael. when you click where? in what program? i use thunderbird and it has a "reply list" button that is default for most of the mailing lists i am subscribed to... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list where it belongs!* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 list traffic on the list where it belongs!* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 it to be there. wouldn't this depend on the setting of "boolean short circuits"? if they are off/false, then the entire boolean sequence is evaluated... or have i misunderstood something? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 something less harmless. or something much much much worse... they can hide malware in pdf files, ya know... you view the pdf document and don't even know the malware is doing stuff behind your back... Can someone with developer status please remove this? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 been doing a lot of bash, perl, javascript, python3, and other similar coding recently... when i first wrote my message, i had put printf instead of writeln! hahaha! maybe it is just a lack of sleep, though? that or lack of c0ffee :) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 sentence. A fourth sentence. A fifth sentence.`; MultiLine2 = `Sentence one. Another sentence. A third sentence. A fourth sentence. A fifth sentence.`; MultiLine3 = `Sentence one. Another sentence. A third sentence. A fourth sentence. A fifth sentence.`; begin writeln("MultiLine1= '",MultiLine1,"'"); writeln("MultiLine2= '",MultiLine2,"'"); (* i forgot to do the line for MultiLine3 *) writeln("MultiLine3= '",MultiLine3,"'"); (* that's what happens when you write directly in the email editor without testing *) end; begin bar; end; end; -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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, like this: 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 sentence. A fourth sentence. A fifth sentence.`; MultiLine2 = `Sentence one. Another sentence. A third sentence. A fourth sentence. A fifth sentence.`; MultiLine3 = `Sentence one. Another sentence. A third sentence. A fourth sentence. A fifth sentence.`; begin writeln("MultiLine1= '",MultiLine1,"'"); writeln("MultiLine2= '",MultiLine2,"'"); end; begin bar; end; end; ? just asking... can't test... the private procedure is specifically to exhibit various formats and to query what the output would be... intended output in this case is 'Sentence one. Another sentence. A third sentence. A fourth sentence. A fifth sentence. In general though I think that using indentation as an actual "argument" against this is very strange (which I know you were not doing, to be clear.) one person's PrettyPrint format is another's ugly-as-sin ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 and doesn't affect anything else... in the other, the formatting and whitespace are important and affect a lot of things... so yeah, i'm out, too... just too much to farkle around with to make it a viable feature without causing problems of one sort or another... This is like saying "somebody might format a text file in a way that they didn't actually want, and thus, TStringList.LoadFromFile is a bad feature." not really... LoadFromFile already exists and has been fleshed out whereas multiline strings don't... don't get me wrong... i'm not against it if someone wants to develop it but i am stepping back like those VC guys on Shark Tank that invest or not in presented projects hoping to get capital and produce their product or service... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 and special characters. 1. not everyone uses lazarus. 2. an addon to do what has been basic since forever? 3. which whitespace do we keep and which is thrown away? 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 and doesn't affect anything else... in the other, the formatting and whitespace are important and affect a lot of things... so yeah, i'm out, too... just too much to farkle around with to make it a viable feature without causing problems of one sort or another... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 operator overloading! However, I think that it is still rather less clean/readable than what would be possible with "true" unbroken multiline strings. FWIW: it uses the '/' in the traditional *nix form of indicating a line continues on the next line... [edit before shipping] oh! oops! nope... that's the '\' character which i would prefer to see but i do like his operator overload and may swipe it for use with the '\' character some time... it appears to fit perfectly for this task ;) https://www.google.com/search?q=linux+line+continuation+character -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 fcl-web\src\base\fphttpclient.pp:749 #3 READRESPONSEHEADERS(0x15e1c30) at fcl-web\src\base\fphttpclient.pp:854 #4 READRESPONSE(0x15e1c30, 0x15b5dc0, 0x145fdb8, 0, false) at fcl-web\src\base\fphttpclient.pp:1132 #5 DONORMALREQUEST(0x15e1c30, {PROTOCOL = 0x15b5e4c 'http', USERNAME = 0x0, PASSWORD = 0x0, HOST = 0x15b5ecc 'www.w3.org', PORT = 0, PATH = 0x1601c9c '/TR/2002/REC-xmldsig-core'..., this path doesn't look right... should it not be /TR/2002/REC-xmldsig-core-20020212 as specified in the URL you're after? that's the only thing i see off the top... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 reason to use plain-text for mailing list and newsgroup posts ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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... pure pascal? pure assembly? pure gold? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 getting old and rarely dabble in pascal code any more but i still read the mailing lists :) I suggest you to take a look at this: https://wiki.freepascal.org/Object_Oriented_Programming_with_Free_Pascal_and_Lazarus#Free_Pascal_Language_Extensions thanks... i'll try to get by there soon-ish... *this is an example of a traditional record and a traditional object as i think of them... [snip] These would still work as is in FPC. right but are they objects, classes or advanced records? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 > back in the (TP6) day but today they are something quite different... i had to > be very careful when i wrote my satellite TLE management tool because of these > differences... > > > Ehm... TP style objects were already quite different to records back in TP days. yes... what i'm saying is that today's are different and that's what confuses me... You are talking about classes, aren't you? maybe... that's part of the confusion... i'm self taught from TP2... never took any classes for anything computer at all... started with B.A.S.I.C. and a friend showed me asm and pascal... i dropped basic like a hot potato and went all out with asm and pascal... had a nice library of routines in asm but as each new TP came out, fewer and fewer of my homegrown asm routines were needed... eventually i was doing asm blocks in my pascal sources instead of compiling .obj files and linking them in... in the day that i speak of, records were simple static blocks that contained data in a certain defined order... today's records have methods, too, which are more like objects back then... i forget the difference between yesterday's objects and today's... But back in the days the objects were already different from records. right... i wrote my own objects when they were introduced and later extensively used message base objects from Mark May when writing BBS message base tools... some objects had (traditional) records* within them... mksm106.zip 215k MK Source for Msg Access v1.06 - Mark May's Pascal OOP source code to access Squish, Jam, Hudson, *.Msg, and Ezycom message bases. Great for developing BBS utilities. (FW) ftp://sestar.synchro.net/main/PROG/mksm106.zip i started, some time back, to convert the code to FPC but RL and other shite got in the way... 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 getting old and rarely dabble in pascal code any more but i still read the mailing lists :) *this is an example of a traditional record and a traditional object as i think of them... Type JamHdrType = Record Signature: Array[1..4] of Char; Created: LongInt; ModCounter: LongInt; ActiveMsgs: LongInt; PwdCRC: LongInt; BaseMsgNum: LongInt; Extra: Array[1..1000] of Char; End; Const JamSubBufSize = 4000; Type JamSubBuffer = Array[1..JamSubBufSize] of Char; Type HdrType = Record JamHdr: JamMsgHdrType; SubBuf: JamSubBuffer; End; Type JamMsgObj = Object (AbsMsgObj) JM: ^JamMsgType; MsgHdr: ^HdrType; JamIdx: ^JamIdxArrayType; TxtBuf: ^JamTxtBufType; Error: Longint; Constructor Init; {Initialize} Destructor Done; Virtual; {Done} Procedure SetMsgPath(St: String); Virtual; {Set netmail path} Function GetHighMsgNum: LongInt; Virtual; {Get highest netmail msg number in area} Function LockMsgBase: Boolean; Virtual; {Lock the message base} Function UnLockMsgBase: Boolean; Virtual; {Unlock the message base} Function WriteMailIdx(FN: String; MsgPos: Word): Word; Virtual; {Write Netmail or EchoMail.jam} Procedure SetDest(Var Addr: AddrType); Virtual; {Set Zone/Net/Node/Point for Dest} Procedure SetOrig(Var Addr: AddrType); Virtual; {Set Zone/Net/Node/Point for Orig} Procedure SetFrom(Name: String); Virtual; {Set message from} Procedure SetTo(Name: String); Virtual; {Set message to} Procedure SetSubj(Str: String); Virtual; {Set message subject} Procedure SetCost(SCost: Word); Virtual; {Set message cost} Procedure SetRefer(SRefer: LongInt); Virtual; {Set message reference} Procedure SetSeeAlso(SAlso: LongInt); Virtual; {Set message see also} Function GetNextSeeAlso: LongInt; Virtual; Procedure SetNextSeeAlso(SAlso: LongInt); Virtual; Procedure SetDate(SDate: String); Virtual; {Set message date} Procedure SetTime(STime: String); Virtual; {Set message time} Procedure SetLocal(LS: Boolean); Virtual; {Set local status} Procedure SetRcvd(RS: Boolean); Virtual; {Set received status} Procedure SetPriv(PS: Boolean); Virtual; {Set priveledge vs public status} Procedure SetCrash(SS: Boolean); Virtual; {Set crash netmail status} Procedure SetKillSent(SS: Boolean); Virtual; {Set kill/sent netmail status} Procedure SetSent(SS: Boolean); Virtual; {Set sent netmail status} Procedure SetFAttach(SS: Boolean); Virtual; {Set file attach status} Procedure SetReqRct(SS: Boolean); Virtual; {Set request receipt status} Procedure SetReqAud(SS: Boolean); Virtual; {Set request audit status} Procedure
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 satellite TLE management tool because of these differences... Ehm... TP style objects were already quite different to records back in TP days. yes... what i'm saying is that today's are different and that's what confuses me... After all the former supported inheritance and (virtual) methods while the later supported variant parts. in the day that i speak of, records were simple static blocks that contained data in a certain defined order... today's records have methods, too, which are more like objects back then... i forget the difference between yesterday's objects and today's... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 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 satellite TLE management tool because of these differences... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 pass it on back to you... there's no way to turn this off that i've found... they want you to use their interface to read conversations and your sent message is included in there slotted in where it should be... I see my own messages both on the GMail Android app as well as Thunderbird. that's weird... i pull my gmail via pop3 in to my tbird and never get any of my list posts back... i'm on 10+ lists... some with this account and others with my gmail... the gmail account never sends back my messages when i pop them... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 interface to read conversations and your sent message is included in there slotted in where it should be... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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... {20 - is Intel (GenuineIntel) } function getdevel:byte; -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 not... i'm still trying to figure out what "bloat" the OP was talking about :smh: -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 const n=12; const s=1 shl n; P.S. And yes, that mask is also zero-extended to 32-bit or whatever the word size is on the CPU. -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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)) SHR (16-n); (*h1:=c SHR (16-n);*) h2:=((a XOR b)*(a SHL 5+b SHR 2)) AND ((s-1) SHL (16-n)) SHR (16-n); (*h2:=c AND ((s-1) SHL (16-n)) SHR (16-n);*) writeln(h1,',',h2); end. the results of h1 and h2 (they are hashes) are different, and only h2 appears to be correct and inside the range. If we precompute the hash value with c, then both h1 and h2 are the same. Does this is an effect of some multiplication overflow, or is it a bug? Regards, Marco Borsari -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 from fpc trunk: created with fpcmkcfg.exe (from trunk) # searchpath for units and other system dependent things -Fu/units/$fpctarget -Fu/units/$fpctarget/* -Fu/units/$fpctarget/rtl Notice all paths are relative (to what?) none of the paths listed above are relative... they all start with a drive letter and backslash or a slash... relative paths do not start with a drive letter or slash but they may start with ".." -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 sign of laziness and not doing the job properly :lol: -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 constructs unrelated to safety which I think merit examination, also. we already have this, don't we? the biggest problem i see is the lack of proper buffer, stack, and heap checking when folks are developing their programs... i mean if you have a 1024byte destination buffer you're going to fill from another buffer, check how much is in the originating buffer before just blindly copying it over to the destination buffer... not checking for things like that is just lazy... hell, deploy with stack and heap checking enabled... slower? really? with today's machines? it doesn't make that much difference, in the long run... the system will still be waiting 95+% of the time for something to do... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 from data :) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 example is different from e.g. using normally declared "I, J: Integer" and employing "J" as a loop variable? Wouldn't it do the same error anyway? i think he's pointing out the two instances of var I in the code... one at the top and one in the loop... at best that would be a redeclaration defect in the code to me... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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? i still have a lot of TP code here and some of it has been ported to FPC... some of that ported code has been recoded to use getopts which allow a lot of other code to be stripped out because getopts handles command line options much better... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 hard float support. The "V" stands for Vector not Virtual thanks for the correction :) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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: Supported FPU instruction sets: SOFT,LIBGCC,FPA,FPA10,FPA11,VFPV2,VFPV3,VFPV3_D16,FPV4_S16 ok, it just jumped out at me because you had been talking about VFP but this was FPV... and apparently i goofed my above, too... i don't even know which one would be proper... it is just crazy that there are so many but that would be a standard, wouldn't it? :lol: (And yes, such kind of abbrevations is always a bit frustrating to type and check, although it is obviously not fpc's fault) 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... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 ./pp (and others?) be rebuilt so that it does use/allow VFP instructions to be used? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 using a combined mailbox for all accounts? i have multiple accounts here but they are each fully separated... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ 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
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 nothing else will generally speaking get you 90% of the way there most of the time, if not all the way. true to a point... FPC in TP mode has been able to compile most of the old Borland TP demos with zero changes for years now... this is true but some of us used a lot of low level operations that aren't available any more... direct screen writes, low level disk access using FAT tables and BIOS function calls, reading the BIOS area to determine which COM ports are assigned and what their addresses are, etc... It's not even like TP was that different. Generally speaking it's just the same Object Pascal, except with less features. I don't mean to be rude, but I simply fail to see how porting code from it could ever be "daunting." again, it is the number of lines that would lead to that in certain cases... then there's also the complete requirement to unlearn old methods that are still stuck in one's memory... hell, i have a library of code here for working with time and dates... FPC has all that already covered so all that code that i wrote is basically useless now but the newer code is different enough that figuring which routine to use and which parameters need to be changed... ya know? some of us old timers don't live in front of the compilers any more, either... anyway, i just wanted to point out that your statement was using a very broad brush with poor knowledge of the facts (aka limited horizon)... for me, i'm done with this thread now ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ 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
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 "interesting" about TP from a current perspective. At this point it's simply just a notably worse Pascal compiler than FPC, and nothing more. I find it extremely difficult to believe that you're actually claiming there is a non-trivial number of people out there who have /literally/ been actively developing in nothing but Turbo Pascal right up until now, and finally have decided to "modernize", and who will as such actually find that article useful. wow... you talk about "making assumptions" and then you that someone claimed something that no one wrote... no one said anything about any non-trivial number of people using TP... personally speaking, depending on the job, yes, i break out my TP6 (!) for many things... if i need 32/64 bit, then i use FPC/Lazarus... i can also honestly point to several projects that are in the process of being ported from TP to FPC... one is/was an extremely popular FTN mailer used in Fidonet and other Fidonet Technology Networks... and yes, Fidonet does still exist today along with another ~50+ other FTNs ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ 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
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... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 Classes; var Buffer: array[0..255] of Byte; what about Buffer: array[0..255] of Byte = [0]; No, you would need to suppply the full amount of elements. my statement "or similar" should cover that but yeah, i did think about that aspect... it is a solution... just not a ""short hand" one ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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]; would that or something similar work? i do similar in several of my programs but i don't have any arrays in use in them... eg: MyMeanMotnStr : string = ''; MyMeanMotion : double = 0.0; ModeDIAG : boolean = False; obs_location : vector = (0,0,0,0); sstringlen: longint = 0; i know one solution has already been posted but thought of this one earlier when i first read your post... i just delayed in writing this until now :/ -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 none of kit's posts arrive here in my (latest) thunderbird (via pop3, not news) with any Referencces in them... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 had to use your ISP given address ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 now, none of his posts have References lines in them even though the posts he's responding to have them... It's hard to follow your very interesting conversation's without proper list thread support. i agree completely and asked him about this a week or so ago... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 real ? yep, for sufficiently large projects... when we compile OSG (OpenSceneGraph) over here (using -j 8) it takes 20+ minutes for the first time or if we reconfigure from debug to release mode or the other way around... now, after the first time we compile it, the next times takes mere 10's of seconds... then we move on to SceneGear and FlightGear when we're building that whole project which uses OSG... 30-45 minutes for a complete, from the ground up builds are not uncommon... it takes me back to the days of 30 years ago when you'd start the (borland/turbo pascal) compile process and go get some c0ffee ;) note: the machines these builds are being done on have 16Gig RAM, 1Tb HD, and a 4Ghz 8-core AMD FX-8350 CPU... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 line(s) in your headers... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 that verbiage... it is straight forward and clear to understand... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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). FWIW: i tried, with my old lazarus 1.6.1 and fpc 3.0.0, to convert the project to a lazarus project but it aborted with no real indication as to the problem... i didn't try with the (also old) trunk install i have... both are pretty old and i've forgotten how i set it all up with fpcup... so i tried just compiling the lpr that did result from the conversion attempt... it looks to be valid source but the compile also failed... mainly for not being able to find System.Diagnostics... maybe i'll muddle about with it later... i was just curious to see what this AMD FX Black FX8350 4Ghz 8-core CPU running linux would do... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 (112) Frac6: 005365C0 (64) Frac7: 00536610 (16) Frac8: 00536660 (96) [...] The number in () after the address is address mod 128. It's interesting to see that for this particular code (and CPU) the "good" ones are 0, 32, and 96, but NOT 64. I'm sure the results are highly dependent on the CPU. why not 64? the pattern looks to be bad,good,bad,good,bad,good,bad,good but i'm very likely missing something... also, not only highly dependent on the CPU but also on what other processes may be running and consuming some CPU time... i'm not even sure that booting linux to "single" mode would get you a system completely dedicated to one task like in the old DOS world... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 to this list without registration? yes, it has been this way for a long time... you just don't get any responses unless people reply directly to the OP or you specifically trudge through the list looking for replies... Should I repeat answer to original author's address? the post you are replying to said that they were forwarding the response via the CC to the OP... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 everywhere... -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 formally pass the bucket to you, I would like to settle with Scooter Software on my work done thus far. if i/we may ask, what happened to your Patch/hg repository? why did it go away? -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 look like this fix (r31356) has been merged into fixes_3_0, or am I missing something? Thanks Marco for merging it last night. yes! excellent! ./timetest.2.6.4 Offset :240 Local Time :11:44:21 UTC:15:44:21 ./timetest.3.0.0 Offset :240 Local Time :11:44:21 UTC:07:44:21 ./timetest.3.0.1 Offset :240 Local Time :11:44:21 UTC:15:44:21 ./timetest.3.1.1 Offset :240 Local Time :11:44:21 UTC:15:44:21 date --utc Thu Jun 30 15:44:21 UTC 2016 wrong time calculations are very bad for tracking space born objects ;) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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:08:53:16 home: >date --utc Tue Jun 28 08:53:25 UTC 2016 home: >date Tue Jun 28 10:53:29 CEST 2016 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 look like this fix (r31356) has been merged into fixes_3_0, or am I missing something? it doesn't look right over here, either... ./timetest.2.6.4 Offset :240 Local Time :14:50:18 UTC:18:50:18 ./timetest.3.0.0 Offset :240 Local Time :14:50:18 UTC:10:50:18 ./timetest.3.0.1 Offset :240 Local Time :14:50:18 UTC:10:50:18 ./timetest.3.1.1 Offset :240 Local Time :14:50:18 UTC:18:50:18 date --utc Wed Jun 29 18:50:18 UTC 2016 -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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/ help?? i can't believe that there has not been one single response to this in nine days :( -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 bugreports. IMO the offset should be 120, not -120. so GetLocalTimeOffset() is wrong and has been for a long time?? cat ~/development/fpc/2.6.4/rtl/unix/sysutils.pp cat ~/development/fpc/3.0.0/rtl/unix/sysutils.pp cat ~/development/fpc/fixes_3_0/rtl/unix/sysutils.pp function GetLocalTimeOffset: Integer; begin Result := -Tzseconds div 60; end; -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[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/scan.pas" The installer encountered the following error: External command "/home/wkitty42/development/fpc/trunk/bin/plex h2pas/scan.l h2pas/scan.pas" failed with exit code 256. Console output: TP Lex Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef FATAL: cannot open file /usr/lib/fpc/lexyacc/yylex.cod make[2]: *** [all] Error 1 make[2]: Leaving directory `/home/wkitty42/development/fpc/trunk/utils' make[1]: *** [utils_all] Error 2 make[1]: Leaving directory `/home/wkitty42/development/fpc/trunk' make: *** [build-stamp.x86_64-linux] Error 2 make: Leaving directory `/home/wkitty42/development/fpc/trunk' i understand why it cannot find and open that file... it doesn't exist as there is no system-wide installation of fpc... there's only my user installed ones in my home directory... to get here, i've just built release_2.6.4 (using the release_2.6.2 compiler) and release_3.0.0 (using my newly built release_2.6.4 compiler)... i have also compiled fixes_3_0 (with my newly built release_3.0.0 compiler)... once i worked out the proper order, this all worked fine with no problems... each of these is in their own directory... eg: ~/development/fpc/2.6.4 ~/development/fpc/3.0.0 ~/development/fpc/fixes_3_0 ~/development/fpc/trunk now i'm trying to build trunk (3.1.1) and i'm having the above problem that i've never seen before... how can i fix it? do i need to install a ubuntu package for lex or something? or perhaps just creating a link for the file and point the link to the existing ~/development/fpc/trunk/utils/tply/yylex.cod?? probably also need one for yyparse.cod?? kubuntu 14.04.4 LTS -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[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 approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 point is kind of irrelevant in case of FPC, because overflows (signed or unsigned) are not undefined here. Every type is guaranteed to exhibit the behaviour defined by 2's complement for its particular byte size. ahhh... i was kinda hoping that this would be the case... if it weren't, maybe a li'l something to bring it to the attention of the devs... strong typing for the win, again! :) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[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. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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"?? as long as delphi compatibility up to version X is supported, FPC can do things in their own fashion and still be ""proper""... even if it means aliasing certain functions to conform to delphi's methods ;) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 appeared similar to a signature over here... On 15 January 2016 at 21:23, Denis Kozlov wrote: Benefits of this directive: 1) Access to build date/time in native TDateTime format. Existing {$I %DATE%} and {$I %TIME%} are inserted as strings in predefined format, parsing is required to extract date/time components or to reformat it. is there a problem using sysutils' StrToDateTime() to convert to TDateTime? parsing is already done for you... program compilerdatetime; uses sysutils; var formatSettings : TFormatSettings; compiledatetime: TDateTime; compiledatetimestr : string; begin formatSettings := DefaultFormatSettings; formatSettings.DateSeparator := '/'; formatSettings.ShortDateFormat := '/mm/dd'; formatSettings.ShortTimeFormat := 'hh:nn:ss'; writeln('DateTime Format : ',formatSettings.ShortDateFormat,' ',formatSettings.ShortTimeFormat); compiledatetimestr := {$I %DATE%} + ' ' + {$I %TIME%}; writeln('raw string : ',compiledatetimestr); compiledatetime := StrToDateTime(compiledatetimestr,formatSettings); writeln('TDateTime : ',compiledatetime); writeln('converted to str: ',DateTimeToStr(compiledatetime,formatSettings)); end. TBH: i see and understand why this might be a good idea but i also see and understand why it is not desirable... for me, though, there are many times that i hex browse binaries to find such compiled on strings... using a floating point number for them doesn't allow such ease of finding this data... we won't mention the additional conversion needed to print it when the current method building with %DATE% and %TIME% are already strings... but of course there is the same need to convert to TDateTime if one wants to ""time bomb"" their binary so that it doesn't work after some period of time (eg: expiring beta, limited time evaluation, simple aging out of old versions)... 2) Atomic access to build date/time. Use of {$I %DATE%} and {$I %TIME%} can have undesired effect if {$I %DATE%} is executed at 2016-01-15 23:59:59.999 and 1 ms later {$I %TIME%} is executed at 2016-01-16 00:00:00.000. Resulting combination of two directive is 2016-01-15 00:00:00, a day out of date. i recognize this race-type condition but it really won't come up that often to be bothersome, will it? 3) Search and replace of build date/time is no longer a trivial text editor operation. i haven't used that method in years... definitely not since i figured out how to embed them in TP6 code ;) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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' + {$ENDIF} ' version ' + prog_ver + ' [' + {$I %DATE%} + ' ' + {$I %TIME%} + ']'); writeln('Compiled with FPC ' + {$I %FPCVERSION%} + ' for ' + {$I %FPCTARGETOS%} + ' running on ' + {$I %FPCTARGETCPU%}); writeln; end; -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 pascaltest.pas Free Pascal Compiler version 3.1.1 [2016/01/07] for x86_64 Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for x86-64 Compiling pascaltest.pas pascaltest.pas(7282,3) Fatal: Procedure too complex, it requires too many registers Fatal: Compilation aborted Error: /usr/bin/ppcx64 returned an error exitcode wowowow... is there something wrong/bad with a short routine? program Project1; var loopcounter : longint; begin for loopcounter := 1 to 100 do writeln(loopcounter); end. -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 error exitcode wowowow... is there something wrong/bad with a short routine? OTOH it's very easy to end up with enormous functions- or even an enormous main block- if machine-generating source by e.g. macro expansion. now that you mention it, i do have a machine generated routine in one of my apps... it was much easier to write code to generate all of the individual case statements for the bit checking than to try to manually write all of them and not typo anything... it started as tri-state for 5 sets of vars and was reduced to bi-state for those 5 sets after a huge epiphany... we ended up with 1024 case values to check instead of something over 18000... I've come across some text-processing tools which were built like this... typically via antique FORTRAN which lacked functions to get unhappy about :-) O:-) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 looped ZERO times). But it is to be skipped if the while exited via break (and only then). For that reason "else" or "otherwise" are badly chosen keywords. Because they imply a different function. exactly my and others' points... "and" would be better but then one might just as easily use a goto to jump around that part if break was used to get out of the loop... 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 ;) Maybe my remark was not clear. I'm not against this *functionality*. I merely pointed out that *the syntax using 'else'* is not going to make it because it breaks backwards compatibility. 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 inc(foo); end; aswell begin dec(foo); end; either 'aswell' or 'aswellas'... while foo is less than 100 increment foo as well as decrement foo when it is no longer less than 100... i don't see a need for it because in this case if one wants foo to only get to 99, then they should use 99 as their count... foo := 0; while foo < 99 do begin inc(foo); end; at the end of the loop, foo will equal 99... but it is also a very simple example... If another keyword is used: no problem. ok... I don't understand why anyone would want this marginal functionality and thus (again) needlessly complicates the language, but hey, it's a (mostly) free world Alas, the monstrosity that Object Pascal syntax is becoming is less and less appealing by the day, it's simply frightening... it seems that way... but it doesn't mean that we have to use it... we can stay with the traditional ways and means within whatever it becomes as long as they don't change with these undesirable extensions... -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 inc(foo); end; aswell begin dec(foo); end; either 'aswell' or 'aswellas'... while foo is less than 100 increment foo as well as decrement foo when it is no longer less than 100... If somebody really has to do this wouldn't "also" be a better choice to avoid (getting close to overloading "as"? :-/ it might... i don't know anything about "as" because i've never used it... what does it do? -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 Quintwrote: 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 want to reread python while-else implementation. (https://docs.python.org/2/reference/compound_stmts.html) "Else" becomes sort of "part of the loop". Thus if you break out of the loop, "else" would not be executed. However, if no break occurs "else" part would be executed. that just doesn't make grammatical sense... foo := 0; while foo < 100 do inc(foo); else dec(foo); end so, if foo is less than 100 we inc(foo)... if foo is not less than 100 we dec(foo)... that's the only way that an "else" can be read... either the boolean is true or /else/ it is false... only if it is false can the else portion be executed... (#2) but then the question is does dec(foo) execute only once or does it execute as long as foo is greater than 100?? what i seem to see is pure laziness of a sort... folks too lazy to write an "if" or "if/else" statement and put the while inside... foo := 0; if foo < 100 then while foo < 100 do inc(foo); else dec(foo); OR depending on the answer of (#2) above... foo := 0; if foo < 100 then while foo < 100 do inc(foo); while foo > 100 do dec(foo); or maybe this is the actual intent? foo := 0; if foo < 100 then while foo < 100 do inc(foo); if foo > 100 then dec(foo); seems like a pretty tough way to have foo equal to 99, eh? ;) It might be a rare case where it's needed. (I cannot think of any), but to achieve exactly the same functionality in Pascal either of two options should be used. 1) make an extra check if break occurred. [...] 2) use goto! :) neither is needed at all in most cases and then not if they have proper logic in place ;) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 block, check breakcounter to see if you need to break again... if so, dec(breakcounter) and break... then check it again in the next outer block... and so on and so on until breakcounter=0... why should the compiler have to do your logic work for you? ;) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 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 block, check breakcounter to see if you need to break again... if so, dec(breakcounter) and break... then check it again in the next outer block... and so on and so on until breakcounter=0... why should the compiler have to do your logic work for you? ;) How would you know if a nested loop finished properly or broke out? ...Just imagine yourself a 4 nested for loops and you need to break out from the 4th to the 1st? 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 as described, too... we had to do it that way as there is/was no other way to do it ;) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 "else" or "otherwise" are badly chosen keywords. Because they imply a different function. exactly my and others' points... "and" would be better but then one might just as easily use a goto to jump around that part if break was used to get out of the loop... 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 ;) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 as described, too... we had to do it that way as there is/was no other way to do it ;) That's exactly the thing. You didn't have a cross-loop break, that's why you've to have some guaranteed values that would allow you to verify if a loop was broken or not. yeah... i implemented my needed logic for that type of scenario... just like any good programmer can/will/should do... If it was broken then you'd set any additional conditions (if needed) to break out another loop and pass it above. In the end you end-up having additional break condition checks in each loop. Just by the fact, that a language doesn't provide you with any other means to do it less complex. ok... so instead we'll have the compiler perform my business logic for me? no thanks... the compiler has enough to do already ;) I'd also need to note, that no other language, to my knowledge, have cross-loop breaks anyway :) Good-old language (Pascal / C /C++) still have goto though... but we won't use it, right? that's right... i think i may have used goto once in 30 years or however long it has been available in pascal... i started self-taught with basic... goto and gosub all over the place... tough as hades to follow the code and no apparent logical layout... i was ecstatic when a friend turned me on to pascal and asm... i dropped basic like a hot potato[e?] and never looked back... especially never looking back at goto ;) ;) ;) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 not sure. it wasn't you that made that statement but if you are willing to add it, i guess maybe it will make it ;) Right now I'm considering that mostly as way for the author to learn about the ways to extend the compiler and what would be needed for a feature patch to be accepted. that's great! it can be a tough row to hoe learning what the proper workflow is when contributing to any project... Whether this specific feature would be added or not is a different topic. +1 -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 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 block, check breakcounter to see if you need to break again... if so, dec(breakcounter) and break... then check it again in the next outer block... and so on and so on until breakcounter=0... why should the compiler have to do your logic work for you? ;) Hi Mark, hiya dave!! it has been a long time, my friend!! You might have seen me write things like this in the old OS2PROG echo of Fidonet some 20+ years ago. ... :-) oh yeah! that echo still exists, too... but it only contains monthly moderator postings these days... it is ready for you any time you want to join back in... nntp access is available via some systems but the dawg grows older with each passing year :? The only language I know that offers that level of control is PL/I, where the break statement is coded as LEAVE. It is handled by labelling the loop control statement and coding the required label in the LEAVE statement. For example: that looks very much like what some would consider goto statements... does the leave return to the top of the previous loop or does it drop to the next statement in the previous loop? If the label is omitted then the immediately containing loop is left. "immediately containing loop" meaning loop_3 if we're in loop_3? This allows any of the nested loops to be escaped, potentially all the way out. I guess the corresponding syntax in a Pascal-esque style would be: that does look interesting for breaks and i can see how it may be beneficial and save some bit of coding but then those of us who have been around a while know how to work our way back out when necessary, right? ;) If we're being strictly Pascal, the labels would need to be declared at the head of the procedure -- and if we're really strict they should be numeric. yup! and i did catch the THEH->THEN oops... no problems there O:) -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 into other forms expressing choice :-/ [aside] years ago when i was working with TP3 and then later TP/BP6&7, i wrote a macro preprocessor for use with my code... basically i coded in .tpl (template) files where i needed macros and then my preprocessor would read the .tpl files and output .pas or .inc files with the macros altered to the real desired data... i did this especially with the date and time of the compile so that it was included in the binary and could be displayed when desired... there were other use cases where this came in very handy... unfortunately it was a down'n'dirty tool that needed to be customized for each project i worked on... i've no clue where that code is today :( [/aside] -- 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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? ok, maybe it wasn't 32bit but it was multi-user multi-tasking and ran many DOS programs without problem... we ran one of our dBaseIII/IV/Foxbase (before m$ got hold of it) accounting packages on PC-MOS and i used PC-MOS as a development environment for other similar dB/FB development... it was especially easy to watch code running on one wyse terminal while feeding data on from another terminal and debugging on the main terminal... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 ANSI only... UTF8string and UTF16string should be available and used where necessary, IMHO... this would seemingly allow for better control as well as string conversion where necessary... speaking of conversions, i would also like to see where UTF8 and similar strings can convert to (eg) CP437 where UTF characters like the trademark symbol are converted to their CP437 four character equivalent (eg) (tm)... registered and copyright symbols are similar... there are other sequences that can also be transliterated to multiple CP437 characters (eg) ae but these are language specific apparently... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel