- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Gofer issue

by Lukas Renggli

> 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 -- Lukas Renggli www.lukas-renggli.ch

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by Miguel CobÃ¡

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 > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 24, 2011

Re: [Pharo-project] Issue 2704 in pharo: Tests for broken withNoLineLongerThan: behavior.

by pharo＠googlecode.com

Comment #7 on issue 2704 by marianopeck: Tests for broken withNoLineLongerThan: behavior. http://code.google.com/p/pharo/issues/detail?id=2704 thanks pocho :) so, it is ready to integrate?

Jan. 24, 2011

Re: [Pharo-project] Pharo on the iPhone

by Sean P. DeNigris

Niko Schwarz tweeted that PhoneGap (http://www.phonegap.com/features) let's you write an app in HTML5 and hook into native mobile features (e.g. accelerometer) on multiple platforms, including the iPhone. He said that one could write an app in Seaside that outputs HTML5 and it would appear native on the iPhone. It sounds interesting. Has anyone played with/seen this yet? Sean -- View this message in context: http://forum.world.st/Pharo-on-the-iPhone-tp3228851p3235065.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by Lukas Renggli

> However, that doesn't change Â that $. and $- cannot be part of the > PackageName or Author. Just $., forget what I said about $-. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by Lukas Renggli

> Ok so I have the impression that we could get rid of branching or use another delimiter. 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. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 24, 2011

Re: [Pharo-project] Tabs and back button in browser?

by Tudor Girba

Hi Janko, Good observation. I too believe that to bring Pharo further we have to rethink the IDE experience altogether. This requires more than just patch the existing IDEs with a couple of widgets. I am definitely interested in working on this. The work on Glamour goes towards providing an infrastructure for such new kinds of tools. For example, tabs are now nicely supported in several forms. Navigation is indeed not yet supported, but it is on the roadmap. The major problem currently is posed by the Morphic widgets. Gary and Alain are doing a great job, but it would be cool if we would get a more concerted effort in this area. If anyone is interested in spending energy on this, please contact me. Cheers, Doru On 24 Jan 2011, at 14:47, Janko MivÅ¡ek wrote: > Hi Pharoers, > > Are you thinking about introducing tabs and back/forward button, like in > web browsers? > > Just because of web we are now all accustomized and used of tabbed > browsing and navigation with a back and forward buttons. This habit now > demands all other tools to follow. Tabs are now everywhere, also in > Smalltalk. Look at Visualworks, also Dolphin. > > Introducing tabs soon in Pharo will therefore greatly improve user > experience, so if someone would spend some time on it, his contribution > will be very valuable! > > Best regards > Janko > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

Jan. 24, 2011

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

by StÃ©phane Ducasse

I would like to have the iSqueak Event hierarchy. It is published in PharoTaskForces if I remember correctly. Stef > I hate yellowButtonPressed and redButtonPressed and blueButtonPressed messages. > > Why not lefClick, rightClick and "middleClick"? > > Cheers, > Guille

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by StÃ©phane Ducasse

Ok so I have the impression that we could get rid of branching or use another delimiter. Would it be ok? Lukas? Dale? Stef On Jan 24, 2011, at 7:06 PM, Dale Henrichs wrote: > On 01/22/2011 12:37 AM, StÃ©phane Ducasse wrote: >> I think that a stupid numbering like the one we have now is not so bad, you do not want to force >> the tools to read all the metadata inside the files. >> I think that we have many more places where we should improve: UI, network layer, Filesystem..... > > I tend to agree, but... > >> >> So with a simple fix in the tools to follow a pattern we can get a good impact. >> So what is the right pattern so that Gofer and Metacello are happy? > > Upon closer examination of the Metacello code, I see that for sorting and comparison operations, Metacello pretty much follows the Gofer sorting scheme (separate methods for wider range of comparison operators)... The departure from Gofer comes in how Metacello matches a package name to a working copy... > > So in the end if you make Gofer happy you make Metacello happy. > > Pharo/Gofer parses the package file name looking for the following pattern" > > packageName, '-', author, '.', branch, '.', counter > > and Squeak/GemStone parses the package file name with this pattern: > > packageName, '-', 'author', '.', counter > > > In Squeak/GemStone, the author is allowed to contain '.' and in Pharo a '.' in the author name causes the characters following the '.' to be interpreted as a branch names and in the sorting scheme for Gofer branches have precedence over the counter....which is why Igor's seeing the "wrong sort order in Gofer". > > In the Squeak/GemStone pattern, branches were indicated by a '.' in the packageName: > > packageName, '.', branch, '-', author, '.', branch, '.', counter > > To see examples just look at the old Seaside package names...Nothing about this ever made it into the code, but when I asked Avi way back when .. that is what he told me and I've been using it for years > > In terms of trying to get Metacello to run on multiple platforms, Pharo naming scheme is a headache, because Squeak/Gemstone allows '.' in author names and Gofer parses them as branch names leading to subtle problems as we've seen > > Personally, I have never seen a package in the wild that uses the Pharo 'branch' naming scheme...I have just seen problems caused by the 'branch' naming scheme. > > The RepositoryInspector itself uses the meta information when it sorts so it doesn't use the package name at all and in Igor's case, CMakeVMMaker-EstebanLorenzano.15 is an ancestor of CMakeVMMaker-Igor.Stasenko.16 and shows CMakeVMMaker-Igor.Stasenko.16 as the latest version, which means that the tools are inconsistent... > > My opinion is that the 'branch' naming scheme just causes problems and isn't in common use so I wouldn't mind seeing it dropped. Without the Pharo-style branch naming scheme a simple-minded sort based on the counter usually matches the actual ancestry... > > With that said I have seen projects with package naming conventions that don't include author names and don't have counters, so the naming schemes for packages is just a mess...without digging in and using the actual ancestry meta information, we are guaranteed to have inconsistencies no matter what we do... > > Dale

Jan. 24, 2011

Re: [Pharo-project] default styler is shout

by StÃ©phane Ducasse

ok we will have to iterate once more time... :) Tx for the report lukas. Stef On Jan 24, 2011, at 5:37 PM, Lukas Renggli wrote: > I mean with the old ParagraphEditor. I am not saying that the old > ParagraphEditor was better (it had lots of other problems), but the > separation between Editor and SmalltalkEditor makes the OB code much > more complicated. > > Also having to send #beStyled is kind of tricky. The previous pull > mechanism with #shoutWantsToBeStyled: was much more useful as the > model of the editor could decide itself how and if it wanted to be > styled. Now the model (or some other new entity inbetween) needs to > know the view and update the editor all the time. > > Lukas > > On 24 January 2011 08:23, Alain Plantec <alain.plantec(a)free.fr> wrote: >> Hi Lukas, >> When you say "previously" do you mean with >> ParagraphEditor or with previous version of >> Editor/TextEditor/SmalltalkEditor ? >> Cheers >> Alain >> >> >> Le 24/01/2011 16:46, Lukas Renggli a Ã©crit : >>> >>> Just as an additional comment (don't know if this is related or not): >>> >>> For OB I had to subclass Editor and duplicate all SmalltalkEditor >>> functionality, because the same Morph instance is used different >>> contexts. Previously it was very easy to enable and disable syntax >>> highlighting and other Smalltalk specific functionality. >>> >>> Lukas >>> >>> On 24 January 2011 00:10, Tudor Girba<tudor.girba(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> I opened a ticket. We should move the discussion there: >>>> http://code.google.com/p/pharo/issues/detail?id=3583 >>>> >>>> Cheers, >>>> Doru >>>> >>>> On 24 Jan 2011, at 08:31, Marcus Denker wrote: >>>> >>>>> On Jan 24, 2011, at 2:19 AM, Guillermo Polito wrote: >>>>> >>>>>> But that imperfect solution won't be a good solution either, since we >>>>>> are not going to have shout styler anywhere :). >>>>>> >>>>> So how is that solved in1.1? We need, for 1.2, just a *usable* >>>>> compromise. Then we can iterate in 1.3 >>>>> >>>>> Marcus >>>>> >>>>> >>>>> -- >>>>> Marcus Denker -- http://www.marcusdenker.de >>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "In a world where everything is moving ever faster, >>>> one might have better chances to win by moving slower." >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 24, 2011