- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ocompletion usability

by StÃ©phane Ducasse

Doru I'm on the cfocnused guy.... So indeed a nice preference now that we have Setting would be good. Stef On Nov 30, 2009, at 12:09 PM, Tudor Girba wrote: > Hi Romain, > >>> 1. Right now, OCompletion is triggered both by Tab and by Enter. It >>> should be only Tab. >>> >>> Here is the reason. When I have a cascade, I want to have the methods >>> starting from the next line, like this: >>> browser mondrian >>> title: 'Something'; >>> painting: [:view ... ] >>> >>> So, after I type browser mondrian, I naturally want to press Enter. >>> However, there exists a method called mondrianAnnounce:, and when I >>> press Enter it gets filled in. So, the intent of Enter should be >>> similar to that of Space: just as a whitespace. Tab is a good choice >>> for triggering the completion because we basically only use Tabs only >>> in a new line where the completion does not apply. >>> >> >> Well, the completion with enter was requested by a few people, so we >> should reach a consensus. > > I believe that the scenario presented above is a reasonable and not > uncommon one. Right now, I have to get from an subconscious state of > typing to a conscious one to get myself to press Space before Enter. > And I do not see the gain of having two keys doing the same thing. > >>> 2. When no completion is offered and I press tab, I do get some list. >>> Why is this not offered by default? Is it because it is slower? Is it >>> because it is the regular ECompletion and that is not useful? >> >> It is the regular ECompletion, which is slower, and less useful. >> >>> >>> 3. The completion is triggered only when typing, but not when >>> removing >>> characters. I believe it would be better if it followed me all the >>> time. >>> >> >> Good point! >> >>> 4. When I want to navigate through the offered list using the down >>> arrow the look changes and the items become wider. In fact, the same >>> appears when I force completion by pressing Tab, so this leads me to >>> believe that the change in the look is given by the change from O >>> to E >>> completion. The look should remain the same. >> >> I thought about it and concluded that it may be good to differentiate >> them. > > I do not believe that making explicit the internal implementation of > the overall completion service is beneficial. In fact, the > inconsistency just raises questions and it somehow makes me feel as if > I am breaking something. > > If the question of the choice between the E and O appearance arises, > my preference is for the colors and appearance of OCompletion (I like > it that it does not take that much space and the colors are less > intrusive). > > Cheers, > Doru > >> As for the tab/enter issue, different people think differently. That's >> why we should reach a consensus >> on these two issues, so that I can decide whether I should remove >> these two features :-). >> >> Cheers, >> Romain >> >>> >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "If you interrupt the barber while he is cutting your hair, >>> you will end up with a messy haircut." >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Romain Robbes >> http://www.inf.unisi.ch/phd/robbes >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "It's not how it is, it is how we see it." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 30, 2009

Re: [Pharo-project] file encodings

by StÃ©phane Ducasse

Doru we integrated the suggestion of nicolas as result of the discussion. Stef On Nov 30, 2009, at 12:11 PM, Tudor Girba wrote: > Hi, > > I know that there was a long discussion regarding opening of files, > but I did not see a resolution. > > I would like to be able to read files regardless of the encoding. I am > using this code: > (CrLfFileStream readOnlyFileNamed: fullPath) contentsOfEntireFile" > > but I get an error when I reach a file in Latin 1 (ISO-8859-1). > > How can I safely deal with this issue without getting hurt? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 30, 2009

Re: [Pharo-project] Where to put removed stuff?

by StÃ©phane Ducasse

indeed > > I wouldn't put these packages into the SqueakSource project "Pharo". I > put the Sound and MorphicExample code that I removed from the core > into separate SqueakSource projects. Like this the main repository > does not get cluttered with unloaded code. Being separate from the > core code also allows for public write access, which is not granted on > the Pharo project. > > Cheers, > Adrian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 30, 2009

Re: [Pharo-project] Where to put removed stuff?

by Niko Schwarz

On Stackoverflow someone asked what to do with good code which isn't needed anymore. This was the answer: <blockquote>As an answer, please consider this short story: The dead code Collector: Bring out yer dead code. Man with dead code : Here's one. The dead code Collector: That'll be ninepence. The dead code: I'm not dead code. The dead code Collector: What? Man with dead code : Nothing. There's your ninepence. The dead code: I'm not dead code. The dead code Collector: 'Ere, he says he's not dead code. Man with dead code : Yes he is. The dead code: I'm not. The dead code Collector: He isn't. Man with dead code : Well, he will be soon, he's very ill. The dead code: I'm getting better. Man with dead code : No you're not, you'll be stone dead code in a moment. The dead code Collector: Well, I can't take him like that. It's against regulations. The dead code: I don't want to go on the cart. Man with dead code : Oh, don't be such a baby. The dead code Collector: I can't take him. The dead code: I feel fine. Man with dead code : Oh, do me a favor. The dead code Collector: I can't. Man with dead code : Well, can you hang around for a couple of minutes? He won't be long. The dead code Collector: I promised I'd be at the Robinsons'. They've lost nine today. Man with dead code : Well, when's your next round? The dead code Collector: Thursday. The dead code: I think I'll go for a walk. Man with dead code : You're not fooling anyone, you know. Isn't there anything you could do? The dead code: I feel happy. I feel happy. [the dead code Collector glances up and down the street furtively, then silences the dead code with his a whack of his Ctrl-X] Man with dead code : Ah, thank you very much.--BraveSirFoobar</blockquote>. (The Thread on Stackoverflow: http://stackoverflow.com/questions/352234/what-to-do-with-unused-useful-code) cheers, Niko 2009/11/29 Simon Denier <Simon.Denier(a)inria.fr>: > Hi there > I think this has been discussed before, but I cant tell if there is an > official rule for that (maybe it could be added to the wiki). > So let's say I have a patch which removes the Collection arithmetic > protocols (332). Now this protocol is still quite nice and we can offer it > as an extension package for those who need it. Where should I put this > Collection-Arithmetic package? In its own squeaksource project? Or is there > a project for extra packages for Pharo? > -- > Â Simon > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Nov. 30, 2009

Re: [Pharo-project] pharo and db support

by Niko Schwarz

Ah, great :). On Sun, Nov 29, 2009 at 3:37 PM, Johan Brichau <johan.brichau(a)uclouvain.be> wrote: > In our experience, Magma took around 250ms, regardless if the query > had a large or small set of results. > Using GOODS, our application appears to run as fast as if the object > collections were kept in-image only (response times of 10ms for our > queries). Maybe it will run slower for very large object collections > but since we will not run into that problem, it's not an issue in our > case. > > There's some differences regarding transactions support which we had > to cope with, but it all seems to run just fine right now. > > and thanks for having suggested it! ;-) > > On 29 Nov 2009, at 13:26, Niko Schwarz wrote: > >> Glad to hear it :). Is it really faster than Magma in your experience? >> >> Cheers, >> >> Niko >> >> On Sun, Nov 29, 2009 at 11:11 AM, Johan Brichau >> <johan.brichau(a)uclouvain.be> wrote: >>> We are using GOODS for a while now and it runs pretty well. I have >>> added it to the wikipage. >>> >>> On 26 Nov 2009, at 17:39, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> I would like to collect a list of the solutions to link Pharo with >>>> existing databases. I am interested in both relational and in object >>>> databases. >>>> >>>> Is there a list somewhere? If not and if you know/use/develop/ >>>> such a >>>> solution, it would be great if we could put it together by >>>> collecting >>>> some data about these: >>>> >>>> - Pharo project and version >>>> - Supported database vendor and version >>>> - Maturity: prototype/production ready/ >>>> - Projects that use this one >>>> - Current development status and maintenance support (if any) >>>> - Website >>>> - Others >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "If you interrupt the barber while he is cutting your hair, >>>> you will end up with a messy haircut." >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> ---------------------------- >>> Johan Brichau >>> johan.brichau(a)uclouvain.be >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Nov. 30, 2009

Re: [Pharo-project] Continuous Integration Server for Pharo?

by Simon Denier

As 'developer by default' of TestServerSimple, I can just: TestServerSimple is just that, something to automatically download the latest version of packages, run the tests, and send a small report by mail. Right now the server works with Metacello configuration, is still not bulletproof to some exceptions (like a TimeOut on a distant repository), and used to work with Flair config or directly with Monticello packages. Now I dont have the time or the energy to invest more in this thing, so I would be happy to beta-test integration servers on Moose. The features you describe are interesting. So once, everybody has settled on some good solution (be it BB, Hudson, ...), just come to me with a good tutorial :) On 28 nov. 2009, at 09:23, Bart Gauquie wrote: > Dear all, > > I come from a Java world and there we use for instance : http://hudson-ci.org/ > to do a continuous integration build. Which means all latest code > gets updated, all test ran & if build successful, the code is tagged > (so you can take the code again from a successful build). It also > provides a nice GUI, and lets you inspect previous builds, the > results from that build, ... . > > In Pharo, I did not directly find an alternative, and therefor, also > as an exercise, I tried to build one myself. > The primitive, but working result so far is: http://www.squeaksource.com/BuildBot > . > > This project depends on BBProjectDescription, which defines class > BBBuildProjectDescription with defines: > BBBuildProjectDescription>>allProjectPackageNames > BBBuildProjectDescription>>installLatestWithDependencies > BBBuildProjectDescription>>buildsClassToPutVersionsOn > What buildbot then does is using a BBBuildProjectDescription , > checkout all latest code, run the tests for all these packages & , > if successfull, take the buildsClassToPutVersionsOn and add a new > method on it, describing the exact package numbers : > for instance: > BuildBotMockProjectBuilds class >> packagesForBuild20091127102654 > ^#(('TODO' -> 'TODO-BKBAG.5.mcz') ('BuildBtMockProject' -> > 'BuildBtMockProject-BartGauquie.7.mcz') ). > > Using this information I can easily install this exact version. > Furthermore creating a release is then just creating for instance a > class BuildBotMockProjectReleases with: > BuildBotMockProjectReleasesclass >> release_1_0 > ^BuildBotMockProjectBuilds packagesForBuild20091127102654 > > I am in fact 'tagging' a group packages that belong together and > work together. So I can rollout this exact versions of the packages > to some image automatically. > > > However, > Today I noticed that there already existed a project: http://www.squeaksource.com/TestServerSimple > which more or less does the same thing. The only thing it does not > do, or I did not find it, is to version the build, so that you can > restore a project again ; a project which is consisting of a number > of packages which are compatible and for which all tests ran. Is > there a way to do that in TestServerSimple? > > Furthermore, are there any other projects that do a similar thing > I'm not aware of? Is there any default way in Pharo to build a > project which consists of multiple packages that each have different > versions? > > I've seen MetaCello & Gofer as some other way 2 load groups of > packages, but no integration into some kind of ci tool. > > This kind of automated ci server seems 2 me an essential tool in > Pharo. > > Thanks for any pointers / ideas ! > > Kind Regards, > > Bart > > -- > imagination is more important than knowledge - Albert Einstein > Logic will get you from A to B. Imagination will take you everywhere > - Albert Einstein > Learn from yesterday, live for today, hope for tomorrow. The > important thing is not to stop questioning. - Albert Einstein > The true sign of intelligence is not knowledge but imagination. - > Albert Einstein > Gravitation is not responsible for people falling in love. - Albert > Einstein > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Nov. 30, 2009

Re: [Pharo-project] ocompletion usability

by Simon Denier

On 30 nov. 2009, at 09:45, Romain Robbes wrote: >> >> I concur with Doru especially on this one. I think the best to do is >> to have some kind of settings (with the new settings package) so that >> users can customize their own key bindings (or, failing that because >> key bindings is not easy for now, a setting to enable/disable the >> 'enter' or the 'tab' keybinding) > > > Is that settings package included by default? I think it is scheduled for inclusion in 1.1. See the latest post of Alain and his slice in the inbox. -- Simon

Nov. 30, 2009

Re: [Pharo-project] Where to put removed stuff?

by Simon Denier

On 30 nov. 2009, at 09:45, Adrian Lienhard wrote: > > On Nov 30, 2009, at 12:07 , StÃ©phane Ducasse wrote: > >>> Hi there >>> >>> I think this has been discussed before, but I cant tell if there is >>> an official rule for that (maybe it could be added to the wiki). >>> >>> So let's say I have a patch which removes the Collection arithmetic >>> protocols (332). Now this protocol is still quite nice and we can >>> offer it as an extension package for those who need it. Where >>> should I put this Collection-Arithmetic package? In its own >>> squeaksource project? Or is there a project for extra packages for >>> Pharo? >> >> in general if a package should be part of a dev image and it was >> curved out from the image it would >> be good to have in the Pharo repository. May be in the future we >> will need some repository for non core packages. > > I wouldn't put these packages into the SqueakSource project "Pharo". I > put the Sound and MorphicExample code that I removed from the core > into separate SqueakSource projects. Like this the main repository > does not get cluttered with unloaded code. Being separate from the > core code also allows for public write access, which is not granted on > the Pharo project. OK, I will do that then. -- Simon

Nov. 30, 2009

Re: [Pharo-project] file encodings

by Tudor Girba

Hi Nicolas, Thanks for the tips. I am a bit alien to the topic of encodings, so I will ask a couple of silly questions. How exactly do I deal with another encoding? For example, why does this work with Utf-8, and what would I do if I encountered another encoding? Or more general, how can I find out what kind of converter I need for a given file? Cheers, Doru On 30 Nov 2009, at 12:30, Nicolas Cellier wrote: > You may try this: > > (CrLfFileStream readOnlyFileNamed: fullPath) converter: > Latin1TextConverter new; contentsOfEntireFile > > Or if you want more explicit control: > > (MultiByteFileStream readOnlyFileNamed: fullPath) lineEndConvention: > #crlf; converter: Latin1TextConverter new; contentsOfEntireFile. > > Nicolas > > 2009/11/30 Tudor Girba <tudor.girba(a)gmail.com>: >> Hi, >> >> I know that there was a long discussion regarding opening of files, >> but I did not see a resolution. >> >> I would like to be able to read files regardless of the encoding. I >> am >> using this code: >> (CrLfFileStream readOnlyFileNamed: fullPath) contentsOfEntireFile" >> >> but I get an error when I reach a file in Latin 1 (ISO-8859-1). >> >> How can I safely deal with this issue without getting hurt? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "When people care, great things can happen." >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "When people care, great things can happen."

Nov. 30, 2009

Re: [Pharo-project] Where to put removed stuff?

by Adrian Lienhard

On Nov 30, 2009, at 12:07 , StÃ©phane Ducasse wrote: >> Hi there >> >> I think this has been discussed before, but I cant tell if there is >> an official rule for that (maybe it could be added to the wiki). >> >> So let's say I have a patch which removes the Collection arithmetic >> protocols (332). Now this protocol is still quite nice and we can >> offer it as an extension package for those who need it. Where >> should I put this Collection-Arithmetic package? In its own >> squeaksource project? Or is there a project for extra packages for >> Pharo? > > in general if a package should be part of a dev image and it was > curved out from the image it would > be good to have in the Pharo repository. May be in the future we > will need some repository for non core packages. I wouldn't put these packages into the SqueakSource project "Pharo". I put the Sound and MorphicExample code that I removed from the core into separate SqueakSource projects. Like this the main repository does not get cluttered with unloaded code. Being separate from the core code also allows for public write access, which is not granted on the Pharo project. Cheers, Adrian

Nov. 30, 2009