[fpc-pascal] TString idea (like stringlist but string only)

[noreply]

Is there a need by anyone for a TString where one could add to a string 
(TString.Add) without any CRLF (line feeds) and modify a string as an 
object?


I have needed this several times as the TStringList linefeeds get in the 
way. It's similar to say some kind of stringlist but focuses only on an 
ansistring as an object instead of a string, to add to, modify, capacity 
(capstr capacity growth idea too).


Regards, Lars
(long time no post!)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] PortAudio writing audio files Windows and MacOS

[noreply]

I noticed freepascal has some PortAudio related code (AFAICT fredvs has 
contributed some units here too)..


Can portaudio, the cross platform API, be used on macOS?

Does it allow writing audio files and adding data to existing audio 
files?


Looking to cut/paste audio into an existing audio stream... And also add 
"silence" to the audio file (dead air, or breaks between audio.. blank 
audio state).


This can all be done on MS Windows likely using MMSystem, but would be 
nice to write audio in a cross platform way.


Also noticed there is FPSound, but it is for reading audio only, so far.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] H2pas tool vs others, C header translation

[noreply]

On 2017-08-27 21:12, Paulo Costa wrote:

On 27-Aug-17 23:47, Dmitry Boyarintsev wrote:

Is 2 neither true, nor false? 3? 4?

If false is zero,
Then true is not false.

Also C doesn't have a boolean type per se. Iirc it was introduced in 
some version of c++ standard.


In C it's very strange to see code like that:

If (b==1)

It's always
If (b)
Or
If (!b)


Of course, that is because, in C, any value that is not zero, is true.

So you can not compare with 1 or -1 or any other value to test if it is 
true...


Paulo Costa


There were some very rare edge cases, that occur, though, I have heard, 
where... this is not the case.


But I would have to take the time to look up the article where I found 
this...


It could even be a rumor, but I think it is serious..

Since it is an edge case, it creeps in like sh*t when you don't expect 
it.

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[noreply]

On 2017-08-27 06:22, Dmitry Boyarintsev wrote:

On Sun, Aug 27, 2017 at 2:37 AM,  wrote:


Why borland chose the bool to not be 100 percent compatible, and
only 50 percent compatible?

Bool in delphi:
true = -1

Bool in C:
true = ($)  1

Why not just make it exactly compatible, there must be some
underlying (possibly obnoxious) reason for this mess.


They are compatible, if you declare like this:

true = (not false);



Depends, AFAIK, if the C library checks for an exact value of 1 
somewhere, when Delphi/FPC sends in a -1, this could cause problems, but 
I haven't thought about it enough.


I just don't see why both languages could not just agree to use "1", 
they must have had some reason, strange or not.

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

Re: [fpc-pascal] sending new parameters to existing instance

[noreply]

On 2017-08-27 14:52, James Richters wrote:
i think you're looking for IPC (InterProcess Communication)... with 
this, the second instance would load up, find that there is one 
already running, tell the already running one about the new file to 
load, and then exit...


Thank you, that is exactly what I want but did not know what it was 
called.


James



http://wiki.lazarus.freepascal.org/SimpleIPC

FPC has its own ipc unit that makes it pretty easy, and I ported it to a 
DLL so that any program in any language can communicate with an fpc 
program

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[noreply]

On 2017-08-27 12:25, mar...@stack.nl wrote:

In our previous episode, nore...@z505.com said:

> rarer
> cases)

That's good news, does Delphi need to add a boolean8/16/32 some day, 
or

already has?


I don't know. FPC needed it for GTK interfacing, but FPC doesn't use 
it.


The main headers interfaced by Delphi are WINAPI, and they have 
longbool.



As I often switch between using fpc and delphi all the time, almost
50/50


More importantly, if you still use ancient D7, would you actually buy a 
new

version (for Eur 1500 or so) if they added it ?



I use ancient versions (D5 and D7) but also have purchased the latest 
Tokyo and use latest too..


No I would not buy it just for that, but, I wonder if I should ring them 
an email on their quality central and feature request it, if they 
haven't got that figured out yet. This header translation stuff, is 
still bothering us years later since the 1990's already, and many errors 
in programs exist because of these damn headers that aren't perfectly 
translated ;-(

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[noreply]

On 2017-08-26 17:09, mar...@stack.nl wrote:

In our previous episode, nore...@z505.com said:

But it gets worse than that: even fpc/delphi's bool is not always
compatible (but is sometimes).

For example:
http://blog.delphi-jedi.net/2008/09/25/bool-boolean-and-integer/

When one must use Integers to do boolean related programming tasks, it
makes me want to quit programming ;)


The QueryServiceConfig2 is a known exception in WINAPI land that in 
some

cases assumes things about what is TRUE.

The GTK headers also use a 0/1 boolean, and for that the boolean8/16/32
types were created. I couldn't quickly find docs, so I filed a bug for 
that.


IOW that problem has long resolved, you just need to know what 
convention
the C code uses, and map that then to either boolean32 or longbool (or 
rarer

cases)


That's good news, does Delphi need to add a boolean8/16/32 some day, or 
already has?


As I often switch between using fpc and delphi all the time, almost 
50/50

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[noreply]

On 2017-08-26 17:22, mar...@stack.nl wrote:

In our previous episode, Michael Van Canneyt said:
I think the programmer *must* worry about the details and must 
definitely

NOT use the booleans for anything C related. That was my point.


The interface uses bool, either as param or in a structure. So what can 
you

do?

Attempting to cater for C code using BOOL or whatever type is 
misplaced.

C does not have a boolean type.


Since C99 it has:

https://stackoverflow.com/questions/4767923/c99-boolean-data-type


The standard says for "if" :

"In both forms, the first substatement is executed if the expression
compares unequal to 0."

Treat it as such.


All true, but futile, since one assumes the C side is not written by 
whoever

wants to interface it. He might not even have source.

And sometimes API don't adhere to above statement, and then having 
chosen

the right boolean type (longbool or boolean) saves a lot of trouble.


Another option is to write BOOLEAN wrappers around the lower level 
functions that interface in to the DLL
So for example, could even use an INTEGER, as the boolean, as the Jedi 
fellow sometimes does, then write a wrapper around it that makes use of 
a proper boolean. All this, though, is a headache and obnoxious, tedious 
.

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[noreply]

On 2017-08-26 02:50, Michael Van Canneyt wrote:
I thought all this BOOL mess was just meant to be able to interface 
with C

libs slightly easier.


But, why is the BOOL in fpc/delphi not compatible with C BOOL, in that 
it has different semantics?


One value lines up correct... but not always the other.

Why borland chose the bool to not be 100 percent compatible, and only 50 
percent compatible?


Bool in delphi:
true = -1

Bool in C:
true = ($)  1

Why not just make it exactly compatible, there must be some underlying 
(possibly obnoxious) reason for this mess.

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[noreply]

What about the BOOL issue..

We know that Boolean in fpc/delphi is not compatible with a C bool

But it gets worse than that: even fpc/delphi's bool is not always 
compatible (but is sometimes).


For example:
http://blog.delphi-jedi.net/2008/09/25/bool-boolean-and-integer/

When one must use Integers to do boolean related programming tasks, it 
makes me want to quit programming ;)


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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[noreply]

On 2017-08-22 04:04, mar...@stack.nl wrote:

In our previous episode, Dmitry Boyarintsev said:


I'm using Chelper.  (http://wiki.freepascal.org/Chelper)
It's my choice, because it preserves comments (which is usually an
important part of open-source libs)
plus, can be configured to handle library header-specific defines.
Naturally, the process is semi-automatic, but get be done quite 
quickly.


Note that to convert C (as in source code, not headers), I did use 
other

tools in the past. Can't remember which though.



I did mean headers, not C source... But C source is also interesting to 
convert of course
I wonder if the Quake to Delphi and Doom To Delphi folks wrote tools for 
conversion, or used existing ones to do the bulk of the work.  If 
superman was involved, they likely did it by hand 100 percent the hard 
way, but if they are A.I. then they have no hands, likely.

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

Re: [fpc-pascal] H2pas tool vs others, C header translation

[noreply]

On 2017-08-21 13:08, mar...@stack.nl wrote:

In our previous episode, Michael Van Canneyt said:

> I am looking to convert the GNU MPFR library header files, or hire
> someone on a bounty to do it if header translation is not so easy with
> h2pas and requires lots of hand work, and close checking.

I do all header translations with h2pas. Most of the time, I run the 
code
first through gcc -E, which will take care of all macro magic. Usually 
h2pas

has little trouble with the result.


Before everything I do a couple of substs with an editor,



What do you mean by substs..

Search/replace, (substitutions? regex?)


gcc -E I use small pascal filterprograms to sort the symbols based on
heuristics.  Usually "clean" defines, structs, function calls and 
"rest".


A custom filter program for each case by case basis, or one major filter 
program you wrote for all header files?


Thanks for the tips.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] H2pas tool vs others, C header translation

[noreply]

On 2017-08-21 20:34, Dmitry Boyarintsev wrote:

On Sun, Aug 20, 2017 at 5:37 PM,  wrote:


Is there a competing tool that does more, or is updated more?


How about this list?
http://wiki.freepascal.org/C_to_Pascal


That's a good one, I missed that.. could not find it previously when 
searching google


Did you write CHelper because H2pas was not to your satisfaction?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Super Large Integer Math Calculations

[noreply]

On 2017-08-20 16:29, I previously wrote:

On 2017-08-10 22:45, Stuart Cox wrote:

Have a look at http://www.wolfgang-ehrhardt.de/




Thanks, looks interesting!

I could not find the maximum supported length of a number (multi
gigabyte?) or number string though..

i.e. for big numbers, but how big?


On his page, I found this:

"For 32/64-bit compilers MAXDigits should be <= 2^24"

http://www.wolfgang-ehrhardt.de/mp_intro.html
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] H2pas tool vs others, C header translation

[noreply]

Forgive me, I have forgotten, this may have been discussed before..

Is h2pas the latest tool to convert C headers to pas files?

Is there a competing tool that does more, or is updated more?

I remember Bob Swart AFAIR had a popular tool for delphi.

And some people use multiple tools if one tool is giving them issues.

Is h2pas for example the one that is used for Mysql header translations 
and other major C headers?


I am looking to convert the GNU MPFR library header files, or hire 
someone on a bounty to do it if header translation is not so easy with 
h2pas and requires lots of hand work, and close checking.


The issue I see with header translation is there is no way to prove that 
the header translation is 100 percent correct, as the compiler will not 
tell you if it found an issue, it will just link the DLL as you stated 
to link it. Too bad DLL/DSO libraries could not export some sort of 
correctness or type verification when you link against the library.

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

Re: [fpc-pascal] Super Large Integer Math Calculations

[noreply]

On 2017-08-10 22:45, Stuart Cox wrote:

Have a look at http://www.wolfgang-ehrhardt.de/




Thanks, looks interesting!

I could not find the maximum supported length of a number (multi 
gigabyte?) or number string though..


i.e. for big numbers, but how big? Big is a vague term :-)

It might be mentioned somewhere on his pages, I just couldn't find it 
yet

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

Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?

[noreply]

On 2017-07-26 06:34, Sven Barth via fpc-pascal wrote:

Am 26.07.2017 10:59 schrieb "Martok" :


> Ideally the function should be portable between FPC and Delphi

XE5...

You'd only need your own functions for Delphi, FPC's intrinsics such

as Insert()

can already work with arrays:

var
  b, c: TBytes;
begin
  b:= TBytes.Create(1,2,3);
  c:= TBytes.Create(10,11);
  Insert(c,b,2);

-> b is now [1,2,10,11,3]


But only in trunk. And Delphi XE8 and newer also support them.

Regards,
Sven


Oh, that would explain why it is not in the wiki/docs yet

Only issue I can see, is with all Create's, programmers expect a 
matching Free.
So that is a bit confusing, but so long as someone remembers arrays are 
garbage (reference rather) collected...

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

Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?

[noreply]

On 2017-07-25 11:00, Martok wrote:

Ideally the function should be portable between FPC and Delphi XE5...
You'd only need your own functions for Delphi, FPC's intrinsics such as 
Insert()

can already work with arrays:

var
  b, c: TBytes;
begin
  b:= TBytes.Create(1,2,3);
  c:= TBytes.Create(10,11);
  Insert(c,b,2);

-> b is now [1,2,10,11,3]




The fpc wiki should probably be updated?

I cannot find "insert" on this page:
http://wiki.freepascal.org/Array

I cannot find it here either:
https://www.freepascal.org/docs-html/ref/refsu14.html

For the last 10 years or so I've been criticizing occasionally the fact 
that everyone reinvents their own array algorithms for each array! So it 
seems that may solve it. In fact this problem goes back to the 1970's 
and 1980's when arrays were being used.


Please list other functions other than insert that are available? Maybe 
someone add it to the wiki/docs

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

Re: [fpc-pascal] Super Large Integer Math Calculations

[noreply]

Here is another utility for really large numbers:

https://github.com/graemeg/freepascal/tree/master/packages/gmp

GMP (multi precision) bindings for fpc

This has been around for quite a while and should be well known - I 
either forgot about it, or memory faded, or it didn't register in my 
mind

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

Re: [fpc-pascal] OS/2 support and text colors

[noreply]

On 2017-07-20 05:00, Graeme Geldenhuys wrote:

Hi,

Not strictly FPC related, but I know here are some OS/2 software
developers around - and I have no idea where else to ask.



Isn't OS/2 from pre-win95 days and is very risky to support since it's 
dead?


Related:
"OS/2: Blue Lion to be the next distro of the 28-year-old OS"

Will fpc be supporting "blue lion", whatever it is.. (sorry, no time to 
research it myself, right now).. up until a.d.d. sets in

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

Re: [fpc-pascal] Static local variables available?

[noreply]

On 2017-07-21 07:16, Sven Barth via fpc-pascal wrote:

Am 21.07.2017 10:44 schrieb "Santiago A." :


El 20/07/2017 a las 15:50, Sven Barth via fpc-pascal escribió:


Am 20.07.2017 13:01 schrieb "Bo Berglund" :
>
> On Thu, 20 Jul 2017 11:11:50 +0200, Maciej Izak
>  wrote:
>
> >2017-07-20 11:03 GMT+02:00 Bo Berglund :
> >
> >> So since I don't really want to use a global, is it possible

to

> >> declare a local variable static in the sense that it retains

its

> >> values across calls to the procedure?
> >> If so how is it done?
> >>
> >
> >procedure foo;
> >{$PUSH}
> >const{$J+}
> >  s : string ='';
> >{$POP}
>
> Thanks,
> but it looks a bit involved, probably better to use an object

field

> variable instead only accessible from the internal methods.

If you don't want to use $push/$pop then you can also simply enable

$J+ for the whole unit. But this will also mean that global constants
are writable.


Well, I'm an old dog so I prefer old fashion ways. A variable that

retains its value is, from memory point of view, a global variable. I
mean, the memory is never freed, it's not freed when it goes out of
scope. So, the problem is what to do to limit the visibility to the
procedure.

Writable constants *are* the old fashion way, cause this kind of usage
stems from Turbo Pascal and allowed to restrict the visibility of
symbols.

Regards,
Sven


Except really old fashioned might mean Modula

That's a neat idea to create a new module, and use it sort of like a 
private object or static object just for the purpose of storing a global 
variable in the private implementation section.


One disadvantage of modules (units) is that they add extra bytes to the 
Exe, but is generally not an issue in desktop software. Previously when 
people have asked for static C type things in fpc they were working with 
embedded systems where every last byte counted and size of the program 
was an issue. But, I don't know the use case in this episode..

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

Re: [fpc-pascal] Food for thought - language string improvement

[noreply]

On 2017-07-08 08:29, Ched wrote:

Is this acceptable ?


'SELECT Customers.CustomerName, Orders.OrderID' +
'FROM Customers' +
'FULL OUTER JOIN Orders' +
'ON Customers.CustomerID = Orders.CustomerID' +
'ORDER BY Customers.CustomerName;'


I think that one have to insert space at some loactions:
'SELECT Customers.CustomerName, Orders.OrderID' +
' FROM Customers' +
' FULL OUTER JOIN Orders' +
' ON Customers.CustomerID = Orders.CustomerID' +
' ORDER BY Customers.CustomerName;';

Cheers, Ched



And if it is a multiline string, the compiler may have to convert 
carriage return/new line into a space for you, to allow it to take:


FROM Customers
FULL OUTER JOIN Orders

and convert the carriage return after "Customers" into a space for you..

otherwise it will be:

FROM CustomersFULL OUTER JOIN Orders

..concatenated without a space

Something to be concerned about if implementing it.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Super Large Integer Math Calculations

[noreply]

On 2017-07-07 17:08, Bart wrote:

On 7/7/17, nore...@z505.com  wrote:


For integers beyond 64 bit, or even beyond 32 bit on a 64 bit machine,
why can't the math be broken down into peices the way a human does it 
on

paper, and then theoretically any number can be added and subtracted,
even if it is beyond 32/64 bit?

Example:

type TSuperLargeInt = string;

var
   i, j: TSuperLargeInt;
   output: TSuperLargeInt;
begin
   i := '10009';
   j := '10001';
   output := AddLargeInts(i,j);
   writeln(output);
end.


http://svn.code.sf.net/p/flyingsheep/code/trunk/wtf/ncalc.pp does 
exactly that

(all dependenies are also found at
http://svn.code.sf.net/p/flyingsheep/code/trunk/wtf).

...


It's not lightning fast, but there is room for optimization I guess.

Bart


I knew someone had already invented this!
Any idea if it does square roots, and, decimal point numbers too..

Or, what math can it "not" do.. things like sin/tan/cos, or strange 
maths..


Probably a complex question requiring a complex answer

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

[fpc-pascal] Super Large Integer Math Calculations

[noreply]

For integers beyond 64 bit, or even beyond 32 bit on a 64 bit machine, 
why can't the math be broken down into peices the way a human does it on 
paper, and then theoretically any number can be added and subtracted, 
even if it is beyond 32/64 bit?


Example:

type TSuperLargeInt = string;

var
  i, j: TSuperLargeInt;
  output: TSuperLargeInt;
begin
  i := '10009';
  j := '10001';
  output := AddLargeInts(i,j);
  writeln(output);
end.

The function AddLargeInts simply breaks the math into peices and adds 9 
plus one, carries the one, then adds 1 plus 1, and writes the total as a 
string,, that the computer can output as a string, instead of an integer 
the cpu can handle directly. Strings allow concatenations of numbers to 
virtually any length (with the limit of the max string length, which is 
quite long) so when you use math to write numbers as strings, the number 
can be written any length you want.


And it doesn't have to be strings that are used, but some compiler magic 
that uses strings internally (concatenating numbers and writing 
numbers). Strings can be used as a prototype to prove the concept 
works... (I can provide a demo if needed).


Am I reinventing something that already exists somewhere in, the Math 
unit, or elsewhere, to have math operations on super large numbers 
beyond 32/64 bit?


This just covers addition/subtraction, which can be broken down into 
small pieces an int32 can easily handle (you are simply doing math from 
0-9 numbers, so its byte sized math!) - multiplication can likely be 
broken down into small pieces too but I haven't thought about it.


Surely someone has already thought of this and it exists somewhere?

To add the two large numbers above, simple write a function that:
 - adds the last number (9) and 1 in the string, and carries any 
remainder

 - adds the second last number, with the remainder, so result is 1
 - adds the third last...
 -  etc..
 - up until the first number (1)
 - write the output result as a concatenated/constructed string (not 
int32)


AFAICT any large number to ridiculous size limits can be added by 
breaking the math into small pieces that 32 bit numbers can handle (or 
rather byte sized numbers actually since you are doing 0-9 math 
addition).


This has got to be reinventing the wheel though: someone must have 
already invented this in Fortran or the math unit, or somewhere...?


And then the question becomes, what math cannot be done, by breaking 
down into small byte sized pieces.


Loops: not sure if these super large integers are any good in loops 
unless you loop an int32 around several times (compiler magic?).


The reason I use a simple case of adding 10009 with 
another number is for simple test case that doesn't require much 
thought.. obviously 9 plus 1 means 10, so you carry the 1. then the rest 
is easy since you skip all the zeros and add the first 1 and 1 = 2. But 
the point is, addition on paper by humans is broken down to 0-9 
additions, so why not a CPU can do this too? Then output the result as a 
concatenated string even if the cpu cannot hold this number directly 
since it is bigger than int32.


Possibly I may be reinventing this:
http://www.delphiforfun.org/Programs/Library/big_integers.htm
Quote "All operations are performed pretty much the way you would do 
them with pencil and paper."


And:
http://rvelthuis.de/programs/bigintegers.html

A compiler could have magic inside it, or a unit could use operator 
overloading, to make it more built in and not use strings, but some 
custom type (maybe implemented as a string underneath, or array of 
bytes). Surely fortran or a number crunching language must have thought 
of this already, or the freepascal Math unit, or some BigInteger unit 
out there already.


Interesting Turing test: can all math be done up until infinity, on an 
int32 computer, if you just implement compiler magic to work around your 
int32 limitation, and break it down to byte sized (or int32 sized) 
pieces...

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

Re: [fpc-pascal] Food for thought - language string improvement

[noreply]

On 2017-07-06 09:13, Graeme Geldenhuys wrote:

Ever had a problem like this?  You have some SQL, say:

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;


and you want to add that SQL to the SQL property of a query at
runtime. You end up either having to turn this into a string like
this:

'SELECT Customers.CustomerName, Orders.OrderID' +
'FROM Customers' +
'FULL OUTER JOIN Orders' +
'ON Customers.CustomerID = Orders.CustomerID' +
'ORDER BY Customers.CustomerName;'

or manually in each line like this (oh please NEVER do this!):

FDQuery1.SQL.Add('SELECT Customers.CustomerName, Orders.OrderID');
FDQuery1.SQL.Add('FROM Customers');
FDQuery1.SQL.Add('FULL OUTER JOIN Orders');
FDQuery1.SQL.Add('ON Customers.CustomerID = Orders.CustomerID');
FDQuery1.SQL.Add('ORDER BY Customers.CustomerName;');


Now this has normally not been much of a problem for me, because part
of tiOPF's support tools, there is a tool name tiSQLEditor  that does
bi-directional conversions for you - to and from quoted strings for
SQL. And even straight from/to the clipboard. This tool has been
around for 17+ years. But why must this be a tool problem or a IDE
problem? Why can't the Object Pascal language solve this for us!

[the following part quoted from a online discussion by somebody else -
I fully agree with his thoughts though]

Imagine if FPC had type inference and multi-line strings, neither very
exotic features. The code then becomes:

=
var query := '''SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;'''

FDQuery1.SQL.Add(query);
=


Easier to read, easier to edit, no need for a IDE wizard or external 
tools.


Language features like this is what increases productivity. But
unfortunately it seems we all rather rely on a specific tool or IDE to
improve our productivity - thus also locking us into using those tools
only.


Regards,
  Graeme


This multiline string issue also helps with HTML:

s := '' +
   '' +
   '' +
   '' +

Instead it should be a multiline string:

s := '''
  



'''

There is also the backquote character, as an option..
`some string
on multiple
lines`


GoLang has multiline strings that work pretty good. AFAIR php has them 
too, especially for html work - but that is likely because PHP is for 
web programming and needed that feature more than Pascal did, so the 
strong need caused them to implement it more than other langauges.

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

Re: [fpc-pascal] fpGUI on macOS

[noreply]

On 2017-06-09 02:35, Michael Van Canneyt wrote:

On Fri, 9 Jun 2017, Felipe Monteiro de Carvalho wrote:


On Fri, Jun 9, 2017 at 9:05 AM, Mattias Gaertner
 wrote:

So will lazarus be converting the IDE over to cocoa?


Probably.


Most stuff already works in Cocoa.

I haven't used LCL-Carbon for my personal projects in years, although
I still use it for the IDE.

You can use the IDE with Carbon for now (until Cocoa is good enough),
but for personal projects I recommend Cocoa, unless you are affected
by a missing functionality or something.


I don't know about others, but as a developer of end-user apps, these
paragraphs tell me 'stay away of cocoa'...


The risk is indeed that if you have an app that works fine in cocoa, 
then all of a sudden you discover that a new feature in your app will 
need a feature cocoa does not have yet in lazarus, you are stuck. So 
planning ahead of time is important, to see if the items you need are 
implemented, but sometimes planning ahead and guessing what components 
you will need, requires psychic power, or a time travel system into the 
future to see what you will need 2 years down the road.


For me, it's TScrollBox and TSplitter after looking in my crystal ball
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpGUI on macOS

[noreply]

On 2017-06-09 02:22, Felipe Monteiro de Carvalho wrote:

On Fri, Jun 9, 2017 at 9:05 AM, Mattias Gaertner
 wrote:

So will lazarus be converting the IDE over to cocoa?


Probably.


Most stuff already works in Cocoa.

I haven't used LCL-Carbon for my personal projects in years, although
I still use it for the IDE.

You can use the IDE with Carbon for now (until Cocoa is good enough),
but for personal projects I recommend Cocoa, unless you are affected
by a missing functionality or something.



I am affected already, and will be hiring a bounty on it (or human 
rather ;-) to get it working..


But a lot of basic stuff seems working according to the roadmap on the 
wiki

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

Re: [fpc-pascal] fpGUI on macOS

[noreply]

On 2017-06-07 10:45, Adriaan van Os wrote:

But as with everything Apple does (which is so G*d damn stupid), they 
keep on reducing functionality and removing >> all the useful features 
from the OS to dumb it down more and more - because all consumers are 
dumb asses right.

;-)


