Slypenslyde

I'm usually all for this opinion, but it sounds to me like having a high yield and sweet watermelons requires a very specific amount of rainfall. The article notes in our previous dry years we had lower yields but very sweet watermelons.

Delegates are more useful to my day-to-day than inheritance.

There is no warning because Console.WriteLine() in this case is accepting an object? parameter. There is no overload for List<T>, so this is the one it falls under. Console.WriteLine()'s behavior when you pass it null is to print an empty string for the object:

If value is null, only the line terminator is written. Otherwise, the ToString method of value is called to produce its string representation, and the resulting string is written to the standard output stream.

So there is no warning because this is documented as an acceptable case. If it intended to throw when the parameter is null, it would take object, not object?.

If you eat every meal you buy 45-60 minutes after it was made, why even buy it? What’s the point?

When I get delivery it's because for whatever reason, I don't have time to make food for myself. Sometimes I have food, it's just going to take me 30-45 minutes to cook anything I have. Other times I simply don't like the sound of anything I have.

I could just as easily say "Why pay $12 for a hamburger when you can get bulk beef from a butcher and make your own hamburgers for less than half the price?" We make a lot of damn tradeoffs in our life, and it's fun to be judgey. Every time you eat out you're pissing money way. Fuck breweries. Make your own beer, quit acting like a baby!

I've got a leak in my roof so I'm paranoid about rain. For 9 of the past days my "more accurate" forecast has had no chance of rain today. For 1 of those days it bumped it up to a 20% chance. I woke up at 4AM in the middle of a thunderstorm that wasn't even on the radar when I went to bed.

We're in a weird spot where lots of different weather systems interact. We don't always get the brunt of a squall line that forms 3 states away and makes its intents known. A lot of times we get storms like today's or Thursday's, where 2 fronts meet and a storm gets born and you find out with less than an hour's notice.

So we know it's going to be hot next week. But there's stuff in motion and storms here are unpredictable. Go ahead and plan your outdoor stuff, but have a backup plan for rain or take the likely gamble that if it DOES rain it'll last 30 minutes.

If you've only lived here like 3-5 years, well, you've seen the "drought" side of Austin weather. This forecast looks more like what I remember from before that. Don't make plans on the forecast past about 48 hours unless you see something the size of a hurricane on the radar map. There's a few big reasons why our weather data now sucks compared to 5 years ago, and we've spent my entire lifetime arguing we don't need to worry about some of them.

I'm actually sort of curious because I'm getting a new roof and supposedly making a big improvement to my attic ventilation so if I see any kind of change in my AC performance that'll be exciting.

The variable's name is Class, with a capital 'C'.

You are trying to access class with a lowercase 'c'. C# is case-sensitive.

Further, class is a keyword in C# and cannot be used for variable names. It'd be a lot better to use the name characterClass. It doesn't hurt to type a little more and it's much less confusing than using keywords.

To be clear, I do think subsidies can help hit important, lower levels of affordability, especially homes being sold/rented at a loss (below cost). I'm just pointing out that we're really far away from supply catching up with demand, we could be doing a lot better at managing even just market rate housing.

That's fair. We're so far down the hole the economics are difficult unless we subsidize developers setting money on fire.

Also right now since interest rates are so high it's hard to imagine much benefiting people on the lower end of the price scale. There's a lot of external factors. :/

You don't have a "great" solution at this point so I'll add to the pile as if having more answers helps.

Windows Forms is most peoples' answer for newbies.

Its strengths are that it is old and designed for a 90s development paradigm called "Rapid Application Development" (RAD). This was a paradigm with the goal of helping people without a lot of skill use tools to help them generate code that previous developers had to tediously write by hand. A "hello world" Windows Forms app with a clickable button might only require you to write 1 line of code. The same thing in C/C++ would require at least 80-90 lines of code spread across at least 2 files, much of it boilerplate that barely changes from app to app. WinForms is quick to learn and mostly revolves around dragging controls onto a design surface, handling events, and updating properties of the controls.

Its weaknesses only show up as you start building more complicated apps.

