Re: [fpc-pascal] download site and mixed http

[Tomas Hajny via fpc-pascal]

On 2024-04-25 15:16, Mattias Gaertner via fpc-pascal wrote:



Hi Matthias,


On
https://www.freepascal.org/down/x86_64/linux-hungary.html

are links without "https://;, causing the browser to bark:

"File not downloaded: Potential security risk".


Thanks for reporting it. In addition, the Canadian mirror apparently 
isn't available any longer. Fixing both issues shouldn't be difficult, 
but I'd like to check the mirror situation first (in particular, if 
there's still some other working mirror at all).


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

Re: [fpc-pascal] AnsiString address changed

[Tomas Hajny via fpc-pascal]

On 2024-03-18 13:29, Hairy Pixels via fpc-pascal wrote:
On Mar 18, 2024, at 5:29 PM, Michael Van Canneyt via fpc-pascal 
 wrote:


Of course there must be, that's the whole point of copy-on-write.

As soon as one reference is changed, a copy is made if the reference 
count

is larget than 1, and this copy is changed.


Oh, it does copy on write. I see now that by looking at the pointer 
addresses.


So what happens if you do this? s2 is pointing to s1 but then you
change the size of s1 and ReAllocMem gets called and invalidates the
pointer to the original s1. How does s2 know this and not access
corrupted memory now?

  s1 := '123';
  s2 := s1;
  s1 := '';


From user point of view, the result is the same as when s1 and s2 are 
declared as shortstring (i.e. s2 = '123' and s1 = 'x'). From 
technical point of view, the original location is used for s2 (with 
reference count 1), whereas s1 points to a new location (with reference 
count also 1 at that point in time).


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

Re: [fpc-pascal] FP IDE sources

[Tomas Hajny via fpc-pascal]

On 2024-03-14 11:06, Marco van de Voort via fpc-pascal wrote:

Op 14-3-2024 om 11:04 schreef Michael Van Canneyt via fpc-pascal:



To me it therefore seems a better idea to move the IDE to utils, and 
to have a
toplevel make command that does the same as 'make all' simply without 
the

utilities. Or have a 'NOUTILS=1' define.


Or let fpmake simply build the union of packages and utils in
parallel. So separate directories, but one build stage


Well, whatever. I remember having raised the same question in the past 
(indeed - on the 5th of February 2020 at 1:30am ;-) on the core list) 
and this is what I got... I even explicity raised the point also 
mentioned by Michael now (quoting my follow-up mail on the same day):


"OK, that would be addressed in case of inclusion under utils as well. 
Even more so, actually - users who want to recompile packages for 
whatever reason (e.g. to have debug information included as discussed 
here recently ;-) ) aren't probably interested in waiting for rebuilding 
of the IDE at all."


However, Michael refused to move it to utils at that point in time in 
order not to delay the release. ;-)


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

Re: [fpc-pascal] FP IDE sources

[Tomas Hajny via fpc-pascal]

On 2024-03-14 09:34, Guillermo Martínez Jiménez via fpc-pascal wrote:

Thanks, Karoly and Marco.

I thought "packages" were libraries not applications, as there is an
"utils" directory with programs.


Well, yes, it's somewhat confusing admittedly. The IDE sources used to 
be located at the higher level (i.e. next to the packages, rtl, etc.) in 
the past. They were moved to packages as part of the transition to using 
fpmake for compilation of most of FPC sources in order to allow having 
it compiled in parallel to other big packages (since IDE is probably the 
biggest one taking the longest time to compile). Having it in packages 
allows compiling it in parallel to other packages; since utils are 
compiled independently (and much quicker), moving IDE in utils would 
result in longer compilation time overall (if parallel compilation is 
allowed).


Tomas




El Wed, 13 Mar 2024 22:45:19 +0100
Marco van de Voort via fpc-pascal 
escribió:

Op 13-3-2024 om 21:34 schreef Karoly Balogh via fpc-pascal:
> H
>
> Where are they?  Why aren't with the official source packages?
> But they are. The IDE code is here:
> https://gitlab.com/freepascal.org/fpc/source/-/tree/main/packages/ide
>
> It also depends on Free Vision, which is here:
> https://gitlab.com/freepascal.org/fpc/source/-/tree/main/packages/fv
>
> The ASCII table code is part of Free Vision, and it's here:
> 
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/fv/src/asciitab.pas
>
And the mouse-keyboard-video drivers are in package rtl-console, e.g.
for windows


https://gitlab.com/freepascal.org/fpc/source/-/tree/main/packages/rtl-console/src/win

___
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] Floating point question

[Tomas Hajny via fpc-pascal]

On 2024-02-22 15:08, Thomas Kurz via fpc-pascal wrote:
If you're using Win64, then the answer is simple: x86_64-win64 unlike 
any
other x86 target does not support Extended, so neither the compiler 
nor the

code in runtime will ever calculate anything with that precision.


That's another thing I've never understood. How can it depend on the
OS? It's the CPU which does math, and I don't understand what the OS
has to do with that? If amd64 architecture didn't support the
extended-type at all, I'd say "ok". But it's supported on Linux but
not on Windows? Huh?


The reason is that the operating system is among others responsible for 
controlling the multitasking. That includes saving the context of the 
originally active task and restoring the context of the new task to the 
original state before it was interrupted. If Win64 doesn't guarantee 
restoring FPU registers specific to the extended type, using this type 
would get you into troubles despite its support in the FPU.


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

Re: [fpc-pascal] Floating point question

[Tomas Hajny via fpc-pascal]

On 2024-02-20 08:03, Sven Barth via fpc-pascal wrote:

James Richters via fpc-pascal 
schrieb am Di., 20. Feb. 2024, 04:42:


I don't know why it would be different in Windows than on Linux.


If you're using Win64, then the answer is simple: x86_64-win64 unlike
any other x86 target does not support Extended, so neither the
compiler nor the code in runtime will ever calculate anything with
that precision.


Well, this probably isn't the (sole) reason in this particular case, 
because the results posted by Michael and coming from Linux (probably 
x86_64) were equal for constants and variables, but less precise than 
the result of run-time posted for Windows (unfortunately without 
specifying whether it was i386-win32 or x86_64-win64, but I'd guess for 
the former based on the results - exactly due to the reason mentioned by 
you).


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

Re: [fpc-pascal] Nested comments.

[Tomas Hajny via fpc-pascal]

On 2024-01-21 13:21, Guillermo Martínez Jiménez via fpc-pascal wrote:


Hi,


I'm wondering if it is possible to make FPC detect and warn (or even
stop compillation when) it has detect a nested comment.  That's because
I'm using Vim and it closes odd comments.  For example, the nex code:

{ This comment isn't closed. *)
  DoSomething ();
{ This is a nested comment. }

I know this is a silly mistake, but sometimes I comment batchs of codde
to deactivate them temporary and when un-comment they're non paired and
it result in weird runtime bugs.

A command line option that activate that functionality would be great.
Something like -wn (because -vn is used for notes).

What do you thing?


Well, I guess that you use mode Delphi, because warning about nested 
comments and even an error in your case (due to nested comment not 
closed) is already issued by default. So the very simple solution is 
using e.g. -Mobjfpc. ;-)


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

Re: [fpc-pascal] Quiz

[Tomas Hajny via fpc-pascal]

On 2024-01-07 20:47, Michael Van Canneyt via fpc-pascal wrote:

On Sun, 7 Jan 2024, Adriaan van Os via fpc-pascal wrote:

 .
 .

There is some special handling for 1. (ending with a dot) due to
Delphi/TP compatibility, they accept it.

 .
 .

   kr5   = 1 . e + 2;


Same as kr1, but not accepted by Delphi.


Personally, I don't think that a dot directly following a number is the 
same as a dot separated from the number by a space. TP/BP doesn't accept 
the latter (i.e. kr5).




   kr6   = 1 . 0 e + 2;


kr6 does not compile, although I don't see why if kr5 is accepted..


Well, I'm not sure whether kr5 should be accepted, but anyway, there are 
IMHO two problems here - the second one being the space before the 
exponent marker.




   kr8   = 1.0 e + 2;


kr8 Does not compile, probably same reason as kr6. Delphi does not 
accept it.


TP/BP requires the exponent marker (i.e. "e") to follow the number 
directly. Spaces in the exponent part are allowed, but not before "e".


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

Re: [fpc-pascal] Strings greater than 255 characters

[Tomas Hajny via fpc-pascal]

On 2023-12-19 12:36, James Richters via fpc-pascal wrote:


Hello James,


I keep getting bit by using STRING variables then trying to store more
than 255 characters.

My typical way to fix this is to just change it to an ANSISTRING.

I'm wondering if there is any reason not to do this the other way
around and just go through

 .
 .

You may be surprised, but FPC (and even earlier also Delphi) provides 
you with multiple ways allowing you to use variables declared as 
"string" without length limits (i.e. using type ansistring or 
unicodestring underneath). There are compiler directives {$H+} and 
{$UNICODESTRINGS} doing exactly that, and there are also modes {$MODE 
DELPHI} and {$MODE DELPHIUNICODE} which (among others) trigger the 
previously mentioned compiler directives (the difference is that the 
modes have wider impact, not only the underlying type used for 
variables, parameters, etc., of type string).


In order to answer you question about potential reasons for not using 
ansistring or unicodestring for everything, it's useful to understand 
the associated differences:


1) Ansistring and Unicodestring are reference counted. This brings some 
computational overhead potentially impacting performance - this may not 
be important in many cases, but there are also cases for which this may 
be very important.


2) Ansistring and Unicodestring are technically pointers to structures 
allocated on the heap rather than directly storing the string itself 
with preallocated number of characters. There are scenarios for which 
this difference is important (e.g. when interfacing with operating 
system API calls or 3rd party code in general).


3) There are some other smaller differences impacting compatibility with 
code designed to work with type shortstring (e.g. related to used 
character sets etc.).


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

Re: [fpc-pascal] Cannot build fpc on Raspberry Pi4B running PiOS 64 bit (aarch64 Linux)

[Tomas Hajny via fpc-pascal]

On November 21, 2023 8:33:55 +0100, Bo Berglund via fpc-pascal 
 wrote:

 .
 .
>Here I lost you, is SF still in use? I thought that everything moved to GitLab
>some time ago?

SF is still used for distribution of releases, see download links on FPC web 
pages. This has nothing to do with migration of the source code repositories to 
GitLab - we never used SF for hosting our source code repositories.


>And is there something like "install" in Linux apart from apt install which is
>what I used?

Well, yes, you can obviously still provide installation packages independently 
from your distribution which may be delayed due to different release cycles.


 .
 .
>I always put my sources in a place like $HOME/devtools/fpc/x.y.z and
>$HOME/devtools/lazarus/x.y.z

That's fine.


 .
 .
>When installing from sources you have a hen-and-egg problem since you need a
>seed compiler on the pristine target system.

Yes, but we provide not only seed compilers (for some platforms), but also 
(more importantly) full FPC releases and also snapshots.


 .
 .
>I did not know that there is a library of seed compilers available on
>Sourceforge, I thought everything had moved over to GitLab nowadays, so where
>exactly can I find a binary download for PiOS 64 bit on SF?
>Where I have looked I only find old stuff like from 2021...
>
>https://sourceforge.net/projects/freepascal/files/Linux/3.2.2/
>Here are tarballs that by the size seem to contain a lot of stuff apart from 
>the
>compiler itself.

Yes, there are full official releases provided by the FPC team and used by many 
FPC users.

Tomas

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

Re: [fpc-pascal] SeekEof issue & 2020 blog post by A Stolyarov

[Tomas Hajny via fpc-pascal]

On 2023-09-11 11:08, Alexey Torgashin via fpc-pascal wrote:
Translation of blog post http://www.stolyarov.info/node/290 from Ru to 
En.

Sep 6 2020.
Author: Andrey Stolyarov, author of Ru books about programming.

 .
 .
Q (reader): Judging by the state of the ticket, has success been 
achieved?

A (Stolyarov): To be honest, it's not clear - you'll have to pull out
a snapshot and see. I really hope that this Tomas Hajny didn't
understand what happens when you open a text stream and ended up not
being able to do what he wanted to do -- cut off buffering for
anything that isn't a file. If he succeeded, then "the victory has

 .
 .

"This Tomas Hajny" still believes that a user having a different opinion 
on a certain thing doesn't automatically prove that his different view 
is wrong. "This Tomas Hajny" tried to provide reasoning on his position 
- among others, "this Tomas Hajny" still values consistency among 
supported platforms and consideration of various use cases more than 
opinions of people only interested in their particular use case on one 
particular platform. "This Tomas Hajny" also sees that FPC RTL already 
provides variety of possibilities for achieving what the user having a 
different opinion intends to achieve. "This Tomas Hajny" understands 
that different people may differ in priorities of various arguments 
which is why he consulted the topic among the FPC core team. On top of 
that, "this Tomas Hajny" has by no means exclusive access to changing 
FPC RTL, i.e. any other member of the FPC core team may have decided to 
change the implementation according to preferences of the user having a 
different opinion.


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

Re: [fpc-pascal] Program crash - read the error messages

[Tomas Hajny via fpc-pascal]

On 2023-09-01 17:39, Rainer Stratmann via fpc-pascal wrote:

Ah, sorry. I Forgot it totally.

It is a plain console program under Linux.

Yes, the remaining program starts the crashing one and I would like to 
check

the results? Yes, a run-time error was there.

I start the program with a console command.

An unhandled exception occured at $0814EC41:
EAccessViolation:  Access violation
  $0814EC41
  ...
  ...
  ...

This messages I need to read automatically


OK. You still missed to provide information on how you start the 
crashing program from the remaining program - certain approaches don't 
allow simple access to the result (e.g. checking whether it's still 
running or accessing the process exit code), whereas others do. However, 
in general, you need to redirect the output and stderr handles (e.g. to 
a pipe if doing it under Linux, but a file would do as well) and read 
them from the remaining program. As an example, TProcess (in unit 
Process) provides means for all of this.


Tomas





Am Freitag, 1. September 2023, 16:13:54 CEST schrieb Tomas Hajny via 
fpc-

pascal:

On 2023-09-01 15:43, Rainer Stratmann via fpc-pascal wrote:


Hello,

> Where can I find the output of the error messages if a program crashes.
>
> There is another program that still is running.
> I want to read the error messages automatically if that is possible.

I'm afraid that we'd need a bit more information on what is your
situation and what you try to achieve. In particular:

1) What kind of an application is your program (console, GUI, ...),
under which operating system?

2) You mention that there is another program that is still running - 
do

you mean that the remaining program starts the crashing one and you
would like to check the results? If this is the case, how you start 
the

program (Dos.Exec, SysUtils.ExecuteProcess, Process.TProcess, ...)?

3) What do you mean if you say "crashes" - a run-time error? Or a GUI
message box stating that the program crashed? Or...?

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

Re: [fpc-pascal] Program crash - read the error messages

[Tomas Hajny via fpc-pascal]

On 2023-09-01 15:43, Rainer Stratmann via fpc-pascal wrote:


Hello,


Where can I find the output of the error messages if a program crashes.

There is another program that still is running.
I want to read the error messages automatically if that is possible.


I'm afraid that we'd need a bit more information on what is your 
situation and what you try to achieve. In particular:


1) What kind of an application is your program (console, GUI, ...), 
under which operating system?


2) You mention that there is another program that is still running - do 
you mean that the remaining program starts the crashing one and you 
would like to check the results? If this is the case, how you start the 
program (Dos.Exec, SysUtils.ExecuteProcess, Process.TProcess, ...)?


3) What do you mean if you say "crashes" - a run-time error? Or a GUI 
message box stating that the program crashed? Or...?


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

Re: [fpc-pascal] Pointer question

[Tomas Hajny via fpc-pascal]

On August 10, 2023 at 0:06:57 +0200, Hairy Pixels via fpc-pascal 
 wrote:
>> On Aug 9, 2023, at 2:54 PM, Tomas Hajny via fpc-pascal 
>>  wrote:
>> 
>>> 
>>> 1) what does "i := x - x;" do and what is it's purpose and why doesn't "x + 
>>> x" work the same?
>> 
>> Pointer subtraction is a reverse operation to adding a number to a pointer; 
>> the result of the subtraction is the offset between the two pointers.
>
>Is that different than decrementing the pointer?
>
>What would an offset between two pointers be used for? Is the offset even a 
>memory address or just a number of bytes? If you had an example usage that 
>would be interesting to see.

No, the offset is not a memory address but just a number of bytes (which is 
also the reason why you cannot add the pointers together, but you can add a 
number to a pointer. As an example, you could use this operation to find out 
the exact alignment of fields within a record (to check whether there's some 
padding inserted between them) - e.g. if you aren't sure what alignment 
directive was used for compiling a unit declaring the structure, or to 
understand the compiler behaviour for a particuler alignment directive..


>>> 2) I've used pointer equality of course but what does "x > p" do and what 
>>> is its purpose?
>> 
>> Relative position between the two locations in memory? As an example, it may 
>> be used to check whether a particular pointer points to a location between 
>> the start and the end of an allocated memory block (obviously, you'd need 
>> two comparisons for that).
>
>I guess that makes sense if a memory address with a higher value is always 
>after an address with a lower value. Is that assumption always true?

