VisualGST

Hi,

  As I've said here is the state of VisualGST. First of all sorry for the
delay but I was sick this week.  So what were the regressions in VisualGST.

 1) First Class Category bug:
 Since I've introduced first class class categories, there was a bug (not
really in Visual) which makes me crazy: namespaces store their categories. It
looks simple add a new inst. var in AbstractNamespace.  That was the problem.
Sometimes the variable become randomly *nil* O_o. In fact in the virtual
machine some classe structures are mapped and the bugs come from that aspect.
I've lost a lot of time in debugging trying to find the bug in my code

  2) The implementor/sender bug:
  Another bug that crashes the vm too was in the implementor and sender tools,
sometimes when you select a method it crashes - is it nice? hehe -. In fact
that was a bug in the = in CompiledMethod or something like that (an infinite
recursion loop).

  3) GIT:
  The state of my git branch is simple, I don't work on stable and don't merge
on it and probably won't do it. Instead of merging visualgst in gst, we could
use gst-package --download to update it and download the latest version.

  4) Patch:
  The patch of Paolo is welcome like any patch, frankly speaking I was a bit
frustrated not by the patch but I know that I've spent a lot of time to make a
descent design and code quality (as an humble and alone developer) and I've
worked a lot on it.

  5) Tetris and clock:
  Don't forget the Tetris game and the GtkClock :P. VisualGST.Tetris open or
VisualGST.GtkClock open (you need composite extension)

there is a roadmap that I wrote and Paolo edited at
http://wiki.github.com/MrGwen/gst-visualgst/roadmap we can discuss it here and
decide where to go next.

Cheers,
Gwen

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/13/2010 01:06 PM, Gwenael Casaccio wrote:
>    3) GIT:
>    The state of my git branch is simple, I don't work on stable and don't merge
> on it and probably won't do it. Instead of merging visualgst in gst, we could
> use gst-package --download to update it and download the latest version.

Sorry, I disagree with this.  There's only three ways to ensure that the
GST-bundled VisualGST is stable:

1) provide a stable branch that GST can reliably sync with every now and
then;

2) do all development on topic branches and merge them only when they
are _rock solid_;

3) synchronize stabilization of GST and VisualGST.


You didn't do (3) for 3.2 (and it doesn't make sense, the stabilization
periods of GST is too long).  You don't do (2).  So the stable branch is
the only possibility.

In addition to this, VisualGST up to not-long-ago was still relying on
the very latest infrastructure in GTK+ bindings.  This has stabilized
now but, if we had reasons to start doing that again, it would be really
necessary to provide a stable branch that can work with the GTK+
bindings in the latest released GST.

    (Why? Because we cannot afford again saying "use the git version"
    for 2 years.  The development of GST should focus on getting it in
    all the distributions, including Debian, Fedora, fink, MacPorts.
    Which is totally unfun work, but has to be done).

It's not hard to do.  When you're bugfixing, you bugfix from stable and
merge stable into master.  When your stabilization period is over, you
merge master into stable.  That's it.

>    4) Patch:
>    The patch of Paolo is welcome like any patch, frankly speaking I was a bit
> frustrated not by the patch but I know that I've spent a lot of time to make a
> descent design and code quality (as an humble and alone developer) and I've
> worked a lot on it.

I don't think there's anything to be frustrated about.  Certainly I
didn't write the patch in anger, and none of my remarks were meant to be
criticisms of the design.  Instead, I wanted to overview best practices
for future patches to VisualGST, based on my experience of a few hours.

    Another sidebar: it's hard to understand without seeing the code
    that VisualGST is much more than the browser; everybody can code
    that.

    The difficult part of VisualGST is the code that allows    you to
    implement the browser as _good_ Smalltalk code.  If you think about
    it in MVC terms, GTK+ provides you with the view and a C interface
    to the model.  The Smalltalk wrappers to the models, and especially
    the controller hierarchy, are a big big part of VisualGST, and one
    that you (Gwen) can only be proud of.

It's easy for people to overlook the complexity of VisualGST despite
being "only" 15k lines of code.


Now, if you want to do something else with GNU Smalltalk that's fine.
You put an incredible effort in VisualGST during the Summer of Code and
also afterwards.  I am also glad sometimes that the VM is so stable :-)
that I can do something else, such as hacking on VisualGST or porting
fun stuff from Squeak.  That I can just say "development of 3.3 is not
yet open, and I don't really care about new features".  I wouldn't have
the energy to start working on a JIT compiler for example; heck, I don't
have the energy to fix the one that exists...  (That also is a matter of
real life constraints of course, but that's not relevant now).

However, there was without doubt a communication problem and a
management problem before the release of 3.2.  We should acknoledge that
(both you and me) so that we can cooperate better in the future.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/13/2010 02:28 PM, Gwenaël Casaccio wrote:
But? :-)

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk