June 2011 - Pharo-users - lists.pharo.org

PetitParser and c#

by Alain Rastoul

Hi all, Do someone know about a PetitParser grammar for c# or java ? Verveine seems to be a Java development (and is not accessible). TIA Cheers Alain

June 26, 2011

Re: [Pharo-users] [TWM] [KeyboardMapping] Image freezes or MNU Array(Object)>>errorSubscriptBounds:??

by Guillermo Polito

It seems a Transcript error... :S I'll have a look... On Sat, Jun 25, 2011 at 10:43 PM, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com> wrote: > > Hi, > > i don't know if this problem belongs to KeyboardMapping or TWM. > Also it's difficult to reproduce. > has someone seen this problem? > > thanks in advance. > > Pharo image: Pharo1.3#13274 > Virtual machine used: Squeak4.1 of 17 April 2010 [latest update: #9957] > Platform Name: unix > Class browser used (if applicable): Browser > > Possible Steps to reproduce: > #.Gofer it squeaksource: 'TilingWindowManager'; > package: 'ConfigurationOfTilingWindowManager'; > load. > #. ConfigurationOfTilingWindowManager loadDevelopment > #. open a workspace and press a key for a long time. > or open a browser and edit a method. > #. image will freeze or MNU Array(Object)>>errorSubscriptBounds: > > > >

June 26, 2011

[TWM] [KeyboardMapping] Image freezes or MNU Array(Object)>>errorSubscriptBounds:??

by Bernardo Ezequiel Contreras

Hi, i don't know if this problem belongs to KeyboardMapping or TWM. Also it's difficult to reproduce. has someone seen this problem? thanks in advance. Pharo image: Pharo1.3#13274 Virtual machine used: Squeak4.1 of 17 April 2010 [latest update: #9957] Platform Name: unix Class browser used (if applicable): Browser Possible Steps to reproduce: #.Gofer it squeaksource: 'TilingWindowManager'; package: 'ConfigurationOfTilingWindowManager'; load. #. ConfigurationOfTilingWindowManager loadDevelopment #. open a workspace and press a key for a long time. or open a browser and edit a method. #. image will freeze or MNU Array(Object)>>errorSubscriptBounds:

June 26, 2011

Re: [Pharo-users] printOn: vs printString

by Alan Rodas

> > How do end user interfere with the programming language? If your user is a > developer than the statement "..does not require the use to understand > streams at all..." is somewhat strange because it is something very > fundamental a good developer should know. > > As I teach introductory OOP, the kids always want to print their object, and they don't yet know anything about streams. But I realize that it's fundamental for any programmer to know. > Anyway, there is printString that produces a String and it uses printOn: to > print on a stream that is used to build the string. For the sole usage you > just need to know printString. If you start to print over a hierarchy of > objects you see it very well why you should use streams. > This is easy to explain from a java perspective. In Java a String is > immutable and we know that concatenating produces a string for every > combination of other strings. That is the reason why you need to use > StringBuffer/StringBuilder if you don't want to lose performance and memory. > And that is something other programming languages force you to know. > A stream is something you can write subsequently on no matter how many > objects write on it. You just hand the stream from on object to another and > only the last one needs to do the string conversion. As Object provides this > functionality you should implement printOn: on your objects. > > Norbert > > Completely makes sense now. Thanks guys. -- Alan Rodas Bonjour

June 25, 2011

Re: [Pharo-users] printOn: vs printString

by Norbert Hartl

Am 25.06.2011 um 06:07 schrieb Alan Rodas: > Hello folks > > I was wondering why does Smalltlak prefer the printOn: aStream method over the printString method. > > As I work with Java and C# all the time, I'm used to define a printString like method where you return a string representing the object, > and, today, having to do the same in smalltlak I unconsciously redefined the printString method. As soon as I realize that my collections were using printOn: instead of my redefined printSrting method for printing their contents, I wondered: > > Why was this decision taken? I mean, every other language seems more simple (from the end user point of view, as it does not require the user to understand streams at all), In the other hand, printOn: seems more versatile. > > Pointless question, I know, but I'm quite curious and I cannot seem to find anything about this, and I though that you guys may know. How do end user interfere with the programming language? If your user is a developer than the statement "..does not require the use to understand streams at all..." is somewhat strange because it is something very fundamental a good developer should know. Anyway, there is printString that produces a String and it uses printOn: to print on a stream that is used to build the string. For the sole usage you just need to know printString. If you start to print over a hierarchy of objects you see it very well why you should use streams. This is easy to explain from a java perspective. In Java a String is immutable and we know that concatenating produces a string for every combination of other strings. That is the reason why you need to use StringBuffer/StringBuilder if you don't want to lose performance and memory. And that is something other programming languages force you to know. A stream is something you can write subsequently on no matter how many objects write on it. You just hand the stream from on object to another and only the last one needs to do the string conversion. As Object provides this functionality you should implement printOn: on your objects. Norbert

