next »

[damagefilter]

Found that changing column types in sql server from varchar to datetime
will actually parse the already stored strings and make correct dates from it.

Saved me a good day of work \o/

[neutonm]

Just found out that negative numbers also return true on checks. That solved a huge bug that has been haunting me for months.
Feeling stupid, but happy 

[_glitch]

Just saved 150 lines of code by deleting unused ifs

[InfiniteStateMachine]

the c# nameof operator and XDocument go so well together. You can add and read nodes using the names of your properties rather than having to use strings directly.

For instance var someNewNode = new XElement(nameof(MyProperty),MyProperty);

Found that changing column types in sql server from varchar to datetime
will actually parse the already stored strings and make correct dates from it.

Saved me a good day of work \o/

Wow that's cool. Does it work for many types of date formatting? What did your date string format look like when you converted.

I've been heavily focused on SQL server lately and once I got used to the differences it's really great to work with. It's tooling is the best I've ever seen.

[oahda]

the c# nameof operator and XDocument go so well together. You can add and read nodes using the names of your properties rather than having to use strings directly.

For instance var someNewNode = new XElement(nameof(MyProperty),MyProperty);

Not sure how that's any different from "MyProperty" if the end result is a string that says MyProperty anyway, and you have to type it out in full anyway, and there's syntax saying "turn this into a string" anyway. What am I missing?

[damagefilter]

Wow that's cool. Does it work for many types of date formatting? What did your date string format look like when you converted.

I've been heavily focused on SQL server lately and once I got used to the differences it's really great to work with. It's tooling is the best I've ever seen.

They were stored as something like "2016-12-31 12:00:00"
At least to mySQL that would be some standard date format.
I can only assume it is the same for mssql and it just did some parsing magic.

I'm not sure if it would work for other date formats as I didn't dive into the matter too much.
I was happy that it worked and continued with whatever else was on my schedule yesterday ^^

[InfiniteStateMachine]

the c# nameof operator and XDocument go so well together. You can add and read nodes using the names of your properties rather than having to use strings directly.

For instance var someNewNode = new XElement(nameof(MyProperty),MyProperty);

Not sure how that's any different from "MyProperty" if the end result is a string that says MyProperty anyway, and you have to type it out in full anyway, and there's syntax saying "turn this into a string" anyway. What am I missing?

You don't have to keep a set of string constants (or verbatim strings) that represent the xml nodes. Plus if you refactor and change the name of your property then you don't have to worry about forgetting to update node names or deal with them being out of sync.

I don't follow the line you mention about syntax for "turn this into a string".

Here's a quick example

before nameof:

Code:

public int MyProperty {get;set;}
public const string MyPropertyNodeName = "MyProperty";

var element = new XElement(MyPropertyNodeName,MyProperty);

after nameof

Code:

public int MyProperty{get;set;}

var element = new XElement(nameof(MyProperty),MyProperty);

Wow that's cool. Does it work for many types of date formatting? What did your date string format look like when you converted.

I've been heavily focused on SQL server lately and once I got used to the differences it's really great to work with. It's tooling is the best I've ever seen.

They were stored as something like "2016-12-31 12:00:00"
At least to mySQL that would be some standard date format.
I can only assume it is the same for mssql and it just did some parsing magic.

I'm not sure if it would work for other date formats as I didn't dive into the matter too much.
I was happy that it worked and continued with whatever else was on my schedule yesterday ^^

Cool

My general experience when trying some transformations with SQLServer is "This can't possibly work.... Holy shit it worked!"

[BorisTheBrave]

Not sure how that's any different from "MyProperty" if the end result is a string that says MyProperty anyway, and you have to type it out in full anyway, and there's syntax saying "turn this into a string" anyway. What am I missing?

nameof isn't really a huge win. The difference is it is typesafe - if the property name is changed, then you'll get a compile error, instead of sending the wrong string and getting a runtime error. It's particularly handy with automated refactoring tools, as it'll get correctly rename'd, instead of being ignored.

