Re: File organization & bootstrapping

2009-01-08 Thread Stuart Sierra
On Jan 7, 12:19 am, "Phil Hagelberg" wrote: > The problem with this is that now you have to repeat your classpath in > two places: your SLIME config and the shell script that you use to > launch your app. This is a DRY[1] violation. I guess I just take that for granted with Java. The classpath

Re: File organization & bootstrapping

2009-01-07 Thread Phil Hagelberg
Craig McDaniel writes: > Connect to your running app from emacs by using "M-x slime-connect" > rather than "M-x slime". When you're done, use "M-x slime- > disconnect" (or from the REPL, "," then "disconnect") to leave your > process running. In addtion, including swank in your running > product

Re: File organization & bootstrapping

2009-01-07 Thread Craig McDaniel
Getting back to Phil Hagelberg's comment that maintaining a project's classpath in both a SLIME config and shell script for each project/ application is a "Don't Repeat Yourself" violation, there is a way to avoid that: Don't bother with swank-clojure-extra-classpaths. Instead, include / path/to/

Re: File organization & bootstrapping

2009-01-07 Thread Stephen C. Gilardi
On Jan 7, 2009, at 2:04 PM, Shawn Hoover wrote: Clojure developers, would it be a good idea for Compiler.java or clojure.core/compile to check if *compile-path* exists, else throw an exception specific to that problem? I like the idea. There is a subtle problem I don't think it will catch

Re: File organization & bootstrapping

2009-01-07 Thread Shawn Hoover
On Wed, Jan 7, 2009 at 1:45 PM, Greg Harman wrote: > > Bingo - *compile-path* was a relative dir. Defining it as the full > path did the trick. > > Thanks! > > > Also, make sure the directory named by *compile-path* exists on the file > > system. Compilation creates subdirs, but not *compile-path

Re: File organization & bootstrapping

2009-01-07 Thread Greg Harman
Bingo - *compile-path* was a relative dir. Defining it as the full path did the trick. Thanks! > Also, make sure the directory named by *compile-path* exists on the file > system. Compilation creates subdirs, but not *compile-path* itself. --~--~-~--~~~---~--~~ Y

Re: File organization & bootstrapping

2009-01-07 Thread Shawn Hoover
On Wed, Jan 7, 2009 at 12:34 PM, Greg Harman wrote: > > This is frustrating - with a fresh REPL I'm back to the compile > problem. I can't think of anything I changed that would cause it to > work intermittently, and I don't know what file it's looking for... > the source files are on the classpa

Re: File organization & bootstrapping

2009-01-07 Thread Greg Harman
> One solution would be to load a single file and then have that file use > add-classpath to set the classpath, but add-classpath is unreliable; > I've had problems getting it to work consistently and have been told in > #clojure that I shouldn't be using it. Possibly the cause of the compile pro

Re: File organization & bootstrapping

2009-01-07 Thread Greg Harman
This is frustrating - with a fresh REPL I'm back to the compile problem. I can't think of anything I changed that would cause it to work intermittently, and I don't know what file it's looking for... the source files are on the classpath (it "require"s just fine) and the directory in *compile-path

Re: File organization & bootstrapping

2009-01-07 Thread Phil Hagelberg
> I think you may be working at too low a level with "load". You should > be able to accomplish the same thing with: > > (ns my-app > (:require package1 package2)) > > (package2/start-app) > > my_app, package1, and package2 all need to be immediately under a > directory (or JAR file

Re: File organization & bootstrapping

2009-01-07 Thread Greg Harman
Nevermind, with a fresh start today (and perhaps more importantly, perhaps, a fresh environment) compiling seems to work fine. > It works for "require" and for calling functions in the package(s), > but the problem now is that it doesn't work for AOT from the REPL. > > (compile 'package1) crashes

Re: File organization & bootstrapping

2009-01-06 Thread Greg Harman
Thanks Stuart, That's a good simplification, and everything seem kosher in terms of loading from the REPL. I would like to structure my libs (package1, package2 in the example) such that they span multiple files. So the main file for the namespace/lib still needs to have "load" operations to get

Re: File organization & bootstrapping

2009-01-06 Thread Stuart Sierra
Hi Greg, I think you may be working at too low a level with "load". You should be able to accomplish the same thing with: (ns my-app (:require package1 package2)) (package2/start-app) my_app, package1, and package2 all need to be immediately under a directory (or JAR file) on the

Re: File organization & bootstrapping

2009-01-06 Thread Greg Harman
In partial answer to my own question, I found these threads helpful: http://groups.google.com/group/clojure/browse_thread/thread/bf9672989524a1bf/1f35a50643bd6325?lnk=raot http://groups.google.com/group/clojure/msg/58e3f8e5dfb876c9 Everything seems to work well, except compilation. I'll post any

File organization & bootstrapping

2009-01-06 Thread Greg Harman
Hi all, I'm struggling a bit with how best to organize and bootstrap a multiple-source file project so that it can be run either command-line (java -cp clojure.jar:myapp.jar ...) or by running a load method from the REPL without having to explicitly change the classpath in my user.clj before runn