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

Post by 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.
* 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.
--
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 unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/jazzscheme?hl=en.