« first day (1904 days earlier)      last day (24 days later) » 
00:00 - 14:0014:00 - 00:00

12:01 AM
RELOAD!
[Phrancis/TwitterTools] 1 commit. 7 additions. 8 deletions.
[rubberduck-vba/Rubberduck] 1 opened issue. 9 issue comments.
[Minesweeper] Games Played: 59, Bombs Used: 41, Moves Performed: 8237, New Users: 12
 
@mansellan at least you weren't a grandpa at age 32. My old man had a friend growing up that had a kid a daughter at 16 who also had a daughter when he was 16. 32 years old and everyone calling him gramps.
@mansellan That is a textbook case of 'Dick-move' right there.
@23fc9a62-56de-47fb-97b4-737890 I derped pretty hard last night. Had the overriding method on the wrong class. :cringe:
Even for me that's a new level of :derp:.
 
@IvenBach Uhm, technically I was a grandpa at 20 depending on how you trace it through.
@IvenBach Yep, totally. And I still had to fight social services to adopt my daughter, because her biological father had to be contacted and decided to object.
Oh wait, there's no technically about it. I was a grandpa at 20. OK, definitely feel old now.
But if you count grandchildren as "your children's children" (not including step-children), then I'm still waiting. Yay!
 
I may have finally hit the RubberduckTests assembly with the compilation issues...
~sigh
Why do I put myself through crap like that again?
 
@mansellan i guess abandoning them wasn't enough of an asshole move for him....
 
It seems not. Assholes gonna ass, I guess...
 
12:15 AM
@Vogel612 to clarify - is that for avoiding parsing from rebuilding? A bit curious there...
 
@this no, it's for killing the AnnotationType enum
 
ok
 
I really want a way to specify that a type inherits static members...
it's really rather annoying right now to not have a way to do that in C#
 
yeah it never ends well
 
do elaborate?
 
12:21 AM
from my past experience, trying to mix static members on instances usually cause more pain, especially if you need to expose it
 
not sure what exactly you mean, but. ...
 
I'm more inclined to think that it's generally less painful to be static all the way or be instance all the way.
 
I'm trying to find a useful way to deal with annotation information that's static without losing the fact that annotation instances are tied to specific parser contexts
 
right now, you want to set up type hierarchy but you want to use static members and somehow inherit. That's the painful part about mixing statics in instances.
 
then again I've not looked deeply into whether that correlation is actually useful
 
12:23 AM
ok, why do we actually care about parser contexts?
 
@this I'm reasonably sure that it's required for rewriting purposes
but I haven't actually checked...
 
right, but you can just have it as a member on the class, just like Declaration does
 
even if not, we still need to have some instance state for annotation arguments
@this yea, that's where it currently is...
the problem is that I need to have a static way to access the "Name" of an annotation
what used to be the AnnotationType's declared name for the enum constant
 
can't you use nameof()?
 
nameof is locally scoped
so it'd return the name of the variable.
also I dislike matching up the user-facing name of the annotations with it's type name
 
12:26 AM
why not borrow from Inspection's spproach?
 
because we don't need localization
annotations are not localized and never should be
also inspection names are not required to be available to a static context
ugh... AnnotationTests. ...
crap this is going to be a pain .
 
why does annotation names need to be static?
 
because Parsing
you need to be able to resolve the specific type of an annotation from it's name before you can construct it
 
I have something similar in a project at work
 
Attributes parsing pass makes the thing even more complicated, because you need to resolve an annotation type from the attribute it belongs to
 
12:35 AM
Got a public const (static) and I basically wrapped it with an interface
So the types all have a public const for static access
And the interface implementation just returns the const value
 
so that's additional information that needs to be statically accessible for some kinds of annotations
also my internet is throwing a fit...
 
string IAnnotation.Name { get; } => Name;
^ something like that
where Name is const/static
feels weird though
 
yea, that's a good start, but doesn't give us any actual enforcement for the static members on inheriting types.
not that my current approach does that either, so there's that
 
ya well you can't have that ;-)
 
