subject:"Re\: \[Pharo\-users\] why Pillar"

On Pon, 2015-12-28 at 21:41 -0500, Offray Vladimir Luna Cárdenas wrote:

> Skeletons go beyond themes (grav also have them). They're like 
> mini-sites ready to be filled out with your own content.

Like demo-sites or with empty slots to add content?

> The fact that I don't need to compile the site to see the output.
> Nikola have implemented something like that, but is not the default
> behavior.

I know about live-reload which is present in Nikola - not sure about
Ecstatic, but I do not expect more from static-site-generator.

> Interactivity as a default is what makes me so happy with 
> Pharo/Smalltalk :-).

Well, that's another world. ;)

Sincerely,
Gour

-- 
For him who has conquered the mind, the mind is the best of 
friends; but for one who has failed to do so, his mind will 
remain the greatest enemy.

Re: [Pharo-users] why Pillar




On 28/12/15 13:28, Saša Janiška wrote:

On Pon, 2015-12-28 at 11:09 -0500, Offray Vladimir Luna Cárdenas wrote:


but themes, skeletons and interactivity. (Details in the referred blog
post).

I agree that there could be more themes available, although I'm not 100%
sure I understand what is special about grav's skeleton's since it seems
to me that such things are usually part of Nikola's theme. In any case,
I understand that having larger choice to srart with is nice.


Skeletons go beyond themes (grav also have them). They're like 
mini-sites ready to be filled out with your own content.



What do you mean by interactivity?


The fact that I don't need to compile the site to see the output. Nikola 
have implemented something like that, but is not the default behavior. 
Interactivity as a default is what makes me so happy with 
Pharo/Smalltalk :-).


Cheers,

Offray

Re: [Pharo-users] why Pillar




On 28/12/15 17:05, stepharo wrote:


Yes, that is true. That is a cost of a smaller community. But the 
problem here is that your solution creates a self fulfilling 
situation. If everybody who comes to Pharo is encouraged to use tools 
outside of Pharo rather than using, improving and extending the tools 
in Pharo. Then the community is working against itself. And the tools 
never reach what the person was wanting to use.


+1


-1 with explanation ;-) :

I don't think this will be the necessary case more if Pharo is a long 
term game. Pharo needs to work better with the external world. It's 
already trying to make that with Git and the abstracting the DVCS layer, 
its putting tools like fossil in the radar. I don't think that making 
the same for flat file web site generators (static like Nikola or 
dynamic like grav) and light markup and data serialization languages is 
different that trying to work better with flat file source code 
management systems or that is having the community working against 
itself. I have proposed a long/mid term game by using Asbtract Syntax 
Trees to work better with Pandoc. Trying to not reinvet git/fossil 
inside Pharo is a good thing the community and doesn't preclude the use 
and improvement of Monticello. Trying to not reinvet grav/nikola/pandoc 
inside Pharo its also a good think and doesn't preclude esctatic/pillar 
exploration and improvement, but in a long term game playing well with 
others with different combinations could be wiser.




Pharo will improve more at a minimum if the people who love Pharo use 
Pharo to scratch their itches and use Pharo to create the tools to 
scratch their itches. If we continually look outside, we might as 
well go outside. Pharo is more like an operating system/environment 
than a simple language. More like Linux/Unix and C/Python, than C or 
Python alone. We prefer our tools to be written native to our 
environment rather than external to it. It is different that Python, 
Ruby, Lua, PHP or whatever.


There are so many advantages to using tools in Pharo when using 
Pharo. Since Pharo is a full environment on top of any OS, it is 
exceptionally portable. Put it in a folder on a flash drive with 
appropriate VMs and off you go.


It is also so easy to simply snapshot where you are to save your 
state in development or exploration of a problem. So many things that 
are easy in Pharo that are difficult, hard or near impossible to do 
elsewhere.



