August 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-dev] [ann] pillar support in gtinspector

by Alexandre Bergel

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(a)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." > > > > >

Aug. 30, 2016

Re: [Pharo-users] [Moose-dev] [ann] pillar support in gtinspector

by Offray Vladimir Luna CÃ¡rdenas

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(a)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-la… >>> >>> 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 >

Aug. 30, 2016

Re: [Pharo-users] [Moose-dev] [ann] pillar support in gtinspector

by Serge Stinckwich

On Tue, Aug 30, 2016 at 12:11 PM, Peter Uhnak <i.uhnak(a)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-la… >> >> 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/

Aug. 30, 2016

Re: [Pharo-users] [Moose-dev] [ann] pillar support in gtinspector

by Peter Uhnak

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-la… > > 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

Aug. 30, 2016

Re: [Pharo-users] [Moose-dev] [ann] pillar support in gtinspector

by Offray Vladimir Luna CÃ¡rdenas

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-la… 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

Aug. 30, 2016

Re: [Pharo-users] standalone/runtime executable

by HernÃ¡n Morales Durand

Hi Stephan 2016-08-29 14:16 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 26/08/16 18:49, HernÃ¡n Morales Durand wrote: > >> Is not fully tested but here is how you install it: >> >> Gofer it >> smalltalkhubUser: 'hernan' project: 'CodeGenerator'; >> configuration; >> loadDevelopment. >> >> CGSmalltalkExamples exampleNSISPharo4. >> CGSmalltalkExamples exampleNSISPharo5. >> >> It will generate a .nsi file in image directory. >> >> > Thanks HernÃ¡n. > Could you tell us something more about the CodeGenerator > that you created it with? For someone new to NSIS there > are a lot of moving parts like this. > This will be properly documented in the future. But here I go with some basic notes. The idea is to have a very modular hierarchy of code generation capabilities. There is a very basic generator for QC Magritte ;) but I hadn't the time for testing or complete yet A description of hierarchy classes is -CGAbstract (Provides code stream) --CGTemplate (Utility class for extracting template methods from classes - in the sense of a Template framework, not design patterns) ---CGAuthoring (Provides identity management) ----CGBash (Bash code generator) ----CGNSISInstaller (Unicode NSIS Installer Script (.nsi) Generator, requires Mustache Templates and ZipDLL.nsh plugin installed) ----CGSmalltalkAuthoring (Abstract Smalltalk code generator providing author management - not the same as identity) - CGStConvenienceMethods (Smalltalk Code Generator based in the pattern Convenience Methods (1998) by Robert Hirschfeld) - CGStAbstractClassPattern (Smalltalk Code Generator based in the Abstract Class Pattern by Bobby Woolf.) - CGStBuilderPattern (Builder Design Pattern - I don't remember the status of this one, I should check) - CGStHierarchyCreator (Smalltalk Code Generator to generate a class hierarchy) - CGStMagritte - CGQCMagritte (Seaside QC Magritte Generator) - CGQCBMagritte (Seaside QC Magritte + Bootstrap) Generator - CGStImageImporter (Scans an input directory and uses ImageReadWriter to read binary file streams) - CGStTextImporter (Same for textual resources) - CGStSingleton (Generates a Singleton in Smalltalk) - CGSunit (SUnit Tests Generator) - CGStSpec (To be implemented) These are examples of how to generate code: Simple class and variables: CGSmalltalk uniqueInstance setCleanTarget; targetClassCategory: 'MPIRunner-Core'; targetClass: #MPIRunner; addInstanceVariables: #(#nproc #submitToQueue). Convenience methods CGStConvenienceMethods uniqueInstance setCleanTarget; parameterCount: 1; targetSelector: #cgConvEx1; targetClassCategory: 'ConvenienceMethodsEx'; targetClass: #ConvenienceMethodsEx; generateMethods. Singleton CGStSingleton uniqueInstance setCleanTarget; targetClassCategory: 'SingletonEx1'; targetClass: #SingletonEx1; generateMethods. Builder CGStBuilderPattern uniqueInstance setCleanTarget; targetClassCategory: 'CGGeneratedCode-Core'; " Abstract Builder class name (ex: UIBuilder) " targetClass: #CGExCarBuilder; productNames: #('CGExFordCar' 'CGExBMWCar' 'CGExHondaCar'); builderNames: #('CGExFordBuilder' 'CGExBMWBuilder' 'CGExHondaBuilder'); familyNames: #('CGExCarEngine' 'CGExCarBody'); " How many product parts per family ? " productPartsPerFamilyCount: 3; directorClassName: #CGExCarAssembler; generateClasses. > It would be great to have an example that is complete > and compiles out of the box. Good target for a screencast > also (for me they work very well for improved community > communication). > > I would love to have more time :) HernÃ¡n > Stephan > > > >

