Re: [fpc-pascal] Type-casting a class variable

[Marco van de Voort via fpc-pascal]

Op 2-5-2024 om 08:32 schreef Adriaan van Os via fpc-pascal:



TWindow(myClass).CreateNewWindow;


And this is what crashes. I can report this, if the type-cast is 
supposed to work.



Known gotcha. Is and as are no good for method variables, use:

if myclass.inheritsfrom(twindow) then

    twindow(myclass).createnewwindow

else

  raise exception.create('something''s rotten in the state of ...');


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

Re: [fpc-pascal] AnsiString address changed

[Marco van de Voort via fpc-pascal]

Op 18-3-2024 om 09:27 schreef Hairy Pixels via fpc-pascal:

  do that, you'll have the same output 3 times.
Oh, it's a pointer to a pointer?


No, it is a pointer variable, but you take the address (@) of that 
pointer, which causes the second indirection



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

Re: [fpc-pascal] FP IDE sources

[Marco van de Voort via fpc-pascal]

Op 14-3-2024 om 11:52 schreef Tomas Hajny via fpc-pascal:



"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. ;-)


Note that I don't feel very strong about moving it to utils, frankly I 
don't care. There is also the matter than the IDE is not the only one 
generating installed programs, some other packages (like package CHM) 
that also generate binaries, would have to be split then (!?!?)


My point was more that _if_ it is to be moved, parallel compilation 
should be retained, and I gave a possible direction


Major buildsystem work is preferably done just before a new major 
release branch is split off trunk, but by then 3.2.0 was probably 
already branched off.   Rearrangements during a release cycle makes 
merging back to fixes hard for a long period.



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

Re: [fpc-pascal] FP IDE sources

[Marco van de Voort via fpc-pascal]

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

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

Re: [fpc-pascal] FP IDE sources

[Marco van de Voort via fpc-pascal]

Op 14-3-2024 om 09:34 schreef Guillermo Martínez Jiménez via fpc-pascal:

Thanks, Karoly and Marco.

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


Roughly the RTL is a base set of units needed for the compiler itself. 
When the compiler bootstraps it is compiled several times.


Most units not needed for the compiler have thus moved out into packages 
that is not compiled multiple time, and directories in packages/ can be 
compiled in parallel to some degree.


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

Re: [fpc-pascal] FP IDE sources

[Marco van de Voort via fpc-pascal]

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

Re: [fpc-pascal] Floating point question

[Marco van de Voort via fpc-pascal]

Op 22-2-2024 om 15:08 schreef Thomas Kurz via fpc-pascal:

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 problem is not that it is only Extended that is deprecated on win64, 
but the whole of x87. To replace it, the Windows 64-bit ABI points to 
SSE2 floating point math which only goes up to 64-bit Double.


I.e. it is not that Microsoft might not in time save the few extra bits 
of an extended in a x87 context save, but more that it won't save the 
x87 state at all, and only save the SSE2 state.


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

Re: [fpc-pascal] Floating point question

[Marco van de Voort via fpc-pascal]

Op 13-2-2024 om 11:39 schreef Bernd Oppolzer via fpc-pascal:



But, sorry, because we are talking about compile time math, 
performance (nanoseconds) in this case doesn't count, IMO.


But probably compiled code is then automatically upscaled to the higher 
type too, since if one of the terms of an expression is of higher 
precision, then the whole expression is.

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

Re: [fpc-pascal] IntToStr implementation

[Marco van de Voort via fpc-pascal]

Op 17-1-2024 om 15:57 schreef Hairy Pixels via fpc-pascal:

Can anyone show me where to find the IntToStr implementation in SysUtils? 
There's so many level of indirection and macros I have no idea where to look 
for it!


Grep rtl/objpas/sysutils for it.


sysstr.inc for the implementation sysstrh.inc for the declaration


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

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

[Marco van de Voort via fpc-pascal]

Op 7-1-2024 om 16:09 schreef Travis Siegel via fpc-pascal:

Not that it's 100 percent relevant, but I always use powerbasic 
(https://www.powerbasic.com) when it's a matter of size, 


I also never use powerbasic.

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

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

[Marco van de Voort via fpc-pascal]

Op 8-1-2024 om 14:03 schreef Karoly Balogh via fpc-pascal:

No, it's not. But the Linker specific options are under Options ->
Linker... There's a smartlinking related option there, but I'm not sure if
it is what you need. :)


That one is -XX, and the "create smartlinkable units" in the tab before 
is -CX (generate smartlinkable units or something similar) .


If you change these, force a build afterwards.



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

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

[Marco van de Voort via fpc-pascal]

Op 7-1-2024 om 11:23 schreef Sven Barth via fpc-pascal:
To underline this with some numbers (I assume you mean the 
demo/text/hello.pp which only contains a mere "Writeln('Hello World')" 
and no additional units; all tests on x86_64-linux with 3.3.1):


- FPC compiled as is: 388976 B
- FPC compiled with full smartlinking: 55920 B
- FPC compiled with C linkage: 388760 B
- FPC compiled with full smartlinking and C linkage: 56792 B

(gotta admit, the last one surprised me though ^^')

I noticed that when I implemented -dFPC_USE_LIBC. The dynamic library 
overhead is bigger than the 15-20kb worth of routines saved in fairly 
simple programs. In the past is was even more pronounced because readdir 
was kernel.


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

Re: [fpc-pascal] How to avoid Copy

[Marco van de Voort via fpc-pascal]

Op 31/12/2023 om 04:11 schreef Amir--- via fpc-pascal:


I compiled the code with `fpc -O3 -Sd -gv -g -gl ` and ran `valgrind` 
on it (the output is attached). It does not look like there is a big 
difference between the Check1 and Check2 but Check3 is about 20 times 
faster than the other two.
I believe the issue could be resolved if we make 
"TCustomListWithPointers.GetPtrEnumerator" a public method. Then, one 
can implement the following function:


 I also do this (an enumerator using a pointer type) in one of my 
container types. It also makes assignment in the for in possible.  Note 
though that it is not necessarily needed to switch the whole collection 
to use a pointer, defining a separate iterator (e.g. 
collection.pointeriterator) that returns an iterator instantiated for 
^T.   You can then select the iterator by using for element in 
collection.iterator do.


The rtl-generics collections already have multiple iterators since for 
maps it is possible to iterate over the keys, the values or 
TPair

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

Re: [fpc-pascal] Daily snapshots?

[Marco van de Voort via fpc-pascal]

Op 27/12/2023 om 12:38 schreef Thomas Kurz via fpc-pascal:


as it seems to take longer for the next major release, I'd appreciate if 
automated snapshots could be provided either daily or weekly.

In the documentation, I found a link to 
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/ but I cannot login. I tried 
with user=anynous and password=my-email-address.

I don't mind the long time for the next release, but it'd help enormously to 
have the option to download an up-to-date nightly build :)


The FTP site has been converted to http because many browsers deprecated 
the FTP protocol, try http://downloads.freepascal.org/fpc/snapshot/fixes/


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

Re: [fpc-pascal] Does the compiler make prodigious use of use ENTER instruction?

[Marco van de Voort via fpc-pascal]

Op 12-12-2023 om 17:48 schreef Anthony Walter via fpc-pascal:
Iwas reading this article today on the Microsoft website about the 
mysterious x86 ENTER instruction. The article states that it's primary 
purpose is to support Pascal and similar compilers to allow for 
preserving local variables on the stack when using with nested functions.


Here is the article:

https://devblogs.microsoft.com/oldnewthing/20231211-00/?p=109126

Do any of the compiler devs know if Pascal programs for the x86 
instruction set are using ENTER and its second argument to the best 
possible effect? I am curious.


No, and if they do, they don't do in the way they are meant to. These 
are very old instructions and the intended use has a nesting limit (of 
32 levels iiirc).  Because of that limit, modern compilers don't use them.


Some forms of enter and leave are use as peephole optimizations.


___
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

[Marco van de Voort via fpc-pascal]

On 1-9-2023 15:43, Rainer Stratmann via fpc-pascal wrote:

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.


How do you start it? TProcess, Runcommand have piping options.

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

Re: [fpc-pascal] Microsoft SAPI on Freepascal

[Marco van de Voort via fpc-pascal]

