Use Rubberduck only for versioning ?

[Selmirrrrr]

Hello,

Firstly let me thank you all for this amazing OSS project. I'm pretty new to Access VBA development (3 weeks) and my main task is to version our Access source code.

I have some issues with code inspections etc (endless loading and memory leak on startup) that freezes my Access 2013 project (tried many solutions and workarounds found in previous issues but didn't find a way make things work). Actually, I don't need code inspectons and others IDE features... So my question is : is it possible to disable others features and use only source control ?

Thank's in advance for your help.

[Vogel612]

Hey there,

a few points:

1. Source Control is considered an experimental feature. We don't consider it ready for full use yet.
2. Source Control is but a small part of what Rubberduck intends to achieve. While it may be useful to have the notion of "I only want Source Control" it's not a notion that's conform with the vision of what Rubberduck wants to be.
3. No... We don't want to throw away three years of work by making it easy to ignore when Rubberduck is bugging you about the mistakes and problems in your code or helping you actually organize your Modules and Classes and Forms into useful folders...
4. What ostensible benefit does this have over just writing a 20-line VBA script to export all your code and doing the source control by hand?

All in all this is not something that will ever be in scope, IMO

Regards Vogel

[retailcoder]

Thank you for your support.

FWIW you can disable inspections through the settings dialog, at the very bottom of the "inspection settings" tab there's a checkbox to "run inspections on successful parse" - un-checking that box will only run inspections when you click the "refresh" button on the Inspection Results toolwindow.

Alternatively you can selectively disable any/all inspection(s) by setting their severity level to "do not show".

That said, if inspections "take forever" to load, it's likely because it's busy crunching hundreds upon hundreds and thousands of inspection results - blanket-dismissing them all and saying "I don't need any of that" essentially boils down to dismissing roughly 100 man-years of combined VBA experience analyzing your code for you. I wouldn't be so fast to say "I don't need that" with a whole 3 weeks of experience under my belt 😉

[Selmirrrrr]

@Vogel612 Ouch, what a punch...

To answer to your points :

1. I saw this point but I can live with that, and why not contribute to improve this feature.
2. Ok for product's vision.
3. I don't want to ignore other Rubberduck's features, it would be amazing if I achieve to enable Ruberduck on our solution, but I tried hard since one week (without opening issue for things I think that could probably come forme our code base), so no disrespect here.
4. As I said, I'm very new to VBA development in my new job, I'm experienced with .NET C# but unfortunately not VBA, my colleagues told me that they already tried this solution but there were some issues with cases arbitrary switching from lowercase to uppercase and that's a mess to version.

Finally, I was not asking for something new to be implemented, I was just asking if it was already implemented.

@retailcoder I already disabled code inspection and defined all severity levels to "do not show" but it's still loading until it has enough RAM (tried on a i7 16GB RAM Access 2013 64 bits config).

There's a misunderstanding, I didn't told that I'm better than others and don't need code analyzers for this solution, I'm actually using Resharper for my .NET projects and that's an AMAZING help, just like Rubberduck seems to be for VBA projects, I just thought it would be easier to enable source control without this feature.

To sum up, sorry if you felt offended with my question (maybe that's because I'm not 100% fluent in English).

[Hosch250]

1. We are contributing to this feature. It started out back in 1.4.3, was greatly improved in 2.0.0, and was just recently made even more stable. There are still known bugs, though, and we are a small team and don't have time to contribute as much as we like.
2. If you are experienced with C#, feel free to help contribute yourself :). More contributors are always welcome.

As for the RAM problem, that is another known issue that we are working on; it is related to the parsing/resolving stage, where we figure out what variable is being called where, etc. We are considering using a DB to store some of our data instead of storing it all in the RAM, but this will be a big change, and may take a while to be implemented.

[retailcoder]

@r0xtar no worries (I was a bit irked by the idea of butchering 3 years' worth of work though ;-)

RAM consumption is an issue (see #3347), but it's the result of a deliberate and necessary memory-vs-performance trade-off in favor of performance, not of a memory leak - if there's a memory leak, it's most likely closer to COM interop and RCW's (e.g. commandbars, docked toolwindows) than any of the managed code, and definitely not perceptible through RAM monitoring (although possibly observable as a silently-crashing hsot process that might linger in Tasks Manager, as explained in the release notes - we used to outright crash on exit, so significant progress was made there, and more to come).

[Selmirrrrr]

@Hosch250 I completely understand the resources/time problem for un free OSS project like Rubberduck is. That's why I totally respect amazing work that's done here.

With my issue, I see RAM consumption growing until usage hits 100%, but the Access process is still working (5-10% of CPU power) and Rubberduck writes parsing errors into the log file.

I'll take some time to try to help this project, my big problem here is lack of VBA knowledge, even if Rubberduck is written in C# I don't now if it's possible to contribute with my very very low VBA level (near to zero). But I'll try :)

[retailcoder]

@r0xtar haha @Hosch250 just so happens to hate VBA with a passion lol no worries about VBA knowledge, it's not a prerequesite at all 👍

[Hosch250]

Don't worry, I have yet to write a useful program in VBA. My limit is hit with stuff like:

Sub Foo()
    Dim fuzz As Integer
    fuzz = 0
    fuzz = 3
End Sub

As for the parsing errors, that is a whole new issue. Something in our grammar is broken. Can you share the details with us? This is something we'll mark as a top-priority bug.

[retailcoder]

Agreed, the parsing errors are very very problematic, and a very likely cause for slow-downs if many modules are throwing exceptions. We'd need to see the logs =)