- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Collection new

by S Krish

In general why is there not a catch all for Stack Overflow and infinite loops. Thats very annoying for newbie.. and infact gives a bad feel to using Pharo. The image they are working for say 3-4 hours and the crash just pushes them out of all the code they are working on with.. small as it maybe.. Recover / and other options are fallbacks but invariably newbies have it messed up and are not very clear on how to recover either .. thats a job for the experienced user actually... This occurs so often from all of the polling code.. and if anyone unknowingly puts in a debug point in the methods that loop infinitely.. and so many of them lurk all around the image.. Just stop the loop and throw up a debugger if say 100 calls have gone to very same method..? or detect a clear loopback to the same method.. On Tue, Jan 31, 2012 at 12:01 AM, Andrew P. Black <black(a)cs.pdx.edu> wrote: > Teaching a class of novices, it's not surprising that someone tried > "Collection new". What was surprising is that this got the VM is a loop of > some kind, with emergency stack dumps and so on. > > Here is my reply: > > > > On 30 Jan 2012, at 01:18 , Xingzhi Harry Pan wrote: > > > >> ...it's pretty innocent: > >> Collection new > > > > > > OK. I looked at this. The problem comes when trying to print the > collection. Somehow the VM gets confused when trying to do do: ... I'm not > quite clear why. > > > > The quick fix is to change the Collection>>new method to > > > > self error: 'Collection is an abstract class, and cannot be > instantiated' > > > > However this will break Heap>>new: , which sends super new. It ought to > send self basicNew instead. > > > > These two changes seem to avoid the problem, but I'm waiting to see ... > > > > Andrew > > But I don't understand the root cause. Printing eventually sends do:, > which is self subclassResponsibility. Why don't we get a clean failure? > > Andrew > > >

Jan. 31, 2012

[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