> Jazz was designed so it can be used independently of Jedi. As for a jazz.exe that implement's a
> Jazz REPL, I started work on that but it is really low priority as it would be a pale substitute
> for Jedi (one big thing for instance that a console-based REPL will never be able to handle well
> is debugging multiple threads / processes).
Nice to hear that you work on a jazz.exe, sad that it is low
priority. Threads are currently not an issue here, but I think there are
ways to handle it in a somewhat blown up REPL, e.g. Common Lisp + SLIME.
> I'd say the best thing for you is to edit in Emacs and debug using Jedi. Note that Jedi when
> activated checks the modification time of all its edited files and proposes reload if some have
> changed.
That's mainly the way I use Jazz right now, but it is not that
satisfactory: what I enjoy most when programming in any kind of Lisp is
the possibility to try things out fast, i.e. use a REPL.
> Also, note that if you decide to give Jedi a spin, it implements a large subset of Emacs
> functionality like :
>
> - navigation using c-a, c-b, ...
> - incremental search
> - syntax coloring
> - tab completion
> - code indentation
> - clipboard stack
> - textual macro recording
> - c-x c-f to find files
> - ...
>
> and when you launch Jedi and create a new profile, if you choose Bindings: Emacs, then pretty much
> all basic Emacs bindings should work.
Yep, I know and use all (almost) of it in Jedi, but:
1. there is no Paredit mode:
I was very surprised to see how much one can get used to such a tool,
in fact I did not close a parenthesis in Lisp for about two years now
- that is before using Jedi :-)
2. Linux
But more important is Jedi's performance on Linux: in the mail
archive someone described that the redraw is more or less pixel-wise,
and this is also the case here. Being not an expert in programming
Cairo, I only can give you two vague hints:
a) AFAIK Cairo does *not* support any kind of double buffering out of
the box
b) you are using only one X11 Window, which is *very* uncommon for a
gui toolkit
Btw, I managed to compile Jazz/Jedi with gambit --enable-cplusplus and
could provide a patch which is not directly applicable (hard coded 'g++'
and the like), but could give you an idea where some (minor) changes
could be made to support c++. Most are explicit casts from int to some
enum type in the ffi, which are necessary in c++ and do not hurt in c.
Regards, Marco
(sorry for the late reply)
> Jazz was designed so it can be used independently of Jedi. As for a jazz.exe that implement's a
> Jazz REPL, I started work on that but it is really low priority as it would be a pale substitute
> for Jedi (one big thing for instance that a console-based REPL will never be able to handle well
> is debugging multiple threads / processes).
Nice to hear that you work on a jazz.exe, sad that it is low
priority. Threads are currently not an issue here, but I think there are
ways to handle it in a somewhat blown up REPL, e.g. Common Lisp + SLIME.
> I'd say the best thing for you is to edit in Emacs and debug using Jedi. Note that Jedi when
> activated checks the modification time of all its edited files and proposes reload if some have
> changed.
That's mainly the way I use Jazz right now, but it is not that
satisfactory: what I enjoy most when programming in any kind of Lisp is
the possibility to try things out fast, i.e. use a REPL.
> Also, note that if you decide to give Jedi a spin, it implements a large subset of Emacs
> functionality like :
>
> - navigation using c-a, c-b, ...
> - incremental search
> - syntax coloring
> - tab completion
> - code indentation
> - clipboard stack
> - textual macro recording
> - c-x c-f to find files
> - ...
>
> and when you launch Jedi and create a new profile, if you choose Bindings: Emacs, then pretty much
> all basic Emacs bindings should work.
Yep, I know and use all (almost) of it in Jedi, but:
1. there is no Paredit mode:
I was very surprised to see how much one can get used to such a tool,
in fact I did not close a parenthesis in Lisp for about two years now
- that is before using Jedi :-)
2. Linux
But more important is Jedi's performance on Linux: in the mail
archive someone described that the redraw is more or less pixel-wise,
and this is also the case here. Being not an expert in programming
Cairo, I only can give you two vague hints:
a) AFAIK Cairo does *not* support any kind of double buffering out of
the box
b) you are using only one X11 Window, which is *very* uncommon for a
gui toolkit
Btw, I managed to compile Jazz/Jedi with gambit --enable-cplusplus and
could provide a patch which is not directly applicable (hard coded 'g++'
and the like), but could give you an idea where some (minor) changes
could be made to support c++. Most are explicit casts from int to some
enum type in the ffi, which are necessary in c++ and do not hurt in c.
Regards, Marco
> On Wed, Sep 23, 2009 at 2:51 PM, Marco Gidde <marco...@freenet.de> wrote:
> Nice to hear that you work on a jazz.exe, sad that it is low
> priority. Threads are currently not an issue here, but I think there are
> ways to handle it in a somewhat blown up REPL, e.g. Common Lisp + SLIME.
>
> I'm open to any suggestions. But seeing that the Gambit REPL's support for threads is
> minimal and that various discussions with Marc Feeley ended in him reiterating that it is
> not possible to fully support threads in a pure console based REPL, I'm doubtful.
Ok, SLIME is not pure console and probably it will pop up some Emacs
windows to do its job. If I come up with a great idea or find something
useful in another Lisp I will discuss it with you and Marc, but don't
hold your breath - I guess you both know what you're doing :-)
> That's mainly the way I use Jazz right now, but it is not that
> satisfactory: what I enjoy most when programming in any kind of Lisp is
> the possibility to try things out fast, i.e. use a REPL.
>
> What do you mean? Jedi's console is a full-fledged REPL! What are you missing from it?
I miss nothing within Jedi's console, it's just too much of Jedi ;-)
> Yep, I know and use all (almost) of it in Jedi, but:
>
> 1. there is no Paredit mode:
>
> I was very surprised to see how much one can get used to such a tool,
> in fact I did not close a parenthesis in Lisp for about two years now
> - that is before using Jedi :-)
>
> Various people mentioned Paredit. I had a quick look at the documentation and Jazz
> already supports most of it but bound to other keys. I'd guess creating a full Paredit
> module for Jazz would be a couple hours work. Any takers?
If Jedi is more usable here (performance not feature wise) I will have
to take a closer look ...
> 2. Linux
>
> But more important is Jedi's performance on Linux: in the mail
> archive someone described that the redraw is more or less pixel-wise,
> and this is also the case here. Being not an expert in programming
> Cairo, I only can give you two vague hints:
>
> a) AFAIK Cairo does *not* support any kind of double buffering out of
> the box
>
> I totally agree! Linux / X11 performance is the big killer and main reason I never
> announced Jazz publicly. Unfortunately my macbook pro died on me twice and Linux / X11 is
> low priority for us at the moment. This is unfortunate as I'm pretty sure somewhat with
> expert knowledge of X11 would probably be able to fix the performance problem in no time.
Export knowledge of X11 in combination with some knowledge of Scheme is
probably hard to find, see below ...
> b) you are using only one X11 Window, which is *very* uncommon for a
> gui toolkit
>
> This is exactly what I happen to be working on at the moment. :) I'll post a message when
> it's ready. Probably beginning of next week.
Do you intend to introduce a full blown widget set like GTK? It might be
easier to find people with enough knowledge to provide patches since
almost nobody programs X11 directly these days. I had to maintain an
in-house widget set for several years and was more than happy when I
convinced my colleges to remove the X11 core as far as possible and
replace it with something higher level, Qt in our case. Since then it
was quite easy to fulfill those nasty customer wishes, e.g. tooltips or
a html browser :-)
> Btw, I managed to compile Jazz/Jedi with gambit --enable-cplusplus and
> could provide a patch which is not directly applicable (hard coded 'g++'
> and the like), but could give you an idea where some (minor) changes
> could be made to support c++. Most are explicit casts from int to some
> enum type in the ffi, which are necessary in c++ and do not hurt in c.
>
> Sure! I'll have a look at it. Thanks.
Great, see the attachment. Some of the code should be conditionalized
with the result of 'gambc-cc.bat C_COMPILER' - sorry that I was too lazy
and too short of time to do it myself.
Regards, Marco