smallwiki

smallwiki@list.inf.unibe.ch

2312 discussions

by Lawson English

I allow users to add gadgets but nothing shows up http://www.gmodules.com/ig/ifr?url=http://bejeweledg.googlecode.com/svn/tru… pasted into the URL box for the gadget doesn't work. However, {{{<script src="http://www.gmodules.com/ig/ifr?url=http://bejeweledg.googlecode.com/svn/tru…"></script>}}} added to the edit box of the page, does. Suggestions? Thanks. Lawson

14 years, 3 months

Re: [GS/SS Beta] Gemstone and Magritte caching and classHistory

by Dale Henrichs

Otto Behrens wrote: > Hi, > > We do the following on every release. Still running 2.8 though. > > MCMethodDefinition cachedDefinitions removeKeys: (MCMethodDefinition > cachedDefinitions keys). > MCMethodDefinition shutDown. > MCFileBasedRepository fastAllSubInstancesDo: [:ea | ea flushCache]. > System commitTransaction. > > HTH I have been thinking about making these caches into session-based caches rather persistent caches ... weak collections are used in Pharo (which we don't have in GemStone) so persistent caches _are_ overkill.. Dale > > On Tue, Sep 28, 2010 at 8:59 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> Hi, >> >> On 28.09.2010, at 19:43, Nick Ager wrote: >> >>> Hi, >>> >>> I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. >>> >>> I've a model component which define's it's own class side descriptionContainer: >>> >>> MyModel class descriptionContainer >>> ^ super descriptionContainer >>> componentClass: IZUIProjectEditor; >>> yourself. >>> >>> However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: >>> >>> IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" >>> >>> The solution I found was to flush the Magritte description cache: >>> >>> MADescriptionBuilder default flush >>> >>> >>> Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? >>> >> This is a two-fold problem. One is that Magritte caches descriptions. So you might have to reset the magritte cache if you change a description. If you update code than you run into a gemstone specific issues. If you use a class name inside of code than you are pinpointing that piece of code to a certain class object. Updating code creates another class object that is now lookupable from the environment (Smalltalk). The compiled methods stay the same and pointing to the old class object. >> >>> From the Gemstone side should I worry that: >>> IZUIProjectEditor classHistory size = 6 >>> >>> How do I go about chasing down other references to old classes within Gemstone? >>> >> I don't know yet but I'll investigate this. >> >> Norbert >> >> >>

14 years, 3 months

Re: [GS/SS Beta] Gemstone and Magritte caching and classHistory

by Norbert Hartl

Hi Otto, can you explain what particular problem you are solving with this? Norbert On 29.09.2010, at 10:54, Otto Behrens wrote: > Hi, > > We do the following on every release. Still running 2.8 though. > > MCMethodDefinition cachedDefinitions removeKeys: (MCMethodDefinition > cachedDefinitions keys). > MCMethodDefinition shutDown. > MCFileBasedRepository fastAllSubInstancesDo: [:ea | ea flushCache]. > System commitTransaction. > > HTH > > On Tue, Sep 28, 2010 at 8:59 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> Hi, >> >> On 28.09.2010, at 19:43, Nick Ager wrote: >> >>> Hi, >>> >>> I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. >>> >>> I've a model component which define's it's own class side descriptionContainer: >>> >>> MyModel class descriptionContainer >>> ^ super descriptionContainer >>> componentClass: IZUIProjectEditor; >>> yourself. >>> >>> However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: >>> >>> IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" >>> >>> The solution I found was to flush the Magritte description cache: >>> >>> MADescriptionBuilder default flush >>> >>> >>> Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? >>> >> This is a two-fold problem. One is that Magritte caches descriptions. So you might have to reset the magritte cache if you change a description. If you update code than you run into a gemstone specific issues. If you use a class name inside of code than you are pinpointing that piece of code to a certain class object. Updating code creates another class object that is now lookupable from the environment (Smalltalk). The compiled methods stay the same and pointing to the old class object. >> >>> From the Gemstone side should I worry that: >>> IZUIProjectEditor classHistory size = 6 >>> >>> How do I go about chasing down other references to old classes within Gemstone? >>> >> I don't know yet but I'll investigate this. >> >> Norbert >> >> >>

14 years, 3 months

Gemstone and Magritte caching and classHistory

by Nick Ager

Hi, I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. I've a model component which define's it's own class side descriptionContainer: MyModel class descriptionContainer ^ super descriptionContainer componentClass: IZUIProjectEditor; yourself. However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" The solution I found was to flush the Magritte description cache: MADescriptionBuilder default flush Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? >From the Gemstone side should I worry that: IZUIProjectEditor classHistory size = 6 How do I go about chasing down other references to old classes within Gemstone? Nick

14 years, 3 months

Re: PUUser class>>descriptionFullName

by Lukas Renggli

Hi Damien, > here is a description that can be found in Pier: > > PUUser class>>descriptionFullName > ^ MAStringDescription new > parameterName: 'full-name'; > accessor: #fullName; > beReadonly; > beHidden; > yourself > > > The write selector #fullName: (with the $:) is not defined in PUUser. > It is probably not a problem, but I wanted to know if it would not be > safer to write the following instead: The description is read-only, so the write accessor is never used anyway. > PUUser class>>descriptionFullName > ... > accessor: (MAAccessor read: #fullName); > ... > > what do you think?' The #read: and #write constructor methods are leftovers from very old Magritte versions. They should not be used any longer (and I removed them just now). The accessors shouldn't know about readonly or not, only if the object can be read and can be written (physically). Thanks for pointing out. Lukas -- Lukas Renggli www.lukas-renggli.ch

14 years, 3 months

permissions system use-cases

by Lawson English

I guess a better way to ask my questions is to give a series of use cases. I've tried this with the one-click Seaside 3.0 final with Pier2 installed and with Squeak 4.1 with Seaside 3.0 and Pier2 installed. I installed pier on both via ConfigurationOfPier2 and ConfigurationofPierAddOns2 and still can't figure it out... Most important use case right now: have a group that is allowed to add new blog posts, as well as comment on existing blog posts, but can't otherwise affect the Pier installation. I honestly can't figure out how to do this. Thanks. Lawson

14 years, 3 months

Pier newbie question

by Dr. Johannes Brauer

Hi, I just downloaded Pier 2.0 (Mac Os). After having started pier and localhost:8080 (on Safari) and trying to login the debugger pops up with the message error: this collection is empty What is going wrong? Johannes ________________________________ Staatlich anerkannte private Fachhochschule NORDAKADEMIE Gemeinnützige Aktiengesellschaft Köllner Chaussee 11 25337 Elmshorn Vorstand: Prof. Dr. Georg Plate (Vorsitzender), Dipl.-Ing. Jörg Meier (stellv. Vorstand) Vorsitzender des Aufsichtsrats: Dr. h.c. Hans-Heinrich Bruns Sitz: Elmshorn, Amtsgericht Elmshorn, HRB 1682

14 years, 3 months

permissions system is confusing

by Lawson English

I've managed to do it before, but I'm starting over from scratch and trying to be methodical and I've forgotten something. When I add a new user "testuser" and a group "testgroup" and make no changes to anything, things work as expected. However, the more I try to hone the permissions for group "testgroup" the less certain I am what is supposed to happen. For example, it proves to be extremely easy to disable the ability to logout. How do I leave this ability for specific users and/or members of a group. Also, at times, if I DO lose the ability to log out for a given user, I also lose the ability to login, period. I've had to start over from scratch quite a few times because I'm suddenly unable to log back in, even though I never touched permissions for admin/pier and the admin group. Lawson

14 years, 3 months

PRFile subclass on Gemstone Pier

by dtrussardi＠tiscali.it

Hi, i work with the Gemstone version of Pier 2.0. I use PRFile to save data into OODB but i'm interested to save some Files directly into directory on the server. For this i create a subclass of PRFile named PRFileOnDisk. In this class i define the method: isAbstract ^false label: ^ 'FIle on disk'. The fileModel class method return: ^ ISTMAExternalFileModel and the descriptionFile is set to: ^ MAFileDescription new kind: ISTMAExternalFileModel; accessor: #file; priority: 300; label: 'File on Disk'; beEditable; yourself The ISTMAExternalFileModel is a subclass of MAExternalFileModel and it work fine ( create directory and save data on the server disk ) for other Magritte description based on MAFileDescription ( with kind set to ISTMAExternalFileModel ). Now when in Pier i define a link with Type: 'File on disk' ( based on PRFileOnDisk ) the system create the subdirectory on the server disk but don't save the file on it . The file is managed how MAMemoryFileModel. Any idea about it ? Thanks, Dario

14 years, 3 months

Pier theme images not showing locally

by Pablo Gancharov

Hi, can someone explain to me why my pier installation can show the images of the theme in the seasidehosting.st server , but not show any theme image when I run pier locally. Locally I'm using the same image as at seasidehosting. Locally I use the default initialize method: "WAKomEncoded startOn: 8080." Thanks in advance.

14 years, 3 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki