« first day (2527 days earlier)      last day (136 days later) » 

12:00 AM
How do I explain it?
I can take something that's pre-existing and modify it. There's a framework already there.
To go from no files, nothing, and build up from there - that's what I'm missing.
Doesn't matter. You've done open source. Put your GH account on your resume.
With RD half the jungle is already built. I can get my banana and build the few extra trees I need.
[MDoerner/AdventOfCode2020] 3 commits. 469 additions. 68 deletions.
[rubberduck-vba/Rubberduck] 1 opened issue. 1 closed issue. 4 issue comments.
[Zomis/FactorioMods] 4 commits. 42 additions. 4 deletions.
[Minesweeper] Games Played: 46, Bombs Used: 25, Moves Performed: 6505, New Users: 5
You have this all wrong. The normal course is this: 100 developers develop. Of those, 10 developers contribute. Of those, 1 developer creates a new, popular, public repo. I am immensely proud of my modest contribution, despite having only 142 downloads. You're firmly in the 10% (probably more like 2%).
12:06 AM
Yep. You're a developer.
Go get a great job
I can write code. I don't consider myself a developer yet.
Developers know how to set things up. They get things started and build from that.
No developers do.
No training, course or qualification can prepare you. You just have to dive in. It's what we all did.
Apply for something that slightly scares you, and build from there.
OK, let me put it like this... If you're a developer, you take on the challenge of "making things happen". At the outset, you don't know how or even if it's possible to get there, but you have a hunch it should be. That's based on experience, and you have plenty of that.
IME, if you understand how things should work, you can devise how they will work in your system.
tl;dr:believe in yourself. You're ready.
If you wait to be ready, you never will be.
12:37 AM
@mansellan that's what I told my wife and before we knew it... it was twins lol
but, out-of-context literal dad jokes aside, that's all true.
@MathieuGuindon I guess it worked - kudos!
@mansellan Thanks for the confidence.
@IvenBach I've seen your commits.
12:56 AM
I've made progress on them.
@IvenBach Yes. Yes you have.
1:18 AM
1:43 AM
@IvenBach it's very much wrong to assume we know how to set things up... We're really all just making it up as we go.
Sometimes we're lucky and have seen something similar before, so we know what to search for instead of having to guess
2:36 AM
@Vogel612 @IvenBach indeed... one quote that always stuck out to me was this: experience is recognizing the mistake you've made before when you make it again.
3:34 AM
unless there are further review comments, #5751 Peek Definition is ready to ship
well, as soon as it builds
3:45 AM
It was really hard learning all new concepts, several at the same time, without any reference.
And added to that VBA doesn’t have any packages you can download and start using.
4:38 AM
merged #5744 qualifying references
6 hours later…
10:50 AM
Simon says that he has some intermitted file system problems with the machine Duga runs on.
There isn't an easy fix and Duga will be unreliable until it has been resolved.
11:24 AM
@MathieuGuindon Maybe that's get us Americans off of our Imperial measurements kick...
That said, some links to reading material about what the metrics mean and why the flagged is bad would help for those who don't really know what they mean. (Thinking 99.9% of VBA devs, here.)
11:55 AM
@FreeMan Coming soon to a school near you: Bobby is driving 100 kilomiles per hour. His car, with him and his load included weighs 1200 kilopounds. How many kilopower will it require his car to sustain the trip?
As I typed that, I thought it odd that we kicked the Imperials out almost 250 years ago, but have tenaciously clung to their system of measurement. We're a weird lot...
My theory is just because it works well enough, in spite of its inconsistency.
@this That... makes my head hurt. It also seems much like the kind of transition we'd make.
but it doesn't work all that well... How many teaspoons in a pint?
I don't know, but when was the last time you needed to convert a pint into teaspoons?
I don't, and I can't easily on that once a decade when I need to.
12:02 PM
so why worry?
@this BTW, we can safely emulate the British with BHP instead of kilopower, I'd think.
@this cause I'm tired of multipling kilopounds by 2.2 and temperatures by 9/5 :(
@FreeMan Nah, they'll just make up a new unit just out of spite.
@this the newtonjoule
I'll call it the "jewton"
At least we don't weigh people by stones as brits do.
I find it odd that we say we weigh X kilograms or Y pounds but they are not compatible units. We should be reporting the weight in newtons/pounds and the mass in kilograms/slugs.
Yeah, but my car gets 47 rods to the hogshead!
12:10 PM
Please don't tell me it's a real thing.
I'm picturing your car whacking 47 rods on a hog's head.... Not a pretty picture.
sounds to me we didn't shoot enough redcoats in the old war.
a hogshead is 252 gallons of wine, 48 gallons of ale, or 54 gallons of beer. Because consistency.
a modern rod is 16.5 feet.
hrm... 775 feet of forward propulsion for 252 gallons of wine. Sounds like top fuel dragster mileage to me!
12:27 PM
and the hog is now dead because of all the blunt force trauma to its head
12:39 PM
You do know that the new units for the speed of light is furlongs per fortnight.
12:51 PM
@this oy! mumble mumble troublesome colonists mumble ;-)
1:03 PM
@mansellan well, Freeman's right. It's weird that we gone to the trouble of dropping all those 'u' and making our own dictionary but kept the imperial system.
meh, good nuff, Noah Webster said.
@this Ah, the question is, did we drop the 'u' or did they add it after we left?
no idea...
I was told Noah Webster made that decision to drop the u from several words.
huh... #TIL
1:21 PM
Hi, I don't know if it is bug or i am doing anything wrong but Encapculate field refactoring is not working for some cases. Like in the image it is not showing any property. I am using the latest version which was released four days ago. in previous version it was working.
Did someone notice this type of unusual things ? Or am i doing something wrong?
Just to clarify - in the screenshot there are no fields. So the refactoring has nothing to select from. Were there fields originally?
Private This as TunitPrice>> this is the field
yes but the point of the refactoring is to convert Private Foo As String into a property; there are none and the This field is not considered, I think
The UDT variable is (correctly) being picked up as the UDT backing structure, as such it makes no sense to... make the UDT recursive?
The issue here is that I think you want to expose the member of UDT as a property, right?
1:32 PM
Oh - yeah that's not a use case that was considered
in which case Encapsulate field refactor feels funny - it's not meant to do that, I think.
The refactoring does not allow exposing a Private UDT on a Class.
Neither does the compiler FWIW
The refactoring will generate Properties for all the UDT members
Actually i was using this encapculate field option to get all the property let and get method for each of the member of the UDT.
1:34 PM
See, I think that's the confusing thing. When we encapuslate the fields into a UDT, we get properties.
but in this case, we already have an UDT, but we want to extract properties out of it.
Hm you worked too hard - just declare a bunch of public fields, the refactoring takes care of everything else
why shouldn't I be able to write a UDT and ask the ducky to make me some properties from that?
So i need to declare the variable under UDT and then if i use encapculate then it will generate all the property for me. and i can get all the property and then i delete those which is not necessary.
@MDIsmailHosen Right now, yes.
@this you should, but I don't think it works that way atm
1:36 PM
@MDIsmailHosen I was able to re-create your scenario. If you close the EF and re-open it, the properties (in my case) are provided.
Yes, I think what we really want to do is split the encapsulate field and extract property
@BZngr hm sounds like a bug?
@this ooh yes!
so that each can be a refactoring action but when we handle the former, we can do the latter automatically.
Like this one is working
It is generating all the property for that UDT members.
@MathieuGuindon Yes - I think there is a state issue once you pick Wrap Fields in Private Type.
Un-selecting it does not yield the last image provided by @MDIsmailHosen ... but it should.
1:39 PM
Yes. It was working in the previous version but now it is not working. I don't know why.
@MDIsmailHosen mind opening a github issue so that it can be tracked?
Semi-relatedly, I think the list should have "name" and "read-only" column instead of there being a box to edit the name of the selected item.
yes, love the idea.
that also makes it easier for us to indicate whether a UDT member ought to get a corresponding property. I have cases where some UDT member should not get a property procedure created.
Definitely a number of UI improvement opportunities.
@this yes. I also have some scenario where i need to use some member only within that class and i need to use it in multiple sub.
1:41 PM
that could be converted into a single dropdown --- No property | Read-only property | Read-write property
With version
Yes. Now check Wrap in Private Field select TUnitPrice as the target..and then uncheck. Do you end up with no properties in the Preview?
@BZngr Previous version is enlisting all of the property. I am checking the new version again.
This is the issue..It is adding one more this as of it own and i need to check the accurate one in there.
definitely a bug
Yes...definitely some things to trackdown here. I'm currently running an older version...and, so far, I cannot find a way to recreate what is in the image.
1:54 PM
@MathieuGuindon In renaming case i have also noticed that if i rename any member of UDT then property name is not renamed accordingly. It just rename this.NewName. Maybe it can be improved too.
I believe there is already an Issue logged related to that.
curious if Enum members do the same
we always forget about Enum and Type stuff lol
@MathieuGuindon can you say more?...'do the same'
if we rename an enum member its qualified uses should be renamed too
1:58 PM
In my mind, Property Foo and This.Foo are 2 different names.
oh, #ImAnIdiot... it's the UDT -> Property relationship that's the problem here
so if I'm renaming This.Foo, I only want to rename all usage of This.Foo, not the Property Foo, and vice versa.
@this they are - but a smart ducky would detect it and prompt the user whether to rename the same-name backing UDT member, no?
sure as an explicit choice
not automatically
definitely not automatically
kind of like how R# lets you "rename related identifiers in comments and string literals"
with a checkbox
2:00 PM
@BZngr 5566
@MathieuGuindon FWIW, looks like enum renaming works as would be expected
5 mins ago, by Mathieu Guindon
oh, #ImAnIdiot... it's the UDT -> Property relationship that's the problem here
Another thing i have noticed that could be improved is that if i want to add new member of UDT then encapsulate does that and it add that member at the end of the UDT which is good but property comes at the very beginning which could be add at the end and it will contain the order. It's personal choice though.
2:17 PM
I think there's an old issue about something like a "sort members" feature that could enforce consistency of how members are ordered in a module across a project
technically the rewriter can insert a new member anywhere it needs/wants it in the module though
it can but it get messy if you have it interspersed with other stuff.
hmm, can we execute it as 2 separate rewrites? one to delete, other to insert?
not if you're swapping entire scope/procedure blocks, I don't think the rewriter would flinch
2:34 PM
Grouping Properties in some order relative to their associated backing UDTMember comes right back to the notion that there is some reliable way to associate the two. Annotate the UDTMember, Property or both?
If the name (and data type, perhaps) matches, it's a go, otherwise don't bother? Having different names for the backing UDT members kinda defeats the whole point of the backing UDT

