May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] mixing open and closed source within Pharo

by Marcus Denker

On May 30, 2012, at 8:01 PM, Frank Shearar wrote: > On 30 May 2012 18:36, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 30 May 2012 16:04, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> What ideas are floating around about mixing open source and closed source >>> using Pharo? I am implementing an IEC Standard object model for electrical >>> power systems to provide a platform for developing electrical applications. >>> I am considering the case where a company may maintain the model of their >>> electrical power distribution network in the open source platform, but then >>> buy various commercial plug-ins perform different calculations upon the >>> shared model. Here are the options I can imagine... >>> >>> 1. Using fuel to load binary packages within the one image without the >>> source. Currently available technology but viewing and decompiling bytecode >>> is still possible - but to what degree this enables reverse engineering I am >>> not sure. >> >> Decompiler is able to fully reproduce the source code of method. >> only variable names is lost, but you can see everything else quite clear. > > I don't know the conditions, but Decompiler can certainly keep > variable names _sometimes_. yes, when there is the original source. > Maybe Pharo's and Squeak's Decompiler have > diverged? Not yet but soon :-) > Or maybe it's because the .changes file is available or > something? > yes. -- Marcus Denker -- http://marcusdenker.de

May 30, 2012

Re: [Pharo-project] mixing open and closed source within Pharo

by Frank Shearar

On 30 May 2012 18:36, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 30 May 2012 16:04, Ben Coman <btc(a)openinworld.com> wrote: >> >> What ideas are floating around about mixing open source and closed source >> using Pharo? Â I am implementing an IEC Standard object model for electrical >> power systems to provide a platform for developing electrical applications. >> Â I am considering the case where a company may maintain the model of their >> electrical power distribution network in the open source platform, but then >> buy various commercial plug-ins perform different calculations upon the >> shared model. Â Here are the options I can imagine... >> >> 1. Using fuel to load binary packages within the one image without the >> source. Â Currently available technology but viewing and decompiling bytecode >> is still possible - but to what degree this enables reverse engineering I am >> not sure. > > Decompiler is able to fully reproduce the source code of method. > only variable names is lost, but you can see everything else quite clear. I don't know the conditions, but Decompiler can certainly keep variable names _sometimes_. Maybe Pharo's and Squeak's Decompiler have diverged? Or maybe it's because the .changes file is available or something? frank >> 2. Having VM support for restricting displaying/decompiling bytecode. Â To >> avoid the ease of switching to another VM without this restriction, the fuel >> package could be encrypted with a key match one compiled inside the required >> VM. > > this is not an option. > A current Debugger implementation implies that you have access to CM bytecodes. > >> >> 3. Running multiple images on a single VM such that the VM passing message >> calls efficiently between the two images like an "enterprise bus*" - one >> open source and one closed source. Â Any common base objects between the >> images might be shared on a copy-on-write basis. >> >> >> What are your thoughts? >> > > I think option 3 is most vital: > you can communicate between two images like between two parties who > don't trust each other (so images should handshake, use encryption > key(s), and try to log-in one to other), then if succeed, one can be > able to see source code Â use Â remote debugger etc > Nothing new under the sun... > >> cheers -ben >> > > > > -- > Best regards, > Igor Stasenko. >

May 30, 2012

Re: [Pharo-project] mixing open and closed source within Pharo

by Igor Stasenko

On 30 May 2012 16:04, Ben Coman <btc(a)openinworld.com> wrote: > > What ideas are floating around about mixing open source and closed source > using Pharo? Â I am implementing an IEC Standard object model for electrical > power systems to provide a platform for developing electrical applications. > Â I am considering the case where a company may maintain the model of their > electrical power distribution network in the open source platform, but then > buy various commercial plug-ins perform different calculations upon the > shared model. Â Here are the options I can imagine... > > 1. Using fuel to load binary packages within the one image without the > source. Â Currently available technology but viewing and decompiling bytecode > is still possible - but to what degree this enables reverse engineering I am > not sure. Decompiler is able to fully reproduce the source code of method. only variable names is lost, but you can see everything else quite clear. > > 2. Having VM support for restricting displaying/decompiling bytecode. Â To > avoid the ease of switching to another VM without this restriction, the fuel > package could be encrypted with a key match one compiled inside the required > VM. this is not an option. A current Debugger implementation implies that you have access to CM bytecodes. > > 3. Running multiple images on a single VM such that the VM passing message > calls efficiently between the two images like an "enterprise bus*" - one > open source and one closed source. Â Any common base objects between the > images might be shared on a copy-on-write basis. > > > What are your thoughts? > I think option 3 is most vital: you can communicate between two images like between two parties who don't trust each other (so images should handshake, use encryption key(s), and try to log-in one to other), then if succeed, one can be able to see source code use remote debugger etc Nothing new under the sun... > cheers -ben > -- Best regards, Igor Stasenko.

May 30, 2012

Re: [Pharo-project] Log framework

by Francois Stephany

>> We should really think about promoting one framework to be the >> one-and-only to be used in the image itself... >> >> Marcus >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> > Or a defined API that can be swapped out underneath for different > implementations. > Right. That would be awesome. The problem is to know which features should be included and how it maps to the different backends... -- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131

May 30, 2012

Re: [Pharo-project] Zinc/Zodiac Documentation

by Sean P. DeNigris

Sven Van Caekenberghe wrote > > Now that I have recovered from the intensive Pharo Conference, I found the > time to publish the Zinc and Zodiac documentation. > ... > http://zn.stfx.eu/zn/zinc-http-components-paper.html > http://zdc.stfx.eu/zodiac-paper.html > Wow, really clear and thorough. The way the raw internet protocols are woven into the examples is really cool (I always have to be reminded that there's no magic, just binary turtles all the way down)... And I found numberOfRetries:, retryDelay:, contentReader:, and #enforceHttpSuccess: particularly useful in simplifying my code A few thoughts: * ZnClient>>retryDelay: - it'd be nice if it took aDuration. If I was reading someone else's code, "client retryDelay: 30" forces me to find the method, but "client retryDelay: 30 seconds" is clear - I think it should return self, like enforceHttpSuccess:. Besides consistency, it will avoid having to send #yourself when configuring a new client instance. * JSJsonParser - where does this class live? A reference would be great... * FileSystem - I remember you mentioned having a problem with FS. Has this been solved? There is a slice in the inbox which replaces all uases of FileDirectory and friends with FS. Also, how will this effect portability (e.g. to Squeak). If you make Zn depend on FS, is the Pharo (renamed classes) version of FS loadable in Squeak trunk? * [up/down]load convenience methods - What do you think about adding e.g. ZnEasy>>download:to: & upload:to: (is POST a good default?) -- View this message in context: http://forum.world.st/Zinc-Zodiac-Documentation-tp4632114p4632508.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 30, 2012

Re: [Pharo-project] moving Finder up to first level of World menu

by Ben Coman

Benjamin wrote: > +1 :) > > You can also use the finder plugin for Nautilus made by Damien Cassou :) > > Ben > Thanks. I'll try it. > On May 30, 2012, at 11:43 AM, Ben Coman wrote: > > >> Has any consideration been given to moving World > Tools > Finder up to World > Finder. >> I find this is core to my work flow and I it is used much more often than any of System Browser, Workspace, Test Runner or Monticello Browser - and I wonder if anyone finds the same? >> >> cheers -ben >> >> > > > >

May 30, 2012

Re: [Pharo-project] moving Finder up to first level of World menu

by Benjamin

+1 :) You can also use the finder plugin for Nautilus made by Damien Cassou :) Ben On May 30, 2012, at 11:43 AM, Ben Coman wrote: > > Has any consideration been given to moving World > Tools > Finder up to World > Finder. > I find this is core to my work flow and I it is used much more often than any of System Browser, Workspace, Test Runner or Monticello Browser - and I wonder if anyone finds the same? > > cheers -ben >

May 30, 2012

Re: [Pharo-project] moving Finder up to first level of World menu

by Sean P. DeNigris

btc wrote > > - and I wonder if anyone finds the same? > Yes, I always add that in my images (as well as commands to build fresh 1.3/1.4/etc image, and open the issue tracker/jenkins in a browser). -- View this message in context: http://forum.world.st/moving-Finder-up-to-first-level-of-World-menu-tp46324… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 30, 2012

[Pharo-project] moving Finder up to first level of World menu

by Ben Coman

Has any consideration been given to moving World > Tools > Finder up to World > Finder. I find this is core to my work flow and I it is used much more often than any of System Browser, Workspace, Test Runner or Monticello Browser - and I wonder if anyone finds the same? cheers -ben

May 30, 2012

Re: [Pharo-project] Glamorous Inspector

by Igor Stasenko

On 30 May 2012 16:47, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > I'm trying to load the Glamorous Inspector in 2.0. > Besides some difficulties with non-present versions in some > Configs (RB and Co) I got the thing more or less running. > > However it doesn't find BorderedSubpaneDividerMorph, any chance where I might find this class? > in trash bin: http://code.google.com/p/pharo/issues/detail?id=5193 > best > cami > > -- Best regards, Igor Stasenko.

May 30, 2012