January 2014 - Pharo-dev - lists.pharo.org

Comparing dates

by Sebastian Sastre

self assert: Date today = Date today. today := Date today translateTo: 2 hours. self assert: today = Date today Is this right?

Jan. 31, 2014

Re: [Pharo-dev] back and oldBack in UTF-8 files

by Nicolas Cellier

I wonder why we need back and oldBack (reallyOldBack ?) in the first place. Condensing sources or changes should just consist in writing source of each method/class comment sequentially (forward), and remember the position of the stream... So this backward thing must be some poorly written part. Ah perhaps we are reading the metadata (author etc...) back from source position, is that it ? If so, then it would be possible to point to the beginning of metadata, and skip forward... 2014-01-31 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Pavel, > > On 31 Jan 2014, at 20:33, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > Hi, > > > > I was looking why we cannot do condenseChanges and the reason looks to > be clear: we do not have proper methods to move backwards (messages #back > and #oldBack) in UTF-8 files. The current implementation changes position > by one byte but in UTF-8 files it can be up to six bytes. And it's worse. > We do not have mechanism how a text converter could handle this. > > Obvious solution is to rewrite condenseChanges to backup position > somehow and do not move backwards at all but it doesn't seem to be so easy. > > Any ideas? > > > > And why do we need working condenseChanges? Because when we unload > non-kernel packages and load them back, the resultant changes file has > about 51MB :-) > > > > Cheers, > > -- Pavel > > Very interesting! > > Actually, I think this is fairly easy to do. Here is a prove of concept. > It does not implement the exact semantics of either #back or #oldBack, but > it does give the elementary building block to make it possible. > > Adding the following method: > > ZnUTF8Encoder>>backOnStream: stream > [ (stream back bitAnd: 2r11000000) == 2r10000000 ] whileTrue > > Makes this possible: > > | encoder stream | > encoder := ZnUTF8Encoder new. > stream := (encoder encodeString: 'Les Ã©lÃ¨ves FranÃ§aises') readStream. > 4 timesRepeat: [ encoder nextFromStream: stream ]. > encoder nextFromStream: stream. " => $Ã©" > encoder backOnStream: stream. > encoder nextFromStream: stream. " => $Ã©" > 3 timesRepeat: [ encoder backOnStream: stream ]. > encoder nextFromStream: stream. " => $s" > > Implementing #back would then be something like: > > | char | > encoder backOnStream: stream. > char := encoder nextFromStream: stream. > encoder backOnStream: stream. > ^ char > > to simulate the #peek, but that might not be needed for the caller. > > Of course, to do this for real would require a couple of good unit tests, > as well as implementations for all encoders in the ZnCharacterEncoder > hierarchy. > > What do you think ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

Jan. 31, 2014

lookInGeneralPreferencesFolder

by Sebastian Sastre

Hi guys, that method is raising an exception when moving the image from one OS to other

Jan. 31, 2014

Re: [Pharo-dev] back and oldBack in UTF-8 files

by Sven Van Caekenberghe

Hi Pavel, On 31 Jan 2014, at 20:33, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I was looking why we cannot do condenseChanges and the reason looks to be clear: we do not have proper methods to move backwards (messages #back and #oldBack) in UTF-8 files. The current implementation changes position by one byte but in UTF-8 files it can be up to six bytes. And it's worse. We do not have mechanism how a text converter could handle this. > Obvious solution is to rewrite condenseChanges to backup position somehow and do not move backwards at all but it doesn't seem to be so easy. > Any ideas? > > And why do we need working condenseChanges? Because when we unload non-kernel packages and load them back, the resultant changes file has about 51MB :-) > > Cheers, > -- Pavel Very interesting! Actually, I think this is fairly easy to do. Here is a prove of concept. It does not implement the exact semantics of either #back or #oldBack, but it does give the elementary building block to make it possible. Adding the following method: ZnUTF8Encoder>>backOnStream: stream [ (stream back bitAnd: 2r11000000) == 2r10000000 ] whileTrue Makes this possible: | encoder stream | encoder := ZnUTF8Encoder new. stream := (encoder encodeString: 'Les Ã©lÃ¨ves FranÃ§aises') readStream. 4 timesRepeat: [ encoder nextFromStream: stream ]. encoder nextFromStream: stream. " => $Ã©" encoder backOnStream: stream. encoder nextFromStream: stream. " => $Ã©" 3 timesRepeat: [ encoder backOnStream: stream ]. encoder nextFromStream: stream. " => $s" Implementing #back would then be something like: | char | encoder backOnStream: stream. char := encoder nextFromStream: stream. encoder backOnStream: stream. ^ char to simulate the #peek, but that might not be needed for the caller. Of course, to do this for real would require a couple of good unit tests, as well as implementations for all encoders in the ZnCharacterEncoder hierarchy. What do you think ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 31, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Sebastian Sastre

On Jan 31, 2014, at 2:19 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > I love the changes of Johan. I would love to have a more compact class definition :) > Now the question by henrik is really puzzling me. But is not working, isnât it? I mean for the people. I donât want to be critical here, only to analyse this case of decision process because on the heat of the trenches this things are easy to miss... Imagination is not market fit. Before deciding to break tradition, shouldnât validation come first? If so, our method to make decisions risks to be overexposed to audience misfits. Misfitting the statu quo is okay, misfiting your audience one too many times is a formula to end up alone (AKA having a product nobody wants to use). Lets say you have an idea to innovate on UI or the API... you can go ahead and prototype how it feels for yourself even a partially implemented draft of the idea (lets say a branch). Lets says it convinces youâ¦ Time to be skeptic. Test. Test with someone else. Tests it with 5 guys and ask how they feel about it. Hear. So to yourself the hard and useful questions: Do they validate? signals of market fit? are they strong? convincing? are they weak? so are they worth now? are you sure they are being honest and not saying yes just to be nice, to please you? When you donât validate youâre doing software for yourself in front of others. Thatâs cool until is not. What are Pharo's usage metrics these days? sebastian o/

Jan. 31, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Pharo4Stef

>> Hi Torsten, >> >> I think it is a design decision / tradeoff, and therefore there is no fundamentally "right way" to do it. For me, it is the same case as the uses: message for Traits. It's not in the template by default because it is used very infrequently. So for language simplicity it should not be there. For me, simplicity is one of the core points of Smalltalk so this is why I feel strongly about it. > > I donât see how this change make Smalltalk (the language) simpler. For me this change looks more like an obfuscation than a simplification. How many lectures did you give? It is annoying to have to explain something that usually people do not need to know. >> When I say "very infrequently", this is of course a fuzzy metric, I know. And I understand that you do not agree with this design decision. >> >> But on the other hand, I don't think that it is too hard to remember where to add the pooldictionaries: line if you need it, and the old message with this line still works, so all old examples still work. > > How should newcomers know how to enter pool dictionaries? I rarely use pool dictionaries and if I will need it I surely have forgotten about > this change and expect irritation and frustration. Newcomers do not use pooldictionaries. In 10 years smalltalking I used them twice. > > So, a -1 for this change from my side. We just need a full class template menu item.

Jan. 31, 2014

back and oldBack in UTF-8 files

by Pavel Krivanek

Hi, I was looking why we cannot do condenseChanges and the reason looks to be clear: we do not have proper methods to move backwards (messages #back and # oldBack) in UTF-8 files. The current implementation changes position by one byte but in UTF-8 files it can be up to six bytes. And it's worse. We do not have mechanism how a text converter could handle this. Obvious solution is to rewrite condenseChanges to backup position somehow and do not move backwards at all but it doesn't seem to be so easy. Any ideas? And why do we need working condenseChanges? Because when we unload non-kernel packages and load them back, the resultant changes file has about 51MB :-) Cheers, -- Pavel

Jan. 31, 2014

Re: [Pharo-dev] Seaside extensions and lowercase package names in Pharo

by Esteban A. Maringolo

2014-01-31 Chris Cunningham <cunningham.cb(a)gmail.com>: > You'll undoubtedly run into this several more times - at least you will when bringing in older Monticello packages or those created outside of Pharo. Not all, but some. Some, which will be very important probably. Like Seaside, Glorp, etc. Regards!

Jan. 31, 2014

Re: [Pharo-dev] Yet another week of commits

by blake

Websense categorizes "association.pharo.org" as "sex". On Fri, Jan 31, 2014 at 10:56 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Another week of improvements > > http://association.pharo.org/web/weekly/Commits-Jan-3 > > stef >

Jan. 31, 2014

Yet another week of commits

by Pharo4Stef

Another week of improvements http://association.pharo.org/web/weekly/Commits-Jan-3 stef

Jan. 31, 2014