« first day (3146 days earlier)      last day (34 days later) » 

00:08
REFRESH!
[Minesweeper] 92 Games Played. 43 Bombs Used. 10651 Moves Performed. 22 New Users
[Zomis/FactorioMods] 2 additions. 1 deletions. 1 commits
@Duga ah that's what the expired token was! #SqueakyWheelDebugging
Hm no, timestamp says 24h ago
cough 37 seconds ago cough
@MathieuGuindon just to point out - you should make sure that the race condition is handled (e.g. client starts to connect but then the timeout expires due to running on a different thread, and client then get an exception) - so that it can just restart the server as well as handle the case where client dies without telling the server about it dying (how rude!)
00:27
yeah.. lots of testing to do! ...I took the best SO answer! :D
the whole thing seems pretty resilient by design though
not going to make that kind of xmldoc everywhere, but I think it's bloody helpful
 
2 hours later…
02:18
I may have accidentally written a telemetry model
ok, not so accidentally
@this we're getting the correlation IDs and trackable requests and everything
#BecauseWhyNot
so, I'll just add a TelemetryClientCapanilities class with a TelemetryOptions, and then it should just plug into the initialization code
and, it's inherently opt-in
I'm tired of knowing exactly nothing of how RD is used, what inspections fire results, how commonly we save anyone's ass, etc.
hopefully at least one or two users opt-in :D
The aggregated metrics could make some pretty interesting daily summaries..
The telemetry client is going to hit an api.rubberduckvba.com endpoint that'll accept the payloads through https, could require GH authentication if we want.
The telemetry payloads are going to be written to localdb in any case
That way whether trace output is enabled or not, detailed troubleshooting data exists and can be pulled locally and reviewed before sharing
02:57
Could be visualized (and purged, exported, or sent to us) from a "Telemetry" tab in the LSP server client app.
> Telemetry is currently disabled. Please review [settings]() to configure how Rubberduck.Server.LSP should handle telemetry notifications.
^^ first encounter with the feature, probably
 
2 hours later…
04:40
pushed (to PR branch)
I'm zombifying.. head, meet bed.
 
9 hours later…
13:12
Aug 22, 2019 at 19:52, by Mathieu Guindon

We're all idiots

17 mins ago, 15 minutes total – 24 messages, 6 users, 0 stars

Bookmarked 6 secs ago by Mathieu Guindon

@MathieuGuindon If telemetry is written to localdb, then for those who would like to participate, but whose corporate IT prevents them from doing so, there could be an Manually Export Telemetry option that would generate a file (JSON/XML) that could be manually uploaded to GH (or somewhere) then parsed and imported to the GlobalTelemetrydb
Not nearly as slick as auto upload, but it gets around the corporate nannies in a fully 100% legit way. It also gives the employee an opportunity to show IT exactly what would be uploaded if it were allowed to be done automatically, and might actually serve to get an IT green light.
13:53
Yep, full transparency here
 
2 hours later…
16:08
> Hi @inventordev , I have been using this patch with Inventor 2022 and it does allow Rubberduck to work. However, I often get an "Unexpected Error" from Rubberduck during refresh when I have Inventor files open. Have you had any similar issues?
16:30
ok I have a bit of a doubt here
var server = new LocalDbServer(Settings.Default.JsonRpcServerPath, startupOptions.Port, console, startupOptions.Interactive, TimeSpan.FromMilliseconds(startupOptions.ExitDelayMilliseconds));
server.Start();

while (server.IsAlive)
{

}
it doesn't feel right to just spin-loop like this
ooh that's pretty
3
A: Recommended way to prevent a .Net Core 5 console app from ending when run on Linux as a service

MonkeyDLuffyWell, while loop is a beautiful thing but it is enemy of the CPU. Instead of while, I often use ManualResetEvent class to prevent closing console apps. Usually it works when i use this code block in Linux containers on Docker. I don't have the actual code block, I am going to remember it like; ...

var server = new LocalDbServer(Settings.Default.JsonRpcServerPath, startupOptions.Port, console, startupOptions.Interactive, TimeSpan.FromMilliseconds(startupOptions.ExitDelayMilliseconds));
server.Start();

_shutdownSignal.WaitOne();
What about the accepted ansewr?
Task.Delay(-1)
and use a cancellation token / exceptions for flow control instead?
:)
IDK. The answer implied that it would handle race conditions or something like that (assuming that's what they meant by "graceful shutdown")
also plays nicely with async, hmm
However, don't be disappointed if it turns out that under the hood, it's ultimately a while loop. :)
16:40
lol
I'll just try both and see which one gives me happy threads
maybe both ways are fine
on a hunch, Task.Delay leaves the main thread happy and usable
pay no attention to the while loop behind the curtain
ServerOptions.Interactive needs to be removed now that the GUI has been made into a separate client app
...and exit delay too
The client will simply go from "ready" to "no connection" instead of shutting down
Hm, haven't done the db backend for telemetry
It'll be nice to reassemble RD and issue telemetry events left & right with troubleshooting and metrics in mind
Traditional logging will probably end up taking a backseat
17:33
Ok, shutdown signal is in place, server will exit after the last client has disconnected. Now the fun part: handling and responding to the initialize request..
might have to tweak RPC-level message handling to correctly handle losing the db server on the LSP side
(it should spawn a new instance)
that part is needed for LSP/add-in comms too
 
5 hours later…
22:24
Tonight the goal is to get into bed by midnight the DB client app to successfully communicate with the localdb server. If I get that quickly I'll script the tables for the telemetry model and prepare the data layer for it.
22:47
I'm dropping the Newtonsoft.Json package, System.Text.Json outperforms it
23:01
Oh damn, it's the JsonRpc library's
23:21
Eh screw it, 1. Make it work. We'll make it faster in due time.
It's probably fast enough already
23:53
[rubberduck-vba/Rubberduck] 1701 stars vs. [decalage2/oletools] 2308 stars

« first day (3146 days earlier)      last day (34 days later) »