Reproducing a development work flow with Jazz/JEDI.

[Andrés Musetti]

Hi!

Currently my Scheme development environment is Emacs, Gambit-C, and a Makefile to grab all my Scheme source and data files and build a single executable, with statically linked libraries, and resources embedded in the executable.

I'm using Linux as development platform right now, targeting both Linux and Windows, and I cross-build Windows executables from Linux, using Gambit-C for MinGW32 (mingw32-gambit-c package for ArchLinux).

I was wondering whether it is possible with Jazz/JEDI to reproduce (and enhance) the same work flow.

Specifically, I want to know:

* Whether it is possible, as a minimum, to use the Jazz units system in my work flow.

* Whether I can replace my Makefiles with the Jazz build system, to create single, monolithic executables, as explained above.

* Whether I can do all that, and use the Jazz dialect, with units, modules, packages, and all.

* Whether it is possible to do all the above from JEDI.

Thanks in advance,

Andrés.

[Guillaume Cartier]

Hi Andrés,

This is a tough one.

To give some background, you may know that before the port to Gambit, Jazz was C++-based. At the time, Jazz compiled Scheme files into C++ files and linked every file and resources into one big happy executable. Just like what you want and exactly what I wanted at the time! It worked great and had many advantages: simple distribution, ultra-fast launch time, ...

When I ported to Gambit, it seemed at the time that supporting a key feature of Jazz which is that modules are only loaded as needed would be impossible in Gambit. The problem is that Gambit loads every module linked into an executable when it is launched. It was almost a deal-breaker away from Gambit. After discussing this with Marc Feeley, he proposed what seemed to me at the time a really convoluted and non-satisfying solution: to keep every module as independently compiled .o1 files and distribute the application in this format. First concern was launch time as Jazz is made up of thousands of modules. After some tests, launch time was deemed acceptable enough to consider the solution. Note that to this day, launch time is still something that we are trying to improve (see static linking lower). The other thing I didn't like was distributing an application as separate files. On this one, Marc argued that on many OS's, like Mac for instance, applications are already packaged as a folder containing all the application files.

OK, all this seems pretty negative, but with time this approach as also yielded many advantages :

Separate compilation

When launching an application and a module gets loaded, Jazz will test if the compiled .o1 is up-to-date and will load the interpreted source automatically if it is out-of-date. So, building is now a totally optional step. If you do not build, you just end up with some modules being loaded interpreted. Personally I only use the build system when pulling many changes from the main trunk. Also, building is much faster as there is no need to re-link the application every time a module has changed. This really improves the development cycle.

Unification of development and deployment environments

This unified format of development and deployment environments both using separate .o1 files lead us at work to a radical approach of distributing our applications using Git. Now when we release a new version, we simply commit the changed .o1 and push. User side, the application invokes Git with a pull to get the new version. Extremely simple and fast. For a user, updating to a new version is a couple seconds process. And no need for any bulky installer.

This also goes very well with rapid testing, delivery of updates, hot fixes, ...

All this being said, we also worked on static linking. Ideally, what I want is to support the 3 levels:

1) all modules as separate .o1

2) all modules in a package built together as one shared library

3) all application modules built into the executable

At this point Jazz only supports 1) and 2). Implementing 3) should be fairly simple as the core work needed was done implementing 2).

Personally I think 2) is a great option for final delivery of an application. Jedi, for example, would end up with and executable and only a couple clean libraries like: jazz.network, jazz.ui, ...

Hope all this is not too confusing,

Guillaume

--
You received this message because you are subscribed to the Google Groups "Jazz Scheme" group.
To view this discussion on the web visit https://groups.google.com/d/msg/jazzscheme/-/_IkLFYP04SwJ.
To post to this group, send email to jazzs...@googlegroups.com.
To unsubscribe from this group, send email to jazzscheme+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jazzscheme?hl=en.