I understand that, and the dynamic nature of the environment makes that 
"reinvention" inside it to make a lot of sense because we have the 
interactivity we're used to. But that doesn't preclude playing well with 
others (including other languages, frameworks and tools) without meaning 
that we will go outside for everything and leave Pharo as a ghost town 
(it doesn't happen with DVCS like git).




If Pharo users were to drop Pillar and begin to use Pandoc, then we 
be using tools that we have no control over and tools that we are 
likely not to contribute to development of. If we then had an need 
which is not met by the tools, then what do we do? Do we now adopt 
yet another language, environment, editor, ... in order to meet that 
need? That is fine for people whose preferred environment and toolset 
is so defined. But that is not the preferred way in Pharo (or 
Smalltalk).




Same applies for git and nobody is talking about a self fulfilling 
prophesy here.


Pharo is a long game tool. We are happy to grow it slow, steady and 
stable. We are happy to have more and more help to do so. We want to 
grow Pharo and its tools. Not Pandoc, Python and their tools. They 
are able to take care of themselves. I want to be using the evolving 
Pharo environment and tools not just now, but in 10 years, in 20 
years. I see no other tools (outside of the Smalltalk world) that 
have this kind of vision. This is best served by contributing to the 
environment and the tools in Pharo. Rather than doing what might be 
expedient in the here and now. It affects my here and nows in the 
future in a more profitable and productive way.


+1


+-1. Fortunately this is a diverse community where making pharo better 
doesn't imply it will not work fine with other languages, frameworks, 
cultures: See ephestos and bridges with python/blender, FileTree and 
bridges with git or grafoscopio and bridges with pandoc.




Now there are times when venturing outside of Pharo is required. And 
when that time occurs, we need to be exceptionally well able to do 
so. And I see great hope on that front.


But when we do not need to venture outside of Pharo. Those of us who 
believe in the vision of Pharo are much more highly advantaged by 
contributing to the tools in this community. Than to looks outside 
the community for tools which my momentarily meet a need.




That moment is different for each of us. I need footnotes and 
bibliographic references and integration with zotero now. Pandoc gives 
me that and Pillar doesn

Re: [Pharo-users] why Pillar

2015-12-28 Thread stepharo



Yes, that is true. That is a cost of a smaller community. But the 
problem here is that your solution creates a self fulfilling 
situation. If everybody who comes to Pharo is encouraged to use tools 
outside of Pharo rather than using, improving and extending the tools 
in Pharo. Then the community is working against itself. And the tools 
never reach what the person was wanting to use.


+1


Pharo will improve more at a minimum if the people who love Pharo use 
Pharo to scratch their itches and use Pharo to create the tools to 
scratch their itches. If we continually look outside, we might as well 
go outside. Pharo is more like an operating system/environment than a 
simple language. More like Linux/Unix and C/Python, than C or Python 
alone. We prefer our tools to be written native to our environment 
rather than external to it. It is different that Python, Ruby, Lua, 
PHP or whatever.


There are so many advantages to using tools in Pharo when using Pharo. 
Since Pharo is a full environment on top of any OS, it is 
exceptionally portable. Put it in a folder on a flash drive with 
appropriate VMs and off you go.


It is also so easy to simply snapshot where you are to save your state 
in development or exploration of a problem. So many things that are 
easy in Pharo that are difficult, hard or near impossible to do 
elsewhere.


If Pharo users were to drop Pillar and begin to use Pandoc, then we be 
using tools that we have no control over and tools that we are likely 
not to contribute to development of. If we then had an need which is 
not met by the tools, then what do we do? Do we now adopt yet another 
language, environment, editor, ... in order to meet that need? That is 
fine for people whose preferred environment and toolset is so defined. 
But that is not the preferred way in Pharo (or Smalltalk).


Pharo is a long game tool. We are happy to grow it slow, steady and 
stable. We are happy to have more and more help to do so. We want to 
grow Pharo and its tools. Not Pandoc, Python and their tools. They are 
able to take care of themselves. I want to be using the evolving Pharo 
environment and tools not just now, but in 10 years, in 20 years. I 
see no other tools (outside of the Smalltalk world) that have this 
kind of vision. This is best served by contributing to the environment 
and the tools in Pharo. Rather than doing what might be expedient in 
the here and now. It affects my here and nows in the future in a more 
profitable and productive way.


+1


Now there are times when venturing outside of Pharo is required. And 
when that time occurs, we need to be exceptionally well able to do so. 
And I see great hope on that front.


But when we do not need to venture outside of Pharo. Those of us who 
believe in the vision of Pharo are much more highly advantaged by 
contributing to the tools in this community. Than to looks outside the 
community for tools which my momentarily meet a need.


I think adding footnotes to Pillar is a great idea. I am not ready to 
do so. I am not a qualified Pillar user yet. But when I am, I would 
not hesitate to add it to Pillar and improve the tool of the 
environment I prefer to use.


Just my 2 cents. It is worth what you paid for it. :)

Shalom.

Jimmie

Re: [Pharo-users] why Pillar

On Pon, 2015-12-28 at 12:19 -0600, Jimmie Houchin wrote:

> There are so many advantages to using tools in Pharo when using
> Pharo. 

I agree with it and that's why I asked what might be some advantages of
using Pillar as documentation tool.

> Do we now adopt yet another  language, environment, editor, ... in
> order to meet that need? That is  fine for people whose preferred
> environment and toolset is so defined.  But that is not the preferred
> way in Pharo (or Smalltalk).

I believe you understand it's not feasible to have *every* required tool
available within Pharo...in my case if Pillar shows it's capable enough
to replace need for using rst, I'll be enthusiastic to embrace it.

Otoh, considering that I'm just starting/learning Pharo, it's obvious
I'm accustomed to use *many* other tools which do the job.

So, being able to use *single* markup for all my writing is clearly
advantageous since it spares me from 'changing gears' in a similar way
that the upcoming feature in Fossil DVCS will allow one to sync with
Git(hub) repositories - no more need to fiddle with Git and focusing
solely to Fossil.

The end result as Richard (Hipp) wrote and, I believe, what I heard from
Stef on one of his presentations is that less brain cpu cells/cycles are
burnt which is always good. :-)

> I think adding footnotes to Pillar is a great idea. I am not ready to
> do 
> so. I am not a qualified Pillar user yet. But when I am, I would not 
> hesitate to add it to Pillar and improve the tool of the environment
> I 
> prefer to use.

I am neither Pillar nor Pharo-qualified user, but share the same
sentiments in regard. ;)

Sincerely,
Gour

-- 
Therefore, without being attached to the fruits of activities, 
one should act as a matter of duty, for by working without 
attachment one attains the Supreme.

Re: [Pharo-users] why Pillar

On Pon, 2015-12-28 at 18:03 +0100, stepharo wrote:

Hello Stef,

> have a look at Pillar and you can add footnotes and we will review
> your code and integrate it.

Don't you think it's too early for me to add such feature. ;)

> We are just really busy right now.

Don't worry. I tried Pillar, but I can live with using rst at the moment
and if find that Pharo/Pillar might be more productive environment when
it comes to the docs, I'll gladly take a look how to do it.

For now, I agree, there are more important issues and I'm really looking
forward to use Spur-based VM as well as 64 bits.

Sincerely,
Gour

-- 
A person is considered still further advanced when he regards honest 
well-wishers, affectionate benefactors, the neutral, mediators, the envious, 
friends and enemies, the pious and the sinners all with an equal mind.

Re: [Pharo-users] why Pillar

On Pon, 2015-12-28 at 11:09 -0500, Offray Vladimir Luna Cárdenas wrote:

> but themes, skeletons and interactivity. (Details in the referred blog
> post).

I agree that there could be more themes available, although I'm not 100%
sure I understand what is special about grav's skeleton's since it seems
to me that such things are usually part of Nikola's theme. In any case,
I understand that having larger choice to srart with is nice.

What do you mean by interactivity?

Otherwise, Nikola is getting nice new feature called 'shortcode' (same
as Hugo)
which allows to pack different functionality and call it via simple
'shorcode'.

> I used Leo for several years, but nothing beats for me the
interactivity  and
> modifiability of a live coding environment like Pharo/Rossal.

I'm just starting, but it looks great, indeed. ;)

Sincerely,
Gour

-- 
Everyone is forced to act helplessly according to the qualities 
he has acquired from the modes of material nature; therefore no 
one can refrain from doing something, not even for a moment.

Re: [Pharo-users] why Pillar

2015-12-28 Thread Jimmie Houchin




On 12/28/2015 09:21 AM, Offray Vladimir Luna Cárdenas wrote:

b. It has support for bibliographic references, footnotes a a more
complete feature set.

I wonder how is it that despite being present for so long, it does miss
such features...


Well that's the cost of being part of a small community where not all 
the projects can be developed beyond the interest and limitations of 
few members. And that's why interaction with broader communities (for 
example pandoc's one could be wise).


Yes, that is true. That is a cost of a smaller community. But the 
problem here is that your solution creates a self fulfilling situation. 
If everybody who comes to Pharo is encouraged to use tools outside of 
Pharo rather than using, improving and extending the tools in Pharo. 
Then the community is working against itself. And the tools never reach 
what the person was wanting to use.


Pharo will improve more at a minimum if the people who love Pharo use 
Pharo to scratch their itches and use Pharo to create the tools to 
scratch their itches. If we continually look outside, we might as well 
go outside. Pharo is more like an operating system/environment than a 
simple language. More like Linux/Unix and C/Python, than C or Python 
alone. We prefer our tools to be written native to our environment 
rather than external to it. It is different that Python, Ruby, Lua, PHP 
or whatever.


There are so many advantages to using tools in Pharo when using Pharo. 
Since Pharo is a full environment on top of any OS, it is exceptionally 
portable. Put it in a folder on a flash drive with appropriate VMs and 
off you go.


It is also so easy to simply snapshot where you are to save your state 
in development or exploration of a problem. So many things that are easy 
in Pharo that are difficult, hard or near impossible to do elsewhere.


If Pharo users were to drop Pillar and begin to use Pandoc, then we be 
using tools that we have no control over and tools that we are likely 
not to contribute to development of. If we then had an need which is not 
met by the tools, then what do we do? Do we now adopt yet another 
language, environment, editor, ... in order to meet that need? That is 
fine for people whose preferred environment and toolset is so defined. 
But that is not the preferred way in Pharo (or Smalltalk).


Pharo is a long game tool. We are happy to grow it slow, steady and 
stable. We are happy to have more and more help to do so. We want to 
grow Pharo and its tools. Not Pandoc, Python and their tools. They are 
able to take care of themselves. I want to be using the evolving Pharo 
environment and tools not just now, but in 10 years, in 20 years. I see 
no other tools (outside of the Smalltalk world) that have this kind of 
vision. This is best served by contributing to the environment and the 
tools in Pharo. Rather than doing what might be expedient in the here 
and now. It affects my here and nows in the future in a more profitable 
and productive way.


Now there are times when venturing outside of Pharo is required. And 
when that time occurs, we need to be exceptionally well able to do so. 
And I see great hope on that front.


But when we do not need to venture outside of Pharo. Those of us who 
believe in the vision of Pharo are much more highly advantaged by 
contributing to the tools in this community. Than to looks outside the 
community for tools which my momentarily meet a need.


I think adding footnotes to Pillar is a great idea. I am not ready to do 
so. I am not a qualified Pillar user yet. But when I am, I would not 
hesitate to add it to Pillar and improve the tool of the environment I 
prefer to use.


Just my 2 cents. It is worth what you paid for it. :)

Shalom.

Jimmie

Re: [Pharo-users] why Pillar

2015-12-28 Thread stepharo


Saša

have a look at Pillar and you can add footnotes and we will review your 
code and integrate it.

We are just really busy right now.

Stef

Re: [Pharo-users] why Pillar


Hi,

On 28/12/15 10:43, Saša Janiška wrote:

On Pon, 2015-12-28 at 10:21 -0500, Offray Vladimir Luna Cárdenas wrote:


That's why I recommending you pandoc's markdown variant. It has
extensive support for footnotes, bibliographic references, tables,
latex, a lot of exporting formats and extensibility via exporting and
manipulating the Abstract Syntax Tree. Pandoc is also used in
Scholarly  markdown and Jupyter projects so you could use the markup
language  variant with more people beyond this community.

But you're aware that you can also use Pandoc's markdown with Nikola?


Yes. I'm but if you read the blog post, you'll see that the main reason 
for choosing grav for almost everything else and Nikola for self hosted 
Jupyter/IPython noteboks is not the lack of support for pandoc, but 
themes, skeletons and interactivity. (Details in the referred blog post).



.

and then Leo Editor[4].


I tried that, but, for some reason, it was not compelling-enough to
switch...


I used Leo for several years, but nothing beats for me the interactivity 
and modifiability of a live coding environment like Pharo/Rossal.


Cheers,

Offray

Re: [Pharo-users] why Pillar

On Pon, 2015-12-28 at 10:21 -0500, Offray Vladimir Luna Cárdenas wrote:

> That's why I recommending you pandoc's markdown variant. It has 
> extensive support for footnotes, bibliographic references, tables, 
> latex, a lot of exporting formats and extensibility via exporting and 
> manipulating the Abstract Syntax Tree. Pandoc is also used in
> Scholarly  markdown and Jupyter projects so you could use the markup
> language  variant with more people beyond this community.

But you're aware that you can also use Pandoc's markdown with Nikola?

> Did you mean this:
> 
> http://practicaltypography.com/why-racket-why-lisp.html

Yes.

>and then Leo Editor[4]. 


I tried that, but, for some reason, it was not compelling-enough to
switch...


Sincerely,
Gour

-- 
What is night for all beings is the time of awakening 
for the self-controlled; and the time of awakening for 
all beings is night for the introspective sage.

Re: [Pharo-users] why Pillar

Hi,

On 28/12/15 06:16, Saša Janiška wrote:

On Ned, 2015-12-27 at 18:50 -0500, Offray Vladimir Luna Cárdenas wrote:

Hiya,

Seems that the reasons exposed in this tread are: It predated
markdown, so was already used inside the community, and gives us
finer control on the overall markup language, including exporting
formats.

Nothing against it, but some features like footnotes are simply 'must'
for serious writing, at least in my domain.

Yes, that's why I use pandoc's markdown.

Two projects implement this idea Pandoc[2]

Yeah, Pandoc is great and it would be cool to have Pillar support for
it.

You could extend it via Abstract Syntax Trees with Pharo.

and Grav[3] and both use a combination of markdown and yaml.

Grav looks interesting, but I believe I simply want to leave PHP world.
:-)

I did for a lot of time, barely touching anything php related and, as I
said in the blog post about Nikola and Grav[1], I dislike the php syntax
and pragmatics. But this doesn't prevent the acknowledge and eventual
use of really good solutions made on php like dokuwiki, Question2Answer
and Grav. What I'm trying to do is to communicate with this solutions
without touching too much the php part, just using more standard formats
like Json, cvs, markdown and yaml.

[1] http://mutabit.com/offray/blog/es/entry/2015-10-06-grav-nikola-both

My bet is on pandoc (markdown+yaml) for writing almost anything, with
some advantages over pillar:

My main complaint to markdown is that it is not standard, despite many
attempts (or extensions).

That's why I recommending you pandoc's markdown variant. It has
extensive support for footnotes, bibliographic references, tables,
latex, a lot of exporting formats and extensibility via exporting and
manipulating the Abstract Syntax Tree. Pandoc is also used in Scholarly
markdown and Jupyter projects so you could use the markup language
variant with more people beyond this community.

b. It has support for bibliographic references, footnotes a a more
complete feature set.

I wonder how is it that despite being present for so long, it does miss
such features...

Well that's the cost of being part of a small community where not all
the projects can be developed beyond the interest and limitations of few
members. And that's why interaction with broader communities (for
example pandoc's one could be wise).

Have you considered to use Pillar markup with Nikola? That's one
option I'm considering if Pillar is going to get things liek footnotes
etc.

No. As I said in the previous referred blog post I will use Nikola for
self hosted IPython/Jupyter notebooks and Grav mostly everywhere in web
publishing. Using padoc's markdown as the default format gives me a lot
of interoperability between documentation systems. My bet for mixing
pharo related developments and pandoc is via the Abstract Syntax Tree
manipulations... at some point.

Ecstatic have more powerful things like a logic-less
approach to templating via mustache, that is neutral to the
underlaying language

That would be another 'pro' for Pillar markup+Nikola, although I belive
Jinja is sufficient for my web needs.

What I would like is to integrate Mustache in future web developments
using Teapot, and Pharo, but my documentation language in the back end
would be the same and more cross-community: markdown + yaml. So mustache
and abstract syntax trees is an argument for not caring too much about a
tightly integrated and Pharo only markup language.

Btw, let me say that I'm also inspired with Butterick and was
considering to use Racket for my project, but ended up here. :-)

Did you mean this:

http://practicaltypography.com/why-racket-why-lisp.html

I think that racket is a pretty interesting system and Pollen[2] is also
interesting for documentation. The idea of document as a program was
presented to me in the times when I used TeXmacs[3] and then Leo
Editor[4]. Now I'm trying to bridge several ideas of these technologies
with the Interactivity of IPython but using the flexibility and
understandability of Pharo/Moose/Roassal for my own interactive
documentation (alpha state) project[5][6]

[2] http://pollenpub.com/
[3] http://texmacs.org/
[4] http://leoeditor.com/
[5] http://mutabit.com/grafoscopio/index.en.html
[6]
http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html

So, while I think that choosing Pharo technologies is better for
making them more mature, tested and used, I also think that is
important to choose proper balance to know which combination of Pharo
technologies and external ones is adequate.

I didn't mention, but I was playing with Golang's Hugo for some time
which is also nice and, to me, preferrable over PHP.

Didn't know about that or TOML. As I said, your barely touch php with
grav, but the self-containment of Hugo and the easy syntax of TOML seem
like good arguments in favor of them for web publishing. The main
mes

Re: [Pharo-users] why Pillar

On Ned, 2015-12-27 at 18:50 -0500, Offray Vladimir Luna Cárdenas wrote:

Hiya,

