Re: [fpc-pascal] What to do to get new users

[Marco van de Voort via fpc-pascal]

Op 16-10-2024 om 23:49 schreef James Richters via fpc-pascal:


I think anyone coming across the IDE and not realizing the help needs 
to be downloaded and installed separately would just assume there is 
no help.I know it states it quite clearly on the download page, but 
when downloading it you are just tying to get it working it’s not 
until you want to really do something and try to use the help that you 
realize there is none, and by then you forgot what was on the download 
page.



3.4.4 will swap the PDF helpfiles for CHM in the windows installer.


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

Re: [fpc-pascal] Fwd: What to do to get new users

[Marco van de Voort via fpc-pascal]

Op 18-10-2024 om 11:23 schreef Karoly Balogh via fpc-pascal:
  

Embarcadero tried it in Delphi, and they failed. Not surprisingly,
they removed again all automatic memory management.

Maybe it was mentioned in the thread, I just glanced through it, but how
about ARC (Automatic Reference Counting), Objective C style?

Delphi tried and failed.  IMHO it was also messy with all the "weak"
attributes.

Just because Delphi failed at something... Doesn't mean we couldn't
succeed. :P Or do it right. But anyway, it definitely serves as a big fat
warning sign, I do agree in that.


Python also uses reference counting (or at least did before the most 
recent version), and it was often blamed for its bad performance.


Reference counting has two problems:

1. as soon as you duplicate references you need to use helpers. This can 
already be seen in ansistrings, but at least by ansistrings it saves 
(some) deep copies of the string contents (compared to shortstrings)


2. These helpers are also in runtimes, so you can't make it optional.

3.  If you have nestable objects, you risk cycles. Defanging that is 
also complicated and costly.


The weak modifiers for references try to cut down on both cases, but it 
is a manual bit.


Personally I don't need GC nor any web or easy deployment for most of my 
work, but I would either have the whole hog (safe, generational, 
movable, i.e. a GC on  scripting language level), or manual witth maybe 
something like shared_ptr for special cases.


But most importantly, since this thread is all about newbs, that is what 
they expect if they , not some halfway beast.


Note that this is already Embarcadero's second halfway attempt, after 
Delphi.NET that iirc tried to declare all classes IDisposable, which 
frustrated the GC and caused heaps to cut out the middle man and go for 
C# directly.



I think it is better that people wanting GC go for the backends that
implement GC.

No argument there.


Or Pascal.NET, component pascal or one of the umpteen others.

My motivation is that it is then the whole hog above, not something two 
wings duck taped to the back of an elephant.




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

Re: [fpc-pascal] Fwd: What to do to get new users

[Marco van de Voort via fpc-pascal]

Op 18-10-2024 om 10:41 schreef Karoly Balogh via fpc-pascal:

By contrast, Pascal is not designed with GC in mind.
You'd need to redesign the language.

If you do that, you can throw away all existing code if you introduce GC,
because the two concepts do not merge easily.

Embarcadero tried it in Delphi, and they failed. Not surprisingly,
they removed again all automatic memory management.

Maybe it was mentioned in the thread, I just glanced through it, but how
about ARC (Automatic Reference Counting), Objective C style?


Delphi tried and failed.  IMHO it was also messy with all the "weak" 
attributes.


I think it is better that people wanting GC go for the backends that 
implement GC.



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

Re: [fpc-pascal] What to do to get new users

[Marco van de Voort via fpc-pascal]

Op 17-10-2024 om 09:10 schreef Michael Van Canneyt via fpc-pascal:


I fully agree. It is especially true for young people.

My wife creates websites for a living. I nearly had to re-animate her 
after she looked at the FPC website.

The FPC website is a no-go area for her since that time.

Hence my intent to re-open the debate.

The discussion back then was about adding a CMS for more timely updates, 
as that was the other problem of the website.


But while a CMS might be slightly easier (but be a drag in maintenance), 
adding new items to the site is not THAT hard, ergo, the problem is in 
the content generation, not the website.


It is the same problem with the documentation (as in contributions from 
people other than you and few contributors like Don), the tools are 
always blamed, but the real problem is that nobody really bothers.



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

