Going via browser: http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals/versions/Obje... says "oops not found" On 21 October 2012 02:36, Igor Stasenko <siguctua@gmail.com> wrote:

Me too: 'Could not load ObjectLiterals-SvenVanCaekenberghe.4.mcz: ZnHttpUnsuccessful: 404 Not Found'

however, the monticello repository window shows it is there.

Nicolas, any clues what going on?

On 21 October 2012 01:30, Dale Henrichs <dhenrich@vmware.com> wrote:

...

Sven,

For some reason I can't see any of the packages in your project on SmalltalkHub, but I was just curious if your work depends upon a pre-existing Smalltalk parser or not?

I assume that "the JSON issue" will come up in a month or two again, so it is worth knowing the answer ahead of time:)

Dale

----- Original Message ----- | From: "Sven Van Caekenberghe" <sven@stfx.eu> | To: "Pharo-project@lists.gforge.inria.fr Development" <Pharo-project@lists.gforge.inria.fr> | Sent: Saturday, October 20, 2012 11:51:34 AM | Subject: [Pharo-project] Parsing Smalltalk Array/Object Literals | | Hi, | | I took Igor's initial code and created a new project: | | http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals/ | | and I added ObjectLiteralParser to convert any Character Stream or | String into a Smalltalk Literal Array and eventually into an Object. | | This proof of concept moves the ObjectLiteral format/notation away | from the Smalltalk compiler and will help us discuss more concretely | the actual details of the specification (which is still not 100% | finished). | | I also added 12 unit tests and cleaned up the code and comments. | | Please have a look at the code. | | This is one of the tests: | | ObjectLiteralParserTests>>#testMixed1 | | input output | | input := ' | #(Array | 1 | foo | #''foo-#bar'' | true | false | nil | 3.14159 | -100 | ''string'' | (#OrderedCollection 7 8 9) | #(Set 10) | (Dictionary | x 1 | y 2) ) '. | output := { | 1. | #foo. | #'foo-#bar'. | true. | false. | nil. | 3.14159. | -100. | 'string'. | OrderedCollection withAll: #(7 8 9). | Set with: 10. | Dictionary newFromPairs: #(x 1 y 2 ). }. | self assert: (self parserOn: input) nextObjectLiteral equals: output | | I like this format, its simplicity and elegance is appealing, it | offers distinctive advantages in the Smalltalk context while its | slight readability disadvantage is acceptable. Like any format it is | a compromise and a tradeoff, but a rather good one. | | Regards, | | Sven | | -- | Sven Van Caekenberghe | http://stfx.eu | Smalltalk is the Red Pill | | | | |

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

On 21 October 2012 10:22, Sven Van Caekenberghe <sven@stfx.eu> wrote:

Yes, something is wrong with the ObjectLiterals repository on SmalltalkHub, but I have no clue what.

I made a copy in another place

http://mc.stfx.eu/ObjectLiterals

hmm.. how i can download it? when i press a link in browser it asks me for username/password?

@Dale

Of course ObjectLiteralsParser, is completely independent of any other code, that is the whole idea. And it is very small as well, it should be portable to any Smalltalk.

@Igor

The Symbol and Number syntax accepted by ObjectLiteralsParser is artificially limited right now, as it was copied from STON. As long as it is a proper subset of Smalltalk that does not strike me as a problem.

Anyway, the goal of the code is to allow for a more precise discussion.

i now modelling a system logger (to replace .changes file), and since i having no better idea, i'll try to use object literals for it. The idea is to preserve chunk format, but use object-literals for meta-information: logEntryExamples #(Method: ClassName instance "or class" 'category' 'author' (DateAndTime 'xxx') 'priorsourceId' ). #(TraitMethod: TraitName instance "or class" 'category' 'author' (DateAndTime 'xxx') 'priorsourceId' ). #(DoIt: 'author' (DateAndTime 'xxx') ). #(ClassComment: ClassName 'author' (DateAndTime 'xxx') 'priorsourceId' ). So, in log, it will look like: !#(Method: Object instance 'testing' 'Super Mario' (DateAndTime ' 2012-10-21T11:30:03.892+02:00') 'abra-ka-da-br-a' )! testSequenceIfNotEmptyDo self empty ifNotEmptyDo: [:s | self assert: false]. self assert: (self nonEmpty ifNotEmptyDo: [:s | self accessValuePutInOn: s]) = self valuePutIn ! ! Note the colon ':' in first literal. This is to prevent collision with any existing (and future) class name. As i suggested earlier, obj-literal can have name resolution logic in front of basic one - (Smalltalk at: name) and of course, there must be an extension mechanism, which can register own resolvers. I think it would be easy to extend chunk reading logic to detect that meta information stored as object-literal. Searching whole .sources file, i found only one occurrence of '!#' sequence and zero '!#(' If i do: '#( 1 2 3) yourself' in workspace, it writes: ! #(1 3 4 ) yourself! (an empty line between ! and #( ) -- Best regards, Igor Stasenko.

On 2012-10-21, at 13:39, Denis Kudriashov <dionisiydk@gmail.com> wrote:

Hello

2012/10/21 Igor Stasenko <siguctua@gmail.com>

...

i now modelling a system logger (to replace .changes file), and since i having no better idea, i'll try to use object literals for it.

ehm, igor, why the heck don't you use fuel for that?

On 21 October 2012 13:39, Denis Kudriashov <dionisiydk@gmail.com> wrote:

Hello

2012/10/21 Igor Stasenko <siguctua@gmail.com>

...

i now modelling a system logger (to replace .changes file), and since i having no better idea, i'll try to use object literals for it.

Do you see Deltas project?

Sure i know about deltas. I was hacking it. :)

I think one of the proposals was .changes file replacement

not exactly. it is more changeset replacement. What i am doing is a bit orthogonal: it is a facility to recover lost changes. All of the sources will be held inside image. -- Best regards, Igor Stasenko.

On Oct 21, 2012, at 3:12 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Sun, Oct 21, 2012 at 2:38 PM, Igor Stasenko <siguctua@gmail.com> wrote: On 21 October 2012 13:39, Denis Kudriashov <dionisiydk@gmail.com> wrote:

...

Hello

2012/10/21 Igor Stasenko <siguctua@gmail.com>

...

i now modelling a system logger (to replace .changes file), and since i having no better idea, i'll try to use object literals for it.

Do you see Deltas project?

Sure i know about deltas. I was hacking it. :)

...

I think one of the proposals was .changes file replacement

not exactly. it is more changeset replacement. What i am doing is a bit orthogonal: it is a facility to recover lost changes. All of the sources will be held inside image.

But one very common case to recover lost changes is when the image is broken... so if you store the stuff in the image...

The .changes right now has two duties 1) Be a log in case of crash. Like a transaction log in a database... 2) the place where the sourcecode is because it is oh so large. So I vote for splitting "where source is stored" from the transaction log. The log file then will be just a log. e.g. the image that you download: the log will be empty. The log can be deleted at any point, it is just a log. Marcus -- Marcus Denker -- http://marcusdenker.de

Well we started with ezequiel to work on that. We took a look at Deltas: - any change is revertible and keeps it changes Ezequiel was planning to show to the group what he has friday but we were busy. he will show us that tomorrow. Now I would really like that we do not have hack change set, whatever…. But write something new aside. And in addition I would like that we FINISH what we are doing before opening new projects. Stef On Oct 21, 2012, at 3:39 PM, Mariano Martinez Peck wrote:

On Sun, Oct 21, 2012 at 3:17 PM, Marcus Denker <marcus.denker@inria.fr> wrote:

On Oct 21, 2012, at 3:12 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

On Sun, Oct 21, 2012 at 2:38 PM, Igor Stasenko <siguctua@gmail.com> wrote: On 21 October 2012 13:39, Denis Kudriashov <dionisiydk@gmail.com> wrote:

...

Hello

2012/10/21 Igor Stasenko <siguctua@gmail.com>

...

i now modelling a system logger (to replace .changes file), and since i having no better idea, i'll try to use object literals for it.

Do you see Deltas project?

Sure i know about deltas. I was hacking it. :)

...

I think one of the proposals was .changes file replacement

not exactly. it is more changeset replacement. What i am doing is a bit orthogonal: it is a facility to recover lost changes. All of the sources will be held inside image.

But one very common case to recover lost changes is when the image is broken... so if you store the stuff in the image...

The .changes right now has two duties

1) Be a log in case of crash. Like a transaction log in a database... 2) the place where the sourcecode is because it is oh so large.

So I vote for splitting "where source is stored" from the transaction log.

The log file then will be just a log. e.g. the image that you download: the log will be empty. The log can be deleted at any point, it is just a log.

+99999999 music to my ears. I have been dreaming with this since a log long time

Marcus

-- Marcus Denker -- http://marcusdenker.de

-- Mariano http://marianopeck.wordpress.com

On 21 October 2012 22:21, Göran Krampe <goran@krampe.se> wrote:

Hey!

On 10/21/2012 04:21 PM, Stéphane Ducasse wrote:

...

Well we started with ezequiel to work on that. We took a look at Deltas: - any change is revertible and keeps it changes

Ezequiel was planning to show to the group what he has friday but we were busy. he will show us that tomorrow.

Ehrm?? Are you looking at Deltas? I haven't seen a single email, I would love to at least be in the "consulting loop" on this - it is my baby after all and I can answer most questions about it.

...

Now I would really like that we do not have hack change set, whatever…. But write something new aside.

Please, please, please - if you plan to replace ChangeSet (and you *should*) - please take Deltas and run with it. It was *built* for that and I think a lot of the code in there is good code and a nice design.

And if you think some other file format is better - I don't care - that is just serialization after all. And Tirade is of course not hard coded into Deltas.

To me the one of important part of this story is to have better code reuse. I like the idea of (re)using regular smalltalk parser to do heavylifting, while rest is built on top of it. I like the idea with Deltas that you can rewind them or play them. Now the problem is that it will require substantial effort to adopt it to Pharo. Not long ago, we introduced SystemAnnouncer, and if you look at announces (SystemAnnouncement subclasses) you can see that it very closely resembling delta records. I dont think that it will be clever to have two classes per each system event, i.e. ClassRemoved and then ClassRemovedDelta. It would be much nicer to have a single one. Another thing is what to do with SystemEditor? My main problem with it, that it is gone too far, trying to resemble many Class/Behavior protocols. That means that any change/extension in Class/Behavior will have potential risk breaking SystemEditor, if we forget to sync changes there as well. And the last time we did pass on SystemEditor, if i remember, there was still no support for traits. But sure thing, i should not forget to say about what SystemEditor gives: atomic updates. My only concern is that price for having such feature is a bit too high as to me: - big and complex (okay, non-trivial ;) ) logic - a maintenance needed if we go and hack Class/Behavior/Traits etc). for the other features, i don't see significant advantage of using it over something else (less complex and more compact). -- Best regards, Igor Stasenko.

On 22 October 2012 00:23, Göran Krampe <goran@krampe.se> wrote:

Hi!

On 10/21/2012 11:46 PM, Igor Stasenko wrote:

...

To me the one of important part of this story is to have better code reuse. I like the idea of (re)using regular smalltalk parser to do heavylifting, while rest is built on top of it.

(I presume regarding external serialization format, anyway, you might note that having "full Smalltalk" is a security issue also, and a speed issue)

...

I like the idea with Deltas that you can rewind them or play them. Now the problem is that it will require substantial effort to adopt it to Pharo. Not long ago, we introduced SystemAnnouncer, and if you look at announces (SystemAnnouncement subclasses) you can see that it very closely resembling delta records.

I would suspect, yes. But still different since I presume a SystemAnnouncement does NOT capture enough to enable undo, so they are still "different beasts". Also, (without having looked) I guess a SystemAnnouncement is not a "standalone object" like a Change in Deltas is. I mean, it probably references the class, or a new method etc - and doesn't actually contain a full copy of all state of the actual change.

right, but if we would do it right, i would make it like you said. Instead of having parallel class hierarchies which representing same event(s) in system.

...

I dont think that it will be clever to have two classes per each system event, i.e. ClassRemoved and then ClassRemovedDelta. It would be much nicer to have a single one.

See above. Different responsibilities, right? But I agree with the "itch", not sure if it can be fully helped though.

