« first day (2793 days earlier)      last day (110 days later) » 

12:00 AM
REFRESH!
[Minesweeper] 130 Games Played. 71 Bombs Used. 18783 Moves Performed. 8 New Users
[rubberduck-vba/Rubberduck] 4 additions. 4 deletions. 2 commits
 
 
16 hours later…
^sa-weeet!!!!
 
4:37 PM
:facepalm:
 
 
2 hours later…
7:19 PM
 
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
 
7:49 PM
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
 
> As Descriped in #5459 a Dialog asks for the Declaration Statement, if a Module-Level Variable gets Moved into a Method.
Furthermore Static Declarations inside Methods don't get replaced with Dim Statements anymore.
I think the mentioned counterpart "move Static local to module level" is already done by the IntroduceField Refractoring.
 
@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.
 
9:07 PM
@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.
 
9:45 PM
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.
 
@this you can do all the SQL magic in Excel using a feature called "Power Query"
https://support.microsoft.com/en-us/office/about-power-query-in-excel-7104fbee-9e62-4cb9-a02e-5bfb1a6c536a
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
 
10:05 PM
but does it do full outer joins? would need tou double it's there
 
@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
 
10:34 PM
@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.
 
10:50 PM
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
 
10:55 PM
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
 
11:28 PM
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
 
11:34 PM
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
 
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
 
11:37 PM
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
 
11:38 PM
@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?
 
11:41 PM
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?
 
11:43 PM
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
 
11:45 PM
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.
 
11:48 PM
^
 
(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.
 
11:50 PM
@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
 
11:52 PM
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
 
11:55 PM
we should start tracking a counter for that, just like for AvalonMentions
2
 
LSP++
2
 
@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,
2
 

« first day (2793 days earlier)      last day (110 days later) »