@dcuccia: Thank you! Immo Landwerth has a great blog post covering the challenges associated with porting from the .NET Framework to .NET Core. For now, we have dotnet-apiport that will help identify what libraries are compatible and what will need more work put into them. Keep in mind, many APIs will be added to .NET Core 2.0 that will make porting even easier with .NET Standard 2.0. Currently, .NET Core 2.0 and .NET Standard 2.0 are planned for Q3 2017.
Thanks for your reply and for the timelines. I'd seen that dotnet-apiport hadn't been worked on for a while, so I assumed it wasn't supported/recommended for the 1.0 tooling release. I'm just one voice, but it would sure be nice to have this baked in to the shipped tooling, and "dotnet migrate" sure sounds relevant to this class of compatibility assesment.
Regarding "dotnet migrate," is the plan to use this same tooling/framework to assist migration from .NET Framework as well? If so, what's the timeline on that? It's great to have assistance for people that used project.json, but obviously the much bigger cohort are those of us who have waited for 1.0 tooling to migrate over from the full framework. Something along the lines of the MoMA/Xamarin tools for checking compatibility against different profiles will be crucial for this.
@degloff VERY exciting. This has been a holy grail for quite some time (e.g. see Brahma, C$ aka "C Bucks", Tidepowered GPU.NET). I look forward to learning more about Alea, and I hope that many of the wins and lessons learned from these previous efforts, as well as importantly C++ AMP, have been integrated into the design.
Looking at your overview docs, all I see are single-line GPU code examples, but I presume multi-line methods work, too. What are the restrictions for the GPU method body?
Many applications will require operating along one dimension of a multidimensional array, e.g. transforming RGB images along the color axis, reducing to scalar intensity, etc. Does Alea work natively with multidimensional arrays? How can one perform gather operations (e.g. gaussian blur)? Using user-defined indexers, or Alea constructs (ala C++ AMP)?
To quote Agent Fox Mulder, "I want to believe." Just being able to checkout code from a NuGet package w/o setting up an old version of VS to work with CUDA will be a joy. Look forward to looking in-depth at your code samples.
Thanks for the video, this sounds like a great tool that probably should have been there from the beginning. Not to sound too cynical, but can you confirm that Visual Studio and Office can and will use this someday soon? That certainly would build confidence.
Thanks for the video. Functions looks quite powerful! Looking forward to the improvements in usability that were discussed here, particularly enhancement to tooling (specifying nuget packages in online editor, VS integration, more languages, etc) and on-prem function execution. Regarding the comment @ 38:24 "we won't give you an SLA for that" - do you mean that on-prem execution will only ever be supported/allowed for testing purposes?
Great video and tools! So, two questions having now watched the whole thing:
Could this service someday be integrated with Roslyn for providing in-line portability information and suggestions (or even transformations)?
What's the chance that this can be extended to XAML markup? IIRC there have been efforts to suggest SL/WPF => UWP mappings. Since it appears to be very pluggable, would also be great to see mapping suggestions (or transformations) to/from Xamarin Forms.
Is the OSS framework generic enough that it would allow API developers a scaffold to offer insights in portability either between it's own API surface (e.g. between versions), or even between it's API surface and that of another framework?