Re: [fpc-pascal] PTCGraph resolution detection

[Nikolay Nikolov via fpc-pascal]

On 3/19/24 18:15, James Richters via fpc-pascal wrote:


I am trying to compile a program that uses PTCGraph for Windows 64 
bit, and it’s not behaving the same as it does on Win32.


When I compile it for Win32, it is correctly detecting my monitor 
resolutionI have a vertical monitor with a resolution of 1080x2560


When I run the Win32 program I correctly get:

Max resolution:1080x2560

The 64bit version incorrectly produces:

Max resolution:2160x3840

I tried it on another computer with a 1280x1024 monitor and it 
correctly identifies it on both versions.


Below is the procedure that gets the monitor resolution.

I am using the current trunk of FPC installed today.

Does anyone have any idea why the 64bit version would work differently 
than the 32bit version?


James

No idea, but it does sound like a Windows issue to me. Or a video card 
driver issue? The API is the same. The mechanism for obtaining the list 
of resolutions is also the same. Perhaps Microsoft uses a fake 
DirectDraw shim in 64-bit Windows that presents a fake resolutions list, 
because they can? Perhaps it is an issue, related to the video card 
drivers? What are the video cards on the two machines that you have tested?


Nikolay


Uses

Windows,ptcgraph,ptccrt,crt,sysutils;

Procedure WindowsGRAPHINIT;

Var

gd,gm:smallint;

m: PModeInfo;

graphinitialize,MaxX,MaxY:Integer;

Begin

Windowtitle:='ptcgraph';

graphinitialize:=1234;

MaxX:=0;

MaxY:=0;

m := QueryAdapterInfo;

while m <> nil do

begin

If m^.MaxX+1>MaxX then

MaxX:=m^.MaxX+1;

If m^.MaxY+1>MaxY then

MaxY:=m^.MaxY+1;

m := m^.next;

end;

Writeln ('Max resolution:',MaxX,'x',MaxY);

gd:=VESA;

gm:=InstallUserMode(WindowXResolution,WindowYResolution,65536,1,1,1);

If gm<0 Then

Begin

Writeln('Error Installing Graphics ',gm,' ',grapherrormsg(gm));

Halt(70);

End;

PtcGraph.InitGraph(gd,gm,'');

… snip …


___
fpc-pascal maillist  -fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] What's in Hello World

[Nikolay Nikolov via fpc-pascal]

On 1/7/24 14:21, Ingemar Ragnemalm via fpc-pascal wrote:


Just for comparison, I fired up Think Pascal and made Hello world!

Plain Hello world, closes so quickly that you don't have time to see 
it: 4625 bytes.


Including ShowText and while not Button do; 4639 bytes.

Yes, less than 5k! Progress?


Nah! It's bloat, bloat, bloat, horrible bloat!!! I'm not impressed. :)

Nothing beats assembler for DOS:

; nasm asmhello.asm -o asmhello.com
    bits 16
    cpu 8086
    org 100h
    mov dx, msg
    mov ah, 9
    int 21h
    ret
msg:    db 'Hello, world!', 13, 10, '$'

The produced executable is only 24 bytes (8 bytes of code and 16 bytes 
of data):


BA 08 01 B4 09 CD 21 C3 48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21 0D 0A 24

You can write this down on a sheet of paper, or memorize it and recite 
it from memory. Try doing that with 4639 bytes :)


Note that noobs will use the following way to terminate the program:

mov ax, 4c00h

int 21h

But that increases the binary size to 28 bytes. We can put a 'ret' 
instruction instead, and that works, because DOS puts a h word on 
top of the stack, and that points to CS:h, which is the beginning of 
the PSP. And that starts with an int 20h, which is the oldschool (MS-DOS 
version 1) way of terminating a process, which requires CS to point to 
the PSP, which it does, because we're a .com file.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Double finalize

[Nikolay Nikolov via fpc-pascal]

On 12/21/23 07:06, Hairy Pixels via fpc-pascal wrote:



On Dec 21, 2023, at 6:11 AM, Hairy Pixels  wrote:

Maybe I misunderstood but I thought they were supposed to be balanced with init 
calls. Is it the design of the compiler to allow multiple finalize calls and 
have the user keep track of it the underlying structure is really finalized or 
not? If you were doing things like deleting memory in the finalizer you would 
have a double free happen here.

Here's another example of this. If I use an array Finalize is called 4 times 
but  Initialize is never called, unless you assign  a record to the array and 
then it's called once.

This makes even less sense. What's the idea behind this behavior? I would 
expect the calls to balanced as this feature is intended for reference counting 
I thought.


Even though it should be possible to implement reference counting, I 
don't think that's the management operators' primary intended use. 
Interfaces and creating a class that inherits from TInterfacedObject is 
the traditional Delphi way to implement reference counting. I tend to 
think of management operators as a way to do a C++ way of managed 
objects, passed by value. That includes not just Initialize and Finalize 
(in C++ these are constructors and destructors), but also Copy as well 
(in C++, this is done by the copy constructor and the assignment operator).


If I wanted to use reference counting, I would still use interfaces and 
TInterfacedObject.


If I wanted to create a new value type that uses memory on the heap, I 
would implement not just Initialize and Finalize, but also Copy and 
probably AddRef (although I don't know when AddRef is used).


However, I think of management operators as a newer and less stable 
feature, so I think that double Finalize call is a bug, that happens 
when a function result is discarded, which is allowed in the extended 
syntax {$X+} mode. Management operators were, unfortunately, added by a 
developer, who had disagreements with the other core FPC developers and 
started an FPC fork, called NewPascal. So it's possible some of the 
features he added were not as stable or as finished as they should be.


That's why I would use interfaces and TInterfacedObject if I wanted just 
reference counting.


Btw, I used management operators in my Unicode-enabled version of the 
KVM units and Free Vision:


https://wiki.freepascal.org/Free_Vision#Unicode_version

See the TEnhancedVideoCell record in:

https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/rtl-console/src/inc/videoh.inc

It enables us to save memory when a character cell is represented by a 
single Unicode code point in the BMP range, but still support complex 
graphemes (which can contain a sequence of unicode code points - 
combining characters, etc.) allocated on the heap when necessary.


So, I don't have hesitance in using them when they are the best choice, 
it's just that I consider them less stable and expect bugs. I just don't 
think they're the best for implementing reference counting.


Nikolay




==

{$mode objfpc}
{$modeswitch advancedrecords}

program test;

type
  TManagedObject = record
x: integer;
class operator Finalize(var self: TManagedObject); inline;
class operator Initialize(var self: TManagedObject); inline;
  end;

class operator TManagedObject.Finalize(var self: TManagedObject);
begin
  writeln('Finalize');
end;

class operator TManagedObject.Initialize(var self: TManagedObject);
begin
  writeln('Initialize');
end;

var
  a: array[0..3] of TManagedObject;
begin
  a[0].x := 1;
  a[1].x := 1;
  a[2].x := 1;
  a[3].x := 1;
end.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Double finalize

[Nikolay Nikolov via fpc-pascal]

On 12/21/23 01:11, Hairy Pixels via fpc-pascal wrote:



On Dec 21, 2023, at 1:53 AM, Michael Van Canneyt via fpc-pascal 
 wrote:

If you look at the generated code, you see that there is an implicit 
try/finally block
and the  finally block does a finalize.

Maybe I misunderstood but I thought they were supposed to be balanced with init 
calls. Is it the design of the compiler to allow multiple finalize calls and 
have the user keep track of it the underlying structure is really finalized or 
not? If you were doing things like deleting memory in the finalizer you would 
have a double free happen here.


Note that you should also add an 'AddRef' and 'Copy' management 
operators and implement these as well. However, I think it's an FPC bug 
that Initialize is called twice in this case. I could be wrong, though.


If you assign the result to a local variable, i.e.:

var

  a: TManagedObject;

begin

  a := TManagedObject.Create;

end.

You get the following output:

Initialize
Initialize
Create
Copy
Finalize
Finalize

So, I think there's a bug in FPC that finalize is called twice when the 
return value is discarded.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] "Modern Pascal is Still in the Race"

