The ugly fact first - to be honest - i screwed it up: I had a number of fatal
computer problems. The bad electrical installation here at the burmese/thai
border was too much for an independent power supply peak filter. I lost two
mainboards and 4 harddisk in only 3 month during rainy season 2007. And
to make it worse my external USB backup disk lost a fight on the desktop with
my cat. Rest in peace my beloved 250 GByte.

I made daily backups on CDROM but only from the current source code i'm working on.
In this codebase almost every single line changed in the past year. So there is no
way to update the 0.7.13 version and fix the bugs that occurred in the meantime.

Unfortunately there is a second factor in the current desaster. After 0.7.13
i started a huge refactoring that i planned to get done in one year. It requires
to change almost all of the 250.000 lines of code that i've written for Arachno Ruby.
I still underestimated it by at least 9 to 12 month. The reason for this is pretty simple
but you do not find it in too many books.

First it is the motivation factor. If you refactor such a huge codebase you
run out of motivation easily and to not let this happen you have to do things
that give you some new ideas and keeps your interest up. This is the reason that
you find an integrated HTTP Server, EMail Test Servers and the SQLite Frontend
(it's generic, but i only have a SQLite database driver now) in the new version.

The second problem is the temptation you run into when you touch an old piece of
code where you learned with your own experience and the user feedback that there
are so many ways to improve it. If you have to touch and understand this code
again it makes sense to do more then just adopting it to a changed environment.
This is where weeks start to sum up to a long delay. But in the end i think
it is good to do it. And i believe that the real reason why a lot of software
is bloated is because they never changed some fundamental weaknesses. Always
adding new features is not a good idea. New clever integrated features are good,
they can simplify a lot of things and still fit seamlessly into the whole program
if you take the time. Feature richness does not automatically mean bloated.



I really apologize for this. And to show you that this was definitely not an intended
situation i will give everyone who ever purchased Arachno free updates to
the next version and all updates for the next 6 month after the final 0.8 release even
if your timespan for free updates already expired. So everyone will get a rock solid
new version again.

Arachno Releases of 17.March 2008

Enough said, lets see what is done. Here are two download links to the Ruby
and PHP version of Arachno. They are totally unusable for daily work except the
database and email parts which are independent from other subsystems and
considered final.

If you already have the 0.7.13 version installed please choose a different directory and program
group for installation because the versions are not compatible. You can use your
existing license key for testing or just use the 30min. emergency session.

Arachno Ruby IDE

Arachno PHP IDE

You will see none of the Ruby specific features are available at the moment.
They are still waiting on my harddisk for the big bang integration build. This
release is just there to show you what is going on. I will publish new releases
here every month from now. So that you can see there is a progress and can estimate
when your required features are available.

What has changed?

Well if you look at the demo program it's hard to see any part that looks and
works the same like previous releases. The following list is not sorted in any order,
just written directly from my mind.

• New Project Handling Now multiple projects can be open at a time and it is
  possible to share project settings on different computers. This turned out to be the
  time killer number one for the refactoring. The problem is that with multiple projects
  you really have to do add another indirection to every single subsystem and feature.
  
  
  
  
• Project File Handling I removed the hotfiles toolpane and added it to the
  file browser. Makes more sense this way. There is also a file system browser for
  fast browsing through your file system together with a directory bookmark feature.
  This is usefull for people who use Arachno only as an editor and don't have large
  project folders.
  
  
  
  
• Scripting Not so visible at the moment. But the idea is to give all Arachno
  users full access to the IDE features in there favourite programming language. Wrapping
  the API's take time and the documentation will be published with version 1.0.
  
  
  
  
• Snippet System It's not only the text snippets - it's about getting the new
  ideas that were introduced with the popular TextMate Editor into Arachno. While TextMate has
  without doubt some good ideas it IMHO takes the regular expressions idea too far. Making
  all the snippet and language code in fact read only. Arachno will use scripting for this.
  The new snippets are setup in the plugins window and are expanded with an
  overloaded "Tab" character.
  
  
  
  
• New Window System The one toolpane on each side was eating too much
  screen real estate. This is now changed. The output and grep buffer are also not longer
  displayed in the editing area of the main window. This emacs like behaviour was annoying
  for many people.
  
  I also added a nicer Drag&Drop
  handling for screens and objects. DD is just carrying a few serious design errors
  with it - like the way to change between operations (which ones?) with different
  modifier keys (which ones?) and adding custom cursors instead of overlays to the
  system cursor.
  
  
  
  
• Open File Handling Each window displays a different set of open files.
  The tab row on the top is displaying the eight most recently used files. The open
  file window has lists for the changed and recently used files.
  
  
  
  
• Command System One more feature which forced me to touch all code
  files. The way TextMate is handling the keybindings is really good. So i decided
  to "steal" this idea. The contexts will be based on the current syntax highlighting
  color. So you can assign different commands to a key if you are inside or outside
  a string. Also assignments of multiple commands to the same key will
  show a popup menu.
  
  
• Database Management Frontend Well this feature is my personal "Peter Jackson
  King Kong" feature. If you ask me why i did it and if it is really necessary when
  there are good frontends available then i can only answer you that this was one of the
  things i always wanted to do. And falling into a motivation crisis i used it to keep my focus
  on the work. It's more and more obvious that SQLite is the new prefered file storage
  mechanism for a lot of programs. PHP and Python are
  using it in the standard library. And i'm sure Ruby will add it also in one of
  the next releases. So a SQLite frontend is as essential as a file browser.
  
  
  
  
• Email Test Servers While working on Scriptolutions automatic order system
  and Newsletter script i found that there are no good ways to do painless testing of
  email processing systems. Thats why i spend 2 weeks and wrote an SMTP and POP3 server with
  a GUI frontend.
  
  
  
  
  
• Integrated Web Server I would assume that 80% of the people who use
  scripting languages are using it for web based applications. So having the complete
  test chain available is a good idea. When you open a project the whole infrastructure
  should be there immediately. Thats the idea of an "I" in IDE. A web server is a
  very small piece of code especially when you write it for development only and you
  do not need to care about performance and security. In the past i tried to bundle
  apache because this is what most people expect. But i couldn't find any reason why
  apache is required in a development environment and people should always write
  webserver independent. The few people who are using mod_ruby and the special apache
  API know what they do so i don't need to care about them.
  
  
  
  
• PHP Yes guys i did not forget that my plan was always to support at least
  PHP, Ruby and Python. When i see that the majority of time goes into the language
  independent parts, i'm pretty sure that i can support all three of them. And PHP and
  especially Python are much more mature then Ruby. The huge support cost for Ruby is
  just the fact that some Ruby parts are just not stable enough for a third party IDE
  developer.
  
  
  
  
• Multithreading One more serious feature that requires a rewrite is
  that when i started with Arachno the Eiffel compiler and runtime did not know anything
  about threads. I added this 2 years ago. And now i'm integrating it into the code
  which turns out to be impossible with a lot of changes. For an IDE there are not
  so many places where it is really usefull: Initial startup, opening multiple files (mostly
  during project open) searching files and the ultra slow RDOC/RI generator are the obvious
  places that benefit from more CPU power. But there are a lot of features that can
  be done in the background. I'm restructuring the program for this purpose. Also
  multithreading is a nice way to add more responsiveness to the interface.
  As a former BeOS fanboy i really miss
  something here.
  
  

What comes next.

I'm trying to do a 50%/50% split. Working 50% to get previous features workable
and 50% to add new features and improvements.

The steps for the next release are simple.

• I have to fix the last problems with the project file handling.
  
  
• There is a background thread that constantly checks for file changes, parses
  the files and keeps information in a "repository". Almost done, just need to add
  the fact that when a file is edited there are two informations and that the one
  from the text inside the editor has priority over the data inside the file.
  
  
• The background thread is doing the syntax check on all files. For ruby i can't
  link statically to ruby anymore. In the past i simply used a 1.8.2 ruby version for
  checking. Now with 1.9/2.0 comming soon i have to call the correct ruby runtime
  to do checking. Unfortunately the API does only exist in binary form and so i need
  to implement a way to either use a delivered binary extension or compile it on
  your system (for Unix/Cygwin systems).
  
  
  
• The repository feeds the navigation pane. And the top row current
  Class/Message listboxes. With an existing repository of all classes and functions
  it is also finally possible to fill this listboxes and buttons with life.
  
  
• The editor text folding algorithm gets its data from the navigation pane.
  So if this works the folding will be back.
  
  
• The background parser is also used to provide the Begin/End Matcher
  
  

When this is done we are one step closer to have a full useable editor again.