Anyone know of any good resources for working with the validation system of
Magritte. Specifically I'm interested in what it takes to have fields that
depend on the value of each other. Say an end date that must be before a
start date, both of which have just been edited.
I was thinking something like this on the instance side...
description
^self class description collect: [:each |
each accessor selector = #eventEndDate
ifTrue: [each addCondition: [:value | value > self
eventStartDate]]
ifFalse: [each]]
But that doesn't work because I can't rely on eventStartDate having a value
yet, it may not have been set by its description, or it may be invalid for
some other reason. Are the any public sample apps that use Magritte heavily
one could look at?
Ramon Leon
http://onsmalltalk.com
Howdy
I just started looking at squeak and all the great toys it can
include. I asked about squeak wiki's on the beginners list and Keith
suggested I look at the preloaded image on www.squeak.org and join
this list.
I did Thanks! :-)
I am interested in squeak for education. We are setting up some
classes for kids (of all ages ;-) ) to learn programming. I had
included an intro to squeak in a class a few years ago and am glad I
can come back to look more.
I am looking into a wiki as one way the kids can collaborate. I ran
swiki and was pleased with the little I did with it. I am interested
in the differences between pier and swiki. I plan on working with pier
for at least the next little bit.
My adventures with pier so far are:
I installed on XP and poked a bit to see it up and running.
I then installed squeak on a ubuntu 6.06 linux box from
www.squeak.org. I realized I had not looked to see if squeak was
available from the ubuntu repositories and checked and :-) there it
was. I uninstalled the first copy and then installed from the
repositories.
I then ran with the preloaded pier image and was up in way less that 5
minutes (if you don't count the test on XP and the first load of
squeak) !!!
I added a page to the wiki and can see and edit from various computers
on our network.
I will play more if I have more time this weekend but it is looking good!
Gary
The process of porting minnow from swiki to pier, is likely to happen.
It will just require a little bit of patience, as the needed components
are road-tested and refined.
As you can imagine my own testing process has been somewhat hindered by
image freezes. Now that I have been informed that Squeak vm 3.6.3 is
actually stable. I have been able to create a pier-wiki with 6200 or
more pages for testing purposes.
Initial Stats Using Pier with PRNullPersistency (i.e. everything in
memory):
6200 pages (generated one for each squeak class from squeak sources)
235352 internal links.
Adding a page 100-500ms
Removing a page 215 seconds!!
(many wikis dont support removing pages anyway)
Total Memory = 77Mb.
Compare this to minnow: Text data of its 5889 pages is about 30Mb.
Of course the swiki, has full page history, and uploaded files too.
Pier Magma should be able to handle this kind of load, but it remains to
be explicitly tested.
Anticipated work to make things workable.
1. Some explicit caching of items that will slow pier-magma down with
data on disk rather than in memory. Removal of pages may be extremely
slow without this.
2. Explicit support for an indexed full text search which avoids the
need to traverse the whole data tree for a simple search.
3. Some form of logging of user edits in addition to the default
persistency strategy.
J J wrote:
>I would say go to Pier. I think Kieth released some software that you
can point >at the swiki and it will slurp it all up. Am I right Kieth?
I haven't written any proper data slurper for minnow. I believe there is
already an importing tool. I have pointed wget at minnow to get the
current set of pages as a test data set. Its about 30Mb or so.
Which leads me to a question. How would pier handle some random person
running this script?
#!/usr/bin/ruby
for i in 1..5889
print `wget --user=squeak --password=viewpoints
http://minnow.cc.gatech.edu/squeak/#{i
}.edit`
end
this would probably create almost 5800 seaside sessions, in a matter of
minutes?
Keith
Send instant messages to your online friends http://uk.messenger.yahoo.com
>> No problem. Check out this announcement, it has an example on how
>> to plug together the Comanche modules for a Seaside application:
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/
>> 058314.html You might also want to have a look at how WAKom itself
>> sets up the server (and modify this behavior).
> Thanks Lukas. That gets me a file server... as probably you wanted
> me to know.
> If you have any pointers, I'd appreciate it. I'm just trying to get
> the squeakfoundation.org going and Ken would rather not add any
> more rules.
Yes, but you need to modify the example to add Seaside to the root
and not to enable file-serving. Something like this might work:
| ma seaside |
seaside := WAKom new.
ma := ModuleAssembly core.
ma addPlug: [:request | seaside process: request]].
(HttpService startOn: 8080 named: 'httpd') plug: ma rootModule
I've never tried, this is just a guess from what I saw in this mail.
> Ken: there is a fundamental problem on the pointer. Going to
> www.squeakfoundation.org is not problem. But, if you hoover over
> any link, you'll see that it links to : http://127.0.0.1:7780/ ...
In the Seaside application configuration there is also a setting to
change the host-name and host-port. Unfortunately Kom (and Apache 1)
does not communicate that correctly to Seaside figure it out by itself.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
PRPier running with PRNullPersistency
6200 pages in 78Mb
Remove page 215 seconds.
18600 pages in 130 Mb
Remove page 500seconds!
It does take quite a while to copy 6200 pages ~10 Mins, but it does do it.
Keith
Send instant messages to your online friends http://uk.messenger.yahoo.com
> With respect to the other walk back. I am using a completely fresh
> image all the latest sources from monticello.
>
> (see http://smallwiki.unibe.ch/smallwiki/pier/
> installationofseasidemagmaandpier)
I get an error with the installer that #isArray is not understood in
a 3.8 image ... though that is quickly fixed.
Now I understand what you installer scripts are all about. Really
cool is the thing with #answer:with:. In wonder why you have
everything in a single class and not have subclasses for SqueakMap,
Mantis, SqueakSource, etc?
> similar walkbacks are occuring which leads me to beleive that there
> is something missing from the magritte code. Is there an update
> that has missed being checked in?
Ouch, I found a bug in Magritte that was introduced with another
project and caused some problems in Pier. Unfortunately I never
tested the latest version of Magritte together with Pier.
The problem should be fixed now.
Name: Magritte-All-lr.172
Author: lr
Time: 20 October 2006, 11:13:06 am
UUID: 707fe363-6537-4ac4-b947-e92531149efd
Ancestors: Magritte-All-lr.171
Dependencies: Magritte-Model-lr.225, Magritte-Tests-lr.95, Magritte-
Seaside-lr.198, Magritte-Morph-lr.33
- fixed a bug for single-selection and multiple-selection rendering
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Is there a way to easily change the text in the header of Pier to
something different than the object created? When editing the
environment/header I just receive the option to change the component
type and it's name. Obviously, the concept is lost on me.
brad
Whenever I try to access some form component of the model. Whether in
Pier or in my own testing of Magritte, I this error.
"Error: My subclass should have overridden #build:"
I've searched the documentation. Yet, I couldn't find anything about
how to override "build:". Also because it is happening in Pier, not
just my own implementation of Magritte. I'm assuming something else
is at fault.
Anyone have any ideas. Thanks.
--
Jason Yates
jaywhy(a)gmail.com
