.NET Megathread 3.5: await GetGoodPosts()

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›6 »

Gul Banana: Nov 28, 2003

crashdome posted:

I've never used Git because gently caress command line. Although, I do find TFS a bit confusing at times. I thought Git would be more confusing. Is that not true? Can I seamlessly browse my projects in VS with Git?

not from within VS, no. if you open a solution that's within a git repository it detects it and opens the repo in VS, so that's what i do.

quote:

Can I type a comment in a textbox and push pending changes to Git? I'm a lone developer with a few read-only accounts to my projects.

yes, commits merge pushes all work.

the vs git integration was not great until recently, but in 2013 i like it a lot

# ¿ Jun 20, 2014 21:08

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 10:08

Gul Banana: Nov 28, 2003

The 'easy fix' is typically to ConfigureAwait(false) so that you don't get marshalled onto a blocked context. however it's irritating and gives up many of the actual benefits of async.

The 'right fix' is that async code should be top-down, not bottom-up. The requirement to use async apis is an asynchronous event loop. Such as: WPF event-handing "async void"s, or ASP.NET actions. if you don't have one of those available, you have to return Task yourself; it can't be safely encapsulated. People get in trouble when they try to use async methods *internally* to implement a non-async thing. Even given that constraint, await is pretty fantastic.

# ¿ Jun 21, 2014 11:46

Gul Banana: Nov 28, 2003

that would require investing any money in WPF ever again, though. so it ain't gonna happen

# ¿ Jun 21, 2014 18:43

Gul Banana: Nov 28, 2003

for the other stuff it's like.. you're totally right that this stuff is not correctly generalised as it could be if they'd just put a little more mathematics into it. linq overall reads as a *rediscovery* of monads, to the point that using SelectMany as bind/>>= is needlessly obtuse. however: there's an alternative case to be made that it's a useful extraction of the common-case benefits into comprehensible patterns.

*IF* you accept the premise that M[a] is too hard for many developers, then the list monad in the form of IEnumerable<a> is a great compromise. collections cover a lot of stuff! collections with generators cover more - it's rare for people to use interesting generators, but being able to do this sort of thing

code:

class HasOneThing : IHasManyThings {
    IEnumerable<Thing> GetTheThings {
       yield myOneThing;
    }
}

is still great. async and await, if only they didn't have the danged context wart, really are a great simplification over callbacks, and the Task<T> abstraction has proven itself.

there's evidence out there. note that Scala, which already had Future and generalised do-notation, added async & is chatting happily about it. heck in .net we already had Linq 2 Tasks, weird as it was. i've seen people write this:

code:

var result = from x in GetXAsync()
              from y in GetYAsync(x)
              select CreateResult(x, y);

and i was not particularly happy to see it, but, it did work. await works better, works clearer.

# ¿ Jun 21, 2014 18:53

Gul Banana: Nov 28, 2003

so with List and Future you have maybe 90%, 99% of the monadic power that Joe Applicationdeveloper can really use. each gets its own special case syntax. for that matter so does IO, which has "the assignment operator". Microsoft's implicit argument here is that by addressing each of these use cases as its EROI becomes high enough, they're frogmarching the world forward as fast as it will grumbly-shuffle. until someone comes up with a piece of software that doesn't need to be maintained, idk that we have proof otherwise.

# ¿ Jun 21, 2014 18:58

Gul Banana: Nov 28, 2003

list+future IS a real problem. at that point you need IObservable, which is sort of half built-in to the language and doesn't follow the same api conventions...

my only defense of .NET there is "many programs don't need it". but one of my current projects does, and suffers from the lack ;_;
it's an ORM which hasn't been able to move to a fully asynchronous read-side API, because that doesn't compose with IQueryable. even internally it has problems needing to do things like reify sequences into lists so that disposal of db handles can take place - unnecessary data copies b/c the streaming and iterating abstractions don't compose with the deferral and concurrency abstractions

Gul Banana fucked around with this message at 07:52 on Jun 22, 2014

# ¿ Jun 22, 2014 07:46

Gul Banana: Nov 28, 2003

