From stephan at stack.nl Tue Jan 2 10:57:53 2007 From: stephan at stack.nl (Stephan Eggermont) Date: Tue, 2 Jan 2007 10:57:53 +0100 Subject: Image size growing very fast In-Reply-To: <67628d690612200539k42ea4839s52fe27a8d379fff@mail.gmail.com> References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com> <67628d690612200539k42ea4839s52fe27a8d379fff@mail.gmail.com> Message-ID: <20070102095753.GA31846@stack.nl> Hello, I've had an image (based on the one from Ramon Leon) growing from 30 MB to 675 MB in a very short time when developing an application with Magritte (Magritte-Model-lr.228, Magritte-Seaside-rjl.204, Seaside2.7a1-lr.137). It has become rather unresponsive, and when trying to find out where the memory was used a LowSpaceDebug.log was created. Any clues? Stephan Eggermont From renggli at iam.unibe.ch Tue Jan 2 13:21:36 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 2 Jan 2007 13:21:36 +0100 Subject: Image size growing very fast In-Reply-To: <20070102095753.GA31846@stack.nl> References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com> <67628d690612200539k42ea4839s52fe27a8d379fff@mail.gmail.com> <20070102095753.GA31846@stack.nl> Message-ID: > I've had an image (based on the one from Ramon Leon) growing > from 30 MB to 675 MB in a very short time when developing an > application with Magritte (Magritte-Model-lr.228, > Magritte-Seaside-rjl.204, Seaside2.7a1-lr.137). > It has become rather unresponsive, and when trying to find out > where the memory was used a LowSpaceDebug.log was created. Usually this should not happen. > Any clues? Things you might want to check: 1. Open the process browser and check if there are any runaway processes, if so there must be an unconditional recursion somewhere in your application. This can also happen if you have accidently defined descriptions that depend on each other (reference descriptions). 2. Evaluate "WARegistry clearAllHanders. Smalltalk garbageCollect". If this reduces the image size then your sessions somehow reference a lot of data. This can happen if you have an OODB and somehow pull-in a copy of a huge amount of data for every session. 3. Evaluate "MCFileBasedRepository flushAllCaches. Smalltalk garbageCollect". Also search the Seaside mailing-list. There were a couple of threads about reducing the image size with other solutions ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch From stephan at stack.nl Thu Jan 4 15:31:29 2007 From: stephan at stack.nl (Stephan Eggermont) Date: Thu, 4 Jan 2007 15:31:29 +0100 Subject: Image size growing very fast In-Reply-To: References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com> <67628d690612200539k42ea4839s52fe27a8d379fff@mail.gmail.com> <20070102095753.GA31846@stack.nl> Message-ID: <20070104143129.GA82935@stack.nl> On Tue, Jan 02, 2007 at 01:21:36PM +0100, Lukas Renggli wrote: > Things you might want to check: > > 1. Open the process browser and check if there are any runaway > processes, if so there must be an unconditional recursion somewhere > in your application. This can also happen if you have accidently > defined descriptions that depend on each other (reference descriptions). Uhhm, how do I see if a process is runaway? It has to be, as the task manager shows 50% CPU use (dual core), and Mem usage keeps growing. I have about 15 minutes to do something in the image before it crashes. Stephan From renggli at iam.unibe.ch Thu Jan 4 15:42:58 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 4 Jan 2007 15:42:58 +0100 Subject: Image size growing very fast In-Reply-To: <20070104143129.GA82935@stack.nl> References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com> <67628d690612200539k42ea4839s52fe27a8d379fff@mail.gmail.com> <20070102095753.GA31846@stack.nl> <20070104143129.GA82935@stack.nl> Message-ID: <45635AD0-7BB7-47EC-A4E9-4B108DCE7ED3@iam.unibe.ch> > Uhhm, how do I see if a process is runaway? It has to be, as the > task manager shows 50% CPU use (dual core), and Mem usage keeps > growing. I have about 15 minutes to do something in the image > before it crashes. Usually a few seconds are enough to save an image ;-) If you can mail it to me or put it online somewhere (compressed), I can have a look. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From philippe.marschall at gmail.com Thu Jan 4 17:50:23 2007 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Thu, 4 Jan 2007 17:50:23 +0100 Subject: Image size growing very fast In-Reply-To: <20070104143129.GA82935@stack.nl> References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com> <67628d690612200539k42ea4839s52fe27a8d379fff@mail.gmail.com> <20070102095753.GA31846@stack.nl> <20070104143129.GA82935@stack.nl> Message-ID: <66666f210701040850k645e825fgffdf0ae63383db95@mail.gmail.com> 2007/1/4, Stephan Eggermont : > On Tue, Jan 02, 2007 at 01:21:36PM +0100, Lukas Renggli wrote: > > Things you might want to check: > > > > 1. Open the process browser and check if there are any runaway > > processes, if so there must be an unconditional recursion somewhere > > in your application. This can also happen if you have accidently > > defined descriptions that depend on each other (reference descriptions). > > Uhhm, how do I see if a process is runaway? It has to be, as the > task manager shows 50% CPU use (dual core), and Mem usage keeps > growing. I have about 15 minutes to do something in the image before > it crashes. Constant 50% on a dual core cpu = runaway process Philippe From renggli at iam.unibe.ch Thu Jan 4 18:38:09 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 4 Jan 2007 18:38:09 +0100 Subject: Image size growing very fast In-Reply-To: <20070104143129.GA82935@stack.nl> References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com> <67628d690612200539k42ea4839s52fe27a8d379fff@mail.gmail.com> <20070102095753.GA31846@stack.nl> <20070104143129.GA82935@stack.nl> Message-ID: <8985B663-BC91-4755-89C0-BF2BF4191A3D@iam.unibe.ch> >> 1. Open the process browser and check if there are any runaway >> processes, if so there must be an unconditional recursion somewhere >> in your application. This can also happen if you have accidently >> defined descriptions that depend on each other (reference >> descriptions). > > Uhhm, how do I see if a process is runaway? It has to be, as the > task manager shows 50% CPU use (dual core), and Mem usage keeps > growing. I have about 15 minutes to do something in the image before > it crashes. I had a look at the image you provided and found the issue I mentioned in the first mail: > 1. Open the process browser and check if there are any runaway > processes, if so there must be an unconditional recursion somewhere > in your application. This can also happen if you have accidently > defined descriptions that depend on each other (reference > descriptions). In your case there was a process trying to validate descriptions that circularly reference each other. Unfortunately Magritte does not detect such situations automatically. I didn't look at your code, but there are certainly different possibilities to solve the problem: - Break circular references in your static or dynamic descriptions explicitly (this is what I suggest and what I do in such cases) - Change the validation implementation to not follow reference descriptions or (better yet) implement it so that it doesn't validate the same object multiple times. PS: I will send you a link where you can download the working image in private. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From ramon.leon at allresnet.com Mon Jan 8 19:50:59 2007 From: ramon.leon at allresnet.com (Ramon Leon) Date: Mon, 8 Jan 2007 11:50:59 -0700 Subject: Magritte and Pragmas Message-ID: <00ee01c73355$f01a4a40$9700a8c0@hq.allresnet.com> Is anyone using Pragmas in 3.9 to do Magritte descriptions? If so, are there any samples anywhere? Ramon Leon http://onsmalltalk.com From ducasse at iam.unibe.ch Mon Jan 8 20:32:45 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Mon, 8 Jan 2007 20:32:45 +0100 Subject: Magritte and Pragmas In-Reply-To: <00ee01c73355$f01a4a40$9700a8c0@hq.allresnet.com> References: <00ee01c73355$f01a4a40$9700a8c0@hq.allresnet.com> Message-ID: <8192C413-F098-4D32-ACCE-C8917B7F92D0@iam.unibe.ch> not that I know but indeed this would be great :) Lukas was planning to do something along this path. At least we should learn if they scale for complex description. stef On 8 janv. 07, at 19:50, Ramon Leon wrote: > Is anyone using Pragmas in 3.9 to do Magritte descriptions? If so, > are > there any samples anywhere? > > Ramon Leon > http://onsmalltalk.com > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From damien.cassou at laposte.net Mon Jan 8 21:12:15 2007 From: damien.cassou at laposte.net (Damien Cassou) Date: Mon, 08 Jan 2007 21:12:15 +0100 Subject: Magritte and Pragmas In-Reply-To: <00ee01c73355$f01a4a40$9700a8c0@hq.allresnet.com> References: <00ee01c73355$f01a4a40$9700a8c0@hq.allresnet.com> Message-ID: <45A2A59F.7060302@laposte.net> Ramon Leon a ?crit : > Is anyone using Pragmas in 3.9 to do Magritte descriptions? If so, are > there any samples anywhere? What do you mean "using pragmas" ? Can you give us a simple example please ? Do you mean a pragma to avoid starting method names by "description" ? I don't think so but it should be easily done if not already. From ducasse at iam.unibe.ch Mon Jan 8 21:18:50 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Mon, 8 Jan 2007 21:18:50 +0100 Subject: Magritte and Pragmas In-Reply-To: <45A2A59F.7060302@laposte.net> References: <00ee01c73355$f01a4a40$9700a8c0@hq.allresnet.com> <45A2A59F.7060302@laposte.net> Message-ID: <69D72F6E-D22C-4647-8250-39967EBDBE32@iam.unibe.ch> On 8 janv. 07, at 21:12, Damien Cassou wrote: > Ramon Leon a ?crit : >> Is anyone using Pragmas in 3.9 to do Magritte descriptions? If >> so, are >> there any samples anywhere? > > What do you mean "using pragmas" ? Can you give us a simple example > please ? > > Do you mean a pragma to avoid starting method names by "description" ? yeap > I > don't think so but it should be easily done if not already. From renggli at iam.unibe.ch Mon Jan 8 21:41:49 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 8 Jan 2007 21:41:49 +0100 Subject: Magritte and Pragmas In-Reply-To: <00ee01c73355$f01a4a40$9700a8c0@hq.allresnet.com> References: <00ee01c73355$f01a4a40$9700a8c0@hq.allresnet.com> Message-ID: <9B2C1A42-750E-40B9-9BB4-BC462001FA88@iam.unibe.ch> > Is anyone using Pragmas in 3.9 to do Magritte descriptions? If so, > are > there any samples anywhere? Yes, it is doable and there was an implementation some time ago in the Magritte-Model package. The class was called MAPragmaBuilder a subclass of MADescriptionBuilder. - The reason that there were no examples was because code using Pragmas cannot be loaded into 3.7 and 3.8 images, and we still have a few of those that work with the latest version of Magritte. I know that others are using Magritte with older Squeak versions as well. - Therefor I removed MAPragmaBuilder from Magritte-Model, in one of the latest cleaning efforts as it was never used ... now that you ask, it might have been the wrong decision. You can reload it by browsing the code of Magritte-Model-lr.228 and load the class. To activate it you need to evaluate: MADescriptionBuilder default: MAPragmaBuilder new Then you can put your descriptions in a method like: Address class>>street ^ MAStringDescription selector: #street You can use class extensions to extend existing descriptions from a different package: Address class>>streetAddendum: aDescription ^ aDescription beReadonly It doesn't matter much for speed. And this implementation is conceptually very close to the naming convention. PS: I think it would be better to actually put the descriptions into accessors (move them to to instance-side), but this means to change a few others things and I didn't find the time to do that yet. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From philippe.marschall at gmail.com Mon Jan 8 22:11:40 2007 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Mon, 8 Jan 2007 22:11:40 +0100 Subject: Magritte and Pragmas In-Reply-To: <9B2C1A42-750E-40B9-9BB4-BC462001FA88@iam.unibe.ch> References: <00ee01c73355$f01a4a40$9700a8c0@hq.allresnet.com> <9B2C1A42-750E-40B9-9BB4-BC462001FA88@iam.unibe.ch> Message-ID: <66666f210701081311l967f232l400487b1ba19380b@mail.gmail.com> 2007/1/8, Lukas Renggli : > > Is anyone using Pragmas in 3.9 to do Magritte descriptions? If so, > > are > > there any samples anywhere? > > Yes, it is doable and there was an implementation some time ago in > the Magritte-Model package. The class was called MAPragmaBuilder a > subclass of MADescriptionBuilder. > > - The reason that there were no examples was because code using > Pragmas cannot be loaded into 3.7 and 3.8 images, and we still have a > few of those that work with the latest version of Magritte. I know > that others are using Magritte with older Squeak versions as well. > > - Therefor I removed MAPragmaBuilder from Magritte-Model, in one of > the latest cleaning efforts as it was never used ... now that you > ask, it might have been the wrong decision. You can reload it by > browsing the code of Magritte-Model-lr.228 and load the class. To > activate it you need to evaluate: > > MADescriptionBuilder default: MAPragmaBuilder new > > Then you can put your descriptions in a method like: > > Address class>>street > > ^ MAStringDescription selector: #street > > You can use class extensions to extend existing descriptions from a > different package: > > Address class>>streetAddendum: aDescription > > ^ aDescription beReadonly > > It doesn't matter much for speed. And this implementation is > conceptually very close to the naming convention. > > PS: I think it would be better to actually put the descriptions into > accessors (move them to to instance-side), but this means to change a > few others things and I didn't find the time to do that yet. Well I actually have a package that uses Magritte and will only load into 3.9 because it uses Traits [1] so I'd be definitely interesed in this. The only requirement I have is that it must play nice along with the old way for legacy applications such as Pier ;) [1] http://mc.lukas-renggli.ch/audioscrobbler.html Cheers Philippe From ramon.leon at allresnet.com Mon Jan 8 22:55:38 2007 From: ramon.leon at allresnet.com (Ramon Leon) Date: Mon, 8 Jan 2007 14:55:38 -0700 Subject: Magritte and Pragmas In-Reply-To: <9B2C1A42-750E-40B9-9BB4-BC462001FA88@iam.unibe.ch> Message-ID: <010d01c7336f$c4e29ac0$9700a8c0@hq.allresnet.com> > Then you can put your descriptions in a method like: > > Address class>>street > > ^ MAStringDescription selector: #street > > Cheers, > Lukas Oh... You're just trying to avoid the description naming pattern, I see. I was thinking something more along the lines of something on the accessors directly... Post>>author ^author Post>>comments ^comments Post>>title ^title Post>>body ^body Post>>isPublished ^isPublished And generating Magritte descriptions from the metadata and not using class side descriptions at all. Or maybe just by default, and falling back on class side descriptions for complex cases. Ramon Leon http://onsmalltalk.com From sebjulliand at gmail.com Mon Jan 8 23:04:53 2007 From: sebjulliand at gmail.com (=?ISO-8859-1?Q?S=E9bastien_Julliand?=) Date: Mon, 8 Jan 2007 23:04:53 +0100 Subject: Pier tools & Query engine Message-ID: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> Hi there! I'd like to ask Pier users what kind of tools could be useful in order to easily maintain their wiki (something like some reporting tools, specific search queries and so on...). We (me and a colleague) will work on this subject and try to make Pier's administrators life easier ;), with the help of Stef Ducasse. We have already some ideas but any other useful ideas are welcome. In the end, we would like to define an advanced query component for Pier. By the way, Lukas, you said that you have already done some work on a previous query component but you lacked the time to finish it. Can you send us what you have done or at least give us some hints? Thanks in advance. Cheers (and happy new year!), S?bastien -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20070108/f3c79a73/attachment.html From renggli at iam.unibe.ch Mon Jan 8 23:44:16 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 8 Jan 2007 23:44:16 +0100 Subject: Magritte and Pragmas In-Reply-To: <010d01c7336f$c4e29ac0$9700a8c0@hq.allresnet.com> References: <010d01c7336f$c4e29ac0$9700a8c0@hq.allresnet.com> Message-ID: <13B5650E-8758-41C1-AB86-78326C380C58@iam.unibe.ch> > Oh... You're just trying to avoid the description naming pattern, I > see. I was thinking something more along the lines of something on > the accessors directly... > > Post>>author > > > > > > > ^author Yes, that is certainly possible as well. You just have to write your own description builder ;-) I am happy to integrate that. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From ramon.leon at allresnet.com Tue Jan 9 00:02:11 2007 From: ramon.leon at allresnet.com (Ramon Leon) Date: Mon, 8 Jan 2007 16:02:11 -0700 Subject: Magritte and Pragmas In-Reply-To: <13B5650E-8758-41C1-AB86-78326C380C58@iam.unibe.ch> Message-ID: <011a01c73379$07f84900$9700a8c0@hq.allresnet.com> > > Post>>author > > > > > > > > > > > > > > ^author > > Yes, that is certainly possible as well. You just have to > write your own description builder ;-) > > I am happy to integrate that. > > Lukas Yea, one of the things I love about Magritte, everything's pluggable. If I do it, which I very likely will, I'll definitely contribute it. Ramon Leon http://onsmalltalk.com From philippe.marschall at gmail.com Tue Jan 9 06:50:07 2007 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Tue, 9 Jan 2007 06:50:07 +0100 Subject: Magritte and Pragmas In-Reply-To: <010d01c7336f$c4e29ac0$9700a8c0@hq.allresnet.com> References: <9B2C1A42-750E-40B9-9BB4-BC462001FA88@iam.unibe.ch> <010d01c7336f$c4e29ac0$9700a8c0@hq.allresnet.com> Message-ID: <66666f210701082150t14a9ef35ice9cd9744e011c58@mail.gmail.com> 2007/1/8, Ramon Leon : > > Then you can put your descriptions in a method like: > > > > Address class>>street > > > > ^ MAStringDescription selector: #street > > > > Cheers, > > Lukas > > Oh... You're just trying to avoid the description naming pattern, I see. I > was thinking something more along the lines of something on the accessors > directly... > > Post>>author > > > > > > > ^author > > Post>>comments > > > > ^comments > > Post>>title > > > > > ^title > > Post>>body > > > > ^body > > Post>>isPublished > > > > ^isPublished This has one problem: sends do not work and neither do classes. As an example the following can not be converted to this style: - PRAddCommand >> #descriptionType - PRCommandsWidget >> #descriptionCommandClasses Philippe > And generating Magritte descriptions from the metadata and not using class > side descriptions at all. Or maybe just by default, and falling back on > class side descriptions for complex cases. From philippe.marschall at gmail.com Tue Jan 9 07:19:33 2007 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Tue, 9 Jan 2007 07:19:33 +0100 Subject: Pier tools & Query engine In-Reply-To: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> References: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> Message-ID: <66666f210701082219j5649d45fyd4428c91aec30e53@mail.gmail.com> 2007/1/8, S?bastien Julliand : > Hi there! > > I'd like to ask Pier users what kind of tools could be useful in order to > easily maintain their wiki (something like some > reporting tools, specific search queries and so on...). We > (me and a colleague) will work on this subject and try to > make Pier's administrators life easier ;), with the help of > Stef Ducasse. We have already some ideas > but any other useful ideas are welcome. In the end, we > would like to define an advanced query component > for Pier. > > By the way, Lukas, you said that you have already done some > work on a previous query component but you > lacked the time to finish it. Can you send us what you > have done or at least give us some hints? > Thanks in advance. > > Cheers (and happy new year!), > S?bastien The following is all not query related - if the kernel mutex is once a again fucked, replace it with a new one - bring back the in-place-edit-command - diff/cvs annotate. And please tree based, not of line based. As for query engine, well it has to compete with google: Enter two search terms and it finds what you are looking for. Cheers Philippe From renggli at iam.unibe.ch Tue Jan 9 07:43:15 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 9 Jan 2007 07:43:15 +0100 Subject: Pier tools & Query engine In-Reply-To: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> References: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> Message-ID: <71260F28-DB21-40A6-A86E-FF598B253ECC@iam.unibe.ch> Hi, > By the way, Lukas, you said that you have already done some work on > a previous query component but you lacked the time to finish it. > Can you send us what you have done or at least give us some hints? > Thanks in advance. there are several sources (an I am sure there are more), but they are all very old and require significant work to make it load and run: - A group of students wrote sort of a refactoring engine, it can be loaded from . - Earlier versions of Magritte (e.g. see Magritte-Model.150) had a parser (MARelationParser) for a constraint language. - Erlier versions of Magritte used this contraint language for searching in Pier (e.g. PRSearchWidget in Pier-Seaside.lr.26). - A longer time there was the beginning of a visual interface (like the Apple Finder Search) in Pier, but I can find the version right now. It must be somewhere in Pier-Seaside.lr ... All versions given here are just the first version I found with the given code, for actual usage you have to look for the latest version for yourself ;-) Hope this helps, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From philippe.marschall at gmail.com Tue Jan 9 08:04:37 2007 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Tue, 9 Jan 2007 08:04:37 +0100 Subject: Pier tools & Query engine In-Reply-To: <71260F28-DB21-40A6-A86E-FF598B253ECC@iam.unibe.ch> References: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> <71260F28-DB21-40A6-A86E-FF598B253ECC@iam.unibe.ch> Message-ID: <66666f210701082304u6edb2e29pb4cd8a8d2df33204@mail.gmail.com> 2007/1/9, Lukas Renggli : > Hi, > > > By the way, Lukas, you said that you have already done some work on > > a previous query component but you lacked the time to finish it. > > Can you send us what you have done or at least give us some hints? > > Thanks in advance. > > there are several sources (an I am sure there are more), but they are > all very old and require significant work to make it load and run: > > - A group of students wrote sort of a refactoring engine, it can be > loaded from . Thou shalt not use kilana! ;) http://www.squeaksource.com/SW2NKDS/ http://smallwiki.unibe.ch/advanceddesignlabs/refactoringengine/ Philippe > - Earlier versions of Magritte (e.g. see Magritte-Model.150) had a > parser (MARelationParser) for a constraint language. > > - Erlier versions of Magritte used this contraint language for > searching in Pier (e.g. PRSearchWidget in Pier-Seaside.lr.26). > > - A longer time there was the beginning of a visual interface (like > the Apple Finder Search) in Pier, but I can find the version right > now. It must be somewhere in Pier-Seaside.lr ... > > All versions given here are just the first version I found with the > given code, for actual usage you have to look for the latest version > for yourself ;-) > > Hope this helps, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From ducasse at iam.unibe.ch Tue Jan 9 11:24:06 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Tue, 9 Jan 2007 11:24:06 +0100 Subject: Magritte and Pragmas In-Reply-To: <13B5650E-8758-41C1-AB86-78326C380C58@iam.unibe.ch> References: <010d01c7336f$c4e29ac0$9700a8c0@hq.allresnet.com> <13B5650E-8758-41C1-AB86-78326C380C58@iam.unibe.ch> Message-ID: <6DCD41C4-6FA3-477F-A7CA-C8252AB1B8A3@iam.unibe.ch> hi ramon I thought about that too. The questions after is how much extensibility do we want. I do not have the answer just meat questions: Will we have the declare new pragmas each time you add a new property to a description. Do we really want that? what are the benefits? over class side single description? I think that this is not clear to me what is really the gain to have fine-grained pragmas. On 8 janv. 07, at 23:44, Lukas Renggli wrote: >> Oh... You're just trying to avoid the description naming pattern, I >> see. I was thinking something more along the lines of something on >> the accessors directly... >> >> Post>>author >> >> >> >> >> >> >> ^author > > Yes, that is certainly possible as well. You just have to write your > own description builder ;-) > > I am happy to integrate that. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From ducasse at iam.unibe.ch Tue Jan 9 11:29:33 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Tue, 9 Jan 2007 11:29:33 +0100 Subject: Pier tools & Query engine In-Reply-To: <66666f210701082219j5649d45fyd4428c91aec30e53@mail.gmail.com> References: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> <66666f210701082219j5649d45fyd4428c91aec30e53@mail.gmail.com> Message-ID: Philippe Scenario one: I'm a high-school teacher and I want to use pier (my wife did that with swiki during years) I want to lock all the pages the kids in my school and in the class CME1 edited. Or I want to unlock. So I go to the admin page and I assemble a simple query. Then the system shows me: a tabel with the links I could select one link and see why this kids have 35 images on the web page (I could rank the pages resulting of a query by one property) Then I compose somehow that I want to do one the pages/element I got. I want to select all or a part and perform a command. Do you see why the query engine on Pier element using meta- information will always beat google? I think that once we get this infrastructure in place Pier will be extremely useful. Stef On 9 janv. 07, at 07:19, Philippe Marschall wrote: > 2007/1/8, S?bastien Julliand : >> Hi there! >> >> I'd like to ask Pier users what kind of tools could be useful in >> order to >> easily maintain their wiki (something like some >> reporting tools, specific search queries and so on...). We >> (me and a colleague) will work on this subject and try to >> make Pier's administrators life easier ;), with the help of >> Stef Ducasse. We have already some ideas >> but any other useful ideas are welcome. In the end, we >> would like to define an advanced query component >> for Pier. >> >> By the way, Lukas, you said that you have already done some >> work on a previous query component but you >> lacked the time to finish it. Can you send us what you >> have done or at least give us some hints? >> Thanks in advance. >> >> Cheers (and happy new year!), >> S?bastien > > The following is all not query related > - if the kernel mutex is once a again fucked, replace it with a new > one > - bring back the in-place-edit-command > - diff/cvs annotate. And please tree based, not of line based. > > As for query engine, well it has to compete with google: > Enter two search terms and it finds what you are looking for. > > Cheers > Philippe > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From ducasse at iam.unibe.ch Tue Jan 9 11:30:58 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Tue, 9 Jan 2007 11:30:58 +0100 Subject: Pier tools & Query engine In-Reply-To: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> References: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> Message-ID: Good to see you guys.... :) I think that the previous email can be put in your report for requirements :) We should meet one of these days. Stef On 8 janv. 07, at 23:04, S?bastien Julliand wrote: > Hi there! > > I'd like to ask Pier users what kind of tools could be useful in > order to easily maintain their wiki (something like some reporting > tools, specific search queries and so on...). We (me and a > colleague) will work on this subject and try to make Pier's > administrators life easier ;), with the help of Stef Ducasse. We > have already some ideas but any other useful ideas are welcome. In > the end, we would like to define an advanced query component for Pier. > > By the way, Lukas, you said that you have already done some work on > a previous query component but you lacked the time to finish it. > Can you send us what you have done or at least give us some hints? > Thanks in advance. > > Cheers (and happy new year!), > S?bastien > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From renggli at iam.unibe.ch Tue Jan 9 11:34:14 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 9 Jan 2007 11:34:14 +0100 Subject: Magritte and Pragmas In-Reply-To: <6DCD41C4-6FA3-477F-A7CA-C8252AB1B8A3@iam.unibe.ch> References: <010d01c7336f$c4e29ac0$9700a8c0@hq.allresnet.com> <13B5650E-8758-41C1-AB86-78326C380C58@iam.unibe.ch> <6DCD41C4-6FA3-477F-A7CA-C8252AB1B8A3@iam.unibe.ch> Message-ID: > I do not have the answer just meat questions: > Will we have the declare new pragmas each time you add a new > property to a description. Pragmas in Squeak do not need to be declared, but I would not use them like suggested. >>> Post>>author >>> >>> >>> >>> >>> >>> >>> ^author In my opinion pragmas should not be used to write code, but to tag and configure code. I would suggest something like that: Post>>author ^ author What tells Magritte to look at #authorDescription to get a description for #author: Post>>authorDescription ^ MASingleOption new options: self findAuthors; relatedTo: SBAuthor; beRequired; yourself Note that there is no need anymore to define an accessor, as this will be figured out automatically by Magritte. > Do we really want that? what are the benefits? over class side > single description? The problem with class side descriptions is that they cannot adapt themselves to the state of the object. Something that currently enforces to override #description and to manually patch the descriptions. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Tue Jan 9 11:36:31 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 9 Jan 2007 11:36:31 +0100 Subject: Pier tools & Query engine In-Reply-To: References: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> <66666f210701082219j5649d45fyd4428c91aec30e53@mail.gmail.com> Message-ID: <385ED930-4C39-4C1D-B5D0-64ABD56B8DB6@iam.unibe.ch> > I want to lock all the pages the kids in my school and in the class > CME1 edited. > Or I want to unlock. Pier-Unix-Security and as far as I know also Spielverderber ACL Security can define permissions (lock/unlock and much more) recursively on a structure. Of course it would be more powerful to be able to execute comands on arbitrary sets of structures. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From ramon.leon at allresnet.com Tue Jan 9 16:43:33 2007 From: ramon.leon at allresnet.com (Ramon Leon) Date: Tue, 9 Jan 2007 08:43:33 -0700 Subject: Magritte and Pragmas In-Reply-To: Message-ID: <016401c73404$eb47e720$9700a8c0@hq.allresnet.com> > Pragmas in Squeak do not need to be declared, but I would not > use them like suggested. > > >>> Post>>author > >>> > >>> > >>> > >>> > >>> > >>> > >>> ^author > > In my opinion pragmas should not be used to write code, but > to tag and configure code. I would suggest something like that: > > Post>>author > > ^ author > > What tells Magritte to look at #authorDescription to get a > description for #author: > > Post>>authorDescription > ^ MASingleOption new > options: self findAuthors; > relatedTo: SBAuthor; > beRequired; > yourself > > Note that there is no need anymore to define an accessor, as > this will be figured out automatically by Magritte. > > > Do we really want that? what are the benefits? over class > side single > > description? > > The problem with class side descriptions is that they cannot > adapt themselves to the state of the object. Something that > currently enforces to override #description and to manually > patch the descriptions. > > Cheers, > Lukas Contrast Magritte with Glorp, both are very powerful, and very pluggable. Magritte provides meta data about a class, Glorp needs that same metadata for its descriptions. Magritte is a runtime meta data system, Pragmas are compile time meta data. However, both Glorp and Magritte require explicit meta data in the form of code, stored away from the accessor the meta data belongs to. Pragmas however, allow one to keep the metadata for a selector, in the selector itself, a very pleasing option because while I don't mind the description building bouncing around following description Pragmas, I'd rather the developer didn't have to, and much of the meta data contained within Magritte descriptions, really is just compile time meta data. Obviously Pragmas are less flexible than class side descriptions, I'm not at all suggesting there's anything wrong with Magritte, it's great, but it could be simpler to configure, just like Glorp vs. Rails. Most of the time, when doing database bound web applications, I think one really could use Pragmas like Rails uses macros to give hints to the description builder to automate the construction of "MOST" descriptions, possibly all. It'd be really elegant if one made a field required by simply adding the Pragma to the accessor itself, and then having the runtime generate both the Magritte and Glorp descriptions off the class meta data allowing Rails like behavior and no code required by the developer. For the more complex cases, you could always have the builder follow to the manually configured class side descriptor, but seriously, most cases will be simple mappings of Strings, Numbers, Dates, and Memo fields directly to a matching field in the database, and those, the most common cases, can be totally automated and work off Pragmas alone. Rails has proven the attraction of zero configuration to the masses, and if Ruby can do it, Smalltalk can do it better. I'm already building an ActiveRecord implementation that builds Glorp descriptions from Magritte's meta data (working well so far), but while doing so, it just occurred to me that most of what I need for Glorp could come directly from Pragmas, and it'd be a shame to build the meta data twice, so I just thought why not build Magritte descriptors from Pragmas as well. It's just an idea, but one I think I'm going to explore a little to see where it leads. Of course, I'll share anything worthy of sharing if anything pans out, if not, oh well, I'm sure I'll have fun in the process. Ramon Leon http://onsmalltalk.com From sebjulliand at gmail.com Wed Jan 10 01:01:25 2007 From: sebjulliand at gmail.com (=?ISO-8859-1?Q?S=E9bastien_Julliand?=) Date: Wed, 10 Jan 2007 01:01:25 +0100 Subject: Pier tools & Query engine In-Reply-To: References: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> Message-ID: <4f6c865a0701091601y2424ee71ndb024f8a29ad1af1@mail.gmail.com> 2007/1/9, st?phane ducasse : > > Good to see you guys.... :) > I think that the previous email can be put in your report for > requirements :) > We should meet one of these days. > > Stef > That's right! By the way, we have a class this thursday and we will see each other all day long. I guess we may find some time to talk about that ;). Cheers, Sebastien -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20070110/20f180ea/attachment.html From ducasse at iam.unibe.ch Tue Jan 9 13:19:19 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Tue, 9 Jan 2007 13:19:19 +0100 Subject: Pier tools & Query engine In-Reply-To: <385ED930-4C39-4C1D-B5D0-64ABD56B8DB6@iam.unibe.ch> References: <4f6c865a0701081404k38736595w7cb18fafa7da5e37@mail.gmail.com> <66666f210701082219j5649d45fyd4428c91aec30e53@mail.gmail.com> <385ED930-4C39-4C1D-B5D0-64ABD56B8DB6@iam.unibe.ch> Message-ID: thanks this was just an example of the kind of scenario a Pier end-user may face. Stef On 9 janv. 07, at 11:36, Lukas Renggli wrote: >> I want to lock all the pages the kids in my school and in the class >> CME1 edited. >> Or I want to unlock. > > Pier-Unix-Security and as far as I know also Spielverderber ACL > Security can define permissions (lock/unlock and much more) > recursively on a structure. > > Of course it would be more powerful to be able to execute comands on > arbitrary sets of structures. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From ducasse at iam.unibe.ch Wed Jan 10 22:42:28 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Wed, 10 Jan 2007 22:42:28 +0100 Subject: Magritte and Pragmas In-Reply-To: <016401c73404$eb47e720$9700a8c0@hq.allresnet.com> References: <016401c73404$eb47e720$9700a8c0@hq.allresnet.com> Message-ID: <8607C52B-5B10-4A2B-86E1-533B81111D65@iam.unibe.ch> Hi ramon this is really interesting. Coming from CLOS I always thought and somehow would like to have first class meta-objects for instance variable. In fact croquet needs them (I do not like the xml used but this is exactly that) Object subclass: #Person iv: (PersistentIV named: address; accessors) or Object subclass: #Person requiredIV: 'name'; I have the impression that the way we describe instance variables in Smalltalk is too monolithic. Strings are not powerful enough. A really interesting first steps that we were talking about with lukas was to have (Object subclass: #Person) instVar: 'x y'; instVar: 'z' ; classVar: 'ZORK' Could be also a way. I'm not sure. In CLOS people are used to write such a kind (not quite the same) of class definition. Now if the intuition that I get is that if you associate the pragmas to method you get a different kind of meta-description. This is true that lukas uses some description once that generate the first time their accessors so there is something missing in Smalltalk from my point of view (I was born with CLOS mop so this may explain that) > Obviously Pragmas are less flexible than class side descriptions, > I'm not at > all suggesting there's anything wrong with Magritte, it's great, > but it > could be simpler to configure, just like Glorp vs. Rails. Yes. I would really to see that. > Most of the time, when doing database bound web applications, I > think one > really could use Pragmas like Rails uses macros to give hints to the > description builder to automate the construction of "MOST" > descriptions, > possibly all. It'd be really elegant if one made a field required > by simply > adding the Pragma to the accessor itself, and then > having the > runtime generate both the Magritte and Glorp descriptions off the > class meta > data allowing Rails like behavior and no code required by the > developer. > > For the more complex cases, you could always have the builder follow > to the manually configured class > side > descriptor, but seriously, most cases will be simple mappings of > Strings, > Numbers, Dates, and Memo fields directly to a matching field in the > database, and those, the most common cases, can be totally > automated and > work off Pragmas alone. Rails has proven the attraction of zero > configuration to the masses, and if Ruby can do it, Smalltalk can > do it > better. > > I'm already building an ActiveRecord implementation that builds Glorp > descriptions from Magritte's meta data (working well so far), but > while > doing so, it just occurred to me that most of what I need for Glorp > could > come directly from Pragmas, and it'd be a shame to build the meta data > twice, so I just thought why not build Magritte descriptors from > Pragmas as > well. It's just an idea, but one I think I'm going to explore a > little to > see where it leads. Of course, I'll share anything worthy of > sharing if > anything pans out, if not, oh well, I'm sure I'll have fun in the > process. Please let us know. From brad at sonaural.com Thu Jan 11 02:02:58 2007 From: brad at sonaural.com (Brad Fuller) Date: Wed, 10 Jan 2007 17:02:58 -0800 Subject: Smallwiki: placing box under dynamic menu on left Message-ID: <45A58CC2.3070303@sonaural.com> With the left menu in a Smallwlki being dynamic (can grow up or down depending on user's selection) how can one place a box underneath the menu so that it moves dynamically with the growth of the menu? Is there a way to do that w/o hacking the image? -- brad fuller http://www.Sonaural.com/ +1 (408) 799-6124 From brad at sonaural.com Thu Jan 11 04:18:56 2007 From: brad at sonaural.com (Brad Fuller) Date: Wed, 10 Jan 2007 19:18:56 -0800 Subject: Smallwiki: placing box under dynamic menu on left In-Reply-To: <45A58CC2.3070303@sonaural.com> References: <45A58CC2.3070303@sonaural.com> Message-ID: <45A5ACA0.3060001@sonaural.com> Brad Fuller wrote: > With the left menu in a Smallwlki being dynamic (can grow up or down > depending on user's selection) how can one place a box underneath the > menu so that it moves dynamically with the growth of the menu? Is there > a way to do that w/o hacking the image? > > I am no css expert, by any stretch. But, I was thinking if you could embed both the menu div and the box below the menu div in a parent div section then both could float within this new box. I don't know if that would solve the problem. If it did, I don't know how to do this in the templates section of SmallWiki. -- brad fuller http://www.Sonaural.com/ +1 (408) 799-6124 From renggli at iam.unibe.ch Thu Jan 11 07:18:25 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 11 Jan 2007 07:18:25 +0100 Subject: Smallwiki: placing box under dynamic menu on left In-Reply-To: <45A5ACA0.3060001@sonaural.com> References: <45A58CC2.3070303@sonaural.com> <45A5ACA0.3060001@sonaural.com> Message-ID: <20ACEC4D-A9BF-4045-AA37-BDAB5E8E176C@iam.unibe.ch> >> With the left menu in a Smallwlki being dynamic (can grow up or down >> depending on user's selection) how can one place a box underneath the >> menu so that it moves dynamically with the growth of the menu? Is >> there >> a way to do that w/o hacking the image? > > I am no css expert, by any stretch. But, I was thinking if you could > embed both the menu div and the box below the menu div in a parent div > section then both could float within this new box. I don't know if > that > would solve the problem. If it did, I don't know how to do this in the > templates section of SmallWiki. In SmallWiki you can only define order in that the template components are generated (as opposed to Pier). You can then position those components (or boxes) anywhere using CSS. Boxes in SmallWiki are built like this:

