REFRESH!

[Minesweeper] 130 Games Played. 71 Bombs Used. 18783 Moves Performed. 8 New Users

[rubberduck-vba/Rubberduck] 4 additions. 4 deletions. 2 commits

[rubberduck-vba/Rubberduck] plentyofcoffee starred us

^sa-weeet!!!!

:facepalm:

[rubberduck-vba/Rubberduck] doterik created comment on pull request #5939: Typo in reasoning - ProcedureCanBeWrittenAsFunction

> 👍🏼

[rubberduck-vba/Rubberduck] dRylynn starred us

for those who excels at Excel.... is there a built-in way to match up 2 lists the equivalent of a FULL OUTER JOIN ?

e.g. if list #1 has a, b, c and list #2 has a, c, d, the result should then have {a, a}, {b, <blank>}, {c, c}, {<blank>, d}

what version of Excel?

o365

and your output would presumably be two columns?

well sure, but even better if it's something I can do generally

as I find that it's common taskf or me to get 2 lists and I have to then reconcile what's different between the 2 lists and that 2 lists could have more than one columns but typically matching on only one column that's common between the 2 lists

TFW you start adding tests to code that's evolved since whenever without it, and start seeing just how much embedded domain knowledge it contains...

Is it bad that a class's cyclomatic complexity is in four figures lol

@this When I first started working with git (only a few years back), it amazed me how it could be so robust, when Access is so flakey. I mean, they both allow multiple users to collaborate on a shared source, right?

Then I realised - Git manages itself locally, and then occasionally syncs. Access literally opens the network file directly during use. Obvious once you realise it.

Lesson: Multiple users opening a file for Shared Read Write over SMB is not likely to end well.

@mansellan yep, git doesn't do any page ripping. In Excel's or Word's case, the entire file is locked so only one can write to it while others can read it. How do you share a database file without a librarian? Hint: very carefully.

Not sure whether it's worth expending effort to improve the RD experience in VB6 - looks like twinBASIC is going to be a perfect replacement for it.

Analysis is yet to arrive, but I'm confident it will.

OTOH, I think RD in VBA is still viable. The VBIDE is the default experience, and that's not likely to change. Power users might choose to use twinBASIC, but it won't be the default.

It creates a new table that references the other two tables.

Then you can "refresh data" to update your new table with the query results. So it can become a living part of a workbook. It just needs to be refreshed regularly because it doesn't update instantly like an automatically calculated formula does.

The reason it doesn't seem to fit in to Excel is because it was written by a different company. It's known as "PowerBI" which was a standalone product that M$ purchased. Now there is a Microsoft PowerBI and there is PowerQuery inside of Excel. Both use the old PowerBi engine

but does it do full outer joins? would need tou double it's there

docs.microsoft.com/en-us/power-query/merge-queries-full-outer

^ @this says yes

@Duga hm, looks like the build pipeline isn't working after all

@mansellan that's what I think too... however RD probably needs a deep overhaul to get the performance and memory issues under control... but I think it's best to wait until tB has a complete API first, before we can even think of any tweaks

@MathieuGuindon it's very weird that the webhook delivery for that works just fine (and worked for the previous PR apparently), but somehow AppVeyor seems entirely unaware there is a PR there

hmm ... actually... looking at the recent builds it seems like no PRs have been built for quite a while..

I'm not sure what's missing tbh

@MathieuGuindon I think LSP is the key. At this point in time, many of the calls would be similar to the ones twiBASIC makes, but others (analysis) wouldn't. I'm not sure what the right effort at the right time would be...

need to do it incrementally, I think. I'd want to try and see if tB can be used to provide the equivalent of COM shims.

That alone would mootize the stupid teardown issues

Agree. RD and tB need to co-exist.

the main problem however is that the .NET core isn't quite there for typelib support. I think we're already on .NET 6 but not much movement on typelib support, I think?

Adding to this, twinBASIC (with mature UI) would be a great way to write the RD front end...

@this what's still missing?

typelib support?

Isn't that a FE concern though? If we could author a complete COM front end in twinBASIC and communicate to the back end through IPC, problem goes away?

that would be the next step. I was thinking incrementally which mean intially tB provides shim for the addins but still work with the COM objects from the RD's .NET objects

ah ok, yeah

otherwise we'd have to go and implement the LSP which could be.... a lot of work? IDK.

Yep. It would be, even in C# In tB, uhm, more so right now?

@MathieuGuindon where do you see us going?

and if LSP is meant to run async, it's going to be easier doing it in C# right now

^

IDK. I'd like to see "Powered by twinBasic" in RD's about box eventually, but realistically the amount of work involved in just RD 3.0 is already orders of magnitude beyond what I can afford to put in, so to think of swapping the whole entire backbone... it's pretty much a full rewrite IMO.

"daunting" doesn't begin to describe it

hmm ... not sure it would be that huge of a change, actually..

the really interesting part is how the grammar (and the use of it) would need to change

most of the other things "we" could either migrate bit by bit or we need them to integrate with the VBE in the first place

for parsing tB code, you mean?

nah, the "powered by tB"

then I'm not sure I follow why grammar needs to change.

I presume that a tB backend will use a different grammar to ours.

p sure there's no ANTLR in the tB backend

Maybe I'm misunderstanding something, but I would be hoping for a tB API that gives us the structural and semantic views in an object model that basically replaces our Declaration and IdentiferReference stuff... no?

ah, no no no no

hm

we don't have ANTLR or anything in tB. Therefore, it has to stay in C#. We just need to decouple sot hat it runs out of process

e.g. using LSP for example

now, I can't be sure if using LSP will mandate changing how Declaration and IdentiferReference works. But I'd hope that we would be able to avoid the rewrite by continuing to using ANTLR while putting in a tB front-end.

that's not how any of that works, I think ..

LSP gets text and returns a syntax tree

hmm.

and I was thinking that walking the syntax tree would be a backend work

basically the idea of LSP is to push the Rubberduck.Parsing out of process

LSP kills ANTLR then

@Vogel612 that alone should be a huge win

@MathieuGuindon that depends on what exactly we put into the LSP server

because we don't want any parsing work to happen on the VBIDE thread.

that could be ANTLR

or it could be tB

@this LSP has support for also doing the whole Rubberduck.Inspections stuff

@MathieuGuindon yup

that, we definitely want out of process for that

LSP is request/response, built on JSON-rpc

so we have much more freedom on how to thread without making VBIDE feel like working in a tarpit

@this LSP isn't strictly necessary for that, but since it works on the parse-tree that basically requires some form of transferring the parse-tree

and at that point we could just go full out-of-process for that

do we know if we have threading problems with toolwindows?

It's a protocol. Could be in-process, IPC, or out to some server on the interwebs.

@this define threading problems?

IINM there is some shenanigans with the UnitTesting toolwindow

by then we'll only have The One toolwindow (#AvalonMentions++) =)

and the whole wrapping XAML in Forms into native dockables is a problem

I'm picturing that the process has to be 1) user makes a change in code in VBIDE -> 2) front-end captures the changes and send raw text to OOP process -> 3) the OOP process does its magic, build/update parse tree, runs inspection -> 4) reports new inspection results back to the toolwindow's control asynchronously, with the result that user does not feel any slowdown with VBIDE.

^ uhm, seems good?

it's the updating toolwindow part that I'm not 100% sure if we can freely maniipulate without interfering/blocking VBIDE's thread

2) is a bit of black magic... just saying..

Avalon XAML into dockable toolwindow likely remains a problem

@this we need to run UI updates on the main thread

see, and that's where I think WPF is doing something to make it so slow so expensive.

we could build UI component trees off the main thread, but the actual update needs to be on the main thread

Just saying... VS 2022's analysis is not great until you let it settle down for a bit to let the async messages come in.

we can allevaite that by making updates cheap to do.

[rubberduck-vba/Rubberduck] 1508 stars vs. [decalage2/oletools] 1897 stars

@Vogel612 Yes that's true but it's not that bad. we just need to extract the user's edits and we can easily do that with dumb VBIDE API

"just" ...

remember that we also need to account for attributes

so that process will always necessitate writing a file

which was the whole rationale for the one huge Avalon toolwindow...

to cut out the file writing.

^

(and maybe make git much more sane)

except that that still regularly has to run an import into the actual VBE

because otherwise you can't run the code.,

or stale code, yeah

I think importing is pretty quick

that can happen on save, or on parse

so if we are able to track the save & compile events, we can import at that point.

@Vogel612 Meh, write it into the host IStorage. HHCIB. ( ;-) )

the document modules will complicate things, though.

Of course. @mansellan has volunteered to find us the pointer to the IStorage.

@mansellan I mean ... LibreOffice figured out some things about that... maybe we can copy their homework

well ... you

they did?

heh, yikes!

@this p sure you get execution semantics for at least a very limited subset of VBA in LibreOffice

you did see the ;-), right?

because they also have macro integration and support a BASIC dialect (as well as java, python, ...)

@mansellan huh? ;)

> HHCIB. ( ;-) )

... winks don't translate well in text... annoyingly

so: yes I saw, the point was still interesting enough to pretend to have not seen it

haha :-)

so, we doing LSP?

I don't quite follow this conversation so I've been looking up some terms I don't understand. I found a C# based plugin that runs ANTLR on a LSP server. It appears to do what we want. Is this useful? github.com/kaby76/AntlrVSIX

LSP++

@HackSlash pretty sure that that plugin is intended for parsing ANTLR grammars

Uhm, if we don't do it soon, Wayne is gonna eat our lunch. Just sayin'

Wayne is actively eating our lunch and he's doing a great job AFAICT

@Vogel612 Yep, and it's a good thing. But I'm still peckish,