Cannot build latest checkout (after "The time syntax now accepts an arbitrary number of forms")

[Martin DeMello]

Platform:
* arch linux
* latest gambit from git (372fa1cf729a30c6ea6d42a396a10e429a686e19)

make jazz dies with:

; compiling jazz/dialect/walker/core...
*** ERROR IN | dialect.o1|, "lib/jazz/src/jazz/dialect/
dialect.scm"@355.1 -- Inconsistant core-class/class slots for Time-
Special: (expressions) / (expression)

commit 3256c75294bee30c7c5dd1e766a9b6cad3f0a447 compiles cleanly.

martin

[Guillaume Cartier]

Fixed.

[Guillaume Cartier]

Really fixed now! Sorry about that.

On Sep 21, 2:16 pm, Guillaume Cartier <gcart...@jazzscheme.org> wrote:
> Fixed.
>

[Martin DeMello]

works, thanks :) do i have to make clean and remake jazz and jedi
every time i update from git?

martin

[Guillaume Cartier]

Not at all! A simple make jedi will do.

Here a quick rundown on what's involved after doing a git pull :

Because Jazz was designed to minimize compilation dependencies, very few changes in a module force recompilation of other modules (some of those changes are modifying a macro, moving an exported symbol to another module, ...). The build system takes advantage of this and recompiles only changed files. This is why a simple make jedi will do.

When some changes done to Jazz should force a full rebuild, like some changes to low-level kernel macro changing the generated code incompatibly, there is a file kernel/versions that the build system consults and that contains entries like :

(version: 201016)

(version: 201015 gambit-version: 405001 gambit-stamp: 20090827151242)

(version: 201014 rebuild: all)

(version: 201011 rebuild: kernel)

For example, with the entries above, if your last pull pulled version 2.01.010, then the (version: 201014 rebuild: all) entry above tells the build system it must recompile everything. All this meaning really that you never have to worry about it as the developers of Jazz have a way to automate rebuilding any parts of Jazz.

Also, Jazz was designed so every module can be loaded interpreted or compiled (except modules containing FFI code). So in theory, you need not even do a make jedi before launching Jedi (it should only improve performance). But that is not really the case anymore as we implemented dependency checking code to automatically determine when a module's imports are not valid anymore because some imported symbol was moved or deleted. For that check we had a choice to do it runtime but incur a non-trivial cost or integrate the check to the build system which is what we did. So now it is possible that if some modules have invalid imports, just launching Jedi after a pull might not work and a make jedi will fix this.

Lastly, you should always consult the NEWS file after doing a pull. This is where we describe any breaking changes not covered by the build system and the corrective actions to take. Here's an example :

Release 2.0.21

==============

Because a slot was added to the Lisp-Entry class, you will need to manually

delete your catalogs before launching Jedi.

In summary, just do make jedi and have fun. :-)

Hope this helps,

Guillaume

[Martin DeMello]

Thanks, that was a great overview of the module functionality

martin

On Tue, Sep 22, 2009 at 5:55 PM, Guillaume Cartier