presenting: casual basic. imagine this everyday scenario: you'd love to use Microsoft Visual Basic .NET but just cant bring yourself to reach for the shift key. if only it was Microsoft visual basic .NET. case-preserving case-insensitivity? there has to be a better way.

now there is a better way.

license: anybody can use it for anything

# ¿ Jun 27, 2014 13:20

Gul Banana: Nov 28, 2003

ultimately winforms designer work translates directly into .cs or .vb code generation. you SHOULD just be able to copy the code changes across if you do it textually or with some non-VS tool

# ¿ Jul 11, 2014 14:14

Gul Banana: Nov 28, 2003

gently caress them posted:

So I'm on .NET 4.5 and apparently it doesn't like to sign things the old 4.0 way, even if I publish it as a 4.0 app. WTF.

4.5 is not fully backwards compatible with 4.0 - there are other issues like this
if you need to deploy to a 4.0 system you should also do builds & tests on one

# ¿ Jul 12, 2014 08:52

Gul Banana: Nov 28, 2003

Essential posted:

Can MEF be used to load & unload a library from a running application? I want to be able to silently update files while a system tray app runs.

I've done the same thing with a windows service and AppDomain, however I'm wondering if MEF is a better option.

I thought I read before that MEF cannot unload a library once it's loaded (without closing the app down of course), but now I can't find anything on that.

The only way to unload an assembly is to kill its app domain - MEF doesn't provide any special facilities for this.

# ¿ Aug 20, 2014 04:33

Gul Banana: Nov 28, 2003

Ithaqua posted:

C#6 will have this in the form of primary constructors. I'm sure someone will correct me if I'm wrong, but you'll be able to do:
code:
public class Employee(int salary) 
{

}
and it will generate a private field for the value, no explicit constructor necessary.

I was really sad to see in Roslyn dev notes that VB.NET is not getting any equivalent to this feature

# ¿ Aug 20, 2014 04:34

Gul Banana: Nov 28, 2003

ljw1004 posted:

Sorry, that was partly my doing. The reason for not doing them in VB is:

* We foresee something nicer coming along, e.g. https://roslyn.codeplex.com/discussions/560339
In C# the primary constructor syntax will already be taken, so C# would have to express "plain old data" objects with some kind of other syntax e.g. "record class Point(int x, int y);" and there'll be several similar kinds of things. In VB, if we don't do primary constructors now, then we'll leave the syntax free for the something nicer in the future.

case classes/ records/ POVBOs are exactly what I want (and wanted primary constructors as a step towards), so that's a pretty good reason!

# ¿ Aug 22, 2014 07:01

Gul Banana: Nov 28, 2003

https://github.com/gulbanana/wpfbinding
here's a demo of something similar to what you describe - using data-binding from a textbox to trigger a calculation in code.

i've implemented it in two different ways
1) using an ICommand binding on a Button to explicitly run the calculating code
2) using a property setter to modify another property, which notifies the UI (using INotifyPropertyChanged, as Ithaqua says)

mvvm really doesn't involve a lot of work - check it out and you might be pleasantly surprised

# ¿ Aug 22, 2014 13:19

Gul Banana: Nov 28, 2003

Factor Mystic posted:

Aside from the non-generic subclass, I'll give the benefit of the doubt to anyone subclassing ObservableCollections since the base class is so irritating. Who's using OC<T> and NOT subclassing it?

in my current project, we've got both FastObservableCollection and SlightlyObservableCollection

# ¿ Aug 22, 2014 18:42

Gul Banana: Nov 28, 2003

A Tartan Tory posted:

So to do what I need to do, I need to get my inputs from View to Viewmodel using data binding, run it through the programming logic in there, then spit it back out through data binding again.

That's right- the only thing I'd add to this summary is that it's not a procedural process. You *declare* bindings, typically in XAML, rather than actually *executing* code which moves data around, and then the rest is taken care of.

It's not magic, mind you. The binding system is just listening for events from the INotifyPropertyChanged interface (or a couple of alternatives)- but in effect, the view and viewmodel are just always synchronised, and the problem is reduced to how to manipulate the data in the viewmodel.

