« first day (1716 days earlier)      last day (1464 days later) » 
00:00 - 12:0014:00 - 00:00

12:00 AM
@Comintern And? Some of us are still using 2003 :-)
 
RELOAD!
[rubberduck-vba/Rubberduck] 1 opened issue. 1 closed issue. 10 issue comments.
 
@mansellan I tried to load an .adp a couple months ago in Access 2013. It was like, "wut?".
 
yeah that's also the version where they got rid of it for good.
2010 can load it but only to use, not design.
2007 was the last one that supported designing & using it.
 
@Jelly Yep.
 
@Jelly Hmm, I guess it doesn't get zero'd out.
 
12:04 AM
I just recently updated my phone, from a Galaxy Note 3 to a Galaxy Note 4. Because newer phones suck. TFW you realise this kind of thinking is the 2019 version of "modern music is just noise". Damn, I feel old...
 
I lost my British English. I definitely learned the spelling. I don't think I ever speak a proper British English accent to begin with because my Tunisian teacher had a Tunisian accent.
@this Yes.
 
@this I don't know you dude ;-)
 
said the brit to the tea drinker
2
 
rofl!
i despise tea
 
Are you sure you're a brit?
 
12:12 AM
uh, half German, so...
 
lol
 
"Unt nein, Ich nicht sprechen Deutsche" waits for Max or Vogel to tell me all the things that are wrong with that...
 
@this Can you take alook at the code example: docs.microsoft.com/en-us/dotnet/api/…
do you think it is because of this : // Always call Marshal.Release to decrement the reference count.
Marshal.Release(pointer);
 
Oh, I actually used \\ Here be dragons: in a work commit today. Unfortunately, I think my OCD is gonna make me remove the hack before I PR :-(
 
that the it is not zero?
 
12:17 AM
@mansellan Ein bisschen schrecklich?
 
fires up Google Translate
ah, awful. Yes.
 
At least you aren't a jelly doughnut.
 
The only thing I remember from my German lessons is "Der zug es späte". Fitting really, because UK ones always are. German ones, not so much I think...
 
@Jelly Indeed, you do need to release whatever you got from Marshal.
 
Although a Berliner is tastier than an Amerikaner - those things are not my cup of tea.
 
12:21 AM
Hacktually... my HBD was - "Don't change thse explicit enum values, they're used as an array int index elsewhere". How many Hail Marys do I need to do?
 
@MathieuGuindon LOL, I left work, and wasn't even watching this room for a few hours.
 
hehe the timing was just perfect though =)
 
@Comintern heh, I see what you did there... "Elevator" is understandable, but "trunk"? No less obtuse than "boot" I guess...
And where the hell does "fender" come from?!?
 
It fends off other cars? I'm not sure where that came from.
 
AHA! That actually makes sense! 1 lifelong question answered :-)
 
12:34 AM
@mansellan It fends off mud.
Apparently it comes from bicycles.
 
Shame locales don't include regions. If you think en-gb-en is foreign, you should hear en-gb-cy...
 
Well, crap. Pumping messages in the TestEngine appears to make it less testable.
 
en-gb-cy: "Who's shoes are them boots? Whose coat is that jacket?"
 
Not having the asserts raised from the other side of the STA boundary creates some concurrency issues in the test environment.
 
(Welsh English, to save you the Googling)
 
12:36 AM
@mansellan That reminds me of one of my favorite history SE answers.
"Boat-crimper".
 
Sometimes, upgrading a server is a lot like making a smoothie.
 
@Comintern ?
 
8
A: What does a "boat crimper" do?

CominternA "boat crimper" is synonymous with a "boot crimper" - a person who specializes in manufacturing and repairing boots. The process of crimping is used to make leather conform to shapes that can't be created with folding, and involves stretching wet leather over a form with clamps or pliers. You c...

 
LOL
 
@MathieuGuindon That looks more like feeding a 2 year-old spaghetti.
 
12:39 AM
Heh, #TIL SE has a history site. And what a boat crimper is.
 
@Comintern why not mock the pumper?
You don't actually need it for testing, do you?
 
@this I'm already doing that.
 
:+1:
 
Although currently it just nops it.
I figured if I did anything else it could skew the test.
 
Skew how? you don't really want to test the behavior with threading, do you?
If you really wanted to test the pump, you could do that in isolation.
 
12:47 AM
Doing work that wouldn't be done in the production environment.
 