----

Code:

public int MyProperty{get;set;}

var element = new XElement(nameof(MyProperty),MyProperty);

Nope, this isn't the cool way of using C#. This is:

var element = MakeXElement(() => MyProperty);

With sufficient magic, you don't need duplicate "MyProperty" at all (admittedly, this is slower to evaluate).

Of course there are plenty of ways to turn an object into xml anyway, so not sure any of this is needed.

[bateleur]

Of course there are plenty of ways to turn an object into xml anyway, so not sure any of this is needed.

Of course it is! As more and more programmers move to modern languages like C# we need new baffling and unnecessary coding styles. Imagine what a disaster it would be if people could encounter code on GitHub or written by coworkers that was clear and comprehensible. It would be the end of computing as we know it!

[InfiniteStateMachine]

Not sure how that's any different from "MyProperty" if the end result is a string that says MyProperty anyway, and you have to type it out in full anyway, and there's syntax saying "turn this into a string" anyway. What am I missing?

nameof isn't really a huge win. The difference is it is typesafe - if the property name is changed, then you'll get a compile error, instead of sending the wrong string and getting a runtime error. It's particularly handy with automated refactoring tools, as it'll get correctly rename'd, instead of being ignored.

----

Code:

public int MyProperty{get;set;}

var element = new XElement(nameof(MyProperty),MyProperty);

Nope, this isn't the cool way of using C#. This is:

var element = MakeXElement(() => MyProperty);

With sufficient magic, you don't need duplicate "MyProperty" at all (admittedly, this is slower to evaluate).

Of course there are plenty of ways to turn an object into xml anyway, so not sure any of this is needed.

How does that make an Xelement? What is the code-behind? I considered wrapping it in a function call but my fear is then you are getting the nameof the local parameter rather than the property.

Of course there are plenty of ways to turn an object into xml anyway, so not sure any of this is needed.

Of course it is! As more and more programmers move to modern languages like C# we need new baffling and unnecessary coding styles. Imagine what a disaster it would be if people could encounter code on GitHub or written by coworkers that was clear and comprehensible. It would be the end of computing as we know it!

But XDocument is one of the .net 3 standard ways and it kind of replaces XmlDocument. I'd argue it's the most common modern way to handle xml in c#. The other standard way of using data contracts can be a nightmare if you are trying to change your xml later because it relies on all those stupid implicit rules about property ordering. Also it can be confusing since data contracts are used for more than just xml serialization (WCF etc).

If I'm doing straight serialization to a file and am working with poco types YAX is pretty nice and doesn't require much learning. It just serializes your public properties unless you put a "don't serialize" attribute above it.

The thing is I'm rarely ever just doing straight serialization.

[BorisTheBrave]

How does that make an Xelement? What is the code-behind? I considered wrapping it in a function call but my fear is then you are getting the nameof the local parameter rather than the property.

It's something like:

Code:

XElement MakeXElement<T>(Expression<Func<T>> expr)
{
    var value = expr.Compile()();
    var key = GetMemberInfo(expr).Member.Name; // From http://stackoverflow.com/q/671968
    return new XElement(key, value);
}

though in practise you'd want to cache things or else it can be very slow indeed.

Expression's are one of C#'s best pieces of magic.

[InfiniteStateMachine]

Ah interesting. So the the expression actually manages to capture the original reference so you can get its name. Didn't realize it could do that.

I can definitely see how that could have performance issues. You're essentially invoking the compiler each time that runs.

The expression stuff is definitely quire cool. The new compiler services stuff is pretty nuts too. I've seen some people do some pretty interesting things with it.

[Oats]

Just used Java reflection for the first time today, way simpler than I thought it would be. I used it to make a generic factory class, I just give it an object class I want it to make, and a path to a file containing the desired properties, then boom, calls a constructor, automatically detects the Class's members and manipulates them to fit the properties, the class doesn't even need to implement an interface or inherit anything, so I could make generic factories for any Object now without any padding code. It's all cached and stuff so it's not awfully slow, I guess you can pretty much use java as a dynamic language now?  
Anyway I'm pretty pumped, I always thought reflection was hell but it's actually pretty straightforward .

