Hi,
is there any photo gallery available for Pier? I mean a widget where I
could upload pictures and they are rendered in a nice way. I started
one 4 years ago but I abandoned it.
Bye
--
Damien Cassou
http://damiencassou.seasidehosting.st
Hi,
I've completed an initial port of Pier 3 (Pier using Magritte 3
descriptions) to Gemstone.
It can be loaded in Gemstone using:
Gofer it
> squeaksource: 'MetacelloRepository';
> package: 'ConfigurationOfPier3AddOns';
> load.
>
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
> ConfigurationOfPier3AddOns load ].
By default this configuration will load Pier-Admin and the Pier add-ons
necessary to make this work - (Pier-Admin is described in this screen-cast:
http://vimeo.com/32749535)
Let me know how you get on,
Nick
Hi,
I just wanted to let you know that the Glamour and Metanool (transformation engine between Fame and Magritte) are now using Magritte 3.
Consequently, in the latest Moose image you will find Magritte 3.
Cheers,
Doru
--
www.tudorgirba.com
Things happen when they happen,
not when you talk about them happening.
Hi,
Magritte 3 is now available for Gemstone - with tests green. The
configuration has been updated and I loaded Magritte 3 with:
Gofer it
squeaksource: 'MetacelloRepository';
package: 'ConfigurationOfMagritte3';
load.
MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
ConfigurationOfMagritte3 project stableVersion load: #('Seaside Tests') ].
However the tests run extremely slowly - in the test suite I've measured
20x slowdown between Magritte 2 and Magritte 3 - making the tests a pain to
execute.
I've run a series of tests to characterise where the problem might be. The
tests are as follows:
-----
1) Test-suite benchmark:
| testSuite |
testSuite := (OBClassCategoryNode on: 'Magritte-Tests-Model-Description')
classes
inject: TestSuite new
into: [:suite :classNode |
(classNode theClass inheritsFrom: TestCase)
ifTrue: [suite addTests: classNode theClass suite tests].
suite].
Time millisecondsToRun: [ testSuite run ].
2) Description benchmark:
Magritte 2:
Time millisecondsToRun:
[100 timesRepeat: [ MABooleanDescription description ] ].
Magritte 3:
Time millisecondsToRun:
[100 timesRepeat: [ MABooleanDescription new magritteDescription ] ].
3) Micro-benchmark
Magritte 2:
Time millisecondsToRun:
[100 timesRepeat: [ MABooleanDescription class allSelectors select: [
:each | each isDescriptionSelector ] ] ].
Magritte 3:
Time millisecondsToRun:
[100 timesRepeat: [ Pragma allNamed: MAPragmaBuilder
magritteDescriptionPragma from: MABooleanDescription to: Object ] ].
* The micro-benchmark is illustrative of the difference between Magritte 2
and Magritte 3 - Magritte 2 uses a naming convention to retrieve
descriptions, whereas Magritte 3 uses Pragmas.
-----
Results:
Pharo Magritte 2: (1) 436 (2) 0 (3) 85
Pharo Magritte 3: (1) 743 (2) 58 (3) 12
Gemstone Magritte 2: (1) 988 (2) 30 (3) 2229
Gemstone Magritte 3: (1) 21663 (2) 1575 (3) 444
Cavet: Although Gemstone and Pharo are running on the same machine -
Gemstone is running virtualised in a VMWare Linux installation, so the
results are not directly comparable, although the 30x performance decrease
between Pharo and Gemstone surprised me.
First the good news:
For Magritte the pragma description look-up is more performant than the
named-based lookup (micro-benchmark (3)).
Now the bad news:
In Pharo Magritte 2 is faster then Magritte 3 when running a description
lookup based test-suite containing 1416 tests. My feeling is that in the
context of a real application performing a smaller number of lookups this
is probably not significant.
However in Gemstone the performance degradation is more noticeable and if
nothing else makes running the tests painful.
How to proceed:
Magritte 2's performance advantage is gained from caching the descriptions.
However I think the benefits of having dynamic (non-caching) descriptions
outweigh the disadvantages and I'd be reluctant to add a generic layer of
caching. In Pharo I don't think this is an issue. However in Gemstone I
feel that these numbers need some further investigation.
Any thoughts how to proceed?
Nick
Hi,
I'm pleased to announce a new version of Magritte - Magritte 3. The
rational for Magritte 3 is eloquently described by Lukas in his mail below.
The work on Magritte 3 was started by Esteban and completed by myself.
I've created a screen-cast which describes:
- the rational for Magritte 3
- the refactorings available to ease the transition from Magritte 1 or
2 to Magritte 3
- A walk-through of updating a sample from Magritte 2 to Magritte 3.
The screen-cast is on vimeo at:
http://vimeo.com/37032840
The sample used in screen-cast can be downloaded as:
Gofer it
> url: 'http://ss3.gemstone.com/ss/MagritteMagic';
> package: 'ConfigurationOfMagritteMagic';
> load.
>
> (Smalltalk at: #ConfigurationOfMagritteMagic) load.
The slides used in the screen-case can be viewed on slideshare at:
http://www.slideshare.net/nickager/magritte3
Enjoy
Nick
---------- Forwarded message ----------
From: Lukas Renggli <renggli(a)gmail.com>
Date: 17 November 2010 17:21
Subject: Re: Providing lookup environment for descriptions
To: "Magritte, Pier and Related Tools ..." <smallwiki(a)iam.unibe.ch>
The way Magritte builds descriptions by default has become quite a
nuisance. I think that at some point Magritte should be improved
in that regard. I wrote a proposal this summer for how to proceed,
but of course I had to finish my writing and never actually
found the time to implement it:
--------------------
I propose to perform the following (non-backward compatible) changes
in the Magritte 2 code-base to resolve some major annoyances and
issues that keep on reoccurring:
- Move descriptions from class-side to instance-side. This resolves
various issues such as cache-invalidation, instance specific
descriptions, dynamic descriptions, context dependent descriptions,
etc. Furthermore the descriptions will be closer to the code they
describe and it will be possible to describe class- and instance-side
of an object, not just the instance-side.
- Rename the method #description as the default entry point into
Magritte to #magritteDescription. This avoids common problems where
the domain model already defines such a method.
- Instead of using a naming convention for description methods, use a
pragma called <magritteDescription> to annotate the methods. And to extend
and
change existing descriptions use <magritteDescription: aSelector>. Finally
all
Smalltalk implementation reached a consensus of pragmas that can be
safely used cross-platform.
All in all the "new" Magritte would look like in the following
example. Imagine a shop item with the accessor #place:
Item>>place
^ place
Item>>place: aString
place := aString
The meta-description is defined on the instance-side and annotated. It
can refer to itself for the possible places:
Item>>placeDescription
<magritteDescription>
^ MASingleOptionDescription new
options: self possiblePlaces;
label: 'Place of Item';
accessor: #place;
yourself
Class extensions can modify a description using:
Item>>placeDescriptionXmlStorage: aDescription
<magritteDescription: #placeDescription>
^ placeDescription xmlTag: 'xname'
Since these changes are not backward compatible I'll try to provide
automatic refactorings for most parts. Moving existing code to the new
codebase will certainly cause some problems, but in the long run I
believe this to be a much better approach than the current one. If
people have any feedback, concerns or other changes that would be
important in the same run I am happy to hear them.
hi all..
say i have a component.. call "stories"
this has many children:
"story 1"
"story 2"
"story 3"
so, all i want to do is list all the stories in the component..
so, stories would have:
+value:children+
everything works just fine..
so.. now, i'd like to embed this component in another page..
i end up with a page with this:
some text.. blah blah .. here is my list of stories:
+stories+
the problem is, it wants to rembed value:children with respect to the
current structure (which, according to the docs, is what it should
do)..
but i would rather have the the children render relative to the
containing structure..
i hope this all makes sense ..
anyone have any ideas?
thanks!
--
----
peace,
sergio
photographer, journalist, visionary
http://www.CodingForHire.comhttp://www.coffee-black.comhttp://www.painlessfrugality.comhttp://www.twitter.com/sergio_101http://www.facebook.com/sergio101
Hi,
When I translated #description to #magritteDescription I noticed that both
MAComponent and Object implement #description and now in Magritte 3 both
implement #magritteDescription.
It seems that MAComponent>>#description/#magritteDescription is a redundant
redefinition of Object>>#description/#magritteDescription. Any reason for
it's existence?
Nick
