- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Online documentation (was: Help on using Git with Pharo)

by Dimitris Chloupis

Search wise you can use GTSpotter to search help topic, I even added that myself as a plugin to GTSpotter at some point with even the ability to preview help inside GTSpotter. Look wise, sure pharo help isnt the prettiest thing but I would not it say it sucks, it does its job okish, it displays help text. If you want docs that are looking very good, Pillar is doing already that and it outputs in the most portable formats, html and pdf , that makes it easy to take documentation where you cannot use pharo, on tablets and smartphones. As a pharo developer I am very much against of cramming things that already exist outside pharo image and do an incredible good job that would take years if not decades for pharo to catch up , instead of putting things inside to make things harder with close to zero benefit. Lets face it the only reason to put things inside the pharo image is with the promise that we will be modifying , improving and extending them. Documentation however is a large effort by itself , so why not instead of worrying about a Pharo Documentation API , worry about the actual documentation ? Personally I am more interested in reducing the complexity of Pharo and increasing its documentation than the opposite. Funny fact: I used to be a big proponent of onboard/in-image documentation but the great work of the Pillar devs made me change my mind completely. Pillar for me documentation wise is the way forward and it already works incredible well. I would not even complain if the help tool was completely replaced with the a link to the pillar documentation , it does not contain much documentation anyway, nowhere close to the amount and quality of documentation produced by Pillar. On Mon, May 9, 2016 at 10:45 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 09 May 2016, at 09:37, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > How about WebDoc (or similar) serving up the API with class comments to > > make it searchable on the web > > > > Although the in-image help is really bad, I would argue that for the API > itself it's quite the opposite. > > Pharo is centered around code, so there is a lot of different and > amazing ways to search the API and easily find what you are looking for > (including trivially scripted searching). > > I don't think that any web interface can compete with that (unless it's > powered by Pharo itself). > > > > In fact there used to be WebDoc for Pharo API, however as there are no > comments and examples it wasn't useful at all. You can do better search and > actually try the code directly in the image, or search for examples. > > See http://files.pharo.org/doc/ for WebDoc. > > I do totally agree with the fact that Pharo is first and foremost an > in-image IDE, we should concentrate on that. The web based documentation is > mostly relevant for search indexing and newcomers. > > > The wiki would also act as a place where the documentation can evolve > > until it is considered stable enough to include in the image. > > > > For this we have books imho. Simple documentation should be added to > image. > > > > also have links to other blogs, etc. that may not be appropriate for > > in-image documentation > > > > I don't see why not, but it would be better to just copy the content > without having to click (depends on the content). > > >

May 9, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Denis Kudriashov

Hi. I have maybe stupid question. Why Spec needs SpecInterpreter? If I understand correctly it purpose is to parse literal array and create morphs from it. Is it true? If yes then why Spec not uses general literal array parser? (there is one which was born from old discussion about external formats http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals) 2016-05-04 8:19 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi guys > > > this afternoon we will have a meeting with Peter and others to talk about > cleaning Spec API. > > If you want/can join let us know > > else we can organise another skype. > > if you have ideas let us know too. > > Stef > > >

May 9, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50752 Home: https://github.com/pharo-project/pharo-core

May 9, 2016

[pharo-project/pharo-core] 70adff: 50752

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 70adff8caa862f6d5fa0f1ca83ec29d07c526216 https://github.com/pharo-project/pharo-core/commit/70adff8caa862f6d5fa0f1ca… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-09 (Mon, 09 May 2016) Changed paths: M AST-Core.package/RBParser.class/class/parsing/parseMethod_onError_.st M FileSystem-Core.package/AbstractFileReference.class/instance/delegated/exists.st M Nautilus.package/NautilusAnnotationDisplayer.class/instance/submorphs-accessing/formatAsYouReadMorph.st M Nautilus.package/NautilusAnnotationDisplayer.class/instance/submorphs-accessing/lineAnnotationMorph.st M Nautilus.package/NautilusAnnotationDisplayer.class/instance/submorphs-accessing/lineNumbersDisplayLabelMorph.st M Nautilus.package/NautilusAnnotationDisplayer.class/instance/submorphs-accessing/wrappingPolicyLabelMorph.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50751.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50752.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50751.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50752.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50752 18178 Some methods comments in FileReference https://pharo.fogbugz.com/f/cases/18178 18174 Delete the second " of the template method break the image https://pharo.fogbugz.com/f/cases/18174 18168 Add Tooltip to describe Rubric options https://pharo.fogbugz.com/f/cases/18168 http://files.pharo.org/image/50/50752.zip

May 9, 2016

Re: [Pharo-dev] FastTable - beExplicite?

by Denis Kudriashov

Hi. 2016-05-08 22:31 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > Hi Stef, > > A FastTable can have a function to extends it. For example a Search or a > Filter. By default this function is not explicitly shown to the user. > For example in Nautilus the user have to know he can type the name of a > method in the list to search a method. > > With beExplicit the functionality is shown to the user. For the search > and the filter there will be a text field added to the FastTable. > I would call it #showTools/#hideTools

May 9, 2016

Re: [Pharo-dev] Online documentation (was: Help on using Git with Pharo)

by Sven Van Caekenberghe

> On 09 May 2016, at 09:37, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > How about WebDoc (or similar) serving up the API with class comments to > make it searchable on the web > > Although the in-image help is really bad, I would argue that for the API itself it's quite the opposite. > Pharo is centered around code, so there is a lot of different and amazing ways to search the API and easily find what you are looking for (including trivially scripted searching). > I don't think that any web interface can compete with that (unless it's powered by Pharo itself). > > In fact there used to be WebDoc for Pharo API, however as there are no comments and examples it wasn't useful at all. You can do better search and actually try the code directly in the image, or search for examples. See http://files.pharo.org/doc/ for WebDoc. I do totally agree with the fact that Pharo is first and foremost an in-image IDE, we should concentrate on that. The web based documentation is mostly relevant for search indexing and newcomers. > The wiki would also act as a place where the documentation can evolve > until it is considered stable enough to include in the image. > > For this we have books imho. Simple documentation should be added to image. > > also have links to other blogs, etc. that may not be appropriate for > in-image documentation > > I don't see why not, but it would be better to just copy the content without having to click (depends on the content).

May 9, 2016

Re: [Pharo-dev] Online documentation (was: Help on using Git with Pharo)

by Peter UhnÃ¡k

> > How about WebDoc (or similar) serving up the API with class comments to > make it searchable on the web Although the in-image help is really bad, I would argue that for the API itself it's quite the opposite. Pharo is centered around code, so there is a lot of different and amazing ways to search the API and easily find what you are looking for (including trivially scripted searching). I don't think that any web interface can compete with that (unless it's powered by Pharo itself). In fact there used to be WebDoc for Pharo API, however as there are no comments and examples it wasn't useful at all. You can do better search and actually try the code directly in the image, or search for examples. The wiki would also act as a place where the documentation can evolve > until it is considered stable enough to include in the image. For this we have books imho. Simple documentation should be added to image. > also have links to other blogs, etc. that may not be appropriate for > in-image documentation > I don't see why not, but it would be better to just copy the content without having to click (depends on the content).

May 9, 2016

Re: [Pharo-dev] PhD Thesis offer

by jannik laval

Yes ! Now, I need a great student ;), like a smalltalker. Jannik 2016-05-04 18:21 GMT+02:00 stepharo <stepharo(a)free.fr>: > looks like a job for mOose :) > > Le 4/5/16 Ã 12:37, jannik laval a Ã©crit : > > Dear friends, > > I am looking for a french student (or someone speaking french) who wants > to engage in a CIFRE PhD thesis (it is a thesis with a french company). > > The subject is attached to the mail. > > Best regards, > -- > ~~Jannik Laval~~ > Enseignant-chercheur > Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me > d'Information > IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re > laboratoire DISP > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info > > > -- ~~Jannik Laval~~ Enseignant-chercheur Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me d'Information IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re laboratoire DISP http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info

May 9, 2016

Online documentation (was: Help on using Git with Pharo)

by Alistair Grant

On Sun, May 08, 2016 at 05:08:37PM +0200, Peter UhnÃ¡k wrote: > ## 1. Help in general: > > The in-image help sucks hardâ¦ monospaced walls of text, no formatting, no > styling, no images, and zero discoverability. > > Some ideas â this is food for thought for moving forward, not something that I > would expect anyone would do tomorrow: > > ### Simple-ish: online frontend > > * have an online frontend for all the help â because the first place most > people will look is Google, and in-image help doesn't even have elementary > search > * use formattingâ¦ Pillar, Markdown, RST, AsciiDoc, whateverâ¦ for the web > frontend it doesn't matter, there are nice outputs for all of them > * even for the in-image help having some formatting markers might be better > than nothing > > ### Complex-ish > > * improving in-image helpâ¦ Offray is/was working on Jupyter (https:// > try.jupyter.org/) style notebooks. That sounds like a good replacement. > * have at least some basic formattingâ¦ some time ago there was in-image Pillar > editor using GT, so it's doable. +1 How about WebDoc (or similar) serving up the API with class comments to make it searchable on the web, and a wiki that lowers the cost of contributing? The wiki would also act as a place where the documentation can evolve until it is considered stable enough to include in the image. It can also have links to other blogs, etc. that may not be appropriate for in-image documentation Speaking of wikis, what is the status of the collaborActive book? It usually appears near the top of my google searches, but appears to be quite out of date. I'd be happy to update it a bit while still in the learning phase of Pharo if someone can provide credentials. Cheers, Alistair

May 9, 2016

Re: [Pharo-dev] call for cleaning ideas around Spec

by Stephan Eggermont

On 08-05-16 18:34, Peter UhnÃ¡k wrote: > If the difference is 10% maybe the word "most" isn't appropriate, but > you are looking at system, not Spec. There is exactly one user of NewValueHolder outside Spec > Most widgets will instantiate the value holder and then immediately > subscribe to it (either directly in #initialize, or in > #registerEvents), at least for ValueHolders that propagate changes to > Morphic. Most properties in a user interface are optional. We need to design for that > Regardless of that I said _will_, because that's the idea behind the > new Adapters, currently in the image only TabModel/MorphicTabAdapter > use it. What is the impact of that on debugability? Stephan

May 8, 2016