From renggli at me.com Fri Sep 2 18:58:33 2011 From: renggli at me.com (Lukas Renggli) Date: Fri, 02 Sep 2011 18:58:33 +0200 Subject: pier In-Reply-To: <45884E5F-2AC1-45AD-803A-B42E1C9E8872@iam.unibe.ch> References: <45884E5F-2AC1-45AD-803A-B42E1C9E8872@iam.unibe.ch> Message-ID: Hi Erwann, All the documentation is linked from here: http://piercms.com/ For the automatic builds I am using the scripts here: https://github.com/renggli/builder/tree/master/scripts Namely seaside3.st, seaside3-kom.st, magritte2.st, pier2.st. Easier is probably to use the Metacello configuration. The Pier application is automatically registered in the initialization code of the Pier-Seaside and/or Pier-Setup packages. Please ask further questions in the mailing list. Lukas On Sep 2, 2011, at 12:34 , Erwann Wernli wrote: > Hi Lukas, > > Is there any resource somewhere indicating how to create a pier web site, after having downloaded the packages? > > The one-click image is nice, but I would like to create pier installation from scratch, but I don't know what needs to be registered as a WAApplication in seaside, how to create the kernel, etc. > > Can you provide me any hint? > > Cheers, > Erwann -- Lukas Renggli www.lukas-renggli.ch From chaetal at gmail.com Tue Sep 13 04:28:39 2011 From: chaetal at gmail.com (Dennis Schetinin) Date: Tue, 13 Sep 2011 06:28:39 +0400 Subject: Pier2 and Seaside 3.1 Message-ID: Hi! I've loaded Seaside 3.1 and Pier2 using Lukas Renggli's scripts [ https://github.com/renggli/builder/blob/master/scripts]. Now it complains (even for the root page) that WAApplication (again?) has no #hasCookieInContext. Is Pier2 supposed to work with 3.1? What's the best way to fix it if possible? TIA VM: Mac OS - intel - 1068 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-IgorStasenko.123] 21.0 Image: Pharo1.3 [Latest update: #13299] WAApplication(Object)>>doesNotUnderstand: #hasCookieInContext: Receiver: a WAApplication Arguments and temporary variables: aMessage: hasCookieInContext: a WARequestContext url: '/' exception: MessageNotUnderstood: WAApplication>>hasCookieInContext: resumeValue: nil Receiver's instance variables: filter: a WAValueHolder contents: a WAExceptionFilter parent: a WADispatcher configuration: a WAUserConfiguration cache: a WACache PRContext>>urlOn: Receiver: a PRContext[1033633792] structure: 'Welcome to Pier!' command: 'View' Arguments and temporary variables: aRenderer: a WARenderCanvas url: /pier?_s=V2Fiigjfi9HNACsN&_k=ksDPAHVZ_TLSnZra Receiver's instance variables: properties: a Dictionary(#application->a WAApplication #components->an Identity...etc... kernel: a PRKernel[975962112] name: 'pier' structure: a PRPage[1021050880] name: 'pier' command: a PRViewCommand[1029963776] WAAnchorTag>>goto: Receiver: a WAAnchorTag Arguments and temporary variables: aContext: a PRContext[1033633792] structure: 'Welcome to Pier!' command: 'View'...etc... Receiver's instance variables: canvas: a WARenderCanvas parent: a WAGenericTag closed: false attributes: a WAHtmlAttributes('class'->' active internal page' 'title'->'Welco...etc... url: nil PRReferenceRenderer>>visitInternalLink: Receiver: a PRReferenceRenderer Arguments and temporary variables: aLink: a PRInternalLink[865337344] anchor: a WAAnchorTag Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas parent: a PRMenuRenderer link: a PRInternalLink[865337344] PRInternalLink>>accept: Receiver: a PRInternalLink[865337344] Arguments and temporary variables: aVisitor: a PRReferenceRenderer Receiver's instance variables: properties: nil children: an Array(a PRText[873988096] text: 'Home') reference: '/' owner: a PRPage[378011648] name: 'menu' embedded: false parameters: {('class'->' active')} target: a PRPage[1021050880] name: 'pier' anchor: nil PRInternalLink(Object)>>acceptDecorated: Receiver: a PRInternalLink[865337344] Arguments and temporary variables: aVisitor: a PRReferenceRenderer Receiver's instance variables: properties: nil children: an Array(a PRText[873988096] text: 'Home') reference: '/' owner: a PRPage[378011648] name: 'menu' embedded: false parameters: {('class'->' active')} target: a PRPage[1021050880] name: 'pier' anchor: nil PRReferenceRenderer(PRVisitor)>>visit: Receiver: a PRReferenceRenderer Arguments and temporary variables: anObject: a PRInternalLink[865337344] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas parent: a PRMenuRenderer link: a PRInternalLink[865337344] PRReferenceRenderer(PRVisitor)>>start: Receiver: a PRReferenceRenderer Arguments and temporary variables: anObject: a PRInternalLink[865337344] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas parent: a PRMenuRenderer link: a PRInternalLink[865337344] PRReferenceRenderer(PRLinkRenderer)>>start: Receiver: a PRReferenceRenderer Arguments and temporary variables: aLink: a PRInternalLink[865337344] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas parent: a PRMenuRenderer link: a PRInternalLink[865337344] PRReferenceRenderer(PRRenderer)>>start:in:on: Receiver: a PRReferenceRenderer Arguments and temporary variables: anObject: a PRInternalLink[865337344] aComponent: a PRPage[378011648] name: 'menu' aRenderer: a WARenderCanvas Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas parent: a PRMenuRenderer link: a PRInternalLink[865337344] PRMenuRenderer(PRViewRenderer)>>visitLink: Receiver: a PRMenuRenderer Arguments and temporary variables: anObject: a PRInternalLink[865337344] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' PRMenuRenderer(PRVisitor)>>visitInternalLink: Receiver: a PRMenuRenderer Arguments and temporary variables: anObject: a PRInternalLink[865337344] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' PRMenuRenderer>>visitInternalLink: Receiver: a PRMenuRenderer Arguments and temporary variables: aLink: a PRInternalLink[758120448] link: a PRInternalLink[865337344] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' PRInternalLink>>accept: Receiver: a PRInternalLink[758120448] Arguments and temporary variables: aVisitor: a PRMenuRenderer Receiver's instance variables: properties: nil children: an Array(a PRText[621543424] text: 'Home') reference: '/' owner: a PRPage[378011648] name: 'menu' embedded: false parameters: #() target: a PRPage[1021050880] name: 'pier' anchor: nil PRInternalLink(Object)>>acceptDecorated: Receiver: a PRInternalLink[758120448] Arguments and temporary variables: aVisitor: a PRMenuRenderer Receiver's instance variables: properties: nil children: an Array(a PRText[621543424] text: 'Home') reference: '/' owner: a PRPage[378011648] name: 'menu' embedded: false parameters: #() target: a PRPage[1021050880] name: 'pier' anchor: nil PRMenuRenderer(PRVisitor)>>visit: Receiver: a PRMenuRenderer Arguments and temporary variables: anObject: a PRInternalLink[758120448] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' [:each | self visit: each] in PRMenuRenderer(PRVisitor)>>visitAll: Receiver: a PRMenuRenderer Arguments and temporary variables: each: a PRInternalLink[758120448] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' Array(SequenceableCollection)>>do: Receiver: an Array(a PRText[589037568] text: ' ' a PRInternalLink[758120448]) Arguments and temporary variables: aBlock: [:each | self visit: each] index: 2 indexLimiT: 2 Receiver's instance variables: an Array(a PRText[589037568] text: ' ' a PRInternalLink[758120448]) PRMenuRenderer(PRVisitor)>>visitAll: Receiver: a PRMenuRenderer Arguments and temporary variables: aCollection: an Array(a PRText[589037568] text: ' ' a PRInternalLink[758120448]...etc... Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' PRMenuRenderer(PRVisitor)>>visitDocumentGroup: Receiver: a PRMenuRenderer Arguments and temporary variables: anObject: a PRListItem[557318144] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' PRMenuRenderer(PRVisitor)>>visitListItem: Receiver: a PRMenuRenderer Arguments and temporary variables: anObject: a PRListItem[557318144] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' [super visitListItem: anObject] in PRMenuRenderer(PRViewRenderer)>>visitListItem: Receiver: a PRMenuRenderer Arguments and temporary variables: anObject: a PRListItem[557318144] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' BlockClosure>>renderOn: Receiver: [super visitListItem: anObject] Arguments and temporary variables: aRenderer: a WARenderCanvas Receiver's instance variables: outerContext: PRMenuRenderer(PRViewRenderer)>>visitListItem: startpc: 27 numArgs: 0 WARenderCanvas(WARenderer)>>render: Receiver: a WARenderCanvas Arguments and temporary variables: anObject: [super visitListItem: anObject] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: a WAAnchorTag parentBrush: a WAGenericTag WARenderCanvas(WACanvas)>>render: Receiver: a WARenderCanvas Arguments and temporary variables: anObject: [super visitListItem: anObject] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: a WAAnchorTag parentBrush: a WAGenericTag [self before. canvas render: anObject. self after] in WAGenericTag(WATagBrush)>>with: Receiver: a WAGenericTag Arguments and temporary variables: anObject: [super visitListItem: anObject] Receiver's instance variables: canvas: a WARenderCanvas parent: a WAUnorderedListTag closed: false attributes: nil tag: 'li' BlockClosure>>renderOn: Receiver: [self before. canvas render: anObject. self after] Arguments and temporary variables: aRenderer: a WARenderCanvas Receiver's instance variables: outerContext: WAGenericTag(WATagBrush)>>with: startpc: 54 numArgs: 0 WARenderCanvas(WARenderer)>>render: Receiver: a WARenderCanvas Arguments and temporary variables: anObject: [self before. canvas render: anObject. self after] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: a WAAnchorTag parentBrush: a WAGenericTag WARenderCanvas(WACanvas)>>render: Receiver: a WARenderCanvas Arguments and temporary variables: anObject: [self before. canvas render: anObject. self after] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: a WAAnchorTag parentBrush: a WAGenericTag WARenderCanvas(WACanvas)>>nest: Receiver: a WARenderCanvas Arguments and temporary variables: aBlock: [self before. canvas render: anObject. self after] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: a WAAnchorTag parentBrush: a WAGenericTag WAGenericTag(WABrush)>>with: Receiver: a WAGenericTag Arguments and temporary variables: aBlock: [self before. canvas render: anObject. self after] Receiver's instance variables: canvas: a WARenderCanvas parent: a WAUnorderedListTag closed: false attributes: nil tag: 'li' WAGenericTag(WATagBrush)>>with: Receiver: a WAGenericTag Arguments and temporary variables: anObject: [super visitListItem: anObject] Receiver's instance variables: canvas: a WARenderCanvas parent: a WAUnorderedListTag closed: false attributes: nil tag: 'li' WARenderCanvas(WAHtmlCanvas)>>listItem: Receiver: a WARenderCanvas Arguments and temporary variables: aBlock: [super visitListItem: anObject] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: a WAAnchorTag parentBrush: a WAGenericTag PRMenuRenderer(PRViewRenderer)>>visitListItem: Receiver: a PRMenuRenderer Arguments and temporary variables: anObject: a PRListItem[557318144] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' PRListItem>>accept: Receiver: a PRListItem[557318144] Arguments and temporary variables: aVisitor: a PRMenuRenderer Receiver's instance variables: properties: nil children: an Array(a PRText[589037568] text: ' ' a PRInternalLink[758120448]) PRListItem(Object)>>acceptDecorated: Receiver: a PRListItem[557318144] Arguments and temporary variables: aVisitor: a PRMenuRenderer Receiver's instance variables: properties: nil children: an Array(a PRText[589037568] text: ' ' a PRInternalLink[758120448]) PRMenuRenderer(PRVisitor)>>visit: Receiver: a PRMenuRenderer Arguments and temporary variables: anObject: a PRListItem[557318144] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' [:each | self visit: each] in PRMenuRenderer(PRVisitor)>>visitAll: Receiver: a PRMenuRenderer Arguments and temporary variables: each: a PRListItem[557318144] Receiver's instance variables: escaper: nil component: a PRPage[378011648] name: 'menu' html: a WARenderCanvas visited: an OrderedCollection(a PRPage[978059264] name: 'mainenvironment' a PRP...etc... withinContent: true target: a PRPage[1021050880] name: 'pier' Array(SequenceableCollection)>>do: Receiver: an Array(a PRListItem[557318144] a PRListItem[802422784] a PRListItem[1049362432]) Arguments and temporary variables: aBlock: [:each | self visit: each] index: 1 indexLimiT: 3 Receiver's instance variables: an Array(a PRListItem[557318144] a PRListItem[802422784] a PRListItem[1049362432]) --- The full stack --- WAApplication(Object)>>doesNotUnderstand: #hasCookieInContext: PRContext>>urlOn: WAAnchorTag>>goto: PRReferenceRenderer>>visitInternalLink: PRInternalLink>>accept: PRInternalLink(Object)>>acceptDecorated: PRReferenceRenderer(PRVisitor)>>visit: PRReferenceRenderer(PRVisitor)>>start: PRReferenceRenderer(PRLinkRenderer)>>start: PRReferenceRenderer(PRRenderer)>>start:in:on: PRMenuRenderer(PRViewRenderer)>>visitLink: PRMenuRenderer(PRVisitor)>>visitInternalLink: PRMenuRenderer>>visitInternalLink: PRInternalLink>>accept: PRInternalLink(Object)>>acceptDecorated: PRMenuRenderer(PRVisitor)>>visit: [:each | self visit: each] in PRMenuRenderer(PRVisitor)>>visitAll: Array(SequenceableCollection)>>do: PRMenuRenderer(PRVisitor)>>visitAll: PRMenuRenderer(PRVisitor)>>visitDocumentGroup: PRMenuRenderer(PRVisitor)>>visitListItem: [super visitListItem: anObject] in PRMenuRenderer(PRViewRenderer)>>visitListItem: BlockClosure>>renderOn: WARenderCanvas(WARenderer)>>render: WARenderCanvas(WACanvas)>>render: [self before. canvas render: anObject. self after] in WAGenericTag(WATagBrush)>>with: BlockClosure>>renderOn: WARenderCanvas(WARenderer)>>render: WARenderCanvas(WACanvas)>>render: WARenderCanvas(WACanvas)>>nest: WAGenericTag(WABrush)>>with: WAGenericTag(WATagBrush)>>with: WARenderCanvas(WAHtmlCanvas)>>listItem: PRMenuRenderer(PRViewRenderer)>>visitListItem: PRListItem>>accept: PRListItem(Object)>>acceptDecorated: PRMenuRenderer(PRVisitor)>>visit: [:each | self visit: each] in PRMenuRenderer(PRVisitor)>>visitAll: Array(SequenceableCollection)>>do: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PRMenuRenderer(PRVisitor)>>visitAll: PRMenuRenderer(PRVisitor)>>visitDocumentGroup: PRMenuRenderer(PRVisitor)>>visitList: PRMenuRenderer(PRVisitor)>>visitUnorderedList: [super visitUnorderedList: anObject] in PRMenuRenderer(PRViewRenderer)>>visitUnorderedList: BlockClosure>>renderOn: WARenderCanvas(WARenderer)>>render: WARenderCanvas(WACanvas)>>render: [self before. canvas render: anObject. self after] in WAUnorderedListTag(WATagBrush)>>with: BlockClosure>>renderOn: WARenderCanvas(WARenderer)>>render: WARenderCanvas(WACanvas)>>render: WARenderCanvas(WACanvas)>>nest: WAUnorderedListTag(WABrush)>>with: WAUnorderedListTag(WATagBrush)>>with: WARenderCanvas(WAHtmlCanvas)>>unorderedList: PRMenuRenderer(PRViewRenderer)>>visitUnorderedList: PRUnorderedList>>accept: PRUnorderedList(Object)>>acceptDecorated: PRMenuRenderer(PRVisitor)>>visit: [:each | self visit: each] in PRMenuRenderer(PRVisitor)>>visitAll: Array(SequenceableCollection)>>do: PRMenuRenderer(PRVisitor)>>visitAll: PRMenuRenderer(PRVisitor)>>visitDocumentGroup: PRMenuRenderer(PRVisitor)>>visitDocument: PRDocument>>accept: PRDocument(Object)>>acceptDecorated: PRMenuRenderer(PRVisitor)>>visit: [self visit: anObject] in PRMenuRenderer(PRRenderer)>>continue:in:on: BlockClosure>>ensure: PRMenuRenderer(PRRenderer)>>continue:in:on: [PRMenuRenderer new copyFrom: parent; target: visitor target; continue: aPage document in: aPage on: html] in PREmbeddedRenderer>>visitPageMenu: BlockClosure>>ensure: PRViewRenderer(PRDeepRenderer)>>structure:during: PREmbeddedRenderer>>visitPageMenu: PREmbeddedRenderer>>visitPage: PRPage>>accept: PRPage(Object)>>acceptDecorated: [:each | super acceptDecorated: aVisitor] in PRPage(PRDecorated)>>acceptDecorated: PRPage(PRDecorated)>>decorationsDo:ownerDo: PRPage(PRDecorated)>>acceptDecorated: PREmbeddedRenderer(PRVisitor)>>visit: PREmbeddedRenderer>>visitInternalLink: PRInternalLink>>accept: PRInternalLink(Object)>>acceptDecorated: PREmbeddedRenderer(PRVisitor)>>visit: PREmbeddedRenderer(PRVisitor)>>start: PREmbeddedRenderer(PRLinkRenderer)>>start: PREmbeddedRenderer(PRRenderer)>>start:in:on: PRViewRenderer>>visitLink: PRViewRenderer(PRVisitor)>>visitInternalLink: PRInternalLink>>accept: PRInternalLink(Object)>>acceptDecorated: PRViewRenderer(PRVisitor)>>visit: [:each | self visit: each] in PRViewRenderer(PRVisitor)>>visitAll: Array(SequenceableCollection)>>do: PRViewRenderer(PRVisitor)>>visitAll: PRViewRenderer(PRVisitor)>>visitDocumentGroup: PRViewRenderer(PRVisitor)>>visitParagraph: PRViewRenderer>>visitParagraph: PRParagraph>>accept: PRParagraph(Object)>>acceptDecorated: PRViewRenderer(PRVisitor)>>visit: [:each | self visit: each] in PRViewRenderer(PRVisitor)>>visitAll: Array(SequenceableCollection)>>do: PRViewRenderer(PRVisitor)>>visitAll: PRViewRenderer(PRVisitor)>>visitDocumentGroup: PRViewRenderer(PRVisitor)>>visitDocument: PRDocument>>accept: PRDocument(Object)>>acceptDecorated: PRViewRenderer(PRVisitor)>>visit: [self visit: aStructure document] in PRViewRenderer(PRDeepRenderer)>>visitStructure: BlockClosure>>ensure: PRViewRenderer(PRDeepRenderer)>>structure:during: PRViewRenderer(PRDeepRenderer)>>visitStructure: PRViewRenderer(PRVisitor)>>visitCase: PRViewRenderer(PRVisitor)>>visitPage: PRPage>>accept: PRPage(Object)>>acceptDecorated: [:each | super acceptDecorated: aVisitor] in PRPage(PRDecorated)>>acceptDecorated: PRPage(PRDecorated)>>decorationsDo:ownerDo: PRPage(PRDecorated)>>acceptDecorated: PRViewRenderer(PRVisitor)>>visit: PREmbeddedRenderer>>visitStructure: PREmbeddedRenderer(PRVisitor)>>visitCase: PREmbeddedRenderer(PRVisitor)>>visitPage: PREmbeddedRenderer>>visitPage: PRPage>>accept: PRPage(Object)>>acceptDecorated: [:each | super acceptDecorated: aVisitor] in PRPage(PRDecorated)>>acceptDecorated: PRPage(PRDecorated)>>decorationsDo:ownerDo: PRPage(PRDecorated)>>acceptDecorated: PREmbeddedRenderer(PRVisitor)>>visit: PREmbeddedRenderer>>visitInternalLink: PRInternalLink>>accept: PRInternalLink(Object)>>acceptDecorated: PREmbeddedRenderer(PRVisitor)>>visit: PREmbeddedRenderer(PRVisitor)>>start: PREmbeddedRenderer(PRLinkRenderer)>>start: PREmbeddedRenderer(PRRenderer)>>start:in:on: PRViewRenderer>>visitLink: PRViewRenderer(PRVisitor)>>visitInternalLink: PRInternalLink>>accept: PRInternalLink(Object)>>acceptDecorated: PRViewRenderer(PRVisitor)>>visit: [:each | self visit: each] in PRViewRenderer(PRVisitor)>>visitAll: Array(SequenceableCollection)>>do: PRViewRenderer(PRVisitor)>>visitAll: PRViewRenderer(PRVisitor)>>visitDocumentGroup: PRViewRenderer(PRVisitor)>>visitParagraph: PRViewRenderer>>visitParagraph: PRParagraph>>accept: PRParagraph(Object)>>acceptDecorated: PRViewRenderer(PRVisitor)>>visit: [:each | self visit: each] in PRViewRenderer(PRVisitor)>>visitAll: Array(SequenceableCollection)>>do: PRViewRenderer(PRVisitor)>>visitAll: PRViewRenderer(PRVisitor)>>visitDocumentGroup: PRViewRenderer(PRVisitor)>>visitDocument: PRDocument>>accept: PRDocument(Object)>>acceptDecorated: PRViewRenderer(PRVisitor)>>visit: [self visit: aStructure document] in PRViewRenderer(PRDeepRenderer)>>visitStructure: BlockClosure>>ensure: PRViewRenderer(PRDeepRenderer)>>structure:during: PRViewRenderer(PRDeepRenderer)>>visitStructure: PRViewRenderer(PRVisitor)>>visitCase: PRViewRenderer(PRVisitor)>>visitPage: PRPage>>accept: PRPage(Object)>>acceptDecorated: [:each | super acceptDecorated: aVisitor] in PRPage(PRDecorated)>>acceptDecorated: PRPage(PRDecorated)>>decorationsDo:ownerDo: PRPage(PRDecorated)>>acceptDecorated: PRViewRenderer(PRVisitor)>>visit: PRViewRenderer(PRVisitor)>>start: PRViewRenderer(PRDeepRenderer)>>start: PRViewRenderer(PRRenderer)>>start:in:on: PRPierFrame>>renderContentOn: WARenderVisitor>>visitPainter: WARenderVisitor(WAPainterVisitor)>>visitPresenter: WARenderVisitor(WAPainterVisitor)>>visitComponent: PRPierFrame(WAComponent)>>accept: WARenderVisitor(WAVisitor)>>visit: WARenderingGuide(WAPresenterGuide)>>visitPainter: WARenderingGuide(WAPainterVisitor)>>visitPresenter: WARenderingGuide(WAPainterVisitor)>>visitComponent: PRPierFrame(WAComponent)>>accept: PRPierFrame(WAPresenter)>>renderUndecoratedWithContext: WAToolDecoration(WADecoration)>>renderNextOn: WAToolDecoration>>renderChildOn: WAToolDecoration>>renderContentOn: WARenderVisitor>>visitPainter: WARenderVisitor(WAPainterVisitor)>>visitPresenter: WARenderVisitor(WAPainterVisitor)>>visitDecoration: WAToolDecoration(WADecoration)>>accept: WARenderVisitor(WAVisitor)>>visit: WARenderingGuide(WAPresenterGuide)>>visitPainter: WARenderingGuide(WAPainterVisitor)>>visitPresenter: WARenderingGuide(WAPainterVisitor)>>visitDecoration: WAToolDecoration(WADecoration)>>accept: WARenderingGuide(WAPainterVisitor)>>visitDecorationsOfComponent: PRPierFrame(WAComponent)>>acceptDecorated: -- and more not shown -- -- Dennis Schetinin -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.marschall at gmail.com Tue Sep 13 07:14:19 2011 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Tue, 13 Sep 2011 07:14:19 +0200 Subject: Pier2 and Seaside 3.1 In-Reply-To: References: Message-ID: 2011/9/13 Dennis Schetinin : > Hi! > I've loaded Seaside 3.1 and Pier2 using Lukas Renggli's scripts > [https://github.com/renggli/builder/blob/master/scripts]. Now it complains > (even for the root page) that WAApplication (again?) has no > #hasCookieInContext. Is Pier2 supposed to work with 3.1? What's the best way > to fix it if possible? TIA First, thanks for loading and testing Seaside 3.1. Seaside 3.1 contains a few breaking changes [1] and one is when it comes to cookies. A direct translation would look like this: (self application trackingStrategy isKindOf: WACookieSessionTrackingStrategy) and: [ (self application trackingStrategy cookieFromContext: self requestContext ifAbsent: [ nil ]) notNil ] However if the browser supports cookies and has a session cookie then it should never be in the URL so removing it seems not needed. In addition my understanding is when a command #isRestful then it should not use #callback:s so there shouldn't be callback id in the URL either. A quick glance seems to confirm this mostly, PRSearchView is the only that answers #isRestful with true (send by #PRViewCommand) but also uses #callback: when rendering. This seems to be a bug. Long story short I think #purgeSeasideFields should not remove the session id and callback id. If the browser supports cookies and has a cookie it will not be there, otherwise it will be there and has to be there. This should also work in Seaside 3.0. [1] http://code.google.com/p/seaside/wiki/Seaside310Changelog Cheers Philippe From chaetal at gmail.com Tue Sep 13 21:04:45 2011 From: chaetal at gmail.com (Dennis Schetinin) Date: Tue, 13 Sep 2011 23:04:45 +0400 Subject: Export/Import widget does not work Message-ID: I've loaded Seaside 3.0 and Pier 2 with Metacello configurations. I tried both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for Seaside; I also updated all Pier packages from Lukas's repo by hand. The problem I encounter is with Export/Import widget: clicks on "Export" and "Import" buttons are just ignored (at least, callbacks are not triggered in image). Am I doing something wrong? I remember I had (and reported) a similar issue several months ago, didn't get any response managed to find some solutions or workaround. Now I can't. Any help please? -- Dennis Schetinin -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Tue Sep 13 21:18:39 2011 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 13 Sep 2011 21:18:39 +0200 Subject: Export/Import widget does not work In-Reply-To: References: Message-ID: On 13 September 2011 21:04, Dennis Schetinin wrote: > I've loaded Seaside 3.0 and Pier 2 with Metacello configurations. I?tried > both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for Seaside; I also > updated all Pier packages from Lukas's repo by hand. The problem I encounter > is with Export/Import widget:?clicks on?"Export" and "Import" buttons are > just ignored (at least, callbacks are not triggered in image). Am I doing > something wrong? I cannot reproduce with the latest builds from Jenkins (http://jenkins.lukas-renggli.ch/job/Pier%202/lastSuccessfulBuild/artifact/pier2.zip). Import and Export works without problems. > I remember I had (and reported) a similar issue several months ago, didn't > get any response managed to find some solutions or workaround. Now I can't. > Any help please? What version of Pharo are you on? I think in 1.4 they have removed ReferenceStreams. Lukas -- Lukas Renggli www.lukas-renggli.ch From renggli at gmail.com Tue Sep 13 21:19:48 2011 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 13 Sep 2011 21:19:48 +0200 Subject: Export/Import widget does not work In-Reply-To: References: Message-ID: Also what server adaptor are you using? I heard that Swazoo has some issues. Lukas On 13 September 2011 21:18, Lukas Renggli wrote: > On 13 September 2011 21:04, Dennis Schetinin wrote: >> I've loaded Seaside 3.0 and Pier 2 with Metacello configurations. I?tried >> both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for Seaside; I also >> updated all Pier packages from Lukas's repo by hand. The problem I encounter >> is with Export/Import widget:?clicks on?"Export" and "Import" buttons are >> just ignored (at least, callbacks are not triggered in image). Am I doing >> something wrong? > > I cannot reproduce with the latest builds from Jenkins > (http://jenkins.lukas-renggli.ch/job/Pier%202/lastSuccessfulBuild/artifact/pier2.zip). > Import and Export works without problems. > >> I remember I had (and reported) a similar issue several months ago, didn't >> get any response managed to find some solutions or workaround. Now I can't. >> Any help please? > > What version of Pharo are you on? I think in 1.4 they have removed > ReferenceStreams. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch From chaetal at gmail.com Tue Sep 13 21:41:33 2011 From: chaetal at gmail.com (Dennis Schetinin) Date: Tue, 13 Sep 2011 23:41:33 +0400 Subject: Export/Import widget does not work In-Reply-To: References: Message-ID: Pharo 1.3. I issue the problem with both Zinc and Comanche. I can provide scripts if it may help. BTW, I've managed to import "from Workspace" (just had to hack #replace in PRExporterImporter a bit), but I'd prefer to figure out the source of the problem in the widget and actually resolve it. 2011/9/13 Lukas Renggli > Also what server adaptor are you using? > > I heard that Swazoo has some issues. > > Lukas > > On 13 September 2011 21:18, Lukas Renggli wrote: > > On 13 September 2011 21:04, Dennis Schetinin wrote: > >> I've loaded Seaside 3.0 and Pier 2 with Metacello configurations. > I tried > >> both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for Seaside; I > also > >> updated all Pier packages from Lukas's repo by hand. The problem I > encounter > >> is with Export/Import widget: clicks on "Export" and "Import" buttons > are > >> just ignored (at least, callbacks are not triggered in image). Am I > doing > >> something wrong? > > > > I cannot reproduce with the latest builds from Jenkins > > ( > http://jenkins.lukas-renggli.ch/job/Pier%202/lastSuccessfulBuild/artifact/pier2.zip > ). > > Import and Export works without problems. > > > >> I remember I had (and reported) a similar issue several months ago, > didn't > >> get any response managed to find some solutions or workaround. Now I > can't. > >> Any help please? > > > > What version of Pharo are you on? I think in 1.4 they have removed > > ReferenceStreams. > > > > Lukas > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Dennis Schetinin -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Tue Sep 13 21:53:02 2011 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 13 Sep 2011 21:53:02 +0200 Subject: Export/Import widget does not work In-Reply-To: References: Message-ID: Did you try with the image I linked? Can you reproduce it there? On 13 September 2011 21:41, Dennis Schetinin wrote: > Pharo 1.3.?I issue the problem with both Zinc and Comanche. I can provide > scripts if it may help. > BTW, I've managed to import "from Workspace" (just had to hack #replace in > PRExporterImporter a bit), but I'd prefer to figure out the source of the > problem?in the widget?and actually resolve it. > 2011/9/13 Lukas Renggli >> >> Also what server adaptor are you using? >> >> I heard that Swazoo has some issues. >> >> Lukas >> >> On 13 September 2011 21:18, Lukas Renggli wrote: >> > On 13 September 2011 21:04, Dennis Schetinin wrote: >> >> I've loaded Seaside 3.0 and Pier 2 with Metacello configurations. >> >> I?tried >> >> both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for Seaside; I >> >> also >> >> updated all Pier packages from Lukas's repo by hand. The problem I >> >> encounter >> >> is with Export/Import widget:?clicks on?"Export" and "Import" buttons >> >> are >> >> just ignored (at least, callbacks are not triggered in image). Am I >> >> doing >> >> something wrong? >> > >> > I cannot reproduce with the latest builds from Jenkins >> > >> > (http://jenkins.lukas-renggli.ch/job/Pier%202/lastSuccessfulBuild/artifact/pier2.zip). >> > Import and Export works without problems. >> > >> >> I remember I had (and reported) a similar issue several months ago, >> >> didn't >> >> get any response managed to find some solutions or workaround. Now I >> >> can't. >> >> Any help please? >> > >> > What version of Pharo are you on? I think in 1.4 they have removed >> > ReferenceStreams. >> > >> > Lukas >> > >> > -- >> > Lukas Renggli >> > www.lukas-renggli.ch >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > -- > Dennis Schetinin > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From chaetal at gmail.com Wed Sep 14 04:21:37 2011 From: chaetal at gmail.com (Dennis Schetinin) Date: Wed, 14 Sep 2011 06:21:37 +0400 Subject: Export/Import widget does not work In-Reply-To: References: Message-ID: No, it is not reproduced in your image. BTW, I have no "Please select the importer/exporter to use:" at the top of the page in my version. I guess I'm missing some package or have incorrect version of something in my image? Going to try to find the difference. 2011/9/13 Lukas Renggli > Did you try with the image I linked? Can you reproduce it there? > > On 13 September 2011 21:41, Dennis Schetinin wrote: > > Pharo 1.3. I issue the problem with both Zinc and Comanche. I can provide > > scripts if it may help. > > BTW, I've managed to import "from Workspace" (just had to hack #replace > in > > PRExporterImporter a bit), but I'd prefer to figure out the source of the > > problem in the widget and actually resolve it. > > 2011/9/13 Lukas Renggli > >> > >> Also what server adaptor are you using? > >> > >> I heard that Swazoo has some issues. > >> > >> Lukas > >> > >> On 13 September 2011 21:18, Lukas Renggli wrote: > >> > On 13 September 2011 21:04, Dennis Schetinin > wrote: > >> >> I've loaded Seaside 3.0 and Pier 2 with Metacello configurations. > >> >> I tried > >> >> both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for Seaside; I > >> >> also > >> >> updated all Pier packages from Lukas's repo by hand. The problem I > >> >> encounter > >> >> is with Export/Import widget: clicks on "Export" and "Import" buttons > >> >> are > >> >> just ignored (at least, callbacks are not triggered in image). Am I > >> >> doing > >> >> something wrong? > >> > > >> > I cannot reproduce with the latest builds from Jenkins > >> > > >> > ( > http://jenkins.lukas-renggli.ch/job/Pier%202/lastSuccessfulBuild/artifact/pier2.zip > ). > >> > Import and Export works without problems. > >> > > >> >> I remember I had (and reported) a similar issue several months ago, > >> >> didn't > >> >> get any response managed to find some solutions or workaround. Now I > >> >> can't. > >> >> Any help please? > >> > > >> > What version of Pharo are you on? I think in 1.4 they have removed > >> > ReferenceStreams. > >> > > >> > Lukas > >> > > >> > -- > >> > Lukas Renggli > >> > www.lukas-renggli.ch > >> > > >> > >> > >> > >> -- > >> Lukas Renggli > >> www.lukas-renggli.ch > >> > >> _______________________________________________ > >> Magritte, Pier and Related Tools ... > >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > > > > -- > > Dennis Schetinin > > > > _______________________________________________ > > Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Dennis Schetinin -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaetal at gmail.com Wed Sep 14 11:16:50 2011 From: chaetal at gmail.com (Dennis Schetinin) Date: Wed, 14 Sep 2011 13:16:50 +0400 Subject: Export/Import widget does not work In-Reply-To: References: Message-ID: Lukas, I've tried to use your scripts to load Seaside 3.0 + Pier 2 in Pharo 1.3 in the following sequence: OmniBrowser Seaside 3 Komanche Magritte2 Pier2 After that, I get MNU for WAApplication>>#hasCookieInContext, just as I reported there: http://forum.world.st/Pier2-and-Seaside-3-1-td3809059.html. I didn't understand how to fix that, as didn't see WAUrl>>purgeSeasideFields ever encountered. What is the best way to handle this? Is it to use some earlier Seaside version? Or the issue can be fixed somehow? 2011/9/14 Dennis Schetinin > No, it is not reproduced in your image. BTW, I have no "Please select the > importer/exporter to use:" at the top of the page in my version. I guess I'm > missing some package or have incorrect version of something in my image? > Going to try to find the difference. > > 2011/9/13 Lukas Renggli > >> Did you try with the image I linked? Can you reproduce it there? >> >> On 13 September 2011 21:41, Dennis Schetinin wrote: >> > Pharo 1.3. I issue the problem with both Zinc and Comanche. I can >> provide >> > scripts if it may help. >> > BTW, I've managed to import "from Workspace" (just had to hack #replace >> in >> > PRExporterImporter a bit), but I'd prefer to figure out the source of >> the >> > problem in the widget and actually resolve it. >> > 2011/9/13 Lukas Renggli >> >> >> >> Also what server adaptor are you using? >> >> >> >> I heard that Swazoo has some issues. >> >> >> >> Lukas >> >> >> >> On 13 September 2011 21:18, Lukas Renggli wrote: >> >> > On 13 September 2011 21:04, Dennis Schetinin >> wrote: >> >> >> I've loaded Seaside 3.0 and Pier 2 with Metacello configurations. >> >> >> I tried >> >> >> both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for Seaside; >> I >> >> >> also >> >> >> updated all Pier packages from Lukas's repo by hand. The problem I >> >> >> encounter >> >> >> is with Export/Import widget: clicks on "Export" and "Import" >> buttons >> >> >> are >> >> >> just ignored (at least, callbacks are not triggered in image). Am I >> >> >> doing >> >> >> something wrong? >> >> > >> >> > I cannot reproduce with the latest builds from Jenkins >> >> > >> >> > ( >> http://jenkins.lukas-renggli.ch/job/Pier%202/lastSuccessfulBuild/artifact/pier2.zip >> ). >> >> > Import and Export works without problems. >> >> > >> >> >> I remember I had (and reported) a similar issue several months ago, >> >> >> didn't >> >> >> get any response managed to find some solutions or workaround. Now I >> >> >> can't. >> >> >> Any help please? >> >> > >> >> > What version of Pharo are you on? I think in 1.4 they have removed >> >> > ReferenceStreams. >> >> > >> >> > Lukas >> >> > >> >> > -- >> >> > Lukas Renggli >> >> > www.lukas-renggli.ch >> >> > >> >> >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> www.lukas-renggli.ch >> >> >> >> _______________________________________________ >> >> Magritte, Pier and Related Tools ... >> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > >> > >> > >> > -- >> > Dennis Schetinin >> > >> > _______________________________________________ >> > Magritte, Pier and Related Tools ... >> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Dennis Schetinin > -- Dennis Schetinin -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Wed Sep 14 11:26:53 2011 From: renggli at gmail.com (Lukas Renggli) Date: Wed, 14 Sep 2011 11:26:53 +0200 Subject: Export/Import widget does not work In-Reply-To: References: Message-ID: That shouldn't happen in Seaside 3.0. Looks like you load Seaside 3.1, maybe through some old files you have in your package cache? Lukas On 14 September 2011 11:16, Dennis Schetinin wrote: > Lukas, I've tried to use your scripts to load Seaside 3.0 + Pier 2 in Pharo > 1.3 in the following sequence: > OmniBrowser > Seaside 3 > Komanche > Magritte2 > Pier2 > After that, I get MNU for?WAApplication>>#hasCookieInContext, just as I > reported there:?http://forum.world.st/Pier2-and-Seaside-3-1-td3809059.html. > I didn't understand how to fix that, as didn't see WAUrl>>purgeSeasideFields > ever encountered. > What is the best way to handle this? Is it to use some earlier Seaside > version? Or the issue can be fixed somehow? > 2011/9/14 Dennis Schetinin >> >> No, it is not reproduced in your image. BTW, I have no "Please select the >> importer/exporter to use:" at the top of the page in my version. I guess I'm >> missing some package or have incorrect version of something??in my image? >> Going to try to find the difference. >> 2011/9/13 Lukas Renggli >>> >>> Did you try with the image I linked? Can you reproduce it there? >>> >>> On 13 September 2011 21:41, Dennis Schetinin wrote: >>> > Pharo 1.3.?I issue the problem with both Zinc and Comanche. I can >>> > provide >>> > scripts if it may help. >>> > BTW, I've managed to import "from Workspace" (just had to hack #replace >>> > in >>> > PRExporterImporter a bit), but I'd prefer to figure out the source of >>> > the >>> > problem?in the widget?and actually resolve it. >>> > 2011/9/13 Lukas Renggli >>> >> >>> >> Also what server adaptor are you using? >>> >> >>> >> I heard that Swazoo has some issues. >>> >> >>> >> Lukas >>> >> >>> >> On 13 September 2011 21:18, Lukas Renggli wrote: >>> >> > On 13 September 2011 21:04, Dennis Schetinin >>> >> > wrote: >>> >> >> I've loaded Seaside 3.0 and Pier 2 with Metacello configurations. >>> >> >> I?tried >>> >> >> both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for Seaside; >>> >> >> I >>> >> >> also >>> >> >> updated all Pier packages from Lukas's repo by hand. The problem I >>> >> >> encounter >>> >> >> is with Export/Import widget:?clicks on?"Export" and "Import" >>> >> >> buttons >>> >> >> are >>> >> >> just ignored (at least, callbacks are not triggered in image). Am I >>> >> >> doing >>> >> >> something wrong? >>> >> > >>> >> > I cannot reproduce with the latest builds from Jenkins >>> >> > >>> >> > >>> >> > (http://jenkins.lukas-renggli.ch/job/Pier%202/lastSuccessfulBuild/artifact/pier2.zip). >>> >> > Import and Export works without problems. >>> >> > >>> >> >> I remember I had (and reported) a similar issue several months ago, >>> >> >> didn't >>> >> >> get any response managed to find some solutions or workaround. Now >>> >> >> I >>> >> >> can't. >>> >> >> Any help please? >>> >> > >>> >> > What version of Pharo are you on? I think in 1.4 they have removed >>> >> > ReferenceStreams. >>> >> > >>> >> > Lukas >>> >> > >>> >> > -- >>> >> > Lukas Renggli >>> >> > www.lukas-renggli.ch >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Lukas Renggli >>> >> www.lukas-renggli.ch >>> >> >>> >> _______________________________________________ >>> >> Magritte, Pier and Related Tools ... >>> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> > >>> > >>> > >>> > -- >>> > Dennis Schetinin >>> > >>> > _______________________________________________ >>> > Magritte, Pier and Related Tools ... >>> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> > >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> >> >> -- >> Dennis Schetinin > > > > -- > Dennis Schetinin > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From chaetal at gmail.com Wed Sep 14 11:35:40 2011 From: chaetal at gmail.com (Dennis Schetinin) Date: Wed, 14 Sep 2011 13:35:40 +0400 Subject: Export/Import widget does not work In-Reply-To: References: Message-ID: Oh? I don't understand, how it could happen, but I'll try to check and prevent that. Anyway, I hacked that exception by commenting the check :) And that way, the Import/Export buttons work. Thus, there's obviously a difference between your scripts and ConfigurationOf..., but I can't find it. Any suggestions on that, maybe? 2011/9/14 Lukas Renggli > That shouldn't happen in Seaside 3.0. Looks like you load Seaside 3.1, > maybe through some old files you have in your package cache? > > Lukas > > On 14 September 2011 11:16, Dennis Schetinin wrote: > > Lukas, I've tried to use your scripts to load Seaside 3.0 + Pier 2 in > Pharo > > 1.3 in the following sequence: > > OmniBrowser > > Seaside 3 > > Komanche > > Magritte2 > > Pier2 > > After that, I get MNU for WAApplication>>#hasCookieInContext, just as I > > reported there: > http://forum.world.st/Pier2-and-Seaside-3-1-td3809059.html. > > I didn't understand how to fix that, as didn't see > WAUrl>>purgeSeasideFields > > ever encountered. > > What is the best way to handle this? Is it to use some earlier Seaside > > version? Or the issue can be fixed somehow? > > 2011/9/14 Dennis Schetinin > >> > >> No, it is not reproduced in your image. BTW, I have no "Please select > the > >> importer/exporter to use:" at the top of the page in my version. I guess > I'm > >> missing some package or have incorrect version of something in my > image? > >> Going to try to find the difference. > >> 2011/9/13 Lukas Renggli > >>> > >>> Did you try with the image I linked? Can you reproduce it there? > >>> > >>> On 13 September 2011 21:41, Dennis Schetinin > wrote: > >>> > Pharo 1.3. I issue the problem with both Zinc and Comanche. I can > >>> > provide > >>> > scripts if it may help. > >>> > BTW, I've managed to import "from Workspace" (just had to hack > #replace > >>> > in > >>> > PRExporterImporter a bit), but I'd prefer to figure out the source of > >>> > the > >>> > problem in the widget and actually resolve it. > >>> > 2011/9/13 Lukas Renggli > >>> >> > >>> >> Also what server adaptor are you using? > >>> >> > >>> >> I heard that Swazoo has some issues. > >>> >> > >>> >> Lukas > >>> >> > >>> >> On 13 September 2011 21:18, Lukas Renggli > wrote: > >>> >> > On 13 September 2011 21:04, Dennis Schetinin > >>> >> > wrote: > >>> >> >> I've loaded Seaside 3.0 and Pier 2 with Metacello configurations. > >>> >> >> I tried > >>> >> >> both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for > Seaside; > >>> >> >> I > >>> >> >> also > >>> >> >> updated all Pier packages from Lukas's repo by hand. The problem > I > >>> >> >> encounter > >>> >> >> is with Export/Import widget: clicks on "Export" and "Import" > >>> >> >> buttons > >>> >> >> are > >>> >> >> just ignored (at least, callbacks are not triggered in image). Am > I > >>> >> >> doing > >>> >> >> something wrong? > >>> >> > > >>> >> > I cannot reproduce with the latest builds from Jenkins > >>> >> > > >>> >> > > >>> >> > ( > http://jenkins.lukas-renggli.ch/job/Pier%202/lastSuccessfulBuild/artifact/pier2.zip > ). > >>> >> > Import and Export works without problems. > >>> >> > > >>> >> >> I remember I had (and reported) a similar issue several months > ago, > >>> >> >> didn't > >>> >> >> get any response managed to find some solutions or workaround. > Now > >>> >> >> I > >>> >> >> can't. > >>> >> >> Any help please? > >>> >> > > >>> >> > What version of Pharo are you on? I think in 1.4 they have removed > >>> >> > ReferenceStreams. > >>> >> > > >>> >> > Lukas > >>> >> > > >>> >> > -- > >>> >> > Lukas Renggli > >>> >> > www.lukas-renggli.ch > >>> >> > > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> Lukas Renggli > >>> >> www.lukas-renggli.ch > >>> >> > >>> >> _______________________________________________ > >>> >> Magritte, Pier and Related Tools ... > >>> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > >>> > > >>> > > >>> > > >>> > -- > >>> > Dennis Schetinin > >>> > > >>> > _______________________________________________ > >>> > Magritte, Pier and Related Tools ... > >>> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > >>> > > >>> > >>> > >>> > >>> -- > >>> Lukas Renggli > >>> www.lukas-renggli.ch > >>> > >>> _______________________________________________ > >>> Magritte, Pier and Related Tools ... > >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > >> > >> > >> > >> -- > >> Dennis Schetinin > > > > > > > > -- > > Dennis Schetinin > > > > _______________________________________________ > > Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Dennis Schetinin -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Wed Sep 14 11:59:22 2011 From: renggli at gmail.com (Lukas Renggli) Date: Wed, 14 Sep 2011 11:59:22 +0200 Subject: Export/Import widget does not work In-Reply-To: References: Message-ID: I don't know. Theoretically configurations load older code that is known to work together. In practice however it didn't work for me, because there were dependent other configurations that used newer code. Also I think the configurations load Swazoo, which has been reported to be broken. Lukas On 14 September 2011 11:35, Dennis Schetinin wrote: > Oh? I don't understand, how it could happen, but I'll try to check and > prevent that. > Anyway, I hacked that exception by commenting the check :) And that way, the > Import/Export buttons work. Thus, there's obviously a difference between > your scripts and ConfigurationOf..., but I can't find it. Any suggestions on > that, maybe? > > 2011/9/14 Lukas Renggli >> >> That shouldn't happen in Seaside 3.0. Looks like you load Seaside 3.1, >> maybe through some old files you have in your package cache? >> >> Lukas >> >> On 14 September 2011 11:16, Dennis Schetinin wrote: >> > Lukas, I've tried to use your scripts to load Seaside 3.0 + Pier 2 in >> > Pharo >> > 1.3 in the following sequence: >> > OmniBrowser >> > Seaside 3 >> > Komanche >> > Magritte2 >> > Pier2 >> > After that, I get MNU for?WAApplication>>#hasCookieInContext, just as I >> > reported >> > there:?http://forum.world.st/Pier2-and-Seaside-3-1-td3809059.html. >> > I didn't understand how to fix that, as didn't see >> > WAUrl>>purgeSeasideFields >> > ever encountered. >> > What is the best way to handle this? Is it to use some earlier Seaside >> > version? Or the issue can be fixed somehow? >> > 2011/9/14 Dennis Schetinin >> >> >> >> No, it is not reproduced in your image. BTW, I have no "Please select >> >> the >> >> importer/exporter to use:" at the top of the page in my version. I >> >> guess I'm >> >> missing some package or have incorrect version of something??in my >> >> image? >> >> Going to try to find the difference. >> >> 2011/9/13 Lukas Renggli >> >>> >> >>> Did you try with the image I linked? Can you reproduce it there? >> >>> >> >>> On 13 September 2011 21:41, Dennis Schetinin >> >>> wrote: >> >>> > Pharo 1.3.?I issue the problem with both Zinc and Comanche. I can >> >>> > provide >> >>> > scripts if it may help. >> >>> > BTW, I've managed to import "from Workspace" (just had to hack >> >>> > #replace >> >>> > in >> >>> > PRExporterImporter a bit), but I'd prefer to figure out the source >> >>> > of >> >>> > the >> >>> > problem?in the widget?and actually resolve it. >> >>> > 2011/9/13 Lukas Renggli >> >>> >> >> >>> >> Also what server adaptor are you using? >> >>> >> >> >>> >> I heard that Swazoo has some issues. >> >>> >> >> >>> >> Lukas >> >>> >> >> >>> >> On 13 September 2011 21:18, Lukas Renggli >> >>> >> wrote: >> >>> >> > On 13 September 2011 21:04, Dennis Schetinin >> >>> >> > wrote: >> >>> >> >> I've loaded Seaside 3.0 and Pier 2 with Metacello >> >>> >> >> configurations. >> >>> >> >> I?tried >> >>> >> >> both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for >> >>> >> >> Seaside; >> >>> >> >> I >> >>> >> >> also >> >>> >> >> updated all Pier packages from Lukas's repo by hand. The problem >> >>> >> >> I >> >>> >> >> encounter >> >>> >> >> is with Export/Import widget:?clicks on?"Export" and "Import" >> >>> >> >> buttons >> >>> >> >> are >> >>> >> >> just ignored (at least, callbacks are not triggered in image). >> >>> >> >> Am I >> >>> >> >> doing >> >>> >> >> something wrong? >> >>> >> > >> >>> >> > I cannot reproduce with the latest builds from Jenkins >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > (http://jenkins.lukas-renggli.ch/job/Pier%202/lastSuccessfulBuild/artifact/pier2.zip). >> >>> >> > Import and Export works without problems. >> >>> >> > >> >>> >> >> I remember I had (and reported) a similar issue several months >> >>> >> >> ago, >> >>> >> >> didn't >> >>> >> >> get any response managed to find some solutions or workaround. >> >>> >> >> Now >> >>> >> >> I >> >>> >> >> can't. >> >>> >> >> Any help please? >> >>> >> > >> >>> >> > What version of Pharo are you on? I think in 1.4 they have >> >>> >> > removed >> >>> >> > ReferenceStreams. >> >>> >> > >> >>> >> > Lukas >> >>> >> > >> >>> >> > -- >> >>> >> > Lukas Renggli >> >>> >> > www.lukas-renggli.ch >> >>> >> > >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> Lukas Renggli >> >>> >> www.lukas-renggli.ch >> >>> >> >> >>> >> _______________________________________________ >> >>> >> Magritte, Pier and Related Tools ... >> >>> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Dennis Schetinin >> >>> > >> >>> > _______________________________________________ >> >>> > Magritte, Pier and Related Tools ... >> >>> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> Lukas Renggli >> >>> www.lukas-renggli.ch >> >>> >> >>> _______________________________________________ >> >>> Magritte, Pier and Related Tools ... >> >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> >> >> >> >> >> >> -- >> >> Dennis Schetinin >> > >> > >> > >> > -- >> > Dennis Schetinin >> > >> > _______________________________________________ >> > Magritte, Pier and Related Tools ... >> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > -- > Dennis Schetinin > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From chaetal at gmail.com Wed Sep 14 16:13:16 2011 From: chaetal at gmail.com (Dennis Schetinin) Date: Wed, 14 Sep 2011 18:13:16 +0400 Subject: Export/Import widget does not work In-Reply-To: References: Message-ID: Ok, I see... Thank you for your help and scripts. I didn't resolve the issue, but I have now a working image for the site I'm building. :) 2011/9/14 Lukas Renggli > I don't know. > > Theoretically configurations load older code that is known to work > together. In practice however it didn't work for me, because there > were dependent other configurations that used newer code. Also I think > the configurations load Swazoo, which has been reported to be broken. > > Lukas > > On 14 September 2011 11:35, Dennis Schetinin wrote: > > Oh? I don't understand, how it could happen, but I'll try to check and > > prevent that. > > Anyway, I hacked that exception by commenting the check :) And that way, > the > > Import/Export buttons work. Thus, there's obviously a difference between > > your scripts and ConfigurationOf..., but I can't find it. Any suggestions > on > > that, maybe? > > > > 2011/9/14 Lukas Renggli > >> > >> That shouldn't happen in Seaside 3.0. Looks like you load Seaside 3.1, > >> maybe through some old files you have in your package cache? > >> > >> Lukas > >> > >> On 14 September 2011 11:16, Dennis Schetinin wrote: > >> > Lukas, I've tried to use your scripts to load Seaside 3.0 + Pier 2 in > >> > Pharo > >> > 1.3 in the following sequence: > >> > OmniBrowser > >> > Seaside 3 > >> > Komanche > >> > Magritte2 > >> > Pier2 > >> > After that, I get MNU for WAApplication>>#hasCookieInContext, just as > I > >> > reported > >> > there: http://forum.world.st/Pier2-and-Seaside-3-1-td3809059.html. > >> > I didn't understand how to fix that, as didn't see > >> > WAUrl>>purgeSeasideFields > >> > ever encountered. > >> > What is the best way to handle this? Is it to use some earlier Seaside > >> > version? Or the issue can be fixed somehow? > >> > 2011/9/14 Dennis Schetinin > >> >> > >> >> No, it is not reproduced in your image. BTW, I have no "Please select > >> >> the > >> >> importer/exporter to use:" at the top of the page in my version. I > >> >> guess I'm > >> >> missing some package or have incorrect version of something in my > >> >> image? > >> >> Going to try to find the difference. > >> >> 2011/9/13 Lukas Renggli > >> >>> > >> >>> Did you try with the image I linked? Can you reproduce it there? > >> >>> > >> >>> On 13 September 2011 21:41, Dennis Schetinin > >> >>> wrote: > >> >>> > Pharo 1.3. I issue the problem with both Zinc and Comanche. I can > >> >>> > provide > >> >>> > scripts if it may help. > >> >>> > BTW, I've managed to import "from Workspace" (just had to hack > >> >>> > #replace > >> >>> > in > >> >>> > PRExporterImporter a bit), but I'd prefer to figure out the source > >> >>> > of > >> >>> > the > >> >>> > problem in the widget and actually resolve it. > >> >>> > 2011/9/13 Lukas Renggli > >> >>> >> > >> >>> >> Also what server adaptor are you using? > >> >>> >> > >> >>> >> I heard that Swazoo has some issues. > >> >>> >> > >> >>> >> Lukas > >> >>> >> > >> >>> >> On 13 September 2011 21:18, Lukas Renggli > >> >>> >> wrote: > >> >>> >> > On 13 September 2011 21:04, Dennis Schetinin < > chaetal at gmail.com> > >> >>> >> > wrote: > >> >>> >> >> I've loaded Seaside 3.0 and Pier 2 with Metacello > >> >>> >> >> configurations. > >> >>> >> >> I tried > >> >>> >> >> both the "latest" (= 3.0.3.1) and the "last" (= 3.0.6) for > >> >>> >> >> Seaside; > >> >>> >> >> I > >> >>> >> >> also > >> >>> >> >> updated all Pier packages from Lukas's repo by hand. The > problem > >> >>> >> >> I > >> >>> >> >> encounter > >> >>> >> >> is with Export/Import widget: clicks on "Export" and "Import" > >> >>> >> >> buttons > >> >>> >> >> are > >> >>> >> >> just ignored (at least, callbacks are not triggered in image). > >> >>> >> >> Am I > >> >>> >> >> doing > >> >>> >> >> something wrong? > >> >>> >> > > >> >>> >> > I cannot reproduce with the latest builds from Jenkins > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > ( > http://jenkins.lukas-renggli.ch/job/Pier%202/lastSuccessfulBuild/artifact/pier2.zip > ). > >> >>> >> > Import and Export works without problems. > >> >>> >> > > >> >>> >> >> I remember I had (and reported) a similar issue several months > >> >>> >> >> ago, > >> >>> >> >> didn't > >> >>> >> >> get any response managed to find some solutions or workaround. > >> >>> >> >> Now > >> >>> >> >> I > >> >>> >> >> can't. > >> >>> >> >> Any help please? > >> >>> >> > > >> >>> >> > What version of Pharo are you on? I think in 1.4 they have > >> >>> >> > removed > >> >>> >> > ReferenceStreams. > >> >>> >> > > >> >>> >> > Lukas > >> >>> >> > > >> >>> >> > -- > >> >>> >> > Lukas Renggli > >> >>> >> > www.lukas-renggli.ch > >> >>> >> > > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> -- > >> >>> >> Lukas Renggli > >> >>> >> www.lukas-renggli.ch > >> >>> >> > >> >>> >> _______________________________________________ > >> >>> >> Magritte, Pier and Related Tools ... > >> >>> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > >> >>> > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > Dennis Schetinin > >> >>> > > >> >>> > _______________________________________________ > >> >>> > Magritte, Pier and Related Tools ... > >> >>> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > >> >>> > > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Lukas Renggli > >> >>> www.lukas-renggli.ch > >> >>> > >> >>> _______________________________________________ > >> >>> Magritte, Pier and Related Tools ... > >> >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > >> >> > >> >> > >> >> > >> >> -- > >> >> Dennis Schetinin > >> > > >> > > >> > > >> > -- > >> > Dennis Schetinin > >> > > >> > _______________________________________________ > >> > Magritte, Pier and Related Tools ... > >> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > >> > > >> > >> > >> > >> -- > >> Lukas Renggli > >> www.lukas-renggli.ch > >> > >> _______________________________________________ > >> Magritte, Pier and Related Tools ... > >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > > > > -- > > Dennis Schetinin > > > > _______________________________________________ > > Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Dennis Schetinin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvdsandt at gmail.com Sun Sep 18 14:05:34 2011 From: jvdsandt at gmail.com (Jan van de Sandt) Date: Sun, 18 Sep 2011 14:05:34 +0200 Subject: Accessing the children of a MAContainer by name ? Message-ID: Hi, In Magritte a MAContainer has a collection of MAElementDescription objects called children. Often I would like to access a child using it's name. Currently a MADescription doesn't have a name property. Most of the times it does have a label and an accessor so I can find a child like this: | accessor | accessor := #eventStatus asAccessor. MBBooking description detect: [ :each | each accessor = accessor ] or MBBooking description detect: [ :each | each label = 'Event status' ] I don't like these options for identifying a child description because they depend on properties that are used for other things. I am thinking about adding an some kind of 'name' property to the description hierarchy. I am curious how others have handled this issue. Jan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Sun Sep 18 14:52:01 2011 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 18 Sep 2011 14:52:01 +0200 Subject: Accessing the children of a MAContainer by name ? In-Reply-To: References: Message-ID: I think the accessor is an ideal object to identify descriptions, because it uniquely identifies a description. Instead of duplicating the accessor you could ask the description for its accessor: accessor := MBBooking descriptionEventStatus accessor. MBBooking description detect: [ :each | each accessor = accessor ] If you do not depend on the extension mechanisms of descriptions, you could also direct call MBBooking descriptionEventStatus to get the description. A bit ugly I agree, we should refactor the creation of descriptions so that also individual descriptions can be cheaply retrieved. Lukas On 18 September 2011 14:05, Jan van de Sandt wrote: > Hi, > In Magritte a MAContainer has a collection of MAElementDescription objects > called children. Often I would like to access a child using it's name. > Currently a MADescription doesn't have a name property. Most of the times it > does have a label and an accessor so I can find a child like this: > | accessor | > accessor := #eventStatus asAccessor. > MBBooking description detect: [ :each | each accessor = accessor ] > or > MBBooking description detect: [ :each | each label = 'Event status' ] > I don't like these options for identifying a child description because they > depend on properties that are used for other things. I am thinking about > adding an some kind of 'name' property to the description hierarchy. I am > curious how others have handled this issue. > Jan. > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From yanni at rogers.com Mon Sep 19 07:02:29 2011 From: yanni at rogers.com (Yanni Chiu) Date: Mon, 19 Sep 2011 01:02:29 -0400 Subject: Accessing the children of a MAContainer by name ? In-Reply-To: References: Message-ID: On 18/09/11 8:05 AM, Jan van de Sandt wrote: > > I don't like these options for identifying a child description because > they depend on properties that are used for other things. I am thinking > about adding an some kind of 'name' property to the description > hierarchy. I am curious how others have handled this issue. I use both methods, and don't like either method. In some cases, I had to use the label. IIRC, it was because it was a chain'ed accessor. From renggli at gmail.com Mon Sep 19 07:24:22 2011 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 19 Sep 2011 07:24:22 +0200 Subject: Accessing the children of a MAContainer by name ? In-Reply-To: References: Message-ID: Uniquely identifying descriptions is a much harder problem than it looks like: descriptions evolve, change, get extended and refactored. At ESUG in 2006 there was a longer discussion about this problem: The question was how to identify descriptions that were dynamically created and edited by users in different images and stored to an OODB. The only reasonable solution was to use UUIDs. It is easy to programmatically add UUIDs, but ideally they should also cover the #description* methods. Lukas On 19 September 2011 07:02, Yanni Chiu wrote: > On 18/09/11 8:05 AM, Jan van de Sandt wrote: >> >> I don't like these options for identifying a child description because >> they depend on properties that are used for other things. I am thinking >> about adding an some kind of 'name' property to the description >> hierarchy. I am curious how others have handled this issue. > > I use both methods, and don't like either method. > > In some cases, I had to use the label. IIRC, it was because it was a > chain'ed accessor. > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From jvdsandt at gmail.com Mon Sep 19 09:26:40 2011 From: jvdsandt at gmail.com (Jan van de Sandt) Date: Mon, 19 Sep 2011 09:26:40 +0200 Subject: Accessing the children of a MAContainer by name ? In-Reply-To: References: Message-ID: Hi Lukas, Thanks for the info. It is indeed more complex than it seems. Would it help if a description has a unique name within a MAContainer? So a container would have an ordered dictionary of children instead of an ordered collection. Jan. On Mon, Sep 19, 2011 at 7:24 AM, Lukas Renggli wrote: > Uniquely identifying descriptions is a much harder problem than it > looks like: descriptions evolve, change, get extended and refactored. > > At ESUG in 2006 there was a longer discussion about this problem: The > question was how to identify descriptions that were dynamically > created and edited by users in different images and stored to an OODB. > The only reasonable solution was to use UUIDs. > > It is easy to programmatically add UUIDs, but ideally they should also > cover the #description* methods. > > Lukas > > > > On 19 September 2011 07:02, Yanni Chiu wrote: > > On 18/09/11 8:05 AM, Jan van de Sandt wrote: > >> > >> I don't like these options for identifying a child description because > >> they depend on properties that are used for other things. I am thinking > >> about adding an some kind of 'name' property to the description > >> hierarchy. I am curious how others have handled this issue. > > > > I use both methods, and don't like either method. > > > > In some cases, I had to use the label. IIRC, it was because it was a > > chain'ed accessor. > > > > _______________________________________________ > > Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yanni at rogers.com Mon Sep 19 17:07:32 2011 From: yanni at rogers.com (Yanni Chiu) Date: Mon, 19 Sep 2011 11:07:32 -0400 Subject: Accessing the children of a MAContainer by name ? In-Reply-To: References: Message-ID: The general case, for dynamic instance-based descriptions, is complicated. Is there some scope for a specialized MAContainer that deals only with static class-based descriptions, using names that are unique within the container? Would this affect the MAContainer protocol in some way? -- Yanni On 19/09/11 3:26 AM, Jan van de Sandt wrote: > Hi Lukas, > > Thanks for the info. It is indeed more complex than it seems. > > Would it help if a description has a unique name within a MAContainer? > So a container would have an ordered dictionary of children instead of > an ordered collection. > > Jan. > > On Mon, Sep 19, 2011 at 7:24 AM, Lukas Renggli > wrote: > > Uniquely identifying descriptions is a much harder problem than it > looks like: descriptions evolve, change, get extended and refactored. > > At ESUG in 2006 there was a longer discussion about this problem: The > question was how to identify descriptions that were dynamically > created and edited by users in different images and stored to an OODB. > The only reasonable solution was to use UUIDs. > > It is easy to programmatically add UUIDs, but ideally they should also > cover the #description* methods. > > Lukas > > > > On 19 September 2011 07:02, Yanni Chiu > wrote: > > On 18/09/11 8:05 AM, Jan van de Sandt wrote: > >> > >> I don't like these options for identifying a child description > because > >> they depend on properties that are used for other things. I am > thinking > >> about adding an some kind of 'name' property to the description > >> hierarchy. I am curious how others have handled this issue. > > > > I use both methods, and don't like either method. > > > > In some cases, I had to use the label. IIRC, it was because it was a > > chain'ed accessor. > > > > _______________________________________________ > > Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From lungu at iam.unibe.ch Mon Sep 19 20:41:44 2011 From: lungu at iam.unibe.ch (Mircea Filip Lungu) Date: Mon, 19 Sep 2011 20:41:44 +0200 Subject: Removing the "pier:" prefix from the title page Message-ID: Hi guys, A quick question: what is the correct way of removing the "pier:" prefix from the title of the pages? Thanks, M. From renggli at gmail.com Mon Sep 19 20:54:42 2011 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 19 Sep 2011 20:54:42 +0200 Subject: Removing the "pier:" prefix from the title page In-Reply-To: References: Message-ID: The word before the colon is the name of the kernel. You can change it here: http://localhost:8080/pier/system/management/kernel If you want to change the title altogether edit "Head Title" in the contents component of your template: http://localhost:8080/pier/system/components/contents?command=PREditCommand Lukas On 19 September 2011 20:41, Mircea Filip Lungu wrote: > Hi guys, > > A quick question: what is the correct way of removing the "pier:" > prefix from the title of the pages? > > Thanks, > M. > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From renggli at gmail.com Tue Sep 20 07:21:40 2011 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 20 Sep 2011 07:21:40 +0200 Subject: Removing the "pier:" prefix from the title page In-Reply-To: References: Message-ID: Also see: http://www.piercms.com/doc/faq#35182702 On 19 September 2011 20:54, Lukas Renggli wrote: > The word before the colon is the name of the kernel. You can change it here: > > ? ?http://localhost:8080/pier/system/management/kernel > > If you want to change the title altogether edit "Head Title" in the > contents component of your template: > > ? ?http://localhost:8080/pier/system/components/contents?command=PREditCommand > > Lukas > > On 19 September 2011 20:41, Mircea Filip Lungu wrote: >> Hi guys, >> >> A quick question: what is the correct way of removing the "pier:" >> prefix from the title of the pages? >> >> Thanks, >> M. >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch From lungu at iam.unibe.ch Tue Sep 20 16:11:03 2011 From: lungu at iam.unibe.ch (Mircea Filip Lungu) Date: Tue, 20 Sep 2011 16:11:03 +0200 Subject: Removing the "pier:" prefix from the title page In-Reply-To: References: Message-ID: Thanks Lukas! M. On Tue, Sep 20, 2011 at 7:21 AM, Lukas Renggli wrote: > Also see: http://www.piercms.com/doc/faq#35182702 > > On 19 September 2011 20:54, Lukas Renggli wrote: >> The word before the colon is the name of the kernel. You can change it here: >> >> ? ?http://localhost:8080/pier/system/management/kernel >> >> If you want to change the title altogether edit "Head Title" in the >> contents component of your template: >> >> ? ?http://localhost:8080/pier/system/components/contents?command=PREditCommand >> >> Lukas >> >> On 19 September 2011 20:41, Mircea Filip Lungu wrote: >>> Hi guys, >>> >>> A quick question: what is the correct way of removing the "pier:" >>> prefix from the title of the pages? >>> >>> Thanks, >>> M. >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Mircea Lungu Researcher Software Composition Group University of Bern http://lungu.org/mircea From renggli at gmail.com Tue Sep 20 18:59:02 2011 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 20 Sep 2011 18:59:02 +0200 Subject: Updated website Message-ID: I've made a pass throughout he piercms.com website to make it up-to-date. I removed all the contents referring to Pier 1.0 and updated the contents where possible. Also I changed the download link to point to the latest stable build. Please let me know if I missed something. Lukas -- Lukas Renggli www.lukas-renggli.ch From lungu at iam.unibe.ch Wed Sep 21 13:51:45 2011 From: lungu at iam.unibe.ch (Mircea Filip Lungu) Date: Wed, 21 Sep 2011 13:51:45 +0200 Subject: Headless Pier Riddle Message-ID: Context: - os: debian - vm: cog - image: the image from the pier site, in which I updated to the latest version of the pier packages ~/coglinux/bin/squeak x.image starts the image with no error and port 8087 is open ~/coglinux/bin/squeak -nodisplay -nosound x.image just blocks and the port 8087 is not open. do you have any idea what could be the reason? I tried with all the possible parameter combinations: (-headless, -vm-display-none) Thanks, M. -- Mircea Lungu Researcher Software Composition Group University of Bern http://lungu.org/mircea From mail.list at ficonab.com Wed Sep 21 16:39:34 2011 From: mail.list at ficonab.com (mail list) Date: Wed, 21 Sep 2011 22:39:34 +0800 Subject: Headless Pier Riddle In-Reply-To: References: Message-ID: I am certain that you will have tried the following suggestions but anyhow 1) check to see if no sound is causing a problem 2) install RFB and see if VNC provides some clues on the image side.. perhaps a dialog is coming up on the image. 3) you could try a strace or struss to see if there i a clue in the libraries... apogees if these are not helpful. S. On Sep 21, 2011, at 7:51 PM, Mircea Filip Lungu wrote: > Context: > > - os: debian > - vm: cog > - image: the image from the pier site, in which I updated to the > latest version of the pier packages > > ~/coglinux/bin/squeak x.image > > starts the image with no error and port 8087 is open > > > ~/coglinux/bin/squeak -nodisplay -nosound x.image > > just blocks and the port 8087 is not open. > > do you have any idea what could be the reason? I tried with all the > possible parameter combinations: (-headless, -vm-display-none) > > Thanks, > M. > > > -- > Mircea Lungu > Researcher > Software Composition Group > University of Bern > http://lungu.org/mircea > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From p3anoman at gmail.com Fri Sep 23 05:08:33 2011 From: p3anoman at gmail.com (John McKeon) Date: Thu, 22 Sep 2011 23:08:33 -0400 Subject: Accessing the children of a MAContainer by name ? In-Reply-To: References: Message-ID: I've used custom properties extensively and are a big part of what I have been doing lately. Don't be afraid to add a property by which YOUR code can identify another description. Just add them in your own package. I don't think you will ever get around iterating through a description to find the one you're after. But you can use another property to store the found description, so it optimizes... I wrestled for some time with finding a way to allow descriptions in a container to "communicate" with one another. Its kind of basic to what we want to use objects for, if one field changes another needs to know about it. But in the memento world, these rules that we might put in a setter method are of no use because they will not execute until the memento is committed. So I came up with an api of sorts, a set of properties, that give you a way to link descriptions together so that components built knowing about these properties can handle events and perform needed operations *on the memento*. It works well with with JQuery. Still quite a work in progress (i.e. it's really ugly code right now) but its in the Magritte-JQueryWidgetBox package in the Magriite 2 addons repositoryif you have the stomach for it :) I removed the widget box components from the functional test so it could run in a stock Seaside 3.0 image. The functional test is the only test in the package btw, ahem 8] Anyway, I've stayed up too late bragging about my crap, but it shows what can be done with custom properties. John On Mon, Sep 19, 2011 at 11:07 AM, Yanni Chiu wrote: > The general case, for dynamic instance-based descriptions, is complicated. > Is there some scope for a specialized MAContainer that deals only with > static class-based descriptions, using names that are unique within the > container? Would this affect the MAContainer protocol in some way? > -- > Yanni > > > On 19/09/11 3:26 AM, Jan van de Sandt wrote: > >> Hi Lukas, >> >> Thanks for the info. It is indeed more complex than it seems. >> >> Would it help if a description has a unique name within a MAContainer? >> So a container would have an ordered dictionary of children instead of >> an ordered collection. >> >> Jan. >> >> On Mon, Sep 19, 2011 at 7:24 AM, Lukas Renggli > > wrote: >> >> Uniquely identifying descriptions is a much harder problem than it >> looks like: descriptions evolve, change, get extended and refactored. >> >> At ESUG in 2006 there was a longer discussion about this problem: The >> question was how to identify descriptions that were dynamically >> created and edited by users in different images and stored to an OODB. >> The only reasonable solution was to use UUIDs. >> >> It is easy to programmatically add UUIDs, but ideally they should also >> cover the #description* methods. >> >> Lukas >> >> >> >> On 19 September 2011 07:02, Yanni Chiu > > wrote: >> > On 18/09/11 8:05 AM, Jan van de Sandt wrote: >> >> >> >> I don't like these options for identifying a child description >> because >> >> they depend on properties that are used for other things. I am >> thinking >> >> about adding an some kind of 'name' property to the description >> >> hierarchy. I am curious how others have handled this issue. >> > >> > I use both methods, and don't like either method. >> > >> > In some cases, I had to use the label. IIRC, it was because it was a >> > chain'ed accessor. >> > >> > ______________________________**_________________ >> > Magritte, Pier and Related Tools ... >> > https://www.iam.unibe.ch/**mailman/listinfo/smallwiki >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> ______________________________**_________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/**mailman/listinfo/smallwiki >> >> >> >> >> ______________________________**_________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/**mailman/listinfo/smallwiki >> > > > ______________________________**_________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/**mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: relators.jpeg Type: image/jpeg Size: 143581 bytes Desc: not available URL: From b.prior at ieee.org Fri Sep 23 18:10:34 2011 From: b.prior at ieee.org (Bruce Prior) Date: Fri, 23 Sep 2011 09:10:34 -0700 Subject: Updated website In-Reply-To: References: Message-ID: <4E7CAF7A.70306@ieee.org> Hi Lukas, It might be useful for newbies if you added something in the Syntax about HTML coding, namely the use of {{{ }}} to enclose the code. I spent a few hours trying to establish what the braces were for when I first saw them. Regards, and thank you for an amazing CMS. Bruce Prior From renggli at gmail.com Sat Sep 24 10:56:25 2011 From: renggli at gmail.com (Lukas Renggli) Date: Sat, 24 Sep 2011 10:56:25 +0200 Subject: Updated website In-Reply-To: <4E7CAF7A.70306@ieee.org> References: <4E7CAF7A.70306@ieee.org> Message-ID: Good catch, the problem is that {{{ }}} was not documented within Pier itself :-( I've added it to the code now: Name: Pier-Model-lr.415 Author: lr Time: 24 September 2011, 10:51:21 am UUID: 3b83cd2d-436c-4184-909b-f7f12bcdc64e Ancestors: Pier-Model-lr.414 - code formatting - describe {{{ and }}} (verbatim) and updated the website: http://www.piercms.com/doc/syntax#152443995 Lukas On 23 September 2011 18:10, Bruce Prior wrote: > Hi Lukas, > > It might be useful for newbies if you added something in the Syntax about > HTML coding, namely the use of {{{ }}} to enclose the code. > > I spent a few hours trying to establish what the braces were for when I > first saw them. > > Regards, and thank you for an amazing CMS. > > Bruce Prior > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From tudor at tudorgirba.com Sat Sep 24 17:03:21 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Sat, 24 Sep 2011 17:03:21 +0200 Subject: default webserver Message-ID: Hi, I see that the default pier2 image still works with Comanche. Is Zinc not reliable enough yet? Cheers, Doru -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding." From renggli at gmail.com Sat Sep 24 18:21:04 2011 From: renggli at gmail.com (Lukas Renggli) Date: Sat, 24 Sep 2011 18:21:04 +0200 Subject: default webserver In-Reply-To: References: Message-ID: > I see that the default pier2 image still works with Comanche. Is Zinc not reliable enough yet? Yes, Zinc sometimes does not come up in headless mode and sometimes break images so that they cannot be opened anymore. Check the thread "[Pharo-project] Zinc crashing image at start up" for more details. So for now we went back to Kom that is slower but works very reliable. Lukas -- Lukas Renggli www.lukas-renggli.ch From tudor at tudorgirba.com Sat Sep 24 18:50:10 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Sat, 24 Sep 2011 18:50:10 +0200 Subject: image persistency does not seem to work Message-ID: <193FB501-A59B-4603-AA43-FFB0A1C0B5F1@tudorgirba.com> Hi, I am testing the latest Pier2 based on Pharo 1.3, and I got an error when trying to use the image-based persistency. The error happens in: PRImagePersistency>>saveImageAndBackupAs: aString ... image openSourceFiles; saveImageSegments; snapshot: true andQuit: false in particular, the SmalltalkImage does not understand saveImageSegments anymore. Is this some cleanup that happened in Pharo and that requires a new package to be loaded? Cheers, Doru -- www.tudorgirba.com "To utilize feedback, you first have to acquire it." From tudor at tudorgirba.com Sat Sep 24 20:18:06 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Sat, 24 Sep 2011 20:18:06 +0200 Subject: [Pharo-project] image persistency does not seem to work In-Reply-To: References: <193FB501-A59B-4603-AA43-FFB0A1C0B5F1@tudorgirba.com> Message-ID: <9CFE68A7-C41D-4A91-8464-F4C1ABD90D33@tudorgirba.com> Hi Marcus, hi Lucas, Thanks. I removed the call and everything is Ok. Cheers, Doru On 24 Sep 2011, at 18:55, Lukas Renggli wrote: > You can probably remove the call to #saveImageSegments. And the Image Segment persistency strategy should probably be removed too. > > Lukas > > On Saturday, 24 September 2011, Tudor Girba wrote: > > Hi, > > > > I am testing the latest Pier2 based on Pharo 1.3, and I got an error when trying to use the image-based persistency. > > > > The error happens in: > > > > PRImagePersistency>>saveImageAndBackupAs: aString > > ... > > image openSourceFiles; saveImageSegments; snapshot: true andQuit: false > > > > in particular, the SmalltalkImage does not understand saveImageSegments anymore. Is this some cleanup that happened in Pharo and that requires a new package to be loaded? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "To utilize feedback, you first have to acquire it." > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch -- www.tudorgirba.com "To utilize feedback, you first have to acquire it." From tudor at tudorgirba.com Sat Sep 24 23:01:29 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Sat, 24 Sep 2011 23:01:29 +0200 Subject: BOLatexWriter Message-ID: Hi, I am testing Pier 2 some more, and now I got a problem in the Latex writer. Specifically, I do not quite understand the difference between the latex instance variable and the inherited stream one. Take a look at the snippet below: BOLatexWriter>>visitInternalLink: anInternalLink ... latex tab ... square: [ stream nextPutAll: 'width='; print: ((anInternalLink parameterAt: 'width' ifAbsent: [ 100 ]) asNumber / 100.0); ... ] When executed on a book we have two instance variables: - stream: instance of GRPharoUtf8CodecStream (inherited) - latex: instance of BOLatexStream which wraps stream Now, it so happens that GRPharoUtf8CodecStream does not understand print:, but this method exists in BOLatexStream. I fixed the code by replacing stream with latex in the above method, and it works. But, there are still other places that use stream, and I think they should all use the BOLatexStream instance instead. So, my question is: Is this intentional? Or maybe should we actually simply override the setting of stream and use that one for everything? Cheers, Doru -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge." From renggli at gmail.com Sat Sep 24 23:11:53 2011 From: renggli at gmail.com (Lukas Renggli) Date: Sat, 24 Sep 2011 23:11:53 +0200 Subject: BOLatexWriter In-Reply-To: References: Message-ID: Yes, this is intentional: 'stream' is the raw low-level stream, 'latex' is the high-level encoded stream. The choice to which you send the output is important. Changing it likely breaks the generation of valid LaTeX. GRPharoUtf8CodecStream or better its abstract superclass should implement #print:. I think this was discussed in the Seaside list recently and fixed, but I might be wrong. Lukas On Saturday, 24 September 2011, Tudor Girba wrote: > Hi, > > I am testing Pier 2 some more, and now I got a problem in the Latex writer. Specifically, I do not quite understand the difference between the latex instance variable and the inherited stream one. > > Take a look at the snippet below: > > BOLatexWriter>>visitInternalLink: anInternalLink > ... > latex tab ... square: [ stream nextPutAll: 'width='; print: ((anInternalLink parameterAt: 'width' ifAbsent: [ 100 ]) asNumber / 100.0); ... ] > > When executed on a book we have two instance variables: > - stream: instance of GRPharoUtf8CodecStream (inherited) > - latex: instance of BOLatexStream which wraps stream > > Now, it so happens that GRPharoUtf8CodecStream does not understand print:, but this method exists in BOLatexStream. I fixed the code by replacing stream with latex in the above method, and it works. > > But, there are still other places that use stream, and I think they should all use the BOLatexStream instance instead. So, my question is: Is this intentional? Or maybe should we actually simply override the setting of stream and use that one for everything? > > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch -------------- next part -------------- An HTML attachment was scrubbed... URL: From tudor at tudorgirba.com Sat Sep 24 23:41:25 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Sat, 24 Sep 2011 23:41:25 +0200 Subject: BOLatexWriter In-Reply-To: References: Message-ID: <882D94A8-5A52-48C2-B329-44A8D1FA3122@tudorgirba.com> Hi, Thanks. In the latest version of all Grease packages and the print: method is not around in the Stream hierarchy. So, for is it Ok to have the fix in BOLatexWriter>>visitInternalLink: by replacing stream with latex to work with print: or do you see problems there? Cheers, Doru On 24 Sep 2011, at 23:11, Lukas Renggli wrote: > Yes, this is intentional: 'stream' is the raw low-level stream, 'latex' is the high-level encoded stream. The choice to which you send the output is important. Changing it likely breaks the generation of valid LaTeX. > > GRPharoUtf8CodecStream or better its abstract superclass should implement #print:. I think this was discussed in the Seaside list recently and fixed, but I might be wrong. > > Lukas > > On Saturday, 24 September 2011, Tudor Girba wrote: > > Hi, > > > > I am testing Pier 2 some more, and now I got a problem in the Latex writer. Specifically, I do not quite understand the difference between the latex instance variable and the inherited stream one. > > > > Take a look at the snippet below: > > > > BOLatexWriter>>visitInternalLink: anInternalLink > > ... > > latex tab ... square: [ stream nextPutAll: 'width='; print: ((anInternalLink parameterAt: 'width' ifAbsent: [ 100 ]) asNumber / 100.0); ... ] > > > > When executed on a book we have two instance variables: > > - stream: instance of GRPharoUtf8CodecStream (inherited) > > - latex: instance of BOLatexStream which wraps stream > > > > Now, it so happens that GRPharoUtf8CodecStream does not understand print:, but this method exists in BOLatexStream. I fixed the code by replacing stream with latex in the above method, and it works. > > > > But, there are still other places that use stream, and I think they should all use the BOLatexStream instance instead. So, my question is: Is this intentional? Or maybe should we actually simply override the setting of stream and use that one for everything? > > > > Cheers, > > Doru > > > > > > > > -- > > www.tudorgirba.com > > > > "Yesterday is a fact. > > Tomorrow is a possibility. > > Today is a challenge." > > > > > > > > > > _______________________________________________ > > Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar." From tudor at tudorgirba.com Sun Sep 25 10:57:37 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Sun, 25 Sep 2011 10:57:37 +0200 Subject: [Seaside] BOLatexWriter In-Reply-To: References: <882D94A8-5A52-48C2-B329-44A8D1FA3122@tudorgirba.com> <08BA6968-EF85-4908-9C06-7F5D2DA22FFE@tudorgirba.com> Message-ID: <7E200178-DF78-4E26-84A5-0DC8430565AA@tudorgirba.com> Thanks, it works. Now, we have a followup problem in BOLatexStream BOLatexStream>>print: anObject anObject isNil ifTrue: [ ^ self ]. anObject isBlock ifTrue: [ anObject value ] ifFalse: [ self nextPutAll: anObject displayString ] displayString is deprecated, and I am not quite sure what it should be replaced with. I guess it should be printString, or we should just delegate to the print: of the inner stream. What do you say? Cheers, Doru On 25 Sep 2011, at 10:16, Lukas Renggli wrote: > Have a look if > > Name: Grease-Core-lr.66 > Author: lr > Time: 25 September 2011, 10:13:37 am > UUID: 0a3221fb-c5d8-4ce1-b139-0e6dc72481a2 > Ancestors: Grease-Core-dkh.65 > > - add GRCodecStream>>#print: > > fixes the problem? > > Lukas > > On 25 September 2011 09:53, Tudor Girba wrote: >> Hi, >> >> >> On 25 Sep 2011, at 08:49, Lukas Renggli wrote: >> >>>> Thanks. In the latest version of all Grease packages and the print: method is not around in the Stream hierarchy. >>> >>> Ok, then it should be added. >>> >>>> So, for is it Ok to have the fix in BOLatexWriter>>visitInternalLink: by replacing stream with latex to work with print: or do you see problems there? >>> >>> No, the two strams don't have te same semantics. stream print: '\' should print '\'; latex print: '\' should print '\\'. >> >> Right. I got the difference now. >> >> But, I still would not know how to implement GRXYZStream>>print:, because I am not sure I understand what is the difference between print: and nextPutAll:. Could anyone help with this matter? >> >> Cheers, >> Doru >> >> >> >>> Lukas >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 24 Sep 2011, at 23:11, Lukas Renggli wrote: >>>> >>>>> Yes, this is intentional: 'stream' is the raw low-level stream, 'latex' is the high-level encoded stream. The choice to which you send the output is important. Changing it likely breaks the generation of valid LaTeX. >>>>> >>>>> GRPharoUtf8CodecStream or better its abstract superclass should implement #print:. I think this was discussed in the Seaside list recently and fixed, but I might be wrong. >>>>> >>>>> Lukas >>>>> >>>>> On Saturday, 24 September 2011, Tudor Girba wrote: >>>>>> Hi, >>>>>> >>>>>> I am testing Pier 2 some more, and now I got a problem in the Latex writer. Specifically, I do not quite understand the difference between the latex instance variable and the inherited stream one. >>>>>> >>>>>> Take a look at the snippet below: >>>>>> >>>>>> BOLatexWriter>>visitInternalLink: anInternalLink >>>>>> ... >>>>>> latex tab ... square: [ stream nextPutAll: 'width='; print: ((anInternalLink parameterAt: 'width' ifAbsent: [ 100 ]) asNumber / 100.0); ... ] >>>>>> >>>>>> When executed on a book we have two instance variables: >>>>>> - stream: instance of GRPharoUtf8CodecStream (inherited) >>>>>> - latex: instance of BOLatexStream which wraps stream >>>>>> >>>>>> Now, it so happens that GRPharoUtf8CodecStream does not understand print:, but this method exists in BOLatexStream. I fixed the code by replacing stream with latex in the above method, and it works. >>>>>> >>>>>> But, there are still other places that use stream, and I think they should all use the BOLatexStream instance instead. So, my question is: Is this intentional? Or maybe should we actually simply override the setting of stream and use that one for everything? >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Yesterday is a fact. >>>>>> Tomorrow is a possibility. >>>>>> Today is a challenge." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Magritte, Pier and Related Tools ... >>>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>>>>> >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> www.lukas-renggli.ch >>>>> _______________________________________________ >>>>> Magritte, Pier and Related Tools ... >>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "From an abstract enough point of view, any two things are similar." >>>> >>>> >>>> >>>> _______________________________________________ >>>> seaside mailing list >>>> seaside at lists.squeakfoundation.org >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> _______________________________________________ >>> seaside mailing list >>> seaside at lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> -- >> www.tudorgirba.com >> >> "In a world where everything is moving ever faster, >> one might have better chances to win by moving slower." >> >> >> >> _______________________________________________ >> seaside mailing list >> seaside at lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > seaside mailing list > seaside at lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower." From tudor at tudorgirba.com Sun Sep 25 11:14:23 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Sun, 25 Sep 2011 11:14:23 +0200 Subject: BOZipView broken Message-ID: <3D266FC7-03E0-485E-BD7B-762989157060@tudorgirba.com> Hi, It looks like BOZipView is out of date: - it implements renderContentOn: but this is never reached - it misses the respondUsing: hook method that seems to be the preferred way to generate a response I tried to implement respondUsing: by copying from renderContentOn:: BOZipView>>respondUsing: aResponse | archive | super respondUsing: aResponse. aResponse contentType: 'application/zip'; attachmentWithFileName: self book name , '.zip'. archive := ZipArchive new. self addLatexTo: archive; addFilesTo: archive. archive writeTo: aResponse stream. archive close It seems to go in the right direction, but the issue is that GRPharoUtf8CodecStream does not understand binary (a method needed by ZipArchive). Again, binary should probably be implemented in the GRCodecStream, but I do not know how. Any hints? Cheers, Doru -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." From renggli at gmail.com Sun Sep 25 11:18:01 2011 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 25 Sep 2011 11:18:01 +0200 Subject: [Seaside] BOLatexWriter In-Reply-To: <7E200178-DF78-4E26-84A5-0DC8430565AA@tudorgirba.com> References: <882D94A8-5A52-48C2-B329-44A8D1FA3122@tudorgirba.com> <08BA6968-EF85-4908-9C06-7F5D2DA22FFE@tudorgirba.com> <7E200178-DF78-4E26-84A5-0DC8430565AA@tudorgirba.com> Message-ID: On 25 September 2011 10:57, Tudor Girba wrote: > Thanks, it works. > > Now, we have a followup problem in BOLatexStream > > BOLatexStream>>print: anObject > ? ? ? ?anObject isNil > ? ? ? ? ? ? ? ?ifTrue: [ ^ self ]. > ? ? ? ?anObject isBlock > ? ? ? ? ? ? ? ?ifTrue: [ anObject value ] > ? ? ? ? ? ? ? ?ifFalse: [ self nextPutAll: anObject displayString ] > > displayString is deprecated, and I am not quite sure what it should be replaced with. I guess it should be printString, or we should just delegate to the print: of the inner stream. > > What do you say? No, #printString is only for developer facing strings; use #greaseString, the platform independent #displayString for user facing strings. Lukas > > Cheers, > Doru > > > On 25 Sep 2011, at 10:16, Lukas Renggli wrote: > >> Have a look if >> >> ? Name: Grease-Core-lr.66 >> ? Author: lr >> ? Time: 25 September 2011, 10:13:37 am >> ? UUID: 0a3221fb-c5d8-4ce1-b139-0e6dc72481a2 >> ? Ancestors: Grease-Core-dkh.65 >> >> ? - add GRCodecStream>>#print: >> >> fixes the problem? >> >> Lukas >> >> On 25 September 2011 09:53, Tudor Girba wrote: >>> Hi, >>> >>> >>> On 25 Sep 2011, at 08:49, Lukas Renggli wrote: >>> >>>>> Thanks. In the latest version of all Grease packages and the print: method is not around in the Stream hierarchy. >>>> >>>> Ok, then it should be added. >>>> >>>>> So, for is it Ok to have the fix in BOLatexWriter>>visitInternalLink: by replacing stream with latex to work with print: or do you see problems there? >>>> >>>> No, the two strams don't have te same semantics. stream print: '\' should print '\'; latex print: '\' should print '\\'. >>> >>> Right. I got the difference now. >>> >>> But, I still would not know how to implement GRXYZStream>>print:, because I am not sure I understand what is the difference between print: and nextPutAll:. Could anyone help with this matter? >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> Lukas >>>> >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On 24 Sep 2011, at 23:11, Lukas Renggli wrote: >>>>> >>>>>> Yes, this is intentional: 'stream' is the raw low-level stream, 'latex' is the high-level encoded stream. The choice to which you send the output is important. Changing it likely breaks the generation of valid LaTeX. >>>>>> >>>>>> GRPharoUtf8CodecStream or better its abstract superclass should implement #print:. I think this was discussed in the Seaside list recently and fixed, but I might be wrong. >>>>>> >>>>>> Lukas >>>>>> >>>>>> On Saturday, 24 September 2011, Tudor Girba wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I am testing Pier 2 some more, and now I got a problem in the Latex writer. Specifically, I do not quite understand the difference between the latex instance variable and the inherited stream one. >>>>>>> >>>>>>> Take a look at the snippet below: >>>>>>> >>>>>>> BOLatexWriter>>visitInternalLink: anInternalLink >>>>>>> ? ? ? ? ? ? ? ?... >>>>>>> ? ? ? ? ? ? ? ?latex tab ... square: [ stream nextPutAll: 'width='; print: ((anInternalLink parameterAt: 'width' ifAbsent: [ 100 ]) asNumber / 100.0); ... ] >>>>>>> >>>>>>> When executed on a book we have two instance variables: >>>>>>> - stream: instance of GRPharoUtf8CodecStream (inherited) >>>>>>> - latex: instance of BOLatexStream which wraps stream >>>>>>> >>>>>>> Now, it so happens that GRPharoUtf8CodecStream does not understand print:, but this method exists in BOLatexStream. I fixed the code by replacing stream with latex in the above method, and it works. >>>>>>> >>>>>>> But, there are still other places that use stream, and I think they should all use the BOLatexStream instance instead. So, my question is: Is this intentional? Or maybe should we actually simply override the setting of stream and use that one for everything? >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Yesterday is a fact. >>>>>>> ?Tomorrow is a possibility. >>>>>>> ?Today is a challenge." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Magritte, Pier and Related Tools ... >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>>>>>> >>>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> www.lukas-renggli.ch >>>>>> _______________________________________________ >>>>>> Magritte, Pier and Related Tools ... >>>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "From an abstract enough point of view, any two things are similar." >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> seaside mailing list >>>>> seaside at lists.squeakfoundation.org >>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>>> >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> _______________________________________________ >>>> seaside mailing list >>>> seaside at lists.squeakfoundation.org >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >>> -- >>> www.tudorgirba.com >>> >>> "In a world where everything is moving ever faster, >>> one might have better chances to win by moving slower." >>> >>> >>> >>> _______________________________________________ >>> seaside mailing list >>> seaside at lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> _______________________________________________ >> seaside mailing list >> seaside at lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From renggli at gmail.com Sun Sep 25 11:27:48 2011 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 25 Sep 2011 11:27:48 +0200 Subject: BOZipView broken In-Reply-To: <3D266FC7-03E0-485E-BD7B-762989157060@tudorgirba.com> References: <3D266FC7-03E0-485E-BD7B-762989157060@tudorgirba.com> Message-ID: > It looks like BOZipView is out of date: Yeah, this is all Seaside 2.8 code that has never been updated. > - it implements renderContentOn: but this is never reached Yeah, this is never reached. Override #respondUsing: instead. > - it misses the respondUsing: hook method that seems to be the preferred way to generate a response > I tried to implement respondUsing: by copying from renderContentOn:: > BOZipView>>respondUsing: aResponse > ? ? ? ?| archive | > ? ? ? ?super respondUsing: aResponse. > ? ? ? ?aResponse > ? ? ? ? ? ? ? ?contentType: 'application/zip'; > ? ? ? ? ? ? ? ?attachmentWithFileName: self book name , '.zip'. > ? ? ? ?archive := ZipArchive new. > ? ? ? ?self addLatexTo: archive; addFilesTo: archive. > ? ? ? ?archive writeTo: aResponse stream. > ? ? ? ?archive close > > It seems to go in the right direction, but the issue is that GRPharoUtf8CodecStream does not understand binary (a method needed by ZipArchive). GRPharoUtf8CodecStream is a text stream by definition (hence the codec). You have to put the response into binary mode using #binary, then you should get a binary stream, not an codec stream. Lukas -- Lukas Renggli www.lukas-renggli.ch From tudor at tudorgirba.com Sun Sep 25 12:54:42 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Sun, 25 Sep 2011 12:54:42 +0200 Subject: BOZipView broken In-Reply-To: References: <3D266FC7-03E0-485E-BD7B-762989157060@tudorgirba.com> Message-ID: <37ABF8A9-40FA-48B9-9397-3476C4025A33@tudorgirba.com> Hi Lukas, Thanks for fixing the code. Now, there is no error when exporting the zip file, but still the book.tex file contains strange characters. I guess it is related to an encoding problem. Just open the file with TextMate and the problem is quite apparent. Cheers, Doru On 25 Sep 2011, at 11:27, Lukas Renggli wrote: >> It looks like BOZipView is out of date: > > Yeah, this is all Seaside 2.8 code that has never been updated. > >> - it implements renderContentOn: but this is never reached > > Yeah, this is never reached. Override #respondUsing: instead. > >> - it misses the respondUsing: hook method that seems to be the preferred way to generate a response > > >> I tried to implement respondUsing: by copying from renderContentOn:: >> BOZipView>>respondUsing: aResponse >> | archive | >> super respondUsing: aResponse. >> aResponse >> contentType: 'application/zip'; >> attachmentWithFileName: self book name , '.zip'. >> archive := ZipArchive new. >> self addLatexTo: archive; addFilesTo: archive. >> archive writeTo: aResponse stream. >> archive close >> >> It seems to go in the right direction, but the issue is that GRPharoUtf8CodecStream does not understand binary (a method needed by ZipArchive). > > GRPharoUtf8CodecStream is a text stream by definition (hence the codec). > > You have to put the response into binary mode using #binary, then you > should get a binary stream, not an codec stream. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "Be rather willing to give than demanding to get." From renggli at gmail.com Sun Sep 25 14:11:21 2011 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 25 Sep 2011 14:11:21 +0200 Subject: BOZipView broken In-Reply-To: <37ABF8A9-40FA-48B9-9397-3476C4025A33@tudorgirba.com> References: <3D266FC7-03E0-485E-BD7B-762989157060@tudorgirba.com> <37ABF8A9-40FA-48B9-9397-3476C4025A33@tudorgirba.com> Message-ID: Ok, I guess that is because of the missing encoding into the Zip archive. That should be fixable. Give me a few minutes. Note that I also fixed the verbatim support for different output types. So writing {{{html:strong}}} will only show up in html. Similarly {{{latex:\strong{strong} }}} will only show up in LaTeX. If you don't specify a type {{{something}}} this shows up verbatim in all output. Likely this is not wanted when producing some decent output in various formats (such as in the book). Cheers, Lukas On 25 September 2011 12:54, Tudor Girba wrote: > Hi Lukas, > > Thanks for fixing the code. > > Now, there is no error when exporting the zip file, but still the book.tex file contains strange characters. I guess it is related to an encoding problem. Just open the file with TextMate and the problem is quite apparent. > > Cheers, > Doru > > > On 25 Sep 2011, at 11:27, Lukas Renggli wrote: > >>> It looks like BOZipView is out of date: >> >> Yeah, this is all Seaside 2.8 code that has never been updated. >> >>> - it implements renderContentOn: but this is never reached >> >> Yeah, this is never reached. Override #respondUsing: instead. >> >>> - it misses the respondUsing: hook method that seems to be the preferred way to generate a response >> >> >>> I tried to implement respondUsing: by copying from renderContentOn:: >>> BOZipView>>respondUsing: aResponse >>> ? ? ? ?| archive | >>> ? ? ? ?super respondUsing: aResponse. >>> ? ? ? ?aResponse >>> ? ? ? ? ? ? ? ?contentType: 'application/zip'; >>> ? ? ? ? ? ? ? ?attachmentWithFileName: self book name , '.zip'. >>> ? ? ? ?archive := ZipArchive new. >>> ? ? ? ?self addLatexTo: archive; addFilesTo: archive. >>> ? ? ? ?archive writeTo: aResponse stream. >>> ? ? ? ?archive close >>> >>> It seems to go in the right direction, but the issue is that GRPharoUtf8CodecStream does not understand binary (a method needed by ZipArchive). >> >> GRPharoUtf8CodecStream is a text stream by definition (hence the codec). >> >> You have to put the response into binary mode using #binary, then you >> should get a binary stream, not an codec stream. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From renggli at gmail.com Sun Sep 25 14:12:06 2011 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 25 Sep 2011 14:12:06 +0200 Subject: BOZipView broken In-Reply-To: References: <3D266FC7-03E0-485E-BD7B-762989157060@tudorgirba.com> <37ABF8A9-40FA-48B9-9397-3476C4025A33@tudorgirba.com> Message-ID: On 25 September 2011 14:11, Lukas Renggli wrote: > Ok, I guess that is because of the missing encoding into the Zip > archive. That should be fixable. Give me a few minutes. > > Note that I also fixed the verbatim support for different output > types. So writing > > ?{{{html:strong}}} > > will only show up in html. Similarly > > ? {{{latex:\strong{strong} }}} > > will only show up in LaTeX. If you don't specify a type > > ? {{{something}}} > > this shows up verbatim in all output. Likely this is not wanted when > producing some decent output in various formats (such as in the book). Some more testing is needed, and we should update PRBookDistribution accordingly. Lukas > > Cheers, > Lukas > > On 25 September 2011 12:54, Tudor Girba wrote: >> Hi Lukas, >> >> Thanks for fixing the code. >> >> Now, there is no error when exporting the zip file, but still the book.tex file contains strange characters. I guess it is related to an encoding problem. Just open the file with TextMate and the problem is quite apparent. >> >> Cheers, >> Doru >> >> >> On 25 Sep 2011, at 11:27, Lukas Renggli wrote: >> >>>> It looks like BOZipView is out of date: >>> >>> Yeah, this is all Seaside 2.8 code that has never been updated. >>> >>>> - it implements renderContentOn: but this is never reached >>> >>> Yeah, this is never reached. Override #respondUsing: instead. >>> >>>> - it misses the respondUsing: hook method that seems to be the preferred way to generate a response >>> >>> >>>> I tried to implement respondUsing: by copying from renderContentOn:: >>>> BOZipView>>respondUsing: aResponse >>>> ? ? ? ?| archive | >>>> ? ? ? ?super respondUsing: aResponse. >>>> ? ? ? ?aResponse >>>> ? ? ? ? ? ? ? ?contentType: 'application/zip'; >>>> ? ? ? ? ? ? ? ?attachmentWithFileName: self book name , '.zip'. >>>> ? ? ? ?archive := ZipArchive new. >>>> ? ? ? ?self addLatexTo: archive; addFilesTo: archive. >>>> ? ? ? ?archive writeTo: aResponse stream. >>>> ? ? ? ?archive close >>>> >>>> It seems to go in the right direction, but the issue is that GRPharoUtf8CodecStream does not understand binary (a method needed by ZipArchive). >>> >>> GRPharoUtf8CodecStream is a text stream by definition (hence the codec). >>> >>> You have to put the response into binary mode using #binary, then you >>> should get a binary stream, not an codec stream. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> -- >> www.tudorgirba.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch From tudor at tudorgirba.com Sun Sep 25 14:19:03 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Sun, 25 Sep 2011 14:19:03 +0200 Subject: BOZipView broken In-Reply-To: References: <3D266FC7-03E0-485E-BD7B-762989157060@tudorgirba.com> <37ABF8A9-40FA-48B9-9397-3476C4025A33@tudorgirba.com> Message-ID: <5CD37352-9C6A-48CB-BD8D-E63A2CDEF3DC@tudorgirba.com> Hi, On 25 Sep 2011, at 14:12, Lukas Renggli wrote: > On 25 September 2011 14:11, Lukas Renggli wrote: >> Ok, I guess that is because of the missing encoding into the Zip >> archive. That should be fixable. Give me a few minutes. >> >> Note that I also fixed the verbatim support for different output >> types. So writing >> >> {{{html:strong}}} >> >> will only show up in html. Similarly >> >> {{{latex:\strong{strong} }}} >> >> will only show up in LaTeX. If you don't specify a type >> >> {{{something}}} >> >> this shows up verbatim in all output. Likely this is not wanted when >> producing some decent output in various formats (such as in the book). > > Some more testing is needed, It looks good. > and we should update PRBookDistribution > accordingly. What do you mean? To add an example? Cheers, Doru > Lukas > > >> >> Cheers, >> Lukas >> >> On 25 September 2011 12:54, Tudor Girba wrote: >>> Hi Lukas, >>> >>> Thanks for fixing the code. >>> >>> Now, there is no error when exporting the zip file, but still the book.tex file contains strange characters. I guess it is related to an encoding problem. Just open the file with TextMate and the problem is quite apparent. >>> >>> Cheers, >>> Doru >>> >>> >>> On 25 Sep 2011, at 11:27, Lukas Renggli wrote: >>> >>>>> It looks like BOZipView is out of date: >>>> >>>> Yeah, this is all Seaside 2.8 code that has never been updated. >>>> >>>>> - it implements renderContentOn: but this is never reached >>>> >>>> Yeah, this is never reached. Override #respondUsing: instead. >>>> >>>>> - it misses the respondUsing: hook method that seems to be the preferred way to generate a response >>>> >>>> >>>>> I tried to implement respondUsing: by copying from renderContentOn:: >>>>> BOZipView>>respondUsing: aResponse >>>>> | archive | >>>>> super respondUsing: aResponse. >>>>> aResponse >>>>> contentType: 'application/zip'; >>>>> attachmentWithFileName: self book name , '.zip'. >>>>> archive := ZipArchive new. >>>>> self addLatexTo: archive; addFilesTo: archive. >>>>> archive writeTo: aResponse stream. >>>>> archive close >>>>> >>>>> It seems to go in the right direction, but the issue is that GRPharoUtf8CodecStream does not understand binary (a method needed by ZipArchive). >>>> >>>> GRPharoUtf8CodecStream is a text stream by definition (hence the codec). >>>> >>>> You have to put the response into binary mode using #binary, then you >>>> should get a binary stream, not an codec stream. >>>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> Magritte, Pier and Related Tools ... >>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >>> -- >>> www.tudorgirba.com >>> >>> "Be rather willing to give than demanding to get." >>> >>> >>> >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "Obvious things are difficult to teach." From renggli at gmail.com Sun Sep 25 14:24:29 2011 From: renggli at gmail.com (Lukas Renggli) Date: Sun, 25 Sep 2011 14:24:29 +0200 Subject: BOZipView broken In-Reply-To: <5CD37352-9C6A-48CB-BD8D-E63A2CDEF3DC@tudorgirba.com> References: <3D266FC7-03E0-485E-BD7B-762989157060@tudorgirba.com> <37ABF8A9-40FA-48B9-9397-3476C4025A33@tudorgirba.com> <5CD37352-9C6A-48CB-BD8D-E63A2CDEF3DC@tudorgirba.com> Message-ID: >> and we should update PRBookDistribution >> accordingly. > > What do you mean? To add an example? No, but the book is full of HTML markup that is actually ment for the HTML book only. I've posted a quick fix for the encoding issue in the Zip archive. Please verify that it works: Name: Pier-Book-lr.151 Author: lr Time: 25 September 2011, 2:21:49 pm UUID: 798b6ff9-3f0f-43f2-848c-43eeed1ffa2d Ancestors: Pier-Book-lr.150 - encode the latex in the zip archive There is something strange in Pharo though. The ZipArchive somehow expects textual contents to be a ByteArray, which is really weird and should probably be fixed in Pharo. Lukas > > Cheers, > Doru > > >> Lukas >> >> >>> >>> Cheers, >>> Lukas >>> >>> On 25 September 2011 12:54, Tudor Girba wrote: >>>> Hi Lukas, >>>> >>>> Thanks for fixing the code. >>>> >>>> Now, there is no error when exporting the zip file, but still the book.tex file contains strange characters. I guess it is related to an encoding problem. Just open the file with TextMate and the problem is quite apparent. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 25 Sep 2011, at 11:27, Lukas Renggli wrote: >>>> >>>>>> It looks like BOZipView is out of date: >>>>> >>>>> Yeah, this is all Seaside 2.8 code that has never been updated. >>>>> >>>>>> - it implements renderContentOn: but this is never reached >>>>> >>>>> Yeah, this is never reached. Override #respondUsing: instead. >>>>> >>>>>> - it misses the respondUsing: hook method that seems to be the preferred way to generate a response >>>>> >>>>> >>>>>> I tried to implement respondUsing: by copying from renderContentOn:: >>>>>> BOZipView>>respondUsing: aResponse >>>>>> ? ? ? ?| archive | >>>>>> ? ? ? ?super respondUsing: aResponse. >>>>>> ? ? ? ?aResponse >>>>>> ? ? ? ? ? ? ? ?contentType: 'application/zip'; >>>>>> ? ? ? ? ? ? ? ?attachmentWithFileName: self book name , '.zip'. >>>>>> ? ? ? ?archive := ZipArchive new. >>>>>> ? ? ? ?self addLatexTo: archive; addFilesTo: archive. >>>>>> ? ? ? ?archive writeTo: aResponse stream. >>>>>> ? ? ? ?archive close >>>>>> >>>>>> It seems to go in the right direction, but the issue is that GRPharoUtf8CodecStream does not understand binary (a method needed by ZipArchive). >>>>> >>>>> GRPharoUtf8CodecStream is a text stream by definition (hence the codec). >>>>> >>>>> You have to put the response into binary mode using #binary, then you >>>>> should get a binary stream, not an codec stream. >>>>> >>>>> Lukas >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> www.lukas-renggli.ch >>>>> >>>>> _______________________________________________ >>>>> Magritte, Pier and Related Tools ... >>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Be rather willing to give than demanding to get." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Magritte, Pier and Related Tools ... >>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From tudor at tudorgirba.com Sun Sep 25 14:47:55 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Sun, 25 Sep 2011 14:47:55 +0200 Subject: BOZipView broken In-Reply-To: References: <3D266FC7-03E0-485E-BD7B-762989157060@tudorgirba.com> <37ABF8A9-40FA-48B9-9397-3476C4025A33@tudorgirba.com> <5CD37352-9C6A-48CB-BD8D-E63A2CDEF3DC@tudorgirba.com> Message-ID: <08087E61-81EB-4969-B837-E37878D16479@tudorgirba.com> Hi, On 25 Sep 2011, at 14:24, Lukas Renggli wrote: >>> and we should update PRBookDistribution >>> accordingly. >> >> What do you mean? To add an example? > > No, but the book is full of HTML markup that is actually ment for the > HTML book only. > I've posted a quick fix for the encoding issue in the Zip archive. > Please verify that it works: > > Name: Pier-Book-lr.151 > Author: lr > Time: 25 September 2011, 2:21:49 pm > UUID: 798b6ff9-3f0f-43f2-848c-43eeed1ffa2d > Ancestors: Pier-Book-lr.150 > > - encode the latex in the zip archive Thanks. It works fine now. Cheers, Doru > There is something strange in Pharo though. The ZipArchive somehow > expects textual contents to be a ByteArray, which is really weird and > should probably be fixed in Pharo. > > Lukas > > > > > >> >> Cheers, >> Doru >> >> >>> Lukas >>> >>> >>>> >>>> Cheers, >>>> Lukas >>>> >>>> On 25 September 2011 12:54, Tudor Girba wrote: >>>>> Hi Lukas, >>>>> >>>>> Thanks for fixing the code. >>>>> >>>>> Now, there is no error when exporting the zip file, but still the book.tex file contains strange characters. I guess it is related to an encoding problem. Just open the file with TextMate and the problem is quite apparent. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On 25 Sep 2011, at 11:27, Lukas Renggli wrote: >>>>> >>>>>>> It looks like BOZipView is out of date: >>>>>> >>>>>> Yeah, this is all Seaside 2.8 code that has never been updated. >>>>>> >>>>>>> - it implements renderContentOn: but this is never reached >>>>>> >>>>>> Yeah, this is never reached. Override #respondUsing: instead. >>>>>> >>>>>>> - it misses the respondUsing: hook method that seems to be the preferred way to generate a response >>>>>> >>>>>> >>>>>>> I tried to implement respondUsing: by copying from renderContentOn:: >>>>>>> BOZipView>>respondUsing: aResponse >>>>>>> | archive | >>>>>>> super respondUsing: aResponse. >>>>>>> aResponse >>>>>>> contentType: 'application/zip'; >>>>>>> attachmentWithFileName: self book name , '.zip'. >>>>>>> archive := ZipArchive new. >>>>>>> self addLatexTo: archive; addFilesTo: archive. >>>>>>> archive writeTo: aResponse stream. >>>>>>> archive close >>>>>>> >>>>>>> It seems to go in the right direction, but the issue is that GRPharoUtf8CodecStream does not understand binary (a method needed by ZipArchive). >>>>>> >>>>>> GRPharoUtf8CodecStream is a text stream by definition (hence the codec). >>>>>> >>>>>> You have to put the response into binary mode using #binary, then you >>>>>> should get a binary stream, not an codec stream. >>>>>> >>>>>> Lukas >>>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> www.lukas-renggli.ch >>>>>> >>>>>> _______________________________________________ >>>>>> Magritte, Pier and Related Tools ... >>>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Be rather willing to give than demanding to get." >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Magritte, Pier and Related Tools ... >>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>>>> >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> -- >> www.tudorgirba.com >> >> "Obvious things are difficult to teach." >> >> >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "Beauty is where we see it." From ed.dunord at gmail.com Thu Sep 29 16:26:26 2011 From: ed.dunord at gmail.com (Edgard Dunord) Date: Thu, 29 Sep 2011 16:26:26 +0200 Subject: Custom CMS Message-ID: Dear all, I'm a Pier noob user, but I know ST and I want to build a custom CMS based on Pier. The main goal is the implementation of a customized interface CMS for my little enterprise, but without the complexity of Pier (yes, I know, it's not realy the case, but...) and with a minimal set of functionality, like an author interface with just Add, delete, modify page commands and, e.g. a view commands to... directly view the result... So I'm lost into the general structure, how to remove things, add personnal components, etc... So I plan to build step by step: 1. An admin page 1.1. with basics commands '? la CMS Box' 1.2. Add layout and templates, etc... 2. An author page 2.1 Just edit/add/modify pages 2.2... 3. Public Site I don't know where or what I can modify into the code, into the objects, etc... And yes, I'm a little bit lost... Please heeeeelp meeee !! PS: I use Pharo 1.3 with ConfigurationOfSeaside and Pier2 scripts and manualy a set of commands like "PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel named: 'mykernel')."... Ed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Thu Sep 29 16:47:35 2011 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 29 Sep 2011 16:47:35 +0200 Subject: Custom CMS In-Reply-To: References: Message-ID: > PS: I use Pharo 1.3 with ConfigurationOfSeaside and Pier2 scripts and > manualy a set of commands like "PRPierFrame registerAsApplication: 'pier' > kernel: (PRKernel named: 'mykernel')."... You might want to use PRDistribution (from the package Pier-Setup) or one of its sub-classes, because this creates you a kernel that is already pre-configured in most parts. Lukas -- Lukas Renggli www.lukas-renggli.ch From garduino at gmail.com Fri Sep 30 02:13:35 2011 From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=) Date: Thu, 29 Sep 2011 21:13:35 -0300 Subject: Magritte and Morphic Message-ID: Sorry if I missed some announce, but, current versi?n of Magritte don't support anymore the building of Morphic UI's? Cheers. -- ================================================= Germ?n S. Arduino? ?? Twitter: garduino Arduino Software & Web Hosting?? http://www.arduinosoftware.com PasswordsPro? http://www.passwordspro.com ================================================= From tudor at tudorgirba.com Fri Sep 30 03:34:42 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Fri, 30 Sep 2011 03:34:42 +0200 Subject: Magritte and Morphic In-Reply-To: References: Message-ID: <85421063-68FA-4871-8CE5-E9E106E6E3B8@tudorgirba.com> Why do you say that? Glamour and Moose are using the Morphic rendering. Cheers, Doru On 30 Sep 2011, at 02:13, Germ?n Arduino wrote: > Sorry if I missed some announce, but, current versi?n of Magritte > don't support anymore the building of Morphic UI's? > > Cheers. > > -- > ================================================= > Germ?n S. Arduino Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "Presenting is storytelling." From garduino at gmail.com Fri Sep 30 03:45:59 2011 From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=) Date: Thu, 29 Sep 2011 22:45:59 -0300 Subject: Magritte and Morphic In-Reply-To: <85421063-68FA-4871-8CE5-E9E106E6E3B8@tudorgirba.com> References: <85421063-68FA-4871-8CE5-E9E106E6E3B8@tudorgirba.com> Message-ID: mm, because I tried today in an 1.3 image, and can't make work #asMorph (Can't get the widgets rendered). Will check better, thanks! Germ?n. 2011/9/29 Tudor Girba : > Why do you say that? > > Glamour and Moose are using the Morphic rendering. > > Cheers, > Doru > > > On 30 Sep 2011, at 02:13, Germ?n Arduino wrote: > >> Sorry if I missed some announce, but, current versi?n of Magritte >> don't support anymore the building of Morphic UI's? >> >> Cheers. >> >> -- >> ================================================= >> Germ?n S. Arduino ? ? Twitter: garduino >> Arduino Software & Web Hosting ? http://www.arduinosoftware.com >> PasswordsPro ?http://www.passwordspro.com >> ================================================= >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From tudor at tudorgirba.com Fri Sep 30 04:04:44 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Fri, 30 Sep 2011 04:04:44 +0200 Subject: Magritte and Morphic In-Reply-To: References: <85421063-68FA-4871-8CE5-E9E106E6E3B8@tudorgirba.com> Message-ID: <8E684FF2-CD58-43FA-96EA-8A53D95C0CBE@tudorgirba.com> Here is the image we use in Moose: http://ci.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/artifact/moose/*zip*/moose.zip It loads Magritte as well. Can you reproduce the problem there? Doru On 30 Sep 2011, at 03:45, Germ?n Arduino wrote: > mm, because I tried today in an 1.3 image, and can't make work > #asMorph (Can't get the widgets rendered). > > Will check better, thanks! > > Germ?n. > > 2011/9/29 Tudor Girba : >> Why do you say that? >> >> Glamour and Moose are using the Morphic rendering. >> >> Cheers, >> Doru >> >> >> On 30 Sep 2011, at 02:13, Germ?n Arduino wrote: >> >>> Sorry if I missed some announce, but, current versi?n of Magritte >>> don't support anymore the building of Morphic UI's? >>> >>> Cheers. >>> >>> -- >>> ================================================= >>> Germ?n S. Arduino Twitter: garduino >>> Arduino Software & Web Hosting http://www.arduinosoftware.com >>> PasswordsPro http://www.passwordspro.com >>> ================================================= >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com "We are all great at making mistakes." From garduino at gmail.com Fri Sep 30 04:17:55 2011 From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=) Date: Thu, 29 Sep 2011 23:17:55 -0300 Subject: Magritte and Morphic In-Reply-To: <8E684FF2-CD58-43FA-96EA-8A53D95C0CBE@tudorgirba.com> References: <85421063-68FA-4871-8CE5-E9E106E6E3B8@tudorgirba.com> <8E684FF2-CD58-43FA-96EA-8A53D95C0CBE@tudorgirba.com> Message-ID: Will try asap and will comment. Thanks Doru! 2011/9/29, Tudor Girba : > Here is the image we use in Moose: > http://ci.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/artifact/moose/*zip*/moose.zip > > It loads Magritte as well. > > Can you reproduce the problem there? > > Doru > > > > On 30 Sep 2011, at 03:45, Germ?n Arduino wrote: > >> mm, because I tried today in an 1.3 image, and can't make work >> #asMorph (Can't get the widgets rendered). >> >> Will check better, thanks! >> >> Germ?n. >> >> 2011/9/29 Tudor Girba : >>> Why do you say that? >>> >>> Glamour and Moose are using the Morphic rendering. >>> >>> Cheers, >>> Doru >>> >>> >>> On 30 Sep 2011, at 02:13, Germ?n Arduino wrote: >>> >>>> Sorry if I missed some announce, but, current versi?n of Magritte >>>> don't support anymore the building of Morphic UI's? >>>> >>>> Cheers. >>>> >>>> -- >>>> ================================================= >>>> Germ?n S. Arduino Twitter: garduino >>>> Arduino Software & Web Hosting http://www.arduinosoftware.com >>>> PasswordsPro http://www.passwordspro.com >>>> ================================================= >>>> >>>> _______________________________________________ >>>> Magritte, Pier and Related Tools ... >>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >>> -- >>> www.tudorgirba.com >>> >>> "Presenting is storytelling." >>> >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- ================================================= Germ?n S. Arduino Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================