On 26-6-2023 21:39, Michael Van Canneyt via fpc-pascal wrote:

 (afaik 3.2.2's comobj does this automatically, in older version YMMV).

Well, I checked prior to sending my answer. If it does this, it's well 
hidden. There seems to be some hook for it, though.


It hooks initproc into a linked list fashion which is called at the end 
of FPC_INITIALIZEUNITS, which is a way to put it last/late in the init 
sequence.



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

Re: [fpc-pascal] Microsoft SAPI on Freepascal

[Marco van de Voort via fpc-pascal]

On 26-6-2023 20:26, Michael Van Canneyt via fpc-pascal wrote:


I suspect COM is not properly initialized, and that Lazarus does this 
for you.

(it needs com for some components on windows)

So, try adding unit windows to the uses clause and add

CoInitialize(nil);

as the first statement of your program.



(afaik 3.2.2's comobj does this automatically, in older version YMMV).


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

Re: [fpc-pascal] Microsoft SAPI on Freepascal

[Marco van de Voort via fpc-pascal]

On 26-6-2023 15:54, Michael Van Canneyt via fpc-pascal wrote:


  v.Voice:=v.GetVoices().Item(1);

I have to change that to (0) to get it to work. Might depend on 
configuration?

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

[Marco van de Voort via fpc-pascal]

On 13-6-2023 15:38, Rafael Picanço via fpc-pascal wrote:

Thank you Marco, I am elaborating on top of your suggestions.

> The problem is that the logical solution, making it a macro, doesn't
work, as macro definitions don't export through USES clauses.

I think that pre-processor constants with $I would be a valid 
alternative for using the best solution. For example:


A matter of taste. I would have as less macros as possible. Moreover the 
typed const doesn't require including additional files at the usage 
site, so IMHO it is objectively a better solution

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

[Marco van de Voort via fpc-pascal]

On 13-6-2023 05:19, Rafael Picanço via fpc-pascal wrote:
(1) I have no idea on how to translate these god-casts, eg., 
((getExButtonStates)0), to free pascal. Right now, I think that even 
if I don't really need them, I just want to understand and learn 
in the process.


The problem is that the logical solution, making it a macro, doesn't 
work, as macro definitions don't export through USES clauses.


Defining it a proper constant would be the best solution, but FPC 
doesn't like it :


const

 EXTERNAL_DEV_NONE = TGetExButtonStatesFunction(pointer(0));

so the next best is turning it into a type constant at the expense of 
sizeof(pointer) bytes in the binary:


const

  EXTERNAL_DEV_NONE : TGetExButtonStatesFunction= pointer(0);

etc etc.



(2) So, the whole point here is binding the 
"enable_external_calibration_device" function. It expects a 
"getExButtonStates buttonStatesfcn". Can you check if my current 
binding is right?


A purist would say it needs to be "ansichar" rather than char (because 
in future unicode modes char could be 2-byte, for the rest it seems ok.


(3) I am using the ELCALLTYPE macro just because they were using them 
too, I am assuming backward compatibility. But I am not sure if I 
really need them. EyeLink code depends on custom SDL2 headers and I 
am running SDL2 Free Pascal related stuff just fine (and it has cdecl 
in everything). What do you think about that? For reference, this is 
the macro:


You must match the calling convention of the implementation. Some 
functions have target dependent calling conventions, some non native 
libraries force cdecl even on Windows. (where stdcall or fastcall is 
more conventional)


Note that an alternative for this macro exists since FPC 3.2.0:

https://wiki.freepascal.org/FPC_New_Features_3.2.0#Support_for_WinAPI_directive

Even though the naming is not "elegant" for crossplatform usage.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Marco van de Voort via fpc-pascal]

On 12-6-2023 08:15, Nikolay Nikolov via fpc-pascal wrote:

Shouldn't the recursive call assign the result?

nextt(num - 1); 



nextt:=nextt(num - 1);


if you don't use the result, the whole call may be optimized away?

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

Re: [fpc-pascal] Compile time -> processor benchmark values

[Marco van de Voort via fpc-pascal]

On 29-5-2023 16:24, Sven Barth via fpc-pascal wrote:


FPC itself is single threaded. So for that the single thread rating is 
more important. However Lazarus (and fpmake) can parallelize the 
building of packages if they don't depend on each other. On the other 
hand this is only really important when rebuilding and not when doing 
normal builds.


Each core above 4 is increasingly irrelevant.

I bought some machines recently, and did test some build times on 
Windows for FPC snapshot (clean,build,install, with as many options as I 
know):


i7-3770 desktop 142s

Ryzen 5800H laptop  103s

Ryzen 4800H laptop 118s

Ryzen 5700X desktop 89s

Note that some of the 5700X's speed comes from a nearly twice as fast 
clean (15s vs 28-33s)as the other machines. The only reason I can think 
of for that is that the machine has a retail SSD (Corsair MP510, decent, 
but nothing extreme), the other two Ryzens also have PCIe SSDs, but 
factory installed.


I tested some of the 8 core ryzens with settings to 6 cores, and the 
difference is a few seconds only.

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

Re: [fpc-pascal] Freeing memory with exceptions

[Marco van de Voort via fpc-pascal]

On 24-5-2023 13:00, Benito van der Zander via fpc-pascal wrote:


It is weird that your code calls setjmp? Are you using a non Windows 
platform?  Comparisons with Delphi should be done on Windows where 
the exception systems match. Apples to Apples please.


It is FPC on Linux.

And Delphi 4 on Linux (in WINE)


Then also run FPC/win32 in wine for a real comparison.

 Even if it wants to do the Linux nonsense, FPC could at least inline 
fpc_setjmp in fpc_pushexceptaddr to make it only one function call.


I regret installing Linux. Everything worked better with Windows 98 
and Delphi 4


These kinds of statements are counter-productive.


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

Re: [fpc-pascal] Freeing memory with exceptions

[Marco van de Voort via fpc-pascal]

On 23-5-2023 12:44, Benito van der Zander via fpc-pascal wrote:

Hi,


Depends on your code. 



I wrote all my code in Delphi 4. From 1998 or so. I do not make new 
projects, only maintain old ones.


Delphi 4 felt much better.

Like take:

procedure test;
var s: string;
begin
  s:= 'abc';
end;



It is weird that your code calls setjmp? Are you using a non Windows 
platform?  Comparisons with Delphi should be done on Windows where the 
exception systems match. Apples to Apples please.



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

Re: [fpc-pascal] Multiple enumerators per class

[Marco van de Voort via fpc-pascal]

Op 12/05/2023 om 14:16 schreef Hairy Pixels via fpc-pascal:

Is it possible to have multiple enumerators on one class?


Yes, see e.g. TDictionary that allows iterations over keys and values 
and both. There is only one default iterator, but you can have some 
property that has its own iterator.


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

[Marco van de Voort via fpc-pascal]

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



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

Re: [fpc-pascal] Fpc 3.2.2 fails to "make install" on RPi4 to local directory

[Marco van de Voort via fpc-pascal]

On 28-3-2023 13:43, Bo Berglund via fpc-pascal wrote:

make install prefix="$HOME" FPC="$HOME/dev/fpc/3.2.2/compiler/ppcarm"


It is install_prefix= not install prefix=  iow, insert a underscore

___
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

[Marco van de Voort via fpc-pascal]

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


Probably yes, but there might be an alternative, see below. But as far as
I understand, Unit is a Turbo Pascal concept, so any Pascal programming
dialect that predates it, probably don't understand it.


True, and before units in Turbo Pascal(*) and Modules in Extended 
Pascal, nothing was standardized about breaking up the source into 
multiple parts.


Most dialects either adopted some form of C "extern" like handling, and 
the more advanced ones some form of Modula2 derived modules, either 
directly, or via the lengthy Extended Pascal standardization process.


(*) Turbo Pascal was strictly not a standard, but influential enough to 
set one.


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

Re: [fpc-pascal] Why in {$mode delphi} it works and in {$mode objfpc} it doesn't?

[Marco van de Voort via fpc-pascal]

On 16-1-2023 20:56, Giuliano Colla via fpc-pascal wrote:


No chance. Addr is a pointer (of type Pin_addr)

but

Addr := Pin_addr(HostEnt.h_addr^)

works only if mode is Delphi. In objfpc it raises exactly the same error.

A little bit weird, isn't it?

It depends. It assumes .h_addr is compatible with pointer.  Since Free 
Pascal is more portable, that might be a platform dependent assumption.

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

Re: [fpc-pascal] GStreamer API unit added

[Marco van de Voort via fpc-pascal]

On 1-11-2022 11:45, Michael Van Canneyt via fpc-pascal wrote:


I'm not an expert in sound/video streams, so if someone can contribute a
more elaborate example, it would be most welcome :)


Did you use gir2pascal ?  Seems there are GIR files for it


https://gitlab.freedesktop.org/gstreamer/gstreamer-rs-sys/-/tree/master/gir-files

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

Re: [fpc-pascal] pthread_detach

[Marco van de Voort via fpc-pascal]

On 30-10-2022 13:05, Hairy Pixels via fpc-pascal wrote:



On Oct 30, 2022, at 6:55 PM, Marco van de Voort via fpc-pascal 
 wrote:

Yes. They call pthread_detach when ending, i.e. just before calling 
pthread_exit. So if you use normal threads, you already use that.

Similarly, pthread_join is a part of tthread.waitfor .  Have a look at 
rtl/unix/cthreads.pp for how the RTL threads map to pthreads on *nix systems.

Ok I see that now in cthreads.pp. Do you need to call EndThread from the thread 
callback when calling BeginThread? I thought the thread cleaned itself up when 
the function terminated but I may be wrong about that.


I'm not that deep into those procedural threading. From what I remember 
the prototypes are defined, but not their use.


But since tthread works on top of that, you can simply trace how tthread 
does it, which is probably more solid and up to date than documentation 
and two decade old tutorials.


Most notably how tthread.freeonterminate is implemented. Some OSes like 
Windows (that tthread is modeled after) keep some thread resources 
around to read the result back after the thread is finished.



  Pthreads at least doesn’t appear to require you to detach the thread but 
maybe it’s leaking memory then.


The manual you quoted seemed to indicate you either have to call _join 
or _detach.


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

Re: [fpc-pascal] pthread_detach

[Marco van de Voort via fpc-pascal]

On 30-10-2022 12:28, Hairy Pixels via fpc-pascal wrote:

The POSIX thread library has a function called pthread_detach 
(https://man7.org/linux/man-pages/man3/pthread_detach.3.html). Do the RTL 
threads have anything comparable?


Yes. They call pthread_detach when ending, i.e. just before calling 
pthread_exit. So if you use normal threads, you already use that.


Similarly, pthread_join is a part of tthread.waitfor .  Have a look at 
rtl/unix/cthreads.pp for how the RTL threads map to pthreads on *nix 
systems.



Honestly I don’t really understand why this is even needed because the threads 
seem to clean themselves up when they exit anyways but since it exists in 
pthreads I thought I was ask.


Maybe there are other uses of pthread_detach that don't immediately call 
_exit.  I'm not pthreads expert, so I can't help there.


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

Re: [fpc-pascal] Variants with classes and records

[Marco van de Voort via fpc-pascal]

On 6-10-2022 14:16, Sven Barth via fpc-pascal wrote:


And that crashed also. I thought it would be ok to just hold the
reference but not claim ownership over it.


Variants count as managed types and they can contain interface 
references and strings. If you use a custom type you can do as you 
please, but the internal types that can be assigned to a Variant *are* 
managed accordingly (if the types themselves are managed).


(IIRC in case of native types there is another pointer in the variant 
which is an interface for something that manages the record.  But it has 
been a while)

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

Re: [fpc-pascal] Enum property can't be published

[Marco van de Voort via fpc-pascal]

On 27-9-2022 11:14, Hairy Pixels via fpc-pascal wrote:

I just tried to build a lazarus project using 3.3.1/ppca64 and I’m getting an 
error that an enum can’t be published. This was working on 3.2.2/ppcx64 so what 
changed?

===

lazbuild ./pasls.lpi --widgetset=cocoa 
--compiler=/usr/local/lib/fpc/3.3.1/ppca64 --cpu=aarch64
Free Pascal Compiler version 3.3.1 [2022/09/15] for aarch64
Copyright (c) 1993-2022 by Florian Klaempfl and others
(1002) Target OS: Darwin for AArch64


===

   TDiagnosticSeverity = ( Error = 1,
   Warning = 2,
   Information = 3,
   Hint = 4
   );


   TDiagnostic = class (TCollectionItem)
   private
 fSeverity: TDiagnosticSeverity;
   published
 property severity: TDiagnosticSeverity read fSeverity write fSeverity;  // 
 error: (3134) This kind of property cannot be published


3.2.2 compiles without warnings,  3.3.1 (i386-win32 from 17 sept:)

ptt.pp(14,44) Warning: This property will not be published

Possibly enums with assigned values (which can have gaps) are not safe 
to publish, and this was only now noted?


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

Re: [fpc-pascal] mciSendString with long file names

[Marco van de Voort via fpc-pascal]

On 22-9-2022 21:26, Travis Siegel via fpc-pascal wrote:
That's on windows, you said the program was running on linux. 


Afaik he said he was on Windows, but his files are on a Linux server:



James richter Wrote:

I just figured out that short filenames won't work, my files are on a linux
server... not NTFS drives


Probably it is something of either escaped spaces or ", but not both? Or 
simply a broken file system driver and an api that isn't very hardened 
against FS problems.

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

Re: [fpc-pascal] BoolToStr

[Marco van de Voort via fpc-pascal]

Op 8/28/2022 om 8:45 PM schreef Ralf Quint via fpc-pascal:

On 8/28/2022 8:23 AM, James Richters via fpc-pascal wrote:

Running "i:\booltostr.exe "

-1

0

Why true is -1 instead of 1 is beyond me, but anyway, I would 
consider this BoolToInt, not BoolToStr,I want the Strings ‘TRUE’ or 
‘FALSE’ as indicated in the documentation


Very logical in fact. 0 is NO bit set in any given size of boolean 
data type, -1 means ALL bits set on that same size boolean data type.


Pascal boolean datatypes only have 0 or 1 as defined values.  But 
probably it is for some COM or Winapi compatible purpose.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Class or Record Helper for Interface?

[Marco van de Voort via fpc-pascal]

Op 8/27/2022 om 3:06 PM schreef Anthony Walter via fpc-pascal:
Ah, it seems the problem is even in {$mode delphi} you must use 
{$modeswitch typehelpers} to define a type helper for an interface.


I put a note on the checklist for the next major version about this to 
review this. (only review, not a guarantee that it will change. But at 
least it won't go through unnoticed then)


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

Re: [fpc-pascal] I am offering a $100 reward for linking static libraries

[Marco van de Voort via fpc-pascal]

On 22-8-2022 15:01, Anthony Walter via fpc-pascal wrote:
I never thought about the linker changes to FPC and am probably using 
the internal one. I know in the past I had been able to compile / link 
libraries created with MinGW GCC on Windows. Parts of the problem also 
include determining which other static dependencies to link IN 
ADDITION to the order of the linking. Yes, the order makes a big 
difference. Unfortunately, many years ago (around 10) I lost or 
overwrote the bits of code I was using for static linking on Windows 
(using the correct linklib commands).


I will try to recreate it again, using your suggestion of falling back 
to the external linker. If it works I'll send you a part of the 
reward. That offer also stands for anyone else that can offer helpful 
advice.


Do the "inp" symbols go away if you put the kernel32 dependency first ?

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

Re: [fpc-pascal] Here is real time graphics and physics simulation, library

[Marco van de Voort via fpc-pascal]

On 1-8-2022 11:12, Michael Van Canneyt via fpc-pascal wrote:


Hence my proposal to refactor it in sysutils, so at least the 
exception handling

can be kept common to all units.


His main objection seems to be the IFDEFING, which is hard to avoid in a 
20 targets + compiler.


Also, the browsability is doable with lazarus (which processes %MAINUNIT 
etc for navigation), and the OP doesn't explain what he used where 
source navigation failed.

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

Re: [fpc-pascal] UBER H3 API working/partially converted

[Marco van de Voort via fpc-pascal]

On 31-7-2022 15:55, Skybuck Flying via fpc-pascal wrote:
(I mainly write this second e-mail to prevent you from wasting time on 
the previous e-mail, cause the conversion was already quite 
successfull with a different tool, read below)



IIRC h2pas doesn't like calling convention modifiers, nor extern C {} 
blocks, and some postediting to simplify them can help get it through.

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

Re: [fpc-pascal] Feature Announcement: Function References and Anonymous Functions

[Marco van de Voort via fpc-pascal]

On 27-5-2022 14:12, Sven Barth via fpc-pascal wrote:

You couldn't have written a test that's independent of TThread? 梁
When I saw no reactions on core this morning, I dumped everything I had 
to the respective issue trackers. I'm not sure if I can get all of this 
reproduced on my private laptop when I'm away this weekend.


If it is about the overload case: well, you said it would be easy 
because objfpc already did it right :-)


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

Re: [fpc-pascal] Feature Announcement: Function References and Anonymous Functions

[Marco van de Voort via fpc-pascal]

On 27-5-2022 00:46, Mattias Gaertner via fpc-pascal wrote:



As these two features are rather complicated there might still be a
huge bundle of bugs lurking around so I ask you to test them to year
heart's content and report found bugs

First!


Ditto! https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39774

This ticket also contains an experimental patch for anonymous method 
queue and synchronize. (required to reproduce)

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

Re: [fpc-pascal] alloca

[Marco van de Voort via fpc-pascal]

On 14-5-2022 17:51, Jonas Maebe via fpc-pascal wrote:

On 14/05/2022 17:31, Marco van de Voort via fpc-pascal wrote:
Also when an exception happens, the stack pointer is not as expected 
in exception frames (don't know if that really is an issue, but I can 
image).  It would be interesting how C handles this (e.g. exceptions 
while alloca called in a loop?)


This is handled via dwarf call frame information, which is also 
generated by the compiler. It describes how to restore the stack 
pointer for every instruction address where it changes.


I was thinking about SEH, but same principle. But that is exactly what I 
expected, so if you manually mutate the stack pointer using assembler, 
it won't register in the unwind info frames.

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

Re: [fpc-pascal] alloca

[Marco van de Voort via fpc-pascal]

On 14-5-2022 10:49, Hairy Pixels via fpc-pascal wrote:

Apparently what it does is advance the stack pointer x bytes and return a 
pointer to the new location so you could probably do that with some assembly. 
Of course this is dangerous because you can request more memory than exists in 
the current frame.


But optimizations sometimes eliminate the frame pointer and use the 
stackpointer directly to index e.g. local vars and params. Also when an 
exception happens, the stack pointer is not as expected in exception 
frames (don't know if that really is an issue, but I can image).  It 
would be interesting how C handles this (e.g. exceptions while alloca 
called in a loop?)


So the only non hacky way is to implement support in the compiler I think.


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

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

[Marco van de Voort via fpc-pascal]

On 25-4-2022 11:11, Sven Barth via fpc-pascal wrote:
Then you don't think creative enough. Think about (de)serialization 
code for binary data which needs to use the correct size. If done 
correctly this can very well be handled with a generic.


Actually that's what I immediate thought of too, but nearly all also 
have string as type. Can this be solved by having a specific overloaded 
version for string ?


I'm thinking of things like TStream helpers in streamex.

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

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

[Marco van de Voort via fpc-pascal]

Op 24/04/2022 om 04:37 schreef Hairy Pixels via fpc-pascal:

On Apr 23, 2022, at 10:30 PM, Marco van de Voort via fpc-pascal 
 wrote:

Btw since you are afaik an Apple user, did you actually use conformant arrays, 
or do you base this on UCSD/Borland dialects only?

I started with THINK Pascal on classic Mac OS but I never heard of conformant 
arrays. What are they?


It's a ISO pascal feature that is a kind of open array construct where 
you can pass non zero based arrays too. The limitation that dynamic/open 
arrays are always zero based is a Delphi simplification.


It is more or less meant that if to judge the non zero array bounderies 
features, you need to know the whole story.


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

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

[Marco van de Voort via fpc-pascal]

On 23-4-2022 16:09, Hairy Pixels via fpc-pascal wrote:

For 2) I'm also of the opinion of the others: this is unneeded syntactic sugar. 
There is already a way to declare arrays with a specific size and for a 
language it's in nearly all cases not good to provide multiple ways to achieve 
the same.

Getting off topic but personally I think the idea of a range bound for arrays 
has been proven to be a bad idea from the original Pascal spec. Originally when 
learning pascal I think I did 1 indexed arrays but eventually realized it’s 
non-standard across other languages and doesn’t really provide any use. In 
99.99% of cases I always do 0…n so it’s just wasting time at this point. In 
fact I would be really hard pressed to think of a time I did something besides 
0…n…


0..n-1  I might hope.

Btw since you are afaik an Apple user, did you actually use conformant 
arrays, or do you base this on UCSD/Borland dialects only?



As I've written elsewhere: implicit function specializations as a feature might 
not have happened if Delphi did not support them as well, cause like 2) they 
are essentially syntactic sugar as well.

The two languages I use commonly these days are Swift and C#, both of which do 
implicit function specialization by default. After you use a generic function a 
couple times it becomes apparent the compiler could infer the types and it’s 
less code to write so it’s natural that any language that has generic functions 
would support this feature.


IMHO It is like with all shorthands, if an addition causes pitfalls, 
debugging those is usually worse then they ever save.


I've no idea about how that is with this feature (and then most notably 
the integration in the Pascal language, since pitfalls are often due to 
combinations of features)


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

Re: [fpc-pascal] Just out of curiosity: Compiling FPC trunk and fpcmake

[Marco van de Voort via fpc-pascal]

On 21-3-2022 22:45, Karoly Balogh via fpc-pascal wrote:

Hi,
I can reproduce this, or something very similar for the clean/distclean
targets, if I have no FPC installed on my machine, but I specify PP= as a
Makefile argument to a "bootstrap" compiler binary, and I use OS_TARGET=
as well, for crosscompiling.


Try the same, but use FPC= instead of PP= . Let it point to the ppc binary.


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

Re: [fpc-pascal] Just out of curiosity: Compiling FPC trunk and fpcmake

[Marco van de Voort via fpc-pascal]

On 21-3-2022 22:17, Victor Campillo via fpc-pascal wrote:



make: -iVSPTPSOTO: Command not found
Makefile:235: *** The Makefile doesn't support target -, please run 
fpcmake first.  Stop.


Binary "fpc" not found. Maybe a different account or something else 
changed in your $PATH ?



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

Re: [fpc-pascal] Case statement for class introspection

[Marco van de Voort via fpc-pascal]

On 16-1-2022 14:18, Ryan Joseph via fpc-pascal wrote:

I had some fun today on my day off and managed to actually implement this based 
on the if-statement based string case labels. Is the compiler team interested 
in this feature? I think it's a clearly useful addition to OOP and an 
appropriate new use of the case statement.

https://gitlab.com/genericptr/free-pascal/-/commits/case_label_classref

Here's an example of what I did. To keep it simple you use "ClassType" to 
branch off of possible class types.



   o := TInterfacedObject.Create;

   case o.ClassType of
 TObject: writeln('TObject');
 TInterfacedObject: writeln('TInterfacedObject');
 TAggregatedObject: writeln('TAggregatedObject');
 otherwise
   writeln('OTHER: ',o.ClassName);
   end;


What does it print in this case? I mean tobject matches, and 
tinterfacedobject too.


The most logic solution would be to only run the most specialized case?

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

Re: [fpc-pascal] Building fpc 3.2.2 from sources - which compiler to use for install?

[Marco van de Voort via fpc-pascal]

Op 6-12-2021 om 12:53 schreef Bo Berglund via fpc-pascal:
  


I.e. should I use the newly compiled 3.2.2 in this step or the seed compiler,
which is the previous version?



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

Re: [fpc-pascal] How to list IP and MAC of network adapters on Windows?

[Marco van de Voort via fpc-pascal]

Op 10-9-2021 om 09:46 schreef Sven Barth via fpc-pascal:
You can use the ipconfig command and parse its output (especially 
ipconfig /all).


Afaik netsh has more info.

I have several tests  for this in Delphi, but they use the iphlp headers 
that FPC doesn't have yet (a point on my todo list).


I was mainly looking for the core (IP + Mac) and jumbo frame status.

Some info can also be found in the wmi and registry, I attach the wmi 
related units.



unit lstwmi;

interface

{$ifdef fpc}
{$mode delphi}
{$endif}
// example from MSDN Win32_NetworkAdapterConfiguration class.
// 
https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-networkadapterconfiguration
uses windows,variants,classes,sysutils,activex,comobj,wmiutil;

procedure  PrintAll_NICAdapter_information(lines:tstrings);
implementation

Function GetMultiString_FromArray( ArrayString:OleVariant; 
separator:string):string;
begin
If varisnull ( ArrayString ) Then
result:= ''
else
result := OleVariantToText(arraystring); // arraystring.items[0]; // 
Join( ArrayString, Seprator )
end;


procedure  PrintAll_NICAdapter_information(lines:tstrings);

procedure addifnonzero(const lab : string;vv:widestring);
//r value : string;
begin
//  value:=vartostr(vv);
  if trim(vv)<>'' then
lines.Add(lab+vv);
end;

var
  objWMIService: OLEVariant;
  colItems : OLEVariant;
  colItem  :  OLEVariant;
  strComputer  : Widestring;
  oEnum: oEnumIterator;
  i : Integer;
  strDefaultIPGateway,
  strDefaultIPSubnet ,
  strIPAddress,
  strIPSecPermitUDPPorts,
  strDNSDomainSuffixSearchOrder,
  strIPSecPermitTCPPorts ,
  strIPSecPermitIPProtocols,
  strIPXFrameType,
  strGatewayCostMetric,
  strIPXNetworkNumber,
  strDNSServerSearchOrder,
  strIPSubnet: string;

  v : olevariant;


Begin
strComputer := '.';
objWMIService := 
GetWMIObject('winmgmts:{impersonationLevel=impersonate}!\\'+strComputer+'\root\cimv2');
colItems  := objWMIService.ExecQuery('Select * from 
Win32_NetworkAdapterConfiguration');  // 48 = wbemFlagReturnImmediately   and 
wbemFlagForwardOnly

lines.add('ok');


//v:=GetWMIObject('Win32_NetworkAdapterConfiguration');
//v.SetPMTUDiscovery(winbool(1));

// vbscript FOR works with _NewEnum operator. FPC/Delphi is slightly more 
complicated, but we can stuff that in an iterator record so we can use FOR..IN
i:=0;
for colItem in oEnum.Enumerate(colItems) do
  begin
i := i + 1;


lines.add('---');

lines.add('Win32_NetworkAdapterConfiguration instance: '+inttostr(i));

lines.add('---');

strDefaultIPGateway := 
GetMultiString_FromArray(ColItem.DefaultIPGateway,', ');

addifnonzero('MACAddress  : 
'#9,vartostr(ColItem.MACAddress));
addifnonzero('Description : 
'#9,vartostr(ColItem.Description));
addifnonzero('DHCPEnabled : 
'#9,vartostr(ColItem.DHCPEnabled));

strIPAddress:=GetMultiString_FromArray(ColItem.IPAddress,', ');

addifnonzero('IPAddress   : '#9,strIPAddress);

strIPSubnet:= GetMultiString_FromArray(ColItem.IPSubnet,', ');

addifnonzero('IPSubnet: '#9,strIPSubnet);
addifnonzero('IPConnectionMetric  : 
'#9,vartostr(ColItem.IPConnectionMetric));
addifnonzero('DHCPLeaseExpires: 
'#9,vartostr(ColItem.DHCPLeaseExpires));
addifnonzero('DHCPLeaseObtained   : 
'#9,vartostr(ColItem.DHCPLeaseObtained));
addifnonzero('DHCPServer  : 
'#9,vartostr(ColItem.DHCPServer));
addifnonzero('DNSDomain   : 
'#9,vartostr(ColItem.DNSDomain));
addifnonzero('IPEnabled   : 
'#9,vartostr(ColItem.IPEnabled));
addifnonzero('DefaultIPGateway: '#9,strDefaultIPGateway);
strGatewayCostMetric := 
GetMultiString_FromArray(ColItem.GatewayCostMetric,', ');
addifnonzero('GatewayCostMetric   : '#9,strGatewayCostMetric);
addifnonzero('IPFilterSecurityEnabled : 
'#9,vartostr(ColItem.IPFilterSecurityEnabled));
addifnonzero('IPPortSecurityEnabled   : 
'#9,vartostr(ColItem.IPPortSecurityEnabled));

strDNSDomainSuffixSearchOrder := 
GetMultiString_FromArray(ColItem.DNSDomainSuffixSearchOrder,', ');

addifnonzero('DNSDomainSuffixSearchOrder  : 
'#9,strDNSDomainSuffixSearchOrder);
addifnonzero('DNSEnabledForWINSResolution : 
'#9,vartostr(ColItem.DNSEnabledForWINSResolution));
addifnonzero('DNSHostName : 
'#9,vartostr(ColItem.DNSHostName));

strDNSServerSearchOrder := 
GetMultiString_FromArray(ColItem.DNSServerSearchOrder,', ');

addifnonzero('DNSServerSearchOrder: 
'#9,strDNSServerSearchOrder);
addifnonzero('DomainDNSRegistrationEnabled: 

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Marco van de Voort via fpc-pascal]

Op 2021-08-12 om 08:12 schreef Christo Crause via fpc-pascal:


This example downloads about 46 MiB of data, which expands to around 
309 MiB on disk, of which 50 MiB is git information.


 Note that a full clone is about 500MB. Still, it is a nice to have for 
e.g. machines that only do release packaging, and the only operation 
done on the VCS is updating and exporting.


There are many problems with GIT, but size is not one of them.

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

Re: [fpc-pascal] TProcess read buffer size

[Marco van de Voort via fpc-pascal]

Op 2021-07-15 om 20:26 schreef Ryan Joseph via fpc-pascal:

I have some code the basically does:

while bytesRead > 0 do
bytesRead := process.Output.Read(buffer^, kBufferSize);

but bytesRead is only ever 512 per call to Read.

Is this a system imposed limit or something that's part of TProcess? Setting 
kBufferSize to anything larger than 512 has no affect.
Not of TProcess as far as I know, it probably depends on the OS pipe 
implementation and maybe the granularity that the processes that you run 
outputs data.  (buffers its I/O iow calls write()  in 512 byte increments )

___
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

[Marco van de Voort via fpc-pascal]

Op 2021-07-06 om 22:37 schreef Jean Pierre CASSOU via fpc-pascal:


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



Missing install.sh

Install is a script to install _binary_ releases, and is part of the 
fpcbuild repo, listed above.



___
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

[Marco van de Voort via fpc-pascal]

Op 2021-06-16 om 23:49 schreef Jean SUZINEAU via fpc-pascal:

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


The fact that you use "result" for function result indicates that you 
use a object pascal mode,  and not the default. If you don't do that 
(compile in the default mode , fpc), I get


35,328 uptime.exe

with FPC 3.2.2
___
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

[Marco van de Voort via fpc-pascal]

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

Since the final binary size after using strip -s on the exe file is
271 kb it seems a bit big!
Or is there a lot behind the scenes I have missed?

Classes is a hog.


I had a look, and only tthreadlist (and with that tlist) were 
instantiated in the startupcode.


No other (RTTI) classes seem to be registered or otherwise referenced in 
the startup code, so then they could be smartlinked out?


Maybe some table does not contain weak references?

___
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

[Marco van de Voort via fpc-pascal]

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.



___
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

[Marco van de Voort via fpc-pascal]

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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] -FNsystem

[Marco van de Voort via fpc-pascal]

Op 2021-05-27 om 13:31 schreef Mattias Gaertner via fpc-pascal:

There are some dotted units in fpc, e.g. system.uitypes.
So it would be nice to have -FNsystem in the default fpc.cfg (Delphi
compatible).

What do you think?


In principle yes, but keep in mind that then probably first uitypes must 
be deleted from lazarus, so that there are no longer two units that 
match "uitypes".  That can happen in lazarus branches that don't have to 
support 3.0.4. (which doesn't have -FN)


On Windows I would also add "winapi", just to allow renaming at some 
point in the future. Same for "Data" (prefix of fcl-db generic units 
like db/dbcommon etc).


Other common ones are web , soap and xml, but afaik those are not 
compatible?


VCL units are prefixed with VCL (namespaces: 
Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell), so that will be a 
problem (stick to compatible VCL, or use LCL?)




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

[fpc-pascal] FPC 3.2.2 released

[Marco van de Voort via fpc-pascal]

Hello,

Finally, the Free Pascal 3.2.2 release is available from our servers and 
from sourceforge.


Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.2

For an overview of what is new see the summary below

The website has been updated for the major targets and work is still 
being done for the rest.


All downloads are available at the main FTP server and sourceforge.

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

ftp://ftp.freepascal.org/pub/fpc/dist/3.2.2/

Enjoy!

The Free Pascal Compiler Team



    Free Pascal Compiler

    Version 3.2.2

**

Free Pascal 3.2.2 is a minor release of the 3.2.x fixes branch. As such, it
contains mostly fixes of bugs discovered in the previous version, plus some
updates for included packages. In this case a new target was also backported
from trunk.

Please also see https://wiki.freepascal.org/User_Changes_3.2.2 for a list
of changes that may affect the behaviour of previously working code, and
how to cope with these changes.

The main highlights of this version:

Platforms:
  * New platform: aarch64-darwin
  * A new 32/64-bit combined installer for Windows.

Utilities:
  * fpcres provides support for compiling resources from *.rc files

Packages:
  * fcl-db extended with support for MySQL 8.0
  * fcl-passrc updates
  * pas2js updates
  * fpdoc updates
  * fcl-base includes new support for logging to StdOut and StdErr
  * rtl-extra includes improvements for Sockets

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

Re: [fpc-pascal] How to find where my app consumes CPU?

[Marco van de Voort via fpc-pascal]

Op 2021-05-18 om 23:29 schreef Travis Siegel via fpc-pascal:
I'm not positive, but I'm pretty sure the sleep command in linux does 
not behave the same way it does in windows.


As you know, in windows, a sleep command (even if delivered with a 
parameter of 0) gives up time slices to other programs on the system.  
This does not appear to be the case on linux.


On linux, the sleep command simply suspends the process for the 
specified amount of time, but so far as I can tell, does nothing for 
unused cpu cycles.


This is what "suspend" means, that process doesn't compete for cycles, 
so they go to the other processes. Since the sleep is a kernel call, I 
can't really imagine why this would not be the case.


So my guess something else is spinning (e.g. in a thread).


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

Re: [fpc-pascal] 50 years of Pascal, by the the author himself

[Marco van de Voort via fpc-pascal]

Op 2021-05-13 om 01:51 schreef Brian via fpc-pascal:


There are still some OpenVMS sites out there, which would lead you to 
assume that VAX Pascal is still alive and kicking, albeit very much a 
minority compiler.



For historic pascal compilers, have a look at this list:

https://www.pascaland.org/pascall.htm

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

Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal

[Marco van de Voort via fpc-pascal]

Op 2021-04-19 om 07:52 schreef Karoly Balogh via fpc-pascal:

No, the RTL and the compiler are tightly coupled.

What might be possible are further packages like the FCL and
interfaceing units, but the core RTL itself definitely not.

I think the need comes from the fact that the release cycle for the
compiler is horribly long, which I tend to agree with. But I think this
comes from the fact that the release for Tier 1 platforms is still mostly
prepared manually.


Doc upload also is a bottleneck.

It is not the work to those tiers that keeps up, but unforeseen things 
happening while doing that, because nobody tests them inbetween 
releases, and things pop up last minute.


If you have automated systems, but nobody pays attention to them till 
just before release time, you get the same problem.


That doesn't mean I'm against automation. The problem is just more than 
that, which is why I hope to moving to a bi-annual release scheme would 
be best.  It would reduce the need for this or that fix to get in last 
minute, and somewhat grease the wheels of releasing.


Major releases can be a pain, minor releases should be reasonably 
effortless.


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

Re: [fpc-pascal] Version 3.2.2 changes

[Marco van de Voort via fpc-pascal]

Op 2021-04-11 om 15:21 schreef Marco van de Voort via fpc-pascal:


Op 2021-04-09 om 10:42 schreef Florian Klämpfl via fpc-pascal:

 but the "fix version" of most bug reports does not get updated when

fixes are backported. I used to spend days on going through all merges
and updating the merge revisions and fix versions when a release was
nearing, but I no longer have time for that.
As this is most likely pretty useful, I am willing to work on it. 
Anybody else?


Start rev on fixes branch to look at is r45254, the  revision that 
3.2.0 branched off, all revs in fixes_3_2 before are guaranteed in 3.2.0


The revisions post merged into 3.2.0 should be subtracted from that set.


I did a few till "r46616 | michael | 2020-08-23"


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

Re: [fpc-pascal] Version 3.2.2 changes

[Marco van de Voort via fpc-pascal]

Op 2021-04-09 om 10:42 schreef Florian Klämpfl via fpc-pascal:

 but the "fix version" of most bug reports does not get updated when

fixes are backported. I used to spend days on going through all merges
and updating the merge revisions and fix versions when a release was
nearing, but I no longer have time for that.

As this is most likely pretty useful, I am willing to work on it. Anybody else?


Start rev on fixes branch to look at is r45254, the  revision that 3.2.0 
branched off, all revs in fixes_3_2 before are guaranteed in 3.2.0


The revisions post merged into 3.2.0 should be subtracted from that set.

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

Re: [fpc-pascal] Minimal size of compiled library (DLL under Windows)

[Marco van de Voort via fpc-pascal]

Op 2021-04-03 om 13:22 schreef LacaK via fpc-pascal:


I am guessing, that there must be something in initialization sections 
of units (SysUtils and Classes), which cause that some code is 
included, right?
Can I somehow to avoid this grow of size (for example I need from 
Classes only TFPList)?


Not in an easy way at the moment, I don't expect it to change anytime soon.

The problem is probably the streaming system that the compiler can't 
easily determine if it is used runtime. This also has resourcestrings as 
errors, uses typeinfo etc etc.  I also see interface related support 
probably because tcomponent also implements interfaces.




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

Re: [fpc-pascal] Hide warning number

[Marco van de Voort via fpc-pascal]

Op 2021-03-25 om 16:28 schreef Ryan Joseph via fpc-pascal:

Is there a way to hide a warning for all files from the command line? The "not 
inlined" warnings (6058) are too numerous to even be useful anymore so I'd like to 
disable it.


from FPC -h:


 -v  Be verbose.  is a combination of the following letters:

 m, : Do not show messages numbered  and 


So  -vm6058 would go a long way


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

Re: [fpc-pascal] Pass type as function parameter

[Marco van de Voort via fpc-pascal]

Op 2021-03-24 om 11:05 schreef Michael Van Canneyt via fpc-pascal:


Would it be possible in FPC to pass a type of a variable as a 
parameter to

a function?

e.g.
 MyFunction(integer);

I have legacy C code that does this via a macro. Hopefully, it can be 
done

so I do not need to change the existing code too badly.


This is not possible as such.

What you can do is use generics

MyFunction

or use typeinfo:

MyFunction(TypeInfo(Integer));

Which of the 2 you need to use depends on the code of course.

Or variants. Or in an emergency: start using/creating an external 
preprocessor.


___
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

[Marco van de Voort via fpc-pascal]

Op 2021-03-07 om 22:26 schreef Bart via fpc-pascal:

On Sun, Mar 7, 2021 at 5:31 PM Marco van de Voort via fpc-pascal
 wrote:


Probably it is not in the BMP and thus needs more position than one.

Length(Char) is 5 according to fpc, I see 5 "graphemes"


Indeed:

.Ld1$strlab:
    .short    1200,2
    .long    -1,5
.Ld1:
    .short    8984,8997,9003,8679,94,0

On win32 a quick test is hard since displaying unicode in the terminal 
is hard.



But a write for "widechar" is called:

   movl    U_$P$PROGRAM_$$_CHARS,%eax
    movw    (%eax),%cx
    movl    %ebx,%edx
    movl    $0,%eax
    call    fpc_write_text_widechar

so it should be ok then.

___
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

[Marco van de Voort via fpc-pascal]

Op 2021-03-07 om 17:38 schreef Ryan Joseph via fpc-pascal:



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

Probably it is not in the BMP and thus needs more position than one.

Isn't char[1] a 2 byte wide char? Not sure I understand "more position than on" 
though.


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


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

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


___
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

[Marco van de Voort via fpc-pascal]

Op 2021-03-07 om 17:21 schreef Ryan Joseph via fpc-pascal:

I came across a bug which was caused but a unicode character losing information 
and narrowed it down to this. Why doesn't the chars[1] print the same character 
as appeared in the string?

var
   chars: UnicodeString;
begin
   chars := '⌘⌥⌫⇧^';
   writeln(chars);
   writeln(chars[1]);
end.

Prints:

⌘⌥⌫⇧^
?


Probably it is not in the BMP and thus needs more position than one.

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

Re: [fpc-pascal] Strange output from make when building 3.2.0

[Marco van de Voort via fpc-pascal]

Op 2021-02-25 om 10:12 schreef Bo Berglund via fpc-pascal:

I am installing fpc 3.2.0 on a notebook running Ubuntu 20.04 LTS
When I execute make clean and make sourceinstall I get this strange output
message:

  :~/dev/fpc/3.2.0$ time make sourceinstall PREFIX=$HOME
  make: -iVSPTPSOTO: Command not found


Missing FPC install.  It can't find a "fpc" binary



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

Re: [fpc-pascal] Traits Proposal

[Marco van de Voort via fpc-pascal]

Op 2021-02-19 om 16:50 schr

So the method resolution doesn't actually change the VMT table of the class, 
just the interface?


See it like this: An interface is a fragment of VMT. All methods of the 
interface are there in order.


If implemented right, it is like a pointer into the implementing 
classes' VMT table.


The IVT is a mapping of interface identifiers (in COM terms, GUIDS) 
mapped to the offset into the VMT they apply too.




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

Re: [fpc-pascal] Traits Proposal

[Marco van de Voort via fpc-pascal]

Op 2021-02-17 om 00:02 schreef Benito van der Zander via fpc-pascal:


And there often is a lot of unintentional deep copying. This is also 
why a property returning a record is fairly useless except for 
extremely small records like TPoint (and even that is not optimal no 


But a managed record to replace an interface, would only contain a 
single pointer/class ref. That can be copied fast


(1) A record is not a pointer. So that would require some implicit 
referencing in the property


(2) If it was managed, it would be an allocation, so I don't understand 
this.



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

Re: [fpc-pascal] Traits Proposal

[Marco van de Voort via fpc-pascal]

Op 2021-02-16 om 21:33 schreef Ryan Joseph via fpc-pascal:



On Feb 16, 2021, at 1:27 PM, Marco van de Voort via fpc-pascal 
 wrote:

And there often is a lot of unintentional deep copying. This is also why a 
property returning a record is fairly useless except for extremely small 
records like TPoint (and even that is not optimal no

deep copying? You mean from ref counted types like "array of" and ansistring?


No, use of TP objects and records in e.g. properties in not carefully 
crafted code. They are a lot less userfriendly.



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

Re: [fpc-pascal] Traits Proposal

[Marco van de Voort via fpc-pascal]

Op 2021-02-16 om 19:21 schreef Ryan Joseph via fpc-pascal:

Interfaces are extremely slow. Virtual method calls are also slow. I have been 
using interfaces for reference counting, and have been thinking to replace it 
all with managed records because they are so slow (unfortunately records can 
also be slow because fpc does not always keep them in registers even if they 
are pointer sized)


And there often is a lot of unintentional deep copying. This is also why 
a property returning a record is fairly useless except for extremely 
small records like TPoint (and even that is not optimal no



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

Re: [fpc-pascal] Traits Proposal

[Marco van de Voort via fpc-pascal]

Op 2021-02-15 om 18:08 schreef Ryan Joseph via fpc-pascal:



As I understand, this is not a method hiding, but just to tell the
compiler which method to implement the interface—the interface could
have method names which are very very common to use and this syntax
allows us to "rename" those methods without changing the original
names that the class might have.

yeah you may be right, that the interface object itself won't be hookup 
correctly if this doesn't happen. Seems strange you have 2 declarations for the 
same method though.

   procedure IMyIntf.Test2 = MyTest2;
   propcedure MyTest2;


instead of something like:
   
   propcedure MyTest2 override  IMyIntf.Test2;

The first syntax allows to for methods to be declared in the ancestor too.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Marco van de Voort via fpc-pascal]

Op 2021-02-14 om 17:16 schreef Michael Van Canneyt via fpc-pascal:


except it doesn't require an interface. The thing we seem to want 
here is a default property which works on records/objects so maybe we 
can just focus on that? The interface has so much boiler plate and I 
don't really see what we're getting in return.


I didn't propose using an interface; For me the

property Test: TTestImpl read fTest implements TTestIimpl;

Where TTestImpl is an object (tp style) or advanced record (delphi 
style) is ample.



You mean in both cases this will lead to a deep copy ? :-)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Marco van de Voort via fpc-pascal]

Op 2021-02-14 om 13:30 schreef Michael Van Canneyt via fpc-pascal:
I think the "performance implications" is more referring to memory 
management.


Interfaces means an extra object per interface, so more objects on the 
heap with all the extra memory management that implies.


(not interfaces do, as they are just a contract, but delegation of 
interfaces does)



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

Re: [fpc-pascal] Windows Defender considers fp.exe a malicious program

[Marco van de Voort via fpc-pascal]

Op 2021-02-12 om 22:48 schreef James Richters via fpc-pascal:

The problem I have had is when programs I compile generate a false virus 
detection.. sure on my own computer I can just disable that directory from the 
virus scanner but it becomes a problem when I release it to my customers and 
their virus scanners quarantine it.   I have no idea how to register a 
legitimate program as not having a virus.  I've had this issue before but 
managed to track down the section of code that caused it... after a completely 
exhaustive search.


Some tips:

 - don't use debug builds.

 - sign the binary, even if just selfsigned. Provide as much context to 
the OS (icon and the rest in that screen). Minimalistic binaries seem to 
be more suspect.


- use a well known installer package, and insist on using installers. 
Copied exes are also more suspect.


- unfortunately, some wellknown Delphi libraries like Indy and Zeos 
sometimes trigger also.


There is no real failsafe solution. It is all hedging and hoping.

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

Re: [fpc-pascal] Question about System.Move()

[Marco van de Voort via fpc-pascal]

Op 2021-01-11 om 15:26 schreef Benito van der Zander via fpc-pascal:

Hi,

perhaps a  safe, generic function for this copying could be added to 
the RTL. Like:


Procedure ManagedMove(const source: T;var dest: T;count: SizeInt);


a) For non-managed types it would be the same as Move(source, dest, 
count*sizeof(T))


Then you want to simply use ismanagedtype and move().  Moving the move() 
to a separate generic procedure will only lead to many instantiations of 
what is basically a move() procedure.



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

Re: [fpc-pascal] Question about System.Move()

[Marco van de Voort via fpc-pascal]

Op 2021-01-09 om 20:12 schreef Yuriy Sydorov via fpc-pascal:

 So, if I move Arr[3] to Arr[1], I first have to finilize/free Arr[1].

After that move the bytes in Arr[3] are exactly the same as in Arr[1]
(by definition of how move works) AFAIU.
Is that a problem with refcounts, because they would be the same also
but the number of copies increased?


System.Move just copies bytes in the memory. So all handling of 
managed types must be done manually.
So if Arr[1] contains a managed value you need to finalize/free it 
before Move.
After move Arr[1] and Arr[3] will contain the same value and if you 
need to keep both you need to increase the refcount manually.


Or overwrite or finalize the old value with fillchar.


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

Re: [fpc-pascal] FPDoc now with Markdown support

[Marco van de Voort via fpc-pascal]

Op 2021-01-02 om 15:31 schreef Michael Van Canneyt via fpc-pascal:


Hello !

I didn't make it quite in time for the new year, but still:

The fpdoc engine (what is used to document the FPC & Lazarus units) is 
now capable of outputting the documentation in markdown.


After this update I get exceptions on

dwriter.pp:405
405   FreeAndNil(FPageInfos);

In the free event, shutting down fpdoc (chm is already written)

The traceback is convoluted(debian x86-64), but looks like:


#0  DESTROY (this=0x75b0a340, vmt=0x0) at fpdoc/dwriter.pp:405
#1  0x00a0 in ?? ()
#2  0x0001 in ?? ()
#3  0x75b0a340 in ?? ()
#4  0x004a7656 in DESTROY (this=0x75b0a340, vmt=0x0)
    at fpdoc/dw_html.pp:261
#5  0x00621738 in VMT_$DW_CHM_$$_TFPDOCCHMWRITER$indirect ()
#6  0x77d4d818 in ?? ()
#7  0x0005 in ?? ()
#8  0x004157e7 in FREE (this=0xa0) at ../inc/objpas.inc:336
#9  0x7fffdbc0 in ?? ()
#10 0x004cf5c8 in CREATEOUTPUT (this=0x77fbb100,
    APACKAGE=0x777c28a0, ENGINE=0x77fbb280) at fpdoc/mkfpdoc.pp:249


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

Re: [fpc-pascal] Two versions of freemem() - are they equal

[Marco van de Voort via fpc-pascal]

Op 2020-12-30 om 23:54 schreef Graeme Geldenhuys via fpc-pascal:

Do both these method yield the same result, or is one better (performance,
safer?) that the other?


procedure FreeMem(p:pointer;Size:ptruint);
procedure FreeMem(p:pointer);
They are the same.   TP required size for deallocation, Delphi and FPC 
don't.  The overload with size is for TP compatibility.

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

Re: [fpc-pascal] Reading Serial Hex Data

[Marco van de Voort via fpc-pascal]

Op 12/27/2020 om 4:47 PM schreef James Richters via fpc-pascal:

I'm trying to figure out how to read a packet of HEX Bytes of an unknown
length that have no specific termination character over a serial port as
efficiently as practical.
The packet ends when there is just no more data to read.

I have something that is working that I wrote using SerRead from the Serial
unit in FPC, and it works at 9600bps,
but the method I am using will not work well at anything higher unless I can
figure out how to a very accurate very short delay.
At 9600, I need a delay just a little less than 1ms, so I use Sleep(1) for
my delay, but since 1ms is the minimum for sleep, and sleep
itself is not really that accurate, I am doing a lot more delay than I need
to in order to make sure it works.


You don't mention OS, but for Windows no sleep should not be necessary, 
and is unnecessarily delaying.


Look at delphi tcomport which has a waitforevent based solution.

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

[Marco van de Voort via fpc-pascal]

Op 2020-12-22 om 00:42 schreef gabor via fpc-pascal:

W dniu 2020-12-21 o 23:41, Sven Barth via fpc-pascal pisze:
> The main restriction is that it only supports ShortString and thus has
> no Unicode support.

I wonder which type would be best suited to store a unicode character 
(code point) for the screen buffer?


type
  TScreenBuffer = array of record
    Character: TypeForUnicodeCodepoint;
    AttributeAndColor: TAttributeAndColor;
  end;


The problem is that multiple unicode codepoints might translate to one 
character. But that character might have variable width (1, 1.5, 2).  
And the rendering of codepoints to characters is output device 
(terminal, GUI canvas) dependent.


First and for all, I would keep the buffer private. This allows to keep 
the buffer in a format suitable to quickly convert to the output device, 
and access won't be simple array like anyway. This also abstracts final 
writing API and end device encoding.


Maybe have multiple arrays, one for one codepoint per character, and one 
larger ones for additional ones.


This way you can simply scan the larger array if there are additional 
ones, and if not, emit the primary one in a straightforward way.



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

Re: [fpc-pascal] Compilation speed on Apple M1

[Marco van de Voort via fpc-pascal]

Op 2020-11-21 om 14:15 schreef Florian Klämpfl via fpc-pascal:

Am 21.11.2020 um 12:54 schrieb Tobias Giesen via fpc-pascal:


According to Geekbench, the single core performance on the new Mac is
around 1.8x as fast as my Intel Mac. Multicore is also much faster. I
wonder why I don't see the speed increase in compiling though. Yes I am
using different FPC and XCode versions, but I wonder what else could
have an influence? My project is very large and not divided into
packages, so I frequently need to recompile the whole project.


Large parts of FPC are memory throughput limited so I suspect the M1 
is not that much better in this regard, not to mention that most 
likely the AAarch code generator is worse than the x86 one. x86 
received a lot of work in this field.


Some memory throughput details are here: 
https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested


M1 is listed as 96ns memory latency through a 128-bit bus.

A Zen3 (ryzen 5x00) should be 67-83ns depending on type of memory:

https://www.anandtech.com/show/14605/the-and-ryzen-3700x-3900x-review-raising-the-bar/2

which in dual channel mode afaik is also 128-bit.

Maybe it's possible that you build using an LLVM compiler the FPC with 
native backend. As I do not use macOS, I have no clue how to do this 
though.



Do the x86(_64) OSX(I) FPC compilers use binary object writers?



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

Re: [fpc-pascal] link.res search dirs when cross compiling

[Marco van de Voort via fpc-pascal]

Op 2020-11-18 om 19:21 schreef Benito van der Zander via fpc-pascal:


where do the SEARCH_DIRs in link.res come from?


Some are hardcoded, and fpc.cfg might contain -Fl lines with paths too 
from parsing ld.so.conf on install



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

Re: [fpc-pascal] Adding file to string to the RTL

[Marco van de Voort via fpc-pascal]

Op 2020-10-05 om 20:45 schreef Ryan Joseph via fpc-pascal:

I often need to use a function which reads a file into a string, as is so 
common in so many scripting languages. Can it be considered to add something 
like this to the RTL? Since we have a refcounted Ansistring type it's natural 
for this to be a one-liner. Not saying we should use TStringList but that's the 
closest thing I found in the RTL.

function ReadFile(path: Ansistring): Ansistring;
var
   list: TStringList;
begin
   list := TStringList.Create;
   list.LoadFromFile(ExpandFileName(path));
   result := list.Text;
   list.Free;
end;

Stringlist static method loadstringfromfile ?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Merging units

[Marco van de Voort via fpc-pascal]

Op 2020-10-02 om 19:55 schreef Ryan Joseph via fpc-pascal:

Something that's bothered me for a while I wanted to ask about.

I have a package I want to distribute which has 2 or more units, all of which 
are required to use the package. Technically all the code should be in one file 
but because units are a nice feature of Pascal we like to keep our code 
separate when we develop.

Usually what happens is we compromise and do either:

1) Have the user of the package add all the units to the uses clause of every 
file which needs it. This is annoying for the user because it bloats the uses 
section but for the developer our code is nicely separated into units.

2) Break the units into include files and wrap the interface/implementation 
blocks in ifdefs. This is nice for the user because they only have a single 
unit to use but now the developers of the package have to work in what are 
essentially header files (like in C). The RTL is of course filled with examples 
like this.


In some cases you can also move types and consts to a secondary unit, 
but alias them in the primary one.


Like e.g. Unixtype (what unit you say? Never heard of it? That is 
because the types are aliased into core units baseunix and unix)

___
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

[Marco van de Voort via fpc-pascal]

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.


___
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

[Marco van de Voort via fpc-pascal]

Op 2020-09-21 om 08:57 schreef LacaK via fpc-pascal:



Hi *,

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\.

Note that probably none of this is supported, just coincidence because 
Windows functions interpret it themselves.


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

Re: [fpc-pascal] x86-linux-gnu cross

[Marco van de Voort via fpc-pascal]

Op 2020-09-01 om 20:28 schreef Adriaan van Os via fpc-pascal:
On Mac OS X 10.8, I have built an fpc-3.0.4  runtime-library for 
CPU_TARGET=x86_64 OS_TARGET=linux BINUTILSPREFIX=x86_64-linux-gnu- 
after building gnu binutils-2.34 for  --target=x86_64-linux-gnu 
--host=i686-apple-darwin --build=i686-apple-darwin --prefix=/usr/local.


It's been a while since I did crosscompiling regularly, but usually the 
key is comparing a ppas.sh/link.res  natively and cross.  FPC tries to 
be smart in the t_ detecting things that might not be there "cross".   
Add a -k to make LD verbose and then run both, comparing output afterwards.


Also the linker might have some defaults natively that it doesn't have 
cross.



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

Re: [fpc-pascal] FPC coding standards

[Marco van de Voort via fpc-pascal]

Op 2020-08-18 om 23:01 schreef Sven Barth via fpc-pascal:



I see what I can do with ptop config and if need be see what it will
take to improve ptop. Or investigate starting over with pparser,
pastree, paswrite, as I'm already looking at those for some other
things.
https://wiki.lazarus.freepascal.org/fcl-passrc


Might be the even better solution as fcl-passrc will be better 
maintained due to it being used for both the documentation utility 
fpdoc as well as pas2js.


Parsers for compilers or source transformation usually discard 
whitespace asap, while editor and formatting parsers don't. Usually they 
are different beasts.

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

Re: [fpc-pascal] CrossPlatform problem, INFINITE not defined on Linux

[Marco van de Voort]

Op 7/19/2020 om 5:40 PM schreef Bo Berglund via fpc-pascal:

On Sun, 19 Jul 2020 08:46:14 +0200 (CEST), Michael Van Canneyt
 wrote:


Various RunCommand procedures in process unit:
https://www.freepascal.org/docs-html/current/fcl/process/runcommand.html


But it looks like it hangs around until the started process exits...
How can I set a timeout on the execution (don't want the whole system
to hang if this external program does not exit)?


Runcommand handles the most used scenarios only. But in FPC 3.2.0 there 
have been some changes to make own variants easier.


I happened to make a variant with a timeout last week, and use this as a 
demonstration for that (3.2.0+) functionality :


https://forum.lazarus.freepascal.org/index.php/topic,50525.msg368880.html#msg368880

but that is as of yet still untested on non-windows. (but it is general 
in principle)




I'll answer these because they are not documented yet:

poRunIdle -  mainly for tprocess.runcommandloop:  run a sleep() in the 
main loop that polls the pipes.


  In general, enable it for runcommands that run 
longer (to reduce CPU use), disable it if you expect that the process 
runs very short (e.g. "hostname"  on linux)


poDetached - The Windows implementation of poNoconsole of FPC 3.0.4 and 
older.   FPC 3.2.0+ ponoconsole is instantiates less of the console, but 
this causes problems for a few programs (like mysql console). In those 
cases use podetached instead ponoconsole


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

Re: [fpc-pascal] TProcess.CurrentDirectory doc

[Marco van de Voort]

Op 07/07/2020 om 07:44 schreef Michael Van Canneyt:

need more info there! a) what happens when the process, eg Bash 
file, changes its working dir (via "cd") many times and I read 
CurrentDirectory eg during OnReadData (ASyncProcess)? do I get 
changed cur-dir, or initial dir? b) do i get changed dir on all 
OSes? c) if Bash file runs child bash file which changes cur-dir, do 
i get changed dir?


No, because it is the *initial* directory only.

I changed the docs, no need to submit a report.

I quickly walked through the tprocess docs and most new things in 3.2.0 
are nicely documented, nice!  Just two emergency changes from May 
aren't, and might need rerunning makeskel for it.


See two identifiers without description in 
https://www.freepascal.org/docs-html/current/fcl/process/tprocessoptions.html


porunidle:  Run  Runidle event.  By default this is a sleep (to avoid 
busy waiting with long living processes)


podetached: Windows specific alternative to poNoConsole.   Still creates 
a console handle even if it doesn't show it. 
(https://forum.lazarus.freepascal.org/index.php/topic,49631.0)



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

Re: [fpc-pascal] FPC for Win64

[Marco van de Voort]

Op 07/07/2020 om 09:14 schreef Rainer Stratmann:

For Linux: Does that mean apt-get install lazarus is always the 32bit version?
Regardless of the Linux Version (32bit or 64bit).
   

No. The reason for no 64-bit compiler is specific to Windows 64-bit.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] how to make this tp7 code work on fpc

[Marco van de Voort]

Op 2020-06-27 om 04:09 schreef Travis Siegel:
I'm porting some code from tp7 to fpc, and I'm running into an error I 
don't know how to fix.  The comments claim it's supposed to be a hash 
table, but to me, it looks more like labels tied to various arrays.


If you assume that variables are not rearranged in memory, it looks like 
a constant declaration of a linked list. That means there might be even 
more problems than just getting it compiled without errors.



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