Fully agreed. Apple has become a fashion shop, where the lastest
winter of summer fashion collection deprecates all the crap they
released the seasson before. So that we all have to buy new gadgets
and rewrite all our software,



I'm concerned about Carbon being unusable in the future, and apps like 
Lazaurs are built on Carbon, right?

So will lazarus be converting the IDE over to cocoa?

It's possible carbon may stay around long enough, 5 years, 10 years, who 
knows - that it won't affect anything.


This maybe should be in fpc-other now, but, since it is lazarus/fpc 
related, I'll keep it here for now.

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

[fpc-pascal] fpGUI on macOS

[noreply]

What sort of macOS abilities does fpGUI have?

Is fpGUI mostly for linux/bsd/windows, and not as much macOS?

Does it require some work to get it working, or installations of stuff 
that macOS doesn't normally have installed?


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

Re: [fpc-pascal] named parameter

[noreply]

On 2017-05-27 01:17, Mr Bee via fpc-pascal wrote:

Hi,

As Pascal mostly well known as a safe, easy to read, and elegant
language, don't you think Pascal needs named parameter? I mean for ALL
kind of parameters, not just for Variants. When you have a function
with many parameters having default values, you know that named
parameter is desirable. For example:

function f(p1: string = ''; p2: integer = 0; p3: boolean = false);

But you only need to supply the third parameter, you still must supply
the first and second ones with appropriate default values, like this:

f('', 0, true);

while with named parameter, you can do this:

f(p3 := true);
;


You can do something similar already with source comments

SomeProc(true {p3})

or

SomeProc({p3} true);

But obviously the compiler doesn't check it.

Problem is it increases the verbosity of the code, and how would the 
compiler determine when to check these and when not to... If you check 
this all the time it makes the language much more verbose and tedious 
for small functions like inttostr that you use all the time.


IMO though it does improve readability in long functions with lots of 
parameters, like windows api style procedures that have 5 or more 
parameters and you can't figure out which param is which

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

Re: [fpc-pascal] OpenGL and SDL frustrations

[noreply]

On 2017-05-23 22:13, Ryan Joseph wrote:

I’ve wasted so much time on this I just need to stop and ask for help
already. Over the last few years I’ve been picking away at OpenGL and
only ever got the legacy 2.x API to work which has been fine for
making 2D games but I wanted to at least learn the modern API and
shaders.


Not sure what ZenGL uses for opengl version but why do you struggle to 
use opengl directly instead of using a wrapper like zengl that has 
already made the functions available for you...


The only problem with using a wrapper like zengl or andorra is that of 
course it could go stale and not be updated, I'm not even sure if it 
uses 2.x, I have forgotten.


[...]

if SDL_Init(SDL_INIT_VIDEO) < 0 then
Fatal('SDL could not initialize! '+SDL_GetError);

// load function pointers
if Load_GL_VERSION_3_3 = false then
Fatal('OpenGL is not loaded');

SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, 
SDL_GL_CONTEXT_PROFILE_CORE);

// NOTE: 4.0 doesn't work, GL_VERSION return null
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16);



All these calls look kind of tedious, instead of using a wrapper. But 
maybe you want to learn opengl at its heart and not use a wrapper.. and 
learn all the fine details the hard way (full respect for that).

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

Re: [fpc-pascal] Browser and exe

[noreply]

On 2017-05-25 08:14, Marcos Douglas B. Santos wrote:

On Wed, May 24, 2017 at 4:23 PM, Graeme Geldenhuys
 wrote:

2. How did you garantee that others applications aren't being using
the same port as your application to avoind conflicts?



I looked at the official IANA list of registered port numbers and 
chose a

port number that hasn't been taken yet.

   http://www.iana.org/assignments/port-numbers

Under FreeBSD you can review the /etc/services file. I believe Linux 
has

something similar. Or simply use the URL above.


Thanks for that link, I didn't know.
But I meant, how do you know if another app is already using a port
that you want to use?


This is the reason I think web servers are the wrong way to go for any 
desktop application (Golang is going crazy with everything being an http 
server). Because ensuring ports are open is a pain in the butt, plus all 
the firewall issues.
Chromium embedded/firefox embedded needs no ports open, But maybe it's 
not your need

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

Re: [fpc-pascal] Browser and exe

[noreply]

On 2017-05-23 20:52, Marcos Douglas B. Santos wrote:

On Tue, May 23, 2017 at 9:29 PM,   wrote:
Exe is a security hazard that could barf up a person's hard drive 
instantly

or create viruses..


I understand these security reasons and I agree, of course...
But this Exe that I am talking about should be installed for all
machines that want use the system so, won't be a problem for security.



Well there is always XUL Runner (Firefox embedded) or Chromium Embedded, 
to run a local browser on the computer machine that is just like 
chrome/firefox, but can communicate with real exe code.




I'm still thinking on these options:

1. NativeMessaging:
https://developer.chrome.com/extensions/nativeMessaging

2. to make an app that will be a local web server, after the user has 
installed.

The web real app could make requests to http//localhost and have a
communication between them.


Or a local chromium embedded/firefox embedded web browser that can talk 
to any native code you want, then the person does not need a web server 
running but will have to install the chromium embedded CEF dll's

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

Re: [fpc-pascal] Browser and exe

[noreply]

On 2017-05-22 21:53, Marcos Douglas B. Santos wrote:

Hi,

If you have some apps or components which was written in Object Pascal
and you would like to use them in Web applications (client-side,
previously installed) what is the best option to choose nowadays?

My users use Windows so, I thought in ActiveX. It works, but I think
Chrome do not use anymore, right?

Is there a way to call an Exe (previously installed, no problem with
that) to interact with an Exe, working in IE and Chrome?



Exe is a security hazard that could barf up a person's hard drive 
instantly or create viruses..


ActiveX is indeed the closest thing to it, as it is like a program that 
is run from the browser, but in some kind of sandbox that does not allow 
it to do too much damage, although someone probably found a security 
issue with it and wrote a virus maybe years ago..

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-18 19:54, Ryan Joseph wrote:
On May 18, 2017, at 10:40 PM, Jon Foster 
 wrote:


62.44  1.33 1.33 fpc_frac_real
26.76  1.90 0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
10.33  2.12 0.22 FPC_DIV_INT64


Thanks for profiling this.

Floor is there as I expected and 26% is pretty extreme but the others
are floating point division? How does Java handle this so much better
than FPC and what are the work arounds? Just curious. As it stands I
can only reason that I need to avoid dividing floats in FPC like the
plague.



Isn't java just a wrapper around C?

So could compare to C too, to see how it does it. But, I don't know 
anything about Java internals.

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-19 05:25, Graeme Geldenhuys wrote:

On 2017-05-19 06:58, Florian Klämpfl wrote:
Over the weekend I’ll verify by testing on both FreeBSD and Windows, 
and

then see if “calling conventions” make any difference.


*BSD is the same as Linux.


Good to know, thanks.


It has its purposes, but it is not suitable for the main repository of 
FPC.


It is not a technical thing but just a matter of mind. ;-)



What happens if you use the SVN bridge that allows you to run svn 
commands to a git server? does git suffer the same problems in this mode 
too?


https://help.github.com/articles/support-for-subversion-clients/

Local working copy issues Florian described would be an issue with this 
bridge, or not an issue?


I'm wondering because I use the bridge for some things, as sometimes I 
find svn simpler. But it may not solve the issues Florian describes

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-19 06:16, Graeme Geldenhuys wrote:

On 2017-05-18 16:33, Reimar Grabowski wrote:

and JS is clearly not faster than FPC.


The JavaScript version runs very smooth on my system. There is no
framerate counter though, so I don't know how much faster.

   http://jsdo.it/notch/dB1E

Again, what does that say about FPC generated binary performance.



I think javascript has been recently heavily improved since millions of 
people are using javascript and work was done to make it faster, whereas 
not so many millions of people use fpc.


Still this is all a good test case to find flaws/slow downs in fpc and 
fix them.


IMO this is like a bug report that's not really a bug, as the code may 
still be correct, just slow...


And IMO when someone finds an issue like this, a slow part of the RTL or 
the compiler, it is a good thing not a bad thing because now is a chance 
to find out where the issue is. Whereas if this had not been found or 
reported it would have gone unnoticed.


It might even be just 2 procedures somewhere that are extremely slow, 
but correct, in some unit..


Until someone profiles it... no one knows. Sorry, I'm not up to date on 
the latest findings of this thread if anyone profiled it or not.


Again if it is an rtl issue, the solution is to swap in a faster rtl 
unit or even a couple of procedures .. that are causing it to become 
slow. Or it could be some while loop in the rtl or a for loop. Or a 
concatenation that wasn't using a fast Copy(), or something that could 
have used a buffer, but did it one by one instead.


But reporting and finding the issue, imo, is a good thing... even if you 
currently find fpc binaries slow, at least you found something to fix! 
:-)

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-19 06:32, Graeme Geldenhuys wrote:

Bottom line is, with the exact same code, NO work-arounds is required
for GCC or Java! So why must we have work-arounds for FPC? It's a
compiler or RTL issue - not being able to understand the code good
enough to generate more efficient binaries.


Agree, but hopefully if it is an RTL issue you can just swap in a 
fastMath.pp unit or fast system.pp unit, or fast sysutils, or crt, or 
fastmm The whole advantage of a modular unit system is you can swap 
in replacements easily, then you verify that it really was an RTL issue 
and not a compiler issue. As an example, the graph unit is swapped in 
with ptc graph unit and look what happens? So then you decide to fix the 
graph unit and match it to ptc graph, or take another route and leave it 
as a more reliable unit but not as fast




And no, I don’t agree that this is a “special case”. It’s a g*d d*mn
game engine I tried to implement. If the FPC team wants to keep
thinking like that, then they should list in big bold letters (on the
Free Pascal homepage) what type of applications they deem fit for FPC,
and what type of applications you shouldn’t bother writing with FPC.



I think it was good for you to do the demo/test to find an issue in fpc 
that needs to be optimized. If you hadn't done this no one would have 
found this bug/slow code until a later time.


Same with the doom/quake ports. In mode delphi, the equivalent code did 
not run the same as Delphi 5/7, meaning that mode delphi had a bug that 
needed to be fixed... Without the quake/doom ports available to compile 
and try, those bugs/issues would have never been found. So not all 
wasted, IMO.


