Re: SmallWiki suggestion
by Lukas Renggli
Hi Michele,
> PS. Let's give it a try: on the 'Changes' page of the Swiki I would
> like to see who made the changes by listing either an IP address and
> some machine info (Swiki does it like that) or (hmm.. ;-) even better:
> The 'Role' of the Person editing the page (was it the creator, a
> maintainer, a (supposedly) read-only person, or some stranger). The
> information should be displayed in a nice table (perhaps on a
> on-the-fly generated page) when I inspect the changes. (This could be
> pushed even further in case a SmallWiki is highly used: an automatic
> 'hacker' detector which correlates some information (for example
> consistent uploads etc.) and triggers automatic defense mechanisms
> like making the Swiki unreadable.. ;-\)
the problem here is that this information is not collected right now,
but of course one could add it easily. I am usually adding that kind of
things when there is the need, but right now I am on holiday, therefor
you have to implement it for yourself or wait a few weeks.
> PPS. You have to protect the top-page (which is the admin page) of the
> current Smallwiki on kilana by means of a password or something like
> that.
The top-page (it is actually a folder) is no different to other pages.
If one wants to simulate the SWiki behavior it is possible to protect
it, of course, but I try to keep everything as open as possible and
just protect the things that might harm your system per default.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
19 years, 11 months
change notification
by John Brant
I was looking at adding a file based storage mechanism. I want it to save
each change to a file whenever it happens, instead of waiting some interval
and then saving all pages. Anyway, I've added my new class, but it appears
that the #changed: message is getting the wrong argument. The argument name
is "aStructure", but it is rarely a structure. It appears that most of the
time it is an Action (e.g., PageEdit, Login, etc.). The only time that I
noticed a structure was when I added something to the folder using the
Contents page.
I would recommend renaming Storage>>changed: and Storage>>changed. These
messages are already defined on Object for dependents handling, but these
methods are doing something different.
Finally, I'd recommend against modifying collections outside of their
containing object. For example, the FolderEdit>>moveDown: reaches inside the
Folder object and manipulates the children collection. The Folder should be
the only object that manipulates its children collection. Externally
modifying the collection makes it hard to change the representation in the
future.
John Brant
19 years, 11 months
Re: remove from folder bug & cache comment
by Lukas Renggli
Hi John,
> There is a bug when deleting pages. Here is a test case:
> 1) Add a *Test* link to the Introduction page
> 2) Click the Page link to create a new Test page
> 3) Save the Test page
> 4) Go to the Information folder and "remove" the Test page
> 5) Go back to the Introduction page and click the Page link to create
> a new
> Test page
> 6) Save the new Test page
> 7) Go back to the Introduction page -- the Folder, Page, Resource
> items are
> still there. However the Information page contains a Test page. If you
> click
> the Page link again, it will create a Test1 page, but it won't update
> the
> Introduction page.
- This bug has been fixed. At the same time I have cleaned the code
with the internal links a little bit, as this was not the only case
where they showed wrong behavior. The look-up of the link-target is now
done dynamically whenever the page is rendered, so I am always
up-to-date. However the new implementation does not update
automatically when renaming the target. In a future version a visitor
could be added to fix that kind of problem. Of course I've also added
some new tests.
- I have added a couple of missing tests, especially for the serving
part with the chain-of-responsibility pattern. This raises the overall
coverage of the tests to about 75% immediately.
> Also, the cache uses a simple scheme for assigning keys (+1). Isn't
> this
> scheme too simple for web apps? For example, I could look at the page
> source, and come up with callbacks that are likely to be valid. For
> example,
> if I see callbacks for 341-344, I could try evaluating code for 340.
> This
> might execute a callback for some other person. Shouldn't the keys be
> some
> large random number instead?
- The tricky thing about the callbacks is, that they have to be
evaluated in the right order. To archive this, I sort the callbacks
according to their number to make sure that they are evaluated in the
same order as they had been defined on the page. In most cases this is
no security-issue as the the global permission of the action is checked
before evaluating the callbacks. However, and in that part your
concerns were absolutely right, there are some links in the EditFolder
action that require special permission (remove, copy) and that had not
been checked properly before. I've added some additional code to handle
this.
The optimal solution would be to have a huge and random session key
combined with small callback-numbers unique to that session. Probably
this will come in the future, when there is a proper session support in
SmallWiki.
I've committed the changes to Cincom StORE.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org
19 years, 11 months
remove from folder bug & cache comment
by John Brant
There is a bug when deleting pages. Here is a test case:
1) Add a *Test* link to the Introduction page
2) Click the Page link to create a new Test page
3) Save the Test page
4) Go to the Information folder and "remove" the Test page
5) Go back to the Introduction page and click the Page link to create a new
Test page
6) Save the new Test page
7) Go back to the Introduction page -- the Folder, Page, Resource items are
still there. However the Information page contains a Test page. If you click
the Page link again, it will create a Test1 page, but it won't update the
Introduction page.
Also, the cache uses a simple scheme for assigning keys (+1). Isn't this
scheme too simple for web apps? For example, I could look at the page
source, and come up with callbacks that are likely to be valid. For example,
if I see callbacks for 341-344, I could try evaluating code for 340. This
might execute a callback for some other person. Shouldn't the keys be some
large random number instead?
John Brant
19 years, 11 months
Re: SmallWiki
by Lukas Renggli
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
19 years, 11 months
SmallWiki
by Lukas Renggli
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
19 years, 11 months
Fwd: smallwiki
by ducasse
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
>>
>>
>>
>
19 years, 11 months
Re: smallwiki
by Lukas Renggli
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
19 years, 11 months
[ANN] Alpha Version Updated
by Lukas Renggli
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
19 years, 11 months
Tests failed
by Serge Stinckwich
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)] _|_/
19 years, 11 months