[Nikolay Nikolov via fpc-pascal]

On 10/12/23 17:07, Hairy Pixels via fpc-pascal wrote:

Pascal still fits a niche as being a lower level language like C or C++ but 
with nicer syntax.

That is true.

For making modern software it's going to be hard to use though since no major 
OS's support it directly.


In what way does this make it "hard to use"? I certainly find it very 
easy to install and use under Windows, Linux and macOS.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pointer question

[Nikolay Nikolov via fpc-pascal]

On 8/11/23 01:23, Hairy Pixels via fpc-pascal wrote:



On Aug 10, 2023, at 2:18 PM, Michael Van Canneyt via 
fpc-pascal  wrote:

https://www.freepascal.org/docs-html/current/ref/refse15.html#x42-620003.4

This document doesn't really do a great enumerating all the operators so I'm 
not sure if the list is complete. I think the list is:

var
p: pointer;
i: ^Integer;
v: Integer;
begin
   // 1)  increment
   p := p + 1;
   inc(p);

   // 2)  increment
   p := p - 1;
   dec(p);
  
   // 3) difference

   v := p - p;
  
  // 4) subscript (inc and dereference in one step)

  v := i[1];


#4 was not  in the list for example so I wonder what others exist.


That is not true. Read that document again and focus on the part that 
starts with "Remark Free Pascal treats pointers much the same way as C 
does. This means that a pointer to some type can be treated as being an 
array of this type."


In fact, Free Pascal's documentation and exactly this page is how I 
learned about this feature a long time ago.


Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parse unicode scalar

[Nikolay Nikolov via fpc-pascal]

On 7/4/23 09:12, Hairy Pixels via fpc-pascal wrote:



On Jul 4, 2023, at 12:38 PM, Nikolay Nikolov via fpc-pascal 
 wrote:

For console apps that use the Unicode KVM video unit, I've introduced two 
functions for determining the display width of a Unicode string in the video 
unit:

function ExtendedGraphemeClusterDisplayWidth(const EGC: UnicodeString): Integer;
{ Returns the number of display columns needed for the given extended grapheme 
cluster }

function StringDisplayWidth(const S: UnicodeString): Integer;
{ Returns the number of display columns needed for the given string }

Remember, the display width is different than the number of graphemes, due to 
East Asian double width characters.

And these work with UnicodeString, which is UTF-16, not UTF-8. But Free Pascal 
can convert between the two.

is there an example snippet of how all this works? It's too level for newbies 
to understand. :)


Rendering Unicode to the screen is not for newbies :)

Using Unicode (where another library, like GTK or QT or the console 
deals with it) is another matter. What is it that you need to do? From 
your emails I get the impression you're writing a parser for a language. 
For that, you don't usually need this sort of "length". If you're making 
a GUI app, e.g. with the LCL, there should be ways to determine the 
display length of a text control? Generally, you should use your GUI or 
TUI toolkit. The Unicode version of Free Vision is for fullscreen TUI 
apps, like the console IDE (which does not yet support Unicode). If 
that's what you want, here's a starting point:


https://wiki.freepascal.org/Free_Vision#Unicode_version

Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parse unicode scalar

[Nikolay Nikolov via fpc-pascal]

On 7/4/23 08:08, Nikolay Nikolov wrote:


On 7/4/23 07:56, Hairy Pixels via fpc-pascal wrote:



On Jul 4, 2023, at 11:50 AM, Hairy Pixels  wrote:

You know you're right, with properly enclosed patterns you can 
capture everything inside and it works. You won't know if you had 
unicode in your string or not though but that depends on what's 
being parsed and if you care or not (I'm doing a TOML parser).

Sorry I'm still curious even though it's not my current problem :)

How can I make this program output the expected results:

   w: widechar;
   a: array of widechar;
begin
    for w in 'abc🐻' do
  a += [w];
   // Outputs 7 instead of 4
   writeln(length(a));
end;

The user doesn't know about unicode they just want to get an array of 
characters and not worry about all these little details. What can FPC 
do to solve this problem?


Depends on what you need, but I suppose in this case you want to count 
the number of extended grapheme clusters (a.k.a. "user perceived 
characters" - how many character-like things are displayed on the 
screen). You might be tempted to count the number of Unicode code 
points, but that's not the same, due to the existence of combining 
characters:


https://en.wikipedia.org/wiki/Combining_character

For extended grapheme clusters, there's an iterator in the 
graphemebreakproperty unit. I implemented this for the Unicode KVM and 
FreeVision. There it's needed for figuring out how many character 
blocks in the console will be needed to display a certain string. For 
the console or other GUIs that use fixed width fonts, there's also the 
East Asian Width property as well - some characters (East Asian - 
Chinese, Japanese, Korean) take double the space. So, to figure out 
where to move the cursor, you need to take East Asian Width as well.


For console apps that use the Unicode KVM video unit, I've introduced 
two functions for determining the display width of a Unicode string in 
the video unit:


function ExtendedGraphemeClusterDisplayWidth(const EGC: UnicodeString): 
Integer;
{ Returns the number of display columns needed for the given extended 
grapheme cluster }


function StringDisplayWidth(const S: UnicodeString): Integer;
{ Returns the number of display columns needed for the given string }

Remember, the display width is different than the number of graphemes, 
due to East Asian double width characters.


And these work with UnicodeString, which is UTF-16, not UTF-8. But Free 
Pascal can convert between the two.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parse unicode scalar

[Nikolay Nikolov via fpc-pascal]

On 7/4/23 07:56, Hairy Pixels via fpc-pascal wrote:



On Jul 4, 2023, at 11:50 AM, Hairy Pixels  wrote:

You know you're right, with properly enclosed patterns you can capture 
everything inside and it works. You won't know if you had unicode in your 
string or not though but that depends on what's being parsed and if you care or 
not (I'm doing a TOML parser).

Sorry I'm still curious even though it's not my current problem :)

How can I make this program output the expected results:

   w: widechar;
   a: array of widechar;
begin
for w in 'abc🐻' do
  a += [w];
   // Outputs 7 instead of 4
   writeln(length(a));
end;

The user doesn't know about unicode they just want to get an array of 
characters and not worry about all these little details. What can FPC do to 
solve this problem?


Depends on what you need, but I suppose in this case you want to count 
the number of extended grapheme clusters (a.k.a. "user perceived 
characters" - how many character-like things are displayed on the 
screen). You might be tempted to count the number of Unicode code 
points, but that's not the same, due to the existence of combining 
characters:


https://en.wikipedia.org/wiki/Combining_character

For extended grapheme clusters, there's an iterator in the 
graphemebreakproperty unit. I implemented this for the Unicode KVM and 
FreeVision. There it's needed for figuring out how many character blocks 
in the console will be needed to display a certain string. For the 
console or other GUIs that use fixed width fonts, there's also the East 
Asian Width property as well - some characters (East Asian - Chinese, 
Japanese, Korean) take double the space. So, to figure out where to move 
the cursor, you need to take East Asian Width as well.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parse unicode scalar

[Nikolay Nikolov via fpc-pascal]

On 7/4/23 07:45, Nikolay Nikolov wrote:


On 7/4/23 07:40, Hairy Pixels via fpc-pascal wrote:


On Jul 4, 2023, at 11:28 AM, Nikolay Nikolov via fpc-pascal 
 wrote:


For what grammar? What characters are allowed in a token? For 
example, Free Pascal also has a parser/tokenizer, but since Pascal 
keywords are ASCII only, it doesn't need to understand Unicode 
characters, so it works on the byte (Pascal's char type) level (for 
UTF-8 files, this means UTF-8 Unicode code units). That's because 
UTF-8 has two nice properties:


1)  ASCII character are encoded as they are - by using bytes in the 
range #0..#127


2) non-ASCII characters will always use a sequence of bytes, that 
are all in the range #128..#255 (they have their highest bit set), 
so they will never be misinterpreted as ASCII.


So, the tokenizer just works with UTF-8 like with any other 8-bit 
code page.
yes this works until you reach a non-ASCII ranged character and then 
the character index no longer matches the string 1 to 1. For example 
consider this was pascal:


i := '🐻';

You can advance by index like:

  Inc(currrentIndex);
  c := text[currentIndex];

but once you hit the bear the offset is now wrong so you can't 
advance to the next character by doing +1.


But you just don't need to do this, in order to tokenize Pascal. The 
beginning and the end of the string literal is the apostrophe, which 
is ASCII. The bear is a sequence of UTF-8 code units (opaque to the 
compiler), that will not be mistaken for an apostrophe, or end of 
line, because they will have their high bit set. There's simply no 
need for a Pascal tokenizer to iterate over UTF-8 code points, instead 
of code units.


Sorry, the last sentence should read: "There's simply no need for a 
Pascal tokenizer to iterate over Unicode code points, instead of UTF-8 
code units." Hope that makes it more clear and accurate.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parse unicode scalar

[Nikolay Nikolov via fpc-pascal]

On 7/4/23 07:40, Hairy Pixels via fpc-pascal wrote:



On Jul 4, 2023, at 11:28 AM, Nikolay Nikolov via fpc-pascal 
 wrote:

For what grammar? What characters are allowed in a token? For example, Free 
Pascal also has a parser/tokenizer, but since Pascal keywords are ASCII only, 
it doesn't need to understand Unicode characters, so it works on the byte 
(Pascal's char type) level (for UTF-8 files, this means UTF-8 Unicode code 
units). That's because UTF-8 has two nice properties:

1)  ASCII character are encoded as they are - by using bytes in the range 
#0..#127

2) non-ASCII characters will always use a sequence of bytes, that are all in 
the range #128..#255 (they have their highest bit set), so they will never be 
misinterpreted as ASCII.

So, the tokenizer just works with UTF-8 like with any other 8-bit code page.

yes this works until you reach a non-ASCII ranged character and then the 
character index no longer matches the string 1 to 1. For example consider this 
was pascal:

i := '🐻';

You can advance by index like:

  Inc(currrentIndex);
  c := text[currentIndex];

but once you hit the bear the offset is now wrong so you can't advance to the 
next character by doing +1.


But you just don't need to do this, in order to tokenize Pascal. The 
beginning and the end of the string literal is the apostrophe, which is 
ASCII. The bear is a sequence of UTF-8 code units (opaque to the 
compiler), that will not be mistaken for an apostrophe, or end of line, 
because they will have their high bit set. There's simply no need for a 
Pascal tokenizer to iterate over UTF-8 code points, instead of code units.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parse unicode scalar

[Nikolay Nikolov via fpc-pascal]

On 7/4/23 07:17, Hairy Pixels via fpc-pascal wrote:



On Jul 4, 2023, at 9:58 AM, Nikolay Nikolov via fpc-pascal 
 wrote:

You need to understand all these terms and know exactly what you need to do. 
E.g. are you dealing with keyboard input, are you dealing with the low level 
parts of text display, are you searching for something in the text, are you 
just passing strings around and letting the GUI deal with it? These are all 
different use cases, and they require careful understanding what Unicode thing 
you need to iterate over.

Thanks for trying to help but this is more complicated than I thought and I 
don't have the patience for a deep dive right now :)

Unicode is complicated under the hood but we should have some libraries to help right? I mean the 
user thinks of these things as "characters" be it "A" or the unicode symbol 👍 
so we should be able to operate on that basis as well. Something like an iterator that return the 
character (wide char) and  byte offset or writing would be a nice place to start.

I have a parser/tokenizer I want to update so I'm trying to find tokens by 
advancing one character at a time. That's why I have a requirement to know 
which character is next in the file and probably the byte offset also so it can 
be referenced later.


For what grammar? What characters are allowed in a token? For example, 
Free Pascal also has a parser/tokenizer, but since Pascal keywords are 
ASCII only, it doesn't need to understand Unicode characters, so it 
works on the byte (Pascal's char type) level (for UTF-8 files, this 
means UTF-8 Unicode code units). That's because UTF-8 has two nice 
properties:


1)  ASCII character are encoded as they are - by using bytes in the 
range #0..#127


2) non-ASCII characters will always use a sequence of bytes, that are 
all in the range #128..#255 (they have their highest bit set), so they 
will never be misinterpreted as ASCII.


So, the tokenizer just works with UTF-8 like with any other 8-bit code page.

Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ShortString still relevant today?

[Nikolay Nikolov via fpc-pascal]

On 7/4/23 04:19, Hairy Pixels via fpc-pascal wrote:

I've been exploring the string types and I'm curious now, does the classic Pascal 
"ShortString" even make sense anymore on modern computers? I'm running tests 
and I can't seem to find a way in which AnsiString overall performs worse than 
ShortString.

Are there any examples where AnsiString is worse? I think if you passed strings 
around lots that would trigger the ref counting and InterlockedExchange (I saw 
this in my own code before and it unnerved me) but that's been hard to test.


ShortString is mainly for compatibility with Turbo Pascal, not for 
performance, IMHO. Although the FPC compiler itself still uses 
ShortString for performance reasons (I think the main advantage is the 
avoidance of the implicit try..finally blocks, needed for ansistrings). 
It might be interesting to benchmark the compiler with AnsiStrings 
instead of ShortStrings and see if there's a performance difference. But 
even if there is, a compiler is an extreme example. For 99% of the 
programs, performance impact of AnsiString is not an issue. I put {$H+} 
in almost all my new programs. I'd say that in 99% of the legit use 
cases, ShortString is used and needed for compatibility with legacy 
code, not for performance. Switching legacy code to {$H+} doesn't always 
work and may need additional fixes. Old code does things like S[0] := x 
instead of SetLength(S, x), etc. It also does uglier things, like 
FillChar() or Move() directly to/from string memory, or saves 
ShortStrings to files, as a part of a record, etc.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parse unicode scalar

[Nikolay Nikolov via fpc-pascal]

On 7/4/23 04:03, Hairy Pixels via fpc-pascal wrote:



On Jul 4, 2023, at 1:15 AM, Mattias Gaertner via fpc-pascal 
 wrote:

function ReadUTF8(p: PChar; ByteCount: PtrInt): PtrInt;
// returns the number of codepoints
var
  CodePointLen: longint;
  CodePoint: longword;
begin
  Result:=0;
  while (ByteCount>0) do begin
inc(Result);
CodePoint:=UTF8CodepointToUnicode(p,CodePointLen);
...do something with the CodePoint...
inc(p,CodePointLen);
dec(ByteCount,CodePointLen);
  end;
end;

Thanks, this looks right. I guess this is how we need to iterate over unicode 
now.

Btw, why isn't there a for-loop we can use over unicode strings? seems like 
that should be supported out of the box. I had this same problem in Swift also 
where it's extremely confusing to merely iterate over a string and look at each 
character. Replacing characters will be tricky also so we need some good 
library functions.


You're still confusing the Unicode terms. The above code iterates over 
Unicode Code Points, not "characters" in a UTF-8 encoded string. A 
Unicode Code Point is not a "character":


https://unicode.org/glossary/#character

https://unicode.org/glossary/#code_point

There are also graphemes, grapheme clusters and extended grapheme 
clusters - these terms can also be perceived as "characters".


https://unicode.org/glossary/#grapheme

https://unicode.org/glossary/#grapheme_cluster

https://unicode.org/glossary/#extended_grapheme_cluster

If you want to iterate over extended grapheme clusters, for example, 
there's an iterator (written by me) in the unit graphemebreakproperty.pp 
in the rtl-unicode package.


If you use the 'char' type in Pascal to iterate over an UTF-8 encoded 
string, you're iterating over Unicode code units (units! not code 
points! https://unicode.org/glossary/#code_unit).


If you use the 'widechar' type in Pascal to iterate over a UnicodeString 
(which is a UTF-16 encoded string), you're also iterating over Unicode 
code units, however this time in UTF-16 encoding.


If you want to iterate over Unicode code points (not units! not 
characters! not graphemes!) in a UTF-8 string, you need something like 
the ReadUTF8 function above. If you want to iterate over Unicode code 
points in a UTF-16 string, you need different code.


You need to understand all these terms and know exactly what you need to 
do. E.g. are you dealing with keyboard input, are you dealing with the 
low level parts of text display, are you searching for something in the 
text, are you just passing strings around and letting the GUI deal with 
it? These are all different use cases, and they require careful 
understanding what Unicode thing you need to iterate over.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parse unicode scalar

[Nikolay Nikolov via fpc-pascal]

On 7/2/23 20:38, Martin Frb via fpc-pascal wrote:

On 02/07/2023 19:20, Nikolay Nikolov via fpc-pascal wrote:

On 7/2/23 16:30, Hairy Pixels via fpc-pascal wrote:
I'm interested in parsing unicode scalars (I think they're called) 
to byte sized values but I'm not sure where to start. First thing I 
did was choose the unicode scalar U+1F496 (💖).


There's no such thing as "unicode scalar" in Unicode terminology:

https://unicode.org/glossary/

There seems to be
https://www.unicode.org/versions/Unicode10.0.0/ch03.pdf#G7404
Too bad it's not included in the Unicode glossary. :( So, it's basicaly 
a Unicode code point that is not a high-surrogate or low-surrogate. And 
if you want to know what "high-surrogate" and "low-surrogate" means, you 
should read about UTF-16.







Next I cheated and ask ChatGPT. :) Amazingly from my question it was 
able to tell me the scaler is comprised of these 4 bytes:


  240 159 146 150


That is an utf-8 encoded representation of such a value.

You can find them on https://www.compart.com/en/unicode/U+0041
(using the hex for whatever codepoint interests you)


Or just learn about Unicode encodings, such as UTF-8, UTF-16, etc.

https://en.wikipedia.org/wiki/UTF-8

https://en.wikipedia.org/wiki/UTF-16

https://en.wikipedia.org/wiki/UTF-32

Both UTF-8 and UTF-16 are frequently used and are important to know. 
UTF-32 is rarely used, but is very simple and easy to understand as 
well. It's just not very efficient, hence its rarity. :)


Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parse unicode scalar

[Nikolay Nikolov via fpc-pascal]

On 7/2/23 16:30, Hairy Pixels via fpc-pascal wrote:

I'm interested in parsing unicode scalars (I think they're called) to byte 
sized values but I'm not sure where to start. First thing I did was choose the 
unicode scalar U+1F496 (💖).


There's no such thing as "unicode scalar" in Unicode terminology:

https://unicode.org/glossary/

So, what do you mean? A Unicode code point? An Extended Grapheme 
Cluster? Or something else? There are also several ways to encode 
Unicode into a byte sequence - UTF-8, UTF-16LE, UTF-16BE, UTF-32, etc.




Next I cheated and ask ChatGPT. :) Amazingly from my question it was able to 
tell me the scaler is comprised of these 4 bytes:

  240 159 146 150

I was able to correctly concatenate these characters and writeln printed the 
correct character.

var
s: String;
begin
s := char(240)+char(159)+char(146)+char(150);
writeln(s);
end.

The question is, how was 1F496 decomposed into 4 bytes?


I guess you should ask ChatGPT, who gave you the answer ;-)

Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpc isn't optimised for tail recursion, is it?

[Nikolay Nikolov via fpc-pascal]

On 6/12/23 04:44, Steve Litt via fpc-pascal wrote:

Hi all,

Tail recursion is recursion in which absolutely nothing gets executed
after the return statement. Some programming languages, including
Guile, optimize for tail recursion such that tail recursive algorithms
don't use additional stack space as you pile up more and more levels of
recursion.

I did a typical non-tail recursion hello world program, and if I set
the "now-go-backward" number high enough, it segfaulted, I assume
because I ran it out of stack space with so many levels of recursion.

So, to see if FPC is optimized for tail recursion, I tested it with the
following program, which I think is tail-recursive.

===
program recursion_hello;

function nextt(num: int64): int64;
begin
writeln('Going deeper=>   ', num);
if (num > 0) then
   begin
   nextt(num - 1);
   end;
nextt := num;
end;

begin
   nextt(10);
end.
===

As you can see, the return from function occurs at the very end of
function nextt(), which I believes makes my algorithm tail-recursive.
Running my program, I found it segfaulted pretty much the same as the
non-tail-recursive version.

I tried to look up all relevant compiler directives, finding {s-}
and {$stackspaces off}, which requires no local vars and no parameters
to not implement a stackspace for a fuunction. So I made the
"now-go-backward" number a global, and made the recursive function a
procedure, and still, I got the segfaulting.

So, subject to your guidance, I'm assuming FPC isn't optimized for tail
recursion. Is my assumption an accurate one?


FPC supports tail recursion optimization, it is enabled at -O2 
optimization level for most CPUs, however your code isn't eligible for 
that optimization, because there's extra code, after the recursive 
invoke. If you change it like that:


program recursion_hello;

function nextt(num: int64): int64;
   begin
   writeln('Going deeper=>   ', num);
   nextt := num;
   if (num > 0) then
  begin
  nextt(num - 1);
  end;
   end;

begin
  nextt(10);
end.

And if you compile with -O2 it works, without segfaulting (tested with 
FPC 3.2.2 on x86_64-linux).


Nikolay



Thanks,

SteveT

Steve Litt
Autumn 2022 featured book: Thriving in Tough Times
http://www.troubleshooters.com/bookstore/thrive.htm
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pause Key

[Nikolay Nikolov via fpc-pascal]

On 4/14/23 20:38, Virgo Pärna via fpc-pascal wrote:

On Thu, 13 Apr 2023 20:53:09 -0400, Travis Siegel via fpc-pascal 
 wrote:

I know of no way to obtain the pause key status under windows.  I can

Considering, that only Caps Lock, Scroll Lock and Num Lock keys
have status lights on keyboard I would suspect, that there is not such
thing as Pause status on PC keyboard.


There is such a thing under DOS, because the BIOS treats the Pause key 
in a special way. When you press it, the BIOS enters a loop and stops 
execution of your program, until you press Pause again. This is done, so 
that you can pause the output to the console, in case it is scrolling 
too fast, so that you can examine it. For this purpose, there's a flag 
in the BIOS data area, which is documented here:


http://www.techhelpmanual.com/58-keyboard_shift_status_flags.html

Bit 3 (mask 08h) at 0040h:0018h contains the Pause status. However, I 
don't think there's such an equivalent under Windows and Linux. 
Actually, the Linux console (but not X11!) uses Scroll Lock to pause the 
console output, pretty much the same way DOS and BIOS used the Pause 
key. Why didn't Linus Torvalds use the Pause key is beyond me.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Getting Shift key with PTCCRT

[Nikolay Nikolov via fpc-pascal]

On 9/10/22 17:57, James Richters via fpc-pascal wrote:

Thanks for the suggestion

I think the syntax should be:
type myKeyEvent = IPTCKeyEvent;
Var myShiftStatus : boolean;

myShiftStatus := myKeyEvent.Shift;

but I get IPTCKeyEvent not found.  I wonder if it's only designated as
internal.. or if I need to use something other than PTCGraph and PTCCRT


It's internal if you use ptccrt and ptcgraph, but it's available if you 
use ptc directly. These are two different APIs:


ptc - low level, non-Borland compatible API

ptcgraph, ptccrt, ptcmouse - these use ptc to provide a Borland 
BGI-compatible and CRT-unit compatible support (plus mouse, which was 
never supported by Borland, but is nice to have also ;-) ). Recently, I 
don't have much time to work on ptc (unfortunately), but you can look at 
the source yourself and write a patch by yourself to get what you need. 
The conversion of ptc key events to CRT-like key codes happens in 
ptccrt.pp, procedure GetKeyEvents (lines 113..534). It tries to convert 
ptc key events to what CRT in dos used to return. There are lots of 
compatibility factors involved, which results in some key data loss, but 
you can modify it at your will for your own purposes. Perhaps we can 
extend ptccrt to be able to return the whole ptc key event as well? It 
can be done, unfortunately, the Borland ReadKey/KeyPressed API wasn't 
designed to do that, so new functions appear to be necessary.




James

looking at the list of constants in ptcpas, i find PTCKEY_SHIFT... i also

find, in Classes, the IPTCKeyEvent which has a GetShift function as well as
a Shift

property... seems like you should be able to the shift status with

something like


type myKeyEvent : IPTCKeyEvent;
type myShiftStatus : boolean;
myShiftStatus := myKeyEvent.Shift;

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] BoolToStr

[Nikolay Nikolov via fpc-pascal]

On 8/29/22 11:33, Jean SUZINEAU via fpc-pascal wrote:

Le 29/08/2022 à 01:41, James Richters via fpc-pascal a écrit :
If a special function is needed for some COM thing or weird Winapi 
thing, then that function should be part of the unit that needs it, 
not modifying the generic function intended to be used for general 
purpose applications output something that does not conform to other 
Pascal Boolean datatypes and just confuses everyone.
Unfortunately, it's not just a few windows functions which use this 
behaviour but the whole Windows API:


https://docs.microsoft.com/fr-fr/windows/win32/api/winuser/nf-winuser-getmessage?redirectedfrom=MSDN 



The Microsoft BOOL datatype uses this convention so the whole 
ecosystem is attracted to use it (other C program on windows, Delphi, 
... )


I imagine it's more efficient at the assembler level to process the 
result of functions returning boolean.


Or, it could be related to the (Visual) BASIC language. BASIC represents 
false as 0 and true as -1, and Microsoft have been a major developer of 
BASIC interpreters and compilers ever since their beginning. My guess 
is, they used -1 to ensure better interoperability between Visual C++ 
and Visual Basic.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] PTCGraph window location

[Nikolay Nikolov via fpc-pascal]

On 3/12/22 15:54, James Richters via fpc-pascal wrote:


Is there some way I can set the location of the pctgraph window before 
it is created so it just pops up where I want it to be?I’m using 
Windows 10.


I’ve been re-locating it with SetWindowPos() which is ok if the window 
is going to be open for a while, but now I am trying to make a little 
program to display things and relocating the window is quite distracting.


It would also be nice to create the window without the title bar.

Currently, there's no way to do that. I'm planning to make it possible 
to change the title, without reopening the window, but I haven't thought 
about creating a window without a title, or moving it to a specific 
location. Btw, if the windows doesn't have a title, how can the user 
move it? Or do you want to move it manually, or just make it stay at a 
fixed location. These things are possible, but may be hard to do in a 
multi-platform way, e.g. in Linux, different window managers and desktop 
environments might ignore the location and place the window somewhere 
else. There are some crazy non-windows-like WMs there, like i3wm :)


Nikolay


James


___
fpc-pascal maillist  -fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Unicode chars losing information

[Nikolay Nikolov via fpc-pascal]

On 3/9/21 2:18 AM, Graeme Geldenhuys via fpc-pascal wrote:

On 08/03/2021 7:49 pm, Jonas Maebe via fpc-pascal wrote:

It's not possible to safely use unicodestring without
knowing how 16bit unicode works. The compiler can't solve that.

I disagree. Java does just that! The issue is the assumption of using
array indexing into the a string. I guess developers should stop doing
that.

The important point is:
But developer should be able to use Unicode strings without needing
to know the is and outs of Unicode and UTF-16 encoding. At least
that's what's possible with Java and other languages.


Yes, you absolutely need to know the ins and outs of Unicode in order to 
know how to extract the first character of a string. First of all, what 
is a character? A UTF-16 code unit, a Unicode code point or an extended 
grapheme cluster? Your Java code only does the expected thing for a 
certain subset of characters. If you write your code like that, you're 
going to think your code works, but it would fail on strings with either 
non-BMP characters (if you use charAt) or strings with combining 
characters (if you use codePointAt). To split the string into user 
perceived characters you need to do this in FPC trunk:


uses

  graphemebreakproperty, fpwidestring;

var

  EGC, S: UnicodeString;

begin

  S := '💩Хей, помисли́ си!';

  for EGC in TUnicodeStringExtendedGraphemeClustersEnumerator.Create(S) do
    Writeln(EGC);

end;


Can Java do that? No, it appears it can't:

https://stackoverflow.com/questions/40878804/how-to-count-grapheme-clusters-or-perceived-emoji-characters-in-java


Neither charAt, nor codePointAt will work for the 'и́'. CharAt will also 
fail at '💩'. Please correct me if I'm wrong, I didn't test this in Java.




FPC (and Delphi) really need to get with the times.


If by "get with the times" you mean always include the fpwidestring unit 
and still produce less bloat than the JVM, then sure, we can do that, 
but some people appreciate the flexibility of choosing your own wide 
string manager or not including it for programs that don't need it.


And for things like splitting a string into characters, you really need 
to know what you're doing anyway, since a Unicode codepoint very rarely 
corresponds to what users perceive as a character.


Nikolay


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Unicode chars losing information

[Nikolay Nikolov via fpc-pascal]

On 3/7/21 7:21 PM, Ryan Joseph via fpc-pascal wrote:



On Mar 7, 2021, at 10:11 AM, Marco van de Voort via fpc-pascal 
 wrote:


Yes it is. And there are about 1114000 unicode codepoints, or about 17 times 
what fits in a 2-byte wide char.

https://en.wikipedia.org/wiki/Code_point

https://en.wikipedia.org/wiki/UTF-16

I thought unicode strings "just worked" but maybe that's UTF-8 and the 
character I want is maybe UTF-16. What are you supposed to do then? UnicodeString knows 
how to print the full string so all the data is there but I can't index to get characters 
unless I know their size.


It depends on what you mean by "just working". UnicodeString is an 
UTF-16 encoded string and a WideChar is just a UTF-16 code unit. Both 
UTF-8 and UTF-16 are variable length encodings. UTF-16 is just more 
simple to decode. Note also that, even though a single Unicode codepoint 
might need two UTF-16 code units (i.e. WideChars), that is still not 
enough to represent what users perceive as a character. There are also 
plenty of Unicode combining characters. What most users perceive as a 
character is actually called an Extended Grapheme Cluster and is 
actually a sequence of Unicode code points. There's an algorithm (an 
enumerator) that splits a string into grapheme clusters, and that's 
implemented in FPC trunk in the GraphemeBreakProperty unit. It 
implements this algorithm:


http://www.unicode.org/reports/tr29/

This was done by me for the Unicode Free Vision port in the unicodekvm 
SVN branch, but it was already committed to trunk (the rest of the 
Unicode Free Vision still isn't), because it's a new unit that is 
relatively self-contained and provides new functionality (so, won't 
break existing code) that wasn't provided by the RTL before.


Note that normally, most programs wouldn't actually need to split a 
string into grapheme clusters, unless they implement something like a UI 
toolkit or a text editor or something of that sort. That's why it was 
needed for the Unicode Free Vision.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] PTCGraph Causing 217

[Nikolay Nikolov via fpc-pascal]

On 1/29/21 3:52 PM, Nikolay Nikolov wrote:



On 1/29/21 12:37 PM, James Richters wrote:


Any idea what’s causing this crash yet?Is there some way I can at 
least detect the error and handle it myself instead of crashing?


I'll take a look and try to reproduce it today or tomorrow. Sorry, 
I've been busy lately.


Ok, I reproduced it today. It appears that DirectX applications lose 
access to their DirectDraw surfaces when a UAC screen appears. Thanks, 
Microsoft! I'll need some time to provide a proper fix for that, but for 
now you can try this as a workaround. Create a text file, called 
ptcpas.cfg in your program's directory and type a single line in it:


GDI

This will disable the DirectX console and use GDI for rendering. This 
might be slower (although, you might not notice the difference on a 
modern PC), but should get rid of the problem. Please let me know if it 
doesn't work.


I'll try to get this fixed in the DirectX console as well, but that 
requires more careful analysis and testing on different versions of 
Windows, so it'll take some time.


Hope this helps,

Nikolay


James

**

**

*From:*fpc-pascal  *On 
Behalf Of *James Richters via fpc-pascal

*Sent:* Monday, January 11, 2021 9:37 AM
*To:* 'FPC-Pascal users discussions' 
*Cc:* James Richters ; 
'Nikolay Nikolov' 

*Subject:* Re: [fpc-pascal] PTCGraph Causing 217

I’ve made a sample program that demonstrates the problem

https://gist.github.com/Zaaphod/936901eb5f31df5044d2bd36a7cf6c91 
<https://gist.github.com/Zaaphod/936901eb5f31df5044d2bd36a7cf6c91>


When I was testing it, I found out that the problem shows up also 
with PTCCRT.Keypressed,


Procedure to re-produce bug in Putimage

1.Run program in Windows

2.Do something that activates Windows User Account Control like open 
an administrator command prompt


3.Program crashes with exitcode 217 EAccessViolation: Access 
violation on line 108 which is doing Putimage, even if you answer NO 
to user account control


Procedure to re-produce bug in Keypressed

1.UnComment //Until ptccrt.Keypressed;Comment out //Until 
ptccrt.Keypressed;


2.Run Program in Windows

3.Do something that activates Windows User Account Control like open 
an administrator command prompt


4.Program crashes with exitcode 217 EAccessViolation: Access 
violation on line 114 which is doing Keypresed (sometimes the error 
is on putimage)


Other things that cause it:

Unplug monitor and plug it back in

Change Display settings

Putting computer to sleep

Unknown reasons… system just idle

James

*From:*fpc-pascal <mailto:fpc-pascal-boun...@lists.freepascal.org>> *On Behalf Of 
*Nikolay Nikolov via fpc-pascal

*Sent:* Thursday, January 7, 2021 2:17 AM
*To:* fpc-pascal@lists.freepascal.org 
<mailto:fpc-pascal@lists.freepascal.org>

*Cc:* Nikolay Nikolov mailto:nick...@gmail.com>>
*Subject:* Re: [fpc-pascal] PTCGraph Causing 217

On 1/6/21 5:44 PM, James Richters via fpc-pascal wrote:

I’ve been having issues with PTCGraph causing a runtime Error 217
: EAccessViolation: Access violation at seemingly random times in
my program.The error is always on a line with either GetImage()
or PutImage() but not the same one.The program can run for hours
with no problems doing GetImage and PutImage every second or so,
and then it just stops with this error.

I know that if something disrupts the screen… like if I install a
program and the Windows user control thing asks for a password,
that ALWAYS causes this to happen, or if I unplug my monitor and
plug it back in…. I find that this happens.. but lately it seems
to happen for no reason.

I don’t know enough about it to track it down, but is there some
way I Can find out what causes this and prevent the error?It
would be nice if I could detect the condition that causes this
issue, and if I find that the issues is present, just stop trying
to do Getimage() or PutImage() until the condition is resolved.

Can you provide an example program and exact steps to reproduce this bug?

Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] PTCGraph Causing 217

[Nikolay Nikolov via fpc-pascal]

On 1/29/21 12:37 PM, James Richters wrote:


Any idea what’s causing this crash yet?Is there some way I can at 
least detect the error and handle it myself instead of crashing?


I'll take a look and try to reproduce it today or tomorrow. Sorry, I've 
been busy lately.


Nikolay


James

**

**

*From:*fpc-pascal  *On Behalf 
Of *James Richters via fpc-pascal

*Sent:* Monday, January 11, 2021 9:37 AM
*To:* 'FPC-Pascal users discussions' 
*Cc:* James Richters ; 
'Nikolay Nikolov' 

*Subject:* Re: [fpc-pascal] PTCGraph Causing 217

I’ve made a sample program that demonstrates the problem

https://gist.github.com/Zaaphod/936901eb5f31df5044d2bd36a7cf6c91 
<https://gist.github.com/Zaaphod/936901eb5f31df5044d2bd36a7cf6c91>


When I was testing it, I found out that the problem shows up also with 
PTCCRT.Keypressed,


Procedure to re-produce bug in Putimage

1.Run program in Windows

2.Do something that activates Windows User Account Control like open 
an administrator command prompt


3.Program crashes with exitcode 217 EAccessViolation: Access violation 
on line 108 which is doing Putimage, even if you answer NO to user 
account control


Procedure to re-produce bug in Keypressed

1.UnComment //Until ptccrt.Keypressed;Comment out //Until 
ptccrt.Keypressed;


2.Run Program in Windows

3.Do something that activates Windows User Account Control like open 
an administrator command prompt


4.Program crashes with exitcode 217 EAccessViolation: Access violation 
on line 114 which is doing Keypresed (sometimes the error is on putimage)


Other things that cause it:

Unplug monitor and plug it back in

Change Display settings

Putting computer to sleep

Unknown reasons… system just idle

James

*From:*fpc-pascal <mailto:fpc-pascal-boun...@lists.freepascal.org>> *On Behalf Of 
*Nikolay Nikolov via fpc-pascal

*Sent:* Thursday, January 7, 2021 2:17 AM
*To:* fpc-pascal@lists.freepascal.org 
<mailto:fpc-pascal@lists.freepascal.org>

*Cc:* Nikolay Nikolov mailto:nick...@gmail.com>>
*Subject:* Re: [fpc-pascal] PTCGraph Causing 217

On 1/6/21 5:44 PM, James Richters via fpc-pascal wrote:

I’ve been having issues with PTCGraph causing a runtime Error 217
: EAccessViolation: Access violation at seemingly random times in
my program.The error is always on a line with either GetImage() or
PutImage() but not the same one.The program can run for hours with
no problems doing GetImage and PutImage every second or so, and
then it just stops with this error.

I know that if something disrupts the screen… like if I install a
program and the Windows user control thing asks for a password,
that ALWAYS causes this to happen, or if I unplug my monitor and
plug it back in…. I find that this happens.. but lately it seems
to happen for no reason.

I don’t know enough about it to track it down, but is there some
way I Can find out what causes this and prevent the error?It would
be nice if I could detect the condition that causes this issue,
and if I find that the issues is present, just stop trying to do
Getimage() or PutImage() until the condition is resolved.

Can you provide an example program and exact steps to reproduce this bug?

Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] PTCGraph Causing 217

[Nikolay Nikolov via fpc-pascal]

On 1/6/21 5:44 PM, James Richters via fpc-pascal wrote:


I’ve been having issues with PTCGraph causing a runtime Error 217 : 
EAccessViolation: Access violation at seemingly random times in my 
program.The error is always on a line with either GetImage() or 
PutImage() but not the same one.The program can run for hours with no 
problems doing GetImage and PutImage every second or so, and then it 
just stops with this error.


I know that if something disrupts the screen… like if I install a 
program and the Windows user control thing asks for a password, that 
ALWAYS causes this to happen, or if I unplug my monitor and plug it 
back in…. I find that this happens.. but lately it seems to happen for 
no reason.


I don’t know enough about it to track it down, but is there some way I 
Can find out what causes this and prevent the error?It would be nice 
if I could detect the condition that causes this issue, and if I find 
that the issues is present, just stop trying to do Getimage() or 
PutImage() until the condition is resolved.



Can you provide an example program and exact steps to reproduce this bug?

Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TurboVision is reborn as FOSS (again)

[Nikolay Nikolov via fpc-pascal]

On 12/22/20 2:39 AM, Karoly Balogh (Charlie/SGR) via fpc-pascal wrote:

Hi,

On Mon, 21 Dec 2020, Sven Barth via fpc-pascal wrote:


As long as one knows why a certain temporal construct is used there is
no problem and at least in Germany (or more specifically Bavaria) we
were taught that in masses.

As a native speaker of a language which only has three tenses and no
grammatical gender, it's difficult to decide if the twelve tenses of
English, or the three genders of German are the more confusing. :P
(Probably still the latter, tho'... ;) )

Anyway, any interest to develop Free Vision further is very welcome one,
so we can move it from past tense to a future one. I still think text mode
UI for console and terminals still has a place, but sadly the current FV
implementation doesn't necessarily plays well on some Un*x terminals (it's
highly dependent on the font, and many other factors), also a mono mode is
sorely missing, which is a problem for both some modern and retro use
cases. And yeah, on the high-end, Unicode would be needed.


Speaking of Unicode, I have started working on adding Unicode support to 
the keyboard, video and mouse units (which are used internally by FV) in 
the unicodekvm branch. So, if anyone is interested in adding Unicode 
support to FV, take a look at this branch.


Nikolay



Charlie

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TurboVision is reborn as FOSS (again)

[Nikolay Nikolov via fpc-pascal]

On 12/21/20 10:42 AM, Markus Greim wrote:

FPC has had a Turbo Pascal-like console IDE for many years...

"has had" ?

AKAIK "has"

I still used it yesterday.


English is not my native language, but I think "has had" means it still 
has it. If I had said "had" instead of "has had", it would mean it had 
it in the past, but no longer has it. Please correct me if I'm wrong.


Nikolay



Grüße

Markus
Sent from Front
On December 20, 2020, 7:33 PM GMT+1 fpc-pascal@lists.freepascal.org 
 wrote:



On 12/19/20 6:35 PM, Liam Proven via fpc-pascal wrote:


> https://github.com/magiblot/tvision 


>
> Someone enterprising could make a TurboPascal clone out of FPC. :-)
>
Meh. FPC has had a Turbo Pascal-like console IDE for many years. It 
uses Free Vision, which is a pascal port of the C++ version of Turbo 
Vision (because Borland didn't release their Pascal version under a 
free/open source license).


https://wiki.freepascal.org/Free_Vision#Turbo_Vision 



Nikolay

___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org 

https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TurboVision is reborn as FOSS (again)

[Nikolay Nikolov via fpc-pascal]

On 12/19/20 6:35 PM, Liam Proven via fpc-pascal wrote:

https://github.com/magiblot/tvision

Someone enterprising could make a TurboPascal clone out of FPC. :-)

Meh. FPC has had a Turbo Pascal-like console IDE for many years. It uses 
Free Vision, which is a pascal port of the C++ version of Turbo Vision 
(because Borland didn't release their Pascal version under a free/open 
source license).


https://wiki.freepascal.org/Free_Vision#Turbo_Vision

Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] PTC Graph - Custom window sizes

[Nikolay Nikolov via fpc-pascal]

On 11/19/20 11:40 PM, James Richters wrote:

So far it's working great!But now I have another question... Since I can 
now have a small little PTCGraph window... is there any possibility of having 
more than one in the same program?  Perhaps running each window in a different 
thread? Or is there something fundamental that prevents this?


That would require rewriting the entire graph unit interface, which is a 
legacy from Turbo Pascal and is designed with full screen graphics on a 
single display in mind. In other words, it would be a new library, and 
not ptcgraph anymore. The problem is, there is currently no concept for 
a graphics or window context. When you call a graphics function, it 
draws to the screen. If you have multiple windows, then each window is 
like a separate screen, and then how can each function know which window 
it should draw into? This means a major API change is required (adding 
extra parameters, or redesigning the API entirely, using classes), which 
would break backward compatibility. And at this point, if you need 
multiple windows, you can probably switch to using the Lazarus LCL and 
create a proper GUI app, since your app will need to be rewritten anyway 
as a multi-window app.


Nikolay



James

-Original Message-
From: fpc-pascal  On Behalf Of James 
Richters via fpc-pascal
Sent: Thursday, November 19, 2020 1:49 PM
To: 'FPC-Pascal users discussions' 
Cc: James Richters ; 'Nikolay Nikolov' 

Subject: Re: [fpc-pascal] PTC Graph - Custom window sizes

Thank you very much Nikolay!  I will test it and let you know the results.

James


-Original Message-
From: fpc-pascal  On Behalf Of Nikolay 
Nikolov via fpc-pascal
Sent: Thursday, November 19, 2020 1:07 PM
To: fpc-pascal@lists.freepascal.org
Cc: Nikolay Nikolov 
Subject: Re: [fpc-pascal] PTC Graph - Custom window sizes


On 11/19/20 7:37 PM, Nikolay Nikolov wrote:

On 11/19/20 3:44 PM, James Richters via fpc-pascal wrote:

I've been using PTCGraph from PTCPas and so far I can only use
windows sizes that there happens to be a display driver for,  even if
they are in a window.. so I can make a 640x480 or 1024x768 window,
but if I have a screen in a vertical configuration now I can't get a
640x480 window, I can only get a 480x640 window because with the
screen vertical, only vertical orientation graphics drivers are
available.There are times I want a totally custom size window as
well,  like a 100x50.  I see a lot of procedure like
ptc_Init640x480x32bpp with all kinds of configurations of screen
resolutions and color densities, but there is also some named
ptc_InitNonStandard32k.. with other color densities.. but I don't
know how to initialize PTCGraph into my own custom window size.
Does anyone know how I could make my PTCGraph windows a custom weird
size that doesn't necessarily match the available video drivers?

It's not possible with the current implementation, but right now I'm
working on a patch that would make this possible. I'll post here when
it's ready for testing.

Implemented and committed in ptcpas and fpc trunk. The new function is called 
InstallUserMode:

function InstallUserMode(Width, Height: SmallInt; Colors: LongInt;
HardwarePages: SmallInt; XAspect, YAspect: Word): smallint;

Example use:

uses
{$ifdef UNIX}cthreads,{$endif} ptcgraph, ptccrt; var
gd, gm: SmallInt;
begin
gd := VESA;
gm := InstallUserMode(100, 160, 16, 1, 1, 1);
if gm < 0 then
begin
  Writeln(ErrOutput, 'Error installing user mode: ', GraphErrorMsg(gm));
  Halt(1);
end;
InitGraph(gd, gm, '');
OutText('Hello!');
ReadKey;
CloseGraph;
end.

It supports adding modes with 16, 256, 32768, 65536 and 16777216 colors with a custom X 
and Y resolution, custom number of hardware pages (for use with SetActivePage and 
SetVisualPage) and a custom pixel aspect ratio (used for drawing circles instead of 
ellipses on displays without square pixels - for square pixels, use "1, 
1").

Please test. :)

Best regards,

Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] PTC Graph - Custom window sizes

[Nikolay Nikolov via fpc-pascal]

On 11/19/20 7:37 PM, Nikolay Nikolov wrote:


On 11/19/20 3:44 PM, James Richters via fpc-pascal wrote:
I've been using PTCGraph from PTCPas and so far I can only use 
windows sizes that there happens to be a display driver for,  even if 
they are in a window.. so I can make a 640x480 or 1024x768 window,  
but if I have a screen in a vertical configuration now I can't get a 
640x480 window, I can only get a 480x640 window because with the 
screen vertical, only vertical orientation graphics drivers are 
available.    There are times I want a totally custom size window as 
well,  like a 100x50.  I see a lot of procedure like 
ptc_Init640x480x32bpp with all kinds of configurations of screen 
resolutions and color densities, but there is also some named 
ptc_InitNonStandard32k.. with other color densities.. but I don't 
know how to initialize PTCGraph into my own custom window size.   
Does anyone know how I could make my PTCGraph windows a custom weird 
size that doesn't necessarily match the available video drivers?


It's not possible with the current implementation, but right now I'm 
working on a patch that would make this possible. I'll post here when 
it's ready for testing.


Implemented and committed in ptcpas and fpc trunk. The new function is 
called InstallUserMode:


function InstallUserMode(Width, Height: SmallInt; Colors: LongInt; 
HardwarePages: SmallInt; XAspect, YAspect: Word): smallint;


Example use:

uses
  {$ifdef UNIX}cthreads,{$endif} ptcgraph, ptccrt;
var
  gd, gm: SmallInt;
begin
  gd := VESA;
  gm := InstallUserMode(100, 160, 16, 1, 1, 1);
  if gm < 0 then
  begin
    Writeln(ErrOutput, 'Error installing user mode: ', GraphErrorMsg(gm));
    Halt(1);
  end;
  InitGraph(gd, gm, '');
  OutText('Hello!');
  ReadKey;
  CloseGraph;
end.

It supports adding modes with 16, 256, 32768, 65536 and 16777216 colors 
with a custom X and Y resolution, custom number of hardware pages (for 
use with SetActivePage and SetVisualPage) and a custom pixel aspect 
ratio (used for drawing circles instead of ellipses on displays without 
square pixels - for square pixels, use "1, 1").


Please test. :)

Best regards,

Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] PTC Graph - Custom window sizes

[Nikolay Nikolov via fpc-pascal]

On 11/19/20 3:44 PM, James Richters via fpc-pascal wrote:

I've been using PTCGraph from PTCPas and so far I can only use windows sizes 
that there happens to be a display driver for,  even if they are in a window.. 
so I can make a 640x480 or 1024x768 window,  but if I have a screen in a 
vertical configuration now I can't get a 640x480 window, I can only get a 
480x640 window because with the screen vertical, only vertical orientation 
graphics drivers are available.There are times I want a totally custom size 
window as well,  like a 100x50.  I see a lot of procedure like 
ptc_Init640x480x32bpp with all kinds of configurations of screen resolutions 
and color densities, but there is also some named ptc_InitNonStandard32k.. with 
other color densities.. but I don't know how to initialize PTCGraph into my own 
custom window size.   Does anyone know how I could make my PTCGraph windows a 
custom weird size that doesn't necessarily match the available video drivers?


It's not possible with the current implementation, but right now I'm 
working on a patch that would make this possible. I'll post here when 
it's ready for testing.


Nikolay

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal