Hello,

If you like eclipse and would like to see where clojuredev (eclipse
plugin) is right now, you can give a quick look at the current state
of clojuredev by trying to immediately install it via the update site
link :

http://clojure-dev.googlecode.com/svn/updatesite/

Still not ready for public availability (it's alpha alpha), but that's
a start.

And you could subscribe to clojuredev user ml: very very low traffic
(no message right now :-), and we could jut publish announces when
something interesting for users is ready on the update site.

Quickly, what is available right now :
- enable a java project with clojure dev nature (contextual menu of
the java project, -> Clojure submenu)
- wizard for creation of clojure project (= java project + clojure
nature)
- syntax coloring
- some keyboard accelerators for :
   - jump to matching bracket : Ctr+Shift+P
   - Go to start of top level defun : Ctrl+Alt+A (or AltGr+A)
   - Go to end of top level defun : Ctrl+Alt+E (or AltrGr+E)
   - Select (highlight) top level defun : Ctrl+Altr+H (or AltrGr+H)
- Launch configuration for clojure : enable to select which files to
load on startup, and other things similar to java launch
configuration. Not yet possible to select a main method other than
clojure.lang.Repl (will change at some point in time)

If you have time, please give it a try, do some feedback, and fill
free to submit tickets if you find bugs (in the features listed above,
the other ones you may find via menus are not yet ready, even if the
menu are there).

Regards,

--
Laurent

On Jan 11, 3:18 am, e <evier...@gmail.com> wrote:
> seems like enclosjure addresses a bunch of my problems/questions.  It
> also seems to work like we wanted SLIME to work, more or
> less . . .where you attach to the vm that's used for execution . . .
> only you attach to the REPL, I think, which still accomplishes the
> goal of keeping the editor separate from the memory, but what about
> having the REPL being able to attach to the vm it is managing.  Then
> it wouldn't be something that NetBeans/enclosure is doing . . . rather
> something that's part of the language.
>
> So, yeah.  enslojure sets up a HelloWorld that you can play with right
> away.  In fact, when you click on "build" it even tells you how you
> could run your application from the command line using a java
> command.  It jars up you whole clojure project and everything.  Nice.
> On the other hand, I couldn't figure out how to use NetBeans' run
> button.  it couldn't find main or something.  So I also couldn't debug
> using NetBeans' debugger because of this.  Also, it isn't clear how to
> get different clojure files to work together.  Do you use the (load)
> function?  If so, I don't know how the project thinks of relative file
> locations.  It's not as clean/clear as java (for a beginner, at least)
> where you just import classes you want to use . . and make
> packages. . . . or modules in python.  I don't know what the notion of
> "path" is in clojure.  I see the namespace stuff but have no clue how
> to make it work yet.  Are you just supposed to use one giant file for
> all your work?  That wouldn't be good for teams, for sure. . . only
> for hacking.  Also the REPL errors are USELESS to a beginner.
> something about iSeq all the time.  The moral for me there was no to
> make an error.  Better than where I was before enclojure.  Again, I
> contend that a language is only as good as the IDE that has been
> written for it, which is why it's cool to see enclojure coming along
> (even though it means learning NetBeans instead of Eclipse).
>
> On Jan 10, 5:31 pm, Paul  Mooser <taron...@gmail.com> wrote:
>
> > If I'm not mistaken, this is fairly close to how SLIME works, when
> > connected to a remote VM. The remote VM is running some server code
> > which allows it to communicate with SLIME, which is running inside of
> > emacs.
>
> > On Jan 10, 2:15 pm, e <evier...@gmail.com> wrote:
>
> > > exactly. . . .but I bet a lot of people would just reply that this is
> > > not possible to address since the REPL is the one and only vm.
> > > Disclaimer, I'm only guessing at that, too.  I don't understand any of
> > > this, yet.  But if that's the case, fix that.  Have the REPL send
> > > messages to the vm that's running the program . . . instead of the
> > > REPL being the program.
>
> > > On Jan 10, 5:00 pm, Paul  Mooser <taron...@gmail.com> wrote:
>
> > > > Yeah, I'm not really sure how I think the problem would be ideally
> > > > solved. It would just be nice for an interactive programming
> > > > environment to be able to recover from all exceptions that happen at a
> > > > higher level than the VM itself.
>
> > > > On Jan 10, 12:20 pm, "Christian Vest Hansen" <karmazi...@gmail.com>
> > > > wrote:
>
> > > > > I don't think it is possible to define a way to deal with heap
> > > > > saturation that is general enough to cover all programs written in
> > > > > Clojure, and therefor I don't think this is something that the Clojure
> > > > > runtime should deal with at all.
>
> > > > > Personally, I only know of two ways to handle OutOfMemoryErrors: 1)
> > > > > let the program blow up and hope someone notices or 2) look at your
> > > > > body, pick the limb you are least likely to be needing pretty soon and
> > > > > cut it off (aka. free some memory) and _then_ yell for help through
> > > > > some hopefully reliable channel.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to