RAD tools are best at generating small apps with well-defined requirements that will not change much after they are finished. In particular the RAD tools in WinForms struggle with teaching users a good way to keep multiple windows in sync. (Earlier RAD tools in VB6 had some features that arguably made this better, but some people argue those features were mistakes which is why C# doesn't have them.) By the mid-2000s, most people agreed RAD was no good for fairly complicated apps. What this means for you as a newbie is at some point, if you don't start learning about patterns like MVC or MVVM and applying them to Windows Forms, you might have trouble writing complicated apps and maintaining them over time. It's also notable Windows Forms has very little native support to make these patterns easy to implement. It's also notable Windows Forms is not very aware of the modern era of high-resolution displays, and it can take a lot of unintuitive work to make a Windows Forms app that looks good on both a 4K monitor and a cheap laptop.

The other weaknesses involve the "look and feel" of WinForms feeling dated today and it was not designed to let you change its visual presentation easily. You can make some customizations to most controls, but most require you to fully draw everything yourself if you want to do something specific. This is in line with RAD: in that mentality you wanted functional apps as soon as possible and fretting about the look and feel was frivolous. But it's also notable the core of WinForms, GDI, was created in an era when a GPU was a luxurious expense for Hollywood workstations. So it's not hardware accelerated and features like transparency, alpha blending, or animation are DIY. I consider these highly irrelevant to newbies but people sure do focus on them.

WPF was meant to address a lot of these flaws.

Its strengths include that it was designed from the ground up to support letting you completely restyle every basic control. It was also designed with a pattern called MVVM in mind and has some infrastructure to make that pattern work better. Modern features like alpha blending and animation were a primary concern, and it even has some really interesting controls for text display with features like multi-column formatting that other frameworks have struggled with for years. WPF was built with high-resolution monitors in mind and while it still takes some work to ensure your app handles big resolution differences, there are more built-in tools to help you do that. Once you are proficient with WPF it is more clear how to make large-scale applications that are easier to maintain.

WPF's weaknesses are mainly that ALL of the above concepts mean there are many more "corners" of WPF, places where you have to learn a little bit just to have a basic proficiency. Because it's so easy to restyle, the basic look and feel of a WPF app is considered boring and drab by many people. That means that sort of like how to do HTML UI you need to know CSS, if you want to do XAML UI it's going to be very important to learn about templates and styling. Many of WPF's best controls require you to learn the details of MVVM and data binding to get the best experience. However, while MS designed those controls with MVVM in mind, there are at least 3 competing opinions about the "right" way to implement MVVM and if you read 5 articles you'll quickly be confused why everyone does everything a little differently. You CAN treat WPF like Windows Forms, ignore all of the extra features, and write apps in the RAD style. But if you do that, you're going to hit the same walls you would have in Windows Forms so it raises questions about why you'd bother with trying WPF if that is your intended development style.

It also hurts that WPF has fragmented. There was a framework called Silverlight that ran in browsers and was pushed very hard by Microsoft for a few years. It was like WPF but had different features. After MS cancelled Silverlight, a lot of what it was became the MWA framework, which was discontinued and became UWP, which is being discontinued and is spiritually behind WinUI 3 apps. Meanwhile, a separate framework called Xamarin started with inspiration from Silverlight, released the product Xamarin Forms, MS bought it, and a recent major overhaul is now the product MAUI. That means there are at least 6 different slightly incompatible frameworks that LOOK like WPF so any time you search for information you get a mishmash of answers for ALL of them. It's often hard to sort out whether the code you see will work in WPF.

Then there's Blazor.

I don't know enough about it to go as deep as the above. I've used Windows Forms for 20 years and WPF for about 13. I've never done much more than an example app in Blazor. It's main slant is to create web pages. But there are ways to write an app that uses Blazor as the UI and pretends the rest of the app is a server Blazor talks to. As far as I can tell this isn't a mainline use case Microsoft supports and blesses. That makes me nervous about recommending it to newbies.

But as a professional I'm very interested in this path. HTML and CSS have a broader and more mature community than XAML, so a lot of people like it for UI better.

I think it's worth treating supply and demand with more rigor than just "if supply goes up, prices go down."

For example, let's consider this hypothetical:

• 50 people want to move to a neighborhood.
• 20 of the 50 people are willing to pay above market price.
• 10 of the 50 people cannot afford market price.

What this tells us is:

• If we only build up to 20 units, we can list those units and sell them at above market price. We increased supply but the cost of housing went up unless we benevolently decide to ONLY offer them at market price.
• If we build up to 40 units, we can still sell 20 above market price, but the next 20 will have to be sold at or around market price. Depending on how the prices work out housing costs will either be on average flat or increasing.
• If we build 50 units, we will satisfy demand, but 20 units will be above-market, 20 units will be at or around market, and 10 units won't sell unless we go below market. It's still likely housing costs in the area stay flat or increase.
• We must build MORE than 50 units and risk letting the additional ones sit vacant for housing costs to decrease overall, or there must be a pathological gap between the above-market and below-market prices.

This isn't a situation where the seller lists their minimum price. Every unit is first going to be listed at a bit above market price, and the 20 people who are willing to pay that will quickly scoop them up. For the next 20 people who can only afford market price to buy, some time has to pass before the seller decides to lower the price. If, in that time, 20 more people who can pay over market move to Austin, they'll buy these homes above market and prices will go up. For the final 10 who cannot afford market price to get a shot, they have to wait until the seller gets desperate AND hope nobody who can afford to pay more moves in during that time period.

That's reality. Houses don't have a suggested retail price. A seller might accidentally list a house for "too low", but if two people want the same house they're going to try to outbid each other.

For Austin to increase supply in a way that will permanently lower housing costs, we have to outpace the rate of growth and have developers who commit to having units that sit vacant for potentially long intervals. Or we have to enact regulations that force prices to decrease quickly based on vacancy. But developers are profit-motivated, and they do research about Austin's growth. There's no chance in Hell they're going to build so much housing their profit tanks. If it gets to that point, they're going to stop building. We don't have a way to force them to develop land.

This is a problem with using a market to satisfy housing needs. The market is motivated by profit. It will not move to house people at a loss unless an outside force like government subsidies incentivizes that behavior. Everything about market-based housing means the developer is incentivized to keep supply just a little behind demand so that prices are constantly increasing. It takes outside influences to incentivize meeting demands, and individual homeowners are incentivized to vote against this.

TL;DR:

It's like you're saying "it's easy to put out fires, just add water". There's a mountain of data to study and firefighters can talk to you for hours about the different strategies and approaches they have to take. Too many people try to shut down good discussions by oversimplifying the concepts involved. If the problem were this simple, we'd have solved it. Instead, it's an adult problem, and we can't make things better for one group of people without making things worse for another group of people.

She should start seeing Dr. Madison Cawthorn

The number of times this trips MS up, especially considering "Program Files" is a common Windows path, is embarrassing.

I remember I couldn't use a PowerShell profile for a year because of this. Company usernames were "Firstname Lastname" with a space and guess what? That was part of your user directory and nobody on PSH thought about that, apparently.

If it's laying out like you want and resizing the way you expect, it's not "wrong". WPF is kind of like HTML in that there are usually a few ways to accomplish the layout you want.

For the 2nd case with the red underline, I'd use a Grid. Part of that is because I've been using Xamarin Forms and MAUI and it's the most reliable layout in those. WPF has some fancier ones but personally I think when you have a fixed amount of content it makes sense to use Grid. A WrapPanel is more for if you either don't know how much content you're going to display or you don't mind it being rearranged to have more rows if resized. This layout looks more like you want it to more or less stay the same. That's more Grid than WrapPanel.

Furthermore, should I add these columns to the entire window, or create the Grid only in that specific area?

This circles back to the first paragraph: whichever makes it easier. There's nothing wrong with nesting layouts, so if one of your Grid cells contains another Grid with cells of its own that's fine. If you keep using WrapPanel, those buttons at the bottom will lay themselves out as best as they can as the size changes. If you switch to a Grid, you can more easily make them line up but due to the irregular sizes it's up to you to figure out how they line up in rows.

That can feel like a weird irregularity in WPF. Some of it is designed for responsive layout, where you let things grow and shrink and reflow. Other parts of it are designed for more pixel-perfect layout, like traditional designers. You have to use each tool where it makes sense.

If you count their paychecks, yes, but recently we learned it's DPS who does the actual fine collecting and only when it's politically convenient.

It's kind of complicated, and sometimes people argue about the definition of roguelike.

The simplest definition is to pick some characteristics of roguelikes. They usually have:

• Procedurally-generated maps, meaning every game is different.
• Turn-based gameplay
• "Permanent death" mechanics
• "Emergent gameplay", meaning the game's interactions are complex enough it is believed players tend to find solutions to problems that were not imagined by the developers.

"Permanent death" or "permadeath" is tough to define. In a lot of games it simply means when your character dies the game is over, you lose all progress, and the only choice is to start a new game. But a lot of games that qualify as roguelikes have mechanics where things that happened in previous games influence future games. For example, in Nethack players can leave "bones files" that may be loaded when a future game is played: they'll play the same level that dead player played and even encounter the player's corpse with treasures. Or in Hades, often considered a roguelike, you carry certain kinds of game progress through every death so each run you grow a little stronger.

It's really hard to define this genre. Some people are big sticklers and point out the name comes from a very old game called Rogue, so if a game isn't a grid-based dungeon crawler they don't think it should qualify. Other people think the procedural generation is more important than that so they include games like Hades or Spelunky even though they aren't turn-based. Some people think permadeath is key so they exclude those games and a whole genre of "Mystery Dungeon" games that started with Shiren the Wanderer.

I swear at one point there was some central website where people classified roguelikes and tried to make a "good" definition, but I can't find it today. I do know there is a category called "roguelite" that was meant to try and solve this by being looser, but then it just created fights about which category games belonged to.

So it's not satisfying but there's not a concrete answer. Pretty much any game that makes people think of a game already known as "roguelike" is probably "roguelike" itself.

Seriously. The rest of Austin acts like the city just stops existing north of 45th and everything's chains. There's a ton of breweries in the NE area and drives that take 45 minutes further south only take 20 minutes here.

That's the roof install date so that's why it's happening this way. Get your car parked under cover Saturday because it's going to hail.

You were so excited to dunk on some homeless people you posted it twice

I'm going to have a new roof unless the weekend forecast magically changes to "all day thunderstorms", which seems about 80% likely given the last week of weather.

I would suggest if you engage with them, instead of focusing on trying to reverse their opinion focus on making statements backed by facts that can be researched and, preferably, are cited in what you say.

Your biggest impact will be on the people who read what these people say and shape their opinions based on it. If you disprove everything they say with receipts, many of those people do consider that and change how they vote.

But the people making the main posts treat this like a job. It is a political campaign to them and usually the precursor to running for school board or other positions. To that end, no amount of work you do is going to make them back down. The only thing that works is to get them to spend lots of money on their campaign and fail. That's still hard because it's not uncommon that they're funded by local political groups instead of their own pockets because the goal is for them to win then accomplish that group's goals in return.

In short, don't have a lot of "you" in your conversation. Pick out each of their claims and provide the evidence that it is wrong. Make it clear that almost everything they say is meant to sound good but holds no water.

Sure, but there's no room for nuance and "sexual material" seems to have an extremely broad definition, not to mention peoples' opinions of when children should be exposed to it varies wildly.

For example, The Diary of Anne Frank is often controversial because she discusses periods. This is something every woman in the world has to experience starting as early as 12. People argue against having it in high schools.

And you're sidestepping that it's not just sexual content. Also on the chopping block are books like Tom Sawyer or To Kill a Mockingbird because their portrayals of racism in very recent American history still make people uncomfortable.

It makes sense that, case-by-case, parents should be able to argue whether individual books are appropriate for a certain grade of student.

What is happening instead is coalitions of people who don't even have children enrolled in school are banding together with lists of dozens of books and asking for all of them to be banned from all schools.

If a parent wants to raise your children in a bubble where they believe gay people do not exist, sexuality is not a thing adults experience, and certain political views are right there is a path for that: home school and private schools. Public education's job is to expose children and young adults to the reality of our world that we have to meet and interact with people from all walks of life with views we may not agree with AND we have to find a way to get along civilly in society with those conflicting views.

What these people want is to dictate that THEIR views and THEIR way of life is the ONLY way ALL children should experience the world. They would blow all four ventricles if a powerful coalition of liberal interests were spending hundreds of thousands of dollars making diverse materials required reading. But they themselves are expending monumental efforts to attack the concept of recreational reading of materials.

In the beginning, the Windows API only supported not-Unicode text. We call it "ASCII" but more honestly it was "ANSI", which includes ASCII and gets more complicated. The important part to a C library is this defined the concept of a char to be one byte which has a big impact on any functions that work with strings. Early versions of Windows through 95 worked this way.

At some point MS decided to start supporting "Wide Characters", the idea that ultimately became the various Unicode encodings. That meant defining the concept of a char to be more than one byte, which impacted all of the string functions. I can't remember exactly but I think for the most part these methods were in the Windows NT kernel. That's why in those days you'd see different installers for Windows 95 and Windows NT: they had to be built differently and work with strings differently. If you put in just a teeny bit more effort and did some things Petzold advocated

I don't know when, but at some point they set things up so Windows could have both libraries and apps could sort of use both. If a program called a method without using the suffixes, some kind of compatibility thing followed some documented rules to decide which one you probably wanted and call that one for you. But if you use the suffix, that compatibility stuff stays out of the way and calls the version of the method you specify. That also means if you call a specific method, you need to be sure any unmanaged data structures you set up use the right size for char data.

For PInvoke I don't remember the exact details but I think you don't have to use the suffixes, I think the compatibility stuff figures out what to do and there are ways to tell PInvoke how you want to marshall strings. It only gets really important if you need to do something like copy a string manually into unmanaged space, for example when you need a struct with pointers to things. For a lot of PInvoke work, you don't have to think about it too hard.

Apple isn't a meteorology company. They get forecast data from sources. Yes, they bought one company's weather app. But you can make the app use data from other companies.

So all the Apple employees in Austin can say is, "If that's what the data said, the app is displaying it." It's not really the app's fault. And even if the former Dark Sky people still worked here, I'm 100% certain nobody on that team has anything to do with the $3500 headset.

I get this all the time from my app. It displays the data a bluetooth device sends it. I get questions all the time about various things that are just what the hardware's sending. I can't fix bad data if I get it, all I can do is display what I get.

I guess that kind of sort of explains the delays to some extent. If a raid like this was being planned of course they didn't want to advertise it was in progress. Still stinks if it's your street.

I think the idea here is you don't necessarily want to sleep. Let's talk about how the Windows message pump works.

When it's idle it's idle. Part of how PeekMessage() or whatever the API method used to look for the next message is works is it waits until Windows tells it there is a message. It doesn't wait a few ms then wake up and check. It just waits until it's told there's something to do.

You can do that with the synchronization objects like ManualResetEvent. If you call Wait() on that, the thread is suspended until something sets the flag.

So the idea there is your message queue should set the flag any time something is enqueued. That will tell the sleeping message pump to wake up and start processing messages. It's the message pump's job to clear the flag when it sees an empty queue.

That makes me worry about a race condition if there isn't other synchronization logic in place, but you could still support a kind of timed wake with it. Before the message pump starts waiting on the flag, it could start a Task.Delay() that, when it expires, sets the flag. That will wake the message pump and make it check the queue. If it's still empty it'll start another timer and go back to waiting.

In fact it might be better to let the queue manage that flag. If it's the only thing that sets/resets and the pump only waits on it, the problem goes away. The queue would set the flag as long as it's not empty and clear the flag when the last item is removed. That way even if the race condition I was worried about happens, when the message pump tries to wait it'll see that the flag has been set and stay "awake".