Re: [fpc-pascal] fpcmake packaging

2020-09-26 Thread Ben Grasset via fpc-pascal 
What you want is FPMake, not FPCMake. FPCMake is just a generator of GNU
makefiles. As Michael said elsewhere though, FPMake is an API designed
specifically for compiling FPC programs, basically. You write a program
using the API, put it in a file that should always be called "fpmake.pp",
and then either invoke fppkg on it or just literally build it with FPC
yourself and run it (as in like, either "fppkg build" in the directory
where your "fpmake.pp" is, or "fpc ./fpmake.pp && ./fpmake build" in the
directory where your "fpmake.pp" is). Again though, since it is literally
just a program, you can also put any custom logic you want in there.

See here for more info: https://wiki.freepascal.org/FPMake

On Tue, Sep 1, 2020 at 9:05 AM Ryan Joseph via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> I've never used fpcmake before and instead relied on my own custom build
> system solutions which are a pain to maintain and non-standard which it
> makes extra work configuring the pascal language server I'm using now.
>
> My first question of fpcmake is, can I package application bundles and
> copy resources using it? For example some things I need to do:
>
> - create a directory structure and copy the executable into it
> - copy resource files that may have changed
> - run some shell commands which apple provides for compiling various
> resources files
> - copy a info.plist text file and replace some patterns in the file to
> reflect the build version
>
> Are those the kind of things fpcmake can do or do I need another build
> system for this?
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Buffer size for TCP DNS queries in netdb

2020-09-26 Thread Noel Duffy via fpc-pascal 

On 26/09/20 9:07 pm, Michael Van Canneyt via fpc-pascal wrote:


On Sat, 26 Sep 2020, Noel Duffy via fpc-pascal wrote:


To restate the question, is 64k too much overhead for DNS queries? That 
overhead would be present on all queries, regardless of whether UDP or TCP was 
used.


I would then prefer to allocate a dynamic buffer. A simple "Array of Byte" can
easily be managed with SetLength() and it is automatically disposed of when
not needed.


Fair enough. Dynamic it is. Thanks Michael.


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

Re: [fpc-pascal] Buffer size for TCP DNS queries in netdb

2020-09-26 Thread Michael Van Canneyt via fpc-pascal 



On Sat, 26 Sep 2020, Noel Duffy via fpc-pascal wrote:


Hi all,

I've spent some time this past couple of weeks reading through the DNS 
resolver code in netdb and poring over RFCs that specify the protocol with a 
view to adding support for additional resource record queries. Things like 
TXT, SOA, and so forth. I'm using netdb from fpc 3.2.0 as the starting point. 
That code only supports querying DNS over UDP. Because TXT records can be up 
to 64k in size, they frequently get too big to fit inside a UDP packet. The 
RFCs mandate that resolvers must fall back to TCP in that case. That's the 
part I'm currently looking at.


The maximum size for a DNS response over TCP is 65,535 octets. The netdb code 
defines a type TPayload that's a 512 octet buffer for receiving DNS 
responses. That's the largest response possible over UDP. The simplest path 
forward for me is to extend that buffer from 512 octets to 65,535. While that 
increase in size would hardly register on most machines, I wonder whether it 
might be too much on some of the more memory-restricted platforms that FPC 
supports. DOS, for instance. I also see IFDEFs for Android in this code.


The alternative is to use different types for TCP queries, or to have the 
buffer allocated dynamically.


To restate the question, is 64k too much overhead for DNS queries? That 
overhead would be present on all queries, regardless of whether UDP or TCP 
was used.


I would then prefer to allocate a dynamic buffer. A simple "Array of Byte" can
easily be managed with SetLength() and it is automatically disposed of when
not needed.

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

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

2020-09-26 Thread Bernd Oppolzer via fpc-pascal 


Am 25.09.2020 um 22:16 schrieb James Richters via fpc-pascal:


I think that’s a GREAT quote from Niklaus Wirth, and I agree with that 
whole heartedly… programs should be readable by humans… otherwise do 
all your programming in assembly language… the whole POINT of a hi 
level language is to make it readable by humans… not computers.I can’t 
stand trying to muddle through things like C++,it’s just to 
confusing.. trying to follow all those curly braces and figure out 
what this line of code is going to do.. it’s just a mess. yes I can 
manage, but I defiantly prefer the clarity of PASCAL… so I also name 
my variable very clearly instead of using cryptic shorthand.. who 
cares how verbose my variable names are… it doesn’t make the program 
any less efficient.. but very clear function and variable names sure 
make it easier to remember what you were thinking when you have to go 
back and modify code you originally wrote 30 years ago.



...

I admit my code gets a little sloppy with the indents, so after a 
while it sometimes looks like:


if something then
begin
some code here;

some more code;
end;

at least it compiles correctly because the begin and end; are defining 
things… once I get a function or procedure working the way I want it, 
I will then take the time to go back and fix my indents.




Same for me, except that I totally automated the process of fixing the 
indents;
when inserting new code into a program, I don't care much about 
indentation;
instead after compiling successfully, I run a (self-written) Pascal 
program which fixes the
indentation etc.; it also draws boxes around certain comments and 
inserts blank lines,
when necessary. The parts of the program, which are already well-formed, 
remain unchanged.


