December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why Smalltalk ? Which Smalltalk ?

by Miguel CobÃ¡

El mar, 21-12-2010 a las 18:51 +0100, Levente Uzonyi escribiÃ³: > On Tue, 21 Dec 2010, Sven Van Caekenberghe wrote: > > > > > On 21 Dec 2010, at 00:14, Levente Uzonyi wrote: > > > >> Really? The third question has 3 wrong answers... > > > > OK, I'll take the bait: I was looking for a high-quality, professional, well-maintained open-source Smalltalk supported by an active community with the right ideas, attitudes and ideals going forward, and I am happy I found it. And it seems I am not the only one. > > I guess you're missing my point, which is: the post has false statements. Maybe you can show us the false statements and not let us guess what are you refering to > And a decision is based on these false statements. > > > Levente > > > > > Sven > > > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Dec. 21, 2010

Re: [Pharo-project] Why Smalltalk ? Which Smalltalk ?

by Levente Uzonyi

On Tue, 21 Dec 2010, Sven Van Caekenberghe wrote: > > On 21 Dec 2010, at 00:14, Levente Uzonyi wrote: > >> Really? The third question has 3 wrong answers... > > OK, I'll take the bait: I was looking for a high-quality, professional, well-maintained open-source Smalltalk supported by an active community with the right ideas, attitudes and ideals going forward, and I am happy I found it. And it seems I am not the only one. I guess you're missing my point, which is: the post has false statements. And a decision is based on these false statements. Levente > > Sven > > >

Dec. 21, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by Dale Henrichs

On 12/21/2010 09:05 AM, Sean P. DeNigris wrote: > > > Eliot Miranda-2 wrote: >> >> When I started working for ParcPlace Systems companies like JPMorgan >> didn't >> allow us to name then since using Smalltalk was such an important >> competitive advantage. >> > > Julian Fitzell says that this is still the case @ http://vimeo.com/17503969 > > Sean I can confirm that this is still true today for GemStone... Dale

Dec. 21, 2010

Re: [Pharo-project] a way to ignore warnings?

by Dale Henrichs

On 12/20/2010 09:27 PM, HernÃ¡n Morales Durand wrote: > 2010/12/20 Esteban Lorenzano<estebanlm(a)gmail.com>: >> duh... >> [ ... ] on: Warning do: [ :w | w resume ]. >> forget my question... :( > > That wouldn't make it for Notifications such as: > > self inform: 'test' > > so you might want to write: > > [ self inform: 'test' ] > on: Warning, Notification > do: [: ex | ex return: 'Ignored: ' , ex class name , ' ' , ex messageText ]. > I would be careful about handling all Notifications. Unlike Error, there is no "correct" pattern for handling Notifications, just take a look at all implementors of #defaultAction for subclasses of Notification and you will see that in most cases, the default action returns an application specific object, so returning a String instead will break them all .. Notifications are meant to be ignored unless you know what you are doing. It turns out that even handling Warning can be dangerous. For Warning it is correct to use #resume to ignore the Warning (which ends up doing a `ex resume: nil`). However, UndeclaredVariableWarning (a subclass of Warning) expects a Boolean result, so if the code you are wrapping does any compiles you'll have to special case UndeclaredVariableWarning to do `ex resume: true`. To ignore #inform: in Pharo, handling ProvideAnswerNotification is a better choice than Notification, but you need to be aware of the implications of ignoring inform: as ProvideAnswerNotification is used for dealing with: inform: - return value is ignored confirm:: - return values is expected to be a Boolean request: - is expected to be a String As Adrian mentions, if you are want to automate the handling of inform:/confirm:/request: you are better off using valueSupplyingAnswers:. Finally, in the above example using 'ex return:'a string` is not the correct way to ignore a Warning or Notification. The #return: messages returns the arg as the result of the block (unwinding the stack). #resume: returns the arg as the result of the #signal: and continues execution from that point. Take a look at the different results for the following two expressions: | w x y z | w := x:= y:= z:= nil. x:= [ w := #before. y:= self confirm: 'test'. z := #after ] on: ProvideAnswerNotification do: [:ex | ex return: false ]. {w. x. y. z.}. | w x y z | w := x:= y:= z:= nil. x:= [ w := #before. y:= self confirm: 'test'. z := #after ] on: ProvideAnswerNotification do: [:ex | ex resume: false ]. {w. x. y. z.}. HernÃ¡n this is common mistake when putting together simple examples and if I hadn't just finished writing a series of automatic Warning handlers, I wouldn't have picked up on it:) Dale

Dec. 21, 2010

[Pharo-project] Issue 3472 in pharo: Text selection problem in Pharo-dev 1.2

by pharo＠googlecode.com

Status: Accepted Owner: Torsten....(a)astares.de New issue 3472 by Torsten....(a)astares.de: Text selection problem in Pharo-dev 1.2 http://code.google.com/p/pharo/issues/detail?id=3472 - loaded the ConfigurationOfPharo to create a pharo-dev from a core 1.2 - in the welcome workspace evaluate the "ProfStef go" - a new window pops up ("Hello! I'm Professor Stef blah) - run the provided "ProfStef next" from this workspace, the tutorial will change to page (2/27) - now set the cursor behind the provided "ProfStef next." expression and select the text by dragging from right to left -> error: #basicNew: failed Reason: - when selecting the text from right to left a negative size is calculated for the string allocation, see this stack: ByteString class(Object)>>error: Receiver: ByteString Arguments and temporary variables: aString: 'basicNew: failed' Receiver's instance variables: superclass: String methodDict: a MethodDictionary(#asByteArray->(ByteString>>#asByteArray "a Compi...etc... format: 23554 instanceVariables: nil organization: ('accessing' at: at:put: byteAt: byteAt:put: byteSize indexOfAnyO...etc... subclasses: nil name: #ByteString classPool: a Dictionary(#NonAsciiMap->#[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0...etc... sharedPools: nil environment: a SystemDictionary(lots of globals) category: #'Collections-Strings' traitComposition: {} localSelectors: nil ByteString class(Object)>>primitiveFailed: Receiver: ByteString Arguments and temporary variables: selector: #basicNew: Receiver's instance variables: superclass: String methodDict: a MethodDictionary(#asByteArray->(ByteString>>#asByteArray "a Compi...etc... format: 23554 instanceVariables: nil organization: ('accessing' at: at:put: byteAt: byteAt:put: byteSize indexOfAnyO...etc... subclasses: nil name: #ByteString classPool: a Dictionary(#NonAsciiMap->#[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0...etc... sharedPools: nil environment: a SystemDictionary(lots of globals) category: #'Collections-Strings' traitComposition: {} localSelectors: nil ByteString class(Object)>>primitiveFailed Receiver: ByteString Arguments and temporary variables: Receiver's instance variables: superclass: String methodDict: a MethodDictionary(#asByteArray->(ByteString>>#asByteArray "a Compi...etc... format: 23554 instanceVariables: nil organization: ('accessing' at: at:put: byteAt: byteAt:put: byteSize indexOfAnyO...etc... subclasses: nil name: #ByteString classPool: a Dictionary(#NonAsciiMap->#[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0...etc... sharedPools: nil environment: a SystemDictionary(lots of globals) category: #'Collections-Strings' traitComposition: {} localSelectors: nil ByteString class(Behavior)>>basicNew: Receiver: ByteString Arguments and temporary variables: sizeRequested: -1 Receiver's instance variables: superclass: String methodDict: a MethodDictionary(#asByteArray->(ByteString>>#asByteArray "a Compi...etc... format: 23554 instanceVariables: nil organization: ('accessing' at: at:put: byteAt: byteAt:put: byteSize indexOfAnyO...etc... subclasses: nil name: #ByteString classPool: a Dictionary(#NonAsciiMap->#[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0...etc... sharedPools: nil environment: a SystemDictionary(lots of globals) category: #'Collections-Strings' traitComposition: {} localSelectors: nil ByteString class(String class)>>new: Receiver: ByteString Arguments and temporary variables: sizeRequested: -1 Receiver's instance variables: superclass: String methodDict: a MethodDictionary(#asByteArray->(ByteString>>#asByteArray "a Compi...etc... format: 23554 instanceVariables: nil organization: ('accessing' at: at:put: byteAt: byteAt:put: byteSize indexOfAnyO...etc... subclasses: nil name: #ByteString classPool: a Dictionary(#NonAsciiMap->#[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0...etc... sharedPools: nil environment: a SystemDictionary(lots of globals) category: #'Collections-Strings' traitComposition: {} localSelectors: nil ByteString(SequenceableCollection)>>copyFrom:to: Receiver: '"Now you''re a Do It master ! Let''s talk about printing. It''s a Do It which prints the ...etc... Arguments and temporary variables: start: 550 stop: 548 newSize: -1 Receiver's instance variables: '"Now you''re a Do It master ! Let''s talk about printing. It''s a Do It which prints the ...etc... Text>>copyFrom:to: Receiver: a Text for '"Now you''re a Do It master ! Let''s talk about printing. It''s a Do It which ...etc... Arguments and temporary variables: start: 550 stop: 563 realStart: 550 realStop: 548 Receiver's instance variables: string: '"Now you''re a Do It master ! Let''s talk about printing. It''s a Do I...etc... runs: a RunArray runs: #(212 2 1 1 1 1 1 1 2 166 2 4 1 5 1 2 4 1 3 1 2 79 2 14 ...etc... SmalltalkEditor(TextEditor)>>selection Receiver: a SmalltalkEditor Arguments and temporary variables: Receiver's instance variables: morph: a TextMorphForEditView(1029177344) selectionShowing: true model: a LessonView editingState: a SmalltalkEditingState Compiler>>evaluate:in:to:notifying:ifFail:logged: Receiver: a Compiler Arguments and temporary variables: textOrStream: a ReadWriteStream '"Cool ! (I like to say Cooool :) ). You''ve ju...etc... aContext: nil receiver: nil aRequestor: a SmalltalkEditor failBlock: [FakeClassPool adopt: nil. ^ #failedDoit] logFlag: true methodNode: DoIt ^ ProfStef next method: (UndefinedObject>>#DoIt "a CompiledMethod(687603712)") value: a LessonView toLog: nil itsSelection: nil itsSelectionString: nil Receiver's instance variables: sourceStream: a ReadWriteStream '"Cool ! (I like to say Cooool :) ). You''ve ju...etc... requestor: a SmalltalkEditor class: UndefinedObject category: nil context: nil parser: a Parser [rcvr class evaluatorClass new evaluate: self selectionForDoitAsStream in: ctxt to: rcvr notifying: self ifFail: [FakeClassPool adopt: nil. ^ #failedDoit] logged: true] in SmalltalkEditor>>evaluateSelection Receiver: a SmalltalkEditor Arguments and temporary variables: rcvr: nil ctxt: nil Receiver's instance variables: morph: a TextMorphForEditView(1029177344) selectionShowing: true model: a LessonView editingState: a SmalltalkEditingState BlockClosure>>on:do: Receiver: [rcvr class evaluatorClass new evaluate: self selectionForDoitAsStream in: ctxt to: ...etc... Arguments and temporary variables: exception: OutOfScopeNotification handlerAction: [:ex | ex resume: true] handlerActive: true Receiver's instance variables: outerContext: SmalltalkEditor>>evaluateSelection startpc: 116 numArgs: 0 SmalltalkEditor>>evaluateSelection Receiver: a SmalltalkEditor Arguments and temporary variables: result: nil rcvr: nil ctxt: nil Receiver's instance variables: morph: a TextMorphForEditView(1029177344) selectionShowing: true model: a LessonView editingState: a SmalltalkEditingState SmalltalkEditor>>doIt Receiver: a SmalltalkEditor Arguments and temporary variables: Receiver's instance variables: morph: a TextMorphForEditView(1029177344) selectionShowing: true model: a LessonView editingState: a SmalltalkEditingState

Dec. 21, 2010

Re: [Pharo-project] Graph library in Smalltalk - Need for advices

by Alexandre Bergel

Hi Chris, > Hi Alexandre, I only have very limited experience with Mondrian, so > please excuse me if this is a stupid question. Is it possible to > employ an Iterator to simply draw on a raster image rather than > creating a model in RAM? Perhaps it could be an option? Would it be > hard to make Mondrian work this way? I am not sure what you mean by raster image. I just added MOImageShape. Update to the last version, open an easel and try: MondrianIcons icons associationsDo: [ :assoc | view shape image form: assoc value. view node: assoc key ] Is this what you meant? > For me, Mondrians primary purpose is output, not input. Being able to > drag around the boxes is cute, but what is the purpose for needing > that sort of input? You mean, interactively adding boxes and edges? Cheers, Alexandre > > > On Sat, Dec 18, 2010 at 6:58 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> Indeed. Mondrian works relative well for displaying and layout graph below 20.000 nodes. Over that, an external library is best. There is a bridge Mondrian<--> graphviz. >> >> Cheers, >> Alexandre >> >> >> On 18 Dec 2010, at 11:26, Levente Uzonyi wrote: >> >>> On Sat, 18 Dec 2010, StÃ©phane Ducasse wrote: >>> >>>> May this is a ridiculuous thought but may be it would be good to start an effort on >>>> build a library for Smalltalk. Reusing some part of mondrian could be good. >>> >>> It would be very slow and really a lot of work. Mondrian is nice for visualization, but a Graph library is a lot more than that. >>> >>> >>> Levente >>> >>>> >>>> Stef >>>> >>>> >>>>> JGraphT worked alright in what I tried against in the past, but it won't >>>>> scale to huge heights like most libs without major tweaking or a graph DB >>>>> backing it along with some serious threading. >>>>> >>>>> Just to throw in a few others I've used, but not with Smalltalk: >>>>> >>>>> * https://software.sandia.gov/trac/mtgl MTGL >>>>> * http://lemon.cs.elte.hu/trac/lemon LEMON >>>>> * .NET http://quickgraph.codeplex.com/ Quickgraph /Graph# >>>>> * http://igraph.sourceforge.net/introduction.html iGraph >>>>> * http://snap-graph.sourceforge.net/ SNAP >>>>> >>>>> Of the above, I've had some of the best experience with LEMON in terms of >>>>> scale and speed for real-world usage. Unfortunately, none of these libraries >>>>> include everything you'd want, so at some point you will have to roll some >>>>> stuff yourself. That's been my experience at least. >>>>> >>>>> Some Graph or Graph-like Databases (tend to have some algorithm libs as >>>>> well): >>>>> >>>>> * http://www.infinitegraph.com InfiniteGraph (this runs on Objectivity >>>>> underneath the covers which has a Smalltalk impl) >>>>> * http://www.neo4j.org neo4j >>>>> * http://www.kobrix.com/hgdb.jsp HyperGraphDB >>>>> >>>>> Some related useful items for dealing with large sets and graphs when you >>>>> are thinking about performance and/or parallel processing: >>>>> >>>>> * http://gauss.cs.ucsb.edu/~aydin/doc/html/index.html Combinatorial BLAS >>>>> * http://www.semanticdesigns.com/Products/PARLANSE/ PARLANSE >>>>> * http://research.microsoft.com/en-us/projects/dryadlinq/ DRYAD LINQ >>>>> >>>>> FYI, I would strongly recommend against using Ruby for anything with graphs >>>>> except as a simple client lib. I spent a lot of time on this before and it >>>>> simply does not scale or perform to anything beyond very simple cases, and >>>>> the memory footprint in a real app becomes horrendous. We had to tweak the >>>>> hell out of some libs to get anything decent and even then we ended up >>>>> writing stacks of C to compensate. If you're just dealing with 100 vertex >>>>> undirected graphs, then it works great. It's honestly the fault of a lot of >>>>> the libs rather than the language, but nonetheless be warned. >>>>> -- >>>>> View this message in context: http://forum.world.st/Graph-library-in-Smalltalk-Need-for-advices-tp3092747… >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 21, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by Sean P. DeNigris

Eliot Miranda-2 wrote: > > When I started working for ParcPlace Systems companies like JPMorgan > didn't > allow us to name then since using Smalltalk was such an important > competitive advantage. > Julian Fitzell says that this is still the case @ http://vimeo.com/17503969 Sean -- View this message in context: http://forum.world.st/Popularity-or-not-of-smalltalk-tp3073990p3159332.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 21, 2010

Re: [Pharo-project] XMLRPC server

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > sean what kind of script do you run? > I've been wrapping the world in Smalltalk. Some of the scripts that are working/almost-there: * wrapped google book search so that when I start reading an eBook in Mac's Preview, it gets entered into my developing library app in my image * wrapped bit.ly's API (used in the above-referenced script), so that the "tweet a page" script takes me into my image with the URL shortened and a TextMorph to enter my tweet, then uses Applescript to submit the Tweet (a hack because Twitter's authentication process for non-web apps fried my brain) Sean -- View this message in context: http://forum.world.st/XMLRPC-server-tp3090251p3159003.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 21, 2010

Re: [Pharo-project] asUrl retrieveContents -> with POST vars

by Sean P. DeNigris

Browsing Url I found #postFormArgs:. Checking the code for #retrieveContents, and tracing the execution, I ended up at #retrieveContentsArgs:accept:, which calls HTTPSocket class>>httpGetDocument:args:accept:request: Contrast to #postFormArgs:, which calls HTTPSocket class>>httpPostDocument:args:accept:request: The magic of Smalltalk tools! HTH, Sean -- View this message in context: http://forum.world.st/asUrl-retrieveContents-with-POST-vars-tp3093111p31578… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 21, 2010

Re: [Pharo-project] Why Smalltalk ? Which Smalltalk ?

by Sven Van Caekenberghe

On 21 Dec 2010, at 00:14, Levente Uzonyi wrote: > Really? The third question has 3 wrong answers... OK, I'll take the bait: I was looking for a high-quality, professional, well-maintained open-source Smalltalk supported by an active community with the right ideas, attitudes and ideals going forward, and I am happy I found it. And it seems I am not the only one. Sven

Dec. 21, 2010