On Thu, Apr 30, 2020 at 7:08 PM Brad Walker <[email protected]> wrote:

> You folks are correct.. I'm not suggesting dropping the code model
> machinery.
>
> My goal is to simply get it working as is. Then take the next step..
>

I guess I'd like to have an idea on how the parsing will be supported in
the long term (how are bugs going to be fixed; how are new language
features going to be implemented).

But what I worry most is that in a few months, there won't be much progress
on CND (as, unfortunately, there was not much progress in the past few
months). But I am eager to be proven wrong!

I guess I'd suggest to start with the list of files that need to be added
to the CND buildable in the Apache context:
https://github.com/jlahoda/netbeans/blob/cnd-building/README.cnd

And try to find out what is the problem and how to solve it. I think I only
have a reasonable idea about three:
-debugger_log.png: I believe we could use the CDDL version of the icon, we
just need the appropriate marks in licenseinfo.xml.
-"cnd/modules/org-netbeans-modules-cnd-antlr.jar =>
cnd/libs.antlr.cnd/external" - this is to get a patched ANTLR, which builds
the CND grammars. Until we need to patch it, we simply should be able to
use the CDDL version(?). There might be some tweaks needed to make this
module better integrated into the build process, but hopefully shouldn't be
too difficult.
-"
https://netbeans.osuosl.org/binaries/5CAB59D859CAA6598E28131D30DD2E89806DB57F-antlr-3.4.jar
=> cnd/cnd.modelimpl/external/antlr-3.4.jar" - hopefully, this should be
easy to solve, but needs some work.

For others, I have very little or no idea what to do with the files, or (in
some cases) what the files even do.

The next step after this would be to ensure various license checks are
passing (rat, ant verify-libs-and-libraries).


>
> It's definitely a lot of work but can probably be drastically improved
> because of JEP-362 and JEP-381..
>

Not sure why that is a significant help. We still need proper parsing and
editor features, and also debugger, on all other platforms.

Jan


> -brad w.
>
>
>
> -brad w.
>
> On Thu, Apr 30, 2020 at 1:50 AM Jan Lahoda <[email protected]> wrote:
>
> >
> >
> > 30. dubna 2020 9:15:19 SELČ, Ivan Soleimanipour <
> > [email protected]> napsal:
> > >I don't think Brad was suggesting ditching the code model machinery
> > >(C++ parsers).
> >
> > Right, I don't think he was suggesting that.
> >
> > But I guess what I am saying is: if we want to have C/C++ support in
> > NetBeans, we need a group of developers working on that. So, as a
> > mitigation plan, I sketched out cpplite, where the group of maintainers
> > could be very small. If we can have full CND, that is even better, but
> are
> > there enough contributors? What are your opinions on how to evolve the
> > model for new versions of C++? Do we use the antlr parser, clank, or
> both?
> > These are all questions I don't know answers to.
> >
> > As you can see below, I did also some work on CND - do you have
> > improvements to that? Because in the current state, it cannot be
> released.
> > I am willing to help, but I can only contribute a little, and this is a
> > huge project.
> >
> > Jan
> >
> > >None of that, in general, is Studio specific.
> > >
> > >CND does have a plugin interface. It's best to illustrate it with
> > >debuggers. There's a
> > >debugger_common module and two plugins, a gdb debugger and a dbx
> > >debugger.
> > >The dbx debugger part was Oracle prorprietay so I don't think there's
> > >anything to get rid of.
> > >The other part which had to be customized was make (gnu-make vs
> > >sun-make) and compiler
> > >customizations. For example, to find out the list of predefined macros
> > >CND has to invoke
> > >each compiler with a slightly different magical incantation.
> > >
> > >So I think Brad was talking about getting rid of Studio-specific
> > >customizations, not code
> > >that was written by people (mostly StPetersburg folk) employed by
> > >Oracle.
> > >
> > >Brads suggestion makes sense tho I don't think it's that much stuff and
> > >getting rid of
> > >it won't simplify things _that_ much.
> > >More importantly, once you ditch Studio support CND will become a
> > >plugin/customization infrastructure with only one plugin: GNU stuff.
> > >And we all know what
> > >happens in such circumstances. The generic part of the code ends up
> > >getting polluted with
> > >features to support it's only plugin.
> > >
> > >On 4/29/20 10:57 AM, Jan Lahoda wrote:
> > >> To elaborate on the C/C++ support in NetBeans a little more: I think
> > >we
> > >> have two main directions which we can take: 1) take more or less the
> > >full
> > >> CND as donated, adjust to Apache standards and maintain; 2) attempt
> > >to do
> > >> something simpler (taking from CND what we need).
> > >>
> > >> Using the full CND has some advantages, like a much more
> > >fully-featured
> > >> support, having a model of the source code inside the IDE, which can
> > >be
> > >> used to implement any feature, etc. The disadvantages are that a) we
> > >need
> > >> to bring it up to Apache standards; b) we need to maintain it (I may
> > >be
> > >> wrong, but my understanding is that there are two C/C++ parsers
> > >there: an
> > >> ANTLR based one, and clank, which is clang converted to Java). This
> > >would
> > >> include, for example, adding support for new C++ versions.
> > >>
> > >> There is a very crude start of this in branch cnd-building in my
> > >NetBeans
> > >> repo:
> > >> https://github.com/jlahoda/netbeans/tree/cnd-building
> > >>
> > >> There is a simple README available for it:
> > >> https://github.com/jlahoda/netbeans/blob/cnd-building/README.cnd
> > >>
> > >> I guess that for this to work, we need some serious effort. At very
> > >least,
> > >> the readme lists a number of files that need to be added, to make
> > >code
> > >> buildable, and for each, we need to find out if we can use it,
> > >provide a
> > >> replacement, or drop it. Some might be reasonably simple, but I am
> > >worried
> > >> about things like CPPParserEx.java, CPPSymbol.java and cppparser.g -
> > >these
> > >> feel like difficult to replace; and possibly difficult to use the
> > >original
> > >> versions (as, presumably, these need to be updated when a new
> > >language
> > >> feature is added).
> > >>
> > >>
> > >> Using something simpler could be to use a C/C++ Language Protocol
> > >Server,
> > >> like ccls (https://github.com/MaskRay/ccls). This would provide
> > >features
> > >> like code completion, without the need to maintain the code to
> > >compute the
> > >> proposals, etc. inside NetBeans. Then there is a need for (simple?)
> > >> projects and (simple?) debugger. I tried to prototype it here:
> > >> https://github.com/jlahoda/netbeans/tree/cpplite
> > >>
> > >> To use it, checkout the branch, and then build using:
> > >> ant -Dcluster.config=cpplite
> > >>
> > >> Then do "ant tryme" to get the IDE. In New Project, there is
> > >> C/C++/Lightweight C/C++ Project - it is primarily intended to open
> > >existing
> > >> projects in NetBeans. It allows to specify compile_commands.json (for
> > >ccls)
> > >> and build commands. Path to "ccls" needs to be specified in
> > >Tools/Options
> > >> (otherwise most editor features don't work).
> > >>
> > >> The advantage of this is that it should be fairly reasonable to
> > >write; and
> > >> hopefully easy to maintain for the long term. The disadvantage is
> > >that some
> > >> (many?) features from CND may be missing.
> > >>
> > >>
> > >> I guess I'd like hear:
> > >> a)  who is willing to help with either of these projects? Which you
> > >prefer?
> > >> b) any other ideas?
> > >> c) if someone would be willing to try cpplite and say how much is
> > >missing
> > >> to make it useful, I'd be grateful. My primary personal reason to
> > >look at
> > >> C/C++ support is to allow developer of native sources from OpenJDK -
> > >and I
> > >> think/hope cpplite could evolve fairly easily into something useful
> > >for
> > >> this usecase.
> > >>
> > >> What do you think?
> > >>
> > >> Thanks,
> > >>       Jan
> > >>
> > >> On Wed, Apr 29, 2020 at 1:20 AM Ernie Rael <[email protected]>
> > >wrote:
> > >>
> > >>> On 4/28/2020 3:58 PM, Brad Walker wrote:
> > >>>> I'm starting to wade into helping get the C/C++ module up and
> > >running on
> > >>>> Apache Netbeans. As a result, I have quick project question for the
> > >more
> > >>>> "senior" folks on this group. Or anyone else who cares to comment.
> > >8-)
> > >>>>
> > >>>> I would like to propose that we drop support for the SunStudio
> > >tools
> > >>> (i.e.
> > >>>> compiler and debugger, etc.). The reason is because it makes
> > >porting more
> > >>>> difficult. In addition, it doesn't really make sense for a project
> > >like
> > >>>> Apache Netbeans to carry all this technical debt that it incurs for
> > >which
> > >>>> no one really is going to support.
> > >>>>
> > >>>> So what are the collective thoughts and opinions about dropping
> > >SunStudio
> > >>>> support in Apache Netbeans?
> > >>>>
> > >>>> The assumption here is that GDB and friends would continue to work
> > >and be
> > >>>> supported.
> > >>>>
> > >>>> -brad w.
> > >>>>
> > >>> There's this tantalizing message from Jan
> > >>>
> > >>>
> > >>>
> > >
> >
> http://mail-archives.apache.org/mod_mbox/netbeans-dev/202004.mbox/%3CCALd%3D3dH2vqLx8rrP2yDh76%3DDVKsok-g0Qeaf9zpeaVG2aeALhA%40mail.gmail.com%3E
> > >>>
> > >>> which suggests
> > >>>
> > >>>      alternative idea is to use a Language Server Protocol (LSP)
> > >server
> > >>>
> > >>> You might find that thread interesting...
> > >>>
> > >>> -ernie
> > >>>
> > >>>
> > >>>
> > >---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: [email protected]
> > >>> For additional commands, e-mail: [email protected]
> > >>>
> > >>> For further information about the NetBeans mailing lists, visit:
> > >>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> >
> > --
> > Odesláno aplikací K-9 Mail ze systému Android. Omluvte prosím moji
> > stručnost.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>

Reply via email to