Recent

Author Topic: Unified Life Models version 6.0  (Read 4647 times)

bienvenu

  • New member
  • *
  • Posts: 6
Unified Life Models version 6.0
« on: July 01, 2017, 11:17:36 am »
Dear Lazarus users,

I am happy to announce the release of the Unified Life Models program, version 6.0.

ULM is an open-source software enabling the simulation and analysis of deterministic and stochastic discrete time dynamical systems for population dynamics modeling. It was written in Delphi more than 20 years ago, and had been used for teaching and by some researchers since. However, the lack of Linux support by Delphi and its uncertain future made us look for an alternative.

Free Pascal and Lazarus have made it possible -- and relatively easy -- to make ULM cross-platform again, and even to improve it.

We also turned to this forum to ask for help with compiling on Mac, and got prompt and helpful responses. Someone from this forum even stepped in the project to help us distribute the program on Mac (something we probably wouldn't have been able to do properly without him).

Therefore, I would like to thank the whole Lazarus community for making this possible! :)

Finally, if some of you are interested: I won't work on this, but if some of you are interested in developing scientific applications with Pascal, there are more projects from the same researchers to be ported from Delphi to Lazarus: see here, here and here.

Best,

François for the ULM development team

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3998
  • I like bugs.
Re: Unified Life Models version 6.0
« Reply #1 on: July 01, 2017, 01:07:41 pm »
I downloaded it from:
 git clone https://gitlab.com/ecoevomath/ulm.git
It is correct?
I am testing on Linux. The project has Debug and Release build modes. With Release mode it runs although I don't know how to use it really.
Switching to Debug mode gives a range check error at the start, in procedure tab_arc_en_ciel;
Var i goes > 255 at:
Code: Pascal  [Select][+][-]
  1. arc_en_ciel[i]:= rgb(0,0,255-k);
You should test the code with Debug mode.

Another one in procedure TSynUlmHl.Next;
String FLineText is read past its end. You have defined the Debug mode but not used it at all. How come?

There were also wrong integer types for milliseconds which caused overflow.
I fixed all the errors and created a patch. Please test and apply.
It can be applied with "git apply ..." or with "patch -p1 < ...".

Before the fixes I got a strange effect in the graph, it changed and its scale increased when I waved mouse over it. Now it is gone, some memory corruption must have caused it. I don't believe it can be reproduced, such errors are typically semi-random.
There is one more problem left related to freeing resources. The application refuses to close fully, meaning the IDE has the red close button active and closing must be forced. This happens only with debug flags. Should be debugged more ...
I have tested with the example model of big horny sheep. :)

One more thing: remove the session *.lps files from revision control. The idea of a session is to be local. You don't want your editor file history to be forced to other people.
« Last Edit: July 01, 2017, 02:14:57 pm by JuhaManninen »
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

bienvenu

  • New member
  • *
  • Posts: 6
Re: Unified Life Models version 6.0
« Reply #2 on: July 03, 2017, 12:13:21 am »
Hi JuhaManninen and thanks for your help,

Quote
I downloaded it from:
 git clone https://gitlab.com/ecoevomath/ulm.git
It is correct?

Yes!

Quote
You have defined the Debug mode but not used it at all. How come?

Most of us do not use the IDE. The debug mode was lazbuild's default and we defined the release mode to reduce the size of the compiled binaries. Then it was just as easy -- and seemed to make more sense -- to add an option to compile with debug mode rather than remove it, even if we've never actually used the debug mode.

Then, since we didn't use the debugger and no error was ever printed out by the program during execution, the errors you point out simply went unnoticed.

By the way, if these errors occur (and then I assumed are caught) during the execution of the program, is there any way we could have them printed out to stderr or stdout?

Concerning the errors you pointed out: they concern part of the code I haven't looked at (what I did was mostly rewrite the GUI and prepare the Linux distribution). It indeed looks like there is a bug with tab_arc_en_ciel, and it looks like this portion of the code should be rewritten using a more modern coding style (I think this portion was probably written around 1995); I'll as the original author about it.