Well, both Deltas and SystemAnnouncement reflecting the change in system. The only difference is that Delta has more capabilities than serving as a simple event. It would be nice if we could leave only single class hierachy for that (not two, parallel ones). Because same story again: once you have parallel stuff in two different places in system, it is prone to go out of sync sooner or later.

...

Another thing is what to do with SystemEditor? My main problem with it, that it is gone too far, trying to resemble many Class/Behavior protocols.

Personally I thought it looked "awful" - but I just wanted to be a user and get "atomicity". IMHO one should be able to get atomicity using become tricks instead, IIRC Henrik Gedenryd (bless his soul) did atomicity in his old 3.3modules code using such a trick (building new classes and then at end - do a "sweep become-replace" operation of all the modified classes)

right, but there's many pitfalls, like code which relying on new shape of a class, but not able to see it because it is still not installed. or opposite: the code which relies on old shape, but forced to 'speak' with new shape, where that part is removed/changed.

...

That means that any change/extension in Class/Behavior will have potential risk breaking SystemEditor, if we forget to sync changes there as well. And the last time we did pass on SystemEditor, if i remember, there was still no support for traits.

But sure thing, i should not forget to say about what SystemEditor gives: atomic updates. My only concern is that price for having such feature is a bit too high as to me: - big and complex (okay, non-trivial ;) ) logic - a maintenance needed if we go and hack Class/Behavior/Traits etc).

for the other features, i don't see significant advantage of using it over something else (less complex and more compact).

Final comment on SystemEditor - it is not hardwired into Deltas, in fact it is kept separate and the idea was to be able to have different "Applier" classes using different mechanisms.

Yes, personally i would like to see Deltas (modulo SystemEditor) integrated in pharo.. but the problem that who will make it happen :)

regards, Göran

-- Best regards, Igor Stasenko.

Hi! (not up to speed on Pharo "goals" in this area, but...) On 10/22/2012 09:45 AM, Goubier Thierry wrote:

Hi all,

I'd like to ask if I understood correctly this part of the discussion. With a suitable log/change format as Deltas propose and Igor is thinking of implementing, we could undo any changes done on the image (such as method creation, modification, class add/remove, etc...).

Note - Deltas actually *exist* - it is not just a proposal. They work. And the answer is "yes", it enables full multilevel undo of *source* changes to the image. It does this by making sure each "Change": - Has captured enough state to reverse itself in full. - Knows how to create its "anti-Change". ...then the code in Delta>>undo basically ends up like: changes reversed do: [:each | each asAntiChange apply ] ...well, in fact - it is not written exactly like that - we create a full "anti-Delta" first, and then "apply" it. But anyway, you get my point. Major changes compared to the total misfit ChangeSet: - A Delta has *ordered* Changes, not a "Set". So we could call a Delta a "ChangeList" instead. :) - A Delta and its list of Changes is *completely* standalone from the rest of the image. Thus trivially serialized, thrown away etc. A ChangeSet is *not at all* standalone, which is the worst aspect of them. You can easily see this yourself by: - Create a ChangeSet and add a method (it gets recorded) - Create a new ChangeSet and modify same method (it gets recorded in the new ChangeSet) - Take a look in the previous ChangeSet, tada! The method there is now not at all what it was from the start... ...so a ChangeSet actually only "points" at methods, they do NOT contain the actual change! Now, coming back to Change>>asAntiChange - this is where the tricky part starts... First each SystemChangeAnnoncement MUST capture all state. For example, earlier a "new class comment" didn't send along the old comment! And it was fired *after* the change was done, so information was lost. Not sure how Pharo does on that exact example today - worth checking for fun! :) Secondly, the delete/remove Change objects end up to have to capture ALL state that was removed... So a "remove class X"-change must in fact capture enough information to be able to reconstruct it. Thus Deltas have CompositeChange which basically is a full list of smaller changes like create a class X, add n methods to it etc.

How does this relates with the undo/redo facility in RefactoringBrowser?

Dunno.

And a question which is nagging me regularly when I try to get my head around it: could we unify change sets and packages? I'm just regularly lost when I try to play with the change set tools.

IMHO they are in fact two different things - but of course can be made to play better with each other. Also, one reason ChangeSets are hard is probably because they are misunderstood (because of their bad design IMHO). Sorry for lengthy post. regards, Göran PS. I presented and demoed Deltas at an ESUG a few years back, but unfortunately most people attended a Seaside thing in parallell :)

