- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3591 in pharo: Implementors of #listMorph place it in different (or no) category

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3591 by sean.p.d...(a)gmail.com: Implementors of #listMorph place it in different (or no) category http://code.google.com/p/pharo/issues/detail?id=3591 Pharo1.2rc1 Latest update: #12320 What is (if any) the standard here? I usually follow Kent Beck's advice to put getters in 'private' unless they are meant to be public, and in that case, in 'accessing'. But here we have 'accessing'/'callbacks' (OB)/'user interface'. Sean

Jan. 25, 2011

Re: [Pharo-project] What about a little rename in MouseEvent?

by csrabak＠bol.com.br

> Em 24/01/2011 05:25, Marcus Denker < marcus.denker(a)inria.fr > > escreveu: > On Jan 24, 2011, at 5:39 AM, Guillermo Polito wrote: > > I hate yellowButtonPressed and redButtonPressed and > > blueButtonPressed messages. Why not lefClick, rightClick and > > "middleClick"? > > > Yes. > Back in the days, the color buttons where "holy cows". You just > could not even suggest to change it. On the other hand, as the buttons of mice can be reassigned, the 'names' "right" and "left" could become ambiguous... my 0.019999... -- Cesar Rabak

Jan. 25, 2011

Re: [Pharo-project] Gofer issue

by Lukas Renggli

> In VW we use the following convention > > Â Â Â Â base version + branch id - branch version > > which then naturally extends to > > Â Â Â Â base version + branch id - branch version + branch2 id - branch2 version Multiple branches are specified as given in the grammar. { "." Branch } in EBNF means zero or more of whatever is enclosed. Whenever a new branch is started its id resets to 1. The ancestry information does not need to be tracked in the name, it is luckily already contained in the meta-information. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by mkobetic＠gmail.com

What about branch from a branch ? In general you need a tuple of (base version, branch id, branch version) to identify a branch version. Similarly a branch on a branch would become ((base version, branch id, branch version), branch2 id, branch2 version). In VW we use the following convention base version + branch id - branch version which then naturally extends to base version + branch id - branch version + branch2 id - branch2 version In monticello, your 'version' is author.nr (to accommodate distributed development) so the scheme would become author0.nr0 + branch1 - author1.nr1 + branch2 - author2.nr2 People probably won't like that, but I think the notion of the version identification tuple is relevant to the discussion. For example neither of the schemes below indicates where the branch starts. "Lukas Renggli"<renggli(a)gmail.com> wrote: > You cannot get rid of branching, this is a central part of version > control and extensively used in many large projects. > > In Seaside we use the following pattern, also see the documentation at > http://code.google.com/p/seaside/wiki/PackageNaming: > > Package = PackageName "-" Author { "." Branch } "." Version > > However I noticed that other projects (and earlier versions of > Seaside) use a different scheme: > > Package = PackageName { "." Branch } "-" Author "." Version > > In this case I guess we must support: > > Package = PackageName { "." Branch } "-" Author { "." Branch > } "." Version > > However, that doesn't change that $. and $- cannot be part of the > PackageName or Author.

Jan. 24, 2011

Re: [Pharo-project] Issue 3562 in pharo: Deferred UI messages executed slowly

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.3 Comment #1 on issue 3562 by marianopeck: Deferred UI messages executed slowly http://code.google.com/p/pharo/issues/detail?id=3562 thanks richo :)

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by Lukas Renggli

On 24 January 2011 14:31, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > Current Pharo accepts $. as part of the full name. Then it is broken. Lukas > > El lun, 24-01-2011 a las 14:22 -0800, Lukas Renggli escribiÃ³: >> > Then an quick/easy fix is to filter out $. from the FullName prompt in >> > the image. >> >> That was one of my first changes to Pharo 0.0001. >> >> Lukas >> > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > > -- Lukas Renggli www.lukas-renggli.ch

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by Dale Henrichs

Filtering doesn't help if the package was saved from a Squeak or GemStone image or someone hand edited their package name ... I know that a number of folks don't care about anyone that isn't using the latest version of Pharo, but that is not the case for all developers. Monticello could be a common interchange format for code, but if folks impose incompatible restrictions on package names then we might as well give up on that possibility ... If you want to have a common interchange format, then you need to avoid unilateral changes that cause incompatabilites ... If you don't want to make common code more difficult than it needs to be, then you are headed down the right path ... I apologize in advance for offending anyone and I'll just shut up on this particular issue... Dale On 01/24/2011 02:20 PM, Miguel CobÃ¡ wrote: > Then an quick/easy fix is to filter out $. from the FullName prompt in > the image. > > Cheers > > El lun, 24-01-2011 a las 14:16 -0800, Lukas Renggli escribiÃ³: >>> However, that doesn't change that $. and $- cannot be part of the >>> PackageName or Author. >> >> Just $., forget what I said about $-. >> >> Lukas >> >

Jan. 24, 2011

Re: [Pharo-project] [Pharo-users] Infinite loop is not stopped by Cmd+.

by Mariano Martinez Peck

I could reproduce it. Myabe I am saying something stupid, but didn't Cmd+. depends on the process priority? I mean, if the loop was caused by a Process with higher priority than Cmd+. then it cannot be interrupted. can someone help? cheers mariano On Wed, Jan 19, 2011 at 12:56 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > probably the loop was too tight and the system did not get a chance to > react. > This is not the right behavior but not clear how to change it. > > Stef > > On Jan 19, 2011, at 12:19 PM, Alex Schenkman wrote: > > > Hi List, > > > > Recently I had a bug causing an infinite loop, which in turn hanged the > image. > > I thought that Cmd+. would allow me to stop this, but this is not the > case. > > > > Adding and executing this method hangs my image and Cmd+. does not stop > it. > > > > MyClass>>infinite > > ^self infinite > > > > Is this the right behavior? > > Thanks in advance! > > > > >

Jan. 24, 2011

Re: [Pharo-project] Pharo packages and Settings/Preferences questions

by Mariano Martinez Peck

On Tue, Jan 18, 2011 at 2:51 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > Two quick questions this morning : > > 1) If I am using a package from squeaksource.com and this package only > works with Squeak now (methods have been removed from Pharo, methods only > exists in Squeak, different behavior in Pharos vs Squeak, whatever the > reason), what is the preferred way of committing a works-in-Pharo version to > SqueakSource ? I wouldn't want the same problem happening to Squeakers, > i.e. someone loads this package in Squeak and discover that the new version > only works in Pharo now! Perhaps the answer is "Pharo needs its own > SqueakSource repository" but in the meantime, what should I do and how? > usually people use a YourApp-Dialect YourApp-Dialect-Squeak , YourApp-Dialect-Pharo etc. Then you can use Grease or Sport. Finally, with Metacello you can automatically load packages depending on the OS. > > 2) Is there a preferred way of adding settings/preferences to the Pharo > environment, if so can someone redirect me to the proper documentation/link > on how-to-do-it ? I'm a bit confused as to what I'd have to use since there > seems to be some old (?!?!) Preferences stuff still present in Pharo. In my > case, I'd like to be able to specify my own parseableSourceCodeTemplate > instead of the default one. > http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting/ > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > >

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by Miguel CobÃ¡

Current Pharo accepts $. as part of the full name. El lun, 24-01-2011 a las 14:22 -0800, Lukas Renggli escribiÃ³: > > Then an quick/easy fix is to filter out $. from the FullName prompt in > > the image. > > That was one of my first changes to Pharo 0.0001. > > Lukas > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 24, 2011