May 2016 - Pharo-dev - lists.pharo.org

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

by Denis Kudriashov

2016-05-09 13:37 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Wow, this is ugly. I like the real "self topSpec" call in the middle of > it. :) > > But even then, this is still a regular Pharo (dynamic) array, so no need > to parse itâ¦ but don't use it like this. :) > By parsing array I mean converting array into underlying object.

May 9, 2016

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

by Peter UhnÃ¡k

On Mon, May 9, 2016 at 1:22 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-05-09 11:38 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> No. Morphs are created by Adapters, Spec interpreter instantiates glues >> everything together. >> Regardless, there's no parsing involvedâ¦ what is there to parse? There >> are no literal arrays anywhere. >> The SpecLayout (that we called array last week), is not an array, it's a >> composition of real objects >> >> defaultSpec >> ^ SpecLayout composed >> newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: >> self toolbarHeight ] ] >> height: self toolbarHeight; >> newRow: [ :row | >> row >> newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 >> @ 1; >> addSplitter; >> newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ >> 1; >> addSplitter; >> newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ] >> top: self toolbarHeight; >> yourself >> > > Maybe array approach deprecated? But in first demos of Spec it was like > this: > > CheckBoxExample class>>defaultSpec > > ^ { #ContainerModel. > #add:. { self topSpec. #layout:. #(#SpecLayoutFrame > bottomFraction: 0 > bottomOffset: 20) }. > #add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: > 22) } > } > > (Actually it is from Pharo 5 image). > Wow, this is ugly. I like the real "self topSpec" call in the middle of it. :) But even then, this is still a regular Pharo (dynamic) array, so no need to parse itâ¦ but don't use it like this. :) Peter

May 9, 2016

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

by Denis Kudriashov

2016-05-09 11:38 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > No. Morphs are created by Adapters, Spec interpreter instantiates glues > everything together. > Regardless, there's no parsing involvedâ¦ what is there to parse? There are > no literal arrays anywhere. > The SpecLayout (that we called array last week), is not an array, it's a > composition of real objects > > defaultSpec > ^ SpecLayout composed > newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self > toolbarHeight ] ] > height: self toolbarHeight; > newRow: [ :row | > row > newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ > 1; > addSplitter; > newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ > 1; > addSplitter; > newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ] > top: self toolbarHeight; > yourself > Maybe array approach deprecated? But in first demos of Spec it was like this: CheckBoxExample class>>defaultSpec ^ { #ContainerModel. #add:. { self topSpec. #layout:. #(#SpecLayoutFrame bottomFraction: 0 bottomOffset: 20) }. #add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) } } (Actually it is from Pharo 5 image).

May 9, 2016

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

by Peter UhnÃ¡k

On Mon, May 9, 2016 at 11:02 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 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) > No. Morphs are created by Adapters, Spec interpreter instantiates glues everything together. Regardless, there's no parsing involvedâ¦ what is there to parse? There are no literal arrays anywhere. The SpecLayout (that we called array last week), is not an array, it's a composition of real objects defaultSpec ^ SpecLayout composed newRow: [ :row | row newColumn: [ :col | col add: #topToolbar height: self toolbarHeight ] ] height: self toolbarHeight; newRow: [ :row | row newColumn: [ :col | col add: #navigatorModel ] origin: 0 @ 0 corner: 0.2 @ 1; addSplitter; newColumn: [ :col | col add: #tabManager ] origin: 0.2 @ 0 corner: 0.85 @ 1; addSplitter; newColumn: [ :col | col add: #formModel ] origin: 0.85 @ 0 corner: 1 @ 1 ] top: self toolbarHeight; yourself Peter > > 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

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

by Esteban Lorenzano

> On 09 May 2016, at 11:10, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > 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. this would be something nice to add :) > > 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. yes, but we need something better, in the future. Esteban > > 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 <mailto:sven@stfx.eu>> wrote: > > > On 09 May 2016, at 09:37, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@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/ <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] FastTable easyList examples are broken

by Esteban Lorenzano

they work for me (latest Pharo5) > On 08 May 2016, at 21:31, stepharo <stepharo(a)free.fr> wrote: > > Hi > > > I started to play with FastTable and some of the examples are broken. > > For example exampleEasyList* > > > Stef > >

May 9, 2016

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