maybe we actually are looking for an attribute?
 
12:39 AM
Hm
 
@this that's my current approach...
 
attributes do get inherited... and they're static-ish
 
@MathieuGuindon that doesn't help, because we want to need to specify the annotation's "user-facing name" for each separate annotation separately
[Annotation("Folder", AnnotationTarget.Module)]
public sealed class FolderAnnotation : AnnotationBase
 
I do like the look of this... what's wrong with it?
 
retrieval is annoying
also requires that too many things know about how annotations work
previously when the static information was required, an AnnotationType was passed around
 
12:42 AM
right
 
that was augmented with an Attribute for the AttributeAnnotations
but the mapping between these AnnotationTypes and the actual type we instantiated in the parsing process was manual
see VBAParserAnnotationFactory's ctor for how
 
maybe I'm missing obvious but the retrieval can be delegated to an abstract base class and then exposed as a static member?
 
@this static members are not inherited
 
true but does it see all the attributes in the inheriting clases?
 
also... nope, because the static belongs to the baseclass
therefore there is only one value for the baseclass, which means that we can't store the information of multiple inheriting classes in the baseclass
that's not how statics work
 
12:46 AM
no, but the attributes are on the types and at runtime reflection, you see the final type
so event hough you're calling a static member on the base, the reflection will show the final type and its attributes.... I think.
 
ohhhh...
 
verify what I said, though, I might be wrong but in my exp, reflection is always on final type
 
it's so close
 
and attributes means you are reflecting.
 
what you're proposing is basically an extension method that's tacked onto a specific part of the type hierarchy
but I'm pretty sure it won't work, because you still need to somehow get the type you're looking at to the basetype.
if it's a static member of the basetype, that means it can't access GetType() (which would return the runtime type), but if you can't take advantage of that, you may as well have an extension method that takes any Type and does the magicking
 
12:54 AM
@this I think that's correct
 
Wow, I feel dumber than a guy trying to write an ampersand on a whiteboard. When you get talking about rhis stuff, I realise how much I don't know about computer science.
 
protected AnnotationInfo GetInfo<T>(T t) where T : IAnnotation
?
base.GetInfo(this)
 
the argument is an instance here.
the hard part is not getting the static information accessible in the instance
 
smells fishy though
 
the hard part is enforcing that the static information is actually there in the first place without it stinking to the heavens
 
12:59 AM
@IvenBach take note - everyone is learning. It's ongoing.
 
^^
 
soo ... I just replaced around 20 test methods with testcases...
but hey, they still don't cover all annotations
 
@mansellan Feels like I'm starting from the back of the bus though.
Back of the short but to be accurate.
 
1:08 AM
@IvenBach Oh, it always feel like that. Welcome to the club, push through it. You're doing great.
:-)
#ImposterSyndrome
 
obtw: AFAICT '@Ignore and '@IgnoreModule are the only annotations that we allow multiple times
 
^^ I feel that all the time.
 
which seems ... not quite right?
 
hmm interesting. Consider this VBA code:
Dim f As Scripting.FileSystemObject
Dim ds As Scripting.Drives
Dim d As Scripting.Drive

Set f = New Scripting.FileSystemObject
Set ds = f.Drives
Set d = ds.Item("C")
 
considers
;-)
 
1:11 AM
~ponders
 
now here's the equivalent C#:
var fso = new Scripting.FileSystemObject();
var drives = fso.Drives;
var drive = drives["C"];
Item simply doesn't exist in C#
 
So... at a high level, that's because C# has indexers and VBA doesn't, no?
 
so how does one refer to Item ?
VBA can do ds("C"), too
 
@this why would you need Item?
 
simply that ds.Item("C") is the fully expanded form.
if you want to mock the drives & drive, you need to know how to mock that property.
 
1:13 AM
@this yeah, because default members. but that's a diiferent thing?
 
Yes
 
but you're not mocking the C# types, are you?
 
No, but I do need to build a legal expression tree on the mocked type
 
the Item member needs to exist somewhere on the COM type, otherwise you couldn't mark it as VB_UserMemId = -4
 
