Sunday, June 27, 2021

FreePascal and Lazarus Development will switch to GIT

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

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

You can see the current progress at:

https://gitlab.com/freepascal.org

2 subgroups have been made:

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

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


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


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

If you are a user on our Bugtracker (Mantis):

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


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


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

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

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

For the FPC & Lazarus teams,
Martin (Message originally by Michael)

Tuesday, February 24, 2015

Updates to LHelp the CHM help viewer for Lazarus

LHelp is the help viewer that is included with Lazarus to view the chm files usually included in releases.

Some time ago some changes were made so that when F1 is pressed and LHelp is started, LHelp would load several help files such as the Lazarus Component Library(LCL) the Runtime Library(RTL) the Free Component Library(FCL) and several others. This is nice because then it's possible to search all the open files for keywords.

The down side to this is that every time a chm is loaded, the Table of Contents updates and the default page of the help file was rendered. So it was very visible as each help file was loaded in LHelp and not very pretty.

Additions the the protocol used for communication between LHelp and Lazarus, made by Reinier Olislagers, allowed LHelp to load the files while it was not yet visible and then be shown afterwards. This worked well but there was a long delay in the time F1 was pressed and the time LHelp became visible. Almost ten seconds on a modern multi-core desktop computer.

Investigation into the cause revealed a couple of slowdowns. The major cause was the speed at which the IPCServer.PeekMessage routine was polled. Only every 200 milleseconds. Sending commands to open 10 files would take 2 seconds. Also it used the syntax if IPCServer.PeekMessage(5) then ... which was not ideal. Changing this to while IPCServer.PeekMessage(5) do ... allows it to handle another message immediately if one is available.

Another factor was the way that Lazarus looked up the chm files to open. It would collect all files in any folder that could contain a chm file without using a file mask. Adding a mask for *.chm files sped this up significantly.

Speedups in LHelp were implemented by adding BeginUpdate and EndUpdate to the protocol. This allows chm's to be loaded without rendering the default page for each chm as it's loaded. When the last EndUpdate is sent, the final requested help topic is the only one rendered.

All of this results in a startup time of ~2 seconds. A big improvement over 10 seconds. The changes are committed in the svn version of Lazarus and will be available in Lazarus 1.4 Release Candidate 2


Saturday, May 10, 2014

(De-) Bug wars - A new hope

 "This are not the bugs you are looking for"

Well hopefully in future it will get easier to find those parts of your code, that joined the dark side.
The Lazarus Team is currently working on improving the Debugger in the IDE. And not just improving, but adding an all new shiny debugger.
In fact not just one either.

Here is what we are currently working on. In future we will offer 3 kind of debuggers in the IDE.

  1. The existing gdb based debugger: "GdbmiDebugger".
    And it's variations for gdbserver, and gdb over ssh.
    We will continue to maintain them, as they support additional targets (arm, powerppc, ...) that the new debuggers do not (or not yet) have.
  2. A gdb free debugger: "FpDebugger".
    This is still in its very early alpha stage. So far it will be for Intel targets only. And initial work concentrates on supporting Mac (which no longer comes with GDB, and urgently needs a replacement), and Windows 32 bits. But Win64 and Linux are planned too.
  3. A hybrid: "FpGdbmiDebugger".
    Like the existing GdbmiDebugger it uses GDB. In fact it inherits much of the functionality from GdbmiDebugger.
    But it will have its own routines to evaluate watches itself (without GDB). So it will be able to deal better with Pascal data. As a side effect watch evaluation will also be faster.
    Other debugging tasks, such as running or stepping the exe, and handling breakpoints are handled by the GdbmiDebugger code using GDB.

    But why this one at all?
    The same watch evaluation is available when using FpDebugger?
    Well, with FpGdbmiDebugger being GDB based, it will be easier to support more of the targets that GDB can support (like arm). It will still need some additions (e.g. a reader for arm executables, to read debug info) in order to do this. And FpGdbmiDebugger also has the potential to be extended to be gdbserver based and support remote debugging in future.

    The progress of FpGdbmiDebugger can be watched on its wiki page: FpGdbmiDebugger on our wiki.
    A page for FpDebugger does not yet exist.

The two new debuggers are developed in our SVN version (1.3). And if all goes to plan, then they will be part of Lazarus 1.4 (Probably sometime in 2015)

May Pascal live long and prosper (Oops wrong source).
May the force be with Pascal.

Sunday, August 25, 2013

Threads with Lazarus

It seems every time I use threads in a program I make, I need to lookup again how threads work. So if you're like me perhaps this will help you.

Here's a more complete tutorial to read.

Threads are a great way to do a large amount of processing in your program while allowing the visual part of your program to remain responsive. If you can split up the processing into several threads you can take advantage of modern processors multi core capability and complete a job in a fraction of the time.

Lazarus programs can use threads in GUI and Console programs. If you use threading in your program you should define the compiler option -dUseCThreads. This can be done in Project->Options->Compiler Options->Other - Custom Options. This does nothing under Windows but on any *nix it includes a needed threadmanager. If your program crashes with the first use of thread.Start; then this is probably your problem.

Now that your program is thread enabled here's some basic information about threads. You must subclass the TThread type and make your own thread type and override the Execute method.

The Execute method is never called directly in your program. It is the method the thread will run on it's own when it is started. If you are using MyThread.Execute then you are making a mistake.

Here's a basic example of a new thread type

type 
  TFooThread = class(TThread) 
  protected
    procedure Execute; override;
  end;

... 

implementation 

procedure TFooThread.Execute;
begin
  // do stuff 
end;

 
To create an instance of your thread you can use

FooThread := TFooThread.Create(True);

The argument True creates the thread in suspended state, meaning the OS thread is created but not yet run. If you use False then the thread begins and Execute is called immediately.  You can of course make your own constructor with whatever parameters you need and use inherited Create(False) there.

To start a thread you should use FooThread.Start. FooThread.Resume is deprecated as well as .Suspend which is not reliable on *nix's and can cause your program to hang.

Now your thread is running and working and making your life easier. Your program is snappier and you decide that you need to make your program display the progress your thread is making processing some data.

So in TFooThread.Execute you add Form1.ProgressBar1.Position := SomeValue.
Bad idea. It may work or your program could immediately crash or it might cause some other harder to find error that happens later. Never ever do this.

The reason this is so bad is because the GUI part of your program is run in a separate thread (duh!) and has it's own memory area. Changing the memory in one thread from another needs to be coordinated carefully. You should never change a LCL control value from a thread other than the main process.

A way to update the main thread from another thread is the Synchronize(@SomeProc) method. The Syncronize method, which is called within a created thread, causes the thread to pause and wait for the main thread to call a procedure. Also see CritialSections from the link at the beginning of this article

When your thread terminates you should assume that any code in it's destructor may be called a thread other than your main process thread, especially if you set FreeOnTerminate to True. If you assign a handler for the OnTerminate property then that procedure will be run in the main thread.

After all the code in the Execute method is run your thread cannot be restarted. You will have to free and create another instance of the thread type you need. It's common to include while not Terminated do begin ... end around the code inside the Execute method in order to use a thread multiple times without having to recreate it.

Most of the basic stuff I have run into is now covered. Go code, or read some more: Threading Tutorial on the Wiki

Tuesday, August 28, 2012

Gtk3, GObject Introspection and Free Pascal

A while back the Gtk community started a project called GObject Introspection. In short it exports the Gtk and Glib api, as well as many others, to an easily parsed xml format.

The result is gir2pascal.

gir2pascal can create bindings to pascal from any library that supports gobject introspection in just a few moments! The result is that Gtk3 bindings have been created fairly easily for pascal and can easily be updated simply by running gir2pascal against the latest version.

Here is part of the XML code from the Gtk3.gir file relating to the caption of the button:

<class name="Button"
           c:symbol-prefix="button"
           c:type="GtkButton"
           parent="Bin"
           glib:type-name="GtkButton"
           glib:get-type="gtk_button_get_type"
           glib:type-struct="ButtonClass">      
      <implements name="Atk.ImplementorIface"/>
      <implements name="Actionable"/>
      <implements name="Activatable"/>
      <implements name="Buildable"/>
      <constructor name="new" c:identifier="gtk_button_new">
        <return-value transfer-ownership="none">
          <type name="Widget" c:type="GtkWidget*"/>
        </return-value>
      </constructor>
      <method name="get_label" c:identifier="gtk_button_get_label">
        <return-value transfer-ownership="none">
          <type name="utf8" c:type="gchar*"/>
        </return-value>
      </method>      <method name="set_label" c:identifier="gtk_button_set_label">
        <return-value transfer-ownership="none">
          <type name="none" c:type="void"/>
        </return-value>
        <parameters>
          <parameter name="label" transfer-ownership="none">
            <type name="utf8" c:type="gchar*"/>
          </parameter>
        </parameters>
      </method>
      <property name="label"                construct="1"
                transfer-ownership="none">
        <type name="utf8"/>
      </property>
 </class>
  
One improvement over the current (Gtk2) bindings in use is that Pascal objects (not classes) have been used in place of records. The advantage is that GObjects, a C style quasi-object, can be accessed in an object oriented way instead of the flat C functions we use currently.

Here is the corresponding generated pascal code from the XML above:

type
  TGtkButton = object(TGtkBin)
    priv3: PGtkButtonPrivate; 
    function new: PGtkButton; cdecl; inline; static;
    function get_label: Pgchar; cdecl; inline;
    procedure set_label(label_: Pgchar); cdecl; inline;
    property label_: Pgchar read get_label write set_label;
  end;

function gtk_button_new: PGtkButton; cdecl; external;
function gtk_button_get_label(AButton: PGtkButton): Pgchar; cdecl; external;
procedure gtk_button_set_label(AButton: PGtkButton; label_: Pgchar); cdecl; external;

implementation

function TGtkButton.new: PGtkButton; cdecl;
begin
  Result := Gtk3.gtk_button_new();
end;

function TGtkButton.get_label: Pgchar; cdecl;
begin
  Result := Gtk3.gtk_button_get_label(@self);
end;

procedure TGtkButton.set_label(label_: Pgchar); cdecl;
begin
  Gtk3.gtk_button_set_label(@self, label_);
end;

You can see that we are using objects instead of records, compare this to the current Gtk2 bindings:

type
  PGtkButton = ^TGtkButton;
  TGtkButton = record
    bin : TGtkBin;
    event_window : PGdkWindow;
    label_text : Pgchar;
    activate_timeout : guint;
    flag0 : word;
  end; 

function gtk_button_new:PGtkWidget; cdecl; external gtklib;
procedure gtk_button_set_label(button:PGtkButton; _label:Pgchar); cdecl; external gtklib;
function gtk_button_get_label(button:PGtkButton):Pgchar; cdecl; external gtklib;


Before, our code would look like this:

procedure Foo;
var
  Button: PGtkWidget;
begin
  Button := gtk_button_new;
  gtk_button_set_label(PGtkButton(Button), 'Hello World!');
end;


But now it's possible to use this instead:

procedure Foo;
var
  Button: PGtkButton;
begin
  Button := TGtkButton.new;
  Button^.label_ := 'Hello World!';
end;

As you see it's a bit shorter to type the second way. Although either will work since the 'flat' functions are still available to use.

Using objects instead of records it is of course possible to access inherited methods and properties with greater ease than before, especially when using the code completion feature of Lazarus (which is extremely close to 1.0 now!). Button in the example above descends from GtkWidget which has the property tooltip_text.

This can be accessed with
Button^.tooltip_text := 'Don''t click me unless you want to!';
whereas before you had to do
gtk_widget_set_tooltip_text(PGtkWidget(Button) ,'Don''t click me unless you want to!');  

Here's the HelloWorld example included with the bindings, modified to have a tooltip.


 The Pascal Gtk3 bindings are not yet well tested. There are a couple of examples in the Lazarus-ccr repository in the folder /bindings/gtk3/examples/ including an example of GtkWebkit.

Perhaps you would like to try it out :)

Thursday, August 2, 2012

Preparing for Lazarus 1.0 (RC1)

Just to announce: Lazarus is preparing to go 1.0.

The first release candidate for the new Version has just been made public on sourceforge. Please test it.

You can find the announcement for the RC here: http://forum.lazarus.freepascal.org/index.php/topic,17717
And a list of what changed is here: http://wiki.lazarus.freepascal.org/Lazarus_1.0_release_notes

Friday, February 17, 2012

Pascal does a strong showing in the Linux Questions Members Choice

Of course that internet quiz is not something scientific but it is nevertheless good news. Both Pascal and Lazarus made a strong showing in the Linux Questions Annual Members Choice Awards, competing with software sponsored by huge corporations. Other software written in Lazarus also appeared in the show, such as Double Commander and LazPaint.

Let's start with Lazarus itself running against other IDEs:



And how Pascal / Object Pascal as a language fared well too (despite someone mistakenly having added it as "Free Pascal"). It is pretty hard to see because of so many multiple lines, so I added a bigger line connector, but anyone can check in the full description of the results here: http://www.linuxquestions.org/questions/linux-news-59/2011-linuxquestions-org-members-choice-award-winners-928502/



See also how Double Commander fared:



And LazPaint:



If there was a category for Accessibility probably the Virtual Magnifying Glass would appear =)

Felipe Monteiro de Carvalho