Can Pharo VM be altered to act like GNUStep as well?
I woke up this morning and was wondering if it is possible to create a message API for C for communicating to a running Pharo VM; wrap the API in a preprocessor that abstracts away the calls with objective-C syntax. At the moment, Pharo is significantly simpler to get than GNUstep, and I feel is far cleaner of an environment than GNUstep. I want to write Objective C on Windows, but I can't without getting GNUstep, and I don't want to get GNUstep because I have bad past experience with getting it to run. By creating such a framework, you can write programs in objective C, run them through a preprocessor to turn objective-c constructs to the corresponding message calls(via sockets/pipes/etc)/create corresponding anonymous structs/dispatch tables. And then you can have a C program talk to the Pharo VM. Perhaps even spawn a fresh Pharo VM(In this case it would essentially act like Java, where java command spawns the virtual machines). This would allow native code that seamlessly uses the Pharo VM to deal with managed structures such a strings, hashmaps, arraylists(std::vector-like structures), and interacts with them via sending messages. In essence, it would be C-Pharo network interface which communicates via passing JSON back and forth over a network, where the pharo structures would be recovered from runtime by using a tagged union(variant) type, and sent to pharo by being wrapped in a variant type. What do you guys think about this absurd idea? -- View this message in context: http://forum.world.st/Can-Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
You should have a look at the Python bridge of Kilon, which operates in a similar fashion. I am working on a bridge for Anatella http://anatella.com/ so that I can make "Pharo Boxes" in it. There was another thread with COM Objects and this would be super nice to have as well. I dug out this old thing: http://wiki.squeak.org/squeak/459 - TL;DR version: unless one is biting the bullet and does a full sized COM plugin, well, this are not going to move much. Phil On Tue, Oct 11, 2016 at 10:04 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:
I woke up this morning and was wondering if it is possible to create a message API for C for communicating to a running Pharo VM; wrap the API in a preprocessor that abstracts away the calls with objective-C syntax.
At the moment, Pharo is significantly simpler to get than GNUstep, and I feel is far cleaner of an environment than GNUstep. I want to write Objective C on Windows, but I can't without getting GNUstep, and I don't want to get GNUstep because I have bad past experience with getting it to run.
By creating such a framework, you can write programs in objective C, run them through a preprocessor to turn objective-c constructs to the corresponding message calls(via sockets/pipes/etc)/create corresponding anonymous structs/dispatch tables. And then you can have a C program talk to the Pharo VM. Perhaps even spawn a fresh Pharo VM(In this case it would essentially act like Java, where java command spawns the virtual machines).
This would allow native code that seamlessly uses the Pharo VM to deal with managed structures such a strings, hashmaps, arraylists(std::vector-like structures), and interacts with them via sending messages.
In essence, it would be C-Pharo network interface which communicates via passing JSON back and forth over a network, where the pharo structures would be recovered from runtime by using a tagged union(variant) type, and sent to pharo by being wrapped in a variant type.
What do you guys think about this absurd idea?
-- View this message in context: http://forum.world.st/Can- Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp4918693.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
The idea is to design this in such a way that it "grows" towards completeness by slowly adding structures and messages via careful versioning and careful use of dynamic library plugins so that the whole project need not be recompiled completely each time a minor change is made.) With careful architecture, it could grow in strategically versioned steps where new features are added via new modules and registered to a feature list(only feature list need to be rebuilt), and be completely decoupled and test driven, since such as system is doomed to grow into an unmanageable spaghetti making it impossible to look back at very very quickly if this is not done. -- View this message in context: http://forum.world.st/Can-Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I am still trying to make a bridge between Pharo and C++ via shared memory which is by far the fastest inter process communication also known as IPC. For Python I use the slowest IPC which is sockets , however it has the advantage of remote communication. There are other IPCs , zeroMQ, RabittMQ, pipes, json files, Apache Thrift and of course Microsoft COM. Apple has its own COM like IPC called shared objects, Linux has dbus. So what you ask is certainly doable, though I have to say shared memory it's proven a tough cookie to crack but I will figure it out. With IPC you can make anything talk to everything, Java to Python, assembly to JavaScript, COM to shared objects, two computers in the opposite corners of the planet, etc etc. The advantages ? You don't need to modify the VM It's easier to maintain Cross platform with exception of course of Microsoft COM and Apple Shared Objects Language agnostic Super flexible Even remote execution
Here is for reference how COM works: On Tue, Oct 11, 2016 at 11:02 PM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
I am still trying to make a bridge between Pharo and C++ via shared memory which is by far the fastest inter process communication also known as IPC. For Python I use the slowest IPC which is sockets , however it has the advantage of remote communication. There are other IPCs , zeroMQ, RabittMQ, pipes, json files, Apache Thrift and of course Microsoft COM. Apple has its own COM like IPC called shared objects, Linux has dbus.
So what you ask is certainly doable, though I have to say shared memory it's proven a tough cookie to crack but I will figure it out. With IPC you can make anything talk to everything, Java to Python, assembly to JavaScript, COM to shared objects, two computers in the opposite corners of the planet, etc etc.
The advantages ?
You don't need to modify the VM It's easier to maintain Cross platform with exception of course of Microsoft COM and Apple Shared Objects Language agnostic Super flexible Even remote execution
Here is for reference, how COM works inside: http://www.codeproject.com/Articles/13601/COM-in-plain-C Wrapping that with a .NET layer hurts my eyes. Phil On Tue, Oct 11, 2016 at 11:02 PM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
I am still trying to make a bridge between Pharo and C++ via shared memory which is by far the fastest inter process communication also known as IPC. For Python I use the slowest IPC which is sockets , however it has the advantage of remote communication. There are other IPCs , zeroMQ, RabittMQ, pipes, json files, Apache Thrift and of course Microsoft COM. Apple has its own COM like IPC called shared objects, Linux has dbus.
So what you ask is certainly doable, though I have to say shared memory it's proven a tough cookie to crack but I will figure it out. With IPC you can make anything talk to everything, Java to Python, assembly to JavaScript, COM to shared objects, two computers in the opposite corners of the planet, etc etc.
The advantages ?
You don't need to modify the VM It's easier to maintain Cross platform with exception of course of Microsoft COM and Apple Shared Objects Language agnostic Super flexible Even remote execution
To be fair COM would be significantly simpler if it had a cleaner API. It takes a lot longer to get "comfortable" with COM than most other COM-like models just because of all the caps, all the absurd type layering(WTF IS AN OLESTR!?!), terrible function names "Co* tm". I can imagine the whole COM system being wrapped with Objective C, but even the newest ATL and .NET do a great job wrapping it. Without the horrible notations, it is a language agnostic model, so it CAN be wrapped, it is just that it takes a great amount of skill to make sense of it to actually wrap it. But in the end, Microsoft managed to wrap it with C++/CLI nicely, and further abstract it with C#. -- View this message in context: http://forum.world.st/Can-Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
.NET Interop just works ... until it doesn't. Try that with some COM objects for hundreds of thousands of calls and run for the bar. COM is fine, as is ATL (I wrote quite a set of things using that in the past), what isn't is that MS just changes direction every N years, leaving the underlying tech intact (COM is not going away, nor are basic NT calls) adding layer upon layer. I do not want to take the full .NET SDK around for interfacing with COM. Phil On Tue, Oct 11, 2016 at 11:26 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:
To be fair COM would be significantly simpler if it had a cleaner API.
It takes a lot longer to get "comfortable" with COM than most other COM-like models just because of all the caps, all the absurd type layering(WTF IS AN OLESTR!?!), terrible function names "Co* tm".
I can imagine the whole COM system being wrapped with Objective C, but even the newest ATL and .NET do a great job wrapping it.
Without the horrible notations, it is a language agnostic model, so it CAN be wrapped, it is just that it takes a great amount of skill to make sense of it to actually wrap it. But in the end, Microsoft managed to wrap it with C++/CLI nicely, and further abstract it with C#.
-- View this message in context: http://forum.world.st/Can- Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp4918693p4918699.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Is the layering really that horrible as long as the library is already shared because it is shared between processes (being in shared libraries which are relies on by many programs), and as long as as much of that overhead is stripped at compile time? -- View this message in context: http://forum.world.st/Can-Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Shared libraries if you refer to DLLs it's actually a bad name, it's one of the rare occasions that Microsoft got the naming correct. It's actually a dynamically linked library, there is no sharing of execution or data and that applies for all OSes whether they call them shared libraries or not. Actually shared memory is one of the very few exception that an OS will share memory and even in that case you won't be given the data or code memory of another process . So each time an executable loads the DLL/Shared Library a new instance get linked dynamically with its own execution and data memory which only the executable that is linked to can access , however only one executable can do this. If that was not the case then there would be no reason to use Shared Memory and we all would be using DLLs.if you want share data , shared memory is your only option, other IPCs just copy memory around. On Wed, 12 Oct 2016 at 00:49, CodeDmitry <dimamakhnin@gmail.com> wrote:
Is the layering really that horrible as long as the library is already shared because it is shared between processes (being in shared libraries which are relies on by many programs), and as long as as much of that overhead is stripped at compile time?
-- View this message in context: http://forum.world.st/Can-Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
O.o can you please elaborate? I wrote a DLL a while ago that successfully shared the global state it exported between the libraries that included it without any shared memory explicitly being created. I'll recreate a test case to make sure that I am not just lying. -- View this message in context: http://forum.world.st/Can-Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Here you go http://stackoverflow.com/questions/19373061/what-happens-to-global-and-stati... On Wed, 12 Oct 2016 at 02:33, CodeDmitry <dimamakhnin@gmail.com> wrote:
O.o can you please elaborate?
I wrote a DLL a while ago that successfully shared the global state it exported between the libraries that included it without any shared memory explicitly being created.
I'll recreate a test case to make sure that I am not just lying.
-- View this message in context: http://forum.world.st/Can-Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Have you got my modified message? or have I been wasting my revisions all along O.o? I'll repost. O.o can you please elaborate? I wrote a DLL a while ago that successfully shared the global state it exported between the callers that without any shared memory explicitly being created. I'll recreate a test case to make sure that I am not just lying. *Solution SharingDemo*: *Project ShareMe*: *ShareMe.cpp*: #pragma data_seg("SHARED") extern "C" { __declspec(dllexport) int sharedInteger = 0; } #pragma data_seg() #pragma comment(linker, "/section:SHARED,RWS") *Project Client1*: *main.cpp*: #include <Windows.h> #include <stdio.h> int main(int argc, char **argv) { HMODULE module_handle = LoadLibrary("ShareMe.dll"); int *shared_integer_handle = (int *)GetProcAddress(module_handle, "sharedInteger"); printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); *shared_integer_handle = 1337; printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); system("pause"); return 0; } *Project Client2*: *main.cpp*: #include <Windows.h> #include <stdio.h> int main(int argc, char **argv) { HMODULE module_handle = LoadLibrary("ShareMe.dll"); int *shared_integer_handle = (int *)GetProcAddress(module_handle, "sharedInteger"); printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); *shared_integer_handle = 0; printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); system("pause"); return 0; } now, debug client1, then debug client2. Client 2 should start with mutated shared state(1337). -- View this message in context: http://forum.world.st/Can-Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
#pragma data_seg("SHARED") looks like this is doing some serious IPC magic behing the scenes. Check this out for some critters: https://social.msdn.microsoft.com/Forums/vstudio/en-US/bc93445e-cec3-456d-95... Phil On Wed, Oct 12, 2016 at 9:34 AM, CodeDmitry <dimamakhnin@gmail.com> wrote:
Have you got my modified message? or have I been wasting my revisions all along O.o? I'll repost.
O.o can you please elaborate?
I wrote a DLL a while ago that successfully shared the global state it exported between the callers that without any shared memory explicitly being created.
I'll recreate a test case to make sure that I am not just lying.
*Solution SharingDemo*: *Project ShareMe*: *ShareMe.cpp*: #pragma data_seg("SHARED") extern "C" { __declspec(dllexport) int sharedInteger = 0; } #pragma data_seg()
#pragma comment(linker, "/section:SHARED,RWS")
*Project Client1*: *main.cpp*: #include <Windows.h> #include <stdio.h>
int main(int argc, char **argv) { HMODULE module_handle = LoadLibrary("ShareMe.dll"); int *shared_integer_handle = (int *)GetProcAddress(module_handle, "sharedInteger"); printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle);
*shared_integer_handle = 1337;
printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle);
system("pause"); return 0; }
*Project Client2*: *main.cpp*: #include <Windows.h> #include <stdio.h>
int main(int argc, char **argv) { HMODULE module_handle = LoadLibrary("ShareMe.dll"); int *shared_integer_handle = (int *)GetProcAddress(module_handle, "sharedInteger"); printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle);
*shared_integer_handle = 0;
printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle);
system("pause"); return 0; }
now, debug client1, then debug client2. Client 2 should start with mutated shared state(1337).
-- View this message in context: http://forum.world.st/Can- Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp4918693p4918720.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Indeed that pragma looks like a shared memory macro to me Actually one thing I found out is that DLLs and Shared Libraries are implemented via shared memory mapped files without giving access to shared memory. CodeDmitry I did get your message as you can see by the quote of my last reply. You are basically using Shared Memory IPC , its just an ungly Windows hack via a pragma and from the thread that Phil linked it looks like its also bug prone. This is also confirmed by Mircrosoft itself here -> https://msdn.microsoft.com/en-us/library/h90dkhs0(v=vs.90).aspx Summary: Use shared memory mapped files, far safer and far more cross platform On Wed, Oct 12, 2016 at 11:12 AM phil@highoctane.be <phil@highoctane.be> wrote:
#pragma data_seg("SHARED")
looks like this is doing some serious IPC magic behing the scenes.
Check this out for some critters: https://social.msdn.microsoft.com/Forums/vstudio/en-US/bc93445e-cec3-456d-95...
Phil
On Wed, Oct 12, 2016 at 9:34 AM, CodeDmitry <dimamakhnin@gmail.com> wrote:
Have you got my modified message? or have I been wasting my revisions all along O.o? I'll repost.
O.o can you please elaborate?
I wrote a DLL a while ago that successfully shared the global state it exported between the callers that without any shared memory explicitly being created.
I'll recreate a test case to make sure that I am not just lying.
*Solution SharingDemo*: *Project ShareMe*: *ShareMe.cpp*: #pragma data_seg("SHARED") extern "C" { __declspec(dllexport) int sharedInteger = 0; } #pragma data_seg()
#pragma comment(linker, "/section:SHARED,RWS")
*Project Client1*: *main.cpp*: #include <Windows.h> #include <stdio.h>
int main(int argc, char **argv) { HMODULE module_handle = LoadLibrary("ShareMe.dll"); int *shared_integer_handle = (int *)GetProcAddress(module_handle, "sharedInteger"); printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle);
*shared_integer_handle = 1337;
printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle);
system("pause"); return 0; }
*Project Client2*: *main.cpp*: #include <Windows.h> #include <stdio.h>
int main(int argc, char **argv) { HMODULE module_handle = LoadLibrary("ShareMe.dll"); int *shared_integer_handle = (int *)GetProcAddress(module_handle, "sharedInteger"); printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle);
*shared_integer_handle = 0;
printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle);
system("pause"); return 0; }
now, debug client1, then debug client2. Client 2 should start with mutated shared state(1337).
-- View this message in context: http://forum.world.st/Can-Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (3)
-
CodeDmitry -
Dimitris Chloupis -
phil＠highoctane.be