Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
JawKnee
Mar 24, 2007





You'll take the ride to leave this town along that yellow line
When dealing with the <defaultProxy> element, does useDefaultCredentials refer to this property?

Adbot
ADBOT LOVES YOU

adaz
Mar 7, 2009

JawKnee posted:

When dealing with the <defaultProxy> element, does useDefaultCredentials refer to this property?

Wow this is a mess. It looks like refers to a SystemNetworkCredntial.defaultCredential which if you look points to this internal class

code:
    internal class SystemNetworkCredential : NetworkCredential {
        internal static readonly SystemNetworkCredential defaultCredential = new SystemNetworkCredential();

        // We want reference equality to work.  Making this private is a good way to guarantee that.
        private SystemNetworkCredential() :
            base(string.Empty, string.Empty, string.Empty) {
        }
    }

JawKnee
Mar 24, 2007





You'll take the ride to leave this town along that yellow line
That... is not what I was expecting, but thank you for the very helpful answer!

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!
I am having to support a lot of conversions between .NET and my Python interpreter project for embedded .NET methods. What would be a good structure for this lookup? I'm guessing to just using a two-level dictionary of source type -> destination type -> conversion function, but I wanted to double check before I do a bunch of typing.

Jen heir rick
Aug 4, 2004
when a woman says something's not funny, you better not laugh your ass off
You could just use a Tuple as a key and have one dictionary.

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!

Jen heir rick posted:

You could just use a Tuple as a key and have one dictionary.

Okay I get what you meant. So I'm making a key be the two types (source and destination) resolve to the code that converts them. That has much more good feels.

raminasi
Jan 25, 2005

a last drink with no ice
Depending on your performance needs you may want to profile using a ValueTuple as well as a Tuple. (Note that ValueTuples can cause headaches when exposed in public APIs so if in doubt use a Tuple.)

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

raminasi posted:

Depending on your performance needs you may want to profile using a ValueTuple as well as a Tuple. (Note that ValueTuples can cause headaches when exposed in public APIs so if in doubt use a Tuple.)

IMO, tuples shouldn't be part of public APIs regardless of technical considerations.

If they're important enough to be exposed, they deserve to get upgraded to a struct or class with named fields and XML comments and all that jazz.

The exception is if you're writing something extremely abstract like a math library.

brap
Aug 23, 2004

Grimey Drawer
Are people writing new code that uses System.Tuple instead of the tuples language feature? I wouldn’t expect most people’s code to need to explicitly reference System.ValueTuple.

Tuples in C# are really nice, use them. Public API is another story of course, usually the right thing is to declare a named type in that case.

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!
This bit I'm doing is buried in some internals for what might as well be a private project, so it's double-safe for me to use goofy stuff. That being said, I was lamenting all the Tuples I was creating as keys just to see if the dictionary even had something, so I'm glad I checked back in on the thread; ValueTuple will reduce a lot of that burden.

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!
Speaking of premature optimization: is anybody else a little irritated about having to do two lookups when you're not 100% sure the dictionary should/would have what you want? In scaling complexity, it's just two, constant lookups so it's just constant time. Still, in an application that's getting pretty rough-and-heavy with Dictionaries, I'm assuming that's still a few percent on the table lost to your standard library. I guess I should just benchmark it some time.

rarbatrol
Apr 17, 2011

Hurt//maim//kill.

Rocko Bonaparte posted:

Speaking of premature optimization: is anybody else a little irritated about having to do two lookups when you're not 100% sure the dictionary should/would have what you want? In scaling complexity, it's just two, constant lookups so it's just constant time. Still, in an application that's getting pretty rough-and-heavy with Dictionaries, I'm assuming that's still a few percent on the table lost to your standard library. I guess I should just benchmark it some time.