On 10/22/2012 11:31 AM, Goubier Thierry wrote:

Le 22/10/2012 11:07, Göran Krampe a écrit :

...

Hi!

(not up to speed on Pharo "goals" in this area, but...)

On 10/22/2012 09:45 AM, Goubier Thierry wrote:

...

Hi all,

I'd like to ask if I understood correctly this part of the discussion. With a suitable log/change format as Deltas propose and Igor is thinking of implementing, we could undo any changes done on the image (such as method creation, modification, class add/remove, etc...).

Note - Deltas actually *exist* - it is not just a proposal. They work.

And the answer is "yes", it enables full multilevel undo of *source* changes to the image.

It does this by making sure each "Change": - Has captured enough state to reverse itself in full. - Knows how to create its "anti-Change".

...then the code in Delta>>undo basically ends up like:

changes reversed do: [:each | each asAntiChange apply ]

...well, in fact - it is not written exactly like that - we create a full "anti-Delta" first, and then "apply" it. But anyway, you get my point.

Major changes compared to the total misfit ChangeSet:

- A Delta has *ordered* Changes, not a "Set". So we could call a Delta a "ChangeList" instead. :)

- A Delta and its list of Changes is *completely* standalone from the rest of the image. Thus trivially serialized, thrown away etc.

A ChangeSet is *not at all* standalone, which is the worst aspect of them. You can easily see this yourself by:

- Create a ChangeSet and add a method (it gets recorded) - Create a new ChangeSet and modify same method (it gets recorded in the new ChangeSet) - Take a look in the previous ChangeSet, tada! The method there is now not at all what it was from the start...

...so a ChangeSet actually only "points" at methods, they do NOT contain the actual change!

Now, coming back to Change>>asAntiChange - this is where the tricky part starts...

First each SystemChangeAnnoncement MUST capture all state. For example, earlier a "new class comment" didn't send along the old comment! And it was fired *after* the change was done, so information was lost. Not sure how Pharo does on that exact example today - worth checking for fun! :)

Secondly, the delete/remove Change objects end up to have to capture ALL state that was removed... So a "remove class X"-change must in fact capture enough information to be able to reconstruct it. Thus Deltas have CompositeChange which basically is a full list of smaller changes like create a class X, add n methods to it etc.

Ok, then I could imagine having a system browser which is able to use Deltas to show this ability to list changes and undo them.

Yes, and while Matthew wrote one UI for Deltas (a system browser variant) I was not all too comfortable with that "view". I was more thinking of simply rewire Dual change sorter and friends to use Deltas instead.

Is there any provision to selectively undo changes and try to maintain the system in a consistent state? For example, undo a class rename and you may have to recompile / change methods which refer to that class name to maintain the system in a consistent state.

Well, I started on this idea of "condensing" a Delta which would remove all redundancy (changes shadowing other changes) and also typically "move" renames to the beginning or end (and adapt the other changes to that fact of course). This is a fun challenge - but I didn't finish it due to lack of time. And yes, this "shadowing analysis" would also come into play in your uses case.

...

...

How does this relates with the undo/redo facility in RefactoringBrowser?

Dunno.

Well, there are some commands such as RBRenameClassRefactoring, when executed, which get stored in an undo/redo facility (RBRefactoryChangeManager) where you can undo or redo the operation.

So, as you can see, it is already a way to record user-made changes and undo them, probably very cleanly, with a huge hierarchy of available commands and ways to group them.

Yeah, and at the moment I can't really comment on it - but it sure is something we would want to look into. Deltas operate on the lowest level - and was meant to do that by design. RB is on another higher level. regards, Göran

On 21 October 2012 15:12, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Sun, Oct 21, 2012 at 2:38 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 21 October 2012 13:39, Denis Kudriashov <dionisiydk@gmail.com> wrote:

...

Hello

2012/10/21 Igor Stasenko <siguctua@gmail.com>

...

i now modelling a system logger (to replace .changes file), and since i having no better idea, i'll try to use object literals for it.

Do you see Deltas project?

Sure i know about deltas. I was hacking it. :)

