- Pharo-dev - lists.pharo.org

Re: [Pharo-project] How do we manage todos?

by Norbert Hartl

On Mon, 2008-09-29 at 10:51 +0200, Marcus Denker wrote: > On 28.09.2008, at 21:40, StÃ©phane Ducasse wrote: > > > I would prefer a bugtraker with a tag todo that are not bug fixes. > > Ok. Then we can split up the one entry that has all the TODOs. > Ok, there are things that are more _to do_ than others? :)) Norbert

Sept. 29, 2008

Installer was: Re: [Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alphauniverse

by Marcus Denker

>> >> So fixes are not integrated into the image anymore and the report >> then >> closed? > When a release image is released the fixes are integrated into the > image > as normal, and can be closed or marked "fixed". > Release image? that means, you will not close *any* bug-report until you release 3.11? Wow. But you sure close at least duplicated bug-reports? > Everything that I have been developing loads into "all" existing > images, > so for example, LPF may want to load fixes into 3.7 if it needs > something. So does this make sense? I think there is not enough manpower to even get *one* stable and *one* development branch going. Beeing backtward compatible to such old releases makes no sense. Especially as 3.7 is very different to 3.9 (just the I18N stuff will kill you). In the end, what you are doing will result in kind of re-doing 3.8 for 3.7, 3.9 for 3.8... and so on, in addition to actually doing 3.11. Is that realistic? > Previously fixes are ONLY available by waiting for the > release team to harvest, or by manually loading a changeset in > yourself. > Now the harvesters can make a fix readily available for everyone > through > Installer. > > This attitude of supporting all users of squeak, while moving things > forward for everyone, is a core-value of the 3.11 team. This is *the* recipe for failure. You can not do anything even remotely complex if any changeset that fixes something in 3.11 needs to work on 3.7, too. > >> What I don't understand with the use of Installer with mantis >> entries: >> From my >> experience from 3.6 to 3.9, there is quite some dependency between >> fixes. > Nothing is automatic, if you or some script loads the wrong fix in the > wrong order then that is a problem. And of course this means that nobody can load any other order, so it makes no sense to have all the fixes as entities on their own at all. >> >> to build "your own release". This just can't work with all the >> dependencies between >> fixes. > However, the old way, fixes are applied to a moving target, since the > alpha image is continuously being updated. Yes, this is very important. As loading a fix for 3.10 into the developement version of 3.11 will almost never work, as other fixes already changed the sytem. This is true even with the installer. So you will end up in using the "moving target" of 3.10+ Intaller as your "HEAD" system that people use when doing changes. Else you will end up in many changesets that have conflicts, and, very annoyting, hundreds of douple-reports of bugs. > With this approach fixes > applied to 3.10 (a fixed target) are used to create a 3.11 unstable > until the combination of fixes is deemed "stable" But this can not work: fixes depend on each other. It is *one of the most important principles* to let the submitter of fixes do the work of merging his fix with the latest fix applied to the image. Else you will die. You can never manage the amount of changes submitted if you can just say: "rejected. reason: conflicts with current version. Please resubmit". Another very important principle is to close reports on the bugtracker as soon as possible to keep it managable. This even means that once a changeset is harvested, the report is closed *and not re-opend* if there is a new bug after applying. That is a *new* report, for a *new* bug (the report then will of course refrence the faulty closed report). Overall, I am 100% sure that your idea how to manage 3.11 is fundamentally wrong (sorry). And Pharo will do it completely differently: release often, integrate as soon as possible, keep the bugtracker down to managable levels and do not be religiously backwards-compatible. We will see at the end what was the better Idea ;-) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by StÃ©phane Ducasse

another point why the down cyan arrow is not a down cyan arrow with a down orange arrow? (may be this is ugly but it would be more consistent). Stef

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by StÃ©phane Ducasse

You know I would really like to see if this is worth pressing the ? So I miss the pane showing the comment under the class def. May be a good way also would be to have the question mark with a different color when there is a comment. David we are starting to use manifesto for package so it would be also great to show them. Stef

Sept. 29, 2008

[Pharo-project] Fwd: Strange bug

by StÃ©phane Ducasse

