[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] Future of managing sourcecode in GST

From: Holger Hans Peter Freyther
Subject: [Help-smalltalk] Future of managing sourcecode in GST
Date: Sat, 12 Jan 2013 19:08:31 +0100
User-agent: Mutt/1.5.21 (2010-09-15)


for my work I normally port packages that target Pharo to GNU Smalltalk.
We have fixed some bugs in the gst-convert utility, we have built some
knowledge on common rules but porting and merging is a manual task right

Now Monticello(?) has gained support to use GIT as a target for the package.
While it is great the downside is that each class is a directory and each
selector is a file. An example of such a package is here[1]. I wonder how
we can make the best use of it?

There are several things I would like to discuss that result in tools and
the documentation of best practises for porting.

* Download the latest package from squeaksource/smalltalkhub by hand.
* Create a new git repository...
* Copy the .mcz:snapshot/ to sources.pharo
* Use gst-convert to convert the code to GST (always forgetting that
  gst2 is smaller than in gst in version, I should add a gst3 alias)
* Create a package.xml and run gst-package --test.package
* Fix parse issues, fix the STInST parser..
* Fix the .st by hand or use gst-convert with more rules.

* Take all or just the last version...
* Convert again.. look at it with.. not much 'incremental' work.

Issues with it:
* Done by hand..
* Having to remember/find the rewrite rules all the time
* Incremental updates are difficult

* I would like to have an automatic process. Most packages should be
  portable with not much work, we should have tools that also ease the
  upgrading. This would mean to have a 'PharoExtensions' package and this
  should come with conversion rules.

How to move forward?
* Implement/Port Metacello.. and build diffs by hand and then use the
* Help building small scripts. Checking in in a Pharo branch
  and creating tags.. and then merging/copying this into a GST branch?
  Write scripts that 'sort' code to make diffs as small as possible?
* Or start using git as in monticello/metacello here? Then we would just
  modify the code in the single files, create some new packages? We could
  build a special package.xml that knows how to collect the files from
  such a package directory. The biggest concern is that I would not like
  creating a new selector by creating a new file by hand? So maybe we can
  have scripts that assemble and split the code?

ideas? comments? volunteers?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]