[ann] pillar support in gtinspector
Hi, I updated the Pillar support in GTInspector. Some of the extensions already exist in the default Pillar #development version. If you want to play with the full support, you can load it like this: Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; package: 'PetitAnalyzer'; package: 'PetitIndent'; package: 'PetitIslands'; smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load Then you can just inspect a book folder and you get this: I did not integrate this in the main Pillar yet because this is an older implementation based on a limited island parser. As now Pillar has a full parser based on PetitParser, the next step is to move the highlighting logic to use this parser instead of the island parser. From my measurements, the speed of the two parsers is about the same, so from a user perspective there will be not much changes. It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."
On 29 Aug 2016, at 21:41, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I updated the Pillar support in GTInspector. Some of the extensions already exist in the default Pillar #development version. If you want to play with the full support, you can load it like this:
Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; package: 'PetitAnalyzer'; package: 'PetitIndent'; package: 'PetitIslands'; smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load
Then you can just inspect a book folder and you get this:
<inspector-pillar.png>
Cool!
I did not integrate this in the main Pillar yet because this is an older implementation based on a limited island parser. As now Pillar has a full parser based on PetitParser, the next step is to move the highlighting logic to use this parser instead of the island parser. From my measurements, the speed of the two parsers is about the same, so from a user perspective there will be not much changes.
It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start.
To make things sadder: when I need to write some short ârichish" Iâm using markdown instead for pillar because in ATOM I can open the rendered version of my document that will update while i type (and will display images and so on). It could be nice to have the same functionality in Pharo, but Iâm really busy with improving other parts. Additionally Iâm not sure that it makes sense to reimplement rich text editor in Pharo. Uko
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
_______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi, On 29/08/16 21:47, Yuriy Tymchuk wrote: [...]
It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start.
To make things sadder: when I need to write some short ârichish" Iâm using markdown instead for pillar because in ATOM I can open the rendered version of my document that will update while i type (and will display images and so on). It could be nice to have the same functionality in Pharo, but Iâm really busy with improving other parts. Additionally Iâm not sure that it makes sense to reimplement rich text editor in Pharo.
Uko
For me it would be really nice to have this kind of support for markdown. That's the language I'm using for writing my PhD thesis in Pharo, and in fact now that I'm in hackademia Summer School[1] is nice to find some other PhD students that in fact are using markdown in their writing. [1] http://www.leuphana.de/en/research-centers/cdc/digital-cultures-research-lab... Having syntax highlighting and graphics preview for markdown would be a way to introduce some new non-technical users and researchers to the Pharo world, reproducible research, interactive documentation and modable tools, but we need to start in a place they know, for example its markup language. Cheers, Offray
On Tue, Aug 30, 2016 at 07:50:10AM +0200, Offray Vladimir Luna Cárdenas wrote:
Hi,
On 29/08/16 21:47, Yuriy Tymchuk wrote:
[...]
It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start.
To make things sadder: when I need to write some short ârichish" Iâm using markdown instead for pillar because in ATOM I can open the rendered version of my document that will update while i type (and will display images and so on). It could be nice to have the same functionality in Pharo, but Iâm really busy with improving other parts. Additionally Iâm not sure that it makes sense to reimplement rich text editor in Pharo.
Uko
For me it would be really nice to have this kind of support for markdown. That's the language I'm using for writing my PhD thesis in Pharo, and in fact now that I'm in hackademia Summer School[1] is nice to find some other PhD students that in fact are using markdown in their writing.
[1] http://www.leuphana.de/en/research-centers/cdc/digital-cultures-research-lab...
Having syntax highlighting and graphics preview for markdown would be a way to introduce some new non-technical users and researchers to the Pharo world, reproducible research, interactive documentation and modable tools, but we need to start in a place they know, for example its markup language.
I don't really see the benefit of pushing Markdown into Pharo at _this moment_ (there is PetitParser for some flavor of md though). If you want to use Markdown, then there is already fifteen billion of other tools outside. If you want deep integration with Pharo, then that takes a lot of effort, which is being invested into Pillar, because Pillar is aiming to be a much more powerful format --- maybe one day comparable to reStructuredText and to what Python does with rst/sphinx. Don't forget that markdown, although an excellent markup for what it knows, is also very simplistic. So if you want to use Markdown for PhD, then you are actually not using markdown, but most likely pandoc (or some richer syntax, such as scholarly markdown)... and support for either is another order of magnitude more complex. Bottom line(s): * there's a continuous investment into improvement and deep integration of Pillar * not enough resources to go around and implement any notation * Markdown is too simplistic for any advanced writing (and yes, I used it to write papers and my thesis, but it also includes pandoc and many make/bash/ruby scripts to hack around) Peter
On Tue, Aug 30, 2016 at 12:11 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Tue, Aug 30, 2016 at 07:50:10AM +0200, Offray Vladimir Luna Cárdenas wrote:
Hi,
On 29/08/16 21:47, Yuriy Tymchuk wrote:
[...]
It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start.
To make things sadder: when I need to write some short ârichish" Iâm using markdown instead for pillar because in ATOM I can open the rendered version of my document that will update while i type (and will display images and so on). It could be nice to have the same functionality in Pharo, but Iâm really busy with improving other parts. Additionally Iâm not sure that it makes sense to reimplement rich text editor in Pharo.
Uko
For me it would be really nice to have this kind of support for markdown. That's the language I'm using for writing my PhD thesis in Pharo, and in fact now that I'm in hackademia Summer School[1] is nice to find some other PhD students that in fact are using markdown in their writing.
[1] http://www.leuphana.de/en/research-centers/cdc/digital-cultures-research-lab...
Having syntax highlighting and graphics preview for markdown would be a way to introduce some new non-technical users and researchers to the Pharo world, reproducible research, interactive documentation and modable tools, but we need to start in a place they know, for example its markup language.
I don't really see the benefit of pushing Markdown into Pharo at _this moment_ (there is PetitParser for some flavor of md though). If you want to use Markdown, then there is already fifteen billion of other tools outside.
If you want deep integration with Pharo, then that takes a lot of effort, which is being invested into Pillar, because Pillar is aiming to be a much more powerful format --- maybe one day comparable to reStructuredText and to what Python does with rst/sphinx.
Yes a lot of effort has already been put on Pillar and should continue this effort. If you want to use Markdown, you can use existing tools outside the image.
Don't forget that markdown, although an excellent markup for what it knows, is also very simplistic. So if you want to use Markdown for PhD, then you are actually not using markdown, but most likely pandoc (or some richer syntax, such as scholarly markdown)... and support for either is another order of magnitude more complex.
Bottom line(s): * there's a continuous investment into improvement and deep integration of Pillar * not enough resources to go around and implement any notation * Markdown is too simplistic for any advanced writing (and yes, I used it to write papers and my thesis, but it also includes pandoc and many make/bash/ruby scripts to hack around)
Markdown is not a good idea for thesis, but org-mode+org-babel is quite good for papers. You might have a look to Scimax that is based on these tools: http://kitchingroup.cheme.cmu.edu/scimax -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Peter and Serge, I will be using Pandoc's markdown for sure. I can not wait *at this moment* for Pillar to have the features I need for my writing (mainly Zotero integration), but given the massive amount of work a proper support of markdown will imply, I just use it, as now, by writing plain text without any syntax highlighting support. I wouldn't image that giving syntax highlighting support for markdown in Pharo could be that hard, but I can write the thesis without it, using just black text anywhere. Anyway having syntax support for another languages is something that is being done for software analysis, so, maybe at some point I can just try to learn how is being done with Petit Parser o Smacc and see if I can help to create a more markdown friendly environment in Pharo. Thanks, Offray On 30/08/16 14:10, Serge Stinckwich wrote:
On Tue, Aug 30, 2016 at 12:11 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Tue, Aug 30, 2016 at 07:50:10AM +0200, Offray Vladimir Luna Cárdenas wrote:
Hi,
On 29/08/16 21:47, Yuriy Tymchuk wrote:
[...]
It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start. To make things sadder: when I need to write some short ârichish" Iâm using markdown instead for pillar because in ATOM I can open the rendered version of my document that will update while i type (and will display images and so on). It could be nice to have the same functionality in Pharo, but Iâm really busy with improving other parts. Additionally Iâm not sure that it makes sense to reimplement rich text editor in Pharo.
Uko
For me it would be really nice to have this kind of support for markdown. That's the language I'm using for writing my PhD thesis in Pharo, and in fact now that I'm in hackademia Summer School[1] is nice to find some other PhD students that in fact are using markdown in their writing.
[1] http://www.leuphana.de/en/research-centers/cdc/digital-cultures-research-lab...
Having syntax highlighting and graphics preview for markdown would be a way to introduce some new non-technical users and researchers to the Pharo world, reproducible research, interactive documentation and modable tools, but we need to start in a place they know, for example its markup language. I don't really see the benefit of pushing Markdown into Pharo at _this moment_ (there is PetitParser for some flavor of md though). If you want to use Markdown, then there is already fifteen billion of other tools outside.
If you want deep integration with Pharo, then that takes a lot of effort, which is being invested into Pillar, because Pillar is aiming to be a much more powerful format --- maybe one day comparable to reStructuredText and to what Python does with rst/sphinx.
Yes a lot of effort has already been put on Pillar and should continue this effort. If you want to use Markdown, you can use existing tools outside the image.
Don't forget that markdown, although an excellent markup for what it knows, is also very simplistic. So if you want to use Markdown for PhD, then you are actually not using markdown, but most likely pandoc (or some richer syntax, such as scholarly markdown)... and support for either is another order of magnitude more complex.
Bottom line(s): * there's a continuous investment into improvement and deep integration of Pillar * not enough resources to go around and implement any notation * Markdown is too simplistic for any advanced writing (and yes, I used it to write papers and my thesis, but it also includes pandoc and many make/bash/ruby scripts to hack around) Markdown is not a good idea for thesis, but org-mode+org-babel is quite good for papers. You might have a look to Scimax that is based on these tools: http://kitchingroup.cheme.cmu.edu/scimax
I do not get how you can write a PhD in a system that does not support - footnote - citation - figure reference. Pillar supports all that. Le 30/8/16 à 15:28, Offray Vladimir Luna Cárdenas a écrit :
Peter and Serge,
I will be using Pandoc's markdown for sure. I can not wait *at this moment* for Pillar to have the features I need for my writing (mainly Zotero integration), but given the massive amount of work a proper support of markdown will imply, I just use it, as now, by writing plain text without any syntax highlighting support.
There is an emacs binding for Pillar and it works well. There is also a textmate binding.
I wouldn't image that giving syntax highlighting support for markdown in Pharo could be that hard, but I can write the thesis without it, using just black text anywhere. Anyway having syntax support for another languages is something that is being done for software analysis, so, maybe at some point I can just try to learn how is being done with Petit Parser o Smacc and see if I can help to create a more markdown friendly environment in Pharo. I do not see the point I do not get why after all the efforts we are doing around Pillar and the proof that we can use it for making so great output people want markdown. Sorry but do not expect us to do anything in that direction.
Stef
Thanks,
Offray
On 30/08/16 14:10, Serge Stinckwich wrote:
On Tue, Aug 30, 2016 at 12:11 PM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Tue, Aug 30, 2016 at 07:50:10AM +0200, Offray Vladimir Luna Cárdenas wrote:
Hi,
On 29/08/16 21:47, Yuriy Tymchuk wrote:
[...]
It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start. To make things sadder: when I need to write some short ârichish" Iâm using markdown instead for pillar because in ATOM I can open the rendered version of my document that will update while i type (and will display images and so on). It could be nice to have the same functionality in Pharo, but Iâm really busy with improving other parts. Additionally Iâm not sure that it makes sense to reimplement rich text editor in Pharo.
Uko
For me it would be really nice to have this kind of support for markdown. That's the language I'm using for writing my PhD thesis in Pharo, and in fact now that I'm in hackademia Summer School[1] is nice to find some other PhD students that in fact are using markdown in their writing.
[1] http://www.leuphana.de/en/research-centers/cdc/digital-cultures-research-lab...
Having syntax highlighting and graphics preview for markdown would be a way to introduce some new non-technical users and researchers to the Pharo world, reproducible research, interactive documentation and modable tools, but we need to start in a place they know, for example its markup language. I don't really see the benefit of pushing Markdown into Pharo at _this moment_ (there is PetitParser for some flavor of md though). If you want to use Markdown, then there is already fifteen billion of other tools outside.
If you want deep integration with Pharo, then that takes a lot of effort, which is being invested into Pillar, because Pillar is aiming to be a much more powerful format --- maybe one day comparable to reStructuredText and to what Python does with rst/sphinx.
Yes a lot of effort has already been put on Pillar and should continue this effort. If you want to use Markdown, you can use existing tools outside the image.
Don't forget that markdown, although an excellent markup for what it knows, is also very simplistic. So if you want to use Markdown for PhD, then you are actually not using markdown, but most likely pandoc (or some richer syntax, such as scholarly markdown)... and support for either is another order of magnitude more complex.
Bottom line(s): * there's a continuous investment into improvement and deep integration of Pillar * not enough resources to go around and implement any notation * Markdown is too simplistic for any advanced writing (and yes, I used it to write papers and my thesis, but it also includes pandoc and many make/bash/ruby scripts to hack around) Markdown is not a good idea for thesis, but org-mode+org-babel is quite good for papers. You might have a look to Scimax that is based on these tools: http://kitchingroup.cheme.cmu.edu/scimax
Doru what would be fun is to extend pillar to get live display and update of scripts. Stef
Hi, On 31/08/16 08:52, stepharo wrote:
I do not get how you can write a PhD in a system that does not support
- footnote
- citation
- figure reference.
Pillar supports all that.
Pandoc's markdown support all that. I need zotero bibliography integration by using @keys. I started writing my thesis using them and I have already markdown documents with yaml metablocks and other pandoc features. I need compatibility with my own past and bridges with other practices/tech beyond pharo community (here at hackademia nobody is using Pillar markup, but they're using Pandoc's markdown now and have PhD documents already wrote on that, like me).
I wouldn't image that giving syntax highlighting support for markdown in Pharo could be that hard, but I can write the thesis without it, using just black text anywhere. Anyway having syntax support for another languages is something that is being done for software analysis, so, maybe at some point I can just try to learn how is being done with Petit Parser o Smacc and see if I can help to create a more markdown friendly environment in Pharo. I do not see the point I do not get why after all the efforts we are doing around Pillar and the proof that we can use it for making so great output people want markdown. Sorry but do not expect us to do anything in that direction.
I'm good with that, as soon as the community doesn't discourage any *individual* attempt to support any other markup language on the world. For me would be like not supporting git because community has invested a lot on effort on monticello and it is what community is doing right now. I don't even like git, and rant against it, but I think that this work is valuable and strategic. The only thing I don't want is getting git into my way, but the work Nico is doing in that direction seems really promising. Python has reST as default, but not as the only markup in the world it support for documentation. There is some other stuff beyond what we're using and support it is a way to get more people interested in Pharo, not less. Cheers, Offray
Hi! Having a spell checker would be fantastic⦠Any chance to have this? Alexandre
On Aug 29, 2016, at 4:41 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I updated the Pillar support in GTInspector. Some of the extensions already exist in the default Pillar #development version. If you want to play with the full support, you can load it like this:
Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; package: 'PetitAnalyzer'; package: 'PetitIndent'; package: 'PetitIslands'; smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load
Then you can just inspect a book folder and you get this:
<inspector-pillar.png>
I did not integrate this in the main Pillar yet because this is an older implementation based on a limited island parser. As now Pillar has a full parser based on PetitParser, the next step is to move the highlighting logic to use this parser instead of the island parser. From my measurements, the speed of the two parsers is about the same, so from a user perspective there will be not much changes.
It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
2016-08-29 21:41 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
I updated the Pillar support in GTInspector. Some of the extensions already exist in the default Pillar #development version. If you want to play with the full support, you can load it like this:
Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; package: 'PetitAnalyzer'; package: 'PetitIndent'; package: 'PetitIslands'; smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load
Then you can just inspect a book folder and you get this:
I did not integrate this in the main Pillar yet because this is an older implementation based on a limited island parser. As now Pillar has a full parser based on PetitParser, the next step is to move the highlighting logic to use this parser instead of the island parser. From my measurements, the speed of the two parsers is about the same, so from a user perspective there will be not much changes.
It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start.
Cheers, Doru
nice! I just played a bit with the code to apply larger different font sizes for the headings and use the code styler for inlined code ("=="). Maybe we should use a different code styler or add a way to instruct the styler to ignore unknown classes or uknown selectors :)
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
Hi Nicolai, Did you commit your changes with the highlight of == code? Cheers, Doru
On Sep 6, 2016, at 4:56 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-29 21:41 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
I updated the Pillar support in GTInspector. Some of the extensions already exist in the default Pillar #development version. If you want to play with the full support, you can load it like this:
Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; package: 'PetitAnalyzer'; package: 'PetitIndent'; package: 'PetitIslands'; smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load
Then you can just inspect a book folder and you get this:
<inspector-pillar.png>
I did not integrate this in the main Pillar yet because this is an older implementation based on a limited island parser. As now Pillar has a full parser based on PetitParser, the next step is to move the highlighting logic to use this parser instead of the island parser. From my measurements, the speed of the two parsers is about the same, so from a user perspective there will be not much changes.
It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start.
Cheers, Doru
nice!
I just played a bit with the code to apply larger different font sizes for the headings and use the code styler for inlined code ("==").
Maybe we should use a different code styler or add a way to instruct the styler to ignore unknown classes or uknown selectors :)
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
_______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."
2016-09-14 22:47 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi Nicolai,
Did you commit your changes with the highlight of == code?
Cheers, Doru
No, but I just saw that I misinterpreted the "==", first I thought this is for "inline code" as it was used in some class comment like that. But it is actually a more general formatting tag for "monospaced font" - we actually don't need to do code highlighting for this text, just use a monospace font resp. code font.
On Sep 6, 2016, at 4:56 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-29 21:41 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
I updated the Pillar support in GTInspector. Some of the extensions already exist in the default Pillar #development version. If you want to play with the full support, you can load it like this:
Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; package: 'PetitAnalyzer'; package: 'PetitIndent'; package: 'PetitIslands'; smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load
Then you can just inspect a book folder and you get this:
<inspector-pillar.png>
I did not integrate this in the main Pillar yet because this is an older implementation based on a limited island parser. As now Pillar has a full parser based on PetitParser, the next step is to move the highlighting logic to use this parser instead of the island parser. From my measurements, the speed of the two parsers is about the same, so from a user perspective there will be not much changes.
It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start.
Cheers, Doru
nice!
I just played a bit with the code to apply larger different font sizes for the headings and use the code styler for inlined code ("==").
Maybe we should use a different code styler or add a way to instruct the styler to ignore unknown classes or uknown selectors :)
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
_______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Obvious things are difficult to teach."
participants (8)
-
Alexandre Bergel -
Nicolai Hess -
Offray Vladimir Luna Cárdenas -
Peter Uhnak -
Serge Stinckwich -
stepharo -
Tudor Girba -
Yuriy Tymchuk