There were workarounds required to get the doom/quake code to work 
properly, which meant mode delphi must have had a bug, or fpc must have 
had an issue that made the graphics not render correctly and the menus 
to not function properly. The fixes were fairly small afair.



As I mentioned, I'll profile the application under both FreeBSD and
Windows over the weekend and post my finds. But as far as I'm
concerned, there is nothing wrong with the way the program has been
implemented. Time permitting, I might even try compiling it with
Delphi 7 to see what happens.


That's a good comparison
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Best way to check SimpleIPC for messages

[noreply]

On 2017-05-16 04:55, Michael Schnell wrote:

On 16.05.2017 07:30, Michael Van Canneyt wrote:


select is basically what peekmessage does.


AFAIK "select()" (and - more versatile -  "poll()"  ) in Linux uses
an appropriate system call to wait on one of multiple events (i.e.
devices, including e.g. pipes, which might be used by IPC). (Despite
the name) it does not do any "busy wait" ("polling"). So it's can be
used (instead of waiting in a blocking read)  in a worker-thread of an
"application". It's perfectly useful in an program without a message
queue provided by LCL or the mse-library.



But can it be used without threads at all without locking the app up
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-18 08:23, Graeme Geldenhuys wrote:

On 2017-05-18 13:42, Reimar Grabowski wrote:

The GPU also does clipping calculations
based on the viewpoint (camera position) in the 3D scene.

Camera position?
OpenGL has no concept of a camera.


Yes, yes, but you know what I mean. Camera, View Point, Player View
whatever. And yes I know there is no "real camera", its the scene that
moves in the opposite direction to the user input.



Why do you have to *calculate* *all*?


My original project was to implement a _software_ raycaster, so no
GPU, no OpenGL etc. Old old early 90's style programming.

This thread is getting a bit ridiculous - just like the Lazarus Forum
thread did. Bottom line is, the exact same code (identical, just the
language syntax that differed) produced acceptable results with GCC
and Java. It didn't with FPC. We all now know FPC doesn't do such a
great job at optimisation (I know the reasons why), and that the
graphics API's is also not to blame. So lets leave it at that.



No no you don't "leave" when you are trying to figure out a slow 
procedure that could be causing the problem, you stay here and find what 
is the bottlneck, then insert 3-234 lines of code to fix it so it's 
equal to the speed of x that you are comparing it to :-)


I just want to pinpoint why fpc is slow:
1.the math unit
2.nothing to do with the math unit
3.a wrapper around a graphics lib is slow, not the graphics lib itself 
just the wrapper in fpc

4. system.pp is slow
5. sysutils is slow
6.none of the above
7.magic (not an option. Leave thread..) ;-)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-18 07:42, Reimar Grabowski wrote:

Camera position?
OpenGL has no concept of a camera.


When I toyed around with Andorra3D it had some concept/code for a 
Camera, but he may have added it with his own code, not sure if he used 
built in directx/opengl code

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-17 02:57, mar...@stack.nl wrote:

In our previous episode, nore...@z505.com said:


i.e. if you end up using opengl, or its successor, why does it even
matter if FPC pure games without any libs are slow?


You still need to calculate all the vertices that you send to the 
graphics

card, even if the GPU renders then.



True so a test to confirm that the calculating functions/procedure are 
really the bottleneck, would need to be written, and compare it to the 
equivalent c++ program with the same calculations


It would just be silly to start optimizing the calculation functions 
without any evidence that those are the issue..


If it's fpc's internal functions such as sqrt() I wonder what those 
internal functions actually are. Right now they are just magic, pointing 
to a magic number, in my mind

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-17 00:14, nore...@z505.com wrote:

On 2017-05-16 09:10, Jon Foster wrote:


I think the key word in Graeme's complaint is "game". And I'm willing
to bet that most of his envisioned gaming scenarios deal with a lot of
floating point math and the more advanced math functions. A quick
glance over his example code and I'm willing to bet that the "math"
unit providing the sqrt(), cos(), sin() and others is the bottle neck.
But that's just a knee-jerk reaction. Seems to me I read a while back
that a ton of effort had not gone into them.



Could those math routines just be written in assembly with a FastXXX
unit? i.e. FastMM is a fast memory manager, so you could have a
FastCRT, fastWhatever, FastMath...


Doh!
Someone already thought of this

Quote: "FastMath is a Delphi math library that is optimized for fast 
performance (sometimes at the cost of not performing error checking or 
losing a little accuracy). It uses hand-optimized assembly code to 
achieve much better performance then the equivalent functions provided 
by the Delphi RTL."


Github:
https://github.com/neslib/FastMath

Whether it ports over to fpc, I don't know
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Best way to check SimpleIPC for messages

[noreply]

On 2017-05-17 00:54, Sven Barth via fpc-pascal wrote:

OnIdle() is called when there is no more event waiting in the
widgetset's event queue, basically meaning that the application has
nothing better to do anyway. It has nothing to do with CPU usage.



That makes sense.
And recursively what happens if you call an event, inside the onidle, 
...


Recursive nightmare, or not a problem?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Size of program vs library ?

[noreply]

On 2017-05-16 09:20, fredvs wrote:

Michael Van Canneyt wrote

On Tue, 16 May 2017, fredvs wrote:


Michael Van Canneyt wrote

What can be misunderstood about adding --gc-sections to the linker
options if -XX is used on the command-line ?


Ha, the way you present it seems to show that you did understand it 
;-)


OK, maybe is it time to add a feature request...


Before filing a request, you can already check yourself what happens 
with

form data if you compile a lazarus form into the library.

Michael.


Huh, with all the respect that I have for LCL, I was never able to 
compile a

Lazarus form into library


Hrm... I think way back I was able to compile a lcl form into a library, 
as a plugin for lazarusrb, but, had issues with showmessage requiring 
two mouse clicks instead of one click to close it, or some strange 
behaviors..


But it was such a long time ago that I forgot. Some strange message loop 
issues AFAIR

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-17 00:14, nore...@z505.com wrote:

On 2017-05-16 09:10, Jon Foster wrote:


I think the key word in Graeme's complaint is "game". And I'm willing
to bet that most of his envisioned gaming scenarios deal with a lot of
floating point math and the more advanced math functions. A quick
glance over his example code and I'm willing to bet that the "math"
unit providing the sqrt(), cos(), sin() and others is the bottle neck.
But that's just a knee-jerk reaction. Seems to me I read a while back
that a ton of effort had not gone into them.






Could those math routines just be written in assembly with a FastXXX
unit? i.e. FastMM is a fast memory manager, so you could have a
FastCRT, fastWhatever, FastMath...



Upon further inspection it seems fpc already uses internal functions
such as
fpc_in_sqrt_real

which are defined as integers that fpc references magically somehow 
internally..


So probably already fast, but I'd have to check further.

I don't know how internal functions work. Internal to the compiler 
source code, internal as in direct cpu calls that the cpu so gladly 
gives you?


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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-15 17:37, James Richters wrote:

I have managed to get ptcgraph and ptccrt to work with my program and
I can report that there is an AMAZING increase in graphics
performance!   It is pretty much a drop in replacement and I did not
change any compiler settings.  I did have to make a few minor changes
to get it to work, not enough to change the speed of anything.



So it can't be an fpc problem, but a unit module problem that someone 
didn't spend time optimizing which has little to do with fpc but more to 
do with the way the units were written?


Or is the ptcgraph/ptccrt in assembly code to avoid FPC mode objcfpc 
compilation and use assembly instead? Sorry I have not looked at it.. 
don't know.

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-16 09:10, Jon Foster wrote:


I think the key word in Graeme's complaint is "game". And I'm willing
to bet that most of his envisioned gaming scenarios deal with a lot of
floating point math and the more advanced math functions. A quick
glance over his example code and I'm willing to bet that the "math"
unit providing the sqrt(), cos(), sin() and others is the bottle neck.
But that's just a knee-jerk reaction. Seems to me I read a while back
that a ton of effort had not gone into them.



Could those math routines just be written in assembly with a FastXXX 
unit? i.e. FastMM is a fast memory manager, so you could have a FastCRT, 
fastWhatever, FastMath...


At one time the fpc system units or sysutils was written in a lot of 
assembly, then they changed it to more pascal so it was more readable 
for people like me who stay away from assembly :-)  Not because assembly 
is bad or anything, I just like living in high level procedural land, 
instead of low level assembly machine land.

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-15 17:27, Graeme Geldenhuys wrote:

On 2017-05-15 22:50, nore...@z505.com wrote:

Graeme will need to clarify whether he was trying to be harsh on FPC
entirely, or just specifically in some areas.. :-)


I'll try and clarify... I believe FPC generates slow (or slower than
Delphi, GCC and Java) code no matter what. The saving grace is that
you don't really notice it on normal event-based desktop applications.
Writing a game is a whole different story. Games are way more
sensitive to performance.

Now the game I wrote, was a desktop GUI application. It was slow under
Linux, FreeBSD and Windows. So the results were consistent, no matter
what GUI API was used Be that fpGUI (via GDI), fpGUI (via X11) or
LCL-GTK2. In all cases, game rendering was to a memory image, then
once done, that memory image was bitblit to the Window Canvas.

The Java and GCC versions did the same, but were faster.

That's all I can say about. Make your own assumptions - read into it
any conspiracy theories or what-not. ;-) At this point I don't really
care, as I already moved on with that project, using OpenGL instead
(both for Java and Object Pascal).



But any game ends up using opengl anyway, doesnt' it? Sorry I'm not a 
big game programmer. Want to be, some day.


i.e. if you end up using opengl, or its successor, why does it even 
matter if FPC pure games without any libs are slow?


AFAIR the doom and quake ports ran pretty fast, but I'm not sure, as I 
didn't play them much. Can't remember.

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

Re: [fpc-pascal] Size of program vs library ?

[noreply]

On 2017-05-16 03:15, fredvs wrote:

noreply wrote

On 2017-05-15 04:26, fredvs wrote:

After lot of fight, there is a solution: using -*-gc-sections*.

And the question was :

/Why FPC does not provide --gc-sections to the linker with the -XX
paramer
for libraries ? (Bug ?) /



Hopefully that's all there is to it, but how do you know that this
doesn't just work for your current code and is not reliable for all
situations?

If that's all there is too it, that's cool! But maybe fpc left it out
for a reason: like it only works in some test cases of libraries, but
not all test cases?
___
fpc-pascal maillist  -



fpc-pascal@.freepascal



http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


It works for all situations, so I propose that fpc add --gc-sections as
parameter for the linker if the user has used -XX parameter to compile 
a

library.

Fre;D


Okay hold on. All situations.
Either you are a serious Edsgar Dijkstra fan, and you have proven it to 
be correct (unlikely) or you have all the test cases of the entire 
universe and are a unit testing nutcase..
All the chess board peices and positions on the game board have all been 
tested in all situations...

No..

But, seriously... if it works in many many many situations I guess that 
is "good enough"

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

Re: [fpc-pascal] Best way to check SimpleIPC for messages

[noreply]

On 2017-05-12 09:37, Michael Van Canneyt wrote:
Obviously "avoid threads where possible" but only if there is a 
simpler mechanism not reinventing a thread. So it seems to me onidle 
in fpgui is a simpler way than creating a new separate thread 
yourself, but how to do it in a program that has no fpgui onidle?


Check manually. What else is left ? There is no message queue, so no
loop in which to check at regular basis.



