May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Fun with pillar and mustache

by Cyril Ferlicot

Guille asked me to add some feature for that, I added it to the TODO list of Pillar but I don't have the time to do it now. On 21 May 2015 at 00:40, Norbert Hartl <norbert(a)hartl.name> wrote: > Good. I would be pleased if you could show me what you've done so far so I don't waste time on things already solved. > > Norbert > >> Am 21.05.2015 um 00:03 schrieb stepharo <stepharo(a)free.fr>: >> >> We did the same with guillermo but we are bullet profing the code before announcing it. >> >> Stef >> >> >> Le 20/5/15 21:45, Norbert Hartl a Ã©crit : >>> I've found some minutes today to play with pillar and mustache. I wanted to know how far I can go when doing some static site generation. The exercise was to simulate a page that has multiple components either in mustache or pillar format. I could do this >>> >>> | masterTemplate masterPillar masterDocument partialPillar partialTemplate finalPillar | >>> >>> masterTemplate := '<master> >>> <head>{{{title}}}</head> >>> <masterContent> >>> {{{content}}} >>> </masterContent> >>> </master>'. >>> >>> masterPillar := '{{title: This is the title of the master!}} >>> !masterheading >>> >>> This text is contained in the master pillar template >>> >>> {{{{{>phase2Template}}}}}'. >>> >>> partialPillar := '!{{{{{{title}}}}}} >>> >>> Some text in the partial template before the content... >>> >>> {{{{{{content}}}}}}} >>> >>> ... and after'. >>> >>> finalPillar := 'I''m a text in pillar format that was inserted in a partial mustache template generated from pillar that was inserted in a mustache master template in pillar format that was inserted in a master mustache template'. >>> >>> masterDocument := PRDocumentParser parse: masterPillar readStream. >>> >>> partialTemplate := PRHTMLWriter write: (PRDocumentParser parse: partialPillar readStream). >>> >>> phase1Result := masterTemplate asMustacheTemplate >>> value: masterDocument properties, { >>> 'content' -> (PRHTMLWriter write: masterDocument) } asDictionary. >>> >>> phase2Result := phase1Result asMustacheTemplate >>> value: { >>> 'title' -> 'A partial title'. >>> 'content' -> (PRHTMLWriter write: (PRDocumentParser parse: finalPillar readStream)) } asDictionary >>> partials: { >>> 'phase2Template' -> partialTemplate } asDictionary. >>> >>> and got >>> >>> <master> >>> <head>This is the title of the master!</head> >>> <masterContent> >>> <h1>masterheading</h1> >>> <p>This text is contained in the master pillar template</p> >>> <p><h1>A partial title</h1> >>> <p>Some text in the partial template before the content...</p> >>> <p><p>I'm a text in pillar format that was inserted in a partial mustache template generated from pillar that was inserted in a mustache master template in pillar format that was inserted in a master mustache template</p>}</p> >>> <p>... and after</p></p> >>> </masterContent> >>> </master> >>> >>> That is really cool. Actually pillar and mustache are a good match. >>> >>> FYI, >>> >>> Norbert >>> >>> >>> >>> >> >> > > -- Cheers Cyril Ferlicot

May 20, 2015

Re: [Pharo-users] Fun with pillar and mustache

by Norbert Hartl

Good. I would be pleased if you could show me what you've done so far so I don't waste time on things already solved. Norbert > Am 21.05.2015 um 00:03 schrieb stepharo <stepharo(a)free.fr>: > > We did the same with guillermo but we are bullet profing the code before announcing it. > > Stef > > > Le 20/5/15 21:45, Norbert Hartl a Ã©crit : >> I've found some minutes today to play with pillar and mustache. I wanted to know how far I can go when doing some static site generation. The exercise was to simulate a page that has multiple components either in mustache or pillar format. I could do this >> >> | masterTemplate masterPillar masterDocument partialPillar partialTemplate finalPillar | >> >> masterTemplate := '<master> >> <head>{{{title}}}</head> >> <masterContent> >> {{{content}}} >> </masterContent> >> </master>'. >> >> masterPillar := '{{title: This is the title of the master!}} >> !masterheading >> >> This text is contained in the master pillar template >> >> {{{{{>phase2Template}}}}}'. >> >> partialPillar := '!{{{{{{title}}}}}} >> >> Some text in the partial template before the content... >> >> {{{{{{content}}}}}}} >> >> ... and after'. >> >> finalPillar := 'I''m a text in pillar format that was inserted in a partial mustache template generated from pillar that was inserted in a mustache master template in pillar format that was inserted in a master mustache template'. >> >> masterDocument := PRDocumentParser parse: masterPillar readStream. >> >> partialTemplate := PRHTMLWriter write: (PRDocumentParser parse: partialPillar readStream). >> >> phase1Result := masterTemplate asMustacheTemplate >> value: masterDocument properties, { >> 'content' -> (PRHTMLWriter write: masterDocument) } asDictionary. >> >> phase2Result := phase1Result asMustacheTemplate >> value: { >> 'title' -> 'A partial title'. >> 'content' -> (PRHTMLWriter write: (PRDocumentParser parse: finalPillar readStream)) } asDictionary >> partials: { >> 'phase2Template' -> partialTemplate } asDictionary. >> >> and got >> >> <master> >> <head>This is the title of the master!</head> >> <masterContent> >> <h1>masterheading</h1> >> <p>This text is contained in the master pillar template</p> >> <p><h1>A partial title</h1> >> <p>Some text in the partial template before the content...</p> >> <p><p>I'm a text in pillar format that was inserted in a partial mustache template generated from pillar that was inserted in a mustache master template in pillar format that was inserted in a master mustache template</p>}</p> >> <p>... and after</p></p> >> </masterContent> >> </master> >> >> That is really cool. Actually pillar and mustache are a good match. >> >> FYI, >> >> Norbert >> >> >> >> > >

