Are there any discrete tasks that would benefit from having a group
of us in the same place we can extract from this discussion? i.e.
are there potential "Hackathon" topics [1] here?
What level of priority is this work in terms of potential for
funding by the EF? [2]
Wayne
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=471463
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=471462
On 06/07/15 12:45 PM, Michael Scharf
wrote:
On
2015-07-04 18:05, Max Rydahl Andersen wrote:
On 1 Jul 2015, at 20:56, Oberhuber, Martin
wrote:
With tern claiming support for
Eclipse/Java , I'm wondering how much of a parser JSDT even
needs ?
Perhaps syntax highlighting would be sufficient, with the rest
offloaded to tern ?
http://ternjs.net/doc/manual.html#tern_java
You guys should come to our talks and discussions on this ;)
You just described what we are trying to get to. Allow us to use
external tools (like tern etc.) since
the _javascript_ world moves way faster than we can currently
efficiently implement it in eclipse/java.
I really think this is an interesting eclipse architectural issue.
The
level at which the eclipse platform supports language integration
great to build something like JDK. The building blocks are very
low
level and many projects started by copying JDK or some similar
project
The platform has no mechanisms to simply contribute any kind of
external (or even internal) tools. Each *DK creates its own
editors,
views, index and extension points. They are not interoperable.
There seem to be a few attempts to solve the problem, like
- Xtext https://eclipse.org/Xtext/ (which is extreme, because it
generates a *DK for
each language)
- DLTK https://www.eclipse.org/dltk/ or
http://www.ibm.com/developerworks/opensource/tutorials/os-eclipse-octave/
- LangEclipseIDE:
https://github.com/bruno-medeiros/LangEclipseIDE/blob/master/README-LangEclipseIDE.md
- LiCLipse http://www.liclipse.com/supported_languages.html
- AntLng https://github.com/dschaefer/antlng
- ... (I am sure that there 5-10 more attempts to solve the
problem)
There is not clear winner. It is the beauty of the bazaar.
The eclipse platform does not provide anything that allows to
easily
add external tools and language support the way the popular
editors
allow it (like Emacs, vim, Sublime, Atom, TextMate, Notepad++)...
Erich Gamma and his team believe the pendulum is swinging
from IDEs to (smart) editors:
https://channel9.msdn.com/Events/Build/2015/3-680
Therefore VS Code takes the approach to integrate with external
tools. He also talks about progressive support for languages,
starting
form simple syntax highlighting...
The really interesting thing is, that Walter Bischofberger
(he was on Erichs team in the early 90ies) wrote an interesting
paper on a lightweight IDE architecture for a tool called
sniff:
"Sniff—A Pragmatic Approach to a C++ Programming Environment."
http://www.ubilab.org/publications/print_versions/pdf/sniff_usenix_92.pdf
This paper is 23 years old, but I think the ideas described in the
paper are still very valid. I can see, how some of those (old)
ideas
enter into VS Code. I have been working on the commercial version
of
sniff for many years, and that my cause a bias in my thinking into
direction of that kind of architecture. (sorry Doug for repeating
myself for many years...)
I am not sure if a "council" can do anything about architecture,
but I
believe that all the knowledge to do something is within the
architecture
council. The question is how to execute to turn the bazaar a
little
bit more into a cathedral. A cathedral needs architecture a bazaar
only
needs a bit of coordination.
I hope eclipse is not one of the cathedrals that was created by
great
architects, but the architects are gone, and the walls are still
there
and although they provide nice places for the bazaar, the
cathedral
slowly falls apart...
Michael
/max
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
-----Original Message-----
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx]
On Behalf Of Michael Scharf
Sent: Wednesday, July 01, 2015 3:01 PM
To: Max Rydahl Andersen; eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] _javascript_: a
bug that makes me really sad....
Thus you at least don't get these
bogus warnings/error markers.
+1 excellent. Not having some warnings is way better than
polluting the workspace with wrong error messages...
Does the parser work in that case correctly. I think the
change in _javascript_ that causes lots of problems is that
keywords can be used as keys of objects and when there is a
`.` before the word.
Classical lexer/parsers handle language keywords special.
I guess the PR solves this problem....
Michael
On 2015-07-01 13:45, Max Rydahl Andersen wrote:
wtp-dev is where you should raise this.
We have a PR for SR1 that will go in an disable this 1998
crappy validation.
Thus you at least don't get these bogus warnings/error
markers.
/max
I am excited about mars being out. But there is a bug,
that makes me
really really sad. The most popular eclipse package is
JavaEE and it
contains _javascript_. But eclipse supports only _javascript_
1998.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=223131
The most annoying problem is that modern versions of
_javascript_ allow
keywords if they are part of a data structure:
promise.catch(function(){...});
var foo {
default: 42
}
Many libraries use `throw` and `catch` as methods on
objects and this
causes a lot of errors and the rest of the file cannot be
parsed.
I know there are a lot of different _javascript_ solutions
out there
that work better than this. But, the out of box experience
with
eclipse is, well suboptimal.
Is there anything the architecture council can do about
this?
Michael
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-cou
ncil
IMPORTANT: Membership in this list is generated by
processes internal to the Eclipse Foundation. To be
permanently removed from this list, you must contact
emo@xxxxxxxxxxx to request removal.
/max
http://about.me/maxandersen
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes
internal to the Eclipse Foundation. To be permanently removed
from this list, you must contact emo@xxxxxxxxxxx to request
removal.
/max
http://about.me/maxandersen
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes
internal to the Eclipse Foundation. To be permanently removed
from this list, you must contact emo@xxxxxxxxxxx to request
removal.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
|
