Waterfront - The Clojure-based editor for Clojure

[Itay Maman]

I've been silently following Clojure (and this group) for several
months now.Somewhere around December I started working on a Clojure
editor/REPL written in Clojure. This effort evolved into the
Waterfront project which is now available on sourceforge (http://
sourceforge.net/project/showfiles.php?group_id=249246).

Waterfront's Highlights:

* CTRL+E: Eval current selection, or the whole file if the selection
is empty
* Edit -> Eval as you type: When turned on (default) periodically
evaluates your code. Boosts productivity as many errors are detected
on the spot.
* Eval-ed code can inspect/mutate Waterfront by accessing the *app*
variable. For instance, if you eval this expression,
((*app* :change) :font-name "Arial"), you will choose "Arial" as the
UI font.
* Eval-ed code can inspect the currently edited Clojure program. For
instance, if you eval this expression, ((*app* :visit) #(when (= (str
(first %1)) "cons") (println %1))), the output window will show all
calls, made by your code, to the cons function.
* Syntax and Evaluation errors are displayed on: (1) The Problems
window; (2) The line-number panel, as red markers.
* Source -> Generate -> Proxy: Generates a proxy for the given list of
super-types, with stub implementations for all abstract methods.
* F1: Shows the doc (as per Clojure's (doc x) function) of the
identifier under the caret.
* Source -> Reflect: Shows the synopsis of a Java class when the caret
stands on a class symbol (e.g.: java.awt.Color).
* CTRL+Space: Token-based auto completion.
* Full parenthesis matching.
* An extensible plugin architecture.
* Other goodies such as undo/redo, toggle comment, recently opened
files, indent/unindent, Tab is *always* two spaces, ...

In order to get started, you need to
(1) Download the waterfront zip file from:
http://sourceforge.net/project/showfiles.php?group_id=249246.
(2) Unpack it into a local directory.
(3) Edit wf.bat: fix the path to clojure.jar according to its
location on your machine.

Personally, this effort was quite interesting. Writing GUI
applications in a functional language is sometimes a challenging task
(at least if you want your Clojure code not to be a transliteration of
Java code…). I used a pattern the "application context" pattern: an
immutable map describing the application's current state that is
passed around. This made it possible for most of Waterfront's code to
be purely functional. Consequently, plugins can accomplish a lot with
just a handful of lines. Many plugins span about 60 lines of code.
Vast majority of them are less than 200 LOC. The main module, ui.clj,
that implements the underlying engine is also less than 200 LOC. I
think this is a very good indication to Clojure's power.

Hope you'll find it useful. I'd be happy if anyone would like to join
and contribute to Waterfront. Your feedback, either on-line or
offline, will be highly appreciated.

--
Itay Maman
http://javadots.blogspot.com

[Itay Maman]

[Itay Maman]

Ooops...
Sorry for the multiple posting. Seems to be some glitch.

-Itay

[Tom Ayerst]

This is an interesting idea and a lightweight IDE distributed in contrib would be a great addition IMHO.

I have tried it (on Windows using a pre-lazy version of clojure) and it doesn't react to any events (though it does repaint after other apps windows are dragged over it).  What version of clojure did you build it agaisnt?

Thanks

Tom

2009/2/24 Itay Maman <itay....@gmail.com>

[Itay Maman]

I built it against the latest download 20081217 (SVN Revision: 1173)

-Itay

[Itay Maman]

All, thanks so much for the feedback.
I am working on adapting Waterfront to the Clojure's latest snapshot.
Will let you know when this process is complete. Till then it can be
tried with Clojure's previous version (Dec.17).

-Itay

[AlamedaMike]

Thanks for this Itay.Very sweet. I've been running it against the
Dec. 17th download and it works fine on Vista SP1. I'm particularly
impressed with the quality of the error messages.

A few suggestions / questions:

* there's a lot of whitespace to the right even when I don't have the
window maximized. Would you consider making the current top and bottom
views side-by-side? Much less wasted space, I think.

* I'm trying to get the reflect operation to work. Sample source code:

(defn in-circle? [[x y]]
(<= (Math/sqrt (+ (* x x) (* y y))) 1))

When I put the cursor anywhere on Math/sqrt or else highlight it and
then select "reflect" from the source menu, I get "I could not
evaluate the symbol 'Math/sqrt'". Ideas?

Thanks again.

Mike

[Itay Maman]

On Feb 24, 10:22 pm, AlamedaMike <limejui...@yahoo.com> wrote:
> Thanks for this Itay.Very sweet.  I've been running it against the
> Dec. 17th download and it works fine on Vista SP1. I'm particularly
> impressed with the quality of the error messages.

Thanks

>
> A few suggestions / questions:
>
> * there's a lot of whitespace to the right even when I don't have the
> window maximized. Would you consider making the current top and bottom
> views side-by-side? Much less wasted space, I think.

I agree with you. Somewhere down the road I want the layout to be
completely flexible. Till then I will try to do something less
general.

>
> * I'm trying to get the reflect operation to work. Sample source code:
>
> (defn in-circle? [[x y]]
>   (<= (Math/sqrt (+ (* x x) (* y y))) 1))
>
> When I put the cursor anywhere on Math/sqrt or else highlight it and
> then select "reflect" from the source menu, I get "I could not
> evaluate the symbol 'Math/sqrt'". Ideas?
>

Yes. The symbol detection takes the whole thing, "Math/sqrt", as a
single token.
Reflect, OTOH, expects class symbols. Thus, the workaround is this:
highlight only the "Math" part and then choose Reflect.

[AlamedaMike]

Thanks for the quick response Itay.

>> Thus, the workaround is this: highlight only the "Math" part and then choose Reflect.

Yup! Very nice feature.

A few further suggestions, if you're in the mood:

* a separate REPL tab would be very useful and save me from having to
enter code into the file, highlight and execute it, and then delete it
(leaving the file in a "dirty" state and me wondering what I changed
that caused that.)

* multiple source tabs in the source editor. Very useful to have.

* documentation for everything in the "generate" sub-menu. I'd write
it myself if I had any idea how it worked, but I don't have the time
to dig into the source code.

* trivia: add a space in the execution time between the digits and
"ms". E.g., "34ms" --> "34 ms"

* a function key for "reflect" to match that for "doc".

* capability to evaluate the form the cursor is currently in with,
say, Ctrl+E, using (say) Shift+Ctrl+E to eval the whole file. Or some
such. This will be a common operation and saves having to highlight
the text every time. Bonus points if it will evaluate the previous
form when it is not inside a form.

* smart indentation. On "enter key pressed", indent on the next line
to the first dark space on the previous line. Bonus points if detects
the end of a form and goes to the first column.

* documentation on plug-ins (lower priority for me and probably for
others). Could you give at least a high-level sense of what plug-ins
you're currently using and what for. This would give the users a sense
of what they may or may not be missing.

Thanks again for a great tool. I'm currently using Slime, but I'd love
to have a tool written in Clojure that I can configure. I'm busy with
other projects, but I hope to get some hacking on this at some point.

Mike

[Itay Maman]

After a few hours of intense work I managed to port Waterfront's code
to Clojure's latest snapshot. This version is now available for
download as "RC1-147" at the same location (http://sourceforge.net/
project/showfiles.php?group_id=249246).

This version is fully functional and so far I didn't encounter any
bugs.
I guess that over the course of the next few days, as people start
using this version,
a few issues may come up. I'd be glad to fix these.

I also took Mike's suggestion, Waterfromt's main window is now using
a side-by-side layout.

[Kevin Albrecht]

Itay,

I took a look at Waterfront and it seems to have a lot of potential.
Keep me and the group updated on your future work.

I have also been working on a GUI application in Clojure and I share
your perspective on the challenges of designing a functional GUI. I
am definitely intrigued by the application context pattern and I am
going to take a look at it for incorporation in my design.

Thanks,
Kevin Albrecht

[bOR_]

I'm trying to rewrite the wf.bat to a linux version, but I was a bit
puzzled what all the ;%~dp0 's mean. Apparently the bash version of it
is ${0%/*}

java -cp ~/src/clojure/clojure.jar;${0%/*}clj;${0%/*}java -
Dnet.sourceforge.waterfront.plugins=${0%/*}clj/net/sourceforge/
waterfront/ide/plugins clojure.main ${0%/*}clj/net/sourceforge/
waterfront/ide/main.clj %*

It seems like you're also assuming 'clj' to exist?

[Itay Maman]

On Feb 25, 11:08 am, bOR_ <boris.sch...@gmail.com> wrote:
> I'm trying to rewrite the wf.bat to a linux version, but I was a bit
> puzzled what all the ;%~dp0 's mean.

In .bat files %~dp0 specifies the directory where the .bat file is
located.
In sh scripts, it should be `dirname $0`.

>Apparently the bash version of it
> is ${0%/*}
>
> java -cp ~/src/clojure/clojure.jar;${0%/*}clj;${0%/*}java -
> Dnet.sourceforge.waterfront.plugins=${0%/*}clj/net/sourceforge/
> waterfront/ide/plugins clojure.main ${0%/*}clj/net/sourceforge/
> waterfront/ide/main.clj %*
>
> It seems like you're also assuming 'clj' to exist?
>

clj and java are the subdirectories in the Waterfront installation
directory. So if the zip was unzipped
successfully, it is safe to assume they exist.

I don't have a Linux machine. Could you send me this script (one it is
up and running)
so that I will put it inside the .zip file?

Thanks,
-Itay

[linh]

where can i read about "application context" pattern?
i this the idiomatic way to write GUI in functional languages?
i'm writing a small swing based app in clojure, and i have problems
wirting the gui, because the gui code tends to be very imperative and
messy.

[Itay Maman]

On Feb 25, 11:48 am, linh <nguyenlinh.m...@gmail.com> wrote:
> where can i read about "application context" pattern?

It is something I had occasionally used in the past. As I started
working on Waterfront, I realized it is well suited for GUI apps in
a functional language. I am not sure where you can find information
about
it, it is just something that was sitting there in my head.

Anyway, I plan to write a more detailed description of this pattern
as it addresses a concrete need of Clojure developers. Hope to get
to that within the next few days.

-Itay

[Jeffrey Straszheim]

Count me interested also.

[Itay Maman]

For those of you who tried one of Waterfront's earlier revisions and
then switched to revision 147 (latest):

In 147 there was a change in the plugin loading order (due to plugin
dependencies). If you ran earlier versions you will get the following
message as Waterfront is launching:
Can't load plugin output-window.clj. Reason: nil
Can't load plugin eval-as-you-type.clj. Reason: nil

Here's the fix: close all Waterfront windows. Go to the directory
indicated by Java's user.home property (typically: c:\windows
\documents and settings\<your user name> or your Unix/Linux home
directory) and delete the file ".waterfront.config.clj".

-Itay


On Feb 25, 3:49 pm, Jeffrey Straszheim <straszheimjeff...@gmail.com>
wrote:
> Count me interested also.

[Mark Colburn]

#!/bin/sh
DP="${0%/*}"
java -cp ~/src/clojure/clojure.jar:${DP}/clj:${DP}/java -
Dnet.sourceforge.waterfront.plugins=${DP}/clj/net/sourceforge/
waterfront/ide/plugins clojure.main ${DP}/clj/net/sourceforge/
waterfront/ide/main.clj $*

[Stephen C. Gilardi]

On Feb 25, 2009, at 1:27 PM, Mark Colburn wrote:

> #!/bin/sh
> DP="${0%/*}"
> java -cp ~/src/clojure/clojure.jar:${DP}/clj:${DP}/java -
> Dnet.sourceforge.waterfront.plugins=${DP}/clj/net/sourceforge/
> waterfront/ide/plugins clojure.main ${DP}/clj/net/sourceforge/
> waterfront/ide/main.clj $*

I propose that we Clojure-using folks adopt CLOJURE_HOME as our
"standard" environment variable that can be used to find clojure.jar
and other interesting bits of Clojure. The proposed value of
CLOJURE_HOME is an absolute path to the top level of an svn checkout
or binary distribution of Clojure.

Scripts would use $CLOJURE_HOME/clojure.jar (or its equivalent on
Windows) as the path to the current environment's preferred clojure.jar.

The script above would become:

> #!/bin/sh
> DP="${0%/*}"
> java -cp $CLOJURE_HOME/clojure.jar:${DP}/clj:${DP}/java -

> Dnet.sourceforge.waterfront.plugins=${DP}/clj/net/sourceforge/
> waterfront/ide/plugins clojure.main ${DP}/clj/net/sourceforge/
> waterfront/ide/main.clj $*
>

--Steve

[Dave Griffith]

There is a small but particularly nasty corner of the third circle of
Hell reserved for people who mandate environment variables. Don't go
there.

> smime.p7s
> 3KViewDownload

[Mark Volkmann]

I already use that so it would be fine with me!

--
R. Mark Volkmann
Object Computing, Inc.

[Phil Hagelberg]

"Stephen C. Gilardi" <sque...@mac.com> writes:

> I propose that we Clojure-using folks adopt CLOJURE_HOME as our
> "standard" environment variable that can be used to find clojure.jar
> and other interesting bits of Clojure. The proposed value of
> CLOJURE_HOME is an absolute path to the top level of an svn checkout
> or binary distribution of Clojure.

I like the idea, but does this imply that clojure-contrib.jar should be
in the same directory? Or should it look in
$CLOJURE_HOME/../clojure-contrib/clojure-contrib.jar.

Can I also suggest that if CLOJURE_HOME isn't set that it defaults to
$HOME/src/clojure? This is what clojure-mode.el's M-x clojure-install
uses, and folks seem to find that useful.

-Phil

[Stephen C. Gilardi]

On Feb 25, 2009, at 4:52 PM, Phil Hagelberg wrote:

> I like the idea, but does this imply that clojure-contrib.jar should
> be
> in the same directory? Or should it look in
> $CLOJURE_HOME/../clojure-contrib/clojure-contrib.jar.

That would work in my setup, but it seems clumsy. Perhaps Rich would
consider blessing a standard location for contrib within the Clojure
top level directory. I just tried that locally and it seems to work
fine with svn--no interference between clojure, an svn checkout
directory for clojure and clojure/contrib, a separate svn checkout
directory for clojure-contrib.

I think:

$CLOJURE_HOME/contrib

would be a good standard location for clojure-contrib and if that
becomes common practice, then the contrib jar will be at:

$CLOJURE_HOME/contrib/clojure-contrib.jar

(If this flies, at some point it would be good to add "contrib" to the
svn-ignore list for Clojure's top level directory so it wouldn't even
show up as an untracked node.)

> Can I also suggest that if CLOJURE_HOME isn't set that it defaults to
> $HOME/src/clojure? This is what clojure-mode.el's M-x clojure-install
> uses, and folks seem to find that useful.

That seems like a great default. I like it.

--Steve

[Laurent PETIT]

No, please, don't mix projects directory hierarchies,

Since clojure-contrib has such a great visibility that it's almost impossible to depend on a lib and not to depend on clojure-contrib also, I would stick to something simple, and say that the env variable for clojure-contrib home should be CLOJURE_CONTRIB_HOME.

My 0,02€,

--
Laurent

2009/2/25 Stephen C. Gilardi <sque...@mac.com>

[Meikel Brandmeyer]

Hi,

Am 25.02.2009 um 23:39 schrieb Laurent PETIT:

> No, please, don't mix projects directory hierarchies,

+1

Where is the problem to tell the people: "Set up a sane CLASSPATH
containing the clojure.jar and clojure-contrib.jar you want!" and then
just use that? Maybe there isn't even a "CLOJURE_HOME"? People
don't need the source installed....

Sincerely
Meikel

[Achim Passen]

Hi!

Am 25.02.2009 um 23:14 schrieb Stephen C. Gilardi:

(If this flies, at some point it would be good to add "contrib" to the svn-ignore list for Clojure's top level directory so it wouldn't even show up as an untracked node.)

Another way to do this is to add contrib as an svn external: http://svnbook.red-bean.com/en/1.0/ch07s03.html

Set up like this, an "svn update" in the root directory would update both projects.

Kind regards,

achim

[Stephen C. Gilardi]

On Feb 25, 2009, at 5:51 PM, Achim Passen wrote:

> Another way to do this is to add contrib as an svn external: http://svnbook.red-bean.com/en/1.0/ch07s03.html
> Set up like this, an "svn update" in the root directory would update
> both projects.

Very cool. I saw this kind of thing in action for the first time
yesterday when checking out Clozure Common Lisp via svn. I had no idea
how they did that.

I just tried it with clojure and clojure-contrib and it worked very
smoothly. One potential glitch is that the external reference for
contrib would presumably be:

contrib http://clojure-contrib.googlecode.com/svn/trunk/

However, for a member of clojure-contrib, the correct entry would be:

contrib https://clojure-contrib.googlecode.com/svn/trunk/

(https vs. http)

Have the svn folks come up with a neat solution for that case or would
a clojure-contrib member simply propedit his local clojure svn
checkout to give the correct URL for him?

Thanks for the pointer to the info about external!

--Steve

[Laurent PETIT]

2009/2/25 Achim Passen <achim....@gmail.com>

Again, please, nothing like that.
An external is a way to set a dependency from the project that uses the external to the project the external refers to.

I think clojure (core) should not depend on clojure-contrib. If so, then they really should be the same project.

Externals should be used with care, e.g. you have to consider if you want to depend on the current head of the other project, or on a particular revision.
If you use the "always depend on the most recent (head) revision of the other project", when you make a "tag" (either explicitly by copying in a new directory in the tags directory, either implicitly by giving others a rev number), you will have to remember to first "freeze" the external to a particular revision before committing your "tag" revision (and you will then just commit another revision just after that to re-enable the external to point at the head of the other project).

So it is error prone, and, in the case of clojure having an external on clojure-contrib, I think it would be the opposite of the dependency graph.

Turned in the other side, if you want to be consistent concerning clojure-contrib development, you could use an external in the clojure-contrib project, pointing at a particular revision of clojure.
But really, this would be interesting in maintenance mode, but not really now. And it is complex and error prone.

My 0,02€ again,

--
Laurent

 

Kind regards,

achim

[Laurent PETIT]

I've already answered to the external stuff in another message (and sorry for having been so crude, but I really think it's not a so good idea. In that particular case : clojure does not depend on clojure contrib. So clojure svn must not depend on clojure-contrib svn).

Concerning the https vs http problem, I haven't checked svn redbook recently (and I don't know exactly which svn version googlecode is running), but at some time in the past, it was tricky (if not impossible) to do edits and commits in an external.

--
Laurent

2009/2/26 Stephen C. Gilardi <sque...@mac.com>

[Jeff Rose]

Stephen C. Gilardi wrote:
>
> On Feb 25, 2009, at 1:27 PM, Mark Colburn wrote:
>
>> #!/bin/sh
>> DP="${0%/*}"
>> java -cp ~/src/clojure/clojure.jar:${DP}/clj:${DP}/java -
>> Dnet.sourceforge.waterfront.plugins=${DP}/clj/net/sourceforge/
>> waterfront/ide/plugins clojure.main ${DP}/clj/net/sourceforge/
>> waterfront/ide/main.clj $*
>
> I propose that we Clojure-using folks adopt CLOJURE_HOME as our
> "standard" environment variable that can be used to find clojure.jar and
> other interesting bits of Clojure. The proposed value of CLOJURE_HOME is
> an absolute path to the top level of an svn checkout or binary
> distribution of Clojure.
>
> Scripts would use $CLOJURE_HOME/clojure.jar (or its equivalent on
> Windows) as the path to the current environment's preferred clojure.jar.

What's wrong with just putting the jars in your CLASSPATH and not
requiring anything explicit in scripts? I just put all the jars I want
to use with Clojure in a single directory, clojure/jars, and they get
added automatically by my .bash_profile along with all the system
installed jars:

CLJ=$PROJECTS/clojure
CLJ_DIR=$CLJ/jars
CLJ_JARS=$(find $CLJ_DIR -name "*.jar" -exec printf {}: \;)
SYS_DIR=/usr/share/java
SYS_JARS=$(find $SYS_DIR -name "*.jar" -exec printf {}: \;)
export CLASSPATH=$CLJ_LIBS:$HOME/sw/java:$SYS_JARS:$CLJ_JARS:.

Seems to work pretty well.

-Jeff

[Stephen C. Gilardi]

On Feb 25, 2009, at 6:14 PM, Laurent PETIT wrote:

> I've already answered to the external stuff in another message (and
> sorry for having been so crude, but I really think it's not a so
> good idea. In that particular case : clojure does not depend on
> clojure contrib. So clojure svn must not depend on clojure-contrib
> svn).

Thanks for the discussion. I understand your objections and in the
face of them I estimate the probability of any of these changes being
adopted to be 0. The status quo, where there is a complete separation
of clojure and clojure-contrib, is in some ways (perhaps many ways)
simpler than using a feature of svn to combine them. Simplicity is a
high value and I'm sure it will win the day. I have no objection to
that.

For my own education, I just re-read the documentation at red-bean and
there is nothing mentioned there in the externals section about
dependencies. What they talk about is keeping code that's logically
part of one thing in separate repositories (or separate locations
within one repository). That's exactly the case with clojure and
clojure-contrib.

It seems to me that the dependency scenario you describe is one use of
externals, but not necessarily the only one.

clojure-contrib is logically part of Clojure:

- The contrib namespaces live in a namespace under the "clojure."
umbrella.
- The licensing and contribution requirements are exactly the same.
- Code can (and has) flowed from clojure-contrib into clojure.

My understanding is that the primary reason contrib code was put in a
separate svn repository is that doing so provides a clean way to have
a few more committers for clojure-contrib than the one committer for
clojure. Another benefit of having them separate (which would be
preserved in a clojure/contrib setup) is that it's clear which parts
of Clojure have Rich's full support and which parts don't.

This external mechanism in svn looks like it would allow all the
benefits of keeping them separate while avoiding some of the minor
annoyances that come with them being separate--like knowing where
clojure is installed doesn't give you any info about where clojure-
contrib is installed.

> Concerning the https vs http problem, I haven't checked svn redbook
> recently (and I don't know exactly which svn version googlecode is
> running), but at some time in the past, it was tricky (if not
> impossible) to do edits and commits in an external.

Thanks for that info.

--Steve

[Telman Yusupov]

+1 on setting a sane CLASSPATH and not depending on other environment
variables.

Then there is no need to specify a custom -cp for every Clojure/Java
program/script either...

Cheers,

Telman

P.S. My very simple CLASSPATH setup detailed here:
http://yusupov.com/blog/2009/basic-clojure-setup-part-1/

>  smime.p7s
> 5KViewDownload

[Stephen C. Gilardi]

On Feb 25, 2009, at 6:50 PM, Telman Yusupov wrote:

> +1 on setting a sane CLASSPATH and not depending on other environment
> variables.
>
> Then there is no need to specify a custom -cp for every Clojure/Java
> program/script either...

The problem I see with using CLASSPATH this way is that it
(potentially) affects the classpath for every JVM instance you launch,
not just the ones associated with Clojure. It seems to me that it's
desirable for there be a more focused way to express/maintain the
concept of "When I deal with a Clojure REPL, these are the jars I want
to be available to it."'

My most recent effort along those lines is at clojure-contrib/
launchers/bash/clj-env-dir.

--Steve

> P.S. My very simple CLASSPATH setup detailed here:
> http://yusupov.com/blog/2009/basic-clojure-setup-part-1/

Cool! Thanks for writing that up.

--Steve

[Laurent PETIT]

2009/2/26 Stephen C. Gilardi <sque...@mac.com>

On Feb 25, 2009, at 6:50 PM, Telman Yusupov wrote:

+1 on setting a sane CLASSPATH and not depending on other environment
variables.

Then there is no need to specify a custom -cp for every Clojure/Java
program/script either...

The problem I see with using CLASSPATH this way is that it (potentially) affects the classpath for every JVM instance you launch, not just the ones associated with Clojure. It seems to me that it's desirable for there be a more focused way to express/maintain the concept of "When I deal with a Clojure REPL, these are the jars I want to be available to it."'

Just to make clear that I don't always disagree with you :-), I would say +1 on that.

Setting a global CLASSPATH, while useful, can lead to awkward bugs sometimes ...
 

[Stephen C. Gilardi]

On Feb 24, 2009, at 6:47 PM, Itay Maman wrote:

> This version is fully functional and so far I didn't encounter any
> bugs.
> I guess that over the course of the next few days, as people start
> using this version,
> a few issues may come up. I'd be glad to fix these.
>
> I also took Mike's suggestion, Waterfromt's main window is now using
> a side-by-side layout.

Hi Itay,

Very nice work on waterfront! I gave it a try on Mac OS X. It worked
well and showcases many cool ideas.

I had a couple of issues:

- when building on Mac OS X with Java 6 64-bit or Java 5 32-bit, I got
errors like this one:

[javac] Compiling 1 source file to /sq/ext/waterfront/waterfront/
bin
[javac] /sq/ext/waterfront/lab/src/net/sourceforge/waterfront/ide/
services/Main.java:92: method does not override a method from its
superclass
[javac] @Override
[javac] ^
[javac] 1 error

in every case where @Override was present in the waterfront source.

I was able to build successfully by commenting all of them out.

- When using waterfront on Mac OS X, it appears that the control
characters intended to trigger menu selections (e.g. ^E) are being
intercepted before they reach the menus. In the specific case of ^E,
it is being interpreted by the text input field as "move to end of
line" which is a common meaning for it in Mac OS X. I suspect there is
a way to trigger menu items using the "command-key" on the Mac (while
still using the control key on Windows) and people using waterfront on
Mac OS X would benefit from a change to using that mechanism.

Thanks very much for waterfront!

--Steve

[Stuart Sierra]

On Feb 24, 6:47 pm, Itay Maman <itay.ma...@gmail.com> wrote:
> After a few hours of intense work I managed to port Waterfront's code
> to Clojure's latest snapshot. This version is now available for
> download as "RC1-147" at the same location

Very impressive, Itay. This strikes me as a good candidate for a
"Clojure in a Box" type of download, filling the role that IDLE does
for Python. One could easily package Waterfront, Clojure core, and
contrib in a single JAR that runs with a simple "java -jar", to help
newcomers get started with the language quickly. I can help with the
build files.

-Stuart Sierra

[Onorio Catenacci]

On Feb 25, 9:17 am, Itay Maman <itay.ma...@gmail.com> wrote:
> For those of you who tried one of Waterfront's earlier revisions and
> then switched to revision 147 (latest):
>
> In 147 there was a change in the plugin loading order (due to plugin
> dependencies). If you ran earlier versions you will get the following
> message as Waterfront is launching:
>    Can't load plugin output-window.clj. Reason: nil
>    Can't load plugin eval-as-you-type.clj. Reason: nil
>
> Here's the fix: close all Waterfront windows. Go to the directory
> indicated by Java's user.home property (typically: c:\windows
> \documents and settings\<your user name> or your Unix/Linux home
> directory) and delete the file ".waterfront.config.clj".
>

I guess my eyes aren't as sharp as they used to be Itay :-) but if we
find a bug in Waterfront, is there a place on Sourceforge to let you
know about it? I didn't see anything resembling a defect tracking
system under the Waterfront project.

--
Onorio Catenacci III

[Michael Wood]

On Wed, Feb 25, 2009 at 8:27 PM, Mark Colburn <colbur...@gmail.com> wrote:
>
> #!/bin/sh
> DP="${0%/*}"
> java -cp ~/src/clojure/clojure.jar:${DP}/clj:${DP}/java -
> Dnet.sourceforge.waterfront.plugins=${DP}/clj/net/sourceforge/
> waterfront/ide/plugins clojure.main ${DP}/clj/net/sourceforge/
> waterfront/ide/main.clj $*

You almost always want to use "$@" (including quotes) instead of $*.

See this thread for why:

http://groups.google.com/group/clojure/browse_thread/thread/769e5bf19e6636ea/a1b2a836ca229384?lnk=gst#a1b2a836ca229384

You'll also run into trouble if ${DP} contains spaces, unless you
quote those arguments too:

#!/bin/sh
DP="${0%/*}"
java -cp "~/src/clojure/clojure.jar:${DP}/clj:${DP}/java"
-Dnet.sourceforge.waterfront.plugins="${DP}/clj/net/sourceforge/waterfront/ide/plugins"

clojure.main "${DP}/clj/net/sourceforge/waterfront/ide/main.clj" "$@"

--
Michael Wood <esio...@gmail.com>

[Itay Maman]

On Feb 26, 3:02 am, "Stephen C. Gilardi" <squee...@mac.com> wrote:
> On Feb 24, 2009, at 6:47 PM, Itay Maman wrote:
>
> > This version is fully functional and so far I didn't encounter any
> > bugs.
> > I guess that over the course of the next few days, as people start
> > using this version,
> > a few issues may come up. I'd be glad to fix these.
>
> > I also took Mike's suggestion, Waterfromt's main window is now using
> > a side-by-side layout.
>
> Hi Itay,
>
> Very nice work on waterfront! I gave it a try on Mac OS X. It worked  
> well and showcases many cool ideas.
>
> I had a couple of issues:
>
> - when building on Mac OS X with Java 6 64-bit or Java 5 32-bit, I got  
> errors like this one:
>
>      [javac] Compiling 1 source file to /sq/ext/waterfront/waterfront/
> bin
>      [javac] /sq/ext/waterfront/lab/src/net/sourceforge/waterfront/ide/
> services/Main.java:92: method does not override a method from its  
> superclass
>      [javac]     @Override
>      [javac]      ^
>      [javac] 1 error
>
> in every case where @Override was present in the waterfront source.

In Java6 @Override can also be attached to a method that overrides an
interface-declared method. So, the code is not supposed to compile w/
a Java5 compiler. As for the Java6 compiler, my guess is that your
compile is configured to be Java5 complaint. So I would suggest to
specify "-source 1.6" in the javac command line. Anyway, I will add it
to the build.xml file.

>
> I was able to build successfully by commenting all of them out.
>
> - When using waterfront on Mac OS X, it appears that the control  
> characters intended to trigger menu selections (e.g. ^E) are being  
> intercepted before they reach the menus. In the specific case of ^E,  
> it is being interpreted by the text input field as "move to end of  
> line" which is a common meaning for it in Mac OS X. I suspect there is  
> a way to trigger menu items using the "command-key" on the Mac (while  
> still using the control key on Windows) and people using waterfront on  
> Mac OS X would benefit from a change to using that mechanism.

Sure.

>
> Thanks very much for waterfront!

You're very welcome.
>
> --Steve
>
>  smime.p7s
> 3KViewDownload

[Konrad Hinsen]

On Feb 26, 2009, at 12:30, Itay Maman wrote:

> In Java6 @Override can also be attached to a method that overrides an
> interface-declared method. So, the code is not supposed to compile w/
> a Java5 compiler. As for the Java6 compiler, my guess is that your
> compile is configured to be Java5 complaint. So I would suggest to
> specify "-source 1.6" in the javac command line. Anyway, I will add it
> to the build.xml file.

Do you need Java 1.6 features? Clojure itself works fine with 1.5,
and there are still machines around for which there is no 1.6 (my PPC
Mac running MacOS 10.4, for example), so it would be nice if
Waterfront could work with Java 1.5 as well.

Konrad.

[Timothy Pratley]

super slick, I love it!

[Itay Maman]

No I don't need Java6. My Eclipse is configured to be Java6-compliant
so it generates
these @Overrides annotations automatically. I agree with your point.
I'll get rid of those.

Coming to think about it, I don't even need the Java code so much. It
is just a few classes
which realize some low-level UI stuff which seemed to be more natural
in Java than in Clojure.
I do want to translate them to Clojure at some point. This will solve
this issue altogether.

-Itay

[Laurent PETIT]

2009/2/26 Itay Maman <itay....@gmail.com>

On Feb 26, 2:02 pm, Konrad Hinsen <konrad.hin...@laposte.net> wrote:
> On Feb 26, 2009, at 12:30, Itay Maman wrote:
>
> > In Java6 @Override can also be attached to a method that overrides an
> > interface-declared method. So, the code is not supposed to compile w/
> > a Java5 compiler. As for the Java6 compiler, my guess is that your
> > compile is configured to be Java5 complaint. So I would suggest to
> > specify "-source 1.6" in the javac command line. Anyway, I will add it
> > to the build.xml file.
>
> Do you need Java 1.6 features? Clojure itself works fine with 1.5,  
> and there are still machines around for which there is no 1.6 (my PPC  
> Mac running MacOS 10.4, for example), so it would be nice if  
> Waterfront could work with Java 1.5 as well.

No I don't need Java6. My Eclipse is configured to be Java6-compliant
so it generates

What ? You used Eclipse, and still wanted to get rid of it and of clojuredev ! How sad I am ... ;-)

I've taken a look at what you've done, wow !

How long did it take to realize that ? Were you working on it daily, or nightly ?

Keep up the good work !

--
Laurent

 

[Itay Maman]

>
> What ? You used Eclipse, and still wanted to get rid of it and of clojuredev
> ! How sad I am ... ;-)

:))

>
> I've taken a look at what you've done, wow !
>
> How long did it take to realize that ? Were you working on it daily, or
> nightly ?

I had a couple of weeks off at Dec. Since Jan. it is mostly night-
time.

>
> Keep up the good work !

Thanks.

[Itay Maman]

Revision 148 is available for download at
http://sourceforge.net/project/platformdownload.php?group_id=249246
It addresses some of the requests that were raised in this discussion:

* Changed default location of the divider
* Fixed the "command-key" issue on Macs.
* Java 1.5 compilance (prev. 1.6)
* Added a space in the execution time between the digits and "ms".
E.g., "34ms" --> "34 ms"
* Source -> Doc and Source -> Reflect consolidated into a single menu
item triggered by F1
* wf.sh file added
* wf.bat handles spaces in the path

Thanks you Stephen, Tom, Mike and all the other for the feedback.

Also, for those interested in the "application context pattern",
please see a post with that title published earlier today.

-Itay

[Marko Kocić]

Nice work.

I have a couple of (mostly cosmetic but important suggestions):
- Set look and feel to NativeLookAndFeel
- Allow user to increase application fonts, not just editor fonts.

Regards,
Marko Kocić

[Itay Maman]

On Feb 27, 5:22 pm, Marko Kocić <marko.ko...@gmail.com> wrote:
> Nice work.
>
> I have a couple of (mostly cosmetic but important suggestions):
> - Set look and feel to NativeLookAndFeel

I'm not sure I understand. Are you referring to
UIManager.getSystemLookAndFeelClassName() ?
This is the L&F that Waterfront is using. If you don't get this L&F
then perhaps the call to setLookAndFeel() fails on your machine. I'll
add a piece of code to log the exception.

-Itay

[Dan]

> I'm not sure I understand. Are you referring to
> UIManager.getSystemLookAndFeelClassName() ?
> This is the L&F that Waterfront is using. If you don't get this L&F
> then perhaps the call to setLookAndFeel() fails on your machine. I'll
> add a piece of code to log the exception.
>
> -Itay

It also has the ugly default swing L&F on my machine too. I'm using Linux / KDE.

[zoltar]

On Feb 25, 6:02 pm, "Stephen C. Gilardi" <squee...@mac.com> wrote:
>
> - When using waterfront on Mac OS X, it appears that the control  
> characters intended to trigger menu selections (e.g. ^E) are being  
> intercepted before they reach the menus. In the specific case of ^E,  
> it is being interpreted by the text input field as "move to end of  
> line" which is a common meaning for it in Mac OS X. I suspect there is  
> a way to trigger menu items using the "command-key" on the Mac (while  
> still using the control key on Windows) and people using waterfront on  
> Mac OS X would benefit from a change to using that mechanism.

Indeed. Instead of hard-coding modifier keys, you should use the
Toolkit.getDefaultToolkit().getMenuShortcutKeyMask(). This will
return control for windows and META (or command) for Mac.

Curtis

[Itay Maman]

Curtis,

Yes, that's exactly what I did in rev. 148, already available at
sf.net.

Thanks,
-Itay

[Itay Maman]

Dan, Marko,

I wonder whether you have the time to do a little experiment. The L&F
is set at line 182 of net/sourceforge/waterfront/ide/ui.clj. Could you
please try to see which L&F works on your machine or, otherwise,
understand why an exception is thrown there?

Thanks,
-Itay

[Dan]

On Sat, Feb 28, 2009 at 4:31 AM, Itay Maman <itay....@gmail.com> wrote:
>
> Dan, Marko,
>
> I wonder whether you have the time to do a little experiment. The L&F
> is set at line 182 of net/sourceforge/waterfront/ide/ui.clj. Could you
> please try to see which L&F works on your machine or, otherwise,
> understand why an exception is thrown there?
>
> Thanks,
> -Itay

I'm not at home right now but as soon as I return (should be Monday), I'll check

My guess is that it has to do with KDE being based on Qt. Java only
has a GTK+ look and feel for Linux so it probably consider it doesn't
have my native look and feel available and defaults to metal.

[Konrad Hinsen]

On 27.02.2009, at 15:14, Itay Maman wrote:

> Revision 148 is available for download at
> http://sourceforge.net/project/platformdownload.php?group_id=249246
> It addresses some of the requests that were raised in this discussion:
>
> * Changed default location of the divider
> * Fixed the "command-key" issue on Macs.
> * Java 1.5 compilance (prev. 1.6)

I still can't run it with Java 1.5:

java.lang.UnsupportedClassVersionError: Bad version number in .class
file (kit.clj:247)

Is there a simple way to recompile everything on my machine?

Konrad.

[Tom Ayerst]

If you pull trunk out of subversion you can build it locally with Ant.  Would that do it?

https://waterfront.svn.sourceforge.net/svnroot/waterfront/trunk

Cheers

Tom

2009/3/3 Konrad Hinsen <konrad...@laposte.net>

[Konrad Hinsen]

On Mar 3, 2009, at 11:46, Tom Ayerst wrote:

> If you pull trunk out of subversion you can build it locally with
> Ant. Would that do it?

Definitely, thanks! I pulled the latest revision and built it by
typing "ant". No compilation errors, but I can't run it either:

Can't load plugin custom-editor.clj. Reason:
java.lang.ClassNotFoundException:
javax.swing.filechooser.FileNameExtensionFilter (file.clj:171)
Can't load plugin context-menu.clj. Reason: nil
Can't load plugin file.clj. Reason: java.lang.ClassNotFoundException:
javax.swing.filechooser.FileNameExtensionFilter (file.clj:171)
Can't load plugin problem-window.clj. Reason: nil
Can't load plugin undo.clj. Reason: java.lang.Exception: LazySeq used
in 'if' (lexer.clj:0)
Can't load plugin comments.clj. Reason: java.lang.Exception: Unable
to resolve symbol: create-undo-transaction in this context
(comments.clj:48)
Can't load plugin line-column.clj. Reason: nil
Can't load plugin find.clj. Reason: java.lang.Exception: Unable to
resolve symbol: create-undo-transaction in this context (find.clj:117)
Can't load plugin indicator.clj. Reason: nil

Can't load plugin output-window.clj. Reason: nil

Can't load plugin check-syntax.clj. Reason: java.lang.Exception:
LazySeq used in 'if' (lexer.clj:0)
Can't load plugin indent.clj. Reason: java.lang.Exception: Unable to
resolve symbol: create-undo-transaction in this context (indent.clj:125)
Can't load plugin paren-matching.clj. Reason: java.lang.Exception:
LazySeq used in 'if' (lexer.clj:0)
Can't load plugin eval-as-you-type.clj. Reason: java.lang.Exception:
LazySeq used in 'if' (lexer.clj:0)
java.lang.NullPointerException
at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:26)
at net.sourceforge.waterfront.ide.plugins$set_font__1700.invoke(font-
observer.clj:20)
at net.sourceforge.waterfront.ide.plugins$set_fonts__1703.invoke
(font-observer.clj:26)
at net.sourceforge.waterfront.ide$dispatcher__550$fn__554.invoke
(ui.clj:85)
...

It looks as if my installation lacks parts of Swing, but there also
seem to be some lazy-seq-related bugs in Waterfront itself (my
Clojure is compiled with clojure.assert-if-lazy-seq=true).

Is anyone running Waterfront successfully on a Mac with Java 1.5?

Konrad.

[Itay Maman]

Konrad,

Your installation is probably fine. The problem lies in the
FileNameExtensionFilter class. It was only introduced in Java6.
Therefore, despite the fact
that you now have binaries that are compatible with your JVM, the
program does not run. I'll try to fix this soon. I'll post a message
when a new revision is up.

Alternatively hoping that this is the only Java6-only dependency in
the code, you can also apply this patch to clj/net/sourceforge/
waterfront/ide/plugins/file.clj (I didn't test is though - I am away
from my machine, so no warranty...)

Replace lines 169..173 with this:

(defn add-chooser [app]
(let [chooser (javax.swing.JFileChooser. (. System getProperty
"user.dir"))]
(assoc app :file-chooser chooser) ))


Hope that helps.
-Itay

[Konrad Hinsen]

Itay,

> Alternatively hoping that this is the only Java6-only dependency in
> the code, you can also apply this patch to clj/net/sourceforge/
> waterfront/ide/plugins/file.clj (I didn't test is though - I am away
> from my machine, so no warranty...)

Thanks for the quick fix, it works!

I can now start Waterfront and work with it, but there are still some
error messages at startup concerning certain plugins:

Can't load plugin undo.clj. Reason: java.lang.Exception: LazySeq used
in 'if' (lexer.clj:0)
Can't load plugin comments.clj. Reason: java.lang.Exception: Unable
to resolve symbol: create-undo-transaction in this context
(comments.clj:48)

Can't load plugin find.clj. Reason: java.lang.Exception: Unable to
resolve symbol: create-undo-transaction in this context (find.clj:117)

Can't load plugin check-syntax.clj. Reason: java.lang.Exception:
LazySeq used in 'if' (lexer.clj:0)
Can't load plugin indent.clj. Reason: java.lang.Exception: Unable to
resolve symbol: create-undo-transaction in this context (indent.clj:125)
Can't load plugin paren-matching.clj. Reason: java.lang.Exception:
LazySeq used in 'if' (lexer.clj:0)
Can't load plugin eval-as-you-type.clj. Reason: java.lang.Exception:
LazySeq used in 'if' (lexer.clj:0)

I applied two fixes in lexer.clj that get rid of all these messages:

1) Replace first-is by

(defn first-is
{ :test (fn []
(assert-eq false (first-is \a (seq "")))
(assert-eq true (first-is :nothing (seq "")))
(assert-eq true (first-is \a (seq "a")))
(assert-eq false (first-is :nothing (seq "a")))
(assert-eq true (first-is \a (seq "ab")))
(assert-eq false (first-is :nothing (seq "ab")))
(assert-eq false (first-is \a (seq "ba")))
(assert-eq false (first-is :nothing (seq "ba"))) )}
[e es]
(if (seq es)
(= e (first es))
(= e :nothing) ))

2) Replace get-mate-from-pairs by

(defn get-mate-from-pairs
{ :test (fn []
(assert-eq [:match 4] (get-mate-from-pairs (compute-
paren-matching-pairs "01[3]5") 2)) )}
[pairs offset]
(let [pair (filter (fn [x] (= offset (second x))) pairs)]
(if (seq pair)
[(nth (first pair) 0) (nth (first pair) 2)]
nil )))

Konrad.

[aperotte]

Hi,

I'm using linux (Ubuntu) and none of the above scripts worked for me.
I added the ${DP}/bin directory to the classpath list to get it to
work.

#!/bin/sh
DP="${0%/*}"
java -cp ~/src/clojure/clojure.jar:${DP}/clj:${DP}/java -
Dnet.sourceforge.waterfront.plugins=${DP}/clj/net/sourceforge/
waterfront/ide/plugins clojure.main ${DP}/clj/net/sourceforge/
waterfront/ide/main.clj $*

P.S. - The text editor you are using for the shell script is encoding
DOS style newlines and doesn't work on linux. I copied the text to a
new file to get around it.

-Adler

On Feb 25, 4:32 am, Itay Maman <itay.ma...@gmail.com> wrote:
> On Feb 25, 11:08 am, bOR_ <boris.sch...@gmail.com> wrote:
>
> > I'm trying to rewrite the wf.bat to a linux version, but I was a bit
> > puzzled what all the ;%~dp0 's mean.
>
> In .bat files %~dp0 specifies the directory where the .bat file is
> located.
> In sh scripts, it should be `dirname $0`.
>
> >Apparently the bash version of it
> > is ${0%/*}
>
> > java -cp ~/src/clojure/clojure.jar;${0%/*}clj;${0%/*}java -
> > Dnet.sourceforge.waterfront.plugins=${0%/*}clj/net/sourceforge/
> > waterfront/ide/plugins clojure.main ${0%/*}clj/net/sourceforge/
> > waterfront/ide/main.clj %*
>
> > It seems like you're also assuming 'clj' to exist?
>
> clj and java are the subdirectories in the Waterfront installation
> directory. So if the zip was unzipped
> successfully, it is safe to assume they exist.
>
> I don't have a Linux machine. Could you send me this script (one it is
> up and running)
> so that I will put it inside the .zip file?
>
> Thanks,
> -Itay
>
> > On Feb 25, 2:57 am, Kevin Albrecht <onlya...@gmail.com> wrote:
>
> > > Itay,
>
> > > I took a look at Waterfront and it seems to have a lot of potential.
> > > Keep me and the group updated on your future work.
>
> > > I have also been working on a GUI application in Clojure and I share
> > > your perspective on the challenges of designing a functional GUI.  I
> > > am definitely intrigued by the application context pattern and I am
> > > going to take a look at it for incorporation in my design.
>
> > > Thanks,
> > > Kevin Albrecht
>
> > > On Feb 24, 6:04 am, Itay Maman <itay.ma...@gmail.com> wrote:
>
> > > > I've been silently following Clojure (and this group) for several
> > > > months now.Somewhere around December I started working on a Clojure
> > > > editor/REPL written in Clojure. This effort evolved into the
> > > > Waterfront project which is now available on sourceforge (http://
> > > > sourceforge.net/project/showfiles.php?group_id=249246).
>
> > > > Waterfront's Highlights:
>
> > > > * CTRL+E: Eval current selection, or the whole file if the selection
> > > > is empty
> > > > * Edit -> Eval as you type: When turned on (default) periodically
> > > > evaluates your code. Boosts productivity as many errors are detected
> > > > on the spot.
> > > > * Eval-ed code can inspect/mutate Waterfront by accessing the *app*
> > > > variable. For instance, if you eval this expression,
> > > > ((*app* :change) :font-name "Arial"), you will choose "Arial" as the
> > > > UI font.
> > > > * Eval-ed code can inspect the currently edited Clojure program. For
> > > > instance, if you eval this expression, ((*app* :visit) #(when (= (str
> > > > (first %1)) "cons") (println %1))), the output window will show all
> > > > calls, made by your code, to the cons function.
> > > > * Syntax and Evaluation errors are displayed on: (1) The Problems
> > > > window; (2) The line-number panel, as red markers.
> > > > * Source -> Generate -> Proxy: Generates a proxy for the given list of
> > > > super-types, with stub implementations for all abstract methods.
> > > > * F1: Shows the doc (as per Clojure's (doc x) function) of the
> > > > identifier under the caret.
> > > > * Source -> Reflect: Shows the synopsis of a Java class when the caret
> > > > stands on a class symbol (e.g.: java.awt.Color).
> > > > * CTRL+Space: Token-based auto completion.
> > > > * Full parenthesis matching.
> > > > * An extensible plugin architecture.
> > > > * Other goodies such as undo/redo, toggle comment, recently opened
> > > > files, indent/unindent, Tab is *always* two spaces, ...
>
> > > > In order to get started, you need to
> > > >   (1) Download the waterfront zip file from:http://sourceforge.net/project/showfiles.php?group_id=249246.
> > > >   (2) Unpack it into a local directory.
> > > >   (3) Edit wf.bat: fix the path to clojure.jar according to its
> > > > location on your machine.
>
> > > > Personally, this effort was quite interesting. Writing GUI
> > > > applications in a functional language is sometimes a challenging task
> > > > (at least if you want your Clojure code not to be a transliteration of
> > > > Java code…).  I used a pattern the "application context" pattern: an
> > > > immutable map describing the application's current state that is
> > > > passed around. This made it possible for most of Waterfront's code to
> > > > be purely functional. Consequently, plugins can accomplish a lot with
> > > > just a handful of lines. Many plugins span about 60 lines of code.
> > > > Vast majority of them are less than 200 LOC. The main module, ui.clj,
> > > > that implements the underlying engine is also less than 200 LOC. I
> > > > think this is a very good indication to Clojure's power.
>
> > > > Hope you'll find it useful. I'd be happy if anyone would like to join
> > > > and contribute to Waterfront. Your feedback, either on-line or
> > > > offline, will be highly appreciated.
>
> > > > --
> > > > Itay Mamanhttp://javadots.blogspot.com

[Itay Maman]

Adler, Konard:

Thank you guys for the patches.
-Itay

[Michael Wood]

On Tue, Mar 3, 2009 at 9:14 PM, aperotte <aper...@gmail.com> wrote:
>
> Hi,
>
> I'm using linux (Ubuntu) and none of the above scripts worked for me.
> I added the ${DP}/bin directory to the classpath list to get it to
> work.
>
> #!/bin/sh
> DP="${0%/*}"
> java -cp ~/src/clojure/clojure.jar:${DP}/clj:${DP}/java -
> Dnet.sourceforge.waterfront.plugins=${DP}/clj/net/sourceforge/
> waterfront/ide/plugins clojure.main ${DP}/clj/net/sourceforge/
> waterfront/ide/main.clj $*

There are some bugs in your script. See my post in this thread from a
few days ago for details:
http://groups.google.com/group/clojure/browse_thread/thread/d5ce5ddb679cb8f9/79919526bf401a08?lnk=gst#79919526bf401a08

> P.S. - The text editor you are using for the shell script is encoding
> DOS style newlines and doesn't work on linux.  I copied the text to a
> new file to get around it.

--
Michael Wood <esio...@gmail.com>

[aperotte]

Michael, Itay,

I apologize, that was actually an intermediate script. I also
incorporated Michael's suggestion. The only thing that's different
from Michael's is the addition of the bin directory. Also, my script
assumes that you've set a CLASSPATH environment variable to contain
the clojure jar file. This is my current script:

#!/bin/bash

DP="${0%/*}"
java -cp "$CLASSPATH:${DP}/clj:${DP}/java:${DP}/bin" -
Dnet.sourceforge.waterfront.plugins="${DP}/clj/net/sourceforge/

waterfront/ide/plugins" clojure.main "${DP}/clj/net/sourceforge/

waterfront/ide/main.clj" "$@"

-Adler

On Mar 4, 1:14 am, Michael Wood <esiot...@gmail.com> wrote:

> On Tue, Mar 3, 2009 at 9:14 PM, aperotte <apero...@gmail.com> wrote:
>
> > Hi,
>
> > I'm using linux (Ubuntu) and none of the above scripts worked for me.
> > I added the ${DP}/bin directory to the classpath list to get it to
> > work.
>
> > #!/bin/sh
> > DP="${0%/*}"
> > java -cp ~/src/clojure/clojure.jar:${DP}/clj:${DP}/java -
> > Dnet.sourceforge.waterfront.plugins=${DP}/clj/net/sourceforge/
> > waterfront/ide/plugins clojure.main ${DP}/clj/net/sourceforge/
> > waterfront/ide/main.clj $*
>
> There are some bugs in your script.  See my post in this thread from a

> few days ago for details:http://groups.google.com/group/clojure/browse_thread/thread/d5ce5ddb6...

>
> > P.S. - The text editor you are using for the shell script is encoding
> > DOS style newlines and doesn't work on linux.  I copied the text to a
> > new file to get around it.
>
> --

> Michael Wood <esiot...@gmail.com>