May 20, 2015

Re: [Pharo-users] Fun with pillar and mustache

by stepharo

We did the same with guillermo but we are bullet profing the code before announcing it. Stef Le 20/5/15 21:45, Norbert Hartl a Ã©crit : > I've found some minutes today to play with pillar and mustache. I wanted to know how far I can go when doing some static site generation. The exercise was to simulate a page that has multiple components either in mustache or pillar format. I could do this > > | masterTemplate masterPillar masterDocument partialPillar partialTemplate finalPillar | > > masterTemplate := '<master> > <head>{{{title}}}</head> > <masterContent> > {{{content}}} > </masterContent> > </master>'. > > masterPillar := '{{title: This is the title of the master!}} > !masterheading > > This text is contained in the master pillar template > > {{{{{>phase2Template}}}}}'. > > partialPillar := '!{{{{{{title}}}}}} > > Some text in the partial template before the content... > > {{{{{{content}}}}}}} > > ... and after'. > > finalPillar := 'I''m a text in pillar format that was inserted in a partial mustache template generated from pillar that was inserted in a mustache master template in pillar format that was inserted in a master mustache template'. > > masterDocument := PRDocumentParser parse: masterPillar readStream. > > partialTemplate := PRHTMLWriter write: (PRDocumentParser parse: partialPillar readStream). > > phase1Result := masterTemplate asMustacheTemplate > value: masterDocument properties, { > 'content' -> (PRHTMLWriter write: masterDocument) } asDictionary. > > phase2Result := phase1Result asMustacheTemplate > value: { > 'title' -> 'A partial title'. > 'content' -> (PRHTMLWriter write: (PRDocumentParser parse: finalPillar readStream)) } asDictionary > partials: { > 'phase2Template' -> partialTemplate } asDictionary. > > and got > > <master> > <head>This is the title of the master!</head> > <masterContent> > <h1>masterheading</h1> > <p>This text is contained in the master pillar template</p> > <p><h1>A partial title</h1> > <p>Some text in the partial template before the content...</p> > <p><p>I'm a text in pillar format that was inserted in a partial mustache template generated from pillar that was inserted in a mustache master template in pillar format that was inserted in a master mustache template</p>}</p> > <p>... and after</p></p> > </masterContent> > </master> > > That is really cool. Actually pillar and mustache are a good match. > > FYI, > > Norbert > > > >

May 20, 2015

Fun with pillar and mustache

by Norbert Hartl

I've found some minutes today to play with pillar and mustache. I wanted to know how far I can go when doing some static site generation. The exercise was to simulate a page that has multiple components either in mustache or pillar format. I could do this | masterTemplate masterPillar masterDocument partialPillar partialTemplate finalPillar | masterTemplate := '<master> <head>{{{title}}}</head> <masterContent> {{{content}}} </masterContent> </master>'. masterPillar := '{{title: This is the title of the master!}} !masterheading This text is contained in the master pillar template {{{{{>phase2Template}}}}}'. partialPillar := '!{{{{{{title}}}}}} Some text in the partial template before the content... {{{{{{content}}}}}}} ... and after'. finalPillar := 'I''m a text in pillar format that was inserted in a partial mustache template generated from pillar that was inserted in a mustache master template in pillar format that was inserted in a master mustache template'. masterDocument := PRDocumentParser parse: masterPillar readStream. partialTemplate := PRHTMLWriter write: (PRDocumentParser parse: partialPillar readStream). phase1Result := masterTemplate asMustacheTemplate value: masterDocument properties, { 'content' -> (PRHTMLWriter write: masterDocument) } asDictionary. phase2Result := phase1Result asMustacheTemplate value: { 'title' -> 'A partial title'. 'content' -> (PRHTMLWriter write: (PRDocumentParser parse: finalPillar readStream)) } asDictionary partials: { 'phase2Template' -> partialTemplate } asDictionary. and got <master> <head>This is the title of the master!</head> <masterContent> <h1>masterheading</h1> <p>This text is contained in the master pillar template</p> <p><h1>A partial title</h1> <p>Some text in the partial template before the content...</p> <p><p>I'm a text in pillar format that was inserted in a partial mustache template generated from pillar that was inserted in a mustache master template in pillar format that was inserted in a master mustache template</p>}</p> <p>... and after</p></p> </masterContent> </master> That is really cool. Actually pillar and mustache are a good match. FYI, Norbert

