« first day (1965 days earlier)      last day (45 days later) » 

12:01 AM
[rubberduck-vba/Rubberduck] 3 opened issues. 1 closed issue. 11 issue comments.
[Minesweeper] Games Played: 94, Bombs Used: 45, Moves Performed: 10968, New Users: 8
4 hours later…
5:10 AM
> Closes #4872

NOTE: Do not merge PR until end of the month.

Merging the PR will mean that we no longer can use Visual Studio 2017; all contributors must start using Visual Studio 2019 after the merging. As a benefit, we are able to remove all the hacky workarounds that was put in place to support WinForms/WPF when we migrated to SDK-style project format. However, we need to test that we are able to build on AV correctly.
[rubberduck-vba/Rubberduck] build for commit e7fac995 on unknown branch: AppVeyor build failed
[rubberduck-vba/Rubberduck] build for commit 9d36c047 on unknown branch: AppVeyor build failed
[rubberduck-vba/Rubberduck] build for commit 347c603f on next: AppVeyor build cancelled
[rubberduck-vba/Rubberduck] build for commit 73236015 on unknown branch: AppVeyor build failed
[rubberduck-vba/Rubberduck] build for commit 347c603f on next: AppVeyor build cancelled
5:40 AM
Something ain't right about AppVeyor. I'm logged in the AV, and I noticed that the builder image was reported as Visual Studio 2015 which doesn't makes sense since the log says it's using Visual Studio 2017. I changed the image to Visual Studio 2019, and the build still fails, reporting that it's using 2017.
When I try to start AV, it randomly picks a commit from.... whatever.
and it won't let me restart my own commit. Logical!
So if anyone who has access to the real Rubberduck account on AV, I'd appreciate if we can check whether it builds using 2019 image.
5:55 AM
> If this PR will invalidate any Visual Studio prior to 2019 it may be prudent to give a couple weeks notice before merging. I know I'd be at a loss right now as I am still on VS2017 and am really out of the RD development loop.
^ @this I'm sure you're already thinking about it but just in case.
1 hour later…
7:17 AM
> Thank you @glowingrunes - I'll check the next build
8:36 AM
Apropos AV issues, anyone have any ideas about this: stackoverflow.com/q/58514044 ?
5 hours later…
1:06 PM
I've just started to use Rubberduck. I would like to say to authors (Mathieu?) THANK YOU SO MUCH! My code isn't optimal yet, but it is A LOT better after reading messages in Code Inspections menu
1:49 PM
I've been using AppVeyor for about 6 months now on three different projects. I cringe every time I need to touch the appveyor.yml; it always feels like an exercise of PDD -- prayer-driven development: copy-paste various things, and randomly fiddle with the syntax until AppVeyor accepts it.
Any suggestions as to what I am doing wrong?
Obviously not enough P in your PDD methodology!
@ZevSpitz you're doing it all right :/
it's not really any different with other CI services.
Though Travis CI seems to have built something that allows you to test your configuration in some way.
2:10 PM
In my case, I think it's because I'm not really Rubberduck.
Rubberduck has a team org and AV is connected to it. I can access some stuff but not as Ruberduck, only as me. That's the only explanation I can come up with what I saw last night.
Rubberduck can't possibly have been building on Visual Studio 2015.
The main problem with AV as I see it is that there's no simple way to test besides actually running it. That's why it's so PDD-ish.
@ZevSpitz I am not familiar with VS extension stuff but is it truly impossible to build a 2017 extension using 2019?
@RafałB. thanks! credits go to the dev team, I just make bugs and half-assed broken features =)
It's certainly possible to build the visualizer (different from VSIX extensions BTW) with 2019, but because the 2017 version needs to target a different version DLL, it requires 2017 to be installed.
If AppVeyor had some image that had both VS 2019 and 2017 installed I could use that.
ah I see
could you include that particular DLL?
(as a reference, perhaps)
I'd have to include it in the repo, but that might work. I'm not sure if I'm allowed to redistribute it though.
you shouldn't
(at least I hope you wouldn't have to)
I'm thinking that just by including the DLL only for the build purpose, you'll get a working visualizer without having to do via a 2nd AV build or deal w/ excluding project which apparently doesn't work.
oh, one more thought just to be sure - you did explicitly exclude the build for all configurations, right?
2:23 PM
Ok. I keep forgetting that our AV builds releases and we build debug so that gets me in trouble somtimes.
@this How could I find out of the legality of something like this?
including the DLL in the repo only for build purposes.
It would be much easier if there was a NuGet package. Sam Harwell (yes, that Sam Harwell) made one a long time ago, but didn't keep it up to date.
I would straight up ask Microsoft.
One way would be to call their anti-piracy hotline.
@MathieuGuindon when you could, you please confirm whether RD AV is using 2017 image? My AV settings seems to do nothing whatsoever and I need to use 2019 image to verify the build of the PR.
> The earliest it can merge would be Nov 1st, and even so, I don't know it'll merge that early. More likely, we'll want to do that after our green release, which is likely to be in mid-November anyway.

Build articles will be updated as well, so you can consider this PR your advance warning. :)
> MSBuild auto-detection: using msbuild version '' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\bin'.
looks like 2017 indeed
2:34 PM
See, when I went into AV last night, it said it was using 2015. Baloney.
I changed to 2019.
In both cases, I get 2017.
the .yaml is overriding all AV settings
> image: Visual Studio 2017
Blargh. Looks like I'm the dumb one
nah, AV config is confusing
so yeah, the .yaml needs to be in the PR's diff :)
here goes. let's see what happens.
2:38 PM
might need a kick, hold on
> MSBuild auto-detection: using msbuild version '' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin'.
nevermind, build is in progress
Looks like it's working!!1!
I feel so smort.
so just for my sanity's sake -- in AV, I apparently can start a new build but doesn't let me kick a build. WTF is up with that?
(and when I say "start a new build", I really should say "AV picks a totally random commit and builds it")
@this "random" is always so handy...
I think it just grabs whatever the latest build was
2:49 PM
[rubberduck-vba/Rubberduck] build for commit 6a89357b on unknown branch: AppVeyor build succeeded
@Duga woohoo!
now I need to see about fixing some of the bogus warnings. Still much better, though.
the designer mostly works, too. The only weird thing is that previewing WPF doesn't work in WinForms.
Was that a thing that used to work?
it's flakey in 2017 as well
@this who are you logged in as?
we had a bit of a fight with carrying over the GH org permissions to AV and basically just gave up
as me?
if i'm supposed to login as rubberduck, I don't know how
3:01 PM
@this maybe Mug or Vogel can share the credentials here for you to use.
in theory all you need to do is authenticate with GitHub
in practice...
@this as a separate AV account for you or via GH?
there is a rubberduck account and I might have the credentials ... somewhere, but ...
I just authenticate via GH and can kick builds, so
i did auth via GH
but i can't kick a specific build.
I can kick a build but it has no correspondence to the history.
if you click on the last "build" link, do you get a "rebuild PR" button?
No only a log button
3:03 PM
and you're logged in via GitHub
hm, hold on
@RafałB. welcome to the pond. Thanks for stopping by.
@this you should have received an email from GitHub / rubberduck-vba org
I've removed you from team AV-dev and invited you to team AV-admin
did it change anything?
there's no documentation on what permission does which thing
3:13 PM
No email yet.... :\
tried signing out & back in (via GH), no changes.
FWIW, either the permission is a lie or there's ssomething wrong
because I was able to view the settings and modify stuff.
(granted it did nothing due to the .yml file but still I can see the settings)
I just can't run a specific build.
1 hour later…
4:38 PM
@FreeMan Isn't it always 4? xkcd.com/221
@ZevSpitz indeed!
5:33 PM
Just making sure - in SQL I have columns MyLongText nvarchar(500) and MyShortText nvarchar(2). If I store 'No' in both columns - they both take up the same amount of space, right?
TYVM Mug for opening my eyes to how slow repeatedly accessing an Excel worksheet is. Avoiding it where possible has sped many things.
ugh... worst javadoc I've ever seen in the standardlib:
says literally nothing
6:37 PM
at least you know the defaults...
@Vogel612 isn't that what you should expect from an oracle?
well ... yea, kinda.
"you shall destroy a mighty kingdom!", saith the oracle. <-- love that story.
6:51 PM
@this you sure that wasn't Trump on Ukraine?
if it were, the oracle should have said "a crumbling empire" instead of "a mighty kingdom"
7:12 PM
Trump's basically the Murica version of Emperor Caligula.
7:30 PM
Loop through foo and get the results begat loop through bar begat loop through duk begat loop through buzz begat loop through irmaGourdPleezStopWithTheLoopThrough O(n^6) is about the order I'm on presently. No small time for it to complete...
Thank goodness for empty workstations.
@IvenBach that's what you get for naming your variables foo, bar, duk, buzz, and irmaGourdPleezStopWithTheloopThrough. I mean, other than that last one, they're not very descriptive...
8:27 PM
> Following my submission for #5135, some bugs were raised. These were: 1) Auto-scrolling when clicking a cell. This has now been fixed with an event handler which stops the RequestBringIntoView event from reaching the ScrollViewer. 2) "After using the scrollbar and collapsing a grouping, expanding it again makes the scrollbar default to the far right hand side" - instead of placing the ScrollViewer inside the DataGrid, I put the DataGrid inside the ScrollViewer. Now it's actually appearing...
in the correct place and no longer behaves erratically. Closes #5237.
[rubberduck-vba/Rubberduck] build for commit f1d3be48 on unknown branch: AppVeyor was unable to build non-mergeable pull request
> this was based off of the state of next from 16 days ago and as such had some conflicts. You should update your local repository with the development progress to avoid things like this in the future ;)
> I've sorted out the auto-scrolling as well now, so both bugs have been addressed in my latest pull request.
[rubberduck-vba/Rubberduck] build for commit 2b4a094d on unknown branch: AppVeyor build failed
> Whenever I do a pull in Visual Studio it says my "next" branch is up to date. And yet the latest commit I see when I View History is from 8th October? What am I doing wrong? I have run a Sync, Fetch and Pull on my "next" branch.
> @glowingrunes you want to git pull upstream next, i.e. bring in the remote commits from the main (this) repository; when you do that the Team Explorer in VS should mention something about merge conflicts, and present a "merge" button - clicking it brings up the conflict resolution tooling.
> @glowingrunes I think the issue is that you're only pulling from your fork of the codebase. You will need to add this repository here to the remotes available in your local git repository using something like:

