OmniBrowser 2.0
Colin Putney
Lately there's been a few complaints about OmniBrowser, ranging from
walkbacks to performance. I think a big part of the problem is that
"OmniBrowser" is ill-defined. There hasn't been an official release in
several years, even though development has been going pretty strong
for most of that time.
To remedy this, I've been working on putting together a new OB
release, along with a new release process similar to the one I've been
using for Monticello 2.0. I've attached the first release of the 2.0
series, and I'd like to get feedback before making a wider announcement.
One of the most important things I've been doing, from a release
perspective, is getting the tests working again. We don't seem to have
been running them very much because a lot of them were broken by
changes in the production code. The tests are crucial to keep OB
running correctly on all the different platforms we support. This
version still doesn't pass 100% of the tests, but I think all the
trivial failures have been fixed, and what remains are actual bugs.
This version is also missing a lot of the work that David has
contributed recently, along with some of the work done by the Pharo
folks. I've tried to establish a baseline version that retains the
best mix of performance, simplicity and features that I could find.
I'd love to hear proposals for back-porting key features from the
Pharo/dev-image branch, so we can unify the codebase.
Colin
Damien Cassou
On Mon, Aug 3, 2009 at 7:27 PM, Colin Putney<cpu...@wiresong.ca> wrote:
> This version is also missing a lot of the work that David has
> contributed recently, along with some of the work done by the Pharo
> folks. I've tried to establish a baseline version that retains the
> best mix of performance, simplicity and features that I could find.
> I'd love to hear proposals for back-porting key features from the
> Pharo/dev-image branch, so we can unify the codebase.
Is there any difference between what is in the zip file and what is in
the mczs at wiresong.ca?
02-OB-Morphic.st can't be loaded because it depends on OBClassNode
from 03-OB-Standard.st.
About the features to backport or not:
I don't think having a Monticello package view is a good thing for
now. Let Squeak/Pharo have a proper implementation and remove
categories before changing the browser.
However, what I miss is the dual view category/hierarchy with a modal
filter ala Visual Works. It is extremely convenient when it works
well.
Trait browsing is a must have in a trait-based image.
Thank you for working on OB again.
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry
stephane ducasse
This is good. Having regular release is the way to go.
I know that david spent a lot of time and that he got also
problems (not clear to me) such as how to have dynamic node.
After and during the bern pharo sprint, he started to clean his code
(removing the isKindOf:....)
because this is important to get OB and his extension fast.
And OB enh were ugly and dog slow. (I'm working --too slowly-- on a
real package object)
So my biggest hope is that david will be able to clean/fix and
interact with you for his needs.
For me, I cannot work without the trait browser and decent package
support. Now david is cleaning
and he simplifies the package browser which was too complex/clunky and
sometimes bugged
but we need a VW like package view supporting class extensions and
other features.
One question: Did you change the registration mechanism for the
browser so that their name
in the UI is not their class? Because from a user interface it is not
so good.
Another question: how will you continue to work on OB?
Stef
Lukas Renggli
02-OB-Morphic.st depends on OBClassNode, OBMethodNode,
OBClassCategoryNode, OBMethodVersionNode and OBMethodCategoryNode.
07-VB-Regex.st should not be loaded into Pharo images, it is already
part of the core. Maybe a note in the readme.txt would be appropriate.
Other than that the browser works nicely in the latest Pharo image.
Loading is cumbersome and updating is not really possible though. Many
people have load script
(http://code.google.com/p/pharo/wiki/ImageBuildScripts). I also use
this script to update to the latest version, that doesn't seem to be
easily possible with the new distribution mechanism. Also I don't see
how to commit changes and where to load the tests from.
Cheers,
Lukas
2009/8/4 stephane ducasse <stephane...@gmail.com>:
Lukas Renggli
http://www.lukas-renggli.ch
Colin Putney
On 4-Aug-09, at 7:02 AM, stephane ducasse wrote:
> One question: Did you change the registration mechanism for the
> browser so that their name
> in the UI is not their class? Because from a user interface it is not
> so good.
Yeah, it' certainly ugly. Unfortunately the fix for that has to be
applied to the base image, not OmniBrowser. Squeak seems to be
accepting contributions again, so I'll make that fix in the Squeak
trunk. What should I do for Pharo?
> Another question: how will you continue to work on OB?
Um... not sure what you're asking here.
I'm not sure how much primary development I'll be able to do on
OmniBrowser, but I do intend to be an active maintainer at the very
least. In particular, I want to get the new release process and
distribution mechanisms working smoothly with all the platforms that
OB runs on. This includes not only Squeak and Pharo, but Gemstone and
maybe other Smalltalks as well.
As for the actual mechanics of development, I've done some work on a
build system which I'm using to prepare development images, build the
release zip, automatically run tests etc. It's not quite ready for
release yet, but it will be soon. I think it will make it easier to
keep the code-quality and performance of OB high, despite all the
different configurations and environments we have to support.
Does that answer your question?
Colin
stephane ducasse
On Aug 8, 2009, at 8:24 AM, Colin Putney wrote:
>
>
> On 4-Aug-09, at 7:02 AM, stephane ducasse wrote:
>
>> One question: Did you change the registration mechanism for the
>> browser so that their name
>> in the UI is not their class? Because from a user interface it is not
>> so good.
>
> Yeah, it' certainly ugly. Unfortunately the fix for that has to be
> applied to the base image, not OmniBrowser. Squeak seems to be
> accepting contributions again, so I'll make that fix in the Squeak
> trunk. What should I do for Pharo?
Could you can sign the agreement and send it to me?
All sensible changes will be nearly immediately integrated :)
>
>> Another question: how will you continue to work on OB?
>
> Um... not sure what you're asking here.
I mean do you plan to check what contributors are doing?
Integrating bug fixes?
> I'm not sure how much primary development I'll be able to do on
> OmniBrowser, but I do intend to be an active maintainer at the very
> least.
> In particular, I want to get the new release process and
> distribution mechanisms working smoothly with all the platforms that
> OB runs on. This includes not only Squeak and Pharo, but Gemstone and
> maybe other Smalltalks as well.
> As for the actual mechanics of development, I've done some work on a
> build system which I'm using to prepare development images, build the
> release zip, automatically run tests etc. It's not quite ready for
> release yet, but it will be soon.
We would like to improve the basic testserver basic develop by adrian
to slowly get a usable version.
> I think it will make it easier to
> keep the code-quality and performance of OB high, despite all the
> different configurations and environments we have to support.
>
> Does that answer your question?
>
> Colin
>
> >