« first day (1275 days earlier)      last day (1905 days later) » 

12:01 AM
RELOAD!
[rubberduck-vba/Rubberduck] 4 commits. 1 opened issue. 7 issue comments. 274 additions. 222 deletions.
[Zomis/Connecting-Blocks] 1 commit. 49 additions. 67 deletions.
[Zomis/UltimateTTT] 1 commit. 1 addition. 1 deletion.
 
@Vogel612 I'm going no need to.
 
12:48 AM
@Mat'sMug In my case I'm not rewriting... yet. This is going to go into the validator class which shouldn't do any rewriting. I already have a dependency on the RubberduckParserState there.
I guess my choices are 1) generalize the validator class into validator + rewriter class and take a dependency on the rewriter, or 2) update the RubberduckParserState to enable retrieval of the token streams.
I don't like #2 very much because that breaks the encapsulation; nobody should be using token streams unless we can make it explicitly read-only
#1 isn't that appealing because one reason for having a validator class to begin is to help make it fast to validate since it's used by the CanExecute method so it has to be light and focused.
 
Does VBA have a way of checking if an object implements multiple specific interfaces? Best I can think of is checking TypeOf Obj Is XXX multiple times.
 
@robodude666 Fundamentally, no.
 
There's also no way to guarantee that if interface A is implemented it will always implement B?
 
COM does not have anything that lets you enumerate interfaces; you can only query whether an object implements a given interface but there is nothing official for enumerating it. That's why VBA doesn't make it easy to expose.
if it's your interfaces, you can.
Not sure I understand your question.
 
programmatically, i mean.
 
12:55 AM
Hmm. Not sure I follow, sorry. If we're talking about custom VBA classes, you write Implements A: Implements B
and then you're required to implement them all.
but to guarantee that a class that implements A also implements B is entirely beyond the scope of interfaces because you're talking about implementation details.
So even if you had a interface A that has a member GetMeTheB which returns interface B, it's still up to the class to implement that method correctly
 
e.g., you have IMammal and ICanine . You then have a class called Dog which implements both. But there's no way of saying that just because a class implements ICanine that it also implements IMammal without doing a TypeOf Obj Is IMammal ?
 
it would be free to return Nothing, itself, some other instance that implements B
 
It would be purely based on my discipline to ensure I implement both interfaces.
 
Not by interfaces solely, no.
Because all interfaces ask for is that you implements so and so members
but how those members are implemented... that's entirely up to you.
one thing I didn't do (hadn't to do in VBA) is --
if you implements IMammal in the ICanine interface
ah, yes, that's a problem. it won't extend the interfaces since you must cast to IMammal, OR write stubs that redirects to IMammal_xxx members
so that's your choices then.
 
Yeah, I'm aware of that part.
 
1:00 AM
either have a Property Get AsMammal() As IMammal or just re-implement all IMammal members then redirect to IMammal implementations.
I would probably opt for the former. Less boilerplate code.
 
hmm, interesting thought.
You'd include the property get AsMammal as part of the ICanine interface?
 
but it's still up to the Dog class to actually do Set AsMammal = Me
and not something weird like Set AsMammal = Nothing or New Mammal
yes
 
right, but it at least provides a tell that you probably should also be an IMammal
 
yes.
 
interesting idea. i'll have to play around with that :)
 
1:03 AM
have fun!
 
back to coding. cheers!
back again right quick!
 
@IvenBach Well, a cheap way to create a static class that's also a singleton is to use a standard module but encapsulate it as if it was a class (e.g. no public fields).
 
just realized that you'd be able to very easily use With Dog.AsMammal to access a few mammal methods without having to create a whole new variable. Brilliant!
 
Ayup
:+1:
 
@robodude666 I'm starting to use that style of coding too. Very helpful.
 
1:05 AM
this->+1 ?
 
this++;
 
won't that increment the pointer address?
 
don't trust me on anything C/C++. I doubt either are legal, actually.
 
> Hey where and how did you get the VBE to honor a dark theme??!!!!?! This is the first time I see an actually dark VBE (and I love it!!) Test
 