June 25, 2011

Re: [Pharo-users] printOn: vs printString

by StÃ©phane Ducasse

printString is a template method printOn: a hook so you should specialize printOn: On Jun 25, 2011, at 6:07 AM, Alan Rodas wrote: > Hello folks > > I was wondering why does Smalltlak prefer the printOn: aStream method over the printString method. > > As I work with Java and C# all the time, I'm used to define a printString like method where you return a string representing the object, > and, today, having to do the same in smalltlak I unconsciously redefined the printString method. As soon as I realize that my collections were using printOn: instead of my redefined printSrting method for printing their contents, I wondered: > > Why was this decision taken? I mean, every other language seems more simple (from the end user point of view, as it does not require the user to understand streams at all), In the other hand, printOn: seems more versatile. > > Pointless question, I know, but I'm quite curious and I cannot seem to find anything about this, and I though that you guys may know. > > Cheers > -- > Alan Rodas Bonjour >

June 25, 2011

printOn: vs printString

by Alan Rodas

Hello folks I was wondering why does Smalltlak prefer the printOn: aStream method over the printString method. As I work with Java and C# all the time, I'm used to define a printString like method where you return a string representing the object, and, today, having to do the same in smalltlak I unconsciously redefined the printString method. As soon as I realize that my collections were using printOn: instead of my redefined printSrting method for printing their contents, I wondered: Why was this decision taken? I mean, every other language seems more simple (from the end user point of view, as it does not require the user to understand streams at all), In the other hand, printOn: seems more versatile. Pointless question, I know, but I'm quite curious and I cannot seem to find anything about this, and I though that you guys may know. Cheers -- Alan Rodas Bonjour

June 25, 2011

Re: [Pharo-users] [Pharo-project] [COTDC] 77 - LazyMorphTreeMorph

by laurent laffont

Thanks Doru ! Laurent. On Thu, Jun 23, 2011 at 8:54 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I am a MorphTreeMorph, but I only render the rows lazily as they appear on > screen. > > Caveat: There is no rendering in the background. This means that if a row > takes too long to render, you can experience a shorter or longer freeze when > scrolling. > > Doru > > On 23 Jun 2011, at 20:46, laurent laffont wrote: > > > Today: LazyMorphTreeMorph > > > > > > Comment Of The Day Contest - One Day One Comment > > Rules: > > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > > #2: If you cannot comment it, deprecate it. > > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > > > Laurent > > -- > www.tudorgirba.com > > "What we can governs what we wish." > > > > >

June 24, 2011

Re: [Pharo-users] Parsing XML into sorted elements

by Sean P. DeNigris

Pat Maddox-3 wrote: > > Yeah, my guess is that sorting a collection while it's being iterated upon > is bad news. > I wanted to replace the parser's use of OrderedCollection with SortedCollection, but it got too complicated and I ended up sorting at the end in one override with one line of code. -- View this message in context: http://forum.world.st/Parsing-XML-into-sorted-elements-tp3615867p3621048.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 23, 2011

Re: [Pharo-users] Parsing XML into sorted elements

by Pat Maddox

On Jun 23, 2011, at 7:14 AM, Norbert Hartl wrote: > > Am 22.06.2011 um 05:11 schrieb Sean P. DeNigris: > >> I did the simplest thing I could think of and overrode >> XMLPageElement>>handleEndTag >> ^ self nodes sort: [ :a :b | a < b ]. >> >> It worked but feels like a hack. Anyone have anything better? >> > Why do need to sort while the parser is parsing? Can't you sort just afterwards? I think this is the cleanest approach. Yeah, my guess is that sorting a collection while it's being iterated upon is bad news. Pat

June 23, 2011