|
Yeah, but that's not until next March. I'm starting a few things as soon as I get back from holidays next week. Need to keep the momentum going.
Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Wayne Beaton
Sent: Monday, July 6, 2015 12:31 PM
To: eclipse.org-architecture-council@xxxxxxxxxxx
Reply To: eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] _javascript_: a bug that makes me really sad....
|
I am hopeful that you will be able to continue your streak and maybe set something up for EclipseCon. I'm thinking that an EclipseCon "extended hackathon" (maybe we need a better term) might be a good opportunity to connect with those individuals who are
interested in extending and improving the Launch Bar, but maybe let's not hijack this thread for that discussion.
Google Hangouts would be cool too!
Wayne
On 06/07/15 02:11 PM, Doug Schaefer wrote:
I think it would be hard to fund travel for a meeting like this (unless for me it’s in Ottawa ;). It would be nice to find a way for those who are interested to work together, maybe over Google Hangout or something similar, to come up with a plan.
Some of this, though, is differences in philosophy or maybe just terminology. I would find it hard to differentiate a “smart” editor from an IDE if the IDE is done right. Not sure we’ve ever sat down and defined what an IDE was other than a development
environment that integrates the tools you use for development, like build and debug and analysis tools, into a seamless flow.
A “smart” editor is a good editor that integrates the tools you use for development. Once you add support for debugging is it really an editor anymore or has it morphed into an IDE. Emacs, IMHO, is an IDE that way with build integration and error markers.
Doug.
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
![EclipseCon France 2015]()
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information
by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
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
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
|