it's failing because i'm doing the equivalent of mock.Setup(x => x.Item).Returns(...)
 
1:16 AM
if that's a problem, how are you going to mock drives.[_Default]("C")?
 
yes I think that's the answer I need to answer
 
wait, is the Items collection not just the enumerator provided by the Drives class?
Bear in mind, I may be talking gibberish...
 
apparently it's not accessible by name on the managed side
 
^
 
bah
 
1:21 AM
they are providing a different representation of the enumerations
 
the fact that it is the enumerator allows for the drives["C"] access
 
which means I need to handle the members that's an enumerator separately from other methods.
that makes me happy now I know what the problem is
more work but better than banging my head on a brick wall
 
yea and Default also need specific handling, but that's somewhat unsurprising.
 
default? you meant default member access?
 
yea
should've been more clear
 
1:26 AM
ugh, VS, why must u be a turd?
@Vogel612 TBH, for this version, the expectation is that they will have to enumerate the each member they want to mock, including the defaults
 
yea, that is very much reasonable
 
I'm not going to do it magically. The VBA testing code can do it implicitly but the setup has to be explicit
 
I'm pretty sure one couldn't set mocks up automagically anyways
 
ok great! this is what I want:
            var mock = new Mock<Scripting.Drives>();
            var mock2 = new Mock<Scripting.Drive>();
            mock2.Setup(x => x.Path).Returns("abc");
            mock.Setup(m => m["m"]).Returns(mock2.Object);

            Assert.AreEqual("abc", mock.Object["m"].Path);
I think I might just have Item be swallowed and converted into an indexer.... this is the original failing mock setup:
var provider = new MockProvider();
var mockFso = provider.Mock("Scripting.FileSystemObject");
var mockDrives = mockFso.SetupChildMock("Drives");
var mockDrive = mockDrives.SetupChildMock("Item",  provider.It.Is("abc"));
mockDrive.SetupWithReturns("Path", "foobar");
var obj = mockFso.Object;
 
@Vogel612 depends.. user code gets to decide if they want one, two, three, or all @Ignore annotation arguments on one line, or if they want to separate each inspection type say, to allow the space for adding a separate justificative comment for each one?
 
1:30 AM
why do we not allow multiple Member/ModuleAttribute annotations then?
 
because VBA wouldn't allow them?
 
ahh, the feared domain knowledge
what about "stupid" annotations like this?
 
hm, that should probably be documented
 
'@MemberAttribute "VB_UserMemId", "-4"
'@MemberAttribute "VB_Description", "foo"
Sub Foo_Bar()

End Sub
 
Huh that should be allowed
 
1:34 AM
pretty sure it isn't but don't have the time or patience to verify right now
 
?propertyInfo.Name
"Item"
so yes it does exist. Just not accessible to C# programmers.
 
I think I saw the duplicate annotation inspection check for the annotation type only to determine whether it was acceptable
@this what the ...
does that imply the IDL handling in C# hides enumerator members?
 
beats me. but reflection has to describe the indexer somehow.
 
yea, that's operator []
 
let me verify that I can get that method....
 
1:38 AM
this[]
 
current build gives me 1.4k warnings...
I dimly recall wanting to do something against those somewhen
I also added a handful of FIXME and TODO comments while ripping out AnnotationType
 
