Main Page

Installing & Building all Components for Exodus

Installing and Using Tortoise Subversion

Simple Command line to check is:

svn co http://svn.neosys.com/svn/trunk exodus

What is Exodus?

Exodus is a way to do traditional pick-basic programming in C++.

It was conceived and created by Steve Bush of NEOSYS Software as a way to move classic pick/multivalue basic into a classic industry standard environment with the minimum of upheaval.

Many people would like to migrate their classic pick/mv based applications into industry standard environments however they have so much code that relies on the nuances of pick/mv, or their programmers are so used to pick-basic, that it is virtually impossible to move.

Exodus is released under the modified BSD licence following the example of Postgres.

Key Points

Language

Use c++ overloading to make C++ behave almost exactly like pick programmers expect and therefore usable for application level programming

Storage

Use standard sql databases (currently Postgres) transparently as a pick storage mechanism ensuring full SORT/SELECT functionality including even on calculated dictionary items (columns) written in the pick style c++ environment.

Supports both classic Pick syntax style AND modern OO syntax.

Classic Pick "Global function" style syntax available

print(convert(extract(c,1,2,3),"abc","xyz")));

This is Exodus's C++ syntax. The trailing ; gives it away as C++

Pick programmers are used to this syntax and many will want to stay with this style for their own reasons which it is not the job of Exodus to gainsay.

It is a pity that C++ syntax doesnt allow the easy-to-write and easy-to-read pick-like array extract/replace like xxx<1,2,3> or x<3>="x". A great shame but not a killer.

Classic OO "Method Chaining" syntax available too

xyz.extract(1,2,3).convert("abc","xyz").print();

This is standard C++ code. The trailing ; gives it away. xyz is one of Exodus' "Mv" objects ... with a method extract ... which just produces another Mv object which is then processed by the following method.

Which means: from variable xyz, extract field 1, multivalue 2, subvalue 3 from variable xyz, convert characters abc to xyz in the result and then print it.

The pick variable object has all the various pick functions as methods so you can use oo like method chaining syntax which is often the way people think in oo languages and (arguably) easier to understand since read from left to right gives you the operations in the order that they are performed. As much as some people may not like OO method syntax, the many more people today are more comfortable with it than global function style.

Why not just Python or PHP?

Both of these are great languages to start new projects and many people using Pick language will have looked at the possibilities of porting to them.

no because python variables dont BEHAVE like pick variables in too many cases.

Look at the php * operator. If you give it a variable that happens to contain a string then, instead of converting it to a number to multiply numerically, it will repeat the string n times! This is fine for php people who are used to it ... but cause chaos when converting and maintaining pick code in php.

"100"*10 in php is "100100100100100100100100100100"

of course it isnt written as "100"*10 in code .. it is written as mynumber*10 ... BUT what happens depends on what data type happens to be in mynumber during execution

if you have thousands of lines of old code you dont have time to sort out all the subtle bugs caused by these differences

generally the objective is to convert often hundreds of thousands of lines of pick basic fairly accurately into another language

changing syntax is laborious but reliable and doesnt require highly skilled programmers. however any subtle changes in semantics (how operators and functions work) mean ports are unreliable which is worse.

this does NOT mean that the syntax cannot change .. but it does mean that the sematics must remain almost identical

otherwise people will be hunting down bugs forever. anybody who has looked at replacing pick will have come to the same conclusion. porting needs meticulous rewriting into the new language mentality due to nuances in how the basic principles of how variables behave.

Look at the php concat operator. very clever of php to have special concat operater (even if it seems almost impossible to read to pickies used to a : for concat) (the dot). Most other languages dont have proper concat operator at all. php concat operator is

Concat operator

The ability to concat variables in precisely the same way as pick is very important if you are going to move pick applications into any other language.

eg in pick if you concat two variables using the pick ":" operator that happen to be numbers you will still get a string out. ie concat in pick means concat. it DOESNT means add if the arguments happen to be numeric. the concat operator missing in c++ because it is strongly typed and it (and you) can tell from arguments whether it will add or concat

in exodus, "variables" are a c++ class that behaves like a pick variable very very closely so you can port pick basic without being nervous of subtle bugs due to differences in mentality of the original language designers.

Why Postgres?

Open source and technically very open and easy to extend with new datatypes etc.

Postgres is widely available and well supported on all major platform. There has been very strong interest in and development of Postgres since Oracle bought up the MySQL's underlying database .

Postgres licence in BSD so can be used in anyway you like whatsoever including using bits of the source code in your own code without GPL restrictions.

Why Boost?

Best of breed and is the prime place that C++ standards are worked out.

Why Visual Studio?

Only because the project is currently primarily developed in Windows. Previously it was primarily developed in Eclipse/Cygwin.

Visual Studio is prime development environment in Windows although there are perfectly good other ones eg Eclipse/Cygwin, Codeblocks (add more here).

there is a windows dependency in this project at the moment about pipes for ipc with postgres but I will be removing that and using the portable boost shared memory

there is also a C driver that you install in postgres ... this is assuming that you want database operations read/write/delete etc which is almost certain

the postgres C driver is in subverwsion under pgneosys

the project isnt setup very flexibly - ie hard coding lib folder locations whereas they should have a macro to ease modification if you have installed the various dependencies in non-standard locations.