I believe that this is indeed guaranteed (at least as long as linear pointers 
are concerned, but Pascal pointer is IMHO always linear - as opposed to a 
farpointer using a segmented model or a combination of a selector and an offset.

Tomas

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

Re: [fpc-pascal] Pointer question

[Tomas Hajny via fpc-pascal]

On August 9, 2023 at 22:14:17 +0200, Hairy Pixels via fpc-pascal 
 wrote:
>Playing around I had a more questions about pointer operations I've never used 
>myself.
>
>1) what does "i := x - x;" do and what is it's purpose and why doesn't "x + x" 
>work the same?

Pointer subtraction is a reverse operation to adding a number to a pointer; the 
result of the subtraction is the offset between the two pointers.


>2) I've used pointer equality of course but what does "x > p" do and what is 
>its purpose?

Relative position between the two locations in memory? As an example, it may be 
used to check whether a particular pointer points to a location between the 
start and the end of an allocated memory block (obviously, you'd need two 
comparisons for that).

Tomas

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

Re: [fpc-pascal] msdos: unresolved external

[Tomas Hajny via fpc-pascal]

On 2023-07-12 12:27, Thomas Kurz via fpc-pascal wrote:

I have to extend code from QuickBasic and am using the "msdos" target
from FPC 3.2 for that purpose. The resulting exe file is linked with
Microsoft Linker for DOS version 5.10. It links *.a files created both
from QuickBasic and FPC. The memory model is i8086-small.

Basically, it works well.

I have to use file functions now (Assign, Reset, Close) and as soon as
I start using any of these, linking fails with the following
unresolved dependencies:

Z:\SYSTEM.LIB(prt0s.asm) : error L2029: '__stklen' : unresolved 
external
Z:\SYSTEM.LIB(prt0s.asm) : error L2029: 'PASCALMAIN' : unresolved 
external

Z:\SYSTEM.LIB(prt0s.asm) : error L2029: '___heap' : unresolved external
Z:\SYSTEM.LIB(system0s896.o) : error L2029: 'INITFINAL' : unresolved 
external
Z:\SYSTEM.LIB(prt0s.asm) : error L2029: '___stacktop' : unresolved 
external

Z:\SYSTEM.LIB(prt0s.asm) : error L2029:
'__fpc_stackplusmaxheap_in_para' : unresolved external


Which *.a files and *.o files did you include for linking and how did 
you compile the FPC part (which parameters)?



 .
 .

Note that I'm *not* compiling and linking the full program with FPC,
I'm only developing parts of it. The main part comes from QuickBasic.
But as FPC is able to build fully working MS-DOS executables in which
(I assume) it needs the criticized external dependencies as well, they
should exist somewhere, shouldn't they? But what do I need to link
against for them to be included?


They're part of the main executable (i.e. FPC compiled program). As an 
example, PASCALMAIN is the entry point of the FPC program. The trouble 
is that you don't create a FPC program here. However, you must still 
ensure initialization (and finalization) of the FPC RTL. On other 
platforms/targets, you'd do this by creating a DLL/shared library, but 
that is not supported for the msdos target. You might try creating a 
simple FPC program using your units, compiling with -s and checking the 
list of *.o and *.a files included in the generated linker response 
file.


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

Re: [fpc-pascal] Parse unicode scalar

[Tomas Hajny via fpc-pascal]

On 3 July 2023 9:12:03 +0200, Hairy Pixels via fpc-pascal 
 wrote:
>> On Jul 3, 2023, at 2:04 PM, Tomas Hajny via fpc-pascal 
>>  wrote:
>> 
>> No - in this case, the "header" is the highest bit of that byte being 0.
>
>Oh it's the header BIT. Admittedly I don't understand how this function 
>returns the highest bit using that case, which I think he was suggesting.
>
>function UTF8CodepointSizeFast(p: PChar): integer;
>begin
> case p^ of
>   #0..#191   : Result := 1;
>   #192..#223 : Result := 2;
>   #224..#239 : Result := 3;
>   #240..#247 : Result := 4;
>   else Result := 1; // An optimization + prevents compiler warning about 
> uninitialized Result.
> end;
>end;

That's why I wrote "in this case". The "header" itself is not fixed size 
either, but the algorithm above shows how you can derive the length from the 
first byte.

Tomas

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

Re: [fpc-pascal] Parse unicode scalar

[Tomas Hajny via fpc-pascal]

On 3 July 2023 8:42:05 +0200, Hairy Pixels via fpc-pascal 
 wrote:
>> On Jul 3, 2023, at 12:04 PM, Mattias Gaertner via fpc-pascal 
>>  wrote:
>> 
>> No, the header of a codepoint to figure out the length.
>
>so the smallest character UTF-8 can represent is 2 bytes? 1 for the header and 
>1 for the character? 
>
>ASCII #100 is the same character in UTF-8 but it needs a header byte, so 2 
>bytes?

No - in this case, the "header" is the highest bit of that byte being 0.

Tomas

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

Re: [fpc-pascal] Pchar from constant string

[Tomas Hajny via fpc-pascal]

On 2023-06-30 11:11, Michael Van Canneyt via fpc-pascal wrote:

On Fri, 30 Jun 2023, Hairy Pixels via fpc-pascal wrote:




On Jun 30, 2023, at 9:03 AM, Hairy Pixels  
wrote:


That's why that worked. Hmm with short strings the null terminator 
could be truncated when copying right? Something to look out for.


this is what I meant about truncation. S is no longer null terminated 
and now the pchar will fail when passed to C libraries right?


var
 s: String;
 p: Pchar;
begin
s := 'hello';
p := @s;


S will still be null-terminated for ansistrings and shortstrings.

change to

  s:=s+s;
  p:=@s[1]; // and not @s
  writeln(p[Length(s)+1]=#0);

and it will print TRUE.


However, there are operations valid for Pascal shortstrings which would 
break this - as an example, older Pascal code used to change the S[0] 
(i.e. the length byte) for a shortstring which wouldn't ensure that #0 
follows such a moved end of the Pascal shortstring.


Moreover, note that #0 is a valid character in Pascal strings, i.e. in 
general it is _not_ guaranteed that the trailing #0 after the end of the 
string is the first one encountered when passing the string to a C code. 
Obviously, you can ensure this in your own code, but it's important to 
stress that neither the compiler nor the FPC RTL check or enforce full 
equivalence of Pascal strings and C null-terminated strings.


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

Re: [fpc-pascal] Pchar from constant string

[Tomas Hajny via fpc-pascal]

On 2023-06-29 16:22, Mattias Gaertner via fpc-pascal wrote:

On Thu, 29 Jun 2023 21:18:44 +0700
Hairy Pixels via fpc-pascal  wrote:


What is really happening in this snippet? I think it must be
implicitly taking the address of the constant string but is it also
adding the null terminator automatically? The string prints with
writeln so it must be null terminated right?

var
  p: Pchar;
begin
  p := '123';
  writeln(p);


AFAIK the trailing #0 is already stored in the binary.


Indeed - all constant strings are already terminated with #0. Note that 
this is not guaranteed for all string variables per se.


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

Re: [fpc-pascal] Legitimate use of for and break

[Tomas Hajny via fpc-pascal]

On 2023-06-18 03:04, Hairy Pixels via fpc-pascal wrote:

On Jun 18, 2023, at 1:07 AM, tsie...@softcon.com wrote:

This is interesting, because it's the first time I've ever seen 
"break" as a valid command in pascal, and I've been using pascal since 
the mid/late 80s.  All kinds of dialects too, and I've never seen 
break as a keyword.  C, Python, Perl, sure, even shell scripts, but 
pascal? Never seen it used before.  Is this a relatively new addition 
to fpc or something?


I don't remember break NOT being in Pascal. How did you exit a loop
otherwise, goto? Break is common in basically all languages now. Can't
think of a language I've used without it.


Obviously, loop is exited using the loop condition by default and that 
may be achieved without additional constructs, should it be break or 
goto. Yes, using break may be more elegant in certain cases, but that's 
another story.


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

Re: [fpc-pascal] Legitimate use of for and break

[Tomas Hajny via fpc-pascal]

On 17 June 2023 20:45:49 +0200, Jean SUZINEAU via fpc-pascal 
 wrote:
>Le 17/06/2023 à 20:07, Travis Siegel via fpc-pascal a écrit :
>> Is this a relatively new addition to fpc or something?
>
>I 've just found it in my Delphi 7 code (and code very likely written for 
>Delphi 4), so I think it's there since at least 2000-2001 ...
>
>May be it appeared with Delphi 1 ?

I believe it was added in TP/BP7.

Tomas

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

Re: [fpc-pascal] Wrong assignment detected only run time without warning

[Tomas Hajny via fpc-pascal]

On 2023-06-16 13:46, Giuliano Colla via fpc-pascal wrote:

Il 16/06/23 13:36, Peter B via fpc-pascal ha scritto:

Yes. Assigning a 64bit integer to a 32bit one is fine as long as the 
range is within bounds.

Range of a variable can only be checked at run time.


I can understand that. But the compiler generates quite a number of
warning for potential loss of information. In that case a little
warning wouldn't be excessive, I think.


If you compile with -CO, you should get at least a hint (if you enable 
displaying them, of course):


---
{$MODE OBJFPC}
uses
 SysUtils;

var
  ISize: Integer;
  SR: TSearchRec;

begin
 FindFirst ('XYZ', faAnyFile, SR);
 ISize := SR.Size;
 WriteLn (ISize);
end.
===

D:\TEMP>fpc -CO -vwih t.pas
Hint: Start of reading config file ...\fpc.cfg
Hint: End of reading config file ...\fpc.cfg
Free Pascal Compiler version 3.2.2 [2021/05/15] for i386
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling t.pas
t.pas(11,8) Hint: Type size mismatch, possible loss of data / range 
check error

Linking t.exe
13 lines compiled, 0.1 sec, 68800 bytes code, 4276 bytes data
3 hint(s) issued

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

Re: [fpc-pascal] Free Pascal bindings for EyeLink C code (with a god-cast)

[Tomas Hajny via fpc-pascal]

On 14 June 2023 20:59:41 +0200, "Rafael Picanço via fpc-pascal" 
 wrote:


Hi Rafael,

>I am trying to follow your advice and use units instead:
>
>const
>  EXTERNAL_DEV_NONE : TGetExButtonStatesFunction = Pointer(0);
>
>However I am receiving an error:
>
>Error: Incompatible types: got "Pointer" expected "of function(PCCDBS):LongInt;CDecl>"
>
>Please, can you shed some light on this?

I can't test it right now, but I believe that 

const
  EXTERNAL_DEV_NONE : TGetExButtonStatesFunction =
   
TGetExButtonStatesFunction (Pointer(0));

(i.e. with an explicit typecast to the required type) should work.

Tomas

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

Re: [fpc-pascal] Oberon-0

[Tomas Hajny via fpc-pascal]

On 2023-04-20 00:34, Ralf Quint via fpc-pascal wrote:

On 4/19/2023 1:06 AM, Markus Greim via fpc-pascal wrote:


 .
 .

A native Oberon0 to Propeller ASM compiler would be fine, but maybe
it would be easier to write first an Oberon0 to PropForth compiler.


What does Oberon and Forth have to do with the FreePascal compiler?



Thanks Ralf, that's a fair comment - I suggest moving possible 
continuation of this discussion to the fpc-other list.


Tomas
(one of FPC mailing list moderators)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] IRC channel for FreePascal support ?

[Tomas Hajny via fpc-pascal]

On 2023-04-18 11:12, Elmar Haneke via fpc-pascal wrote:

Just my comments on IRC-Channels.

 .
 .

Thanks for your input, but as already suggested previously, everybody 
interested in this topic should preferably use the fpc-other mailing 
list to keep this one available for discussion related to use of FPC 
itself rather than associated communication channels.


Thanks

Tomas
(one of FPC mailing list moderators)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] As I predicted

[Tomas Hajny via fpc-pascal]

On 2023-04-14 16:25, Steve Litt via fpc-pascal wrote:


Hi all,


As I predicted, here's what happened to me on #fpc:

==
Joanna sets ban on $a:stevelitt
* You have been kicked from #fpc by Joanna (sorry i cant share a
  channel with you after what you said in mailing list)
==

And here's what happens when I try to join #irc:

==
Cannot join #fpc (You are banned).
==

I'll be using #fpc-alt and ##fpc-alt from now on.


It's a pitty that this happened (and it's obvious that my response to 
the private message didn't have the expected result), but anyway - I'd 
like to ask everybody to direct potential responses and further 
discussion about the IRC channel and Joanna's moderation to the 
fpc-other mailing list.


Tomas
(one of FPC mailing list moderators)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] IRC channel for FreePascal support ?

[Tomas Hajny via fpc-pascal]

On 2023-04-14 09:43, Michael Van Canneyt via fpc-pascal wrote:


Hi,

 .
 .

I've been contacted as well by email.

I received a similar story, and after reading it I believe she (she
confirmed it is a female name) is sincere in her wish to keep the
channel free from trolls, so it appears to me (as an outsider, I am
not on IRC) she is simply a little overzealous in her moderation
activity.

I am not an IRC user, so I'll let Tomas handle the rest of the story.


I'm no IRC user either (and even less having any rights on the chat 
platform), but I responded to the private message sent by her in the 
forum and explained why I believe that her moderation style deserves 
some reconsideration.


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

Re: [fpc-pascal] IRC channel for FreePascal support ?

[Tomas Hajny via fpc-pascal]

On 13 April 2023 22:08:58 +0200, "Vojtěch Čihák via fpc-pascal" 
 wrote:


Hi,

>I'm almost fourteen years on the forum and a few years less on mailing lists 
>and I never had a single problem.
>I don't attend IRC so I can't say what's wrong there.
>OTOH I read Joanna's comments on the forum and they are OK (to the topic; non 
>conflict).

I've been contacted by Joanna using a private message on the forum. Apparently, 
she (assuming it's a female name) tries to do her best to manage the channel 
and protect it from trolls, etc. I'll try to clarify to her why I believe that 
her actions don't match her intents in at least some cases.

Tomas.


>__
>> Od: "Karl-Michael Schindler via fpc-pascal" 
>> Komu: fpc-pascal@lists.freepascal.org
>> Datum: 13.04.2023 18:49
>> Předmět: Re: [fpc-pascal] IRC channel for FreePascal support ?
>> 
>
>...
>
>All this is completely in line with my past experience with Joanna on #fpc 
>during freenode times. I withdrew from the channels completely, because of her 
>activities. Therefore, I strongly suggest action regarding her operator status 
>of the fpc channel on libera.chat. Alternatively, ask for the removal of the 
>“official” status and a corresponding disclaimer or the channel altogether. 
>This recent example shows, that her self-centered and dictatorial actions as 
>operator harm fpc more than fpc benefits from her activities.
>
>Regards - Michael.
>___
>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] IRC channel for FreePascal support ?

[Tomas Hajny via fpc-pascal]

On 2023-04-13 11:23, Jacob Kroon via fpc-pascal wrote:


Hi Jacob,

 .
 .

Ok, maybe this "Joanna" is on this mailing list and would care to
elaborate more why I got banned ?

The same "Joanna" also kicked me out of the channel a couple of days
ago with the reason that "we don't allow lurkers", since I was
inactive in the chat.


Just FYI - I don't see anybody having name "Joanna" among people 
subscribed to this mailing list, and nobody like that has been 
considerably active here in the last years as far as my memory serves 
correctly. Obviously, the address and/or name may be completely 
different from the IRC nickname, thus it doesn't mean that you wouldn't 
get the response here for sure. I can't check the list of people 
subscribed to FPC forum, the person may be active there.


Tomas
(one of FPC mailing list moderators)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Tomas Hajny via fpc-pascal]

On 2023-04-04 16:14, Bart via fpc-pascal wrote:

On Tue, Apr 4, 2023 at 9:43 AM Jacob Kroon via fpc-pascal
 wrote:

What is the technical downside to using "const", or is it just 
cosmetic ?


If your local "writeable constant" is of type string, and strings are
longstrings, and the writeable const is assigned a value that is the
result of a string concatenation, then you'll have a memory leak.


Well, managed types are not very likely in code imported from a Pascal 
compiler not knowing units...


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

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Tomas Hajny via fpc-pascal]

On 2023-04-04 11:14, Sven Barth wrote:

Tomas Hajny via fpc-pascal  schrieb
am Di., 4. Apr. 2023, 09:51:


 .
 .

