- Pharo-dev - lists.pharo.org

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

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

by CodeDmitry

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-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

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

Oct. 11, 2016

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

by CodeDmitry

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

Oct. 11, 2016

Re: [Pharo-dev] Halt once

by stepharo

I improved all the comments that I could. Now this is better. especially since the new version in Ph6.0 do not need to be restarted. Stef Le 10/10/16 Ã 02:08, Ben Coman a Ã©crit : > On Mon, Oct 10, 2016 at 3:26 AM, stepharo <stepharo(a)free.fr> wrote: >> Hi guys >> >> we can do better in terms of comments. >> >> https://pharo.fogbugz.com/f/cases/19193/Halt-once-comment-mega-sucks >> >> In Pharo 60 I tried to use Halt once. >> >> There is no menu to set it up anymore so I looked in the class ... :( >> >> What a supercool and welcoming comment >> >> Halt is provided to support Object>>halt. >> >> once >> | callingContext senderContext node | >> <debuggerCompleteToSender> > I touched that last so I'll take it on the chin. > I guess there were no comments before I updated it and was complacent > about comments status quo. > > Freshening up existing comments (or lack of) hasn't been in the > forefront of my mind, but you are right, modifying an existing method > is a good opportunity to improve comments. > > cheers -ben > >

Oct. 11, 2016

Re: [Pharo-dev] Shout style table editor (Request for Feedback)

by stepharo

Le 10/10/16 Ã 19:30, Sven Van Caekenberghe a Ã©crit : > Wow, that looks very nice ! + 10 I want that :) > >> On 10 Oct 2016, at 18:42, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> I am working on a syntax style table editor, see issue for some background about this. >> 18322 Settings for Syntax Highlighting a bit confusing >> 15409 A more complete set of syntactic colors is needed >> >> >> Load package >> >> ST-StylingPreview >> ST-StylingPreviewShoutExtension >> >> from >> >> MCHttpRepository >> location: 'http://smalltalkhub.com/mc/NicolaiHess/StylerTableEditor/main' >> user: '' >> password: '' >> >> And open the preview/editor with: >> >> STStylerPreview open. >> >> This is a prototype, you can view builtin style tables, create and edit new custom style tables. >> This has some fake code styler methods to make the styling work for the >> code preview pane, and it supports more styling attributes than the default styler. >> >> This is what I would like to have as a syntax style setting dialog instead of the current >> confusing behavior. It may be helpful to actually see what syntax styling attributs are >> actually available. >> >> >> <PharoScreenshot.3.png> > >

Oct. 11, 2016