What's left is possibly something like apache 1.3 source code which 
somehow, AFAIR avoids using threads by using some other obscure strange 
thing, which I have forgotten. Possibly something like old dos programs 
used (sorry, not a Dos programmer, don't know.. not old enough).


Quote from some slashdot comment:
"There is an Apache2 mpm, called "prefork", which isn't threaded and 
basically makes Apache2 look like Apache1. But hey, we have a very good 
server already that looks like Apache1."


Some people have magically figured out how to avoid threads using 
possibly bizarre techniques..


Quote " It handles requests in a manner similar to Apache 1.3. It is 
appropriate for sites that need to avoid threading for compatibility 
with non-thread-safe libraries. It is also the best MPM for isolating 
each request, so that a problem with a single request will not affect 
any other."


I looked into the apache 1.3 sources before to figure out what they 
used, but long forgotten now.

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-15 01:02, Sven Barth via fpc-pascal wrote:

Wow, Graeme! That's harsh. One of the last set of benchmarks I did
that focused on integer math and procedure call speed came out as
follows:



I think he specifically meant graphics apps, not general apps


While a raytracer is indeed a graphics app it's mainly about CPU
computation in this case and not interfacing with the GPU like OpenGL
does (of course one can write a raytracer to take advantage of the
parallel architecture of a GPU, but that's bot the case in this
specific example).




Graeme will need to clarify whether he was trying to be harsh on FPC 
entirely, or just specifically in some areas.. :-)


But Nikolay Nikolov's replacement unit should tell if fpc is as fast as 
turbopascal, as he claims it is a direct replacement and is super 
fast Then it's not fpc's fault but some problem in the default unit 
that was not optimized?  I don't know, never tried Nikolay's unit. But 
that also depends on whether Graeme was using that code from that unit 
too.


Any claims that something is slow depends entirely on 1 million 
parameters...
Then there are even those projects out there like FastMM but that's 
probably another aside unrelated

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

Re: [fpc-pascal] Size of program vs library ?

[noreply]

On 2017-05-15 04:26, fredvs wrote:

After lot of fight, there is a solution: using -*-gc-sections*.

And the question was :

/Why FPC does not provide --gc-sections to the linker with the -XX 
paramer

for libraries ? (Bug ?) /



Hopefully that's all there is to it, but how do you know that this 
doesn't just work for your current code and is not reliable for all 
situations?


If that's all there is too it, that's cool! But maybe fpc left it out 
for a reason: like it only works in some test cases of libraries, but 
not all test cases?

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

Re: [fpc-pascal] Size of program vs library ?

[noreply]

On 2017-05-15 04:19, Michael Van Canneyt wrote:

If you want to compare today, you need to add the sizes of all the C
libraries that are loaded during execution of a C program with the
size of an FPC program.

I think you'll find that the sizes of FPC programs are not so different 
then.


Just check the size of libc:

ls /lib/x86_64-linux-gnu/libc-2.19.so -l



But if FPC also uses libc, in units like unix/linux/other .pp units, 
that means FPC is using C libs too..


This also was a claim made by Golang that it doesn't use C code so you 
are comparing apples to Women, but in fact, the women eat apples and 
oranges and See (C) too.

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-11 18:57, Jon Foster wrote:

On 05/11/2017 02:48 PM, Graeme Geldenhuys wrote:

On 2017-05-11 19:43, James Richters wrote:

Any Suggestions?


Speed:
  In recent graphics work I've done, I've noticed that FPC is 
fantastic

  at created cross-platform applications. But the generated binaries
  are NOT fast at all - no matter how many compiler parameters and
  artificial speed optimisations we tried to implement. Sloppy Java
  code ended up 3x faster than the best I could get out of FPC
  generated binaries.

  I'm not saying this is your performance problem (especially 
comparing

  a 3Ghs PC vs a 233Mhz PC) - there certainly seems to be another
  problem contributing to your speed issue.

Wow, Graeme! That's harsh. One of the last set of benchmarks I did
that focused on integer math and procedure call speed came out as
follows:


I think he specifically meant graphics apps, not general apps

But I'm not sure
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-11 16:48, Graeme Geldenhuys wrote:

On 2017-05-11 19:43, James Richters wrote:

Any Suggestions?


Speed:
  In recent graphics work I've done, I've noticed that FPC is fantastic
  at created cross-platform applications. But the generated binaries
  are NOT fast at all - no matter how many compiler parameters and
  artificial speed optimisations we tried to implement. Sloppy Java
  code ended up 3x faster than the best I could get out of FPC
  generated binaries.


What about things like opengl, i.e. ZenGL?

Or you use something else for graphics?

Since opengl are just wrappers around librarie that call c code, it 
shouldn't be slow and should be the same speed as any C++ wrapper other 
than the wrapper itself having bottlenecks?


But depends what you mean by graphics I guess.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Best way to check SimpleIPC for messages

[noreply]

Is the best general way to check IPC messages in SimpleIPC to spawn a 
thread? and check


I noticed in fpgui sample apps that use simpleipc, graemeg checks the 
messages in the fpgui OnIdle event, AFAICT, not a separate thread. But 
what if you are running a console mode program that has no onidle event?


Obviously "avoid threads where possible" but only if there is a simpler 
mechanism not reinventing a thread. So it seems to me onidle in fpgui is 
a simpler way than creating a new separate thread yourself, but how to 
do it in a program that has no fpgui onidle?


On that note what would a lazarus app generally do to check for 
messages, without locking the app up? A similar OnIdle solution?


Making some progress on the SimpleIPC DLL for any programming language, 
but trying to figure out whether the end user of the dll should create 
his own thread to check for ipc messages, or have the dll do it for him 
to simplify, then fire a callback when message received.

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

Re: [fpc-pascal] SimpleIPC examples in docs

[noreply]

On 2017-05-08 03:27, Graeme Geldenhuys wrote:

In the fpGUI repository there are a few examples of SimpleIPC
usage. The examples/apps/nanoedit/ uses it.


That is Cool! Might fork this project on github and create NanoPlug with 
a small plugin system.  Had a NotePlug prototype years ago that I never 
really released, using KOL/MCK but yours would be cross platform.


But once again. A.d.d./a.d.h.d.

When I get time
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] SimpleIPC examples in docs

[noreply]

On 2017-05-08 03:40, Graeme Geldenhuys wrote:

On 2017-05-08 06:17, nore...@z505.com wrote:

Or there
could already be an examples feature in the docs that I don't know
about.



fpdoc already supports "Examples" for some years now - I use it very 
often

in fpGUI and tiOPF's class documentation.


Indeed, it supports examples underneath other content, but I meant an 
examples index page...


If I wasn't working on SimpleIPC DLL right now I might just send a patch 
to index examples for fpdoc, but that would be classified according to 
my own professional psychiatry opinion as A.D.D. or A.D.H.D




A index of all help topics that contain examples would be a useful 
addition
to fpdoc output. On the other hand (just tested), if you use fpGUI's 
DocView
and INF help files (generated by fpdoc and compiled with WIPFC), then 
you
can do a search for "Example" and that will list all help topics with 
the

Example heading.



More reason for me to check out fpGUI once again

Or I could see my if my own Lufdoc search utility could be modified to 
search for examples..but the docs are older copy on my server right now, 
so would only be pointing to fpc docs many years old


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

Re: [fpc-pascal] SimpleIPC examples in docs

[noreply]

On 2017-05-08 03:27, Graeme Geldenhuys wrote:

On 2017-05-08 06:17, nore...@z505.com wrote:

Can't seem to find them in the current docs.


In the fpGUI repository there are a few examples of SimpleIPC
usage. The examples/apps/nanoedit/ uses it. The 
examples/apps/debugserver/

uses it. I think the examples/apps/ide/ also uses it. All non-LCL
by the way. ;-)



Also found one in this folder of my lazarus installation (1.6.4):
fpc\3.0.2\source\packages\fcl-process\examples\

there are three programs in that directory that relate to IPC

simpleipcserver.lpr
ipcserver.pp
ipcclient.pp

Trying to figure out what I do with them to send a message and 
communicate between the two antisocial programs

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

[fpc-pascal] SimpleIPC examples in docs

[noreply]

I thought I remember some simpleipc examples in the documentation a 
while ago (years ago)..


Can't seem to find them in the current docs.

Were they moved elsewhere or did I miss finding them?

For what I need I will probably not be  using any lazarus components, 
but rather ipc without LCL involved. There are indeed lazarus examples 
kicking around.


The fpc documentation has:

[Overview][Resource 
strings][Constants][Types][Classes][Variables][Index]


Maybe an [Examples] would be a handy link, but some examples are hidden 
away in specific pages. Could index all the examples I suppose, with 
fpdoc tool, but not sure if that would be useful to people. Or there 
could already be an examples feature in the docs that I don't know 
about.

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

[fpc-pascal] simpleIPC strings

[noreply]

With simpleipc you can send a string.

I am wondering what type of string is safe to send?

i.e. what happens with utf8 or unicode?

Is it meant to send a regular string (like a pointer to char) and not 
more complex strings? Both?


Because if a string is being sent across two different separate 
processes (exe's) and possibly in different programming languages (when 
I make simpleipc DLL) it will be handy to know what exact type of string 
this communication is meant for: english characters, unicode,  utf8, all 
of the above.

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

Re: [fpc-pascal] Threading vs Parallelism ?

[noreply]

On 2017-05-05 14:27, Brian wrote:

Affinity

If a thread is dedicated to say , polling a serial or Ethernet port 
which
has a high input data rate , then dedicating one CPU to that 
task/thread is

useful.



Isn't the speed of serial (so slow) that it would be overkill to 
dedicate a Cpu to it?


Maybe usb 2 or 3, or possibly Gigabyte ethernet 1000 speed ;-)

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

Re: [fpc-pascal] machine readable grammar of object pascal?

[noreply]

On 2017-05-03 06:49, Peter wrote:

On 03/05/17 00:53, Marc Santhoff wrote:

Hi,

for playing around I would need a grammar of Object Pascal. I do not
care for which tool it is written or at best if it is plain EBNF.

Does such grammar exist?

TIA,
Marc




I found grammar for Delphi once.
Trying to attach it.




Which version? Delphi 5? 4? 7?

There is really no such thing as "delphi" language since there are more 
than 10 versions of it ;-)


But to find even a subset, would be handy.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Record operator for assignment

[noreply]

On 2017-04-28 01:01, Ryan Joseph wrote:
On Apr 28, 2017, at 12:43 PM, Sven Barth via fpc-pascal 
 wrote:


It would introduce an ambiguity as "(x" could also complete to other 
expressions (e.g. "(x + y) * 2" or even merely "(x)"). Especially 
older Pascal compilers were geared towards the simplicity of the 
language and thus they didn't add it. For FPC it simply never came up.


I never thought about it either until I saw some c++ code doing it.
Despite having overlooked it, it’s basically a built in record
constructor that’s been in the language since forever.


You can also look into GoLang for struct ideas, as golang is simpler 
than C++



rec := (x: (x + y) * 2; y: 0; z: 0);

Why can’t everything between : and ; just be treated like a normal
assignment? “x” is already defined but it’s just a label and not part
of the assignment.



It's always easier said than done, to say "Why can't" and then have to 
write the actual parser code to do it ;-)


I think fpc is based on wirth's simplicity, and even wirth's languages 
probably did not have the ability to setup a record initially with 
default record as another poster said. I do like this feature a lot , 
but can see why a minimalist like worth would avoid it.


It's similar to this feature:

x,y,z := 1, 12, 7

It's neat to be able to assign multiple variables on a single line. But 
necessary? mandatory?
Again, could look into golang for ideas.. may have something like it 
too, without becoming a large C++ mammoth.


In fact that's how golang's error checking works.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] simpleIPC for all programming languages ?

[noreply]

I was thinking, that I need a way to use IPC (inter process 
communication) in all languages, so for example I could compile a plain 
C exe, Delphi exe, Rust exe, Nimrod exe, or GoLang exe and communicate 
back with fpc (very powerful idea). But simpleIPC is only available for 
FPC/lazarus, not other tools, so really it's only good for fpc to fpc 
communication. But the whole point of IPC is that it's general purpose 
for any exe/elf.


So rather than rewrite simpleIPC in every language out there, (big waste 
of time), why not just load SimpleIPC.dll where the fpc compiled dll 
contains simpleipc functions? Any programming language that can load a 
DLL (virtually all languages these days) can now use simpleIPC. Each 
program that wants to use ipc, simply loads the simple ipc dll written 
in fpc.


So this way delphi could communicate with fpc/lazarus programs, golang 
could communicate, nimrod, rust, c, c++, etc.


