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

Re: [Pharo-project] Who broke UTF8TextConverter?

by Igor Stasenko

On 6 September 2012 13:48, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 28.08.2012 23:11, Igor Stasenko wrote: >> >> On 28 August 2012 14:45, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On 28.08.2012 14:35, Igor Stasenko wrote: >>>> >>>> or it was like that from the birth?? >>>> >>>> arrrrgghhhh... >>>> >>>> | stream | >>>> stream := WriteStream on: (ByteArray new: 100). >>>> >>>> UTF8TextConverter new nextPut: (Character value: 129 ) toStream: stream. >>>> >>>> stream contents >>>> #[129] >>>> >>>> This is WRONG! RTFM, about utf8 encoding, please! :) >>>> >>>> --------- >>>> >>>> nextPut: aCharacter toStream: aStream >>>> | leadingChar nBytes mask shift ucs2code | >>>> aStream isBinary ifTrue: [^aCharacter storeBinaryOn: aStream]. >>>> >>>> in my case, stream is binary, so it goes directly to #storeBinaryOn: >>>> >>>> storeBinaryOn: aStream >>>> "Store the receiver on a binary (file) stream" >>>> value < 256 >>>> ifTrue:[aStream basicNextPut: value] >>>> ifFalse:[aStream nextInt32Put: value]. >>>> >>>> This is not even close to UTF8. >>>> If character code is less than 256, it will store a single byte (wtf?), >>>> and if more than that, it will store 32-bit integer value in >>>> big-endian order (wtf raisedToPower: 2).. >>>> >>>> i wonder , for what purpose we actually having this code path? this >>>> stuff is completely useless. >>>> according to implementation of storeBinaryOn: >>>> there's no way how you can read the same character value back. >>>> because it can be 1 byte or 4 bytes.. but you simply cannot determine >>>> which one. >>>> this is one of the reasons we using utf8 encoding, btw ;) >>>> >>> It's been this way from the start. >> >> so, it was broken from the start? >> the point is, that i am talking specifically about UTF8Converter... i >> don't care about any grade of >> polymorphism/megamorphism/whatevermorphism inherited from >> TextConverters.. but by simplest logic, my ignorant expectation was >> that UTF8Converter should convert its input into utf8 >> form or die trying.. but not something which not even remotely related >> to utf8.. wtf? >> Because if i don't need it to be converted to utf8, then why i would >> bother using it in a first place? >> >>> You want to sanely encode to in-memory bytearrays, use the Zn converters. >>> You want to conveniently switch between putting binary and encoded >>> contents >>> to a filestream (and do so efficiently), use the TextConverters. >>> >> conveniently? are you joking? :) >> conveniently is when i say things once, either: >> >> newstream := converter on: stream. >> x timesRepeat: [ newstream nextPut: oneElement ]. >> or >> >> stream addConverter: myconverter. >> x timesRepeat: [ stream nextPut: oneElement ]. >> >> but instead i forced to use it like: >> >> x timesRepeat: [ converter nextPut: oneElement onStream: stream ] >> >> it is neither convenient, nor optimal, because you operating with >> three entities in a loop: >> - stream, converter and element, while you really need only two. >> >> But aside of that, is there a reason why we must have 2 >> implementations of very same thing in our 'clean' system? If we have >> that , i think, we should stop calling it clean :) >> >> Sven told, why he implemented his own - just because the existing one >> is inherently broken (well, it was more polite form if i remember). >> >> Maybe Sven is too polite to put it straight or don't wants to shake >> the very foundations of our beautiful text conversion ecosystem.. >> But i don't mind to say it: TextConverters is piece of crap and we >> need to throw it out and replaced with something better or >> review/refactor/(choose your path).. >> >> So if some of you feel offended, i am sorry. You're a good guy/girl, >> who produced this code. The problem is that code doesn't follows "The >> principle of a least wtf". :) >> >> > I originally wrote a detailed response, but gave up after awhile. > > Let me just say that, at it's core, I don't think it's so much a problem of > believing the current situation is good, but that the inextricable link > between converters and filestreams, and how their extensive usage limits the > space for actual improvements within the space of backwards compatability. > (for a related example, there are multiple codepaths that rely on #binary > not actually doing any encoding) > > For a definition of better that means "less wtf's per line of code > read/spent trying to use these things", I for one don't see a way for big > improvements that does not involve breaking huge amounts of old code. > At that point, a clean break to a more sensible architecture like XTreams, > with clear separation of streaming/encoding responsibilites becomes a more > attractive alternative in the first place. > Yes, i agree, that the situation with streams is not simple, where you can swipe them out of a system and replace with better stuff. But we should not tolerate the status quo and do some little steps for having better system in future. Slowly but steady. And one of the first steps, is to prevent new code from using the stuff we want to remove. When users asking what they should use for conversions, we should inform them to not use TextConverters :) > Creating backwards-compatability protols to a new framework might help > somewhat, but it's still a massive undertaking which would cause huge > amounts of pain to users. Sort of like the Settings-switch really, but at a > much larger scale. > > And so we keep on encountering a few wtf's once in a while, learn to deal > with them, and then move on with our lives while hoping someone else picks > up the torch :) > > Cheers, > Henry > -- Best regards, Igor Stasenko.

