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

[Sven Barth via fpc-pascal]

Am 06.07.2017 23:34 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-07-06 20:07, Dmitry Boyarintsev wrote:
>>
>> The thread of discussion:
>> http://lists.freepascal.org/pipermail/fpc-devel/2016-February/036709.html
>
>
>
> Thanks for the link. Seems this topic has already been discussed a year
and a bit ago.
>
> Anybody know if there was any movement on the $IncludeString idea?

See my message from yesterday night. :)

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

Re: [fpc-pascal] If vs case or something else?

[Stefan V. Pantazi]

I am not sure I follow. If switching on strings, or any sparse value 
set, you can use the balanced tree approach or better yet, a hash table. 
But when switching on a compact, limited set of integer values (as the 
case seems to be), I do not see how you can compete with constant time 
procedure table/array lookups.


Stefan


You can skip large blocks of tests coding like this

Not as fast as a tree search balanced with probabilities (no answer to
my question on the list afew days ago...), but probably ten time faster
then what you proposed.

Cheers, Ched'



Le 06.07.2017 à 20:41, Stefan V. Pantazi a écrit :

That is quite the case statement you have there. You may benefit
greatly from re-analyzing and refactoring your programs by splitting
them in multiple individual units, if possible. That should be
perfectly possible if Dosomething();DoSomethingelse(); keep
repeating across your 70+ switch cases.

Anyway, here you go, you can try something like the attached.

Good luck!

Stefan



On 07/06/2017 12:33 PM, James Richters wrote:

I'm trying to optimize a console application ported over from Turbo
Pascal with a huge set of if then else statements like this:

Var
 TXT : String;
If TXT = 'Thing1' then
   Begin
  Dosomething();
  DoSomethingelse();
   End
else
If TXT = 'AnotherThing' then
   Begin
  Dosomethinganotherway();
  DoSomethingelsetoo();
   End
Else
If TXT = 'Thing3' then
   Begin
  Dosomethingathirdtime();
  DoSomethingelse3();
   End
else    etc..  over 70 times... etc

It works but it's hard to follow and not so fast.  It has to run
through this for every line of a file to see what's in the file and
do the right things with it.
So I'm thinking of undertaking a huge re-organization of it and I'm
wondering what the best way would be to do it.

I can use case statement with strings apparently now, but the thing
is,  I create this file myself in an earlier stage, so I do not need
to create the file with strings at all, I could use some codes and do
something like this:

Const
   Thing1 = 1
Another_Thing = 2
Thing3 = 3
Var
Codenum: Word;

Case Codenum of
   Thing1: Begin
DoSomethng()
DoSomethingElse()
   End;
Another_Thing: Begin
... etc ...


I'm guessing that would be faster as I wouldn't have to keep
evaluating all the strings for every condition.   As I was searching
for the best way to do this, I came across something about making an
Array of Procedures, or something to that effect.   Does anyone know
how to do that, and are there performance advantages to doing that?
It's going to take a bit of work to straighten all this out so it
would be best if I just did it the best way instead of doing it one
way then finding out it could have been better another way.   Any
other ideas on how to handle this?

Any advice on this is greatly appreciated

James




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





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



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


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

[Michael Van Canneyt]

On Thu, 6 Jul 2017, Sven Barth via fpc-pascal wrote:


On 06.07.2017 16:13, Graeme Geldenhuys wrote:

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.


Completely ignoring the type inference which I'm definitely not a fan of
- at least not in Pascal: In my opinion it would be better to improve
and finalize the $IncludeStringFile patch from issue #25536 (
https://bugs.freepascal.org/view.php?id=25536 ).


Sven,

What stops us from applying the patch ?
It has been in Mantis for ages.

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

[Graeme Geldenhuys]

On 2017-07-06 20:07, Dmitry Boyarintsev wrote:

The thread of discussion:
http://lists.freepascal.org/pipermail/fpc-devel/2016-February/036709.html



Thanks for the link. Seems this topic has already been discussed a year 
and a bit ago.


Anybody know if there was any movement on the $IncludeString idea?

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] If vs case or something else?

[Ched]

Hi Stefan,

You can skip large blocks of tests coding like this

If Length(txt)>0 then
   case txt[1] of
  'a': if txt='another' then
  ...
   else if txt='anum' then
  ...;
  'b': if txt="bubble' then
  ...
   else if ...
   else
  ...
   end;

Not as fast as a tree search balanced with probabilities (no answer to my question on the list afew days 
ago...), but probably ten time faster then what you proposed.


