Re: Rust, anyone?

[John Kostaras]

Hello there. There has already been something about Rust
 (written
in JavaCC).

Ioannis.


On Sun, Feb 12, 2023 at 10:18 AM Antonio  wrote:

> Thanks Michael!
>
> D'oh! My intents to add Rust to the NetBeans core (very much as in the
> Linux kernel case) have been detected! :-D
>
> Latest commits solve these issues, though (and add new bugs).
>
> Next challenge: Cargo workspaces [1].
>
> Cheers,
> Antonio
>
> [1] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
>
> On 12/2/23 9:03, Michael Bien wrote:
> > for others who want to give it a try: I had to fix two things to make
> > the build pass:
> >   - removed references of RustPackage in org.openide.nodes.Node
> > (probably a happy coding accident)
> >   - had to create this folder: netbeans/rust/rust.project/test/unit/src
>
> -
> 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
>
>
>
>

distribute question

[name name2]

Hello

Can i distribute my paid program based on NB with my own closed module/s
without any changing base NB platform modules/core? I found a way how to
make NB great again.

Re: Dependent PRs.

[Алексей Борохвостов]

Thanks, Laszlo!

сб, 11 февр. 2023 г. в 15:16, Laszlo Kishalmi :

> Yes that kind of thing is a bit hard to crack and could be itchy.
>
> I'd prefer the 1st option, the 3rd could also work in some cases.
>
> So, wait till your PR gets merged. Do something else during that time.
> You can also have a running branch for your second PR, which coiuld be
> rebased when the first PR gets merged, so you can create the next PR
> right away.
>
> On 2/8/23 23:15, Алексей Борохвостов wrote:
> > Hello!
> > Can you advise how to do the right thing?
> > I already have an open PR https://github.com/apache/netbeans/pull/5443
> with
> > a fix for https://github.com/apache/netbeans/issues/5427
> > I also made a fix for https://github.com/apache/netbeans/issues/5375 and
> > want to open PR.
> > But the problem is that I can't do the correct tests for 5375 until the
> > fixes for 5427 are made.
> > What is the best way to proceed?
> > 1. wait until the PR https://github.com/apache/netbeans/pull/5443 is
> merged
> > and then create a new PR
> > 2. create a PR with incorrect tests with a note that it should be taken
> > after PR https://github.com/apache/netbeans/pull/5443
> > 3. create a draft PR and add tests after merge
> > https://github.com/apache/netbeans/pull/5443
> >
>
> -
> 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
>
>
>
>

Extract Interface...

[Ernie Rael]

I'm starting to work with some unfamiliar code. For example I've got

   class DerivedTableModel extends AbstractTableModel
   class DerivedJTable extends JTable

I want a list of all methods in DerivedTableModel that are not in 
AbstractTableModel. I tried "Refactor > ExtractInterface" but the list 
includes all methods defined in DerivedTableModel and if you click the 
"check all action" at the bottom it gets all methods; not what I'm 
looking for.


One thought is to have "exclude" option checkboxes

   Implemented Interface methods
   Extended Class methods
   Unknown Methods

To get the current default none of these checked, so all methods are 
included. One think I'm looking for, I'd check both interface/class 
options, so only methods that do not override something is in the list 
of methods to chose from.


My task is to provide a plug in compatible alternate implementation. 
Knowing what needs to be implmented, and isn't part of 
AbtractTableModel, is a place to start. It could be argued that such an 
interface should have been made when DerivedTableModel was first built.


Another list, with "Unknown Methods" checked, is also useful to look at 
especially when it comes to considering how super class/interface are 
tweaked.


Any convenient way to get these? I haven't done a deep dive into how 
useful these would actually be. I'd consider adding the "exclude" 
checkboxes if it seems useful and someone is willing to answer questions 
about "Extract Interface" and review PR. I don't think I've ever looked 
at any refactor code; might be a steep curve; but since it's filters on 
an existing list, might not be too bad.


-ernie

Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))

[Scott Palmer]

While I appreciate Jaroslav's point about libraries being compatible with a
wide variety of Java versions, we do have to balance that with keeping up
with recent developments and the extra effort it entails to avoid using
modern features that are otherwise available.
I personally don't see an issue in dropping Java 8 as a minimum platform
for building or running NetBeans. If you want to run on Java 8, you are
already accustomed to living in the past - you can deal with an older
version of NB or the NB platform that supports Java 8.  I say that however,
having no stake in a NB platform app. It isn't going to affect me. My vote
shouldn't count for much.