We're all idiots

Aug 22 '19 at 19:34, 15 minutes total – 24 messages, 6 users, 1 star

Bookmarked Aug 22 '19 at 19:52 by Mathieu Guindon

@BZngr @FieldFor("PropertyName") could work for this
But it's not refactoring-friendly....
Unless we make Rename look at @FieldFor annotations
Ugh a whole can of worms right there lol
True. When first generated - using the names and types for the association seems fairly reliable. I'm thinking about all the changes that could take place over time. The tidy associations created by the initial refactoring can all be gone.
2:49 PM
I maintain that a backing UDT with members having names different than the property they're a backing field for, significantly reduces what's gained from using a backing UDT. Enough IMO, for Rubberduck to ignore different-name members.
As far as placing a newly generated encapsulation Properties in a 'sensible' place: that seems like something that EF should/could support with user input. Let the user re-order the members as they like while within the refactoring.
tbh that could be a feature of the preview box or something
like, any generated code earns the ability to be placed where the user wants it
not exactly the simplest, but would be nice :)
@MathieuGuindon nice stuff is never easy. That's why there's so little of it.
3:27 PM
> Logging this issue with incomplete information so it can be tracked. So, better info TBD.

From chat 5/7/2021 6:20am (created a bookmark - but could not find how to provide it here).