> Seems that the reasons exposed in this tread are: It predated
> markdown,  so was already used inside the community, and gives us
> finer control on  the overall markup language, including exporting
> formats. 

Nothing against it, but some features like footnotes are simply 'must'
for serious writing, at least in my domain.

> Two projects implement this idea  Pandoc[2] 

Yeah, Pandoc is great and it would be cool to have Pillar support for
it.

> and Grav[3] and both use a combination of markdown and yaml.

Grav looks interesting, but I believe I simply want to leave PHP world.
:-)

> My bet is on  pandoc (markdown+yaml) for writing almost anything, with
> some advantages  over pillar:

My main complaint to markdown is that it is not standard, despite many
attempts (or extensions).

> b. It has support for bibliographic references, footnotes a a more 
> complete feature set.

I wonder how is it that despite being present for so long, it does miss
such features...

> I have been using Nikola myself and keeping myself under a more
> cohesive  python environment for making my publishing and
> scripting/programming  exploration. That changed after knowing
> Pharo/Roassal/Moose and now I  try to "live inside" these technologies
> most of the time for my own  interactive documentation and
> visualization project[6] and connect with  the external world via
> standards & formats like Json, cvs, yaml and  markdown. That's why now
> I'm using grav instead of Nikola for my web  publishing. 

Have you considered to use Pillar markup with Nikola?

That's one option I'm considering if Pillar is going to get things liek
footnotes etc.

> Ecstatic have more powerful things like a logic-less 
> approach to templating via mustache, that is neutral to the
> underlaying language

That would be another 'pro' for Pillar markup+Nikola, although I belive
Jinja is sufficient for my web needs.

Btw, let me say that I'm also inspired with Butterick and was
considering to use Racket for my project, but ended up here. :-)

> So, while I think that choosing Pharo technologies is better for
> making  them more mature, tested and used, I also think that is
> important to  choose proper balance to know which combination of Pharo
> technologies  and external ones is adequate. 

I didn't mention, but I was playing with Golang's Hugo for some time
which is also nice and, to me, preferrable over PHP.

> Ps: Would you mind to share more details about your project. The 
> questions you're asking for it are pretty interesting.

Well, I' considering to write extensive application for Vedic astrology
(including calendaring app) which could be used for research purposes,
e.g. having ability to seatch for different patterns present in charts
stored in local (Sqlite3) databases. There is something similar here:

http://saravali.de/maitreya.html

but it's written in C++/wx, while I hope to make it with Pharo.

Sincerely,
Gour

-- 
Whatever action a great man performs, common men follow. And 
whatever standards he sets by exemplary acts, all the world pursues.
-- 
As a strong wind sweeps away a boat on the water, 
even one of the roaming senses on which the mind 
focuses can carry away a man's intelligence.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: [Pharo-users] why Pillar

2015-12-27 Thread Offray Vladimir Luna Cárdenas


Hi Gour,

It seems that I have some similar quest to you, so I will try to answer 
about my approximation to documentation in the Pharo worl, even with the 
existance of Pillar (but being by no means any kind of expert on it, and 
of course this is my own experience, your mileage may vary).


On 25/12/15 11:02, Saša Janiška wrote:

Hiya,

I see that Pharo project has embraced Pillar system for documentation
purposes and my first question was "Why Pillar?" since, iirc, comparison
was made with e.g Markdown which is, obviously, not sufficient for eg.
authoring books, but there are more capable markups with 'standard'
implementations like rst/Sphinx and Asciidoc(tor).

Then I thought it must be some deeper reason, iow. something suitable to
work more closely with Pharo itself.

Now I have two questions:

1) Can someone answer in more detail "Why Pillar?" and


Seems that the reasons exposed in this tread are: It predated markdown, 
so was already used inside the community, and gives us finer control on 
the overall markup language, including exporting formats. I have tested 
several light markup languages for documentation including markdown, 
reST, AsciiDoc, dokuwiki, wikimedia, tiddly wiki, text2tags (t2), among 
others. There are several features that are desirable in many of them, 
like nice evoking notations of t2t and dokuwiki, wide support for 
exporting formats of reST, readability of AsciiDoc regarding extending 
features, the spread of Media wiki or nice modular approach to 
documentation of tiddly wiki. Surely the two reasons for pillar are also 
good ones. How do you balance this options?


Before reentering Pharo I was thinking in something like an extensible 
light markup language, like t2t, but instead of using regular expression 
(t2t uses them), it would use something like yaml[1] and a processor of 
these serialized data for different exporters. The idea of combining 
light markup languages for documentation and data serialization seems to 
become more popular these days. Two projects implement this idea 
Pandoc[2] and Grav[3] and both use a combination of markdown and yaml.