Then I would create a simpleIPC website advertising this idea, as an 
alternative to say ZeroMQ.


Then some small questions arise: is it possible to statically link fpc 
code into other programs rather than it being a DLL? for example .a 
files instead of a dll at runtime? Then theoretically, IPC could be 
linked in statically, not just as a dll.


Indeed the dll functions will need to be flattened out (non object 
oriented) so all languages can use IPC, but that's not a problem for me 
- simply I write some wrappers around SimpleIPC objects and make them 
plain C/pascal like procedures, which is not so hard.


I have forgotten if fpc can generate .a files to statically link? I know 
it can link in AFAIK .a static files, for example sqlite? But the other 
way around: fpc generating static .a files?  This is not mandatory for 
this idea to work, just would be interesting to know, as an alternative 
to a run time loaded IPC dll.

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

Re: [fpc-pascal] Translation C to Pascal

[noreply]

On 2017-05-02 18:49, Marc Santhoff wrote:

On Di, 2017-05-02 at 08:33 -0700, fredvs wrote:

Hello.

The best (IMHO) is c2pas32 --> 
http://www.astonshell.com/freeware/c2pas32/


Nice program, i fed the adc.c source from STMs fwlib for stm32f4 
through
and the generated code looks fine. There is some guessing on type 
casts,

but I hope those can be cleared using simple scripting or the like.


There was also a mailing list thread about this a few weeks/months ago, 
where I was discussing the idea with a few other people on the list.


Another idea is to link in C source as .a files into your fpc program? 
If you want to write wrappers around the C code and use the C code 
directly as .a files from gcc generated...


But depends.. what you need.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] machine readable grammar of object pascal?

[noreply]

On 2017-05-03 04:37, Michael Van Canneyt wrote:

On Wed, 3 May 2017, denisgolovan wrote:


On 2017-05-03 00:53, Marc Santhoff wrote:

 Does such grammar exist?


Well, it depends on what you are trying to solve.
If you want to parse Pascal using FPC - that's one way. If you want to 
get some king of AST using any available [command-line] tools - that's 
another one.


Talking about latter - I would take LPEG (Lua+PEG) and create a parser 
myself. It comes quite simple and intuitive (contrary to 
LL,LR,LALR,...).

Most of Object Pascal is done right (minus sets/open arrays),


Add generics to the 'minus' list.


Does it take into account little bizarre things like writable consts 
(assignable consts)


like

const
  i: integer = 0;

which is like a variable, but called a const ;-)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] machine readable grammar of object pascal?

[noreply]

On 2017-05-02 18:53, Marc Santhoff wrote:

Hi,

for playing around I would need a grammar of Object Pascal. I do not
care for which tool it is written or at best if it is plain EBNF.

Does such grammar exist?



The issue is that there is no object pascal, or in other words, there's 
about 5 million different versions of it.

Delphi 5 is different than delphi 6, 7, 8, as things keep changing...

It's not like Plain C which stays mostly the same.

So in order to get a grammar, you'd need to only include a subset of 
object pascal in a certain version.


Delphi 5 compatibility would be a good candidate (subset)... as it is a 
fairly small language or subset (well, no, actually it's Big like Ada..) 
but would not include generics and all the other features of object 
pascal.


This is one of the biggest issues object pascal faces is that it is not 
very standard and keeps changing, but C++ is very similar to this, 
despite supposed standards existing

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

Re: [fpc-pascal] Vehicle management

[noreply]

On 2017-05-07 13:33, Mark Morgan Lloyd wrote:

Has anybody used FPC to talk to a vehicle via the OBD connector?

Can anybody give me a quick summary of the position of FPC on Android
etc.? (Graeme, that includes FPCgui if it's relevant).

We've been caught short by a vehicle problem that appears to be only
fixable by a VB.NET program. However it's GPLed and we're trying to
lean on the (reluctant) author for the source, it would be a natural
to transcribe to e.g. a tablet or possibly a bratphone.



I was looking in to this idea too. The only sources I found was some 
plain C or some kind of C code on sourceforge, which could (painfully) 
be converted or at least derived from to get ideas for FPC.


The downside is that this did not work on a windows Tablet, it has some 
GUI issues that doesn't work right on a tablet, but works fine on a 
desktop pc.


Can't remember the name of the software and don't remember what 
platforms it ran on.. maybe could find it by going to

https://www.google.ca/search?q=obd+sourceforge

But there is also github... But as for FPC code or lazarus code? I have 
no idea. Would be interesting to know.


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

Re: [fpc-pascal] WebAssembly Target

[noreply]

On 2017-03-17 09:57, Reimar Grabowski wrote:

On Thu, 16 Mar 2017 11:14:17 +
Graeme Geldenhuys  wrote:


And I am pleasantly surprised! :)  That demo worked perfectly on my
system. Sound, animation, graphics all silky smooth. Impressive 
indeed.


If running a 3 year old iOS Demo in a browser when we have seen Unreal
Tournament 3 being playable there 4 years ago is impressive is
debatable.
For me the impressive thing is that FireFox with WebAssembly manages
to show the same performance as Chrome without it. Having them run
side by side both fullscreen I can see no performance difference at
all.
Perhaps the JS side is doing so little that it hardly matters (as it
should be, when doing WebGL you want to do as much on the GPU as
possible).
First benchmarks indicate that there isn't much of a performance
increase with the current WebAssembly implementation over pure JS
anyway.
The benefit is that you can 'run C code' in the browser and that's 
currently it.

Having a WebAssembly target for FPC would surely be nice (more
options) but hardly a game changer currently.
In my little experience with WebGL the JS performance was never that
big of a problem but getting lots of data into the browser without the
transfer being super slow or the browser consuming alot more memory
than it should.



Why run webgl through javascript if you could just make something like a 
flash plugin object (like youtube videos) that plays opengl scenes using 
some native format similar to how flash uses SWF files, or whatever?


I think there was some opengl plugin object, but can't remember...

It seems like almost the web browser is trying to become Emacs, 
everything and the kitchen sink, though...


If it includes opengl or webgl, and video players, and.. everything 
under the sun.. it makes me wonder whether we should really not be going 
back to exe's again... I.e. if you want to download a opengl 
application, you just download an exe/elf program instead of running it 
in the web browser ;-)


Still, web browser (abuse syndrome) apps are cool.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Hash List

[noreply]

On 2017-03-17 19:06, Giuliano Colla wrote:

Il 18/03/2017 00:29, African Wild Dog ha scritto:


Ia there any hash list implementation in free Pascal?

The IniFiles unit (fpc/packages/fcl-base/src/inifiles.pp) provides a
THashedStringList (descendant from TstringList) which I'm using
reliably since many years.


If it is not specific to INI files and can be used generally for many 
things, maybe it should be pulled out into some other unit so people do 
not think it is just INI file related?


Also, ini files are file based, so could it be used without using files 
on the disk and used as a in memory list only?
Any time someone sees "ini file" they think "files on the hard drive", 
and could be turned off using this, when in fact it could be just what 
they need.

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

Re: [fpc-pascal] Array clearing

[noreply]

On 2017-04-01 02:39, Sven Barth via fpc-pascal wrote:

Am 01.04.2017 05:42 schrieb "Ryan Joseph"
:


As far as the compiler is concerned what’s the difference between

clearing an array using a for-loop vs. FillChar? It seems like
iterating the array would be slower but what does FillChar do exactly
and is it faster? The primary concern here is that the memory
originally allocated (using SetLength right?) remains in the same
location.


var
  list: array of integer;

SetLength(list, 10);

for i := 0 to high(list) do
  list[i] := 0;

FillChar(list[0], Length(list) * sizeof(integer), 0);


It totally depends on the type. In case of primitive types like
integers there is indeed only the performance difference (though if
you know that the element size is four FillDWord could be even faster,
depending on the implementation in the RTL).
If you have managed types however or class instances the result of the
FillChar (or equivalent) would be memory leaks.

Plase also note that after a SetLength the new elements are already 0
(or equivalent).


Since fillchar is not a general way to clear an item it almost seems 
like pascal needs a way to clear things generically, such as Array.clear
But I guess this would be reinventing OOP, or Ruby where everything is 
an object and can have .Something tacked on to it.


I've never been a fan of things like fillchar as it seems like a 
reinvention of something more like Clear() and mistakes can easily be 
made when you use complex function like this:


fillchar(something, something * something, 0)

instead of a more simpler:

Array.Clear
or
Clear(array)

You could, put the array inside a class/object I suppose and make a 
clear method... or use an old pascal object with a clear method on the 
stack so no free/create is required.


All this seems to be maybe either reinventing GoLang or Ruby though, or 
possibly python.


To me, fillchar doesn't actually say anything sensible about what the 
code is doing... "Clear" or "Default" (I think delphi is implementing 
something like this in later versions) says exactly what the code is 
doing. FillChar is some obscure old 1970's/80's pascal function that 
really doesn't tell what you are doing, unless you are an old pascal 
programmer who knows it from long ago. I'm skeptical of these old ways 
of doing things.. Imagine a newcomer to pascal who did not program in 
the 1980's... He sees "fillchar" in the program... Does that code even 
tell this learner of pascal what is happening? What's a "char" have to 
do with an array that may not have anything to do with chars?


Just my opinion and, possibly rant. Apologies.  Rant not directed at 
anyone in particular, just I'm skeptical of this whole fillchar thing... 
Even though I use it myself. Usually in a clear() wrapper of my own, to 
make the code more clear... Or a setdefault() or default() like function

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

Re: [fpc-pascal] TSQLQuery and buffering.

[noreply]

On 2017-03-24 14:42, Gary Doades wrote:

Hi everyone,

Firstly, I realise this is an old subject, but I still can't find any
easy answer.

Really, the question is simple: Is there ANY way of TSQLQuery NOT
reading the entire result set into memory?


What about making multiple queries and setting sql's LIMIT?

Should you really be writing sql queries that return millions of 
results?

Is this a design choice that could be a bad one?

For example in many web programs, I only retrieve 10-100 results back by 
using SQL's LIMIT feature...


Example:
SELECT * FROM Orders LIMIT 15, 10

SQLDB likely has a similar setting/feature so that you don't have to 
write actual SQL code to achieve it.


And in your case, you may actually really need to retrieve millions of 
results of the database, I don't know your use case. But generally in my 
web programs where I have millions of results, I use SQL to my advantage 
and it's language features, such as LIMIT, instead of retrieving all of 
the results at once which kind of defeats the purpose of an sql database 
since it's job is to give you only the data you need. Are you using 
pascal to do the work that the database could already do for you?


I could be misunderstanding your situation, and again your use case 
could be different.




This is really killing me. I've got quite a lot of web code using
sqldb and it works really well. The classes for connection,
transaction, query etc. are perfect for general use and make it so
easy to write database applications. I find it excellent that I only
need to change the connection class in my code to use a different
database.

For web code (mine included), fetching a few dozen, hundred or even a
few thousand rows is no real problem. The sqldb classes are *VERY*
fast and very easy to use.

The problem comes when I need to write some apps to either analyse or
move a lot of data. Initially all I need to do is analyse some data by
simply reading through rows, doing some calculations and other
analysis. For even 1 million rows this is very fast (10 seconds using
MySQL) so no major problems. However, it does use quite a lot of
memory.



If you need a temporary work around simply use SQL Limit feature.. then 
your data that comes back into your memory on your end is only what you 
have limited the result set to... If you need to combine all this data 
into one big data set to do analysis though, maybe sql LIMIT is the 
wrong tool for the job, I don't know.


But it's a big warning sign if you have a program that retrieves 
millions of results from a database and you only need to display 10 of 
those items to the end user - in that case LIMIT is really useful. But, 
you are analyzing these millions of results maybe monolithically so your 
case may be different.

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

Re: [fpc-pascal] Threading vs Parallelism ?

[noreply]

On 2017-03-30 11:29, Jon Foster wrote:

On 03/29/2017 01:15 PM, Michael Van Canneyt wrote:



