[squeak-dev] Trunk now Toolbuilderized ;-)

Folks -

Just as an FYI, I did a serious pass on toolbuildering (or would that be
toolbuilderizing? ;-) the Tools package in the trunk. In the process
I've removed some tons of stuff from the Tools package referencing half
of MVC and Morphic and replaced them with using ToolBuilder specs
consistently.

Since that was a sizable change there is a chance for some fallout and
I'd appreciate feedback if you find something that got broken in the
process. One difference I'm aware about is that I (temporarily) removed
the "always visible comment pane" in the browser. I just haven't figured
out how to deal with it using ToolBuilder - if anyone has an idea I'm
all ears. Everything else should work, including Inspector, Debugger,
PackagePaneBrowser, etc.

The good news is that this is both, progress towards unloading MVC as
well as making some tools available to MVC which previously were either
not at all or only partially available. So all in all, I consider it a
good trade.

Cheers,
   - Andreas

Hi Andreas,

Andreas Raab wrote:
Great!

I guess I found a bug. The #annotationPanes preference is not honored
anymore.

Cheers,
Juan Vuletich

Cannot open Workspace, log is attached. 

Vaidotas Didžbalis wrote:
> Cannot open Workspace, log is attached.

Oops, sorry. I had committed the fix into the inbox instead of the trunk
(caused by some issues we had with source.squeak.org). It's now available.

Sorry for the inconvenience.

Cheers,
   - Andreas

--
http://gulik.pbwiki.com/

On Sat, Aug 08, 2009 at 12:46:34AM -0700, Andreas Raab wrote:
I have not been able to update my trunk image since this change. I'm getting
a locked up user interface (unresponsive, display does not refresh, Squeak
still busy and using CPU). I can see one or more debuggers being opened, and
pointing to MNUs in GrafPort (one was GrafPort>>seco??? where the ??? is
part of the method name that I cannot read). I cannot open a debugger to
see more.

The failure is happening in the update for Morphic-ar.150(jmv.138).mcd.
I am running a Unix VM under Linux.

I was assuming that I have been doing something dumb (the usual explanation)
but I'm beginning to suspect that it may be due to a platform issue. When
running under X window (a KDE window manager in this case), there are lots
of times when Squeak receives notification from the window manager that it
should refresh its display. My guess is that a display update is being
performed at some point during the update process when Squeak is not able
to actually perform the update.

Any tips?

Dave

David T. Lewis wrote:
> I was assuming that I have been doing something dumb (the usual explanation)
> but I'm beginning to suspect that it may be due to a platform issue. When
> running under X window (a KDE window manager in this case), there are lots
> of times when Squeak receives notification from the window manager that it
> should refresh its display. My guess is that a display update is being
> performed at some point during the update process when Squeak is not able
> to actually perform the update.
>
> Any tips?

Try the "standard" tricks:
* Close all open transcripts
* Destroy all shared flaps
* Close all other windows.

My best bet would be a transcript since loading may print something to
the transcript and if that happens to happen while the text changes are
loaded, I could see how something goes wrong here.

Cheers,
   - Andreas

Michael van der Gulik wrote:
> Did you use anything from the PlusTools package?
>
> http://www.squeaksource.com/PlusTools/

Wow. No, I didn't know someone had salvaged those (I thought they were
lost for good). I'll check to see if there's anything worth moving forth
or back.

BTW, is any of your work at a point where it might be interesting to a
larger audience?

Cheers,
   - Andreas

On Sun, Aug 09, 2009 at 08:59:01AM -0700, Andreas Raab wrote:
Thanks, I'll give that a try. I did have a transcript open. Right now
I'm running an update in a headless image to see if that gets me around
the problem.

Dave

On Sun, Aug 09, 2009 at 08:59:01AM -0700, Andreas Raab wrote:
Yes, closing the transcript resolved the problem. Evidently the original
hypothesis (me doing something dumb again) was correct. Thanks!

BTW, the new fonts are very nice. I wasn't sure I liked the look at
first but I have quickly gotten accustomed to it, and the overall look
is very good.

Dave

In the current trunk image, World menu -> open -> method finder gives a window containing a single text pane. Is this
related to the toolbuilder changes ?

Also, would you prefer to see this report on-list or in mantis ? I thought mantis was still a mandatory part of our
process, but today I'm hearing not. If it's optional, I might start reporting quick issues to the list using the
debugger's great mail out bug report feature.

On 13.08.2009, at 21:57, Simon Michael wrote:

> In the current trunk image, World menu -> open -> method finder  
> gives a window containing a single text pane. Is this related to the  
> toolbuilder changes ?
>
> Also, would you prefer to see this report on-list or in mantis ? I  
> thought mantis was still a mandatory part of our process, but today  
> I'm hearing not. If it's optional, I might start reporting quick  
> issues to the list using the debugger's great mail out bug report  
> feature.

I guess you misunderstood. Mantis is still where to report bugs.

But if a core developer notices a small bug and can fix it right away,  
he can just do so. Formerly, he would have to open a Mantis bug and  
attach a changeset. Now he can simply commit the fix to the trunk.

- Bert -

Bert Freudenberg wrote:
> On 13.08.2009, at 21:57, Simon Michael wrote:
>> Also, would you prefer to see this report on-list or in mantis ? I
>> thought mantis was still a mandatory part of our process, but today
>> I'm hearing not. If it's optional, I might start reporting quick
>> issues to the list using the debugger's great mail out bug report
>> feature.
>
> I guess you misunderstood. Mantis is still where to report bugs.

Yes, but ... I also consider reporting issues here a good idea. Many
Mantis issues get overlooked because you actively have to search for
them to get notified. So if there's an issue it's a good idea to report
it here *and* file a Mantis report, along the lines of: I found bug x or
y, here is how to recreate it. I've filed Mantis #xxxx to track it.

In other words, mentioning bugs here is good for awareness. Putting them
on Mantis is good for tracking them and ensure they get resolved.

Cheers,
   - Andreas

As another tool for bug awareness, I'm experimenting with announcing new issues in irc.
See squeakbugsbot, currently under test in #squeak-in-depth on freenode.net.

Also under test in this channel are:

squeaklandbugsbot - announces etoys bugs, hopefully
squeaksrccombot - announces squeaksource.com updates
squeaksrcorgbot - announces source.squeak.org updates
squeakplanetbot - announces new blog posts appearing on planet.squeak.org

Oh, and under test in #squeak since this morning there is

sosqueakbot - announce stackoverflow.com questions with the squeak tag
sosmalltalkbot - ditto for the smalltalk tag

FYI the bots announcing code updates show only a few items at a time, the next batch will appear five minutes later.

Bert Freudenberg wrote: Actually, last I saw from a board member on irc is that mantis is on its
way out. Logical considering that we just got the technical side of the
process of using mantis to manage fixes working. How about we invest in
actually organising people to use mantis properly.
> I guess you misunderstood. Mantis is still where to report bugs.
>
> But if a core developer notices a small bug and can fix it right away,
> he can just do so. Formerly, he would have to open a Mantis bug and
> attach a changeset.
Exactly this should be mandatory, otherwise you have no idea what has
been fixed and what hasn't. I understand you are insisting on running
this thing without any management, but we are a community with about 5
active forks management is needed.  Not everyone can afford to track
trunk, I know I cant, I already have 5 open images at any one time.

I have actual production images, you are imposing a process upon me
which is untenable. First I have to wait for the next release, which
will be more than a year because you haven't got a continuous release
early and often process in place. Second I have to wait for every
package that I use to be ported by their maintainers, which is about 20
packages. Then I have to port all of my own stuff, and then I get to use
the final result, which has the fix I wanted in the first place. So just
to obtain one fix I am looking at perhaps 18 months cycle time, and that
is being optimistic.
> Now he can simply
Please define simply - consider what an average squeak user has to do
differently now as compared to the original situation.

So to submit a fix, I now have to load the image, update to trunk
latest, perform the fix again, retest because someone else might have
already refactored that code, commit the fix to the repo. Before all I
needed was a little changeset generated from my own working image. This
is not easier for the average squeak user working in their own images,
now they have to track trunk all the time as well.
> commit the fix to the trunk
Which is a bad idea, because then the whole existing community misses
out on the chance to adopt that fix, and it slips into the release
undocumented and unnoticed. Then when the same bug is reported in
cobalt, pharo, 3.8  etc, the same work is repeated over again. If the
fix is available on mantis, then it is documented and any release which
includes the fix can generate its "fixed bugs" documentation automatically.

Other forks of squeak can browse the list of documented fixes and pick
out any that they might also like to adopt, and when they do they can
generate their documentation automatically.

>From the community that invented extreme programming this is embarrassing

Keith

*Please* change the subject line if you change the topic of a thread.  
Thanks.

On 14.08.2009, at 04:01, Keith Hodges wrote:

Firstly, Board members are free to speak their mind. We usually make  
it clear in writing when something is a decision by the Board.

Secondly, Ken stated that "Mantis is falling out of favor", which  
seems an accurate description of how our community uses the bug  
tracker. Wish it was different, but it somehow is at odds with the way  
this community works.

(I should also point out that IRC is a second-grade medium in our  
community. So it's good you bring that to the attention of the mailing  
list. I think the discussion you refer to starts at 09:29:02 here: http://tunes.org/~nef/logs/squeak/09.08.13 
  )

> Logical considering that we just got the technical side of the
> process of using mantis to manage fixes working. How about we invest  
> in
> actually organising people to use mantis properly.

Good idea. Try to convince people. We tried. As Ken wrote on IRC, "I'm  
tired of fighting this issue after several years now".

>> I guess you misunderstood. Mantis is still where to report bugs.
>>
>> But if a core developer notices a small bug and can fix it right  
>> away,
>> he can just do so. Formerly, he would have to open a Mantis bug and
>> attach a changeset.
> Exactly this should be mandatory

This is a valid proposal. Who does support it? Who is against?

Nothing is set in stone, ideas for better processes are always  
welcome. So far the trunk is still an experiment, we'll see how it goes.

>> Now he can simply
> Please define simply - consider what an average squeak user has to do
> differently now as compared to the original situation.

Core developer:
1. Fix bug.
2. Commit changed package to trunk.

Non-core developer:

1. Fix bug.
2. Commit changed package to inbox.
3. Open Mantis report.

This assumes users are using the trunk image. If not, you can still  
attach changesets to mantis, so it's about the same as before.

> Before all I needed was a little changeset generated from my own  
> working image.

How about a poll: Who actually uses changesets for daily development?

I have the impression that use of Monticello has overtaken changesets  
by far. Many newer developers are not comfortable with changesets at  
all. Making a changeset from a MC package is still not trivial.

> Other forks of squeak can browse the list of documented fixes and pick
> out any that they might also like to adopt, and when they do they can
> generate their documentation automatically.
>>

We need to produce this list for a release, indeed. But why not from  
trunk commit logs?

> From the community that invented extreme programming this is  
> embarrassing


Actually, Squeak development in the last two years felt glacial. I  
have the impression that people like the trunk model because it is way  
more agile, not less.

Many people like Squeak because it allows them to be way more  
productive than in any other tool. So the processes that best fit that  
mind-set do not require external tools. This is what made the old  
update stream attractive - you prepared a changeset and submitted it  
without ever having to switch away from Squeak. And this is what makes  
the trunk attractive.

The idea of relying on external tools, web sites, shell scripts etc.  
is only slowly catching on, if at all. This is the unixy open-source  
way, true, but just look at the sorrow state of Squeak packages in the  
major distributions. Not too many community members come from that  
background. This is what I suspect is the reason this mindset not more  
widely supported here.

- Bert -

Simon Michael wrote:
Are these written with Francois Stephany's Bonobot? Do you have any
comments on things, like suggestions for improvements?

frank

Bert Freudenberg wrote:
Ken certainly has been at the forefront of pushing Mantis. Remember when
we moved from BFAV and Ken lead the Janitors (I think I remember the
name correctly?) team, patiently moving bugs posted to squeak-dev onto
Mantis?

>> Logical considering that we just got the technical side of the
>> process of using mantis to manage fixes working. How about we invest in
>> actually organising people to use mantis properly.
>
> Good idea. Try to convince people. We tried. As Ken wrote on IRC, "I'm
> tired of fighting this issue after several years now".
 >
>>> I guess you misunderstood. Mantis is still where to report bugs.
>>>
>>> But if a core developer notices a small bug and can fix it right away,
>>> he can just do so. Formerly, he would have to open a Mantis bug and
>>> attach a changeset.
>> Exactly this should be mandatory
>
> This is a valid proposal. Who does support it? Who is against?

I'd vote for mandatory reporting. Speaking for myself, bug tracking (and
Mantis in particular, for all its warts) is simply invaluable.

I'm not necessarily in favour of the particular _process_ Keith mentions
here: I can see people simply wanting to fix the bug rather than open up
a browser, go to Mantis, fill out the form, etc. Bert, you suggest this
later on: that people like to work in Squeak.

Perhaps we can write tools (regrettably I'm not volunteering here) that
could easily allow a developer to report a bug. Behind the scenes this
little screen does all the right magic with Mantis, while presenting a
very simple "what's the bugfix for?" kind of screen.

frank

On 14.08.2009, at 11:16, Frank Shearar wrote:

So if I notice a typo that was introduced yesterday, I'd not only fix  
it, but also I'd have to open a bug report and immediately resolve it?  
Just making sure I understand.

- Bert -