On Jun 19, 12:29 pm, James Abley <james.ab...@gmail.com> wrote:
> 2009/6/19 rssh <rus...@shevchenko.kiev.ua>:
>
>
>
> > // In termware for debug mode special debug chunk (class with all
> > work: wrap call of interpreter from java-class with correct JSR-45
> > pmap) is
> > //created for each line.
>
> > So, this issue can be solved in fully interpreted version, but in
> > extremely ugly way.
> > [It would be good to include entries for trace manipulation in next
> > version of JSR-233 API]
>
> Did you mean JSR-223 - Scripting?
>
Yes
>
>
>
>
> >> On Jun 17, 8:37 pm, James Abley <james.ab...@gmail.com> wrote:
>
> >> > Hi,
>
> >> > Part of the attraction of having languages other than Java on the JVM
> >> > is that arguably more powerful, apt, glue languages can be used for
> >> > certain parts of an application, and then use Java (either for legacy
> >> > reasons) or performance, etc.
>
> >> > One thing that I've encountered recently is the inability to debug
> >> > Ruby code (set breakpoints, etc) along with breakpoints in Java code -
> >> > I can only debug one layer (tried with Eclipse and IDEA; can't do it
> >> > in Netbeans either, but I don't know Netbeans very well).
> >> > .
> >> > I'm curious what experiences other language implementers have had in
> >> > providing support for this functionality, both in sharing ideas /
> >> > implementation experiences and to consider the possibility of any
> >> > common requirements that might need to be pushed up into the JVM, a la
> >> > invokedynamic? Is there more than JSR-45 required?
>
> >> > Cheers,
>
> >> > James
>
> >> > N.B. I'm aware that there is sometimes a chasm to cross in terms of
> >> > attracting an audience to a language [1]; I think that languages on
> >> > the JVM have to contend with the fact that Java the Language offers
> >> > pretty good tooling and so that is a box that needs to be checked in
> >> > order to attract significant mind-share, unless the other features are
> >> > so compelling.
>
> >> > [1]http://osteele.com/archives/2004/11/ides
>
> Sorry, I could have been clearer in my original post. I'll try again.
>
> From a user perspective, I would like something like the following:
>
>
> JRuby, it should be starting up the process so that ruby debugging is
> on port X and Java debugging is on port Y, and let me do both, if I
> want that option. There are a lot of legacy Java libraries out there
> and that is one of the selling points of writing a language for the
> JVM.
>
It means that we must have separate debug protocol for each language,
which can be different from Java.
I'm not sure, that maintaining 'separate' view of program state in
two different
languages is possible and more useful than one mixed state. I. e.
usually we
debug mix of Java and other languages and one mixed state give us more
information.
(From other side - of course it depends, may be for jruby we have
other situation)
>
> I believe that what I'm asking should Just Work. So I'd like to know
> if this support is offered in some JVM languages and not others, and
> what common things can be learned to improve the shared state of the
> art.
>
In general, contract between debugger and VM is defined by JPDA:
debugger user JODA VM API:
http://java.sun.com/javase/6/docs/jdk/api/jpda/jdi/index.html
JDI is defined in term of mirrors for constructions, specified in Java
programming language.
What can be near ideal solution in long-term perspective: is to
define set of 'language-neutral'
analogues of JDI interfaces (let's name one Language Debug
Interface, LDI) in such case, that
language implementer can register set of callback interfaces and one
root object
('view for VM state from language X) in some registry, so debugger
will be able call
LNI methods provided by language, to show current stack frame, state
of variables, etc.
More realistic and 'hacky' approch is to emulate Java debugging, by
providing JDWP
(http://java.sun.com/javase/6/docs/technotes/guides/jpda/jdwp-
spec.html) interface
implemented in own debug server.
> Cheers,
>
> James
>
> [1]http://www.netbeans.org/issues/show_bug.cgi?id=135357
> [2]http://gist.github.com/132520
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---