Mathieu Guindon

room topic changed to VBA Rubberducking: This chat has moved to Discord: discord.gg/MYX9RECenJ [antlr] [com-interop] [parsing] [rubberduck] [vb6] [vba] [whiskey-tango-foxtrot]

room topic changed to VBA Rubberducking: This chat has moved to Discord: discord.gg/EmbYjbPr [antlr] [com-interop] [parsing] [rubberduck] [vb6] [vba] [whiskey-tango-foxtrot]

This room comes up whenever you search for COM stuff lol

Deleting the room would be a great loss IMO... so much knowledge is buried in here...

Here we go:

Or a mod could freeze the room if we ask nicely 😉

(assuming the file association isn't working)

then you can have a .bat that launches the command =)

@FreeMan run an admin command prompt (CMD.exe), and see what arguments would need to be given to run your package: learn.microsoft.com/en-us/sql/integration-services/packages/…

@FreeMan no problem! We're ready when you are!

try running it from command-line

@FreeMan I... oh. lol sorry 😂 have you joined yet? Please mention your SE username when you join.

Otherwise there's definitely a way to get a bot up, twinBASIC has one

Hm that'd be nice

(the other link expires in a few days)

Discord server join permalink

@Duga nice!

Discord server join link

Hm, I should set up the labels and merge the projects, will be much easier to manage

so, this week I'm wrapping up the platform stuff, ...and coming up with a backlog

been a while since I dreamed of having that kind of time again :D

weekly sprints with small broken-up tasks should make everything bite-sized

I think I can pick up a pace and actually schedule time for "sprint planning" and other PO activities

I think it's just a matter of discipline after that

trying something...

That said nothing stops a client from logging its own stuff without telling the LSP server ;-)

I'll have to double-check if it's LSP-compliant (IIRC it is), but RD3 RPC clients will be able to send log notifications to the server through that client library, so add-in logging that could potentially trigger a TraceTelemetry event would all go through it.

there's a piece missing between the add-in and the LSP server though: the Rubberduck.Client library will expose everything the add-in needs to communicate with the LSP server, so it won't need to deal with RPC and proxies at all.

a tB add-in would probably have to reference at least some of the RD3 assemblies, and thus would have to be a consumer of the logging API, I think.

there are other approaches to cross-cutting concerns; we could have used an AOP (aspect-oriented) framework to generate that logging code at compile-time for example

...while still having access to the logger if more detailed logging should be needed

@Greedo logging is a special concern in an application, because it is "cross-cutting" - we went with DI so we're typically injecting the logger into some base class that invokes a templated abstract method that derived classes can implement without needing to care much about trace logging, ...

(look into NLog for a better idea of what the intent/destination was for this)

@Greedo I based that code on making an experience similar to using NLog but in VBA =)

Rubberduck3 roadmap discussion

Once that's fixed, the PR is pretty much good to go and RD3 kicks off for real

Went to bed with RPC failing with a weird JSON deserialization error, like, the method sends it a InitializeParams instance, but then it tries to deserialize it as a completely unrelated type that makes no sense; I'll be diving into the lower-level RPC stuff, think it has to do with positional vs named parameters.

almost there!! :)

progress...

update: RPC works! ...almost :D

Me, paying GD since 2015 for a SQL Server database that's a tiny fraction of the size I'm allowed: PAYBACK TIME 😂😂

(also, heavily client-side, esp. anything that isn't a TraceTelemetry event)

It's much more granular than trace logs :)

(list is obviously incomplete)

EventTelemetry items would be fired for these: github.com/rubberduck-vba/Rubberduck3/blob/server/groundwork/…

At least that's how I see it