May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] TxText new version 0.8

by Igor Stasenko

On 22 May 2013 21:04, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 22 May 2013 10:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> I would use >>> >>> TextModelCore >>> TextModelExtensions >>> >>> TextModelCore-Tests >>> >>> No extra dash in the middle. >> >> nooooo :) >> >> But for tests, i +1, the names are not very good. >> For package: >> >> Package-Name-Tick-Tack >> >> tests should be in: >> >> Package-Name-Tick-Tack-Tests >> >> This convention used everywhere in pharo. > > Please do not do that :). > > If you do that, publishing Package-Name-Tick-Tack will publish the code from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely implicit one-to-many mapping. > > So, the pattern I know of is to put the Tests as a discriminator before the variable part of your code. So, something like: > - BaseName-Core > - BaseName-Tests-Core > i stand corrected.. actually i meant following composition: ProjectName-Core ProjectName-Extras ProjectName-Tests no 3-4 levels of tick-tacks (but i love to use subcategories inside a package, i.e. ProjectName-Core-Foo , ProjectName-Core-Bar... etc > But, the rule I apply more recently for code is to use - only for categories, and camel case for the Monticello packages. Like this we also document what is the unit of publishing, thus when you look into the code browser we also know what is mapped on a Monticello package. > > Cheers, > Doru > > > >>> Stef >>> >>> On May 21, 2013, at 10:24 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> 2013/5/21 stephane ducasse <stephane.ducasse(a)free.fr> >>>> >>>> >>>> On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>>> wrote: >>>> >>>> 2013/5/20 stephane ducasse <stephane.ducasse(a)free.fr> >>>>> >>>>> >>>>> Hello. >>>>> >>>>> New TxText version 0.8 is ready: >>>>> >>>>> - editor stuff extracted to separate packages TxText-Editor and >>>>> TxTextTests-Editor >>>>> >>>>> may be you should call the second package TxTextEditor-Tests >>>> >>>> >>>> I just follow convention of other TxText packages: TxText-Model -> >>>> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. >>>> Some times ago I suggest such repackaging and nobody was against it >>>> >>>> >>>> Still I think that the packages names are not good. I do not hitnk that >>>> having tests mixed with the package name is a good approach >>>> and we should clean all of them for 3.0 >>> >>> >>> So what the correct way (Pharo way) to name test packages? >>> For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package >>> should be? >>> >>>> >>>> >>>> Stef >>>> >>>> >>>> >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- > www.tudorgirba.com > > "Value is always contextual." > > > > -- Best regards, Igor Stasenko.

May 23, 2013

Re: [Pharo-dev] clean, please[SEC=UNCLASSIFIED]

by Stephen Taylor

On Wed, 2013-05-22 at 14:06 -0400, Paul Davidowitz wrote: > I was referring to text used in this mailing list, particularly words of > the form *u** aunt? bulb? cute? dump? euro? fuzz? gums? huge? iuds? junk? luck? much? null? ouch? pulp? quag? (marsh or bog, so the dictionary says) ruby? suet? tuna? -- -- -- -- yurt? zuni? I am a bit sad that I couldn't find anything for u, v , w or x. And a bit ashamed that I had to settle for the plural of iud. Steve

May 22, 2013

Re: [Pharo-dev] [squeak-dev] Re: MC should really write snaphsot/source.st in UTF8

by Nicolas Cellier

MC never wrote a BOM, so we don't have to be compatible with BOM. If we can simplify the process, let's simplify, because maintaining useless compatibility costs, the code is really crooked by now, and this leads to mis-understanding, and soon to broken features and noise. Currently, snapshot/source.st IS broken. If there are codes > 127, the UTF8TextConverter will most likely fail, and I like the idea of Norbert to retry with a legacy encoding. This way, we put crooked compatibility layer in exceptional handling. This will also simplify the MC readers/writers in VW, gst, Gemstone, ... Even for the legacy code, I wonder if MacRoman would be the right choice. MC never encoded the strings and always wrote the codes as is. So, setEncoderForCode is here for maintaining compatibility with MC snapshot/source.st written from an old image where internal String encoding was MacRoman - when was it, 3.7? Are there really many of these? I bet 99% of MC-files are encoded in latin-1 but decoded with MacRoman if we go through a MczInstaller... Of course, MC now uses snapshot.bin rather than snapshot/source.st. Did old versions of MC failed to write snapshot.bin? Eventually, we can set a Preferences in Squeak for ultra old legacy encoding (not in Pharo, I guess Pharo should not care at all). 2013/5/23 Yoshiki Ohshima <Yoshiki.Ohshima(a)acm.org> > On Wed, May 22, 2013 at 2:16 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > First thing would be to simplify #setConverterForCode and > > #selectTextConverterForCode. > > Do we still want to use a MacRomanTextConverter, seriously? I'm not even > > sure I've got that many files with that encoding on my Mac-OSX... > > Do we really need to put a ByteOrderMark for UTF-8, seriously? See > > http://en.wikipedia.org/wiki/Byte_order_mark, it's valueless, and not > > recommended. It were a Squeak way to specify that a Squeak source file > would > > use UTF-8 rather than MacRoman, but now this should be obsolescent. > > Old code was certainly in MacRoman, and quite a few used middle dot, > accented chars and other characters in the right half of the character > chart. > > Monticello surely should use UTF-8. I'd think, though, it should keep > BOM; did you encounter any problems? (it is not recommended, but it > is permitted.) > > -- > -- Yoshiki > >

May 22, 2013

Re: [Pharo-dev] MC Filetree -- missing FiletreeURL ?

by Frank Shearar

On 22 May 2013 20:37, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> Sven >>> >>> PS: I occasionally read the Squeak mailing and I see the work that you are doing and it is impressive. Your attitude, approach and drive remind me of the many Pharo developers. I would not dream of convincing you, but IMHO you would fit perfectly in the Pharo community, where you would find more interaction and feedback - maybe you would even reconsider using Smalltalk in business. >> >> Thanks, Sven. I'm really not trying to pick fights over here. And >> perhaps today was a bad day to open my mouth at all, given my >> crankiness level. >> >> I would _love_ to be able to use Smalltalk at work. Until it can work >> properly with git, and people can use their own text editors (vim, >> emacs, sublime), and quite a few other bits and pieces, it's just a >> non-starter. > > that's simply not true, as you can see by all the success stories: > http://files.pharo.org/SuccessStories/ Sorry, I didn't mean in general. I meant at my work. >> I _like_ Pharo, and I _like_ how it has energy and momentum, and a >> much nicer UI than the old Pharo 1.0 UI. I'm honestly quite jealous of >> the resources the community wields, not just because of INRIA's and >> the Consortium's money, but because there are loads of people actually >> around, who are prepared to knuckle down and do the gruntwork needed. >> Squeak is now a very small community. I'm rather proud of what we get >> done with what little we have. > > > that is sad :(, I really think your contribution would be better off > over here. I speak for many at our lab I think, that there is no motivation > to prepare stuff for squeak: burnt once, fooled twice :/ I don't understand that, I really don't. Burnt by what? By whom? frank

May 22, 2013

Re: [Pharo-dev] [squeak-dev] Re: MC should really write snaphsot/source.st in UTF8

by Yoshiki Ohshima

On Wed, May 22, 2013 at 2:16 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > First thing would be to simplify #setConverterForCode and > #selectTextConverterForCode. > Do we still want to use a MacRomanTextConverter, seriously? I'm not even > sure I've got that many files with that encoding on my Mac-OSX... > Do we really need to put a ByteOrderMark for UTF-8, seriously? See > http://en.wikipedia.org/wiki/Byte_order_mark, it's valueless, and not > recommended. It were a Squeak way to specify that a Squeak source file would > use UTF-8 rather than MacRoman, but now this should be obsolescent. Old code was certainly in MacRoman, and quite a few used middle dot, accented chars and other characters in the right half of the character chart. Monticello surely should use UTF-8. I'd think, though, it should keep BOM; did you encounter any problems? (it is not recommended, but it is permitted.) -- -- Yoshiki

May 22, 2013

Re: [Pharo-dev] MC should really write snaphsot/source.st in UTF8

by Nicolas Cellier

That sounds good. We could even try to fallback to UT-32 if we encounter zeros (but his should be very rare...). For write, ZipArchive are un-aware of any encoding... They use latin1. In Squeak, I could place some squeakToUTF8 sends in MCMczWriter, and equivalent UTF8TextConverter in Pharo #serializeDefinitions:, maybe this is needed in some other serialize* (version, dependencies who knows...) 2013/5/22 Norbert Hartl <norbert(a)hartl.name> > > > Am 22.05.2013 um 23:16 schrieb Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > > First thing would be to simplify #setConverterForCode and > #selectTextConverterForCode. > Do we still want to use a MacRomanTextConverter, seriously? I'm not even > sure I've got that many files with that encoding on my Mac-OSX... > Do we really need to put a ByteOrderMark for UTF-8, seriously? See > http://en.wikipedia.org/wiki/Byte_order_mark, it's valueless, and not > recommended. It were a Squeak way to specify that a Squeak source file > would use UTF-8 rather than MacRoman, but now this should be obsolescent. > > > A BOM for utf-8 does not make sense. It could act as a switch between > legacy encoding and utf-8. But it would also be a decision that will be > regretted shortly after. Most files in monticello are 7bit so there > wouldn't be a problem changing the default encoding. For every other file > an exception will be thrown. So reading utf-8 and on exception reading the > same thing in legacy might be a way to go. > > Norbert > > > > 2013/5/22 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > >> >> http://stackoverflow.com/questions/16645848/squeak-monticello-character-enc… >> Let's kill this one, it's totally insane >> > >

May 22, 2013

Re: [Pharo-dev] MC should really write snaphsot/source.st in UTF8

by Norbert Hartl

Am 22.05.2013 um 23:16 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > First thing would be to simplify #setConverterForCode and #selectTextConverterForCode. > Do we still want to use a MacRomanTextConverter, seriously? I'm not even sure I've got that many files with that encoding on my Mac-OSX... > Do we really need to put a ByteOrderMark for UTF-8, seriously? See http://en.wikipedia.org/wiki/Byte_order_mark, it's valueless, and not recommended. It were a Squeak way to specify that a Squeak source file would use UTF-8 rather than MacRoman, but now this should be obsolescent. A BOM for utf-8 does not make sense. It could act as a switch between legacy encoding and utf-8. But it would also be a decision that will be regretted shortly after. Most files in monticello are 7bit so there wouldn't be a problem changing the default encoding. For every other file an exception will be thrown. So reading utf-8 and on exception reading the same thing in legacy might be a way to go. Norbert > > > 2013/5/22 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> >> http://stackoverflow.com/questions/16645848/squeak-monticello-character-enc… >> Let's kill this one, it's totally insane >

May 22, 2013

Re: [Pharo-dev] MC should really write snaphsot/source.st in UTF8

by Norbert Hartl

+1 Am 22.05.2013 um 22:57 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > http://stackoverflow.com/questions/16645848/squeak-monticello-character-enc… > Let's kill this one, it's totally insane

May 22, 2013

Re: [Pharo-dev] MC should really write snaphsot/source.st in UTF8

by Nicolas Cellier

First thing would be to simplify #setConverterForCode and #selectTextConverterForCode. Do we still want to use a MacRomanTextConverter, seriously? I'm not even sure I've got that many files with that encoding on my Mac-OSX... Do we really need to put a ByteOrderMark for UTF-8, seriously? See http://en.wikipedia.org/wiki/Byte_order_mark, it's valueless, and not recommended. It were a Squeak way to specify that a Squeak source file would use UTF-8 rather than MacRoman, but now this should be obsolescent. 2013/5/22 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > > http://stackoverflow.com/questions/16645848/squeak-monticello-character-enc… > Let's kill this one, it's totally insane >

May 22, 2013

Re: [Pharo-dev] clean, please

by Norbert Hartl

Am 22.05.2013 um 20:06 schrieb Paul Davidowitz <pdavidow(a)fastmail.fm>: > I was referring to text used in this mailing list, particularly words of > the form *u** > I like to agree that using them shouldn't be a common case. I don't have a problem if there are rare occurrences of them. And I see this list that way. One thing I like about this community is that emotional explosions are not prohibited. Most of the people here understand that this happens sometimes and they try to read what is behind it instead of blaming unpoliteness. I consider this as something healthy. my 2 cents, Norbert

May 22, 2013