[1] https://en.wikipedia.org/wiki/YAML
[2] http://pandoc.org/
[3] http://getgrav.org/

So, how this could be combined with the offerings of Pharo? My bet is on 
pandoc (markdown+yaml) for writing almost anything, with some advantages 
over pillar:


a. It has a bigger momentum with projects like scholarly markdown ([4] 
http://scholmd.org/)
b. It has support for bibliographic references, footnotes a a more 
complete feature set.


The finer control would be offered by using abstract syntax trees (AST) 
for more detailed manipulation, which is already used to extend pandoc 
with languages like ruby, lua, perl  (see examples in [5] 
http://pandoc.org/scripting.html) and could be used, theoretically with 
Pharo. That's where metamodels used by Pillar could be used, so we could 
extend pandoc inside Pharo, while using markdown + yaml as a common 
language to write prose with other authors beyond this community, 
because Pillar is used only here, while markdown is becoming more used 
as a cross-community language for documentation, including Jupyter 
notebooks that combine documentation with languages like R, Julia, 
Haskell or Python.


This lead me to your next point:



2) For some time I was considering whether to settle on using rst or
AsciiDoc for *all* my writings, which means blog posts, my study notes,
preparing books, writing articles etc.

Since I've settled to use Python-powered static-site-generator (Nikola)
along with reStructuredText markup which can call external 'compilers'
to process blog posts written in specific markup, I wonder if it would
be possible to use Pillar markup with it since it seems there is cli for
it?


I have been using Nikola myself and keeping myself under a more cohesive 
python environment for making my publishing and scripting/programming 
exploration. That changed after knowing Pharo/Roassal/Moose and now I 
try to "live inside" these technologies most of the time for my own 
interactive documentation and visualization project[6] and connect with 
the external world via standards & formats like Json, cvs, yaml and 
markdown. That's why now I'm using grav instead of Nikola for my web 
publishing. Ecstatic have more powerful things like a logic-less 
approach to templating via mustache, that is neutral to the underlaying 
language, while grav templating is tied to php, but grav seems more 
developed and with more ready to use templates or skeletons for web 
publishing, so, once installed, you barely touch any underlaying 
technology beyond markup languages. More details on the 
transition/combination of grav/nikola can be found on [7].


[6] http://mutabit.com/grafoscopio/index.en.html
[7] http://mutabit.com/offray/blog/es/entry/2015-10-06-grav-nikola-both

So, while I think that choosing Pharo technologies is better for making 
them more mature, tested and used, I also think that is

Re: [Pharo-users] why Pillar

On Pet, 2015-12-25 at 15:59 -0500, Robert Withers wrote:

Hello Robert,

> Welcome to Pharo!  I view use of Pharo (squeak) as a knowledge
> sacrifice eliminating bondage to Karma. This is not the mainstream and
> a good thing too.

Nice comparison...although, being at the beginning I still do not
understand/see it as a sacrifice, but can feel it is liberating.

> As an example, where is the root implementation of #new defined? Hint:
> it is close to Pharo's arupa-brahma-loka, the highest planes. ;)

:-)

> Hare hare and Merry Christmas,

Haribol and Happy New Year!

-- 
As a lamp in a windless place does not waver, so the transcendentalist, 
whose mind is controlled, remains always steady in his meditation on the 
transcendent self.

Re: [Pharo-users] why Pillar

2015-12-25 Thread Robert Withers

Sorry, that was meant to be private.

---
robert

> On Dec 25, 2015, at 3:59 PM, Robert Withers  
> wrote:
> 
> 
>> On Dec 25, 2015, at 1:58 PM, Saša Janiška  wrote:
>> -- 
>> As a blazing fire turns firewood to ashes, O Arjuna, so does the 
>> fire of knowledge burn to ashes all reactions to material activities.
> 
> ---
> The knowledge sacrifice is superior 
> To any material sacrifice, O Arjuna. 
> Because, all actions in their entirety 
> Culminate in knowledge.
> ---
> 
> Dear Saša,
> Welcome to Pharo!  I view use of Pharo (squeak) as a knowledge sacrifice 
> eliminating bondage to Karma. This is not the mainstream and a good thing 
> too.  
> 
> As an example, where is the root implementation of #new defined? Hint: it is 
> close to Pharo's arupa-brahma-loka, the highest planes. ;)
> 
> Hare hare and Merry Christmas,
> Robert
> 
> 
>> 
>> 
>> 
>> 
>>

