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

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by stepharo

Hi eliot > Good question. Let's be clear there are two issues here. One, that > shouldn't be in doubt, is that Pharo should use the simple mirror > primitives I provided that are already in the VM asap both to provide > low level inspectors for proxies and to make the debugger/execution > simulator correct. Note that process termination, where a > high-priority process terminates a lower one, and end up invoking the > execution simulation machinery in getting to a point where unwind > blocks can be executed, so the correctness issue can bite in the base > system, not just when debugging. > > The other issue is your question, should there be a proper set of > mirror objects as described by Gilad Bracha. The rationale for proper > mirrors is security; to avoid making dangerous primitives like > instVarAt: and object:instVarAt: (not to mention allInstances, > allObjects, class itself, etc etc) generally available so people can > write secure code. This is a great rationale, and makes sense, but > the current system is a /long/ way away from that. A truly secure > system (meaning a single Smalltalk system which could allow untrusted > Smalltalk scripts to run within it and not provide these scripts with > the ability to break (into) code in the system) would require much > more work than merely providing proper mirrors. The whole system of > object access, method access, class manipulation needs to be > implemented in a secure manner. That's a great long term project, but > just adding mirrors is very far from enough. > > Our experience at Cadence where we have used the newspeak mirror > system in a non secure squeak host, is that mirrors introduce a lot of > complexity and performance overhead and so we've been eliminating > their use. Our application provides an SOC domain model that used to > be manipulated by mirrors, but we're phasing that out because it costs > so much in performance. > > So my considered opinion is that we should not add proper mirrors to > current Pharo, because we will pay the performance and complexity > penalties but not get the security reward. Instead, there should be > research projects on small simple systems that attempt to architect a > usable secure Smalltalk environment, and when that architecture > demonstrates its viability to port the architecture into Pharo. I > think that's years away. Interesting. I have two questions: - what is the complexity you mentioned? To have an hierarchy of mirrors and calling the right now instead of a method? - for the speed cost: What was it exactly? Creating a mirror and sending a message that will then apply the primitive to the object? I imagine that they are some scenarios - like manipulating a remote object or a different space where the cost should be small compared to other operations At cadence what were the use of mirrors? Stef

Jan. 3, 2016

Re: [Pharo-dev] Pharo-contribution down

by Esteban Lorenzano

