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

[Michael Van Canneyt via fpc-pascal]

On Thu, 12 Aug 2021, Christo Crause via fpc-pascal wrote:


Now as I said I have not used git and for my day use cannot switch because
we
use properties of svn that are simply not available in git...



To retrieve a specific branch without history (I think this is
approximately equivalent to the svn co command) specify options --branch
(to specify which branch to check out),  --single-branch (to not pull in
other branches) and --depth (to limit the history that git pulls in):

git clone --depth=1 --branch fixes_3_2 --single-branch
https://gitlab.com/freepascal.org/fpc/source.git fpc-fixes_3_2

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


Nice, I didn't even know this one. We learn every day !

Thanks.

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

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

[Michael Van Canneyt via fpc-pascal]

On Thu, 12 Aug 2021, Dmitry Boyarintsev wrote:


On Thu, Aug 12, 2021 at 12:27 AM Michael Van Canneyt via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:


It's like switching car brands from a VW to an Audi or so.
Some buttons are in different places, your key will maybe look different,
but that's it. It's a car, it brings you from a to b.


It's not switching brands, it's switching the type of the car.
from a passenger i.e. to a bus.
It's still a car, but the concept is a little different.


A file version system manages versions of files.
The actual commands differ a little, but that's it.



The human psychology. There were no particular problems for anyone to use
SVN.
It worked fine. So for the people it doesn't seem like an obvious reason
for the change.
The change is not recognized by the brain as a needed change, as a cure of
some sort.
Instead it's recognized as an unnecessary burden.
(unlike switching from CVS to SVN)

The same is happening with kids at school. They don't recognize the new
knowledge as something useful.
Instead they still treat the school as a burden.
---
In the software we for some reason prefer to stick to "backwards
compatibility"
No matter how much it affects a project. (it's considered that retaining
backwards compatibility is a positive effect).


Yes, because you break other people's code if you don't.


However the same concept doesn't apply to the infrastructure for some
reason.


No, because the consequences are entirely different:

Changing infrastructure is normally only affecting the team working with
it. If you change it, the effect is only for your team. The final product
is not affected:

For users that download the installer of FPC or Lazarus, it doesn't
matter whether we use git or SVN.

I can understand and up to a point relate to resistance against change, 
but when I speak of 'no-brainer' I simply mean that it's not difficult to

learn or master another version system.

In the particular case of git, it's not like we switched to some obscure
unknown system, totally undocumented... The internet overflows with info
about git.

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

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

[Michael Van Canneyt via fpc-pascal]

On Wed, 11 Aug 2021, Bart via fpc-pascal wrote:


On Wed, Aug 11, 2021 at 11:37 PM Michael Van Canneyt via fpc-pascal
 wrote:


As a programmer, switching version systems should be a no-brainer.


My brain begs to differ...


Well, sorry to say, but I don't understand this.

What's so hard about it ?

It's like switching car brands from a VW to an Audi or so.
Some buttons are in different places, your key will maybe look different,
but that's it. It's a car, it brings you from a to b.

A file version system manages versions of files. 
The actual commands differ a little, but that's it.


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

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

[Michael Van Canneyt via fpc-pascal]

On Wed, 11 Aug 2021, Dmitry Boyarintsev via fpc-pascal wrote:


why not to use Github mirror?


Why not encourage people to go with the times ?

Git is not some witchcraft or dark magic. It's only a version system.

As a programmer, switching version systems should be a no-brainer.

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

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

[Michael Van Canneyt via fpc-pascal]

On Wed, 11 Aug 2021, Bo Berglund via fpc-pascal wrote:


I have for many years been using an install script I wrote to install a complete
freepascal/lazarus dev environment on Raspberry Pi devices.

The script uses subversion to get the sources for fpc and lazarus via svn based
on the specific tags.
Then the script installs the needed dependencies and makes the complete
installation on Raspberry Pi boxes.

Now I have this probles:
- The fpc svn server has been shut down so the source retrieval does not work

Please advice how to:
1) Find which is the latest release tag of fpc and lazarus
2) Retrieve the full sources for that tag on the command line from gitlab

(I do not need the sources to be "live", I can use an export that cannot be
updated because I am not participating in developing either tool.
But it must be something that can be incorporated in a script and run
unattended.)




As soon as I have the sources I believe the rest of my script will work just
fine...

I have used these lines in my script to accomplish the retrieval (with script
variables holding target location, tag and version):

echo "Downloading version $FPCVER of FPC"
cd "$FPCDIR"
svn co https://svn.freepascal.org/svn/fpc/tags/$FPCTAG/ $FPCVER


# Get sources
git clone https://gitlab.com/freepascal.org/fpc/source.git  $FPCVER
# switch to branch/tag
cd $FPCVER
git checkout $FPCTAG
cd ..



echo "Downloading version $LAZVER of Lazarus"
cd "$LAZDIR"
svn co https://svn.freepascal.org/svn/lazarus/tags/$LAZTAG/ $LAZVER



# Get sources
git clone https://gitlab.com/freepascal.org/lazarus/lazarus.git  $LAZVER
# switch to branch/tag
cd $LAZVER
git checkout $LAZTAG
cd ..

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

[fpc-pascal] FPC move to mantis completed

[Michael Van Canneyt via fpc-pascal]

Hello,

After several technical issues (8 tries were needed to convert the FPC
sources to git), the move from svn/mantis to gitlab has been completed.

The FPC sources are now available at

https://gitlab.com/freepascal.org/fpc/source

All FPC git repositories are available at:

https://gitlab.com/freepascal.org/fpc

This is also where bugs can be reported from now on:

All Mantis issues have been converted to Gitlab issues.

Depending on where you report an issue, the Gitlab system will ask you to
select a project under which to report a bug.

Note that e.g. documentation bugs should be reported in the documentation
repository:

https://gitlab.com/freepascal.org/fpc/documentation

etc.

A redirect has been put in place for the old bug system, if possible the
system will redirect you to the correct issue in Gitlab.
A similar redirect will be put in place for the viewvc repository view tool.

The "development" page has been updated with the necessary instructions to
connect with Git:
https://www.freepascal.org/develop.html

More information about git has been placed in the WIKI:

https://wiki.freepascal.org/FPC_git

The lazarus team also placed a version at

https://wiki.freepascal.org/SVN_to_GIT_Cheatsheet

If you see places where we overlooked updating the SVN to git or mantis to
gitlab information, please let us know...

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

Re: [fpc-pascal] Old Mantis issue broken URL redirection

[Michael Van Canneyt via fpc-pascal]

On Wed, 4 Aug 2021, Zamrony P. Juhara via fpc-pascal wrote:


Hi,

URL redirection of old mantis issue to Gitlab  is not working
https://bugs.freepascal.org/view.php?id=[issue id]
redirects to
https://gitlab.com/freepascal.org/fpc/source/-/issues/[issue id]
which yields page not found (404) error.


This is unfortunately correct, there is an unforeseen delay in 
the conversion of the FPC svn -> git repository. 
I think we're meanwhile at attempt 7...


The conversion takes a lot of time (>48 hours in total). 
As long as the conversion is not finished, the repository 
is marked private, and you will get a 404;

only team members have access at this point.

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

Re: [fpc-pascal] Moving to gitlab.

[Michael Van Canneyt via fpc-pascal]

On Thu, 22 Jul 2021, John Lee via fpc-pascal wrote:


I use viewvc to look at repository - is there an equivalent when everyting
is on gitlaB? tia john


Yes; The gitlab interface.

https://gitlab.com/freepascal.org/fpc/testconversion3/-/commits/main

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

[fpc-pascal] Moving to gitlab.

[Michael Van Canneyt via fpc-pascal]

Hello,

Some of you may have seen this on the lazarus list:
During the upcoming weekend we will be moving to GitLab.

During this time, there may be interruptions to 2 of our services:

- SVN will become unavailable permanently.

- Mantis/Bugtracker will become unavailable.
  * It will be taken offline. 
  * A forwarder to the GitLab issue tracker will be installed after all was reworked,

so old 'view' links will continue to work.

The forum and mailing lists should not be affected and continue to work as 
normal.

The list of new Urls will be posted when the move has been done.

We plan a read-only GitHub mirror.

GitHub advertises that the repositories can be read with an svn client too.
So for those needing read only access, there will be an svn link.

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

[fpc-pascal] To all Mantis (Bugtracker) account holders - prepare for the move to Gitlab - Now

[Michael Van Canneyt via fpc-pascal]

Repost from the lazarus list:

---

Hello All,

https://forum.lazarus.freepascal.org/index.php/topic,55167.0.html

We are moving our bugs to Gitlab.

- If you have a mantis account,
- and you want your bugs (or notes) to be identified on gitlab

we can add your gitlab account to the info of the converted bugs/notes.

But you need to provide the info.

To map your gitlab user name (or ID) to the
mantis user, we ask that you file an issue in the mantis project of the
current bugtracker
https://bugs.freepascal.org/bug_report_page.php?project_id=4
Assign it the category gitlab, and set the summary of
the bugreport to your gitlab account name or ID number (not both!).

Only a few days left.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] RxDBGrid and RxColumn

[Michael Van Canneyt via fpc-pascal]

On Wed, 14 Jul 2021, Hassan Camacho Cadre via fpc-pascal wrote:


Hello

I am using lazarus v2.012 and rxnew 3.3.5.231.

In a form I have placed a RxDBGrid component with a lookup column, I want
to know if it is possible search on the values of this column as the user
types, just like the TRxDBLookupCombo component does.

Now when I run the project, position the cursor on the lookup column field
and write some value nothing happens, and I would like to locate the values
that contain the characters that the user types.


I don't think the maintainer of the Rx components is on this list.

Maybe the article here can help you get started:
https://www.freepascal.org/~michael/articles/#grids

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

Re: [fpc-pascal] FPC & Lazarus moving to gitlab

[Michael Van Canneyt via fpc-pascal]

On Mon, 5 Jul 2021, Bo Berglund via fpc-pascal wrote:


On Mon, 5 Jul 2021 19:17:35 +0100, Graeme Geldenhuys via fpc-pascal
 wrote:


On 04/07/2021 9:12 pm, Martin Frb via fpc-pascal wrote:

I recommend on the long run to switch to git.


Once you switch, you'll never want to go back. ;-)



In fpc/lazaus I only ever use the svn repositories to *retrieve* the respective
sources when installing the systems.

My question was really about the two source repositories:
Will they be abandoned now and the only source retrieval is by way of GIT?


Yes.
If you only retrieve, there is little that will change.

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

Re: [fpc-pascal] Tuples as variant arrays

[Michael Van Canneyt via fpc-pascal]

On Fri, 25 Jun 2021, Dennis Lee Bieber via fpc-pascal wrote:


On Fri, 25 Jun 2021 16:12:41 -0600, Ryan Joseph via fpc-pascal
 declaimed
the following:


Is it possible something like this could work? Seems like it should but I get 
an error (got MyRecord expected variant).



{$mode objfpc}

program unit_name;

type
 TTuple = array of variant;

type
 MyRecord = record
 end;


Uhm, is there supposed to be some name designating storage space inside
that record declaration? Just my initial observation -- my Pascal
experience is Jensen via UCSD (college, on LSI-11) and Alcor (on
TRS-80 Model 4).


var
 t: TTuple;
 r: MyRecord;
 i: variant;
begin
 t := [1,'string', r];


https://wiki.freepascal.org/Variant
"""
Values of any simple data type can be stored in a variant variable.
"""
... would seem to reject the use of a record type (as records are,
themselves, made up of other "simple data types").


It is not possible to do this unless you create some custom variant manager
that can handle this. But even so, you'd need to make it a pointer to a
record, as a variant has limited, fixed size.

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

[fpc-pascal] FPC & Lazarus moving to gitlab

[Michael Van Canneyt via fpc-pascal]

Hello All,

The Free Pascal and Lazarus teams are in the process of switching to 
Gitlab to manage their source code and issue reports.


In order to lower maintenance of their own infrastructure, a hosted solution
has been chosen, and an open source license was granted to the teams.

You can see the current progress at:

https://gitlab.com/freepascal.org

2 subgroups have been made:

https://gitlab.com/freepascal.org/fpc
https://gitlab.com/freepascal.org/lazarus-ide

Several testconversions of the SVN history to a Git repository have been
done, with ever improving results. All repositories will be switched to git.

A program has been written to convert Mantis bug reports to Gitlab issues;
it is very complete, and all available info will be converted.
You can see (partial) conversion results on the above projects.

