Hi John,
thanks a lot for your review! I really appreciate it, as you are the
first one to report real bugs and to give lots of useful hints and
suggestions. I am just writing this as kind of a log while looking at
my code and trying to solve the problems.
> *) The Folder>>defaultDocument method adds a Code item instead of a
> Paragraph -- there's a missing ";".
>
> *) SwazooServer>>start has hard coded the ip to be '*'.
Those bugs are fixed.
> *) The tests don't have great coverage. I had to fix several bugs
> after all
> tests passed.
>
> [...]
>
> BTW, you could use my coverage tool to improve the tests. Currently, it
> shows about 60% method coverage for the tests.
Wow, that is really a great tool, I didn't knew about it. I will used
it in the feature more regularly when writing tests.
> *) 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.
> *) 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]".
>
> [...]
>
> *) I found a few non-#return: exceptions while running the tests, but I
> found others after. I finally ran the rewrite rule:
>
> ``@a
> on: ``@b
> do: [:`var | ``@c
> `{:node | node isMessage not
> or: [node receiver ~= `var]}]
> ->
> ``@a on: ``@b do: [:`var | `var return: ``@c]
>
> Most of these showed up as bugs in the permissions. For example, I
> would get
> a message saying that I couldn't do something, but it would also show
> me the
> stuff that I wasn't supposed to do. For example, I could see the
> history or
> edit blocks when I wasn't logged in.
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. Thanks
for providing the rewrite rule, this is really a great tool to use for
such kind of refactorings. However the rule did not detect that piece
of code, what should have been probably also rewritten:
^[ WikiParser parse: input readStream for: nil ]
on: Refactory.SmaCC.SmaCCParserError
do: [ :error |
Transcript show: 'WARNING: Unable to parse '; show: aClass name; cr.
nil ]
I didn't notice the problem with the permissions and could not
reproduce in VisiualWorks. Is this only a problem with #Smalltalk?
> *) 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 ...
> *) Here's an ANSI version of the moveDown:ifError:
>
> moveDown: anObject ifError: aBlock
> | index temp |
> index := self indexOf: anObject.
> (index between: 1 and: self size - 1)
> ifTrue: [ temp := self at: index.
> self at: index put: (self at: index + 1).
> self at: index + 1 put: temp ]
> ifFalse: [ aBlock value ]
>
> #swap:with: and #find: are VW messages (probably Squeak also has them,
> but I
> don't think VA or Dolphin does).
Ok, I replaced the old code with your suggestion and added two test to
check if it is really working as expected.
> *) 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 ...
> *) The VisitorRendererWiki>>contents message assumes that "stream cr"
> only
> puts one character in the string. It would be better if the #cr wasn't
> put
> on the stream to begin with so we didn't need the #copyFrom:to:.
Well, this is just a dirty trick to make the parser work. As the
wiki-syntax is line-based, I basically parse every line on its own up
to the line-ending. Therefor I have to make sure that also the last
line ends with a #cr. Another problem is, that the parser does not
allow nested lists. I couldn't figure out how to parse this properly.
The visitors however, would be able to render it correctly.
#1
##1.1
##1.2
#2
#-2.1
#-#2.1.1
I am usually learning from examples, but I couldn't find a wiki-grammar
anywhere on the web, so this is probably the first one ever written.
Furthermore I must admit that I wrote the parse before I had any
lecture about scanners, parsers and compilers, therefor there are even
more such ugly things that might have been written in a much nicer way.
If I find some time in the future I might try to rethink the whole
parsing and look if I manage to make it better.
> *) The Folder>>remove: method assumes that #remove: throws an error if
> the
> item isn't in the collection -- the ANSI standard says that the
> behavior is
> undefined, so #Smalltalk doesn't throw an error. Anyway, I doubt that
> it is
> really necessary, but there are a few tests for the error.
Ok, I changed the code and raise the exception manually if necessary.
> *) 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
Current time is: [ [ :h | h render: Timestamp now ] ]
you can always rewrite as
Current time is: [ html render: Timestamp now. nil ]
or even shorter
Current time is: [ Timestam now ]
These lines are all equivalent in VisualWorks, but I don't know about
#Smalltalk. You must have seen that I am also using dirty tricks with
the thisContext to setup global variables for that block. How do you
manage that? Would you prefer just to have the current action passed as
a parameter, even-tough the code written by the user would be longer in
case he didn't want just to return a value?
Current time is: [ :action | action html render: Timestamp now. nil ]
> *) The PageEdit>>exception: method wasn't covered in the tests. It
> sends
> #nextAvailable: which isn't implemented in #Smalltalk. I implement
> #next: to
> work that way. The ANSI standard says that the behavior is undefined
> when
> the integer is larger than the amount available, so I defined it to
> just
> return the remaining elements.
Ok, that has been fixed. A long time ago I decided not to cover the
action-package with tests. However, time has changed and there is a lot
of code that is somehow critical, I probably have to write some tests
in that area too.
> *) The RecentChanges>>renderDate:changes: method isn't covered.
> #Smalltalk
> uses the ANSI DateAndTime and Duration classes. It doesn't have the
> Date,
> Time & Timestamp classes like VW. Anyway, the #asTime method isn't
> implemented in #Smalltalk.
Unfortunately there is no class DateAndTime and Duration in VisualWorks
7.1, so I cannot fix that problem easily. In that case Squeak seems to
have better ANSI comparability than VisualWorks.
> *) TemplateEdit>>repositoryIndex wasn't covered. #Smalltalk doesn't
> have
> #upToSeparator. I changed it to be #upTo: a space.
Ok, I implemented it this way too.
> *) PageHistory>>renderDocument: sends #contractTo: which wasn't
> implemented
> in #Smalltalk.
I am using a more portable form of code there ...
> BTW, are you using the latest version of SmaCC? I put one on the public
> archive a week or two ago. It fixes a bug in the scanner generator
> where
> some token might be scanned correctly. For example, if you had
> something
> like:
> <aa> : aa;
> <anything> : .;
> It might scan "aa" as <anything> <anything> instead of <aa>. In
> addition to
> that fix, I also explicitly put it under the MIT license.
Yeah I noticed that, because Serge Stinckwich reported failing
parser-tests when downloading SmallWiki from the Cincom Repository. I
checked out the new version and had to tweak some minor things to make
all the tests pass again. However the new SmaCC version had never been
a problem when editing the page from the web.
Today I have just published the changes to the SCG repository and I
will push them to the Cincom Public repository tomorrow evening, after
having written some more additional tests.
Regards,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Hi Vassili,
SmallWiki is almost ready for including into the goodie collection, I
will just fix some bugs tonight that John Brant detected during his
code-review and while porting to S#.
So my question is the following: how is it the best to deploy and make
sure that all the prerequisites (SmaCC, Swazoo, SIXX) work when
installing? I think SmaCC and Swazoo will be included into the goodie
collection anyway, but I don't know what version and if the
auto-loading work properly. I played a bit around with 'Publish as
Parcel ...' but it seemed to have problems while loading Swazoo and
SmaCC and while initializing the classes of SmallWiki. Do you have any
suggestion how to proceed?
Thanks,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Begin forwarded message:
> From: ducasse <ducasse(a)iam.unibe.ch>
> Date: Mar oct 7, 2003 09:00:08 Europe/Zurich
> To: "John Brant" <brant(a)refactory.com>
> Cc: Lukas Renggli <renggli(a)student.unibe.ch>, Alexandre Bergel
> <bergel(a)iam.unibe.ch>
> Subject: Re: smallwiki
>
> Thanks john,
> Excellent, I wish I would have you as a teacher, really!
>
> I learned something too. Could you let us know the bugs that you fixed
> so that we can add tests?
> By the way, will you work on another back-end storage?
>
> Another question that we have is how to bundle SmallWiki. I was
> thinking that the version of the required package such as
> SmaCC, SIXX, Swazoo should be fixed so that we do not have a bug
> because one package is loaded while another version is expected.
>
>
> Stef
>
> On Mardi, oct 7, 2003, at 05:32 Europe/Zurich, John Brant wrote:
>
>> I finally got around to porting SmallWiki to #Smalltalk. I've gotten
>> it to
>> run. I don't have any storage hooked up yet, but most things appear
>> to be
>> working. Anyway, here are some more comments:
>>
>> *) The Folder>>defaultDocument method adds a Code item instead of a
>> Paragraph -- there's a missing ";".
>>
>> *) SwazooServer>>start has hard coded the ip to be '*'.
>>
>> *) The tests don't have great coverage. I had to fix several bugs
>> after all
>> tests passed.
>>
>> *) 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>".
>>
>> *) 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]".
>>
>> *) 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.
>>
>> *) Here's an ANSI version of the moveDown:ifError:
>>
>> moveDown: anObject ifError: aBlock
>> | index temp |
>> index := self indexOf: anObject.
>> (index between: 1 and: self size - 1)
>> ifTrue: [ temp := self at: index.
>> self at: index put: (self at: index + 1).
>> self at: index + 1 put: temp ]
>> ifFalse: [ aBlock value ]
>>
>> #swap:with: and #find: are VW messages (probably Squeak also has
>> them, but I
>> don't think VA or Dolphin does).
>>
>> *) 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.
>>
>> *) The VisitorRendererWiki>>contents message assumes that "stream cr"
>> only
>> puts one character in the string. It would be better if the #cr
>> wasn't put
>> on the stream to begin with so we didn't need the #copyFrom:to:.
>>
>> *) The Folder>>remove: method assumes that #remove: throws an error
>> if the
>> item isn't in the collection -- the ANSI standard says that the
>> behavior is
>> undefined, so #Smalltalk doesn't throw an error. Anyway, I doubt that
>> it is
>> really necessary, but there are a few tests for the error.
>>
>> *) Is there some location I can download the .css files from? If I
>> run a
>> server, I'd prefer not to have to go to your server for each of the
>> .css
>> files. Also, are those files under the same MIT license?
>>
>>
>> John Brant
>>
>>
>>
>
Hi John,
thanks a lot for you report! I have to go to work now and will only
have a closer look at all those things today evening. Just wanted to
answer your last question:
> *) Is there some location I can download the .css files from? If I run
> a
> server, I'd prefer not to have to go to your server for each of the
> .css
> files. Also, are those files under the same MIT license?
You can download the design and some documentation from the SmallWiki
resource pool at:
http://www.iam.unibe.ch/~scg/smallwiki/
Everything is released under the same MIT license, I should probably
mention that somewhere inside those files ...
Thanks,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Hi,
I just published a new version to SCG and Cincom StORE that fixes
several problems and double-checked that everything runs out of the
box, including the tests and the examples:
- clicking on save when editing a page returns to the view
- creating a new structure entity directly goes into edit-mode
- uploading a resource returns to the page where the resource has been
added from
- folders are a subclass of page, so they might also contain a wiki
document describing the content of the folder and giving a selection of
links to its children
- the default document for a folder is a script generating a list of
the folder content automatically, so to the end-user it looks the same
as before
- when creating new structures from within a folder, a child of that
folder will be created by default
- when creating new structures form within a page, a brother/sister of
that page will be created by default
- fixed the parser problem reported by Serge
- several other minor fixes
The documentation of SmallWiki is also available now, download it from:
http://www.iam.unibe.ch/~scg/smallwiki/smallwiki.pdf
If there are no further comments about this version, I will release
version 1.0 on Monday or Tuesday and hand it in into the Cincom goodie
collection. I will leave for holiday on Friday, therefor I want
everything to be done before ...
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Hi all,
i try to run the tests for the last version of SmallWiki available on
the Cincom public store. 17 tests failed all in the ParserTests ...
--
Serge Stinckwich -< )
Université de Caen>CNRS UMR 6072>GREYC>MAD /~\
http://www.iutc3.unicaen.fr/serge/ (/ |
Smalltalkers do: [:it | All with: Class, (And love: it)] _|_/
Hi,
we are approaching the the 1.0 release of SmallWiki very fast. The
version you have in Cincom and SCG StORE now is almost the final one.
I set the blessing level 'to review', what tells that I want you to
download and run it, and ask you to send any bug- or problem-reports to
me. The blessing comment is the following:
This is the ALPHA-RELEASE of SmallWiki 1.0, the final
version will be published very soon. Please report any
problems or bugs to renggli(a)iam.unibe.ch.
For those that don't know how to install it, just follow these
instructions:
1. Load the bundle named 'SmallWiki' from Cincom Public StORE. You will
be asked to load some additional bundles like the SIXX XML
serialisation library, the Swazoo web-server and the SmaCC parser
generator.
2. If you like to have some example extensions loaded, also load the
bundle called 'SmallWiki Examples'.
3. While loading SmallWiki a workspace should have opened automatically
with useful commands to run the web-server. Read trough the whole text
to see some more possibilities for configuration.
4. If you are in a hurry, just evaluate the first expression
server := SmallWiki.SwazooServer startOn: 8080
starting the server on the port 8080.
5. Switch to your favourite web-browser, point it to
http://localhost:8080
and everything should be working :)
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Hi all
I would like to have a sync point monday after the blueprint
experience. David could you tell me where you are exactly? One guy
coming from france for a small project will work on SmallWiki. I do not
know if he is fast but we will ask him to work on security (blokcing
all the ip....)
Stef
Hi,
SmallWiki 1.0 will be ready very soon. Today I've added a few
components to make it even better useable in daily life:
- added a simple search tool
- created an action to allow searching
- created a template-component to allow searching
- fixed rendering-problems with Internet Explorer
- fixed some html-generation problems
Today after-noon I will finish the welcome-documentation that will be
displayed when opening the wiki for the first time.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Hi everybody,
I've updated the test server at
http://kilana.unibe.ch:9090/Designs
with the simple css-styles I've created last weekend. In fact there is
only one design, but in 3 different colours. I would be glad if others
could contribute different designs. As mentioned already several times,
there are some great examples available at:
http://www.csszengarden.com
For those that want to see the template editor, I have created a page
where even an anonymous user has full access to that feature.
http://kilana.unibe.ch:9090/Designs/TemplateEditor
Note: After all this is also a cool demo for the powerful and simple
security mechanism of SmallWiki, that some people are in doubt of.
Anonymous users just have the additional permission to edit the
template, whereas in all the other parts of the wiki they still do not
have it. Let's paint that page in green, the green page, ... :-)
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