Re: [Pharo-users] why Pillar

2015-12-25 Thread Robert Withers

> On Dec 25, 2015, at 1:58 PM, Saša Janiška  wrote:
> -- 
> As a blazing fire turns firewood to ashes, O Arjuna, so does the 
> fire of knowledge burn to ashes all reactions to material activities.

---
The knowledge sacrifice is superior 
To any material sacrifice, O Arjuna. 
Because, all actions in their entirety 
Culminate in knowledge.
---

> Dear Saša,

Welcome to Pharo!  I view use of Pharo (squeak) as a knowledge sacrifice 
eliminating bondage to Karma. This is not the mainstream and a good thing too.  

As an example, where is the root implementation of #new defined? Hint: it is 
close to Pharo's arupa-brahma-loka, the highest planes. ;)

Hare hare and Merry Christmas,
Robert

> 
> 
> 
> 
>

Re: [Pharo-users] why Pillar

On Pet, 2015-12-25 at 18:07 +0100, Damien Cassou wrote:

> We wanted to generate slides, Cyril changed Pillar to generate slides.
> We want to generate exercises and questions, we will change Pillar to
> generate questions in a dedicated format for a specific MOOC platform.
> Because Pillar is in Pharo, is well designed and is fully tested, we
> can easily extend it the way we want. 

Thank you. That explains it nicely. ;)


Sincerely,
Gour

-- 
As a blazing fire turns firewood to ashes, O Arjuna, so does the 
fire of knowledge burn to ashes all reactions to material activities.

Re: [Pharo-users] why Pillar

On Pet, 2015-12-25 at 18:10 +0100, Damien Cassou wrote:

> I don't like footnotes so I never added them. 

Heh, that's *you*, but I still wonder about all other Pillar users.

> If you like them, 

Let me say that I *need* them - that's the nature of the content I
write...

> I guess it's less than a hundred lines of code using annotations. 

I'll take a look, but first things first.

> Bold uses double quotes whereas italic uses single quotes. I guess
> mixing them is no problem but I don't have my computer to check. 

I'm interested to find out - if someone has Pillar installed, before I
venture into it.

Sincerely,
Gour

-- 
As fire is covered by smoke, as a mirror is covered by dust, 
or as the embryo is covered by the womb, the living entity is 
similarly covered by different degrees of this lust.

Re: [Pharo-users] why Pillar

2015-12-25 Thread Damien Cassou

On December 25, 2015 6:02:05 PM GMT+01:00, "Saša Janiška"  
wrote:
>Can Pillar handle footnotes? (I can't see on the cheetsheet.)

I don't like footnotes so I never added them. If you like them, I guess it's 
less than a hundred lines of code using annotations. 

>Seeing that quotes are used for *both* italic and bold, I wonder if
>Pillar can do nested inline markup, like e.g. bold-italic? 

Bold uses double quotes whereas italic uses single quotes. I guess mixing them 
is no problem but I don't have my computer to check. 

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-users] why Pillar

2015-12-25 Thread Damien Cassou

On December 25, 2015 5:02:13 PM GMT+01:00, "Saša Janiška"  
wrote:
>Hiya,
>
>I see that Pharo project has embraced Pillar system for documentation
>purposes and my first question was "Why Pillar?" since, iirc,
>comparison
>was made with e.g Markdown which is, obviously, not sufficient for eg.
>authoring books, but there are more capable markups with 'standard'
>implementations like rst/Sphinx and Asciidoc(tor).
>
>Then I thought it must be some deeper reason, iow. something suitable
>to
>work more closely with Pharo itself.
>
>Now I have two questions:
>
>1) Can someone answer in more detail "Why Pillar?" and
>
>2) For some time I was considering whether to settle on using rst or
>AsciiDoc for *all* my writings, which means blog posts, my study notes,
>preparing books, writing articles etc.
>
>Since I've settled to use Python-powered static-site-generator (Nikola)
>along with reStructuredText markup which can call external 'compilers'
>to process blog posts written in specific markup, I wonder if it would
>be possible to use Pillar markup with it since it seems there is cli
>for
>it?
>
>
>Sincerely,
>Gour
> 

We wanted to generate slides, Cyril changed Pillar to generate slides. We want 
to generate exercises and questions, we will change Pillar to generate 
questions in a dedicated format for a specific MOOC platform. Because Pillar is 
in Pharo, is well designed and is fully tested, we can easily extend it the way 
we want. 
-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-users] why Pillar