July 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Time Profile mostly unusable

by Schwab,Wilhelm K

I was able to write some pretty reasonable tests for gui elements in Dolphin. Getting something to open/close and in between, firing a few commands at it can be informative, sometimes ~:0 ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Thursday, July 21, 2011 3:09 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Time Profile mostly unusable this is mainly a ui concern. On Jul 21, 2011, at 8:58 PM, Igor Stasenko wrote: > On 21 July 2011 20:29, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Thu, Jul 21, 2011 at 6:14 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> it depends on your scenario and when users do not use or use the tool >>> differently you get different feedback. >> >> Or even better: if noboy says anything in the last 6 months while Pharo 1.3 >> was being developed/tested then we cannot do magic. >> I am tired of saying that anything that YOU don't test, can be broken. >> > > why "can be"? it definitely will be broken. > > What would be nice is to write tests for TimeProfileBrowser to prevent > regressions. > Any ideas? > > -- > Best regards, > Igor Stasenko AKA sig. >

July 21, 2011

Re: [Pharo-project] UUIDs not so unique

by Philippe Marschall

On 21.07.2011 21:03, Philippe Marschall wrote: > On 21.07.2011 09:08, Lukas Renggli wrote: >>> Good energy is not going the fix the Seaside repository. >> >> Stop complaining. >> >> Let's build a Gofer script that resaves a series of versions. If we >> load each version from the last correct one and safe each over the >> existing one everything should be fine again. I can help, but I only >> have an iPhone available right now :-) > > Yeah, but we must not load the new versions using Monticello otherwise > they'll be in the ancestry again. We must extract the source.st from the > .mcz file and then file that in. However this will not work for > removed/renamed methods or classes, they'll stay in the image. We could > just unload the package but then we get undeclareds and we'd have to > recompile all dependencies. Also, you have to take care computing the ancestry because of the duplicate UUIDs. I guess for merges you could get away with following just one path. Cheers Philippe

July 21, 2011

Re: [Pharo-project] Time Profile mostly unusable

by StÃ©phane Ducasse

this is mainly a ui concern. On Jul 21, 2011, at 8:58 PM, Igor Stasenko wrote: > On 21 July 2011 20:29, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Thu, Jul 21, 2011 at 6:14 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> it depends on your scenario and when users do not use or use the tool >>> differently you get different feedback. >> >> Or even better: if noboy says anything in the last 6 months while Pharo 1.3 >> was being developed/tested then we cannot do magic. >> I am tired of saying that anything that YOU don't test, can be broken. >> > > why "can be"? it definitely will be broken. > > What would be nice is to write tests for TimeProfileBrowser to prevent > regressions. > Any ideas? > > -- > Best regards, > Igor Stasenko AKA sig. >

July 21, 2011

Re: [Pharo-project] UUIDs not so unique

by Philippe Marschall

On 21.07.2011 09:08, Lukas Renggli wrote: >> Good energy is not going the fix the Seaside repository. > > Stop complaining. > > Let's build a Gofer script that resaves a series of versions. If we > load each version from the last correct one and safe each over the > existing one everything should be fine again. I can help, but I only > have an iPhone available right now :-) Yeah, but we must not load the new versions using Monticello otherwise they'll be in the ancestry again. We must extract the source.st from the .mcz file and then file that in. However this will not work for removed/renamed methods or classes, they'll stay in the image. We could just unload the package but then we get undeclareds and we'd have to recompile all dependencies. Cheers Philippe

July 21, 2011

Re: [Pharo-project] Time Profile mostly unusable

by Igor Stasenko

On 21 July 2011 20:29, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Thu, Jul 21, 2011 at 6:14 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> it depends on your scenario and when users do not use or use the tool >> differently you get different feedback. > > Or even better: if noboy says anything in the last 6 months while Pharo 1.3 > was being developed/tested then we cannot do magic. > I am tired of saying that anything that YOU don't test, can be broken. > why "can be"? it definitely will be broken. What would be nice is to write tests for TimeProfileBrowser to prevent regressions. Any ideas? -- Best regards, Igor Stasenko AKA sig.