In a lot of cases you could probably do a TryGetValue if you don't know it's an entry. Edit (but yeah I wouldn't sweat stuff like that without profiling)

rarbatrol fucked around with this message at 19:18 on Feb 2, 2020

insta
Jan 28, 2009
Dictionaries are really, really fast. Millions of lookups per second on an average desktop.

adaz
Mar 7, 2009

insta posted:

Dictionaries are really, really fast. Millions of lookups per second on an average desktop.

this assumes the dictionary isnt huge but yeah in general I wouldn't worry about the 2 lookups. Chances are relatively high if the size of the dictionary is reasonable its a low value. The thing to worry about though is if you overriding gethashcode() and have a complex op in there. That _will_ destroy dictionary lookups.

Malcolm XML
Aug 8, 2009

I always knew it would end like this.

NihilCredo posted:

IMO, tuples shouldn't be part of public APIs regardless of technical considerations.

If they're important enough to be exposed, they deserve to get upgraded to a struct or class with named fields and XML comments and all that jazz.

The exception is if you're writing something extremely abstract like a math library.

Nah, it's often extremely useful to have small tuples as a way of returning multiple arguments.

Anything beyond triples probably deserves to be a struct/class

insta
Jan 28, 2009

adaz posted:

this assumes the dictionary isnt huge but yeah in general I wouldn't worry about the 2 lookups. Chances are relatively high if the size of the dictionary is reasonable its a low value. The thing to worry about though is if you overriding gethashcode() and have a complex op in there. That _will_ destroy dictionary lookups.

I haven't really noticed slowdowns, unless I'm swapping. I use dictionaries for their insane lookup performance when running 5-8 million entries.

Definitely agreed on the GetHashcode performance though (and Equals).

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!
Reflection e/n: That moment you've got a whole good thing going with MethodInfos, decided to throw the constructor at it, and find out those aren't. Instead, they are MethodInfo's bastard cousin, ConstructorInfo. Because, you know, a constructor can't be a method with the return type of the class it constructs...

...yes, yes, I got most of what I needed with MethodBase, but my heart sank when I found that out.

Funking Giblet
Jun 28, 2004

Jiglightful!

Rocko Bonaparte posted:

Reflection e/n: That moment you've got a whole good thing going with MethodInfos, decided to throw the constructor at it, and find out those aren't. Instead, they are MethodInfo's bastard cousin, ConstructorInfo. Because, you know, a constructor can't be a method with the return type of the class it constructs...

...yes, yes, I got most of what I needed with MethodBase, but my heart sank when I found that out.



What would a static constructor return in that case.

raminasi
Jan 25, 2005

a last drink with no ice

Malcolm XML posted:

Nah, it's often extremely useful to have small tuples as a way of returning multiple arguments.

Anything beyond triples probably deserves to be a struct/class

ValueTuple fields are named, too!

Rocko Bonaparte
Mar 12, 2002

Every day is Friday!

Funking Giblet posted:

What would a static constructor return in that case.

I dunno, void? Alternately: my frustrated, shaking butt.

Hughmoris
Apr 21, 2007
Let's go to the abyss!
I'm a hobbyist programmer, and a novice with C#. I'd like to create a simple desktop app as an exercise to better learn how to create a GUI. I'm thinking the app will be used as a front-end to the StackOverflow database (local db) and the user can choose different query parameters and filters etc...

I'm not sure where to start. After doing some research/reading it seems like UWP is dead (long live UWP), WinForms is too old, WPF too hard, and something new called WinUI.

Any recommendations on where I should start?

New Yorp New Yorp
Jul 18, 2003

Only in Kenya.
Pillbug

Hughmoris posted:

I'm a hobbyist programmer, and a novice with C#. I'd like to create a simple desktop app as an exercise to better learn how to create a GUI. I'm thinking the app will be used as a front-end to the StackOverflow database (local db) and the user can choose different query parameters and filters etc...

I'm not sure where to start. After doing some research/reading it seems like UWP is dead (long live UWP), WinForms is too old, WPF too hard, and something new called WinUI.

Any recommendations on where I should start?

In general, desktop GUIs are super dead. It's all web apps and mobile apps nowadays. That said, Microsoft brought WPF and Winforms to .NET Core 3, so WPF would probably be the recommended path forward for desktop GUI apps. In general, if it's not in .NET Core or coming to .NET Core, it's on life support.

adaz
Mar 7, 2009

Hughmoris posted:

I'm a hobbyist programmer, and a novice with C#. I'd like to create a simple desktop app as an exercise to better learn how to create a GUI. I'm thinking the app will be used as a front-end to the StackOverflow database (local db) and the user can choose different query parameters and filters etc...

I'm not sure where to start. After doing some research/reading it seems like UWP is dead (long live UWP), WinForms is too old, WPF too hard, and something new called WinUI.

Any recommendations on where I should start?

What new york new york said basically but a few weeks back I wante dto see how WPF was (literally hadnt touched in like a decade) and found this channel 9 series a solid quick overview

Mr Shiny Pants
Nov 12, 2012

Hughmoris posted:

I'm a hobbyist programmer, and a novice with C#. I'd like to create a simple desktop app as an exercise to better learn how to create a GUI. I'm thinking the app will be used as a front-end to the StackOverflow database (local db) and the user can choose different query parameters and filters etc...

I'm not sure where to start. After doing some research/reading it seems like UWP is dead (long live UWP), WinForms is too old, WPF too hard, and something new called WinUI.

Any recommendations on where I should start?

Fabulous is cool, none of the 2 way binding stuff. Makes it a lot simpler. It is F# though.

https://fsprojects.github.io/Fabulous/Fabulous.XamarinForms/

Cuntpunch
Oct 3, 2003

A monkey in a long line of kings

Mr Shiny Pants posted:

Fabulous is cool, none of the 2 way binding stuff. Makes it a lot simpler. It is F# though.

https://fsprojects.github.io/Fabulous/Fabulous.XamarinForms/

Depending on how many brainworms you have from non-functional UI programming models, the MVU cycle honestly might make more sense to someone coming to UIs untainted. And while functional languages like F# make it easier to implement, it's still something you could put together in C#.

Mr Shiny Pants
Nov 12, 2012

Cuntpunch posted:

Depending on how many brainworms you have from non-functional UI programming models, the MVU cycle honestly might make more sense to someone coming to UIs untainted. And while functional languages like F# make it easier to implement, it's still something you could put together in C#.

That is what I was getting at, MVU is just a lot simpler to understand in my opinion, stuff flows one way and that's it.

EssOEss
Oct 23, 2006
128-bit approved
What is a mvu?

mystes
May 31, 2006

EssOEss posted:

What is a mvu?


Model-View-Update (the react/elm model)

Cuntpunch
Oct 3, 2003

A monkey in a long line of kings

mystes posted:

Model-View-Update (the react/elm model)

To expand on this:

You have a model that represents the state of the page.
You feed that model to a View function to generate the HTML for the page.
The interactive bits are wired up to dispatch messages (buttons, etc), and that triggers the Update function, which takes the type of message and the model, and generates a new model.

EssOEss
Oct 23, 2006
128-bit approved
That sounds like it is worth trying. While MVVM and MVC are okay, I always felt like one could do better, so experimenting with this model might be of interest. Is there some straightforward way to apply this model to .NET UI frameworks? WPF/ASP.NET/WinForms/whatever? What should I do to avoid reinventing wheels when I experiment with it?

mystes
May 31, 2006

EssOEss posted:

That sounds like it is worth trying. While MVVM and MVC are okay, I always felt like one could do better, so experimenting with this model might be of interest. Is there some straightforward way to apply this model to .NET UI frameworks? WPF/ASP.NET/WinForms/whatever? What should I do to avoid reinventing wheels when I experiment with it?
The main problem with implementing it yourself is that in the MVU model, the "view" is a pure function that converts the model to some sort of markup or tree representation of the gui. In other words, each time anything changes, the view function outputs a representation of the new state of the gui that has no connection with the previous state. However, obviously in a normal gui library you can't just remove all the widgets and add them back every time anything changes, so you need a diffing algorithm to figure out what actually needs to be changed.

In an MVU program, the model is just an object (immutable generally) that represents the state. The View function just takes the model and outputs whatever. The update function takes events and updates the model (or rather outputs a new, updated model).

The MVU library basically is just running the view and update functions in a loop, BUT it needs the diffing algorithm to figure out how to actually update the underlying gui given the last two outputs of the view function.

The basic idea is incredibly simple, but if you want to implement it yourself you will have to implement the diffing algorithm yourself.

I don't know if there's any c# MVU library for desktop guis but maybe you could use fabulous from c# if you really wanted to?

mystes fucked around with this message at 18:38 on Feb 8, 2020

Cuntpunch
Oct 3, 2003

A monkey in a long line of kings

mystes posted:

The main problem with implementing it yourself is that in the MVU model, the "view" is a pure function that converts the model to some sort of markup or tree representation of the gui. In other words, each time anything changes, the view function outputs a representation of the new state of the gui that has no connection with the previous state. However, obviously in a normal gui library you can't just remove all the widgets and add them back every time anything changes, so you need a diffing algorithm to figure out what actually needs to be changed.

In an MVU program, the model is just an object (immutable generally) that represents the state. The View function just takes the model and outputs whatever. The update function takes events and updates the model (or rather outputs a new, updated model).

The MVU library basically is just running the view and update functions in a loop, BUT it needs the diffing algorithm to figure out how to actually update the underlying gui given the last two outputs of the view function.

The basic idea is incredibly simple, but if you want to implement it yourself you will have to implement the diffing algorithm yourself.

I don't know if there's any c# MVU library for desktop guis but maybe you could use fabulous from c# if you really wanted to?

Some colleagues of mine got drunk on Casey's IMGUI and proof-of-concepted it with C# using WinForms in Linqpad to prove a point. So it isn't actually *that* bad to do ad-hoc UI stuff. The crazy newing up might get a bit...GC-hungry though?

mystes
May 31, 2006

Cuntpunch posted:

Some colleagues of mine got drunk on Casey's IMGUI and proof-of-concepted it with C# using WinForms in Linqpad to prove a point. So it isn't actually *that* bad to do ad-hoc UI stuff. The crazy newing up might get a bit...GC-hungry though?
Doesn't IMGUI redraw everything every frame? If so, that would probably be the exception where you don't need diffing in which case it would be trivial. I actually thought about mentioning that but it seemed like unnecessary tangent.

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

When I have to add new forms to an old VB.Net Winforms desktop app I write them in MVU-ish fashion. The Winforms event handlers just update the _model object and then call Render(), where Render() updates every control to match the model.

It's not true MVU because it lacks a diffing step, but as long as either

(a) the graphical components are coded well enough to notice you're setting e.g. a Datasource property to the same object and ignore it as a no-op

or (b) the form is small/fast enough that it's not noticeable that you're re-rendering a bunch of stuff

then it works fine, and it still offers most of the MVU advantages like trivializing the implementation of an Undo button (just keep a stack of Model objects).

The only real footgun is accidental infinite loops via e.g. TextChanged events triggering themselves, but they usually make themselves known the very first time you use your form.

Cuntpunch
Oct 3, 2003

A monkey in a long line of kings
That's the second time someone has mentioned diffing with the implication it's part of the MVU architecture and I'm curious where that's coming from. Maybe I just haven't dug deep enough into MVU library code in things like Elmish(which I've used) or Fabulous(which seems to largely crib from Elmish) - but at least in a 'pure functional' sense, there's not a lot of space in the signatures for diffing(and, conceptually, diffing requires holding state)

You define your model type as *whatever*
You define a message type as *whatever*
You define a View method that takes in a model and spits out a UI, including bindings that generate messages.
You define an Update method that takes a message, the current/old model, and spits out a new model (and possibly a message)

That's pure MVU - diffing is an implementation detail and it would seem the only way to get at it would be to ensure that the View method is a closure into a stateful object so that it can 'see' the previous View output and tweak it - or to add additional functionality 'outside' the MVU loop.

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

I agree that diffing is technically an implementation detail, but without some underlying system that preserves view state MVU can become effectively unusable.

E.g. imagine a hypothetical web MVU library that naively triggered a page refresh on every update!

Or for a slightly less extreme example, if it naively wiped and re-created every element in the page, in order to have a usable form you would be forced to use your model to keep track of stuff like cursor position and focus - a giant abstraction leak.

mystes
May 31, 2006

Cuntpunch posted:

That's pure MVU - diffing is an implementation detail and it would seem the only way to get at it would be to ensure that the View method is a closure into a stateful object so that it can 'see' the previous View output and tweak it - or to add additional functionality 'outside' the MVU loop.
In some sense you could technically consider diffing an implementation detail, because it's not needed for some implementations where you redraw everything each time you call the view function.

However, the need for diffing with the MVU model in html or normal gui frameworks is a result of a fundamental and profound limitation of the MVU model: the view function spits out two different outputs with no way to understand how they're connected. It's fundamentally impossible to fix this if your view is a pure function that maps from model to UI. If you use MVU and there are reasons you have to avoid destroying and recreating elements/widgets (e.g. losing cursor focus as NihilCredo said), diffing is the ONLY way to do this.

