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

[Pharo-project] Pharo Morphic View Application Framework

by S Krish

http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework… Obliged for feedback ... For details and links.. Sharing this little framework that should go some way to ease creating large applications ( currently morphic oriented). AbstractMorphicView subclass: #MyNewView â¦ #createMorphsSpecs ^{ âpanel1â² -> #SomeOtherView. âlabel1â² -> #LabelMorph. âtext1â² -> #PluggableTextMorph. âbutton1â² -> #PluggableButtonMorph. } layoutSpecsArray ^{ âwidgetNameInMorphsDictionaryâ -> { #fractions -> (0 @ 0 corner: 1 @ 0.5). â fractional value 0 to 1 range â #offsets -> (10 @ 10 corner: 0 @ 0). â offsets relative to the fractional position â }. ââ¦ add other widgetspecsâ¦â } Thats it.. you should have a prototype UI neatly laid out.. and then specify: #morphsPrimaryPropertiesSpecs and #morphsSecondaryPropertiesSpecs for full functionality that composes views inside views and scales well. AbstractSimpleMorphicView can make it simpler for TableLayout stuff without requiring #layoutSpecsArray. ..... the main post has other details and links to package...

Jan. 31, 2012

Re: [Pharo-project] Following context execution

by Eliot Miranda

On Sun, Jan 29, 2012 at 1:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi > > I would like to write some tests about MethodContext and BlockClosure > activation. > To start I wanted to write a simple invocation and step in from context to > context. > > I could manually annotate the code with thisContext and store the > resulting contexts > somewhere. But does anybody has some magic information so that I can reuse > the debugger logic? > ContextPart>runSimulated:atEachStep:, e.g. | last | last := thisContext. thisContext runSimulated: [#(1 2 3) detect: [:e| e even]] contextAtEachStep: [:c| c ~~ last ifTrue: [Transcript print: c; cr; flush. last := c]] => [] in UndefinedObject>>DoIt Array(Collection)>>detect: Array(Collection)>>detect:ifNone: Array(SequenceableCollection)>>do: [] in Array(Collection)>>detect:ifNone: [] in [] in UndefinedObject>>DoIt SmallInteger>>even [] in [] in UndefinedObject>>DoIt [] in Array(Collection)>>detect:ifNone: Array(SequenceableCollection)>>do: [] in Array(Collection)>>detect:ifNone: [] in [] in UndefinedObject>>DoIt SmallInteger>>even [] in [] in UndefinedObject>>DoIt [] in Array(Collection)>>detect:ifNone: Array(Collection)>>detect: [] in UndefinedObject>>DoIt or... | last home indent | last := nil. home := thisContext. indent := 0. thisContext runSimulated: [#(1 2 3) detect: [:e| e even]] contextAtEachStep: [:c| | ctxt | c ~~ last ifTrue: [last := c. indent := 0. ctxt := c sender. [ctxt ~~ home] whileTrue: [ctxt := ctxt sender. indent := indent + 1]. Transcript crtab: indent; print: c; flush]] [] in UndefinedObject>>DoIt Array(Collection)>>detect: Array(Collection)>>detect:ifNone: Array(SequenceableCollection)>>do: [] in Array(Collection)>>detect:ifNone: [] in [] in UndefinedObject>>DoIt SmallInteger>>even [] in [] in UndefinedObject>>DoIt [] in Array(Collection)>>detect:ifNone: Array(SequenceableCollection)>>do: [] in Array(Collection)>>detect:ifNone: [] in [] in UndefinedObject>>DoIt SmallInteger>>even [] in [] in UndefinedObject>>DoIt [] in Array(Collection)>>detect:ifNone: Array(Collection)>>detect: [] in UndefinedObject>>DoIt -- best, Eliot

Jan. 30, 2012

Re: [Pharo-project] pharo vision

by Henrik Sperre Johansen

On 30.01.2012 23:02, StÃ©phane Ducasse wrote: > On Jan 30, 2012, at 5:10 PM, Henrik Johansen wrote: > >> Going back to pure ANSI-streams as provided by FSFileStream is not really an option. > Can you elaborate on your previous sentence? > Because the underlying reason is not 100% clear to me. FSFileStreams are pure ansi-protocol compliant streams. No buffering, no optimization, strange concoction of the underlying primitives (like Nicolas mentioned, always pairing seek and read), no "built-in" way to translate using encodings, no other bells, no whistles. Creating such streams from the FSPath stream creation API makes little to no sense, lest the goal is to provide a simple API for accessing streams in a cross-platform manner, in which case I guess you'd leave the rest of the work to other non-ansi, but cross-platform libraries. Cheers, Henry

Jan. 30, 2012

Re: [Pharo-project] pharo vision

by StÃ©phane Ducasse

Thanks serge I do not know how to help. Now I hope that a small kernel will help. I hope to allocate some time and ben will work three months on it again. Stef On Jan 30, 2012, at 5:24 PM, Serge Stinckwich wrote: > On Mon, Jan 30, 2012 at 3:24 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> > > Thank you for this nice vision. > > I think "Language and Remote IDEs for small devices" and "robotics" > could be merge in the same section about "embedded system", because > they share more or less the same concerns: small kernel, C/C++ > integration, headless system, reliable networking support, remote > debugging, customizable real-time gc, ... Having the possibility of > mixing several domain-specific languages is also quite interesting in > robotics, see for the example the recent series of workshop i organize > recently: http://www.doesnotunderstand.org/wikka.php?wakka=DSLRob11 > I try to push Smalltalk use in robotics in several projects: > 1) SqueakBot (http://wiki.laptop.org/go/Projects/SqueakBot) 2) > PlayerST to control Player/Stage robotic simulation > (http://www1.ifi.auf.org/mediawiki/index.php/Smalltalk_Player_Client) > 3) ROSTalk to connect Smalltalk and ROS > (https://github.com/SergeStinckwich/rostalk) > but this is still difficult because most of the robotic stuff are > written in C/C++ and also the lack of manpower ... > It's easier at the moment to use Python or Lua for robots than > Smalltalk. Look here: https://github.com/timn/roslua > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Matsuno Laboratory, Kyoto University, Japan (until 12/2011) > http://www.mechatronics.me.kyoto-u.ac.jp/ > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ >

Jan. 30, 2012

Re: [Pharo-project] pharo vision

by StÃ©phane Ducasse

On Jan 30, 2012, at 5:27 PM, Nicolas Cellier wrote: > I think the best option with Xtreams > (http://code.google.com/p/xtreams/ ) is to rewrite client code. > This is why the designers have chosen a set of new selectors. > > If we think it's time to remove some cruft, but still have late client > adopters, we could also write a wrapper providing old Stream API in > Xtreams > Something like: > > 'foo' reading withStreamAPI > > Then replace ReadStream/WriteStream with such factory... > > Of course, replicating the whole zoo of specialized selectors of > current Stream library is not an option IMO. > > Nicolas Nicolas my main concern is - we got documentation for Streams and I would like it got adapted. - lack of manpower but if somebody would drive this effort I would survive and accept Xstreams (even if I have some doubts on the API) The document is also to build a common roadmap on which we can gather energy and effort to get some real momentum. This document is to show the vision we got since long time and that we were not able to share. Stef

Jan. 30, 2012

Re: [Pharo-project] pharo vision

by StÃ©phane Ducasse

On Jan 30, 2012, at 5:10 PM, Henrik Johansen wrote: > > On Jan 30, 2012, at 9:24 14AM, StÃ©phane Ducasse wrote: > >> <main.pdf> > Nice! > > Some comments on the parts I'm most familiar with: > 3.2 > I agree, the nice parts in FS to me is the path manipulation API. > Going back to pure ANSI-streams as provided by FSFileStream is not really an option. Can you elaborate on your previous sentence? Because the underlying reason is not 100% clear to me. > Since it's a clean break from FileDirectory & friends though, it might be the perfect time to introduce XTreams; -or it might be too much hassle to have to change both parts in existing code at once. > > A good compromise would be to make it pluggable, using the existing Standard/MultiByteFileStreams by default, but making XStreams pluggable (on a use--by-use basis, so you can write new code with XStreams while maintaining old code where you have only had time to rewrite the path handling) > > 3.3 > "Using ephemerons we can then simplify the Announcement and make sure that clients do not have to worry about weak or not registration." > You still have to worry about whether you want weak or strong registration. > "Do I have strict requirements for when the announcement should stop being delivered in relation to subscriber lifespan?" is still a valid question. > What you don't have to worry about, is what _type_ of subscription (action blocks or message sends), you are allowed to use when registering weakly. Yes this is what I wanted to write :) Fixed it. > > Ends with "In addition, " then nothing :) :) Fixed :) > > Cheers, > Henry

Jan. 30, 2012

Re: [Pharo-project] PseudoContext?

by StÃ©phane Ducasse

Indeed ActivationContext is nicer. I will use that one :) Stef > > > On Mon, Jan 30, 2012 at 1:21 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > Also, collapsing ContextPart and MethodContext onto just Context (or ActivationContext (?)) would be nice. > > > > Thanks for the suggestion I will do it. What is the best choice to avoid incompatibility? Having MethodContext I guess. > > > > Yes. But it is perhaps worth making the change incompatible to say goodbye to BlockContext? One can always do > > Smalltalk at: #MethodContext put: ActivationContext > > to get older packages to load. I don't know what's best, but for once I like the clean-up :) > > I see :) > > I was more concerned about the fact that VM people may rely on MethodContext (name) while ContextPart as a superclass > should not be used (or has a lower probably to be used). > > Right. My point is that MethodContext is now a bad name since MethodContext represents both method and block activations. > > > Stef > > > > > > -- > best, > Eliot >

Jan. 30, 2012

Re: [Pharo-project] PseudoContext?

by Eliot Miranda

On Mon, Jan 30, 2012 at 1:21 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > Also, collapsing ContextPart and MethodContext onto just Context (or > ActivationContext (?)) would be nice. > > > > Thanks for the suggestion I will do it. What is the best choice to avoid > incompatibility? Having MethodContext I guess. > > > > Yes. But it is perhaps worth making the change incompatible to say > goodbye to BlockContext? One can always do > > Smalltalk at: #MethodContext put: ActivationContext > > to get older packages to load. I don't know what's best, but for once I > like the clean-up :) > > I see :) > > I was more concerned about the fact that VM people may rely on > MethodContext (name) while ContextPart as a superclass > should not be used (or has a lower probably to be used). > Right. My point is that MethodContext is now a bad name since MethodContext represents both method and block activations. > Stef > > > -- best, Eliot

Jan. 30, 2012

Re: [Pharo-project] PseudoContext?

by StÃ©phane Ducasse

> > Also, collapsing ContextPart and MethodContext onto just Context (or ActivationContext (?)) would be nice. > > Thanks for the suggestion I will do it. What is the best choice to avoid incompatibility? Having MethodContext I guess. > > Yes. But it is perhaps worth making the change incompatible to say goodbye to BlockContext? One can always do > Smalltalk at: #MethodContext put: ActivationContext > to get older packages to load. I don't know what's best, but for once I like the clean-up :) I see :) I was more concerned about the fact that VM people may rely on MethodContext (name) while ContextPart as a superclass should not be used (or has a lower probably to be used). Stef

Jan. 30, 2012

[Pharo-project] Fwd: [vwnc] Smalltalk for small projects only?

by Janko MivÅ¡ek

-------- Prvotno sporoÄilo -------- Zadeva: Re: [vwnc] Smalltalk for small projects only? Datum: Mon, 30 Jan 2012 19:27:31 +0000 Od: Niall Ross <niallfr(a)btinternet.com> Dear Janko, (tried to send this to Pharo and squeak mailing lists as well as well as vwnc and you - got a hiccough; trying again just to vwnc and you). The largest Smalltalk project I've experienced was Kapital. They were approaching 70 developers in 4 locations in 2005 and IIUC are larger now. They use an in-house process based on Envy. Frequent rebuilding of images is forced by aging of Envy repositories, properly committed stuff being copied over. Thus developers are obliged to use correct process or lose code. I described the process briefly in a secondary talk (not my main one) at ESUG 2004, and Jan Monclair gave more recent info at ESUG 2008 and ESUG 2009 (see my reports on the ESUG website). A developer I knew there had practical experience of a rival's attempt to replicate their achievement in Java, using comparable resources, that crashed and burned. I've worked in two teams of 15 - 20 developers (one on a single site, one at two sites), each of which were verifiably matching systems maintained by ~100 developers in rivals. These were both in the insurance domain. In one of these, Envy-based, each developer rebuilt their image each day - the process took quite a few minutes but was valuable. In the other, images were eternal (yes, I do mean that!); it would take a long time to describe their process and even longer to convince readers that, contrary to what I at first thought and what most of you will think, it was a viable development process. All the other Smalltalk teams I've worked in, prior to coming to Cincom, were in single figures and used Store or Envy. One of them was verifiably rivalling a sytem of 10s of people in another language. Conclusions: 1) As your Smalltalk project gets large, you will need to put process and tools in place on top of what Envy, or Store, or, as Dale says, Monticello and Metacello, give you out-of-the-box at the moment. (It is news to me if Java projects of 200 people do not find the same, but I defer to those with more - which means any - experience of being in a 200-person Java project to correct me if that is not so - or is less so in some important respect.) It would be good if Smalltalk projects that find themselves growing into this area could get a tool/add-on that conveyed existing experience and solutions instead of having to re-roll their own superstructure on existing tools. (In Cincom, we are attempting to use our own development-process and build-process-improvement work to achieve this.) 2) Combining Kapital experience with the ratio one can justify between 'Smalltalk developers needed to do' and 'Java developers needed to do', persuades me that there is no limit on the complexity of problem Smalltalk can attack relative to its rivals. 3) I agree with Dale that making the minumum image smaller is the way to go. (Again, we wish to do this in VW; as always, such efforts progress slowly in background while we meet immediate requirements.) Yours faithfully Niall Ross -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Jan. 30, 2012