About Pharo 60

>> what are the points you are working on and that would deserve more focus and help from the community?
> I once started with a refactored version of GetText, covered with tests and tools.
> Code status I reached so far is here:
>
>    http://www.smalltalkhub.com/#!/~TorstenBergmann/Gettext
>
> Idea was to be lean, no dependency on Seaside or others and get a well documented easy to use I18N solution.
> This would open up the possibility for more internationalized Pharo image and Pharo based apps. Would be nice
> if this could be completed and become part of our infrastructure to get a wider audience and globally usable
> applications.
>
> Additionally I would like to see:
>
>   - investigation in the Win Pharo VM for being able to run again as a Windows Service
>     (as it was possible for Squeak) to be able to easily provide, deploy and administrate a web
>     app on Windows
>
>   - image size management under control (as Philip already suggested)
>
>   - better support for REST based systems (as Philip already suggested)
>
>   - modern "Material style" UI (as Philip already suggested) but additionally with
>     better out of the box Spec support and examples for regular widgets
>     (Accordion, draggable Toolbars, calendar widget, date/time picker, ...)
>
>   - clear rules to not accept undocumented classes/packages in the image
>     And a clear separation in packages between CORE/BASE stuff and TESTS on top.
>     Because TEST are usually only for development and for production/deployment of an app
>     TESTS usually should be thrown out.
>
> Christmas list would include:
>   - 64 Bit support
>   - an out of the box Pharo Pi VM + image on the website
>
> Bye
> T.
>
>

>>
>>   - modern "Material style" UI (as Philip already suggested) but
>> additionally with
>>     better out of the box Spec support and examples for regular widgets
>>     (Accordion, draggable Toolbars, calendar widget, date/time
>> picker, ...)
>>
>>   - clear rules to not accept undocumented classes/packages in the image
>>     And a clear separation in packages between CORE/BASE stuff and
>> TESTS on top.

> On 24 Aug 2016, at 06:59, stepharo <[hidden email]> wrote:
>
> Hi
>
> We have some ideas (because people are working on items) for the Pharo 6 roadmap
>
> and we will consolidate them soon and propose them to you.
>
> but I would like to know two kinds of points
>
>    - what are the points you are working on and that would deserve more focus and help from the community?
>
>        (these points are important because like that you could go faster and this is a good feeling to get done for example)
>
>    - what would be points where (if magically we would get more resources - to not dream if this is not you
>
>        there is a high chance that we will not make it) it would be nice to get some changes
>
>
> Please pay attention that if you type too fast and come up with a christmas list well it will stay a christmas list and will just make the thread larger for nothing.
>
> Stef
>
>

> Ok, now I know what I want.
>
> I want a better way to document. Because I’m trying to write a documentation about my stuff, but there are too many disconnected ways to do that. I’m trying to always have reasonable class comments. But sometimes you need a more general description, so you write help topics which are disconnected from class comments. Yes, we can add help topics generated from class comments but that’s too weak. Additionally I version my projects on github, so I want t doc there in readme, or on a wiki. What’s more I think that it’s a good idea to export doc to the web. Because when someone mentioned package manifest I started to google for it and could not find anything.
>
> My suggestions:
> - write comments in pillar and slowly add pillar support to enrich comment (documentation) styles
> - add a possibility to reference classes/methods and help topics from pillar comments
> - have exporters to generate html documentation about a project based on comments and help topics
> - then I will be able to add a hook to Icebeg telling it: ok, on commit also generate a doc and export it as MarkDown (because we can) and commit it as a README or as a wiki entry or whatever.
>
> This way we will have interconnected documentation in the image, and if it should be placed somewhere else we export it.

> On Wed, Aug 31, 2016 at 12:00:30PM +0200, Yuriy Tymchuk wrote:
>> Ok, now I know what I want.
>>
>> I want a better way to document. Because I’m trying to write a documentation about my stuff, but there are too many disconnected ways to do that. I’m trying to always have reasonable class comments. But sometimes you need a more general description, so you write help topics which are disconnected from class comments. Yes, we can add help topics generated from class comments but that’s too weak. Additionally I version my projects on github, so I want t doc there in readme, or on a wiki. What’s more I think that it’s a good idea to export doc to the web. Because when someone mentioned package manifest I started to google for it and could not find anything.
>>
>> My suggestions:
>> - write comments in pillar and slowly add pillar support to enrich comment (documentation) styles
>> - add a possibility to reference classes/methods and help topics from pillar comments
>> - have exporters to generate html documentation about a project based on comments and help topics
>> - then I will be able to add a hook to Icebeg telling it: ok, on commit also generate a doc and export it as MarkDown (because we can) and commit it as a README or as a wiki entry or whatever.
>>
>> This way we will have interconnected documentation in the image, and if it should be placed somewhere else we export it.
> +14.
>
> Knowing that I cannot verify that the documentation is sync with code is very discouraging to even start writing the docs. When I was writing a chapter for agile visualization, I had the examples as independent scripts which I could execute (I believe Pillar has added executable examples since then).
>
> But there are more things than examples, e.g. a Travis could run "docs verification" that would look at all the code (so even method and class name references) and made sure they exist and are not, say, deprecated. As Pillar provides you with a real syntax tree this might not be so hard.
>
> At least personally the above could be a real value for me with Pillar, because up until now it was just another document format (and there's a lot of better ones) with poor infrastructure. But deep integration with Pharo could make it really valuable, and we are getting there.
>
>> - then I will be able to add a hook to Icebeg telling it: ok, on commit also generate a doc and export it as MarkDown (because we can) and commit it as a README or as a wiki entry or whatever.
> so close :) https://github.com/peteruhnak/IconFactory/blob/master/repository/BaselineOfIconFactory.package/BaselineOfIconFactory.class/class/updateReadme.st
>
> Peter
>
>