...

I think one of the proposals was .changes file replacement

not exactly. it is more changeset replacement. What i am doing is a bit orthogonal: it is a facility to recover lost changes. All of the sources will be held inside image.

But one very common case to recover lost changes is when the image is broken... so if you store the stuff in the image...

the log can be opened by another image. And doing image backups also helps. And recovering image also possible :)

...

-- Best regards, Igor Stasenko.

-- Mariano http://marianopeck.wordpress.com

-- Best regards, Igor Stasenko.

On 21 Oct 2012, at 11:53, Igor Stasenko <siguctua@gmail.com> wrote:

On 21 October 2012 10:22, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

Yes, something is wrong with the ObjectLiterals repository on SmalltalkHub, but I have no clue what.

I made a copy in another place

http://mc.stfx.eu/ObjectLiterals

hmm.. how i can download it? when i press a link in browser it asks me for username/password?

It worked/works fine when you define a regular Monticello repository on it: MCHttpRepository location: 'http://mc.stfx.eu/ObjectLiterals' user: '' password: '' There was indeed an error in the generated HTML that only affect humans clicking the link, I fixed it. Sorry about that.

...

@Dale

Of course ObjectLiteralsParser, is completely independent of any other code, that is the whole idea. And it is very small as well, it should be portable to any Smalltalk.

@Igor

The Symbol and Number syntax accepted by ObjectLiteralsParser is artificially limited right now, as it was copied from STON. As long as it is a proper subset of Smalltalk that does not strike me as a problem.

Anyway, the goal of the code is to allow for a more precise discussion.

i now modelling a system logger (to replace .changes file), and since i having no better idea, i'll try to use object literals for it.

Igor do not open too many projects :). Please finish the others. We want athens We are working on that with ezequiel and martin will probably help to get started with his phd. It would be good if we could get rid of the ! !! delimiters for now ezequiel is just strong fuel objects but indeed having a textual format can be really important. Note that we will probably want to store complete refactorings so that we can reapply a logical changes or a set of physical modifications. Stef

The idea is to preserve chunk format, but use object-literals for meta-information:

logEntryExamples #(Method: ClassName instance "or class" 'category' 'author' (DateAndTime 'xxx') 'priorsourceId' ). #(TraitMethod: TraitName instance "or class" 'category' 'author' (DateAndTime 'xxx') 'priorsourceId' ). #(DoIt: 'author' (DateAndTime 'xxx') ). #(ClassComment: ClassName 'author' (DateAndTime 'xxx') 'priorsourceId' ).

So, in log, it will look like:

!#(Method: Object instance 'testing' 'Super Mario' (DateAndTime ' 2012-10-21T11:30:03.892+02:00') 'abra-ka-da-br-a' )! testSequenceIfNotEmptyDo

self empty ifNotEmptyDo: [:s | self assert: false]. self assert: (self nonEmpty ifNotEmptyDo: [:s | self accessValuePutInOn: s]) = self valuePutIn ! !

Note the colon ':' in first literal. This is to prevent collision with any existing (and future) class name. As i suggested earlier, obj-literal can have name resolution logic in front of basic one - (Smalltalk at: name) and of course, there must be an extension mechanism, which can register own resolvers.

I think it would be easy to extend chunk reading logic to detect that meta information stored as object-literal. Searching whole .sources file, i found only one occurrence of '!#' sequence and zero '!#('

If i do:

'#( 1 2 3) yourself' in workspace, it writes:

!

#(1 3 4 ) yourself!

(an empty line between ! and #( )

-- Best regards, Igor Stasenko.

yes I know. We will fix that one of these days :) Stef On Oct 21, 2012, at 8:06 PM, Igor Stasenko wrote:

On 21 October 2012 16:18, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

...

i now modelling a system logger (to replace .changes file), and since i having no better idea, i'll try to use object literals for it.

Igor do not open too many projects :). Please finish the others. We want athens We are working on that with ezequiel and martin will probably help to get started with his phd.

Don't worry, i wanted to do that during weekend :)

I took a look at current stuff in CompiledMethod 'source code management' and it makes me vomit:

logMethodSource: aText forMethodWithNode: aCompiledMethodWithNode inCategory: category withStamp: changeStamp notifying: requestor

putSource: sourceStr fromParseNode: methodNode class: class category: catName withStamp: changeStamp inFile: fileIndex priorMethod: priorMethod

putSource: sourceStr fromParseNode: methodNode inFile: fileIndex withPreamble: preambleBlock

it is just horrible: passing around tons of arguments, no delegation, no encapsulation, spaghetti code.

...

It would be good if we could get rid of the

! !! delimiters

for now ezequiel is just strong fuel objects but indeed having a textual format can be really important.

Note that we will probably want to store complete refactorings so that we can reapply a logical changes or a set of physical modifications.

Stef

-- Best regards, Igor Stasenko.

Sven, I'm not asking about the parser for the literal array but the parser to parse the literal array itself, but I think you've answered my question (indirectly:) The original reason for going with JSON 9 months ago was that since GemStone does not have a accessible parser for Smalltalk syntax, I need to choose an export format for "objects" that included a portable parser for the syntax ... Presumably your implementation assumes the existence of a Smalltalk literal parser (I think that is what I was able to glean from Igor's mails) in which case I won't be able to use it (even if I thought it was usable from a readability standpoint:). Dale ----- Original Message ----- | From: "Sven Van Caekenberghe" <sven@stfx.eu> | To: Pharo-project@lists.gforge.inria.fr | Sent: Sunday, October 21, 2012 1:22:06 AM | Subject: Re: [Pharo-project] Parsing Smalltalk Array/Object Literals | | Yes, something is wrong with the ObjectLiterals repository on | SmalltalkHub, but I have no clue what. | | I made a copy in another place | | http://mc.stfx.eu/ObjectLiterals | | @Dale | | Of course ObjectLiteralsParser, is completely independent of any | other code, that is the whole idea. | And it is very small as well, it should be portable to any Smalltalk. | | @Igor | | The Symbol and Number syntax accepted by ObjectLiteralsParser is | artificially limited right now, as it was copied from STON. As long | as it is a proper subset of Smalltalk that does not strike me as a | problem. | | Anyway, the goal of the code is to allow for a more precise | discussion. | | Sven | | On 21 Oct 2012, at 02:36, Igor Stasenko <siguctua@gmail.com> wrote: | | > Me too: | > 'Could not load ObjectLiterals-SvenVanCaekenberghe.4.mcz: | > ZnHttpUnsuccessful: 404 Not Found' | > | > however, the monticello repository window shows it is there. | > | > Nicolas, any clues what going on? | | -- | Sven Van Caekenberghe | http://stfx.eu | Smalltalk is the Red Pill | | | | |

Guys, guys.. calm down. I'm not going to reinvent the wheel. What i am trying to do is to prototype the interface of external log. The contents of log is not particularly important to me at this stage, because i wanna first try to see if following model good enough: - logs will be stored in subdirectory, instead of single file. A directory name is ./imageFileName.sessionLog/ for each new session, a new file will be created. The file name format will be something like: <sessionId>-<date>.log what will be stored there (like example which i given) is mostly a speculation right now. First, i wanna make a sketch of this idea and see, how far we can go with it (what advantages/disadvantages). -- Best regards, Igor Stasenko.

Dale, Please, please look at the code. Again: no my code does _not_ depend on a Smalltalk compiler. And indeed, there are 2 steps: 1. String -> Array Literal 2. Object Literal -> Object All in all, its very little code. Sven On 21 Oct 2012, at 20:23, Dale Henrichs <dhenrich@vmware.com> wrote:

Sven,

I'm not asking about the parser for the literal array but the parser to parse the literal array itself, but I think you've answered my question (indirectly:)

The original reason for going with JSON 9 months ago was that since GemStone does not have a accessible parser for Smalltalk syntax, I need to choose an export format for "objects" that included a portable parser for the syntax ...

Presumably your implementation assumes the existence of a Smalltalk literal parser (I think that is what I was able to glean from Igor's mails) in which case I won't be able to use it (even if I thought it was usable from a readability standpoint:).

Dale

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Thought I'd share this here: http://jsoneditoronline.org -- View this message in context: http://forum.world.st/Parsing-Smalltalk-Array-Object-Literals-tp4652173p4652... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.