Release: NumeRe v1.1.2rc1

Erik Hänel — Tue, 24 Sep 2019 08:56:57 -0000

Today we publish the new release candidate no. 1 of the version 1.1.2. We appended the changes log for reasons of completeness. A brief overview may be found in the following:

switch is a new control flow environment
Clusters are new data types, which may contain numerical values and strings in mixed order
We created new string functions, which may determine the types of the contained characters
We improved the editor: saving of bookmarks, multi-selection pasting, autocompletion of LaTeX commands, warnings about global variables
The console may now use HOME, END and CTRL-LEFT, CTRL-RIGHT correctly
Animations include now an additional rendering step, during which the animation is cached to run the animation more fluently and less resource-consuming afterwards
We improved the debugger massively: it now features many standard functions like step over block, execute next instruction and leave current scope
The inline flag of procedures was improved and allows real inlining, which may offer runtime improvements of a factor 20
NumeRe now offers an integrated version control of files, which are stored in one of the default paths and which are edited in the editor
The dialog command provides graphical dialogs to interact with the user
The refactoring functions were improved and may now be restricted in the search range. Additionally, each symbol renaming is logged
NumeRe may now calculate a dependency tree of a procedure (Tools menu)
NumeRe offers a package creator, which may create an install script from a provided set of procedures (Tools menu)
The documentation window was redesigned and features now an index tree on the left and a toolbar on the top, which provides the history functions and the possibility to print a documentation article
Many fixes and improvements

Version control systems - DevLog #007

Erik Hänel — Mon, 15 Jul 2019 06:32:34 -0000

Some weeks ago,

we had the discussion, why we're using Apache SVN. Many of our colleagues use git as version control system and but we do not. They like the powerful features of git, which may offer many freedoms in their usage. And this might be one of the major issues in the whole discussion about SVN and git: SVN seems to restrict the freedoms of their users. I do not want to argue against it, because it's true. However, it's not always an issue and I'd like to explain, why that might be the case.

The issue with freedom

Freedom always comes at a price. This price is the responsibility that you take for all your actions. Freedom may offer you great opportunities, but it also requires that you always think about the consequences, which you might face. Thinking about version control systems: git offers many freedoms but it also requires your attention while working with it. If you decide to push your changes in another order than the historical one (which is possible) you might break the corresponding branch in all other repositories. If you do not push all your changes, you have a local version control but you will lose all your code, if your hard drive fails (which happened to me a few years ago). So you're responsible for archiving your code revisions by yourself.

As a disclaimer, I did use git in the past. But, for example, to understand the difference between the functions fetch, push, pull and commit took me hours, which would probably be more useful during an implementation of a new feature.

Although I like freedom and the responsibility coming with it, there are some cases, where I prefer to push away the responsibility: version control systems are one of them. I simply do not want to think about what's happening in my repository. I simply want it to work and to safely archive my code changes. If that restricts my freedoms, fine. I willingly give that away for a repository system, which cannot be broken by its users.

TLDR: I prefer Apache SVN, because it restricts the actions, which you can do with it. It is just simpler than git.

The reason why - DevLog #006

Erik Hänel — Thu, 21 Mar 2019 19:01:13 -0000

Is it possible

that I'm silly? What's the reason for me to spend most of my free time working on an open-source project like NumeRe? I'm not kidding---that's a serious question, because from an objective, financial viewpoint there's really no reason to do so. I mean, of course I'm learning interesting stuff during my coding sessions, but I also could have done so by programming some commercial application. And, in fact, if I would work for a company, which would sell self-coded applications, I would most probably not work on this project, although the reason is different: after 8 hours of programming, I'm simply exhausted and neither able to produce some reasonable code nor even think of possible solutions.

Well, the question still persist: why am I doing this? Is it possible that I'm simply bored at work during the day times and need some sort of compensation? Certainly not---I really like my daytime job, because it's challenging everyday. Well, is it then possible that I'm bored at home? Of course not! My wife and my cat (Every physicist should have a cat!) are very demanding and they don't like (however accept) when I'm spending hours in front of my computer inspecting code and smashing bugs.

