October 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by CodeDmitry

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

Oct. 12, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by Dimitris Chloupis

Here you go http://stackoverflow.com/questions/19373061/what-happens-to-global-and-stat… On Wed, 12 Oct 2016 at 02:33, CodeDmitry <dimamakhnin(a)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-t… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 12, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by CodeDmitry

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

Oct. 11, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by Dimitris Chloupis

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(a)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-t… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 11, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by CodeDmitry

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

Oct. 11, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by phil＠highoctane.be

.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(a)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. > >

Oct. 11, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by CodeDmitry

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

Oct. 11, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by phil＠highoctane.be

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(a)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 >

Oct. 11, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by phil＠highoctane.be

Here is for reference how COM works: On Tue, Oct 11, 2016 at 11:02 PM, Dimitris Chloupis <kilon.alios(a)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 >

Oct. 11, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by Dimitris Chloupis

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

Oct. 11, 2016