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