Jazz Scheme Google Group

Re: Strange Jedi crashes on Mac OS X

2009-11-17T22:08:00Z

Update on this bug.

After discussing this with Marc, the bug was due to a fundamental assumption
in Gambit that every module name should be unique. When linking an
executable like jedi, the flat link file generated must be named jedi.c
hence the clash with the jedi module.

So, the patch we did to add a uniqueness prefix to compiled module names

Re: Strange Jedi crashes on Mac OS X

2009-11-17T16:59:39Z

In the previous message I forgot to mention that "kernel -compile jedi
-force" relies on a new -force option of the Jazz kernel.

So before running that command you will need to rebuild your kernel
with "gsc make kernel" or "gsc make jedi".

Guillaume

On Nov 17, 11:45 am, Guillaume Cartier <gcart...@jazzscheme.org>

Strange Jedi crashes on Mac OS X

2009-11-17T16:45:36Z

Some people have reported a very strange bug on Mac OS X.

After a full build of jedi :

running bin/jedi would crash but
running bin/kernel -run jedi would run ok

After some bug hunting, it seems it boils down to a bug in Gambit's new
module-name: option to compile-file-to-c. A temporary patch was pushed to

Re: OS X 10.6 (Snow Leopard) build issues

2009-11-17T16:12:37Z

Indeed. GCC 4.2.x has severe problems handling large files.

A couple points :

First, we reduced walker.scm's size from 240K down to 185K. This should help
a bit in all cases but compile times will still be pretty high.

Second, a test was added in the Jazz kernel to automatically disable

Re: OS X 10.6 (Snow Leopard) build issues

2009-11-16T13:07:59Z

A follow-up to my last post.

I tried falling back to gcc-4.0 and that seems to fix it though
gcc-4.0 does not default to x86_64 and thus I had to rebuild Gambit 32-
bit. However with that done, it's well past walker now. So I
conclude this is a bug in gcc-4.2.1.

Derrell

OS X 10.6 (Snow Leopard) build issues

2009-11-16T12:44:08Z

Hi,

New user here. I'm trying to build Jazz from git on 10.6.2 with
Gambit 4.5.3 and Xcode 3.2.1 (gcc 4.2.1). The first issue is that
Gambit builds itself 32-bit by default though it defaults to producing
64-bit binaries. So without doing anything, you blow up in your first
link step trying to link 64-bit binaries against a 32-bit

Re: X11 performance tests/results

2009-11-08T13:54:59Z

Hi Guillaume,
sorry for this very late reply.
Please don't waste your time with this "bug" and continue your fine work
on Jazz/Jedi by adding features, cleaning up code or even optimizing the
drawing routines (I think I mentioned already, that the UI redraws too
much). Of course you could try to use cairo_surface_create_similar to

Re: Windows binary anywhere

2009-11-05T13:14:09Z

When JazzScheme was released 9 months ago, we took the time to build
binaries for Mac, Windows and Linux. Unfortunately we haven't had the
time yet to automate this lengthy process yet. And as Jazz is evolving
rapidly with many commits each day, I decided the best was simply to
remove binaries and references to them from the website (I have now

Windows binary anywhere

2009-11-03T18:03:31Z

Hello,
The windows binary are mentioned in the site, but I cannot find them.
Are they available?
bitli

Breaking changes to user profiles

2009-11-02T20:47:12Z

A recent commit introduces breaking changes to user profiles.

In HOME/jazz_user/lib/profile.<pr ofile name>/profile/<profile name>/
settings/Workbench.jml, change

(<Validate-Manifest> tag-module: project.jazz.validate.Validate -
Manifest)

(<Validation-Manifest> tag-module: project.jazz.validation.Valida tion-

Re: problem with the gomoku sample

2009-10-13T19:35:48Z

That's the difference between invalidate-view and redraw-view.

invalidate-view tells the windowing system a certain area must be
refreshed at the next paint. So multiple calls to invalidate-view will
just accumulate and the next paint will draw the union of those
invalidated areas. This is usually what we want.

Re: problem with the gomoku sample

2009-10-13T19:29:05Z

ah, okay :) why does invalidate-view not cause a redraw?

martin

On Wed, Oct 14, 2009 at 12:53 AM, Guillaume Cartier

Re: problem with the gomoku sample

2009-10-13T19:23:14Z

Sorry about that, I had read C4 :-)

Then, everything is as it should be. It does the same thing on Windows
and Mac. I'll add a redraw-view, so apart from being nicer, no one
else will go thinking it's a platform specific bug ;-)

Thanks!

Guillaume

Re: X11 performance tests/results

2009-10-13T19:16:25Z

Hi Marco,

First of all, many thanks for such an exaustive analysis of the
problem! It is very difficult and frustrating to try and debug a
problem like this without access to reproducing it but your help sure
goes a long way!

After reading your email, it seems to me the most promising approach

Re: problem with the gomoku sample

2009-10-13T18:42:21Z

No, C4 works fine, it's gomoku that has the problem. Here are the
details from xorg.log, in case they help:

X.Org X Server 1.6.3.901 (1.6.4 RC 1)
Release Date: 2009-8-25
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.30-ARCH i686
Current Operating System: Linux mercury 2.6.31-ARCH #1 SMP PREEMPT Thu