everything is down I think we need to wait âtill monday to fix it :( Esteban > On 02 Jan 2016, at 18:39, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > The Jenkins for pharo-contribution seems to be down: builds never > finish. > > https://ci.inria.fr/pharo-contribution > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill >

Jan. 2, 2016

Pharo-contribution down

by Damien Cassou

The Jenkins for pharo-contribution seems to be down: builds never finish. https://ci.inria.fr/pharo-contribution -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Jan. 2, 2016

[Survey] Forking Operating System Proces in Pharo

by Mariano Martinez Peck

Dear all, As I mentioned in the thread "Pharo Consortium Sponsored Development Effort" [1] I built a survey about Forking Operating System Processes in Pharo. The idea of the survey is simple: I want to understand what people needs the most, which features would be useful, which ones would not, what is missing, what is wrong, etc etc etc. As always, since we have limited resources, we should optimize them as much as possible. I count with you so that we can make a roadmap together on this project. Please, feel free to forward this survey anywhere where there could be an interest. https://www.surveymonkey.com/r/DHR22TL Best regards, [1] http://forum.world.st/ANN-Pharo-Consortium-Sponsored-Development-Effort-td4… -- Mariano http://marianopeck.wordpress.com

Jan. 2, 2016

Re: [Pharo-dev] [OT] Open source everything

by philippe.back＠highoctane.be

Interesting read. Will take action along these lines. Phil On Jan 2, 2016 12:37 PM, "Eliot Miranda" <eliot.miranda(a)gmail.com> wrote: > Happy new year! > > http://gu.com/p/3q95q <http://gu.com/p/3q95q?CMP=Share_iOSApp_Other> > > _,,,^..^,,,_ (phone) >

Jan. 2, 2016

how to make a method inlined

by Ben Coman

Since DelayScheduler runs very often at the highest priority, the desire is to have it highly optimised. One way to do this is put everything into a very long method to avoid the overhead of message sends. Another might be to keep it logical split into several method for readability, but have those methods in-lined. I'm sure how pragmatic doing that would be, but it sparked my curiosity.... how do you go about designating a method/message to be inlined. I see OCASTTranslator>>visitMessageNode: (presumably) calls RBMessageNode>>isInlined which does a bundle of checks, for example RBMessageNode>>isInlineIf checks (#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) includes: self selector) ifFalse: But there also seems to be an <inline> pragma per WarpBlt>>rgbMap:from:to: What are the trade-off between these approaches, particularly for the special case where a method may have only one sender, where code is broken into small "private" methods mainly for readability. Also, do you need to manually supply the inlined bytecode yourself? cheers -ben

Jan. 2, 2016

[OT] Open source everything

by Eliot Miranda

Happy new year! http://gu.com/p/3q95q _,,,^..^,,,_ (phone)

Jan. 2, 2016

Re: [Pharo-dev] Happy new year 2016

by Sven Van Caekenberghe

I also thank everybody in the Pharo community for everything that was done in 2015. So much has happened, it was again hard to follow everything in detail. Both at the standard Pharo image and at the VM level, a massive amount of contributions came from everywhere. Many important projects around Pharo made great progress and delivered clear results. Thank you. 2016 will be at least as exciting, everything is set for us to continue moving forward. Sven > On 01 Jan 2016, at 16:57, stepharo <stepharo(a)free.fr> wrote: > > Hi Pharoers > > I want to thank all of you for making Pharo what it is becoming: a Really Cool system and community. > > I wish you good health and a lot of business or fun in Pharo :). > > 2016 will see many changes that are planned > to name a few > - Pharo 5.0 with Spur > - Pharo 5.0 with 64 bits > - Bootstrap Pharo in production > - SDL full integration > - Git and Package validation > - A full Mooc on Pharo > - A couple of cool tutorials > And I'm sure many unexpected project and libraries... > > The consortium should continue to grow so if you are hesitating to join please do. > > Stef >

Jan. 1, 2016

Re: [Pharo-dev] [Pharo-users] Happy new year 2016

by philippe.back＠highoctane.be

Happy New Year to the Community that makes the tool with the shortest path between the brain and actual tangible executable results. I am appreciating it even more now that I have to work with toolchains requiring lengthy compilation. How primitive. Let's make 2016 a great Pharo year. And see you at PharoDays! Phil On Jan 1, 2016 7:55 PM, "Trussardi Dario Romano" <dario.trussardi(a)tiscali.it> wrote: > > > > Happy new year to all! > > + 1000 > > > > > Alexandre > > > > > >> On Jan 1, 2016, at 12:57 PM, stepharo <stepharo(a)free.fr> wrote: > >> > >> Hi Pharoers > >> > >> I want to thank all of you for making Pharo what it is becoming: a Really Cool system and community. > >> > >> I wish you good health and a lot of business or fun in Pharo :). > >> > >> 2016 will see many changes that are planned > >> to name a few > >> - Pharo 5.0 with Spur > >> - Pharo 5.0 with 64 bits > >> - Bootstrap Pharo in production > >> - SDL full integration > >> - Git and Package validation > >> - A full Mooc on Pharo > >> - A couple of cool tutorials > >> And I'm sure many unexpected project and libraries... > >> > >> The consortium should continue to grow so if you are hesitating to join please do. > >> > >> Stef > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > >

Jan. 1, 2016

Re: [Pharo-dev] [Pharo-users] Happy new year 2016

by Trussardi Dario Romano

> Happy new year to all! + 1000 > > Alexandre > > >> On Jan 1, 2016, at 12:57 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi Pharoers >> >> I want to thank all of you for making Pharo what it is becoming: a Really Cool system and community. >> >> I wish you good health and a lot of business or fun in Pharo :). >> >> 2016 will see many changes that are planned >> to name a few >> - Pharo 5.0 with Spur >> - Pharo 5.0 with 64 bits >> - Bootstrap Pharo in production >> - SDL full integration >> - Git and Package validation >> - A full Mooc on Pharo >> - A couple of cool tutorials >> And I'm sure many unexpected project and libraries... >> >> The consortium should continue to grow so if you are hesitating to join please do. >> >> Stef >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Jan. 1, 2016