Port to enable use with non-Unity projects #1
Conversation
…ect to .NET 4 Client Profile.
…than I originally thought, so I've simplified the platform check. It doesn't matter anyway; all currently-supported platforms are the same from a JIT perspective.
|
Interesting! I can't apply this as, well, I'm using a decrepit version of .Net and I like using the name Tuple. :) It's really a language deficit of C# that this collision can't be fixed in a clean way with some sort of "using" statement here due to the generics. Have you measured the performance of Slinq vs LINQ with the latest runtime and libraries? It would be harder to factor in the deferred cost of GC than in the Unity graphs, but I'd be interested in the up-front differences. And, yeah, the platforms only really matter for JIT. Which I suppose would be important on MonoTouch. And this library and especially Smooth.Compare could be useful for people on that platform as I believe it still has issues with generic value type comparisons. Hmm... Something like this may have to be applied after all. And then maybe branched or have a script to create Unity builds. Though Unity form is what I use and would be updating. (Actually, I've decided to put an end to my "one programmer with no funding and no art" game development dreams and get a real job again, so brushing up on Scala and real world stuff will take priority over anything else for a while.) On Tuesday, May 6, 2014 7:18 PM, Cole Campbell notifications@github.com wrote: Hello, You can merge this Pull Request by running |
|
Btw, I would love to move this discussion to my (completely empty) forums so others may be able to see it and join in! Interesting! I can't apply this as, well, I'm using a decrepit version of .Net and I like using the name Tuple. :) It's really a language deficit of C# that this collision can't be fixed in a clean way with some sort of "using" statement here due to the generics. Have you measured the performance of Slinq vs LINQ with the latest runtime and libraries? It would be harder to factor in the deferred cost of GC than in the Unity graphs, but I'd be interested in the up-front differences. And, yeah, the platforms only really matter for JIT. Which I suppose would be important on MonoTouch. And this library and especially Smooth.Compare could be useful for people on that platform as I believe it still has issues with generic value type comparisons. Hmm... Something like this may have to be applied after all. And then maybe branched or have a script to create Unity builds. Though Unity form is what I use and would be updating. (Actually, I've decided to put an end to my "one programmer with no funding and no art" game development dreams and get a real job again, so brushing up on Scala and real world stuff will take priority over anything else for a while.) On Tuesday, May 6, 2014 7:18 PM, Cole Campbell notifications@github.com wrote: Hello, You can merge this Pull Request by running |
|
I had a feeling the Stuple thing would be a problem. I'm not a huge fan of solutions that would require branches or build scripts; that kind of complexity rarely seems worth the trouble, in my experience. What I could do is revert the name to Tuple and change the shared library code to reference it by its fully-qualified name. People using Unity could continue to reference it by its unqualified name, and people using the CLR could resolve the conflict however they feel is best for their purposes. We would just need to take care not to use the unqualified name in any code that's shared between the Unity and CLR versions. How do you feel about that? As for the performance, this is something that I wanted to explore more deeply when I had time. I did a few quick tests which seemed to indicate that Slinq's performance is usually either on-par with or significantly slower than CLR LINQ, depending on the exact query, but it wasn't anything extensive. My plan was to do more extensive profiling sometime this weekend and try to identify any bottlenecks that we might be able to address. |
|
As you requested, I've created a thread on your forums: https://www.smooth-games.com/forums/showthread.php?tid=98 |
|
Sounds good, I should also get rid of the Assets folder. At first I was going to check in more Unity project level stuff, but then I remembered that other people may be using this on other Unity versions or in MonoDevelop or VS or wherever and that I hate when IDE stuff is in a repo.... Though I noticed that you checked some in. :) Anyway, let's take this discussion to the forum thread for here on out. Having some activity there will be helpful both for the project and for any potential employers who find the site while looking into what I've been up to since I left my last real job. And having done some interesting C# with deep generics and all that jazz is much better than just having a programmer art game in development. (!) On Wednesday, May 7, 2014 9:01 AM, Cole Campbell notifications@github.com wrote: As you requested, I've created a thread on your forums: https://www.smooth-games.com/forums/showthread.php?tid=98 |
… naming conflict with System.Tuple on Windows
Added UnityEngine.dll to project.
2 participants
Hello,
I saw your post on /r/gamedev the other day and was very impressed with your project, but since I don't work with Unity I wasn't able to make use of it. So I've taken it upon myself to create a Visual Studio solution and refactor what code was necessary to make the project run on the Microsoft CLR. I'm new to this whole github thing, so forgive me if I've screwed anything up.
By far the most significant change was that I renamed Smooth.Tuple to Smooth.Stuple in order to avoid conflicts with the System.Tuple type. I was hesitant to make a breaking change like this, but the alternatives seemed worse.
Other than that, only a few changes were necessary:
I think that about covers it. Please let me know if you have any questions or concerns.