From: Lukas Renggli [mailto:renggli@student.unibe.ch]
*) You can't save the Syntax page after you
edit it. This occurs in VW
also.
It appears that it is interpreting the "*" inside the
"<code>*</code>".
Yeah, that is a know problem: I build the parse-tree manually, because
one would need to escape all the special characters like *, [, etc.
using &xxx; Right now this is not on top of my to-do-list, but I will
fix that some time.
I was wondering how to escape characters... How about using double
characters (e.g., ** for a *)?
*) When you
have an exception handler, the exception block shouldn't
just
return since that isn't legal ANSI Smalltalk. For example, instead of
having
"[self something] on: Error do: [:ex | 5]" it should be "[self
something]
on: Error do: [:ex | ex return: 5]".
Didn't know about that, the way I wrote it seemed to me more natural.
But if this is the ANSI standard, I will change it of course.
Well, I may be telling you wrong. I just read the #signal method on the ANSI
standard, and it appears that "[self foo] on: Error do: [:e | 5]" should be
"5". Now, I can't remember where I saw that it was undefined. Anyway,
I'll
change the #Smalltalk implementation so that "[self foo] on: Error do: [:e |
5]" returns 5. You shouldn't need to change your code.
I didn't notice the problem with the permissions
and could not
reproduce in VisiualWorks. Is this only a problem with #Smalltalk?
You can't reproduce it in VW -- it was in #Smalltalk. #Smalltalk treated the
behavior as undefined, which means that it was effectively resuming the
exception and the code continued to run so you would get a message saying
that you didn't have the permissions to do something and then it would show
you want you weren't supposed to do.
*) Does the
#nextVersionBecome: message ever get sent where the
argument's
class isn't the same as the receiver's class? I didn't see any places
where
that would happen so I changed it to be:
nextVersionBecome: aStructure
| previous |
previous := self copy.
self instanceVariableNames do: [:each | self instanceVariableNamed:
each put: (aStructure instanceVariableNamed: each)].
self version: previous version + 1.
self predecessor: previous.
^self
This version gets around having to #become: the versions.
That makes the tests pass, but unfortunately the real issue doesn't
seem to be covered by the tests. There might be links with references
to that structure anywhere within the wiki that have to be updated. The
cleanest solution (but maybe a bit slow) I can think of, would be to
write a visitor walking through the documents and all its versions of
the whole wiki and check manually all the internal links. As I have a
test case for that behavior now, it should be easy to get rid of the
one and only #become: in SmallWiki ...
I might not be understanding you, but I believe that it does handle that
case. In my version, everyone only references the current page. When you
create a new version, it creates a copy of the current object for history
and then copies all of the data to the current object. The current page is
always the same object -- it just gets different data copied into it.
Anyway, I don't believe either approach is the best. Instead I would like to
see an object that is a structure holder. It would contain things like the
title, parent, and the current structure. The structure object would contain
the stuff that changes between edits. When a page object referenced another
structure, it would hold the structure holder object instead of a particular
structure. This gets around the #become: hack by putting another level of
indirection in there. Furthermore, I believe it would be easier to model
this in a db than the current approach.
BTW, it appears that only the root structure has dependents. You could get
around having the dependents by having the root structure be a child of the
server and then adding a #changed:with: method to the server to update the
storage (of course this would limit the root to only be in one server).
Also, it might be better to have storage be a dependent of server instead of
an instance variable.
*) It would be
nice if the integer comparisons used #= instead of #==.
In
#Smalltalk, "1 + 2 == 3" is false since I have to use real objects for
integers.
Now I know that it is stupid to use #== when it wouldn't be needed.
When starting with the project I had a different opinion, that is why
there are still a lot of unnecessary #== in the code. I hope that I
cleaned everything now ...
I still have lots of code lying around that uses #== when it isn't
necessary. Anyway, for the SmallWiki, I was able to change most of them
using:
``@a == `#l `{:node | node value isKindOf: Number}
->
``@a = `#l
*) The tests
didn't test evaluating code that returns a block and then
doing
a renderOn: that block. In #Smalltalk, it just evaluates the parse
trees
instead of compiling the code so evaluated code blocks are instances of
RBFakeEvaluationBlock instead of BlockClosure. When I loaded the
initial
page, it displayed "a RBFakeEvaluationBlock" instead of the items in
the
collection.
Are you taking about code in the wiki-documents? I haven't thought
about returning blocks and don't even know what this could be useful
for? So instead of writing something like
Essentially, this was a shortcoming in the tests. Even though all the tests
passed under #Smalltalk, the folders didn't display correctly. Instead of a
list of the items in the folder, I just got "a RBFakeEvaluationBlock".
BTW, if you press the move up/down buttons in the template settings when
nothing is selected, you'll get a walkback. The bug is the #find: message
send -- it gives an error if the object isn't in the collection. My ANSI
versions of these methods should fix the bug...
John Brant