« first day (1486 days earlier)      last day (1694 days later) » 

Duga
Duga
12:01 AM
RELOAD!
[FreezePhoenix/XtraUtils] 1 commit. 26 additions.
[Hosch250/CheckersWebsite] 2 commits. 34 additions. 31 deletions.
[rubberduck-vba/Rubberduck] 1 opened issue. 1 closed issue. 1 issue comment.
 
 
2 hours later…
ThunderFrame
ThunderFrame
1:37 AM
@mansellan wait, so GetStdModAccessor allows VB6 to have an arbitrary entry point in VB6? That's amazing. We need to add details to the wiki about how to implement testing in VB6. That said, having tests in a separate project is probably better practise, but that shouldn't stop Wayne's approach from working. I'll see if I can get both approaches working.
 
 
3 hours later…
ThunderFrame
ThunderFrame
4:14 AM
@mansellan Would any of the existing clipboard formats be suitable for export? The Copy button puts CSV, SpreadsheetML, RTF and an HTML snippet onto the clipboard. All of those could be exported to disk, although the HTML snippet would need its snippet header removed.
 
 
3 hours later…
Duga
Duga
7:09 AM
> Unit Test and Code Inspection windows works on new laptop with Rubberduck ver 2 green release, breaks with latest release - unable to go back to earlier release to get working unit test window.

What not working looks like is probably best explained with an image:
<img width="960" alt="2018-07-01" src="https://user-images.githubusercontent.com/9349975/42131869-57c3d42c-7d4f-11e8-94f6-c6dd20bb4c26.png">

When test explorer is opened the 2 windows shown in the above image overlap with the b
 
 
2 hours later…
mansellan
mansellan
8:45 AM
@ThunderFrame tbh idk, I've never set up CI for unit tests, its always been already there at the places I've worked.
 
Duga
Duga
9:05 AM
> This pull request is incomplete. Can someone give a quick review and tell me if the way I'm going is OK? I tried fixing the issue but more and more issues are coming up. Here are a few questions/issues: * Bug: Redim variables are resolved as e.g. procedures if the procedure has the same name as the redim variable that should be implicitly created
* Bug: The simple name expression has a wrong classification because of this:...
https://github.com/rubberduck-vba/Rubberduck/blob/bd4a92e4371095dcc90bfd3bb2f7e6ac3ea06855/Rubberduck.Parsing/Symbols/DeclarationFinder.cs#L701 I've tried adding a result variable declaration instead for functions and properties. Is that OK? * Should we create a VariableDeclaration and RedimVariableDeclaration and ResultVariableDeclaration?
* I've added an inspection that introduces a local variable if there is none for redim variables. I think that is what retailcoder was thinking about?
 
ThunderFrame
ThunderFrame
9:17 AM
@mansellan sure, there's undoubtedly some work there, but the report writing is largely done.
 
Duga
Duga
[rubberduck-vba/Rubberduck] build for commit 37c6fc8b on unknown branch: AppVeyor build failed
BUILD FAILURE!
 
mansellan
mansellan
9:38 AM
@ThunderFrame RD is gonna be a game-changer for anyone still writing VB6 :-)
5
 
Duga
Duga
> Could you try unchecking these two windows in the Settings under "open on Startup" and restart you office host? Also is there anything in the logs?
 
ThunderFrame
ThunderFrame
9:53 AM
@mansellan agreed, but the VB6 projects in my company have been stable for so long that nobody has VB6 installed. If they did ever need work, I think they'd sooner invest in migrating to C#, rather than adding tests and building out CI in VB6. But given how many VB6 users there are, I'm sure there are plenty of places that would take the time.
 
 
7 hours later…
IvenBach
IvenBach
4:50 PM
@MathieuGuindon when you get your Turing tumble GoTo Pg93. There’s an Easter egg you’ll immediately spot.
 
Vogel612
Vogel612
hmm ... this is proving a little annoying :/
 
this
this
I apologize for being a little annoying, @Vogel612.
 
Vogel612
Vogel612
gee ....
 
this
this
;)
 
Vogel612
Vogel612
basically any message in this chatroom containing "this" should be rejected with an "ambiguous reference error"
well ... I got it back to building, now to commit the groundwork and then make it work again
no failed tests yet...
1.9k tests to go
we'll pass 3k tests soon
1k to go, still green
all green ... this is a bad sign
 
this
this
5:06 PM
if you think it's bad, then you need more tests, no?
 
Vogel612
Vogel612
well... yes and no
for now I want to be able to shuffle the design around a bit
the less tests I break there, the easier it is for me.
but yea, that will need some tests...
 
Duga
Duga
> In line with #3862 this PR is splitting the UnitTesting functionality into a separate project,

This will include a minor overhaul on the design of the TestEngine and classes that depend on it. Note that the current code **can not be working**, yet all Unit-Tests seem to pass. This indicates that a few more unit-tests need to be written...
 