doesn't look like
member.Key.GetMembers()[0].Name
"get_Item"
member.Key.GetMembers()[1].Name
"get_Count"
member.Key.GetMembers()[2].Name
"GetEnumerator"
member.Key.GetMembers()[3].Name
"Item"
member.Key.GetMembers()[4].Name
"Count"
(won't let me enumerate it so did it manually)
Interesting.
dispinterface IDriveCollection {
    properties:
    methods:
        [id(00000000), propget, helpstring("Get drive"), helpcontext(0x00214b3a)]
        IDrive* Item([in] VARIANT Key);
        [id(0xfffffffc), propget, restricted, hidden]
        IUnknown* _NewEnum();
        [id(0x00000001), propget, helpstring("Number of drives"), helpcontext(0x00214b39)]
        long Count();
};
pretty sure the _NewEnum() maps to GetEnumerator(), while Item maps to.... a black hole, I guess....
 
what about the Methods?
 
[this]( youtube.com/watch?v=hwfnHA1DprI) is why I need to buy an Occulus Rift.
 
@Vogel612 those are the first 3 items I enumerated
the last 2 are properties
 
1:48 AM
hmm ...
 
the only special thing i have to go on is the fact that Item is also the default member
but I don't think that's enough to extrapolate that it will be an indexer in C#
going to ask Moq guys
 
VS is being weird and started swallowing errors from the build output
 
that happened to me the other day.
I had to restart VS after few iterations of tests
 
well, I'm still fixing compilation errors and I can navigate to them from the output just as well, soo ...
imma use that.
and if VS crashes on me, I'll go to sleep
'cause that's actually reasonable at 4AM
if the tests actually run, then I'll probably also head to bed :D
 
lol. I have to step away anyway. Good night!
 
1:55 AM
gn!
 
77 files changed, 509 insertions(+), 683 deletions(-)
... yea, that seems reasonable :)
tests are very much red, but at least the thing compiles.
good enough for today. Night :)
 
2:11 AM
'night!
 
interesting
 
2:43 AM
> Rubberduck.CodeAnalysis.xml is a build artifact, shouldn't be under SC.
[rubberduck-vba/Rubberduck] retailcoder pushed commit 13cffc4e to next: ignore the xmldoc export
Merge pull request #5102 from retailcoder/next

ignore the xmldoc export
[rubberduck-vba/Rubberduck] build for commit 13cffc4e on next: AppVeyor build cancelled
BUILD FAILURE!
[rubberduck-vba/Rubberduck] web-flow pushed commit d1cb84ab to next: Delete Rubberduck.CodeAnalysis.xml
[rubberduck-vba/Rubberduck] build for commit d1cb84ab on next: AppVeyor build cancelled
BUILD FAILURE!
[rubberduck-vba/Rubberduck] build for commit 1e8be743 on next: AppVeyor build succeeded
 
3:22 AM
@this does the example trigger your inner #PedanticPete? Hard to code properly when the examples start by leading you astray.
 
@IvenBach I’m late to your message pardon me sir! I’ll say I trust the inner coder that a solution will arise! :)
@IvenBach especially if my brain doesn’t match the possible reality
 
Because of this pond I know it should be a bit wise Or and not +.
 
@IvenBach it can be +, if 1 + 1 = 1
;-)
    101100010
    110001011
 Or 111101011
 
4:03 AM
@this the ComCommand PR looks good to me. If Max is ok with it, I say let's merge this baby!
AC/SCP with parameter quickinfo will be awesome, too!
 
4:15 AM
[rubberduck-vba/Rubberduck] web-flow pushed commit 06f5fb3d to moq-attrib: Update Attributions.md
Merge pull request #5103 from rubberduck-vba/moq-attrib

Update Attributions.md
 
4:57 AM
> Fixes the "add missing attribute" quickfix (double quotes were missing around the value).

The quickfix to "add missing annotation" can't deal with the "\n" in "T\n14" right now, so getting the annotation from the attribute is broken ATM.
 
@Duga wait a minute, it shouldn't be dealing with the "\n" anyway... the annotation just wants the "T"
 
@MathieuGuindon Works since the bits don't overlap.
Although it'd be an odd bitflag if things did overlap.
 
[rubberduck-vba/Rubberduck] build for commit 1dec1e34 on unknown branch: AppVeyor build succeeded
 
5:19 AM
> I'm an idiot
 
Wasn’t the idiot post parade earlier today?
 
[rubberduck-vba/Rubberduck] build for commit b8a37a3c on unknown branch: AppVeyor build failed
BUILD FAILURE!
 
@IvenBach whisles
hmm, does @ExcelHotkey A really makes sense? Shouldn't it be @ExcelHotkey "A"?
 
