Related
I really like live smalltalk environment (though I only experimented a bit with Pharo), but there is one thing why I can't really use it for everyday development. It seems that it is not possible to create a native standalone executable from smalltalk system. The native standalone executable means to create a single executable file (PE on windows, ELF on linux, Mach-O on macosx), that a user could run by double clicking it without the need to install any additional execution environments. Am I missing something and it is in fact possible to create native standalone executable with smalltalk?
If we talk about Pharo specifically. I know that Pharo's environment includes efficient just in time compiler (that generates true native code from Pharo's VM bytecode), I know that the VM image can be stripped down by cutting of the code that my application won't ever need. So basically we already have almost everything (except the linker I guess) to be able to create native standalone executables. Cross-compilation shouldn't be a problem too, if we put all code generation stuff (for all target processors) in the image.
I know that in smalltalk world it is considered to be a good thing to deliver the whole VM image separately from the runtime environment, so the user can hack on software he/she is using. However I don't see any good reasons why it shouldn't be possible to deliver your smalltalk software as fully compiled native standalone executable. Could you please explain me why it is not a common thing to do in smalltalk world? Is there any good smalltalk implementation that allow to do it?
To sum all this. I dream of a live smalltalk environment, where I could develop and test my software, but then (when the software is actually ready for delivery) cross-compile it to native executables for windows, linux and macosx from my single development machine. That would be really awesome.
ironically enough there is one thing that an exe needs to be preloaded. Your OS. See the thing is that C/C++ can be so light because already your OS acts pretty much as the image acts with a ton of preloaded libraries. You need to waste several GBs of memory just get a simple calculator starting. Your OS is a collection of C/C++ libraries.
Things are not any prettier with other languages like python, java etc , even if the app is smaller, they still depend on this libs and they come will quite big libraries that would need installation whether your app use them or not.
Pharo and Smalltalk in general is diffirent case because they aspire to be a virtual OS by itself. The diffirence with a real OS , the smalltalk image is made to be hacked the easy way by a user .
Saying that you can rename the pharo executable, change its icon, disable to IDE tools inside Pharo so your user sees only the GUI of your App. Applications like Dr. Geo and Phratch already do this.
Compiling a Pharo project to a native executable will not make much difference, because a) Pharo is already compiled to a native executable b) you dont need to do that since Pharo is already standalone does not need to even be installed.
My advice is stop worrying about things that do not really matter and enjoy learning how powerful and fun Pharo can be.
Not Pharo, but native, compiled (through ANSI C or its own JIT) smalltalk [applications] (with ability to load pre-compiled DLLs or [JIT-]compile code on demand):
Smalltalk/X
http://www.exept.de/en/products/smalltalk-x.html
or (unofficial enhanced development version):
Smalltalk/X JV branch - https://swing.fit.cvut.cz/projects/stx-jv/
Nearly completely open-source. Everything except librun (core runtime - memory management, JIT, etc.) and stc (smalltalk-to-c) compiler is already open-source. Claus Gittinger / Exept also promised/confirmed they would release remaining sources were they to stop further development (AFAIK, those parts are closed only because of concerns of existing clients).
I highly recommend everyone to check it out, it is a wonder such a great implementation is so little known.
You might also check out Dolphin from Object Arts.
It is windows only, but the very best IDE, bar none.
If you do anything in Smalltalk, you should buy a copy.
(They also have a free non-commercial version, but you will
want to support the kind of craftsmanship behind it by buying
the Pro version. An absolutely kick-ass product, IMHO).
It will produce a standalone exe, if that's what you want.
I made an exe of a medium-featured wiki with it - the exe was
less than 1 MB. That is not a typo.
-Jim
The problem is that Pharo, in that case, cannot be compared to any native compiler like C, C++ or others, but more like java, python, ruby and other languages with a Virtual Machine around.
In these languages, you produce jars, eggs or gems to distribute your project.
In Pharo, you produce a "production image" following technics you already mentioned. But nothing prevents you to deliver an artefact including also the PharoVM (it is 2m large, after all), and you can prepare your apps to detect and open your production image (without having to ask for it).
It is about as practical with Smalltalk as with other languages: not very much. As soon as you create a somewhat larger application, you start depending on other libraries/applications being installed. If you compile them statically with the application, you have now created a much larger application that takes longer to download, and needs to be updated at least as soon as a security problem is found in one of the dependencies. If not, your application is no longer double-click startable.
There are two directions for solutions: web applications, and installers and package managers.
Squeak still maintains its one-click installer, allowing the same set of files to work on windows, mac and linux. Pharo used to have that too, but moved to having separate builds. The need hasn't been so large that the one-click build has been reinstated. It is mostly seen as useful to be able to carry around a cross-platform environment on an usb-stick. With the move to the 64-bit spur vm the dependency problems will lessen as more of the needed libraries will come pre-installed on those platforms.
Dolphin Smalltalk can produce a standalone .exe for Windows.
This is a key feature of the Pro version.
Your dream has been around since the mid-80's and it is called Smalltalk/X.
I need to learn to program MSP430, but don't have the actual chip yet. All configurations that I've tried at Code Composer Studio (except Snapshot, but it does not count, right?) require something on my USB. How do I learn to program the chip without the chip?
And what is an emulator that requires a USB?
Online emulator (used chrome): http://www.msp430emulator.com
This MSP430 Emulator is open source, and can be used directly online without downloading anything. Still under construction but has a good debug interface. Unfortunately no integration with CCS.
It is on the TI Open source page: TI Open Source Project Page
"The MSP430 Online Emulator provides a complete software model of the MSP430 16-bit instruction set. It is an interactive debugger for advanced development and in depth firmware/hardware analysis. Peripherals include UART, GPIO Ports, BCM+, Timer_A, and more! Open source, and absolutely free - access to the TI MSP430 Launchpad allows you to effectively build and debug firmware. No hardware setup, emulate anytime anywhere!"
open source on github:
https://github.com/RudolfGeosits/MSP430-Emulator
If you need something implemented you can add to the code yourself and run a local emulation server for real time applications.
This emulator is pretty awesome, once you can get it running. Note that it does claim GDB support, which likely means you can get a pure eclipse CDT C project & CDT-GDB-HW-Debugging session up and running against it (making sure to compile with the msp430's tool chain, of course).
http://opencores.org/project,openmsp430
As far as a simulator, the answer is truly 'no'. I would like to be wrong on that... But consider for a moment the number of variants of the msp430, the peripherals, and so on. Not sure if any company can justify that kind of cost!
Especially when launchpad/etc are so cheap and fast.
If you can afford £10 then the launchpad is the way to go just to teach yourself about the MSP430. You can use either IAR Embedded Workbench or Code Composer Studio, both which come in code size limited version which will be plenty big enough to learn with. I don't like either, but of the two the IAR one is, IMHO, the better bet as it's not Eclipse based. If you don't mind Java and Eclipse, then CCS is a viable option for you. One huge advantage with CCS is it runs on Linux, but really, it's still not a patch on Rowley Crossworks which runs on Linux. The latter has a cheap educational licence.
As far as the emulator and USB question is concerned, it's maybe being slightly pedantic, but it's not an emulator, it's a debug interface. There is a debugger built into the chip that enables you to load the code into the chip, set breakpoints, single step through code.
This kit is a great way to start because the debugger interface is built into the kit, you can access pins on the processor, see LEDs come on and all that good stuff that gives you the warm feeling you're programming a chip properly. For the sake of £10 you'd be mad not to!
I just downloaded the full 4.0.1_r1 Android Source Code repository according to the official instructions. Can someone help me understand the repository's basic naming scheme?
For example, in the root directory of the repository, what exactly is the "frameworks" directory? How does this differ from the "packages" directory?
I have spend quite a bit of time around the android source code the last few years, so let me take a shot at explaining the different folders in the root. These are roughly (depending a bit on the android version):
bionic
The standard c library used and developed for Android specifically.
bootable
Contains the bootloader (which the device manufacture normally provides) and the recovery application which is execute when the phone is booted into recovery mode.
build
Android has very unique modular build system, which itself is built on top of ordinary make-files. For example in build/target/products you will find all the generic build targets you see when you launch lunch.
cts
Compatibility Test Suite. When a device manufactures wants to get their device certified (and thus get Google Play and other proprietary apps) they need to pass the CTS. The source of CTS is contained in this directory.
dalvik
The dalvik virtual machine. Android uses java for the better part of the framework as well as for all the apps. Because each app runs as its own process under its own uid, in its own virtual machine, the virtual machine have to have a rather small memory footprint, so Android have chosen to use a custom virtual machine for Java called dalvik. The source of dalvik is placed here.
development
I haven't used this repository really, but it seems supporting stuff for developing android apps are placed here.
device
Each device vendor put all the stuff that defines their specific devices here. For example you can provide a devices/{yourname}/products/{yourdevice}.mk defining exactly which apps should be build for your device (as well as a few other things). This adds an entry to the lunch menu called {yourdevice} that you can build.
docs
As far as I understand this is actually the source of http://source.android.com.
external
Almost all of the third party projects that Android pull in and which makes up the base Android Linux OS are located here. They are maintained in their own git repositories, which makes it easy to pull new versions from upstream. You see things like bzip2, dbus, ping, tcpdump, and many other projects here.
frameworks
This is the source of the Android framework. All the stuff that you use when you build an app for Android. I think it is somewhere around 50% Java code and 50% C++ (and sometimes C), which is bound together using jni. When you for example play some audio in an app, you are probably accessing AudioManager. The source of AudioManager as well as all the internal Android source supporting AudioManager is placed under frameworks/base/media. You will find the bulk of the Android SDK implemented somewhere under frameworks/base/.
hardware
Android talks to a set of libraries which then controls the hardware (such as vibrator, lights, proximity sensor, gps, audio, etc.). These libraries are collectively called the HAL (Hardware Abstraction Layer). Some default implementations are contained in the hardware folder, however manufactures implement their own libraries and place them in hardware/{manufcaturename} (or in device/{manufacture}).
libcore
I don't know about this one.
ndk
The native development kit which allows app developers to code some (or all) of their apps as native code (in c and c++ usually). Basically it is a toolchain to crosscompile to the different cpu architectures Android runs on.
out
All Android build artifacts are placed here. So removing the out folder will clean the sources completely. out is divided into different folders, the main ones are host and target where stuff compiled for the host machine (e.g. adb) and for the target device (most of the android system) are separated. There are further subdivisions below, and in general the out folder is quite nicely sorted, so you should just explore it a bit yourself.
packages
These contains all the default apps, providers, inputmethods, and so on, that are built along with Android. The phone app, contacts, calender, calculator, default soft-keyboard, etc, are placed here. They are not 3rd party apps, they are internal apps where many of them are build against non-public android apis. So most of the apps here cannot build against the public Android SDK (e.g. in eclipse), but have to be build as part of the complete Android build process.
prebuilt
Stuff that is distributed along with Android as binaries. The primary thing located here are the crosscompiler(s) for building Android for ARM (and now also x86). They are prebuilt such that you do not have to actually build the crosscompilers yourself. (This could be very time-consuming if you besides Android also had to compile the crosscompilers.)
sdk
All the tools that are part of the Android SDK, such as ddms, the emulator, sdkmanager, etc.
system
The core system processes running on an android device. These are native (c or c++) programs. Mediaservice is an example of such a system service.
This is all from my experience with working with the Android source, I do not have any (other) references. I hope this helps you get an overview of the folder structure.
This is a question related to Get OS-Version in WinRT Metro App C# but not its duplicate.
Is there any option to detect from a Metro application whether there is the desktop feature available on the system? I understand that detection of the OS version is not supported and that is OK imo.
However my metro app needs to know whether there is a Desktop available on the system it is running on.
By Desktop I mean extendable desktop - desktop, where 3rd party desktop applications can be installed. As we know ARM based units will have the desktop too, but only with Microsoft built-in programs.
Can I distinguish whether my Metro app is running on a ARM based tablet with non-extendable desktop vs on all other (Intel based) devices with extendable desktop?
After some more extensive search I found GetNativeSystemInfo method. The hint was right away on SO site - this question. This approach seems to be fully supported by Windows Store applications - the App Cert Kit test ran smoothly despite the fact that pinvoke was used.
I ended up with the following code:
[DllImport("kernel32.dll")]
internal static extern void GetNativeSystemInfo(ref SystemInfo lpSystemInfo);
internal static bool IsArmBased()
{
var sysInfo = new SystemInfo();
GetNativeSystemInfo(ref sysInfo);
return sysInfo.wProcessorArchitecture == ProcessorArchitectureArm; //ushort 5
}
This seems to be as a solution I was looking for. Please tell me if not or make me aware of whatever problems connected to such an approach. Thank you.
If this is HTML, you can use window.cpuClass to get if it's ARM, x86 or amd64.
A non dynamic version is to use target specific architectures rather than AnyCPU, and then use the flavours with #ifdefs to hard code it at build time. You have to submit 3 packages to the store, however.
Use a try {} catch(){} to access those libraries, if anything goes wrong assume the ARM version.
I'd like to build a special AIR launcher program in C along the lines of java.exe.
I've looked at running AIR programs with a process viewer and was able to locate the AIR runtime DLL that is being used. AIR programs are different than Java in that they are installed as platform-specific executables that bind the AIR runtime as an in-process shared library once they're launched (their icon is double-clicked by the user).
Well, I want to make an AIR launcher that is instead like the java.exe.
The java.exe is launched as a platform OS process that binds to the Java JVM runtime (JRE) as an in-process shared library. The java application that is to be executed is specified as a command-line argument to java.exe. Once java.exe is running and the JVM is fully functional, the specified java application class is loaded by the JVM class loader for execution. That specified Java application then takes over, in a sense "hijacking" the process of java.exe. Of course, the specified java application shows up in any process listing as the java.exe program that host it.
I want to make AIR app launching work like this. Why? So I can explore ways to hack AIR and perhaps overcome some of its many, many deficiencies. For instance, for starters I want to extend the AIR runtime experience with some new APIs that become available to the running AIR application.
My first order of business would be to:
Implement a binding interface of
ActionScript3 to C that is comparable
to .NET PInvoke
Add an API for process launching that
is comparable to the APIs found in
Java SE for doing this (Runtime.exec,
ProcessBuilder, Process)
Add support for an AIR application to
be able to interact with stdin,
stdout, stderr. Strangely, though
Adobe added support for local file
access in AIR, they have omitted
interaction with these standard file
pipes (yet they are found on any
OS platform that AIR supports).
Implement support of AMF over stdin,
stdout, stderr - so AIR (or Java or
any AMF capable language) apps can
interprocess communication via
exchanging AMF objects. This would add
a touch of Microsoft's PowerShell
to AIR.
Currently Merapi provides a AMF bridge with Java, so that demonstrates the efficacy of this. Alas, Merapi has to use a localhost port and socket for doing the interprocess communication - which is a clumsy way to go relative to using stdin/stdout/stderr interprocess pipes instead.
It sounds like you want to do some very hardcore AIR hacking. I don't think hosting the AIR runtime in your own process will be very easy. But you might consider embedding the Flash Player ActiveX Control. Since it is just a COM object, any COM application can CoCreateInstance() the Flash Player. The COM interface is not well documented, but here are some examples that might be helpful:
F-IN-BOX is a developer's library to enhance Macromedia Flash Player ActiveX features. It does not use its own engine to display movies but provide a wrapper around official swflash.ocx/flash.ocx code instead.
How to embed Flash Player ActiveX using BoxedApp SDK
If you want to get even lower level access, you could embed the open-source Tarmain AS3 VM. The code has an example command-line shell called "avmshell". If you build the Tamarin VM yourself, you can add new ActionScript classes implemented in native C++. Tamarin (and the Flash Player) implement many of their features using this "AVM Glue" between AS and C++.
What my question posed attempting to do turns out to be prohibited by Adobe (so far as any potential commercial use):
From the Adobe® AIR™ Runtime Distribution FAQ:
Distribute or use the Adobe AIR
runtime, installer files, or extracted
installer files in an undocumented
manner or purpose. For example, you
may not distribute, call directly, or
write wrappers for any of the Adobe
AIR libraries or runtime components
within your software application.
Runtime.dll, Runtime executables,
template.exe, and template.app are
examples of Runtime Components.