The date for the final conversion has been established as the weekend of
17/18 july. People that wish to report bugs after that will have to create a
gitlab account in order to do so. (Those with a github account can normally
also use that account to log in with gitlab, see the gitlab login page.)

The conversion program will attempt to convert existing bugs using the
account of the new gitlab user. To map your gitlab user name (or ID) to the
mantis user, we ask that you file an issue in the mantis project of the
current bugtracker, assign it the category gitlab, and set the summary of
the bugreport to your gitlab account name or ID number (not both!).

All accounts that can be collected in this manner by 17 july will be used in 
the final conversion.

All necessary information to connect to gitlab will be collected in the FPC &
Lazarus Wiki. Several pages have already been set up:

https://wiki.freepascal.org/FPC_git
https://wiki.freepascal.org/FPC_git_concepts
https://wiki.freepascal.org/SVN_to_GIT_Cheatsheet

These pages will be updated with the correct URLS when the final conversion happens. 
The FPC & Lazarus websites will also be adapted with new instructions.


For the FPC & Lazarus teams,

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

[fpc-pascal] Push rules

[Michael Van Canneyt via fpc-pascal]

Hello,

Martin asked how we intend to go about git commit authors/emails.
These can of course be manipulated at will in Git.

But gitlab can place some restrictions on what is pushed to the repo:

https://docs.gitlab.com/ee/push_rules/push_rules.html

From what I understood, the lazarus team is looking at
"Check whether the commit author is a GitLab user"
and
"Reject unverified users"

(the difference between those two is not clear to me)

Any opinions on this ?

There are many other options.
I only propose to forbid pushing executables (*.exe) or even object files (*.o).

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Wed, 16 Jun 2021, Bo Berglund via fpc-pascal wrote:


I had to add SysUtils to make it work but Lazarus put Classes in there by
itself.
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?

I see many command line utilities (not written by me) that are *much* smaller
and still do much more


That's simply because most of their code is in libc.
libc is the equivalent of sysutils, and many other units in FPC taken
together.

So, to be more correct, you would need to see what libraries they load, add all 
the
sizes of the libraries to the size of the actual executable, and then this
is the total "size" of the binary. That is what you should compare to the
size of the FPC gnerated binary.

As an example take the 'ls' binary.

Binary itself is quite small:

~s -lh /usr/bin/ls
-rwxr-xr-x 1 root root 139K Sep  5  2019 /usr/bin/ls

But look at what it loads:

~$ ldd /usr/bin/ls
linux-vdso.so.1 (0x7ffc3f9c1000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 
(0x7f45b7132000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f45b6f4)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 
(0x7f45b6eb)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f45b6eaa000)
/lib64/ld-linux-x86-64.so.2 (0x7f45b718f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f45b6e87000)
~$ ls -lh /lib/x86_64-linux-gnu/libselinux.so.1 /lib/x86_64-linux-gnu/libc-2.31.so /lib/x86_64-linux-gnu/libpcre2-8.so.0.9.0 /lib/x86_64-linux-gnu/libdl-2.31.so  /lib/x86_64-linux-gnu/libpthread-2.31.so 
-rwxr-xr-x 1 root root 2.0M Dec 16 11:04 /lib/x86_64-linux-gnu/libc-2.31.so

-rw-r--r-- 1 root root  19K Dec 16 11:04 /lib/x86_64-linux-gnu/libdl-2.31.so
-rw-r--r-- 1 root root 571K Dec  7  2019 
/lib/x86_64-linux-gnu/libpcre2-8.so.0.9.0
-rwxr-xr-x 1 root root 154K Dec 16 11:04 
/lib/x86_64-linux-gnu/libpthread-2.31.so
-rw-r--r-- 1 root root 160K Feb 26  2020 /lib/x86_64-linux-gnu/libselinux.so.1

Total size of code needed to run the application: close to 3 Mb.

Comparison is different because of all kinds of memory sharing techniques,
but in general, the code size of an FPC binary is not too bad.

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Wed, 16 Jun 2021, Tomas Hajny via fpc-pascal wrote:


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

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

 Or if they contain $R inclusions.

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



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


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


FPC/lazarus tell you which units are unused, and in the Lazarus IDE you can use 
the
quick actions of the message dialog to quickly remove all unused units.
I use it all the time.

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

Re: [fpc-pascal] TMemoryStream.SetSize question.

[Michael Van Canneyt via fpc-pascal]

On Mon, 14 Jun 2021, gabor via fpc-pascal wrote:


W dniu 2021-06-14 o 21:27, Michael Van Canneyt via fpc-pascal pisze:



On Mon, 14 Jun 2021, gabor via fpc-pascal wrote:


Why does TMemoryStream only implement one version of SetSize method?


https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/classes/classesh.inc?revision=49038=markup#l1225 



The TStream class has two versions of SetSize method (virtual, 
overload) - one with a parameter of LongInt type and the other with 
the Int64 type. Since function is virtual, child classes can override 
it and can be called from code, but then a version of the SetSize 
function not implemented for a given platform in the TMemoryStream 
class can be called.


The base method checks which one is overridden. So it does not matter 
which one you override in the child.

The "other" one will always fall back to the method in TStream.



Unfortunately, on the 64bit platform it does not fully work. See the 
project below.


Sorry, I was mixing up seek and setsize.

Indeed. You should not be calling the integer SetSize() directly.

People creating descendent classes are expected to know what to do, 
i.e. to use the 64-bit version.


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

Re: [fpc-pascal] TMemoryStream.SetSize question.

[Michael Van Canneyt via fpc-pascal]

On Mon, 14 Jun 2021, gabor via fpc-pascal wrote:


Why does TMemoryStream only implement one version of SetSize method?

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/classes/classesh.inc?revision=49038=markup#l1225

The TStream class has two versions of SetSize method (virtual, overload) 
- one with a parameter of LongInt type and the other with the Int64 
type. Since function is virtual, child classes can override it and can 
be called from code, but then a version of the SetSize function not 
implemented for a given platform in the TMemoryStream class can be called.


The base method checks which one is overridden. 
So it does not matter which one you override in the child.

The "other" one will always fall back to the method in TStream.

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

Re: [fpc-pascal] -FNsystem

[Michael Van Canneyt via fpc-pascal]

On Thu, 27 May 2021, Sven Barth via fpc-pascal wrote:


Mattias Gaertner via fpc-pascal  schrieb
am Do., 27. Mai 2021, 13:32:


Hi,

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?



While I agree that adding the namespaces might be a good idea, the fpc.cfg
is not: unlike with Delphi, where it's available as a setting, the fpc.cfg
can't be changed from the IDE. And you can't "unadd" a default namespace,
it needs to be actively removed from the cfg.