May 20, 2015

Re: [Pharo-users] Spec TreeModel dynamic contents

by Thierry Goubier

Hi, I believe that you need to work a bit more at the Morphic level; MorphTreeMorph and MorphTreeNodeMorph have everything you need. The problem seems to be in the way Spec provides an API for those features (or does not provide an API). Regards, Thierry Le 20/05/2015 20:28, Nicolai Hess a Ã©crit : > > > 2015-05-19 18:04 GMT+02:00 webwarrior <reg(a)webwarrior.ws > <mailto:reg@webwarrior.ws>>: > > I want to make a tree using TreeModel that reacts to changes in > underlying > data - when an item changes, tree node for that item should update > its state > (recompute its children, etc.). > > Rebuilding the whole tree is ok, as long as selections and > collapsed/expanded state of nodes are preserved. > > Using #updateTree however resets all these things. And there is no > easy way > to save/load them either - #selectedItems/#selectedItems: work with > TreeNode > instances that get reset, and collapsed/expanded states of nodes are > simply > unaccessible from TreeModel. > > I also tried subclassing TreeNodeModel. But I found no way to update > underlying UI widget. There is a huge mess involving TreeNodeModel, > MorphicTreeNodeAdapter, SpecTreeNodeModel, and MorphTreeNodeMorph. > > The only option left is to extract all needed information from > TreeNodeModel > hierarchy (preserving the tree structure) before update, and then try to > reapply it to newly created hierarchy. > > Or is there an easier way? > > > Not that I know of. I tried to change PharoLauncher to reselect the > current item if you rename or recreate > an image. But I could not find a way :( > > > > -- > View this message in context: > http://forum.world.st/Spec-TreeModel-dynamic-contents-tp4827440.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

May 20, 2015

Re: [Pharo-users] Spec TreeModel dynamic contents

by Nicolai Hess

2015-05-19 18:04 GMT+02:00 webwarrior <reg(a)webwarrior.ws>: > I want to make a tree using TreeModel that reacts to changes in underlying > data - when an item changes, tree node for that item should update its > state > (recompute its children, etc.). > > Rebuilding the whole tree is ok, as long as selections and > collapsed/expanded state of nodes are preserved. > > Using #updateTree however resets all these things. And there is no easy way > to save/load them either - #selectedItems/#selectedItems: work with > TreeNode > instances that get reset, and collapsed/expanded states of nodes are simply > unaccessible from TreeModel. > > I also tried subclassing TreeNodeModel. But I found no way to update > underlying UI widget. There is a huge mess involving TreeNodeModel, > MorphicTreeNodeAdapter, SpecTreeNodeModel, and MorphTreeNodeMorph. > > The only option left is to extract all needed information from > TreeNodeModel > hierarchy (preserving the tree structure) before update, and then try to > reapply it to newly created hierarchy. > > Or is there an easier way? > > Not that I know of. I tried to change PharoLauncher to reselect the current item if you rename or recreate an image. But I could not find a way :( > > > -- > View this message in context: > http://forum.world.st/Spec-TreeModel-dynamic-contents-tp4827440.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

May 20, 2015

Re: [Pharo-users] Alt-tab between windows

by Andrei Chis

On Wed, May 20, 2015 at 5:13 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Wed, May 20, 2015 at 11:04 PM, Avdi Grimm <avdi(a)avdi.org> wrote: > >> >> On Wed, May 20, 2015 at 10:19 AM, Esteban A. Maringolo < >> emaringolo(a)gmail.com> wrote: >> >>> >>> Regarding a tab based environment, Dolphin X6 also included that in a >>> concept called "Idea Space", you can open as many idea spaces as you want, >>> and as you browse classes, inspect objects or look for references, all the >>> usual new windows will open inside the idea space where the command was >>> issued. There also was the option to save the open tabs, to restore them >>> later. And you could move between tabs using only the keyboard; in fact you >>> could do everything without a mouse. >>> >> >> For the record, I find tabs to be almost as much of a UI dead-end as >> myriad windows. They are often incompatible with the need to see several >> things at once, and they become unmanageable past a dozen or so. >> >> Personally I prefer environments where the number of windows/tabs/buffers >> is a non-issue, something managed by the environment. All I care about is: >> >> a) Navigating back and forth between the thing I'm looking at now and the >> last ~10 things I looked at; and >> b) Quickly finding and foregrounding new things by whatever searchable >> aspect I can remember about them. >> >> > GTSpotter has a "history" category (not that I've used it so far, perhaps > time to try). > > It might be an interesting experiment for GTSpotter to have an "open > window" category. > Interesting idea. Could be easily done :) Cheers, Andrei > > cheers -ben >

May 20, 2015

Re: [Pharo-users] Alt-tab between windows

by Ben Coman

On Wed, May 20, 2015 at 11:04 PM, Avdi Grimm <avdi(a)avdi.org> wrote: > > On Wed, May 20, 2015 at 10:19 AM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> >> Regarding a tab based environment, Dolphin X6 also included that in a >> concept called "Idea Space", you can open as many idea spaces as you want, >> and as you browse classes, inspect objects or look for references, all the >> usual new windows will open inside the idea space where the command was >> issued. There also was the option to save the open tabs, to restore them >> later. And you could move between tabs using only the keyboard; in fact you >> could do everything without a mouse. >> > > For the record, I find tabs to be almost as much of a UI dead-end as > myriad windows. They are often incompatible with the need to see several > things at once, and they become unmanageable past a dozen or so. > > Personally I prefer environments where the number of windows/tabs/buffers > is a non-issue, something managed by the environment. All I care about is: > > a) Navigating back and forth between the thing I'm looking at now and the > last ~10 things I looked at; and > b) Quickly finding and foregrounding new things by whatever searchable > aspect I can remember about them. > > GTSpotter has a "history" category (not that I've used it so far, perhaps time to try). It might be an interesting experiment for GTSpotter to have an "open window" category. cheers -ben

May 20, 2015

OpenCL problems since we switch to OS X 10.10.3

by Serge Stinckwich

Hi Ronie, since we switch here from OS X 10.10.2 to 10.10.3, your OpenCL framework doesn't not work anymore ... We crash Pharo everytime we try to use GPU. This is an except of the crash log: Process: Pharo [21039] Path: /Applications/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: Pharo 0.2.7-2015.04.20 (21.0) Code Type: X86 (Native) Parent Process: ??? [1] Responsible: Pharo [21039] User ID: 502 Date/Time: 2015-05-20 16:50:33.740 +0200 OS Version: Mac OS X 10.10.3 (14D136) Report Version: 11 Anonymous UUID: 53101D99-4009-6151-7D46-D4F943A588CF Sleep/Wake UUID: D65CFFA9-9DD4-490B-99A5-D5A3F37C8649 Time Awake Since Boot: 240000 seconds Time Since Wake: 19000 seconds Crashed Thread: 0 Dispatch queue: opencl_runtime Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 What can we do ? Apparently this is difficult to downgrade back to 10.10.2 Regards -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

May 20, 2015

Re: [Pharo-users] Alt-tab between windows

by Avdi Grimm

On Wed, May 20, 2015 at 10:19 AM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > > Regarding a tab based environment, Dolphin X6 also included that in a > concept called "Idea Space", you can open as many idea spaces as you want, > and as you browse classes, inspect objects or look for references, all the > usual new windows will open inside the idea space where the command was > issued. There also was the option to save the open tabs, to restore them > later. And you could move between tabs using only the keyboard; in fact you > could do everything without a mouse. > For the record, I find tabs to be almost as much of a UI dead-end as myriad windows. They are often incompatible with the need to see several things at once, and they become unmanageable past a dozen or so. Personally I prefer environments where the number of windows/tabs/buffers is a non-issue, something managed by the environment. All I care about is: a) Navigating back and forth between the thing I'm looking at now and the last ~10 things I looked at; and b) Quickly finding and foregrounding new things by whatever searchable aspect I can remember about them. I don't want to think or care about how many old things I once looked at the environment keeps open; it is welcome to manage that on its own. Incidentally, this is exactly what it's like to use RubyMine with tabs turned off. I can navigate backwards and forwards through history, and I can find things by name, and it worries about how many buffers to keep open in the background. If I go "back" to a buffer it has closed, it re-opens it. This is complemented by the fact that it auto-saves. Having high-quality "Undo" is far more important than manually controlling when things are saved, in my experience. In the RubyMine case, it is able to visually show and undo every change that has been made since the last Git commit. -- Avdi Grimm http://avdi.org

May 20, 2015