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

[Pharo-project] Community Development (a suggestion)

by Sean P. DeNigris

Since there is a major push in both Squeak and Pharo to be clear about what's loading where, and get more and more projects loadable; and the community is fixing projects that we don't own... I propose: 1. Everyone make your SqS repos globally writable unless you have a reason not to. 2. SqS admins, send an email to all the repo admins requesting this. Motivation: I've been fixing many projects as I try to load them, as a service to the community, but I am not necessarily taking on being responsible for their long-term maintenance. Right now, the process seems to be: 1. Upload fixes to my own repo 2. Email the project admin (if they are even still findable) 3. Post to the mailing lists with the new link 4. Wait for a response Not only is this more complicated than it has to be, but creates confusion. For example, I fixed ExternalWebBrowser to work in Pharo, but couldn't upload it to the project repo. Now I fixed the ConfigurationOf. Where do I put it? If I put it in the usual places, it will now point to my personal repository. It doesn't seem right to hijack someone else's project this way. And it's confusing for users - why are there two ExternalWebBrowsers and ConfigurationOfs on squeaksource? Thanks. Sean -- View this message in context: http://forum.world.st/Community-Development-a-suggestion-tp2224670p2224670.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 20, 2010

Re: [Pharo-project] MetaSource demo app working again

by Sean P. DeNigris

Mariano Martinez Peck wrote: > > Cool Torsten. I have just tested in Mac and I got a problem since > ExternalWebBrowserMacOS class >> isApplescriptAvailable uses SMSqueakMap > I had fixed this and made a new ConfigurationOf, but I don't have write access to the EWB repo, so they are both here: http://www.squeaksource.com/SPDProjectUpdates -- View this message in context: http://forum.world.st/MetaSource-demo-app-working-again-tp2223751p2224656.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 20, 2010

Re: [Pharo-project] inbox cleaning

by StÃ©phane Ducasse

Me tooooooooooo > > I sort of prefer: > SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix) > That way all slices are next to each other in the inbox, and ordered by number, which makes it much easier to find what you're looking for, either when starting out with an issue from the bug tracker you need to integrate, or when you're looking at which slices are in inb

May 20, 2010

Re: [Pharo-project] Fwd: [Pharo-users] Accentuate Characters

by Henrik Johansen

On May 20, 2010, at 2:18 57PM, Mariano Martinez Peck wrote: > > > ---------- Forwarded message ---------- > From: Adrien BARREAU <abarreau.dev(a)live.fr> > Date: Mon, May 17, 2010 at 11:16 AM > Subject: [Pharo-users] Accentuate Characters > To: pharo-users(a)lists.gforge.inria.fr > > > Hello, > > I want to compose accentuate character in Pharo, but I don't know how I can do that. > I saw in Visual Works I can write this kind of things : > > $e composeDiacritical: (Character diacriticalNamed: #acute). > > That returns $Ã©. > > But, I don't find a way to do that in Pharo. > > Does somebody have an idea ? :) > > A.B. cc := CombinedChar new. cc add: $e; add: (Unicode value: 769); combined Diacriticals in CombinedChar only contain the Unicode Combining Diacritical Marks, it seems. There's no symbol -> diacriticial char mapping as far as I can tell. Cheers, Henry

May 20, 2010

Re: [Pharo-project] inbox cleaning

by laurent laffont

On Thu, May 20, 2010 at 3:17 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > FWIW, there's already kind of a process described at > http://code.google.com/p/pharo/wiki/HowToContribute > > I do agree with you on some things which could/should be changed though: > > On May 20, 2010, at 3:03 09PM, laurent laffont wrote: > > > I was thinking about following rules to make life easier: > > - a submission in PharoInbox must be a slice > +1. > Makes it much easier to scan the inbox for related package when an issue > has been marked as fixed and in Inbox. > Even when it only effects a single package (as the page states as an > exception to the slice-rule) > > > - slice must be formatted like LabelOfPatch-IssueNumber > > for example: > > BadCharactersInPackagenames-2124 > > PerformWithArgsPrimFailure-2443 > > - reject automatically slices which don't follow the name convention > > I sort of prefer: > SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix) > That way all slices are next to each other in the inbox, and ordered by > number, which makes it much easier to find what you're looking for, either > when starting out with an issue from the bug tracker you need to integrate, > or when you're looking at which slices are in inbox, but need to know which > issues are safe to close. > Yes, better to have the number before. Maybe we can remove the word slice too: XYZM-DescriptionOfIssue. I think the real trick is to reject (kindly, with lot of explanations :) all slices which do not follow the adopted convention so people follow the rule. We can create a PharoRejected repository to let people know. Then some Smalltalk code scans PharoInbox, move bad formatted slices to PharoRejected automatically. In PharoRejected packages are deleted after 2 weeks for example. Laurent > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 20, 2010

Re: [Pharo-project] halt in TTFontReader >>processCompositeGlyph:contours:from:

by Mariano Martinez Peck

2010/5/20 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > On May 20, 2010, at 2:11 48PM, Cyrille Delaunay wrote: > > Hello, > > There is a 'self halt' in the code of TTFontReader > >>processCompositeGlyph:contours:from:. > Therefore, when I try to import a font from a file, for example by > evaluating: > > TTFontDescription addFromTTFile: FileDirectory default fullName, > '/Fonts/DejaVu/DejaVuSans-Bold.ttf' > > the execution is stoped by this halt (And I don't know why). > Now, when I remove the 'self halt', all seems to work correctly. > > > The halt is in > > ((flags bitAnd: 2) = 2) ifFalse:[self halt]. > > From the spec at http://www.microsoft.com/typography/otspec/glyf.htm , > under Composite Glyph Description the flags are described : > * > * > ARGS_ARE_XY_VALUES1If this is set, the arguments are xy values; otherwise, > they are points. > So, it's probably an indication that reading the values as points is not > supported. > great. In such case we should write: ((flags bitAnd: 2) = 2) ifFalse:[self error: 'Reading the values as points is not supported']. :) Cheers Mariano > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 20, 2010

Re: [Pharo-project] inbox cleaning

by Henrik Johansen

FWIW, there's already kind of a process described at http://code.google.com/p/pharo/wiki/HowToContribute I do agree with you on some things which could/should be changed though: On May 20, 2010, at 3:03 09PM, laurent laffont wrote: > I was thinking about following rules to make life easier: > - a submission in PharoInbox must be a slice +1. Makes it much easier to scan the inbox for related package when an issue has been marked as fixed and in Inbox. Even when it only effects a single package (as the page states as an exception to the slice-rule) > - slice must be formatted like LabelOfPatch-IssueNumber > for example: > BadCharactersInPackagenames-2124 > PerformWithArgsPrimFailure-2443 > - reject automatically slices which don't follow the name convention I sort of prefer: SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix) That way all slices are next to each other in the inbox, and ordered by number, which makes it much easier to find what you're looking for, either when starting out with an issue from the bug tracker you need to integrate, or when you're looking at which slices are in inbox, but need to know which issues are safe to close. Cheers, Henry

May 20, 2010

[Pharo-project] Algernon for 1.1.

by Torsten Bergmann

>open a ticket done: http://code.google.com/p/pharo/issues/detail?id=2451 -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 20, 2010

Re: [Pharo-project] inbox cleaning

by StÃ©phane Ducasse

On May 20, 2010, at 3:03 PM, laurent laffont wrote: > I was thinking about following rules to make life easier: > - a submission in PharoInbox must be a slice > - slice must be formatted like LabelOfPatch-IssueNumber > for example: > BadCharactersInPackagenames-2124 > PerformWithArgsPrimFailure-2443 > - reject automatically slices which don't follow the name convention > > Then > - it's easy to build an interface which shows queued patches (filter by package name) > - it's easy to clean PharoInbox / delete required packages > - more visibility to the contribution process, one way of doing things (so we can automate - hudson server which test patch integration :) > > What do you think ? I like the idea. I need a server that we can script. > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > > On Thu, May 20, 2010 at 2:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes! > I clean but this is really tedious > > stef > > On May 20, 2010, at 11:57 AM, Torsten Bergmann wrote: > > > Hi Stephane, > > > > the MCZ's for > > HelpSystem-Core-tbn.45 > > HelpSystem-Core-tbn.43 > > > > were already harvested. So shouldnt this be moved > > to treated inbox then? > > > > Thx > > T. > > -- > > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > > > _______________________________________________ > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 20, 2010

Re: [Pharo-project] how to center a workspace in the World ?

by Fernando olivero

workspace := Workspace new. workspace acceptContents: ' Welcome to pharo...blah blah'. morph := workspace embeddedInMorphicWindowLabeled: 'Welcome to Pharo'. morph extent: 800@500. centeredPosition := ( RealEstateAgent maximumUsableArea center - ( ( morph width /2) @ ( morph height /2) ) ) rounded . morph position: centeredPosition. morph openAsIs . On May 20, 2010, at 2:21 PM, Mariano Martinez Peck wrote: > > > On Thu, May 20, 2010 at 1:46 PM, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > morph := Morph new. > morph extent: 400@400. > centeredPosition := ( RealEstateAgent maximumUsableArea center - ( ( morph width /2) @ ( morph height /2) ) ) rounded . > morph position: centeredPosition. > morph openInWorld . > > > Thanks Fernando. I want to do that but for a Workspace. Workspace doesn't extend from Morph. > > Cheers > > Mariano > > > > > On May 20, 2010, at 1:31 PM, Mariano Martinez Peck wrote: > > > How can I do that? For the moment, I am doing: > > > > openWelcomeWorkspace > > > > (Workspace new > > acceptContents: ' Welcome to pharo...blah blah > > > > '; > > embeddedInMorphicWindowLabeled: 'Welcome to Pharo') > > position: 50@120; > > extent: 800 @ 500; > > openAsIs > > > > > > I want to keep the extent, but the position to be centered. > > > > Thanks for any hint, > > > > Mariano > > <ATT00001..txt> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <ATT00001..txt>

May 20, 2010