Right, but you can set dedicated test suite for the concurrency
and simply test the rest of the engine with a mocked pump.... right?
 
Hmmm... You mean actually let it pump for the tests that need it?
 
Sure, if you can set it up
for example, you can set the test to run in a STA
or to spin it off in a new task to simulate the STA boundary
I did something similar w/ the suspension tests.
 
It's more a matter of not setting it up I think.
Right now, the UI dispatcher is mocked.
Although, now that I've said that, it sounds like a horrible idea...
This is the problem setup:
 
Should I learn C /C++? I feel like I'm at the stage where I want to get closer to the hardware, but not ready to pore over x86 instruction sets for assembly. What's the current language for low(er) level?
 
12:51 AM
You'll notice that I caught the issue from the comment, but I didn't think it effected single calls.
@mansellan I mainly depends on what you're intending to use it for. I find c++ a train-wreck of a language personally.
Rust might be a good choice.
 
@Comintern yeah, that's what puts me off.
Rust is low-level? Googles
 
I do enjoy ANSI C though.
 
IIUC, C more than most languages evolved rather than got designed. And it shows?
 
@Comintern I have to agree.
I'd much rather do C.
Rust does seems like a fun one if I ever have a reason to use unmanaged code.
 
#TIL Rust is unmanaged... Reading wiki now. From the trendy name, I assumed it was a new-fangled-web-thingy.
 
12:56 AM
it does seems to be used with webassembly as an alternative to JS
 
Does it allow footguns? Pointer arithmetic and such? I feel that's what I need RN...
 
probably because it's low level it can produce a small executable => win for the web, I guess?
not 100% sure
 
Any alternative to JS is a good alternative to JS.
 
^
 
Footguns? LOL
 
12:57 AM
@Comintern just to be be 100% sure, slapping the STA attribute on the test won't do anything, right?
 
Every language has footguns. If you want to aim higher...
 
I don't even have reason to use unsafe {} at work atm...
 
@this It might, but that's assembly-wide.
 
Hmmm... that still leaves the invoke coming from the wrong side of the boundary though.
 
12:59 AM
I feel like I need to peek past the curtain. C# has protected me enough, time to venture into the badlands...
 
Would actually automating Scripting.FileSystemObject work?
 
@mansellan Sounds like you need to start code golfing in C.
 
Probably because of all the talk of STAs and message loops. Your fault...
 
@Comintern does that teach about the dangers w/ pointers and whatnots?
 
@this That adds a dependency on an interop assembly, no?
 
1:00 AM
IDK, golfing seems to be more exercise in estorcity
No you don't have to.
let me see how I did that...
 
@this Like you wouldn't believe. You have to do things in the least safe ways.
 
hmm and MT?
seems that most of problem w/ MT can be only experienced?
 
@this I "get" MT, to the extent that the TPL abstracts it. I'm vaguely aware that there are things called fences underneath...
 
Threads are fun.
 
Never thought I'd be looking where to buy Excel 2003 from in 2019.
 
1:03 AM
o_O
 
Ask Clippy?
 
That would be one way to get a COM object
and I know AV has Scripting.FileSystemObject
 
@Comintern Especially in VB6... Apparently possible, according to the webs.
 
I want a Pre-2007 (Ribbon interface) Excel to get the hotkeys.
 
1:04 AM
But you need to assign it to dynamic
 
Hmmm... I'm cool with dynamic in the tests.
 
or if you'd rather, wrap it in SafeIDispatchWrapper
 
@IvenBach eBay.
 
whether that will generate the condition you need, IDK.
After all, Scripting is just a dumb ol' DLL
not an EXE with a GUI
 
Except how do I get it to call the appropriate assert method? I'm basically building a dummy VBA method, right?
 
1:05 AM
@pond Thanks for the help today.
Home time for me.</iven>
 
can you assert on the scripting?
say.... lame stuff like FSO.DriveExists("C")
 
The RD Assert class has to be newed up from inside it.
 
hmmm.
 
Otherwise the calls are still on the "wrong" side of the boundary.
@IvenBach 'later!
 
Ok, VBS? :-D
No, won't work - you'd need to register the classes in AV.
 
1:07 AM
I feel dirty just considering that.
 
IKR?
 
Maybe spin them off in a Task?
That might get "close enough"
 
I thinkt hat's all you really need
 
Might be worse, actually.
I'm going to try that.
 
