A new version of Monticello was added to project The Inbox:
http://source.squeak.org/inbox/Monticello-topa.585.mcz ==================== Summary ==================== Name: Monticello-topa.585 Author: topa Time: 25 January 2014, 10:08:51.15 pm UUID: ff122640-845a-402a-bd97-9fc79daea119 Ancestors: Monticello-cmm.583 The number of distinct authors in the image is low: (MCVersionInfo allInstances collect: [ :each | each author ]) asIdentitySet size. "13336" (MCVersionInfo allInstances collect: [ :each | each author ]) asSet size. "128" Hence, we can safely store them as symbols. This does not save much memory in a small image but should in production images. =============== Diff against Monticello-cmm.583 =============== Item was changed: ----- Method: MCVersionInfo>>asDictionary (in category 'converting') ----- asDictionary ^ Dictionary new at: #name put: name; at: #id put: id asString; at: #message put: message; at: #date put: date; at: #time put: time; + at: #author put: self author; - at: #author put: author; at: #ancestors put: (self ancestors collect: [:a | a asDictionary]); yourself! Item was changed: ----- Method: MCVersionInfo>>author (in category 'pillaging') ----- author + ^ author asString! - ^ author! Item was changed: ----- Method: MCVersionInfo>>initializeWithName:id:message:date:time:author:ancestors:stepChildren: (in category 'initialize-release') ----- initializeWithName: vName id: aUUID message: aString date: aDate time: aTime author: initials ancestors: aCollection stepChildren: stepCollection name := vName asString asMCVersionName. id := aUUID. message := aString. date := aDate. time := aTime. + author := initials ifNotNil: [:str | str asSymbol]. - author := initials. ancestors := aCollection. stepChildren := stepCollection! Item was changed: ----- Method: MCVersionInfo>>summaryHeader (in category 'accessing') ----- summaryHeader ^ String streamContents: [:s | s nextPutAll: 'Name: '; nextPutAll: self name; cr. date ifNotNil: [s + nextPutAll: 'Author: '; nextPutAll: self author; cr; - nextPutAll: 'Author: '; nextPutAll: author; cr; nextPutAll: 'Time: '; nextPutAll: date asString, ', ', time asString; cr]. id ifNotNil: [s nextPutAll: 'UUID: '; nextPutAll: id asString; cr]. s nextPutAll: 'Ancestors: '; nextPutAll: self ancestorString. self stepChildren isEmpty ifFalse: [s cr; nextPutAll: 'Backported From: '; nextPutAll: self stepChildrenString]. ]! Item was added: + (PackageInfo named: 'Monticello') postscript: '(MCVersionInfo allInstances select: [ :ea | (ea instVarNamed: ''author'') isSymbol not ]) + do: [ :ea | ea instVarNamed: ''author'' put: (ea instVarNamed: ''author'') asSymbol] + '! |
I’m late to the 4.5 wagon, I know.
Probably this is not much but who knows: This was hinted by Stephan Eggermont. In one image that saved me 100k, but I think in images with much more versions loaded (seaside, magma, devel images) this could actually save a bunch. Best -Tobias PS: ignore 584, i had my changes file corrupted. On 25.01.2014, at 21:08, [hidden email] wrote: > A new version of Monticello was added to project The Inbox: > http://source.squeak.org/inbox/Monticello-topa.585.mcz > > ==================== Summary ==================== > > Name: Monticello-topa.585 > Author: topa > Time: 25 January 2014, 10:08:51.15 pm > UUID: ff122640-845a-402a-bd97-9fc79daea119 > Ancestors: Monticello-cmm.583 > > The number of distinct authors in the image is low: > (MCVersionInfo allInstances collect: [ :each | each author ]) asIdentitySet size. "13336" > (MCVersionInfo allInstances collect: [ :each | each author ]) asSet size. "128" > > Hence, we can safely store them as symbols. > This does not save much memory in a small image but should in > production images. > > =============== Diff against Monticello-cmm.583 =============== > > Item was changed: > ----- Method: MCVersionInfo>>asDictionary (in category 'converting') ----- > asDictionary > ^ Dictionary new > at: #name put: name; > at: #id put: id asString; > at: #message put: message; > at: #date put: date; > at: #time put: time; > + at: #author put: self author; > - at: #author put: author; > at: #ancestors put: (self ancestors collect: [:a | a asDictionary]); > yourself! > > Item was changed: > ----- Method: MCVersionInfo>>author (in category 'pillaging') ----- > author > + ^ author asString! > - ^ author! > > Item was changed: > ----- Method: MCVersionInfo>>initializeWithName:id:message:date:time:author:ancestors:stepChildren: (in category 'initialize-release') ----- > initializeWithName: vName id: aUUID message: aString date: aDate time: aTime author: initials ancestors: aCollection stepChildren: stepCollection > name := vName asString asMCVersionName. > id := aUUID. > message := aString. > date := aDate. > time := aTime. > + author := initials ifNotNil: [:str | str asSymbol]. > - author := initials. > ancestors := aCollection. > stepChildren := stepCollection! > > Item was changed: > ----- Method: MCVersionInfo>>summaryHeader (in category 'accessing') ----- > summaryHeader > ^ String streamContents: > [:s | > s > nextPutAll: 'Name: '; nextPutAll: self name; cr. > date ifNotNil: > [s > + nextPutAll: 'Author: '; nextPutAll: self author; cr; > - nextPutAll: 'Author: '; nextPutAll: author; cr; > nextPutAll: 'Time: '; nextPutAll: date asString, ', ', time asString; cr]. > id ifNotNil: > [s nextPutAll: 'UUID: '; nextPutAll: id asString; cr]. > s > nextPutAll: 'Ancestors: '; nextPutAll: self ancestorString. > self stepChildren isEmpty ifFalse: > [s cr; nextPutAll: 'Backported From: '; nextPutAll: self stepChildrenString]. > ]! > > Item was added: > + (PackageInfo named: 'Monticello') postscript: '(MCVersionInfo allInstances select: [ :ea | (ea instVarNamed: ''author'') isSymbol not ]) > + do: [ :ea | ea instVarNamed: ''author'' put: (ea instVarNamed: ''author'') asSymbol] > + '! > > signature.asc (1K) Download Attachment |
Symbols are one way to canonicalize Strings. Another way is to
introduce one's own canoncalized IdentityDictionary of author strings. Whenever a Symbol is not going to be a selector name, I tend to prefer the latter. On Sat, Jan 25, 2014 at 3:11 PM, Tobias Pape <[hidden email]> wrote: > I’m late to the 4.5 wagon, I know. > Probably this is not much but who knows: > > This was hinted by Stephan Eggermont. > In one image that saved me 100k, but I think in images with much more > versions loaded (seaside, magma, devel images) this could actually save a bunch. > > Best > -Tobias > PS: ignore 584, i had my changes file corrupted. > > > On 25.01.2014, at 21:08, [hidden email] wrote: > >> A new version of Monticello was added to project The Inbox: >> http://source.squeak.org/inbox/Monticello-topa.585.mcz >> >> ==================== Summary ==================== >> >> Name: Monticello-topa.585 >> Author: topa >> Time: 25 January 2014, 10:08:51.15 pm >> UUID: ff122640-845a-402a-bd97-9fc79daea119 >> Ancestors: Monticello-cmm.583 >> >> The number of distinct authors in the image is low: >> (MCVersionInfo allInstances collect: [ :each | each author ]) asIdentitySet size. "13336" >> (MCVersionInfo allInstances collect: [ :each | each author ]) asSet size. "128" >> >> Hence, we can safely store them as symbols. >> This does not save much memory in a small image but should in >> production images. >> >> =============== Diff against Monticello-cmm.583 =============== >> >> Item was changed: >> ----- Method: MCVersionInfo>>asDictionary (in category 'converting') ----- >> asDictionary >> ^ Dictionary new >> at: #name put: name; >> at: #id put: id asString; >> at: #message put: message; >> at: #date put: date; >> at: #time put: time; >> + at: #author put: self author; >> - at: #author put: author; >> at: #ancestors put: (self ancestors collect: [:a | a asDictionary]); >> yourself! >> >> Item was changed: >> ----- Method: MCVersionInfo>>author (in category 'pillaging') ----- >> author >> + ^ author asString! >> - ^ author! >> >> Item was changed: >> ----- Method: MCVersionInfo>>initializeWithName:id:message:date:time:author:ancestors:stepChildren: (in category 'initialize-release') ----- >> initializeWithName: vName id: aUUID message: aString date: aDate time: aTime author: initials ancestors: aCollection stepChildren: stepCollection >> name := vName asString asMCVersionName. >> id := aUUID. >> message := aString. >> date := aDate. >> time := aTime. >> + author := initials ifNotNil: [:str | str asSymbol]. >> - author := initials. >> ancestors := aCollection. >> stepChildren := stepCollection! >> >> Item was changed: >> ----- Method: MCVersionInfo>>summaryHeader (in category 'accessing') ----- >> summaryHeader >> ^ String streamContents: >> [:s | >> s >> nextPutAll: 'Name: '; nextPutAll: self name; cr. >> date ifNotNil: >> [s >> + nextPutAll: 'Author: '; nextPutAll: self author; cr; >> - nextPutAll: 'Author: '; nextPutAll: author; cr; >> nextPutAll: 'Time: '; nextPutAll: date asString, ', ', time asString; cr]. >> id ifNotNil: >> [s nextPutAll: 'UUID: '; nextPutAll: id asString; cr]. >> s >> nextPutAll: 'Ancestors: '; nextPutAll: self ancestorString. >> self stepChildren isEmpty ifFalse: >> [s cr; nextPutAll: 'Backported From: '; nextPutAll: self stepChildrenString]. >> ]! >> >> Item was added: >> + (PackageInfo named: 'Monticello') postscript: '(MCVersionInfo allInstances select: [ :ea | (ea instVarNamed: ''author'') isSymbol not ]) >> + do: [ :ea | ea instVarNamed: ''author'' put: (ea instVarNamed: ''author'') asSymbol] >> + '! >> >> > > > > |
On 26.01.2014, at 18:00, Chris Muller <[hidden email]> wrote: > Symbols are one way to canonicalize Strings. Another way is to > introduce one's own canoncalized IdentityDictionary of author strings. > > Whenever a Symbol is not going to be a selector name, I tend to prefer > the latter. Why? |
I ask you not to put this into trunk. I actually have recent
experience with this exact issue. Let me explain. So, Monticello is not the only application to have lots and lots of redundant String instances. MANY applications have that. And MC also has lots of redundant Date instances (one per VersionInfo), as do many other apps. And sometimes lots of redundant Float instances (i.e., 0.0, 1.0, and 100.0 often will have lots of instances). So slamming application-specific Strings into the SymbolTable does not solve the overarching problem while at the same time raising several new (non-obvious) issues of its own. One issue relates whether the app will ever want to scale into a database. When an object is retrieved from a database, that object is associated with a particular DB Session, by identity. But persistent Symbol objects, by their nature, cannot be associated to only one Session, because there can only be one in the image. The Monticello application is _already_ scaled into a database, Magma. Each of my own application instances has its own SharedObjects container. It's just a simple wrapper of some IdentityDictionary's, one for Dates, one for literals (incl. Strings). This way, each object belongs in its own persistent domain, and remaining a String to avoid being forced to be shared across persistent domains. We should not let any one app bloat the SymbolTable (which can slow down the system for ALL apps) merely for this purpose. If we want to address this data redundancy, we should do so explicitly in the app (MC). This is a recurring issue we should address it with a reusable first-class SharedObjectsContainer (or something else acceptable). Thanks. On Sun, Jan 26, 2014 at 11:06 AM, Tobias Pape <[hidden email]> wrote: > > On 26.01.2014, at 18:00, Chris Muller <[hidden email]> wrote: > >> Symbols are one way to canonicalize Strings. Another way is to >> introduce one's own canoncalized IdentityDictionary of author strings. >> >> Whenever a Symbol is not going to be a selector name, I tend to prefer >> the latter. > > Why? > > > |
On 26 January 2014 23:45, Chris Muller <[hidden email]> wrote:
> I ask you not to put this into trunk. I actually have recent > experience with this exact issue. Let me explain. > > So, Monticello is not the only application to have lots and lots of > redundant String instances. MANY applications have that. And MC also > has lots of redundant Date instances (one per VersionInfo), as do many > other apps. And sometimes lots of redundant Float instances (i.e., > 0.0, 1.0, and 100.0 often will have lots of instances). So slamming > application-specific Strings into the SymbolTable does not solve the > overarching problem while at the same time raising several new > (non-obvious) issues of its own. > > One issue relates whether the app will ever want to scale into a > database. When an object is retrieved from a database, that object is > associated with a particular DB Session, by identity. But persistent > Symbol objects, by their nature, cannot be associated to only one > Session, because there can only be one in the image. > > The Monticello application is _already_ scaled into a database, Magma. > > Each of my own application instances has its own SharedObjects > container. It's just a simple wrapper of some IdentityDictionary's, > one for Dates, one for literals (incl. Strings). This way, each > object belongs in its own persistent domain, and remaining a String to > avoid being forced to be shared across persistent domains. > > We should not let any one app bloat the SymbolTable (which can slow > down the system for ALL apps) merely for this purpose. If we want to > address this data redundancy, we should do so explicitly in the app > (MC). This is a recurring issue we should address it with a reusable > first-class SharedObjectsContainer (or something else acceptable). > > Thanks. In other words, if an app has a problem with lots of "duplicate" value objects, it ought to have its own cache of these value objects. I think that's sound. frank > On Sun, Jan 26, 2014 at 11:06 AM, Tobias Pape <[hidden email]> wrote: >> >> On 26.01.2014, at 18:00, Chris Muller <[hidden email]> wrote: >> >>> Symbols are one way to canonicalize Strings. Another way is to >>> introduce one's own canoncalized IdentityDictionary of author strings. >>> >>> Whenever a Symbol is not going to be a selector name, I tend to prefer >>> the latter. >> >> Why? >> >> >> > |
In reply to this post by commits-2
Chris wrote:
>Each of my own application instances has its own SharedObjects >container. It's just a simple wrapper of some IdentityDictionary's, >one for Dates, one for literals (incl. Strings). This way, each >object belongs in its own persistent domain, and remaining a String to >avoid being forced to be shared across persistent domains. > >We should not let any one app bloat the SymbolTable (which can slow >down the system for ALL apps) merely for this purpose. If we want to >address this data redundancy, we should do so explicitly in the app >(MC). This is a recurring issue we should address it with a reusable >first-class SharedObjectsContainer (or something else acceptable). Ha, that’s the kind of comments I was hoping for. Thanks Tobias for pushing this. An application specific value object cache makes sense. Stephan |
On 27.01.2014, at 12:06, Stephan Eggermont <[hidden email]> wrote: > Chris wrote: >> Each of my own application instances has its own SharedObjects >> container. It's just a simple wrapper of some IdentityDictionary's, >> one for Dates, one for literals (incl. Strings). This way, each >> object belongs in its own persistent domain, and remaining a String to >> avoid being forced to be shared across persistent domains. >> >> We should not let any one app bloat the SymbolTable (which can slow >> down the system for ALL apps) merely for this purpose. If we want to >> address this data redundancy, we should do so explicitly in the app >> (MC). This is a recurring issue we should address it with a reusable >> first-class SharedObjectsContainer (or something else acceptable). > > Ha, that’s the kind of comments I was hoping for. Thanks Tobias for > pushing this. An application specific value object cache makes sense. > > Stephan > > Best -Tobias signature.asc (1K) Download Attachment |
On 27.01.2014, at 12:27, Tobias Pape <[hidden email]> wrote:
> On 27.01.2014, at 12:06, Stephan Eggermont <[hidden email]> wrote: > >> Chris wrote: >>> Each of my own application instances has its own SharedObjects >>> container. It's just a simple wrapper of some IdentityDictionary's, >>> one for Dates, one for literals (incl. Strings). This way, each >>> object belongs in its own persistent domain, and remaining a String to >>> avoid being forced to be shared across persistent domains. >>> >>> We should not let any one app bloat the SymbolTable (which can slow >>> down the system for ALL apps) merely for this purpose. If we want to >>> address this data redundancy, we should do so explicitly in the app >>> (MC). This is a recurring issue we should address it with a reusable >>> first-class SharedObjectsContainer (or something else acceptable). >> >> Ha, that’s the kind of comments I was hoping for. Thanks Tobias for >> pushing this. An application specific value object cache makes sense. >> >> Stephan >> >> > > May we schedule this for 4.6? > > Best > -Tobias MC already re-uses MCDefinitions, with a special cache. Generalizing this sounds like a Good Idea. - Bert - smime.p7s (5K) Download Attachment |
In reply to this post by Chris Muller-3
Hi,
below.. Am 27.01.2014 00:45, schrieb Chris Muller: > One issue relates whether the app will ever want to scale into a > database. When an object is retrieved from a database, that object is > associated with a particular DB Session, by identity. But persistent > Symbol objects, by their nature, cannot be associated to only one > Session, because there can only be one in the image. > Thanks for this post. I had about 500.000 testresults per week and I converted date (7), Teststation (~25) and failureCause (~100) into Symbols. Everything worked fine and at a blazing speed because of the selection via symbols and I had everything in Memory. I assumed that a lot of different symbols (as compared to the 35000 ones in a 4.4 image) would slow down the whole system. If the next customer has higher production your post will save me a lot of headache if I need a database then. Cheers Herbert |
In reply to this post by Tobias Pape
On 27 January 2014 11:27, Tobias Pape <[hidden email]> wrote:
> > On 27.01.2014, at 12:06, Stephan Eggermont <[hidden email]> wrote: > >> Chris wrote: >>> Each of my own application instances has its own SharedObjects >>> container. It's just a simple wrapper of some IdentityDictionary's, >>> one for Dates, one for literals (incl. Strings). This way, each >>> object belongs in its own persistent domain, and remaining a String to >>> avoid being forced to be shared across persistent domains. >>> >>> We should not let any one app bloat the SymbolTable (which can slow >>> down the system for ALL apps) merely for this purpose. If we want to >>> address this data redundancy, we should do so explicitly in the app >>> (MC). This is a recurring issue we should address it with a reusable >>> first-class SharedObjectsContainer (or something else acceptable). >> >> Ha, that’s the kind of comments I was hoping for. Thanks Tobias for >> pushing this. An application specific value object cache makes sense. >> >> Stephan >> >> > > May we schedule this for 4.6? Sounds like a good idea. Would you mind updating http://wiki.squeak.org/squeak/6192 accordingly? frank > Best > -Tobias > > > |
On 27.01.2014, at 14:17, Frank Shearar <[hidden email]> wrote: > On 27 January 2014 11:27, Tobias Pape <[hidden email]> wrote: >> >> On 27.01.2014, at 12:06, Stephan Eggermont <[hidden email]> wrote: >> >>> Chris wrote: >>>> Each of my own application instances has its own SharedObjects >>>> container. It's just a simple wrapper of some IdentityDictionary's, >>>> one for Dates, one for literals (incl. Strings). This way, each >>>> object belongs in its own persistent domain, and remaining a String to >>>> avoid being forced to be shared across persistent domains. >>>> >>>> We should not let any one app bloat the SymbolTable (which can slow >>>> down the system for ALL apps) merely for this purpose. If we want to >>>> address this data redundancy, we should do so explicitly in the app >>>> (MC). This is a recurring issue we should address it with a reusable >>>> first-class SharedObjectsContainer (or something else acceptable). >>> >>> Ha, that’s the kind of comments I was hoping for. Thanks Tobias for >>> pushing this. An application specific value object cache makes sense. >>> >>> Stephan >>> >>> >> >> May we schedule this for 4.6? > > Sounds like a good idea. Would you mind updating > http://wiki.squeak.org/squeak/6192 accordingly? Best -Tobias signature.asc (1K) Download Attachment |
On 27 January 2014 13:25, Tobias Pape <[hidden email]> wrote:
> > On 27.01.2014, at 14:17, Frank Shearar <[hidden email]> wrote: > >> On 27 January 2014 11:27, Tobias Pape <[hidden email]> wrote: >>> >>> On 27.01.2014, at 12:06, Stephan Eggermont <[hidden email]> wrote: >>> >>>> Chris wrote: >>>>> Each of my own application instances has its own SharedObjects >>>>> container. It's just a simple wrapper of some IdentityDictionary's, >>>>> one for Dates, one for literals (incl. Strings). This way, each >>>>> object belongs in its own persistent domain, and remaining a String to >>>>> avoid being forced to be shared across persistent domains. >>>>> >>>>> We should not let any one app bloat the SymbolTable (which can slow >>>>> down the system for ALL apps) merely for this purpose. If we want to >>>>> address this data redundancy, we should do so explicitly in the app >>>>> (MC). This is a recurring issue we should address it with a reusable >>>>> first-class SharedObjectsContainer (or something else acceptable). >>>> >>>> Ha, that’s the kind of comments I was hoping for. Thanks Tobias for >>>> pushing this. An application specific value object cache makes sense. >>>> >>>> Stephan >>>> >>>> >>> >>> May we schedule this for 4.6? >> >> Sounds like a good idea. Would you mind updating >> http://wiki.squeak.org/squeak/6192 accordingly? > > Can I? I'm confused: are you asking for permission? ("yes, of course, since you're a member of the Squeak community, and the 4.6 list of requests is for everyone") Or are you asking for the ability? (Because you don't know the password.) frank > Best > -Tobias > > > > |
On 27.01.2014, at 14:34, Frank Shearar <[hidden email]> wrote: > On 27 January 2014 13:25, Tobias Pape <[hidden email]> wrote: >> >> On 27.01.2014, at 14:17, Frank Shearar <[hidden email]> wrote: >> >>> On 27 January 2014 11:27, Tobias Pape <[hidden email]> wrote: >>>> >>>> On 27.01.2014, at 12:06, Stephan Eggermont <[hidden email]> wrote: >>>> >>>>> Chris wrote: >>>>>> Each of my own application instances has its own SharedObjects >>>>>> container. It's just a simple wrapper of some IdentityDictionary's, >>>>>> one for Dates, one for literals (incl. Strings). This way, each >>>>>> object belongs in its own persistent domain, and remaining a String to >>>>>> avoid being forced to be shared across persistent domains. >>>>>> >>>>>> We should not let any one app bloat the SymbolTable (which can slow >>>>>> down the system for ALL apps) merely for this purpose. If we want to >>>>>> address this data redundancy, we should do so explicitly in the app >>>>>> (MC). This is a recurring issue we should address it with a reusable >>>>>> first-class SharedObjectsContainer (or something else acceptable). >>>>> >>>>> Ha, that’s the kind of comments I was hoping for. Thanks Tobias for >>>>> pushing this. An application specific value object cache makes sense. >>>>> >>>>> Stephan >>>>> >>>>> >>>> >>>> May we schedule this for 4.6? >>> >>> Sounds like a good idea. Would you mind updating >>> http://wiki.squeak.org/squeak/6192 accordingly? >> >> Can I? > > I'm confused: are you asking for permission? ("yes, of course, since > you're a member of the Squeak community, and the 4.6 list of requests > is for everyone") Or are you asking for the ability? (Because you > don't know the password.) Best -Tobias PS: I have up until now never used the swiki… Probably we should have a meta-4.6 todo for nicer swiki urls? ;) signature.asc (1K) Download Attachment |
On 27.01.2014, at 14:48, Tobias Pape <[hidden email]> wrote:
> On 27.01.2014, at 14:34, Frank Shearar <[hidden email]> wrote: > >> On 27 January 2014 13:25, Tobias Pape <[hidden email]> wrote: >>> >>> On 27.01.2014, at 14:17, Frank Shearar <[hidden email]> wrote: >>>> Sounds like a good idea. Would you mind updating >>>> http://wiki.squeak.org/squeak/6192 accordingly? >>> >>> Can I? >> >> I'm confused: are you asking for permission? ("yes, of course, since >> you're a member of the Squeak community, and the 4.6 list of requests >> is for everyone") Or are you asking for the ability? (Because you >> don't know the password.) > > The latter :) > > Best > -Tobias > > PS: I have up until now never used the swiki… > Probably we should have a meta-4.6 todo for nicer swiki urls? ;) Username: squeak Password: viewpoints - Bert - smime.p7s (5K) Download Attachment |
On 27.01.2014, at 14:56, Bert Freudenberg <[hidden email]> wrote: > On 27.01.2014, at 14:48, Tobias Pape <[hidden email]> wrote: > >> On 27.01.2014, at 14:34, Frank Shearar <[hidden email]> wrote: >> >>> On 27 January 2014 13:25, Tobias Pape <[hidden email]> wrote: >>>> >>>> On 27.01.2014, at 14:17, Frank Shearar <[hidden email]> wrote: >>>>> Sounds like a good idea. Would you mind updating >>>>> http://wiki.squeak.org/squeak/6192 accordingly? >>>> >>>> Can I? >>> >>> I'm confused: are you asking for permission? ("yes, of course, since >>> you're a member of the Squeak community, and the 4.6 list of requests >>> is for everyone") Or are you asking for the ability? (Because you >>> don't know the password.) >> >> The latter :) >> >> Best >> -Tobias >> >> PS: I have up until now never used the swiki… >> Probably we should have a meta-4.6 todo for nicer swiki urls? ;) > > It's a shared "secret" to keep the spam out (and already in the list archive multiple times). > > Username: squeak > Password: viewpoints thanks signature.asc (1K) Download Attachment |
In reply to this post by Tobias Pape
On Mon, Jan 27, 2014 at 5:48 AM, Tobias Pape <[hidden email]> wrote:
The SWIKI already does have a built-in better URL's. Unfortunately, they don't work with pages that have periods in them (that is, http://wiki.squeak.org/squeak/squeak4.6 goes to the FunSqueak4.2Cog page, not really what is desired). The 'trick' is to lump all the works from the title together, with new words being capitalized. It does a scan (or sorts, obviously) to find the best match. My personal past with this is that I make several guesses about what will get a good result, and eventually one works fairly well.
-cbc |
Free forum by Nabble | Edit this page |