Can Pharo VM be altered to act like GNUStep as well?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Can Pharo VM be altered to act like GNUStep as well?

CodeDmitry
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

philippeback
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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

CodeDmitry
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

kilon.alios
In reply to this post by philippeback
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
Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

philippeback
Here is for reference how COM works:


On Tue, Oct 11, 2016 at 11:02 PM, Dimitris Chloupis <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

philippeback
In reply to this post by kilon.alios
Here is for reference, how COM works inside:


Wrapping that with a .NET layer hurts my eyes.

Phil

On Tue, Oct 11, 2016 at 11:02 PM, Dimitris Chloupis <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

CodeDmitry
This post was updated on .
In reply to this post by CodeDmitry
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

philippeback
.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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

CodeDmitry
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

kilon.alios
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 <[hidden email]> 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-tp4918693p4918701.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

CodeDmitry
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

kilon.alios
Here you go

http://stackoverflow.com/questions/19373061/what-happens-to-global-and-static-variables-in-a-shared-library-when-it-is-dynam

On Wed, 12 Oct 2016 at 02:33, CodeDmitry <[hidden email]> 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-tp4918693p4918710.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

CodeDmitry
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

philippeback
#pragma data_seg("SHARED")

looks like this is doing some serious IPC magic behing the scenes.


Phil

On Wed, Oct 12, 2016 at 9:34 AM, CodeDmitry <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Can Pharo VM be altered to act like GNUStep as well?

kilon.alios
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 [hidden email] <[hidden email]> wrote:
#pragma data_seg("SHARED")

looks like this is doing some serious IPC magic behing the scenes.


Phil

On Wed, Oct 12, 2016 at 9:34 AM, CodeDmitry <[hidden email]> 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.