Re: Proposed New Structure (starter for 10)

Paul Landes <[email protected]> writes:

> On Aug 26, 2015, at 11:19 AM, Phillip Lord <[email protected]> wrote:
>
>> Indeed, this is a risk. Although I am not entirely convinced that this
>> is caused by actually compiling the classes, merely that they have been
>> recompiled which potentially will cause all the issues that you mention.
>> 
>> At the moment I tend toward thinking that the build tool interaction
>> should be out-of-band of nREPL and the JVM, simply because maven has no
>> decent API. But then, for example, how do I get the source paths?
>
> I think from maven (see more reasons below).
>
> Have you seen maven shell? If used, need not be literally from the command
> line, but I assume they've done the tricky work and provide an interface that
> should be easy to find based on what the REPL (maven shell REPL) is using.
>
> https://github.com/jdillon/mvnsh

In my hands, anyway, it doesn't even compile.

Another possibility is to just use malabar-mode which uses EDE to manage
the projects and generate the mvn commands.


>> Ironically, I had a quick peak at the JDEE source and discovered that it
>> actually includes a DynamicClassLoader that is supposed to reload from
>> file every time.
>
> Yes, the beanshell dynamic class loader, which loads byte codes generated by
> the ASM library.

jde.util.DynamicClassLoader? Looks like a different one to me.

>> They are supposed to be accessible for GC as you say.
>
> Right, and I'm saying even when nulling out the variable function bindings
> they'll still hang around because the JVM loaded the class and despite the GC
> running won't get rid of it. It lives forever in perm space. Maybe this was
> just a bug on the JVM I was using at the time, but this was fairly recent.

I am unsurprised. Class loaders often seem like a good solution, but
normally turn out to be horrendously complicated.


>> My strategy for dealing with this was to use Vinyasa
>> (https://github.com/zcaudate/vinyasa) which has a "reimport"
>> functionality.
>
> I've already gone down this route and had no luck with it reloading
> classes as it should. I emailed the author and said it was a known bug
> with the current (at the time) version of Clojure but didn't have a
> lot of time to go back and fix it. That's where I left it after failed
> attempts to use Clojure's dynamic class loader directly (which is what
> vinyasa in turn uses). This was about 6 - 8 months ago and things
> change and my memory has been known to fail.

Okay, that's a shame. There should be a law against good ideas failing
because the libraries don't quite work as you think they should!



>> Use of Java source, I agree, I can see the advantages. But set against
>> this is dealing with the issues of when the Java source is wrong.
>
>
> When the Java source is wrong the parsing API should know where and why and
> then point to the issue. This gives us fly compile for "free" if we get it
> working.

Possibly, if the parser is rich enough and sane enough to give rich
compilation messages.


>>>> Incidentally, I was thinking of renaming jdee-live again to "jive" just
>>>> for shortness.
>>>> 
>>> 
>>> Not sure that's a great idea.
>> 
>
> Even "jve" is fine, but "jive" _could_/_might_ be perceived as less
> than PC in the United States.

I didn't know that.

Phil

------------------------------------------------------------------------------