ha, that would increment the pointer and break your code.
 
1:07 AM
> Hey where and how did you get the VBE to honor a dark theme??!!!!?! This is the first time I see an actually dark VBE (and I love it!!)
 
@Mat'sMug Think you may have given me, and possibly other contributors, edit access. yep... Seems I can edit your post.
@Mat'sMug I got a Lock Conversation icon too. If that's any help in diagnosing the permision.
 
@IvenBach with great power, comes great responsibility.
 
I don't want that kind of power.
 
1:27 AM
@robodude666 depends on the type
@IvenBach that's because the Github permission system sucks for people that don't pay money
 
I remember this last time Mug messed with the permissions.
 
3 hours ago, by Mat's Mug
basically "Dev" and "Contributor" are the same now
see surrounding stuff for context...
 
oh dear... that means contributors can push stuff into the repo?
 
as of now: yes.
 
but not actually merge
cos I'm looking at the PR adn the merge button is disabled
 
1:34 AM
because GH has a [insert a large number of choice words here] permission system
@this probably needs status checks to finish
 
This pull request can be automatically merged by project collaborators
Only those with write access to this repository can merge pull requests
doesn't seem so.
 
hmm ... which one are you looking at?
 
so at most we can push a crappy PR that can be rejected
....right?
 
hmm ... apparently merging PRs is down to the Dev team ...
 
which is better. The fewer who can merge, the better, IMO.
we don't want a lunkhead borking the repo.
 
2:08 AM
hmm. why would debug load ok but release not?
 
2:24 AM
I saw merge was disabled too.
Is it best practice to not merge ones own PR?
 
that is the case anyways.
 
Cool.
 
I took the liberty to do it on the i18n PRs anyways...
but it's why I so persistently bugged the Mug about Code Metrics.
an additional mechanism to provide a modicum of stability to next
as well as a safeguard against a maintainer going rogue
not that the latter is likely in any way, but being held accountable on SE and in my job has made stuff like that somewhat second nature
and I'm pretty sure that it's similar for the mug.
that said... I need to get my sleep cycle back on track. G'Night :)
 
Night.
 
3:19 AM
uuuggghhh, they are not making it easy to read from hidden channel.
awfully tempted to just hack it with a regex looking for whitesapce + #
at least line numbers or labels are illegal on the same line for the compilation constants/directives.... so the regex should be simple.
 
 
2 hours later…
5:16 AM
I'm observing that the CanExecute doesn't always fire when it should.
for a given selection that should be valid, if I place cursor at end, then ctrl + home to select the line, it enables the method. But, if I put it at the start, then ctrl + end... it doesn't get toggled.
I also see that if I drag the selection, it does not fire when I release the mouse button. I think it should.
 
 
10 hours later…
3:00 PM
@this We do not only hide the compilation directives; we also hide whatever branch of an #if #then #else directive is not activated given the precompiled conditions.
 
3:16 PM
@M.Doerner yes but there are other problems, unfortunately. If there's flags defined in the project's Conditional Compilation Argument, those will be always be false, regardless of how it's set
Because AIUI, we don't have a way to read that information.
Furthermore, the selection can become strange.... when we select any part of the directives, it is invalid. If we select only inside the active block, it is valid. But if we select inside the inactive block, it is invalid (even if the code is valid) because to the parser, I've just selected a lot of whitespace.
For the selection to work more intelligently than that, I'd need the parser to be aware of the compilation directives, I think.
 
that's unfortunately nearly impossible
because compiler directives can be literally anywhere
well almost, but it's close enough
 
yeah, and you can have invalid code within it
 
and rewriting the grammar at that scale is simply not feasible...
 
For right now, I'm fine with the behavior mostly.
I don't like that it's still "valid" inside the active block because extracting out of it would basically break the logic of the #If...#else block
well, no. It wouldn't. It'd be replaced with a call site
hmm now that I realize that, it becomes easier to fix the #else (or #if if it's the one active)
extract from the active block
then update the inactive block to use similar call statement. (manually)
so that's not too bad.
As a favor to the users, I suppose I can even add a warning to the user if the procedure or the module contains any directives that the process will operate on the active blocks and other inactive blocks must be manually updated.
To avoid surprising them
 
