[squeak-dev] Re: Status of Squeak 4.0 relicense: harvesting Pharo relicense

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Status of Squeak 4.0 relicense: harvesting Pharo relicense

Göran Krampe
Hi guys!

(added CC to squeak-dev)

NOTE: This is an adhoc status update about Deltastreams so if you are
not a Squeak coder it is probably not interesting to read.

Last night I registered for ESUG and I intend to spend my spare time
there hacking on DS. Will be fun seeing you Stephane! :)

In my DS hacking I may be removing some of Matthew's stuff that I don't
fully grok - no offense, I think you understand Matthew. We can always
merge stuff back in later. :)

My todo looks like this:

1. Refactor creation of changes in order to more easily hook in Tirade
storage format. I am working on this right now.

2. Hook in Tirade (file format). I am doing this in parallell with #1.

3. Simplify. I am removing some abstract classes, trying to clean out
unused and deprecated things etc.

4. Hack up a UI similar to a dual change sorter for manipulation of
Deltas. I intend to leverage the func that already works - like load and
edit (without applying), apply, unapply and probably a first simple
validation like "perfectly clean" (analysing and verifying that the
Delta applies without any mismatch whatsoever).

This ordering is based on the fact that a good stable storage format is
really needed. Tirade will fit very good I think and Tirade itself is
very portable, readable, flexible and small. After having that I think a
UI similar to a changesorter is important in order to get people
participating.

When we have the above there are tons of other roads:

- The whole "streams" bit, how to feed/find Deltas around the globe.
RSS? Some other scheme?

- More validation levels, this is where it gets really fun. How "smart"
can we be? For example "clean" (instead of perfectly clean) might mean
that the image will end up in the same state, but for example stuff that
the Delta wants to remove was already removed.

- Normalization of Deltas. I started on this earlier, and it is kinda
fun code to write, but while it is a good thing to have (turning a Delta
from a "log" to more like a "Changeset" removing redundancy) it is
probably not a showstopper not having it from the start.

regards, Göran

PS. I will try to make sure I have snapshotted everything later today
and I can update my blog entry on how to get started hacking.


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Status of Squeak 4.0 relicense: harvesting Pharo relicense

Douglas Brebner
Göran Krampe wrote:
> When we have the above there are tons of other roads:
>
> - The whole "streams" bit, how to feed/find Deltas around the globe.
> RSS? Some other scheme?
Maybe Atom format? At least it standard (RFC 4287 &  RFC 5023) and used
for other things like ebook catalogs.
<http://bitworking.org/projects/atom/rfc5023.html>

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Status of Squeak 4.0 relicense: harvesting Pharo relicense

Igor Stasenko
In reply to this post by Göran Krampe
2009/8/15 Göran Krampe <[hidden email]>:

> Hi guys!
>
> (added CC to squeak-dev)
>
> NOTE: This is an adhoc status update about Deltastreams so if you are not a
> Squeak coder it is probably not interesting to read.
>
> Last night I registered for ESUG and I intend to spend my spare time there
> hacking on DS. Will be fun seeing you Stephane! :)
>
This would be cool! I looking forward meeting with you as well :)

I started digging the SystemEditor in order to fix some red tests,
and found that without external help some of them is very hard to fix, because
it requires the deep understanding of some bit & design..
So, it would be nice to see you and discuss it, and i hope i could
help hacking DS while being on ESUG.

> In my DS hacking I may be removing some of Matthew's stuff that I don't
> fully grok - no offense, I think you understand Matthew. We can always merge
> stuff back in later. :)
>
> My todo looks like this:
>
> 1. Refactor creation of changes in order to more easily hook in Tirade
> storage format. I am working on this right now.
>
> 2. Hook in Tirade (file format). I am doing this in parallell with #1.
>
> 3. Simplify. I am removing some abstract classes, trying to clean out unused
> and deprecated things etc.
>
> 4. Hack up a UI similar to a dual change sorter for manipulation of Deltas.
> I intend to leverage the func that already works - like load and edit
> (without applying), apply, unapply and probably a first simple validation
> like "perfectly clean" (analysing and verifying that the Delta applies
> without any mismatch whatsoever).
>
> This ordering is based on the fact that a good stable storage format is
> really needed. Tirade will fit very good I think and Tirade itself is very
> portable, readable, flexible and small. After having that I think a UI
> similar to a changesorter is important in order to get people participating.
>
> When we have the above there are tons of other roads:
>
> - The whole "streams" bit, how to feed/find Deltas around the globe. RSS?
> Some other scheme?
>
> - More validation levels, this is where it gets really fun. How "smart" can
> we be? For example "clean" (instead of perfectly clean) might mean that the
> image will end up in the same state, but for example stuff that the Delta
> wants to remove was already removed.
>
> - Normalization of Deltas. I started on this earlier, and it is kinda fun
> code to write, but while it is a good thing to have (turning a Delta from a
> "log" to more like a "Changeset" removing redundancy) it is probably not a
> showstopper not having it from the start.
>
> regards, Göran
>
> PS. I will try to make sure I have snapshotted everything later today and I
> can update my blog entry on how to get started hacking.
>
>
>



--
Best regards,
Igor Stasenko AKA sig.