|
Munkeymon posted:Linq is really good and I miss the hell out of it when I use other languages. Just curious what do you like most about it? I did find it pretty handy doing some data manipulation on datatables but that's all I ever used it for.
|
# ? Aug 25, 2016 20:57 |
|
|
# ? May 22, 2024 16:49 |
|
I use LINQ every day! Well, I mean I use the LINQ extension methods, not the weird SQL-ish syntax. For example, today I wrote the following code to get all the categories of an entity that match a whitelist: code:
Async/await is also awesome, especially if you deal with things that need to be responsive (UI code) and especially on weak devices (e.g. Windows Phone). By going from a multithreaded model to an async model, I totally eliminated a whole bunch of performance issues and jitters in an app I had made. It takes a bit of time to understand but once you get it, it just makes so much sense! EssOEss fucked around with this message at 21:17 on Aug 25, 2016 |
# ? Aug 25, 2016 21:15 |
|
Cool, I guess I do a lot of stuff manually but its probably not as efficient or fast as LINQ. I suppose taking the time to learn how it works will speed up the coding process and probably the time it takes to run on some stuff. I've done a few multithread things and I almost get it. I just hate how hard it it to debug.
|
# ? Aug 25, 2016 21:28 |
|
smarion2 posted:Cool, I guess I do a lot of stuff manually but its probably not as efficient or fast as LINQ. I suppose taking the time to learn how it works will speed up the coding process and probably the time it takes to run on some stuff. I've done a few multithread things and I almost get it. I just hate how hard it it to debug. First lesson: Async != multithreading. Multithreading is one method of achieving asynchrony, not the only way.
|
# ? Aug 25, 2016 21:37 |
|
Ithaqua posted:First lesson: Async != multithreading. Multithreading is one method of achieving asynchrony, not the only way. I'm fairly new to C# and I have been trying to wrap my head around this over the past week. I found an article that helped me understand it better. The visuals really helped.
|
# ? Aug 25, 2016 21:44 |
|
smarion2 posted:Just curious what do you like most about it? I did find it pretty handy doing some data manipulation on datatables but that's all I ever used it for. Making data manipulation code a lot easier to write is exactly why I like it. Contrary to some old posts of mine ITT, I've even gotten into the SQL-like syntax because it can be even easier and more concise than chaining extension calls, especially when things get really hairy.
|
# ? Aug 25, 2016 21:49 |
|
smarion2 posted:Cool, I guess I do a lot of stuff manually but its probably not as efficient or fast as LINQ. I suppose taking the time to learn how it works will speed up the coding process and probably the time it takes to run on some stuff. I've done a few multithread things and I almost get it. I just hate how hard it it to debug. You can do some pretty baller stuff. Today I was running this code:
code:
|
# ? Aug 25, 2016 21:52 |
|
smarion2 posted:Cool, I guess I do a lot of stuff manually but its probably not as efficient or fast as LINQ. I suppose taking the time to learn how it works will speed up the coding process and probably the time it takes to run on some stuff. I've done a few multithread things and I almost get it. I just hate how hard it it to debug. Well, LINQ is actually usually a hair slower. But it's just so much more clear and readable. Use LINQ.
|
# ? Aug 25, 2016 22:12 |
|
Ithaqua posted:Why aren't you disposing the Image objects? That should clean up the unmanaged memory. calling GC.Collect() is almost always a bad thing. Yeah I know, you're missing the point, the Image is just a view element in XAML on which you can change the Source (and it isn't disposable anyway). I dug up this minimal reproduction sample: code:
|
# ? Aug 25, 2016 22:25 |
|
Munkeymon posted:Linq is really good and I miss the hell out of it when I use other languages. I feel like everybody these days is getting something kind of similar (although I guess most of them aren't lazily evaluated).
|
# ? Aug 25, 2016 22:49 |
|
Bognar posted:If you haven't seen it yet, here's the list of potential C# 7 features. Looks like a great list.
|
# ? Aug 25, 2016 23:01 |
|
Munkeymon posted:Linq is really good and I miss the hell out of it when I use other languages. At happy hour with a colleague recently we discussed how nice it would be to have a Java Extension for Linq Querying.
|
# ? Aug 25, 2016 23:10 |
|
Ithaqua posted:First lesson: Async != multithreading. Multithreading is one method of achieving asynchrony, not the only way. Ahhh thanks for the distinction! gariig posted:You can do some pretty baller stuff. Today I was running this That is freaking amazing I want to get really good at Linq now... raminasi posted:Well, LINQ is actually usually a hair slower. But it's just so much more clear and readable. Use LINQ. It's probably still faster than MY code.... HA!
|
# ? Aug 26, 2016 00:03 |
|
Inverness posted:I'd like to know more about your DataGridView issue. Were you using row virtualization?
|
# ? Aug 26, 2016 02:22 |
|
mystes posted:I was trying to; it's on by default, right? quote:I may very well have been doing something wrong, causing it to load more rows than necessary, however. The problem was that scrolling seemed pretty slow, but I didn't try to debug it too much, because it seemed like the WPF datagridview control would be really inappropriate for my next goal (changing the color of individual cells based on the result of calculations performed in another thread). Frankly, the whole row virtualization thing was much clearer with Windows Forms since you essentially just have to implement one function to provide the data when required, rather than setting the itemsource and praying that your object will work with row virtualization (different tutorials seem to do different cryptic things which may or may not be required to actually get row virtualization to function in WPF). In any case, I don't think the control necessarily has an issue with large amounts of data. I assume that was planned from the beginning given the nature of the control. Also, make sure you're not putting the DataGridView inside a scroll viewer as that will cause it to expand infinitely. In any case, how many rows and columns were you doing here? I'm curious and want to investigate the performance issue myself.
|
# ? Aug 26, 2016 03:07 |
|
amotea posted:Yeah I know, you're missing the point, the Image is just a view element in XAML on which you can change the Source (and it isn't disposable anyway). I dug up this minimal reproduction sample: Have you run this on 4.6.2? The memory management behind bitmaps was changed to call GC.Add/RemoveMemoryPressure so it might have helped your issue slightly. But yes, you still could conceivably outpace the GC doing that.
|
# ? Aug 26, 2016 03:31 |
|
LINQ is also a good gateway drug into functional programming.
|
# ? Aug 26, 2016 05:50 |
|
amotea posted:We've had OutOfMemoryExceptions popping up out of SyncFlush() when displaying a BitmapImage in an Image control. The problem IIRC was that the GC didn't kick in in time when swapping images because it didn't track the unmanaged memory. I somehow didn't fully read the original post here, sorry. The "out of memory" that comes from SyncFlush is not really out of memory. Think of it this way, if you ever get an out of memory error it should be pretty much a fail fast. Once you fail an allocation, you're pretty much screwed. In the case of SyncFlush, the error you are seeing happened some time ago and there were likely many many allocations between the time the error occurred and the time you saw the SyncFlush. Just to even fire a SyncFlush requires allocations, so very likely this isn't a memory issue. What we see a lot in these cases is that what you're really running out of is GDI handles due to the fast allocation of bitmaps and the fact that the finalizers haven't yet released the native GDI resources. Forcing a GC would run the finalizers (as you know) and likely the handles being freed are what fixed your problem. If you actually ran out of per process memory that would be interesting, did you check it with task manager/process explorer?
|
# ? Aug 26, 2016 06:16 |
|
Mister Duck posted:I somehow didn't fully read the original post here, sorry. The "out of memory" that comes from SyncFlush is not really out of memory. Think of it this way, if you ever get an out of memory error it should be pretty much a fail fast. Once you fail an allocation, you're pretty much screwed. In the case of SyncFlush, the error you are seeing happened some time ago and there were likely many many allocations between the time the error occurred and the time you saw the SyncFlush. Just to even fire a SyncFlush requires allocations, so very likely this isn't a memory issue. I remember the used memory in task manager stalling somewhere around 1200MB, the used memory reported by the GC was usually about ~70MB IIRC. If I can find some time next week I'll try to see what happens when I run the repro sample now on 4.6.2.
|
# ? Aug 26, 2016 13:09 |
|
Charlie Mopps posted:MIcrosoft should promote F# instead of trying to turn C# into a worse F#. that would be a bad plan, because F# is an inadequate C#
|
# ? Aug 26, 2016 14:16 |
|
Charlie Mopps posted:MIcrosoft should promote F# instead of trying to turn C# into a worse F#. I love F# so much. I'm curious -- in what ways do people think Microsoft should promote F#? For developers to switch over to it from C# for their regular work like websites and WPF? For backends like jet.com? Or for whole other areas like data-science? A couple of years ago I had Dave Wecker come talk about his F# project "LIQUi|>", a quantum computing simulator. That was the most mind-blowing my mind has been blown in decades. https://www.microsoft.com/en-us/research/project/language-integrated-quantum-operations-liqui/
|
# ? Aug 26, 2016 15:44 |
|
Make F# the other language they promote heavily. Make .Net core work with it, make WPF bindings easy, make it as ubiquitous as C# is right now.
|
# ? Aug 26, 2016 16:33 |
|
ljw1004 posted:I love F# so much. I'm curious -- in what ways do people think Microsoft should promote F#? For developers to switch over to it from C# for their regular work like websites and WPF? For backends like jet.com? Or for whole other areas like data-science? Oh, I think it's simpler than that: F# needs full out-of-the-box support in Visual Studio. Right now, Visual F# itself is an optional checkbox in the installation, so people who hear about F# have to first go back and install it. Then, Visual F#'s tooling is so insultingly barebones that the F# Power Tools - a Gallery extension most users won't know about - are mandatory if you want such utter luxuries as "Rename refactoring", "Find all references" or "Folder organization". Then, you still won't have any decent project templates; you need to clone a GitHub repo like Project Scaffold, or get them from the various open-source project like Websharper, FsXaml, Yeoman Generator (a npm tool!) and so on. Compare that to VB, the other "lesser" .NET language (no disrespect meant, Lucian; I do VB for a living and honestly like it better than C# overall, but I call it how it is). Most Visual Studio users don't write VB either, but nevertheless they already get it "for free" - in the new Preview 4 installed, if I'm reading the screenshot correctly, it's bundled under ".NET Desktop development", on equal footing with C#. They can just find the many templates under New Project and have everything set up for working with VB, no extra steps required. Like it or not, the vast majority of the .NET audience is hugely influenced by whether or not Microsoft is putting a new technology front and centre in its products, or whether it's treated as a side project that will go the way of IronPython. If you want more people to try out F# - and I'm firmly convinced it's such a charming language that that's all it needs to succeed - this is where I'd start: - Integrate all the features of F# Power Tools into the basic Visual F# package, or include it as part of the same installation - Make the Visual F# Package automatically included in all of the following Visual Studio components: Web Development, .NET Desktop Development, Mobile Development with F#. Also UWP Development, once the work on .NET Native support is finished. - (this is important) Provide some good templates for F# development! They're already available online, they just need to be packaged with Visual Studio so people can discover them and get intrigued. Off the top of my head, these would all be great: - A WPF desktop template showing off the FsXaml type provider - A Xamarin cross-platform mobile F# template - A pure F# ASP.NET MVC 5 web template - A Data Access Layer template showing off one of the various SQL type providers - A MBrace template showing off the Azure integration through computation expressions (this one would double as an Azure promotion!) - A Suave-based webservice template - A frontend web template using one of the various F#-to-JS open source compilers (Fable, Websharper, or FunScript)
|
# ? Aug 26, 2016 16:35 |
|
Cuntpunch posted:At happy hour with a colleague recently we discussed how nice it would be to have a Java Extension for Linq Querying. You mean Java 8 streams are or you referring to something like the weird sql syntax? Or IQueryable?
|
# ? Aug 26, 2016 19:17 |
|
ljw1004 posted:I love F# so much. I'm curious -- in what ways do people think Microsoft should promote F#? For developers to switch over to it from C# for their regular work like websites and WPF? For backends like jet.com? Or for whole other areas like data-science? This link isn't working for me but it does sound amazing and I'd like to read it!
|
# ? Aug 26, 2016 20:19 |
|
amotea posted:I remember the used memory in task manager stalling somewhere around 1200MB, the used memory reported by the GC was usually about ~70MB IIRC. If I can find some time next week I'll try to see what happens when I run the repro sample now on 4.6.2. Interesting. If the bitmaps were hanging around, you'd definitely use memory + handles, but usually when it's SyncFlush reporting the memory issue it's due to handles. Basically the graphics stack at some point is commanded to create the bitmap and can't create the handle to it and allocates a handle. I guess if your bitmaps were very large then the failed creation due to memory would be fine in terms of the rest of the program execution and you might get the same error coming up from the stack. I'll try to find the code for that portion when I get to work on Monday and see what it does exactly. The traditional scenario I think is lots of bitmaps that are smaller in size (icons, etc). We've seen this in Visual Studio before sometimes introduced by extensions, sometimes by bugs in new code. Hopefully the GC will be more responsive with the current changes, but you might just be stuck forcing the collect.
|
# ? Aug 27, 2016 05:44 |
|
Mister Duck posted:The traditional scenario I think is lots of bitmaps that are smaller in size (icons, etc). We've seen this in Visual Studio before sometimes introduced by extensions, sometimes by bugs in new code. Hopefully the GC will be more responsive with the current changes, but you might just be stuck forcing the collect. ljw1004 posted:I love F# so much. I'm curious -- in what ways do people think Microsoft should promote F#? For developers to switch over to it from C# for their regular work like websites and WPF? For backends like jet.com? Or for whole other areas like data-science?
|
# ? Aug 27, 2016 15:21 |
|
talking the language maintainers into using a multipass compiler and allowing unordered files would be nice :-(
|
# ? Aug 27, 2016 17:14 |
|
amotea posted:I really like F# and use it whenever I can, but for a very large codebase it's currently unworkable because tooling is meh. If it had full R# support I think we wouldn't need C# anymore. So mostly tooling IMO, but I'm talking Resharper level tooling so that's probably not very realistic. Yeah, switching from C# to F# at work feels like going back to working with notepad sometimes.
|
# ? Aug 27, 2016 18:46 |
|
rarbatrol posted:Yeah, switching from C# to F# at work feels like going back to working with notepad sometimes. Gul Banana posted:talking the language maintainers into using a multipass compiler and allowing unordered files would be nice :-( edit: Also more guidance on coding style. We rely heavily (with R# help) on the MS style guide in C#. In F# there isn't really anything in the community or from MS about a consistent approach to naming, scoping, project layout etc. Destroyenator fucked around with this message at 13:32 on Aug 28, 2016 |
# ? Aug 28, 2016 13:24 |
|
Destroyenator posted:edit: Also more guidance on coding style. We rely heavily (with R# help) on the MS style guide in C#. In F# there isn't really anything in the community or from MS about a consistent approach to naming, scoping, project layout etc. Well there is a community linter, it's integrated in the F# Power Tools. But I agree that an official MS style guide would make a much better impression on CTOs and assorted suits.
|
# ? Aug 28, 2016 14:06 |
|
Destroyenator posted:I think this is explicitly not a goal or at least: incorrect for widescale adoption, use in large-team software, etc. separate development of components without source janitoring is absolutely crucial in that context
|
# ? Aug 28, 2016 15:53 |
|
Thank you goons for suggesting learning Linq. The lamba kind of scared me at first since it looked so different from the object oriented approach I've been accustomed to but it ended up being much easier than I thought it would be. I'll be sure to be incorporating this more in my code from now on!
|
# ? Aug 28, 2016 17:14 |
|
NihilCredo posted:Well there is a community linter, it's integrated in the F# Power Tools. But I agree that an official MS style guide would make a much better impression on CTOs and assorted suits.
|
# ? Aug 28, 2016 17:59 |
|
Gul Banana posted:right, that's why i say "talk into". it's not something they don't have the manpower for or w/e, but rather an incorrect choice they've made Isn't this more about people coming in with the wrong attitude and unwilling to learn how to properly separate components? Creating properly seperatated components in C# with large teams requires janitoring wrt. building, packages etc. anyway. Destroyenator posted:edit: Also more guidance on coding style. We rely heavily (with R# help) on the MS style guide in C#. In F# there isn't really anything in the community or from MS about a consistent approach to naming, scoping, project layout etc. smarion2 posted:Thank you goons for suggesting learning Linq. The lamba kind of scared me at first since it looked so different from the object oriented approach I've been accustomed to but it ended up being much easier than I thought it would be. I'll be sure to be incorporating this more in my code from now on! amotea fucked around with this message at 13:17 on Aug 29, 2016 |
# ? Aug 29, 2016 13:14 |
|
Dumb MVC question time: What's the best way to avoid using Model objects inside ViewModels even though it's convenient because I need multiple properties from that model? The reason I want to avoid putting the model inside the ViewModel definition is so I can test the code later and insert whatever I want for data. It's also a large database call as this particular model object has a lot of properties and further dependencies via other model objects in it's repository. I don't need 300 lines of SQL for three properties. Thinking about what I just wrote, I'm kind of screwed anyway since I have to query for the massive object to retrieve any of it's properties anyway (as far as I know). Is there a better pattern I can be using for returning minimal amounts of data rather than huge complex objects and the queries associated with them?
|
# ? Aug 30, 2016 03:47 |
|
spiderlemur posted:Dumb MVC question time: Share some code, I'm not sure what the problem that you're trying to solve is.
|
# ? Aug 30, 2016 04:01 |
|
Ithaqua posted:Share some code, I'm not sure what the problem that you're trying to solve is. code:
1) How do I unit test this? There are no interfaces on the objects and even so the Person object has 30+ properties associated with it that'd I'd have to implement with some mock object if I filled it in. It's also tied to Identity Framework by checking the UserID when the database is initialized inside of a controller. 2) Isn't this a giant query? I'm grabbing every UserStatus in the database and displaying it on the page, which seems fine, it has two properties and nothing linked to it. But what about the Person I'm comparing it to to determine which column to put it in on my page? I have to grab every single one out of the database to make this check. Isn't EF going to grab every property of every object (a lot of table joins) on that Person when I really only care about one? It seems bad because a lot of information is being passed into the View when I only use or care about 2% of it in the page. Still kind of a poo poo post, but hopefully that helps a bit.
|
# ? Aug 30, 2016 04:24 |
|
spiderlemur posted:
1) You wouldn't mock the Person class, you'd mock the repository that returns them. Then you'd construct those Persons that you're using for your test however you want. Yes, you'll need to add interfaces and use standard DI techniques to provide an instance (whether it's a mock implementation of your Repository or a real one) at runtime. If the property isn't relevant to your test, leave it as null or default. If your Person object touches the database, that's bad. Don't do that. In general, once you know the typical techniques for unit testing, the statement, "This is hard to test" is almost always followed by "...because it's badly designed". The answer to "How do I unit test this?" then becomes "Fix the bad design." Sometimes that requires working with what you have and writing some awful integration tests to give you a safety net while you're fixing the design. That's okay. 2) I don't use EF frequently.
|
# ? Aug 30, 2016 05:22 |
|
|
# ? May 22, 2024 16:49 |
|
Is there a decent resource for diving into MVC5/6? Books are fine.
|
# ? Aug 30, 2016 05:48 |