**Rubberduck version information**

Starting with a Private UDT and UDT instance field, there are user interactions that can interfere the Preview of Properties.

**To Reproduce**
This is likely the MCVE.

1. Start with:

Option Explicit

Private Type TUnitPrice
@BZngr it's hidden behind the [Info] link: chat.stackexchange.com/rooms/info/14929/…
> **Justification**
By default `EncapsulateField` places new Properties at the top of the Module Code Section. For scenarios where properties related to the `UDT` already exist, the default placement of the new properties are likely _not_ where the user would prefer them

Allow the user to interactively place generated properties within the module.
3:59 PM
oops, didn't mean to steal that checkmark @BigBen
no worries
totally not motivated by imaginary internet points
tB now has attributes! That is wicked!
@BigBen well that was slightly sarcastic, gamification does motivate me. #DopamineHit
It appears the program UI does highlight the results. Noting thrice that you don't want to highlight the resuts doesn't tell us what you do want it to do. We're looking at red circles and a rather passive-aggressive post, and there's no mention whatsoever of anything you might have tried, like this, or this. — Mathieu Guindon 42 mins ago
@this you are about to be tried, twice.
makes a memo to stop hanging out at a meat market
4:53 PM
@this ikr - I tagged that GH comment with Party and Heart emojis :-)
5:13 PM
I'd love to ask the guy who thought it was a fantastic idea to allow enum names to be bracketed and prettify it away.
5:48 PM
I think this is a very understandable bug and just shows that you should write unit test for strange cases as well.
@this I was thinking, as an alternative to postfixing the attribute, it could be escaped c# stylee, i.e. @[Description("Don't use this enum value, it will launch the missiles!")]
at-symbol for escape
6:05 PM
suggest to wayne
ok will do, wanted to sound out the idea before, uh, sounding out the idea...
tbh i didn't even know @ could be used to escape
6:27 PM
yeah, it's occasionally useful, for example if you really want to use event as a variable name...
3 hours later…
10:01 PM

« first day (2527 days earlier)      last day (136 days later) »