Vogel612
Vogel612
welp ... Modularization is on page 5 of open issues...
we have 707 open issues...
I bet a few of them are outdated :/
 
this
this
yes, I'm sure they are - I even found one support issue that was meant to e closed but never was
I intend to go through some and clean up
 
Vogel612
Vogel612
you should have privileges, IIRC
 
this
this
5:17 PM
yes just want to finish this stuff w/ the refactoring ioc first before I switch gears
 
Vogel612
Vogel612
sounds great
how's extract method coming along?
 
this
this
RE: your PR - there's the busy state PR that will conflict, I think. will that matter?
 
Vogel612
Vogel612
no, I'll just rebase my stuff on top
 
this
this
EM can't start until I get the refactoring dialog refactor done because my refactored EM is based on the similar refactoring
so I'd like to get the refactor for the dialogs merged so that EM has a stable base to go forward
keeping it in sync w/ the next has became increasingly problematic exactly because of that.
 
Vogel612
Vogel612
rebase is pretty helpful for dealing with a moving upstream IME
but YMMV (by quite a lot even)
 
this
this
5:20 PM
definitely need to learn how to do that when I get EM branch started up. I know there are tons of conflicts right now
and i really don't need to reoslve them - i only need to move the new stuff over, and re-integrate it
 
Vogel612
Vogel612
if you just want to move stuff over, rebase is probably the wrong tool ...
rebase tries to preserve the history of the branch you move
you could just soft-reset to the state of your EM refactoring and hunt compiler errors.
that might be quite a bit faster
 
this
this
soft-reset means I can move the head to the next but keep my working tree?
 
Vogel612
Vogel612
yeap
 
this
this
yes, prolly for the best
fortunately, most of my changes were new files
 
this
this
6:24 PM
i don't get why CW won't activate the types I want. It works in the build (e.g. I can get the dialogs just fine) but the mocked IoC just can't resolve it.
and the search for the errors is...sparse and possibly unrelated.
 
Vogel612
Vogel612
6:38 PM
wow...
ummm ... I can't even use the VBE with RD loaded right now...
LibTypeNotRegistered and RCWDisposalRace flying all over
 
M.Doerner
M.Doerner
6:57 PM
Did you try to register an auto-magic factory for anything COM related?
Never do that.
 
Vogel612
Vogel612
nope, I didn't.
I didn't touch IoC code at all yet.
I just dropped some IVBEs from Ctors
everything else was just moving stuff around a bit
 
M.Doerner
M.Doerner
Regarding the not registered thing, your probably broke some registration there.
Did you move something into a new project?
 
Vogel612
Vogel612
yea
I do get the not registered thing when starting from next as well, though, so there's that
welp ... repro'd on [next]
 
Duga
Duga
7:28 PM
> The root cause for this is the fact that the parse-tree listener does not recognize the end of the ModuleDeclarations section correctly and considers the first annotation on a member to belong to the module declarations.

That is because annotations are considered "EndOfLine" statements by the parser. This leads to the unfortunate side-effect that (unless you declare a module attribute), we do not correctly interpret the Annotation as inside a moduleBody, but before it, which results in this
> The root cause for this is the fact that the parse-tree listener does not recognize the end of the ModuleDeclarations section correctly and considers the annotation on the first body element to belong to the module declarations.

That is because annotations are considered "EndOfLine" statements by the parser. This leads to the unfortunate side-effect that (unless you declare a module attribute), we do not correctly interpret the Annotation as inside a moduleBody, but before it, which results
 
Duga
Duga
7:39 PM
> Actually we already have code taking care of that false-positive. Unfortunately that code is not correctly prepared. We're not correctly resetting the Contexts of ParseTreeListeners between every module
 
Duga
Duga
8:05 PM
> Another time I am rather grateful for the extensive test-suite we have... I did some nonsense and the tests called me out on it. The actual solution was to reset the flag that takes care of this when entering a module, not by resetting the contexts between modules (which drops inspection results).

A fix is coming up (awaiting passing unit-tests and a review)
 
Duga
Duga
8:20 PM
[rubberduck-vba/Rubberduck] build for commit 3cde5a3b on unknown branch: AppVeyor build succeeded
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4147?src=pr&el=h1) Report
> Merging [#4147](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4147?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/bd4a92e4371095dcc90bfd3bb2f7e6ac3ea06855?src=pr&el=desc) will **increase** coverage by `<.01%`.
> The diff coverage is `100%`.


```diff
@@ Coverage Diff @@
## next #4147 +/- ##
=========================
[rubberduck-vba/Rubberduck] build for commit 3cde5a3b on unknown branch: 52.44% (target 0%)
 

« first day (1486 days earlier)      last day (1694 days later) »