This is just a heads up to anyone interested. As you know a few months ago I created a new documentation site at http://docs.getlazarus.org that improves the help system for Free Pascal and Lazarus.

Continuing along the same vein I've started work on a new series of Free Pascal and Lazarus pages which I have named Lazarus learning center:

http://www.getlazarus.org/learn/

Currently these pages hold minimal stubs for study guides, but I anticipate adding a lot of content to them over the next few weeks. What I'd like from you is to feedback about concerning which new topics you'd like covered or feedback on articles I have or will be posting.

Anyone can add their requests, critiques, or corrections on the site by using the "Edit this page" link at the top of every page. My back end editor page shows me all the pending "diffs" which I can easily integrate into any page.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160128/007769ff/attachment-0001.html>

Maybe a quick comparison of Pascal with Java, C, C++, C#, so beginners from those background can quickly pick up fpc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160129/c04ef418/attachment.html>

Noted. I might add that as a beginning level video tutorial. Right now I am writing javascript canvas code to convert text to lexical diagrams and slicing a screen shot of the IDE for a visual popover guide, -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160128/5b7d06db/attachment.html>

Anthony Walter wrote

What I'd like from you is to feedback about concerning which new topics you'd like covered

Maybe a tutorial about using TThreads and TEvents to syncronize tasks within a multi-threaded application.
Good examples using threads for TCPIP networking or similar would be good.

Thanks for the idea Bo. I'll put it near the top of my queue. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160131/fcd39440/attachment.html>

Anthony Walter wrote

Thanks for the idea Bo. I'll put it near the top of my queue.

+1

IMHO the knowledge about the (great) thread Features of Lazarus are by far not spread wide enough.

The "lesson" should include:

- Motivation for the usage of threads:
- - long winding calculations
- - blocking sockets and other hardware / system interface
- - exploiting multi-core hardware
- Different programming Paradigms for Main Thread and Worker Threads
- - Main thread: Event driven (never sleep ! )
- - one-shot Worker threads
- - cyclic Worker Thread
- - - "wake up" e.g. by blocking interfaces,TEvent or CriticalSection
- - - polling with sleep (trading performance against latency)
- Worker Thread to Main Tread Events:
- - TTherad.Synchonize
- - TThread.Queue
- - Application.ProcessMessages (IMHO less important since we have TThread.Queue in FPC 3.x)
- - using "Event data transport classes" to be used as an argument of TThread.Queue
- Data integrity
- - "Thread safe"
- - CriticalSection
- - TThreadList
- Creating a Thread pool to prevent overhead for creating and destroying worker threads.
- Advanced:
- - Threads and DLL/so

...

-Michael

I could not agree more! I have been programming Delphi since 1996 and only very occationally used TThread objects. So I have totally forgotten now how it was done. (I am now retired so I don't have access to my old work code anymore)

Blocking sockets is where I am now...
Got some help from Remy Lebeau concerning running a TIdTcpClient object in a TThread descendant because its methods are blocking. But his solution is based on TThread and TEvent new functionality existing in Delphi XE5 but not in Delphi 2007 or FreePascal 3.0 So I am essentially stuck anyway since I would like it to be a portable solution Delphi <=> FreePascal

This is anyway why I proposed the thread section here, believing that if I don't know enough to use it properly there are for shure a whole bunch others that share this predicament....

Just a bit of information, my Cross.Codebot library has threading built in to the socket protocol implementations, so with regards to explaining it I could just show the source code or I could write it a again just to demonstrate.

With regards to complexity, I never define a new thread class, which is the typical way most people think about working with threads in Free Pascal. Instead I have one thread class defined in my System unit, and you pass it your execute method along with an optional status handler. Your execute is called, the thread object is freed for you automatically, and you don't need to declare a new type.

procedure TDownloadForm.DownloadComplete(Thread: TSimpleThread);
begin
  FThread := nil;
  // Invoked in the user interface thread
  // Check Thread.Cancelled here
end;
procedure TDownloadForm.DownloadStatus(Thread: TSimpleThread);
begin
  // Invoked in the user interface thread
  // Do something with Thread.Status here
end;
procedure TDownloadForm.Download(Thread: TSimpleThread);
begin
  // Download here in a thread
  // Set Thread.Status := SomeString to sync status updates with the UI
  // FThread.Cancel cancels the thread
  // Throw exception cancels the thread
end;
procedure TDownloadForm.DownloadClick(Sender: TObject);
begin
  if FThread  nil then
    Exit;
  FThread := TSimpleThread.Create(Download, DownloadStatus,
DownloadComplete);
end;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160201/498458ca/attachment.html>

Bo Berglund wrote

Blocking sockets is where I am now...

So Porting AsyncPro would be a great exercise :-) !!!

