Pier3 with latest Pillar?

What needs to be done to get Pier3 to use the latest Pillar code?

I think I've got it partly working with a few small changes. (an
isEmbedded method was missing, and PRFigure needed some changes).

Relevant slack discussion below.


Peter Meadows [6:45 AM]
I was trying to run Pier3

Max Leske [6:45 AM]
I assume that didn’t work as you had expected :slightly_smiling_face:

Peter Meadows [6:45 AM]
It half works

[6:46]
I can read pier pages but not edit them

Max Leske [6:47 AM]
Do you see a debugger?

Peter Meadows [6:47 AM]
when?

Max Leske [6:48 AM]
When you try to edit a page. Or does it just silently refuse to work?

Peter Meadows [6:49 AM]
it's silent

Max Leske [6:49 AM]
Hm.

[6:50]
Did you load Pier3 through the catalog as well?

Peter Meadows [6:51 AM]
but i had to change some things, and i might not have done it in the
best way. Because the newest pillar seems to make PRFigures when it
should used to make PRLinks .. or something. I don't really understand
it.

[6:52]
no. custom

[6:52]
the catalog uses an old version of pillar

[6:52]
i think

[6:55]
I had to change PRDocumentParser to PRPillarParser

Peter Meadows [7:00 AM]
and why does Magritte need seaside? I thought they made it completely
independent?

Max Leske [7:02 AM]
It doesn’t. As far as I can tell, the problem is somewhere between
Pier and Seaside.

[7:03]
When I try to load Pier I get exactly the same error as you but I can
load Seaside3 by itself without problems. This may possibly be a
Metacello bug.

[7:05]
Concerning pillar, you probably best ask Cyril Ferlicot. And for
trouble with Seaside / Pier it’s best to ask on the seaside mailing
list

Peter Meadows [7:08 AM]
ahh. well that might explain why it has been confusing/confounding me!

Peter Meadows [7:20 AM]
does Metacello not have a very verbose setting?

Stephan Eggermont [7:48 AM]
@anteater: Pillar forked from Pier and did not maintain compatibility.
I have not updated configurations for Pharo 6. Magritte and Seaside
are independent. Load the right metacello group to get a combination.

Stephan Eggermont [7:54 AM]
@anteater: just load Pier3 from the catalog and check the package
cache to see if what is loaded is what you expect. Without pharo6
tags, very old stuff gets loaded

Peter Meadows [7:56 AM]
Yes, but I wanted my Pier to use the latest pillar code. Surely that
was always the plan? It hasn't changed dramatically i think?

[7:57]
If it was actually a fork they would/should have changed the name!

Stephan Eggermont [12:43 PM]
@anteater it is definitely a fork with lots of breaking changes. No
compatibility

[12:46]
Pillar broke compatibility on purpose and  had zero interest in
keeping things working

[12:50]
ConfigurationOfMagritte3 load loads a default group, which is often
not what you want

Cyril Ferlicot [12:54 PM]
Is there a lot to change in Pillar/Pier to keep compatibility?

Pierce Ng [2:01 PM]
@cyrilferlicot the Pillar part of Pier has been taken out of Pier and
made standalone, so Pier has to be updated to use Pillar. i looked at
this a while back so maybe Pier has been kept updated.

Stephan Eggermont [2:49 PM]
@cyrilferlicot: flatten traits. Pier is cross-dialect. The other
things were easy, just breaking the build once a month

Cyril Ferlicot [2:51 PM]
Maybe when Pillar will move to github we will be able to do a Pharo
branch with trait and a flattened branch for cross dialects.

[2:52]
I think I broke a lot of compatibility during my internship but that
was not because I did not wanted to keep compatibility but more
because I did not knew the relation between Pillar and Pier. That was
the first time I contributed to a real project :slightly_smiling_face:

Stephan Eggermont [2:52 PM]
Should not be difficult. It just asks for some attention to downstream
consequences

Dimitris Chloupis [2:53 PM]
you are not the only one

[2:54]
even in the PBE we had half the files in pier extension and half with
pillar extension

Stephan Eggermont [3:06 PM]
@cyrilferlicot: I didn't assume you intended to break things.

Pierce Ng [4:07 PM]
my blog has switched to pillar. before it was shelling out to the
markdown executable called discount. so now the blog has one fewer
dependency. thank you for the standalone pillar.

Hi peter

I do not know but I would love that it would work. I should find some
time to do a new pass on pillar.

On my first todo:

     - fix use of DNU instead of plain magritte methods.

     - extract object out of the command line.

     - document, document and document.


Stef



Le 10/11/16 à 22:34, Peter H. Meadows via Pharo-users a écrit :

+1 from me, and would love to help where I can.

Hey. Can someone check this for me? In Pharo5 do:

Gofer new
    smalltalkhubUser: 'Pier' project: 'Pillar';
    configuration;
    loadDevelopment.

Gofer new
    url:'http://www.smalltalkhub.com/mc/phm/PierLoadExperiment/main';
    package: 'ConfigurationOfPierLoadExperiment';
    load.
((Smalltalk at: #ConfigurationOfPierLoadExperiment) project version:
#stable) load.

Gofer new
    url:'http://www.smalltalkhub.com/mc/phm/PierLoadExperimentChanges/main';
    package: 'ConfigurationOfPierLoadExperimentChanges';
    load.
((Smalltalk at: #ConfigurationOfPierLoadExperimentChanges) project
version: #stable) load.


ZnZincServerAdaptor startOn: 8080.

PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel
instanceNamed: 'pier').

(WAAdmin defaultDispatcher handlerAt: 'pier' ) exceptionHandler:
WADebugErrorHandler .


Then visit http://localhost:8080/pier
Does it work? Is it loading the right things? (I didn't check the
tests yet, and i don't really understand metacello or Pier, just
playing by trial and error :), but if it works, maybe someone with
more experience can turn it into a config that will load from catalog
in Pharo6. Thx.

On 11 November 2016 at 13:16, stepharo <[hidden email]> wrote:

+1 from me, and would love to help where I can.

It would be nice to see Pillar return to being a cross platform project as well. One of the beautiful things about Seaside/Magritte/Pier was it’s compatibility across many dialects of Smalltalk. The “develop in Pharo and deploy in GemStone” was a big draw for me :) One of my clients uses VW so it was great to have these projects there as well.

Yes but at the end of the day. You see we cannot work for free and in addition got constraints that are dragging us behind.

Pillar was refactored to use Traits and save duplication of (from memory) about 3 methods, but in doing so it became a Pharo-only project. I asked about this and found there wasn’t an interest in maintaining cross platform compatibility, so I saved a copy on git hub [1] and added a PRPillarGemstoneCodeTool class with a simple method for flattening the traits. My hope was being able to maintain a cross platform version of Pillar and keep Pier updated in a manageable way.

I will see if the trait usage make sense and can be removed. But you see if everything we do has to be compatible better be dead.
I would prefer to see GS having an infrastructure to load Pharo kernels. We are pushing the bootstrap for this reasons.
Because you see Pharo will use more and more slots because they are really really cool and powerful.

What do you do with Pillar? Because I write books, slides, and websites so this is an important piece of software for me.

Frustratingly, my work only allows me the occasional sprints in Smalltalk and without a Pier project to work on, I haven’t had the resources to keep it updated.

I’d like to see Pier get some love - it’s an awesome tool. How can I help?

[1] https://github.com/JupiterSmalltalk/Pillar

Join and hack.

On 12 Nov 2016, at 12:16 am, stepharo <[hidden email]> wrote:

Hi peter

I do not know but I would love that it would work. I should find some time to do a new pass on pillar.

On my first todo:

   - fix use of DNU instead of plain magritte methods.

   - extract object out of the command line.

   - document, document and document.


Stef



Le 10/11/16 à 22:34, Peter H. Meadows via Pharo-users a écrit :

Hey Stephane,

>> It would be nice to see Pillar return to being a cross platform project as well. One of the beautiful things about Seaside/Magritte/Pier was it’s compatibility across many dialects of Smalltalk. The “develop in Pharo and deploy in GemStone” was a big draw for me :) One of my clients uses VW so it was great to have these projects there as well.
> Yes but at the end of the day. You see we cannot work for free and in addition got constraints that are dragging us behind.

Absolutely! Luckily the hard work of cross-compatability has already been done for Pier. I’m just hoping we can keep the parts of Pillar on which Pier is reliant working across dialects - Pharo and GemStone at least. From memory, the only thing that made it hard was PRTParametrizable.

I imagine very few of us are being paid for the contributions we make. In my case, it’s only when I have a paid project that allows me to work in Smalltalk, that I can invest some of that paid time in contributing towards the packages I’m using for that project.

I also feel my smalltalk-ability isn’t up to the standard of so many of the amazing people contributing, which makes me a little reticent to get involved in the more complex projects.

> I will see if the trait usage make sense and can be removed. But you see if everything we do has to be compatible better be dead.

Maybe not a matter of code or die, but certainly a matter of style and most likely a commitment to more pain. it is (sometimes much) harder working with community projects since it takes working with that community -  and everyone has their own use case, and at least three opinions. :)

I’ve experienced this many time in non-software projects. It may take a little longer to get there, but it’s definitely worth the extra pain it in the end.

> I would prefer to see GS having an infrastructure to load Pharo kernels. We are pushing the bootstrap for this reasons.

Dale and the GemStone team are doing a great job moving towards that ideal. Their constraints are even greater since they have a large commercial install base supporting many platforms. We should be able to be more flexible and dynamic

> Because you see Pharo will use more and more slots because they are really really cool and powerful.
> What do you do with Pillar? Because I write books, slides, and websites so this is an important piece of software for me.

For me, Pillar was a package in Pier, and Pier was a tool that I used for all my presentations, prototyping, and small or short-lived community and not-for-profit projects.

>> I’d like to see Pier get some love - it’s an awesome tool. How can I help?
> Join and hack.

I’d love to! I noticed that the issue tracker and other Pillar related stuff is now on GitHub which is awesome. Is there any chance that the Smalltalk project could also move there? It would make it easier to fork and hack and make versions available to test before deciding what might be valuable pushed back to the core project.

Thanks for all your excellent work with Pillar - not to mention everything else!

Have fun!

Jupiter

>>> It would be nice to see Pillar return to being a cross platform project as well. One of the beautiful things about Seaside/Magritte/Pier was it’s compatibility across many dialects of Smalltalk. The “develop in Pharo and deploy in GemStone” was a big draw for me :) One of my clients uses VW so it was great to have these projects there as well.
>> Yes but at the end of the day. You see we cannot work for free and in addition got constraints that are dragging us behind.
> Absolutely! Luckily the hard work of cross-compatability has already been done for Pier. I’m just hoping we can keep the parts of Pillar on which Pier is reliant working across dialects - Pharo and GemStone at least. From memory, the only thing that made it hard was PRTParametrizable.
>
> I imagine very few of us are being paid for the contributions we make. In my case, it’s only when I have a paid project that allows me to work in Smalltalk, that I can invest some of that paid time in contributing towards the packages I’m using for that project.

Which packages?
> I also feel my smalltalk-ability isn’t up to the standard of so many of the amazing people contributing, which makes me a little reticent to get involved in the more complex projects.
You see fixing a comment or adding a test should be possible.
Don't hide yourself behind this argument.
>> I will see if the trait usage make sense and can be removed. But you see if everything we do has to be compatible better be dead.
> Maybe not a matter of code or die, but certainly a matter of style and most likely a commitment to more pain. it is (sometimes much) harder working with community projects since it takes working with that community -  and everyone has their own use case, and at least three opinions. :)
>
> I’ve experienced this many time in non-software projects. It may take a little longer to get there, but it’s definitely worth the extra pain it in the end.
>
>> I would prefer to see GS having an infrastructure to load Pharo kernels. We are pushing the bootstrap for this reasons.
> Dale and the GemStone team are doing a great job moving towards that ideal. Their constraints are even greater since they have a large commercial install base supporting many platforms.
Come on. Pharo too and we have far less ressources!!!

> We should be able to be more flexible and dynamic
>
>> Because you see Pharo will use more and more slots because they are really really cool and powerful.
>> What do you do with Pillar? Because I write books, slides, and websites so this is an important piece of software for me.
> For me, Pillar was a package in Pier, and Pier was a tool that I used for all my presentations, prototyping, and small or short-lived community and not-for-profit projects.
Ok then you can still use an old version of Pier and hope that others
will do what you want.
>>> I’d like to see Pier get some love - it’s an awesome tool. How can I help?
>> Join and hack.
> I’d love to! I noticed that the issue tracker and other Pillar related stuff is now on GitHub which is awesome. Is there any chance that the Smalltalk project could also move there? It would make it easier to fork and hack and make versions available to test before deciding what might be valuable pushed back to the core project.
Why easier? You cannot produce a slice?
Seriously I will not move pillar to github before Pharo has a fully
working solution.
And I will maintain pillar but I need time.

>
> Thanks for all your excellent work with Pillar - not to mention everything else!
>
> Have fun!
>
> Jupiter
>
>

For me, Pillar was a package in Pier, and Pier was a tool that I used for all my presentations, prototyping, and small or short-lived community and not-for-profit projects.

I do not get why you cannot use Pharo for that.

Hey Stephane,

It would be nice to see Pillar return to being a cross platform project as well. One of the beautiful things about Seaside/Magritte/Pier was it’s compatibility across many dialects of Smalltalk. The “develop in Pharo and deploy in GemStone” was a big draw for me :) One of my clients uses VW so it was great to have these projects there as well.

Yes but at the end of the day. You see we cannot work for free and in addition got constraints that are dragging us behind. 

Absolutely! Luckily the hard work of cross-compatability has already been done for Pier. I’m just hoping we can keep the parts of Pillar on which Pier is reliant working across dialects - Pharo and GemStone at least. From memory, the only thing that made it hard was PRTParametrizable.

I imagine very few of us are being paid for the contributions we make. In my case, it’s only when I have a paid project that allows me to work in Smalltalk, that I can invest some of that paid time in contributing towards the packages I’m using for that project.

I also feel my smalltalk-ability isn’t up to the standard of so many of the amazing people contributing, which makes me a little reticent to get involved in the more complex projects.

I will see if the trait usage make sense and can be removed. But you see if everything we do has to be compatible better be dead.

Maybe not a matter of code or die, but certainly a matter of style and most likely a commitment to more pain. it is (sometimes much) harder working with community projects since it takes working with that community -  and everyone has their own use case, and at least three opinions. :)

I’ve experienced this many time in non-software projects. It may take a little longer to get there, but it’s definitely worth the extra pain it in the end.

I would prefer to see GS having an infrastructure to load Pharo kernels. We are pushing the bootstrap for this reasons.

Dale and the GemStone team are doing a great job moving towards that ideal. Their constraints are even greater since they have a large commercial install base supporting many platforms. We should be able to be more flexible and dynamic

Because you see Pharo will use more and more slots because they are really really cool and powerful.
What do you do with Pillar? Because I write books, slides, and websites so this is an important piece of software for me. 

For me, Pillar was a package in Pier, and Pier was a tool that I used for all my presentations, prototyping, and small or short-lived community and not-for-profit projects.

I’d like to see Pier get some love - it’s an awesome tool. How can I help?

Join and hack. 

I’d love to! I noticed that the issue tracker and other Pillar related stuff is now on GitHub which is awesome. Is there any chance that the Smalltalk project could also move there? It would make it easier to fork and hack and make versions available to test before deciding what might be valuable pushed back to the core project.

Thanks for all your excellent work with Pillar - not to mention everything else!

Have fun!

Jupiter

On 15 November 2016 at 07:30, Peter H. Meadows
<[hidden email]> wrote:
Anyone check this? If it's correct, how do I get the changes into Pier?

Hi Peter,