never hurts to explicitly note that..
 
3:31 PM
Yeah I think i have to do that because extract method will be parsing stuff outside the selection (e.g. the variable declaration for instance)
 
 
1 hour later…
4:45 PM
same module but w/ them commented out:
 
shouldn't var3 be passed as param to the ExtractedMethod?
 
it's dumb right now.
 
warning looks awesome, though
 
all variables will default to Private Local Variable
the user has the option to change to ByRef Parameter (what isn't obvious is that the grid is selectable and editable)
 
Personally I'd default to making them parameters
because that's what I'm used to when extracting methods with other IDEs.
You could make the grid display a dropdown arrow to make the "editable" more obvious
 
4:49 PM
I see. I was thinking that after I have the logic of actually extracting them, in the 2nd iteration, I'd make the default more smarter by analyzing the references
Yeah, the style of that grid is horrid.
I think Hosch said he'd help out with that.
 
yes, he did
 
the way it is now, you must click on grid to see the dropdown
which I really don't like. it hsould be always visible, else I'd never know it was meant to be editable.
@all - RE: default for the first iteration --- I'd love to hear others' opinion -- should ByRef Parameter be the default rather than Private Local Variable? ( keep in mind 2nd iteration will make it a bit more smarter )
 
> This update includes some refactoring, and improved UI logic, notably warning about compilation directives. Also fix the repainting bug when moving the form and enabling resizing of the form.
 
hmmm seems I can merge this PR.... I thought I wouldn't have that ability (nor would I want to do without others having had a chance to review).
 
5:00 PM
@this the problem is: merging a PR and assigning yourself to an issue are the same level of permission in GH
 
the strange thing was that when I looked at IvenBach's PR, I couldn't.
oh wait, so I can do what I started but not what others started.
 
that's weird. it should be independent of who authored the PR
 
well, as you said... GH permissions is....
 
@this I would have put the warning icon on the left. Looks awesome though!
Actually... If that warning panel could borrow some styling from the SC panel's, would be even nicer =)
 
drats should have thought to look somewhere else to implement that.
agreed about the placement - that was before me knowing RD has a warning style somewhere and I was following the only thing I had, the red X for the validation
oooh, not cool, git. Now you have two RubberduckUI.resx, one missing some keys, others with all keys. I am disappoint.
 
@Mat'sMug what's your opinion on default? Vogel thinks it should default to ByRef Parameter - it's currently set to default to Private Local Variable. (in either cases they can be changed)
 
This is all in a branch on the master repo?
I can take a look now.
 
no
sorry - misread
yes it is on a separate branch
ExtractMethod is the branch
 
Cool.
 
5:27 PM
@this not sure I understand
Default should be as cleverly close as possible to what you'd want to do
 
on the UI, you have a dropdown to choose between 6 possible settings for extracted variables.
right now I just apply only one (hard-coded).
 
The way I see it, it depends on what's used where
 
in future, I'll make it a bit more smarter but I want to get the first iteration done sooner.
 
Hmm, whatever works then =)
 
Yeah and that requires additional parsing. I guess the question is more -- which is more likely... an extracted variable will be a parameter or simply moved over?
I assumed more common would be to moving variables than parameters but Vogel thinks otherwise.
only want to have a default that doesn't require them to change every time until I get the 2nd iteration.
 
@this I see. We definitely want to move it over if the only uses are within the selection.
The possibilities need to be per-variable
 
It's got some fun bugs still :)
 
Hmm, that would be a warning about there being no executable statements
 
It works for my part--cleaning up the UI.
Got it.
Making a PR now.
 
5:53 PM
[rubberduck-vba/Rubberduck] Hosch250 pushed commit 879fb8af to ExtractMethod: Fix border lines in UI
 
