I was willing to create an app for IntelAppUp store.I came across Cilk++.I was wondering how to use this C++ library in C # application while building a form based application?Any insight will be helpful
Cilk++ is unsupported. It has been replaced by Intel® Cilk™ Plus, which has been implemented by the Intel Composer XE C++ compiler (Composer XE 2011 or later), as well as in the "cilkplus" branch of GCC.
You'll need to be careful mixing Cilk Plus and C# forms. Cilk Plus provides an easy-to-use fork/join parallelism mechanism. Inside the parallel region, there's no way to predict which thread a piece of code will run on. You'll need to be aware of the limitations of C# forms and threaded applications. A good primer on the issues here is the article "Safe, Simple Multithreading in Windows Forms" available at http://msdn.microsoft.com/en-us/library/ms951089.aspx . You might also look at the QuickDemo example which shipped with Composer XE for Windows. Admittedly, QuickDemo is an MFC, not WinForms, based application, but it demonstrates many of the same issues.
- Barry Tannenbaum
Intel Cilk Plus Runtime Development
Related
I'm trying to build a dual platform application for a company of my own I'm trying to start at night.
I have the .NET version done, but have not finished the UI part. I'm thinking of buying some 3rd party controls.
If I buy these controls, however, they clearly will only work in my Windows version. I'm wondering if I should try to do the UI in GTK# and use Mono with CocoaSharp or just build the thing in MS technology and teach myself the Mac side?
I'm just really unfamiliar with the Mac world and am wondering how much of a learning curve there might be.
I've thought perhaps of rewriting my core logic in Ruby or Python. This why I could use the .NET version with .NET controls and presumably hook the same code up on the Mac.
It's an educational app targeted at consumers. As such, it shouldn't require a lot of technical sophistication to install.
If the non-visual part of the .NET application is quite big compared to the UI, then you can go full .NET and adopt the following two-steps strategy:
Non-Visual Part
Develop the non-visual .NET part to be the most platform independent.
Platform dependent code for non-visual code should be isolated in small classes that provide the same interface so they could be plugged according to the platform.
User Interface
Use System.Windows.Forms (or your favorite toolkit) for Windows
Use a Cocoa bridge (see this page for the choices) for Mac OS X.
You still can benefit from learning Objective-C: as the Cocoa bridges are usually heavily based on the Apple's API, you will find a lot of help in the Apple's sample code (which are in Objective-C).
On Windows, the application will run with the Microsoft .NET runtime and on Mac OS X, the application will run with the Mono runtime.
The DeepMeta application uses this strategy. As you can see the user experience is quite good on both platforms.
Avoid using cross platform UI tools; the result will never be as good as a native implementation, which is especially bad on the OS X where most customers expect a certain level of polish in their applications. Implementing the core logic in a platform independent language like C++ and maintaining a different code base for the interface on each platform can be a good solution, especially if you have a very complex model.
Anyway, you shouldn't have too much difficulty learning Cocoa if you're a good .NET programmer; I did the reverse several years ago and didn't have much trouble. Objective-C is more C oriented than C#, but if you know the basics about pointers and such you're going to be okay. Cocoa and .NET definitely have their differences in certain areas, but they're both high level frameworks which you shouldn't have too much trouble understanding. Get a good book (Hillegass is the go-to author) and go through it so you understand how the two APIs use different design patterns in certain areas, and don't try to fight the framework if it's different than what you're used to.
In my experience this will make you a better programmer in the long run by expanding your knowledge, even if you don't write any more Cocoa applications.
We have a business logic that works with the file systems on OS that we want to implement on both Linux and Windows platforms. The language we have selected is Python for Linux and C# for Windows. GUI is not a priority for now. We were looking for ways to abstract the business logic in a way that we dont have to repeat the business logic (ofcourse I understand since it is related to file system, some code will differ from platform to platform).
Any ideas on how to implement it? Is C/C++ the only option. We dont want to use Java.
Thanks,
Pranz
yea, pick a common language for the logic first. Punting down in to C/C++ pretty much eliminates any of the real values to development that the Python and C# languages provide. Done write, MOST of your logic will be "Business Logic" with the rest glue to external services (i.e. databases, etc.).
So, you should pick a portable environment from the get go. Dropping down to C/C++ and linking it in is a viable alternative, but most likely not worth the time.
Mono is an option you'll probably want to look into.
Quote from the site for easy explanation:
Mono is a software platform designed to allow developers to easily create cross platform applications. Sponsored by Novell, Mono is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime. A growing family of solutions and an active and enthusiastic contributing community is helping position Mono to become the leading choice for development of Linux applications.
Either use Mono or Python.
Mono allows you to run C# .NET code on both platforms. Python can be executed on both platforms already.
Qt has cross-platform libraries for all sorts of things, including UI and file system. It does, however, use C++.
I just caught one of Google's commercials for Chrome where at the end they mention that it runs on Linux, Mac, and PC. So I started wondering how they are able to develop a program that can run on multiple platforms like that? I have experience with Java, and .Net but only on a windows machine. Java is by design portable, but I wouldn't think Google is using Java for something like Chrome where performance is such a concern.
I understand that each version is going to have some platform specific code, such as for the UI. But there must also be some central code that is reused across each platform. What language is this written in?
Here is an entire article about the development of Chrome. It's mostly written in C++.
Chrome is written in C++, so they will have a significant amount of platform-specific code for each OS. They most likely maintain a separate branch for each OS.
Any reasonably standardized and popular language will do, because the goal is to compile it on all platforms, not create one binary that will work on Windows, MacOSX, Linux, and z/OS. C and C++ are popular choices, because they'll work readily with pretty much anything. Java is a good choice, because it runs on pretty much everything. For applications with low performance requirements, Perl and Python are good.
The important point is to separate out what is platform-dependent from what isn't, since (except in the case of Java or scripting languages) it will probably be necessary to rewrite platform-specific stuff for each platform, and not necessarily in the same language. MacOSX is best programmed in Objective-C, and that's true for no other popular platform.
The programs are supposed to be portable in source level, not binary level. So you only need to compile it for different platforms, not necessary to make one universal binary. In fact, most languages are supported in all modern platforms including UNIX/Windows/Mac, so you can choose from almost all modern lanagues, which C/C++ is prefered by many people. BTW, C++ is the language of Chrome.
Scripting languages like Python/Perl are also good choices. One more thing, Java can be faster than you think - see Eclipse. Even without JNI Technology, Java is still good enough for most applications like JDownloader.
Google had to build different distributions for each OS (ie compiled for each platform as Francis's answer explains) - in fact the Mac OS version only recently became available - the Windows version has been around much longer.
Google Apps are 'thin applications' - the grunt-work is done on their servers.
The Apps are portable in the sense that the front-end is put together using HTML, CSS and Javascript - which are standard (in theory at least) across all browsers.
Google put a lot of effort into building Chrome's Javascript engine to be performant - to ensure any client-side logic is run quickly.
Which processors are capable of running Common Intermediate Language(CIL), formerly known as Microsoft Intermediate Language (MSIL)? Clearly any machine that can run Microsoft Windows with .net qualifies as well as machines targeted by the Mono project.
It would appear that the .NET Micro Framework has the ability to target other processors not covered by the above, but it is not clear to me that it uses CIL.
Does anyone have a list of which processors are capable of running a program in CIL and or interpreting C# directly (as the .NET Micro Framework appears to do)?
EDIT to clarify, I understand that CLI is not executed directly on the metal but rather by a a runtime engine. So for this question any processor with a runtime engine that executes CIL qualifies.
None. There is no processor that runs CIL - CIL is to my knowledge ALWAYS translated to another form of machine code.
I think there is a CIL processor "floating around" are research project, but so far not seen in the real world.
The .NET Micro Framework doesn't allow processors to interpret CIL directly. It is simply an even more lightweight interpreter that runs on embedded hardware instead of requiring a full PC architecture. It's like .NET Compact Framework but with a smaller footprint. To look at the architectures that this supports:
.NET Micro Framework Hardware
Afaik, TomTom is right.
They call it Intermediate for a reason... it is between the programmer's language and the processor's language.
An interesting thought, though - having a processor that runs CIL code.
I found two research processors that execute CIL natively much like the JOP does for Java Bytecode:
SCIL According to the paper it supports a subset of CIL, so the some portions of CIL will have to be emulated in subroutines. Honestly though the processor and paper do not look well put together.
DSP Core for Hardware Based CIL Machine This one looks more legitimate, however its designed with a very specific purpose in mind (DSP on a mobile phone).
Realize that these cores are meant for use with FPGAs. Sadly neither of them provided source code or bitfiles, so you will have to request more information from the authors if you actually want to use them.
On the .NET Micro Framework page it mentions a CLR which is what is running the CIL.
It includes a small version of the .NET CLR...
The supported platforms on mono-project.com list a few architectures.
Though be careful to test it before investing too much time.
The only guaranteed targets are those bundled with the Xamarin product.
In the past mono was missing floating point support on some ARM architectures which since has been added.
Since MS appears to have killed Managed JavaScript in the latest DLR for both server-side (ASP.NET Futures) and client-side (Silverlight), has anyone successfully used non-obsolete APIs to allow scripting of their application objects with JScript.NET and/or can explain how to do so? A Mono/JScript solution might also be acceptable, if it is stable and meets the requriements below.
We are interested in upgrading off of a script host which uses the Microsoft JScript engine and ActiveScript APIs to something with more performance and easier extensibility. We have over 16,000 server-side scripts weighing in at over 42MB of source, so rewriting into another scripting language is out of the question.
Our specific requirements are:
Noteably better performance than the Microsoft JScript (ActiveScript) engine
Better runtime performance and/or
Retention of pre-parsed or compiled scripts (don't reparse on every run)
Lower or equal memory consumption
Full ECMA-262 ECMAScript compatibility
a little porting can be tolerated
Injection of custom objects into the script namespace
.NET objects (not a hard requirement)
COM objects or COM objects wrapped in .NET
Instantiation of COM objects from Script
à la "new ActiveXObject(progid)"
Low priority given the preceeding
Include files
Pre-loading of "helper scripts" into a script execution context
An "include" function or statement (easy to create, given the above)
Support for code at global-scope
Execution of code the global scope
Retention of values initialized at global scope
Extraction of values from the global scope
Injection and replacement of values at the global scope
Calling of script-defined functions
with parameters
and with access to the previously initialized global scope
Source-level debugging
Commercial or Open Source Support
Non-obsolete APIs
I answered a similar question here. Have a look at IronJS, an implementation of JavaScript in F# running on the DLR.
Sooner or later, I imagine someone will write a DLR Javascript. I know that's not very convenient for you right now, but maybe you could start the project. I suspect it would have a better cost/benefit analysis to using JScript.NET.
If moving away from .NET and Microsoft is ok for you then you should try Mozilla's Rhino. It is an open-source implementation of JavaScript written entirely in Java. Alot of modern server side js libraries target this platform.
I have used CSScript.net as it will allow you to run C# as a scripting platform. From the site:
CS-Script combines the power and
richness of C# and FCL with the
flexibility of a scripting system.
CS-Script can be useful for system and
network administrators, developers and
testers. For any one who needs an
automation for solving variety of
programming tasks.
CS Script satisfies all the conditions that you laid out. I have used it in production as a substitute for Boo it has performed really well. You can see it in action here.
The use of Com interop means you are limited to an MS solution Java and Opensource want as little as possible to do with it.
I dont see any solution that supports all your requirements either you ditch all the COM/.NET stuff and go Java (Rhino) /Linux/Open source or you question the use of Javascript as your server language even in the Linux world we use PHP/Python/Ruby more on the server if we cant run Java. Your not going to see big performance gains with Java script as the language is the main barrier.
I wouldnt count on people writing a new DLR as server Java script is dying fast.
Considering you want performance ,what about F# , Microsoft will keep the Jscript engine supported for at least 5 years giving you time to create new stuff in F# while you slowly migrate the code.
Have you seen ROScript?
http://www.remobjects.com/script.aspx
Supports both PascalScript and ECMAScript (Javascript) syntax
The Jurrassic-Engine is alive and kicking.
From their codeplex site:
Supports all ECMAScript 3 and ECMAScript 5 functionality, including ES5 strict mode
Well tested - passes over five thousand unit tests (with over thirty thousand asserts)
Simple yet powerful API
Compiles JavaScript into .NET bytecode (CIL); not an interpreter
Deployed as a single .NET assembly (no native code)
Basic support for integrated debugging within Visual Studio
Uses light-weight code generation, so generated code is fully garbage collected
Tested on .NET 3.5, .NET 4 and Silverlight