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

2023-03-02 Thread wkitty42--- via fpc-devel

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?

2023-01-14 Thread wkitty42--- via fpc-devel

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?

2023-01-13 Thread wkitty42--- via fpc-devel

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

2021-08-22 Thread wkitty42--- via fpc-devel

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

2020-06-09 Thread wkitty42

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

2020-06-09 Thread wkitty42

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

2020-05-01 Thread wkitty42

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!

2020-01-29 Thread wkitty42

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

2019-10-12 Thread wkitty42

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

2019-07-12 Thread wkitty42

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.

2019-07-07 Thread wkitty42

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.

2019-07-07 Thread wkitty42

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.

2019-07-06 Thread wkitty42

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.

2019-07-04 Thread wkitty42

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.

2019-07-04 Thread wkitty42

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.

2019-07-03 Thread wkitty42

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

2019-07-01 Thread wkitty42

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.

2019-06-28 Thread wkitty42

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

2019-06-26 Thread wkitty42

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)

2019-06-17 Thread wkitty42

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)

2019-06-17 Thread wkitty42

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)

2019-06-17 Thread wkitty42

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)

2019-06-16 Thread wkitty42

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

2019-06-16 Thread wkitty42

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

2019-06-16 Thread wkitty42

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

2019-05-24 Thread wkitty42

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

2019-05-19 Thread wkitty42

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

2019-05-17 Thread wkitty42

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

2019-05-17 Thread wkitty42

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

2019-03-24 Thread wkitty42

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

2019-03-10 Thread wkitty42

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

2019-02-21 Thread wkitty42

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

2019-02-20 Thread wkitty42

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

2019-02-20 Thread wkitty42

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

2019-01-17 Thread wkitty42

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

2018-12-16 Thread wkitty42

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

2018-12-15 Thread wkitty42

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

2018-12-15 Thread wkitty42

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

2018-12-15 Thread wkitty42

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

2018-12-03 Thread wkitty42

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

2018-11-05 Thread wkitty42

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

2018-11-05 Thread wkitty42

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

2018-11-04 Thread wkitty42

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

2018-09-17 Thread wkitty42

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

2018-08-31 Thread wkitty42

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

2018-08-31 Thread wkitty42

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

2018-07-31 Thread wkitty42

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

2018-07-31 Thread wkitty42

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

2018-07-31 Thread wkitty42

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?

2018-07-30 Thread wkitty42

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

2018-07-09 Thread wkitty42



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

2018-05-18 Thread wkitty42

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

2018-04-28 Thread wkitty42

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

2018-04-28 Thread wkitty42

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?

2017-11-23 Thread wkitty42

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

2017-04-27 Thread wkitty42

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

2016-10-25 Thread wkitty42

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

2016-06-30 Thread wkitty42

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

2016-06-29 Thread wkitty42

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

2016-06-29 Thread wkitty42

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

2016-06-29 Thread wkitty42

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

2016-06-29 Thread wkitty42



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

2016-06-28 Thread wkitty42

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

2016-06-21 Thread wkitty42



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

2016-06-20 Thread wkitty42


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

2016-05-08 Thread wkitty42

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

2016-05-08 Thread wkitty42


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

2016-03-02 Thread wkitty42

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%}

2016-02-23 Thread wkitty42

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%}

2016-02-23 Thread wkitty42

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 ?

2016-01-14 Thread wkitty42

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 ?

2016-01-14 Thread wkitty42

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

2015-10-13 Thread wkitty42

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

2015-10-13 Thread wkitty42

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

2015-10-12 Thread wkitty42

On 10/12/2015 01:47 PM, Dmitry Boyarintsev wrote:

On Mon, Oct 12, 2015 at 1:35 PM, Ralf Quint  wrote:

Either the while loop is executed or it isn't, depending in the expression.
I don't see an actual use case for any else/otherwise extension to it...

You probably 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

2015-10-12 Thread wkitty42

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

2015-10-12 Thread wkitty42

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

2015-10-12 Thread wkitty42

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

2015-10-12 Thread wkitty42

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

2015-10-12 Thread wkitty42

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

2015-10-12 Thread wkitty42

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

2015-10-10 Thread wkitty42

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

2013-09-26 Thread wkitty42

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

2013-09-09 Thread wkitty42

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