WT*!
What the heck happened there!
It's the same thing that let me delete Next back again. I tried to push to origin, and it pushed to upstream...
Stupid UI...
Oh well.
I guess I'd better start using the command prompt instead.
 
Good catch, Hosch. I don't have a check for that.
Don't use VSTS. That's why I don't use it. It just doesn't work.
@Mat'sMug sounds like a vote for parameter by default. They definitely will be considered per-variable in 2nd iteration.
 
6:15 PM
@Hosch250 next and master are protected, you couldn't delete them if you tried
 
@Mat'sMug I know.
But it's the same thing--my local branch is supposed to be pointed at origin, but it is pointed at upstream.
 
@Hosch250 looks much better, thanks! That said, the combobox looks funky
clicking on it gives a box + dropdown inside the blue bar.
 
Yeah.
Same as it was before.
I can maybe tweak that a little later. Not ATM though.
 
OK, NP
 
7:30 PM
@Hosch250 you can fix that by using --set-upstream-to
 
8:04 PM
Cool.
Basically, I used the "Checkout branch" thing, and unchecked the box to track the remote repo. That used to work, but it hasn't been working anymore.
@this Can you get me a mockup of what you'd prefer?
Wireless earbuds are so awesome.
 
@Hosch250 until you smash them to bits in your backpack with your laptop
totally didn't happen to me... ~cough
 
I have a little case to keep them in clipped to my belt loop :)
LOL.
I kept my wired ones in my pocket with my phone. That was gross.
I had to wipe them off every time before I used them.
 
@Hosch250 something like this...
 
Minor UI cleanup, enabling resizing of the form
Remove literals here and there into the resource file for internationalization
Correct a bug with the (None) selection
[rubberduck-vba/Rubberduck] bclothier pushed commit 3d47d0f9 to ExtractMethod: Reset RubberduckUI.resx
Rename of some classes for clear self-documentation
Refactoring various things and remove unused things
Handle the case of the compilation directives or constants in the selection
 
 
[rubberduck-vba/Rubberduck] bclothier pushed commit 7564d7e0 to ExtractMethod: Update the UI to handle warning for the presence of compilation directives within a module which can impact extraction of a method.
 
OK.
 
8:25 PM
Merge branch 'ExtractMethod' of https://github.com/rubberduck-vba/Rubberduck into feature-extract-method

# Conflicts:
# RetailCoder.VBE/UI/Refactorings/ExtractMethod/ExtractMethodView.xaml
 
WTF
 
Fix warning style
Partial refactoring
 
oh balls. I pushed to the ExtractMethod, not my origin. :(
apparently, pushing to the master repo => auto merge
 
LOL.
 
see, that's why too much power can be a bad thing!
 
8:28 PM
Well, no. It wasn't a merge.
It was just a direct commit.
 
it did merge the PR
PR is now closed.
 
No, there was no merge involved.
Oh, hmm.
 
Yeah. I thought you just directly pushed like I did.
 
@this nope
 
8:29 PM
Looking into that issue.
 
what I should have done is push to my origin. That would merely update the PR
 
because GH allows merging from console, when the base branch of a PR is updated to include the HEAD commit of a PR, the PR is closed
@this that :)
 
yes I realized my mistake too now. I absentmindely selected the master repo + ExtractMethod when pushing
 
@Mat'sMug I think we can't leave GH permissions like they are now 😒 Too many people unhappy about it...
 
8:31 PM
Thinking about it, because the concept of "pull request" doesn't exist in git, it's very easy to get confused when doing direct commands
because updating a PR and merging a PR are both a push
the only difference is where you push
 
@this yes and no..
it depends a little on how you define "merge" a PR
because if you only consider a PR merged when there is a merge-commit, just pushing isn't sufficient
then again that definition would be somewhat stupid
 
to my mind, a merged PR means that the master repo's branch now has all the changes accepted.
 
good definition.
 
therefore, to update the PR but not the master repo's branch, you have to update the forked repo instead.
 
includes force-pushes :)
 
8:36 PM
the bright side is that I did select the ExtractMethod....
 