git remote add upstream git@github.com:rubberduck-vba/Rubberduck.git

Then you can update your local repository's next by using:

# checkout next branch if not already on it
git checkout next
git fetch upstream
git merge --ff-only upstream/next
[rubberduck-vba/Rubberduck] build for commit 91993341 on unknown branch: AppVeyor build succeeded
> @glowingrunes you want to git pull upstream next, i.e. bring in the remote commits from the main (this) repository; when you do that the Team Explorer in VS should mention something about merge conflicts, and present a "merge" button - clicking it brings up the conflict resolution tooling.
> Ah, right. Thanks!
> I'm a bit confused here. The linked issue #5237 is for code inspection toolwindow but this seems to fix test explorer toolwindow?

Wouldn't we want the fix to be applied on all toolwindow to have an uniform behavior WRT sizing & scrolling?
9:05 PM
@Duga hmm. I think I'm even more confused since this seems to be a older PR than the linked issue.
> Hmm, running into a problem when trying to fetch upstream.

A:\repos\Rubberduck>git fetch upstream
The authenticity of host 'github.com (' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? y
Please type 'yes', 'no' or the fingerprint: yes
Warning: Permanently added 'github.com,' (RSA) to the list of known hosts.
git@github.com: Permission den
looks like he's using ssh
> do you have an SSH key registered with your github identity? If not you'll want to use the https cloning. You can accomplish that by changing the remote's url using

git remote set-url upstream https://github.com/rubberduck-vba/Rubberduck.git
@this that's on me... I gave them the ssh url assuming they'd have an ssh key set up
9:08 PM
nonetheless, #TIL that user@domain syntax => use ssh
not necessarily, actually
could also be telnet
I hope nobody uses telnet for git.... at least not across WAN.....
That's basically streaking across the internet
@this I don't think git supports that as a protocol, soo ...
> Perfect, that fixed it. :)
9:14 PM
git pigeon:send commit -m "fly, pigeon, fly"
@Vogel612 ok, I'm confused now. Why did you bring telnet into the conversation if it's not supported? I was referring to the syntax git remote add upstream git@github.com:rubberduck-vba/Rubberduck.git
there is nothing saying "use ssh", so I inferred that the user@domain was what makes it uses ssh
@this because the URL format using @ can also refer to telnet authentication
ah okay, GTK but that wouldn't happen in this context, right?
A: git over telnet

qqxNo, it isn't possible. Even 13 years ago telnet wasn't an acceptable protocol to use, and ssh was already supported by any server worth using. That's even more the case now. You may be able to set up support for doing git over http, including pushes. But you should really see about getting some...

I'm somehow not surprised that somebody out there tried it..
fwiw I still do use telnet but only as a sanity check
usually to verify that port is open, etc.
but to actually use it for anything....
9:19 PM
yea, apparently you can get git to actually work via arbitrary connection interfaces, so long as you properly route the commands on the other end:
> Data written to stdin of the specified <command> is assumed to be sent to a git:// server, git-upload-pack, git-receive-pack or git-upload-archive (depending on situation), and data read from stdout of <command> is assumed to be received from the same service.
> There were 2 issues, #5133 and #5135, which were to add a horizontal scrollbar to the Test Explorer and Code Inspections window, respectively. I added similar code to both, so I thought it best to add the fix for #5237 not only to the Code Inspection window but the Test Explorer as well. My pull request for #5133 had already been merged in, so I updated my pull request for #5135 which is still pending.

I'm still new to Rubberduck, so if you could give me a list of the other tool windows tha
10:04 PM
> We have 4 toolwindows:

Code Explorer
Todo Explorer
Test Explorer
Code Inspection Results

We have few more XAML dialogs (e.g. Settings, RegEx Assistant) but they aren't used in a toolwindow so I think they don't necessarily need the same behavior.

« first day (1965 days earlier)      last day (45 days later) »