Re: [fpc-pascal] What to do to get new users

[Marco van de Voort via fpc-pascal]

Op 16-10-2024 om 15:50 schreef Ștefan-Iulian Alecu via fpc-pascal:



4. a proper VSCode extension (we can include Vim and Emacs there too, 
but the main focus is VSCode) with all the bells and whistles more 
established extensions have. I know we would all want to stick to 
Lazarus and we all know that VSCode is bloated, but we have to accept 
the reality that people do use it and it is really popular. Survive, 
adapt, overcome. :-) OmniPascal was a nice attempt, but it's dead and 
also closed source;



To paraphrase GJC, I came, I provided the resources and I overcame.

5. some form of describing projects that's (ideally) separate from 
Lazarus; it brings 1-4 together, as well as helping the following 
items in one form or another;


Does VSCode have a project system then nowadays?  I thought that being 
projectless was the main feature of VSCODE.


 10. more widespread usage of PasDoc, or a solution like it, and 
improve how the documentation is displayed within Lazarus itself. We 
*really* have to insist on documentation and tutorials, since a lot of 
parts of the RTL and FCL might as well not be documented, with no 
examples;


There is fpdoc, and the FPC docs are quite ok. The problem is contributors.

It would be absurd to expect the Free Pascal team to do all of these, 
everyone's already stretched thin and overworked. More people that 
could develop FP would be nice. Notice that all of the things listed 
above *don't* involve changing the language in any way (maybe changing 
Lazarus, but not by a whole lot).


Agree. In practice the best solution is to try to rise through the ranks 
and become a bugreporter and triager, delivering good quality patches to 
core, and maybe have a bunch of own projects on the side. Core 
developers are usually recruited from those ranks.



We can't be an insular community, otherwise we'll die surrounded by 
the sharks of misinformation or of old age.


Or because we spread ourselves too thin. Having dreams of an ivory tower 
that somehow restores equilibrium ( new developers > old developers) is 
easy. Making the economics work is much harder.


Attempting to whipold and tired Lazarus developers into submission to 
work on vscode plugins IMHO it doesn't make sense. In short, I think the 
new IDEs developers must come from the new developers ranks, those who 
actually believe in it.




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

Re: [fpc-pascal] What to do to get new users

[Marco van de Voort via fpc-pascal]

Op 16-10-2024 om 16:06 schreef Hairy Pixels via fpc-pascal:
Another point is that FPC doesn’t have an official forum except for 
the mail list and that in and of itself is a problem if you ask me. 
Most young people don’t use email and won’t like this. I myself don’t 
prefer the mail list over some of the very nice forums that allow 
posting code and very easy to use and browse information.


FPC asked the Lazarus team to provide FPC specific forum section to act 
as official forum, so this is FUD IMHO




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

Re: [fpc-pascal] What to do to get new users

[Marco van de Voort via fpc-pascal]

Op 16/10/2024 om 06:53 schreef Alexey T. via fpc-pascal:
- Linux: All relevant files (executable files, configuration files, 
source code,etc.) are scattered all over the Linux system. This is 
very complicated again.


This is important part. I agree. Some FPC binaries are in /usr/bin. 
Data files are here, src files are there.

Bad!
We need one folder of FPC in ~/fpc33 (version suffix is optional):


Afaik the FPC installer script already suggest a location in the home 
dir if you execute it with /usr/lib non writable, and it does so for at 
least two decades.


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

Re: [fpc-pascal] What to do to get new users

[Marco van de Voort via fpc-pascal]

Op 16/10/2024 om 15:36 schreef Rainer Stratmann via fpc-pascal:

Am Mittwoch, 16. Oktober 2024, 14:03:39 CEST schrieb Marco van de Voort via
fpc-pascal:

Making sure the few initial
converts stick is as important as getting more initial impressions.

I can't see any contradiction here. If we do things better, everyone benefits.


You need the new users to stick, not just to try it. Specially if you 
have to do a lot of trouble to increase the numbers only a bit. This is 
different from the really popular projects where small efforts can huge 
changes in usage.


It is not bad to work at release engineering and default behavior of the 
IDE, but it should be more focussed on what can be done with limited 
means without changing course, rather than wild new plans.


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

