Roadmap for GST and VisualGST

Hi,

this is to kick off a discussion on roadmap for GST 3.3 and beyond. In
general I would like to aim for time based releases. This way a constant
amount of bugfixes go into it and users benefit from it.


== Website ==
* Migrate to a newer version.


== Ports ==
* Update ports (newer Seaside, newer Magritte, etc.)?
* Create another repository/index with ports and provide a way to
  track upstream of them. The porting should be automatic with travis-ci/
  hydra so we find out when new (stable?) versions break.
* Make it more easy to import from Monticello/Metacello systems.


== Kernel ==
* Integrate Announcements more closely into behavior? Right now we need
  to provide alternative Behavior implementations. The notifications hooks
  should be in the kernel, announcements probably not.
* Create a Pragma class.. look into supporting traits?


== VM-Work ==
* Check if we can re-enable the JIT for certain things (e.g. calling
  primitives)
* Introduce an embedded profile that starts with a smaller memory footprint
* OSProcess handling in the core (with sigchld handling)


== Tooling ==
* I want to make VisualGST usable.. and there are multiple things
* Make it possible to have VisualGST operate on a remote GST image.
* Make VisualGST a set of independent utilities. The main window should
  help to close/connect an image and create new tools.


=== Browser ===
* Get rid of the treeview. It somehow does not work. Either start browsing
  by package.. or by flat namespace or by categories.. from a list
* Create a column view?

=== Debugger ===
* Deal with the debugger having exceptions.. do not recursively create
  new debuggers..
* Keyboard shortcuts...
* Apply fit-laws and put text on the buttons..
* Fix debugging/inspection of block closures.

=== FileOut ===
* With the new dir package I would like to have a Package fileOut which
  writes out modifications to the existing files. E.g. 'edit' them in place.
* Keep track of where a subclass comes from.. load the lines to RAM.. and
  then replace them at the right place. This way the order and formatting
  could be left as it was.

=== Changes ===
* Keep a Journal and create nice UI to replay them. Also remember the
  source of the operation (e.g. Object subclass: #Bla in a workspace should
  be tracked differently to the one done in VisualGST).

=== Unit Testing ===
* Make SUnit testing more easy.


== Packages ==

=== Star ====
* Make it more easy to create TestSuites. Instead of giving testcases to
  the package.xml let it use TestCase allSubclasses.. E.g. a class should
  also belong to a package.


holger

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

On Mon, Mar 25, 2013 at 04:06:15PM +0100, Holger Hans Peter Freyther wrote:
I think I have concluded on how we could do these things nicely. GST-Changes
or such would create one git-repository per package[1] and use the FileTree/
Cypres format[2] in it.

Modifications to Classes.. would result in file operations in the package
in the package (git add, git rm, git mv). We would also have the option to
make a snapshot (un-named auto-commit), commit (some real work done).

Then we could and should have tools (like gst-convert) to convert from file
tree to another form of fileout and we could have the more clever fileout
I was hoping for (to replace the text in place).

comments? ideas?

        holger



[1] This might mean we need a way to go from CompiledMethod to package or
use heuristic based on the category name and available packages.

[2] A class is a directory, selectors are files, properties for
namespace and instance variables. https://github.com/CampSmalltalk/Cypress

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