5:51 AM
[rubberduck-vba/Rubberduck] build for commit 0a09d07a on unknown branch: AppVeyor build succeeded
[rubberduck-vba/Rubberduck] retailcoder pushed commit 1dec1e34 to next: hotfix for ExcelHotkey annotation; quickfix for MissingMemberAnnotation is broken for this annotation though, presumably because of the "\n" in the attribute value.
[rubberduck-vba/Rubberduck] retailcoder pushed commit b8a37a3c to next: account for double quotes
[rubberduck-vba/Rubberduck] retailcoder pushed commit bdca75aa to next: fixed broken test (added the expected quotes)
[rubberduck-vba/Rubberduck] retailcoder pushed commit 0a09d07a to next: added quotes around annotation value
Merge pull request #5104 from retailcoder/next

hotfix for ExcelHotkey annotation
 
6:21 AM
The latter makes more sense. Would it be clearer with @ExcelHotkey(A)?
 
6:52 AM
@all interesting food for thought as per CodeProject
Suzdalnitski argues. Object-oriented programs instead end up with variables and their mutable states “shared promiscuously between various objects.”

“In most cases, OOP programs turn out to be one big blob of global state, [which] can be mutated by anyone and anything without restrictions,” he tells me in an email.

Suzdalnitski also believes that object-oriented code is harder to refactor and harder to unit test, and his essay builds up to a bold pronouncement that “It is impossible to write good and maintainable object-oriented code…”
 
@PeterMTaylor There's OOP and good OOP. A lot of OOP I see is "OOP for the sake of OOP" (bad OOP).
It being easy to write bad OOP doesn't mean it's impossible to write good OOP.
He's making a leap there without basis.
 
True and we did start this journey didn’t we pond
 
Besides, claming something is dangerous is easy. Where's the article where he suggests a viable alternative?
FP has its own pitfalls and problems.
 
Eyup as I learnt that much from hooch
 
What's the preferred paradigm in VBA anyway? Before you know it, you have more functions than are good for you.
 
7:05 AM
no personal preference for me yet so I say anything goes and yes in the end good mature functionality works
 
 
2 hours later…
8:41 AM
 
@Vogel612 For which purpose do you require static access to the annotation names?
Would it be sufficient for the annotation factory to know the mapping name to type?
Hm, I had an idea about how to inject the mapping there, but that will probably not really work because some annotations require valid values.
My idea was to inject IEnumerable<IAnnotation>, and have a new AnnotationName property on IAnnotation.
Then, we could generate the mapping from the injected annotations.
However, any annotation requiring valid arguments will require special setup in the IoC container.
 
 
1 hour later…
10:40 AM
@M.Doerner I wanted to avoid instantiating them with CW..
also the injection point is currently three or four manual constructor invocations deep, so there's that
 
So, risk of building a house of cards?
 
> Hello,

Thank you very much indeed for having created and for supporting this fanstatic free tool -- I am very grateful to you and all who participated and so generously donated their time and expertise to the creation and maintenance of this tool. I feel a little awkward needing to point that in my case there seems to be a problem with the tool and that I may need your help (and thus detract your attention from whatever more useful and important you might be doing).

Also, I am not sure w
 
welp ... the first paragraph is just fluff...
 
11:17 AM
> Hey, thanks for the kind words.

Here's the timeline for the parsing runs you attached. The first run is the initial parse. All modules are parsed here.

Notably, Inspections are not run here, which means the initial parsing clocks in at about 220 seconds, roughly three and a half minutes (10:25:57 -> 10:29:38)

