« first day (3128 days earlier)      last day (52 days later) » 

Duga
Duga
00:08
REFRESH!
[Minesweeper] 53 Games Played. 36 Bombs Used. 7882 Moves Performed. 5 New Users
[Zomis/FactorioMods] 3306 additions. 45 deletions. 8 commits
[Rubberduck] 1 Synchronizations
 
2 hours later…
this
this
02:34
@Greedo FYI that's a 404 for me. A private repo, maybe?
Right now, no. It really should be using Funcs to discover the private methods but that requires implementing the rest of ITypeInfo and ITypeLib interfaces and testing them properly. Note that I did not use the TLI library since we could just provide the interfaces directly in the twinBasic.
@MathieuGuindon Hopefully that means it will be either non-existent or at least trimmed down significantly. That thing does way too much and is hard to wrap one's head around.
Duga
Duga
[rubberduck-vba/Rubberduck] bclothier created comment on issue #5961: Building RD fails on olewoo
> One thing I want to confirm.... is the VS 2022 64-bit? The olewoo reference is a C++ library and it's 32-bit only. Since this was developed, someone made a nuget package for the olewoo (see: https://github.com/leibnitz27/olewoo/pull/16). Now that this exists, it might be possible to use the nuget package instead of hard-coding the olewoo package and dealing with that 32/64 bit due to the C++ interop.

(It might be better even still to get rid of the dependency altogether but that's a whole
Mathieu Guindon
Mathieu Guindon
03:20
@this yeah it's totally headed that way; the declaration-handling is out already, and module state is its own thing. I think I need to make a diagram and rethink the namespaces, it's quite a piece.
Also I think I messed up the RPC service interface, the way I have it the server side only exists for storage, but I think ultimately we'll want parsing to run completely out-of-process, so the interface should be very simple, like void EnqueueParseRequest(ParseRequest) -- and then comms go two-way and the server pushes a notification to the client as the request progresses... hmm..
ParseRequest gets the protobuf attributes, and then it can include a QualifiedModuleName, I'd guess... worst-case it just needs a DTO with more protobuf attributes.
definitely going for server-side if I can
 
2 hours later…
Duga
Duga
05:09
[rubberduck-vba/Rubberduck] pflugs30 created comment on issue #5961: Building RD fails on olewoo
> You are right - I'm using VS 2022 64-bit:
<details>
<summary>VS System Info</summary>

### Screenshot
![image](https://user-images.githubusercontent.com/4409272/209905801-68011976-dec7-40fa-8dce-04e03f9c2612.png)

### All Info
```
Microsoft Visual Studio Community 2022
Version 17.4.3
VisualStudio.17.Release/17.4.3+33205.214
Microsoft .NET Framework
Version 4.8.09032

Installed Version: Community

ADL Tools Service Provider 1.0
This package contains services used by Data L
[rubberduck-vba/Rubberduck] pflugs30 edited comment on issue #5961: Building RD fails on olewoo
> You are right - I'm using VS 2022 64-bit:
<details>
<summary>VS System Info</summary>

### Screenshot
![image](https://user-images.githubusercontent.com/4409272/209905801-68011976-dec7-40fa-8dce-04e03f9c2612.png)

### All Info
```
Microsoft Visual Studio Community 2022
Version 17.4.3
VisualStudio.17.Release/17.4.3+33205.214
Microsoft .NET Framework
Version 4.8.09032

Installed Version: Community

ADL Tools Service Provider 1.0
This package contains services used by Data L
 
2 hours later…
Duga
Duga
06:45
[rubberduck-vba/Rubberduck] bclothier created comment on issue #5961: Building RD fails on olewoo
> Indeed, I stand corrected. I thought they had made a nuget package but apparently it never got finished. :(

Just to quickly jerry-rig and verify this is the culprit, can you try and replace the olewoo's DLL with the 64-bit counterparts?
[olewoo x64.zip](https://github.com/rubberduck-vba/Rubberduck/files/10317982/olewoo.x64.zip)

If you can confirm this works, we can look at a more permanent solution to handle both 32-bit and 64-bit VS since the VS build task needs to link to it to run t
 
2 hours later…
Greedo
Greedo
08:56
@this ah apologies, added now
@this ah ok so you are doing neither test discovery nor executing private methods with ITypeInfo at the moment. Yes implementing the TLI interfaces is I think where I must've broken my code part way. Really hard to debug tB at the moment I'm just using logging but that only gets you so far. I'm sure I'll figure it out eventually. I'm assuming it's possible to use the same technique from a DLL because it gets all the same privileges over poking around memory as it's parent VBA process
 
1 hour later…
M.Doerner
M.Doerner
10:13
@MathieuGuindon If we move parsing, and probably also resolving, out of process, we might as well look into implementing the language server protocol, with some extensions for stuff we extract from the VBE.
Unfortunately, we cannot just use the nuget package with the base implementation because of in compatibles licenses.
Duga
Duga
10:36
[rubberduck-vba/Rubberduck] dshortway starred us
2
 
3 hours later…
Greedo
Greedo
13:14
I've looked into LSP a little. It's really not too complicated. The summary: dev tool (RDE) + language servers (RD inspections+analysis) are 1 to many relationship. 1 tool can use several servers. The protocol is between 2 processes and the inter process communication is unspecified. Some typical ones I see are TCP+Rest API, Websockets, Stdio pipes. But even HTTP or COM are allowed. The important thing is the tool is responsible for initialising and controlling the lifetime of the server...
... The LSP protocol defines messages like initialisation, sync, changes etc. between the server and the Dev tool. These messages are nothing more than specific JSON structures which are all a subset of JSON RPC (so have a method name + some parameters)
JSON RPC 2.0 is pretty simple and you can read the entire specification in 20 minutes jsonrpc.org/specification
 
1 hour later…
Duga
Duga
14:22
[rubberduck-vba/Rubberduck] Vogel612 created comment on issue #5961: Building RD fails on olewoo
> The build is not actually performed by VS, so the bitness of VS shouldn't matter at all. The relevant bitness is that of MSBuild. There might be a win here by explicitly specifying the `PlatformTarget` of the meta projects to x86, which would trigger 32-bit linking semantics.

We currently only specify `AnyCPU` for the Main project and the Test project. Since the meta projects are separate from that we should be able to target that to 32-bit without issue.
Duga
Duga
14:43
[rubberduck-vba/Rubberduck] pflugs30 created comment on issue #5961: Building RD fails on olewoo
> Thanks for the note, @bclothier. I spent some time last night exploring the Olewoo project and even managed to get it to build after installing numerous tools and extensions. A fun exercise!

I downloaded the zipped file you sent in your comment and used the contents to update the files in `(root)\Rubberduck\Rubberduck.Deployment.Build\OleWoo`. I then opened and built `RubberduckMeta.sln` successfully, and then I attempted to build `Rubberduck.sln`. I then ran into a new error:
![image]
 
1 hour later…
M.Doerner
M.Doerner
16:01
I think if we implemented the LSP the upshot would be that there is already a sensible base protocol and that one could potentially even use the LS with a vscode client, albeit without the features driven by the stuff we pull directly from the VBE.
Duga
Duga
[rubberduck-vba/Rubberduck] bclothier created comment on issue #5961: Building RD fails on olewoo
> TBH, I'd love to get rid of the Olewoo dependency. As you see, it's a pain to build because of all that C++ stuff involved.

> Since the meta projects are separate from that we should be able to target that to 32-bit without issue.

The meta solution has 3 projects; I do not think the 2 projects can be changed (e.g. the code analysis stuff which I assume get hosted by the VS and thus must match in bitness). I'm not confident whether changing the `Deployment.Build` project only to be 32-bi
 
3 hours later…
Duga
Duga
19:19
> - Updated `TargetFramework` in `RubberduckBaseProject.csproj` from `net461` to `net462` since 4.6.2 is the latest supported 4.6 version.
- Updated `TargetFramework` in `RubberduckBaseMetaProject.csproj` from `net46` to `net462` since 4.6.2 is the latest supported 4.6 version.
- Updated `RubberduckPostBuildTask.NetToolsDir` in `Rubberduck.Deployment.csproj` to point to `NETFX 4.6.2 Tools`.
- Converted the `stdole` reference in both the `Rubberduck.VBEditor` and `Rubberduck.VBEditor.VBA` proj
[rubberduck-vba/Rubberduck] build for commit 67a443b8 on unknown branch: AppVeyor build failed
BUILD FAILURE!
Mathieu Guindon
Mathieu Guindon
@Duga ah, that's probably the token again
Duga
Duga
[rubberduck-vba/Rubberduck] pflugs30 created comment on issue #5961: Building RD fails on olewoo
> Reference #6063. I updated the Olewoo dependencies to the 64-bit versions provided by @bclothier, and the solution built as expected. I created the pull request more to continue the conversation than to initiate the change. I think there are more changes we could make with regards to migrating to NuGet packages rather than embedded references.

At this point, I would like to further contribute to the project. I'm using RD extensively in a legacy Access app I'm maintaining, so I have a ve
 
3 hours later…
Duga
Duga
21:59
[rubberduck-vba/Rubberduck] pflugs30 synchronized pull request #6063: Fixing various build issues in VS2022 (64-bit)
[rubberduck-vba/Rubberduck] build for commit 1c8e6219 on unknown branch: AppVeyor build failed
BUILD FAILURE!
[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)
> The AppVeyor token expired a few days ago, I think that's why it's failing. I'll restart the build for this PR once it's updated. Thanks!
[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)
> Ok no it's something else (see AppVeyor build details), ... I'm still updating that token though.
Mathieu Guindon
Mathieu Guindon
Ugh, switched accounts too early
Duga
Duga
[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)
> Yes, I think we have a build error due to the x86 / x64 versions of olewoo.dll tested in this PR. I will see if I can include both DLL versions and use them conditionally.
[rubberduck-vba/Rubberduck] retailcoder created branch retailcoder-patch-1
[rubberduck-vba/Rubberduck] web-flow pushed commit 09aef0d9 to retailcoder-patch-1: Update AppVeyor token
> null
[rubberduck-vba/Rubberduck] retailcoder created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)
> Hm, I wonder if it would be possible to target 4.8 now 🤔
Duga
Duga
22:43
[rubberduck-vba/Rubberduck] build for commit 09aef0d9 on retailcoder-patch-1: AppVeyor build succeeded
Duga
Duga
23:08
[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created comment on pull request #6064: Update AppVeyor token
> :white_check_mark: Build Rubberduck 2.5.2.6213 completed (commit github.com/rubberduck-vba/Rubberduck/commit/27927f8352 by @retailcoder)
[rubberduck-vba/Rubberduck] build for commit 09aef0d9 on retailcoder-patch-1: AppVeyor build succeeded
[rubberduck-vba/Rubberduck] codecov[bot] created comment on pull request #6064: Update AppVeyor token
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/6064?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=rubberduck-vba) Report
> Merging [#6064](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/6064?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=rubberduck-vba) (09aef0d) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/92a0bff7893298e0a2d15194
[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)
> The build fails due to this error:
```
C:\projects\rubberduck\Rubberduck.Deployment\Rubberduck.Deployment.csproj(49,5): error MSB4062:
The "RubberduckPreBuildTask" task could not be loaded from the assembly C:\projects\rubberduck\Rubberduck.Deployment\..\Rubberduck.Deployment.Build\bin\Rubberduck.Deployment.Build.dll.
Could not load file or assembly 'olewoo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
The system cannot find the file specified. Con
Duga
Duga
23:29
[rubberduck-vba/Rubberduck] pflugs30 created comment on issue #5961: Building RD fails on olewoo
> > I think we need to conditionally redirect the references based on the bitness of VS.

Would it be easier to simply support VS2022 moving forward? :-) I mean, is there a strong reason not to go that way?
[rubberduck-vba/Rubberduck] pflugs30 edited comment on issue #5961: Building RD fails on olewoo
> I get this error when building a fresh pull of RD next branch in VS2022 **with** an MSOffice installation. I've also been able to implement all the changes found in PR #5982 on my local machine (since the PR isn't yet merged). However, I can't get past this 'olewoo' error. Here's my version:

> The "RubberduckPreBuildTask" task could not be loaded from the assembly **C:\dev\personal\Rubberduck\Rubberduck.Deployment\..\Rubberduck.Deployment.Build\bin\Rubberduck.Deployment.Build.dll**. Coul
[rubberduck-vba/Rubberduck] codecov[bot] edited comment on pull request #6064: Update AppVeyor token
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/6064?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=rubberduck-vba) Report
> Merging [#6064](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/6064?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=rubberduck-vba) (09aef0d) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/92a0bff7893298e0a2d15194
[rubberduck-vba/Rubberduck] pflugs30 synchronized pull request #6063: Fixing various build issues in VS2022 (64-bit)
[rubberduck-vba/Rubberduck] build for commit c74b79b5 on unknown branch: AppVeyor build failed
BUILD FAILURE!
[rubberduck-vba/Rubberduck] retailcoder pushed 1 commit to next
[rubberduck-vba/Rubberduck] web-flow pushed commit 095fa86b to next
Merge pull request #6064 from rubberduck-vba/retailcoder-patch-1

Update AppVeyor token
[rubberduck-vba/Rubberduck] build for commit 09aef0d9 on next: 97.34% (target 0.00%)
Duga
Duga
23:53
[rubberduck-vba/Rubberduck] 1690 stars vs. [decalage2/oletools] 2295 stars

« first day (3128 days earlier)      last day (52 days later) »