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-tp4918693.html
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

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-tp4918693p4918699.html
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-tp4918693p4918720.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.