Also the less fpc.cfg does automatically for *such* settings the better
(its why we're essentially stuck with enabled C operators as well...).


I also think that this should not be enabled by default.

Such things should be enabled only when we finally release a
unicode-enabled RTL.

With recent changes by Jonas in fpmake, this can now be created with more ease.

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

Re: [fpc-pascal] Can a console app running as Linux service restart itself?

[Michael Van Canneyt via fpc-pascal]

On Thu, 20 May 2021, Bo Berglund via fpc-pascal wrote:


On Thu, 20 May 2021 14:52:47 +0200 (CEST), Michael Van Canneyt via fpc-pascal
 wrote:




On Thu, 20 May 2021, Bo Berglund via fpc-pascal wrote:


I would like my service application to restart itself once per 24 hours, but
only when nothing else is going on. So the application itself would know this
but how can I make it restart itself (as the service)?


Just exit ? 
If you configured systemd to start your app correctly it will restart it.




Is it as simple as that? Here is my service file:

[Unit]
Description=SSRemote Server
Wants=network.target
After=syslog.target network-online.target

[Service]
Type=simple
ExecStart=/agi/ssremote/bin/SSRemoteServerLx
Restart=always  #<== This
RestartSec=10   #<== And this
KillMode=process
User=pi

[Install]
WantedBy=multi-user.target

Do these 2 marked lines mean that if the service application just exits (with no
exit code) systemd will restart it after 10 seconds?


Yes.



And:
Right now I am running it as user pi as shown above, is there some reason I
should run it as root instead?


Running as root is not recommended. You can do it, but I would not.

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

Re: [fpc-pascal] Can a console app running as Linux service restart itself?

[Michael Van Canneyt via fpc-pascal]

On Thu, 20 May 2021, Bo Berglund via fpc-pascal wrote:


I would like my service application to restart itself once per 24 hours, but
only when nothing else is going on. So the application itself would know this
but how can I make it restart itself (as the service)?


Just exit ? 
If you configured systemd to start your app correctly it will restart it.


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

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

[Michael Van Canneyt via fpc-pascal]

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



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

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


Not just "retro" but a more efficient and faster protocol for file downloads.
Unfortunately the whole world is going HTTP crazy and thinks everything should
go over it, including the kitchen sink.


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

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

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

[Michael Van Canneyt via fpc-pascal]

On Mon, 17 May 2021, Travis Siegel via fpc-pascal wrote:

The -dev part of the package is necessary for the headers used for 
compiling, any target system running the finished product will not 
require the -dev version of the packages to be installed, since they 
won't be using the header files directly.


This is not correct for synapse. The name of the library that synapse loads
(it loads dynamically) is the dev name (.so), without version number.

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

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

[Michael Van Canneyt via fpc-pascal]

On Tue, 18 May 2021, Bo Berglund via fpc-pascal wrote:


On Mon, 17 May 2021 23:20:16 +0200, gebylist via fpc-pascal
 wrote:


?Dne 17.05.2021 v 22:06 Bo Berglund via fpc-pascal napsal(a):


And that is what I have done, it is listed in uses of my mailsupport source file
as:
uses
   Classes,
   SysUtils,
   smtpsend,
   ssl_openssl, //<= Here
   synautil,
   mimemess,
   mimepart;

Yet it is "not compiled"...

Very confusing.

It is because loading of ssl_openssl plugin failed. Have you installed 
OpenSSL libraries on your RPi?


How is that done?
Is not openssl part of the Debian and derivatives Linux distros?

Well, I Googled and found a suggested remedy:
sudo apt install libssl-dev

After this was done I ran the exact same code in Lazarus debugger and this time
it got through and the emails were delivered!

Check function |InitSSLinterface in ssl_openssl_lib unit. I personally 
never test ssl_openssl on RPi, maybe some error is here.|




Follow-on question:
Do I have to install dev packages like this on the  target system as well (one
where the application is not going to be built on?

Or is it only needed to be on the *development* system?


It is always needed.

Basically, this package installs a symlink from libssl.so to libssl.so.x.y.z;
you can make this symlink yourself if you prefer.

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

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

[Michael Van Canneyt via fpc-pascal]

Apologies, typed the wrong email alias. 
This was meant to go to the core list.


The problem is real, though... Consider it a heads up :-)

Michael.

On Mon, 17 May 2021, Michael Van Canneyt via fpc-pascal wrote:



Hello,

Mattias Gaertner pointed out that Chrome no longer supports FTP downloads.

I know that Firefox will follow suit really soon (if they haven't already).
Since Edge now also uses Chromium, they will soon also have this disabled.

This wil surely cause problems for many users.

So I think we should start making the FTP server downloads available through 
HTTP(s)
instead of FTP. I also think we should do this for 3.2.2. 
(the pages are auto-generated from some base URLS, so this should not be a 
lot of work)


It should be sufficient to have a virtual host that points
to the ftp directory of the current FPC's ftp dir.

Charlie, is this an option for you ?

If you want, I can create a new DNS:

downloads.freepascal.org

which you can then use to set up the virtual host. 
I don't think HTTPS is a necessity, but if you prefer that is also good of

course...

When that is done, the links on the download page can be switched to http(s).

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


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

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

[Michael Van Canneyt via fpc-pascal]

Hello,

Mattias Gaertner pointed out that Chrome no longer supports FTP downloads.

I know that Firefox will follow suit really soon (if they haven't already).
Since Edge now also uses Chromium, they will soon also have this disabled.

This wil surely cause problems for many users.

So I think we should start making the FTP server downloads available through 
HTTP(s)
instead of FTP. I also think we should do this for 3.2.2. 
(the pages are auto-generated from some base URLS, so this should not be a lot of work)


It should be sufficient to have a virtual host that points
to the ftp directory of the current FPC's ftp dir.

Charlie, is this an option for you ?

If you want, I can create a new DNS:

downloads.freepascal.org

which you can then use to set up the virtual host. 
I don't think HTTPS is a necessity, but if you prefer that is also good of

course...

When that is done, the links on the download page can be switched to http(s).

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

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

[Michael Van Canneyt via fpc-pascal]

On Sat, 15 May 2021, Bo Berglund via fpc-pascal wrote:


On Sat, 15 May 2021 09:00:08 +0200 (CEST), Michael Van Canneyt via fpc-pascal
 wrote:


Glad you got it working.

I worked for some time for a mass mailing company. 
From that experience I assure you that delivering mail is NOT easy.


Meanwhile, there are a lot of safety mechanisms installed on all "big" mail
platforms, and getting a mail delivered becomes more and more difficult.


Well, after a few more tests two of my test recipients again did not receive the
emails. Both are handled by GMail (of course). Now the reason is that GMail
determined that the recipient had gotten too many "similar" emails so it stopped
accepting them.
And I also saw that it is getting suspicious of the "non-validated" sender...

All of this is a PITA since I am working on porting an automatic environment
monitoring system from Delphi to FreePascal and Linux. Here the results will be
emailed packaged in a zipfile several times a day to a few recipients and it is
not acceptable that the recipient's mail server blocks these emails.


Welcome to the world of mailing.
I wish I could say it gets better, but it does not.



The body of the message is fixed at the moment, I could add a timestamp string
to it but not much more to make it "new" every time.
... :(


It might be better not to mail this, but to upload results to a server using
http, which puts everything in a database, and make a small frontend for your 
database.

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

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

[Michael Van Canneyt via fpc-pascal]

On Sat, 15 May 2021, Bo Berglund via fpc-pascal wrote:



It is not a size problem, the test mail contains just a very small zipfile
sample (5 kb in size).
And the mail is not in the spam folder either, it is simply silently rejected by
GMail... No error message.

It turns out that GMail inspects the *content* of the zipfile and if it
discovers "dangerous" constituent files it blocks delivery altogether.
https://support.google.com/mail/answer/6590?hl=en#zippy=%2Cmessages-that-have-attachments%2Cmessages-that-dont-have-attachments

In my case there is a small text file inside named .cmd which is NOT
a Windows command file (similar to a batch file) but a file with a set of
equipment commands and geometry information

So I tested by changing the extension from .cmd to ,cmd.txt and then delivery
started working...
So now I have to modify the automatic server so it will rename this particular
file using a different extension.
But that is easier than dealing with the OpenSSL incompatibility of Indy10 in
any case.


Glad you got it working.

I worked for some time for a mass mailing company. 
From that experience I assure you that delivering mail is NOT easy.


Meanwhile, there are a lot of safety mechanisms installed on all "big" mail
platforms, and getting a mail delivered becomes more and more difficult.

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

Re: [fpc-pascal] SQLDB: Set MySQL SkipVersionCheck in TSQLConnector

[Michael Van Canneyt via fpc-pascal]

On Fri, 14 May 2021, Luis Henrique via fpc-pascal wrote:


Does Anyone known how to set TMySQLConnectionXX SkipVersionCheck property from 
TSQLConnector?
 
It validates the client version against the server version, which is 
problematic, as some client libraries are backward compatible and others don't 
even match any version of the server
like(https://downloads.mysql.com/archives/c-c/) which reports the client 
version as 6. x.
 
My project must support different database vendors/servers so i cannot use 
TMySQLConnectionXX directly.


It currently cannot be done from the TSQLConnector. Although we can probably 
fix that
by allowing to set this property using the parameters. I will add that.

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

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

[Michael Van Canneyt via fpc-pascal]

On Thu, 13 May 2021, Bo Berglund via fpc-pascal wrote:


On Wed, 12 May 2021 12:42:14 +0200 (CEST), Michael Van Canneyt via fpc-pascal
 wrote:


The only attachment example I have (from Michael) brings in mime, which I don't
understand much of and the synapse docs are very hard reading too.


I guess we have a different understanding of "hard reading", then.


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


I found more reading and now I am a bit confused again:
When using MIME, why do you need to also set the recipient, sender etc for the
SMTP object when it is already part of the MIME object?


Recipient and sender are part of the SMTP protocol.

But they are totally independent from the headers that can appear in the 
message.
This is how lots of people are caught with phishing.


Or does SMTP discard its own properties if a MIME package comes along?


No, it does not.

Just set both.

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Wed, 12 May 2021, Ryan Joseph via fpc-pascal wrote:





On May 12, 2021, at 4:00 PM, Sven Barth  wrote:

There's also Oxygene as one of the current ones. 



Oh that's right, that's a pretty cool one. I hope once closures are finished we 
can use them to implement async/await like Oxygene or JavaScript. :)


pas2js already has those :-)

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

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

[Michael Van Canneyt via fpc-pascal]

On Tue, 11 May 2021, Bo Berglund via fpc-pascal wrote:


On Mon, 10 May 2021 09:24:37 - (UTC), Virgo Pärna via fpc-pascal
 wrote:


On Mon, 10 May 2021 10:08:53 +0200 (CEST), Michael Van Canneyt via fpc-pascal 
 wrote:


That's it. From your story, it seems you just need to set
   FSMTP.TargetPort:=465;
   FSMTP.FullSSL:=True;



Also ssl_openssl must be in uses somewhere in program to include
openssl support for Synapse.


Of course, but as I said the basic mail sending is working I just have a hard
time understanding how to add file attachments.
It would not have worked unless the proper uses are added to the pas file and
also the laz_synapse package set as required for the project.


That is always so, for every package you use out there.



The only attachment example I have (from Michael) brings in mime, which I don't
understand much of and the synapse docs are very hard reading too.


I guess we have a different understanding of "hard reading", then.


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

And I had an additional question:

Does Synapse throw exceptions when errors happen? It does not look like that in
the code I have examined so far but I have only looked in two units..


Yes, it does.

You should always assume exceptions. Maybe synapse itself does not throw
one, but e.g. underlying file IO routines might.

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

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

[Michael Van Canneyt via fpc-pascal]

On Mon, 10 May 2021, Bo Berglund via fpc-pascal wrote:



Not so simple when you read scores of Internet pages on the subject...


99% of what is written on internet is junk or outdated.

OK, maybe it's only 98%.

Check the synapse sources, that's all you need. 
The handling of attachments is well explained on the synapse homepage/wiki.


http://www.ararat.cz/synapse/doku.php/public:howto
http://www.ararat.cz/synapse/doku.php/public:howto:mimeparts


Where is the actual sending of the email happening?
And how do I add the attachments?


It is explained in my article. Nothing has changed in this regard.
Didn't you read the section on attachments ?

in the below, aMailData is a record with MailBody, MailHTML strings, and a list 
of
recipients 'Recipients' and attachment filenames in Attachments.

var
  Msg: TMimeMess;
  Body,Html : TStringList;
  H,PM,P,Rel,Alt : TMimePart;
  Recips : TArray;

begin
Msg.Header.From := FSMTP.Username;
Msg.Header.Subject:=aMailData.Subject;
for S in Recips do
  Msg.Header.ToList.Add(S);
if (aMailData.MailBody<>'') and (aMailData.MailHTMl<>'') then
  begin
  PM:=Msg.AddPartMultipart('mixed',Nil);
  Rel := Msg.AddPartMultipart('related', P);
  Alt := Msg.AddPartMultipart('alternative', Rel);
  P:=Alt;
  end;
if aMailData.MailBody<>'' then
  begin
  Body:=TStringList.Create;
  Body.Text:=aMailData.MailBody;
  Body.WriteBOM:=False;
  Msg.AddPartText(Body,P);
end;
if aMailData.MailHTMl<>'' then
begin
  HTML:=TStringList.Create;
  HTML.WriteBOM:=False;
  HTML.Text:=aMailData.MailHTMl;
  H:=Msg.AddPartHTML(HTML,P);
  H.ConvertCharset:=False;
  // H.EncodingCode:=ME_BASE64;
  H.EncodePart;
  H.EncodePartHeader;
end;
// Todo : attachments
// Add all attachments, assume Attachments is a stringlist with
// filenames
For I:=0 to aMailData.Attachments.Count-1 do
   Msg.AddPartBinaryFromFile(Attachments[I],PM);
// Compose message
Msg.EncodeMessage;
if not FSMTP.Login then
  Raise EDaemon.CreateFmt(SErrLoginFailed,[Fsmtp.EnhCodeString]);
//If you successfully pass authorization to the remote server
If Not FSMTP.AuthDone Then
  Raise EDaemon.CreateFmt(SErrLoginFailed,[Fsmtp.EnhCodeString]);
//Send MAIL FROM SMTP command to set sender’s e-mail address.
If Not FSMTP.MailFrom('ourmail@ourcompany', Length(Msg.Lines.text)) then
  Raise EDaemon.CreateFmt(SErrMailFromFailed,[Fsmtp.EnhCodeString]);
For S in aMailData.Recipients do
  begin
  If Not FSMTP.MailTo(S) Then
Raise EDaemon.CreateFmt(SMailtoFailed,[Fsmtp.EnhCodeString]);
  if not FSMTP.MailData(Msg.Lines) Then
Raise EDaemon.CreateFmt(SMailDataFailed,[Fsmtp.EnhCodeString]);
  end;

The above is actual code from a program currently in production. 
This together with the sample from the article should be plenty to create

your own code.

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

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

[Michael Van Canneyt via fpc-pascal]

On Mon, 10 May 2021, Bo Berglund via fpc-pascal wrote:



I have now installed  Synapse 40.1 in LKazarus 2.0.12 with Fpc 3.2.0


I use it myself in a headless FPC-created server running on linux, since many 
many
years, and use it in a Delphi-created server also running on linux, so I'm very
confident it works as described :-)


I have also read your document (pdf):
http://www.freepascal.org/~michael/articles/lazmail/lazmail-en.pdf

But it seems like I still need an example showing how to enable the SSL (port
465) *without* modifying Synapse itself...
This is not mentioned there (also not mentioned are the uses entries for the
example code to work...).

I found this thread in the forum stating that it is written to help for this
problem:
https://forum.lazarus.freepascal.org/index.php?topic=27222.msg168067#msg168067

But the solution here seems to *modify* Synapse package code itself, which I
think is a very bad idea, especially for code that needs to build on "out of the
box" Lazarus installations only specifying which packages to install.

It is very strange to me.
So a working SSL SMTP sending example (with file attachments)would help a lot
because my mail server demands such validation to allow sending.


You don't need to change Synapse ?

My setup is basically:

FSMTP.TargetHost:=MailCfg.HostName;
FSMTP.TargetPort:=IntToStr(MailCfg.Port);
FSMTP.AutoTLS:=MailCfg.UseTLS;
FSMTP.FullSSL:=MailCfg.FullSSL;
FSMTP.Username:=MailCfg.SMTPUserName;
FSMTP.Password:=MailCfg.SMTPPassword;

You need these properties:

{:If is set to true, then upgrade to SSL/TLS mode if remote server support 
it.}
property AutoTLS: Boolean read FAutoTLS Write FAutoTLS;
{:SSL/TLS mode is used from first contact to server. Servers with full
 SSL/TLS mode usualy using non-standard TCP port!}
property FullSSL: Boolean read FFullSSL Write FFullSSL;

That's it. From your story, it seems you just need to set
  FSMTP.TargetPort:=465;
  FSMTP.FullSSL:=True;

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

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

[Michael Van Canneyt via fpc-pascal]

On Thu, 6 May 2021, Bo Berglund via fpc-pascal wrote:


I highly recommend Synapse over Indy.



I had great troubles a year or so ago when I tried using some serial packages
based on synapse because they brought in GUI stuff that made it impossible to
compile a simple program aimed at running as a service on a server style linux
box...


Yes, because you were using the wrong package.

If you use the correct package (laz_synapse.lpk), there will be no issue.

See e.g. here:

https://sourceforge.net/p/synalist/code/HEAD/tree/trunk/

But you can install it using the Online package manager.

In the online package manager, DO NOT use the pl_synapsevs package.

You myst use the laz_synapse (Synapse 40.1) package. 
It does not have GUI dependencies.


I use it myself in a headless FPC-created server running on linux, since many 
many
years, and use it in a Delphi-created server also running on linux, so I'm very
confident it works as described :-)

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

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

[Michael Van Canneyt via fpc-pascal]

On Wed, 5 May 2021, Bo Berglund via fpc-pascal wrote:


On Wed, 5 May 2021 16:51:06 +0200 (CEST), Michael Van Canneyt via fpc-pascal
 wrote:




On Wed, 5 May 2021, Nico Neumann via fpc-pascal wrote:


Indy has support for OpenSSL 1.1.1, just not officially (yet).
See https://github.com/IndySockets/Indy/pull/299


I am aware of this. Good luck getting that to work on linux. 
It's a total mess and not nearly ready for production use.


In the end I simply installed an older version of openssl.



Any directions on how to accomplish this?

Or is there some other way in Lazaus for Linux to add a function to send an
email containing attachments (files with monitoring result data)?
THe SMTP server I use requires SSL on port 465.
I have only ever used Indy for things like this.


Use package laz_synapse (in online package manager), unit smtpsend.

I'm using it in FPC and Delphi even today. 
In general, it works a lot easier/simpler than Indy.


Unless you need some weird/outdated protocols, 
I highly recommend Synapse over Indy.


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

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

[Michael Van Canneyt via fpc-pascal]

On Wed, 5 May 2021, Nico Neumann via fpc-pascal wrote:


Indy has support for OpenSSL 1.1.1, just not officially (yet).
See https://github.com/IndySockets/Indy/pull/299


I am aware of this. Good luck getting that to work on linux. 
It's a total mess and not nearly ready for production use.


In the end I simply installed an older version of openssl.

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

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

[Michael Van Canneyt via fpc-pascal]

On Wed, 5 May 2021, Bo Berglund via fpc-pascal wrote:


I have an application which is ported from Delphi to FreePascal and will be used
on Raspberry Pi (Debian based Linux).
It uses Indy10 components. Indy is installed using OnLinePackageManager in
Lazarus.

The problem I have is that when I run the application it gets an exception when
trying to send an email via an SSL encrypted SMTP mail server.

The exception log I have shows this:
ERROR: Exception during email send: Could not load SSL library.

When searching for this problem I found a Lazarus forum thread dealing in the
same, where a openssl version clash is the reason:
https://forum.lazarus.freepascal.org/index.php/topic,48974.msg354212.html#msg354212

This post states that the problem is solved in FPC 3.2.0


If you are using Indy, it is not.



The core of the problem seems to be the openssl version clash...

Any ideas on how to solve this on Pi-OS Linux?


You can't. Indy does not work with openssl 1.1. 
You must install an older openssl library if you wish to work with Indy.


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

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

[Michael Van Canneyt via fpc-pascal]

On Fri, 30 Apr 2021, Bo Berglund via fpc-pascal wrote:


On Tue, 27 Apr 2021 10:52:28 -0600, Ryan Joseph via fpc-pascal
 wrote:





On Apr 27, 2021, at 9:58 AM, Michael Van Canneyt  wrote:

Wait.


Is this thread intentionally moved from fpc-devel?


No. Mistake, due to mailing list settings and too many recipients when you
hit reply.

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

Re: [fpc-pascal] Detecting IO errors with INI file

[Michael Van Canneyt via fpc-pascal]

On Thu, 29 Apr 2021, James Richters via fpc-pascal wrote:


Best add SysUtils and Classes.


Thanks, that worked.   But now I'm getting "cannot read or write variables of this 
type" for Writeln(Exception)  is there an easy way to find out what the exception is?



On E : Exception do
  Writeln(E.ClassName,' : ',E.Message);

Adapt E to whatever variable you used.

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

Re: [fpc-pascal] non-virtual class methods called from virtual regular method

[Michael Van Canneyt via fpc-pascal]

On Thu, 29 Apr 2021, LacaK via fpc-pascal wrote:



Dňa 29.4.2021 o 9:26 Michael Van Canneyt via fpc-pascal napísal(a):



On Thu, 29 Apr 2021, LacaK via fpc-pascal wrote:


Hi *,

consider the following example

T1 = class
  class procedure CP1;
  procedure P1; virtual;
end;

T2 = class(T1)
  class procedure CP1;
end;

procedure T1.P1;
begin
  CP1; // here is called allways T1.CP1, right?
  // if I want call T2.CP1 then class procedure CP1 must be also 
virtual, right?


Yes

  // so Self.CP1 does not take runtime type but is staticaly resolved 
at compile time to T1.CP1 ?


Yes.


This is bit counter-intuitive for me:


For me not, it's perfectly logical.

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

Re: [fpc-pascal] Detecting IO errors with INI file

[Michael Van Canneyt via fpc-pascal]

On Thu, 29 Apr 2021, James Richters via fpc-pascal wrote:


I’m trying to put the Ini file stuff all in it’s own unit.

My unit is {$Mode OBJFPC}
and Uses IniFiles;

“Try”  is compiling, but I’m getting Error: Identifier not found “EFOpenError”

And also Syntax error “Do” expected but “)” found