> > > > Hi > > ImageSegment discoverActiveClasses. > is cool and it lets you (by swapping method dict behind your back) > knowing which classes > have been involved in a certain action. > > as follow > Now ImageSegment discoverActiveClasses. > -- do something typical -- > ImageSegment activeClasses size printString , ' classes were active > out of ' , > Smalltalk allClasses size printString. > > Now if following > recoverFromMDFaultWithTrace > > you put > > Smalltalk at: #MDFaultDict put: Dictionary new. > > you get a strange error, tell you that there is syntax error > > Stef > > >

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Lukas Renggli

> > One quick suggestion: classes without a comment need to have an icon, and > really really ugly one, for obvious reason: to get rid of it by writing a > comment ASAP :) > > Indeed, this is something we should add. The reason to not add it so far > was that almost every class would get this icon in most packages. ;) > But we will prepare an icon for it. Please don't add such an icon. This is the most horrible thing in VisualWorks, I always disable it as a first action. There will always be tons of classes in the system that have not been commented and that you don't want to comment, because this is not your library. Nothing will change that. Adding another icon there will just add a horrible noise and is totally orthogonal to the kind-icon that classes already have. Again (as I did for the method icons) I vote not to mix different concerns in a single icon. If really needed, add an exclamation mark to the question mark button for example. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Damien Cassou

On Mon, Sep 29, 2008 at 3:31 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > In that case, how can I load OB? ScriptLoader new universalInstaller universe install: 'OB-Enhancements' If it does not install the very latest version, it's because David does not think it is ready yet. You can still update using monticello if you want. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Alexandre Bergel

> Hi Alex. You should stop doing that manually. I already maintain the > universe version. Please update your method to look like > ScriptLoader>>installingRB. Moreover, future pharo releases will > contain OB. Excellent! In that case, how can I load OB? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by Damien Cassou

On Mon, Sep 29, 2008 at 2:25 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > I made a new version of Scriptloader that reflect the new version of OB Hi Alex. You should stop doing that manually. I already maintain the universe version. Please update your method to look like ScriptLoader>>installingRB. Moreover, future pharo releases will contain OB. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 29, 2008

Re: [Pharo-project] OB's icon support improved

by David RÃ¶thlisberger

Hi Janko, > One quick suggestion: classes without a comment need to have an icon, > and really really ugly one, for obvious reason: to get rid of it by > writing a comment ASAP :) Indeed, this is something we should add. The reason to not add it so far was that almost every class would get this icon in most packages. ;) But we will prepare an icon for it. David > David RÃ¶thlisberger wrote: >> Hi there, >> >> taking the suggestions from the "On icons" thread, I have now changed >> and extended >> the icons in columns like this: >> >> - Removed icons for extension methods ('+'), instead use italic font >> for the method >> name label if it's a extension method and additionally red color if >> it's an override >> (as Lukas suggested) >> >> - Use new icons for abstract method and super send (credits to Stef >> who did the hard >> work of drawing them). >> The new icons make clear whether an abstract method or a method >> sending super is >> redefined in subclasses or not (they get an additional triangle >> pointing down if they >> are redefined). >> For a complete list of supported icons see: >> http://smallwiki.unibe.ch/hermion/icons/ >> There are still some icons missing for rare situations, if someone >> volunteers to draw >> them, we'd be happy. ;) >> >> - Explaining labels for all icons (keep the mouse over them) >> >> - Most icons are clickable: Clicking on a super send icon brings you >> to the method in >> the superclass, clicking on a triangle down icon brings you to the >> overridding method >> in the subclass or gives you a list of candidates if there are several >> sub-implementations. >> This I consider as a very convenient extension. >> >> - Classes or Traits can implement the method #browserIcon (answering a >> symbol for the >> icon name) to define the icon they will get in the class column >> themselves >> >> >> If you have more suggestions or wishes concerning icons (or anything >> else), let me know. >> Current ideas include to introduce icons for trait classes and methods >> (trait methods >> are shown in italic right now, hence somehow conflicting with >> extension methods), or >> to have an icon for methods without any additional implementor. >> I would be interested to know whether you consider these ideas as >> valuable. >> >> >> To load the latest version of OB, you can use this Installer script: >> >> >> Installer wiresong >> project: 'ob'; >> install: 'OmniBrowser-dr.419'; >> install: 'OB-Standard-dr.355'; >> install: 'OB-Morphic-dr.57'; >> install: 'OB-Enhancements-dr.217'. >> >> >> Cheers, >> David > >

Sept. 29, 2008