```
2019-08-23 10:25:57.4501;DEBUG-2.4.1.4627;Rubberduck.Parsing.VBA.ParseCoordinator;Parsing run started. (thread 10).;
2019-08-23 10:25:57.4501;INFO-2.4.1.4627;Rubberduck.Par
> I see that you use the stable last release. Could you try the current prerelease, or one from the last two months?

I recall observing this and analyzing it under a profiler. I think some (partial) fix has been implemented at some point after the last stable release.
> @Vogel612 The stages do not contain the invokation of the event handlers for the state changed events. I think the problem here was/is in the CE refresh.
 
yea, that's probably true
do we want to get these event handlers to a separate thread, then?
 
They are already on a background thread.
 
why are they blocking the parsing run then?
 
The problem was that the CE pushed lots of work explicitly on the UI thread via the UiDispatcher.
Some parts needed to be done there, but it did not try to minimize the work done there.
It should be better in the current prerelease, but I remember that I could not fully get rid of the freeze for some reason.
Btw, the parser also freezes the VBE shortly sometimes.
However, there is little we can do about that because the access to the UI thread is in the interop library.
 
11:36 AM
@M.Doerner Isn't freezing up when busy inherent to Excel?
 
yea, the parser needs that for the COM access.
@Mast no it's not. we're not even in EXCEL in the first place
the problem is that our UI worker doesn't yield control for the event loop to possibly kick in
and it really can't, if my understanding is correct
so if the event loop is not running due to RD doing some heavy lifting on the UI thread it looks like the VBE is completely locked up (because the UI is unresponsive), but we're still doing things in the background
 
@Vogel612 Oh
 
12:03 PM
> I did some digging. The freeze mentioned here has already been observed in issue #4905 and the main sources should have been fixed in the PRs #4918 and #4914.

The main source was that the CE refresh reloaded settings over and over from file because of a bug in the code for loading the settings. This bug prevented the intended caching to happen.

Unfortunately, there has not been a stable release since the fix.
 
12:26 PM
> Hello MDoerner and Vogel612,

Many thanks for the fast response. As advised, I will now try installing the latest availabl release and report on this.

Thanks,
Radio Engineer
 
This is the most in-depth explanation for the behavior I observed yesterday. Unfortunately, this still comes up short in actually explaining how the compiler determine whether a property on a COM type should be made into an indexer.
I see that I could have used the get_XXX but I worry that setting it up will cause more problem since it's a method and I'd have to also setup the set_XXX, which feels more complicated.
For now my working assumption is that if the member is the default member (which I can know that because it'll have DispId attribute set to 0), then I can try to treat it liked an indexer but I am not confident that this assumption is true in all cases.
 
12:44 PM
> Hello MDoerner and Vogel612,

**THE ISSUE IS NOW _RESOLVED_ FOR ME** -- as advised by MDoerner I installed the latest release available at this time (which was Rubberduck v2.4.1.4869-pre) and the problem seems to have disappeared.

This was truely great response from you both -- thank very much indeed for your help and time. Thanks to MDoerner for suggesting to use the latest release, and to Vogel612 for helping with the initial analysis (and for even editing my first post to make it more
> Hello MDoerner and Vogel612,

**THE ISSUE IS NOW _RESOLVED_ FOR ME** -- as advised by MDoerner I installed the latest release available at this time (which was Rubberduck v2.4.1.4869-pre) and the problem seems to have disappeared.

This was truely great response from you both -- thank you very much indeed for your help and time. Thanks to MDoerner for suggesting to use the latest release, and to Vogel612 for helping with the initial analysis (and for even editing my first post to make it m
 
1:41 PM
Private Sub CheckBox1_Click()
If Me.CheckBox1.Value = True Then
    Me.TextBox6.BackColor = &H80000005
    Me.TextBox6.Enabled = True
    Me.CheckBox2.Enabled = True
Else
    Me.TextBox6.Enabled = False
    Me.TextBox6.BackColor = &H80000004
    Me.TextBox6 = ""
    Me.CheckBox2.Value = False
    Me.CheckBox2.Enabled = False
End If

End Sub
shoot me now.
there's like ~20 userforms with code similar to that.
 
@this That's more like dying of radiation poisoning than dying of a gunshot.
Oh, I see why you want to be shot now...
 
:) Yes.
 
1:53 PM
Someone just got a windfall.
David Koch just died.
Let's hope whoever got his businesses don't crash them. I like using toilet paper...
 
00:00 - 14:0014:00 - 00:00

« first day (1904 days earlier)      last day (24 days later) »