The class I called Controller in the sample code was just a place to do that, and ICommands are just a kind of data which is itself bound - rather than a string or a number, they represent an action to potentially take.

# ¿ Aug 26, 2014 20:27

Gul Banana: Nov 28, 2003

Why not just have the viewmodel set a property RequiresUpdate and have a DataTrigger bound to that?

# ¿ Aug 27, 2014 12:39

Gul Banana: Nov 28, 2003

i hit another pair of
The WPF team has recently reviewed this issue and will not be addressing this issue as at this time the team is focusing on the bugs impacting the highest number of WPF developers.
at work today

# ¿ Aug 27, 2014 14:04

Gul Banana: Nov 28, 2003

I think it is, until you want a bunch of range variables sugared. VB makes it more awkward, though - it doesn't allow you to place the periods at the beginnings of lines like that.

# ¿ Aug 29, 2014 05:37

Gul Banana: Nov 28, 2003

jesus christ. Grid ColumnDefinition.SharedSizeGroup takes effect at an random time after the measure and arrange passes, and *does not itself trigger a layout*

# ¿ Sep 10, 2014 04:00

Gul Banana: Nov 28, 2003

<DataGrid Visibility="{Binding SomeVMProperty}"/>

if you want to bind it to a Boolean instead of a Visibility you can use the BooleanToVisibilityConverter type. if you want to bind to something in the view instead of the viewmodel, {Binding SomeProperty,ElementName=foo}

# ¿ Sep 10, 2014 11:14

Gul Banana: Nov 28, 2003

why is MEF2 so underdocumented and kind of insane. i'm totally behind the tradeoffs they made like dropping private-import stuff, focusing on startup performance, that's all good and i'd like to move to it - but there's no actual way to find out how to USE stuff like new concrete metadata views. also, it isn't CLS-compliant, and they close all issues saying they're not "targetting" that??

# ¿ Sep 15, 2014 10:12

Gul Banana: Nov 28, 2003

My current code base contains both "FastObservableCollection<T>" and "SlightlyObservableCollection<T>".
Inadequacies of the original aside, though, there's not much reason you should need a different collection type. This is viewmodel code! Its job is to present stuff to the view, in a format suitable *for* the view. If you want a unique set or lazy stream or keyed dictionary, put it in a model or controller - have the sync from that to the OC<T> BE your "forced" refresh.

# ¿ Oct 7, 2014 06:25

Gul Banana: Nov 28, 2003

GrumpyDoctor posted:

This did not work, unfortunately.

Yeah, I know this is the "right" answer, but the way that WPF is missing certain kinds of duct tape is infuriating sometimes.

it's definitely something that needs some really core pieces added and an iteration or two of simplification to codify best practices into the easy path.

instead they've spent half a decade rewriting it twice, for the web and then for tablets, modifying the existing bug set each time :/

# ¿ Oct 7, 2014 18:09

Gul Banana: Nov 28, 2003

sometimes if i want to be really sad i think about how awesome WPF would be by now if its development had continued after 2008.

# ¿ Oct 7, 2014 18:10

Gul Banana: Nov 28, 2003

Neurion posted:

I'm very familiar with VB .Net, and have written a fair number of applications for my own use with it. I'm also somewhat familiar with C/C++. Would I see any performance benefit from attempting to rewrite some of my applications in C#? I somewhat doubt it, seeing as how both C# and VB compile to CLR, so they'd probably result in similar performance (though worse in the case of C#, owing to my lack of familiarity with it.)

they're each just as fast for almost all purposes. C# does have the option of using unsafe blocks in which unchecked arithmetic and pointer accesses can be performed, but it's rarely worthwhile.

# ¿ Oct 22, 2014 13:40

Gul Banana: Nov 28, 2003