Cheers, Ched'



Le 06.07.2017 à 20:41, Stefan V. Pantazi a écrit :
That is quite the case statement you have there. You may benefit greatly from re-analyzing and 
refactoring your programs by splitting them in multiple individual units, if possible. That should be 
perfectly possible if Dosomething();DoSomethingelse(); keep repeating across your 70+ switch cases.


Anyway, here you go, you can try something like the attached.

Good luck!

Stefan



On 07/06/2017 12:33 PM, James Richters wrote:
I'm trying to optimize a console application ported over from Turbo Pascal with a huge set of if then 
else statements like this:


Var
 TXT : String;
If TXT = 'Thing1' then
   Begin
  Dosomething();
  DoSomethingelse();
   End
else
If TXT = 'AnotherThing' then
   Begin
  Dosomethinganotherway();
  DoSomethingelsetoo();
   End
Else
If TXT = 'Thing3' then
   Begin
  Dosomethingathirdtime();
  DoSomethingelse3();
   End
else    etc..  over 70 times... etc

It works but it's hard to follow and not so fast.  It has to run through this for every line of a file 
to see what's in the file and do the right things with it.
So I'm thinking of undertaking a huge re-organization of it and I'm wondering what the best way would 
be to do it.


I can use case statement with strings apparently now, but the thing is,  I create this file myself in 
an earlier stage, so I do not need to create the file with strings at all, I could use some codes and 
do something like this:


Const
   Thing1 = 1
Another_Thing = 2
Thing3 = 3
Var
Codenum: Word;

Case Codenum of
   Thing1: Begin
DoSomethng()
DoSomethingElse()
   End;
Another_Thing: Begin
... etc ...


I'm guessing that would be faster as I wouldn't have to keep evaluating all the strings for every 
condition.   As I was searching for the best way to do this, I came across something about making an 
Array of Procedures, or something to that effect.   Does anyone know how to do that, and are there 
performance advantages to doing that?  It's going to take a bit of work to straighten all this out so 
it would be best if I just did it the best way instead of doing it one way then finding out it could 
have been better another way.   Any other ideas on how to handle this?


Any advice on this is greatly appreciated

James




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





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



___
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

[Mark Morgan Lloyd]

On 06/07/17 20:00, Sven Barth via fpc-pascal wrote:

On 06.07.2017 16:13, Graeme Geldenhuys wrote:> 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.
Completely ignoring the type inference which I'm definitely not a fan of- at 
least not in Pascal: In my opinion it would be better to improveand finalize 
the $IncludeStringFile patch from issue #25536 
(https://bugs.freepascal.org/view.php?id=25536 ).It has the advantage that it 
doesn't change the language and that theinclude file can be viewed 
independently with an appropriate syntaxhighlighter (especially with more 
complex SQL statements - to stick withyour example - that is something that I'd 
really welcome).Of course it has the disadvantage that one can't easily add 
variables,but for things like this one can always pass the included string 
toFormat() and friends which in my opinion would be more cleaned up anyway.


Some sort of heredoc approach would seem reasonable and I think it might 
be worth noting the PostgreSQL way:


$$Dianne's horse$$
$SomeTag$Dianne's horse$SomeTag$

$function$
BEGIN
RETURN ($1 ~ $q$[\t\r\n\v\\]$q$);
END;
$function$

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] If vs case or something else?

[Stefan V. Pantazi]

That is quite the case statement you have there. You may benefit greatly 
from re-analyzing and refactoring your programs by splitting them in 
multiple individual units, if possible. That should be perfectly 
possible if Dosomething();	DoSomethingelse(); keep repeating across your 
70+ switch cases.


Anyway, here you go, you can try something like the attached.

Good luck!

Stefan



On 07/06/2017 12:33 PM, James Richters wrote:

I'm trying to optimize a console application ported over from Turbo Pascal with 
a huge set of if then else statements like this:

Var
 TXT : String;
If TXT = 'Thing1' then
   Begin
  Dosomething();
  DoSomethingelse();
   End
else
If TXT = 'AnotherThing' then
   Begin
  Dosomethinganotherway();
  DoSomethingelsetoo();
   End
Else
If TXT = 'Thing3' then
   Begin
  Dosomethingathirdtime();
  DoSomethingelse3();
   End
else    etc..  over 70 times... etc

It works but it's hard to follow and not so fast.  It has to run through this 
for every line of a file to see what's in the file and do the right things with 
it.
So I'm thinking of undertaking a huge re-organization of it and I'm wondering 
what the best way would be to do it.

