On Fri, 10 Jul 2020, Bo Berglund via fpc-pascal wrote:
On Fri, 10 Jul 2020 01:26:24 +0200, Tomas Hajny
wrote:
Here I use the blocking Read(ch) instead and now Enter makes the code
move on to the termination phase.
It will not be used at all in the production program...
But I really asked
On Fri, 10 Jul 2020 01:26:24 +0200, Tomas Hajny
wrote:
Well I do not believe the problem I am seeing is because of thread
safe or not.
This test server is just running the main thread (the program itself)
where the detection of keyboard entry q is in a loop to make it
possible to end execution i
Am 10.07.2020 um 03:02 schrieb Ryan Joseph via fpc-pascal:
On Jul 10, 2020, at 12:23 AM, Sven Barth via fpc-pascal
wrote:
(so that it points to the VMT generated for the interface)
So, it sounds like what the interface actually is, is a pointer to VMT table.
Correct.
The VMT is generate
> On Jul 10, 2020, at 12:23 AM, Sven Barth via fpc-pascal
> wrote:
>
> (so that it points to the VMT generated for the interface)
So, it sounds like what the interface actually is, is a pointer to VMT table.
The VMT is generated with the class that implements the interface? Does it have
to
On 2020-07-10 01:05, Travis Siegel wrote:
On 7/9/2020 5:11 PM, Tomas Hajny wrote:
On 2020-07-09 22:58, Michael Van Canneyt wrote:
On Thu, 9 Jul 2020, Bo Berglund via fpc-pascal wrote:
On Thu, 9 Jul 2020 19:36:31 +0200 (CEST), Michael Van Canneyt
wrote:
Is this done in a thread ? Since you'
On 7/9/2020 5:11 PM, Tomas Hajny wrote:
On 2020-07-09 22:58, Michael Van Canneyt wrote:
On Thu, 9 Jul 2020, Bo Berglund via fpc-pascal wrote:
On Thu, 9 Jul 2020 19:36:31 +0200 (CEST), Michael Van Canneyt
wrote:
Is this done in a thread ? Since you're using indy, I suppose so.
The crt unit
On 2020-07-10 00:40, Bo Berglund via fpc-pascal wrote:
On Thu, 09 Jul 2020 23:11:34 +0200, Tomas Hajny
wrote:
You can use the unit Keyboard as well, which is cross-platform.
I did as follows:
uses
...
Keyboard,
...
begin
...
repeat
//ch := ReadKey; //ReadKey is not support
On Thu, 09 Jul 2020 23:11:34 +0200, Tomas Hajny
wrote:
>You can use the unit Keyboard as well, which is cross-platform.
I did as follows:
uses
...
Keyboard,
...
begin
...
repeat
//ch := ReadKey; //ReadKey is not supported by Keyboard...
Read(ch);
until ch='q'; {q}
Am 09.07.2020 um 18:42 schrieb Bo Berglund via fpc-pascal:
On Thu, 9 Jul 2020 16:25:50 +, Alexander Grotewohl
wrote:
it sounds like your terminal has gotten fudged somehow
I am using crt in the lpr file just for the sake of being able to shut
it down sensibly:
It doesn't matter where t
On 2020-07-09 22:58, Michael Van Canneyt wrote:
On Thu, 9 Jul 2020, Bo Berglund via fpc-pascal wrote:
On Thu, 9 Jul 2020 19:36:31 +0200 (CEST), Michael Van Canneyt
wrote:
Is this done in a thread ? Since you're using indy, I suppose so.
The crt unit is not thread safe. The implementation on
On Thu, 9 Jul 2020, Bo Berglund via fpc-pascal wrote:
On Thu, 9 Jul 2020 19:36:31 +0200 (CEST), Michael Van Canneyt
wrote:
Is this done in a thread ? Since you're using indy, I suppose so.
The crt unit is not thread safe. The implementation on Windows and Linux is
totally different, which
On Thu, 9 Jul 2020 19:36:31 +0200 (CEST), Michael Van Canneyt
wrote:
>Is this done in a thread ? Since you're using indy, I suppose so.
>
>The crt unit is not thread safe. The implementation on Windows and Linux is
>totally different, which may explain the difference you see.
Is there a way to c
On Thu, 09 Jul 2020 21:13:38 +0200, Rainer Stratmann
wrote:
>I had exactly the same behaviour.
>
>Some setterm commands solved it, if I remember correct.
>
>setterm -blank 0
Response was:
setterm: terminal xterm-256color does not support --blank
>setterm -powersave off
Power save is not involv
I had exactly the same behaviour.
Some setterm commands solved it, if I remember correct.
setterm -blank 0
setterm -powersave off
I guess it was the first command.
You can try it.
Am Donnerstag, 9. Juli 2020, 18:01:42 CEST schrieb Bo Berglund via fpc-pascal:
> I am writing a cross-platform pro
On Thu, 9 Jul 2020, Bo Berglund via fpc-pascal wrote:
On Thu, 9 Jul 2020 16:25:50 +, Alexander Grotewohl
wrote:
perhaps try 'reset' or 'stty sane' in the terminal before running your program?
reset in PuTTY gives me a new resized empty screen, but works exactly
the same afterwards.
Am 09.07.2020 um 14:31 schrieb Ryan Joseph via fpc-pascal:
Given the code below and the 2 cases can anyone explain what exactly the
compiler does when the interfaces are assigned to? Does it copy a record like
structure, call some internal functions, do runtime checks? I'm curious if
they're d
On Thu, 9 Jul 2020 16:25:50 +, Alexander Grotewohl
wrote:
>perhaps try 'reset' or 'stty sane' in the terminal before running your program?
reset in PuTTY gives me a new resized empty screen, but works exactly
the same afterwards.
>are you using the crt or video units at all?
Yes, see below.
perhaps try 'reset' or 'stty sane' in the terminal before running your program?
are you using the crt or video units at all?
it sounds like your terminal has gotten fudged somehow
--
Alexander Grotewohl
https://dcclost.com
From: fpc-pascal on behalf of Bo
Bergl
I am writing a cross-platform program (console program, no GUI).
I am using Lazarus 2.0.8 and FPC 3.0.4 on both Linux and Windows.
During sebugging I have put numerous writeln commands in the code to
track what is happening.
I started on Windows and all worked just fine according to
expectations.
Given the code below and the 2 cases can anyone explain what exactly the
compiler does when the interfaces are assigned to? Does it copy a record like
structure, call some internal functions, do runtime checks? I'm curious if
they're doing more than I think they do.
I suspect Embarcadero that they often intently design Delphi to be not
compatible with FPC.
V.
__
Od: "Sven Barth via fpc-pascal"
Komu: fpc-pascal@lists.freepascal.org
Datum: 09.07.2020 07:30
Předmět: Re: [fpc-pascal] LongInt and LongW
21 matches
Mail list logo