This is an exceptionally useful tool, great open source code once done by a professional tea, but done in a Windows-only and outdated way (not using TThread.Queue, but Windows messages and "procedure... message" instead. Mending this and using decently portable blocking Socket and Com-Port (TTY) components would do the trick.

[snip]

This mechanism could easily be added as class static methods to TThread itself. It would make life easier for many simple cases.

Class Procedure TThread.Spawn(MyProcedure,OnStatus,OnTerminate : TThreadProcedure); static;

Or "ExecuteInThread" instead of "Spawn".

Would you care to enter this as a feature request ?

Michael.

Michael,

My implementation adds an optional Status property to a thread, which then necessitates an instance. When Status is written (that's the optional part) in a background thread its value is copied temporarily to a private field, then the thread invokes Synchronize. Before your status changed handler is notified, the thread instance copies the temporary status back to the property read field. With this type of arrangement it's possible to update the Status property in a background thread while the user interface might be reading from it.

The net result is that setting Status in the background thread causes the user interface thread to receive a notification where it can do whatever it wants with Status. Examples: show a percentage complete, show steps being worked on, show bytes transferred, or whatever you dream up. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160201/1a433f90/attachment.html>

Michael, if you or anyone with commit rights feels comfortable adding a derived thread class (TSimpleThread) with the features I've described to the classes unit, then I'll post my implementation to mantis as a patch. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160201/94fa9821/attachment.html>

Anthony Walter wrote

Michael, if you or anyone with commit rights feels comfortable adding a derived thread class (TSimpleThread) with the features I've described to the classes unit, then I'll post my implementation to mantis as a patch.

I feel comfortable with this :-)

I wouldn't have proposed it otherwise :)

Michael.

Ouch! Now you seem to have found my old thread where I was asking about AsyncPro. I used that in Delphi including the variation that uses TCP/IP rather than COM: as transport layer.
I used it, without really having to understand what was going on behind the scenes...

But as you say it is Windows-only...
And very complex to hack into as well.
So I turned to Indy10 now since I don't need serial, but have to handle the blocking sockets in a scenario similar to event driven handling....

I will watch this! :)

Bo Berglund wrote

And very complex to hack into as well.

If I can provide any help., please let me know.

So I turned to Indy10 now

Not a good idea IMHO, Indy is exceptionally complex.

-Michael

in

> to the socket protocol implementations, so with regards to explaining it

I

> could just show the source code or I could write it a again just to > demonstrate. > > With regards to complexity, I never define a new thread class, which is

the

> typical way most people think about working with threads in Free Pascal. > Instead I have one thread class defined in my System unit, and you pass

it

> your execute method along with an optional status handler. Your execute

is

TThreadProcedure); static;

Or "ExecuteInThread" instead of "Spawn". Would you care to enter this as a feature request ?

Current Delphis have something similar for anonymous functions already, so we should use the same name, but with "of object" procvars instead (note: the resulting thread class will be TAnonymousThread).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160201/3422c332/attachment.html>

Sven,

What's the current road map look like for closures? Is it even on the radar? If so, and if no major work has been done on it yet, an improved syntax would go a long way in usability.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160201/c58249f3/attachment-0001.html>

"Anthony Walter" wrote

Sven, What's the current road map look like for closures? Is it even on the

radar? If so, and if no major work has been done on it yet, an improved syntax would go a long way in usability.

Someone is working on them and a prototype exists (look in fpc-devel's archive for December). Now the code only needs to be cleaned up.

In my head I already play around with a shorter/nicer syntax at least for expressions (thus lambda expressions ;) ), but most ideas rely on type inference which I'm very reluctant to add, because that's something that's not part of the sprit of Pascal.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160201/609c40a1/attachment.html>

But Remy Lebeau keeps it compatible to Free Pascal too, he says...

Bo Berglund wrote

But Remy Lebeau keeps it compatible to Free Pascal too, he says...

Indeed he does, and brilliant in answering questions. I'm using the latest Indy 10 from SVN now, and pretty much moved all my Synapse based projects over to Indy now.

Regards,
- Graeme -

My public PGP key: http://tinyurl.com/graeme-pgp

Michael Schnell wrote

Indy is exceptionally complex.

It depends on the developer I guess. ;-)

Regards,
- Graeme -

My public PGP key: http://tinyurl.com/graeme-pgp

Graeme Geldenhuys wrote

It depends on the developer I guess. ;-)

I (mostly with Delphi) did use as well AsyncPro as Indy as Synapse (and once LNET)

I found Indy rather hard to use. But it can successfully be made doing lots of stuff .

-Michael

Michael Schnell wrote

I found Indy rather hard to use.

Like I said, that is dependent on the person. I had no problem switching between Synapse and Indy. They seem equally user friendly to me. Indy is just a lot more convenient to me because it implements, as standard, just about every TCP protocol there is. Plus, Indy documentation is good, support is good, and it is still actively being developed (even contributions from Embarcadero).

Synapse and LNet seem very slow moving - but that doesn't necessarily mean anything bad.

Regards,
- Graeme -

Michael, I submitted TSimpleThread to mantis. It's filed under issue #29597. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160205/110f4c9d/attachment.html>

Anthony Walter wrote

Michael, I submitted TSimpleThread to mantis. It's filed under issue #29597.

Thank you, I'm on it.

Michael.