VBA Rubberducking

Duga

00:08

REFRESH!

[Minesweeper] 112 Games Played. 70 Bombs Used. 15277 Moves Performed. 17 New Users

[rubberduck-vba/Rubberduck] 1 issue comments

[Rubberduck] 1 Synchronizations

Duga

12:04

[rubberduck-vba/Rubberduck] hwnd-git starred us

2

Duga

13:12

[rubberduck-vba/Rubberduck] hwnd-git added label bug to issue #6070: Sub/Function in Class - references missing between various Projects

[rubberduck-vba/Rubberduck] hwnd-git opened issue #6070: Sub/Function in Class - references missing between various Projects

> **Rubberduck version information**
The info below can be copy-paste-completed from the first lines of Rubberduck's log or the About box:

Rubberduck version [2.5.2.5906]
Operating System: [Microsoft Windows NT 10.0.19044.0, x64]
Host Product: [Dassault Systemes Product x64] (Catia v5)
Host Version: [5.28.0.17255]
Host Executable: [CNEXT.EXE]

**Description**
Rubberduck -> Navigate -> Find all referencess... does not seem to work for Subs or Functions located ins

Duga

13:23

[rubberduck-vba/Rubberduck] retailcoder added label resolver to issue #6070: Sub/Function in Class - references missing between various Projects

[rubberduck-vba/Rubberduck] retailcoder created comment on issue #6070: Sub/Function in Class - references missing between various Projects

> Thanks for the report! Probably a little oversight somewhere in the resolver causing too much filtering and excluding declarations in other projects that should be accessible.

Mathieu Guindon

I'm having to make early design decisions wrt both the client and server capabilities. The LSP specs define the interfaces in TypeScript, and the union types aren't playing nicely with C# so for example a method that would return X given client capability A but Y otherwise, returns X.

IOW the RD LSP likely won't support multiple clients, at least not as flexibly as it should

I went with returning X over object because I'm basically prioritizing type safety over spec compliance

Duga

14:29

[rubberduck-vba/Rubberduck] Vogel612 created comment on issue #6070: Sub/Function in Class - references missing between various Projects

> honestly to a certain extent I want to believe that that's by design. After all the number of declarations that needs to be searched is quite large enough already for find references even when not checking all open projects.

Duga

14:43

[rubberduck-vba/Rubberduck] retailcoder created comment on issue #6070: Sub/Function in Class - references missing between various Projects

> Hm to me that's definitely a scenario (cross-project refs) that should be handled correctly. There's no reason we can get refs for MsgBox but not for exposed classes & their public members in a user-code referenced project.

[rubberduck-vba/Rubberduck] hwnd-git created comment on issue #6070: Sub/Function in Class - references missing between various Projects

> @Vogel612 I have been wondering it that was intended behavior to maybe reduce the amount of computations needed to analyze all open projects that are referencing each other. But then, why the inconsistency during refactoring? Why can I refactor the name of the public object, and it is renamed in both projects, but can not refactor properly the names of its functions? This is what gave me an impression, that it might be a bug or kind of oversight.

Duga

15:02

[rubberduck-vba/Rubberduck] jozefizso starred us

2

Greedo

Sounds complicated. Multiple clients (Dev tools) per server isn't in the spec though is it? IIUC, the relationship is one tool (client) initialises and connects to potentially many servers. Or do you mean RD server cannot be instantiated more than once to cater for muffins clients, or similar that RD server won't be fully LSP compliant so cannot be used from other clients then RDE?

@MathieuGuindon

this

FWIW Wayne did mention that in his implementation of LSP, he uses custom messages (which is allowed by specs) to optimize the message-passing between the IDE (e.g. the LSP client) and the compiler (the server) .

Greedo

"muffin" = multiple

this

VS Code cannot use that, and thus the tb's LSP implementation is not 100% compatible with VS Code though the multiple messages can be split one by one which would make it compatible but with more overhead.

Greedo

@this how do you mean "split" the custom messages to make it compliant? Is Wayne grouping several standard LSP messages into a single custom one to make it more efficient (less back and forth between the processes)?

this

15:18

Yes, exactly

so really the custom messages are just a bunch of several individual messages rolled up.

Greedo

I think it's okay not to be 100% compliant if the immediate future for the rubberduck language server is RDE and possibly tBIDE, both of which can probably be adjusted to work around non compliant implementations.

this

The way I read it, not even VS Code is 100% complaint since the bunched messages is allowed by specs but it won't handle that.

Greedo

I'm more interested in if a RDE can use vscode LSP servers rather than whether vscode can use the RD language server. Both would be good but imagine opening the VB editor up to the marketplace of LSP extensions. E.g. a server that does spellcheck on your strings

@this that's weird considering they wrote the spec (I don't doubt it's true though ;)

this

@Greedo Not unprecedented, though. Likely a different group wrote the specs and the group responsible for VSC looked at it, and said, "nope"

@Greedo that's more to do with consuming LSP specification than implementing the specific LSP server / client. That shouldn't prevent RDE or even tBIDE from providing that as long they consume the LSP. However, I think that is a huge undertaking and it's easier to just implement the server and client to get things moving as is the case w/ tBIDE.

Mathieu Guindon

"muffins clients" is my new fav

3

Greedo

15:34

Freudian slip I clearly have cake on the mind

Mathieu Guindon

the way I see it, RD server would handle all its clients (each client would connect to the same server instance), although I'll have to check in the spec if that's OK to do. In theory RDE would be just one possible client for RD server; I'm not planning to have more, but in theory a VSC client shouldn't be impossible

actually if there are more clients than just RDE, it's probably better to spin a separate instance per client

this

It would be fun to have multiple VBA projects all sharing one same "solution".

Not sure that's practical though - I don't think you can edit an add-in while it's loaded in another project.

Mathieu Guindon

yeah, that needs more thought :)

still, with the VBE that becomes nothing more than a host, we get to play by our own rules

this

Yeah. This also would mean the sqlite database could have the declarations from other type libraries pre-loaded, cutting down the parsing time since Office's type libraries aren't likely to get changed as often as VBA projects get.

Mathieu Guindon

yep

@this is that the "prepare" requests? Basically he just returns all hierarchy items directly instead of sending a list to the client?

Greedo

15:49

@MathieuGuindon no I can't find the quote but the protocol explicitly says multiple clients per server instance is not supported, something to do with not supplying any process ids or having synchronisation built in.

Mathieu Guindon

Oooh that does make sense

Also I do recall reading something about clients using multiple servers, ...and thinking yeah no thanks, one will be enough

Especially with a SQLite database... multiple servers would imply RPC betwern servers, not having it haha

this

16:04

@MathieuGuindon sorry don't know. He didn't specify what; only explained that with VSCode he'd have to send back'n'forth several messages but with tBIDe, he can group them up as a single message, reducing the IPC chatter.

@MathieuGuindon Given the SQLite's design, it'll have to be a single server to all RPC server instances, i think.

or at least an individual SQLite process per RPC instance that loads a saved database.

Mathieu Guindon

16:29

Damn... Not going to have a choice but to do it that way if we want two RD instances to ever share a db

Or rather, if we want to avoid having two RD instances messing up the db

this

My suggestion would be to dump the type library declarations into a separate .sqlite database file.

then have a routine to spin up a new sqlite instance, then load it into the database from a template and populate the database using the selected type libraries for that VBA project.

should be still faster than parsing it from scratch, I think.

while allowing you to compose together different type libraries' declarations instead of just loading one giant database know-it-all

Mathieu Guindon

It'll be much easier to corrupt the db though

this

The reason for this is because the sqlite process effectively allow only one writer. I don't remember if it allows reading while writing is happening but I think not - all access will be serialized.

Mathieu Guindon

Yeah, in principle it's an in-process db

this

so if you have multiple processes sharing, the writes will have to be controlled carefully.

Right

Mathieu Guindon

16:36

I think I'd rather host it in its own process, and treat it like a server (kinda is)

That way there's only ever a single writer, and all reads come from one place

this

which in this case, the VBA project's declarations would need to be segregated

(while sharing the type library's declarations)

Mathieu Guindon

they got their own project ID, that should be enough to keep them separate

...no?

this

yes. the trick is to remember to apply filter on that while not on the type library (e.g. complicated WHERE / JOIN clauses)

probably better off abstracting in a view or soemthing like that

Mathieu Guindon

oh, there's totally a bunch of views... the tables are a bit weird because I managed to get all declarations into the same table, so to get the full picture you need to join with another table, like Modules or Members

this

16:51

awesome

Mathieu Guindon

not sure it covers every need yet though

Declaration is essentially becoming a mere little DTO in RD3

so everything we pull out of the context later on, needs to be in there somewhere

Mathieu Guindon

17:36

I think there's no more than a handful of inspections for which this'll mean a complete re-implementation. Then again the inspections will be running server-side, so there's a way to make them run with the full parse trees if we need to

this

the LSP specifications allow for something akin to event notifications, right? That should be easy to achieve whenever an inspection finishes its check and return the result.

Mathieu Guindon

the protocol doesn't enforce 2-way comms, but yeah RD LSP is going to have server pushing notifications to the client

Mathieu Guindon

18:05

it's defined in the client-side support, so the client would signal it supports such notifications on initialize

there's a number of such things I'm tempted to shortcut on, and just assume the client is RD

But I'd feel kinda dirty doing that, so I'll still have the server check client capabilities

Feeds

20:53

Things Leonhard Euler created ( most of math ( overlapping circle diagrams ) a cricket bowling machine ) Things John Venn created

Mathieu Guindon

22:03

Ah, I knew I'd seen it - it's a Publish diagnostics notification @this

and then there's a mechanism for the client to pull them for a given document

Duga

23:53

[rubberduck-vba/Rubberduck] 1698 stars vs. [decalage2/oletools] 2301 stars

Transcript for