Sept. 6, 2012

Re: [Pharo-project] nil key in last literal in instance side methods (reproducible)

by Nicolas Cellier

A bot providing simple diffs would help more eyes reviewing code... By now this important work is restricted to a narrow team of busy active developpers. Of course, CI may help a bit, but monkeys don't read code they just evaluate it. Nicolas 2012/9/6 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi guys. So we have a case where we can reproduce the problem. See > http://code.google.com/p/pharo/issues/detail?id=6644 > > If you take a Pharo 20274 and load this slice: > SLICE-Issue-6635-Removing-class-does-not-remove-class-tag-CamilloBruni.1 , > the #testInstanceSideMethodsWithNilKeyInLastLiteral starts to fail and we > have lots of instance side methods with nil in the last literal (in fact, > from the package that the slide installs). > I tried to debug the #basicLoad and MC friends to see if I come to the real > problem but no luck so far. > If anyone wants to take a look, it would be great since I think this is a > really important bug. > > Thanks, > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 6, 2012

Re: [Pharo-project] Fwd: Working with Pharo 1.4/2.0 â¦

by Marten Feldtmann

Another hint here: I like the refactoring browser's way: multi-select items in the list of attributes and default accessors are created - no need to edit the code here. I am in the browser, already looking at this class - and then I change the code in the browser. Marten Am 06.09.2012 17:30, schrieb Sean P. DeNigris: >> >> * creating accessor methods for instance attributes is not speedy and >> takes too much clicks >>

Sept. 6, 2012

Re: [Pharo-project] MemoryMonitor not in from Pharo?

by StÃ©phane Ducasse

ok so this was not intentional and this is good to have configurationOfMemory. Stef On Sep 6, 2012, at 9:25 PM, Mariano Martinez Peck wrote: > > > On Thu, Sep 6, 2012 at 9:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > No at least not that I remember. > > > Yes, it was but just becuase it was loaded by ConfigurationOfPharo. Since now we do not have the difference between core and dev anymore not ConfigurationOfPharo (for the moment), then it is simply not there because it has never been integrated. > > Stef > On Sep 6, 2012, at 5:50 PM, Alexandre Bergel wrote: > > > Hi! > > > > Some times ago MemoryMonitor was in Pharo. Apparently it has been removed. > > Any idea why? > > > > http://www.squeaksource.com/MemoryMonitor.html > > > > Cheers, > > Alexandre > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > <MemoryMonitor.png> > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Sept. 6, 2012

Re: [Pharo-project] Fwd: Working with Pharo 1.4/2.0 â¦

by Marten Feldtmann

Just some additional remarks about the setting framework and how VA has it since its latest release. Due to its source code management (ENVY) each application has its own configuration section in a simple ascii based *.ini file. Therefore each application has a text section like [name of application] key = value ... The developer just write 3 methods on the class side of its application class, which more or less do something: one method defines all possible entries expected in the text files and what type it has one method defines current AND default values for each setting one method defines how to transfer the values to your application. That's pretty simple - but also limited - and you copy the implementation of these three methods from another application, change them according to your needs and that's it. The documentation describing the Pharo settings framework is 20 pages long and offers many more features - I actually do not need. And I do not need a GUI to edit my setting values - but for others this might be useful. The documentation is not straight forward - three or four pages with introductions. And even now I do not know how the settings are stored outside the system. But as I said before - I have not done much work with Squeak/Pharo yet - and this only reflects my early impressions when working with this system. And I even do not know, if Settings is part of Pharo 1.4 or Pharo 2.0. Just to give you an overview of my ideas here. and another point I want to say about using the system: Working with VASmalltalk/ENVY the methods called after starting, resuming, loading, unloading (and various other events) to each class/application are well documented. I do not find documents/informations about this in Pharo/Squeak and this is a very important information when initializing an application. Marten Feldtmann Am 06.09.2012 17:30, schrieb Sean P. DeNigris: > * Settings â I find this one *really* interesting. Will you highlight the > key differences to VA? Maybe we can improve the framework in Pharo, or at > minimum create a UI that makes things simpler and more straightforward for > you

Sept. 6, 2012

Re: [Pharo-project] MemoryMonitor not in from Pharo?

by Mariano Martinez Peck

On Thu, Sep 6, 2012 at 9:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > No at least not that I remember. > > Yes, it was but just becuase it was loaded by ConfigurationOfPharo. Since now we do not have the difference between core and dev anymore not ConfigurationOfPharo (for the moment), then it is simply not there because it has never been integrated. > Stef > On Sep 6, 2012, at 5:50 PM, Alexandre Bergel wrote: > > > Hi! > > > > Some times ago MemoryMonitor was in Pharo. Apparently it has been > removed. > > Any idea why? > > > > http://www.squeaksource.com/MemoryMonitor.html > > > > Cheers, > > Alexandre > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > <MemoryMonitor.png> > > > -- Mariano http://marianopeck.wordpress.com

Sept. 6, 2012

Re: [Pharo-project] MemoryMonitor not in from Pharo?

by StÃ©phane Ducasse

No at least not that I remember. Stef On Sep 6, 2012, at 5:50 PM, Alexandre Bergel wrote: > Hi! > > Some times ago MemoryMonitor was in Pharo. Apparently it has been removed. > Any idea why? > > http://www.squeaksource.com/MemoryMonitor.html > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > <MemoryMonitor.png>

Sept. 6, 2012

[Pharo-project] Advanced mocking or something like that

by Santiago Bragagnolo

Hi all! I'm analazing a protocol for a pharo based robot-client, and i need two things: a) to test the protocol and the application (which have a complex conversational state management) b) to mock the application at all for debuggin without a robot conected. (ok, is pretty similar to a complex test) Is there any state-machine-like mock? or anything similar? Any one have a better idea to make this? Thanks! Santiago.

Sept. 6, 2012

Re: [Pharo-project] Fwd: Working with Pharo 1.4/2.0 â¦

by Esteban A. Maringolo

If you want those kind of niceties in the debugger/browser look at how Dolphin Smalltalk does it. On MNU's you can implement methods in the class of any of the parents of the receiver object. Or even implement it while in the method browser. The development experience is so streamlined that it flows naturally. Regards, -- Esteban -- View this message in context: http://forum.world.st/Fwd-Working-with-Pharo-1-4-2-0-tp4646428p4646450.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 6, 2012

Re: [Pharo-project] Fwd: Working with Pharo 1.4/2.0 â¦

by Sean P. DeNigris

Chris Cunningham wrote > > I really wished that the debugger had a button when enountering an > unknown method called 'create accessor' or something similar Well, we're almost there... if you send a unary or binary message with the same name as an inst var, and click "create " from the debugger, you get an accessor template... The only problem is that is has "self shouldBeImplemented." added to it, which is not even highlighted for deletion. I've wondered for a while what the purpose of this is... Unless someone speaks up convincingly for its usefulness, I say we remove it and start with a complete and valid accessor as the template... Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Working-with-Pharo-1-4-2-0-tp4646428p4646445.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 6, 2012