I'll forward your other remarks and your patch to the team.

Quote
One more thing: remove the session *.lps files from revision control. The idea of a session is to be local. You don't want your editor file history to be forced to other people.

Yes, that makes sense! I'll do it right away.

Thanks again for taking the time to try the program and patching it!  :)

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3998
  • I like bugs.
Re: Unified Life Models version 6.0
« Reply #3 on: July 03, 2017, 12:05:45 pm »
Most of us do not use the IDE.
How do you edit your code then? GEdit? Kate? Notepad?
Hint: Lazarus IDE is quite good.

Quote
... even if we've never actually used the debug mode.
Uhhh ... ok :(
As a result your code had buffer overruns and overflows like a typical C-program from the last millenium. FPC's range and overflow checks catch them all. Please use them always when developing and testing code. Use the Release mode only for the final binary delivered for users.

Quote
By the way, if these errors occur (and then I assumed are caught) during the execution of the program, is there any way we could have them printed out to stderr or stdout?
Exceptions are thrown then. However Lazarus IDE lets you go to the problematic line with one click. I don't understand why you would not use it.  %)
« Last Edit: July 03, 2017, 12:13:15 pm by JuhaManninen »
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 10993
Re: Unified Life Models version 6.0
« Reply #4 on: July 03, 2017, 12:21:01 pm »
@Juha

Typical case of the mad scientist  :D
The work is highly impressive, though. This kind of modeling has also other applications.
The average programmer productivity is 4-5 hours per day. Peak performance 72 hours for short bursts. MTBF is 1 second or less.

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3998
  • I like bugs.
Re: Unified Life Models version 6.0
« Reply #5 on: July 03, 2017, 01:49:08 pm »
Finally, if some of you are interested: I won't work on this, but if some of you are interested in developing scientific applications with Pascal, there are more projects from the same researchers to be ported from Delphi to Lazarus: see here, here and here.
I checked the first one, https://www.biologie.ens.fr/~legendre/zen/zen.html.
It also has ELF binaries for Linux, but no sources.
The binaries require QT shared libs. I quess it is made with C++ and QT.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

bienvenu

  • New member
  • *
  • Posts: 6
Re: Unified Life Models version 6.0
« Reply #6 on: July 04, 2017, 05:18:20 pm »
Quote
How do you edit your code then? GEdit? Kate? Notepad?

The main author used the Delphi IDE to write the program, the rest of us used our usual text editor to port it to Lazarus (Vim in my case, the others use Emacs).

Quote
Hint: Lazarus IDE is quite good.

I do not question that; however I've become virtually unable to edit text with anything else that Vim, and more generally I tend to avoid point-and-click programs.

Of course it's a matter of personal taste, and that does not mean that I consider such programs to be inferior whatsoever. In fact I'm genuinely convinced that GUI's are the best solution for a lot of people, which is why I got involved in rewriting the GUI of this program, and why I have written GUIs for other programs (mostly GTK2 GUI's for OCaml programs and Tk/GTK2 GUI's for Python programs).

I that case, I re-wrote the GUI by editing the .lfm files. It takes a bit of time to understand how the positioning of elements works and get the syntax, but once this is done it's not as much work at it looks.

Quote
Please use them always when developing and testing code.

Yes, it looks like a sensible thing to do. Apart from the main author, none of us had never used Pascal before so we just started "heads on" without really knowing what the typical workflow is to build a program. Thus, we did more-or-less the same thing that we do when using our usual programming languages -- edit the source from Vim/Emacs and use a makefile to compile.

In my case I come from OCaml, where the debugger is not so much used because the philosophy of the language is to use the type-system to allow the compiler to catch as many errors as possible during compilation, and let the garbage-collector manage the memory. As a result, to be honest, the idea of using a debugger did not even cross my mind.

Quote
Exceptions are thrown then.

What I do not understand then is that when I worked on the program and tested it, I always started it from program from a terminal and -- apart from one or two GTK2 warnings -- no error / warning was ever printed to stdout / stderr. With most high-level languages I've used, when the program is started from a terminal and an error is raised and not caught, it's printed to stdout. But here I never got any error message.

Quote
I don't understand why you would not use it.

As I said I'm not against the idea of using a debugger, but I'd rather use one that does not force me to use the Lazarus IDE and let's me use my favorite text editor. Is there any such tool (besides the general purpose ones such as Valgrind).

Quote
I checked the first one, https://www.biologie.ens.fr/~legendre/zen/zen.html.
It also has ELF binaries for Linux, but no sources.
The binaries require QT shared libs. I quess it is made with C++ and QT.

Yes, that is normal: the program is currently written in Delphi (hence the Qt dependencies on Linux) and not open-source. However, this puts it at high risk of becoming bit-rotten, especially since the main author is not actively developing these programs anymore. Therefore, I'm sure he would be favorable to rendering these programs open-source and porting them to Lazarus, as we've done with ULM (even though I'm no sure he'll have time to work on them).

I was initially planning on working on this but since (1) I'm no real Pascal programmer and (2) I have a PhD thesis to finish, I won't do it anytime soon. I think the amount of work is reasonable though, especially for an experienced Lazarus user -- which is why I mentioned it here.  ::)

@Thaddy

Quote
The work is highly impressive, though.

Even more so when you realize that everything is reimplemented from scratch! A lot of things which one would nowadays let be handled by a third-party library have been reimplemented by the author:
- there is a parser and a compiler for the language used to describe models.
- all the numerical routines (e.g, computing eigen-elements) have been reimplemented.
- even plotting utilities have been reimplemented.

This of course goes against modern programming practices, where the idea is to try to "avoid reinventing the wheel", but it makes the program very interesting on many levels. For those of you who know it, it reminds me a bit of FontForge (whose author single-handedly reimplemented a whole GUI toolkit because at the time when he started developing the software he was not satisfied by the alternatives).

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3998
  • I like bugs.
Re: Unified Life Models version 6.0
« Reply #7 on: July 04, 2017, 09:47:46 pm »
What I do not understand then is that when I worked on the program and tested it, I always started it from program from a terminal and -- apart from one or two GTK2 warnings -- no error / warning was ever printed to stdout / stderr. With most high-level languages I've used, when the program is started from a terminal and an error is raised and not caught, it's printed to stdout. But here I never got any error message.
You did not get error messages because you did not enable range and overflow checks.
The exceptions are shown in terminal and the widgetset catches them, too, showing a messagebox.

Quote
As I said I'm not against the idea of using a debugger, but I'd rather use one that does not force me to use the Lazarus IDE and let's me use my favorite text editor. Is there any such tool (besides the general purpose ones such as Valgrind).
Ok, I never learned Vim but its users claim it is the fastest way to edit text. I guess I just have to believe it.
Mixing Vim and Lazarus is tricky. I can only recommend that you test and debug your code in Lazarus IDE and fix some small errors using its editor. Use Vim for the creative bulk of editing.
I certainly don't recommend creating GUIs by editing the .lfm files. The form designer is so much better and easier. Did you even try it?
Uhhh, this is quite bad honestly ... please give Lazarus IDE a chance!

Quote
Yes, that is normal: the program is currently written in Delphi (hence the Qt dependencies on Linux) and not open-source. However, this puts it at high risk of becoming bit-rotten, especially since the main author is not actively developing these programs anymore. Therefore, I'm sure he would be favorable to rendering these programs open-source and porting them to Lazarus, as we've done with ULM (even though I'm no sure he'll have time to work on them).
Yes, the source must be there before it can be ported to Lazarus.
Now it is apparently ported to Linux using Kylix which is an old and dead product. Porting to Lazarus cross-platform should be easy because the code already has directory separators right and does not call WinAPI for sure.
The "Delphi Converter" in Lazarus even fixes the "Q..." unit names. I could run it through the converter once I get the sources.
« Last Edit: July 04, 2017, 09:50:21 pm by JuhaManninen »
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

 

TinyPortal © 2005-2018