Path

...
If you just put them one after each other the second one will be places below the first one. If you set a width for "list", they will be just on the left side and not use up the whole width. In combination with relative positioning you can then put the contents over the empty area to get something similar to what we have in Pier. (see http://www.csszengarden.com/ and http://www.csszengarden.com/). Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From brad at sonaural.com Thu Jan 11 19:58:26 2007 From: brad at sonaural.com (Brad Fuller) Date: Thu, 11 Jan 2007 10:58:26 -0800 Subject: Smallwiki: placing box under dynamic menu on left In-Reply-To: <20ACEC4D-A9BF-4045-AA37-BDAB5E8E176C@iam.unibe.ch> References: <45A58CC2.3070303@sonaural.com> <45A5ACA0.3060001@sonaural.com> <20ACEC4D-A9BF-4045-AA37-BDAB5E8E176C@iam.unibe.ch> Message-ID: <45A688D2.3070102@sonaural.com> Lukas Renggli wrote: >>> With the left menu in a Smallwlki being dynamic (can grow up or down >>> depending on user's selection) how can one place a box underneath the >>> menu so that it moves dynamically with the growth of the menu? Is >>> there >>> a way to do that w/o hacking the image? >>> >> I am no css expert, by any stretch. But, I was thinking if you could >> embed both the menu div and the box below the menu div in a parent div >> section then both could float within this new box. I don't know if >> that >> would solve the problem. If it did, I don't know how to do this in the >> templates section of SmallWiki. >> > > In SmallWiki you can only define order in that the template > components are generated (as opposed to Pier). You can then position > those components (or boxes) anywhere using CSS. > > Boxes in SmallWiki are built like this: > >
>
>

Path

>
> ... >
>
>
> Can you set this up without going into the image? (forgive my newbie-ness to this) I don't see how you can do that in the settings page. All I see is ordering of the templates. > If you just put them one after each other the second one will be > places below the first one. If you set a width for "list", they will > be just on the left side and not use up the whole width. In > combination with relative positioning you can then put the contents > over the empty area to get something similar to what we have in Pier. > (see http://www.csszengarden.com/ and http://www.csszengarden.com/). > > Cheers, > Lukas > > -- brad fuller http://www.Sonaural.com/ +1 (408) 799-6124 From renggli at iam.unibe.ch Thu Jan 11 20:54:42 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 11 Jan 2007 20:54:42 +0100 Subject: Smallwiki: placing box under dynamic menu on left In-Reply-To: <45A688D2.3070102@sonaural.com> References: <45A58CC2.3070303@sonaural.com> <45A5ACA0.3060001@sonaural.com> <20ACEC4D-A9BF-4045-AA37-BDAB5E8E176C@iam.unibe.ch> <45A688D2.3070102@sonaural.com> Message-ID: <0B2D32ED-8120-4B20-8163-FC9A548BED71@iam.unibe.ch> > Can you set this up without going into the image? (forgive my > newbie-ness to this) I don't see how you can do that in the > settings page. Yes, you can basically define the whole look and layout without going to the image. > All I see is ordering of the templates. - Yes, Admin | Templates allows you select the template components to be visible and the ordering of those. - The next menu-item Admin | Components allows you to define the settings of those template components. - And last but not least Admin | Stylesheet allows you to either select one of the predefined CSS style-sheets or write your own right within SmallWiki. HTH, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From brad at sonaural.com Thu Jan 11 21:18:01 2007 From: brad at sonaural.com (Brad Fuller) Date: Thu, 11 Jan 2007 12:18:01 -0800 Subject: Smallwiki: placing box under dynamic menu on left In-Reply-To: <0B2D32ED-8120-4B20-8163-FC9A548BED71@iam.unibe.ch> References: <45A58CC2.3070303@sonaural.com> <45A5ACA0.3060001@sonaural.com> <20ACEC4D-A9BF-4045-AA37-BDAB5E8E176C@iam.unibe.ch> <45A688D2.3070102@sonaural.com> <0B2D32ED-8120-4B20-8163-FC9A548BED71@iam.unibe.ch> Message-ID: <45A69B79.8000603@sonaural.com> Lukas Renggli wrote: > >> All I see is ordering of the templates. >> > > - Yes, Admin | Templates allows you select the template components to > be visible and the ordering of those. > > - The next menu-item Admin | Components allows you to define the > settings of those template components. > > - And last but not least Admin | Stylesheet allows you to either > select one of the predefined CSS style-sheets or write your own right > within SmallWiki. > I got all that, thanks. What I'm asking is how can you define divs within divs as you mentioned in your previous message. From what I see you can only order, not embed a div inside a div. What am I missing? From renggli at iam.unibe.ch Thu Jan 11 22:10:26 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 11 Jan 2007 22:10:26 +0100 Subject: Smallwiki: placing box under dynamic menu on left In-Reply-To: <45A69B79.8000603@sonaural.com> References: <45A58CC2.3070303@sonaural.com> <45A5ACA0.3060001@sonaural.com> <20ACEC4D-A9BF-4045-AA37-BDAB5E8E176C@iam.unibe.ch> <45A688D2.3070102@sonaural.com> <0B2D32ED-8120-4B20-8163-FC9A548BED71@iam.unibe.ch> <45A69B79.8000603@sonaural.com> Message-ID: <369E9992-FAF8-410B-811B-0D1EF9E7B975@iam.unibe.ch> > I got all that, thanks. What I'm asking is how can you define divs > within divs as you mentioned in your previous message. From what I > see you can only order, not embed a div inside a div. What am I > missing? You can't. What you need to change is the CSS to do the layout. The XHTML defines the content (what the developer does and what is defined trough the template components in SmallWiki), and the design and look-and-feel is done using CSS (what the graphics designer does). This is how modern web development goes, as presented on www.alistapart.com and www.csszengarden.com. HTH, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From brad at sonaural.com Thu Jan 11 22:38:06 2007 From: brad at sonaural.com (Brad Fuller) Date: Thu, 11 Jan 2007 13:38:06 -0800 Subject: Smallwiki: placing box under dynamic menu on left In-Reply-To: <369E9992-FAF8-410B-811B-0D1EF9E7B975@iam.unibe.ch> References: <45A58CC2.3070303@sonaural.com> <45A5ACA0.3060001@sonaural.com> <20ACEC4D-A9BF-4045-AA37-BDAB5E8E176C@iam.unibe.ch> <45A688D2.3070102@sonaural.com> <0B2D32ED-8120-4B20-8163-FC9A548BED71@iam.unibe.ch> <45A69B79.8000603@sonaural.com> <369E9992-FAF8-410B-811B-0D1EF9E7B975@iam.unibe.ch> Message-ID: <45A6AE3E.7030509@sonaural.com> Lukas Renggli wrote: >> I got all that, thanks. What I'm asking is how can you define divs >> within divs as you mentioned in your previous message. From what I >> see you can only order, not embed a div inside a div. What am I >> missing? >> > > You can't. What you need to change is the CSS to do the layout. > OK, but I don't have any more ideas on how to do this. I can easily change the CSS which is what I'm doing - that's easy. But, I don't have a clue on how to make a box, that is located below another, dynamically change it's position as the one above grows and shrinks in CSS. One idea was two divs within a div and make them float within the parent (as we both mentioned in the previous messages.) I'll keep looking for a solution. It's probably starring me in the face ;-) From renggli at iam.unibe.ch Thu Jan 11 22:58:01 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 11 Jan 2007 22:58:01 +0100 Subject: Smallwiki: placing box under dynamic menu on left In-Reply-To: <45A6AE3E.7030509@sonaural.com> References: <45A58CC2.3070303@sonaural.com> <45A5ACA0.3060001@sonaural.com> <20ACEC4D-A9BF-4045-AA37-BDAB5E8E176C@iam.unibe.ch> <45A688D2.3070102@sonaural.com> <0B2D32ED-8120-4B20-8163-FC9A548BED71@iam.unibe.ch> <45A69B79.8000603@sonaural.com> <369E9992-FAF8-410B-811B-0D1EF9E7B975@iam.unibe.ch> <45A6AE3E.7030509@sonaural.com> Message-ID: <242918EB-F2EF-487A-8B17-7BA2909B9FE0@iam.unibe.ch> > OK, but I don't have any more ideas on how to do this. I can easily > change the CSS which is what I'm doing - that's easy. But, I don't > have > a clue on how to make a box, that is located below another, > dynamically > change it's position as the one above grows and shrinks in CSS. I don't get it. Don't they do that by default?
The blue is below the red one, no matter how much the red one grows. > One idea was two divs within a div and make them float within the > parent (as we > both mentioned in the previous messages.) Then they align from left to right, not from top to bottom. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From brad at sonaural.com Thu Jan 11 23:57:27 2007 From: brad at sonaural.com (Brad Fuller) Date: Thu, 11 Jan 2007 14:57:27 -0800 Subject: Smallwiki: placing box under dynamic menu on left In-Reply-To: <242918EB-F2EF-487A-8B17-7BA2909B9FE0@iam.unibe.ch> References: <45A58CC2.3070303@sonaural.com> <45A5ACA0.3060001@sonaural.com> <20ACEC4D-A9BF-4045-AA37-BDAB5E8E176C@iam.unibe.ch> <45A688D2.3070102@sonaural.com> <0B2D32ED-8120-4B20-8163-FC9A548BED71@iam.unibe.ch> <45A69B79.8000603@sonaural.com> <369E9992-FAF8-410B-811B-0D1EF9E7B975@iam.unibe.ch> <45A6AE3E.7030509@sonaural.com> <242918EB-F2EF-487A-8B17-7BA2909B9FE0@iam.unibe.ch> Message-ID: <45A6C0D7.4000308@sonaural.com> Lukas Renggli wrote: >> OK, but I don't have any more ideas on how to do this. I can easily >> change the CSS which is what I'm doing - that's easy. But, I don't >> have >> a clue on how to make a box, that is located below another, >> dynamically >> change it's position as the one above grows and shrinks in CSS. >> > > I don't get it. Don't they do that by default? > >
>
> > The blue is below the red one, no matter how much the red one grows. > > >> One idea was two divs within a div and make them float within the >> parent (as we >> both mentioned in the previous messages.) >> > > Then they align from left to right, not from top to bottom. > Right, but the "contents" box is next to the top left box (next in line to render, right?), is in the center and also grows. There are two other boxes on the right (which are now "absolute") with fixed sizes. Maybe everything should float? Or everything should be relative? > Cheers, > Lukas > > -- brad fuller http://www.Sonaural.com/ +1 (408) 799-6124 From brad at sonaural.com Fri Jan 12 00:28:06 2007 From: brad at sonaural.com (Brad Fuller) Date: Thu, 11 Jan 2007 15:28:06 -0800 Subject: Smallwiki: placing box under dynamic menu on left In-Reply-To: <45A6C0D7.4000308@sonaural.com> References: <45A58CC2.3070303@sonaural.com> <45A5ACA0.3060001@sonaural.com> <20ACEC4D-A9BF-4045-AA37-BDAB5E8E176C@iam.unibe.ch> <45A688D2.3070102@sonaural.com> <0B2D32ED-8120-4B20-8163-FC9A548BED71@iam.unibe.ch> <45A69B79.8000603@sonaural.com> <369E9992-FAF8-410B-811B-0D1EF9E7B975@iam.unibe.ch> <45A6AE3E.7030509@sonaural.com> <242918EB-F2EF-487A-8B17-7BA2909B9FE0@iam.unibe.ch> <45A6C0D7.4000308@sonaural.com> Message-ID: <45A6C806.9010907@sonaural.com> Brad Fuller wrote: > Lukas Renggli wrote: > >>> OK, but I don't have any more ideas on how to do this. I can easily >>> change the CSS which is what I'm doing - that's easy. But, I don't >>> have >>> a clue on how to make a box, that is located below another, >>> dynamically >>> change it's position as the one above grows and shrinks in CSS. >>> >>> >> I don't get it. Don't they do that by default? >> >>
>>
>> >> The blue is below the red one, no matter how much the red one grows. >> >> >> >>> One idea was two divs within a div and make them float within the >>> parent (as we >>> both mentioned in the previous messages.) >>> >>> >> Then they align from left to right, not from top to bottom. >> >> > Right, but the "contents" box is next to the top left box (next in line > to render, right?), is in the center and also grows. There are two other > boxes on the right (which are now "absolute") with fixed sizes. > > i find the problem. Because there is a center box, I had to make this box relative, as it was defaulted to static. And then when it was relative everything kinda cascaded down as it flowed to the right. After I did this, and changed all the left boxes coordinates, I got the bottom left box to go up and down. Thanks for your help, Lukas! From renggli at iam.unibe.ch Sat Jan 13 20:41:41 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sat, 13 Jan 2007 20:41:41 +0100 Subject: Magritte Post Message-ID: A very interesting post about Magritte: http://gilesbowkett.blogspot.com/2007/01/magritte.html This is exactly what I am using Magritte for, writing highly complex application that that end users can customize ... -- Lukas Renggli http://www.lukas-renggli.ch From tblanchard at mac.com Sat Jan 13 20:58:14 2007 From: tblanchard at mac.com (Todd Blanchard) Date: Sat, 13 Jan 2007 11:58:14 -0800 Subject: Magritte Post In-Reply-To: References: Message-ID: <5D5889AE-F133-4837-A7B7-61A9D6643C48@mac.com> That's very nice, now if we can get GLORP working with it by generating GLORP descriptor systems off the magritte model, we will have the full package. That's what I'm starting to work on. -Todd Blanchard On Jan 13, 2007, at 11:41 AM, Lukas Renggli wrote: > A very interesting post about Magritte: > http://gilesbowkett.blogspot.com/2007/01/magritte.html > > This is exactly what I am using Magritte for, writing highly complex > application that that end users can customize ... > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From ducasse at iam.unibe.ch Sat Jan 13 22:15:40 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Sat, 13 Jan 2007 22:15:40 +0100 Subject: Magritte Post In-Reply-To: <5D5889AE-F133-4837-A7B7-61A9D6643C48@mac.com> References: <5D5889AE-F133-4837-A7B7-61A9D6643C48@mac.com> Message-ID: <1A57D615-D075-4183-8A1D-195C64F51320@iam.unibe.ch> Cool! Lukas did you sit with adrian recently because I'm curious to see what you could get for magritte 2 :) > That's very nice, now if we can get GLORP working with it by > generating GLORP descriptor systems off the magritte model, we will > have the full package. > > That's what I'm starting to work on. > > -Todd Blanchard > > On Jan 13, 2007, at 11:41 AM, Lukas Renggli wrote: > >> A very interesting post about Magritte: >> http://gilesbowkett.blogspot.com/2007/01/magritte.html >> >> This is exactly what I am using Magritte for, writing highly complex >> application that that end users can customize ... >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> >> >> _______________________________________________ >> SmallWiki, Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From renggli at iam.unibe.ch Sat Jan 13 22:28:44 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sat, 13 Jan 2007 22:28:44 +0100 Subject: Magritte Post In-Reply-To: <1A57D615-D075-4183-8A1D-195C64F51320@iam.unibe.ch> References: <5D5889AE-F133-4837-A7B7-61A9D6643C48@mac.com> <1A57D615-D075-4183-8A1D-195C64F51320@iam.unibe.ch> Message-ID: > Lukas did you sit with adrian recently because I'm curious to see > what you could get for magritte 2 :) Yes, just yesterday we discussed about it and in what direction we want to push our models. We also discussed about maybe merging Magritte and Meta. I also learned that he is going into the direction of automatic code-generation, something that I always wanted to avoid ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch From ducasse at iam.unibe.ch Sat Jan 13 22:32:32 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Sat, 13 Jan 2007 22:32:32 +0100 Subject: Magritte Post In-Reply-To: References: <5D5889AE-F133-4837-A7B7-61A9D6643C48@mac.com> <1A57D615-D075-4183-8A1D-195C64F51320@iam.unibe.ch> Message-ID: I will come at Bern to discuss that with you guys :) >> Lukas did you sit with adrian recently because I'm curious to see >> what you could get for magritte 2 :) > > > want to push our models. We also discussed about maybe merging > Magritte and Meta. I also learned that he is going into the direction > of automatic code-generation, something that I always wanted to > avoid ... In moose I had a package generating smalltalk code + its meta description because sometimes I was too lazy to type it and I wanted to see if I could reproduce the code from its description when there is no logic. Stef From azreal1977 at hotmail.com Sun Jan 14 00:05:05 2007 From: azreal1977 at hotmail.com (J J) Date: Sat, 13 Jan 2007 23:05:05 +0000 Subject: ORM status (was Re: Magritte Post) In-Reply-To: <5D5889AE-F133-4837-A7B7-61A9D6643C48@mac.com> Message-ID: So is Ramon, and I think Alan Knight said he had an ActiveRecord for GLORP as well. Is there any overlap between you guys, or are all three approaches different? If so, maybe the news team could interview you guys for a feature break down, so outsiders like myself could see what options are out there. I think it would be good for it to become more public that Squeak probably handles CRUD apps better then Rails at this point. >From: Todd Blanchard >Reply-To: "Magritte, Pier and Related Tools ..." >To: "Magritte, Pier and Related Tools ..." >Subject: Re: Magritte Post >Date: Sat, 13 Jan 2007 11:58:14 -0800 > >That's very nice, now if we can get GLORP working with it by >generating GLORP descriptor systems off the magritte model, we will >have the full package. > >That's what I'm starting to work on. > >-Todd Blanchard > >On Jan 13, 2007, at 11:41 AM, Lukas Renggli wrote: > > > A very interesting post about Magritte: > > http://gilesbowkett.blogspot.com/2007/01/magritte.html > > > > This is exactly what I am using Magritte for, writing highly complex > > application that that end users can customize ... > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > > > > > _______________________________________________ > > SmallWiki, Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > >_______________________________________________ >SmallWiki, Magritte, Pier and Related Tools ... >https://www.iam.unibe.ch/mailman/listinfo/smallwiki _________________________________________________________________ Communicate instantly! Use your Hotmail address to sign into Windows Live Messenger now. http://get.live.com/messenger/overview From tblanchard at mac.com Sun Jan 14 01:14:21 2007 From: tblanchard at mac.com (Todd Blanchard) Date: Sat, 13 Jan 2007 16:14:21 -0800 Subject: ORM status (was Re: Magritte Post) In-Reply-To: References: Message-ID: <13B4E230-EDCB-47EA-98D1-D1CACF610BE3@mac.com> We are talking - I think the ball is in my court to get the glorp port upgraded so it is in sync with the current version. Then I'l integrate my stuff that generates alter scripts. Ramon is working on mapping the model and has a start on it. I have to look into his work. I'm a little strapped for time just now but it will come soon. -Todd Blanchard On Jan 13, 2007, at 3:05 PM, J J wrote: > So is Ramon, and I think Alan Knight said he had an ActiveRecord > for GLORP > as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20070114/4dc4ae56/attachment.html From ramonleon at cox.net Tue Jan 16 02:14:12 2007 From: ramonleon at cox.net (Ramon Leon) Date: Mon, 15 Jan 2007 18:14:12 -0700 Subject: ORM status (was Re: Magritte Post) In-Reply-To: <13B4E230-EDCB-47EA-98D1-D1CACF610BE3@mac.com> References: <13B4E230-EDCB-47EA-98D1-D1CACF610BE3@mac.com> Message-ID: <45AC26E4.3020803@cox.net> > We are talking - I think the ball is in my court to get the glorp port > upgraded so it is in sync with the current version. Then I'l integrate Yea, I'd definitely like to work with the latest version. > my stuff that generates alter scripts. Ramon is working on mapping the > model and has a start on it. I have to look into his work. I'm a > little strapped for time just now but it will come soon. I just released what I have on SqueakSource, check out my blog for where I'm at, I just explained it on http://onsmalltalk.com/programming/smalltalk/a-smalltalk-activerecord-using-magritte-seaside-and-glorp/ Ramon Leon http://onsmalltalk.com From tblanchard at mac.com Tue Jan 16 02:21:01 2007 From: tblanchard at mac.com (Todd Blanchard) Date: Mon, 15 Jan 2007 17:21:01 -0800 Subject: ORM status (was Re: Magritte Post) In-Reply-To: <45AC26E4.3020803@cox.net> References: <13B4E230-EDCB-47EA-98D1-D1CACF610BE3@mac.com> <45AC26E4.3020803@cox.net> Message-ID: <546914BC-E910-4F1A-B5B3-ED88AB09BA2C@mac.com> FWIW, I think the port is about 80% done - I hope to wrap it up by beginning of next week if all goes well. Also, I have take over ownership of the glorp entry on squeakmap. -Todd On Jan 15, 2007, at 5:14 PM, Ramon Leon wrote: >> We are talking - I think the ball is in my court to get the glorp >> port >> upgraded so it is in sync with the current version. Then I'l >> integrate > > Yea, I'd definitely like to work with the latest version. > >> my stuff that generates alter scripts. Ramon is working on >> mapping the >> model and has a start on it. I have to look into his work. I'm a >> little strapped for time just now but it will come soon. > > I just released what I have on SqueakSource, check out my blog for > where > I'm at, I just explained it on > > http://onsmalltalk.com/programming/smalltalk/a-smalltalk- > activerecord-using-magritte-seaside-and-glorp/ > > Ramon Leon > http://onsmalltalk.com > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From ramonleon at cox.net Tue Jan 16 04:26:13 2007 From: ramonleon at cox.net (Ramon Leon) Date: Mon, 15 Jan 2007 20:26:13 -0700 Subject: ORM status (was Re: Magritte Post) In-Reply-To: <546914BC-E910-4F1A-B5B3-ED88AB09BA2C@mac.com> References: <13B4E230-EDCB-47EA-98D1-D1CACF610BE3@mac.com> <45AC26E4.3020803@cox.net> <546914BC-E910-4F1A-B5B3-ED88AB09BA2C@mac.com> Message-ID: <45AC45D5.9010209@cox.net> Todd Blanchard wrote: > FWIW, I think the port is about 80% done - I hope to wrap it up by > beginning of next week if all goes well. Also, I have take over > ownership of the glorp entry on squeakmap. > > -Todd Sweet, I look forward to it, Glorp's my new favorite tool. Ramon Leon http://onsmalltalk.com From ramon.leon at allresnet.com Tue Jan 16 16:22:04 2007 From: ramon.leon at allresnet.com (Ramon Leon) Date: Tue, 16 Jan 2007 08:22:04 -0700 Subject: Magritte Post In-Reply-To: References: <5D5889AE-F133-4837-A7B7-61A9D6643C48@mac.com><1A57D615-D075-4183-8A1D-195C64F51320@iam.unibe.ch> Message-ID: <016d01c73982$14137660$9700a8c0@hq.allresnet.com> > > Lukas did you sit with adrian recently because I'm curious > to see what > > you could get for magritte 2 :) > > Yes, just yesterday we discussed about it and in what > direction we want to push our models. We also discussed about > maybe merging Magritte and Meta. I also learned that he is > going into the direction of automatic code-generation, > something that I always wanted to avoid ... > > Lukas What's Meta, this is the first I've heard of it? Ramon Leon http://onsmalltalk.com From renggli at iam.unibe.ch Tue Jan 16 17:22:09 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 16 Jan 2007 17:22:09 +0100 Subject: Magritte Post In-Reply-To: <016d01c73982$14137660$9700a8c0@hq.allresnet.com> References: <5D5889AE-F133-4837-A7B7-61A9D6643C48@mac.com><1A57D615-D075-4183-8A1D-195C64F51320@iam.unibe.ch> <016d01c73982$14137660$9700a8c0@hq.allresnet.com> Message-ID: > What's Meta, this is the first I've heard of it? The meta model used in Moose, the re-engineering tool of the SCG. http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi? query=Duca06d&abstract=yes Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From ducasse at iam.unibe.ch Tue Jan 16 21:00:24 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Tue, 16 Jan 2007 21:00:24 +0100 Subject: Magritte Post In-Reply-To: References: <5D5889AE-F133-4837-A7B7-61A9D6643C48@mac.com><1A57D615-D075-4183-8A1D-195C64F51320@iam.unibe.ch> <016d01c73982$14137660$9700a8c0@hq.allresnet.com> Message-ID: <1358F2AC-3CD7-4154-95FB-AE7A82D24B9A@iam.unibe.ch> In fact the story is like that Moose without description in 1996 -> slowly got a ER metametamodel -> slowly got a MOF meta meta model (no relations or badly done I did it :)) -> I work with frederick to put a meta model in SmallWiki -> lukas saw got it right meta described magritte with itself and we got Magritte -> Adrian kuhn got some fun reading the EMOF 2.0 spec and reimplemented totally the bad Moose metamodel. It is cool to work with smart guys that take ideas and transcend them, really. Now we are looking at them and checking how we can learn. Magritte is more data oriented and Moose Meta is more a traditional object-oriented metametamodel. But this is interesting to get exposed. On 16 janv. 07, at 17:22, Lukas Renggli wrote: >> What's Meta, this is the first I've heard of it? > > The meta model used in Moose, the re-engineering tool of the SCG. > > http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi? > query=Duca06d&abstract=yes > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From renggli at iam.unibe.ch Wed Jan 17 11:59:32 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 17 Jan 2007 11:59:32 +0100 Subject: Magritte Post In-Reply-To: <45ACFE59.2080802@yahoo.co.uk> References: <5D5889AE-F133-4837-A7B7-61A9D6643C48@mac.com><1A57D615-D075-4183-8A1D-195C64F51320@iam.unibe.ch> <016d01c73982$14137660$9700a8c0@hq.allresnet.com> <45ACFE59.2080802@yahoo.co.uk> Message-ID: <5670976F-7145-4101-983C-9A38499A38DB@iam.unibe.ch> Hi Keith, > I have had a go at porting the class that you were missing into 2.7 > > I have once more attempted to merge my changes with yours in the > current repositories. I am hoping that you might be able to adopt > them into the mainstream now. I had a look at your changes. I cannot merge them directly, since they break several parts of Pier and all my productively running images. I just committed a manually merged version of your code, below you find the comments: Pier-Model-kph.107: - PRPathLookup class>>star:path: you removed that, but it is needed all trough the system - PRCommand: I moved the mutex from the kernel into the persistency, it seems to belong there so that we don't violate demeter. Now instad of having the critical section within the command, the command passes itself to the persistency by sending #execute:. The persistency strategy then can call #doValidate and #doExecute at the right point in time. I think this is more elegant and should even work better with object database, xml, ... - PRFilePersistency: I removed that class for now, it does not work - PRPersistency >>#log: this is not needed anymore - I don't understand the code to rename a kernel (why should that matter?) and the code related related to #realize. I think most people don't want to start right from a database, the use of a persistency strategy other than the default PRNullPersistency should be only possible after everything is setup. - PRPersistency has no #snaphost method anymore, there was no need for that anymore. Pier-Seaside-kph.109: - PRPierMain>>#structureAtPath: this breaks a possible setup with Apache, I restored my old code but wrapped #start: into the root context, so that it basically has the same effect as your modification. - PRPierControlPanel: I would suggest that you add this class into a separate package and/or transform it to a normal WAComponent so it can be directly used from within Pier. I usually remove the config application from productive servers. Moreover it introduces dependencies to external packages that might not be loaded (Pier Unix Security) and duplicates functionality that I already ported to that package earlier on. Hope these changes help to finally merge all the code again? Thanks for your contribution! Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Wed Jan 17 18:24:21 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 17 Jan 2007 18:24:21 +0100 Subject: Magritte Post Message-ID: >> - PRPathLookup class>>star:path: you removed that, but it is >> needed all trough the system > > Sorry I dont think that I meant to remove that method. Its the Pier- > Caching package that is supposed to hook in to these methods. Then this must be caused by the subsequent merges of the different branches ... >> - PRCommand: I moved the mutex from the kernel into the >> persistency, it seems to belong there so that we don't violate >> demeter. Now instad of having the critical section within the >> command, the command passes itself to the persistency by sending >> #execute:. The persistency strategy then can call #doValidate and >> #doExecute at the right point in time. I think this is more >> elegant and should even work better with object database, xml, ... > > sounds good Yes, this seems to be much more logical to me. It does not enforce the prevayler model (snapshot/changes) to the persistency, but let it basically do anything it likes: before a command is executed, between the validation and the execution, after the execution, etc. >> - I don't understand the code to rename a kernel (why should that >> matter?) and the code > > Because the kernel is looked up by name in the database. Why don't you give your persistency strategy a unique id then? Pier (currently) does not enforce unique names for kernels. > But once everything is set up, what if you want to change things. I > do frequently. I expect my image to change frequently, and my > persistent store to hold my data. > > With my approach you can switch between persistency schemes on the > fly. I thought that it was quite flashy to be able to switch from > "everything in memory", "everything in memory, back up to > persistent store" persistence to full "serve from persistent store". That's cool, I completely agree. > At your suggestion I guess I could begin a Pier-Persistency-Manager > package to put this and the migration methods in. Yep, that sounds nice to me. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From jaywhy at gmail.com Wed Jan 17 20:17:54 2007 From: jaywhy at gmail.com (Jason Yates) Date: Wed, 17 Jan 2007 14:17:54 -0500 Subject: Magritte Post In-Reply-To: References: Message-ID: <4cbfccd70701171117u78e462a6m69d054274c65e314@mail.gmail.com> > A very interesting post about Magritte: > http://gilesbowkett.blogspot.com/2007/01/magritte.html > > This is exactly what I am using Magritte for, writing highly complex > application that that end users can customize ... Interesting. From my own experience, I've seen this problem first hand. A couple years back, I was thinking of the same basic principal that Magritte solves. My family owns a small business, and have a software program tracking customers and other related data. Certain data however, would have no applicable field. So it would instead be placed in a "Customer Notes" text field. Several issues came from this. The obvious is it was essentially impossible to search and sort. The data was extremely inconsistent. "Customer has pets" is different than "Customer has a dog", etc. Even remembering to note if a customer has pets or not is a challenge, since the field wasn't required. It also brings up training issues with new employees. And this is just a small business, the problems would be amplified with larger companies. On top of all that, it would be nice if you could market to specific "customers with pets" as an example. So you are losing a potential revenue stream here. And that is just one little field. I remember thinking at the time, it would be nice if you could create fields on the fly maybe using a oodb. Giving a place for the data. The idea kinda got stored somewhere. Probably never to be brought up again. But when I learned of Magritte it immediately sparked a light bulb in my brain. -- Jason Yates jaywhy at gmail.com From ducasse at iam.unibe.ch Wed Jan 17 21:04:21 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Wed, 17 Jan 2007 21:04:21 +0100 Subject: Magritte Post In-Reply-To: References: Message-ID: <0CFC3294-B3AD-4E8F-9E9D-9216987AE7FA@iam.unibe.ch> Keith may be you should give a cool name to your persistency framework. Let us think marketing. Docker? Docks? Stef On 17 janv. 07, at 18:24, Lukas Renggli wrote: >>> - PRPathLookup class>>star:path: you removed that, but it is >>> needed all trough the system >> >> Sorry I dont think that I meant to remove that method. Its the Pier- >> Caching package that is supposed to hook in to these methods. > > Then this must be caused by the subsequent merges of the different > branches ... > >>> - PRCommand: I moved the mutex from the kernel into the >>> persistency, it seems to belong there so that we don't violate >>> demeter. Now instad of having the critical section within the >>> command, the command passes itself to the persistency by sending >>> #execute:. The persistency strategy then can call #doValidate and >>> #doExecute at the right point in time. I think this is more >>> elegant and should even work better with object database, xml, ... >> >> sounds good > > Yes, this seems to be much more logical to me. It does not enforce > the prevayler model (snapshot/changes) to the persistency, but let it > basically do anything it likes: before a command is executed, between > the validation and the execution, after the execution, etc. > >>> - I don't understand the code to rename a kernel (why should that >>> matter?) and the code >> >> Because the kernel is looked up by name in the database. > > Why don't you give your persistency strategy a unique id then? Pier > (currently) does not enforce unique names for kernels. > >> But once everything is set up, what if you want to change things. I >> do frequently. I expect my image to change frequently, and my >> persistent store to hold my data. >> >> With my approach you can switch between persistency schemes on the >> fly. I thought that it was quite flashy to be able to switch from >> "everything in memory", "everything in memory, back up to >> persistent store" persistence to full "serve from persistent store". > > That's cool, I completely agree. > >> At your suggestion I guess I could begin a Pier-Persistency-Manager >> package to put this and the migration methods in. > > Yep, that sounds nice to me. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From stephan at stack.nl Wed Jan 17 21:09:21 2007 From: stephan at stack.nl (Stephan Eggermont) Date: Wed, 17 Jan 2007 21:09:21 +0100 Subject: Breaking Dependencies In-Reply-To: <4cbfccd70701171117u78e462a6m69d054274c65e314@mail.gmail.com> References: <4cbfccd70701171117u78e462a6m69d054274c65e314@mail.gmail.com> Message-ID: <20070117200921.GA707@stack.nl> I'd be interested to see a working example of breaking description dependencies to avoid runaway processes. Stephan From renggli at iam.unibe.ch Wed Jan 17 22:19:01 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 17 Jan 2007 22:19:01 +0100 Subject: Breaking Dependencies In-Reply-To: <20070117200921.GA707@stack.nl> References: <4cbfccd70701171117u78e462a6m69d054274c65e314@mail.gmail.com> <20070117200921.GA707@stack.nl> Message-ID: <3DBBEB34-2E4A-451B-BB42-E6828236BD7A@iam.unibe.ch> > I'd be interested to see a working example of > breaking description dependencies to avoid runaway processes. That depends on where the recursion happens. Imagine the following problem: Person class>>descriptionPartner ^ MAToOneRelationDescription new reference: self description; yourself This is purely Smalltalk and Magritte cannot do anything about the recursion caused here. When you evaluate "Person description" Magritte will collect all the description elements and also call #descriptionPartner that calls #description and leads to an infinite recursion. 1. The simplest solution to this problem is a hack: Person class>>descriptionPartner ^ (MAToOneRelationDescription selector: #partner) reference: (MADynamicObject on: [ self description ]); yourself MADynamicObject is a proxy that delegates most of its messages to the result of the block evaluation. This is easy and mostly works, however it is very hard to debug and usually leads to problems sooner or later. There are a couple of examples in Magritte, Pier and Pier- Unix-Security of this hack. This does not solve the problem with the recursion when validating or printing the object. 2. Another solution is just to exclude the circular references from the referenced: Person class>>descriptionPartner ^ (MAToOneRelationDescription selector: #partner) reference: (MADynamicObject on: [ self descriptionWithoutReferences ]); yourself And then you need to implement something like this: Object class>>descriptionWithoutReferences ^ self description reject: [ :each | each isKindOf: MAReferenceDescription ] Not very nice, but it works well. It should also solve the problem when validating or printing a recursive object. 3. Compose your descriptions dynamically on the instance side. Person>>description | desc part | desc := MAContainer new. part := MAToOneRelationDescription selector: #partner. desc add: (part copy reference: part). ^ desc Ugly and looks like a Java UI built manually, but it also works for validating or printing recursive objects. As I mentioned in earlier mails the goal would be to enable the detection of recursion in validation, printing and serialization automatically. Note: Magritte seems to lack some feature in the field of complex composed objects (especially if you compare it with EMOF that has something like an 'opposite' for back references, etc). This comes from the fact that most (or even all) my described objects form a tree and not a graph with loops. Of course the object model has loops, but they are all handled manually with the glue-code in- between that is not considered by Magritte. That's the power of Smalltalk, everything is real close together ... HTH, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From ramon.leon at allresnet.com Fri Jan 19 01:33:01 2007 From: ramon.leon at allresnet.com (Ramon Leon) Date: Thu, 18 Jan 2007 17:33:01 -0700 Subject: Magritte Message-ID: <022001c73b61$604e5000$9700a8c0@hq.allresnet.com> Lukas, I loaded up the latest Magritte code the other day, and it blew up because MANamedBuilder is now using your #value: symbol hack from your Mondrian package. I like the symbol trick, but I assume you don't mean for Magritte to depend on Mondrian. Ramon Leon http://onsmalltalk.com From renggli at iam.unibe.ch Fri Jan 19 14:29:44 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Fri, 19 Jan 2007 14:29:44 +0100 Subject: Magritte In-Reply-To: <022001c73b61$604e5000$9700a8c0@hq.allresnet.com> References: <022001c73b61$604e5000$9700a8c0@hq.allresnet.com> Message-ID: <384D7188-7537-4AD8-AC13-F3CBB5F45857@iam.unibe.ch> > Lukas, I loaded up the latest Magritte code the other day, and it > blew up because MANamedBuilder is now using your #value: symbol > hack from your Mondrian package. I like the symbol trick, but I > assume you don't mean for Magritte to depend on Mondrian. Well, Symbol>>#value: was still in Magritte-Model in my image at least. And it is also in 3.9 by default, so there is maybe a conflict there. Anyway, I think it should be avoided and I just commited a version of Magritte and Pier that does not use this trick anymore. Hope this helps, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From azreal1977 at hotmail.com Mon Jan 22 06:38:01 2007 From: azreal1977 at hotmail.com (J J) Date: Mon, 22 Jan 2007 05:38:01 +0000 Subject: PRModel Message-ID: Hi all, I am building a mostly static website that can take advantage of some automation, so I have written it using Pier. I just took a look at the MC repo and noticed I am a ways behind in revisions (i'm at 79) so maybe there is a way to do this now. Or maybe there was before I just didn't understand it. What I am doing is making a band website. One of the things we need on the page are CD's. What I would like to do is; in Pier do a normal Component add, but I would select PRCDPage instead of the normal one. Then I can edit the CD from the Edit command. Simple enough. But it occurs to me that this is a more general problem. I have an object which may be image only, or it may actually live in the database. I want to do a "PRModelPage" add, have the edit let me select the model and then after the model is known the Edit command will edit the object directly. I really think something like this would be helpful for the site overall. I think this is the type of thing you get easily from Rails. So before I go off and implement it, I thought I was ask, what do you guys think? Does this exist already? Is there some better way it should be implemented them how I am suggesting (i.e. the Migretta meta-information will have to be kind of "two phase")? Thanks for any insight you can provide, Jason _________________________________________________________________ Turn searches into helpful donations. Make your search count. http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_donation&FORM=WLMTAG From renggli at iam.unibe.ch Mon Jan 22 07:47:03 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 22 Jan 2007 07:47:03 +0100 Subject: PRModel In-Reply-To: References: Message-ID: > I am building a mostly static website that can take advantage of some > automation, so I have written it using Pier. I just took a look at > the MC > repo and noticed I am a ways behind in revisions (i'm at 79) so > maybe there > is a way to do this now. Or maybe there was before I just didn't > understand > it. What package? There are several packages with version 79, some of them even have multiple branches with a 79 version. Pier-All-lr.79? > What I am doing is making a band website. One of the things we > need on the > page are CD's. What I would like to do is; in Pier do a normal > Component > add, but I would select PRCDPage instead of the normal one. Then I > can edit > the CD from the Edit command. Simple enough. > > But it occurs to me that this is a more general problem. I have an > object > which may be image only, or it may actually live in the database. > I want to > do a "PRModelPage" add, have the edit let me select the model and > then after > the model is known the Edit command will edit the object directly. I am a bit confused. First you talk about Components, I guess you ment structures. Now you talk about models, what is a "PRModelPage"? Then you talk about the addition of a structure. And about the fact the user has to choose the type (Page, File, Component) before adding it. > I really think something like this would be helpful for the site > overall. I > think this is the type of thing you get easily from Rails. So > before I go > off and implement it, I thought I was ask, what do you guys think? > Does > this exist already? Is there some better way it should be > implemented them > how I am suggesting (i.e. the Migretta meta-information will have > to be kind > of "two phase")? Isn't this already the default behavior? Adding lets you select the type, then an editor on the selected type is displayed. Two-phases, the first one always looks the same, the second one is different depending on the type selected and its user customizable settings. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From azreal1977 at hotmail.com Mon Jan 22 19:48:26 2007 From: azreal1977 at hotmail.com (J J) Date: Mon, 22 Jan 2007 18:48:26 +0000 Subject: PRModel In-Reply-To: Message-ID: >From: Lukas Renggli >Reply-To: "Magritte, Pier and Related Tools ..." >To: "Magritte, Pier and Related Tools ..." >Subject: Re: PRModel >Date: Mon, 22 Jan 2007 07:47:03 +0100 > >What package? There are several packages with version 79, some of >them even have multiple branches with a 79 version. Pier-All-lr.79? Well, the point is, it's old now. It is Pier-model-lr.79 I think and Pier-seaside-lr.79. > > But it occurs to me that this is a more general problem. I have an > > object > > which may be image only, or it may actually live in the database. > > I want to > > do a "PRModelPage" add, have the edit let me select the model and > > then after > > the model is known the Edit command will edit the object directly. > >I am a bit confused. First you talk about Components, I guess you >ment structures. > >Now you talk about models, what is a "PRModelPage"? > >Then you talk about the addition of a structure. And about the fact >the user has to choose the type (Page, File, Component) before adding >it. Well, I guess at 4am it seemed clear enough. :) What I was basically thinking was (as clearly as I can remember it) if I have some class that was previously in the image (for example) that happens to be a domain object, then maybe we could have a generic class that has a member variable "model". The initial "Edit" command in pier would let you point this model variable at a given class, database table or whatever. After that, the class would have the meta-descriptions so that the pier "Edit" command would let you edit an instance of the actual domain object, etc. :) I realize you can do this from Magritte by adding the meta information directly, but I was just trying to think of a way to make it more automatic. Maybe it's a bad idea, which is why I wanted to ask before I go writing misguided code. :) >Isn't this already the default behavior? Adding lets you select the >type, then an editor on the selected type is displayed. Two-phases, >the first one always looks the same, the second one is different >depending on the type selected and its user customizable settings. It is. I was just thinking of one more layer between. Thanks for the quick feedback. _________________________________________________________________ Laugh, share and connect with Windows Live Messenger http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline From renggli at iam.unibe.ch Mon Jan 22 20:37:59 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 22 Jan 2007 20:37:59 +0100 Subject: PRModel In-Reply-To: References: Message-ID: <08197162-955D-46E1-B269-3919A5E9AC76@iam.unibe.ch> >> What package? There are several packages with version 79, some of >> them even have multiple branches with a 79 version. Pier-All-lr.79? > > Well, the point is, it's old now. It is Pier-model-lr.79 I think > and Pier-seaside-lr.79. Not too old then, I think it should be easily possible to update. With some precaution of course ... ;-) >> Then you talk about the addition of a structure. And about the fact >> the user has to choose the type (Page, File, Component) before adding >> it. > > Well, I guess at 4am it seemed clear enough. :) What I was basically > thinking was (as clearly as I can remember it) if I have some class > that was > previously in the image (for example) that happens to be a domain > object, > then maybe we could have a generic class that has a member variable > "model". > The initial "Edit" command in pier would let you point this model > variable > at a given class, database table or whatever. After that, the > class would > have the meta-descriptions so that the pier "Edit" command would > let you > edit an instance of the actual domain object, etc. :) I guess the thing you are taking about is what's in the package Pier- Forms provides. You can find the package in the official repository: http://mc.lukas-renggli.ch/pier There is some documentation in my thesis: http://www.iam.unibe.ch/~scg/Archive/Diploma/Reng06a.pdf (3.6.3 Adaptive Forms, Page 39) > I realize you can do this from Magritte by adding the meta information > directly, but I was just trying to think of a way to make it more > automatic. > Maybe it's a bad idea, which is why I wanted to ask before I go > writing > misguided code. :) The example I am giving above needs some work. It is a bit too complex for people not being familiar with the underlying model. If you want to improve, feel free to do so ... Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From thierry.thelliez.tech at gmail.com Tue Jan 23 22:27:38 2007 From: thierry.thelliez.tech at gmail.com (Thierry Thelliez) Date: Tue, 23 Jan 2007 14:27:38 -0700 Subject: New to Pier/Magma/Seaside Message-ID: <42f5c4430701231327x1141b77cp14407e60acbfc5c2@mail.gmail.com> Beginning with Pier/Magma/Seaside, I have some issues following the 'How-To'. While starting the server works, few lines down the 'How-To' we can see: "To Change Admin Password ' pier' control panel link is visible in config application has buttons for (Manage Users) and (Manage Groups)" where is this panel link refered to? Thanks, Thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20070123/fec94d40/attachment.html From thierry.thelliez.tech at gmail.com Tue Jan 23 23:05:41 2007 From: thierry.thelliez.tech at gmail.com (Thierry Thelliez) Date: Tue, 23 Jan 2007 15:05:41 -0700 Subject: Pier 'How to' Message-ID: <42f5c4430701231405l5360942eh516ff966884ccaa0@mail.gmail.com> Related to my previous post, here is the 'out of the box' experience of a newbie. The image was downloaded from the Web site and untouched. The 'How To' seems to be out of sync with the software. > Configuring for Magma. Why does it have to be configured for Magma? What is the default persistency system? > In application 'pier' configuration. This is the Pier > configure link on the Pier home page. >1. Add WAMagmaConfiguration to configurations. I am assuming that this is in the 'Configuration Ancestors' area? >2. Switch sessionClass to WAMagmaSharedSession There is now a General > sessionClass with an override link. I am assuming that we have to press Save at this point... >3. Return to the config app and click the new 'magma'. There is no direct link, so I pressed Done and clicked again on the configure from the Home page. In the General section there is a override link next to Location > Magma >4. Create RepositoryRoot selecting PRMagmaRepository (create) No such thing... The choices for Magma > Locations are - MagmaRemoteLocation, and - MagmaLocalLocation. Not sure what to do, I selected MagmaLocalLocation and left 'magma' in the path field. Then pressed Saved. >5. Return to config app and click the 'pier' link. There is no Pier link. Only a Pier section header. >6. Switch the kernel to the persistency scheme of your choice. For the Kernel the choices are: - "None", or - "a Pier kernel named: 'Pier'" Thierry From keith_hodges at yahoo.co.uk Wed Jan 24 06:02:18 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Wed, 24 Jan 2007 05:02:18 +0000 Subject: New to Pier/Magma/Seaside In-Reply-To: <42f5c4430701231327x1141b77cp14407e60acbfc5c2@mail.gmail.com> References: <42f5c4430701231327x1141b77cp14407e60acbfc5c2@mail.gmail.com> Message-ID: <45B6E85A.3080906@yahoo.co.uk> Thierry Thelliez wrote: > Beginning with Pier/Magma/Seaside, I have some issues following the > 'How-To'. > > While starting the server works, few lines down the 'How-To' we can see: > > "To Change Admin Password > > ' pier' control panel link is visible in config application > has buttons for (Manage Users) and (Manage Groups)" > > where is this panel link refered to? The seaside config application is available at http://localhost:8080/seaside/config user: seaside password: admin In the config application you will see a 'pier' link in the line: pier 'configure' 'remove' 'pier' I will answer your next email in a mo... cheers Keith ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From azreal1977 at hotmail.com Wed Jan 24 06:02:35 2007 From: azreal1977 at hotmail.com (J J) Date: Wed, 24 Jan 2007 05:02:35 +0000 Subject: Magritte Collection Description In-Reply-To: <08197162-955D-46E1-B269-3919A5E9AC76@iam.unibe.ch> Message-ID: Hi all, I am writing some Magritte descriptions for a class of mine and I don't see something I really expected to see. This of course makes me think I am missing something. What I have is, a class with various fields I want to have set, including a collection of strings. The others were no problem, MANumberDescription and so on, but I don't see anything for handling a collection. The nearest thing I saw was MAToManyDescription? But that seems to want something more complex. Perhaps it is for linking classes together. I looked at MACollection but that said it is for a collection of *descriptions*. I tried it anyway, and it didn't understand #default. :) Thanks for any help you can give me. If I just have to write one, or upgrade that is ok. I just wanted to make sure I'm not missing something fundamental. Thanks, Jason _________________________________________________________________ Laugh, share and connect with Windows Live Messenger http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline From keith_hodges at yahoo.co.uk Wed Jan 24 06:22:45 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Wed, 24 Jan 2007 05:22:45 +0000 Subject: Pier 'How to' In-Reply-To: <42f5c4430701231405l5360942eh516ff966884ccaa0@mail.gmail.com> References: <42f5c4430701231405l5360942eh516ff966884ccaa0@mail.gmail.com> Message-ID: <45B6ED25.1050809@yahoo.co.uk> >> Configuring for Magma. >> > Why does it have to be configured for Magma? It doesnt: You can see the persistency options available in the 'pier' control panel, in the /seaside/config application as explained in the previous email. The other persistency options are selected with a simple drop down menu. You can switch between them 'on the fly'. Your data is migrated from one persistency scheme to another, subject to your approval, before committing to the change. (note: PRFilePersistency is not working, and it has been removed from the latest pier builds - so don't bother with it at the moment) > What is the default > persistency system? > > The default is PRNullPersistency, the data is all in the image. If you save the image you save the data. There is an option PRImagePersistency which does a periodic image save for you. If you switch to PRMagmaPersistency it is likely to tell you that it has not yet been configured. Hence the explanation for this 'non-trivial' case in the How-to. >> In application 'pier' configuration. >> > This is the Pier > configure link on the Pier home page. > > >> 1. Add WAMagmaConfiguration to configurations. >> > I am assuming that this is in the 'Configuration Ancestors' area? > > You find the application 'pier' configuration, in /seaside/pier, or, as you did, from the 'configure' link in the toolbar at the bottom of Pier. (this toolbar only appears in non-deployed applications). When you arrive there the Configuration Ancestors area already has WAMagmaConfiguration visible in the drop down box, with an 'Add' button next to it. You click the Add button. >> 2. Switch sessionClass to WAMagmaSharedSession >> > There is now a General > sessionClass with an override link. > I am assuming that we have to press Save at this point... > > Having Added the WAMagmaConfiguration, the session class has been automatically set to WAMagmaSession. (so things will work). Yes this could use some clearer explanation I agree. Its a bit subtle. >> 3. Return to the config app and click the new 'magma'. >> At this point you are missing a vital piece of seaside information. The config app refered to is again /seaside/config username: seaside password: admin where before you would have seen pier 'configure' 'remove' 'pier' you should now see pier 'configure' remove' 'pier' 'magma' > There is no direct link, so I pressed Done and clicked again on the > configure from the Home page. > In the General section there is a override link next to Location > Magma > > >> 4. Create RepositoryRoot selecting PRMagmaRepository (create) >> If you clock on 'magma' you will be taken to an entirely new page that you have not yet seen which has the Create Button on it. > No such thing... The choices for Magma > Locations are > - MagmaRemoteLocation, and > - MagmaLocalLocation. > Not sure what to do, I selected MagmaLocalLocation and left 'magma' in > the path field. Then pressed Saved. > thats fine. >> 5. Return to config app and click the 'pier' link. >> > There is no Pier link. Only a Pier section header. > > this is once more the link in the config app http://localhost:8080/seaside/config >> 6. Switch the kernel to the persistency scheme of your choice. >> > For the Kernel the choices are: > - "None", or > - "a Pier kernel named: 'Pier'" > > > > Thierry > I hope this helps, I guess just a little more information in the how to would have helped you along much more smoothly. Sorry about that I shall ensure that the next version is much improved. best regards Keith ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" ? The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html From renggli at iam.unibe.ch Wed Jan 24 09:13:36 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 24 Jan 2007 09:13:36 +0100 Subject: Magritte Collection Description In-Reply-To: References: Message-ID: <6CD7E0FB-F988-4C47-B7E3-0214C4B772DF@iam.unibe.ch> Support for collections in Magritte is weak. For quite some time I planned to add support for multiplicities like in EMOF and UML, however I never found the time to actually do it. > What I have is, a class with various fields I want to have set, > including a collection of strings. The others were no problem, > MANumberDescription and so on, but I don't see anything for > handling a collection. The nearest thing I saw was > MAToManyDescription? Yes, MAToManyDescription is what you are looking for. If you are not using fully described objects as children, you want to check out its subclass MAToManyScalarRelationDescription. Maybe Philippe can give you more hints on how to use that? The description probably looks something like this: ^ (MAToManyScalarRelationDescription selector: #flowers) reference: MAStringDescription new; default: #(); yourself > I looked at MACollection but that said it is for a collection of > *descriptions*. I tried it anyway, and it didn't understand > #default. :) I don't have MACollection in my image, only MAContainer. As you said, this is a collection of descriptions; not a description on collections. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From philippe.marschall at gmail.com Wed Jan 24 11:10:38 2007 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Wed, 24 Jan 2007 11:10:38 +0100 Subject: Magritte Collection Description In-Reply-To: <6CD7E0FB-F988-4C47-B7E3-0214C4B772DF@iam.unibe.ch> References: <6CD7E0FB-F988-4C47-B7E3-0214C4B772DF@iam.unibe.ch> Message-ID: <66666f210701240210q7cd9bbbdgb7a320be98ac0779@mail.gmail.com> 2007/1/24, Lukas Renggli : > Support for collections in Magritte is weak. For quite some time I > planned to add support for multiplicities like in EMOF and UML, > however I never found the time to actually do it. > > > What I have is, a class with various fields I want to have set, > > including a collection of strings. The others were no problem, > > MANumberDescription and so on, but I don't see anything for > > handling a collection. The nearest thing I saw was > > MAToManyDescription? > > Yes, MAToManyDescription is what you are looking for. If you are not > using fully described objects as children, you want to check out its > subclass MAToManyScalarRelationDescription. Maybe Philippe can give > you more hints on how to use that? > > The description probably looks something like this: > > ^ (MAToManyScalarRelationDescription selector: #flowers) > reference: MAStringDescription new; > default: #(); > yourself Yeah, that's about it. Check out ICalMagritte for examples: descriptionComments ^(MAToManyScalarRelationDescription selector: #comments label: 'Comments' priority: 5000) classes: (Array with: String); reference: MAMemoDescription new; yourself Note that MAToManyScalarRelationDescription is really just a hack and hopefully disappears once multiplicities are fixed. So use it with caution. Cheers Philippe > > I looked at MACollection but that said it is for a collection of > > *descriptions*. I tried it anyway, and it didn't understand > > #default. :) > > I don't have MACollection in my image, only MAContainer. As you said, > this is a collection of descriptions; not a description on collections. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From thierry.thelliez.tech at gmail.com Wed Jan 24 20:13:41 2007 From: thierry.thelliez.tech at gmail.com (Thierry Thelliez) Date: Wed, 24 Jan 2007 12:13:41 -0700 Subject: Pier 'How to' In-Reply-To: <45B6ED25.1050809@yahoo.co.uk> References: <42f5c4430701231405l5360942eh516ff966884ccaa0@mail.gmail.com> <45B6ED25.1050809@yahoo.co.uk> Message-ID: <42f5c4430701241113k2b1d0223o7aabf6508541c860@mail.gmail.com> Thanks Keith. I gave it another try following your hints. Here are more notes, again from a newbie approach. I found many issues: 1- Minor: Default port The default proposed port is 8080. This conflict with usual Tomcat installation. Changing the text to 9090 does not seem to change the underlying hot link. Being new to Squeak, I do not know how to change that. I had to do the classic highlight+do it. I would recommend changing the default port or let the user choose themselves (remove the hot link). 2- Major: Froze Squeak clicking 'Over' in the debugger Going to seaside/config then Pier>Magma I got an error about a filestream (more about that below). I clicked debugged. Inspected the variables in Squeak. I found that a directory was set to c:/tmp/magma. I thought that maybe the issue was with the Windows path (\ vs. /). I changed a variable and clicked Over. Oops... Squeak would not respond anymore to any click. The web site still worked. How does one unfreeze Squeak in such situation? Crtl-C did nothing. 3- Critical: Magma error following instructions I removed every thing and started over: fresh 3.9 Squeak + fresh SMP image. Following the How To I clicked on PRMagmaRepository > create. I got an error: Repository Path Setting: magma c:\dev\Squeak\SMP\magma\objects not found The above file and directory do exist... Further clicking brings an error page. Here is the top of the stack: MaUserError: fileStream required * MaUserError class(Exception class)>>signal: self MaUserError temps signalerText 'fileStream required' inst vars superclass MaError methodDict a MethodDictionary(#isUserError->a CompiledMethod (1830) ) format 140 instanceVariables nil organization ('as yet unclassified' isUserError) subclasses {MaClientServerUserError . MaHashIndexUserError . MaObjectSerializationUserError . MagmaUserError} name #MaUserError classPool nil sharedPools nil environment a SystemDictionary(lots of globals) category #'Ma exception handling-exceptions' traitComposition nil localSelectors nil * MaTransactionalFileStream class>>fileStream: self MaTransactionalFileStream temps aFileStream nil inst vars superclass MaObject methodDict a MethodDictionary(#bePhysical->a CompiledMethod (2620) #binary->a CompiledMethod (3812) #close->a C...etc... format 142 instanceVariables #('filename' 'fileStream' 'guard' 'uncommittedSize' 'position' 'writers') organization ('accessing' bePhysical committedSize copyToDirectory: physicalStream writersDo:) ('filestream api' ...etc... subclasses nil name #MaTransactionalFileStream classPool nil sharedPools nil environment a SystemDictionary(lots of globals) category #'Magma server-recovery' traitComposition nil localSelectors nil * MaObjectFiler>>openFile: self a MaObjectFiler temps unqualifiedName 'objects' answer nil inst vars directory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' file nil preMadeObjectBuffer a MaObjectBuffer oid : **invalid** classId : **invalid** objectInstSize : **invalid** filePositionIndex nil usedByteArrays an Array(a ByteArray(0) a ByteArray(0 0) a ByteArray(0 0 0) a ByteArray(0 0 0 0) a ByteArray(0 0 0 0...etc... primitiveAttributeAddressesMap a Dictionary('anchorOid'->43->64 'booleanFlags'->10->8 'classDefinitionsOid'->27->64 'definitionOid'...etc... * MaObjectFiler>>openObjectsFile self a MaObjectFiler temps inst vars directory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' file nil preMadeObjectBuffer a MaObjectBuffer oid : **invalid** classId : **invalid** objectInstSize : **invalid** filePositionIndex nil usedByteArrays an Array(a ByteArray(0) a ByteArray(0 0) a ByteArray(0 0 0) a ByteArray(0 0 0 0) a ByteArray(0 0 0 0...etc... primitiveAttributeAddressesMap a Dictionary('anchorOid'->43->64 'booleanFlags'->10->8 'classDefinitionsOid'->27->64 'definitionOid'...etc... * MaObjectFiler>>open self a MaObjectFiler temps inst vars directory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' file nil preMadeObjectBuffer a MaObjectBuffer oid : **invalid** classId : **invalid** objectInstSize : **invalid** filePositionIndex nil usedByteArrays an Array(a ByteArray(0) a ByteArray(0 0) a ByteArray(0 0 0) a ByteArray(0 0 0 0) a ByteArray(0 0 0 0...etc... primitiveAttributeAddressesMap a Dictionary('anchorOid'->43->64 'booleanFlags'->10->8 'classDefinitionsOid'->27->64 'definitionOid'...etc... * MaObjectFiler class>>open: self MaObjectFiler temps aFileDirectory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' inst vars superclass MaObject methodDict a MethodDictionary(#anchorOid->a CompiledMethod (1003) #anchorOid:->a CompiledMethod (3392) #append:...etc... format 142 instanceVariables #('directory' 'file' 'preMadeObjectBuffer' 'filePositionIndex' 'usedByteArrays' 'primitiveAttributeA...etc... organization ('accessing' anchorOid classDefinitionsOid dataFileName definitionOid directory filePointerForOid: f...etc... subclasses nil name #MaObjectFiler classPool nil sharedPools nil environment a SystemDictionary(lots of globals) category #'Magma server-private' traitComposition nil localSelectors nil * MaObjectRepository>>open: self a MaObjectRepository temps aFileDirectory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' inst vars transactionLog a MaTransactionLog sessions a Dictionary() filer nil repositoryController a MagmaRepositoryController largeCollectionManagers a Dictionary() systemReadStrategy nil nextOid nil recoveryManager nil commitGuard a Monitor applyProcess nil wantsToClose nil * MaObjectRepository class>>open:controller: self MaObjectRepository temps aFileDirectory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' aMaRepositoryController a MagmaRepositoryController inst vars superclass MaObject methodDict a MethodDictionary(#abortTransactionFor:->a CompiledMethod (131) #applyToCache:->a CompiledMethod (1...etc... format 152 instanceVariables #('transactionLog' 'sessions' 'filer' 'repositoryController' 'largeCollectionManagers' 'systemReadSt...etc... organization ('client-requests' abortTransactionFor: fractionLoaded: getTrunkFor:expression: numberOfEntriesFrom:...etc... subclasses nil name #MaObjectRepository classPool a Dictionary(#RunningTestCases->false #SimulateOutage->false ) sharedPools nil environment a SystemDictionary(lots of globals) category #'Magma server-private' traitComposition nil localSelectors nil * MagmaRepositoryController>>privateOpen: self a MagmaRepositoryController temps aFileDirectory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' inst vars repository a MaObjectRepository session a MagmaSession serverSerializer a MaObjectSerializer requestInterruptGuard a Monitor directory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' preferences a MagmaServerPreferences Thierry From keith_hodges at yahoo.co.uk Wed Jan 24 20:36:10 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Wed, 24 Jan 2007 19:36:10 +0000 Subject: Pier 'How to' In-Reply-To: <42f5c4430701241113k2b1d0223o7aabf6508541c860@mail.gmail.com> References: <42f5c4430701231405l5360942eh516ff966884ccaa0@mail.gmail.com> <45B6ED25.1050809@yahoo.co.uk> <42f5c4430701241113k2b1d0223o7aabf6508541c860@mail.gmail.com> Message-ID: <45B7B52A.6080604@yahoo.co.uk> Thierry Thelliez wrote: > Thanks Keith. > > I gave it another try following your hints. Here are more notes, again > from a newbie approach. I found many issues: > > 1- Minor: Default port > The default proposed port is 8080. This conflict with usual Tomcat > installation. Changing the text to 9090 does not seem to change the > ;-) I think that tomcat is conflicting with a usual seaside, or any other server configuration. > underlying hot link. Being new to Squeak, I do not know how to change > that. I'm a bit rusty on that myself. > I had to do the classic highlight+do it. I would recommend > changing the default port or let the user choose themselves (remove > the hot link). > > 2- Major: Froze Squeak clicking 'Over' in the debugger > Going to seaside/config then Pier>Magma I got an error about a > filestream (more about that below). I clicked debugged. Inspected the > variables in Squeak. I found that a directory was set to c:/tmp/magma. > I thought that maybe the issue was with the Windows path (\ vs. /). I > changed a variable and clicked Over. Oops... Squeak would not respond > anymore to any click. The web site still worked. How does one unfreeze > Squeak in such situation? Crtl-C did nothing. > > Squeak uses ctrl '.' as a user interrupt, as in ctrl 'stop'. Its an apple thing, or at least it was an apple thing. I have had this problem or very similar to what you describe. Sometimes using the website unfreezes the squeak ui. I am using (knoppix) linux, and I solved it once and for all by going back to vm version 3.6-3, which predates some newer IO code. > 3- Critical: Magma error following instructions > I removed every thing and started over: fresh 3.9 Squeak + fresh SMP > image. Following the How To I clicked on PRMagmaRepository > create. I > got an error: > Repository Path Setting: magma > c:\dev\Squeak\SMP\magma\objects not found > The above file and directory do exist... > they should be created when you click on 'create', it can take some time to complete. I dont think that you need to manually create the 'magma' directory. Other than that I dont know. I admire your persistence, if you pardon the pun, It sure worked more easily for me. I am planning to release an updated SMP image later this week. --- Keith ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" ? The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html From thierry.thelliez.tech at gmail.com Wed Jan 24 22:46:13 2007 From: thierry.thelliez.tech at gmail.com (Thierry Thelliez) Date: Wed, 24 Jan 2007 14:46:13 -0700 Subject: Pier 'How to' In-Reply-To: <45B7B52A.6080604@yahoo.co.uk> References: <42f5c4430701231405l5360942eh516ff966884ccaa0@mail.gmail.com> <45B6ED25.1050809@yahoo.co.uk> <42f5c4430701241113k2b1d0223o7aabf6508541c860@mail.gmail.com> <45B7B52A.6080604@yahoo.co.uk> Message-ID: <42f5c4430701241346l1a8b7f3bw3b9839ed8fa1442a@mail.gmail.com> Trying again from the beginning. I re-dowloaded the files from http://ftp.squeak.org/various_images/Seaside-Magma-Pier/ and http://ftp.squeak.org/current_stable/win/Squeak3.9-win32.zip But I got stuck again at the same place: > 4. Create RepositoryRoot selecting PRMagmaRepository (create) There is a magma direectory created, and it contains for files: applied.images, commitPackages, objects, objects.idx. Ignoring the error message: >Repository Path Setting: magma > c:\dev\Squeak\SMP\magma\objects not found I clicked on 'create'. I got: >Outage occurred while writing system-definitions! Will now attempt to repair. Clicking on Ok I get again: >MaUserError: fileStream required The top of the stack is included below. The generated error is at: ..................... MATransactionalFileStream class fileStream: aFileStream aFileStream ifNil: [ MaUserError signal: 'fileStream required' ]. ^ self new setFileStream: aFileStream ; yourself ..................... aFileStream is nil. The calling method is: ...................... openFile: unqualifiedName | answer | answer _ MaTransactionalFileStream fileStream: (directory fileNamed: unqualifiedName). answer ifNil: [ MagmaEnvironmentError signal: 'Could not open files in ', directory pathName ] ifNotNil: [ answer binary ]. ^ answer ...................... I inspected 'directory fileNamed: unqualifiedName'. It indeed returned nil... directory is set to DosFileDirectory on 'C:\dev\Squeak\SMP\magma'. As far as I can see this is correct. unqualifiedName is set to 'objects'. This also seems correct, and the file exists. I attempted to follow the issue with the debugger: The method MultipleByteStream open: fileName forWrite: writeMode fails at: fileID := StandardFileStream retryWithGC:[self primOpen: f writable: writeMode] until:[:id| id notNil] forFileNamed: fileName. fileName looks ok but fileID is nil. Of course at this point the file might be locked from the previous failure... Thierry ---------------------------------------------------- MaUserError: fileStream required * MaUserError class(Exception class)>>signal: self MaUserError temps signalerText 'fileStream required' inst vars superclass MaError methodDict a MethodDictionary(#isUserError->a CompiledMethod (1830) ) format 140 instanceVariables nil organization ('as yet unclassified' isUserError) subclasses {MaClientServerUserError . MaHashIndexUserError . MaObjectSerializationUserError . MagmaUserError} name #MaUserError classPool nil sharedPools nil environment a SystemDictionary(lots of globals) category #'Ma exception handling-exceptions' traitComposition nil localSelectors nil * MaTransactionalFileStream class>>fileStream: self MaTransactionalFileStream temps aFileStream nil inst vars superclass MaObject methodDict a MethodDictionary(#bePhysical->a CompiledMethod (2620) #binary->a CompiledMethod (3812) #close->a C...etc... format 142 instanceVariables #('filename' 'fileStream' 'guard' 'uncommittedSize' 'position' 'writers') organization ('accessing' bePhysical committedSize copyToDirectory: physicalStream writersDo:) ('filestream api' ...etc... subclasses nil name #MaTransactionalFileStream classPool nil sharedPools nil environment a SystemDictionary(lots of globals) category #'Magma server-recovery' traitComposition nil localSelectors nil * MaObjectFiler>>openFile: self a MaObjectFiler temps unqualifiedName 'objects' answer nil inst vars directory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' file nil preMadeObjectBuffer a MaObjectBuffer oid : **invalid** classId : **invalid** objectInstSize : **invalid** filePositionIndex nil usedByteArrays an Array(a ByteArray(0) a ByteArray(0 0) a ByteArray(0 0 0) a ByteArray(0 0 0 0) a ByteArray(0 0 0 0...etc... primitiveAttributeAddressesMap a Dictionary('anchorOid'->43->64 'booleanFlags'->10->8 'classDefinitionsOid'->27->64 'definitionOid'...etc... * MaObjectFiler>>openObjectsFile self a MaObjectFiler temps inst vars directory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' file nil preMadeObjectBuffer a MaObjectBuffer oid : **invalid** classId : **invalid** objectInstSize : **invalid** filePositionIndex nil usedByteArrays an Array(a ByteArray(0) a ByteArray(0 0) a ByteArray(0 0 0) a ByteArray(0 0 0 0) a ByteArray(0 0 0 0...etc... primitiveAttributeAddressesMap a Dictionary('anchorOid'->43->64 'booleanFlags'->10->8 'classDefinitionsOid'->27->64 'definitionOid'...etc... * MaObjectFiler>>open self a MaObjectFiler temps inst vars directory DosFileDirectory on 'C:\dev\Squeak\SMP\magma' file nil preMadeObjectBuffer a MaObjectBuffer oid : **invalid** classId : **invalid** objectInstSize : **invalid** filePositionIndex nil usedByteArrays an Array(a ByteArray(0) a ByteArray(0 0) a ByteArray(0 0 0) a ByteArray(0 0 0 0) a ByteArray(0 0 0 0...etc... primitiveAttributeAddressesMap a Dictionary('anchorOid'->43->64 'booleanFlags'->10->8 'classDefinitionsOid'->27->64 'definitionOid'...etc... From thierry.thelliez.tech at gmail.com Wed Jan 24 23:19:59 2007 From: thierry.thelliez.tech at gmail.com (Thierry Thelliez) Date: Wed, 24 Jan 2007 15:19:59 -0700 Subject: Pier 'How to' In-Reply-To: <42f5c4430701241346l1a8b7f3bw3b9839ed8fa1442a@mail.gmail.com> References: <42f5c4430701231405l5360942eh516ff966884ccaa0@mail.gmail.com> <45B6ED25.1050809@yahoo.co.uk> <42f5c4430701241113k2b1d0223o7aabf6508541c860@mail.gmail.com> <45B7B52A.6080604@yahoo.co.uk> <42f5c4430701241346l1a8b7f3bw3b9839ed8fa1442a@mail.gmail.com> Message-ID: <42f5c4430701241419s7b84cfben47112a892dc098e4@mail.gmail.com> I started to wonder if the problem could be with Windows. So I did a full install on Fedora (C5, under colinux). I do not have a Mac for trying that. Same problem... Thierry From thierry.thelliez.tech at gmail.com Thu Jan 25 01:15:01 2007 From: thierry.thelliez.tech at gmail.com (Thierry Thelliez) Date: Wed, 24 Jan 2007 17:15:01 -0700 Subject: Pier 'How to' In-Reply-To: <42f5c4430701241419s7b84cfben47112a892dc098e4@mail.gmail.com> References: <42f5c4430701231405l5360942eh516ff966884ccaa0@mail.gmail.com> <45B6ED25.1050809@yahoo.co.uk> <42f5c4430701241113k2b1d0223o7aabf6508541c860@mail.gmail.com> <45B7B52A.6080604@yahoo.co.uk> <42f5c4430701241346l1a8b7f3bw3b9839ed8fa1442a@mail.gmail.com> <42f5c4430701241419s7b84cfben47112a892dc098e4@mail.gmail.com> Message-ID: <42f5c4430701241615m477eb6f9gc207ccf5395ca084@mail.gmail.com> Quite a lot of problems with the Squeak environment... Because of the previous issues, I decided to try updating Magma and other Packages. I must say that I am underwhelmed with the SqueakMap system. Few days ago I was using YumEx for Fedora. I found the dependency management more clear. Anyhow, I first tried to update Magma. localhost:9090/seaside/pier refused to work... I tried updating other packages. Still no luck. Then I tried opening a fresh 3.9 image and running the Pier installation script. Again many not very clear messages about loading older versions of some MA * packages. The choices are yes and no. That's not clear what the implications are. I picked yes for all of them. I then got an error message about a missing MATestCase class... My perception as a newbie is that there is quite some version management issues here. The whole process stopped because of a syntax error (probably due to a different class schema version). I am not sure what to do next... From billksun at yahoo.com Thu Jan 25 04:22:03 2007 From: billksun at yahoo.com (Bill Sun) Date: Wed, 24 Jan 2007 19:22:03 -0800 (PST) Subject: Pier 'How to' Message-ID: <862183.93569.qm@web53307.mail.yahoo.com> Do you need Magma? I've not tried installing the Magma-Pier integration, yet (quite frankly, Keith's instructions are a bit vague and needs a bit more detail for a newbie like me), but the experience of just installing Pier is fairly straightforward (unless something has changed since my last install). Just install Pier from SqueakMap, and it'll take care of all the dependencies. Even when installing via the Monticello repository according to the instructions worked painlessly. Try the instructions here for the installation without Magma: http://smallwiki.unibe.ch/smallwiki/pier/installationofpier/ If you're determined to get Magma running with Pier, you might want to try getting help on Magma's mailing list, since it seems that most of your problems come from Magma. Magma List: magma at lists.squeakfoundation.org Magma List Archive: http://lists.squeakfoundation.org/mailman/listinfo/magma I feel similarly in regards to SqueakMap. It seems to lack automatic dependency resolution, and puts all the dependency resolution in the hands of the package developer, of which many pass that burden on to the user. The most well-behaved SqueakMap package so far for me, is Pier. I can take a fresh 3.8 image and install Pier, and it'll install all the other packages that it depends on, plus setting things up so it can start running once the installation is done. I always keep a fresh image that I can restart on. Many times installing packages from SqueakMap and fiddling around Squeak can break my image or change file, and I don't know how to fix it, so I just start fresh again. -Bill ----- Original Message ---- From: Thierry Thelliez To: "Magritte, Pier and Related Tools ..." Sent: Wednesday, January 24, 2007 4:15:01 PM Subject: Re: Pier 'How to' Quite a lot of problems with the Squeak environment... Because of the previous issues, I decided to try updating Magma and other Packages. I must say that I am underwhelmed with the SqueakMap system. Few days ago I was using YumEx for Fedora. I found the dependency management more clear. Anyhow, I first tried to update Magma. localhost:9090/seaside/pier refused to work... I tried updating other packages. Still no luck. Then I tried opening a fresh 3.9 image and running the Pier installation script. Again many not very clear messages about loading older versions of some MA * packages. The choices are yes and no. That's not clear what the implications are. I picked yes for all of them. I then got an error message about a missing MATestCase class... My perception as a newbie is that there is quite some version management issues here. The whole process stopped because of a syntax error (probably due to a different class schema version). I am not sure what to do next... _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20070125/e529e19e/attachment-0001.html From ducasse at iam.unibe.ch Thu Jan 25 10:49:36 2007 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Thu, 25 Jan 2007 10:49:36 +0100 Subject: Pier 'How to' In-Reply-To: <42f5c4430701241615m477eb6f9gc207ccf5395ca084@mail.gmail.com> References: <42f5c4430701231405l5360942eh516ff966884ccaa0@mail.gmail.com> <45B6ED25.1050809@yahoo.co.uk> <42f5c4430701241113k2b1d0223o7aabf6508541c860@mail.gmail.com> <45B7B52A.6080604@yahoo.co.uk> <42f5c4430701241346l1a8b7f3bw3b9839ed8fa1442a@mail.gmail.com> <42f5c4430701241419s7b84cfben47112a892dc098e4@mail.gmail.com> <42f5c4430701241615m477eb6f9gc207ccf5395ca084@mail.gmail.com> Message-ID: <4820ACD0-0A38-4F0A-A9A9-7112D044ABBC@iam.unibe.ch> On 25 janv. 07, at 01:15, Thierry Thelliez wrote: > Quite a lot of problems with the Squeak environment... > > Because of the previous issues, I decided to try updating Magma and > other Packages. > > I must say that I am underwhelmed with the SqueakMap system. Few days > ago I was using YumEx for Fedora. I found the dependency management > more clear. Sure there is no dependency mechanism in squeakMap. > Anyhow, I first tried to update Magma. localhost:9090/seaside/pier > refused to work... I tried updating other packages. Still no luck. > > Then I tried opening a fresh 3.9 image and running the Pier > installation script. Again many not very clear messages about loading > older versions of some MA * packages. The choices are yes and no. > That's not clear what the implications are. I picked yes for all of > them. I then got an error message about a missing MATestCase class... > My perception as a newbie is that there is quite some version > management issues here. The whole process stopped because of a syntax > error (probably due to a different class schema version). > > I am not sure what to do next... > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From kironsky at grisoft.cz Fri Jan 26 13:54:26 2007 From: kironsky at grisoft.cz (Elod Kironsky) Date: Fri, 26 Jan 2007 13:54:26 +0100 Subject: Setting up a simple Wiki... Message-ID: <45B9FA02.6020402@grisoft.cz> Hi! I am planning to set up a simple wiki for personal use (noting my tasks, thoughts, etc.) and maybe more. I decided to use SmallWiki, as it seems to work really fine in practice (www.squeak.org is very nice). At first I tried Pier, but it was a bit complicated for me, as I am not familiar with Seaside and I really don't want to develop web applications. So I downloaded the SmallWiki prepared image from http://homepage.mac.com/jborden23/FileSharing3.html. Loading from SqueakMap to 3.9 did not really work out (getting a dependency message and after ignoring it getting another error on a non-existing method in Monticello?). The prepared image is a Squeak 3.7 one and works just fine but I did run into troubles when trying to configure SmallWiki. So here are some questions, maybe you can help me: 1.) I don't really understand the difference between roles and users. If I enter the wiki, I have automatically anonymous role? Why can't I edit any page then? 2.) I tried to protect a page, that should not be viewable by other users then admin. I executed the script I found in the SmallWiki FAQ: (server root at: 'Secret') roles: (OrderedCollection with: (BasicRole name: 'anonymous')) " this role has no permissions " but I could still access the page when I normally entered it without any login. Am I doing something wrong? 3.) How can I remove actions (RSS for example) from the upper right corner? I think that's pretty much it. I would appreciate any help. Thanks in advance, Elod From Michael.Binzen at bahn.de Fri Jan 26 14:20:13 2007 From: Michael.Binzen at bahn.de (Michael.Binzen@bahn.de) Date: Fri, 26 Jan 2007 14:20:13 +0100 Subject: Antwort: Setting up a simple Wiki... In-Reply-To: <45B9FA02.6020402@grisoft.cz> Message-ID: Hello Elod, you may look at http://www.c2.com/cgi/wiki?EasiestInstallableWikiContest Ciao Michael Binzen |-------------------------------------> | Elod Kironsky | | | | Gesendet von: | | smallwiki-bounces at iam.uni| | be.ch | | | | | | 26.01.2007 13:54 | | Bitte antworten an | | '"Magritte, Pier and | | Related Tools ..."' | |-------------------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | | | An:| | smallwiki, The general-purpose Squeak developers list | | Kopie:| | | | Blindkopie:| | | | Thema:| | Setting up a simple Wiki... | | | >-------------------------------------------------------------------------------------------------------------------------------| Hi! I am planning to set up a simple wiki for personal use (noting my tasks, thoughts, etc.) and maybe more. I decided to use SmallWiki, as it seems to work really fine in practice (www.squeak.org is very nice). At first I tried Pier, but it was a bit complicated for me, as I am not familiar with Seaside and I really don't want to develop web applications. So I downloaded the SmallWiki prepared image from http://homepage.mac.com/jborden23/FileSharing3.html. Loading from SqueakMap to 3.9 did not really work out (getting a dependency message and after ignoring it getting another error on a non-existing method in Monticello?). The prepared image is a Squeak 3.7 one and works just fine but I did run into troubles when trying to configure SmallWiki. So here are some questions, maybe you can help me: 1.) I don't really understand the difference between roles and users. If I enter the wiki, I have automatically anonymous role? Why can't I edit any page then? 2.) I tried to protect a page, that should not be viewable by other users then admin. I executed the script I found in the SmallWiki FAQ: (server root at: 'Secret') roles: (OrderedCollection with: (BasicRole name: 'anonymous')) " this role has no permissions " but I could still access the page when I normally entered it without any login. Am I doing something wrong? 3.) How can I remove actions (RSS for example) from the upper right corner? I think that's pretty much it. I would appreciate any help. Thanks in advance, Elod _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki --------- Diese E-Mail k?nnte vertrauliche und/oder rechtlich gesch?tzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ---------- From kironsky at grisoft.cz Fri Jan 26 14:40:52 2007 From: kironsky at grisoft.cz (Elod Kironsky) Date: Fri, 26 Jan 2007 14:40:52 +0100 Subject: Antwort: Setting up a simple Wiki... In-Reply-To: References: Message-ID: <45BA04E4.7040109@grisoft.cz> Thank you very much, that site gives a great insight, especially TiddlyWiki looks cool, but I'm looking for a wiki with a standalone web server to deploy it somewhere and access it over the net, and in this case, Squeak Wiki looks like the best candidate, because I want also cross-platform usability (I'm using Linux and Windows on the same machine). The problem is with swiki, that it seems a bit outdated to me, that is, why I would like to try SmallWiki. Elod > > > Hello Elod, > > you may look at http://www.c2.com/cgi/wiki?EasiestInstallableWikiContest > > Ciao > Michael Binzen > > > > > |-------------------------------------> > | Elod Kironsky | > | | > | Gesendet von: | > | smallwiki-bounces at iam.uni| > | be.ch | > | | > | | > | 26.01.2007 13:54 | > | Bitte antworten an | > | '"Magritte, Pier and | > | Related Tools ..."' | > |-------------------------------------> > >-------------------------------------------------------------------------------------------------------------------------------| > | | > | | > | An:| > | smallwiki, The general-purpose Squeak developers list | > | Kopie:| > | | > | Blindkopie:| > | | > | Thema:| > | Setting up a simple Wiki... | > | | > >-------------------------------------------------------------------------------------------------------------------------------| > > > > > Hi! > > I am planning to set up a simple wiki for personal use (noting my tasks, > thoughts, etc.) and maybe more. I decided to > use SmallWiki, as it seems to work really fine in practice > (www.squeak.org is very nice). At first I tried Pier, but it > was a bit complicated for me, as I am not familiar with Seaside and I > really don't want to develop web applications. So > I downloaded the SmallWiki prepared image from > http://homepage.mac.com/jborden23/FileSharing3.html. Loading from > SqueakMap to 3.9 did not really work out (getting a dependency message > and after ignoring it getting another error on a > non-existing method in Monticello?). The prepared image is a Squeak 3.7 > one and works just fine but I did run into > troubles when trying to configure SmallWiki. So here are some questions, > maybe you can help me: > > 1.) I don't really understand the difference between roles and users. If > I enter the wiki, I have automatically anonymous > role? Why can't I edit any page then? > > 2.) I tried to protect a page, that should not be viewable by other > users then admin. I executed the script I found in the > SmallWiki FAQ: > > (server root at: 'Secret') > roles: (OrderedCollection > with: (BasicRole name: 'anonymous')) " this role > has no permissions " > > but I could still access the page when I normally entered it without any > login. Am I > doing something wrong? > > 3.) How can I remove actions (RSS for example) from the upper right corner? > > I think that's pretty much it. I would appreciate any help. Thanks in > advance, > > Elod > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > > --------- > > Diese E-Mail k?nnte vertrauliche und/oder rechtlich gesch?tzte > Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder > diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die > unbefugte Weitergabe dieser Mail sind nicht gestattet. > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > ---------- From giovanni at corriga.net Fri Jan 26 15:03:21 2007 From: giovanni at corriga.net (Giovanni Corriga) Date: Fri, 26 Jan 2007 15:03:21 +0100 Subject: Antwort: Setting up a simple Wiki... In-Reply-To: <45BA04E4.7040109@grisoft.cz> References: <45BA04E4.7040109@grisoft.cz> Message-ID: <1169820201.3110.51.camel@rincewind.discworld> Il giorno ven, 26/01/2007 alle 14.40 +0100, Elod Kironsky ha scritto: > Thank you very much, that site gives a great insight, especially > TiddlyWiki looks cool, but I'm looking for a wiki with a > standalone web server to deploy it somewhere and access it over the net, > and in this case, Squeak Wiki looks like the best > candidate, because I want also cross-platform usability (I'm using Linux > and Windows on the same machine). The problem > is with swiki, that it seems a bit outdated to me, that is, why I would > like to try SmallWiki. While Swiki is an old wiki engine and has an "uncommon" architecture, it's stable and bug-free. I wouldn't discard it without trying it. Giovanni From kironsky at grisoft.cz Fri Jan 26 15:08:17 2007 From: kironsky at grisoft.cz (Elod Kironsky) Date: Fri, 26 Jan 2007 15:08:17 +0100 Subject: Antwort: Setting up a simple Wiki... In-Reply-To: <1169820201.3110.51.camel@rincewind.discworld> References: <45BA04E4.7040109@grisoft.cz> <1169820201.3110.51.camel@rincewind.discworld> Message-ID: <45BA0B51.1030205@grisoft.cz> Giovanni Corriga wrote: > Il giorno ven, 26/01/2007 alle 14.40 +0100, Elod Kironsky ha scritto: > >> Thank you very much, that site gives a great insight, especially >> TiddlyWiki looks cool, but I'm looking for a wiki with a >> standalone web server to deploy it somewhere and access it over the net, >> and in this case, Squeak Wiki looks like the best >> candidate, because I want also cross-platform usability (I'm using Linux >> and Windows on the same machine). The problem >> is with swiki, that it seems a bit outdated to me, that is, why I would >> like to try SmallWiki. >> > > While Swiki is an old wiki engine and has an "uncommon" architecture, > it's stable and bug-free. I wouldn't discard it without trying it. > > Giovanni > > > Yes, that is why we use it at our university. But I don't really like the content management in swiki, especially the uploaded files, that I cannot remove after I uploaded them. Elod From brad at sonaural.com Tue Jan 30 17:48:33 2007 From: brad at sonaural.com (Brad Fuller) Date: Tue, 30 Jan 2007 08:48:33 -0800 Subject: Examples of Pier Sites Message-ID: <45BF76E1.7020001@sonaural.com> I was going to send an email about Pier and I couldn't come up with any example sites. Can anyone reply with some links that I can use? -- brad fuller http://www.Sonaural.com/ +1 (408) 799-6124 From brad at sonaural.com Tue Jan 30 17:54:59 2007 From: brad at sonaural.com (Brad Fuller) Date: Tue, 30 Jan 2007 08:54:59 -0800 Subject: Examples of Pier Sites In-Reply-To: <45BF76E1.7020001@sonaural.com> References: <45BF76E1.7020001@sonaural.com> Message-ID: <45BF7863.1050709@sonaural.com> Brad Fuller wrote: > I was going to send an email about Pier and I couldn't come up with any > example sites. Can anyone reply with some links that I can use? oh... another question. Anyone run a "forum" in Pier? -- brad fuller http://www.Sonaural.com/ +1 (408) 799-6124 From philippe.marschall at gmail.com Tue Jan 30 18:24:05 2007 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Tue, 30 Jan 2007 18:24:05 +0100 Subject: Examples of Pier Sites In-Reply-To: <45BF7863.1050709@sonaural.com> References: <45BF76E1.7020001@sonaural.com> <45BF7863.1050709@sonaural.com> Message-ID: <66666f210701300924k3c09a0a1lf9338a81c9cf2d21@mail.gmail.com> 2007/1/30, Brad Fuller : > Brad Fuller wrote: > I was going to send an email about Pier and I couldn't come up with any > example sites. Can anyone reply with some links that I can use? http://www.lukas-renggli.ch/ http://swiki.gsug.org/ > oh... another question. Anyone run a "forum" in Pier? I know of no forum add-on for Pier. Philippe From brad at sonaural.com Tue Jan 30 18:33:02 2007 From: brad at sonaural.com (Brad Fuller) Date: Tue, 30 Jan 2007 09:33:02 -0800 Subject: Examples of Pier Sites In-Reply-To: <66666f210701300924k3c09a0a1lf9338a81c9cf2d21@mail.gmail.com> References: <45BF76E1.7020001@sonaural.com> <45BF7863.1050709@sonaural.com> <66666f210701300924k3c09a0a1lf9338a81c9cf2d21@mail.gmail.com> Message-ID: <45BF814E.7090404@sonaural.com> Philippe Marschall wrote: > 2007/1/30, Brad Fuller : >> Brad Fuller wrote: >> I was going to send an email about Pier and I couldn't come up with any >> example sites. Can anyone reply with some links that I can use? > > http://www.lukas-renggli.ch/ > http://swiki.gsug.org/ > >> oh... another question. Anyone run a "forum" in Pier? > > I know of no forum add-on for Pier. > Thanks Philippe, Let me ask if there are any forum's running on any seaside? -- brad fuller http://www.Sonaural.com/ +1 (408) 799-6124 From renggli at iam.unibe.ch Tue Jan 30 19:06:45 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 30 Jan 2007 19:06:45 +0100 Subject: Examples of Pier Sites In-Reply-To: <66666f210701300924k3c09a0a1lf9338a81c9cf2d21@mail.gmail.com> References: <45BF76E1.7020001@sonaural.com> <45BF7863.1050709@sonaural.com> <66666f210701300924k3c09a0a1lf9338a81c9cf2d21@mail.gmail.com> Message-ID: <41B98270-8675-4716-9024-CB46E0AF5AA9@iam.unibe.ch> >> I was going to send an email about Pier and I couldn't come up >> with any >> example sites. Can anyone reply with some links that I can use? > > http://www.lukas-renggli.ch/ > http://swiki.gsug.org/ http://ese.unibe.ch http://spielverderber.seasidehosting.st/ http://create.seasidehosting.st/ >> oh... another question. Anyone run a "forum" in Pier? > > I know of no forum add-on for Pier. An early version of Pier (SmallWiki) had a forum component. I don't know if it still works on the latest version, probably not. I'll forward this mail to the developer of the code, maybe he can give you some pointers on how to get at least the version ... Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From rbb at techgame.net Tue Jan 30 19:32:17 2007 From: rbb at techgame.net (Brian Brown) Date: Tue, 30 Jan 2007 11:32:17 -0700 Subject: Examples of Pier Sites In-Reply-To: <45BF814E.7090404@sonaural.com> References: <45BF76E1.7020001@sonaural.com> <45BF7863.1050709@sonaural.com> <66666f210701300924k3c09a0a1lf9338a81c9cf2d21@mail.gmail.com> <45BF814E.7090404@sonaural.com> Message-ID: <7343ECB8-276F-4896-ADF4-BB2691A50A0C@techgame.net> On Jan 30, 2007, at 10:33 AM, Brad Fuller wrote: > Philippe Marschall wrote: >> 2007/1/30, Brad Fuller : >>> Brad Fuller wrote: >>> I was going to send an email about Pier and I couldn't come up >>> with any >>> example sites. Can anyone reply with some links that I can use? >> >> http://www.lukas-renggli.ch/ >> http://swiki.gsug.org/ >> >>> oh... another question. Anyone run a "forum" in Pier? >> >> I know of no forum add-on for Pier. >> > > Thanks Philippe, > > Let me ask if there are any forum's running on any seaside? > > I have one in rough form that is running on Seaside, somewhat like phpBB in functionality. Brian > -- > brad fuller > http://www.Sonaural.com/ > +1 (408) 799-6124 > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From brad at sonaural.com Tue Jan 30 19:37:55 2007 From: brad at sonaural.com (Brad Fuller) Date: Tue, 30 Jan 2007 10:37:55 -0800 Subject: Examples of Pier Sites In-Reply-To: <7343ECB8-276F-4896-ADF4-BB2691A50A0C@techgame.net> References: <45BF76E1.7020001@sonaural.com> <45BF7863.1050709@sonaural.com> <66666f210701300924k3c09a0a1lf9338a81c9cf2d21@mail.gmail.com> <45BF814E.7090404@sonaural.com> <7343ECB8-276F-4896-ADF4-BB2691A50A0C@techgame.net> Message-ID: <45BF9083.7070303@sonaural.com> Brian Brown wrote: > On Jan 30, 2007, at 10:33 AM, Brad Fuller wrote: > >> Philippe Marschall wrote: >>> 2007/1/30, Brad Fuller : >>>> Brad Fuller wrote: >>>> I was going to send an email about Pier and I couldn't come up >>>> with any >>>> example sites. Can anyone reply with some links that I can use? >>> http://www.lukas-renggli.ch/ >>> http://swiki.gsug.org/ >>> >>>> oh... another question. Anyone run a "forum" in Pier? >>> I know of no forum add-on for Pier. >>> >> Thanks Philippe, >> >> Let me ask if there are any forum's running on any seaside? >> >> > > I have one in rough form that is running on Seaside, somewhat like > phpBB in functionality. Heck, I don't know the difference. I don't know what phpBB is like (but, I'm old enough to intimately know BBS's!) Any example? For that matter, is there any other seaside based, pre-configured system that would supply forum-like functionality? From denker at iam.unibe.ch Tue Jan 30 20:22:20 2007 From: denker at iam.unibe.ch (Marcus Denker) Date: Tue, 30 Jan 2007 20:22:20 +0100 Subject: Examples of Pier Sites In-Reply-To: <45BF9083.7070303@sonaural.com> References: <45BF76E1.7020001@sonaural.com> <45BF7863.1050709@sonaural.com> <66666f210701300924k3c09a0a1lf9338a81c9cf2d21@mail.gmail.com> <45BF814E.7090404@sonaural.com> <7343ECB8-276F-4896-ADF4-BB2691A50A0C@techgame.net> <45BF9083.7070303@sonaural.com> Message-ID: <2238F989-1463-4F27-9898-749E4F9120CB@iam.unibe.ch> On 30.01.2007, at 19:37, Brad Fuller wrote: > Brian Brown wrote: >> On Jan 30, 2007, at 10:33 AM, Brad Fuller wrote: >> >>> Philippe Marschall wrote: >>>> 2007/1/30, Brad Fuller : >>>>> Brad Fuller wrote: >>>>> I was going to send an email about Pier and I couldn't come up >>>>> with any >>>>> example sites. Can anyone reply with some links that I can use? >>>> http://www.lukas-renggli.ch/ >>>> http://swiki.gsug.org/ >>>> >>>>> oh... another question. Anyone run a "forum" in Pier? >>>> I know of no forum add-on for Pier. >>>> >>> Thanks Philippe, >>> >>> Let me ask if there are any forum's running on any seaside? >>> There is smallBB: http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/ abstract=yes?Roet04a But I have no idea how usable that is. Marcus -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3947 bytes Desc: not available Url : http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20070130/44ca8038/smime.bin From azreal1977 at hotmail.com Tue Jan 30 21:58:55 2007 From: azreal1977 at hotmail.com (J J) Date: Tue, 30 Jan 2007 20:58:55 +0000 Subject: Examples of Pier Sites In-Reply-To: <7343ECB8-276F-4896-ADF4-BB2691A50A0C@techgame.net> Message-ID: I have one I will be releasing soon. It isn't online yet, but you can see what it will look like at: www.hisflame.ch. At the moment it looks exactly like that, except the guest book has been replaced with "login". When the band members log in they get a few more buttons, and when I log in I get the big grey pier boxes to let me add new pages, changes settings and so on. As you can see, the front flyer is out of date. My pier site has a calendar where the band members can put in a concert date (or concert recurrence date). There are 3 places that get driving by the data in the calendar. The front flyer, which looks for a file on disk with the name matching the next concert date, the "termin" link which shows the next 5 events and one other place that just shows the next termin. This way, the site will be the authoritative place for band members to see when the next date is, and the flyer can't end up getting out of date like this. The site is full of custom components. In fact, the only things in the site that are stock pier are, I think, two static pages. Everything else is a component of some sort or another. Oh, and the site is completely done with styles. If you have a browser that can, you can turn off style sheets and you will see a plain white text page with no pictures anywhere, except where it was part of the data being rendered (e.g. the CD Cover picture). >From: Brian Brown >Reply-To: "Magritte, Pier and Related Tools ..." >To: "Magritte, Pier and Related Tools ..." >Subject: Re: Examples of Pier Sites >Date: Tue, 30 Jan 2007 11:32:17 -0700 > > >On Jan 30, 2007, at 10:33 AM, Brad Fuller wrote: > > > Philippe Marschall wrote: > >> 2007/1/30, Brad Fuller : > >>> Brad Fuller wrote: > >>> I was going to send an email about Pier and I couldn't come up > >>> with any > >>> example sites. Can anyone reply with some links that I can use? > >> > >> http://www.lukas-renggli.ch/ > >> http://swiki.gsug.org/ > >> > >>> oh... another question. Anyone run a "forum" in Pier? > >> > >> I know of no forum add-on for Pier. > >> > > > > Thanks Philippe, > > > > Let me ask if there are any forum's running on any seaside? > > > > > >I have one in rough form that is running on Seaside, somewhat like >phpBB in functionality. > >Brian > > > > -- > > brad fuller > > http://www.Sonaural.com/ > > +1 (408) 799-6124 > > > > > > > > _______________________________________________ > > SmallWiki, Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > >_______________________________________________ >SmallWiki, Magritte, Pier and Related Tools ... >https://www.iam.unibe.ch/mailman/listinfo/smallwiki _________________________________________________________________ Get live scores and news about your team: Add the Live.com Football Page http://www.live.com/?addtemplate=football From azreal1977 at hotmail.com Tue Jan 30 22:15:07 2007 From: azreal1977 at hotmail.com (J J) Date: Tue, 30 Jan 2007 21:15:07 +0000 Subject: Status of Pier Message-ID: Hello all, I have been working with Pier a bit lately, and I noticed a couple of things I was curious about. First, in my image, if you go to a page and then go to lunch, come back and hour later and click a link you get dropped back to the front page because your session has expired. But I thought Pier used the URL to be able bookmark, surf the side via URL etc. In fact, I thought it even worked this way before I put the security package in. Has this been fixed? It seems like if you click on a link that has a URL, but an old session Pier could just make a new session and apply that to the page the user is trying to go to. If the user is not allowed to see that resource with the blank session then kick them back to the front like now, but if the page is not restricted they should see it. Second, is there any plan to expand on the RESTfulness of Pier? I mean, I'm not a die-hard REST person or anything, but there are times it would be nice to use URL's. I think the above suggested handling would probably be enough. One thing that makes me want this is the difficulty of pointing to another page in your Pier site from a custom component. I know you have the #goto: message on anchor, but (1) I need it anywhere a URL could be used, since I am using "html tag:" to do some tags not in seaside (an HTML image map to be specific). And (2) the #goto: message expects a structure that can be tough to get a hold of sometimes. The easiest thing for me would be if I could simply point my image map at the URL as a string, since that part is public and I don't care if the user is logged in or not. And lastly, I have had some users complain about the ugly URL's. I know you can say that they shouldn't look at the URL, etc. etc., but if we can make this better why not? What I was thinking was, how hard would it be to change Pier so that the URL part stays, but at least the session (and maybe the command and view fields as well) could optionally be cookies. And this could even be something configured in the /seaside/config/pier page. Thanks in advance. You may have ways to do all these things by now, but I thought I would check. Jason _________________________________________________________________ Valentine’s Day -- Shop for gifts that spell L-O-V-E at MSN Shopping http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tcode=wlmtagline From renggli at iam.unibe.ch Tue Jan 30 23:27:30 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 30 Jan 2007 23:27:30 +0100 Subject: Status of Pier In-Reply-To: References: Message-ID: <1A70C3DE-47FD-4CC3-A2D6-B8E0A3AB3F26@iam.unibe.ch> > First, in my image, if you go to a page and then go to lunch, come > back and hour later and click a link you get dropped back to the > front page because your session has expired. But I thought Pier > used the URL to be able bookmark, surf the side via URL etc. In > fact, I thought it even worked this way before I put the security > package in. Yes, it should work and remember the page even if the session expired. > Has this been fixed? It seems like if you click on a link that has > a URL, but an old session Pier could just make a new session and > apply that to the page the user is trying to go to. If the user is > not allowed to see that resource with the blank session then kick > them back to the front like now, but if the page is not restricted > they should see it. This is a bug in Seaside. I fixed it, and the scenario you describe works when you load the latest version: Name: Seaside2.7a1-lr.162 Author: lr Time: 30 January 2007, 11:23:44 pm UUID: b22fe0c4-77c1-4e3d-99f7-331a368c4337 Ancestors: Seaside2.7a1-pmm.161 > Second, is there any plan to expand on the RESTfulness of Pier? I > mean, I'm not a die-hard REST person or anything, but there are > times it would be nice to use URL's. I think the above suggested > handling would probably be enough. Yep, that's a requirement. Thanks that you reported this, I probably wouldn't have noticed it myself. > One thing that makes me want this is the difficulty of pointing to > another page in your Pier site from a custom component. I know you > have the #goto: message on anchor, but (1) I need it anywhere a URL > could be used, since I am using "html tag:" to do some tags not in > seaside (an HTML image map to be specific). And (2) the #goto: > message expects a structure that can be tough to get a hold of > sometimes. The easiest thing for me would be if I could simply > point my image map at the URL as a string, since that part is > public and I don't care if the user is logged in or not. Glad that you ask. For the blog component I also felt the need to have just the url and not only an anchor. I think I will need to add that sooner or later. Shouldn't be too difficult though. > And lastly, I have had some users complain about the ugly URL's. I > know you can say that they shouldn't look at the URL, etc. etc., > but if we can make this better why not? > > What I was thinking was, how hard would it be to change Pier so > that the URL part stays, but at least the session (and maybe the > command and view fields as well) could optionally be cookies. And > this could even be something configured in the /seaside/config/pier > page. Go to the Seaside configuration page and enable 'Use Session Cookies'. This will put the session key into a cookie, if possible. > Thanks in advance. You may have ways to do all these things by > now, but I thought I would check. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch