Re: Aligning implementation and specification versions?
On Fri, 2 Aug 2019, 19:43 Tim Boudreau, wrote: > We discussed this long ago, but if you want fewer friend dependencies, then > the solution is to get more of those through the API review process and > committed to as stable API. That's what it's for, and that's what actually > solves the problem. > It might solve that problem, it doesn't solve this problem! We're trying to get to a situation where different builds of the same source get the same implementation versions. It's something to consider in moving towards more reproducible builds, and already caused an issue in this release cycle. Eric suggested elsewhere using the git hash as build number, which could work although might raise other issues. Hence wondering whether replacing build number in implementation versions with the same text value as the spec version might work instead. This wouldn't affect anything where the implementation version is set in another way. Best wishes, Neil
[VOTE] Release Apache Netbeans Standalone Java Hints Tool 11.1 [vote candidate 2]
Dear all,
Another attempt on releasing the standalone Java Hints tool ("jackpot")
based on Apache NetBeans 11.1, VC2 this time. I tried to resolve most of
the questions/issues found during the vote a few months back, and improve
the Maven repository, as requested (a staging Maven repository is available
this time, see below). Unfortunatelly, I don't know how to improve the
NOTICE for the convenience binary, which includes NOTICE from Apache Lucene
and is a quite long (we have the same problem in "normal" NetBeans).
The release is here:
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-jackpot-11.1-vc2/apache-netbeans-jackpot-11.1-vc2.zip
Signature file:
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-jackpot-11.1-vc2/apache-netbeans-jackpot-11.1-vc2.zip.asc
SHA512:
af36197648cd4861208c35539e7ad0cf5ca5e111e75fb43f9ab03f609d46a070036d7d045c3b91916df3280f2136fefb694ad1fceda44f875619f08fb088a6be
apache-netbeans-jackpot-11.1-bin-vc2.zip
KEYS file:
https://dist.apache.org/repos/dist/release/netbeans/KEYS
Apache NetBeans Jackpot 3.0 Git Repo tag:
https://github.com/apache/netbeans-jackpot30/releases/tag/netbeans-jackpot-11.1-vc2
Convenience binaries:
-built standalone tool:
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-jackpot-11.1-vc2/apache-netbeans-jackpot-11.1-bin-vc2.zip
Its signature file:
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-jackpot-11.1-vc2/apache-netbeans-jackpot-11.1-bin-vc2.zip.asc
and its SHA512:
af36197648cd4861208c35539e7ad0cf5ca5e111e75fb43f9ab03f609d46a070036d7d045c3b91916df3280f2136fefb694ad1fceda44f875619f08fb088a6be
apache-netbeans-jackpot-11.1-bin-vc2.zip
-there is also a plugin for Maven, a staging Maven repository is here:
https://repository.apache.org/content/repositories/orgapachenetbeans-1040/
This vote is going to be open at least 72 hours, vote with +1, 0, and -1 as
usual.
Thanks for any feedback!
Jan
[CANCEL] [VOTE] Release Apache Netbeans Standalone Java Hints Tool 11.1 [vote candidate 1]
Let's cancel this vote, and try again with better maven artifacts.
Jan
On Thu, Aug 1, 2019 at 7:29 AM Jan Lahoda wrote:
> Dear all,
>
> I'd like to release the standalone Java Hints tool ("jackpot") based on
> Apache NetBeans 11.1. I tried to resolve most of the questions/issues found
> during the last vote a few months back. Unfortunatelly, I don't know how to
> improve the NOTICE for the convenience binary, which includes NOTICE from
> Apache Lucene and is a quite long (we have the same problem in "normal"
> NetBeans).
>
> The release is here:
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-jackpot-11.1-vc1/apache-netbeans-jackpot-11.1-vc1.zip
>
> Signature file:
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-jackpot-11.1-vc1/apache-netbeans-jackpot-11.1-vc1.zip.asc
>
> SHA512:
> c39998a357d01f79ef8ebc71b54d787c34b62e7d6faff14ace2b0c8d2502df2860fd201098f6ca99c0e64620ecb2c8d004b715ab15c6065e4d81a1f65a469d0a
> apache-netbeans-jackpot-11.1-vc1.zip
>
> KEYS file:
>
> https://dist.apache.org/repos/dist/release/netbeans/KEYS
>
> Apache NetBeans Jackpot 3.0 Git Repo tag:
>
> https://github.com/apache/netbeans-jackpot30/releases/tag/netbeans-jackpot-11.1-vc1
>
> Convenience binaries:
> -built standalone tool:
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-jackpot-11.1-vc1/apache-netbeans-jackpot-11.1-bin-vc1.zip
>
> Its signature file:
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-jackpot-11.1-vc1/apache-netbeans-jackpot-11.1-bin-vc1.zip.asc
>
> and its SHA512:
> 4b633d0ad4e41dfcd7573c80a76873e0ee7e3d51e780c3169f6e0fb24cdfa2f6e3a2eb9aed123fa16d9595dbe9c27ff66c18c478bf7f4e7f122ea212e7eb47ae
> apache-netbeans-jackpot-11.1-bin-vc1.zip
>
> -there is also a plugin for Maven, a snapshot of the Maven repository,
> containing what would be uploaded there is here:
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-jackpot-11.1-vc1/apache-netbeans-jackpot-mavenrepo-11.1-bin-vc1.zip
>
> Its signature file:
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-jackpot-11.1-vc1/apache-netbeans-jackpot-mavenrepo-11.1-bin-vc1.zip.asc
>
> and its SHA512:
> 9ed1d453ec202aa61416be91c6155b685382f86a46e707b0a0c5eb8ecb7d8cd3af8b6f32470ec86a83a40c67f7ff45c66a9841d5e798723e7363573a993cffe9
> apache-netbeans-jackpot-mavenrepo-11.1-bin-vc1.zip
>
> This vote is going to be open at least 72 hours, vote with +1, 0, and -1
> as usual.
>
> Thanks for any feedback!
>
> Jan
>
Re: Aligning implementation and specification versions?
> NBANDROID uses a special web server, which changes the implementation > version of the dependencies in the modules, but it's not a clean > solution... > And I would like it to be finally resolved. Because it makes module > developers trouble... > Using the build number serves an important purpose: If you are making no compatibility guarantees, then the only thing that's reliable that two libraries are actually compatible is if the answer is "yes" to the question "were both of these things compiled as part of the same build?". Fix that in NBANDROID, not globally. *However, what would be the pros and cons or possibilities of making implementation and specification versions the same? Given we already increment all specification versions between releases, this should achieve the same purpose for anyone not utilising daily builds?* It will break more things than it fixes and just create new problems. Some modules use semi-stable values for implementation version - they aren't official API but they change rarely if at all, and a module built against those will work across releases without someone having to download a new JAR whose only difference may be a dependency version string. Anyone developing a module against those will suddenly start having exactly the problem you want to solve - needing to cut a new release for every increment of the spec version. We discussed this long ago, but if you want fewer friend dependencies, then the solution is to get more of those through the API review process and committed to as stable API. That's what it's for, and that's what actually solves the problem. -Tim
Re: Aligning implementation and specification versions?
Hi, For ANB, I think it's easiest to add implementation versions to all modules. Because currently there are problematic modules that do not have the implementation version. And compiler uses build number as the implementation version. NBANDROID uses a special web server, which changes the implementation version of the dependencies in the modules, but it's not a clean solution... And I would like it to be finally resolved. Because it makes module developers trouble... ArSi *From:* Neil C Smith *Sent:* Friday, August 02, 2019 10:52AM *To:* Dev *Subject:* Aligning implementation and specification versions? Hi, On Sat, 27 Jul 2019 at 05:57, Jaroslav Tulach wrote: Using implementation dependency is a hack of the last resort. It is certainly not something we should encourage. Long time ago there was a discussion about eliminating friend dependencies. We haven't made any changes in the friend dependencies area, but it was clear we see them as problematic. Implementation dependency is way worse. It is at most good for quick and private hacking (actually I am about to use it soon for prototyping). However publishing a plugin NBM with implementation dependency to general consumption is a heresy of the biggest kind. It makes it non-portable across derivatives - CoolBeans, Ideal Graph Visualizer and maybe even Linux distributions! Following on from this, and the re-rolled vote on Maven artefacts for NB 11.1 because of mismatched implementation versions, I was wondering about the best resolution for this going forward. This is not to encourage implementation dependencies any further, although until we do eliminate the annoyance that is friend dependencies (or at least provide ways to externally override) this is going to happen! We should be moving towards more reproducible builds. Having different binary builds of the same sources have different implementation versions is problematic. One option is having the git hash (or similar) be the implementation version. However, what would be the pros and cons or possibilities of making implementation and specification versions the same? Given we already increment all specification versions between releases, this should achieve the same purpose for anyone not utilising daily builds? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Aligning implementation and specification versions?
> However, what would be the pros and cons or possibilities of making > implementation and specification versions the same? Given we already > increment all specification versions between releases, this should > achieve the same purpose for anyone not utilising daily builds? > http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#how-vers Implementation version is a free form text. Specification version must be dewey decimal. Having them be the same means that implementation version would be equal to dewey's decimal spec version. Could it work? Maybe. It is certainly truth that if Apache does only source releases, then it would be great if two subsequent builds on the same source result in the same bits. -jt
AW: Propose using milestones instead of labels
+1 for Milestones. Cheers Chris Von: Junichi Yamamoto Gesendet: Mittwoch, 24. Juli 2019 12:29 An: dev@netbeans.apache.org Betreff: Re: Propose using milestones instead of labels I propose that we mark versions using both labels and milestones if some people are worried about visibility. That way, we can remove version labels without problems(we can search PRs for specific versions even if labels are removed) if they are not required, I suppose. Thanks, Junichi On Wed, Jul 24, 2019 at 4:53 PM Neil C Smith wrote: > > On Wed, 24 Jul 2019 at 00:54, Junichi Yamamoto wrote: > > Currently, we are using labels to mark specific versions in GitHub > > repo. However, Version labels are never used after those versions are > > released. It means version labels which we don't use again continue to > > increase. > > So, I suppose that we should use milestones instead of version labels. > > What do you think? > > +0 - I've found pros and cons to milestones on other projects, and > they're a little less visible. OTOH, other features might be useful. > > We can also delete labels that are no longer required, if that's the > only concern to be addressed. If so, please keep 11.0 and 11.1 around > for now - they do potentially have a purpose post release while the > releases are still active. > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Future of Javascript on Netbeans
Hello Matthias, the current situation isn't pleasant. It is in my interest to solve it without introducing parser based on other than Nashorn/Graal.js technology. I'll see what I can do. Give me five working days to figure out my options. -jt čt 1. 8. 2019 v 21:23 odesílatel Matthias Bläsing napsal: > Hi, > > in the last few days I worked often with fresh builds on my machine and > everytime I had to hop through loops (i.e. install js parser manually). > At this point JS on Netbeans is annoying for me. > > I therefore reopened: > > https://issues.apache.org/jira/browse/NETBEANS-1159 > > The reasoning: Oracle relicensed the graal.js parser to UPL, however, > not the version we need. > > The one we are currently use is: > > http://hg.openjdk.java.net/graal/graal-js-parser/rev/ba7a8bc42268 > > The relicensed version generates a different parse tree, then the old > version and misses at least the JSX parsing feature. > > The current state of affairs of an experient to move to graal.js parser > can be found here: > > https://github.com/apache/netbeans/tree/graaljs2 > > Run the unittests in javascript2.editor and you'll see the problem. > The above referenced branch already contains fixes to deactivate/remove > broken unittests, so the reported failing tests represent the minimum > problem set. > > Any ideas? > > Greetings > > Matthias > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Aligning implementation and specification versions?
Hi, On Sat, 27 Jul 2019 at 05:57, Jaroslav Tulach wrote: > Using implementation dependency is a hack of the last resort. It is certainly > not something we should encourage. > > Long time ago there was a discussion about eliminating friend dependencies. We > haven't made any changes in the friend dependencies area, but it was clear we > see them as problematic. > > Implementation dependency is way worse. It is at most good for quick and > private hacking (actually I am about to use it soon for prototyping). However > publishing a plugin NBM with implementation dependency to general consumption > is a heresy of the biggest kind. It makes it non-portable across derivatives - > CoolBeans, Ideal Graph Visualizer and maybe even Linux distributions! Following on from this, and the re-rolled vote on Maven artefacts for NB 11.1 because of mismatched implementation versions, I was wondering about the best resolution for this going forward. This is not to encourage implementation dependencies any further, although until we do eliminate the annoyance that is friend dependencies (or at least provide ways to externally override) this is going to happen! We should be moving towards more reproducible builds. Having different binary builds of the same sources have different implementation versions is problematic. One option is having the git hash (or similar) be the implementation version. However, what would be the pros and cons or possibilities of making implementation and specification versions the same? Given we already increment all specification versions between releases, this should achieve the same purpose for anyone not utilising daily builds? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: C/C++ module ?
Dne 02. 08. 19 v 10:28 Siddhesh Rane napsal(a): I have to run programs on embedded hardware that requires multiple ssh jumps. One feature I would like to add is support for ssh jump hops (-J flag or ProxyJump in config) in Netbeans ssh. It would be nice if Netbeans use standard ssh-agent instead of configuring password or key in Netbeans. Or even use the same configuration as OpenSSH in ~/.ssh/config – then you could configure all proxy and other options only once. Despite these minor flaws and some missing features, Netbeans has been extremely productive for me to dive into large undocumented projects and add features on top. Excellent Remote development and create project from existing sources are the killer features for me. I was surprised that even Clion lacks these features. +1 However my previous e-mail was critical, I really appreciate Netbeans and its unique features. Franta - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: C/C++ module ?
I use netbeans on large c++ code remotely and I haven't had issues with cursor slowing down. I have observed waiting for code completion but very rarely. There are several nice things about Netbeans There is a plugin for gdbserver support in Netbeans 8.2. I have installed it but haven't used. There is builtin support for remote development which I have used extensively at work. It comes with remote debugging as well. I have to run programs on embedded hardware that requires multiple ssh jumps. One feature I would like to add is support for ssh jump hops (-J flag or ProxyJump in config) in Netbeans ssh. There are several bugs that I encountered and would like to fix: - diff to does not work for remote files - ctrl shift t to open last closed file works only for local files - inline refactor doesn't always work (thankfully rename refactoring always works!) - Certain refactoring are not supported for projects built with existing sources - Code assistance for a large remote project with existing sources will fail many times. Requires successive runs to fully develop source model - /** tab does not automatically generate javadoc/doxygen style documentation with parameter names and return values for projects built with existing sources (it works for projects created from the ide) - some companies, especially ones using c/c++ tend to use Perforce for version control. It would be good to add support for p4 edit, although not a priority. Despite these minor flaws and some missing features, Netbeans has been extremely productive for me to dive into large undocumented projects and add features on top. Excellent Remote development and create project from existing sources are the killer features for me. I was surprised that even Clion lacks these features. Siddhesh August 2, 2019 1:29 PM, "František Kučera" wrote: > Dne 01. 08. 19 v 22:42 Geertjan Wielenga napsal(a): > >> What new features would you like? What can you provide, what would you like >> to focus on? > > I also use Netbeans not only for Java but also for C/C++. I have random > problems with: > > 1) Extreme slowness – even moving the cursor in the source code is laggy (and > I am talking about > seconds, not milliseconds) or I am sometimes waiting 10 or more seconds until > the popup with > code-completion shows. It displays „Please wait…“ and it does not consume 100 > % CPU, so it is > probably waiting for some lock or something. > > 2) Broken code completion – I understand that code completion for language > like C++ is not an easy > task, but it seems, that lot of work has been done and the C++ support in > Netbeans is pretty > complete, better than in many other IDEs or editors – it is just buggy and > sometimes stops working > – sometimes Netbeans does not recognize a smart pointer (just one kind like > std::shared_ptr while > another smart pointers work at the same time) or other template and are > unable to offer its methods > in the popup, and sometimes it works (I mean the same code). Sometimes helps > the „Clean C/C++ cache > and restart IDE“ function and sometimes helps changing „__cplusplus“ macro > (in Netbeans options) to > some other and then back (it probably causes some refresh). > > And sometimes it works (with same projects, same code) – i.e. the features > are not missing, just > buggy. > > Besides fixing bugs, important is support of new C/C++ standards. Of course, > there might be > additional features, there is always something that could be added, but it is > not necessary – if > the basic (already implemented) features will reliably work and new standards > will be supported, > Netbeans would be a perfect IDE for C/C++. > > I know that this is just vague lamenting – if I can help with debugging I > would be happy to do so – > please advise how to diagnose such random performance issues and random bugs > in code completion. > > Franta > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: C/C++ module ?
P.S. for example now I get this Unexpected exception in the
Notifications panel:
java.lang.VerifyError: Operand stack underflow
Exception Details:
Location:
org/netbeans/modules/cnd/classview/SmartChangeEvent.addChangeEvent(Lorg/netbeans/modules/cnd/classview/SmartChangeEvent;)Z
@33: dstore_3
Reason:
Attempt to pop empty stack.
Current Frame:
bci: @33
flags: { }
locals: { 'org/netbeans/modules/cnd/classview/SmartChangeEvent',
'org/netbeans/modules/cnd/classview/SmartChangeEvent',
'java/util/Iterator' }
stack: {
'org/netbeans/modules/cnd/classview/SmartChangeEvent$Storage' }
Bytecode:
0x000: 2ab6 00c6 b900 e001 00b9 00dd 0100 4d2c
0x010: b900 de01 0099 002a 2cb9 00df 0100 c000
0x020: 5d4a 2db6 00d1 b900 da01 009d 000f 2db6
0x030: 00d2 b900 da01 009e 0005 03ac a7ff d32a
0x040: 2bb7 00c8 2a59 b400 b704 60b5 00b7 04ac
0x050:
Stackmap Table:
append_frame(@15,Object[#83])
append_frame(@58,Object[#93])
chop_frame(@60,1)
chop_frame(@63,1)
at
org.netbeans.modules.cnd.classview.ClassViewUpdater.scheduleUpdate(ClassViewUpdater.java:212)
at
org.netbeans.modules.cnd.classview.ClassViewModel.scheduleUpdate(ClassViewModel.java:125)
at
org.netbeans.modules.cnd.classview.ClassView.modelChanged(ClassView.java:324)
at
org.netbeans.modules.cnd.classview.ClassViewTopComponent.modelChanged(ClassViewTopComponent.java:288)
at
org.netbeans.modules.cnd.modelimpl.csm.core.ListenersImpl.fireModelChanged(ListenersImpl.java:145)
at
org.netbeans.modules.cnd.modelimpl.csm.core.Notificator.flush(Notificator.java:239)
at
org.netbeans.modules.cnd.modelimpl.csm.core.ProjectBase.findFileImpl(ProjectBase.java:2783)
at
org.netbeans.modules.cnd.modelimpl.csm.core.ProjectBase.findFile(ProjectBase.java:2737)
at
org.netbeans.modules.cnd.modelimpl.csm.core.ProjectBase.prepareIncludedFile(ProjectBase.java:1780)
at
org.netbeans.modules.cnd.modelimpl.parser.apt.APTParseFileWalker.includeAction(APTParseFileWalker.java:231)
at
org.netbeans.modules.cnd.modelimpl.parser.apt.APTProjectFileBasedWalker.include(APTProjectFileBasedWalker.java:109)
at
org.netbeans.modules.cnd.apt.support.APTAbstractWalker.serialIncludeImpl(APTAbstractWalker.java:317)
at
org.netbeans.modules.cnd.apt.support.APTAbstractWalker.includeImpl(APTAbstractWalker.java:165)
at
org.netbeans.modules.cnd.apt.support.APTAbstractWalker.onInclude(APTAbstractWalker.java:132)
at
org.netbeans.modules.cnd.apt.support.APTWalker.onAPT(APTWalker.java:229)
at
org.netbeans.modules.cnd.apt.support.APTWalker.toNextNode(APTWalker.java:342)
at
org.netbeans.modules.cnd.apt.support.APTWalker.visit(APTWalker.java:82)
at
org.netbeans.modules.cnd.modelimpl.parser.apt.APTParseFileWalker.includeFileWithoutTokens(APTParseFileWalker.java:434)
at
org.netbeans.modules.cnd.modelimpl.parser.apt.APTParseFileWalker.includeAction(APTParseFileWalker.java:246)
at
org.netbeans.modules.cnd.modelimpl.parser.apt.APTProjectFileBasedWalker.include(APTProjectFileBasedWalker.java:109)
at
org.netbeans.modules.cnd.apt.support.APTAbstractWalker.serialIncludeImpl(APTAbstractWalker.java:317)
at
org.netbeans.modules.cnd.apt.support.APTAbstractWalker.includeImpl(APTAbstractWalker.java:165)
at
org.netbeans.modules.cnd.apt.support.APTAbstractWalker.onInclude(APTAbstractWalker.java:132)
at
org.netbeans.modules.cnd.apt.support.APTWalker.onAPT(APTWalker.java:229)
at
org.netbeans.modules.cnd.apt.support.APTWalker.toNextNode(APTWalker.java:342)
at
org.netbeans.modules.cnd.apt.support.APTWalker.visit(APTWalker.java:82)
at
org.netbeans.modules.cnd.modelimpl.parser.apt.APTParseFileWalker.includeFileWithoutTokens(APTParseFileWalker.java:434)
at
org.netbeans.modules.cnd.modelimpl.parser.apt.APTParseFileWalker.includeAction(APTParseFileWalker.java:246)
at
org.netbeans.modules.cnd.modelimpl.parser.apt.APTProjectFileBasedWalker.include(APTProjectFileBasedWalker.java:109)
at
org.netbeans.modules.cnd.apt.support.APTAbstractWalker.serialIncludeImpl(APTAbstractWalker.java:317)
at
org.netbeans.modules.cnd.apt.support.APTAbstractWalker.includeImpl(APTAbstractWalker.java:165)
at
org.netbeans.modules.cnd.apt.support.APTAbstractWalker.onInclude(APTAbstractWalker.java:132)
at
org.netbeans.modules.cnd.apt.support.APTWalker.onAPT(APTWalker.java:229)
at
org.netbeans.modules.cnd.apt.support.APTWalker.toNextNode(APTWalker.java:342)
at
org.netbeans.modules.cnd.apt.support.APTWalker.nextTokenImpl(APTWalker.java:313)
at
org.netbeans.modules.cnd.apt.support.APTWalker.access$200(APTWalker.java:61)
at
org.netbeans.modules.cnd.apt.support.APTWalker$WalkerTokenStream.nextToken(APTWalker.java:103)
at
org.netbeans.modules.cnd.apt.support.APTWalker$WalkerTokenStream.nextToken(APTWalker.java:95)
at
org.netbeans.modules.cnd.antlr.TokenStreamSelector.nextToken(TokenStreamSelector.java:36)
Re: C/C++ module ?
Dne 01. 08. 19 v 22:42 Geertjan Wielenga napsal(a): What new features would you like? What can you provide, what would you like to focus on? I also use Netbeans not only for Java but also for C/C++. I have random problems with: 1) Extreme slowness – even moving the cursor in the source code is laggy (and I am talking about seconds, not milliseconds) or I am sometimes waiting 10 or more seconds until the popup with code-completion shows. It displays „Please wait…“ and it does not consume 100 % CPU, so it is probably waiting for some lock or something. 2) Broken code completion – I understand that code completion for language like C++ is not an easy task, but it seems, that lot of work has been done and the C++ support in Netbeans is pretty complete, better than in many other IDEs or editors – it is just buggy and sometimes stops working – sometimes Netbeans does not recognize a smart pointer (just one kind like std::shared_ptr while another smart pointers work at the same time) or other template and are unable to offer its methods in the popup, and sometimes it works (I mean the same code). Sometimes helps the „Clean C/C++ cache and restart IDE“ function and sometimes helps changing „__cplusplus“ macro (in Netbeans options) to some other and then back (it probably causes some refresh). And sometimes it works (with same projects, same code) – i.e. the features are not missing, just buggy. Besides fixing bugs, important is support of new C/C++ standards. Of course, there might be additional features, there is always something that could be added, but it is not necessary – if the basic (already implemented) features will reliably work and new standards will be supported, Netbeans would be a perfect IDE for C/C++. I know that this is just vague lamenting – if I can help with debugging I would be happy to do so – please advise how to diagnose such random performance issues and random bugs in code completion. Franta - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re: C/C++ module ?
Start by just creating issues. Gj On Fri, 2 Aug 2019 at 05:22, Eric Bresie wrote: > Where on the wiki would these go? > > Eric Bresie > ebre...@gmail.com > > On August 1, 2019 at 3:57:48 PM CDT, Geertjan Wielenga < > geert...@apache.org> wrote: > > Would be great if you’d document together on the Wiki all the > enhancements > > you’d like and create issues for each of them. > > > > Gj > > > > > > On Thu, 1 Aug 2019 at 22:56, tygrysek HD wrote: > > > > > Better support for gdb, for example support for gdbserver (gdb target > > > remote), now is not possible to use this by ide. > > > > > > czw., 1.08.2019, 22:47 użytkownik Brad Walker > > > napisał: > > > > > > > I really would like to see a good embedded module for the platform. > It > > > > doesn't seem like we have a good answer for this. Since I do embedded > > > work > > > > in my professional life, I end up having to use Eclipse because that > is > > > > what so many chip vendors provide with their SDK. > > > > > > > > So having said that, guess that means I'm volunteering to work on > this, > > > > no? 8-) > > > > > > > > -brad w. > > > > > > > > On Thu, Aug 1, 2019 at 2:42 PM Geertjan Wielenga < > geert...@apache.org> > > > > wrote: > > > > > > > > > What new features would you like? What can you provide, what would > you > > > > like > > > > > to focus on? > > > > > > > > > > Gj > > > > > > > > > > On Thu, 1 Aug 2019 at 22:41, Brad Walker > wrote: > > > > > > > > > > > Yes, that's what has always been said to me.. I should have > worded my > > > > > > question more correctly. > > > > > > > > > > > > Once, that happens, then what would be the "vision" about the > next > > > > > steps.. > > > > > > Do we just start using it and jump in as needed? Is there a list > of > > > new > > > > > > features the group would like to see? > > > > > > > > > > > > Hopefully, I'm a little bit clearer. > > > > > > > > > > > > -brad w. > > > > > > > > > > > > On Thu, Aug 1, 2019 at 2:24 PM Geertjan Wielenga < > > > geert...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > The news has been consistent from the beginning — the code that > > > > > > constitutes > > > > > > > the C++ modules is part of the 4th donation, which is currently > > > being > > > > > > > audited prior to donation by Oracle to Apache. > > > > > > > > > > > > > > Gj > > > > > > > > > > > > > > > > > > > > > On Thu, 1 Aug 2019 at 20:58, Brad Walker > > > > wrote: > > > > > > > > > > > > > > > Part of the reason I got involved with the NetBeans project > was > > > > > > because I > > > > > > > > was interested in the C/C++ module. > > > > > > > > > > > > > > > > So what's the current status of this module? Is there > anything I > > > > can > > > > > do > > > > > > > > there to help make it better or ready for consumption? > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > -brad w. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: instructions on building netbeans Git repo with jdk newer than jdk 8
Hi Gary Please add below parameter -Dpermit.jdk9.builds=true So the command to build will be ant clean build -Dpermit.jdk9.builds=true Regards, Arunava Sinha On 8/2/2019 5:14 AM, Gary Bello wrote: Some threads indicate success in building netbeans with jdk newer than jdk 8; my attempts so far fail. Are there instructions ? Thanks -Gary - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