:[ we just got hit by a vb.net compiler bug. turns out that if you have a pair of functions like this:

code:

iterator function foo() as ienumerable(of x)
    yield a
    yield b
end function

iterator function bar() as ienumerable(of x)
    yield c
    yield d
end function

then it can be silently miscompiled as if you had written this:

code:

iterator function foo() as ienumerable(of x)
    yield a
    yield b
    yield c
    yield d
end function

iterator function bar() as ienumerable(of x)
end function

this bug only occurs if the functions are physically adjacent in the code, with no other methods between them. it's fixed in vs2013, which i'm using, but our build server isn't... very very confusing.

# ¿ Oct 23, 2014 08:51

Gul Banana: Nov 28, 2003

don't be afraid of writing codebehind code and custom controls, though - that is the right way to accomplish some view-specific stuff in WPF

(well, maybe stay away from the latter unless you've got a good handle on templatebindings and Generic.xaml...)

# ¿ Nov 11, 2014 06:41

Gul Banana: Nov 28, 2003

Chasiubao posted:

Would people event want WPF skinned apps on Linux / OSX?

I'd settle for a gui api that was cross-platform between windows 7 and windows 8

# ¿ Nov 13, 2014 07:41

Gul Banana: Nov 28, 2003

ljw1004 posted:

For VB/C#, here are complete lists of all new language features in C#6 and VB14.

Here in the VB/C#/.NET teams we're pretty excited! We'll writing more on the .NET blog, C# blog and VB blog, once we have time to write it in the coming weeks

very nice! nothing quite as exciting as record classes, but I'll be making immediate use of half this stuff. how on earth did you solve the memcpy problem to allow for parameterless value type constructors?

# ¿ Nov 13, 2014 07:50

Gul Banana: Nov 28, 2003

ljw1004 posted:

Could you say precisely what you mean by "the memcpy problem" ?

as I understand it, the CLR will sometimes initialise or copy value types around bytewise no matter what a language compiler has to say about it - meaning that constructors cannot be guaranteed to run. normally with a reference type you're assured by the language semantics that it will be given its initial state by application defined code, but this same guarantee can't be made for value types.

I thought that was why you weren't allowed to write parameterless constructors for valueobject subtypes, and *were* allowed to assign Nothing or default(T) to them instead (which I assume uses initobj) - the parameteless constructor would have been a "trap" which looked like, but was not, the only way to init objects of the type.

quote:

So we just relaxed the restriction on the declaration side, and ensured that code only ever calls initobj in places where it knows for sure that it's a struct with no parameterless constructor. (Note that struct constructors are required, as always, to initialize all fields).

If you have an instance of a struct and assign it to another one, then yes it's just a straight memcpy, not expected to go via additional constructor calls.

When you declare an array of structs, that's expected to be the same as default(T), i.e. to bypass the constructor.

this sounds like a partial solution, where the language makes what restrictions it can - but fundamentally, there are still situations where your struct gets inited to 0 rather than its constructor being called, which is not the case with classes?

# ¿ Nov 14, 2014 05:42

Gul Banana: Nov 28, 2003

is this interpretation correct?

code:

    Public Class StructFactory(Of T As Structure)
        Public Function CreateWithConstructor() As T
            Return New T ' call Activator::CreateInstance
        End Function

        Public Function CreateWithoutConstructor1() As T
            Dim ts(1) As T
            Return ts(0) ' initobj
        End Function

        Public Function CreateWithoutConstructor2() As T
            Return Nothing ' initobj
        End Function
    End Class

if so, will T As {Structure, New} now be allowed? that'd let us differentiate between the stronger- and weaker-construction-guaranteeing types.

# ¿ Nov 14, 2014 11:25

Gul Banana: Nov 28, 2003

ljw1004 posted:

The intent of your proposal is so that no one writes a parameterless constructor under the belief that this will always be called, but then does something that fails to call it. It's kind of strange because library authors will have to do the {Structure, New} work at no benefit to themselves, solely to help callers. Also strange because it doesn't catch INITOBJ cases done by the caller without going via generic methods. One unknown is whether the metadata format itself can accommodate both "New" and "Structure" constraints (i.e. whether their bitfields don't clash). A bigger unknown is whether it's possible to catch all things that might call INITOBJ both directly and indirectly. That seems really hard.

you're right, the burden and benefit go in the wrong places. i'm just kind of grasping at straws here because i care more about static analysis guarantees (like: object won't exist without its constructor being called) than being able to type New SFoo() instead of SFoo.Create()

we've got some fairly monolithic codebases, so if {Structure,New} did become possible we'd use it internally and alleviate the issue. i understand that might not be a niche worth supporting!

# ¿ Nov 15, 2014 07:37

Gul Banana: Nov 28, 2003

Inverness posted:

From my understanding, WPF uses MILCore at the low level to render everything with DirectX. I assume most of the work would be in making an OpenGL implementation of this for Mac and Linux. Most of the higher level stuff should work fine though, right?

Silverlight demonstrated that a XAML implementation is possible without DirectX - WinRT is more closely related to Silverlight than WPF, too, at least in terms of API subset. I don't think they'll open source either, though.

This might be somewhat uncharitable toward Microsoft, but my guess is that their .NET strategy goes something like this:
1) we own the enterprise desktop. there's nothing else as good as wpf OR forms out there, so we don't have to attract new developers to them. no major investment and keep things closed.
2) mobile is big and growing bigger, and we've got low marketshare - therefore it's a major growth opportunity. invest heavily, attempting to leverage our existing platform (which must therefore remain closed).
3) in server/cloud we're competing with other heavyweights; it's all very back and forth. a lot of people are refusing to touch asp.net because they don't Do license fees for servers or upfront IDE costs. if we get some of those people using the OWIN stack, it's a selling point for Azure, where this stuff integrates really nicely; Azure is on decent footing against the other clouds but could certainly use advantages like that.

Another example: note that the open source stuff includes WCF *client*, but not WCF *server* - that's another case where the enterprises that host WCF services have no real competition other than step down to HTTP/REST services, which falls under 3 above. Microsoft isn't interested in giving out stuff which is already a lock-in competitive advantage (this is not an attack: why *should* they be?).

There are some real benefits to openness of the stack, both to Microsoft and to Microsoft developers. Unfortunately, the first party wouldn't benefit so much in the (rather large) use case of enterprise line-of-business development. The people inside Microsoft who push for open stuff - more power to them but either they aren't interested in opening up business-desktop and internal-server stuff or, more likely, they aren't allowed because it's a different segment of the business with a different (non-growth) model.

# ¿ Nov 15, 2014 07:53

Gul Banana: Nov 28, 2003

Those one-off analysers are pretty convincing ads for vs2015! Can they be shared with a team via e.g. extension galleries?

# ¿ Nov 18, 2014 11:40

Gul Banana: Nov 28, 2003

ah, so that's why immutablearray was removed from the first public release of bcl.immutablecollections...

# ¿ Nov 24, 2014 05:50

Gul Banana: Nov 28, 2003

Dietrich posted:

Why the hell is Random.Next() not thread safe?

because it mutates state..? exact same reason that
globalPreviousRandomNumber = currentRandomNumber;
wouldn't be.

# ¿ Dec 2, 2014 07:00

Gul Banana: Nov 28, 2003

I've got a piece of code that uses app domains and assembly unloading- unsurprisingly, it's a plugin loader system. It supports multiple versions of the same types, wants to keep runs isolated, etc. (Why is this all in one process? Because my project is, itself, a visual studio plugin...)

The feature is effective but very niche and complex to use. I'm not surprised to see it cut from Core

# ¿ Dec 6, 2014 07:15

Gul Banana: Nov 28, 2003

Does anyone know whether it is possible to do an upgrade install from windows 7 to 8 while preserving an installed copy of Visual Studio?

# ¿ Dec 15, 2014 07:34

Gul Banana: Nov 28, 2003

EssOEss posted:

Yes, an upgrade install of Windows will leave any existing Visual Studio installation in an operational state, barring exceptional circumstances.

cool, that should help me avoid having to dig up new MSDN licenses

# ¿ Dec 16, 2014 08:36

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 10:08

Gul Banana: Nov 28, 2003

Since when are lists unordered? Relations between entities are, sure, but the code equivalent of that would be a *set*.

# ¿ Jan 4, 2015 07:49

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›6 »