I can use case statement with strings apparently now, but the thing is,  I 
create this file myself in an earlier stage, so I do not need to create the 
file with strings at all, I could use some codes and do something like this:

Const
   Thing1 = 1
Another_Thing = 2
Thing3 = 3
Var
Codenum: Word;

Case Codenum of
   Thing1: Begin
DoSomethng()
DoSomethingElse()
   End;
Another_Thing: Begin
... etc ...


I'm guessing that would be faster as I wouldn't have to keep evaluating all the 
strings for every condition.   As I was searching for the best way to do this, 
I came across something about making an Array of Procedures, or something to 
that effect.   Does anyone know how to do that, and are there performance 
advantages to doing that?  It's going to take a bit of work to straighten all 
this out so it would be best if I just did it the best way instead of doing it 
one way then finding out it could have been better another way.   Any other 
ideas on how to handle this?

Any advice on this is greatly appreciated

James




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



--
___
program fast_switch;

uses sysutils,

fast_switch_handler_unit;//implements case handlers

const
  TEST_COUNT=100;

function GetCodeNum():word;
begin
  Result:=Random(MAX_HANDLER_IDX);
end;

var
  i:Integer;
	Codenum: Word; //or enum

begin
  Randomize;
  for i:=0 to TEST_COUNT-1 do
  begin
WriteLn('Test switching #',i);
repeat
		  codeNum:=GetCodeNum();
  //execute procedure with index codeNum from PROC_TABLE
		  if (Codenum>0) and (Codenum<=MAX_HANDLER_IDX) then PROC_TABLE[CodeNum];
  Sleep(50);
	  until codeNum=0;
WriteLn('Done switching test #',i);
  end;
  WriteLn('Done switching test program.');
end.
unit fast_switch_dosomething_unit;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils;

procedure Dosomething();
procedure DoSomethingelse();
procedure Dosomethinganotherway();
procedure DoSomethingelsetoo();
procedure Dosomethingathirdtime();
procedure DoSomethingelse3();

implementation

procedure Dosomething();
begin
  WriteLn('Dosomething()');
end;

procedure DoSomethingelse();
begin
  WriteLn('DoSomethingelse()');
end;

procedure Dosomethinganotherway();
begin
  WriteLn('Dosomethinganotherway()');
end;

procedure DoSomethingelsetoo();
begin
WriteLn('DoSomethingelsetoo()');
end;

procedure Dosomethingathirdtime();
begin
  WriteLn('Dosomethingathirdtime()');
end;

procedure DoSomethingelse3();
begin
  WriteLn('DoSomethingelse3()');
end;

end.

unit fast_switch_handler_unit;

{$mode objfpc}{$H+}

interface

uses
	fast_switch_dosomething_unit;//implements DoSomething*
const
  MAX_HANDLER_IDX=3;// or 70

procedure Thing1_Handler();
procedure AnotherThing_Handler();
procedure Thing3_Handler();

const
	PROC_TABLE:array[1..MAX_HANDLER_IDX] of procedure=(
		@Thing1_Handler,
		@AnotherThing_Handler,
		@Thing3_Handler
//		...
//@Thing70_Handler
		);

implementation

procedure Thing1_Handler();
Begin
	Dosomething();
	DoSomethingelse();
End;

procedure AnotherThing_Handler();
Begin
	Dosomethinganotherway();
	DoSomethingelsetoo();
End;

procedure Thing3_Handler();
Begin
	Dosomethingathirdtime();
	DoSomethingelse3();
End;

end.

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

Re: [fpc-pascal] If vs case or something else?

[Sven Barth via fpc-pascal]

On 06.07.2017 18:33, James Richters wrote:
> I can use case statement with strings apparently now, but the thing is,  I 
> create this file myself in an earlier stage, so I do not need to create the 
> file with strings at all, I could use some codes and do something like this:

"case of String" is essentially the same as your chain of if-statements,
the compiler doesn't do any real optimization there.

> Const
>Thing1 = 1
> Another_Thing = 2
> Thing3 = 3
> Var
> Codenum: Word;
> 
> Case Codenum of
>Thing1: Begin
> DoSomethng()
> DoSomethingElse()
>End;
> Another_Thing: Begin
> ... etc ...
> 
> 
> I'm guessing that would be faster as I wouldn't have to keep evaluating all 
> the strings for every condition.   As I was searching for the best way to do 
> this, I came across something about making an Array of Procedures, or 
> something to that effect.   Does anyone know how to do that, and are there 
> performance advantages to doing that?  It's going to take a bit of work to 
> straighten all this out so it would be best if I just did it the best way 
> instead of doing it one way then finding out it could have been better 
> another way.   Any other ideas on how to handle this?
> 
> Any advice on this is greatly appreciated

If you aren't fixed on having to work on a string that would definitely
be best as you could then use a enum or something like that and you a
case statement. The compiler will try to pick a suitable implementation
then (jumptable, linear search), depending on the amount of labels.

Alternatively you can indeed use an array of procedures like this:

=== code begin ===

program tprocarray;

procedure Proc1;
begin
  Writeln('Proc1');
end;

procedure Proc2;
begin
  Writeln('Proc2');
end;

const
  Procs: array[0..1] of TProcedure = (
@Proc1,
@Proc2
  );

var
  proc: Longint;
begin
  proc := 1;
  Procs[proc]();
end.

=== code end ===

Of course you can also use an enum as the array index:

=== code begin ===

{$scopedenums on} // just for demonstrations

type
  TProcs = (
One,
Two
  );

const
  Procs: array[TProcs] of TProcedure = (
@Proc1,
@Proc2
  );

var
  proc: TProcs;
begin
  proc := TProcs.Two;
  Procs[proc]();
end.

=== code end ===

The variant with the enum has the advantage that the compiler will
complain about missing elements if you add one to the enum type.

Though in both cases you should ensure that your index is in range.

In case of many branches the variant with the array (any of the two
variants) should be faster than the case one.

Regards,
Sven
___
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

[Sven Barth via fpc-pascal]

On 06.07.2017 16:13, Graeme Geldenhuys wrote:
> 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.

Completely ignoring the type inference which I'm definitely not a fan of
- at least not in Pascal: In my opinion it would be better to improve
and finalize the $IncludeStringFile patch from issue #25536 (
https://bugs.freepascal.org/view.php?id=25536 ).
It has the advantage that it doesn't change the language and that the
include file can be viewed independently with an appropriate syntax
highlighter (especially with more complex SQL statements - to stick with
your example - that is something that I'd really welcome).
Of course it has the disadvantage that one can't easily add variables,
but for things like this one can always pass the included string to
Format() and friends which in my opinion would be more cleaned up anyway.

Regards,
Sven
___
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

[Dmitry Boyarintsev]

On Thu, Jul 6, 2017 at 10:27 AM, Marcos Douglas B. Santos 
wrote:

> That would be very, very nice.
> And instead of using [ " ' sql ' " ] would be better to use just [ " sql "
> ].
>

The thread of discussion:
http://lists.freepascal.org/pipermail/fpc-devel/2016-February/036709.html
___
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

[Bernd Oppolzer]

Am 06.07.2017 um 18:32 schrieb Andreas:


For this reason I would be against this implementation. Maybe taking 
away the need for the + sign at the end of the line. The strings are 
concatenated until a semi-colon or other symbol is encountered


This is what the (new) Stanford Pascal compiler does:

program TESTLSTR ( OUTPUT ) ;

var ZEILE : array [ 1 .. 200 ] of CHAR ;
I : INTEGER ;

begin (* HAUPTPROGRAMM *)
  ZEILE := ''
   ''
   ''
   ''
   '' ;
  WRITELN ( ZEILE ) ;
  MEMSET ( ADDR ( ZEILE ) , 'b' , 200 ) ;
  WRITELN ( ZEILE ) ;
  for I := 1 to 200 do
ZEILE [ I ] := '=' ;
  WRITELN ( ZEILE ) ;
end (* HAUPTPROGRAMM *) .

that is: long strings may be concatenated simply by closing
the string constant on one line and reopening it on the next line.

http://bernd-oppolzer.de/job9.htm

HTH, kind regards

Bernd

___
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

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> 
> 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;'''


''' already has meaning, you'll see that 

var s : ansistring;
begin
  s:='''text''';
end.

already compiles now.
___
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

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 6 Jul 2017, Graeme Geldenhuys wrote:

> On 2017-07-06 15:35, Karoly Balogh (Charlie/SGR) wrote:
> > But sure, web devs are well known for their productivity... :P
>
> Just in case you thought I was a web developer - far from it!
>
> Anyway, the idea was just that - an idea (and possibly an improvement)
> on an age old problem. I have no means or skills to implement something
> like that in FPC. But I thought it might be worth a discussion. I like
> to think outside the box every now and again - most of my projects show
> that.

Sure, we should be free to discuss such proposals, nothing wrong with
that. I just stated my opinion, but that shouldn't stop discussion in any
way. :)

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

[fpc-pascal] If vs case or something else?

[James Richters]

I'm trying to optimize a console application ported over from Turbo Pascal with 
a huge set of if then else statements like this:

Var
 TXT : String;
If TXT = 'Thing1' then
   Begin   
  Dosomething();
  DoSomethingelse();
   End
else 
If TXT = 'AnotherThing' then
   Begin   
  Dosomethinganotherway();
  DoSomethingelsetoo();
   End
Else
If TXT = 'Thing3' then
   Begin   
  Dosomethingathirdtime();
  DoSomethingelse3();
   End
else    etc..  over 70 times... etc

It works but it's hard to follow and not so fast.  It has to run through this 
for every line of a file to see what's in the file and do the right things with 
it.
So I'm thinking of undertaking a huge re-organization of it and I'm wondering 
what the best way would be to do it. 

I can use case statement with strings apparently now, but the thing is,  I 
create this file myself in an earlier stage, so I do not need to create the 
file with strings at all, I could use some codes and do something like this:
 
Const
   Thing1 = 1
Another_Thing = 2
Thing3 = 3
Var
Codenum: Word;

Case Codenum of
   Thing1: Begin
DoSomethng()
DoSomethingElse()
   End;
Another_Thing: Begin
... etc ...


I'm guessing that would be faster as I wouldn't have to keep evaluating all the 
strings for every condition.   As I was searching for the best way to do this, 
I came across something about making an Array of Procedures, or something to 
that effect.   Does anyone know how to do that, and are there performance 
advantages to doing that?  It's going to take a bit of work to straighten all 
this out so it would be best if I just did it the best way instead of doing it 
one way then finding out it could have been better another way.   Any other 
ideas on how to handle this?

Any advice on this is greatly appreciated

James




___
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

[Andreas]

Graeme, I am a big fan of your messages. You have many good ideas and I 
sometimes read a theme that I am not interested in just to see your 
response.


In this case however I think you are wrong. Pascal has fantastic 
inherent type and error checking in its structure. It would be wrong to 
have an editor that can introduce unwanted errors. Just one way that I 
can see potential problems in you code style is the line end. Not every 
string is a SQL text which is very flexible in it's interpretation. 
Other string may want one or more spaces between the last symbol on the 
top line and the first on the second, today the editor normally strips 
these spaces away. If they are left in, they are spaces that visually I 
can not determine just by looking at the code. A mess.


For this reason I would be against this implementation. Maybe taking 
away the need for the + sign at the end of the line. The strings are 
concatenated until a semi-colon or other symbol is encountered



On 06/07/2017 11: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



___
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

[Graeme Geldenhuys]

On 2017-07-06 15:35, Karoly Balogh (Charlie/SGR) wrote:

But sure, web devs are well known for their productivity... :P


Just in case you thought I was a web developer - far from it!

Anyway, the idea was just that - an idea (and possibly an improvement) 
on an age old problem. I have no means or skills to implement something 
like that in FPC. But I thought it might be worth a discussion. I like 
to think outside the box every now and again - most of my projects show 
that.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 6 Jul 2017, Graeme Geldenhuys wrote:

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

Stuff like this looks almost as bad to me, as PHP intermixed with HTML and
Javascript. But sure, web devs are well known for their productivity... :P

(And I'm quite conservative on such things, so ignore me. :) )

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

[Marcos Douglas B. Santos]

On Thu, Jul 6, 2017 at 11:13 AM, Graeme Geldenhuys
 wrote:
>
> 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.

That would be very, very nice.
And instead of using [ " ' sql ' " ] would be better to use just [ " sql " ].

Best regards,
Marcos Douglas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Graeme Geldenhuys]

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

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Serial to TCP gateway in FPC?

[Michael Schnell]

On 04.07.2017 00:06, Mark Morgan Lloyd wrote:
... if you're in any sort of tight loop you need to call APM to get 
any of the usual GUI stuff to work.
Including any messages sent by worker threads such as "TThread.Queue", 
"TThread.Synchronize", "Application.QueueAsnycCall" and 
"SendThreadMessage".


With the additional afterthought that TThread.Synchronize will stall the 
worker thread until the event is able to be handled in the GUI Thread.


-Michael

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