If you read the documentation (wiki or the real documentation in
PDF/HTML etc.) properly, you don't find there anything saying that
constants declared locally within functions or procedures are
guaranteed to keep their modified values across runs of that
function/procedure. It
might behave like that, but you shouldn't rely on it unless it's a
const
on a global level (and then renaming may still be needed in case of
conflicts).


It *is* documented (the remark at the end):
https://www.freepascal.org/docs-html/current/ref/refse10.html#x22-210002.2


OK, my bad. :-( Thanks for this correction.

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

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Tomas Hajny via fpc-pascal]

On 2023-04-04 09:43, Jacob Kroon wrote:


Hi Jacob,

You don't need to change "var" to "const" - if you want to ensure the 
variables to persist in between the function/procedure runs, you need 
to move them to the global level, i.e. outside of the 
functions/procedures. It is not advisable as a general practice (to 
keep all variables globally), because then you might e.g. access the 
same variable from multiple functions by mistake, but it would 
probably solve your issue. Obviously, you might need to solve 
potential conflicts if you use the same variable names in multiple 
functions/procedures (e.g. by prepending the function/procedure name 
to the variable name or something like that).




I could move them to global scope, and add a prefix to avoid name
collisions, but using a "const" section seems more readable to me
since I don't need to add a prefix.

The wiki page says (https://wiki.freepascal.org/Const):

"The declaration const in a Pascal program is used to inform the
compiler that certain identifiers which are being declared are
constants, that is, they are initialized with a specific value at
compile time as opposed to a variable which is initialized at run
time.

However, the default setting in Free Pascal is to allow const
identifiers to be re-assigned to."

Then it says there is a flag to make reassigning to a const variable
an error. But if I ignore that, it would seem this is just what I
need, since this seems to make the variable have a whole-program
lifetime, no ?

What is the technical downside to using "const", or is it just cosmetic 
?


If you read the documentation (wiki or the real documentation in 
PDF/HTML etc.) properly, you don't find there anything saying that 
constants declared locally within functions or procedures are guaranteed 
to keep their modified values across runs of that function/procedure. It 
might behave like that, but you shouldn't rely on it unless it's a const 
on a global level (and then renaming may still be needed in case of 
conflicts).


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

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Tomas Hajny via fpc-pascal]

On 2023-04-04 08:16, Jacob Kroon via fpc-pascal wrote:


Hi Jacob,

 .
 .

But I suspect I have a new problem: With the old Pascal/MT+ compiler
it would appear that local variables declared in functions/procedures
have a life-time that spans the whole program, like a "static"
declared variable in C. With fpc, it looks like locally declared
variables are automatic, put on the stack(?), and so they go out of
existence once out of scope ?


Yes, local variables are declared on stack and their lifetime is indeed 
equivalent to the time of processing the particular function/procedure.




The program depends on this feature in the old compiler. I did some
googling and found that putting local variables in a "const" section
instead of "var" would make them have a "whole-program" lifetime, but
then I need to provide them with an initial value.

Do I have any other option besides changing from "var" to "const"
everywhere, and provide initial values in all declarations ?


You don't need to change "var" to "const" - if you want to ensure the 
variables to persist in between the function/procedure runs, you need to 
move them to the global level, i.e. outside of the functions/procedures. 
It is not advisable as a general practice (to keep all variables 
globally), because then you might e.g. access the same variable from 
multiple functions by mistake, but it would probably solve your issue. 
Obviously, you might need to solve potential conflicts if you use the 
same variable names in multiple functions/procedures (e.g. by prepending 
the function/procedure name to the variable name or something like 
that).


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

Re: [fpc-pascal] Converting Delphi7 code to FreePascal with interfacing to protection key?

[Tomas Hajny via fpc-pascal]

On 2023-03-30 10:08, Bo Berglund via fpc-pascal wrote:
On Thu, 30 Mar 2023 10:02:49 +0200, Tomas Hajny via fpc-pascal 
 wrote:


 .
 .
I'd suggest trying to switch to external linking (for both versions) - 
that might help...




Could you be more specific?

I have never heard of such, I am just a long time user of Lazarus/Fpc 
but not in

the deep understanding of how it all works. I have always focused on my
applications and not how they were screwed together behind the scenes 
by Fpc...


Is there a setting to use something other than Fpc to link after 
compiling?

How is that done?


I don't know where it is configured in Lazarus, but you need to use the 
-Xe parameter when using command-line compilation.


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

Re: [fpc-pascal] Converting Delphi7 code to FreePascal with interfacing to protection key?

[Tomas Hajny via fpc-pascal]

On 30 March 2023 9:36:35 +0200, Marco van de Voort via fpc-pascal 
 wrote:
>On 30-3-2023 07:38, Bo Berglund via fpc-pascal wrote:
>> The problem seems to be that neither is a valid COFF file according to my Fpc
>> (or Lazarus) in any case. Both generate the COFF error when reaching the 
>> linker
>> step.
>
>32-bit objs for delphi are typically OMF, 64-bit are typically coff (for 
>AMD64).

I'd suggest trying to switch to external linking (for both versions) - that 
might help...

Tomas

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

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Tomas Hajny via fpc-pascal]

On 2023-03-28 11:33, Karoly Balogh via fpc-pascal wrote:


Hi,

 .
 .

You might wanna consider this approach, because if units somehow end up
cross-referencing each other, then you might run into difficulties
restructuring the code to use Units. Also, it is possible to
cross-reference units from eachother, but there are some caveats.

With the external way, you only need to change the declarations of
variables, no need to restructure the code, although for long-term
maintenance, that might be still beneficial.


Since some changes would be necessary anyway even if using imports (not 
only adding public names plus changing the external references, also 
some changes necessary to get multiple object files linked into the same 
final program), I'd suggest biting the bullet and changing the code to 
units, but yes, an alternative exists.


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

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Tomas Hajny via fpc-pascal]

On 2023-03-27 11:45, Jacob Kroon via fpc-pascal wrote:


Hi,


I have some old Pascal code that was compiled in a CPM environment
using the Pascal/MT+ compiler from Digital Research. I'm trying to get
this project to build in a modern environment, for a start using
FreePascal.

First, is anyone aware of a tool for converting this dialect of Pascal
to something that FreePascal will accept ?


Sorry, no idea.



Second, the old code contains a lot of:

var
foobar : external integer;

in sources that reference 'foobar', then there is a declaration in one 
of them:


var
foobar : integer;

As I understand it, in order to translate this to something that
FreePascal understands, the variable needs to go in a "unit" and be
part of its interface. Then, pascal sources that needs to reference
the variable should use this unit. Is this the easiest way forward ?


Yes, most likely.



I thought maybe I instead could adapt the syntax like:

var
foobar : integer; external;

but with this I still get undefined references when linking. Using
units seems ok.


Indeed - while using the keyword 'external' as outlined in your modified 
example would be possible (even for importing a variable from another 
FPC compiled unit), it's primary purpose is for importing variables 
coming from object files compiled using different compilers (e.g. C, 
etc.) and there's no reason for using it for variables declared in a FPC 
unit in most cases (let's put some special cases aside for now).


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

Re: [fpc-pascal] Downloaded cross-compiler from Sourceforge - wiki incorrect?

[Tomas Hajny via fpc-pascal]

On 2023-03-23 09:25, Bo Berglund via fpc-pascal wrote:

I tried to add a cross-compiler for Win32 to my existing Lazarus 2.2.4
installation on Windows 10 x64.

 .
 .
Then opened Lazarus 2.2.4 with my project and changed project options 
as

follows:

Compiler_Options/Config_and_Target/Target OS(-T): Win32

Everything else left as-is.


Now when I OK this, Lazarus pops up a message saying:
--
The current FPC has no config file. It will probably miss
some units. Check your installation of fpc.
--
When I hit the OK button another pop-up:
--
The project uses target OS=win32 and CPU=x86_64.
The system.ppu for this target was not found in the FPC
binary directories.
Make sure fpc is installed correctly for this target and the
fpc.cfg contains the right directories.
[OK]
---

So I followed the install instructions on the Wiki and wound up in this
non-working state...

What steps are missing that I must do?
Why does it not find the correct system.ppu?

I searched the install dir for system.ppu and found two here:

C:\Programs\Lazarus_2.2.4\fpc\3.2.2\units\i386-win32\rtl
C:\Programs\Lazarus_2.2.4\fpc\3.2.2\units\x86_64-win64\rtl


What I see is:
in C:\Programs\Lazarus_2.2.4\fpc\3.2.2\bin\ only x86_64-win64 exists

in C:\Programs\Lazarus_2.2.4\fpc\3.2.2\units these dirs exsist:
i386-win32
x86_64-win64

in C:\Programs\Lazarus_2.2.4\fpc\3.2.2\fpmkinst these dirs exsist:
i386-win32
x86_64-win64

It seems like the cross installer failed to install the cross binaries, 
why


I must have done something seriously wrong...

Or could the problem be that Windows Defender has blocked all exe files 
from

being installed?


I don't know how it works with Lazarus (I install FPC using the 
installer provided with FPC, not the one for Lazarus), but I don't think 
that this has anything to do with Windows Defender. You missed another 
step mentioned by Sven, in particular changing the target CPU from 
x86_64 to i386. If it fails to find system.cpu even after that step, you 
may need to revisit the configuration file as already suggested in the 
message to make sure that search path for units (-Fu) references the 
full target "variable" rather than explicitly the x86_64-win64 
directory.


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

Re: [fpc-pascal] Working on a new way to educate people about pascal

[Tomas Hajny via fpc-pascal]

Hello everybody,

Could we get back on topic, please? Discussion of strengths and 
weaknesses of SQL and/or other database technologies and their history 
(especially if primarily focusing subjective feelings of different 
authors rather than use of these database technologies together with 
FPC) isn't really on topic here - feel free to use fpc-other instead...


Tomas
(one of FPC mailing list administrators)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Working on a new way to educate people about pascal

[Tomas Hajny via fpc-pascal]

On 29 December 2022 13:31:57 +0100, Anthony Walter via fpc-pascal 
 wrote:


Hello Anthony,
 .
 .
>I suggest you either brush up on these subjects or refrain from scolding
>people on subjects with which you have no practical experience.

You asked for feedback and you got it. Please, stop attacking others who 
provided what you'd asked for. Obviously, it's up to you whether you consider 
the feedback, or not, or whether you agree to it, or not, but arguing this way 
makes no sense and doesn't belong here for sure, because it isn't related to 
either FPC or Pascal.

Tomas
(one of FPC mailing lists moderators)

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

Re: [fpc-pascal] Can't build single package

[Tomas Hajny via fpc-pascal]

On 2022-11-03 08:58, Luca Olivetti via fpc-pascal wrote:

El 2/11/22 a les 17:06, Tomas Hajny via fpc-pascal ha escrit:



I see. This means that you already have the prerequisites fulfilled in 
the source tree for Linux, but not for Windows. Start by issuing 'make 
rtl_all packages_all' in D:\fpc-3.2.2. Then try rebuilding fcl-web in 
the fcl-web directory - I believe that it might work then.



Yes, that worked, but then it caused another problem: I wanted to
recompile fcl-web because I couldn't install the lazsqldbrest package

Compile package sqldbrestschemadesigner 0.0: Exit code 1, Errors: 1, 
Warnings: 1

Warning: Recompiling sqldbrestmodule, checksum changed for
C:\FPC\3.2.2\units\i386-win32\fcl-web\fphttp.ppu
build304.pp(19,58) Fatal: Cannot find sqldbrestmodule used by
build304. Make sure all ppu files of a package are in its output
directory. ppu in wrong
directory=C:\FPC\3.2.2\units\i386-win32\fcl-web\sqldbrestmodule.ppu..


Most probably because I modified some units to correct a couple of 
bugs.

Now, after "make rtl_all packages_all" and copying the fcl-web units
to the correct location, I get this


Compile package sqldbrestschemadesigner 0.0: Exit code 1, Errors: 1, 
Warnings: 1

Warning: Recompiling sqldbrestschema, checksum changed for
C:\FPC\3.2.2\units\i386-win32\rtl\classes.ppu
sqldbrestschema.pp(13,55) Fatal: Can't find unit sqldbrestschema used
by dlgrestfieldoptions


Might as well build and install fpc from source :-/


That's always an option, of course. ;-) However, I guess that it would 
also help to run 'make rtl_clean packages_clean rtl_all packages_all' or 
even 'make distclean rtl_all packages_all'. Did you combine compilation 
using an IDE (e.g. Lazarus) with compilation using makefiles? That may 
easily lead to problems (especially due to compiled files being placed 
in locations not expected by the makefiles, thus resulting in multiple 
compiled versions of the same unit in different places)...


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

Re: [fpc-pascal] Can't build single package

[Tomas Hajny via fpc-pascal]

On 2022-11-02 16:40, Luca Olivetti via fpc-pascal wrote:

El 2/11/22 a les 15:54, Tomas Hajny via fpc-pascal ha escrit:


OK, the problem is that I installed the compiler with the windows
installer and the makefile expects it to be in its tree (hence the
"-n" and the "-Fu" options).
Is there something I can do (other than building and installing the
compiler from the source tree)?


This is not matter of the compiler location (the current directory is 
the location where you started make.exe). However, you are supposed to 
have the packages sources together with the rtl sources. The location 
where you start make seems to be the directory of compiled fcl-web 
package rather than the directory with the respective sources. Did you 
copy the fcl-web sources there manually?


No, in fact "make clean; make" under linux, with the same tree(*), 
works:


luca@seis:~/Datos/fpc-3.2.2/packages/fcl-web$ make clean ; make
./fpmake clean --localunitdir=../.. --globalunitdir=.. --os=linux
--cpu=x86_64 -o -Cg -o -dx86_64 --compiler=/usr/local/bin/ppcx64 -bu
./fpmake compile --localunitdir=../.. --globalunitdir=.. --os=linux
--cpu=x86_64 -o -Cg -o -dx86_64 --compiler=/usr/local/bin/ppcx64 -bu
Start compiling package fcl-web for target x86_64-linux.
   Compiling BuildUnit_fcl_web.pp
   Compiling ./src/base/fpmimetypes.pp
   Compiling ./src/base/httpprotocol.pp
.
   Compiling ./src/restbridge/sqldbrestauthini.pp
   Compiling ./src/restbridge/sqldbrestmodule.pp
[100%] Compiled package fcl-web

The difference is that under Linux I built and installed fpc from that
tree, but there are no compiled units for windows there (only the
sources).

(*) when I say "the same" I mean "the same", i.e. linux is the host
and windows is a guest VM with the "~/Datos" directory mapped as
network drive D:


I see. This means that you already have the prerequisites fulfilled in 
the source tree for Linux, but not for Windows. Start by issuing 'make 
rtl_all packages_all' in D:\fpc-3.2.2. Then try rebuilding fcl-web in 
the fcl-web directory - I believe that it might work then.


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

Re: [fpc-pascal] Can't build single package

[Tomas Hajny via fpc-pascal]

On 2022-11-02 15:25, Luca Olivetti via fpc-pascal wrote:

El 2/11/22 a les 9:37, Luca Olivetti via fpc-pascal ha escrit:

IIRC I did it in the past but now:

D:\fpc-3.2.2\packages\fcl-web>make
C:/FPC/3.2.2/bin/i386-Win32/ppc386.exe fpmake.pp -n -Fu../../rtl 
-Fu../../packages/paszlib -Fu../../packages/fcl-process 
-Fu../../packages/hash -Fu../../packages/libtar 
-Fu../../packages/fpmkunit/units_bs/i386-win32

Fatal: Can't find unit system used by fpmake
Fatal: Compilation aborted
make: *** [fpmake.exe] Error 1


OK, the problem is that I installed the compiler with the windows
installer and the makefile expects it to be in its tree (hence the
"-n" and the "-Fu" options).
Is there something I can do (other than building and installing the
compiler from the source tree)?


This is not matter of the compiler location (the current directory is 
the location where you started make.exe). However, you are supposed to 
have the packages sources together with the rtl sources. The location 
where you start make seems to be the directory of compiled fcl-web 
package rather than the directory with the respective sources. Did you 
copy the fcl-web sources there manually?


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

Re: [fpc-pascal] Test Free Pascal program not compiling

[Tomas Hajny via fpc-pascal]

On 2022-09-12 21:12, Terry A. Haimann via fpc-pascal wrote:


Hello Terry,


I personally think it can't find the assembler.  I did test this on my
desktop and it compiled w/o error.


No, but the installed assembler doesn't know the "softvfp" FPU type 
apparently specified in the compilation options:


---

[0.430] Executing "/usr/bin/as" with command line "-mfpu=softvfp -o
Sqrt.o  Sqrt.s"
Assembler messages:
Error: unrecognized option -mfpu=softvfp

===



Below you will see the output of the compile as you suggested.  Sorry
it is so long.


As a reminder - you can always zip the file and add it to attachment, or 
place it on some server and include just a link (or reduce the size by 
removing the beginning of the file if it's so long and there's a message 
close to the end starting with "Error:").


