Re: [fpc-devel] Now sure why this raises Runtime Error 216
Ok, I'll check it out. Thanks guys, did not realize it was a pointer, too
many years writing scripts instead of code. Thanks!!
On Thu, Jan 6, 2022, 11:51 PM Michael Van Canneyt
wrote:
>
>
> On Thu, 6 Jan 2022, Ozz Nixon via fpc-devel wrote:
>
> > Procedure Make_Language_File(
> > Description,MenuPath,TextPath,QuestPath:String;
> > Enabled:Boolean;SecurityLevel:Byte;Flags:Longint);
> > Var
> > FileSize:Longint;
> >
> > Begin
> > Writeln('Language_File empty size is ',SizeOf(L));
> > FileSize:=0;
> > Description:=Description+#0;
> > Inc(FileSize,Length(Description));
> > MenuPath:=MenuPath+#0;
> > Inc(FileSize,Length(MenuPath));
> > TextPath:=TextPath+#0;
> > Inc(FileSize,Length(TextPath));
> > QuestPath:=QuestPath+#0;
> > Inc(FileSize,Length(QuestPath));
> > SetLength(L.Description,Length(Description));
> > SetLength(L.MenuPath,Length(MenuPath));
> > SetLength(L.TextPath,Length(TextPath));
> > SetLength(L.QuestPath,Length(QuestPath));
> > Move(Description[1],L.Description,Length(Description));
>
> This code is wrong. That must be
>
> Move(Description[1],L.Description[0],Length(Description));
>
> > Move(MenuPath[1],L.MenuPath,Length(MenuPath));
>
> Same here.
> Move(MenuPath[1],L.MenuPath[0],Length(MenuPath));
>
> > Move(TextPath[1],L.TextPath,Length(TextPath));
>
> Same here
> Move(TextPath[1],L.TextPath[0],Length(TextPath));
>
> > Move(QuestPath[1],L.QuestPath,Length(QuestPath));
>
> Same here.
> Move(QuestPath[1],L.QuestPath[0],Length(QuestPath));
>
> These fields are dynamic arrays, in essence pointers to a memory block.
>
> Your code writes to the memory area for pointer, not to the memory area
> the pointer points to.
>
> Michael.
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Now sure why this raises Runtime Error 216
Just incase someone needs to know: (public release, not a custom build).
Free Pascal Compiler version 3.0.4 [2017/10/06] for i386
Copyright (c) 1993-2017 by Florian Klaempfl and others
C:\FPC\3.0.4\bin\i386-Win32\fpc.exe [options] [options]
On Thu, Jan 6, 2022 at 6:50 PM Ozz Nixon wrote:
> Without SetLength(var,0) at the end I get Runtime Error 216 once, adding
> those - assuming FPC now required me to zero out those fields, I now get
> the error twice.
>
> Code:
> Program MakePrompts;
>
> Type
>Language_File = Record
> Description:Array of Char; {null terminated string}
> Enabled:Boolean;
> SecurityLevel:Byte;{zero to 255, 255 is reserved for SYSOP}
> Flags:Longint; {32 Flags - A..Z,1..6}
> MenuPath:Array of Char;
> TextPath:Array of Char;
> QuestPath:Array of Char;
>End;
>
> Var
>L:Language_File;
>
> Procedure Make_Language_File(
>Description,MenuPath,TextPath,QuestPath:String;
>Enabled:Boolean;SecurityLevel:Byte;Flags:Longint);
> Var
>FileSize:Longint;
>
> Begin
>Writeln('Language_File empty size is ',SizeOf(L));
>FileSize:=0;
>Description:=Description+#0;
>Inc(FileSize,Length(Description));
>MenuPath:=MenuPath+#0;
>Inc(FileSize,Length(MenuPath));
>TextPath:=TextPath+#0;
>Inc(FileSize,Length(TextPath));
>QuestPath:=QuestPath+#0;
>Inc(FileSize,Length(QuestPath));
>SetLength(L.Description,Length(Description));
>SetLength(L.MenuPath,Length(MenuPath));
>SetLength(L.TextPath,Length(TextPath));
>SetLength(L.QuestPath,Length(QuestPath));
>Move(Description[1],L.Description,Length(Description));
>Move(MenuPath[1],L.MenuPath,Length(MenuPath));
>Move(TextPath[1],L.TextPath,Length(TextPath));
>Move(QuestPath[1],L.QuestPath,Length(QuestPath));
>L.Enabled:=Enabled;
>L.SecurityLevel:=SecurityLevel;
>L.Flags:=Flags;
>Inc(FileSize,6);
>Writeln('Language_File size is ',FileSize);
>SetLength(L.Description,0);
>SetLength(L.MenuPath,0);
>SetLength(L.TextPath,0);
>SetLength(L.QuestPath,0);
> End;
>
> Begin
>Make_Language_File('English (c) 2022 by Ozz
> Nixon','%ROOTPATH%\MENUS\','%ROOTPATH%\TXTFILES\','%ROOTPATH%\QUESTION\',True,0,0);
> End.
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Now sure why this raises Runtime Error 216
Without SetLength(var,0) at the end I get Runtime Error 216 once, adding
those - assuming FPC now required me to zero out those fields, I now get
the error twice.
Code:
Program MakePrompts;
Type
Language_File = Record
Description:Array of Char; {null terminated string}
Enabled:Boolean;
SecurityLevel:Byte;{zero to 255, 255 is reserved for SYSOP}
Flags:Longint; {32 Flags - A..Z,1..6}
MenuPath:Array of Char;
TextPath:Array of Char;
QuestPath:Array of Char;
End;
Var
L:Language_File;
Procedure Make_Language_File(
Description,MenuPath,TextPath,QuestPath:String;
Enabled:Boolean;SecurityLevel:Byte;Flags:Longint);
Var
FileSize:Longint;
Begin
Writeln('Language_File empty size is ',SizeOf(L));
FileSize:=0;
Description:=Description+#0;
Inc(FileSize,Length(Description));
MenuPath:=MenuPath+#0;
Inc(FileSize,Length(MenuPath));
TextPath:=TextPath+#0;
Inc(FileSize,Length(TextPath));
QuestPath:=QuestPath+#0;
Inc(FileSize,Length(QuestPath));
SetLength(L.Description,Length(Description));
SetLength(L.MenuPath,Length(MenuPath));
SetLength(L.TextPath,Length(TextPath));
SetLength(L.QuestPath,Length(QuestPath));
Move(Description[1],L.Description,Length(Description));
Move(MenuPath[1],L.MenuPath,Length(MenuPath));
Move(TextPath[1],L.TextPath,Length(TextPath));
Move(QuestPath[1],L.QuestPath,Length(QuestPath));
L.Enabled:=Enabled;
L.SecurityLevel:=SecurityLevel;
L.Flags:=Flags;
Inc(FileSize,6);
Writeln('Language_File size is ',FileSize);
SetLength(L.Description,0);
SetLength(L.MenuPath,0);
SetLength(L.TextPath,0);
SetLength(L.QuestPath,0);
End;
Begin
Make_Language_File('English (c) 2022 by Ozz
Nixon','%ROOTPATH%\MENUS\','%ROOTPATH%\TXTFILES\','%ROOTPATH%\QUESTION\',True,0,0);
End.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Just wanted to share...
As some of you who know me, know I wrote all kinds of interpreter and pcode compilers. Last night I decided to compile my latest engine in delphi. I ran a script that does over 18 million double = double + 0.5 Fpc build takes 1m 26.8s Delphi takes over 15min... I have up and walked away, when I came back after it had been 30min it had finished. Good work guys!! Delphi exe was about 100k smaller, but fpc smacked delphi around like a Lil B!!! On Thu, Dec 23, 2021, 6:16 AM Ryan Joseph via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Thank you for continuing work on this, we all really appreciate your > efforts. > > > On Dec 23, 2021, at 1:16 AM, Blaise--- via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > 1) The attached metaclass_meth_to_procvar-1.patch fixes the internal > error reported for: > > Regards, > Ryan Joseph > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature request/discussion - SetLengthNoInit
Then, I would suggest it gets bolted into strutils, or sysutils. There are many good reasons to optimize Setlength(), especially for script authors :-) Currently, I am working (learning) Alpha Controls (alphaskins), and trying to find a fit into FCL/LCL, or Graeme's GUI. And if I tweak too much, things forget to draw - so I understand avoiding "core" bloat. But, Isn't that what SYSUTILs is for :-) Ozz On Wed, Sep 16, 2020 at 11:33 PM J. Gareth Moreton via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Ah yes, that works, thanks. > > I feel a bit silly because I haven't explored these useful features as > much as I should, possibly because assembly language isn't object oriented! > > I think the difficulty with getting things like this approved is that it > crosses into the realm of defining the language itself. I can't say I > speak on behalf of Florian or Jonas, but I sense they want to avoid > feature bloat that became a bit of an issue with Delphi. > > Gareth aka. Kit > > On 17/09/2020 04:03, Ryan Joseph via fpc-devel wrote: > > > >> On Sep 17, 2020, at 9:59 AM, J. Gareth Moreton via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> > >> type generic TMyArray = record > >>Data: ^T; > >>Length: PtrUInt; > >> end; > >> > >> The compiler will complain about T being an unresolved forward > declaration. Outside of specifying a second parameter for the pointer type > (which would be a little unfriendly for third-party users), there isn't > really a way around this. > >> > > To be clear all the features work but it's not as optimized as dynamic > arrays and could be cumbersome with arrays of records. > > > > I think you're supposed to redeclare a pointer to T: > > > > type generic TMyArray = record > >type > > TP = ^T; > >public > > Data: TP; > > Length: PtrUInt; > > end; > > > > > > Regards, > > Ryan Joseph > > > > ___ > > fpc-devel maillist - fpc-devel@lists.freepascal.org > > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > > > > -- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console problem in Lazarus trunk
Probably not your issue - but, if you have Avasta Anti-Virus - it can foobar Lazarus and Delphi console apps - where the Console is showing, but you cannot find it. Not on Taskbar, not in TaskList, etc. If you put an exclusion on your binary folder, then it works. Took me about 2 days to figure this out. On Sat, Jul 25, 2020 at 1:41 PM J. Gareth Moreton wrote: > Hi everyone, > > This is likely due to something peculiar in my configuration that I > haven't found yet, but I can't be sure. I'm having problems in that the > latest Lazarus trunk won't create a console window when I'm running the > compiler source in the debugger. I tried to jury-rig it to create its > own using the AllocConsole() Windows API function as a temporary > workaround, but it failed with an "access denied" error. The little I > could find on that error implies that the application already has a > console, but it's not displayed. Anyone got any ideas? > > Gareth aka. Kit > > > -- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows Console App
Lol. That is not being done on purpose.
To do it on purpose there are different ways depending upon your OS -
windows I assume?
keybd_event(Ord('A'), 0, KEYEVENTF_KEYDOWN, 0);
keybd_event(Ord('A'), 0, KEYEVENTF_KEYUP, 0);
* Common mistake is to call it once, it must be both for it to
register. (this is from some OLD code)... looking at FPC's site -
keybd_event is deprecated.
This pay work:
https://wiki.freepascal.org/MouseAndKeyInput
KeyInput.Apply([ssCtrl]);
KeyInput.Press(VK_F1);// This will simulate press of
F1 function key.
KeyInput.Unapply([ssCtrl]);
** Uses: MouseAndKeyInput, LCLType,
FROM LAZARUS being installed.
On Sun, Apr 26, 2020 at 4:41 AM Gerhard Scholz wrote:
> (laughter)
>
> I know how to write console apps; I even know how to start them :-)
> {I have no experience with GUI progarms, but that's another story :-( }
>
> No, my question was: how did you put the "D" in the keyboard buffer? I
> would
> like to put out the next command
>
>
> - Original Message -
> From: Ozz Nixon
> To: Gerhard Scholz
> Cc: FPC developers' list
> Sent: Sunday, April 26, 2020 8:31 AM
> Subject: Re: [fpc-devel] Windows Console App
>
> Sure! I assume you are asking how to make a console app?
>
> You do not need {$APPTYPE CONSOLE} ... instead, you simply write your code
> like normal:
>
> Program example;
>
> Uses
>CRT;
>
> Begin
>ClrScr;
>Writeln('Wassup?!');
>Readln;
> End.
>
> then in the command prompt (any OS), simply fpc example then
> .\example, or ./example - depending upon your OS... voila. "Console
> App"
> now, that is not a DOS 16bit APP... that requires other mess, and since I
> own Turbo Pascal 7.0 source, I have my own TP 32bit compiler that produces
> TP 7 compatible 16bit Units and Apps. ;-)
>
>
> @ you can get me at ozzni...@gmail.com if you need any help (I do not
> normally code GUI apps - money in the Legacy market) so I have made a wide
> range of solutions. This email was started because of something odd on
> Windows recently for me...
>
>
>
> Ozz
>
>
> On Sun, Apr 26, 2020 at 1:27 AM Gerhard Scholz wrote:
>
> Hi,
>
> I would like to know how you did that since it was exactly what I was
> searchomg for a while ago...
>
> Could you send me a piece of code?
>
> Greetings
>
> Gerhard
>
>
> - Original Message -
> From: Ozz Nixon via fpc-devel
> To: FPC developers' list
> Cc: Ozz Nixon
> Sent: Sunday, April 26, 2020 2:21 AM
> Subject: [fpc-devel] Windows Console App
>
>
> Anyone ever experience making a console app (cross-platform), but, on
> windows when the app finishes, it appears to have put an uppercase C or D
> in
> the keyboard buffer, so the Prompt now has C:\>D ???
>
>
> Every time I run my app, be it show help screen and end, or actually
> execute - when it finishes I end up with a letter sitting at the prompt. (A
> few months ago, I was having a problem, and it was related to compiling all
> of the methods with cdecl. That build would leave a stray "C" at the start
> of the prompt upon exiting. Now, I ran into a new problem where I needed to
> recompile with -FcUTF8 to track down which units it thought were having a
> UTF-8 mismatch... it was showing the wrong unit until I used the -FcUTF8
> compile option, then it actually showed what file had ''
> strings ... so I switched to # and it compiles, but, the
> prompts have "D" at the start of them now.(hopefully I described that
> understandable).
>
>
> Environment: Windows XP 32bit
> C:\FPC\3.0.4\bin\i386-Win32\fpc.exe
>
>
>
> If no one else has experienced/has a solution, I will sit down and bang out
> test cases until I find what combination (units, code, whatever) is
> producing this result.
>
>
> Ozz
>
>
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows Console App
I will check your suggestions Alexander. Checked the code, it does if paramcount=0 then show help, then exit from main begin/end. It does not interact with the keyboard unless instructed to (its a pascal script engine). On Sun, Apr 26, 2020 at 3:28 AM Alexander Grotewohl wrote: > you're not using the crt unit are you? first because i think it doesn't > support utf8 and second because i think you can cause this by doing "if > keypressed.." without then doing readkey before exit. > > -- > Alexander Grotewohl > https://dcclost.com > ---------- > *From:* fpc-devel on behalf of > Ozz Nixon via fpc-devel > *Sent:* Saturday, April 25, 2020 8:21:13 PM > *To:* FPC developers' list > *Cc:* Ozz Nixon > *Subject:* [fpc-devel] Windows Console App > > Anyone ever experience making a console app (cross-platform), but, on > windows when the app finishes, it appears to have put an uppercase C or D > in the keyboard buffer, so the Prompt now has C:\>D ??? > > Every time I run my app, be it show help screen and end, or actually > execute - when it finishes I end up with a letter sitting at the prompt. (A > few months ago, I was having a problem, and it was related to compiling all > of the methods with cdecl. That build would leave a stray "C" at the start > of the prompt upon exiting. Now, I ran into a new problem where I needed to > recompile with -FcUTF8 to track down which units it thought were having a > UTF-8 mismatch... it was showing the wrong unit until I used the -FcUTF8 > compile option, then it actually showed what file had '' > strings ... so I switched to # and it compiles, but, the > prompts have "D" at the start of them now.(hopefully I described that > understandable). > > Environment: Windows XP 32bit > C:\FPC\3.0.4\bin\i386-Win32\fpc.exe > > If no one else has experienced/has a solution, I will sit down and bang > out test cases until I find what combination (units, code, whatever) is > producing this result. > > Ozz > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows Console App
Sure! I assume you are asking how to make a console app?
You do not need {$APPTYPE CONSOLE} ... instead, you simply write your code
like normal:
Program example;
Uses
CRT;
Begin
ClrScr;
Writeln('Wassup?!');
Readln;
End.
then in the command prompt (any OS), simply fpc example then
.\example, or ./example - depending upon your OS... voila. "Console
App" now, that is not a DOS 16bit APP... that requires other mess, and
since I own Turbo Pascal 7.0 source, I have my own TP 32bit compiler that
produces TP 7 compatible 16bit Units and Apps. ;-)
@ you can get me at ozzni...@gmail.com if you need any help (I do not
normally code GUI apps - money in the Legacy market) so I have made a wide
range of solutions. This email was started because of something odd on
Windows recently for me...
Ozz
On Sun, Apr 26, 2020 at 1:27 AM Gerhard Scholz wrote:
> Hi,
>
> I would like to know how you did that since it was exactly what I was
> searchomg for a while ago...
>
> Could you send me a piece of code?
>
> Greetings
>
> Gerhard
>
>
> - Original Message -
> From: Ozz Nixon via fpc-devel
> To: FPC developers' list
> Cc: Ozz Nixon
> Sent: Sunday, April 26, 2020 2:21 AM
> Subject: [fpc-devel] Windows Console App
>
>
> Anyone ever experience making a console app (cross-platform), but, on
> windows when the app finishes, it appears to have put an uppercase C or D
> in
> the keyboard buffer, so the Prompt now has C:\>D ???
>
>
> Every time I run my app, be it show help screen and end, or actually
> execute - when it finishes I end up with a letter sitting at the prompt.
> (A
> few months ago, I was having a problem, and it was related to compiling
> all
> of the methods with cdecl. That build would leave a stray "C" at the start
> of the prompt upon exiting. Now, I ran into a new problem where I needed
> to
> recompile with -FcUTF8 to track down which units it thought were having a
> UTF-8 mismatch... it was showing the wrong unit until I used the -FcUTF8
> compile option, then it actually showed what file had ''
> strings ... so I switched to # and it compiles, but, the
> prompts have "D" at the start of them now.(hopefully I described that
> understandable).
>
>
> Environment: Windows XP 32bit
> C:\FPC\3.0.4\bin\i386-Win32\fpc.exe
>
>
>
> If no one else has experienced/has a solution, I will sit down and bang
> out
> test cases until I find what combination (units, code, whatever) is
> producing this result.
>
>
> Ozz
>
>
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Windows Console App
Anyone ever experience making a console app (cross-platform), but, on windows when the app finishes, it appears to have put an uppercase C or D in the keyboard buffer, so the Prompt now has C:\>D ??? Every time I run my app, be it show help screen and end, or actually execute - when it finishes I end up with a letter sitting at the prompt. (A few months ago, I was having a problem, and it was related to compiling all of the methods with cdecl. That build would leave a stray "C" at the start of the prompt upon exiting. Now, I ran into a new problem where I needed to recompile with -FcUTF8 to track down which units it thought were having a UTF-8 mismatch... it was showing the wrong unit until I used the -FcUTF8 compile option, then it actually showed what file had '' strings ... so I switched to # and it compiles, but, the prompts have "D" at the start of them now.(hopefully I described that understandable). Environment: Windows XP 32bit C:\FPC\3.0.4\bin\i386-Win32\fpc.exe If no one else has experienced/has a solution, I will sit down and bang out test cases until I find what combination (units, code, whatever) is producing this result. Ozz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!
So far in testing, looks like setting $TERM to xterm-256color resolved my issue. (not 100% sure if it was specifically that setting, but, after 20+ hours for a couple days in a row, it started working with that being defined in the .sh idea (thanks!)). path typo was just my exhaustion... it is set to /tmp/test.txt ... per user pid, I am old school (risk taker), I shell in as root, and code/run as root. Have since 1997 when I started running Linux as my main server line...so not a permissions issue. ;-) off to bed... Thanks everyone for your input and ideas where/what to try! Monday should be a good day :-) On Wed, Jan 29, 2020 at 11:28 AM Nikolai Zhubr via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi! > > 29.01.2020 19:04, Ozz Nixon via fpc-devel: > > cat /etc/test.txt > > > > ls -alrt /etc/test.txt > > -rw-r--r-- 1 root root 0 Jan 29 10:54 /tmp/test.txt > > Make sure there is no naming confusion (such as e.g. /tmp/test.txt and > /etc/test.txt unintentionally intermixed) > > Another point is that a binary running from systemd context might have > somewhat different access rights as compared to running from an > interactive shell, so that might lead to some files being unreadable and > that might potentially also lead to changed behaviour. > Actually systemd allows you to set a user and group you want for the > service, like e.g.: > > [Service] > User=root > Group=root > > > A don't remember what it sets by default. > (And certaily, root/root is generally not a safe practice, but just for > a test...) > > > Regards, > Nikolai > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!
I have waited this long now :-) I only run 2.6.4 as something I developed didn't work correctly when compiled with 3.0.0, 3.0.2... Ozz On Wed, Jan 29, 2020 at 10:11 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Ozz Nixon via fpc-devel schrieb am Mi., > 29. Jan. 2020, 16:51: > >> PS. Worsecase, I can scrap 2.6.4 for 3.0.x - just been waiting for a >> stable LLVM build for all 3 OSes I support. >> > > Then you're in for long wait as the LLVM backend is fully supported only > on trunk (at least for macOS and Linux on x86_64). We're currently > preparing the 3.2 release and that means you'll have to wait around two > years at least. > > Also 3.0.x and 3.2 provide better code generation compared to 2.6.4 as > well. So there is probably no need to require the LLVM backend. > > Regards, > Sven > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!
using the .sh concept: # systemctl status coderunner * coderunner.service - The Modern Pascal Code Running Socket Server Loaded: loaded (/usr/lib/systemd/system/coderunner.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2020-01-29 10:55:30 EST; 8s ago Process: 18065 ExecStartPre=/usr/bin/rm -f /run/coderunner2.pid (code=exited, status=0/SUCCESS) Main PID: 18066 (coderunner2.sh) CGroup: /system.slice/coderunner.service |-18066 /bin/sh /usr/local/bin/coderunner2.sh `-18069 /usr/local/bin/coderunner2 Jan 29 10:55:30 www.modernpascal.com systemd[1]: Starting The Modern Pascal Code Running Socket Server... Jan 29 10:55:30 www.modernpascal.com systemd[1]: Started The Modern Pascal Code Running Socket Server. So it starts - telnet 127.0.0.1 - and I get the stuff still. cat /etc/test.txt ls -alrt /etc/test.txt -rw-r--r-- 1 root root 0 Jan 29 10:54 /tmp/test.txt chmod 777 just incase... do not make a different, I even tried, bash, and even added starting... #!/bin/bash echo "Starting">>/tmp/test.txt echo "LANG=$LANG" >>/tmp/test.txt echo "LOCALE=$LOCALE" >>/tmp/test.txt export LC_ALL=C /usr/local/bin/coderunner2 Nothing writes to the file when systemctl starts it. However, if I ./coderunner2.sh I get: Starting LANG=en_US LOCALE= So, I guess try FPC 3.0.x??? On Wed, Jan 29, 2020 at 9:42 AM Nikolai Zhubr via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi! > > 29.01.2020 18:07, Ozz Nixon via fpc-devel: > > 1. My code does not directly interact with any environment variables. > > Ok. > > > ExecStart=/usr/local/bin/coderunner2 > > I'd suggest, as a quick and horrible temporary hack/test, replace this > direct binary call with a shell wrapper, lets name it e.g. > coderunner2.sh, containing something like: > > #!/bin/sh > echo "LANG=$LANG" >>/tmp/test.txt > echo "LOCALE=$LOCALE" >>/tmp/test.txt > export LC_ALL=C > /usr/local/bin/coderunner2 > > (Put it into /usr/local/bin/ as otherwise systemd might refuse it; I > suppose the script is simple enough to be self-explanatory) > > > 3. I do not see anything in that file that would override socket output. > > Sure. > > > 5. per wireshark, tcpdump (if the same) - it shows '?' is being sent > > when the daemon is managed by systemctl, and the expected 8bit is sent > > when ran at the shell prompt. > > That proves the problem is unrelated to sockets. Is is related to > string/encoding handling. > > > HTH... > > Regards, > Nikolai > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!
per units, coderunner uses:
uses
{$IFDEF UNIX}
cthreads,
baseunix,
unix,
{$ENDIF}
{ huge list of units I developed }
variants,
keyboard,
PdfDocs,
PdfTypes,
PdfFonts,
SQLDb,
odbcconn,
sqlite3conn, <-- soon to remove, it's unstable in our testing
jansql, <-- soon to remove could not get it to work
spellcheck;
Those are the unit I run that I did not code.
Back to testing .sh idea.
PS. Worsecase, I can scrap 2.6.4 for 3.0.x - just been waiting for a stable
LLVM build for all 3 OSes I support.
On Wed, Jan 29, 2020 at 9:45 AM Marco van de Voort <
c...@pascalprogramming.org> wrote:
>
> Op 29/01/2020 om 16:07 schreef Ozz Nixon via fpc-devel:
>
> 1. My code does not directly interact with any environment variables.
>
> Unit cwstring and clocale might do on startup. This might influence e.g.
> widestring/unicodestring<-> ansistring conversions and back.
>
> 2. I am using version 2.6.4 to compile the daemon.
>
> That makes encoding debugging quite more difficult, as 2.6.4 behaves
> differently from 3.0.x in that regard.
>
>
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!
> That proves the problem is unrelated to sockets. Is is related to string/encoding handling. Now that makes a lot more sense than the socket doing goofy magic. The string layer in FPC doing goofy magic! I am trying your .sh script idea now... On Wed, Jan 29, 2020 at 9:42 AM Nikolai Zhubr via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi! > > 29.01.2020 18:07, Ozz Nixon via fpc-devel: > > 1. My code does not directly interact with any environment variables. > > Ok. > > > ExecStart=/usr/local/bin/coderunner2 > > I'd suggest, as a quick and horrible temporary hack/test, replace this > direct binary call with a shell wrapper, lets name it e.g. > coderunner2.sh, containing something like: > > #!/bin/sh > echo "LANG=$LANG" >>/tmp/test.txt > echo "LOCALE=$LOCALE" >>/tmp/test.txt > export LC_ALL=C > /usr/local/bin/coderunner2 > > (Put it into /usr/local/bin/ as otherwise systemd might refuse it; I > suppose the script is simple enough to be self-explanatory) > > > 3. I do not see anything in that file that would override socket output. > > Sure. > > > 5. per wireshark, tcpdump (if the same) - it shows '?' is being sent > > when the daemon is managed by systemctl, and the expected 8bit is sent > > when ran at the shell prompt. > > That proves the problem is unrelated to sockets. Is is related to > string/encoding handling. > > > HTH... > > Regards, > Nikolai > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!
1. My code does not directly interact with any environment variables. 2. I am using version 2.6.4 to compile the daemon. my .service file for systemctl looks like: [Unit] Description=The Modern Pascal Code Running Socket Server After=network.target [Service] Type=simple PIDFile=/run/coderunner2.pid EnvironmentFile=-/etc/coderunner2.conf ExecStartPre=/usr/bin/rm -f /run/coderunner2.pid ExecStart=/usr/local/bin/coderunner2 ExecReload=/bin/kill -s HUP $MAINPID KillSignal=SIGQUIT TimeoutStopSec=5 KillMode=process PrivateTmp=true Restart=on-failure RestartSec=42s StandardOutput=null [Install] WantedBy=multi-user.target 3. I do not see anything in that file that would override socket output. 4. And again, if I to /usr/local/bin/coderunner2 from the shell, the client see's the 8bit code. 5. per wireshark, tcpdump (if the same) - it shows '?' is being sent when the daemon is managed by systemctl, and the expected 8bit is sent when ran at the shell prompt. 6. So, the thought of LANG/LOCALE affecting it, from the shell: [root@www LEGACYX]# echo $LANG en_US [root@www LEGACYX]# echo $LOCALE 6b. Not sure how to do that except have my daemon display those two at connect time... 7. CentOS 7, dropped using init.d for systemctl - on my CentOS 6 machine, it works perfectly... 8... does socket.pp get affected at RUN-TIME, by environment variables? (did not notice my first pass through)... On Wed, Jan 29, 2020 at 8:43 AM wrote: > 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 > ___ 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!
Would/Could, LANG/LOCALE affect socket output? * I personally do not touch environment variables - so I am not sure what to ever try. The "client" (Telnet) I have tried Terminal.App, iTerm2, Putty.exe, Telnet.exe, xTerm-256, fTelnet, etc. all clients on all 3 OSes render '?' from the daemon if systemctl starts it, again, if I just start the fpc binary from a shell'd session, ./program - it works fine on all 3 OSes that previously show '?'. I have tcpdump'd the socket, it sends '?' when ran under systemctl, however, sends the 8bit character when ran manually on the command line. Thanks, Ozz On Wed, Jan 29, 2020 at 7:39 AM Marco van de Voort < c...@pascalprogramming.org> wrote: > > Op 29/01/2020 om 14:23 schreef Ozz Nixon via fpc-devel: > > I am not sure how this is occurring, however, my socket daemon on Linux - > is launched by hand ./program is able to send to the socket: > > Socket.Write(#218+#196+#191); > > And the terminal (any) will display the single highbit characters. > > If systemctl start myprogram... that same call sends '???'. Same binary, > not recompiled or anything. Then I do systemctl stop myprogram, and > ./program connect to it, and I get the single highbit characters again. > > I have googled everything I could think of for FPC and SYSTEMCTL, to see > if either have documented this - without success. Since you guys know what > the compiler is producing, and all these tricks you guys do for UTF8, > CP437, etc... I decided to give up and ask you guys - any idea what is > going on? > > * The other challenge is, this just started a week ago. the > myprogram.service file has not been modified, nothing for the OS had been > modified, I just noticed one day - the code I use for UTF8 auto detection > was showing ... and then ran my 8bit test, and noticed ever character > 0x80+ displays as '?'. > > > LANG or LOCALE environment variables ? > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!
I am not sure how this is occurring, however, my socket daemon on Linux - is launched by hand ./program is able to send to the socket: Socket.Write(#218+#196+#191); And the terminal (any) will display the single highbit characters. If systemctl start myprogram... that same call sends '???'. Same binary, not recompiled or anything. Then I do systemctl stop myprogram, and ./program connect to it, and I get the single highbit characters again. I have googled everything I could think of for FPC and SYSTEMCTL, to see if either have documented this - without success. Since you guys know what the compiler is producing, and all these tricks you guys do for UTF8, CP437, etc... I decided to give up and ask you guys - any idea what is going on? * The other challenge is, this just started a week ago. the myprogram.service file has not been modified, nothing for the OS had been modified, I just noticed one day - the code I use for UTF8 auto detection was showing ... and then ran my 8bit test, and noticed ever character 0x80+ displays as '?'. Thanks, Ozz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TStrings and BOM
Just make your own descendent - jeez. On Wed, Jan 1, 2020 at 5:02 PM Werner Pamler wrote: > Am 01.01.2020 um 17:01 schrieb Ondrej Pokorny: > > Isn't the TStrings.WriteBOM property good enough? Why to have yet > > another not-very-useful overload? > > To be honest I think Bart's idea of making the BOM an optional parameter > of the Save methods appears to me more efficient than defining a > property just for this only purpose. Do we really have to imitate all > the nonsense dictated by Delphi? > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