Aug. 30, 2016

Re: [Pharo-users] [Moose-dev] [ann] pillar support in gtinspector

by Yuriy Tymchuk

> On 29 Aug 2016, at 21:41, Tudor Girba <tudor(a)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(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Aug. 29, 2016

[ann] pillar support in gtinspector

by Tudor Girba

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."

Aug. 29, 2016

Re: [Pharo-users] Traits inheritance

by stepharo

Alex the explicitRequirement was removed because of the algorithms you need to check for example to update the icons or do static check each time you compile a method. Stef Le 28/8/16 Ã 11:17, Alexandre Bergel a Ã©crit : > Hi Petr! > > You have found what I think is a bug. Indeed, Nautilus may be improved to have the behavior you describe. Having an explicit requirement ("self explicitRequirementâ) should be indicated by Nautilus. I suggest you to open a bug on https://pharo.fogbugz.com > > Regarding the second problem, I cannot reproduce it. Do you have the exact steps to reproduce it? > > Alexandre > > >> On Aug 27, 2016, at 10:23 PM, Petr Fischer <petr.fischer(a)me.com> wrote: >> >> Hello, is Trait methods inheritance supported in Pharo? >> >> Like this: >> >> TBaseTrait>>myMethod >> self subclassresponsibility >> >> TSubTrait >> uses: TBaseTrait >> ... >> TSubTrait>>myMethod >> some real implementation >> >> MyClass >> uses: TSubTrait >> (MyClasss>>myMethod already implemented in TSubTrait, but I can reimplement again) >> >> Problems: >> >> 1) when I put "self subclassresponsibility" in TBaseTrait, everything is nicely visible in Nautilus browser (something like "abstract" method with proper (a) yellow icon). But I read somewhere, that for traits, I must use "^ self explicitRequirement" instead of "subclassresponsibility" - then, I can't see anything usefull in Nautilus >> >> 2) sometimes (it was maybe with "self subclassresponsibility" in TBaseTrait), Monticello not detected overrided TSubTrait>>myMethod (TSubTrait residing in another package than TBaseTrait) and this overrided trait method in TSubTrait was not saved in monticelo package (no changes was detected by Monticello, thus not saved to mcz package!) >> >> So - is trait a "bag of methods" only, or is trait inheritance supported? Thanks very much! >> >> pf >>

Aug. 29, 2016

Re: [Pharo-users] standalone/runtime executable

by Stephan Eggermont

On 26/08/16 18:49, HernÃ¡n Morales Durand wrote: > Is not fully tested but here is how you install it: > > Gofer it > smalltalkhubUser: 'hernan' project: 'CodeGenerator'; > configuration; > loadDevelopment. > > CGSmalltalkExamples exampleNSISPharo4. > CGSmalltalkExamples exampleNSISPharo5. > > It will generate a .nsi file in image directory. > Thanks HernÃ¡n. Could you tell us something more about the CodeGenerator that you created it with? For someone new to NSIS there are a lot of moving parts like this. It would be great to have an example that is complete and compiles out of the box. Good target for a screencast also (for me they work very well for improved community communication). Stephan

Aug. 29, 2016