5th of March – Vide 2.12 RC01

Ok, that didn’t last long.

Another Release Candidate. I fixed one bug and added some additional stuff Peer wanted to look at.

Why is it so “difficult” to do a “native packaged” version?

Actually the native packaging is just one “switch” in the Netbeans GUI – not much to do here. What I am trying to do – and where there might still be a couple of bugs – I want Vide to behave like it did before!

The changes that I had to implement are about the same changes I did last year, when I changed Vide to be “startable” from everywhere.

See, as I said – the home directory of a Java application is ALWAYS the directory Java was started from. Now Java is started not from the “Vide” directory anymore but from a subdirectory (Vide.app – or even a directory or two deeper).

All settings, all file associations, all project data within Vide are kept as “relative” paths. The base of these relative path information used to be the Java start directory (I will call that from now on “Java_home”) – but now the base of the relative paths must be the directory all these Vide directories reside in (which I will call from now on “Vide_home”).

Relative paths as configuration entities are “good” because we can move Vide around or copy project files to another Vide instance or similar things. This I deemed “good” because it is very “easy” for the user.

But I had to change every file access within Vide – again!

A simple vectorlist load used to be:

...
String filename = "Vectorlistname.xml";
String path = "xml/vectorlists/"
File f = new File(path+filename);
...

etc. as you see the File was “created” with relative path information.

Loading the file with above code succeded because the relative path would access the correct directory – the one where Vide was started from. Now I must make sure the above “path” is accessed from Vide_home not from Java_home. In order for that to succeed I must convert the relative path to an absolut path, and this conversion must result in the correct directory.

The “bad” thing with that is, even when I do a:

String here = f.getAbsolutePath();

It does not help all that much, since that is the absolut path to the “Java_home”.

To remedy I have created 4 additional functions:

  • String makeVideRelative(String fullpath) – which takes a full path and builds a Vide_home relative path from it
  • String makeJavaRelative(String fullpath) – which takes a full path and builds Java_home relative path from it
  • String makeJavaAbsolute(String relName) – which actually is more or less the f.getAbsolutPath(), it takes the given relative path and builds an absolut path
  • String makeVideAbsolute(String relName) – which takes a given relative path and builds an absolut path, but assumes the given path was relative to Vide_home, not to Java_home

What follows is, that I now must do all file accesses using absolut paths (which are mostly the result of “makeVideAbsolute(String relName)“. These were 100dreds of changes – and I am not certain I got them all, or if I accidently mangled some relative and absolut paths. This is why I chose to do a Release Candidate, in the hopes some people may test this – and report errors (or correct workings).

Release Candidate downloads

Not available. A new vide “full” version is available (or will be shortly).


Tagged on: ,

3 thoughts on “5th of March – Vide 2.12 RC01

  1. Peer

    I am downloading right now. Here is already some feedback: I am using Vide, and it is awsome. The way you are handling all my questions (and requests) is exceptionally great!

    So, “Hello World:” I asked Malban for support with a stack pointer issue just two days ago, and now here is a new version with a respective feature included. That is really great. Many thanks!

    Will start testing as soon as the download is completed.

  2. Peer

    That worked great! Nailed down two bugs with the new stack pointer tracking feature 🙂

    Explanation: When programming in C with gcc6809, the compiler creates stack frames for local variables and for passing arguments to functions. The stack starts at the upper user RAM boundary and grows towards lower RAM adresses. Global RAM variables (which are very useful when doing C on the Vectrex) are instantiated from the lower user RAM boundary upwards. if you have lots of such variables and if functions calls get too deeply nested, then the stack overuns the RAM variables and corrupts the data.

    The new features Malban implemented confirmed one of the bugs to be caused by exactly such a situation, and also confirmed that the other bug was not stack related. Very, very helpful!

    Great stuff, many thanks again!

Leave a Reply to Malban Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.