July 21, 2011

Re: [Pharo-project] UUIDs not so unique

by StÃ©phane Ducasse

On Jul 21, 2011, at 6:39 PM, Gary Chambers wrote: > Some of us are happy using Pharo (1.4)... new product we are developing. we are always happy to learn new business with pharo :) Gary benjmain started to write a chapter on widgets and we will need some reviews :)

July 21, 2011

Re: [Pharo-project] Time Profile mostly unusable

by Mariano Martinez Peck

On Thu, Jul 21, 2011 at 6:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > it depends on your scenario and when users do not use or use the tool > differently you get different feedback. > Or even better: if noboy says anything in the last 6 months while Pharo 1.3 was being developed/tested then we cannot do magic. I am tired of saying that anything that YOU don't test, can be broken. > > Stef > > On Jul 21, 2011, at 1:48 PM, Hilaire Fernandes wrote: > > > In Pharo 1.3, the new Time Profile is unusable (the one you get from > > profiling the UI): > > > > - In the resulting window clicking in a line cause an error > > - WORST: there is no way (at least obvious one) to copy and past the > > resulting profile in an external file. > > > > When replacing the tools, beware to replace with working ones otherwise > > developers may run away. > > > > I am updating my image to see if it is a temporary problem. > > > > Hilaire > > > > -- > > Education 0.2 -- http://blog.ofset.org/hilaire > > > > > > > -- Mariano http://marianopeck.wordpress.com

July 21, 2011

Re: [Pharo-project] UUIDs not so unique

by Gary Chambers

Some of us are happy using Pharo (1.4)... new product we are developing. Regards, Gary ----- Original Message ----- From: "Philippe Marschall" <philippe.marschall(a)netcetera.ch> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, July 20, 2011 1:42 PM Subject: Re: [Pharo-project] UUIDs not so unique > On 07/20/2011 09:00 AM, Serge Stinckwich wrote: >> On Wed, Jul 20, 2011 at 1:36 PM, Philippe Marschall >> <philippe.marschall(a)netcetera.ch> wrote: >>> On 07/19/2011 09:41 PM, Esteban Lorenzano wrote: >>>> yes... there is a problem in latest vm's and UUID generation (I don't >>>> know if it is present at any vm or just mines, but well...). For the >>>> moment, faster solution is by deactivating uuid primitive, at: >>>> >>>> UUID>>#primMakeUUID >>>> <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> >>>> UUIDGenerator default generateBytes: self forVersion: 4. >>>> >>>> just comment the primitive call. >>> >>> Guys, srsly? Is this some kind of practical joke? You have been shipping >>> with a known bug that has a trivial fix and eats peoples code? You are >>> wondering why nobody takes you seriously and you don't have more users? >>> You teach software engineering? >> >> Hum, you know like in most open-source software project, nothing >> happens by magic, unfortunately. >> Human ressources are very scarce as Pharo is a part-time project for >> most of us. Maybe your problem will required some interactions between >> VM guys and Pharoers. Not something that could be done in 5 minutes. >> >> Did you submit an issue in the bug tracker just to keep track of it ? >> Did you package some patch that could be used more easily by people >> who do the release ? >> >>> This is exactly the kind of shit that makes me want to never again use >>> Pharo in production. This is the reason why I don't recommend Pharo to >>> other people. >> >> If you use Pharo in production did you give money to support the project >> ? >> Pharo is not supported by a company (not yet), so no commitments could >> be done on the speed of the adoption of patches. >> People are just doing their best to enhance the system. And if you >> help them (by packaging patches that solve some problems), everyone >> will win in the long term. > > And that is completely fine. But then you don't have to be surprised > when people don't take you serious, you don't have more users and you > don't have any enterprise penetration. > > To quote from the project page: > "We want Pharo to be the obvious choice for professional development in > an open-source Smalltalk." > > Pro tip: if you want to be the obvious choice for professional > development don't eat peoples code. > > Cheers > Philippe > >

July 21, 2011

Re: [Pharo-project] Time Profile mostly unusable

by StÃ©phane Ducasse

it depends on your scenario and when users do not use or use the tool differently you get different feedback. Stef On Jul 21, 2011, at 1:48 PM, Hilaire Fernandes wrote: > In Pharo 1.3, the new Time Profile is unusable (the one you get from > profiling the UI): > > - In the resulting window clicking in a line cause an error > - WORST: there is no way (at least obvious one) to copy and past the > resulting profile in an external file. > > When replacing the tools, beware to replace with working ones otherwise > developers may run away. > > I am updating my image to see if it is a temporary problem. > > Hilaire > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

July 21, 2011

Re: [Pharo-project] pharo ide task force - morphic issues

by Igor Stasenko

i think it should be put on wiki to prevent get buried in mails. On 21 July 2011 16:04, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Where do you keep this list? > I would like to have inplace edit in list item :) > > > On Jul 21, 2011, at 6:11 AM, Tudor Girba wrote: > >> Hi, >> >> Here is a list of Morphic-related issues that would make the work on the Pharo IDE easier. >> >> Btw, if you want to join this cool task force, all you have to do is announce yourself and I offer to provide tasks :). >> >> >> === Keymappings should work with Morph instances >> - Currently, Keymappings define the keys for all instances of a morph class. This is not useful when we want to create new user interfaces. >> - Nevertheless, it would be great if we could use the same infrastructure both as it is used now for defining image-wise shortcuts and for controlling instance-based mappings >> >> >> === PluggableTextMorph / TextMorph should provide a means to announce the current selection >> - Currently, to get notified of when the selection changed, we need to create three subclasses (see below). This solution does not work well with other >> >> GLMPluggableTextMorph>>textMorphClass >> Â Â Â ^ GLMTextMorphForEditView >> >> GLMTextMorphForEditView>>editorClass >> Â Â Â ^ GLMSmalltalkEditor >> >> GLMSmalltalkEditor>>storeSelectionInParagraph >> Â Â Â super storeSelectionInParagraph. >> Â Â Â self morph ifNotNil: [ >> Â Â Â Â Â Â Â self morph editView >> Â Â Â Â Â Â Â Â Â Â Â announceSelectionFrom: self startIndex >> Â Â Â Â Â Â Â Â Â Â Â to: self stopIndex - 1 ] >> >> >> === The label of a TabMorph should shrink to fit the space >> - Right now a tab with a large title will expand the bounds of the tab. >> - We would need the possibility to limit the size of the title to the size of the contents. Ideally, there should be some abbreviation (with ...) of the title. >> >> >> === MorphTreeMorph should expand the embedded morphs horizontally >> - Currently, a row in the MorphTreeMorph takes the preferred size of the embedded morph. Instead, it should expand the row horizontally to fill the space. Or at least we should have the option to have it like that >> - MorphTreeMorph inherits from ScrollPane. I think it would be great to get it inherit from GeneralScrollPane. Or maybe there is a better solution. >> >> >> === In place editing of items in a list morph >> - It would be great to have the possibility of editing an item in a list morph in place, rather than being forced to open a dialogue >> >> >> === The button icons in Scrollbar and Expander should work with forms defined in UITheme >> - Currently, the buttons from Scrollbar and Expander create the arrow icons by drawing them directly. This does not work well with the other icons in the theme. >> - Instead, the Theme should have a means to provide a form for drawing these >> >> >> === A flexible layout >> - The idea is to offer a mechanism that would enable us to collapse a pane, and have the rest of the panes expand to fill the space >> - There is a start of an implementation, but we need to integrate this deeper. >> - See the thread from: >> http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/040408.ht… >> >> >> === Integrate TWM windows grouping mechanism >> - I know that for it to work, it requires some changesets that need to be filed in. >> - It would be great if they were integrated :) >> - See thread: >> http://lists.gforge.inria.fr/pipermail/pharo-project/2011-June/050116.html >> >> >> >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "The coherence of a trip is given by the clearness of the goal." >> >> >> >> >> > > > -- Best regards, Igor Stasenko AKA sig.

July 21, 2011