Re: [Pharo-users] why Pillar
Le 29/12/2015 13:18, Offray Vladimir Luna Cárdenas a écrit : > Hi, > > > If you're on Mac/Linux. Windows is another story. > Hi, since Pillar 1.0.0 the only difference is that Pillar doesn't generate a Windows script to compile the .tex into pdf. Else Pillar should works on Windows. > Cheers, > > Offray > > > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France signature.asc Description: OpenPGP digital signature
Re: [Pharo-users] why Pillar
Hi, On 29/12/15 06:01, Dimitris Chloupis wrote: I think in case of Pillar makes sense to create something in Pharo because the existing solutions are not that powerful anyway with the notable exception of Latex which is something that Pillar can use and inline anyway. Personally I love Pillar, the syntax, installation and the general usage is super simple. If you're on Mac/Linux. Windows is another story. I also think that having a documentation frameworks instead of using one from another language is a must have because documentation is super important and you should not be limited by what people do in other languages and its not that complex to implement like for example version control. Agreed. Of course Pillar is somewhere in between because on one hand yes its a Pharo implementation but on the other it depends on Latex for the creation of pdfs, so I think overall its a very well designed frameworks with very good syntax, small learning curve and enormous abilities because of the latex integration. Same as Pandoc. So to answer your question Why Pillar ? Because its awesome :) Same as pandoc. Cheers, Offray
Re: [Pharo-users] why Pillar
I am a huge supporter of Pharo being directly connected to the outside world and not just recreate (I wont use the term "reinvent the wheel" because I was always found it a stupid remark anyway) something that it exists out there without an obvious advantage. However it makes sense in many cases because of the tiny fact that when one chooses and dedicates his life on one language he or she will want to code on that language alone. I think in case of Pillar makes sense to create something in Pharo because the existing solutions are not that powerful anyway with the notable exception of Latex which is something that Pillar can use and inline anyway. Personally I love Pillar, the syntax, installation and the general usage is super simple. I also think that having a documentation frameworks instead of using one from another language is a must have because documentation is super important and you should not be limited by what people do in other languages and its not that complex to implement like for example version control. Of course Pillar is somewhere in between because on one hand yes its a Pharo implementation but on the other it depends on Latex for the creation of pdfs, so I think overall its a very well designed frameworks with very good syntax, small learning curve and enormous abilities because of the latex integration. So to answer your question Why Pillar ? Because its awesome :) On Tue, Dec 29, 2015 at 9:37 AM Saša Janiška wrote: > 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 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
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
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
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
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
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
> 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
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
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
On Pet, 2015-12-25 at 17:36 +0100, stepharo wrote: > Pillar exists before Markdown. > We did pillar syntax back in 2002. Heh, it's interesting that both rst & AsciiDoc are also, according to Wikipedia from 2002. :-) What about Pillar and Pharo? Any additional advantage to use it? > We do that with Pillar because we have the control over it and because > we have it since long time. The seaside book was fully written in > pillar. Can Pillar handle footnotes? (I can't see on the cheetsheet.) Seeing that quotes are used for *both* italic and bold, I wonder if Pillar can do nested inline markup, like e.g. bold-italic? It's one of the design limit of rst, but AsciiDoc can handle it. Sincerely, Gour -- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities.
Re: [Pharo-users] why Pillar
Le 25/12/15 17:02, Saša Janiška a écrit : 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 Pillar exists before Markdown. We did pillar syntax back in 2002. 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. We do that with Pillar because we have the control over it and because we have it since long time. The seaside book was fully written in pillar. 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? Check Ecstatic (we should do another pass on it). The idea is to use pillar + mustache to generate static web pages. Sincerely, Gour
[Pharo-users] why Pillar
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 -- When your intelligence has passed out of the dense forest of delusion, you shall become indifferent to all that has been heard and all that is to be heard.