On Wed, 29 Mar 2017, Dimitrios Chr. Ioannidis via fpc-pascal wrote:


Hi,

On 29/3/2017 9:57 μμ, fredvs wrote:

Hello.

Some developers treat me as dinosaur because I use threads in place 
of

doing

parallelism.

Huh, ok, but why parallelism is better and how to do it with fpc ?


  a nice article I've found long ago when I was researching the same 
topic "Threading/Concurrency vs. Parallelism" is the following :


http://tutorials.jenkov.com/java-concurrency/concurrency-vs-parallelism.html 
 and I tried the multithreadprocslaz package in Lazarus :


http://wiki.freepascal.org/Parallel_procedures


Showing nicely that parallelism in a single process implies threads.
I would not pay too much attention to what these developers are 
saying.




Either I'm dense, which is entirely possible, or the author of that
article didn't do a good job of making his point, even assuming he had
one.

Thinking about this a bit more I would say that "threads" are a means
(vehicle) to achieve parallelism. I think that in the majority of
programming contexts they are synonymous. But I can think of other
contexts where they may not be: Say animating a film. You have 1000
computers generating frames to be assembled into a final sequence. The
process of dispatching each frame render is most likely not going to
be done with the OSes thread call, but through a networked work queue
of some sort (ala Torque or something). So you have the "task"
(rendering the movie) being worked on in "parallel" via a networked
job dispatch mechanism.



Or modify the film format...

Example: create a 10 hour video that is composed of 100 files.

You have 100 computers, or 100 threads, or, 100 processes..Each computer 
creates 1 file.

The video is composed of 100 files but is really just a single video.

You open up VLC to play the video, and it opens 100 files, but the end 
user just opens a single file that links to each of these 100 files.


This could be the stupidest ridiculous parallel video creation technique 
ever. I'm not sure...

Or it could be an idea...




Or the case of using "make -j ..." which "forks" multiple jobs
(compile, link, ...) in parallel based on a dependency tree.

I say threading is parallelism, even if just one form of it. The other
methods of parallelism I mentioned here could also be done in FPC with
the appropriate code.


What about the difference between parallelism vs concurrency?

Rob Pike has some videos on it and meetup events discussing it on 
youtube.

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

Re: [fpc-pascal] sqldb create/free lifetime of object

[noreply]

On 2017-04-12 05:03, LacaK wrote:

Yes, example should be adjusted. Please report bug to not forget.
Thanks
-Laco.



It is not a bug, I just wanted to clarify the magic going on behind the 
scenes - which, is "ownership".


That's all I needed to know.

The key to seeing this trick/magic is in the Create function where you 
pass in the C (connection) as the owner.


But on my cell phone I didn't really see this, and, it's not always 
obvious.. hence my gripe.


In a way, this is a form of garbage collection or RAII sort of. And 
reduces the obnoxious free's required in non garbage collected 
programming languages... So it's a nice feature/trick to have ownership. 
But at the same time you can think there is a memory leak since there is 
no create/free pair easily visible...


So you train your eyes to look for ownership.

And similarly, delphi gui widgets you throw onto a form, don't need to 
be freed yourself, even though the program created them - so in a way 
delphi TForm's gui widgets are also garbage collected, sort of. Again a 
nice feature/trick to avoid all the obnoxious free calls that bloat up 
the source code with line noise.

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

Re: [fpc-pascal] WebAssembly Target

[noreply]

On 2017-03-16 08:35, Mattias Gaertner wrote:

On Thu, 16 Mar 2017 14:07:51 +0100 (CET)
"Karoly Balogh (Charlie/SGR)"  wrote:


[...]
Also, WebAssembly is a descendant of asm.js,


Maybe historically. Technically asm.js is higher lvl than webassembly.



which was basically striped
down Javascript with some integer/pointer type tagging. As far as I 
know,
the main problem with JS from a computing point of view, that it 
handles

all numbers as floats for "simplicity", but with some code in other
languages, this can have real side effects (for example some integers
cannot be exactly expressed as floats,


JS uses Double, which can express integers correctly from
-$10 to $f.
That should be enough for most browser programs, don't you think?



Well I used to think 32 bit integers were good enough for everyone, but 
now I wish that all our integers went on to infinity, as some clever 
person probably wants to create some program you never dreamed of that 
will hit the integer limit...


But for dumb things like web stores, blogs... Yes.

For some physics simulation that is a massive number cruncher "no 
integer is ever big enough"...


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

Re: [fpc-pascal] Annual inform

[noreply]

On 2017-03-08 05:34, Rafael Angel Campos Vargas wrote:

Annual inform:

I am programming LibreN3D for 3D animations, and some other projects
in FreeDOS and other systems,
but these three past years they really were standing by.


Why DOS..

for nostalgia?

i.e. compared to opengl on a modern Windblows/Loonix/BerkleyScreeOfDeath 
system?


FreeDOS probably runs on extremely low resources (old systems)...

So why DOS? performance? Simple nostalgia of the old Dos days?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Management Operators

[noreply]

On 2017-02-28 14:48, Jonas Maebe wrote:

On 28/02/17 21:40, nore...@z505.com wrote:

What happens with a stack allocated record?
(no new() required, nor dispose() so is the record ever
initialized/finalized?)


Yes, just like records that contain e.g. an ansistring field.


Jonas



do records which contain ansistring fields have some special stack 
initialization system (sorry, I should really read the source code in 
this case - still interested in theory of how this works)

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

Re: [fpc-pascal] Feature announcement: Management Operators

[noreply]

On 2017-02-28 14:50, Graeme Geldenhuys wrote:

On 2017-02-28 20:40, nore...@z505.com wrote:
Sorry, I've been out of touch with what's happening with Records 
lately

in modern pascal/delphi/etc.


Don't worry, I'm with you on that one. All I know is that
Borland/CodeGear/EMBT broken TP Objects somewhere in Delphi. Then they
decided they want that functionality back, so instead of fixing TP
Objects, the decided to butcher Records to act just like TP Objects
(well, pretty much)! Go figure.

I mostly code with classes, but do still us TP Objects mixed in with my
code for simpler data structures where I don't really want to
instantiate objects. Records - well, I use them like they were defined
in Delphi 7 and earlier. I really don't see the need for Records with
Methods (ie: TP Objects) and such.

Regards,
  Graeme



There are many cases where I do not want to free and create an object 
and just use something on the stack instead. TP objects kind of offered 
a solution to this, but not really, since if you used an old TP object 
which was designed to be on the heap, but you used in on the stack 
instead - problems would occur...


I'm fond of what Oberon and Golang are doing to try and solve the issue, 
but, that's garbage collected rather than stack.  And in those languages 
you have to send the self parameter in as your own (there is no hidden 
self, you create your own self shortform)

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

Re: [fpc-pascal] class operator in record

[noreply]

On 2017-03-01 03:06, Graeme Geldenhuys wrote:

On 2017-03-01 02:39, nore...@z505.com wrote:

How come:

   class operator Initialize(var aFoo: TFoo);
   class operator Finalize(var aFoo: TFoo);

in a record are called class operator..

why not "record operator"?



hahaha... You are asking all the questions I've been meaning to ask 
too.

From your question, just goes to show how rubbish Delphi is being
designed these days. Mixing concepts of class and record
interchangeably. And now we have "records" with constructors and
destructors! WTF. EMBT/Delphi are seriously polluting the Object Pascal
with all this rubbish. Unfortunately FPC feels like they need to follow
them like lemmings.



I don't blame FPC for following them in some respects because it enables 
compatible code to be shared between FPC and delphi, but I get what you 
mean..


Oberon is a fresh new start without all this rubbish but look where 
oberon is: no where.

Almost no one uses it, nor cares about it..

so if fpc does things right and diverges from delphi, you have 
incompatibility ...


But I see what you mean and understand your point
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] class operator in record

[noreply]

How come:

  class operator Initialize(var aFoo: TFoo);
  class operator Finalize(var aFoo: TFoo);

in a record are called class operator..

why not "record operator"?

Are these advanced neo-records considered classes?

Again, sorry I'm new to all this new record stuff (neo records ;-))

If they really are just classes, shouldn't it be called a class instead 
of record.


This also reminds me of the confusion between what an object is versus a 
class.

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

Re: [fpc-pascal] MSEide+MSEgui 4.4 for Free Pascal 3.0.2

[noreply]

On 2017-02-14 08:51, Martin Schreiber wrote:

Hi,
MSEide+MSEgui 4.4 for Free Pascal 3.0.2 has been released:
https://sourceforge.net/projects/mseide-msegui/

There are also new versions of the ARM (Raspberry Pi) cross and native
environments for Free Pascal:
https://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/
https://sourceforge.net/projects/mseide-msegui/files/fpcarm/

and new versions of MSEgit, MSEspice and MSErun:
https://sourceforge.net/projects/mseuniverse/


Is there a wiki or information page explaining what mserun is, along 
with others mentioned above.. I could not find it on google.


I'm interested in the theory of such tools and what they do.

Found on post from Graeme about compiling with 8 cores, but that still 
does not explain what mserun is ;-)

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

Re: [fpc-pascal] Feature announcement: Management Operators

[noreply]

On 2017-02-28 05:20, Maciej Izak wrote:


It works correctly in all possible ways with RTL:

* New (Initialize)
* Dispose (Finalize)


What happens with a stack allocated record?
(no new() required, nor dispose() so is the record ever 
initialized/finalized?)


Or stack records are forbidden?

One reason I love records is because you can create a stack record 
without any worry of freeing and creating it on heap, a huge advantage 
over OOP programming in delphi/fpc where everything is heap object 
(except old turbo pascal objects).


Sorry, I've been out of touch with what's happening with Records lately 
in modern pascal/delphi/etc.
(If it sounds like a silly newbie question, forgive me, I am not up on 
the latest and greatest!)

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

Re: [fpc-pascal] TProcess usage and reading program output

[noreply]

On 2017-02-28 10:06, Graeme Geldenhuys wrote:

Hi,

Can anybody see if there is something wrong with the code shown below.
The code is copied from one of my earlier projects where I call the FPC
compiler and it worked just fine in that project.



Did you end up resolving the issue?

I'd be interested in creating a build tool that not only compiles 
projects in FPC but also compiles with dcc32 (delphi compiler)..


Is that something like what you are doing? I have a lot of projects that 
compile both in fpc and delphi and compiling manually using to compilers 
is a pain. One step just compiling it with a build tool that does both 
compilers would be nice.

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

Re: [fpc-pascal] parser combinator library

[noreply]

On 2017-02-24 15:00, Bernd wrote:

Hello,

Eight years ago someone asked whether there is a parser combinator
library for free pascal, nothing like that existed at that time and
also does not seem to exist up to the present day.

While I was reading about parser combinators in functional programming
languages (during my 42nd attempt to learn Haskell) I thought to
myself why not try to implement something like that in Object Pascal,
just so see how far we can push the boundaries of this imperative
object oriented language.

This is what I have come up with so far:
https://github.com/prof7bit/fpc_parser_combinators

Since we don't have lambdas I choose the next closest approach to
emulate them with object instances instead. This leads to a lot of
boiler plate in the definition of the elementary parsers and
combinators but fortunately it can all be hidden away in the library
and the usage of the combinators looks quite neat:

 // define the grammar
  EXPR  := Num or _PARENS;
  MULFUNC   := Sym('mul') and EXPR and EXPR;
  ADDFUNC   := Sym('add') and EXPR and EXPR;
  INNER := MULFUNC or ADDFUNC or Num;
  PARENS:= Sym('(') and INNER and Sym(')');

Please also note the unorthodox usage of and/or operators to invoke
the combinators :-)


Cool! Parsing is my favourite area of computing science..

And my 42 attempt at learning haskell I gave up because it seemed not to 
be able to do a simple char by char parser like any procedural language 
can do...


But, now that you've mentioned this, my interest has peaked in both 
Object Pascal and Haskell.




Please post improvements or variations of this theme, especially I am
interested in how to properly build up a syntax tree in the most
generic and reusable manner, this is something I have not yet
completely understood (because I am myself still quite unfamiliar with
this whole parsing business) currently all my parsers only return
arrays of strings that I can optionally post-process with an optional
hook function after a parser has completed.


I think parsing is still something computing science has to study more. 
There are many undiscovered techniques. The biggest issue I have seen is 
large long case statements where you start duplicating code in the case 
statement. Rob Pike has done some work on this, but I've had little time 
to research his solution proposed.

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

Re: [fpc-pascal] uses myunit in '../src/myunit.pas' ?

[noreply]

On 2017-02-12 01:33, Tim Veldhuizen wrote:

Indeed, I can confirm Delphi does this. I think since 2009 or XE or
so,


I'm too lazy to check right now, but I think even delphi 5 and such used 
paths in the dpr (project) file


Would be interesting to find out the real reason, but once again, I'm 
too lazy to head down that path and post a question on stackoverflow 
(plus, they would likely shut it down as off topic or irrelavent, 
knowing those turds)

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

[fpc-pascal] Re: LGPL rtl

[noreply]

I wrote

 If you statically link the lgpl code into your EXE, your exe is the module
 under lgpl now. Therefore all code must be released. Statically linked
 lgpl code in an exe is not a dll that can be shipped separately.

Nevermind, I see this has been discussed:

http://free-pascal-general.1045716.n5.nabble.com/Name-for-our-license-td2823357.html

Essentially, freepascal RTL is not LGPL, it's a new modified LGPL.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] LGPL rtl

[noreply]

I think all freepascal people have a misunderstanding of LGPL.

If you statically link the lgpl code into your EXE, your exe is the module
under lgpl now. Therefore all code must be released. Statically linked
lgpl code in an exe is not a dll that can be shipped separately.

This means currently all freepascal developers are violating the license
if they don't release their sources with their Exe that is statically
linked with lgpl sources.

The way to get around this is to ship object files with your application
so that you can relink the application.

Since freepascal and delphi is very ship one exe oriented (compile all
into single exe) and since dll's aren't used to ship the RTL, this means
freepascal developers all around the world are currently violating the
lgpl since the Exe you ship to people is a lgpl module, not your own
module under your own license.

I personally couldn't care less if you ship your exe without your source
code... but I think freepascal users and developers have grossly
misinterpreted what legally the LGPL actually means.

If you read up on it on the internet you will see that the work around is
to ship your RTL in a separate dll, or ship it as object files along with
object files that your application needs to be recompiled. This is a huge
inconvenience for developers IMO and is why LGPL/GPL is even more
obnoxious than the so called bsd advertising clause problem.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] inline and other modifiers

[noreply]

 On 12/21/2011 20:27, nore...@z505.com wrote:

 Also delphi is
 more strict when it comes to PROGRAM name parsing. In freepascal the
 program name can mismatch the file name, whereas delphi stops compiling
 and tells you error.

 i've never known this (program name must equal filename) to be a
 requirement...
 but then again, i've never used delphi... i have, however, used TP2 thru
 TP/BP7
 and in a world stricken with 8.3 filename limitations, being able to have
 something like

PROGRAM TestMonitorResolutions

 with a filename of montest.pas was a GoodThingtm... why this would ever
 change
 simply because we can use long filenames is completely beyond me smh


Possibly it was Unit names and not program names, my memory may not serve
me well.  I came across issues when compiling some code once, and there
was something different between compilers like unit name strictness.

The problem with allowing any sort of syntax is that your code is not
portable, different compilers might not accept it, where others will
accept it.  This can lead to people creating hundreds of files that
compile with one compiler but not another. That's one advantage of
defining a language standard.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] initializing pointer values

[noreply]

 On Fri, 16 Dec 2011, dhkblas...@zeelandnet.nl wrote:


 On implementing a linked list I hit to some unexpected (doesn't mean
 incorrect though) behaviour.

  

   ptest = ^test;
   test = record
      p: pointer;
   end;

  

   new(mytest);

  

 When I allocate mytest the pointer variable p is initialized as
 $ instead of nil as I did suspect. In my code though I am
 relying on the fact that new pointers are indeed nil so I can allocate
 them accordingly. How can I force and rely on the fact that
 p is always nil? What is the correct procedure here?

 Newly allocated memory is never zeroed out. You must do this manually with
 FillChar or FillWord.
 This is only done automatically for class instances.

 I will add a note to the docs.

 Michael.

Also you can Zero out records using:

var r: TSomeRec = ();

Or access the record fields and nil out the ones you want, but () gets it
all done in one shot.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Shared libries

[noreply]

 On 2011-12-12 00:48, nore...@z505.com wrote:

 Ok, thanks for clearifying that. I guess it's going to be a lot of
 include files instead... :)

 -Torsten.


 Why do you need include files in your case?
 You can put the units in the uses clause of your library.
 Because it is still going to give me a very long list of exports -
 considering I have approx. 200 methods to export.

 Instead I would do something like this:

 library something;

 {$DEFINE InterfaceSection}
 {$I unit1}
 [snip...]
 {$I unit20}
 {$UNDEFINE InterfaceSection}

 exports
 {$DEFINE ExportSection}
 {$I unit1},
 [snip...]
 {$I unit20}
 {$UNDEFINE ExportSection}
 ;

 end.

 unit 1;

 {$IFDEF InterfaceSection}
 function Foo(a: integer): integer;
 begin
result := a * a;
 end;
 {$ENDIF}

 {$IFDEF ExportSection}
Foo name 'Bar'
 {$ENDIF}


Well maybe ExportAll compiler feature should be suggested?

But please try this

unit Unit1;

{$mode objfpc}{$H+}

interface

procedure proc1; stdcall;
procedure proc2; stdcall;

implementation


procedure proc1; stdcall;
begin
  writeln('hello');
end; exports proc1;

procedure proc2; stdcall;
begin
  writeln('hello 2');
end; exports proc2;


end.


Notice how I put exports in several places...

It works on win32..

Try linux?

Now for your executable, load it like so:

program p;
{$mode objfpc}{$H+}

procedure proc1; stdcall; external 'd2.dll';
procedure proc2; stdcall; external 'd2.dll';

begin
  writeln('First proc from lib..enter');
  readln;
  proc1;
  readln;
  writeln('Second proc from lib..enter');
  proc2;
  readln;
end.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Shared libries

[noreply]

 Well maybe ExportAll compiler feature should be suggested?

 But please try this

 unit Unit1;

 {$mode objfpc}{$H+}

 interface

 procedure proc1; stdcall;
 procedure proc2; stdcall;

 implementation


 procedure proc1; stdcall;
 begin
writeln('hello');
 end; exports proc1;

 procedure proc2; stdcall;
 begin
writeln('hello 2');
 end; exports proc2;


 end.
 I tried and it didn't seem to work, however perhaps it could be related
 to that I'm trying to create a library for arm-linux on android.


Try adding EXPORT keyword after the stdcall.

I forgot to put that in there, that's what i used, but I figured it was
not needed so I deleted it before I sent my message. I thought export
keyword was not used for exports..
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Shared libries

[noreply]

 On 12 Dec 2011, at 19:56, nore...@z505.com wrote:

 procedure proc1; stdcall;
 begin
  writeln('hello');
 end; exports proc1;

 procedure proc2; stdcall;
 begin
  writeln('hello 2');
 end; exports proc2;


 end.


 Notice how I put exports in several places...

 It works on win32..

 It only partially works. Please see the bug report I mentioned earlier:
 http://bugs.freepascal.org/bug_view_advanced_page.php?bug_id=16070



interesting, I tried BUILD ALL in lazarus ide and it works, but I also
tried not building all and using the EXPORT keyword along with EXPORTS
section, and that requires no build all. Whereas without the EXPORT
keyword it only works if you build all. This is on win32.

So the export keyword does something on win32?

You said that EXPORT keyword is for emx and os/2 ...

But maybe I should look into the compiler sources to see if it does
something else.. it seems to cause the dll to work without a build all..
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] CloseThread needed? still unclear

[noreply]

I wrote:

 I think I found some documentation that still doesn't include
 CloseThread in the examples.. I will send patches or recommendations to
 the documentation soon.  For example closethread is now documented as a
 function, but some of the other pages that show threading examples just
 use endthread. I thought maybe closethread somehow was tied into endthread
 but this not the case.



For example:
http://www.freepascal.org/docs-html/prog/progse44.html#x217-2310.2

In this example it doesn't call closethread (and it doesn't use endthread).


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Shared libries

[noreply]

 Hi.

 I'm trying to create a shared library (under linux) and I not sure what
 the
 difference between the modifier *export* and the section *exports* is?
 Or perhaps
 when to use one and the other...


Just different ways of doing it.

You can export each one, or you can use exports clause to do it all there
in one place.  I think it is from the old borland days when they used to
do the export, but then they added exports as a feature.. but I'm not 100
percent sure.

A long time ago when I was using libraries on linux, I had some problems,
with initialization and finalization sections, I'm not sure if the
problems are fixed.  Also on BSD it didn't load libraries back then, not
sure if it has changed.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Shared libries

[noreply]

 Ok, thanks for clearifying that. I guess it's going to be a lot of
 include files instead... :)

 -Torsten.


Why do you need include files in your case?
You can put the units in the uses clause of your library.

library something;

uses
  someunit;

exports
  someunit.yourproc;

end.

The someunit. prefix is optional.

In newer versions of FPC it allows you to put an exports clause in the
unit itself, but older versions didn't allow it.

http://62.166.198.202/bug_view_page.php?bug_id=4398history=1

In delphi 1.0 the export directive meant something different which causes
confusion. Borland made export directive obsolete but kept the export
keyword there probably for compiling old code. fpc has slightly different
reasons for the export directive than delphi and lots of confusion arises.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Readline substitute

[noreply]

 The usual answer for this question is libreadline. I already worked with
 it (in plain C) but before I do a header translation for FreePascal I
 wanted to ask you for your opinion if there is a better alternative or
 anybody already has a header translation or even programmer-friendly
 wrapper for the history and auto-completion stuff.

 linenoise[1] and editline[2] are alternatives. Don't know if there are
 pascal bindings to those.

 [1]: https://github.com/antirez/linenoise
 [2]: http://www.thrysoee.dk/editline/


Also these pages too:
http://sourceforge.net/projects/libedit/
http://s11n.net/editline/

All bsd licensed


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Readline substitute

[noreply]

 2011/5/1 Johann Glaser johann.gla...@gmx.at:

 If you find any improvements or comments don't hesitate to send me an
 EMail.

 I just used it. I only needed readline() and add_history(), these two
 functions are already enough to make a ReadLn() substitute that really
 works and It works like a charm! Thank you!

 I think this code really deserves to be included in FPC.

Be very careful with ReadLine GPL library. It is not LGPL as far as i
know, and therefore it is viral stallmanware... requires we relicense
anything else as gpl if you use the library...

See what happened to common lisp clisp when they used it. Had to change
license to GPL even though they didn't want to.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] CloseThread needed? still unclear

[noreply]

 On 28.11.2011 21:25, nore...@z505.com wrote:
 Am 14.11.2011 02:32, schrieb nore...@z505.com:
 First I thought I would post this to the mailing list to ask you what
 the
 proper way to program with threads is. If we must call closethread on
 MS
 Win machines but not unix machines, then something needs to change to
 make
 the threading in the RTL more cross platform (and all the docs would
 need
 to mention things about closethread if it is needed).

 The bug was already mentioned here
 http://mantis.freepascal.org/view.php?id=13160 and fixed for 2.2.2.
 CloseThread was implemented in a cross platform way.

 Regards,
 Sven

 Hmm, but the compiler I'm using right now is a 2.4 and I think there is
 a
 leak if I don't call closethread.

 That is exactly my point: CloseThread was implemented because of that
 leak (see the comments in the bug issue I linked to).


I see. I think I found some documentation that still doesn't include
CloseThread in the examples.. I will send patches or recommendations to
the documentation soon.  For example closethread is now documented as a
function, but some of the other pages that show threading examples just
use endthread. I thought maybe closethread somehow was tied into endthread
but this not the case.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal