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

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

by Mariano Martinez Peck

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] RPackage question

by Goubier Thierry

Le 06/09/2012 14:32, Tudor Girba a Ã©crit : > This is just the way symbols print like when they have non alpha numeric characters :) And of course $- is not an alpha numeric character... :) Ok, helps the understanding. 6647 is apparently solved by unregistering MCPackageManager from SystemAnnouncer. But still : Why, if you add a method in an extension protocol (such as #'*At2-Test') with indirect creation of a package, RPackageOrganizer ends up with: RPackage(#'*At2-Test') And RPackage(#At2) Because MCWorkingCopy has created the #At2 MCPackage ? Thierry > Doru > > > On 6 Sep 2012, at 14:10, Goubier Thierry wrote: > >> I'm trying to see what's happening with bug 6647, since it's pretty dangerous for development on Pharo 2.0 at the moment, and annoying as well. >> >> So I'm looking at RPackageOrganizer packages key and is there a reason for some keys to have quotes and others not ? >> >> for example : >> #Nautilus >> and >> #'Ring-Core-Kernel' >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > -- > www.tudorgirba.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 6, 2012

Re: [Pharo-project] RPackage question

by Tudor Girba

This is just the way symbols print like when they have non alpha numeric characters :) Doru On 6 Sep 2012, at 14:10, Goubier Thierry wrote: > I'm trying to see what's happening with bug 6647, since it's pretty dangerous for development on Pharo 2.0 at the moment, and annoying as well. > > So I'm looking at RPackageOrganizer packages key and is there a reason for some keys to have quotes and others not ? > > for example : > #Nautilus > and > #'Ring-Core-Kernel' > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- www.tudorgirba.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Sept. 6, 2012

[Pharo-project] RPackage question

by Goubier Thierry

I'm trying to see what's happening with bug 6647, since it's pretty dangerous for development on Pharo 2.0 at the moment, and annoying as well. So I'm looking at RPackageOrganizer packages key and is there a reason for some keys to have quotes and others not ? for example : #Nautilus and #'Ring-Core-Kernel' Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 6, 2012

Re: [Pharo-project] #skipSeparators doesn't work for MultiByteBinaryOrTextStream

by Henrik Sperre Johansen

On 06.09.2012 10:44, Sven Van Caekenberghe wrote: > Mariano, > > What would be wrong with something more elegant, like > > consumeWhitespace > "Strip whitespaces from the input stream." > > [ readStream atEnd not and: [ readStream peek isSeparator ] ] > whileTrue: [ > readStream next ] > > ? > > In my book #peek, which means a one-element pushback buffer, is a whole lot less of a requirement that a general #position[:] interface which actually assumes that all contents is in memory, a contradiction to the concept of streaming. Considering we are talking of PositionableStream subclasses, using the position: protocol (also to implement peek) isn't exactly heresy. :) Though, neglecting converter state (which in one case involves more than position) when one does so is a bad idea. Rewriting #peek to employ a buffer instead of position: for positionable streams(double dispatched through saveStateOf:) purely for the sake of not dealing with position: seems like a bad use of time imho, though you'd lose the compexity of dd'ing through the converter, dealing with the buffer translates into quite a few changes elsewhere. For non-positionable streams, a buffer is really the only choice though, and isn't _that_ complicated to deal with in face of no arbitrary position: changes. (Ironically in light of the above, the use cases of CompoundTextConverter, which is the one which _does_ care about other state than position in saveStateOf:, should never necessitate arbitary position: changes, so it seems targetted purely at making peek work) > Maybe these uglier versions are more efficient, but who can say for sure they are correct ? > > ;-) > > Sven When it comes to streams on in-memory collections (like MBBOTS), using peek shouldn't be very noticeable. For streams with external sources, position: can be costly, inlining the position book-keeping peek does (as MBFS>>skipSeparators does) might be justified. With the amount of whitespace one normally parse through, I sort of doubt it even in that case. Anyways, who can say for sure the peek approach is correct? ;) As mentioned above, for MultiByteBinaryOrTextStreams using CompoundTextConverters it won't be., since #peek in MBBOTS doesn't account for converter state. (Just like skipSeparators, which in addition does not account for multibyte elements, the source of the bug Mariano ran into in the first place, and why peek fixes his non-CompTextConv usecase) TLDR; - Yap, using peek is cleaner, and is a nicer implementation as long as internally you use a buffer / position: is cheap. - MultiByteBinaryOrTextStream>>#peek needs fixing, along the lines Mariano originally intended for skipSeparaters wrt. copying what is done in MultiByteFileStreams, in order to work correctly with all converters. Cheers, Henry

Sept. 6, 2012

Re: [Pharo-project] Who broke UTF8TextConverter?

by Henrik Sperre Johansen

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. 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

Sept. 6, 2012

Re: [Pharo-project] Jenkins again not triggering tests?

by Camillo Bruni

On 2012-09-06, at 12:17, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > On Thu, Sep 6, 2012 at 12:11 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> >> On 2012-09-06, at 12:10, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >>> On Thu, Sep 6, 2012 at 12:08 PM, Camillo Bruni <camillobruni(a)gmail.com >>> wrote: >>> >>>> yes the damn win slave is still down... >>>> >>> >>> yes but ... how that can affect the Mac one? >> >> it waits for completion of the matrix build. so it won't finish unless all >> 3 platforms did so... >> > > grrrr ok. So, can't we remove completly the win slave so that it does not > bother us until it is working again? nope I won't do that :D the win slave has LIVE god dammit! all paths (I mean ports) are cleared from lifl but there seems to still a nasty issue at INRIA, I'll write yet another request to open yet another oh so insecure port...

Sept. 6, 2012

Re: [Pharo-project] Jenkins again not triggering tests?

by Mariano Martinez Peck

On Thu, Sep 6, 2012 at 12:11 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-09-06, at 12:10, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > On Thu, Sep 6, 2012 at 12:08 PM, Camillo Bruni <camillobruni(a)gmail.com > >wrote: > > > >> yes the damn win slave is still down... > >> > > > > yes but ... how that can affect the Mac one? > > it waits for completion of the matrix build. so it won't finish unless all > 3 platforms did so... > grrrr ok. So, can't we remove completly the win slave so that it does not bother us until it is working again? -- Mariano http://marianopeck.wordpress.com

Sept. 6, 2012

Re: [Pharo-project] Monkey can't find working copies?

by Camillo Bruni

has been resolved by now. the problem was Gofer related, since it did not properly manage the merge action when the requested package hasn't been loaded before. so usually this works since you merge only with things you already have in your image, however with slices this won't work, since each slice is treated like a new MC package. On 2012-08-21, at 15:49, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > There are a few issues with "Error: Working copy for SLICE-Issue-Xxx not > found". Is this a monkey problem? The slice for > http://code.google.com/p/pharo/issues/detail?id=6560 at least seems to load > fine in latest 2.0... > > Sean > > [1] > http://code.google.com/p/pharo/issues/list?can=2&q=Error+%22Working+copy+fo… > > > > -- > View this message in context: http://forum.world.st/Monkey-can-t-find-working-copies-tp4644829.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Sept. 6, 2012

Re: [Pharo-project] Jenkins again not triggering tests?

by Camillo Bruni

On 2012-09-06, at 12:10, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > On Thu, Sep 6, 2012 at 12:08 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> yes the damn win slave is still down... >> > > yes but ... how that can affect the Mac one? it waits for completion of the matrix build. so it won't finish unless all 3 platforms did so...

Sept. 6, 2012