Tomas
(one of the FPC mailing lists moderators)
___
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

[Tomas Hajny via fpc-pascal]

On 2022-09-12 21:41, Nikolay Nikolov via fpc-pascal wrote:

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.


Old TP/BP programs were usually accessing the BIOS ShiftState "variable" 
(using direct BIOS memory access). TV unit Drivers provided this 
functionality using function GetShiftState (available in FreeVision as 
well, of course). If you're looking for adding something compatible to 
TP/BP functionality, ShiftState (e.g. as a property), or GetShiftState 
function might be good candidates for such an addition, IMHO.


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

[fpc-pascal] Fwd: Re: Cross-compiler for ARM64 on Windows available?

[Tomas Hajny via fpc-pascal]

Sorry, one additional thought - it's better to choose a directory 
without spaces when installing the LLVM package (i.e. not to accept the 
default proposal "C:\Program Files\..."), or at least let the installer 
change the PATH variable for you (which is not checked by default).


Tomas


 Original Message 
Subject: Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?
Date: 2022-06-25 14:07
From: Tomas Hajny 
To: FPC-Pascal users discussions 

On 2022-06-25 10:58, Wolfgang Hubert via fpc-pascal wrote:


Hi Wolfgang,

if you already have your FPC 3.2.2 installation, plus installation of 
an external package (LLVM). All of it rather feasible. Yes, you may 
possibly encounter some issues with the current port to this target 
(aarch64-win64), but I'm sure there are others willing to help with 
that part as well if you report such issues. Just let me/us know if 
you want to continue that way, I'm willing to provide more specific 
directions.


OK. What would be a good starting point? my Windows XP/32 machine with
fpc 3.2.2 installed or my Windows 10/64 machine with fpc 3.2.2
installed?


Actually, this shouldn't matter. Assuming that your Win64 machine is 
newer and thus probably faster, I'd use that one.




And which LLVM package shall I install?


If you decide for the WinXP machine, you need 
https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.5/LLVM-14.0.5-win32.exe. 
If you go for the Win64 machine, I'd choose the 64-bit installer 
(https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.5/LLVM-14.0.5-win64.exe), 
but the 32-bit one should work equally well, in fact. A new LLVM release 
(14.0.6) has been officially announced yesterday, but the Win32/Win64 
installers aren't available for it yet and I don't think that it should 
matter (eventually, you can upgrade to the newer version of LLVM later 
if needed).




My source code only uses RTL, System, SysUtils and Windows units.
Windows is only needed for registry access.


OK. Nevertheless, I'll show you how to build packages as well - just in 
case you find a need to use some of them too.


In addition to LLVM installation, you'll also need to get source files 
for the development version of FPC. Considering the fact that you may 
need to update it later in case you discover some issues with this 
version, it's the best to get up to date source using the Git tool. 
Installer for this tool may be downloaded from 
https://git-scm.com/download/win/. Depending on the chosen machine, 
you'd use either 32-bit Git for Windows Setup or 64-bit Git for Windows 
Setup. The installer might ask you some questions and I don't remember 
them - if you come across a question you can't answer yourself, just ask 
here. Once you're ready with this part, we'll continue from there by 
getting the latest FPC sources as described on 
https://www.freepascal.org/develop.html#git. One important point (not 
really mentioned on that page clearly) is that you run the "git clone" 
command described there in a directory, where you want to place the FPC 
source tree. You don't need the fixes_3.2 sources, just the main 
development version (i.e. you don't care of anything following the 
"Fixes to 3.2.x" subtitle).


Let me know once you get to the end of that point (or if you come across 
some issue on the way there).


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

Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?

[Tomas Hajny via fpc-pascal]

On 2022-06-25 10:58, Wolfgang Hubert via fpc-pascal wrote:


Hi Wolfgang,

if you already have your FPC 3.2.2 installation, plus installation of 
an external package (LLVM). All of it rather feasible. Yes, you may 
possibly encounter some issues with the current port to this target 
(aarch64-win64), but I'm sure there are others willing to help with 
that part as well if you report such issues. Just let me/us know if 
you want to continue that way, I'm willing to provide more specific 
directions.


OK. What would be a good starting point? my Windows XP/32 machine with
fpc 3.2.2 installed or my Windows 10/64 machine with fpc 3.2.2
installed?


Actually, this shouldn't matter. Assuming that your Win64 machine is 
newer and thus probably faster, I'd use that one.




And which LLVM package shall I install?


If you decide for the WinXP machine, you need 
https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.5/LLVM-14.0.5-win32.exe. 
If you go for the Win64 machine, I'd choose the 64-bit installer 
(https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.5/LLVM-14.0.5-win64.exe), 
but the 32-bit one should work equally well, in fact. A new LLVM release 
(14.0.6) has been officially announced yesterday, but the Win32/Win64 
installers aren't available for it yet and I don't think that it should 
matter (eventually, you can upgrade to the newer version of LLVM later 
if needed).




My source code only uses RTL, System, SysUtils and Windows units.
Windows is only needed for registry access.


OK. Nevertheless, I'll show you how to build packages as well - just in 
case you find a need to use some of them too.


In addition to LLVM installation, you'll also need to get source files 
for the development version of FPC. Considering the fact that you may 
need to update it later in case you discover some issues with this 
version, it's the best to get up to date source using the Git tool. 
Installer for this tool may be downloaded from 
https://git-scm.com/download/win/. Depending on the chosen machine, 
you'd use either 32-bit Git for Windows Setup or 64-bit Git for Windows 
Setup. The installer might ask you some questions and I don't remember 
them - if you come across a question you can't answer yourself, just ask 
here. Once you're ready with this part, we'll continue from there by 
getting the latest FPC sources as described on 
https://www.freepascal.org/develop.html#git. One important point (not 
really mentioned on that page clearly) is that you run the "git clone" 
command described there in a directory, where you want to place the FPC 
source tree. You don't need the fixes_3.2 sources, just the main 
development version (i.e. you don't care of anything following the 
"Fixes to 3.2.x" subtitle).


Let me know once you get to the end of that point (or if you come across 
some issue on the way there).


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

Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?

[Tomas Hajny via fpc-pascal]

On 2022-06-24 09:02, Wolfgang Hubert via fpc-pascal wrote:


Hi Wolfgang,


thank you for your thoughts and suggestions on this topic.

Tomas Hajny wrote:
I may be wrong, but I believe that the original poster meant that he 
was using a "regular" (32-bit) version of WinXP on x86 and wanted to 
cross-compile from there to aarch64-win64.

Yes, you are right. I have a XP machine as well as Windows 10, both
32-bit and 64-bit. So one of these should be the host. But it must be
a cross-compiler  for the ARM64 target, since I cannot operate a ARM64
machine running Windows. It is not accessible to me. It is a bit like
the hen/egg-problem.

I am using fpc 3.2.2 on my XP machine (32-bit) successfully for
building 32-bit and 64-bit DLLs for Windows x86/x64. My goal is to do
the same for the ARM64 target.

Now I think of porting my pascal code to C++, installing MS Visual
Studio and compiling it there.
I am not a compiler compiler and will not be able to finalize or test
a cross-compiler before using it.


I believe that we can help you with resolution with FPC if you're 
interested, it isn't that difficult after all. Building a trunk (main) 
compiler, rtl and packages is matter of several rather simple commands 
if you already have your FPC 3.2.2 installation, plus installation of an 
external package (LLVM). All of it rather feasible. Yes, you may 
possibly encounter some issues with the current port to this target 
(aarch64-win64), but I'm sure there are others willing to help with that 
part as well if you report such issues. Just let me/us know if you want 
to continue that way, I'm willing to provide more specific directions.


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

Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?

[Tomas Hajny via fpc-pascal]

On 2022-06-23 19:58, Travis Siegel via fpc-pascal wrote:

There actually is a 64-bit version of xp, but it's not compatible with
very much.  Apparently, it didn't have an emulator in it, so running
32-bit software wasn't something it did by default.  I never did
figure out if it could be made to run 32-bit software or not, I just
gave up on it, (more precisely, the person I installed it for gave up
on it), because everything they tried to install wouldn't work,
because it wasn't 64-bit.

Even so, I have no idea if the FPC cross compiler would work on such a
machine anyway, and I no longer have a machine on which I can test
said version of windows anyhow, (come to think of it, I don't think I
have the install disk for it anymore either), so that will have to
remain a mystery.


I may be wrong, but I believe that the original poster meant that he was 
using a "regular" (32-bit) version of WinXP on x86 and wanted to 
cross-compile from there to aarch64-win64.


Tomas





On 6/21/2022 10:36 AM, Pierre Muller via fpc-pascal wrote:

Hello,

  this is normally a native aarch64-win64 compiler,
not a cross-compiler package to be installed on linux.

  Note however that, as stated below, this was never tested.
It will also not run on a Windows XP, unless
you have an aarch64-windows_XP, but I am not aware
of the existence of such machines.

Regards,

Pierre


Le 21/06/2022 à 11:14, Wolfgang Hubert a écrit :

Hi all,

Pierre Muler via fpc-pascal wrote:


You might also try this "completely untested" cross-installer:



ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/aarch64-win64/fpc-3.3.1.aarch64-win64.built.on.x86_64-linux.tar.gz


Thank you for pointing me to this installer. Since I am a Windows XP 
user

and also blind, it would be too much effort for me to install a Linux
machine or compile the compiler myself. I would rather wait until a 
compiler

for the Windows host is available.

If anyone has one, please let me know.

Regards,

Wolfgang

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

Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?

[Tomas Hajny via fpc-pascal]

On 2022-06-21 20:01, Sven Barth wrote:

Tomas Hajny via fpc-pascal  schrieb
am Di., 21. Juni 2022, 18:08:



Hi Sven,

 .
 .

I just tried to follow the advice above. Compiling the
cross-compiler
(Win32 hosted) is no problem using the fullcycle target (obviously,
I
could build just the particular compiler for AArch64 instead of all
of
them, but that isn't important) - so far so good. However, it
already
fails when trying to build the aarch64-win64 rtl using this
cross-compiler, because the compiler complains about missing
assembler
aarch64-win64-clang.exe. Do we provide (compiled) win32 or win64
hosted
binutils providing support for aarch64-win64 target? FWIW, I checked
the
contrib directory on our FTP, but didn't find anything useful in
this
regard there either.


As is mentioned in my announcement mail for the target it requires
clang as assembler, not GNU binutils. And we don't *want* to ship that
as clang provides nice installers themselves.


I can't find any clang installers. Do you mean the 263 MB installer of 
the whole LLVM 
(https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.5/LLVM-14.0.5-win32.exe 
or 
https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.5/LLVM-14.0.5-win64.exe)? 
Moreover, that wouldn't provide the executable aarch64-win64-clang.exe 
expected by FPC, would it (unlike the contributed cross binutils 
provided by Pierre and some others for other architectures)? I believe 
that we should either reconsider the idea of not providing such binaries 
ourselves, or change the compiler so that it can invoke the tools as 
installed by the installer (or to provide detailed steps necessary for 
making this to work as the very least, but my personal opinion is that 
this last option wouldn't be the right thing to do in this case).


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

Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?

[Tomas Hajny via fpc-pascal]

On 2022-06-21 00:14, Pierre Muller via fpc-pascal wrote:

Le 20/06/2022 à 23:53, Sven Barth via fpc-pascal a écrit :

Am 20.06.2022 um 12:34 schrieb Wolfgang Hubert via fpc-pascal:



Hi Pierre (and others ;-) ),

 .
 .
Windows on AArch64 is currently only supported in main thus you need 
to

compile it yourself (see also
https://lists.freepascal.org/pipermail/fpc-announce/2020-April/000614.html
). Also there are still some errors for which the origins haven't been
found yet, so your mileage may vary...


  You might also try this "completely untested" cross-installer:
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/aarch64-win64/fpc-3.3.1.aarch64-win64.built.on.x86_64-linux.tar.gz
See:
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/aarch64-win64/README-fpc-3.3.1.aarch64-win64.built.on.x86_64-linux


I just tried to follow the advice above. Compiling the cross-compiler 
(Win32 hosted) is no problem using the fullcycle target (obviously, I 
could build just the particular compiler for AArch64 instead of all of 
them, but that isn't important) - so far so good. However, it already 
fails when trying to build the aarch64-win64 rtl using this 
cross-compiler, because the compiler complains about missing assembler 
aarch64-win64-clang.exe. Do we provide (compiled) win32 or win64 hosted 
binutils providing support for aarch64-win64 target? FWIW, I checked the 
contrib directory on our FTP, but didn't find anything useful in this 
regard there either.


In order to check that, I downloaded your "cross-installer" mentioned 
above, but it contains win32 hosted builds of binutils named 
x86_64-win64-*.exe, i.e. supposedly aimed at targetting Win64 on x86_64, 
but not usable together with the included ppca64.exe binary (because the 
included ppca64.exe binary is a native compiler for aarch64-win64, 
whereas the binutils only run under win32/win64; moreover, they do not 
fit the subdirectory bin/aarch64-win64/ included in the .tar.gz file). 
And just as a funny fact, the included x86_64-win64-objdump.exe does not 
even recognize the AArch64 architecture ;-) (tried with the ppca64.exe 
binary) - not surprisingly, because it's version 2.26 compiled in 
January 2016.


Conclusion:

1) Packaging of the "cross-installer" mentioned above should be revised 
(specifically, the binutils should be replaced with something more 
appropriate).


2) We should provide the appropriate cross-binutils, otherwise even 
suggesting people to compile the ppca64.exe compiler from trunk/main FPC 
themselves doesn't help much.


3) It might be time for updating the provided Win32 binutils as well - 
version 2.28 of objdump included with the latest release of FPC (and 
also included in the fpcbuild repository in both the win32 and win64 
subdirectories under install/) doesn't support/recognize the AArch64 
architecture yet.


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

Re: [fpc-pascal] Compiler flag define or $IFOPT for optimizations

[Tomas Hajny via fpc-pascal]

On 2022-06-03 14:41, Benito van der Zander via fpc-pascal wrote:


Hi,


However, you can possibly solve it by always taking the options from
an environment variable to the command line and then including
contents of this command line to your sources.


Unfortunately it is picking up all kinds of options from fpc.cfg and
Lazarus.

Like in this case, I tried to disable range checking, and it is still
enabled.


You can disable using the configuration files using -n (that's what is 
being done during the FPC release process for release builds) and define 
all necessary / used options from the environment.




You can introduce something like that yourself by always building

all your sources from scratch, but then the solution outlined above
should work for you.

I am setting up a build server that compiles the entire project from
scratch on every commit.


As mentioned above, then the suggested approach should fit well, IMHO.

Tomas





On 28.05.22 14:34, Tomas Hajny via fpc-pascal wrote:


On 2022-05-28 13:44, Benito van der Zander via fpc-pascal wrote:

Hi,


I want to show how my program was compiled.

Now I have string like "FPC3.2.2 i386-Linux R+C+" from

compiler := 'FPC' + {$INCLUDE %FPCVERSION%} + ' ' + {$INCLUDE
%FPCTargetCPU%}+'-'+{$INCLUDE %FPCTargetOS%}+ ' ' + {$IfOpt
R+}+'R+'{$endif} {$IfOpt S+}+'S+'{$endif} {$IfOpt O+}+'O+'{$endif}

{$IfOpt Q+}+'Q+'{$endif} {$IfOpt M+}+'M+'{$endif} {$IfOpt
C+}+'C+'{$endif};

But the optimization level (-O2 or -O1 ...) is missing.

Is there an IFOPT for that? Or a define with all the arguments


I don't think that there's such an option at the moment. However,
you can possibly solve it by always taking the options from an
environment variable to the command line and then including contents
of this command line to your sources. I don't think that it makes
much sense for the compiler to provide such an option, because
unlike the compiler version, different options (including the
optimization level) may be used for compilation of different units
and there's no such a thing as a general optimization level valid
for the complete compiled program from the compiler point of view.
You can introduce something like that yourself by always building
all your sources from scratch, but then the solution outlined above
should work for you.

Tomas
___
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] Be careful of too many features

[Tomas Hajny via fpc-pascal]

On 2022-05-31 11:22, Liam Proven via fpc-pascal wrote:

On Tue, 31 May 2022 at 04:12, Steve Litt via fpc-pascal
 wrote:


A truly great language would be Turbo Pascal 5.5 (with OOP) plus
function/procedure references.


Oberon?

https://en.wikibooks.org/wiki/Oberon


Please, everybody - this stream of the discussion (history, alternative 
past and current compilers, etc.) is a perfect fit for the fpc-other 
mailing list (and vice versa not for fpc-pascal).


Thanks

Tomas
(one of FPC mailing list moderators)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiler flag define or $IFOPT for optimizations

[Tomas Hajny via fpc-pascal]

On 2022-05-28 13:44, Benito van der Zander via fpc-pascal wrote:


Hi,


I want to show how my program was compiled.

Now I have string like "FPC3.2.2 i386-Linux R+C+" from

  compiler := 'FPC' + {$INCLUDE %FPCVERSION%} + ' ' + {$INCLUDE
%FPCTargetCPU%}+'-'+{$INCLUDE %FPCTargetOS%}+ ' ' + {$IfOpt
R+}+'R+'{$endif} {$IfOpt S+}+'S+'{$endif} {$IfOpt O+}+'O+'{$endif}
{$IfOpt Q+}+'Q+'{$endif} {$IfOpt M+}+'M+'{$endif} {$IfOpt
C+}+'C+'{$endif};

But the optimization level (-O2 or -O1 ...) is missing.

Is there an IFOPT for that? Or a define with all the arguments


I don't think that there's such an option at the moment. However, you 
can possibly solve it by always taking the options from an environment 
variable to the command line and then including contents of this command 
line to your sources. I don't think that it makes much sense for the 
compiler to provide such an option, because unlike the compiler version, 
different options (including the optimization level) may be used for 
compilation of different units and there's no such a thing as a general 
optimization level valid for the complete compiled program from the 
compiler point of view. You can introduce something like that yourself 
by always building all your sources from scratch, but then the solution 
outlined above should work for you.


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

Re: [fpc-pascal] Compiler internals. Changing dynamic arrays format

[Tomas Hajny via fpc-pascal]

On 2022-04-13 00:34, denisgolovan via fpc-pascal wrote:


Hi Denis,


I've been maintaining a set of private patches for some quite old FPC
revision for some years.

 .
 .
My first trouble is initialization of dynamic arrays with constant 
arrays.

It looks like simply building one version of compiler just makes a
build with old-style array constants and my already patched code.
That leads to code/constant data format mismatches and new compiler
process just crashes.

Looks vanilla makefile builds a several versions of compiler
progressing to a final version.
It seems that my troubles also can be solved by enabling parts of the
patchset progressively.
More specifically, I plan to enable array serialization code patch
first in cyclelevel 1.
Then build next compiler level using compiler 1 with rest code enabled
to get cyclelevel 2.
Cyclelevel2 build should already contain both all code changes and
data constants in new format.
And finally build cyclelevel3 build with cyclelevel2 compiler to 
complete build.


Is it the right way to go?
And if I get it right - could anyone suggest me how to enable my
constants code serialization patches (via conditional defines I guess)
at cyclelevel 1 and all patches at cyclelevels 2 and 3?


Your comment about conditional defines goes in the right direction - 
basically:


1) Separate your changes into parts affecting the compiler behaviour 
(e.g. the changes impacting the compiled structures and code, etc.) from 
changes needed because of the changed behaviour (i.e. use of your new 
features within the RTL and/or the compiler, modified versions of code 
working with the newly / differently compiled structures, etc.).


2) Create a conditional define for your new changes - this new define 
would be enabled within the compiler behaviour affecting changes.


3) Make your changes resulting from the changed behaviour (either in the 
RTL, or in the compiler) enabled only when the new conditional define is 
enabled.


If you do this, you should be able to use the standard makefiles without 
any changes (e.g. "make compiler_cycle", etc.).


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

Re: [fpc-pascal] converting to UTF8

[Tomas Hajny via fpc-pascal]

On 2022-03-24 20:47, Santi via fpc-pascal wrote:

El 23/03/2022 a las 10:51, Mattias Gaertner via fpc-pascal escribió:


FPC does not yet understand comments,

What do you mean with "understand comments"?


Mattias meant that comments were the only place where information about 
use of CP1252 was included.




so maybe it does not know this
literal is cp1252. Add {$codepage cp1252} somewhere at the start of
the unit.

If this is part of a Lazarus application, then String is by
default UTF-8, so your "original" is already converted to UTF-8.

So, as far as Ive understood,  without {$codepage cp1252}, when I read
the string from a file, it supposes it is utf8, even when it is not a
valid utf8 string.


First, there are many cases when a file may be a valid UTF-8 file, yet 
it is still a valid file in ANSI encoding. There must be some default. 
Lazarus uses UTF-8 as the default.




And ansiToUtf8 doesn't suppose that the input string ansi, but utf8? I
can't understand what is ansiToUtf8  for.


A particular encoding must be already defined when the string is 
assigned to the string. The string contents may not change depending on 
which function is called on it (moreover, implicit conversions migt be 
used regardless from the original encoding.


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

Re: [fpc-pascal] Putting Delimited text into a StringList

[Tomas Hajny via fpc-pascal]

On 2022-02-07 13:20, James Richters via fpc-pascal wrote:

I'm trying to use TCSVDocument,

I have:

Uses Math,sysutils,Classes,CSVReadWrite;

That seems to be fine,
But I get an error 1D.pas(18,17) Error: Identifier not found 
"TCSVDocument"


On a line:

Var
   CSVData   :  TCSVDocument;

Do I need another unit or am I doing something wrong?


CSVDocument?

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

Re: [fpc-pascal] Make clean error when building fpc 3.2.2 from sources

[Tomas Hajny via fpc-pascal]

On 2021-11-22 16:21, Jonas Maebe via fpc-pascal wrote:

On 22/11/2021 16:02, Bo Berglund via fpc-pascal wrote:
This is what happens when I execute the first make command inside the 
fpc source

dir:

   ~/devel/fpc/3.2.2$ make clean
   make: -iVSPTPSOTO: Command not found
   /usr/bin/rm -f build-stamp.*
   /usr/bin/rm -f base.build-stamp.*

I have checked that build-essentials are installed on this Ubuntu 
machine.


Where do I go from here?


FPC needs a previous version of FPC to bootstrap. So first install fpc
using apt-get on the VM.


While the answer from Jonas is obviously the simplest and most complete 
solution, there is an alternative workaround (not necessarily a fully 
guaranteed solution!) for your situation. The particular failing / 
missing command used by make is the fpc binary. If you have installed a 
bootstrap compiler _and_ if you try to perform a native build (not to 
build for a different CPU), you can run make with an additional 
parameter setting the variable "FPC" to the path of your compiler binary 
(e.g. 'make all "FPC=/usr/bin/ppcx64"').


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

Re: [fpc-pascal] Code page for the Windows event viewer

[Tomas Hajny via fpc-pascal]

On 2021-09-15 16:09, Abuy via fpc-pascal wrote:

UnicodeString change only look of symbols (instead of quastion marks
this — Іівівйц ГђВ№
вфівфъ2цву
йцуцйівів). No BOM. File is UTF-8. No
command line parameters.


If your source file is in UTF-8, you need to let the compiler know about 
this. You can do so by using the compiler option -Fcutf8 (or by using 
the BOM, but the explicit option is the safest).


Tomas




On 15.09.2021 16:53, Tomas Hajny via fpc-pascal wrote:

On 2021-09-15 15:08, Abuy via fpc-pascal wrote:

Instead of cyrillic characters there some garbage in Windows event
viewer. Have tried AnsiString with Windows-1251 code page (type
StringCP1251 = type AnsiString(1251)) but this does not work. What
works is RawByteString variable with the following conversion to
Windows-1251. Here is code:

{$MODE objfpc} {$ifdef mswindows}{$apptype console}{$endif}
{$R C:\lazarus\fpc\3.2.0\source\packages\fcl-base\src\win\fclel.res}
program Project1;

uses
  EventLog,
  sysutils;
type
  StringCP1251 = type AnsiString(1251);
var
  logger:teventlog;
  //msg:StringCP1251;
  msg:rawbytestring;
begin
msg:='Іівівйц й вфівфъ2цву йцуцйівів';
SetCodePage(msg, 1251, True);

Write('DefaultSystemCodePage is ');
Writeln(system.DefaultSystemCodePage);

logger:=teventlog.create(nil);
logger.Identification:='My gressdqwwe';
logger.RegisterMessageFile('');
logger.logtype:=ltsystem;
logger.active:=true;

Write('Code page is ');
WriteLn(StringCodePage(msg));

logger.Info(msg);
logger.Destroy;

WriteLn('End');
end.


What happens if you declare Msg as UnicodeString? How is your source
file stored (which encoding, BOM if applicable or not)? Which command
line parameters do you use (e.g. -Fc???)?

Tomas

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

Re: [fpc-pascal] Code page for the Windows event viewer

[Tomas Hajny via fpc-pascal]

On 2021-09-15 15:08, Abuy via fpc-pascal wrote:

Instead of cyrillic characters there some garbage in Windows event
viewer. Have tried AnsiString with Windows-1251 code page (type
StringCP1251 = type AnsiString(1251)) but this does not work. What
works is RawByteString variable with the following conversion to
Windows-1251. Here is code:

{$MODE objfpc} {$ifdef mswindows}{$apptype console}{$endif}
{$R C:\lazarus\fpc\3.2.0\source\packages\fcl-base\src\win\fclel.res}
program Project1;

uses
  EventLog,
  sysutils;
type
  StringCP1251 = type AnsiString(1251);
var
  logger:teventlog;
  //msg:StringCP1251;
  msg:rawbytestring;
begin
msg:='Іівівйц й вфівфъ2цву йцуцйівів';
SetCodePage(msg, 1251, True);

Write('DefaultSystemCodePage is ');
Writeln(system.DefaultSystemCodePage);

logger:=teventlog.create(nil);
logger.Identification:='My gressdqwwe';
logger.RegisterMessageFile('');
logger.logtype:=ltsystem;
logger.active:=true;

Write('Code page is ');
WriteLn(StringCodePage(msg));

logger.Info(msg);
logger.Destroy;

WriteLn('End');
end.


What happens if you declare Msg as UnicodeString? How is your source 
file stored (which encoding, BOM if applicable or not)? Which command 
line parameters do you use (e.g. -Fc???)?


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

Re: [fpc-pascal] https://sourceforge.net/projects/freepascal/files/Source/3.2.2/ : Missing install.sh

[Tomas Hajny via fpc-pascal]

On 2021-07-06 22:37, Jean Pierre CASSOU via fpc-pascal wrote:

https://sourceforge.net/projects/freepascal/files/Source/3.2.2/

Missing install.sh


This file is included in the fpcbuild package (either zip, or tar.gz), 
in particular in subdirectory "install".


Apart from that - I assume that you already know that the source 
packages are not meant to be installed directly and that you need to 
have a previous FPC binary for the given target (or cross-compile from a 
different platform on which the FPC binary is already installed) in 
order to build the compiler, accompanying tools, run-time library and 
other packages first before installing them (and if you already do this, 
you can use 'make install' rather than install.sh; install.sh is only 
needed for installation of pre-built compiler, etc.).


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

Re: [fpc-pascal] Will the size of an executable depend on the uses clause

[Tomas Hajny via fpc-pascal]

On 2021-06-16 23:49, Jean SUZINEAU via fpc-pascal wrote:

My best score is 67 kb after strip -s with the code below ... ;-)

Of course it will not work on every  version of Windows.

program uptime;

function GetTickCount64: QWord; stdcall; external 'kernel32.dll';

function _2d( _i: Integer): String;
begin
 Str( _i, Result);
 if Length(Result) < 2 then Result:= '0'+Result;

end;

function FormatUpTime( _tc: QWord): String;
var
   t, d, h, m, s: Integer;
   sd: String;
begin
 t:= _tc div 1000;
 s:= t mod 60;
 m:= (t div 60) mod 60;
 h:= (t div 3600) mod 24;
 d:= (t div 86400);

 Result:= _2d(h)+':'+_2d( m)+':'+_2d( s);
 if 0 = d then exit;

 Str( d, sd);
 Result:= sd+' '+Result;
end;

begin
 WriteLn( FormatUpTime( GetTickCount64));
end.


I get half of your size, in particular 35840 bytes if compiling for 
Win32 (a 64-bit version is 46592 bytes). The trick with manual import of 
the respective Win32 API function is not necessary, the size doesn't 
increase by adding 'uses Windows;' instead of the manual import.


D:\TEMP>fpc -XX -Xs uptime.pas
Free Pascal Compiler version 3.2.2 [2021/05/15] for i386
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling uptime.pas
Linking uptime.exe
33 lines compiled, 0.0 sec, 29760 bytes code, 1308 bytes data

D:\TEMP>dir uptime.exe
 .
 .
 Directory of D:\TEMP
17.06.2021  12:1835 840 uptime.exe
   1 File(s) 35 840 bytes

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

Re: [fpc-pascal] Will the size of an executable depend on the uses clause

[Tomas Hajny via fpc-pascal]

On 2021-06-16 11:38, Marco van de Voort via fpc-pascal wrote:

Op 2021-06-16 om 11:21 schreef Tomas Hajny via fpc-pascal:

 Or if they contain $R inclusions.

...or many other things which may not be smartlinked, either because 
it is not possible, or because the compiler and/or linker cannot do it 
right now.



Yes. But it is good to keep the things that fundamentally can't be
smartlinked (like init sections and resource files) apart from the
ones that might not be smartlinkable  yet, which is only a temporary
assessment of a target.


Well, as an example - if you add FV units App and Views to your uses 
clause, it increases the binary size for mainstream targets as well, 
although these units don't contain initialization sections nor $R 
inclusions. The best recommendation is IMHO different - just pay 
attention to which units you really need/use rather than using a general 
collection.


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

Re: [fpc-pascal] Will the size of an executable depend on the uses clause

[Tomas Hajny via fpc-pascal]

On 2021-06-16 10:58, Marco van de Voort via fpc-pascal wrote:

Op 2021-06-16 om 09:16 schreef Mattias Gaertner via fpc-pascal:

On Wed, 16 Jun 2021 08:57:13 +0200
Bo Berglund via fpc-pascal  wrote:


If I by habit add a bunch of often used units to the uses clause will
that affects the size of the compiled application even if they are
not in fact used?

Yes, if they have e.g. initialization sections.

Or if they contain $R inclusions.


...or many other things which may not be smartlinked, either because it 
is not possible, or because the compiler and/or linker cannot do it 
right now.


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

Re: [fpc-pascal] Will the size of an executable depend on the uses clause

[Tomas Hajny via fpc-pascal]

On 2021-06-16 09:16, Mattias Gaertner via fpc-pascal wrote:

On Wed, 16 Jun 2021 08:57:13 +0200
Bo Berglund via fpc-pascal  wrote:


If I by habit add a bunch of often used units to the uses clause will
that affects the size of the compiled application even if they are
not in fact used?


Yes, if they have e.g. initialization sections.


There are other conditions apart from contents of those particular 
units:


1) Not all targets support smart-linking (i.e. the impact may be even 
larger for those).


2) It depends on options used for the particular compilation as well.

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

Re: [fpc-pascal] FTP support gone - switch to HTTP ?

[Tomas Hajny via fpc-pascal]

On 2021-05-18 18:01, Bo Berglund via fpc-pascal wrote:

On Tue, 18 May 2021 16:20:29 +0100, Henry Vermaak via fpc-pascal
 wrote:


On Tue, 18 May 2021 at 11:50, Sven Barth via fpc-pascal
 wrote:

I don't think we need to mention any specific clients (and why did 
your list not include Filezilla? :P )


Because FileZilla bundles adware when you download from the homepage?
Would actually be good to warn _against_ using it.

Henry


Do you mean that when you use Filezilla to download a file you also get 
adware

files transfered? Never ever seen that.
I have used Filezilla successfully for many-many years and it works 
very well

IMO.


No, it was related to Filezilla installation 
(https://en.wikipedia.org/wiki/FileZilla#Bundled_adware_issues). Please, 
stop discussing specific FTP clients on this list - if you want to 
continue, use fpc-other.


Tomas
(one of FPC mailing list administrators)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FTP support gone - switch to HTTP ?

[Tomas Hajny via fpc-pascal]

On 2021-05-18 10:38, Michael Van Canneyt via fpc-pascal wrote:

On Tue, 18 May 2021, Graeme Geldenhuys via fpc-pascal wrote:



On 17/05/2021 3:13 pm, Karoly Balogh via fpc-pascal wrote:

I'd actually keep
FTP enabled, as it doesn't hurt anything and it's still a thing for 
retro

downloads.


Not just "retro" but a more efficient and faster protocol for file 
downloads.
Unfortunately the whole world is going HTTP crazy and thinks 
everything should

go over it, including the kitchen sink.


I'm old enough to remember the time when I used the NCSA and netscape 
browsers
with the Gopher protocol. Apparently it still exists, on about 300 
sites :-)


I'm old enough to remember that standalone Gopher clients existed well 
before NCSA Mosaic. ;-) Fortunately, there's plenty of standalone FTP 
clients including those with GUI add-ons, we can point out this fact in 
our release communication as well. Out of those mentioned on the 
respective Wikipedia page 
(https://en.wikipedia.org/wiki/Comparison_of_FTP_client_software), 
WinSCP (MS Windows), gFTP (Linux) and Cyberduck (OSX and MS Windows) 
might be worth mentioning (to cover the major platforms); possibly also 
FAR Manager with its FTP plugin (MS Windows, Linux, *BSD, OSX) to extend 
the coverage to *BSD as well (although that's rather TUI than GUI).


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

Re: [fpc-pascal] Dependency of OpenSSL 1.0.2 still in FPC 3.2.0 on some platforms?

[Tomas Hajny via fpc-pascal]

On 2021-05-15 00:25, Bo Berglund via fpc-pascal wrote:
On Wed, 12 May 2021 12:42:14 +0200 (CEST), Michael Van Canneyt via 
fpc-pascal

 wrote:

So right now I try to read up on how to actually handle the mime 
object here...


And I had an additional question:

Does Synapse throw exceptions when errors happen? It does not look 
like that in

the code I have examined so far but I have only looked in two units..


Yes, it does.

You should always assume exceptions. Maybe synapse itself does not 
throw

one, but e.g. underlying file IO routines might.

So I have succeeded in sending a zip file as attachment using Synapse 
code

snippets from your pdf and also the smtp source examples.

However, when I send to 3 of my email addresses (one To and two Cc 
addresses) I
get the email only to one of them. It does not matter if I place that 
address
first or in the middle of the address list, it will get the email in 
any case.


But the two other accounts (my company email managed by Google and my 
private

Gmail) do not get the messages.

Apart from reordering the 3 mail addresses I have also tried to replace 
the
attached zipfile with another non-zip binary file, and then the emails 
to Gmail

accounts are received.

This is baffling and makes it hard to move on. Our monitoring system 
packages
measured data into a zipfile in order for it to be reduced in size and 
because

the data set consists of several files which need to be together.

Is there some kind of blocking for emails with zip attachments which 
stops them

from being delivered to GMail accounts?

If so, is there some other type of compressed  format I can use which 
is allowed

by GMail?


Probably a silly question, but have you checked the Spam folder in 
GMail? In general, you can certainly send ZIP files to GMail. Also, what 
was the size of those attachments? The e-mail used as sender address 
didn't get any SMTP error message, did it? Personally, I'd guess for 
some other difference in your sending apart from the attachment type.


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

Re: [fpc-pascal] [fpc-devel] Nested function closures

[Tomas Hajny via fpc-pascal]

On 2021-04-29 09:00, Mattias Gaertner via fpc-pascal wrote:

On Thu, 29 Apr 2021 07:52:19 +0200
Sven Barth via fpc-pascal  wrote:


[...]
You completely ignored my first point, which in this case is the much
more significant one: Pascal does not support type inference.


FPC does not.
Delphi does:
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Inline_Variable_Declaration

begin
  var MyDictionary := TDictionary.Create;
  for var I:=1 to 10 do ;
end.


Are you aware that Delphi limits this specifically to inline variable 
declaration (quoting including the typo: "compiler can now in several 
circumstances infer the type of a variable at ints line declaration 
location")? One could argue to which extent are inline variable 
declarations still Pascal... :/ (I have my opinion about this, but let's 
save everybody from a flamewar about this topic.)


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

Re: [fpc-pascal] Interruption handling on i8086

[Tomas Hajny via fpc-pascal]

On 2021-04-09 19:56, Guillermo via fpc-pascal wrote:


Hi,

> I'm doing DOS development for fun and, after installing the compiler
> (was quite hard), I'm having problems handling interrupts.
> 
> I started with keyboard and it doesn't work. The handler declaration:
> 
> procedure DOS_KbdHandler; interrupt;
> 
> but compiler says:
> 
> keybrd.inc(14,29) Warning: Calling convention directive ignored:
> "OldFPCCall"

I believe that you need to add the "far" modifier after the "interrupt" - at 
least this has been the case with TP/BP and is probably needed at least for 
some memory models supported with FPC for i8086. The {$F+} directive as 
mentioned in your later post is an alternative, but not needed for the whole 
program (it might make it less efficient). I don't know if there are any other 
caveats.

Tomas

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

Re: [fpc-pascal] Directory Tree

[Tomas Hajny via fpc-pascal]

On 2021-04-06 14:43, James Richters wrote:

Is there any documentation or a sample program for TDirListBox?  I
tried doing a search but only found a page that showed it's functions
and procedures, but no real explanation on what they are supposed to
do.


The functionality is used within the text mode IDE (sources are in 
package IDE). In particular TChDirDialog (still part of FV, in 
particular) is invoked using File / ChDir and it contains TDirListBox as 
one of its subcomponents. The respective implementation is in the 
include file fpmfile.inc (search for PChDirDialog). It's rather simple 
(but it might be enhanced in a possible descendent, of course).


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

Re: [fpc-pascal] Directory Tree

[Tomas Hajny via fpc-pascal]

On 2021-04-06 12:29, James Richters via fpc-pascal wrote:
Does FPC include any tools to display a directory tree, similar to the 
way
files and folders are normally displayed, but I want to make my own 
custom

entries.  Have the branches expand and collapse etc..
It doesn't have to be graphical, it can be text based.
Or Am I going to be better off going graphical with Lazarus for 
something

like this?


Lazarus shall be a more appropriate choice for a graphical output. If 
talking about text output, FPC package FV (FreeVision) contains an 
object TDirListBox which allows traversing the directory tree, but it 
doesn't provide a generic feature of collapsing / expanding (you can 
expand just one directory).


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

Re: [fpc-pascal] SinclairQL (M68K) Port

[Tomas Hajny via fpc-pascal]

On 2021-03-22 12:35, Norman Dunbar via fpc-pascal wrote:
> On 21/03/2021 12:07, Tomas Hajny via fpc-pascal wrote:


Hi Norman,

>> The page https://wiki.freepascal.org/System_unit_structure (referred 
>> to from the 'RTL development articles' appearing on the 'FPC 
>> development' page mentioned above is the one supposed to help
>> in this case, but it is very incomplete, unfortunately. :-( I'll try 
>> to add at least some additional bits.
> 
> I've seen that page, thanks. As you say, it's a wee bit sparse, but it
> was helpful all the same.

In the meantime, I managed to extend the page a bit by adding 
information about the directory layout and some other stuff. I still 
plan to add at least basic description of the Do_* functions, but any 
comments are welcome (or even your own improvements based on your 
findings - remember, that it's a Wiki and you can improve it as well as 
anyone else).

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

Re: [fpc-pascal] SinclairQL (M68K) Port

[Tomas Hajny via fpc-pascal]

On 2021-03-21 10:23, Karoly Balogh via fpc-pascal wrote:

On Sat, 20 Mar 2021, Norman Dunbar via fpc-pascal wrote:



Hi,

 .
 .

It would be helpful to beginners like me, trying to look around and
fix/implement stuff. I've been all over the Wiki and found this page,
https://wiki.freepascal.org/FPC_development, but it's not what I was
looking for although there are some interesting articles on the RTL 
pages.


Yeah, I think code is the best documentation here, as it's changing 
quite

fast, although some overview is probably there and it wouldn't hurt to
make it more easy to find that overview it seems. :)


The page https://wiki.freepascal.org/System_unit_structure (referred to 
from the 'RTL development articles' appearing on the 'FPC development' 
page mentioned above is the one supposed to help in this case, but it is 
very incomplete, unfortunately. :-( I'll try to add at least some 
additional bits.


Tomas
___
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

[Tomas Hajny via fpc-pascal]

On 2021-03-09 09:46, Graeme Geldenhuys via fpc-pascal wrote:

On 09/03/2021 1:44 am, Tomas Hajny via fpc-pascal wrote:
UnicodeString may be used in a program simply because the included 
unit

has it used in its interface. That may be the case even if there's no
use of characters outside of US ASCII at all.


So FPC rather goes with the fact that data may be *silently* lost 
during
encoding conversions? That doesn't seem like a safe default behaviour 
to

me.


The same happens e.g. if you configure your terminal to use a font that 
doesn't contain all the characters which may appear in the output - the 
compiler cannot know all the circumstances and thus cannot handle all of 
them; among others due to the fact that there are decisions to be made 
based on weighing pros and cons in the particular use case and those 
simply aren't 'one size fits all'.


Tomas
___
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

[Tomas Hajny via fpc-pascal]

On 2021-03-08 21:36, Martin Frb via fpc-pascal wrote:
 .
 .

In the example the index access should have returned a single
codeunit, which was known to be a complete codepoint.
As far as I understand the unexpected part was, that the unicode
string did not contain the content of the string constant, because the
assignment had caused an encoding conversion to be inserted.
That conversion caused the need for a widestring manager.

Maybe to help the search when/where and whatfor notes/warnings
should/could be produced, those implicit conversions can be broken
down into groups.
I can think of 2 groups already.
1) Conversion due to explicit declared different encoding.
   AnAnsiString := SomeWideString;
  AnAsciiString := AnUtf8String; // declared as "type
AnsiString(CP_ASCII);" and "type AnsiString(CP_UTF8);"


Do you mean a compile-time warning? The trouble is that the compiler 
wouldn't know whether a real widestring manager would get included in 
the final binary when such conversions are encountered. And remember 
that the final binary may be compiled at a different time from the 
moment when the unit containing such conversions is compiled. In other 
words, compile-time warnings would be rather difficult to implement. It 
might be possible to error-out at runtime when such conversions are 
invoked, but note that technically the conversion may not lead to 
incorrect results if the string doesn't contain characters beyond 
US-ASCII. In other word, a run-time error might be appropriate only if 
the conversion encounters a character it cannot handle. However, adding 
such a check would probably slow-down processing even for cases when the 
strings don't contain any problematic characters.




2) Conversion where at least one string is not explicitly declared for
a certain codepage.
   This should include indirection via $codepage


No, this is not the case. $codepage defines the source file encoding. 
The compiler translates the string constants declared this way to a 
UTF-16 constant stored within the compiled binary. Specifying $codepage 
has no implications on runtime conversions by itself.




Then maybe as a first step, a note/warning could be given, if a
constant string is assigned to a variable, and a change of encoding is
needed for this.
- "constant string" here would be any string that does not have a
direct explicit declared encoding.
- This could be given, even if the presence/absence of a widestring
manager is not known. Because


Because what?



Obviously knowing the presence/absence of a widestring manager allows
to refine warnings.
But I guess that comes at a higher price, as each unit when compiled
could only set flags in the ppu (including forwarding flags from used
units).
And the compiling the final program would read which warning flags are
present, and if any unit flagged the inclusion of a widestring
manager.


Yes, this would be indeed the only possibility.

Tomas
___
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

[Tomas Hajny via fpc-pascal]

On 2021-03-08 11:59, Adriaan van Os via fpc-pascal wrote:


Hi,


adriaan% cat uniquizz-utf8.pas

{$codepage utf8}

program uniquizz;
var
  chars: UnicodeString;
begin
  chars := '⌘ key';
  writeln(chars);
  writeln(chars[1]);
  writeln( 'size ', sizeOf( chars));
  writeln( 'length ', length( chars));
end.

adriaan% fpc uniquizz-utf8.pas -FcUTF-8
Free Pascal Compiler version 3.0.4 [2018/09/30] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Darwin for x86_64
Compiling uniquizz-utf8.pas
Assembling (pipe) uniquizz-utf8.s
Linking uniquizz-utf8
14 lines compiled, 0.1 sec

[l24:~/gpc/testfpc] adriaan% ./uniquizz-utf8
? key
?
size 8
length 5



This leaves me with a question mark too.


UnicodeString is a pointer from technical point of view, SizeOf 
(UnicodeString) thus always returns 8 on 64-bit platforms regardless of 
the string content. Michael already answered regarding the question mark 
output - you need a widestring manager to translate the character from 
the internal storage (UTF-16 - see uniquizz-utf8.s if compiled with -a) 
to your terminal charset.


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

Re: [fpc-pascal] Questions from Semi-Beginner

[Tomas Hajny via fpc-pascal]

On 2021-02-20 17:15, Tomas Hajny wrote:

On 2021-02-20 13:49, Sven Barth via fpc-pascal wrote:
CSlemaker via fpc-pascal  schrieb am 
Sa.,

20. Feb. 2021, 09:48:




Hello everybody,

Please, note that the original poster (in Cc: now, so that he doesn't
miss the response from Sven below) isn't subscribed to fpc-pascal,
make sure to include him in Cc: of your replies.


Oops, sorry :-( - it should probably have been "she", the name wasn't 
visible in the message from Sven and I didn't pay enough attention to 
look it up. In any case, no offence intended.


Tomas




Will I need to recompile my Pascal source files for object 
compatibility

with Win 10?
Should I install the latest version of Free Pascal, and if so, which
version is that?
Will I have any compatibility problems with my source codes and an
up-to-date compiler?


You don't need to do anything except for installing your FPC version 
again.


Of course you're free to upgrade to 3.2.0, but it might involve 
changes, so

that might be something for another day.

P.S. - "Lazarus" is a term I'm not familiar with.  Is it a completely 
new

IDE for Free
   Pascal?  Is there a document which describes differences with the 
old

IDE?
   Is the old IDE still available in case I have trouble with 
Lazarus?




Lazarus is nothing new. It's around 20 years old as well and is a very
stable and comfortable IDE for Free Pascal. You can use it for both 
GUI and

console development and especially the code utilities and the debugger
integration are more advanced than the text mode IDE.

If you want I'd suggest you to simply download Lazarus 2.0.10 and to 
give
it a try. On Windows it comes with FPC 3.2.0 which will *not* 
interfere

with a standalone installation of FPC (e.g. Your 2.6.4).

If you have trouble you can ask here or on the forum (
forum.lazarus.freepascal.org for both FPC and Lazarus) or look at the 
wiki (

wiki.freepascal.org, also for both projects).

Regards,
Sven

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

Re: [fpc-pascal] Questions from Semi-Beginner

[Tomas Hajny via fpc-pascal]

On 2021-02-20 13:49, Sven Barth via fpc-pascal wrote:
CSlemaker via fpc-pascal  schrieb am 
Sa.,

20. Feb. 2021, 09:48:



Hello everybody,

Please, note that the original poster (in Cc: now, so that he doesn't 
miss the response from Sven below) isn't subscribed to fpc-pascal, make 
sure to include him in Cc: of your replies.


Tomas


Will I need to recompile my Pascal source files for object 
compatibility

with Win 10?
Should I install the latest version of Free Pascal, and if so, which
version is that?
Will I have any compatibility problems with my source codes and an
up-to-date compiler?


You don't need to do anything except for installing your FPC version 
again.


Of course you're free to upgrade to 3.2.0, but it might involve 
changes, so

that might be something for another day.

P.S. - "Lazarus" is a term I'm not familiar with.  Is it a completely 
new

IDE for Free
   Pascal?  Is there a document which describes differences with the 
old

IDE?
   Is the old IDE still available in case I have trouble with Lazarus?



Lazarus is nothing new. It's around 20 years old as well and is a very
stable and comfortable IDE for Free Pascal. You can use it for both GUI 
and

console development and especially the code utilities and the debugger
integration are more advanced than the text mode IDE.

If you want I'd suggest you to simply download Lazarus 2.0.10 and to 
give

it a try. On Windows it comes with FPC 3.2.0 which will *not* interfere
with a standalone installation of FPC (e.g. Your 2.6.4).

If you have trouble you can ask here or on the forum (
forum.lazarus.freepascal.org for both FPC and Lazarus) or look at the 
wiki (

wiki.freepascal.org, also for both projects).

Regards,
Sven

___
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)

[Tomas Hajny via fpc-pascal]

On 2020-12-26 15:45, gabor via fpc-pascal wrote:

W dniu 2020-12-22 o 04:57, Nikolay Nikolov via fpc-pascal pisze:


 .
 .

Very interesting. But in a future version of the FV (or other TUI
framework) apart from migrating from objects to classes, using
component streaming, collections, etc...  it would be good if the unit
"drivers" were more abstract and not strictly dependent on Video,
Mouse and Keyboard units. Then it will be possible to create a driver
that, for example, renders the screen buffer in a win32-gdi window, or
even in html5 canvas or LCL.


There's nothing preventing you to implement unit video in these 
environments, IMHO.


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

Re: [fpc-pascal] Selecting Records with a variable

[Tomas Hajny via fpc-pascal]

On 2020-12-20 11:56, Sven Barth via fpc-pascal wrote:

Am 20.12.2020 um 05:26 schrieb Jean SUZINEAU via fpc-pascal:


I know you don't like objects, but maybe something like :



Using modeswitch AdvancedRecords that also works with record types.

And I'd suggest a case-statement as well. Anything else will only be
slower or just as fragile.


If I understand the original case correctly, the wanted behaviour should 
be doable using (extended) RTTI, shouldn't it? Not that I'd know how to 
do that myself, but my (admittedly limited) understanding of RTTI 
suggests this as a possible solution, am I wrong?


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

Re: [fpc-pascal] callback from c with varargs

[Tomas Hajny via fpc-pascal]

On 2020-12-20 14:00, Jonas Maebe via fpc-pascal wrote:

On 20/12/2020 13:01, Luca Olivetti via fpc-pascal wrote:

El 19/12/20 a les 23:15, Jonas Maebe via fpc-pascal ha escrit:
It is indeed not possible to implement a function with C varargs in 
FPC.


I was afraid that's the answer :-(

as an ugly workaround, I wrote a c library that vsnprintf msg and args
to a buffer and then calls a pascal function with no varargs.

It works but, as I said, it's ugly and I'd need to provide a .a for
every platform I plan to use.

Is there a better/simpler way (apart from asking the library 
developers

to use a callback with no varargs)?


No.


Not necessarily better than platform specific .a files mentioned by 
Luca, but the required playing with stack and registers should be still 
doable with a function written in assembler (inside the Pascal sources), 
shouldn't it?


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

Re: [fpc-pascal] Initialization of constant record member of pointer type

[Tomas Hajny via fpc-pascal]

On 2020-12-02 16:01, LacaK via fpc-pascal wrote:

Dňa 2.12.2020 o 13:55 Tomas Hajny via fpc-pascal napísal(a):

On 2020-12-01 11:39, Ladislav Karrach via fpc-pascal wrote:


Because MyConst1 is not an *untyped* constant. Only untyped 
constants can be used in constant expressions (a pointer to 
something can be considered an untyped constant).


The following might work though I did not test it:

=== code begin ===

const
   MyStr = 'abc'
   MyConst1: AnsiString = MyStr;
   MyConst2: TMyRec = (l: Length(MyStr); a: @MyConst1[1]);


=== code end ===


Yes it works, but I must define 2 constants (MyStr and MyConst1),
which is not so nice ;-)

It would be nice to have support for true constants:

const
   MyConst1 = 'abc' ;
   MyConst2: TMyRec = (l: Length(MyConst1); a: @MyConst1[1]);

But may be that there are technical reasons why it is problematic 
(may

be that true constants are stored in another memory locations, which
can not be easy addressed)


Yes, that's one of possible reasons.

Regarding Length in constant value assignment - remember that Length 
is a function. In case of real constants, the call may be replaced by 
the compiler with the constant value. However typed constants may not 
be constant, so generic replacement throughout the source code at 
compile time is not possible (if it appears in the main body or some 
function, the length may already be changed to something else) and 
selective replacement may result in a behaviour not expected by the 
user. The only questionable case is IMHO the case of {$WRITEABLECONST 
OFF} - the compiler _might_ be able to perform the compile-time 
substition in that case (and thus allow using Length of such a 
constant in constant value assignment), but it doesn't do that in that 
case either apparently.


Yes I have no problem with {$WRITEABLECONST OFF} if it will allow 
Length().


Somewhere I read (may be in Delphi documentation) that some intristic
functions like Low(), High(), Pred() and also Length() etc. can be
used in constant expressions because compiler can evaluate them if
theirs arguments are also constants.
Which is the case in my example.
For now {$WRITEABLECONST OFF} does not help ;-)


Yes, that's what I mentioned as well, but it might be changed for this 
particular case. You might create a ticket for that if Delphi allows to 
use Length that way; obviously, you might create such a ticket even if 
Delphi doesn't allow to do that. ;-)


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

Re: [fpc-pascal] Initialization of constant record member of pointer type

[Tomas Hajny via fpc-pascal]

On 2020-12-01 11:39, Ladislav Karrach via fpc-pascal wrote:


Because MyConst1 is not an *untyped* constant. Only untyped constants 
can be used in constant expressions (a pointer to something can be 
considered an untyped constant).


The following might work though I did not test it:

=== code begin ===

const
   MyStr = 'abc'
   MyConst1: AnsiString = MyStr;
   MyConst2: TMyRec = (l: Length(MyStr); a: @MyConst1[1]);


=== code end ===


Yes it works, but I must define 2 constants (MyStr and MyConst1),
which is not so nice ;-)

It would be nice to have support for true constants:

const
   MyConst1 = 'abc' ;
   MyConst2: TMyRec = (l: Length(MyConst1); a: @MyConst1[1]);

But may be that there are technical reasons why it is problematic (may
be that true constants are stored in another memory locations, which
can not be easy addressed)


Yes, that's one of possible reasons.

Regarding Length in constant value assignment - remember that Length is 
a function. In case of real constants, the call may be replaced by the 
compiler with the constant value. However typed constants may not be 
constant, so generic replacement throughout the source code at compile 
time is not possible (if it appears in the main body or some function, 
the length may already be changed to something else) and selective 
replacement may result in a behaviour not expected by the user. The only 
questionable case is IMHO the case of {$WRITEABLECONST OFF} - the 
compiler _might_ be able to perform the compile-time substition in that 
case (and thus allow using Length of such a constant in constant value 
assignment), but it doesn't do that in that case either apparently.


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

Re: [fpc-pascal] I'm working on automated Help Output for console apps

[Tomas Hajny via fpc-pascal]

On 2020-11-20 09:32, Graeme Geldenhuys via fpc-pascal wrote:

On 20/11/2020 7:04 am, Sven Barth via fpc-pascal wrote:

a way to convert the
option list to TConsoleApplication's argument handling so that one 
doesn't

have to declare that twice.


Oh, I really like that idea. I'll make sure to include both of those 
mentioned.


Just a comment - I'm not sure how much general the "mandatory" part is. 
More complex console programs often have "commands" and those have 
different requirements for additional options. As an example, remember 
options for common archivers (rar, arj, ...), command-line version 
control programs (cvs, svn, ...), etc.


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

Re: [fpc-pascal] CRT unit and bug #32558

[Tomas Hajny via fpc-pascal]

On 2020-11-06 23:54, Ched via fpc-pascal wrote:

Dear All,

I have some difficulties using the crt unit.

For what I can see, https://bugs.freepascal.org/view.php?id=32558
could well be the answer, specialy a call like SetUseACP(False); . At
the end of the bug report, it is said that the crt unit will be
ugraded in 3.1.1. I run 3.2.0 under both Linux and W10, but there is
apparently no callable SetUseACP procedure in the crt unit. Is it
available in 3.2.0 ?


Yes, it should be available (under Win32/Win64). It makes no sense under 
Linux, because Linux doesn't differentiate between process codepage and 
console codepate. I guess it doesn't appear in the docs, because those 
are generated under Linux, but you can find it in sources 
(packages/rtl-console/src/win/crt.pp).


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

Re: [fpc-pascal] basic question on begin, end;

[Tomas Hajny via fpc-pascal]

On 2020-09-22 14:46, dano none via fpc-pascal wrote:


Hello,


I have a basic shuffle routine. I put being, end statements in the
outer loop for clarification.
It ended up producing random results.
Commenting out the begin, end combination allows the code to run as 
expected.

My code is below, can someone tell me if the begin, end combination
should actually make a difference, or should they be more ornamental
in function?

 .
 .

Well, your question suggests that your understanding of the Pascal 
language (and creating algorithms in general) shall be improved. The 
begin / end pair creates a block which then becomes part of the program 
structure. If there is a language construct (e.g. a condition, a loop or 
with) which is applied to a statement within the source following this 
construct, using begin / end causes the construct to apply to the whole 
block between begin / end rather than a single statement, thus it indeed 
makes a big difference in many (most) cases.


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

Re: [fpc-pascal] -Fu unit search path and network paths

[Tomas Hajny via fpc-pascal]

On 2020-09-21 14:44, Marco van de Voort via fpc-pascal wrote:

Op 2020-09-21 om 13:44 schreef LacaK via fpc-pascal:


are supported in -Fu (unit search path) networks paths? i.e. 
-Fu\\server\share -Fu\\server\share\path ?
Correction: unit cannot be found only if it is placed in "share 
root" \\server\share !

When is placed in \\server\share\path then it is found.

Why?


Possibly Share vs directory.   A directory has 4 slashes 
(\\x\y\

Try \\server\share\.
*Does not works. More confusing is that, when I map \\server\share to 
F:\ and I add F:\ to search path it does not work also!

*

*(if unit is in any subdirectory i.e. F:\something then it works ... 
so only root does not work!)*


*
*


[0.015] Handling option "-Fud:\"
[0.015] interpreting option "-Fud:\"
[0.015] Path "D:\" not found

So the path exist function probably fails on root dirs.


This looks like the infamous wrong implementation of checking of 
directory existence based on reading its attributes (which doesn't work 
for the root directory, because it has no specific entry on the 
file-system and thus also no attributes, at least on DOS-like systems) 
without special handling of the special case of the root directory:


cfileutl.pas, line 361-375 (trunk):

function TCachedDirectory.DirectoryExists(const 
AName:TCmdStr):boolean;

  var
Attr : Longint;
  begin
if not TryUseCache then
  begin
Result:=PathExists(Name+AName,false);
exit;
  end;
Attr:=GetItemAttr(AName);
if Attr<>0 then
  Result:=((Attr and faDirectory)=faDirectory)
else
  Result:=false;
  end;

I suggest filing a bug report.

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

Re: [fpc-pascal] String literals and code page of .pas source file

[Tomas Hajny via fpc-pascal]

On 2020-09-14 16:09, Michael Van Canneyt wrote:

On Mon, 14 Sep 2020, Tomas Hajny via fpc-pascal wrote:

application (let's say notepad.exe) will result in garbage.  I don't 
say that it is necessarily bad, but it should be documented at least 
if we want to keep it that way.


I would definitely keep it that way.

As I see it: Redirection or not should not matter, the system should
assume console output.
Things like 'tee' make this concept dubious in any case:

If you pipe output to a program, you don't expect the codepage to 
change

because of the redirection.


No problem, but I'd suggest documenting it at least.


Document what exactly ? That redirecting does not change the codepage ?


1) Document that the following test program results in two different 
lines under Win32/Win64 (unless you change the console codepage to be 
equal to the process codepage before running the program):


{$CODEPAGE CP1250}
const
 S = 'Úžasné';
var
 A: ansistring;
 T: text;
begin
 Assign (T, '');
 Rewrite (T);
 A := S;
 WriteLn (A);
 WriteLn (T, A);
 Close (T);
end.


2) Document that the following test program compiled, run and having the 
output redirected to a file named output1.txt results in two files with 
different content (again unless you change the console to the process 
codepage before running the program):


{$CODEPAGE CP1250}
const
 S = 'Úžasné';
var
 A: ansistring;
 T: text;
begin
 Assign (T, 'output2.txt');
 Rewrite (T);
 A := S;
 WriteLn (A);
 WriteLn (T, A);
 Close (T);
end.


 .
 .

Not really accidental:

r3606 | florian | 2006-05-20 23:42:58 +0200 (Sat, 20 May 2006) | 2 
lines
* fix from Maxim Ganetsky to fix CRT output with non latin code pages, 
should fix #6785


(there were additional changes performed later, but the primary change 
was this one)


Does this handle UTF8 ?


In what sense? It works correctly (under Win32/Win64) if I change the 
console codepage to 65001 (both for shortstrings and for ansistrings), 
and it works correctly if I assign a constant to an Utf8string and write 
it to the console regardless from the console codepage.




Judging by the sources, I would think not:

Interface

{$mode fpc} // Shortstring is assumed
{$i crth.inc}

Const
  { Controlling consts }
  Flushing = false;   {if true then don't buffer 
output}

  ConsoleMaxX  = 1024;
  ConsoleMaxY  = 1024;
  ScreenHeight : longint = 25;
  ScreenWidth  : longint = 80;

Type
  TCharAttr=packed record
ch   : char;
attr : byte;
  end;
  TConsoleBuf=Array[0..ConsoleMaxX*ConsoleMaxY-1] of TCharAttr;
  PConsoleBuf=^TConsoleBuf;

var
  ConsoleBuf : PConsoleBuf;

Since every screen position handles only a single char (byte) there is 
no
way this can handle UTF8. Maybe other "real" single-byte codepages, 
yes.


I assume that you're looking at the implementation for Linux, whereas I 
talk about the implementation for Win32/Win64. I don't know if it makes 
any difference with regard to UTF-8 string handling on Linux (I'm not 
aware of any particular issues, but I might be wrong).


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

Re: [fpc-pascal] String literals and code page of .pas source file

[Tomas Hajny via fpc-pascal]

On 2020-09-14 16:09, Michael Van Canneyt wrote:

On Mon, 14 Sep 2020, Tomas Hajny via fpc-pascal wrote:

application (let's say notepad.exe) will result in garbage.  I don't 
say that it is necessarily bad, but it should be documented at least 
if we want to keep it that way.


I would definitely keep it that way.

As I see it: Redirection or not should not matter, the system should
assume console output.
Things like 'tee' make this concept dubious in any case:

If you pipe output to a program, you don't expect the codepage to 
change

because of the redirection.


No problem, but I'd suggest documenting it at least.


Document what exactly ? That redirecting does not change the codepage ?


1) Document that the following test program results in two different 
lines under Win32/Win64 (unless you change the console codepage to be 
equal to the process codepage before running the program):


{$CODEPAGE CP1250}
const
 S = 'Úžasné';
var
 A: ansistring;
 T: text;
begin
 Assign (T, '');
 Rewrite (T);
 A := S;
 WriteLn (A);
 WriteLn (T, A);
 Close (T);
end.


2) Document that the following test program compiled, run and having the 
output redirected to a file named output1.txt results in two files with 
different content (again unless you change the console to the process 
codepage before running the program):


{$CODEPAGE CP1250}
const
 S = 'Úžasné';
var
 A: ansistring;
 T: text;
begin
 Assign (T, 'output2.txt');
 Rewrite (T);
 A := S;
 WriteLn (A);
 WriteLn (T, A);
 Close (T);
end.


 .
 .

Not really accidental:

r3606 | florian | 2006-05-20 23:42:58 +0200 (Sat, 20 May 2006) | 2 
lines
* fix from Maxim Ganetsky to fix CRT output with non latin code pages, 
should fix #6785


(there were additional changes performed later, but the primary change 
was this one)


Does this handle UTF8 ?


In what sense? It works correctly (under Win32/Win64) if I change the 
console codepage to 65001 (both for shortstrings and for ansistrings), 
and it works correctly if I assign a constant to an Utf8string and write 
it to the console regardless from the console codepage.




Judging by the sources, I would think not:

Interface

{$mode fpc} // Shortstring is assumed
{$i crth.inc}

Const
  { Controlling consts }
  Flushing = false;   {if true then don't buffer 
output}

  ConsoleMaxX  = 1024;
  ConsoleMaxY  = 1024;
  ScreenHeight : longint = 25;
  ScreenWidth  : longint = 80;

Type
  TCharAttr=packed record
ch   : char;
attr : byte;
  end;
  TConsoleBuf=Array[0..ConsoleMaxX*ConsoleMaxY-1] of TCharAttr;
  PConsoleBuf=^TConsoleBuf;

var
  ConsoleBuf : PConsoleBuf;

Since every screen position handles only a single char (byte) there is 
no
way this can handle UTF8. Maybe other "real" single-byte codepages, 
yes.


I assume that you're looking at the implementation for Linux, whereas I 
talk about the implementation for Win32/Win64. I don't know if it makes 
any difference with regard to UTF-8 string handling on Linux (I'm not 
aware of any particular issues, but I might be wrong).


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

Re: [fpc-pascal] String literals and code page of .pas source file

[Tomas Hajny via fpc-pascal]

On 2020-09-14 14:51, Michael Van Canneyt wrote:

On Mon, 14 Sep 2020, Tomas Hajny via fpc-pascal wrote:


opened:
{$ifdef FPC_HAS_FEATURE_ANSISTRINGS}
  { if no codepage is yet assigned then assign default ansi codepage 
}

  TextRec(t).CodePage:=TranslatePlaceholderCP(TextRec(t).CodePage);
{$else FPC_HAS_FEATURE_ANSISTRINGS}

I see no need to change this ?


Please, have a look at OpenStdIO (implemented at the end of text.inc). 
That one changes the default codepage for Input, Output and StdErr, 
but it doesn't care about possible redirection and/or piping to some 
other application (not necessarily written in FPC). That approach has 
both advantages and disadvantages. The advantage is that "type 
" will give correct results on the console. The 
disadvantage is that opening the redirected file with any Win32 GUI 
application (let's say notepad.exe) will result in garbage.  I don't 
say that it is necessarily bad, but it should be documented at least 
if we want to keep it that way.


I would definitely keep it that way.

As I see it: Redirection or not should not matter, the system should
assume console output.
Things like 'tee' make this concept dubious in any case:

If you pipe output to a program, you don't expect the codepage to 
change

because of the redirection.


No problem, but I'd suggest documenting it at least.


I think it will differ since Crt is not codepage aware. If you want 
it to
work the same you'll have to make Crt codepage (and hence unicode) 
aware.


As mentioned by me, Crt is currently more codepage aware than the 
System unit output as far as output to console is concerned, because 
Crt provides correct output even for shortstrings (unlike the System 
unit).


I would need to check the details, but that sounds more like
accidental behaviour as opposed to intended behaviour to me :-)



Not really accidental:

r3606 | florian | 2006-05-20 23:42:58 +0200 (Sat, 20 May 2006) | 2 lines
* fix from Maxim Ganetsky to fix CRT output with non latin code pages, 
should fix #6785


(there were additional changes performed later, but the primary change 
was this one)


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

Re: [fpc-pascal] String literals and code page of .pas source file

[Tomas Hajny via fpc-pascal]

On 2020-09-14 14:20, Michael Van Canneyt wrote:

On Mon, 14 Sep 2020, Tomas Hajny via fpc-pascal wrote:

On 2020-09-14 13:39, Michael Van Canneyt wrote:

On Mon, 14 Sep 2020, Tomas Hajny via fpc-pascal wrote:


On 2020-09-12 23:03, Tomas Hajny wrote:

On 2020-09-12 18:51, Jonas Maebe via fpc-pascal wrote:

On 12/09/2020 18:44, Sven Barth via fpc-pascal wrote:

Jonas Maebe via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> schrieb am Sa., 12. 
Sep. 2020,

17:47:

 .
 .
1) Wouldn't it be better if shortstrings are treated the same way as 
ansistrings with CP_ACP? This would make a difference only during 
assignments to strings with different codepages. Since strings with 
different codepages didn't exist in the past (and in the current 
situation they are simply broken), this change shouldn't break 
compatibility hopefully.


No idea what to advise here. I would think shortstring is ASCII or 
OEM

codepage, not even ANSI :/


As far as I'm concerned, there's no difference between OEM or ANSI (or 
ISO 8859-x for that matter) _unless_ somebody targets Win32/Win64 and 
never anything else. From this point of view, there's no reason why 
shortstrings should be always OEM. Historically, they were used simply 
for the default characters set on the particular operaing environment.



2) Shouldn't WriteLn with a untyped string constant parameter result 
in calling some Unicode based version of WriteLn rather than the 
shortstring overloaded version (since the constant

is stored in UTF-16 internally)?


What is the codepage of a constant string ? Should this not be used ?


That's what I wrote - internally, the (untyped) constant strings are 
stored in UTF-16.



3) Shouldn't we try to make the output of Write with and without 
unit Crt compatible to each other? If we do so, what should be the 
encoding used for output redirected to a file - should it use 
DefaultSystemCodePage, or scpConsoleCP, or what (remember that this 
question doesn't exist with unit Crt, because unit Crt isn't 
compatible with redirection).


I think this last one are in fact 3 questions:
- What to do if output is redirected externally ? (IMHO nothing)


There's no "nothing". Every text file record has an attribute stating 
the codepage used for that text file. The question is which codepage 
should be assigned there under which cases.


Why do you want to assign one ? It's the responsability of the user to
set the correct codepage.

As far as I can see it is initialized to the default one when the file 
is

opened:
{$ifdef FPC_HAS_FEATURE_ANSISTRINGS}
  { if no codepage is yet assigned then assign default ansi codepage }
  TextRec(t).CodePage:=TranslatePlaceholderCP(TextRec(t).CodePage);
{$else FPC_HAS_FEATURE_ANSISTRINGS}

I see no need to change this ?


Please, have a look at OpenStdIO (implemented at the end of text.inc). 
That one changes the default codepage for Input, Output and StdErr, but 
it doesn't care about possible redirection and/or piping to some other 
application (not necessarily written in FPC). That approach has both 
advantages and disadvantages. The advantage is that "type 
" will give correct results on the console. The 
disadvantage is that opening the redirected file with any Win32 GUI 
application (let's say notepad.exe) will result in garbage. I don't say 
that it is necessarily bad, but it should be documented at least if we 
want to keep it that way.




- What to do if output is redirected internally ? (IMHO, the codepage
should be kept)


Kept from what?


Things like AssignCRT() should not set the codepage on the passed text 
record.


AssignCrt doesn't do that. The translation is performed when calling the 
console output functions (on MS Windows).




- Whether and how to extend Crt so it works with unicode.
  (Since Crt is legacy, I would not touch it; You'd need to rewrite 
it

as unicode.)


That is a different question and I don't want to raise that one. My 
question is simply whether WriteLn (shortstring) should behave 
differently with and without Crt.


I think it will differ since Crt is not codepage aware. If you want it 
to
work the same you'll have to make Crt codepage (and hence unicode) 
aware.


As mentioned by me, Crt is currently more codepage aware than the System 
unit output as far as output to console is concerned, because Crt 
provides correct output even for shortstrings (unlike the System unit).


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

Re: [fpc-pascal] String literals and code page of .pas source file

[Tomas Hajny via fpc-pascal]

On 2020-09-14 13:39, Michael Van Canneyt wrote:

On Mon, 14 Sep 2020, Tomas Hajny via fpc-pascal wrote:


On 2020-09-12 23:03, Tomas Hajny wrote:

On 2020-09-12 18:51, Jonas Maebe via fpc-pascal wrote:

On 12/09/2020 18:44, Sven Barth via fpc-pascal wrote:

Jonas Maebe via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> schrieb am Sa., 12. Sep. 
2020,

17:47:

 .
 .
1) Wouldn't it be better if shortstrings are treated the same way as 
ansistrings with CP_ACP? This would make a difference only during 
assignments to strings with different codepages. Since strings with 
different codepages didn't exist in the past (and in the current 
situation they are simply broken), this change shouldn't break 
compatibility hopefully.


No idea what to advise here. I would think shortstring is ASCII or OEM
codepage, not even ANSI :/


As far as I'm concerned, there's no difference between OEM or ANSI (or 
ISO 8859-x for that matter) _unless_ somebody targets Win32/Win64 and 
never anything else. From this point of view, there's no reason why 
shortstrings should be always OEM. Historically, they were used simply 
for the default characters set on the particular operaing environment.



2) Shouldn't WriteLn with a untyped string constant parameter result 
in calling some Unicode based version of WriteLn rather than the 
shortstring overloaded version (since the constant

is stored in UTF-16 internally)?


What is the codepage of a constant string ? Should this not be used ?


That's what I wrote - internally, the (untyped) constant strings are 
stored in UTF-16.



3) Shouldn't we try to make the output of Write with and without unit 
Crt compatible to each other? If we do so, what should be the encoding 
used for output redirected to a file - should it use 
DefaultSystemCodePage, or scpConsoleCP, or what (remember that this 
question doesn't exist with unit Crt, because unit Crt isn't 
compatible with redirection).


I think this last one are in fact 3 questions:
- What to do if output is redirected externally ? (IMHO nothing)


There's no "nothing". Every text file record has an attribute stating 
the codepage used for that text file. The question is which codepage 
should be assigned there under which cases.




- What to do if output is redirected internally ? (IMHO, the codepage
should be kept)


Kept from what?



- Whether and how to extend Crt so it works with unicode.
  (Since Crt is legacy, I would not touch it; You'd need to rewrite it
as unicode.)


That is a different question and I don't want to raise that one. My 
question is simply whether WriteLn (shortstring) should behave 
differently with and without Crt.


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

Re: [fpc-pascal] String literals and code page of .pas source file

[Tomas Hajny via fpc-pascal]

On 2020-09-12 23:03, Tomas Hajny wrote:

On 2020-09-12 18:51, Jonas Maebe via fpc-pascal wrote:

On 12/09/2020 18:44, Sven Barth via fpc-pascal wrote:

Jonas Maebe via fpc-pascal > schrieb am Sa., 12. Sep. 
2020,

17:47:

 .
 .

While performing some tests, I came across other things which are not
very nice either (those are specific to the Win32/Win64 target due to
the difference between process codepage and console codepage). Let's
take the following test program:

{$codepage cp1250}
{$IFDEF USECRT}
uses
 Crt;
{$ENDIF USECRT}
const
 S = 'žluťoučký kůň';
var
 T: string;
begin
 T := S;
{$IFDEF USECRT}
 Write ('Using Crt');
{$ELSE USECRT}
 Write ('Not using Crt');
{$ENDIF USECRT}
 WriteLn (S);
 WriteLn (T);
 WriteLn (DefaultSystemCodepage);
 WriteLn (TextRec (Output).Codepage);
end.

Let's compile it _without_ -dUSECRT and _with_ -Mfpc first. The
original poster uses the same default codepage as me. If I start
cmd.exe and run "chcp" without parameters, it shows codepage 852 as
the console codepage. Now run the test program. It shows that the
codepage for the default file handle Output matches the console
codepage (as it should), but the string output is incorrect for both
WriteLn(S) and WriteLn(T) lines. If you perform "chcp 1250" and run
the program again, the codepages match and the string output is
correct.

If you compile the same program with -dUSECRT, the output is correct
for both WriteLn calls regardless from the console codepage setting
(i.e. both for "chcp 852" and for "chcp 1250" - and also for "chcp
65001").

If you compile the same program with -dUSECRT and -Mdelphi together
and run the program in a console window set to codepage 852 (i.e. the
default setting here), the first WriteLn call is wrong, whereas the
second gives a correct result (due to the fact that T becomes an
ansistring in mode Delphi and dynamic translation is thus performed as
opposed to the case when a shortstring or an untyped constant are
passed).


Questions resulting from my test above and the observed inconsistencies:

1) Wouldn't it be better if shortstrings are treated the same way as 
ansistrings with CP_ACP? This would make a difference only during 
assignments to strings with different codepages. Since strings with 
different codepages didn't exist in the past (and in the current 
situation they are simply broken), this change shouldn't break 
compatibility hopefully.


2) Shouldn't WriteLn with a untyped string constant parameter result in 
calling some Unicode based version of WriteLn rather than the 
shortstring overloaded version (since the constant is stored in UTF-16 
internally)?


3) Shouldn't we try to make the output of Write with and without unit 
Crt compatible to each other? If we do so, what should be the encoding 
used for output redirected to a file - should it use 
DefaultSystemCodePage, or scpConsoleCP, or what (remember that this 
question doesn't exist with unit Crt, because unit Crt isn't compatible 
with redirection).


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

Re: [fpc-pascal] String literals and code page of .pas source file

[Tomas Hajny via fpc-pascal]

On 2020-09-12 18:51, Jonas Maebe via fpc-pascal wrote:

On 12/09/2020 18:44, Sven Barth via fpc-pascal wrote:

Jonas Maebe via fpc-pascal > schrieb am Sa., 12. Sep. 
2020,

17:47:

> All the doubts, questions, and discussions prove that current
system is
> counter-intuitive and confusing.

The issue in this thread is caused by a bug in the LCL: it blindly
assumes that the dynamic code page of the caption string is always
utf-8. That is simply wrong (unless you put the burden on the user 
to

always assign an utf-8-encoded string to it, but _that_ is
counter-intuitive and confusing).


But shouldn't the compiler insert a conversion if the string is 
declared

as CP_1250 and the destination is CP_ACP? 


There are two things:
1) regardless of how the static code page of a string is declared, it 
is

never guaranteed that its dynamic code page will match it. The simplest
example is when you assign a RawByteString to it. There is, however,
also a second case (and this one indeed is counter-intuitive, but 
needed

for backward compatibility):
2) the second bullet under
https://wiki.freepascal.org/FPC_Unicode_support#Dynamic_code_page

That's what gets triggered here: the source file CP is CP_1250 and the
string is also ansistring(1250). That case would be solved by declaring
Label as UTF8String though.


Yep.

While performing some tests, I came across other things which are not 
very nice either (those are specific to the Win32/Win64 target due to 
the difference between process codepage and console codepage). Let's 
take the following test program:


{$codepage cp1250}
{$IFDEF USECRT}
uses
 Crt;
{$ENDIF USECRT}
const
 S = 'žluťoučký kůň';
var
 T: string;
begin
 T := S;
{$IFDEF USECRT}
 Write ('Using Crt');
{$ELSE USECRT}
 Write ('Not using Crt');
{$ENDIF USECRT}
 WriteLn (S);
 WriteLn (T);
 WriteLn (DefaultSystemCodepage);
 WriteLn (TextRec (Output).Codepage);
end.

Let's compile it _without_ -dUSECRT and _with_ -Mfpc first. The original 
poster uses the same default codepage as me. If I start cmd.exe and run 
"chcp" without parameters, it shows codepage 852 as the console 
codepage. Now run the test program. It shows that the codepage for the 
default file handle Output matches the console codepage (as it should), 
but the string output is incorrect for both WriteLn(S) and WriteLn(T) 
lines. If you perform "chcp 1250" and run the program again, the 
codepages match and the string output is correct.


If you compile the same program with -dUSECRT, the output is correct for 
both WriteLn calls regardless from the console codepage setting (i.e. 
both for "chcp 852" and for "chcp 1250" - and also for "chcp 65001").


If you compile the same program with -dUSECRT and -Mdelphi together and 
run the program in a console window set to codepage 852 (i.e. the 
default setting here), the first WriteLn call is wrong, whereas the 
second gives a correct result (due to the fact that T becomes an 
ansistring in mode Delphi and dynamic translation is thus performed as 
opposed to the case when a shortstring or an untyped constant are 
passed).


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

Re: [fpc-pascal] Fpc make questions...

[Tomas Hajny via fpc-pascal]

On 2020-09-11 21:51, Bo Berglund via fpc-pascal wrote:

I am not very informed about how make works when building fpc
installations, I have just used commands I have gathered online and it
has worked...

Now I would like to know:
1) Does make clean inside the fpc source dir erase ALL of the binaries
produced by an earlier build inside that source tree?


Yes, as long as the same target is involved. If you want to clean for 
results of possible cross-compilations as well, use 'make distclean'.




2) If so, does these two versions of "make all" build for ARMv7 and
ARMv6 respecitively:
make all FPC=/home/pi/dev/ppcarm OPT="-dFPC_ARMHF"
make all FPC=/home/pi/dev/ppcarm OPT="-dFPC_ARMHF -CpARMV6 -OpARMV6"


I know nothing about ARM thus I can't answer this one.



3) Does the following command overwrite existing files from an earlier
attempt so the CPU target can be replaced?
For ARMv7:
make install OPT="-dFPC_ARMHF" PREFIX=/home/pi
FPC="/home/pi/dev/ppcarm"
For ARMv6:
make install OPT="-dFPC_ARMHF -CpARMV6 -OpARMV6" PREFIX=/home/pi
FPC="/home/pi/dev/ppcarm"


If you perform 'make all' before running 'make install', then you 
probably don't need the OPT=... parameter for 'make install'.




4) Do I also need to switch the seed compiler /home/pi/dev/ppcarm
(3.0.4) between v6 and v7 or can any of the two work to build
correctly fpc itself?


No - as long as the seed compiler works on your machine and is supported 
by the makefiles (i.e. isn't too old), you can use the same seed 
compiler. Preferably, you should use a seed compiler from the last 
official release for your platform.




The reason I am asking is that I need to switch my system from
building ARMv7 binaries to build ARMv6 binaries and I don't want to
start over from scratch on this RPi, which I have used for some
time...

Hopefully

make clean
make all
make install

with the proper options will do the trick
TIA..


They should.

Tomas




___
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] String literals and code page of .pas source file

[Tomas Hajny via fpc-pascal]

On 2020-09-09 17:59, Mattias Gaertner via fpc-pascal wrote:

On Wed, 09 Sep 2020 17:44:11 +0200
Tomas Hajny via fpc-pascal  wrote:

 .
 .

The implicit conversion is explicitly expected by the user
in this case if I understand it correctly (source in CP1250), right?


If you mean the "non implicit conversion" requires explicit
conversion by the user, then yes.


No, I mean that the original poster explicitly mentioned that he 
expected the implicit conversion to be performed as necessary when he 
specified that his source code was in CP1250.


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

Re: [fpc-pascal] String literals and code page of .pas source file

[Tomas Hajny via fpc-pascal]

On 2020-09-09 17:37, Mattias Gaertner via fpc-pascal wrote:

On Wed, 09 Sep 2020 17:25:09 +0200
Tomas Hajny via fpc-pascal  wrote:


On 2020-09-09 13:51, LacaK via fpc-pascal wrote:
[...]
A simple question - is TLabel.Caption declared as Utf8String (I don't
use Lazarus)? _Then_ it should work without any issues and/or special
attention from users.


Declaring as UTF8String would insert implicit conversion code for all
String (CP_ACP), so basically everywhere.


Everywhere except when used with other Utf8string variables and 
constants. The implicit conversion is explicitly expected by the user in 
this case if I understand it correctly (source in CP1250), right?


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

Re: [fpc-pascal] String literals and code page of .pas source file

[Tomas Hajny via fpc-pascal]

On 2020-09-09 17:30, Bart via fpc-pascal wrote:

On Wed, Sep 9, 2020 at 5:25 PM Tomas Hajny via fpc-pascal
 wrote:


A simple question - is TLabel.Caption declared as Utf8String


No.


No wonder that the implicit conversion doesn't work then. Adding an 
explicit conversion would be another possible option, although obviously 
tedious.


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