Hi Chris,
sorry for my slow replay, there is a lot of other work to do ...
> I don't know the language support of VW. But does it make sense to use
> such a VW specific feature, if you plan to port it to different
> dialects?
Sure, you are right! But you still might want to have a look at it and
how they handle the support for different languages.
>>> (there is already a realease)
>>> ifTrue: [Where can I download a copy?]
>>> ifFalse: [When will SmallWiki be released?]
>> We did not announce a final release yet, but I think the current
>> implementation is stable and usable. It is available as Bundle from
>> SCG or Cincom StORE. There are also some projects available for
>> Squeak using parts of SmallWiki (Gardner, ...).
>
> My favourite Smalltalk is Squeak and I don't even have a copy of VW
> and don't want to install one. I don't know SCG and so I have no
> chance to get a copy. How can I access a copy just with a browser over
> http or ftp?
The current source is always available from the public Cincom StORE.
Unfortunately I am not able to maintain other places. However I will
send a private e-mail to you with a snapshot of the current status.
> Personally I don't like the long links of seaside. Is there a way to
> store the session ID in cockies and not in the url?
There is a property that you have to turn on.
> PS: Can I upload and delete files with SmallWiki? If not yet, is it
> planned for the future?
Sure, this is already implemented and fully functional. The demo on
http://kilana.unibe.ch:9090 has got some security restrictions set,
that disallows people that are not logged in to upload and delete files.
Cheers
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Maybe you can steal something for the German documentation
of SmallWiki from:
> So hatte ich mir das Gedacht
>
> http://wiki.rk-hildesheim.de/reservisten/help
>
> MfG
> Michael
>
Markus
> "Neumann, Michael" <Michael.Neumann(a)Katasteramt-HI.Niedersachsen.de>
Hi there,
I am new to SmallWiki but very interested. When I saw the Demo, I
was impressed. Good Work!
I'm interested in translating the SmallWiki into the german
language and maintain this german package. Do you have build in
support for different languages? I thought about using diff to
'patch' the source files. Maybe we can translate SmallWiki in
other languages too?!?
Any ideas/hints?
(there is already a realease)
ifTrue: [Where can I download a copy?]
ifFalse: [When will SmallWiki be released?]
Regards
Chris Burkert
--
http://www.chrisburkert.de/
Begin forwarded message:
> From: Chris Burkert <chris(a)chrisburkert.de>
> Date: Mit Jul 30, 2003 10:45:47 Europe/Zurich
> To: Lukas Renggli <renggli(a)student.unibe.ch>
> Subject: Re: [Q] Newbie Questions
>
> Lukas Renggli wrote:
>> Hi Chris,
>>> I'm interested in translating the SmallWiki into the german language
>>> and maintain this german package. Do you have build in support for
>>> different languages? I thought about using diff to 'patch' the
>>> source files. Maybe we can translate SmallWiki in other languages
>>> too?!?
>>>
>>> Any ideas/hints?
>> Great! There is no support for different languages in SmallWiki yet,
>> however I think it should be quite easy to use the support available
>> with VisualWorks (see #>> and #<<).
>
> I don't know the language support of VW. But does it make sense to use
> such a VW specific feature, if you plan to port it to different
> dialects?
>
>>> (there is already a realease)
>>> ifTrue: [Where can I download a copy?]
>>> ifFalse: [When will SmallWiki be released?]
>> We did not announce a final release yet, but I think the current
>> implementation is stable and usable. It is available as Bundle from
>> SCG or Cincom StORE. There are also some projects available for
>> Squeak using parts of SmallWiki (Gardner, ...).
>
> My favourite Smalltalk is Squeak and I don't even have a copy of VW
> and don't want to install one. I don't know SCG and so I have no
> chance to get a copy. How can I access a copy just with a browser over
> http or ftp?
>
>> Currently I have quite a lot of other things around, but I am still
>> doing the following things ...
>> [ self think about a port to squeak ] forkAt: 10.
>
> Sounds great to me! Maybe I can help with this?
>
>> [ self think about version 2 using seaside ] forkAt: 10.
>
> Personally I don't like the long links of seaside. Is there a way to
> store the session ID in cockies and not in the url?
>
>> [ self fix some bugs and do minor enhancements ] forkAt: 30.
>> [ self prepare presentation for ESUG 2003 ] forkAt: 40.
>> Cheers
>> Lukas
>
> Regards
> Chris Burkert
> --
> http://www.chrisburkert.de/
>
>
--
Lukas Renggli
http://renggli.freezope.org
Michael,
I am glad to hear that you are planning to extend SmallWiki with new
functionality!
> We are going to add the calendar to each User and make it viewable and
> updatable. I was thinking about adding another navigation box on the
> left hand side of the browser w/ functionality for accessing the
> calendar.
First of all you have to decide, if you want your calendar to have its
own url and to behave like a wiki-page (1) or if you want it to be
visible as part of the layout on each and every page (2); of course
these two possibilities might also get combined.
1. With the first approach you basically create one or more subclasses
of Structure. I imagine that you need one for the calendar and one for
the events. You might want to have a look at the implementation of the
message #processChild:, to get an idea how the urls are resolved and
the nesting of the structures is handled.
To see how actions, security and structures work together, have a look
inside the bundle 'SmallWiki Examples' where 'SmallWiki Example
Glossary' will be the most interesting for you. I've just updated the
latest code and bug-fixes to Cincom StORE.
2. If you want to go for the template solution, have a look at the
examples 'SmallWiki Example RSS' and 'SmallWiki Example Statistic'. I
am not sure if I should really suggest you to go with this solution, as
I am thinking about dropping the templates and going for a plain
CSS-Solution. Also note that the editing and configuration of templates
is somehow tricky to implement.
Maybe you want to subscribe to the SmallWiki mailing-list at
http://www.iam.unibe.ch/cgi-bin/majordomo?module=modify to get the
latest news and join the online discussions.
Hope that helps,
Lukas
On Montag, Jul 28, 2003, at 05:06 Europe/Zurich, Michael Baker wrote:
> Lukas,
>
> I am a student at UIUC (http://st-www.cs.uiuc.edu/users/cs497/ )
> taking a course in OOA&D w/ Ralph Johnson. For our class project (
> http://wiki.cs.uiuc.edu/cs497rej/Calendar+feature+for+SmallWiki ) , my
> partner and I are attempting to add calendar fuctionality ( like an
> Outlook Calendar ) to your SmallWiki.
> We have completed the calendar classes, but are having trouble getting
> started integrating it w/ SmallWiki. We are going to add the calendar
> to each User and make it viewable and updatable. I was thinking about
> adding another navigation box on the left hand side of the browser w/
> functionality for accessing the calendar.
>
> Can you provide some tips on integrating the calendar? I have thought
> that we will need new EditAction subclasses, a ViewAction subclasses,
> a couple of Structure subclasses. Also, I think we'll need to add a
> few #acceptWhatever: methods to Visitor and the VisitorRendererHtml.
>
> Do you have any recommendations?
> Thanks in advance for your help!
>
> Michael Baker
> http://wiki.cs.uiuc.edu/cs497rej/Michael+Baker
>
--
Lukas Renggli
http://renggli.freezope.org
Hi,
after quite a long time without having a chance to continue on
SmallWiki I restarted today morning. I wanted to implement the RSS
viewer, but unfortunately all the Cincom web-pages and also Cincom
StORE seems to be down. Therefor I started out with some cosmetic
changes to SmallWiki.
- The html-renderer does a double-dispatching to determine the type of
the parameter you give. The following examples are all equivalent and
should demonstrate the use of this feature. Of course all the old code
still works.
html bold: [ html text: 100 factorial printString ].
html bold: 100 factorial.
html bold: [ html text: 'bla' ].
html bold: 'bla'.
html bold: [ ].
html bold: nil.
- The 'SmallWiki Examples' have been updated to run with the current
implementation.
- A server-bug has been fixed to disallow caching of SmallWiki pages.
Before that fix some browsers had problems determining changes of a
page and wrong pages could be sent when SmallWiki ran behind a proxy.
- There has been a link added to the stack-trace called 'Open
Debugger', that opens the current exception in a debugger in the image.
This is quite useful when developing new extensions. However the
implementation is quite tricky and involves some crazy tricks with
contexts, as the exception must be kept and prepared to be reraised
within a different context in a different process at a later time. It
works well with VisualWorks 7.1, but probably not with older versions.
Cheers
Lukas
--
Lukas Renggli
http://renggli.freezope.org
08:52PM <cdegroot> lukas - I'm currently on a turning point. Either
keep current 'Gardner' as a simple embeddable Wiki component (almost
there), or continue porting SmallWiki stuff. Do you guys have any plans
for a SmallWiki Seaside port?
09:03PM > we don't have concrete plans right now
09:04PM <cdegroot> (and no time, probably ;-))
09:04PM > however there are some points that we want for SmallWiki 2
09:04PM > one of them is the Seaside port
09:04PM > yes, my time is very limited right now
09:06PM <cdegroot> ah. I'm currently looking at things like user
authentication/rights, and I need to decide where to place that kind of
stuff, etcetera. So I'm hopping on two thoughts: either keep 'ripping'
SmallWiki components, or cook things up myself.
09:07PM > well I don't see there is much sense to make a 1:1 port of
SmallWiki to Seaside/Squeak
09:07PM <cdegroot> probably not, no.
09:07PM <cdegroot> oh well, I think I'll create a separate 'userdb'
component (read up on Zope's interfaces etcetera) and see where it goes
from there...
09:08PM > so if you like, we might do a slight (this means not an 1:1
port) together (in my rare spare time ;-) )
09:08PM > well as you have certainly seen I have taken a lot of ideas
from zope
09:08PM <cdegroot> well, that'd mean that your rare spare time would
have to overlap with my rare spare time ;-).
09:09PM > :-)
09:09PM > but copying zope is not my goal
09:09PM > also there are a lot of problems with this
09:09PM <cdegroot> furthermore, I'm probably not of much use to you -
although I grok the ideas behind Seaside reasonably well, I'm a bit
behind with the concrete implementation.
09:09PM > because zope is heavily basing on multiple inheritance
09:09PM <cdegroot> my goal is a 'white box' component toolkit.
09:10PM <cdegroot> no through-the-web software building nonsense (the
absolutely worst idea of Zope)
09:10PM > but around a 'white box' a black box might be easily built :-D
09:10PM <cdegroot> yup. But not be me (at least not now).
09:11PM > well, i do not agree completely
09:11PM <cdegroot> So 'Gardner' is a component (ok, not yet), and my
other pet project, 'Sagan', is the substrate underneath: persistence,
interfaces for authentication etcetera, ...
09:11PM <cdegroot> at least, that's where I think I'm going.
09:11PM > sometimes it is quite usefull to have a web-editing stuff ...
09:11PM > see WABrowser
09:11PM > for some things this is a hit !
09:12PM <kencausey> I agree, sometimes you have a customer who just
needs to make an occasional change to a page.
09:12PM <cdegroot> well, having developed a couple of hefty things in
Zope, I can tell you that it is unwise to make it the *only* mode ;-)
09:12PM > http://www.ahl.unibe.ch is a zope page i made ;-)
09:12PM <kencausey> Agreed, zope external editor is the best thing
since sliced bread.
09:12PM <cdegroot> kencausey: occasionally editing a page is decidedly
something different from building a shop through-the-web.
09:12PM > i am interfacting now with seaside
09:13PM <kencausey> But both dtml and ZPT makes me hack up a hairball
after I spend time in Squeak.
09:13PM <cdegroot> yup
09:13PM > but i started with it before I knew smalltalk
09:13PM <cdegroot> where I'm going is a white-box toolkit for
programmers, including all the tools (like a Wiki) that allows
end-users to configure bits.
09:13PM <kencausey> Same here more or less, lots of prehistory with
python at least.
09:13PM <cdegroot> ditto for me, btw
09:14PM > ohh, it feels like in a python irc-chat ;-)
09:14PM <cdegroot> haven't used python for at least a year.
09:15PM <cdegroot> it falls by the wayside - complex things I do in
Smalltalk, simple things in bash/sed/awk/...
09:15PM > so with SmallWiki I tried to make something similar to Zope
(nesting, different components, ...), but not to copy the bad things
and to stay with the easiness of Wikis
09:16PM > right now there is still a lot of handwork to do
09:16PM > but that will change, especially with Seaside
09:16PM <cdegroot> 'component' is a completely different concept in
Seaside...
09:17PM > yes, I talked about a component in the sense of zope
09:17PM <cdegroot> ok, so 1:1 port of SmallWiki is useless. I'll let
myself be inspired by it, then.
09:17PM <cdegroot> First and foremost, I need some authentication
model...
09:17PM <cdegroot> (and I'm heavily leaning towards capabilities)
09:18PM > Stéphane is using SmallWiki in Smalltalk-Lectures here at
Bern and the students write (zope-)components as exercise ;-)
09:18PM > when implementing the security-model i had a look at
capabilites
09:18PM <cdegroot> yeah, that's the nice thing of teaching - students
available to extend whatever you like to be extended ;-)
09:19PM > but it was too complex for me
09:19PM <cdegroot> it is not very complex, however management can be
hard.
09:19PM > i did not found good examples/documentation
09:19PM > so i decided to go with a unix like security
09:19PM <cdegroot> essentially, you have a sort of keyring for every
user, with lots and lots of keys on it.
09:20PM <cdegroot> (if you see every cap as a key to unlock a single
'door')
09:20PM > a door might be 'editing a specific page'?
09:20PM <cdegroot> yup.
09:20PM > or 'editing editing any page'?
09:20PM <cdegroot> also
09:21PM <cdegroot> whatever you want :-)
09:21PM <cdegroot> so you could give a trusted user an 'edit any page'
capability, which basically would be a key to unlock a key-box. The
key-box would hold capabilities for all the pages to edit them.
09:21PM <cdegroot> (or, rather, produce them on-the-fly).
09:22PM > ok
09:22PM <cdegroot> a less trusted user might receive capabilities on
specific pages.
09:22PM > yes, or if you have folder, it would mean that he might edit
only a subtree of the wiki
09:23PM <cdegroot> well, if you let that sort of stuff inherit.
09:23PM > and what if you only want to let users edit pages that they
created themselves?
09:23PM <cdegroot> but the basic idea is that every combo
'object/message' is protected by a capability. On top of that, you can
have capabilities that help you to access other capabilities, etcetera.
09:24PM <cdegroot> That's easy enough, because if you create something
you usually receive full capabilities on them.
09:24PM <cdegroot> In fact, the only way to get a capability is to get
it from someone else or to create the object (basically)
09:25PM > so implementation would be with a keyring class containing a
set of keys
09:25PM > so how do you check the capabilities when executing messages
09:25PM <cdegroot> You don't - capabilities *are* the message sends.
09:25PM > you don't want to have to check in each and every message
manually, no?
09:26PM > but this looks odd
09:26PM <cdegroot> so if you don't have a capability, you simply don't
have a way to express the action.
09:26PM > so you have to send all the messages to your keyring
09:26PM > how would this look in smalltalk?
09:26PM <cdegroot> no, to the capabilities.
09:26PM <cdegroot> well, you never see the original object.
09:27PM <cdegroot> only capabilities on the original object.
09:27PM > so you need to work with symbols?
09:27PM > message-sends?
09:27PM <cdegroot> (which, internally, holds a pointer to the object
you cannot access and implements #dnu to forward a selected set of
messages).
09:27PM <cdegroot> no, you just say 'someObject foo'
09:27PM > so you have proxies around everything?
09:27PM <cdegroot> but someObject is not the real object, it is your
capability on the object.
09:28PM <cdegroot> yup, basically secure proxies.
09:29PM > so every user wraps with its own proxies, this means quite a
heavy overhead, no?
09:29PM > and how is the wrapping done?
09:29PM > all results of a message send has to be wrapped, no?
09:29PM <cdegroot> lots of ways are possible. Easiest is by just
storing the proxies.
09:31PM <cdegroot> you need some sort of interaction between your
keyring and the storage in order to fetch object wrapped inside the
correct capabilities, but basically that's all doable.
09:32PM > yeah, but also if you get return values from your wrapped
object you have to wrap them ...
09:32PM > when returning collection you even have to do a deep-wrap ;-)
09:33PM <cdegroot> unless of course your keyring expresses your whole
view of the database. Then you're done - you just operate on your
keyring.
09:34PM > do you know any smalltalk examples of such an implementation?
09:34PM <cdegroot> nope.
09:34PM > i have only found Java and E implementations :-(
09:34PM <cdegroot> yup
09:34PM <water> squeak-E is getting close
09:35PM > ahh, didn't know about that
09:35PM <cdegroot> water: I thought E-language-on-top-of-Squeak was
furthest, not?
09:35PM <cdegroot> (as opposed to 'E-zen applied to Squeak')
09:35PM <water> cdegroot: he asked about smalltalk :P
09:36PM <cdegroot> anyway, if your keyring presents your view of the
database it becomes remarkably simple. Just another OODB.
09:36PM <water> cdegroot: and it's not E-language-on-top-of-squeak
09:36PM <water> cdegroot: it's E-concepts-embedded-in-squeak
09:37PM <smakbo> water: is this all happening offline?
09:37PM <cdegroot> so the language would be Smalltalk?
09:37PM <smakbo> I'm subscribed to the Squeak-E list, but haven't seen
any activity for quite a while
09:37PM <water> is what happening offline? the main author of it is Rob
Withers, who is "quotar" here
09:37PM <smakbo> ok
09:38PM <water> cdegroot: no, the language would be smalltalk modified
to better support the E model. just like AspectS isn't Smalltalk but is
an extension to support AspectJ concepts
09:39PM <cdegroot> yeah - that's what I meant.
09:39PM <cdegroot> Smalltalk ;-)
09:39PM <cdegroot> For Some Value Of Smalltalk[tm]
09:39PM * water rolls his eyes
09:39PM <cdegroot> I thought that one project was actually porting E on
top of the Squeak VM.
09:40PM <water> that's what the E fellows were considering
09:40PM <cdegroot> and that one was going reasonably well. But can't
remember - I've been so busy the past ~6 months that I only have
vaguely followed all this.
09:40PM <water> that's a total unknown
09:40PM <water> if you don't know, don't say
09:40PM <water> :P
09:41PM <cdegroot> anyway, lukas - try to think about modelling a
zope-like 'content database' with just caps. Probably after reading up
http://www.skyhunter.com/marcs/ewalnut.html#SEC41 - it's an interesting
exercise, and I think it is doable.
09:43PM <cdegroot> caps would probably be modelled basically by
keyboxes - probably a better metaphor than keyrings.
09:43PM <cdegroot> your password unlocks your keybox. In it are keys
directly to 'content objects', but probably also references to other
keyboxes.
09:44PM <cdegroot> For example, everyone would have a key to the
'anonymous' keybox, a) to access all the objects in there, and b) to
add stuff in there.
09:44PM <cdegroot> etcetera.
09:44PM > that sounds reasonable to have a kind of composite ...
09:44PM > of keyboxes
09:44PM > thanks for the link, but the java examples, arghhhh ...
09:44PM > ok, i won't complain ;-)
09:45PM <cdegroot> when you create an object, you stash the naked
object in your keybox and add some basic capabilities to other keyboxes
- that'd constitute publishing.
09:45PM <cdegroot> not java, the examples are in E
09:45PM > yeah, you are right of course, but it's quite close to java
;-)
09:46PM <cdegroot> for some cases you probably would need some way of
amplifying caps - if you have a cap on A and you also hand it a cap on
B, you might get a more powerful cap on A (or C) back.
09:46PM <cdegroot> lukas: I will not forward that comment to E's
author. He might take offense...
*** fragment joined channel #squeak at 09:46PM
09:47PM > why not?
09:47PM <cdegroot> because most of his writings contain passages about
how bad Java is ;-)
09:48PM > really? but why did he stick to that kind of style?
09:48PM <cdegroot> it's curlybraces style, but quite far removed from
Java I think.
09:49PM > anyway, the text about capabilities I read half a year ago
was with java-examples
09:49PM <cdegroot> if you have 'class' as a keyword and '{}' as
delimiter, it's hard not to be compared with Java ;-)
09:49PM > and it was painful trying to understand ...
09:49PM > or C++
09:49PM <cdegroot> E is actually quite a nice language. Too bad there's
no IDE, class browser, .. for it, b/c I don't do languages without them
anymore.
09:50PM <cdegroot> and it runs on top of Java :-(
09:50PM > yeah i know
09:50PM > why have they taken the java-vm and not dot-net or squeak or
...
09:51PM <cdegroot> anyway, in a web environment this whole capability
thingy would be perfectly secure. With a locally-connected Squeak
image, it'd become risky (not with a remote image in a client-server
configuration) - you'd need Squeak-E for the latter to work.
09:51PM <cdegroot> I think at the time the JavaVM was most readily
available.
09:52PM > i see and it is probably also possible to mix java and E, no?
09:52PM <cdegroot> yeah, but probably not with full security :-)
09:52PM > i once read an article how to wrap the FileStreams of Java
with E ...
09:53PM > there are some drawbacks of course ...
09:53PM > but that doesn't bother us ;-)
09:53PM <cdegroot> nope.
09:56PM <cdegroot> anyway, I think I'll give it a shot. At least I'll
be able to say "I tried it..."
09:56PM > cool, I am looking forward hearing from your experiences and
seeing the code
09:57PM <cdegroot> me too....
09:57PM * cdegroot looks over shoulder. Sh*t, nobody there
09:59PM <cdegroot> only issue is that I probably need a good OODB
underneath.
09:59PM <cdegroot> so, next question (is the group still with me?
guys?): Magma fit enough already?
09:59PM > yeah, lets come back to this issue ...
10:00PM > it would be cool to have something that does versions
automatically ...
*** efc joined channel #squeak at 10:00PM
10:00PM <cdegroot> versions?
10:00PM <cdegroot> (a bit overloaded term. Please specify :-))
10:00PM > like the zope-db, something of zope that is think is really
cool
10:01PM > and also quite secure, i've never heard of a zope-db-crash so
far
10:01PM <efc> Whats the address of the channel stats page thingy ?
10:01PM > am I talking too much?
10:01PM <efc> I think I know the server, but can't remember the page
hehe
10:01PM <efc> You're not taking my spot lukas!
10:02PM * water indicates the topic
10:02PM <efc> oh hehe
10:02PM <cdegroot> Zope DB is basically image+changelog :-)
10:02PM <efc> Who reads topics anyway..
10:03PM <cdegroot> (strike that smiley, on second thought)
10:04PM <cdegroot> lukas: it is impossible to 'crash' a transaction log.
10:04PM > yes, it is similar to PrefLayer or what was its name?
10:04PM <cdegroot> Prevayler. That's really image+changelog. Zope is
actually just changelog.
10:04PM > yeah ...
10:04PM > zope is only appending
10:05PM > so in the worst case if something goes wrong
10:05PM > you just cut the file
10:05PM > and have something valid again
10:05PM <cdegroot> yup. Downside: GC is necessary. But we have a >1Gig
ZEO db in production for almost two years now, never a problem.
10:05PM > although this is rarely needed, i 've never needed to do it
so far
10:05PM > yeah
10:06PM <cdegroot> biggest issue that kept me from writing one is a
*fast* marshaller.
10:06PM > but gc is easy, you just copy everything to a new file ...
10:06PM <cdegroot> no doubt about it ;-)
10:07PM <cdegroot> so, SRP, (Smart)RefStreams, ... - what would be a
good cPickle equivalent in Squeak?
10:07PM > well I've never used SRP
10:08PM > and I doubt that RefStreams work, as you have to keep the
references somehow up-to-date
10:09PM <cdegroot> references are always backwards in the file, so you
don't need to keep much up-to-date.
10:10PM > yeah but if you save a page, you don't want that the whole
wiki is coming with it. so how do you handle that?
10:10PM <cdegroot> cPickle lets you place methods on classes to replace
a 'serialize-by-value' with a 'serialize-by-ref'. That's a vital
component.
10:11PM > ok, that is cool. so do you think that we could use
SmartRefStreams to write to a Zope-DB like file?
10:12PM <water> and cPickle works on block closures and languages with
full GC's?
10:12PM <cdegroot> dunnow - I think it's a tad slow.
10:12PM <cdegroot> water: dunnow about the full GC bit, but python has
no block closures ;-)
10:12PM <water> cdegroot: right. so basically it's the same broken
pickle concept from python
10:13PM <cdegroot> cPickle = pickle
10:15PM <cdegroot> water - it might be broken in some ways, but it
works fine, is fast, and supports a lot of awfully useful tools.
10:16PM <cdegroot> but blocks do complicate matters, yes.
10:16PM <water> cdegroot: well then use magma
10:16PM > i do not get that, why do they complicate?
10:17PM <water> because they need to be lexical closures of at least
some kind
10:17PM <water> over their environment
10:17PM <cdegroot> water: I'm a bit (a lot) worried about all the
statements in the Magma docs re. the speed of collections.
*** dvf joined channel #squeak at 10:18PM
10:18PM <water> hi daniel
10:18PM <cdegroot> hi dvf
10:18PM <smakbo> hey d
10:18PM <water> cdegroot: well, you can worry until you're blue in the
face, or figure out how to improve it yourself instead of rolling
another pickle solution
10:19PM <cdegroot> oh, you're right there. However, it'd be nice if
there would be something akin to pickle for Squeak. Magma is not always
what you want...
10:20PM <water> nothing is ever always what you want
10:21PM <cdegroot> Furthermore, I'm looking at something to build
commercial projects on. A totally unproven OODB which is highly complex
is not something I am going to recommend to customers. Something
ZODB-like, where you can almost prove that you won't lose data, I'd do
a lot quicker.
10:22PM <cdegroot> (something that would stash everything in MySQL
without me having to break my head over the O/R gap, even quicker ;-))
10:22PM <efc> Are customers in Europe more willing to look at
non-"standard" solutions (not Microsoft and not Java) ?
10:23PM <cdegroot> Depends on the customer and the sort of solution.
10:23PM <cdegroot> If I build a website and I say 'Linux, MySQL,
Apache, and <something>', most of them will not really care (or know)
about the difference between something=PHP, Python, Perl, or Squeak.
--
Lukas Renggli
http://renggli.freezope.org
Hi Frank,
> As I am using in one of my case study for my diploma work SmallWiki, I
> am wondering if there is somewhere a "one paragraph explanation" what
> SmallWiki is?
the only thing I am able to provide right now is the following link,
where you might find what you are looking for ;-)
http://c2.com/cgi/wiki?SmallWiki
Btw, what kind of case study are you doing with SmallWiki?
HTH
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Bonjours,
> Si ca ne t'interesse pas de m'aider, pourrais-tu me refiler le mail de
> Lukas. Il parle francais?
oui je sais parler et écrire français un peu, mais il y a sûrement
beaucoup de fautes :-(
> Il me semblait que tu etais developpeur professionnel et donc que tu
> demandais des honoraires. Il n'y a vraiment pas de honte a demander de
> l'argent. Tout travail merite salaire.
>
> Serais-tu capable de m'aider a faire fonctionner Wiki Works (j'ecris
> un dictionnaire)?
> J'ai Windows 98.. Le plus simple serait de suivre les etapes que j'ai
> suivies: de telecharger Visual Works 7.1; installe-le sur n'importe
> quel Windows et on pourrait partir de la...
>
> Le probleme: je loade le parcel: Wikiworks. Je fais la commande: http:
> initializeWikiWorks sur un workplace et j'ai une erreur. Double
> dictionnaire dit-on. Home Page et Wiki Syntax.
Nous avons développe un nouveau wiki qui s' appelle SmallWiki est qui
est développé en VisualWorks. Nous avons créer un nouveau
implémentation, parce que ce n' était pas possible de faire des
extensions facilement en WikiWorks ou en SWiki.
SmallWiki est toujours en train de développement, mais c' est déjà
utilisable. Pour voir SmallWiki en action regardez à
http://kilana.unibe.ch:9090. Il y a aussi un peu de documentation
technique à http://scgwiki.iam.unibe.ch:8080/SCG/520 (en anglais) et la
mailing-list officielle est smallwiki(a)iam.unibe.ch.
Si vous avez des question comment on doit installer et utiliser
SmallWiki sur VisualWorks 7.1, contactez moi s' il vous plaît.
Lukas
--
Lukas Renggli
http://renggli.freezope.org
