Ya, in fact when traits (If I recall correctly) were first introduced I started getting complains about the JPEG primitive decoder failing. Turns out it uses the "known" order of instance variables to read data into C variables so it can do calculations. Earlier versions of Traits, changed the order, that would break the math and decisions in the decoder primitive, so it would fail.

Of course everything in the smalltalk walkback looked fine...

On Aug 20, 2007, at 10:29 PM, Craig Latta wrote:

Hi Göran--

...

...do we care about changing the ORDER of say instvars?

 I think we should, if we are to support direct installation of  

compiled methods (without recompiling from source code), since methods use instructions that refer to the receiver's instance variables explicitly by field index.

-C

-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

Hi!

Hi, goran@krampe.se wrote in message news:20070821010142.44AC5EF5E0@mail.krampe.se...

...

Hi all!

Ok, managed to get some more code written tonight - but I am still on a low level here - matching up with ChangeSet etc. But if anyone wants to join in:

See details here: http://wiki.squeak.org/squeak/6001

The first goal is to make DSDelta work as a "true log" capturing all changes in full detail.

One question for you gurus out there - do we care about changing the ORDER of say instvars?

yes,the order can be important. A concrete example...

[SNIP]

Ok, someone said something similar - perhaps it was you (on IRC) :) Sigh, well, then I will just have to add one more Change class then that captures any change in relative order between the ivars that are not added nor removed.

So "a b c" -> "a c" would only generate a removeIvar Change and not a orderIvar Change since c still follows after a.

And "a b c d" -> "c a e b f" would generate 3 changes:

1 addIvarsChange adding e and f. 1 orderIvarsChange reordering "a b c" to "c a b" (relatively) 1 removeIvarsChange removing d.

Sounds fair?

regards, Göran

regards, Göran

Hi!

Hi Göran,

I refer to your proposed Delta File Format, with your remarks Human readable? encoding , (utf8? BOM or no BOM?) (put encoding in header?) and the Method Source preamble.

Note that I didn't write the lower part of the Swiki page. :) Not sure who did. But I kept it anyway.

[SNIP]

It looks a bit wordy but, what do you think?

Well, honestly I don't like XML much. :)

But either we pick ONE single format (for simplicity) and then I am leaning towards a simple chunk format very much like previous formats (.st .cs). You know - KISS.

...or we allow multiple formats from the start and then an XML format is of course a useful one to have for some people (I guess). Definitely for cross-Smalltalk use.

Since I can't do all work I will focus on the simple chunk-format but will take into account that the system may have multiple "parsers" to use when reading/writing Deltas. Thus we can add more formats as we go. If you are interested in helping with an XML-format, that would be nice! :)

Note though that file formats are still way off - my current goal is to make a DSDelta be able to "record" all kinds of Changes in a correct way using SystemNotifier, I am almost there.

Next goal is probably to implement #apply and #revert using SystemEditor.

After that we might be looking at external read/write. :)

regards, Göran

Göran Krampe wrote:

...

It looks a bit wordy but, what do you think?

Well, honestly I don't like XML much. :)

But either we pick ONE single format (for simplicity) and then I am leaning towards a simple chunk format very much like previous formats (.st .cs). You know - KISS.

XML is not necessarily a bad option for this goal. We have an XML parser that works very well, is relatively small and fast and allows for all but the most esoteric stuff. Chunks are okay but the disadvantage with them is that they are context-sensitive and that a parser can therefore not ignore something it doesn't understand which makes extensibility a brittle thing. A good example is that a 3.8 file contents browser will be unable to correctly parse fileOuts created from 3.9 - that's because it expects to find a class definition being made up of a particular number of tokens and that number of tokens has changed in 3.9 (which is impossible to tell without some sort of meta information). However, if that problem had been addressed by another (context-sensitive) chunk it would probably have exploded the FCB altogether ;-)

Since I can't do all work I will focus on the simple chunk-format but will take into account that the system may have multiple "parsers" to use when reading/writing Deltas. Thus we can add more formats as we go. If you are interested in helping with an XML-format, that would be nice! :)

I'll check it out. Unfortunately, I'm completely swamped with work right now.

Cheers, - Andreas

Thank you Michael for your 2c's :)

The format you suggested is so easy to translate into the XML-format that I had in mind, just by supplying an appropriate self (calls for a traits implementation ;-). Even the text body with its indentations and whitespace is taken care of.

Of course the other direction (XML to your 2c's) is a bit more complicated but doesn't look undoable.

Thanks again, will keep in mind you have a library for such things :)

/Klaus

On Thu, 23 Aug 2007 15:30:06 +0200, Michael wrote:

Klaus D. Witzel wrote:

...

Hi Göran,

I refer to your proposed Delta File Format, with your remarks Human readable? encoding , (utf8? BOM or no BOM?) (put encoding in header?) and the Method Source preamble.

Can I suggest to consider a small XML-parseable format, which is so flat that it is easy to parse by just the two methods #upTo: and #scanTokens: (perhaps assisted by #replaceAll: $" with: $' and #utf8ToIso).

This way Deltas could perfectly be used in other markedup docs, for example with xhtml. Also transport (http+friends) and transfer encoding can be handled by existing (hope so :) protocols. It would look like

VisualWorks has an XML file out format that is the default. It has brought the product no discernable advantage except that it is aware of packages, properties etc that were never added to the standard bang fileout format (which was an oversight by someone at some point in the past).