It might seem like you should be able to avoid diffing, but if you look at other approaches for guis in pure functional languages that try to avoid diffing by somehow retaining state (e.g. FRP), these approaches are fundamentally different from MVU and much more complicated, so I think that the role of diffing is actually far more significant than it would initially seem.

putin is a cunt
Apr 5, 2007

BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION
This is a good example of why throwing functional programming at every problem is not gonna work.

Boz0r
Sep 7, 2006
The Rocketship in action.
I have a constructor that should only be called from a factory. How do I give the other devs a warning and refer them to the factory(also suppress the warning in the factory) if they try to use it? I was thinking of using Obsolete, but the constructor isn't obsolete.

Adbot
ADBOT LOVES YOU

SimonChris
Apr 24, 2008

The Baron's daughter is missing, and you are the man to find her. No problem. With your inexhaustible arsenal of hard-boiled similes, there is nothing you can't handle.
Grimey Drawer

Boz0r posted:

I have a constructor that should only be called from a factory. How do I give the other devs a warning and refer them to the factory(also suppress the warning in the factory) if they try to use it? I was thinking of using Obsolete, but the constructor isn't obsolete.

You can put the factory and the object in their own assembly and make the constructor internal.

You can also use nested classes, but I have never tried this and can't vouch for the results: https://www.tutorialspoint.com/what-is-the-chash-equivalent-of-cplusplus-friend-keyword

I wish they would add friend declarations to C#, for this exact purpose.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply