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

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

by StÃ©phane Ducasse

+ 1000 :) On May 22, 2013, at 11: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. > > > 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 23, 2013

Re: [Pharo-dev] Messy Configurations

by stephane ducasse

On May 23, 2013, at 4:22 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> What do you think? > > I think we should have a stable and strong Versionner. As soon as making a software release is more than clicking one button, we will end up with messy configurations. Yes christophe worked on porting travis to pharo because dale used it for his tests so that we can get the latest version of metacello in pharo. We do not do it for fun believe me. Stef

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by stephane ducasse

>> >> > i stand corrected.. actually i meant following composition: > > ProjectName-Core > ProjectName-Extras > ProjectName-Tests Yes something simple!!!!!! > > no 3-4 levels of tick-tacks (but i love to use subcategories inside a > package, i.e.

May 23, 2013

Re: [Pharo-dev] could we rename ensureDeleted into ensureDelete?

by stephane ducasse

I disagree and this is not coherent with the ensureFile and ensureDirectory On May 22, 2013, at 10:33 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Camillo Bruni-3 wrote >> because it is the final state, the file is deleted. >> it emerged out of a longer discussion with sean, mariano and me I think > > Yes, we discussed thoroughly in the ml [1] (you were a part, but it was a > while back). The objection, which I came to agree with, was that you're not > "ensuring delete" because it may not be deleted (e.g. if it never existed). > > [1] > http://forum.world.st/FileReference-should-throw-error-when-deleting-unexis… > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-dev-could-we-rename-ensureDeleted-into-ensureDe… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 23, 2013

Re: [Pharo-dev] FileSystem inconsistency

by stephane ducasse

We should talk when I'm back but my point is that deleting an nonexisting file should raise an error, if deleting an non existig folder does. >> Hi >> >> I'm doing a pass on the FileSystem chapter (yes you know the documentation that nobody write but everybody >> wants to read), I'm updating/adding method comments and I get the following. >> >> paf does not exist >> >> (FileSystem disk workingDirectory / 'paf' ) delete. >> works without barking >> >> => may delete should barks to be consistent. >> >> >> >> (FileSystem disk workingDirectory / 'paf' ) deleteAll. >> barks! >> >> (FileSystem disk workingDirectory / 'paf' ) deleteAllChildren. >> barks! >> >> (FileSystem disk workingDirectory / 'paf' ) deleteIfAbsent: [ Warning signal: ' File does not exist' ] . >> works > > > that's fully correct in my opinion. The error message are less consistent. > There are operations that only work on files and some that only work on folders. > #deleteAll, #deleteAllChildren are only working on directories (much like `rm -R folder`). > #delete works on single instances, much like `rm file` but also on folders

May 23, 2013

Re: [Pharo-dev] Messy Configurations

by Alexandre Bergel

> What do you think? I think we should have a stable and strong Versionner. As soon as making a software release is more than clicking one button, we will end up with messy configurations. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 23, 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 3:57 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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. For a long time, yes. > 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. Right. I now remember the pain. > 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). For Pharo, I'd guess so, too. (I heard that the Japanese support is pretty much dropped in Pharo.) -- -- Yoshiki

May 23, 2013

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

by Igor Stasenko

On 22 May 2013 21:12, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 22 May 2013 18:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Frank, >> >> On 22 May 2013, at 14:55, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> On 22 May 2013 13:44, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> >>>> On 2013-05-22, at 14:36, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> >>>>> On 22 May 2013 13:20, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>>> >>>>>> On 2013-05-22, at 14:02, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>>> >>>>>>> On 22 May 2013 12:49, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>>>>>>>>>> >>>>>>>>>> ./pharo Pharo.image config filetree://`pwd`/../src/ >>>>>>>>>> >>>>>>>>>> Fails on trying to execute #mcRepositoryAsUser:withPassword: on a GenericUrl >>>>>>>>>> instance inside Gofer. >>>>>>>>> >>>>>>>>> Yep, I'd agree with your assessment. Has Pharo forked Gofer, or does >>>>>>>>> it still use Lukas Renggli's repository? >>>>>>>> >>>>>>>> We forked it. We cannot built a part of our infrastructure on a project that can vanished in nature. >>>>>>> >>>>>>> Well. What I should have asked was "have you cloned the repository >>>>>>> with the intention of pushing improvements upstream, or have you >>>>>>> forked the project with no intention of pushing changes upstream?" >>>>>> >>>>>> well, check on how much we changed in detail and them come back. >>>>> >>>>> Sorry, was that supposed to be an answer? I must go find out how much >>>>> work you've done before guessing whether you've forked and abandoned >>>>> upstream? >>>> >>>> abandon or progress that's the question here. >>> >>> That's a false dichotomy. There's a middle path, where you do the MC >>> equivalent of a pull request. Now there's something useful to aim for: >>> GitHub works so very, very well because it's utterly trivial to make >>> upstream repositories know you have improvements lying around. Because >>> fragmentation of your committer base _does not help you_ in the long >>> run. >>> >>> Now if the upstream maintainer _dies_, sure, that's a different story. >>> >>>>> Like I said: What I want to know is this: if I want to make a change >>>>> to infrastructure common to multiple Smalltalks, does Pharo expect me >>>>> to submit special unique snowflake additions to Pharo AND to upstream? >>>> >>>> well if you expect us to push anything upstream then have a look at the >>>> massive amount of changes that happened since pharo 1.0. >>> >>> I don't care about Pharo 1.0 in the context of this discussion. I care >>> about one particular package, one that should have no UI elements in >>> it or similar nasty sources of entanglement. (I have attempted to port >>> quite a few Pharo packages to Squeak. Lack of separation between UI >>> and core functionality has been the only reason I've had to abandon a >>> port, thus far.) And certainly Gofer as it's pulled in via Metacello >>> (er, which one? The upstream one, not Pharo's fork of same) works fine >>> in Pharo, Squeak and Gemstone, and wherever else Metacello and Gofer >>> run. I should _not_ have to submit to more than one repository to add >>> functionality to Gofer. >>> >>>> There IS a reason pharo forked from squeak... >>> >>> I'm not pursuing this thread: it's my understanding that the fork was >>> largely political, and personal, and that's as far as I'm going to >>> talk about it. >> >> Well, you are wrong about the reasons for the fork, IMO. But it is a done deal. (See my answer to Janko). > > Am I? I spent a good hour crawling through squeak-dev for the time > period 2007-2008. The Board was around at the time, and I saw nothing > in their communications to indicate anything about a fork. So whatever > happened, happened in secrecy, in private mails, in person. Ways that > left no public trace. And, in my opinion, if people did unethical > things to certain members of the community, then I think they should > be named and shamed. > > The split was _bad_ for the community. I understand that Stef and > Marcus did what they felt they had to do, and I think it's a crying > shame that they were forced into such drastic action. It's now 5 or 6 > years later and it's still an open wound. > I felt the same around 2009.. but today not.. maybe because i am too involved with Pharo now, and i cannot tell a difference. But i agree with Stef, that main issue with Squeak, there is no clear what direction(s) it going. Fixes and small improvements? Okay.. but can you call it evolution? Clearly not. (well, except from plans to make next Squeak release to be based on Craig's Spoon work.. which was plans when i was board member in 2008 (i think), and it is still not there).. The only big thing which happened around, when i was active member of Squeak, was fixing license issues and making Squeak code covered by MIT. Yes, this is important move (but Pharo came through this pain too, as you know, and it took much less time for them to do that, and take into account that at that time there was much more squeakers than pharoers). But again this "progress" belongs rather to political plane, not technical one, and personally, i do not really care :). The technical progress is Opal compiler. Nautilus browser, and RPackage (and this list not ends..). Yes they are not ideal and need further work.. but what i like that we, in pharo do not wait till something will become ideal and only then we include it into our project: it should be just fairly acceptable. And that we're not fear to step on someone's toys. And believe me, Pharo is still quite far (to my taste) from being ideal platform for my daily needs. But that's why i here, and many others, who sharing same vision: make smalltalk appeal to professional developers. Because if you can attract professionals, then they can do rest: better tools, better UI's.. everything. And then eventually you will have plenty of manpower to make things done, as well as feel safe from bus-factor, when one guru leaves project making its future very dim & uncertain. So, this are the values, why i would bet on Pharo instead of Squeak for any future project i may want to develop: not technical superiority(or opposite), not the size of community, but clear vision and direction where it heading. >> Now, for library/framework developers/maintainers it is hard to be compatible with different Smalltalk implementations. It is not impossible, but requires manpower, interest and will. Recently, only Fuel managed to do that (of the bigger projects). > > Yes, it _is_ hard, and I _greatly_ appreciate the efforts not just of > Max, Martin and Mariano but also the Metacello community (especially > Dale, who has suffered for his project) on making things work across > platforms. I try do what little I can to help to support them. Again > thanks to Dale, I can have my various libraries running against Pharo > (although I see I need to add Pharo 2.0 to my Control library's > matrix). So I try make sure that my Squeak work's available for Pharo > users. > >> 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. > > 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. > > frank > -- Best regards, Igor Stasenko.

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Igor Stasenko

On 23 May 2013 02:38, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 22 May 2013 22:16, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2013-05-22, at 22:11, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >>> 2013/5/22 Camillo Bruni <camillobruni(a)gmail.com> >>> >>>> >>>> On 2013-05-22, at 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 >>>>> >>>>> 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. >>>> >>>> I would love to change that rule. I think Tests have the same value as the >>>> code itself. >>>> The only reason to not load the code is the load time for the >>>> configuration. Which is >>>> basically is unimportant if you have a CI server preparing images for you. >>>> >>>> I can only speak for smaller projects, but I really do not sea a reason to >>>> not load tests... >>>> >>> >>> Because tests not needed to run your application. >> >> technically yes, but you do not need many things to run the code: >> - class comments >> - method comments >> - any documentation in general >> yet you load them. so I wonder if it makes sense to even load tests separately? > > for me there is one big reason to put tests in separate package: modularity. > I usually care a little about modularity when writing tests (they can > use anything from anything, > as long as test fulfills its purpose and covers the functionality i need).. > But in regular code i cannot afford that , because then Kernel will > start depending on Morphic etc.. > .. as for production, i am even more radical: i would leave only bytecode in image. (and some people would even go further and obfuscate class/method names, replacing them with meaningless names). The problem is that we don't have such tools. Probably because we don't need them, because most of our work is open source. But for proprietary, closed-source project i bet this is one of the issues why pointy-hair managers ;) prefer to use other language than smalltalk. > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Igor Stasenko

On 22 May 2013 22:16, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-05-22, at 22:11, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> 2013/5/22 Camillo Bruni <camillobruni(a)gmail.com> >> >>> >>> On 2013-05-22, at 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 >>>> >>>> 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. >>> >>> I would love to change that rule. I think Tests have the same value as the >>> code itself. >>> The only reason to not load the code is the load time for the >>> configuration. Which is >>> basically is unimportant if you have a CI server preparing images for you. >>> >>> I can only speak for smaller projects, but I really do not sea a reason to >>> not load tests... >>> >> >> Because tests not needed to run your application. > > technically yes, but you do not need many things to run the code: > - class comments > - method comments > - any documentation in general > yet you load them. so I wonder if it makes sense to even load tests separately? for me there is one big reason to put tests in separate package: modularity. I usually care a little about modularity when writing tests (they can use anything from anything, as long as test fulfills its purpose and covers the functionality i need).. But in regular code i cannot afford that , because then Kernel will start depending on Morphic etc.. -- Best regards, Igor Stasenko.

May 23, 2013