The program, which fixes the indentation, is in many cases scheduled 
automatically after

a successful compiler run.

This is how a program looks after automated indentation:
https://github.com/StanfordPascal/Pascal/blob/master/PASCAL1.pas

Kind regards

Bernd


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

[fpc-pascal] Buffer size for TCP DNS queries in netdb

2020-09-26 Thread Noel Duffy via fpc-pascal 

Hi all,

I've spent some time this past couple of weeks reading through the DNS resolver 
code in netdb and poring over RFCs that specify the protocol with a view to 
adding support for additional resource record queries. Things like TXT, SOA, 
and so forth. I'm using netdb from fpc 3.2.0 as the starting point. That code 
only supports querying DNS over UDP. Because TXT records can be up to 64k in 
size, they frequently get too big to fit inside a UDP packet. The RFCs mandate 
that resolvers must fall back to TCP in that case. That's the part I'm 
currently looking at.

The maximum size for a DNS response over TCP is 65,535 octets. The netdb code 
defines a type TPayload that's a 512 octet buffer for receiving DNS responses. 
That's the largest response possible over UDP. The simplest path forward for me 
is to extend that buffer from 512 octets to 65,535. While that increase in size 
would hardly register on most machines, I wonder whether it might be too much 
on some of the more memory-restricted platforms that FPC supports. DOS, for 
instance. I also see IFDEFs for Android in this code.

The alternative is to use different types for TCP queries, or to have the 
buffer allocated dynamically.

To restate the question, is 64k too much overhead for DNS queries? That 
overhead would be present on all queries, regardless of whether UDP or TCP was 
used.

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

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

2020-09-26 Thread James Richters via fpc-pascal 
I think that’s a GREAT quote from Niklaus Wirth, and I agree with that whole
heartedly… programs should be readable by humans… otherwise do all your
programming in assembly language… the whole POINT of a hi level language is
to make it readable by humans… not computers.  I can’t stand trying to
muddle through things like C++,  it’s just to confusing.. trying to follow
all those curly braces and figure out what this line of code is going to
do.. it’s just a mess. yes I can manage, but I defiantly prefer the clarity
of PASCAL… so I also name my variable very clearly instead of using cryptic
shorthand.. who cares how verbose my variable names are… it doesn’t make the
program any less efficient.. but very clear function and variable names sure
make it easier to remember what you were thinking when you have to go back
and modify code you originally wrote 30 years ago.
 
I don’t like the begin on the same line after the then, and I prefer
indents.. it really does help a lot to make sure the correct things are
included.. 
 
if something then
   begin
  some code here;
  some more code;
   end
else
   begin
  some other code here;
  some more other code;
   end;
 
with complex code, the indents are a big help, but I also don’t like python
that is strictly defined by the indents.. it becomes too tedious.  I admit
my code gets a little sloppy with the indents, so after a while it sometimes
looks like:
 
if something then
   begin
some code here;
  some more code;
end;
 
at least it compiles correctly because the begin and end; are defining
things… once I get a function or procedure working the way I want it, I will
then take the time to go back and fix my indents.  Its one of the reasons I
don’t care for python.. when I’m busy trying to get some basic logic figured
out, I don’t’ have time to count the indents.. it interferes with my thought
process.  I know I’m going to fix it later.. so I defiantly prefer my
program not to break if I get a little off on my indents trying to get
something done…  Yes PASCAL is my favorite language, and I only even look at
others if I need to.
 
James
 
 
From: fpc-pascal  On Behalf Of
Markus Greim via fpc-pascal
Sent: Thursday, September 24, 2020 4:12 AM
To: bo.bergl...@gmail.com; fpc-pascal@lists.freepascal.org
Cc: Markus Greim 
Subject: Re: [fpc-pascal] basic question on begin, end;
 
Bo,
 
"Programs must not be regarded as code for computers, but as literature for
humans"
 
Niklaus Wirth, the inventor of PASCAL.
Last sentence on the last slide of his presentation. 
given at a conference to honor of his 80th birthday at the ETH Zürich in
2014.
 
(i had the honor to participate)
 
Kind Regards
 
Markus
 
 


On September 24, 2020, 10:04 AM GMT+2 fpc-pascal@lists.freepascal.org
  wrote:
On Wed, 23 Sep 2020 08:28:20 -0700, Ralf Quint via fpc-pascal
mailto:fpc-pascal@lists.freepascal.org> >
wrote:



>Similar like moving code blocks around in 
>Python with a one-off indentation and all the sudden the flow of that 
>code changes, without complaining...

This use of whitespace as block delimiter is why I never could cope
with Python when I was working (now retired).

Begin-end are really big helpers to correctly structure loops etc and
I use them all the time to make things clearer.

Also putting begin right below if, for, while etc makes it much easier
in Lazarus to see what happens in multi-level code when one is
selecting begin or end since they match vertically.
So I never do:

if something then begin
some multi-line code here
end;

Instead:

if something then
begin
some multi-line code here
end;

And of course as has already been pointed out the original question's
example code fundamentally changes execution with or without the
begin-end pair!

-- 
Bo Berglund
Developer in Sweden

___
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