But NB or the NB platform isn't the only library an application will use,
and many others are already starting to raise the bar as far as the minimum
supported JDK/JRE.  You can only go back as far as all of your dependencies
will allow.  If there is demand for it, a Java 8 compatible maintenance
branch can be made. One reason for running on JDK 8 mentioned running on
Android.  Are there a significant number of NB platform apps that run on
Android now?  Do they already build with the latest NB platform, or are
they already using an older version anyway - i.e. being on the lastest NB
platform may not be a big deal for them.

An informed decision needs to be based on these details.  Holding back for
JDK 8 compatibility helps no one if there isn't actually any real demand to
do so.

Just my 2c,

Scott


On Sun, Feb 12, 2023 at 5:22 PM Neil C Smith  wrote:

> On Sun, 12 Feb 2023, 19:11 Matthias Bläsing,
>  wrote:
>
> > Hi,
> >
> > Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith:
> > > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing <
> mblaes...@doppel-helix.eu.invalid>
> > wrote:
> > > > - commit to make NetBeans runnable on JDK LTS -1
> > > > - build with JDK LTS -1
> > > > - be able to be build with the current JDK
> > >
> > > +1 as long as that includes the platform.
> > >
> > > That is what I suggested in the other thread (I don't see why we need
> > > multiple threads incidentally!)
> > >
> > > An LTS-1 strategy seems closest to how NetBeans used to function -
> > > major-1, in a time when it also had more development resources?
> > >
> > > Let's also be clear, though, that adopting an LTS-1 strategy means
> > > dropping JDK 11 support either in our first release after JDK 21, or
> > > the first after JDK 22 - so latest May 2024.
> >
> > why would we do that? I said _runnable_ and _buildable_. As long as the
> > current JDK support the target release I did not exclude that.
> >
>
> In which case I don't understand what you mean by committing to make
> NetBeans buildable and runnable on LTS-1? That to me means dropping the
> commitment to JDK 11 when it becomes LTS-2.
>
>
>
> > > > - keep as many modules as feasible compatible with release 8
> > >
> > > -1 : A number of things have come up recently about preparing for JDK
> > > 21+ that would involve increasing the bytecode level and APIs in some
> > > core parts of the NetBeans runtime container.
> >
> > Could you elaborate what that is? Not using Thread#stop and dropping
> > finalizers is it not. That can be done (with some pain) with support
> > for 8. So what is the problem?
> >
>
> Yes, those and I think some others. My paragraph after the one you quoted
> was acknowledging we can do this for 8 with some pain (headache). The
> question is whether it is worth it?
>
> Best wishes,
>
> Neil
>

Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))

[Neil C Smith]

On Sun, 12 Feb 2023, 19:11 Matthias Bläsing,
 wrote:

> Hi,
>
> Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith:
> > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing 
> > 
> wrote:
> > > - commit to make NetBeans runnable on JDK LTS -1
> > > - build with JDK LTS -1
> > > - be able to be build with the current JDK
> >
> > +1 as long as that includes the platform.
> >
> > That is what I suggested in the other thread (I don't see why we need
> > multiple threads incidentally!)
> >
> > An LTS-1 strategy seems closest to how NetBeans used to function -
> > major-1, in a time when it also had more development resources?
> >
> > Let's also be clear, though, that adopting an LTS-1 strategy means
> > dropping JDK 11 support either in our first release after JDK 21, or
> > the first after JDK 22 - so latest May 2024.
>
> why would we do that? I said _runnable_ and _buildable_. As long as the
> current JDK support the target release I did not exclude that.
>

In which case I don't understand what you mean by committing to make
NetBeans buildable and runnable on LTS-1? That to me means dropping the
commitment to JDK 11 when it becomes LTS-2.



> > > - keep as many modules as feasible compatible with release 8
> >
> > -1 : A number of things have come up recently about preparing for JDK
> > 21+ that would involve increasing the bytecode level and APIs in some
> > core parts of the NetBeans runtime container.
>
> Could you elaborate what that is? Not using Thread#stop and dropping
> finalizers is it not. That can be done (with some pain) with support
> for 8. So what is the problem?
>

Yes, those and I think some others. My paragraph after the one you quoted
was acknowledging we can do this for 8 with some pain (headache). The
question is whether it is worth it?

Best wishes,

Neil

Re: Bill of Materials POMs for Netbeans Modules

[Edwin F.]

Thanks Neil
Gonna try it. I'll keep posting.
BR,
===
Edwin F. López A.
===

Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))

[Matthias Bläsing]

Hi,

Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith:
> On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing 
>  wrote:
> > - commit to make NetBeans runnable on JDK LTS -1
> > - build with JDK LTS -1
> > - be able to be build with the current JDK
> 
> +1 as long as that includes the platform.
> 
> That is what I suggested in the other thread (I don't see why we need
> multiple threads incidentally!)
> 
> An LTS-1 strategy seems closest to how NetBeans used to function -
> major-1, in a time when it also had more development resources?
> 
> Let's also be clear, though, that adopting an LTS-1 strategy means
> dropping JDK 11 support either in our first release after JDK 21, or
> the first after JDK 22 - so latest May 2024.

why would we do that? I said _runnable_ and _buildable_. As long as the
current JDK support the target release I did not exclude that.

> > - keep as many modules as feasible compatible with release 8
> 
> -1 : A number of things have come up recently about preparing for JDK
> 21+ that would involve increasing the bytecode level and APIs in some
> core parts of the NetBeans runtime container.

Could you elaborate what that is? Not using Thread#stop and dropping
finalizers is it not. That can be done (with some pain) with support
for 8. So what is the problem?

> We could choose to keep release 8 for some modules that make sense as
> libraries outside of the runtime container - utilities, lookup, etc.?
> But surely it makes more sense to explicitly specify those, so that we
> and third-parties have clarity over which things still support JDK 8?

This might be part of a constructive counter proposal of the "JDK 8
will never die" fraction.

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

Re: Bill of Materials POMs for Netbeans Modules

[Neil C Smith]

On Sun, 12 Feb 2023, 16:29 Edwin F.,  wrote:

> Can I please have the url where these boms are available?
> I'm interested initially in the bom that has the required dependencies for
> the database module to work on its own.
>

I wonder if the kit module covers what you're looking for though?

https://central.sonatype.com/artifact/org.netbeans.modules/org-netbeans-modules-db-kit/RELEASE160/overview

Best wishes,

Neil

Re: Bill of Materials POMs for Netbeans Modules

[Edwin F.]

Hi Antonio.

Yes, I checked them, but I assumed that was the initial conversation :-D
Anyways, thanks for answering my question. I'll think about it. Is there
any resource you can point me to at learning about contributions?
Thanks.
BR,
===
Edwin F. López A.
===

Re: Gradle Distribution Settings

[Scott Palmer]

I’m an odd ball with more than just my Gradle setup 藍 

Basically I just want to use the latest version unless I need to pin it down 
for compatibility.  That lets me see when I’m using something that has been 
deprecated etc.

Regarding the Gradle User Home setting… I think these days the people that have 
multiple drives and need to have Gradle store artifacts outside of their home 
directory likely know various ways to make that happen (e.g. symlink or env 
var).  As I stated, we don’t have a similar override for Maven (which has other 
ways to deal with it as well), so we don’t likely need this.  In any case 
running from the command line, I doubt users would want to always type the 
--gradle-user-home option (or remember to if they’ve changed the setting in 
NB), they probably set the GRADLE_USER_HOME environment variable.  That should 
solve the issue for NetBeans as well.

You could always keep the ability behind a more generic list of additional 
options to add to Gradle commands.  Like the way you can add arguments to build 
actions from the project settings.

Cheers,

Scott

> On Feb 12, 2023, at 12:29 AM, Laszlo Kishalmi  
> wrote:
> 
> Dear Scott,
> 
> You are an odd ball with your setup. I'm sure you are doing that for a 
> reason, so that should be appreciated. Thank you for your feedback! It seems 
> the custom distribution is here to stay.
> 
> Setting the Gradle Home is for those (poor) people, who have limited space on 
> their home directory (wrong PC setup, educational setups, etc.), so they 
> could pack their stuff somewhere else.
> 
> I'm going to think about your ideas as well! Once again, Thank you for 
> speaking up!
> 
>> On 2/11/23 15:32, Scott Palmer wrote:
>> Gradle wrapper should always be the default if it is initialized.  So I 
>> would reverse the logic for the "Prefer to use Gradle Wrapper" checkbox and 
>> change the main part of the Gradle settings dialog to, e.g:
>> 
>> [checkbox] Override Project Gradle Version
>> 
>> Default Gradle Distribution:
>> [radio] Use Standard Gradle Version: [combobox]
>> [radio] Custom: [path field][browse button]
>> 
>> If the wrapper isn't configured for a project, the default version is 
>> implied.
>> 
>> "Gradle User Home" should be an advanced setting that isn't normally 
>> visible, or just remove it.  There is no such setting to override the Maven 
>> Home, why do we have it for Gradle?
>> "Start Gradle Daemon on IDE Start" isn't needed.  If you are opening Gradle 
>> projects as the IDE restores the last open projects, starting the daemons 
>> needed will happen anyway.
>> "Install Gradle Runtime Silently" isn't needed.  It's implied that this will 
>> happen if "Default Gradle Distribution" is not set to "Custom"
>> 
>> When a new project is made, it uses the Gradle init logic which will 
>> automatically configure the Gradle Wrapper with the default Gradle version.  
>>  So most NB-created projects will have a "project" setting for what Gradle 
>> to use.  The use of the wrapper is a best practice, so I think this makes 
>> sense.
>> 
>> The Project Properties should show the current version configured for the 
>> Gradle Wrapper and allow it to be changed.
>> If the wrapper is not configured for a project, instead it should show a 
>> button to "Initialize Gradle Wrapper with Gradle version: [combobox]"  The 
>> combobox includes all standard versions and is pre-selected with the word 
>> "Default" and the version number of "custom" in parenthesis. e.g. "Default 
>> (7.6)" or "Default (custom)"
>> 
>> Regards,
>> 
>> Scott
>> 
>> On Sat, Feb 11, 2023 at 5:59 PM Scott Palmer  wrote:
>> 
>>I don't use the wrapper until a project is final or I have to
>>share it.
>>I am almost always on the bleeding edge as far as Gradle
>>versions.  I keep all of my projects on the most recent Gradle
>>version when I work on them, often on the latest release candidate
>>(unless I encounter problems - which I want to be aware of so I
>>can report them or fix my scripts).  The wrapper just adds
>>overhead for my day to day usage. I don't need a zillion versions
>>of Gradle cached on my system.  If the project is to be shared,
>>then I add the wrapper because then it makes sense.
>> 
>>My NB settings are such that I use a version of Gradle at a fixed
>>location via Custom Gradle Distribution, which is just a symlink
>>to the latest version of Gradle that I have downloaded.  That
>>symlink is also on my path.  So I'm using the latest Gradle in NB
>>and from the command line, unless I invoke the wrapper instead.
>> 
>>So I don't want the Custom Gradle Distribution option to go away.
>> 
>>The Gradle User Home option is useless to me.  I don't understand
>>why I would ever want to change that.  That's just asking for
>>trouble as then my command line builds would be doing something
>>different from my NB builds and I don't want that.
>>image.png
>>Scott
>> 

Re: Bill of Materials POMs for Netbeans Modules

[Antonio]

Hi Edwin,

I was pointing to two old threads that talked about adding BOMs to 
NetBeans that Neil was talking about.


The fact is that we don't have a BOM yet. But contributions are welcome :-).

Cheers,
Antonio

On 12/2/23 17:28, Edwin F. wrote:

Can I please have the url where these boms are available?
I'm interested initially in the bom that has the required dependencies for
the database module to work on its own.


-
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: Bill of Materials POMs for Netbeans Modules

[Edwin F.]

Thanks Antonio.
Can I please have the url where these boms are available?
I'm interested initially in the bom that has the required dependencies for
the database module to work on its own.
Thanks a lot.
BR,
===
Edwin F. López A.
===


El vie, 10 feb 2023 a la(s) 20:02, Antonio (anto...@vieiro.net.invalid)
escribió:

> Yep, Bill of Materials have been around for a long time now...
>
> - 2020 https://lists.apache.org/thread/xqf041nzhl1rwvh4gosqkg19h43g9fl6
> - 2022 https://lists.apache.org/thread/ll2xq0mrbdw9y3rwm1gpnf7ovc2ld4rf
>
> Cheers,
> Antonio
>
> On 10/2/23 12:22, Neil C Smith wrote:
> > Yes, Eric and I had a conversation ages ago about the possibility of
> > replacing or augmenting the cluster poms with a bill of materials.  I
> > started looking at the process for generating, but other things, etc.
> > etc. took priority and I never did get around to it.
>
> -
> 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: Rust, anyone?

[Antonio]

Thanks Michael!

D'oh! My intents to add Rust to the NetBeans core (very much as in the 
Linux kernel case) have been detected! :-D


Latest commits solve these issues, though (and add new bugs).

Next challenge: Cargo workspaces [1].

Cheers,
Antonio

[1] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html

On 12/2/23 9:03, Michael Bien wrote:
for others who want to give it a try: I had to fix two things to make 
the build pass:
  - removed references of RustPackage in org.openide.nodes.Node 
(probably a happy coding accident)

  - had to create this folder: netbeans/rust/rust.project/test/unit/src


-
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: How to incorporate MIT source code?

[Neil C Smith]

On Sun, 12 Feb 2023, 09:06 Antonio,  wrote:

> I've updated the "licenseinfo.xml" (adding the proper license in
> nbbuild/licenses. Question is, shall I mantain the original MIT license
> header in the file as well as the Apache one such as in [1]?
>


Yes. I covered that with ASF link in my reply.

Best wishes,

Neil

Re: Gradle Distribution Settings

[Michael Bien]

sounds good to me.

regarding the gradle custom dist selection:

One argument for keeping it would be to have parity to maven which is 
still fairly similar in setup, it has daemons, wrappers etc. The UI has 
a dist selector too - I use that one sometimes. But I do also agree that 
it is more common in gradle projects to use wrappers, while in maven 
land it is still often expected that it is installed on your machine 
like in old times.


if it isn't too difficult to maintain I would consider keeping that option.

also if you are planning to move elements around in the gradle options, 
it would be worth thinking about trying to mirror it in the maven 
options so that the UX is somewhat similar.


best regards,
michael


On 11.02.23 08:39, Laszlo Kishalmi wrote:

Dear all,

I'd like to collect some feedback on the Gradle Distribution Settings 
(Tools > Options > Java > Gradle > Execution Panel > Distribution 
Section)


Over the years, Gradle evolved and some usage patterns has changed.

8 years ago, Gradle Daemon was in incubation phase. It could took a 
few  (5-10) seconds to start a daemon especially with HDDs.
People usually installed some latest Gradle and used that globally, 
wrapper was not yet popular.


I think the following settings are obsolete:
  - Start Gradle Daemon on IDE Start: Most people are using wrappers, 
so a daemon with the IDE defined distribution, just wasting resources.

  - Install Gradle Runtime Silently (Project trust is fine for that)

The following options are questionable:
  Custom Gradle Distribution. (I think I've used only once around 2.3 
when I built my own Gradle distribution due to a bug in Gradle)


The Gradle Distribution Selector Combo Box is over engineered. I would 
replace that and the
"Prefer to Use Gradle Wrapper that Comes with the Project" check box 
in a simple combo with elements:

Wrapper
8.0
7.6

3.0

I would drop the selection below at least 3.0 (Gradle 2.x are ancient, 
and there are a few versions which are not working well with NetBeans)


So at the end I would keep the Gradle Home and the combined 
distribution selector. Probably move that to root project level as well.


What do you think?


-
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: How to incorporate MIT source code?

[Antonio]

Thanks, Laszlo,

I've updated the "licenseinfo.xml" (adding the proper license in 
nbbuild/licenses. Question is, shall I mantain the original MIT license 
header in the file as well as the Apache one such as in [1]?


On other news, I generate the grammars at build time with [2] (using the 
org.antlrv4.Tool in build.xml).


Thanks,
Antonio



[1]
https://github.com/vieiro/netbeans-cnd/blob/285b1cd5192ba57852e01c0b01057a772d83c6a1/rust/rust.grammar/src/org/netbeans/modules/rust/grammar/antlr4/g4/RustLexer.g4

[2]
https://github.com/vieiro/netbeans-cnd/blob/285b1cd5192ba57852e01c0b01057a772d83c6a1/rust/rust.grammar/build.xml



On 11/2/23 9:03, Laszlo Kishalmi wrote:
Here is an example: 
https://github.com/apache/netbeans/blob/master/java/languages.antlr/licenseinfo.xml


MIT is a pretty permissive license, AFAIK it can be used without 
restriction. See the nbbuild/licenses folder for examples.


-
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: Rust, anyone?

[Michael Bien]

well, I just wrote my first Rust program in NetBeans - great work Antonio!

already added the 'Rust' label :)

for others who want to give it a try: I had to fix two things to make 
the build pass:
 - removed references of RustPackage in org.openide.nodes.Node 
(probably a happy coding accident)

 - had to create this folder: netbeans/rust/rust.project/test/unit/src

best regards,
michael

On 11.02.23 22:26, Antonio wrote:

Hi again,

For those interesed, an alpha version (under heavy refactoring) is 
available at


https://github.com/vieiro/netbeans-cnd/tree/rust

Buildable with "ant -Dcluster.config=rust"

Cheers,
Antonio

P.S.: Of course, you need Rust's "cargo" on your command line to make 
any use of it.


On 11/2/23 15:54, Antonio wrote:
I have a minimal cluster with Rust support, but I'm not sure I'll be 
able to maintain it. Maybe a plugin is a better idea?


-
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