I have:

try
 Log_ini := TIniFile.Create('myini.ini');
except
 on e: EFOpenError do  // Identifier not found “EFOPenError”
   Writeln(EFOpenError);
 on e: Exception do
   Writeln(Exception);
end;

Do I need some other unit for EFOpenError to work?


Best add SysUtils and Classes.

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

Re: [fpc-pascal] non-virtual class methods called from virtual regular method

[Michael Van Canneyt via fpc-pascal]

On Thu, 29 Apr 2021, LacaK via fpc-pascal wrote:


Hi *,

consider the following example

T1 = class
  class procedure CP1;
  procedure P1; virtual;
end;

T2 = class(T1)
  class procedure CP1;
end;

procedure T1.P1;
begin
  CP1; // here is called allways T1.CP1, right?
  // if I want call T2.CP1 then class procedure CP1 must be also 
virtual, right?


Yes

  // so Self.CP1 does not take runtime type but is staticaly resolved 
at compile time to T1.CP1 ?


Yes.


end;

var
  c1: T1;

begin
  c1:=T2.Create;
  c1.P1; // here is called T2.P1 - runtime class type
end.

Thanks

Btw If I need for various class descendants define various class 
constants, it is possible only by using class functions (getters), where 
descendant class getter hides parents getter?


If they depend on the class, they're not "constants" to begin with, so a
getter function is the right approach. For such purposes I use virtual class
functions.

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

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

[Michael Van Canneyt via fpc-pascal]

On Tue, 27 Apr 2021, Ryan Joseph via fpc-pascal wrote:





On Apr 27, 2021, at 9:58 AM, Michael Van Canneyt  wrote:

Wait.

I asked Sven to make sure that nested functions are under ALL circumstances
usable as closures or can be used instead of anonymous functions.

Pas2js already supports this, and I want FPC and Pas2JS to be compatible in
this regard.

So as Sven wrote, you would be duplicating effort, needlessly, since it has
to work always... If the compiler can decide that the heap interface is not
needed and optimize it away: so much the better. But I doubt this will be
possible.


Maybe we're misunderstanding each other then. I'm responding to Sven when he 
says:


Getting rid of the interface only works in very narrow circumstances that are 
so seldom in real world code that it is not worth the effort.



I.e.  all closures will be interface based because there are not enough
real world use cases to support any alternative.  Which is contrary to
what you're saying that nested functions/closure will be compatible types.


Why is this contrary ?

As I understand it:

a closure is used for arguments of type 'reference to procedure'.

In delphi, this procedure can be a real method or an anonymous function.

So why should you not be able to use a local function instead of an
anonymous function ?

How the closure is implemented internally is irrelevant from the programmer's point of view. 
As long as the signature is correct, presumably the compiler can figure out what needs to be 
done: create an interface (with all that implies) or not.


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

Re: [fpc-pascal] Mustache templates implementation

[Michael Van Canneyt via fpc-pascal]

On Wed, 21 Apr 2021, Michael Van Canneyt via fpc-pascal wrote:




The result has been committed to packages/fcl-mustache, in case someone
else
has a need for it.


Now thank you for this, I'll be sure to check it out to replace dmustache.


I'm currently porting it to Delphi (where I'll eventually need it) and will
publish those sources too on gitlab or so.
Delphi's JSON handling is not compatible to FPC's so some minor changes are 
needed.


For those interested, I published the Delphi code at:
https://gitlab.com/mvancanneyt/mustached

Michael.


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

Re: [fpc-pascal] Mustache templates implementation

[Michael Van Canneyt via fpc-pascal]

On Tue, 20 Apr 2021, leledumbo via fpc-pascal wrote:


Since dmustache (part of mORMot) fails the official mustache tests and did

not work

on the platform I needed it for, I wrote my own implementation.


I do remember it didn't pass all the tests, but still works for my needs so
I let it be.


My biggest beef is that it does not work on all platforms, because it pulls
in some of mORMot. My implementation just needs the classes and sysutils
units..




The result has been committed to packages/fcl-mustache, in case someone
else
has a need for it.


Now thank you for this, I'll be sure to check it out to replace dmustache.


I'm currently porting it to Delphi (where I'll eventually need it) and will
publish those sources too on gitlab or so.
Delphi's JSON handling is not compatible to FPC's so some minor changes are 
needed.

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

[fpc-pascal] Mustache templates implementation

[Michael Van Canneyt via fpc-pascal]

Hello ,

For my job I needed a Mustache templates library in pascal.

Since dmustache (part of mORMot) fails the official mustache tests and did not 
work
on the platform I needed it for, I wrote my own implementation.

The result has been committed to packages/fcl-mustache, in case someone else
has a need for it.

Basic Features:
- TMustache Component, can be dropped on a form.
- Compiles the template, so repeated output should be fast.
- Passes all official testcases (including weird whitespace rules).
- JSON data input by default.
- Output easily configurable.

Extra:
- Integration with FPExprPars engine for expressions: {{[age + 2]}} will work.
- You can use datasets as source of data.
- Written to be easily extendable with other features.
- Unit tested.

Demos available, there is a complete usable command-line program that has all 
features
enabled.

Enjoy,

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote:


On 19/04/2021 11:28, Michael Van Canneyt via fpc-pascal wrote:



On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote:


On 19/04/2021 09:28, Michael Van Canneyt via fpc-pascal wrote:



From what you say, both problems are related to the tool you use. Are
there no other tools that can be used ?


The wrapping problem is unrelated to the tool, but to the console mode
focus of our installation files. Such a manually formatted text file is
simply unsuitable for a GUI installer.


But if the tool didn't wordwrap, all would be OK, no ?


It's not the tool, it doesn't touch the files. It's the GUI of the
installer application, which shows a plain window that happens to be
slightly too narrow relative to our chosen line length (depending on the
kind of characters on the line, as it uses a proportional font).


So it's the MacOS installer window that does the wrapping ?
being used to Inno Setup I automatically assumed the tool also does the
GUI...

That explains it. Thanks.

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote:


On 19/04/2021 09:28, Michael Van Canneyt via fpc-pascal wrote:



From what you say, both problems are related to the tool you use. Are
there no other tools that can be used ?


The wrapping problem is unrelated to the tool, but to the console mode
focus of our installation files. Such a manually formatted text file is
simply unsuitable for a GUI installer.


But if the tool didn't wordwrap, all would be OK, no ?

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Mon, 19 Apr 2021, Karoly Balogh via fpc-pascal wrote:


Hi,

On Mon, 19 Apr 2021, Michael Van Canneyt via fpc-pascal wrote:


> The main remaining problem is our hard-wrapped readme and whatsnew files
> that look terrible in its installer (because it also performs wrapping
> and it uses a proportional font, so many hard-wrapped lines get wrapped
> again). So at least the changed/new parts need manual unwrapping every time.
>
> For Mac OS X/PowerPC there is the additional issue that the tool to
> create installer packages that work on Mac OS X 10.4 no longer works
> under macOS 10.14, so they have to be created on an older Mac OS X
> version (I don't know when it broke exactly).

Manual work and requiring an old OS are a problem if you want to automate.

From what you say, both problems are related to the tool you use.
Are there no other tools that can be used ?


Well, if we're talking about automation, I'm sure some VM can be set up,
and then it almost doesn't matter which version of macOS it is, until it
works.


In my experience, MacOS is not well-behaved in VMs, but admittedly it's been
a while since I last tried.

But that does not solve the manual formatting.

Don't get me wrong, I am all for automating as much as possible, but if a
tool requires an old macos, and manually formatting files, my first reaction
is to look for another tool.

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote:


On 19/04/2021 07:59, Michael Van Canneyt via fpc-pascal wrote:


But MacOS is a problem.


macOS is also perfectly scriptable, I just have to finish automating it.


I didn't mean to imply that it is not scriptable.

But it's a problem for the reasons you mention below.
At least the first reason was known to me and one of the reasons why I
described mac as problematic.


The main remaining problem is our hard-wrapped readme and whatsnew files
that look terrible in its installer (because it also performs wrapping
and it uses a proportional font, so many hard-wrapped lines get wrapped
again). So at least the changed/new parts need manual unwrapping every time.

For Mac OS X/PowerPC there is the additional issue that the tool to
create installer packages that work on Mac OS X 10.4 no longer works
under macOS 10.14, so they have to be created on an older Mac OS X
version (I don't know when it broke exactly).


Manual work and requiring an old OS are a problem if you want to automate.

From what you say, both problems are related to the tool you use. 
Are there no other tools that can be used ?


I don't know whether Mac OS X/PowerPC still qualifies as a Tier-1 platform; 
But I doubt it. So maybe that can be dropped for these "intermediate" releases.


Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Mon, 19 Apr 2021, Karoly Balogh via fpc-pascal wrote:


Hi,

On Mon, 19 Apr 2021, Sven Barth via fpc-pascal wrote:


Am 18.04.2021 um 23:29 schrieb Zamrony P. Juhara via fpc-pascal:

I would like to propose to separate RTL release  from compiler release
so that RTL bug fixes and features can be released with shorter release
cycle. Is that possible?


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. So if we want to improve on that, we need to improve
the automated packaging of relase-ready binaries at least for Windows,
Linux and MacOS, so Tier 1 systems. Linux is a no brainer, but I've no
clue about what would automating the packaging the Windows or macOS
installers involve.


Windows is also a no-brainer, it's perfectly scriptable. We're using inno
setup.

But MacOS is a problem.

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

Re: [fpc-pascal] Documentation patch for fcl/netdb

[Michael Van Canneyt via fpc-pascal]

Thank you. 
I will check it out ASAP. 
Before publishing, I will need to document all identifiers in the unit.


Michael.

On Sat, 17 Apr 2021, Noel Duffy via fpc-pascal wrote:

I've added a documentation patch to bug 0037906 in the bug tracker. This 
covers the new code that I added to fcl/netdb for DNS resolution as well 
most of the other functions and procedures in the unit. The patch also 
adds examples that showcase the new functions. I've tested these on 
Fedora 32 only.


https://bugs.freepascal.org/view.php?id=37906#c130418



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


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

Re: [fpc-pascal] Trouble integrating examples into fpcdoc

[Michael Van Canneyt via fpc-pascal]

On Mon, 5 Apr 2021, Noel Duffy via fpc-pascal wrote:

In the fpcdocs subversion project, there are a number of example 
directories each containing one or more small programs and a Makefile. 
My question is, is that Makefile automatically generated, or is it 
hand-crafted?


It is hand-crafted.



I'm writing documentation for the netdb module and want to add some 
example programs. I've created the first program and used an example tag 
to reference it within netdb.xml, and this works to show the example 
code in the generated html. But the example program isn't compiled.


None of the examples are compiled when you make the documentation.



Taking the fpcdocs/linuxex example directory, the Makefile references 
the single defined example, ex64.pp, at line 54:


OBJECTS=ex64

This line occurs after this warning:

###
# No need to edit after this line.
###


The OBJECTS= line should be before that remark.

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Wed, 24 Mar 2021, Darius Blaszyk via fpc-pascal wrote:


Hi,

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.

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

Re: [fpc-pascal] fpreport: can not use two ObjectLists as datasource in one report

[Michael Van Canneyt via fpc-pascal]

On Fri, 19 Mar 2021, Andreas Frieß via fpc-pascal wrote:



Am 19.03.2021 um 13:34 schrieb Michael Van Canneyt via fpc-pascal:



On Fri, 19 Mar 2021, Andreas Frieß via fpc-pascal wrote:


If it is not
a bug, so a featurerequest must be possible, because other reports can
handle this without a problem.


You can definitely submit a feature request. For severity, simply
select 'feature'.

Done: 0038639 , but i am not able to set the severity to 'feature'


Hm. Strange. I did it for you.

Thanks for submitting the issue.

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

Re: [fpc-pascal] fpreport: can not use two ObjectLists as datasource in one report

[Michael Van Canneyt via fpc-pascal]

On Fri, 19 Mar 2021, Andreas Frieß via fpc-pascal wrote:



Am 19.03.2021 um 11:07 schrieb Michael Van Canneyt via fpc-pascal:



On Fri, 19 Mar 2021, Michael Van Canneyt via fpc-pascal wrote:




On Fri, 19 Mar 2021, Andreas Frieß via fpc-pascal wrote:


Make a Report Preview -> only the contend of the first dataset is
shown.


I will file a bug


No need, because this is as designed.



For clarity: it's as designed, but that doesn't mean I won't consider
changing the design. Just don't report it as a bug, because it is not.

Michael.


For the record, is this written downwhat is 'by design' ?


No. There are testsuites and some pages in the WIKI 
I obviously don't expect people to deduce the behaviour from those sources.




For me it is a bug, because i can design a unuseable not working second
Databand and i got no message. Nor Designtime, nor runtime.


I expected this comment, and to a certain degree I can see your point.

But for me this is more akin to 'don't put your cat in the microwave to dry it'
you can do it, but don't expect satisfactory results :-)


If it is not
a bug, so a featurerequest must be possible, because other reports can
handle this without a problem.


You can definitely submit a feature request. For severity, simply select 
'feature'.

For completeness:
In general implementing it may be not so trivial as it seems:

First: 
If there are 2 (or more) data bands, which one should I treat first ? 
The one that comes first in the internal list of bands, or the one that comes first

when you visually design the report, or the dataset that comes first in the
list of report data sets ? These orderings may not be identical

Second:
For me it is also a question whether you should first loop the data of the
first data band, and then loop the next. This is your case if I understood
you correctly.

An equally valid approach would be to print one data band, then the other.
Then advance both datasets. etc.

Which one to take depends on what output you need, obviously.
(which is what I remarked on in my first reply)

Then the treatment groupings must be considered, page jumps etc.

Just to say it's far from trivial.

That is why I initially suggested making a second page in the report, 
because then this is all much less ambiguous.


But please submit a feature request, I will try to find a good solution.

For the time being, your approach with fake master detail will need to
suffice...

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

Re: [fpc-pascal] fpreport: can not use two ObjectLists as datasource in one report

[Michael Van Canneyt via fpc-pascal]

On Fri, 19 Mar 2021, Michael Van Canneyt via fpc-pascal wrote:




On Fri, 19 Mar 2021, Andreas Frieß via fpc-pascal wrote:


Make a Report Preview -> only the contend of the first dataset is shown.


I will file a bug


No need, because this is as designed.



For clarity: it's as designed, but that doesn't mean I won't consider
changing the design. Just don't report it as a bug, because it is not.

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

Re: [fpc-pascal] fpreport: can not use two ObjectLists as datasource in one report

[Michael Van Canneyt via fpc-pascal]

On Fri, 19 Mar 2021, Andreas Frieß via fpc-pascal wrote:


Make a Report Preview -> only the contend of the first dataset is shown.


I will file a bug


No need, because this is as designed.

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

Re: [fpc-pascal] fpreport: can not use two ObjectLists as datasource in one report

[Michael Van Canneyt via fpc-pascal]

On Thu, 18 Mar 2021, Andreas Frieß via fpc-pascal wrote:


The expected layout is in the demo.


'Expected layout' for me is a PDF, screenshot image of some finished
document, showing what you want to see printed.



I have data inside of ObjectsList=OL (here in the demo two) and i want
to report one OL by one. This should be done continuos and each OL have
their own layout. There is no master-detail. After one OL is finished
the next should be processed and appended, if the one page is finished,
it should continued on the next page. This works for lReportOLData1 ok,
but lReportOLData2 is never used/seen/reported.


In that case, you must put lReportOLData2 on a separate design page.

So:
* Add a design page (page 1) to the report.
* Do what you need with lReportOLData1 on this page.
* Add a second design page (page 2) to the report
* Do what you need with lReportOLData2 on this page.


That should be it.

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

Re: [fpc-pascal] fpreport: can not use two ObjectLists as datasource in one report

[Michael Van Canneyt via fpc-pascal]

On Thu, 18 Mar 2021, Andreas Frieß via fpc-pascal wrote:


I have a sample attached to show the problem.

I want in the report (created a runtime) to use more than one report
datasource. I create a databand and connect this with a
TFPReportObjectListData object. Each TFPReportObjectListData object
works. But i want to have the data of the first, then the data of the
other object. But i am not able to combine this two Data in one Report.

**
  DataBand := TFPReportDataBand.Create(p);
  DataBand.Name:= 'DBBand01';
  DataBand.Layout.Height := 10;
  DataBand.Data:= lReportOLData1;   // First Data ! This is shown

  Memo := TFPReportMemo.Create(DataBand);
  Memo.Layout.Left := 5;
  Memo.Layout.Top := 0;
  Memo.Layout.Width := 60;
  Memo.Layout.Height := 5;
  Memo.Font.Name := defaultFont;
  Memo.Text := '[InfoA] - [ValueA]';


  DataBand2 := TFPReportDataBand.Create(p);
  DataBand2.Name:= 'DBBand02';
  DataBand2.Layout.Height := 10;
  DataBand2.Data:= lReportOLData2;   // Second Data ! This is not shown

  Memo2 := TFPReportMemo.Create(DataBand2);
  Memo2.Layout.Left := 5;
  Memo2.Layout.Top := 0;
  Memo2.Layout.Width := 60;
  Memo2.Layout.Height := 5;
  Memo2.Font.Name := defaultFont;
  Memo2.Text := '[InfoB] - [ValueB]';

*--*
Any Hint for this problem to solve ?


This is not supported as you write it.

You can have multiple datasources, but only 1 data band. 
If you need multiple data bands, you'll need to use master-detail.


If you want to use the second dataset in a memo expression, you must add it
to the reportdatasets:

lReportOLData2.name:='Data2';
YourReport.ReportData.Add(lReportOLData2);

and in memo2 (which you must place somewhere else):

 Memo2.Text := '[Data2.InfoB] - [Data2.ValueB]';

I can't advise you on what bands you must place memo and how to advance the 2nd
data list, because for that I would need to know the expected layout.

By the way, in
 if Assigned(rptExporter) then FreeAndNil(rptExporter);
etc.

The If Assigned() is not needed. FreeAndNil (or more accurately, Free) will 
already check this for you.

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

Re: [fpc-pascal] Pull request for fphttpclient.pp in git mirror repo

[Michael Van Canneyt via fpc-pascal]

On Tue, 16 Mar 2021, Graeme Geldenhuys via fpc-pascal wrote:



On 16/03/2021 9:29 pm, Martin Frb via fpc-pascal wrote:

For none git users, githup offers patch/diff



Ah yes, I forgot to mention that. Thanks Martin.


Applied in Rev. 48992, so you can close it.

And thank the original contributer from me, please.

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

Re: [fpc-pascal] JSONStringToString question

[Michael Van Canneyt via fpc-pascal]

On Sun, 14 Mar 2021, Sven Barth via fpc-pascal wrote:


On Sun, Mar 14, 2021 at 4:15 PM Michael Van Canneyt via fpc-pascal
 wrote:


Fixed. Thanks for the patch.
There was a second issue, which is now also fixed.


You set target to fpc 4.0
The simple patch I made can be backported/merged to 3.2 fixes branch?


Well, 4.0 is the only "future" version.
There is not yet a 3.2.4 planned.
We don't know what the next version is, so I chose what is available.



Why not merge it to 3.2.1 regardless? After all we'll tag the final 3.2.2
from the fixes branch again and there are already some other fixes that
will be in the final that aren't in the RC yet.


No worries; I was planning to merge to fixes.

But whether it should be in 3.2.2, I don't know yet, 
there is a related bugreport which indicates that the bug is deeper than expected.


In each case, there is no 3.2.4, so currently 4.0 is the only future
version. I mark all bugs I fix for that version currently.

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

Re: [fpc-pascal] JSONStringToString question

[Michael Van Canneyt via fpc-pascal]

On Sun, 14 Mar 2021, Bart via fpc-pascal wrote:


On Sun, Mar 14, 2021 at 4:15 PM Michael Van Canneyt via fpc-pascal
 wrote:


Fixed. Thanks for the patch.
There was a second issue, which is now also fixed.


You set target to fpc 4.0
The simple patch I made can be backported/merged to 3.2 fixes branch?


Well, 4.0 is the only "future" version.
There is not yet a 3.2.4 planned. 
We don't know what the next version is, so I chose what is available.


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

Re: [fpc-pascal] JSONStringToString question

[Michael Van Canneyt via fpc-pascal]

On Sun, 14 Mar 2021, Bart via fpc-pascal wrote:


On Sun, Mar 14, 2021 at 2:55 PM Bart  wrote:


I think I have a fix, will report it.


Reported as https://bugs.freepascal.org/view.php?id=38622
Possible patch attached in the bugreport.


Fixed. Thanks for the patch.
There was a second issue, which is now also fixed.

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

Re: [fpc-pascal] JSONStringToString question

[Michael Van Canneyt via fpc-pascal]

On Sun, 14 Mar 2021, Bart via fpc-pascal wrote:


On Sun, Mar 14, 2021 at 12:43 AM Michael Van Canneyt via fpc-pascal
 wrote:


> Do I misunderstand the purpose of this function or is this a bug?

Seems like a bug.


I'll report it then.
Do you know if we have a test suite for this function, so I can test
if there ar regressions when I try to fix it?


The JSON classes use this function. 
There is a JSON testsuite. Just run that.


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

Re: [fpc-pascal] JSONStringToString question

[Michael Van Canneyt via fpc-pascal]

On Sat, 13 Mar 2021, Bart via fpc-pascal wrote:


From : 
https://www.freepascal.org/docs-html/current/fcl/fpjson/jsonstringtostring.html

Function result
Pascal string with escaped characters replaced

{$mode objfpc}
{$h+}
uses
 fpjson;

var
   S1, S2: TJSONStringType;
begin
 repeat
   write('S: ');readln(S2);
   S1 := JSONStringToString(S2);
   writeln(S1);
 until S2='';
end.

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc test.pas
Free Pascal Compiler version 3.2.0 [2020/06/04] for i386
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
Linking test.exe
15 lines compiled, 0.2 sec, 233536 bytes code, 10196 bytes data

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
S: \u0041\
A (as expected)
S: \u0042
B (as expected)
S: \"\u0041\
"A (as expected)
S: \"\u0041\"
"A" (as expected)
S: \u0041\u0042
AAB (Huh??)

Do I misunderstand the purpose of this function or is this a bug?


Seems like a bug.

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

Re: [fpc-pascal] Smart-linking versus Whole Program Optimization

[Michael Van Canneyt via fpc-pascal]

On Wed, 10 Mar 2021, Jonas Maebe via fpc-pascal wrote:


On 10/03/2021 14:33, LacaK via fpc-pascal wrote:

It will be nice have this in documentation. For example in
https://www.freepascal.org/docs-html/prog/progse30.html#x195-207.3

At least explain:
- relation of -CX and -XX


Indeed.


I am all for it.

But please explain them in plain language so I can update the documentation,
because from the help pages, I don't know what exactly to explain.

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Tue, 9 Mar 2021, Florian Klämpfl via fpc-pascal wrote:


By using the necessary IFDEF mechanism in the config file, we can avoid
inserting it for windows (which does not need it) or the smaller embedded 
platforms
(which cannot handle it).

People that don't need/want this can remove the config setting from the file. 
All the others leave it as-is and will get their desired conversion mechanisms
'for free'.

This way a default choice is made for you on those platforms, but you can still 
100% control
it.


I am very much against this because this means that a default FPC
executable would link against libc.  And this is far too much only because
a few people complain because they didn’t read the docs.


Well, maybe the Lazarus IDE can insert the necessary units, just like it is
done for cthreads...

Michael.___
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

[Michael Van Canneyt via fpc-pascal]

On Tue, 9 Mar 2021, Mattias Gaertner via fpc-pascal wrote:


On Tue, 9 Mar 2021 08:04:54 +0100
Sven Barth via fpc-pascal  wrote:


[...]
FPC is not Java. In FPC you have more fine-grained control over the
resulting binary than "install big, fat runtime". Not to mention that
FPC can target resource constrained systems as well.


Optional is good.

Maybe the defaults can be changed. For example the macOS dmg and
Linux-x86-64 debs/rpms could install an fpc.cfg containing

#ifndef FPNonUnicode
-Facwstring
-Fcutf-8
#endif

For minimal programs pass -dFPNonUnicode


Our mails crossed.

That corresponds to what I proposed, with minor differences. 
The additional #ifndef FPNonUnicode is also a good idea.


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

Re: [fpc-pascal] Cannot write datetime field on sqlite3 database on ARM

[Michael Van Canneyt via fpc-pascal]

On Tue, 9 Mar 2021, Toru Takubo via fpc-pascal wrote:



thank you for the test program. I tested on linux 64-bit, that works OK 

too.


When you look in the database on the arm machine  with an sqlite tool, do
you see the correct values or are the inserted values wrong ?

(I'm trying to establish whether the problem happens during read  or write)

Looking into the database with "DB Browser for SQLite", those fields are all 
"0".
If you set some value in those fields by the tool, you can read them with fpc 
program.

Therefore problem happens on writing values, I believe.


It certainly seems so, yes.

I used a shared library libsqlite3.so included in the "DB Browser for 

SQLite",
so it should work. What can cause such a problem only in the specific 

field

on the specific platform?


Seems like either a floating point issue, or an alignment issue.
I know ARM has some specific behaviour with regard to alignment.

Unfortunately, I have no idea what to test or the means to test it.
Someone more familiar with ARM will need ro test.


It would be better for me to create a bug report?


At this point I think this would indeed be necessary.

So, yes, please add a bugreport !

Michael.___
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

[Michael Van Canneyt via fpc-pascal]

On Tue, 9 Mar 2021, Graeme Geldenhuys via fpc-pascal wrote:


On 09/03/2021 1:44 am, Tomas Hajny via fpc-pascal wrote:
UnicodeString may be used in a program simply because the included unit 
has it used in its interface. That may be the case even if there's no 
use of characters outside of US ASCII at all.


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


No, we give the programmer a choice: 
* Not use unicode conversion at all.

* Use the C library to handle conversion (cwstring).
* Use FPC native code to handle conversion (fpwidestring).
* Some other means.

Since the compiler cannot reliably detect that a choice was made, 
it also cannot make the choice for you, because the choice also cannot 
be undone by the compiler.


This mechanism implies the programmer *has* to make that choice.

This is not different from the threading driver mechanism, for which Lazarus 
adds
some {$IFDEF } mechanisms in the program uses clause.

But, I have been thinking about this. What we can do to alleviate this is the 
following:

Use the -FaNNN option of the command line.

This option will insert NNN implicitly in the uses clause of the program.

So, we can add 
-Fafpwidestring

or
-Facwstring

in the default generated fpc.cfg config file for selected platforms (mac, linux
i386,64-bit, *bsd). The result will be that a widestring driver unit will be 
inserted by default for those platforms.


By using the necessary IFDEF mechanism in the config file, we can avoid
inserting it for windows (which does not need it) or the smaller embedded 
platforms
(which cannot handle it).

People that don't need/want this can remove the config setting from the file. 
All the others leave it as-is and will get their desired conversion mechanisms

'for free'.

This way a default choice is made for you on those platforms, but you can still 
100% control
it.

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

Re: [fpc-pascal] Cannot write datetime field on sqlite3 database on ARM

[Michael Van Canneyt via fpc-pascal]

On Tue, 9 Mar 2021, Toru Takubo via fpc-pascal wrote:


I don't know what to advise to further investigate the issue, One thing to
try would be to test whether normal float arithmetic or date arithmetic 
works.

If not, then the compiler people will need to give more advice.



I created a simple test code, and ran on linux-i386 and linux-arm.
Test on linux-i386 is OK but on linux-arm, I got unexpected values
"30-12-99" as datetime and "2.12199579096527E-314" as float, which are 
different

from values previously set. (except INT and VARCHAR fields)

---linux-i386
INT, VARCHAR,   DATETIME,   DOUBLE
0, 9-3-21 08:50:23, 9-3-21 08:50:23, 0
1, 9-3-21 12:16:06, 9-3-21 12:16:06, 0.142857142857143
2, 9-3-21 15:41:49, 9-3-21 15:41:49, 0.285714285714286
3, 9-3-21 19:07:32, 9-3-21 19:07:32, 0.428571428571429
4, 9-3-21 22:33:15, 9-3-21 22:33:15, 0.571428571428571
5, 10-3-21 01:58:58, 10-3-21 01:58:58, 0.714285714285714
6, 10-3-21 05:24:40, 10-3-21 05:24:40, 0.857142857142857
7, 10-3-21 08:50:23, 10-3-21 08:50:23, 1
8, 10-3-21 12:16:06, 10-3-21 12:16:06, 1.14285714285714
9, 10-3-21 15:41:49, 10-3-21 15:41:49, 1.28571428571429

---linux-arm-
INT, VARCHAR,   DATETIME,   DOUBLE
0, 9-3-21 08:55:53, 30-12-99, 2.12199579096527E-314
1, 9-3-21 12:21:36, 30-12-99, 2.12199579096527E-314
2, 9-3-21 15:47:18, 30-12-99, 2.12199579096527E-314
3, 9-3-21 19:13:01, 30-12-99, 2.12199579096527E-314
4, 9-3-21 22:38:44, 30-12-99, 2.12199579096527E-314
5, 10-3-21 02:04:27, 30-12-99, 2.12199579096527E-314
6, 10-3-21 05:30:10, 30-12-99, 2.12199579096527E-314
7, 10-3-21 08:55:53, 30-12-99, 2.12199579096527E-314
8, 10-3-21 12:21:36, 30-12-99, 2.12199579096527E-314
9, 10-3-21 15:47:19, 30-12-99, 2.12199579096527E-314


thank you for the test program. I tested on linux 64-bit, that works OK too.

When you look in the database on the arm machine  with an sqlite tool, do
you see the correct values or are the inserted values wrong ?

(I'm trying to establish whether the problem happens during read  or write)



I used a shared library libsqlite3.so included in the "DB Browser for 
SQLite",

so it should work. What can cause such a problem only in the specific field
on the specific platform?


Seems like either a floating point issue, or an alignment issue.
I know ARM has some specific behaviour with regard to alignment.

Unfortunately, I have no idea what to test or the means to test it.
Someone more familiar with ARM will need ro test.

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Tue, 9 Mar 2021, Graeme Geldenhuys via fpc-pascal wrote:



On 08/03/2021 2:49 pm, Michael Van Canneyt via fpc-pascal wrote:
In that sense, unicode conversion support is something optional and so we 
require you to enable it explicitly, since enabling it has some drawbacks:


Surely if you explicitly use the UnicodeString type, the compiler should
know you are using UTF-16 (the default encoding of said type), so why not
include the required units implicitly. It doesn't make sense otherwise.


The system unit is full of unicodestring typed routines, same for sysutils.
Mostly they are overloads of single-byte versions of the same call.

Being on Linux, I use only the UTF8 single-byte version of these calls.

So no, I don't need UTF16 despite that these calls are present in units that I 
am
using. So I know this, but the compiler does not.

Maybe with WPO the compiler would be able to deduce it, but even then I am
not sure it can establish this with 100% certainty.

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Mon, 8 Mar 2021, Martin Frb via fpc-pascal wrote:

Obviously knowing the presence/absence of a widestring manager allows to 
refine warnings.


It does not.

The compiler has no way to know if the widestring manager actually does a
complete or even a good job. Maybe it just does logging and calls the
previously registered widestringmanager. 
Maybe it replaces all with a single chinese character for testing purposes, 
or replaces everything with a 0.


Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Mon, 8 Mar 2021, Tomas Hajny via fpc-pascal wrote:


On 2021-03-08 15:49, Michael Van Canneyt via fpc-pascal wrote:

On Mon, 8 Mar 2021, Adriaan van Os via fpc-pascal wrote:

Michael Van Canneyt via fpc-pascal wrote:


You didn't configure your environment to deal correctly with Unicode.


Wow ! what a sentence !

That sounds like "you didn't configure your car correctly to also take 
corners to the right."


A car that does not turn is unusable.

Programs that don't need unicode conversions exist and are perfectly 
usable.


In that sense, unicode conversion support is something optional and so
we require you to enable it explicitly, since enabling it has some
drawbacks:
- Links to C libs if you use cwstring
- Increases your binary substantually if you use fpwidestring and
include all needed characters.


The trouble is - when exactly should the supposed warning be issued? At 
compile time if there are Unicodestring variables and/or constants 
involved, but the Widestring manager is not included in the final binary


Provided you can detect to begin with that a "real" widestring manager 
is included in the final binary...


Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Mon, 8 Mar 2021, Adriaan van Os via fpc-pascal wrote:


Michael Van Canneyt wrote:


The output for me is the same, regardless of the -FcUTF-8 flag being 
present

or not: question marks.

But if I add

uses cwstring;

all will be well.

Rationale:
Without that, the RTL cannot convert whatever the compiler wrote in
the binary to UTF8 to display it on the console.

The compiler people will need to explain what exactly the compiler writes
with or without the flag.


Well, this should at least produce a warning, if not an error. Silently 
producing the wrong code is  not a good idea.


Strictly speaking, there is no wrong code produced:

You didn't configure your environment to deal correctly with Unicode.
You're using the default widestring manager, which simply skips any non-ascii
characters.

All this is documented in various places, for example:

https://www.freepascal.org/docs-html/rtl/system/unicodesupport.html

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Mon, 8 Mar 2021, Adriaan van Os via fpc-pascal wrote:


adriaan% cat uniquizz-utf8.pas

{$codepage utf8}

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

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

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



This leaves me with a question mark too.


The output for me is the same, regardless of the -FcUTF-8 flag being present
or not: question marks.

But if I add

uses cwstring;

all will be well.

Rationale:
Without that, the RTL cannot convert whatever the compiler wrote in
the binary to UTF8 to display it on the console.

The compiler people will need to explain what exactly the compiler writes
with or without the flag.

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

Re: [fpc-pascal] Cannot write datetime field on sqlite3 database on ARM

[Michael Van Canneyt via fpc-pascal]

On Mon, 8 Mar 2021, Toru Takubo via fpc-pascal wrote:


Hi,

I am developing my app on Windows and building apps for other
platforms by using cross compiler. Now I have a problem only
occurred on Linux ARM.

The problem is that it cannot write datetime field on sqlite3
database. It can read/write other fields like int, varchar
or blob, but always write zero in datetime (maybe float as well)
field.

Does anyone have an idea about this issue? I am not sure it is
fpc issue, but better to report bug?


It sounds like a floating point problem. As you probably know, a TDateTime
type is actually a double type. Did you try with a float value ?

The DB explorer tools probably just use strings to read/write from the
database, so they will not be bothere by such things, but FPC stores dataset
values in 'native' formats in memory.

I don't know what to advise to further investigate the issue, One thing to
try would be to test whether normal float arithmetic or date arithmetic works.
If not, then the compiler people will need to give more advice.

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

Re: [fpc-pascal] Traits Proposal

[Michael Van Canneyt via fpc-pascal]

On Sun, 14 Feb 2021, Sven Barth via fpc-pascal wrote:


Am 14.02.2021 um 13:30 schrieb Michael Van Canneyt via fpc-pascal:



On Sun, 14 Feb 2021, Sven Barth via fpc-pascal wrote:

So whether it be this, or just an improvement on the Interfaces we 
already have, I'd definitely personally be in favor of something 
that "works like Interfaces except minus the negative performance 
implications."


There are no significant performance implications of interfaces. 
They're essentially a virtual method call, something that one is 
doing all day long with Object Pascal classes.


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.


No, interfaces by *themselves* don't mean that.


I meant in the context of traits and mixins, obviously.

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

Re: [fpc-pascal] Traits Proposal

[Michael Van Canneyt via fpc-pascal]

On Sun, 14 Feb 2021, Ryan Joseph via fpc-pascal wrote:





On Feb 14, 2021, at 5:30 AM, Michael Van Canneyt via fpc-pascal 
 wrote:

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


You mean COM interfaces? I've only ever used CORBA style ones which I thought 
were just contracts basically. The supports() function returns a pointer to 
something which I thought was part of the existing VMT table.



That is why I think that a 'trait' using an object/advanced record has it's 
advantage: There is only 1 continuous memory block for a class implementing
traits.


Considering the functionality we actually want, i.e. something like inheritance, you could achieve 
the trait by simply making an "imports" property. No need to even introduce the extra 
"trait" type. For example:

 property Test: TTestImpl import FTest;

which is basically the same as:

 property Test: TTestImpl read fTest implements ITest; default;

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.

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

Re: [fpc-pascal] Traits Proposal

[Michael Van Canneyt via fpc-pascal]

On Sun, 14 Feb 2021, Sven Barth via fpc-pascal wrote:

So whether it be this, or just an improvement on the Interfaces we 
already have, I'd definitely personally be in favor of something that 
"works like Interfaces except minus the negative performance 
implications."


There are no significant performance implications of interfaces. They're 
essentially a virtual method call, something that one is doing all day 
long with Object Pascal classes.


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.


That is why I think that a 'trait' using an object/advanced record has it's 
advantage: There is only 1 continuous memory block for a class implementing

traits.

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

Re: [fpc-pascal] Traits Proposal

[Michael Van Canneyt via fpc-pascal]

On Wed, 10 Feb 2021, Ryan Joseph via fpc-pascal wrote:





On Feb 10, 2021, at 8:41 AM, Michael Van Canneyt  wrote:

I heavily object to this; We have way too much keywords as it is already. So 
unless there really is no other way I don't think we should introduce
even more.


I guess the first question is whether a "trait" is a new construct or just
a way to import fields/methods from a  class.  I like the idea of a formal
new type so we can limit the scope of the feature instead of taking on the
baggage of an old type like "object".  I'll wait to hear from the compiler
team however.


I don't see what baggage there is ?

You said it yourself: internally it will just be an object. Just make it 
formally so.

I also think the argument of reusing existing objects deserves consideration.

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

Re: [fpc-pascal] Traits Proposal

[Michael Van Canneyt via fpc-pascal]

On Wed, 10 Feb 2021, Ryan Joseph via fpc-pascal wrote:





On Feb 10, 2021, at 12:32 AM, Michael Van Canneyt via fpc-pascal 
 wrote:

Instead of trait you might as well use simply "object", so basically we
could simply state that instead of an interface, you can also specify an object
in the class definition:


TMyClass = class (TParent,TMyTrait1,TMyTrait2)
Public
 property Trait1: TMyTrait1 read FTrait1 implements TMyTrait1;
 property Trait2: TMyTrait2 read FTrait2 implements TMyTrait2;
end;



Here's the old thread 
http://free-pascal-general.1045716.n5.nabble.com/Interface-delegates-and-the-implements-property-specifier-td5734729.html#a5734741.
 I think we agreed on introducing "trait" because it makes it clear that they 
are not objects and have other limitations. Under the hood they will be objects but it's 
important that the new type exists so the compiler can limit certain feature, like 
operator overloads and constructors (see below).


I heavily object to this; We have way too much keywords as it is already. 
So unless there really is no other way I don't think we should introduce

even more.

The compiler can do the check on an object for allowed/disallowed features
as soon as it is used in a 'trait'. So there really is no advantage gained 
by using 'trait'. The check just happens in a different place: not in the
object definition, but when it is used as a trait. At that point you must 
check for duplicate names (and probably other things) anyway.


Using 'object' has the additional advantage that you can simply use existing
objects, if they fulfill any restrictions, as traits.

If you impose the use of 'trait'  you risk that you must define objects twice 
to be able to use them as a trait - once standalone, once as a trait.


In Javascript you also don't need to use special classes/objects for mixins.

I really do not see a good reason to introduce a new type and matching
keyword.

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

Re: [fpc-pascal] Traits Proposal

[Michael Van Canneyt via fpc-pascal]

On Tue, 9 Feb 2021, Ryan Joseph via fpc-pascal wrote:


We had talked about this some time ago and it's been rattling around in my brain so I wanted to 
write it down into a formal proposal where we can discuss it and hopefully agree upon a syntax. 
Everything is preliminary and tentative but this is a syntax which allows a "composition over 
inheritance" model, also known as "mix-ins" in some languages. That idea is similar 
to multiple inheritance except you have a concrete reference to the trait being implemented so you 
can resolve conflicts easily.

Here's what I have so far. Please feel free to look at it and give any feedback.

https://github.com/genericptr/freepascal/wiki/Traits-Proposal


In general, I am charmed by this idea.

But I don't see the need to extend/change existing syntax, and in fact I highly
object to it.

Instead of trait you might as well use simply "object", so basically we
could simply state that instead of an interface, you can also specify an object
in the class definition:


TMyClass = class (TParent,TMyTrait1,TMyTrait2)
Public
  property Trait1: TMyTrait1 read FTrait1 implements TMyTrait1;
  property Trait2: TMyTrait2 read FTrait2 implements TMyTrait2;
end;

So no syntax changes are needed. Any restrictions on the objects in the
"traits" can be handled by the compiler.

The only difference with Interfaces is that you MUST have a property with
'Implements' if you specify an object. If you do not, the compiler complains.

It will also automatically mean that you can only have 1 trait of a certain
type, since the 
TMyClass = class (TParent,TMyTrait1,TMyTrait2)

cannot contain duplicates.

I also don't think you should forbid constructors; In fact I think they are
necessary if you want to support polymorphism, because I think they create/set 
the VMT ?
(the compiler people need to confirm this)

The only obvious thing missing in your proposal is how this changes the RTTI of 
the
objects.

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

Re: [fpc-pascal] Value:x:y syntax

[Michael Van Canneyt via fpc-pascal]

On Tue, 9 Feb 2021, Luis Henrique via fpc-pascal wrote:


At https://lists.freepascal.org/pipermail/fpc-devel/2021-February/043569.html I saw the 
syntax "value: x: y".

str(value:6:3, valuestr);

What is the name of this and where is it documented?


It is documented in the official documentation:

https://www.freepascal.org/docs-html/current/rtl/system/str.html

The write procedure also supports these formatting options, they are also
documented:

https://www.freepascal.org/docs-html/current/rtl/system/write.html


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

Re: [fpc-pascal] How to handle fpc.cfg on Ubuntu with 3.0.4 and 3.2.0 co-existing?

[Michael Van Canneyt via fpc-pascal]

On Sat, 6 Feb 2021, Bo Berglund via fpc-pascal wrote:


FPC versions.


Graeme thanks for the info!
Since I am not doing any fpc or lazarus development I guess I don't really need
all of that..

My .fpc.cfg file also has the $fpcversion everywhere in the paths so I guess
that unless a new version of fpc adds extra stuff into the file I don't really
need to modify the .fpc.cfg file when installing a new fpc release?


No, you don't. I think my fpc.cfg has not changed in many many years.

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

Re: [fpc-pascal] Statically linked-in fpc code

[Michael Van Canneyt via fpc-pascal]

On Fri, 5 Feb 2021, Michael Van Canneyt via fpc-pascal wrote:




On Fri, 5 Feb 2021, Sven Barth via fpc-pascal wrote:


Adriaan van Os via fpc-pascal  schrieb am
Fr., 5. Feb. 2021, 10:50:


Adriaan van Os via fpc-pascal wrote:

Jonas Maebe via fpc-pascal wrote:

On 2021-02-05 09:24, Adriaan van Os via fpc-pascal wrote:

It's crazy !
<https://bugs.freepascal.org/view.php?id=38440>


The default fpc.cfg file contains this (both in 3.0.4 and 3.2.0):



Thanks for tne reply.


# For a debug version compile with debuginfo and all codegeneration
checks on
#IFDEF DEBUG
  -gl
  -Crtoi
  #WRITE Compiling Debug Version
#ENDIF


I find such sneaky configuration files an extremely bad idea !


Also

1. Section 1.3.31 of the Programmer's manual says "By default, no stack
checking is performed."



The default of the compiler *without* a configuration file (maybe we should
mention that somewhere in the Programmer's Guide). For example C operators
are disabled by default as well (see Programmer's Guide 1.2.10), but the
default configuration file enables them.


Not sure where the 1.3.31 came from, but stack checking is mentioned in
1.7.72;


Make that 1.2.72 :-(

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

Re: [fpc-pascal] Statically linked-in fpc code

[Michael Van Canneyt via fpc-pascal]

On Fri, 5 Feb 2021, Sven Barth via fpc-pascal wrote:


Adriaan van Os via fpc-pascal  schrieb am
Fr., 5. Feb. 2021, 10:50:


Adriaan van Os via fpc-pascal wrote:

Jonas Maebe via fpc-pascal wrote:

On 2021-02-05 09:24, Adriaan van Os via fpc-pascal wrote:

It's crazy !



The default fpc.cfg file contains this (both in 3.0.4 and 3.2.0):



Thanks for tne reply.


# For a debug version compile with debuginfo and all codegeneration
checks on
#IFDEF DEBUG
  -gl
  -Crtoi
  #WRITE Compiling Debug Version
#ENDIF


I find such sneaky configuration files an extremely bad idea !


Also

1. Section 1.3.31 of the Programmer's manual says "By default, no stack
checking is performed."



The default of the compiler *without* a configuration file (maybe we should
mention that somewhere in the Programmer's Guide). For example C operators
are disabled by default as well (see Programmer's Guide 1.2.10), but the
default configuration file enables them.


Not sure where the 1.3.31 came from, but stack checking is mentioned in
1.7.72;

https://www.freepascal.org/docs-html/current/prog/progsu72.html#x79-780001.2.72

I added a warning about defaults in the introduction of the section on
directives, as it is valid for all defaults mentioned.

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

Re: [fpc-pascal] Patches for Issue #37906 - DNS over TCP

[Michael Van Canneyt via fpc-pascal]

On Sat, 30 Jan 2021, Sven Barth via fpc-pascal wrote:

In addition to new code for DNS over TCP, this latest set of patches 
adds checks for writes beyond buffer boundaries and other potential 
security issues. Since the last update I've also added support for 
SRV records, as defined in RFC 2782.


Very nice indeed !! I checked your patches, they're all applied.


Great stuff! Thanks Michael. As always, I wonder if you ever sleep! :-D


Michael applied that around 9 o'clock CET, which is a rather normal time 
for us Europeans to be awake. ;)


Depends on when you go to bed. If I try to wake my daughter at 9AM, 
I risk my life ;)


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

Re: [fpc-pascal] Patches for Issue #37906 - DNS over TCP

[Michael Van Canneyt via fpc-pascal]

On Sat, 30 Jan 2021, Noel Duffy via fpc-pascal wrote:


On 30/01/21 9:45 pm, Michael Van Canneyt via fpc-pascal wrote:



On Sat, 30 Jan 2021, Noel Duffy via fpc-pascal wrote:

I've added patches to resolve issue #37906, DNS over TCP, to the bug 

tracker:


https://bugs.freepascal.org/view.php?id=37906

I've broken the changes into three patches:

1. netdb.patch, which updates packages/fcl-net/src/netdb.pp, adding 

support for DNS over TCP
2. netdb-example.patch, which adds an example program to 
packages/fcl-net/examples and adds it to 
packages/fcl-net/examples/Makefile.fpc
3. netdb-tests.patch, which adds unit tests to packages/fcl-net/tests and 

updates tests/Makefile.fpc to add the new tests to the build system


I've created separate patches to simplify applying them. If there's a 

problem with one, the others should still be OK.


In addition to new code for DNS over TCP, this latest set of patches adds 
checks for writes beyond buffer boundaries and other potential security 
issues. Since the last update I've also added support for SRV records, as 
defined in RFC 2782.


Very nice indeed !! I checked your patches, they're all applied.


Great stuff! Thanks Michael. As always, I wonder if you ever sleep! :-D


Less and less with age ;-)





Thank you very much for this contribution !


Happy to do so.

With regard to documentation, I've not written anything yet, and it seems I'm 
as well placed as anyone to do it. That said, I'm completely unfamiliar with 
generating documentation from source in FPC. But there's just one way to 
learn, I suppose!


Lastly, a minor point: in the source for netdb.pp there's a comment warning 
of stringfromlabel's lack of checks. Since it now has a good few checks, I 
think this warning is superfluous. But I didn't want to remove it without 
checking, in case there's more to it than meets the eye.


I also noticed this, but decided to leave it for the moment. 
if you feel it can be removed, I'll trust your judgment on that.


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

Re: [fpc-pascal] Patches for Issue #37906 - DNS over TCP

[Michael Van Canneyt via fpc-pascal]

On Sat, 30 Jan 2021, Noel Duffy via fpc-pascal wrote:


I've added patches to resolve issue #37906, DNS over TCP, to the bug tracker:

https://bugs.freepascal.org/view.php?id=37906

I've broken the changes into three patches:

1. netdb.patch, which updates packages/fcl-net/src/netdb.pp, adding support 
for DNS over TCP
2. netdb-example.patch, which adds an example program to 
packages/fcl-net/examples and adds it to 
packages/fcl-net/examples/Makefile.fpc
3. netdb-tests.patch, which adds unit tests to packages/fcl-net/tests and 
updates tests/Makefile.fpc to add the new tests to the build system


I've created separate patches to simplify applying them. If there's a problem 
with one, the others should still be OK.


In addition to new code for DNS over TCP, this latest set of patches adds 
checks for writes beyond buffer boundaries and other potential security 
issues. Since the last update I've also added support for SRV records, as 
defined in RFC 2782.


Very nice indeed !! I checked your patches, they're all applied.

Thank you very much for this contribution !

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

Re: [fpc-pascal] fcl-web: Trequest.RemoteAddr is empty (sometimes)

[Michael Van Canneyt via fpc-pascal]

On Tue, 12 Jan 2021, Luca Olivetti via fpc-pascal wrote:


El 12/1/21 a les 10:24, Michael Van Canneyt via fpc-pascal ha escrit:



Am I right thinking that, even if several copies of the above method 
are running, each will get it's own local variables, so the 
LocCommandQueue variable (as well as the other locals) won't be 
clobbered by another copy?

Or should I declare them as threadvar?


If FCommandQueue is the only thing that is set during SyncNewConnection
based on TRequest, then yes.


yes to "each will get its [*] own local" or yes to "should I declare 
them as threadvar"?


Yes to "each will get its own local copy".
I don't think threadvars are needed here.

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

Re: [fpc-pascal] fcl-web: Trequest.RemoteAddr is empty (sometimes)

[Michael Van Canneyt via fpc-pascal]

On Tue, 12 Jan 2021, Luca Olivetti via fpc-pascal wrote:


El 8/1/21 a les 11:14, Luca Olivetti via fpc-pascal ha escrit:

El 8/1/21 a les 11:06, Michael Van Canneyt via fpc-pascal ha escrit:



Are you using https ?


No, plain text http.
An even weirder fact is that I seem to get the wrong ip address (i.e. 
the address of a different client).


I think I found the possible cause:

I have an own thread that spawns a TEmbeddedHttpServer (actually a 
derived class to manage server-sent-events, 
https://lists.lazarus-ide.org/pipermail/lazarus/2020-June/238072.html) 
with threaded:=true.


My thread has a method to manage the requests and it does this

FRequest:=ARequest;
Synchronize(@SyncNewConnection);
if FCommandQueue<>nil then .


I think that, since the method is called from a different thread for 
each request, if two requests come at the same time, the FRequest and/or 
the FCommandQueue (which is set in the synchronized method) could get 
mixed up.


If there is only 1 FRequest instance/location in your thread, then this is 
definitely
so...


I now did 2 things:

1) protected that part of the code with a critical section
2) use TThread.Synchronize(nil,..) (since it's not my thread but another one


   FCrit.Acquire;
   FRequest:=ARequest;
   TThread.Synchronize(nil,@SyncNewConnection);
   LocCommandQueue:=FCommandQueue;
   FCrit.Release;
   if LocCommandQueue<>nil then...



WDYT?


From the info you gave me, I think this could work, yes.

Care should be taken that the critical lock does not cause a deadlock, 
I don't know what happens in SyncNewConnection.




Am I right thinking that, even if several copies of the above method are 
running, each will get it's own local variables, so the LocCommandQueue 
variable (as well as the other locals) won't be clobbered by another copy?

Or should I declare them as threadvar?


If FCommandQueue is the only thing that is set during SyncNewConnection
based on TRequest, then yes. For safety, I would Nil the FCommandQueue after
assigning it to locCommandQueue.

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

Re: [fpc-pascal] SQLDB: Set port in TSQLConnector

[Michael Van Canneyt via fpc-pascal]

On Mon, 11 Jan 2021, Virgo Pärna via fpc-pascal wrote:


On Fri, 08 Jan 2021 14:25:09 -0300, Luis - SoftSAT Sistemas via fpc-pascal 
 wrote:
I'm trying to connect to a Firebird database with TSQLConnector, but I can't 
seem to find a way to set the port number.


Looking at TIBConnection, there is a port property, but none in TSQLConnector.


	You can use 
HostName := ServerName/Port;


Port is normally handled using the Params property, so

Params.Values['port']:='1234'

should do.

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

Re: [fpc-pascal] fcl-web: Trequest.RemoteAddr is empty (sometimes)

[Michael Van Canneyt via fpc-pascal]

On Fri, 8 Jan 2021, Luca Olivetti via fpc-pascal wrote:


El 7/1/21 a les 16:59, Luca Olivetti via fpc-pascal ha escrit:

El 7/1/21 a les 16:15, Luca Olivetti via fpc-pascal ha escrit:

Hello,

I need to tailor the content based on the remote ip address.
I use the property RemoteAddr of a TRequest, but sometimes it is empty.
I see that it is a header, what I didn't see (yet, I'll trace through 
the code later) is if it is sent from the remote host or is it filled 
based on the ip address of the connection.
If the former, is there a more reliable way to obtain the connected ip 
address?

If the latter is it a bug?


I now see that it set in TFPHTTPConnection.ReadRequestHeaders:

    Result.RemoteAddress := SocketAddrToString(FSocket.RemoteAddress)

In turn SocketAddrToString returns an empty string if the address is 
ipv6, but in my case it shouldn't be (the clients, firefox under windows 
10 uses the ipv4 address of the server and most of the time I get the 
correct remote address, even from the same client).


Besides, it seems that the server only listens on ipv4.
I'm puzzled, I really can't see where this empty RemoteAddress could 
come from.


Are you using https ?

Michael.___
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

[Michael Van Canneyt via fpc-pascal]

On Mon, 4 Jan 2021, Bo Berglund via fpc-pascal wrote:


On Sat, 2 Jan 2021 15:31:11 +0100 (CET), Michael Van Canneyt via
fpc-pascal
 wrote:



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.




Question about viewing MD documents (excuse the little deviation from
the main thread topic regarding fpdoc):

Is there an MD renderer created with free pascal that can be plugged
into Apache webserver so that the MD files are rendered correctly in
any browser?


You can use for example this one to translate markdown to HTML:

https://github.com/luridarmawan/fpc-markdown

The demo shows how to use it. You can convert & view the markdown pages
directly or coonvert to html and put the static files somewhere.

Michael.
___
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

[Michael Van Canneyt via fpc-pascal]

On Sat, 2 Jan 2021, Marco van de Voort via fpc-pascal wrote:



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)


Should be fixed in rev. 47981

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

[fpc-pascal] FPDoc now with Markdown support

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


This can be used as input for mkdocs or another engine such as sphinx.
As a first engine, I tackled mkdocs.

Compare the official page for TObject.Dispatch:

https://www.freepascal.org/docs-html/current/rtl/system/tobject.dispatch.html

With the following pages:

They are all the same documentation page, but just use a different theme for 
mkdocs:

gitbook theme:
https://www.freepascal.org/~michael/docs-demo/gitbook/system/tobject.dispatch/

ivory theme:
https://www.freepascal.org/~michael/docs-demo/ivory/system/tobject.dispatch/

windmill theme: (seems broken)
https://www.freepascal.org/~michael/docs-demo/windmill/system/tobject.dispatch/

windmill dark theme: (seems broken)
https://www.freepascal.org/~michael/docs-demo/windmill-dark/system/tobject.dispatch/

docskimmer theme:
https://www.freepascal.org/~michael/docs-demo/docskimmer/system/tobject.dispatch/

default (mkdocs) theme: 
https://www.freepascal.org/~michael/docs-demo/windmill-dark/system/tobject.dispatch/


readthedocs theme: 
https://www.freepascal.org/~michael/docs-demo/readthedocs/system/tobject.dispatch/


material theme: 
https://www.freepascal.org/~michael/docs-demo/material/system/tobject.dispatch/


Some themes work better than others.

Fun fact:
Generating the documentation in HTML with fpdoc takes a couple of seconds.
Depending on the theme, generating the docs with mkdocs (written in Python)
takes 3-7 minutes.

Just shows that Pascal code is very efficient, I suppose... ;-)

I've been looking at allowing markdown for the description files (they would
be less verbose then), but there seems to be no decent markdown parser available 
for pascal. If somone cares to contribute one...


Enjoy,

Michael.


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