[pelle]

Just used Java reflection for the first time today, way simpler than I thought it would be. I used it to make a generic factory class, I just give it an object class I want it to make, and a path to a file containing the desired properties, then boom, calls a constructor, automatically detects the Class's members and manipulates them to fit the properties, the class doesn't even need to implement an interface or inherit anything, so I could make generic factories for any Object now without any padding code. It's all cached and stuff so it's not awfully slow, I guess you can pretty much use java as a dynamic language now? 
Anyway I'm pretty pumped, I always thought reflection was hell but it's actually pretty straightforward .

You will be even more amazed when you realize there actually are full dynamic languages implemented on the jvm that you can combine with your java-code (eg clojure or javascript or jython) to make the whole experience a lot more pleasant .

[InfiniteStateMachine]

Started using MEF2 (aka System.Composition in .NET) and it's quite interesting and very well put together. It's way more like a standard IoC container compared to MEF1 which was almost like its own concept.

I'm not a huge advocate for fancy dependency injection frameworks but they certainly do shine when working on desktop gui tools and server-side communications stuff.

Also started playing with the .NET RX reactive extensions which is also pretty cool. I've heard it's complicated but I got everything I needed from it with just an added Where() when you subscribe to an observable so you can filter a stream of events. Maybe I haven't used enough advanced features to see where it gets complicated.

[Krux]

Yay, I finally did it, and it works. I stored a tilemap in a hardware texture. Then I did the entire texel to tile conversion in shader. So changing the texture changes the tilemap instantly on sceen, and saving the texture as an image is saving the map.

[Cheezmeister]

How exactly does that work Krux?

[Krux]

@Cheezmeister
I created a regular grid that is exactly as big as the screen plus one row and one column. Each square is made out of two triangles, the corners are always integer coordinates, and both triangles have the same starting vertex. In the vertex shader I do a textelFetch from the tilemap texture with the vertex xy coordinate. the texture stores an unsigned integer with the tileid. The tileid is a flat vertex out variable. Declaring the out variable as flat is important, because otherwise I would have different tile IDs in the corners of the triangle. With this setup I can easily add an offset to texexFetch to simulate scrolling, even though the same mesh is rendered at the same spot all the time.

[Stib]

I have an XML file format for the levels in my Unity game. After fighting with IXMLSerializable classes for about 2 weeks I switched the whole parser over to XMLDocument in 2 days. Life is good now 

[Photon]

I had something of an epiphany relating to Haxe interfaces and typedefs not too long ago. I didn't realize how powerful typedefs could be for readability and conciseness. To me, typedefs seemed inferior to interfaces, at least when looking at simple, one-way inheritance structures. Why wouldn't I want to declare relationships directly using interfaces, as opposed to the more under-the-covers nature of typedefs?

Well first off, you can establish common relationships across different codebases. I may have an interface for "Positionable" in my codebase, but I shouldn't be shoehorning inheritance for it into an external library I'm using. Typedefs allow you to establish common ground between libraries without making them muck each other up.

But what really floored me was how they handle type templating. For instance, I have a finite state machine typedef that defines how to get state while not implicitly declaring what type state is:

Code:

typedef AurFSM<T>
{
    public function update(t:Int):Void;
    public function get_state():T;
}

Making this an interface would be OK, but then every finite state machine would have to implicity delcare its state type. This seemed silly if I wanted to build an FSM that only worked with one kind of state; yes, I could declare that single type every time I initialize the class but its kind of vestigial in a sense. Using a typedef, however, the type is implied by the structure of the class itself. As long as the "get_state" function returns something, the return type is implied and satisfies conformance with the typedef.

Sometimes Haxe amazes me with its flexibility.