Re: [fpc-pascal] What to do to get new users

[Marco van de Voort via fpc-pascal]

Op 16/10/2024 om 04:32 schreef Rainer Stratmann via fpc-pascal:

I don't think the situations are vary similar, so I don't think the
comparison is useful.

I mainly wanted to say that it is possible to do so without extensive
marketing. Linux is another example. Linux does not spend a huge amount of
money in marketing. It is widely used because it runs stable and for some
other reasons.


I don't think we can compare ourselves to projects that IBM already 
invested a billion into two decades ago.


The foundation helps, but is not yet in that magnitude :-)

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

Re: [fpc-pascal] What to do to get new users

[Marco van de Voort via fpc-pascal]

Op 16/10/2024 om 02:54 schreef DougC via fpc-pascal:


 On Tue, 15 Oct 2024 19:07:58 -0400 *Rainer Stratmann via
fpc-pascal * wrote ---
At the Lazarus Congress in Cologne in October 2024, it ended up
being very

interesting. An important question came up.

Why are no new users coming to Lazarus/Freepascal?
Why do we find it so difficult?
How can we get new, younger users to come to us?



The most fundamental reason more people are not adopting Pascal as a 
programming language is because in the mid-1990's Pascal lost out to 
Java as the initial language that was taught in university settings. 
Because that was the last place Pascal was widely used, it quickly 
became obscure. Also, C was always thought to be the pinnacle of 
achievement. That is, if you could program in C you were considered 
elite. That continues today, although those promoting Rust are making 
a commendable and stalwart effort to have it accepted into the Linux 
kernel.


I agree roughly with you. It is simply a case of what brings in initial 
users. It used to be TP and Delphiers for either platform or cost but 
that is decreasing. We don't have big patron or other mechanism that 
substitutes.


All the navelgazing on what could be wrong with the presentation or 
initial user experience don't make up for those initial numbers. That 
mostly influences the conversion rate of initial impressions to users 
that try it, but we simply don't have the same number of initial 
impressions.  And those initial impressions are generated by major 
vendors or linux distributors or whatever adopting a language.





Today, Python is probably the most widely used programming language. 
Its appeal is based on ease of learning and relaxed rules that 
increase ease of use. While it is as severely flawed language from a 
strict design viewpoint, it has taken over.


Keep in mind that before Python became data scientist's darling, many 
distributions installed it by default for over a decade to replace 
default distro engineering scripting in Perl (the scripting darling 
before Python). It is not just features, exposure is also a factor.




So, faced with this situation, what can be done? Short of a massive 
and expensive marketing effort, not much, except to remove obvious 
attributes that hinder adoption.


Not always.  Keep in mind that entice an initial user to stick around a 
bit longer is only one stage.   Core motivation to start and persist 
with anything beyond the first install, and all other stages till you 
are a core developer ;-) (and each stage has a progressively smaller 
conversion factor).


Overly focusing on the initial user experience is a luxury from projects 
with enormous initial impressions, where every effort for the initial 
user leads to masses of extra new converts, that will sooner or later 
permeate all aspects of the project. Either by paying the bills or 
taking part in development)


But we are not in that situation, and must keep an eye on all users, not 
just focus on the initial user conversion. Making sure the few initial 
converts stick is as important as getting more initial impressions.


One such attribute is the messy, cluttered look of the IDE. An IDE 
redesign with a cleaner, simpler, and visually appealing presentation 
would help enormously. It looks like that is what is being proposed here.
I think the docked IDE by default will have its advantages. Redesign is 
probably not an option.
I have always found that the self-contained nature of Pascal/Delphi 
executables is a big advantage over other language systems. Just copy 
the file and run it, even on a system that has never seen a 
Pascal/Delphi executable before. If we could do that with the 
IDE/compiler it would be magic! The install process is far from that 
goal right now.


And the longevity of those binaries, and quick install.   Copies that 
are installed standalone can be copied with components and all. Here at 
work we use Delphi for the main delivered applications, but lazarus for 
everything else because of the limited number of Delphi installs.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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: 
'#9,vartostr(ColItem.DomainDNSRe

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