The actual reason is most probably that I like the concept of open source software, because I can look at it, if I don't understand, what it's doing. I like the idea of being able to modify every software, to add or remove features. My major competitor is probably also one reason, why I code an application: I dislike many design decisions being done in this software and I want to build an application, which outclasses it in these aspects.

TLDR: I'm developing NumeRe, because I like the concept of open source software and I dislike silly, expensive closed source.

Overused identifiers - DevLog #005

Erik Hänel — Wed, 20 Mar 2019 06:56:03 -0000

I complain quite often

about another numerical framework. It defines a domain specific language, where many identifiers are overused depending on where they are used in the code. If the identifier is used at the beginning of a line, then it is most probably a flow control statement, but if used in an expression, it is either a function itself or a dimension constant. From a software architects viewpoint in my opinion that's bad design and should not be implemented.

Well, some of you might already have recognized that I'm talking about my major competitor. And some of you might also know that the editor shipped with the other numerical framework is even worse than this design decision: they 're somewhere around version 7.0.0+ and it still does not support a reasonable syntax highlighting or mouseover tooltips? Come on! That's not too difficult to implement!

However, today I faced a similar situation in my own project. I want to implement dimension constants for tables, which will automatically contain the number of lines and columns and should therefore be called lines and cols:

table(:, 1) = table(5:lines-5,cols-1);

This is quite intuitive, isn't it? The issue is, that I'm already using these two identifiers as methods and as command parameters and therefore my lexer has issues to determine, whether I want the identifier to be used as method, as parameter or as dimension constant. Due to the fact that methods start with a dot, the lexer could distinguish between methods and the other two, but not between the dimension constant and the command parameter.

The only reasonable decision was, to derive other identifiers for the dimension constant, because I do not want to break backwards compatibility, if it's avoidable. As a consequence, I named the identifiers nlines and ncols, which shall mean number of lines and number of columns. Although I'm not too pleased about this identifiers, they're a good compromise between the original identifiers and other, more lengthy names.

TLDR: I faced the situation that I was trying to overuse some of the identifiers of NumeRe. I want to avoid ambiguity, so I had to derive new names for the identifiers.

Legacy code - DevLog #004

Erik Hänel — Tue, 19 Mar 2019 19:12:27 -0000

I think,

everyone of us has this spot in his or her code, which he or she does not like. It's ugly, poorly written code back from the days, when we started our applications and learned programming. Code from these days is often single-function code, with many duplicates. However, it's working code, of course, and thoroughly tested--which is the reason, why this code is still there.

I have this spot in NumeRe's code, too. And, to be honest, there are more than one spots. They are working and not that central code sections. However, each time, when I have to change something in these sections, I have to fight against my own sickness and the strong feeling, to hit CTRL-A and DEL afterwards. I have reworked some of these sections already (those were mostly more crucial parts), but refactoring is not the top priority in my daily work. I want to focus on new features, which enhance the functionality of NumeRe. And I don't want to look back into bad written code, but rather into newer, elegant solutions.

Therefore, I have the refactoring tickets on my list. And the day will come, that I erase the poorly written code and replace it by a newer, more elegant solution. But this day is not today--and everybody knows: never touch a running system

TLDR: Everyone has bad written code, which he or she just doesn't refactor.

NumeRe wants you! - DevLog #003

Erik Hänel — Sat, 16 Mar 2019 19:13:20 -0000

Since 2013,

I'm working more or less alone in this project. Of course I'm using libraries such as MathGL, TinyXML-2, GSL and so on, but more or less the whole work apart from the functionality provided by libraries was done by me. You bet that this is a lot of work to be done and it's really time-consuming. Well, at least during the testing phase I'm supported by a lot of people, although it's not a real testing phase but more a production test.

Therefore I keep on asking for support. Since about half a year, I'm supported by two new co-workers: Jonas and Rudolf. They have just started working on the source and are now trying to understand the whole bunch of code. However, they've already implemented some minor stuff. It's planned for the future that they will support me even more.

If you're thinking about supporting our team during the development, then you're welcome. You might either comment below this post or write us a mail. The following bullet points name our requirements. However, it's not an issue, if you're not fulfilling every requirement.

Some knowledge in C++
Some knowledge about the GCC Toolchain or experiences with MinGW/TDM-GCC (we're using the latter)
Some experiences in programming and debugging
Development is on Windows, but feel free to port it to Linux or Mac
Helpful: experiences with Apache SVN for version controlling
Helpful: experiences with wxWidgets, which is our graphical framework
Helpful: experiences with Code::Blocks, which is our IDE

TLDR: if you want to support the development of NumeRe, then you're welcome in our team. Note the requirements displayed above and get in touch.

What's your use case? - DevLog #002

Erik Hänel — Sat, 16 Mar 2019 13:46:04 -0000

Some days ago

one of my colleagues asked me, if I can describe NumeRe by its central use case. I really was baffled by this question. How might I describe such a complex application by only one use case, even if it is the central one? Some of you might have experiences with UML and use case diagrams--most applications do not feature the one and central use case, do they?

I escaped the situation by talking about the complexity of NumeRe and that it's not possible to name its one and central use case. However, this answer was not really satisfying--neither for my colleague nor for me. Sadly, I was not able to derive a better answer to his question.

Now it's the time to rethink about this situation and derive a more elaborate answer. First, we have to think about what NumeRe provides, i.e. identifying its key features:

Intuitive plotting algorithms with publication-ready results (i.e. plot sin(x) will create a plot of sin(x) over the default range of -10 to 10. No more input needed)
Numerical calculation functionalities including more complex evaluations using procedures and flow control statements (like if, while and so on)
Functions for data analysis like statistics, FFT and FWT algorithms, an ODE solver and a Leuvenberg-Marquardt fitting algorithm
Many input and output data formats. although this it not really a key feature ...

Wait--was that all?

I am not able to identify more than 3 key features? Then why is it so difficult to name the one and central use case of NumeRe? What am I doing wrong? Well, let's make that short: most probably it's not difficult and I'm not really doing something wrong--I am just too deep down into the code and all the tiny little features provided by NumeRe. It's time to step back from the details and take a look at the application as a whole.

And after I had done this, it was really simple:
NumeRe is a framework for data analysis, numerical calculations and data visualisation.

That's all--nothing more left to say. The one and central use case is now fixed. Everyone, who reads this post will probably do better than me, if he or she may stumble upon a similar situation. But that is the reason, why we're posting this stuff.

TLDR: after being asked by one of my colleagues to describe NumeRe's central use case, I needed to step back from the code to identify it.

Introduction - DevLog #001

Erik Hänel — Sat, 16 Mar 2019 13:24:36 -0000

Last night,

we read at the project promotion site of SourceForge that we're encouraged to use the blog available here at SourceForge to write about NumeRe, especially, if we were doing a new release, because that would bring our releases to the attention of the SourceForge community team.

Nice idea, isn't it?

Yes, this was our first thought. But how would it look like, if we were only posting updated during a release? Okay, there are the regular updates in SVN and the notification, when we work on tickets. However, a blog containing only post about releases doesn't look very active, does it? So, we thought about content which would fit into this blog and won't need much deep-thinking during creation.

Then we came up with the idea on writing a non-regular DevLog. Some kind of documentation on what we're actually doing during our development process. This shall also include the things, which we've learned during the coding and debugging processes, and which will probably help others but at least all newcomers to our team. Additionally this would give us the possiblity to provide some insights in the ideas behind NumeRe.

We're also thinking about bringing the series describing NumeRe's features, which we started at Facebook, here to SourceForge, because it might provide us better interaction and the posts will not disappear randomly.

TLDR: we'll post non-regular development updates in this DevLog. Probably this will also include a series describing NumeRe's features, which was originally started on Facebook.

Recent posts to devlog