just soI'm not missing something obvious - you're testing AssertHandler
but you aren't running any actual code that would create the Rubberduck.AssertClass COM object?
 
1:11 AM
No, I'm generating test results to test the model.
I only really care about the callback to the AssertHandler.
 
hmm if you spun up a new task that news the AssertClass, then ran your test with STA, I think that's close, no?
 
Oh yeah, that's much worse.
 
:( sorry
 
Why sorry, the Task was my idea. :-P
@this Hmmm... that might work.
Although the problem is less that it's not asynchronous than it isn't synchronous enough.
What about mocking the UIDispatcher for the TestEngine, but then using the real one in the action?
 
didn't you say you are already doing that?
 
1:16 AM
No, I'm not using a real UIDispatcher anywhere. I'm not sure that works though, because I doubt the test runner even has a message pump.
It doesn't have a window, so there's no hwnd to attach it to.
Hmmm... What about posting to the current SynchronizationContext instead of invoking an action?
 
would that be still the case even if the .NET's COM object is in another .NET thread
I think that sounds better if we can control it
 
Trying it now.
Yeah, same result as a new Task, which makes sense I guess.
 
short of creating a mock COM server, i'm not sure what else can be done.
besides, a mock COM Server makes it more of an integration test than an unit test anyway
 
1:32 AM
Huh. I think your idea of newing up an AssertClass actually works:
                action = () =>
                {
                    var assert = new AssertClass();
                    assert.Succeed();
                };
No idea why that would be the case, but hey, I'm not complaining.
 
on a STA test?
also, keep in mind the real litmus test will be AV
 
Yeah, I'm going to try that shortly.
Nope, running all 188 gives some random failures.
 
fun.
 
I'm trying the STA attribute on top of that.
I forgot to set it before.
Wait a minute... Is the AssertHandler just not threadsafe?
This shouldn't be possible:
Message:   Expected and actual are both <System.Collections.Generic.List`1[Rubberduck.UnitTesting.TestMethod]> with 1 elements
  Values differ at index [0]
  Expected: <Rubberduck.UnitTesting.TestMethod>
  But was:  <Rubberduck.UnitTesting.TestMethod>
 
well it's static
did you apply an explicit orderby?
 
1:39 AM
That test literally only has a single TestMethod.
 
wut?
 
Well, 2. But one is ignored.
 
hmm. and the result should be just one, right?
 
And it works fine stepping through the debugger or run individually.
Yeah. It's testing Succeed, Ignore.
 
anyway, AssertHandler is indeed a static class, and I do not think it makes any guarantees about how it's receiving the asserts from the AssertClass instance.
 
1:41 AM
TBH, there is zero reason for the AssertClass or AssertHandler to be thread safe.
Lemme try completely non-parallel.
 
if that does work, there's the attribute for it: github.com/nunit/docs/wiki/NonParallelizable-Attribute
 
Do I need to explicitly order these? NonParallelizable gave the same result.
I'm happy to be typing that rather than trying to pronounce it BTW.
 
interesting. I have no idea then.
 
I'm almost getting to the point of commenting them out with a FIXME on them.
Checking the test setup again just to make sure I'm not missing something obvious...
 
2:24 AM
Actually, that's the weird thing. In an HTA and VBA, if you try to ReDim an object that does already exist in those engines (like "Window", or "Application"), it lets you! You end up with a new local variable that overrides the built in object until it goes out of scope. VBScript is the only one of the three that complains. Interesting, and oddly useful! — CyberTaco 15 mins ago
WTF?
Oh duh, it's just hiding.
 
ReDim == plain old declaration
 
Yup.
@CyberTaco - That's normal scope resolution. A ReDim statement counts as a declaration (it can be used on its own even without a Dim if Option Explicit is specified). The new variable "hides" the one within the scope that it's defined in. See the second bullet under "Static Sematics" for ReDim in the VBA spec. — Comintern 27 secs ago
 
@Duga OK, I officially give up for the time being.
 
2:57 AM
[rubberduck-vba/Rubberduck] build for commit aaf20c82 on unknown branch: AppVeyor build failed
BUILD FAILURE!
 
Oh, FFS
 
@Comintern what's up?
 
Hark! I don't hear a canary singing!
 
Problems with the test setup. I think I need to comment out some more tests.
Pending figuring out how to simulate the STA boundary that is.
 
I saw you using SpinWait. Don't you want WaitOne?
otherwise you have no assurance that the other thread is done?
 
3:03 AM
I was thinking SpinWait would more accurately represent the "live" state, but in retrospect that's exactly what I don't want, isn't it.
 
No, not for testing
You need to assert only after everything is done
Look at suspension tests as example of that
 
The part that sucks is that AV is a lot less forgiving than local.
 
(or don't. It could be flawed for what little I know about MT, LOL)
IKR.
 
You're referring to the parser suspension tests, right?
 
yes
It starts tasks in taks then wait for them all
 
3:09 AM
Hmmm... I'd have to take a look at it. Need to find it first...
 
Suspend* IIRC
 
Yeah, I'm looking at it now.
I'm not thinking that will work though. The assert would need to free its thread in the middle of the test loop... I think.
 
If you need it to keep running, then it needs to be its own task
 
I also realized before I added the waits that there is an additional moving part in that the ListCollectionView in the vm is also listening to events from the ObservableCollection in the model for that set of tests.
 
so start two tasks -- one to run the test loop, and another to consume the test method.
I think you need to start the 2nd task inside the 1st task
then wait on both tasks
 
3:16 AM
Hmmm... I'm trying to walk through that in my head. If the first task is raising events that are being consumed by the second task synchronously, wouldn't that simply deadlock the whole thing?
 
This may also help - this is supposed to produce a deadlock deliberately:
(the effect being that suspension will then time out since we specify a timeout to avoid hanging up RD in production due to some lame bug)
 
Actually, what would solve this entire thing is if I just refactored the test engine.
 
uh, wasn't that what you were doing? :D
 
Not really, I was trying to minimize what I was up to in there to UI related stuff.
 
Ah I see.
 
3:22 AM
My goal was to make it easier to tell if changes were UI related or test engine related.
 
TBH, your PR already refactors a bit of the engine already
 
Slightly - it's alot heavier in the model and viewmodel.
I mainly just added a state flag and raise some more events.
 
What would we lose (besides test coverage) if we took the PR as-is without the tests?
 
Nothing. The tests even "pass", just sporadically.
 
In that case, I think I'd comment out them with FIXME or TODO (or if you prefer both ;-) ), then keep it for a separate PR dedicated to hacking up the test engine
 
3:25 AM
Ultimately, the TestEngine should be more of a TestCoordinator, with the work of actually launching VBA functions moved onto an ITestMethodRunner interface.
 
^
you really don't need to test the STA + COM + all that shit
 
If we do that, it's testable, because we can mock the damned interface at the boundary.
OK, I'm busting out the comment hammer.
 
I thought it'd be nice to have some tests that might at least prove that our MT implementation is sane but...
With the suspension tests it was sorta easier because I didn't have to deal with a hacky COM server.
 
It's really not MT though.
That's the problem with trying to test it.
 
#Words - I just like the reassurance that we're trying to cover those hairy bits of COM marshaling
but this might end up being delusional. :(
 
3:29 AM
Although now I am curious if this is uncovering a problem with how we use the AssertHandler. It could be that when the VBE blocks it masks a real underlying problem.
 
Could be. Sorry, I'm a bit fuzzy why do we have it in the first place?
 
@Duga Yes, please.
@this It's segregated into a COM visible assembly.
 
> Any languages can be translated! The issue is that we need volunteers to help and translate them into the target language. If you are interested or know who would be, we can help get this started and thus enable Spanish (or any other languages).
 
Which means that we're kind of stuck with it.
 
3:32 AM
No, that's for AssertClass
all AssertClass ultimately delegates into AssertHandler, basically
 
Right, but that reports the results to the AssertHandler.
 
but AssertHandler is static, which doesn't make sense to me.
 
I need to look at it again.
 
Ok, so we're newing up the AssertClass in the test module (I think only once for all tests).
 
Right.
 
3:34 AM
then we invoke the test methods.
 
So we rely on the message pump to order them.
 
Between the calls we reset the asserts, IIRC.
hmmm.
Maybe that's actually the problem.
 
we don't need that.
Ok, what we actually want is a provider so that when VBA code requests an instance, we create it
 
I think we do though. The AssertClass doesn't have the caller information.
 
3:35 AM
that mean we then have a reference to the AssertClass that VBA has.
hmm.
 
We could have the test coordinator serve as a factory for providing AssertClass instances to MethodRunners.
That kind of breaks the COM contract though.
 
no.
damn, backward compatibility.
 
I think what would happen is that when the module teardown ran, you'd wind up with a bad pointer, right?
 
I was thinking that the test module should not be doing this: Set AssertClass = New Rubberduck.AssertClass
That's wrong.
 
Oh, we could fix it easily if we broke every existing test in the field, but that's a non-starter.
 
3:38 AM
What we want is Set Provider = New Rubberduck.UnitTestingProvider : Set AssertClass = Provider.GetAssertClass
 
> Great! I have little knowledge, but how could I help?
 
That would allow us to create the instance and provide it to the VBA
 
@Duga Become fluent in Spanish!
I'm trying to think of a COM safe way to let the existing caller do that.
 
I don't think that's what he meant
 
3:39 AM
LOL
 
do it like Outlook?
Set outlook = New Outlook.Application 'Not a new instance
 
Break everything for security reasons?
Hmmm... That might work.
And then have the coordinator set the Assert context to a specific method before invoking it.
I could see that working.
 
> @D3vlin I'd take a scan through the wiki if you haven't already. How is your c#?
 
Using internal context switching on the AssertClass would make some other testing features possible too, now that I think about it.
 
the issue is I have no idea how to implement this in C#
I assume with Outlook, it has a custom IClassFactory that basically ensure that only one instance is spun up or something like that, IDK.
 
3:46 AM
Right.
 
but in COM interop, we don't get that kind of customization, I think.
Unless we Wayne it out. :D
 
Wouldn't you just make AssertClass a singleton?
 
you must have a parameterless constructor.
and it will not return... not-itself.
 
Is there anything that says you can't new up a static?
COM knows nothing of static.
 
hmm. if you define public static class Foo(), then you can only have static Foo()
I think that would be not be creatable from COM but I may be wrong.
 
3:49 AM
I've never tried it.
Of course there's nothing that says you couldn't make it a thin wrapper around a singleton.
I.e., the instance has no state of its own - it just provides an interface for the underlying singleton.
 
> My ability with C# is basic, I understand the language. Management of variables, arrays, classes.
but I do not have very advanced knowledge.
 
well, isn't that what we already have w/ the ASsertHandler + AssertClass?
 
Now that you mention it, yes.
:facepalm:
 
so what problem are we solving again?
 
The solved one apparently.
 
3:53 AM
lol, back a bit up - so why wasn't this working out for the tests?
 
I think all we really need to do is pry out a TestMethodRunner so the engine doesn't have to rely on events raised by the AssertHandler.
 
yep, sounds right.
 
I think that's the link that fails in the tests.
 
Which is another PR
 
Right. Ditch OnAssertCompleted. Have the Engine new up a runner. Synchronize that with the AssertClass, then store the instances.
I'd invite D3vlin to chat, but I can't remember how to auth a user without the CR rep.
 
3:56 AM
hmm there's no wiki on translation. :(
doesn't he have to join first?
 
Yeah, that's trivial though
OK, I found it.
 
> Great, that's good enough.

You should start by reading through [Contributing](https://github.com/rubberduck-vba/Rubberduck/wiki/Contributing), so you can fork the project and start building. You can also join the [chat](https://chat.stackexchange.com/rooms/14929/vba-rubberducking) - if you do not have enough SE rep, one of the room owner can authorize you and you can then start more detailed questions to get started.
 
:+1:
 
TODO: we need a wiki for translation - since I never use the whatever thingamigjig they use for trnaslate, someone will need to write it up.
resxmanager, something
 
Yeah, I have not a clue what's involved there.
 
4:02 AM
> I realized that the wiki does not have anything that details the process for doing the translation. I think it would be beneficial to document the tools and the process in doing translation for any potential contributors.
 
GTG, later!
 
'night
 
4:32 AM
[rubberduck-vba/Rubberduck] build for commit 4af510d0 on unknown branch: AppVeyor build succeeded
 
@Duga And there was much rejoicing.
 
 
4 hours later…
9:01 AM
@Comintern For another example of test working with multiple threads, you could have a look at the AttributeRecovererTests.
 
 
3 hours later…
11:47 AM
@IvenBach sounds like you should look out for 2003 specifically. Avoid XP as, despite the name, it doesn't support XP themes. 2003 is the only version that had old style menus and decent icon colour depth.
 
00:00 - 12:0014:00 - 00:00

« first day (1716 days earlier)      last day (1464 days later) »