At one point there was some fevered excitement over the idea of presenting smalltalk xml fileouts using XSLT to make XHTML.. but at the end of the day, the outcome was hardly spectacular - you could generate something far more interesting directly from the image and make it interactive with seaside, for example.

As to human readable - well.. let's just say XML leaves a lot to be desired there :) I'd much rather see pure message sends going on here, eg:

self encoding: #utf8. self class: 'SuperDeltaObject' superclass: 'Object' do: [ self instanceVariables: #(a b c). self comment: 'uhm, what class comment ;-)'. self method: 'with:do:' category: '--all--' timestamp: '8/23/2004 14:41' author: 'st' body: [ ^this perform: that ]. self classMethod: 'initialize' category: 'class initialization' timestamp: '8/23/2004 14:42' author: 'st' body: [ ]. ]

I'm sure there would be plenty of debate on the actual methods used to build things, mode versus scope and things like that.. all worthwhile. But the beauty of it is that it doesn't introduce a non-smalltalk syntax such as the bangs or xml.

Just my 2c. I've got a library in VW that does most of this. I'm sure the technique could be ported fairly readily.

Michael

...

<?xml version="1.0" encoding="UTF-8"?><...

st:xmlns="http://www.squeak.org/2007/deltaFileFormat%22%3E <st:class name="SuperDeltaObject" superclass="Object" dialect="Squeak"> <st:classcomment /> <!--uhm, what class comment ;-) --> <st:method selector="with:do:" category="--all--" timestamp="8/23/2004 14:41" author="st"> with: this do: that ^ this perform: that </st:method> <st:metaclass instvars=""> <st:method selector="initialize" category="class initialization" timestamp="8/23/2004 14:42" author="st"> initialize </st:method> </st:metaclass> </st:class></...>

All the not explicitly mentioned attributes can have an intuitive default (like format="fixed" and instvars="", etc) and complex attributes (like oldinstvarorder="c b a") can be ignored by simple readers.

It looks a bit wordy but, what do you think?

/Klaus

On Tue, 21 Aug 2007 03:01:45 +0200, goran@krampe.se wrote:

...

Hi all!

Ok, managed to get some more code written tonight - but I am still on a low level here - matching up with ChangeSet etc. But if anyone wants to join in:

See details here: http://wiki.squeak.org/squeak/6001

The first goal is to make DSDelta work as a "true log" capturing all changes in full detail.

One question for you gurus out there - do we care about changing the ORDER of say instvars?

regards, Göran

Craig Latta wrote:

...

Of course the other direction (XML to your 2c's) is a bit more complicated but doesn't look undoable.

 That's what I'm afraid of, that we'll introduce XML into the mix 

and won't be able to un-do it. :)

Let's put it this way - if we use Smalltalk instead of XML, then we can program stuff and extend it easily. If we use XML, then we end up with something like Ant.. when we could have just used Smalltalk. Using Smalltalk fulfills two requirements - a file out format that describes declarative code structures - and a disk format for writing smalltalk programs that doesn't involve weird !'s or xml tags/namespaces.

Just another 2c.. almost up to 5c now.

Michael

I agree, avoiding XML and sticking with Smalltalk is a big plus.

Travis.

Michael Lucas-Smith wrote:

Craig Latta wrote:

...

...

Of course the other direction (XML to your 2c's) is a bit more complicated but doesn't look undoable.

 That's what I'm afraid of, that we'll introduce XML into the mix 

and won't be able to un-do it. :)

Let's put it this way - if we use Smalltalk instead of XML, then we can program stuff and extend it easily. If we use XML, then we end up with something like Ant.. when we could have just used Smalltalk. Using Smalltalk fulfills two requirements - a file out format that describes declarative code structures - and a disk format for writing smalltalk programs that doesn't involve weird !'s or xml tags/namespaces.

Just another 2c.. almost up to 5c now.

Michael

Hi, <snip>

As to human readable - well.. let's just say XML leaves a lot to be desired there :) I'd much rather see pure message sends going on here, eg:

self encoding: #utf8. self class: 'SuperDeltaObject' superclass: 'Object' do: [ self instanceVariables: #(a b c). self comment: 'uhm, what class comment ;-)'. self method: 'with:do:' category: '--all--' timestamp: '8/23/2004 14:41' author: 'st' body: [ ^this perform: that ]. self classMethod: 'initialize' category: 'class initialization' timestamp: '8/23/2004 14:42' author: 'st' body: [ ]. ]

That looks good. How does the body:[ ... ] part parse? Is there a way of quickly 'skipping' from start '[' to the end ']' without having to parse the source in the midlle with a full Smalltalk parser? It can't just skip matching '[ ]' pairs, in case there are ']' embedded in strings etc. , right?

DeltaStreams, on disk, could be large. Especially if used as a kind of finer grained .changes file. Quickly scanning the file to find 'interesting' entries, without deserializing the whole file into memory, would be useful.

Cheers, Andy

That looks good. How does the body:[ ... ] part parse? Is there a way of quickly 'skipping' from start '[' to the end ']' without having to parse the source in the midlle with a full Smalltalk parser? It can't just skip matching '[ ]' pairs, in case there are ']' embedded in strings etc. , right?

You just let it compile as per normal. It has errors - but when you go to call the block, you reflect back to the parse tree and extract the source code.

It's a rather simple trick of self-reflecting code. It's kind of a shame that blocks don't already ahve access to their own source code like methods do - but whatcha gunna do :)

Michael