and if Mat is correct that nobody can push to master or next, then I can live with that.
 
it's not like that...
it's just that nobody can force-push ..
 
@this You have to have push privs to merge.
 
@Vogel612 not sure I follow you RE: force push. @Hosch250 i assume that only applies to the master & next branches but not other branches.
 
8:43 PM
@this you and I can push to next
we just can't destroy things while doing that
 
oh.
 
Force push essentially means choose yours if there are any conflicts.
 
oooh right
 
@Hosch250 no.
just no
 
so therefore if I done it stupid, Mat or whoever can just undo the commit at least... right?
 
8:44 PM
force push means waltzing over anything they ever did and completely erasing it from history
@this define "undo"
 
i'm thinking of reverting the head back to an earlier commit
as if the bad commit never happened
 
meh,
it's not next
 
yeah it's not (thankfully) but i"m also worried about mistakes that hits the next or master.
 
worst case, mat has god privileges and can nuke commits
 
I screw up my branch, Ok, I can deal with that. I screw up the master.... well, going to have to get me a good hiding place.
 
8:46 PM
alternatively there's git revert
 
@this That's what I felt like when I nuked next :P
 
hmmm. I just had a thought. on the master/next there's checks.
suppose we added a check to all branches
 
We can set it up for this too.
 
basically to confirm, "are you sure you wanna do this?"
that way, if one accidentally pushes to wrong branch, it's easily undone
feasible?
 
@Vogel612 Got an example? It's not recognizing it.
I know I've done this before, so...
Oh, I need git branch
 
8:55 PM
don't you need to do a git fetch then git checkout ?
(assuming your intention is to change to the branch specified)
 
no. that's an entirely different problem you're solving
it's not
 
I found the *** problem.
...
 
yeah. not quite right.
shld be hosch250\rubberduck.git
 
Yup. This should fix it.
Fixed.
 
@Vogel612 just to check I understood your comments about null-object pattern... that means I need to modify the ReturnParameter member so that its getter will return a None object, rather than null?
 
9:03 PM
I'd use a null-object to check for the "none-specified" return parameter explicitly
that's just a special instance that can not be created from normal means, which you can check against instead of checking against special strings
@Hosch250 git remote -v is cool for stuff like that
 
hmmm..... so we're talking about something like ReturnParameter.None (a static function on the class? )
thus, returnParameter != ReturnParameter.None
?
 
Wrong way.
Ugh. This is a mess.
I'm having all sorts of problems with the resx. I'll do it later.
Time to walk my dog.
 
if it's the RubberduckUI.resx, there's a "duplicate" up there. Later.
 
alright wonderful. now I got ssh tunneling working from my Windows to my linux machine ...
 
10:03 PM
RetailCoder.VBE	Merge pull request #3579 from Vogel612/german-i18n	a day ago
Retailcoder.VBE/UI	Make CodeMetrics Headings refer to the i18n Resx	8 days ago
aint that lovely.
 
did I bork that one?
 
no that was in my repo
 
> Continuation of previous PR that was accidentally merged prematurely.
 
remember few days I mentioned having dupes?
I thought I had fixed it but I only fixed my local repo but not my GH fork which still had it and it got merged into the RD's repo.
Hopefully the new PR will fix it for real good
 
10:14 PM
@this I'm adding the ability to read the persisted project, which means, if the project is saved, we'll have access to the compilation constants.
 
does that imply that one'd have to open the dialog to get it loaded initially?
 
@this Pull this checkin did: github.com/Hosch250/Rubberduck/commit/…
That fixes the height issue. I haven't gotten it to always display the dropdown.
 
@this No. I'm reading from the VBProject.bin in the persisted file. If the project is dirty/unsaved, then reading the binary will give stale results.
 
 
1 hour later…
11:40 PM
Well, i know that OASIS-SVN can trap for Ctrl+S in VBE, and I think the default Save button can be replaced with our custom Save button, so we can handle that and re-read.
 

« first day (1275 days earlier)      last day (1905 days later) »