Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[stepharo]

On Fri, Sep 16, 2016 at 2:45 AM, stepharo  wrote:

Hi all

I want something similar in the spirit to PythonDocTest
https://docs.python.org/2/library/doctest.html

I'm talking about

basename
 "Returns the base of the basename,
 i.e.
 /foo/gloops.taz basename is 'gloops.taz'
 / basename is '/'"

Pragmas do not work well i.e.,
basename
 "Returns the base of the basename"
  


We should invent a syntax to be put inside comments and that we can easily
parse because we need to improve
the use and discovery of the library.

I was thinking about

basename
 "Returns the base of the basename"
 "
 '/foo/gloops.taz' asFileReference basename
 >>> 'gloops.taz'
 "

Do you have any idea?

basename
  "Returns the base of the basename"
  """
  '/foo/gloops.taz' asFileReference basename
 ==> 'gloops.taz'
  """
 self size == 0
 "the root node"
 ifTrue: [ ^ '/'].
  ^ self at: self size

I like this idea.  But a fine semantic
We should think of these less as "tests"
and more as "howto" snippets that are tested for correctness.

They should show just the *simplest* was to get an object to which the
method can be sent.
Maybe they could be also displayed via the gtExample interface ??


May be. Right now I want to make sure that all the little examples that 
are written for example

inside methods are correct.

Stef


cheers -ben

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[stepharo]

Furthermore, typical examples require more than one liners, and
these should be factored out separately.


I really like the one liners that you can find im some method 
comments, like in Color class>>#wheel:
if you are new to pharo and start exploring the system, it makes fun 
to see these little one lines and
just execute it. (even if they aren't onelines like in some method in 
class Form).


Me too and what I like is that there are coupled to the method.
I find a method and I guess it will help me
and bam I read the example and I'm sure it is or not what I'm looking for.

Stef



Cheers,
Doru


>
>   Marcus
>
>
>
>
>
>

--
www.tudorgirba.com 
www.feenk.com 

"Every thing should have the right to be different."

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[stepharo]

So, until know, I didn't really know what pythondoctest is about.  I 
first thought the "test" is about unit tests
and thought our way how we can generate or jump from methods to the 
corresponding is better,
but know I understand that it is about "perform regression testing by 
verifying that interactive examples are working"

And that is of course a good idea.


To me this is more than that.
This is having simple scenario always validated and in front of my nose 
when I read the code.






If we have ' ' then it would be good that the syntax higlighter
works with a special mode inside the ' '


Not for pragma arguments, I think this would be confusing.

Yes I cam to the same conclusion than marcus.


I did some expreiments with formatting code in comments. I 'll write 
shortly about it.





nicolai



Stef


  60220
19086 do not allow expressions as pragma arguments
https://pharo.fogbugz.com/f/cases/19086

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[Ben Coman]

On Fri, Sep 16, 2016 at 2:45 AM, stepharo  wrote:
> Hi all
>
> I want something similar in the spirit to PythonDocTest
> https://docs.python.org/2/library/doctest.html
>
> I'm talking about
>
> basename
> "Returns the base of the basename,
> i.e.
> /foo/gloops.taz basename is 'gloops.taz'
> / basename is '/'"
>
> Pragmas do not work well i.e.,
> basename
> "Returns the base of the basename"
>   'gloops.taz'>
>
>
> We should invent a syntax to be put inside comments and that we can easily
> parse because we need to improve
> the use and discovery of the library.
>
> I was thinking about
>
> basename
> "Returns the base of the basename"
> "
> '/foo/gloops.taz' asFileReference basename
> >>> 'gloops.taz'
> "
>
> Do you have any idea?

basename
 "Returns the base of the basename"
 """
 '/foo/gloops.taz' asFileReference basename
==> 'gloops.taz'
 """
self size == 0
"the root node"
ifTrue: [ ^ '/'].
 ^ self at: self size

I like this idea.  But a fine semantic
We should think of these less as "tests"
and more as "howto" snippets that are tested for correctness.

They should show just the *simplest* was to get an object to which the
method can be sent.
Maybe they could be also displayed via the gtExample interface ??

cheers -ben

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[p...@highoctane.be]

I'd be more interested with a package level doc than a class doc or test.

Package level doc is quite useful to outline how some things are working
together, something which is quite hard to figure out except by reading
external doc or inferring things by walking through the code or a running
test.

Having the ability to read about a package would be very useful. Basically,
this is what Java provides.

http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javadoc.html#packagecomment

Phil


On Thu, Sep 15, 2016 at 8:45 PM, stepharo  wrote:

> Hi all
>
> I want something similar in the spirit to PythonDocTest
> https://docs.python.org/2/library/doctest.html
>
> I'm talking about
>
> basename
> "Returns the base of the basename,
> i.e.
> /foo/gloops.taz basename is 'gloops.taz'
> / basename is '/'"
>
> Pragmas do not work well i.e.,
> basename
> "Returns the base of the basename"
>   'gloops.taz'>
>
>
> We should invent a syntax to be put inside comments and that we can easily
> parse because we need to improve
> the use and discovery of the library.
>
> I was thinking about
>
> basename
> "Returns the base of the basename"
> "
> '/foo/gloops.taz' asFileReference basename
> >>> 'gloops.taz'
> "
>
> Do you have any idea?
>
> I cannot not do anything and just complain that our methods are not that
> well documented.
> We as a community should take this and build an super cool system.
>
> I tried and defined >>> on Object to see if it works!
>
> Object >>> aResultingObject
> "If the method comment contains >>> then it is a pharo documentated
> test. We can check that it is true."
>
> "
> '/foo/gloops.taz' asFileReference basename
>>>> 'gloops.taz'
> "
>
> ^ self = aResultingObject
>
>
> Stef
>
>
>

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[Nicolai Hess]

2016-09-15 20:45 GMT+02:00 stepharo :

> Hi all
>
> I want something similar in the spirit to PythonDocTest
> https://docs.python.org/2/library/doctest.html
>
> I'm talking about
>
> basename
> "Returns the base of the basename,
> i.e.
> /foo/gloops.taz basename is 'gloops.taz'
> / basename is '/'"
>
> Pragmas do not work well i.e.,
> basename
> "Returns the base of the basename"
>   'gloops.taz'>
>
>
> We should invent a syntax to be put inside comments and that we can easily
> parse because we need to improve
> the use and discovery of the library.
>
> I was thinking about
>
> basename
> "Returns the base of the basename"
> "
> '/foo/gloops.taz' asFileReference basename
> >>> 'gloops.taz'
> "
>
> Do you have any idea?
>
> I cannot not do anything and just complain that our methods are not that
> well documented.
> We as a community should take this and build an super cool system.
>
> I tried and defined >>> on Object to see if it works!
>
> Object >>> aResultingObject
> "If the method comment contains >>> then it is a pharo documentated
> test. We can check that it is true."
>
> "
> '/foo/gloops.taz' asFileReference basename
>>>> 'gloops.taz'
> "
>
> ^ self = aResultingObject
>
>
Ok, this is a quick hack ( do not look at the code :), yes using regex here
is a bit fragil)

You can add code in comments between backticks (`)
The formatter will highlight the text like smalltalk code (or not if it is
not valid code).
+ an icon styler with an icon showing a warning icon for faulty code or an
information icon otherwise
you can click on the icon,

if the code is an association

expression -> result

it executes the expression and compares it with the result, (with
assert:equals: ) opens debugger if it fails and does
nothing otherwise

if the code is just an expression, it opens an inspector.

This is just one way to do some tests and experiments with this idea, don
't yet know if this is a good idea or if
we can / should find a better way to connect code with examples.

first result, I find expressions in comments, highlighted as code,
confusing :)

(file in attached cs in a recent pharo 6.0 and look at the method
AbstractFileReference>>#baseName . Or
add an expression with backticks in a method comment
` your code here `




>
> Stef
>
>
>
'From Pharo6.0 of 13 May 2016 [Latest update: #60225] on 15 September 2016 at 
10:27:15.932951 pm'!
IconStyler subclass: #ExampleIconStyler
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Reflectivity-Tools-Breakpoints'!

!AbstractFileReference methodsFor: 'accessing' stamp: 'NicolaiHess 9/15/2016 
22:25'!
basename
"Returns the basename, i.e. /foo/gloops.taz basename is 'gloops.taz'
` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.` <- 
suceeds, no output
` '/foo/gloops.taz' asFileReference basename -> 'gloops.ta'.`   <- 
fails, shows asserter
` '/foo/gloops.taz' asFileReference basename` < opens inspector

"
^ self fullPath basename! !


!ExampleIconStyler methodsFor: 'as yet unclassified' stamp: 'NicolaiHess 
9/15/2016 14:37'!
iconBlock: aNode
^ (self exampleIsFaulty: aNode)
ifTrue: [ self notifySourceError: aNode ]
ifFalse: [self runExampleBlock: aNode]! !

!ExampleIconStyler methodsFor: 'as yet unclassified' stamp: 'NicolaiHess 
9/15/2016 14:38'!
iconFor: aNode
^ (self exampleIsFaulty: aNode)
ifTrue: [ self iconProvider iconNamed: #smallWarning ]
ifFalse: [ self iconProvider iconNamed: #smallInfo ]! !

!ExampleIconStyler methodsFor: 'as yet unclassified' stamp: 'NicolaiHess 
9/15/2016 14:35'!
exampleIsFaulty: aNode
^ aNode comments
anySatisfy: [ :commentNode | commentNode exampleNodes 
anySatisfy:[:node |
node value isFaulty ]]! !

!ExampleIconStyler methodsFor: 'as yet unclassified' stamp: 'NicolaiHess 
9/15/2016 14:39'!
notifySourceError: aNode
^ [ | examples faultyExample |
examples := aNode comments flatCollect: #exampleNodes.
faultyExample := examples detect: [ :example | example value isFaulty ].
RBParser parseExpression: faultyExample value source ]! !

!ExampleIconStyler methodsFor: 'as yet unclassified' stamp: 'NicolaiHess 
9/15/2016 12:53'!
shouldStyleNode: aNode
^ (aNode isMethod and: [ aNode comments isEmpty not ])
and: [ aNode comments anySatisfy: [ :commentNode | commentNode 
exampleNodes isNotEmpty ] ]! !

!ExampleIconStyler methodsFor: 'as yet unclassified' stamp: 'NicolaiHess 
9/15/2016 14:44'!
iconLabel: aNode
"3+4"
^ (self exampleIsFaulty: aNode)
ifTrue: [ 'Faulty Example' ]
ifFalse: [ 'Runnable Examle' ]! !

!ExampleIconStyler methodsFor: 'as yet unclassified' stamp: 'NicolaiHess 
9/15/2016 14:37'!
runExampleBlock: 

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Tudor Girba]

Hi,

> On Sep 15, 2016, at 10:16 PM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-09-15 8:12 GMT+02:00 Tudor Girba :
> Hi,
> 
> > On Sep 15, 2016, at 7:50 AM, Marcus Denker  wrote:
> >
> >
> >>>
> >>> We can change it back and maybe add support for the reformatter to not 
> >>> convert it to the literal array #(3 #+ 4) .
> >>
> >> I do not know in fact this is why I asked :)
> >> Now may be my idea to use pragma to get something like pythondoctest is a 
> >> bad idea
> >> but I really want to have literal programming.
> >> What do you think?
> >>
> > I like the idea to show examples/tests close to code, but pragmas are not 
> > really good...
> >
> >> If we have ' ' then it would be good that the syntax higlighter works with 
> >> a special mode inside the ' '
> >
> > it is just a string. How do you know that it contains code?
> >
> > Would you highlight all string in all code as if it contained code? Or 
> > would you add this just for
> > Pragmas? But even there, strings are string, not code.
> >
> > I think we can conclude that pragmas are not a good solution to the 
> > problem, as they are far
> > too limited to express code.
> 
> I second that.
> 
> Furthermore, typical examples require more than one liners, and these should 
> be factored out separately.
> 
> I really like the one liners that you can find im some method comments, like 
> in Color class>>#wheel:
> if you are new to pharo and start exploring the system, it makes fun to see 
> these little one lines and
> just execute it. (even if they aren't onelines like in some method in class 
> Form).
> 

I like one liners, too. But, should a documentation mechanism be confined to 
only work with small examples?

Cheers,
Doru


> Cheers,
> Doru
> 
> 
> >
> >   Marcus
> >
> >
> >
> >
> >
> >
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Every thing should have the right to be different."

--
www.tudorgirba.com
www.feenk.com

"Reasonable is what we are accustomed with."

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[Esteban A. Maringolo]

2016-09-15 17:09 GMT-03:00 Tudor Girba :
> However, one thing to keep in mind is that one reason why these solutions 
> exist is because they assume no UI environment. Thus, the only thing they 
> have is text and the solution is built around it.
>
> In Pharo, we can think of concatenating information in the environment. If we 
> have a casual connection between examples and the code they exemplify, the 
> interface can provide all this information at the same time. The advantage 
> here is that the syntax remains simple.

+1

I wouldn't like that syntax, nor PharoDoc (a la JavaDoc), nor anything
"polluting" the code that way.

The comment or examples can be attributes of the method itself, just
like the class comment are today.

Regards!

Esteban A. Maringolo

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Nicolai Hess]

2016-09-15 8:12 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Sep 15, 2016, at 7:50 AM, Marcus Denker 
> wrote:
> >
> >
> >>>
> >>> We can change it back and maybe add support for the reformatter to not
> convert it to the literal array #(3 #+ 4) .
> >>
> >> I do not know in fact this is why I asked :)
> >> Now may be my idea to use pragma to get something like pythondoctest is
> a bad idea
> >> but I really want to have literal programming.
> >> What do you think?
> >>
> > I like the idea to show examples/tests close to code, but pragmas are
> not really good...
> >
> >> If we have ' ' then it would be good that the syntax higlighter works
> with a special mode inside the ' '
> >
> > it is just a string. How do you know that it contains code?
> >
> > Would you highlight all string in all code as if it contained code? Or
> would you add this just for
> > Pragmas? But even there, strings are string, not code.
> >
> > I think we can conclude that pragmas are not a good solution to the
> problem, as they are far
> > too limited to express code.
>
> I second that.
>
> Furthermore, typical examples require more than one liners, and these
> should be factored out separately.
>

I really like the one liners that you can find im some method comments,
like in Color class>>#wheel:
if you are new to pharo and start exploring the system, it makes fun to see
these little one lines and
just execute it. (even if they aren't onelines like in some method in class
Form).


>
> Cheers,
> Doru
>
>
> >
> >   Marcus
> >
> >
> >
> >
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Every thing should have the right to be different."
>
>
>
>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Nicolai Hess]

2016-09-14 21:24 GMT+02:00 stepharo :

>
> Hi nicolai
>>
>> Why we should not accept
>>
>> foo
>> 
>> ^ self
>>
>> and be forced to put around ''
>>
>> foo
>> < func: '(3+4)' res: 0 >
>> ^ self
>>
>> I understand that we store literal but why you do not like it :).
>>
>
> First of all, the old compiler did not accept this. And I am a bit
> sensitive about changes, we allow a different syntax
> just because RB happens  to allow this (and maybe no one knows why or it
> just does not happens on purpose).
>
>
> valid point.
>
>
> And another reason, even without my fix, if we don't put quotes around
> that expression, the reformatting the source will convert this to:
>
> foo
> 
> ^ self
>
> What I noticed is that I could not write
>
>  foo
> 
>
> but it worked when I put () so I did it in the new code I wrote.
>
> And, even if (3+4) looks like an expression, it is just a list of literals
> something like this:
>
> foo
> 
> ^ self
>
> would be allowed too.
>
> This one is ugly
>
> But of course this is only my own opinion :)
>
> We can change it back and maybe add support for the reformatter to not
> convert it to the literal array #(3 #+ 4) .
>
>
> I do not know in fact this is why I asked :)
> Now may be my idea to use pragma to get something like pythondoctest is a
> bad idea
> but I really want to have literal programming.
> What do you think?
>

So, until know, I didn't really know what pythondoctest is about.  I first
thought the "test" is about unit tests
and thought our way how we can generate or jump from methods to the
corresponding is better,
but know I understand that it is about "perform regression testing by
verifying that interactive examples are working"
And that is of course a good idea.



>
> If we have ' ' then it would be good that the syntax higlighter works with
> a special mode inside the ' '
>

Not for pragma arguments, I think this would be confusing.

I did some expreiments with formatting code in comments. I 'll write
shortly about it.

>
>
> nicolai
>
>
>
>> Stef
>>
>>
>>   60220
>>> 19086 do not allow expressions as pragma arguments
>>> https://pharo.fogbugz.com/f/cases/19086
>>>
>>
>>
>>
>
>

Re: [Pharo-dev] [pharo-project/pharo-core] 4d8aa6: 60226

[stepharo]

This change break the miniimage. I will check with pavel.

Stef


Le 15/9/16 à 22:05, GitHub a écrit :

   Branch: refs/heads/6.0
   Home:   https://github.com/pharo-project/pharo-core
   Commit: 4d8aa66f6cb150f6aef66a9d807106bb89404cf5
   
https://github.com/pharo-project/pharo-core/commit/4d8aa66f6cb150f6aef66a9d807106bb89404cf5
   Author: Jenkins Build Server 
   Date:   2016-09-15 (Thu, 15 Sep 2016)

   Changed paths:
 M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/class/icons/taskbarIcon.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAccept.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAdd.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAlarm.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBookmark.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBrowse.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBug.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousCancel.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousClose.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousDown.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousDropDown.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousEdit.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousExample.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousFolder.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGo.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGrayCircle.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGrayCircleEmpty.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGreenCircle.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousHelp.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousInspect.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousInto.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLargeGrayCircleEmphasized.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLeft.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLeftSide.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousMore.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOpen.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOpenFromUrl.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOver.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousPlay.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRedCircle.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRedo.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRefresh.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRemove.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRestart.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRight.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRightSide.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSave.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSaveToUrl.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSearch.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSpawn.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousThrough.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousTrash.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousUndo.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousUp.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousZoomIn.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousZoomOut.st
 M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousZoomToFit.st
 M 
Glamour-Morphic-Theme.packa

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[Tudor Girba]

Hi,

I think this is an interesting idea.

However, one thing to keep in mind is that one reason why these solutions exist 
is because they assume no UI environment. Thus, the only thing they have is 
text and the solution is built around it.

In Pharo, we can think of concatenating information in the environment. If we 
have a casual connection between examples and the code they exemplify, the 
interface can provide all this information at the same time. The advantage here 
is that the syntax remains simple.

At the same time, we also want to have Pillar more thoroughly supported in our 
tools. Could it be that we could extend Pillar to support literate programming?

Cheers,
Doru


> On Sep 15, 2016, at 8:45 PM, stepharo  wrote:
> 
> Hi all
> 
> I want something similar in the spirit to PythonDocTest 
> https://docs.python.org/2/library/doctest.html
> 
> I'm talking about
> 
> basename
>"Returns the base of the basename,
>i.e.
>/foo/gloops.taz basename is 'gloops.taz'
>/ basename is '/'"
> 
> Pragmas do not work well i.e.,
> basename
>"Returns the base of the basename"
>  'gloops.taz'>
> 
> 
> We should invent a syntax to be put inside comments and that we can easily 
> parse because we need to improve
> the use and discovery of the library.
> 
> I was thinking about
> 
> basename
>"Returns the base of the basename"
>"
>'/foo/gloops.taz' asFileReference basename
>>>> 'gloops.taz'
>"
> 
> Do you have any idea?
> 
> I cannot not do anything and just complain that our methods are not that well 
> documented.
> We as a community should take this and build an super cool system.
> 
> I tried and defined >>> on Object to see if it works!
> 
> Object >>> aResultingObject
>"If the method comment contains >>> then it is a pharo documentated test. 
> We can check that it is true."
> 
>"
>'/foo/gloops.taz' asFileReference basename
>   >>> 'gloops.taz'
>"
> 
>^ self = aResultingObject
> 
> 
> Stef
> 
> 

--
www.tudorgirba.com
www.feenk.com

"It's not how it is, it is how we see it."

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 4d8aa6: 60226

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 4d8aa66f6cb150f6aef66a9d807106bb89404cf5
  
https://github.com/pharo-project/pharo-core/commit/4d8aa66f6cb150f6aef66a9d807106bb89404cf5
  Author: Jenkins Build Server 
  Date:   2016-09-15 (Thu, 15 Sep 2016)

  Changed paths:
M 
FontChooser.package/AbstractFontSelectorDialogWindow.class/class/icons/taskbarIcon.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAccept.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAdd.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousAlarm.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBookmark.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBrowse.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousBug.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousCancel.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousClose.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousDown.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousDropDown.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousEdit.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousExample.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousFolder.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGo.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGrayCircle.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGrayCircleEmpty.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousGreenCircle.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousHelp.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousInspect.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousInto.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLargeGrayCircleEmphasized.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLeft.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousLeftSide.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousMore.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOpen.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOpenFromUrl.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousOver.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousPlay.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRedCircle.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRedo.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRefresh.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRemove.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRestart.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRight.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousRightSide.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSave.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSaveToUrl.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSearch.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousSpawn.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousThrough.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousTrash.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousUndo.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousUp.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousZoomIn.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousZoomOut.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamorousZoomToFit.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamourousNextFailure.st
M 
Glamour-Morphic-Theme.package/GLMUIThemeExtraIcons.class/class/icons/glamourousNextPar

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[Tudor Girba]

Hi,

Given the current interest, I am raising the issue of GTExample again.

I sent a while ago a thorough description of the current solution:
http://gtoolkit.org/doc/Examples/examples.html

The goal is to provide documentation for all methods and classes both by 
allowing simple examples (plain unary methods) and offering the potential of 
doing more than just simple things.

Except for Nicolai, there was no other feedback. Is there an interest to have a 
conversation about it?

Cheers,
Doru


> On Sep 15, 2016, at 8:40 PM, stepharo  wrote:
> 
>>> Would you highlight all string in all code as if it contained code? Or 
>>> would you add this just for
>>> Pragmas? But even there, strings are string, not code.
> and then? you try and if it failed then in not code and you do not highlight 
> it.
> KISS. No?
>>> I think we can conclude that pragmas are not a good solution to the 
>>> problem, as they are far
>>> too limited to express code.
>> I second that.
>> Furthermore, typical examples require more than one liners, and these should 
>> be factored out separately.
> 
> I'm talking about
> 
> basename
>"Returns the base of the basename,
>i.e.
>/foo/gloops.taz basename is 'gloops.taz'
>/ basename is '/'"
> 
> I do not think that it makes sense to have a separate example for this.
> Because you want to read everything
> 
> 
> I do not see why the following would not work.
> basename
>"Returns the base of the basename"
>  'gloops.taz'>
> 
> Now I hate the extra ' for strings.
> We should invent a syntax to be put inside comments and that we can easily 
> parse because we need to improve
> the use and discovery of the library.
> 
> basename
>"Returns the base of the basename"
>"
>'/foo/gloops.taz' asFileReference basename
>>>> 'gloops.taz'
>"
> 
> I cannot not do anything and just complain that our methods are not that well 
> documented.
> We as a community should take this and build an super cool system.
> 
> 
> Stef
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."

[Pharo-dev] need new pharo features for phratch and community

[jannik laval]

Hi pharoers,

regularly, I have french teachers that ask me for new addons for phratch.
These teachers don't like Scratch 2 or Snap! because of latency or used
language or because it needs a web browser...

I have 3 important points that I cannot answer because of a lack of time:
- having phratch on RPi
- making Arduino working with phratch
- having sound working on linux and RPi

These features do not depends on phratch but on pharo. I use fully
functions of pharo. But I don't have time to develop now on that.
Could someone help me ?

Thank you
Jannik

-- 
~~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

[Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[stepharo]

Hi all

I want something similar in the spirit to PythonDocTest 
https://docs.python.org/2/library/doctest.html


I'm talking about

basename
"Returns the base of the basename,
i.e.
/foo/gloops.taz basename is 'gloops.taz'
/ basename is '/'"

Pragmas do not work well i.e.,
basename
"Returns the base of the basename"
 'gloops.taz'>



We should invent a syntax to be put inside comments and that we can 
easily parse because we need to improve

the use and discovery of the library.

I was thinking about

basename
"Returns the base of the basename"
"
'/foo/gloops.taz' asFileReference basename
>>> 'gloops.taz'
"

Do you have any idea?

I cannot not do anything and just complain that our methods are not that 
well documented.

We as a community should take this and build an super cool system.

I tried and defined >>> on Object to see if it works!

Object >>> aResultingObject
"If the method comment contains >>> then it is a pharo documentated 
test. We can check that it is true."


"
'/foo/gloops.taz' asFileReference basename
   >>> 'gloops.taz'
"

^ self = aResultingObject


Stef

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

[stepharo]

Would you highlight all string in all code as if it contained code? Or would 
you add this just for
Pragmas? But even there, strings are string, not code.
and then? you try and if it failed then in not code and you do not 
highlight it.

KISS. No?

I think we can conclude that pragmas are not a good solution to the problem, as 
they are far
too limited to express code.

I second that.
Furthermore, typical examples require more than one liners, and these should be 
factored out separately.


I'm talking about

basename
"Returns the base of the basename,
i.e.
/foo/gloops.taz basename is 'gloops.taz'
/ basename is '/'"

I do not think that it makes sense to have a separate example for this.
Because you want to read everything


I do not see why the following would not work.
basename
"Returns the base of the basename"
 'gloops.taz'>


Now I hate the extra ' for strings.
We should invent a syntax to be put inside comments and that we can 
easily parse because we need to improve

the use and discovery of the library.

basename
"Returns the base of the basename"
"
'/foo/gloops.taz' asFileReference basename
>>> 'gloops.taz'
"

I cannot not do anything and just complain that our methods are not that 
well documented.

We as a community should take this and build an super cool system.


Stef

[Pharo-dev] 60224 TestRunner warning Collections-Arithmetic manually resolved dependency not detected as a dependency!

[Ben Coman]

This curious warning appeared when running TestRunner in a fresh
60224.image... Collections-Abstract: Collections-Arithmetic dependency
declared in the package Manifest as manuallyResolvedDependencies not
detected as a dependency!

There is...
ManifestCollectionsArithmetic class >> dependencies
^ #(#'Collections-Native' #'Collections-Unordered'
#'Collections-Sequenceable' #Kernel #'Collections-Abstract')

and removing the last element makes the error go away, but I was
wondering if that was the RightThing or the warning was a symptom for
something else?

btw, was is "manually resolved" ?  Is it just adding elements to #dependencies?

cheers -ben

Re: [Pharo-dev] Author / TestRunner interaction in fresh image

[Marcus Denker]

> On 15 Sep 2016, at 18:38, Ben Coman  wrote:
> 
> In a freshly downloaded build 60224, I open TestRunner and run all
> tests.  At run 418 I get a dialogue asking for the Author.  To me that
> seems wrong.  I don't want any code changes made during testing to
> have my normal identification on them. Tests invoked from Test Runner
> should be author-tagged something like 'TestRunner' or
> 'TestRunner-BenComan'.
> 
> The question arises in this particular case due to...
>  RPackageMonticelloSynchronisationTest >> setUp
>  ...
>  Author fullName ifNil: [ Author fullName: 'Tester' ].
> 
> Minor point... this check actually is a bit pointless since #fullName
> invokes #requestFullName that presents the dialog.  And #fullName will
> *never* return nil. At a minimum it returns 'Anonymous'.
> 
> First step would seem to be wrapping  TestCase>>runCase:
> with   Author useAuthor: 'TestRunner' during: [  ]
> 

Yes, something like this this would be good.

> But further. I envisage a time when TestRunner doesn't block the UI,
> so I can happily browse around the system and code while TestRunner is
> doing its thing.  Obviously the system is not set up to have two
> parties (myself and TestRunner) both updating code in the system, but
> changing the state of the global Author uniqueInstance like this…
> 

Yes, Nautilus used to fork running tests… leads to lots of strange problems.

> 
> would itself seem to a big impediment.   It would be good if "Author"
> was dependent on the context of the call chain.This would seem a
> requirement for one day having two people working in the one Image (is
> this a possible use case where someone is using a remote debugger
> while another person is using the standard UI?)
> 
Could it be part of Denis new ExecutionEnvironment concept?

Marcus

[Pharo-dev] Author / TestRunner interaction in fresh image

[Ben Coman]

In a freshly downloaded build 60224, I open TestRunner and run all
tests.  At run 418 I get a dialogue asking for the Author.  To me that
seems wrong.  I don't want any code changes made during testing to
have my normal identification on them. Tests invoked from Test Runner
should be author-tagged something like 'TestRunner' or
'TestRunner-BenComan'.

The question arises in this particular case due to...
  RPackageMonticelloSynchronisationTest >> setUp
  ...
  Author fullName ifNil: [ Author fullName: 'Tester' ].

Minor point... this check actually is a bit pointless since #fullName
invokes #requestFullName that presents the dialog.  And #fullName will
*never* return nil. At a minimum it returns 'Anonymous'.

First step would seem to be wrapping  TestCase>>runCase:
with   Author useAuthor: 'TestRunner' during: [  ]

But further. I envisage a time when TestRunner doesn't block the UI,
so I can happily browse around the system and code while TestRunner is
doing its thing.  Obviously the system is not set up to have two
parties (myself and TestRunner) both updating code in the system, but
changing the state of the global Author uniqueInstance like this...

   Author>>useAuthor: aString during: aBlock
  ^ self uniqueInstance useAuthor: aString during: aBlock

would itself seem to a big impediment.   It would be good if "Author"
was dependent on the context of the call chain.This would seem a
requirement for one day having two people working in the one Image (is
this a possible use case where someone is using a remote debugger
while another person is using the standard UI?)

So my second proposal is for Author>>fullName to invoke a Notification
mechanism to determine #fullName.  Something like...

 Notification subclass: AuthorRequest

 Author>>#fullName
   ^ AuthorRequest new signal
   instanceVariables: 'contextFullName'.

Author>>useAuthor: tempAuthorFullname during: aBlock
  [ block ]
 on: AuthorRequest
 do: [ :noti | noti contextFullName: tempAuthorFullname ]

with only unhandled AuthorRequests returning "Author uniqueInstance
basicFullname".

Thus code changes are not constrained to be assigned to a global
author.  Not that we *yet* have multiple people working in one image,
but one more impediment is removed - step by step.

What concerns would there be?

cheers -ben

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] a5ac37: 60225

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: a5ac374f7d5509a57e8bf39fc40c332026b0c2d3
  
https://github.com/pharo-project/pharo-core/commit/a5ac374f7d5509a57e8bf39fc40c332026b0c2d3
  Author: Jenkins Build Server 
  Date:   2016-09-15 (Thu, 15 Sep 2016)

  Changed paths:
A 
Collections-Tests.package/WeakSetTest.class/instance/testing/testAnyOneWhenAllContentsWasGarbaged.st
A Collections-Weak.package/WeakSet.class/instance/accessing/anyOne.st
A Kernel-Tests.package/ClassDescriptionTest.class/instance/tests - 
slots/testprintHierarchy.st
A Kernel-Tests.package/ClassDescriptionTest.class/instance/tests - 
slots/testprintSubclassesOnLevelFilterA.st
A Kernel-Tests.package/ClassDescriptionTest.class/instance/tests - 
slots/testprintSubclassesOnLevelFilterB.st
A Kernel-Tests.package/ClassDescriptionTest.class/instance/tests - 
slots/testprintSubclassesOnLevelFilterNil.st
M Monticello.package/MCPackageManager.class/class/system 
changes/methodModified_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60224.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60225.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60224.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60225.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M System-Support.package/SmalltalkImage.class/instance/sources%2C change 
log/systemInformationString.st
M Traits.package/TClassDescription.class/instance/accessing class 
hierarchy/printSubclassesOn_level_.st
A Traits.package/TClassDescription.class/instance/accessing class 
hierarchy/printSubclassesOn_level_filter_.st

  Log Message:
  ---
  60225
19093 WeakSet anyOne is not work correctly when only nil there
https://pharo.fogbugz.com/f/cases/19093

19089 About dialog: add a space to Pharo6.0...
https://pharo.fogbugz.com/f/cases/19089

17881 loading package which add extension method to trait from external package 
makes loadable package dirty
https://pharo.fogbugz.com/f/cases/17881

19077 extend ClassDescription>>printSubclassesOn:level: to have a filter
https://pharo.fogbugz.com/f/cases/19077

http://files.pharo.org/image/60/60225.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] a9e59a: 60224

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: a9e59aa91f1a228be0f2775026a7007eae3570c8
  
https://github.com/pharo-project/pharo-core/commit/a9e59aa91f1a228be0f2775026a7007eae3570c8
  Author: Jenkins Build Server 
  Date:   2016-09-15 (Thu, 15 Sep 2016)

  Changed paths:
M Kernel.package/Metaclass.class/instance/instance 
creation/newAnonymousSubclass.st
M 
SUnit-Core.package/TestExecutionEnvironment.class/instance/controlling/checkForkedProcesses.st
M 
SUnit-Core.package/TestExecutionEnvironment.class/instance/controlling/runTestCase_.st
A 
SUnit-Tests.package/SUnitTest.class/instance/private/failedTestWithFailedChildProcessTest.st
A 
SUnit-Tests.package/SUnitTest.class/instance/testing/testChildProcessShouldNotBeStoredStronglyByTestEnvironment.st
A 
SUnit-Tests.package/SUnitTest.class/instance/testing/testFailedChildProcessTestShouldNotEffectFollowingAnotherTest.st
A 
SUnit-Tests.package/SUnitTest.class/instance/testing/testFailedTestWithFailedChildProcessTestShouldNotEffectFollowingAnotherTest.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60223.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60224.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60223.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60224.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60224
19092 TestExecutionEnvironment should clean all intercepted processes 
collections when test completes
https://pharo.fogbugz.com/f/cases/19092

19088 simplify newAnonymousSubclass in MetaClass
https://pharo.fogbugz.com/f/cases/19088

http://files.pharo.org/image/60/60224.zip

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

[Nicolai Hess]

2016-09-14 22:47 GMT+02:00 Tudor Girba :

> 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  wrote:
> >
> >
> >
> > 2016-08-29 21:41 GMT+02:00 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
> >
> >
> > 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-...@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."
>
>
>
>
>
>

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] bced96: 60223

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: bced96c46f6ffe8f29ae9f3794f8db1b6986b665
  
https://github.com/pharo-project/pharo-core/commit/bced96c46f6ffe8f29ae9f3794f8db1b6986b665
  Author: Jenkins Build Server 
  Date:   2016-09-15 (Thu, 15 Sep 2016)

  Changed paths:
A 
GT-InspectorExtensions-Core.package/extension/CompiledBlock/instance/gtDisplayOn_.st
A 
GT-InspectorExtensions-Core.package/extension/CompiledCode/instance/gtInspectorASTIn_.st
A 
GT-InspectorExtensions-Core.package/extension/CompiledCode/instance/gtInspectorBytecodeIn_.st
A 
GT-InspectorExtensions-Core.package/extension/CompiledCode/instance/gtInspectorBytesIn_.st
A 
GT-InspectorExtensions-Core.package/extension/CompiledCode/instance/gtInspectorHeaderIn_.st
A 
GT-InspectorExtensions-Core.package/extension/CompiledCode/instance/gtInspectorIrIn_.st
A 
GT-InspectorExtensions-Core.package/extension/CompiledCode/instance/gtInspectorItemsIn_.st
A 
GT-InspectorExtensions-Core.package/extension/CompiledCode/instance/gtInspectorPragmasIn_.st
A 
GT-InspectorExtensions-Core.package/extension/CompiledCode/instance/gtInspectorSourceIn_.st
A 
GT-InspectorExtensions-Core.package/extension/CompiledCode/instance/gtInspectorVariableValuePairs.st
R 
GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtInspectorASTIn_.st
R 
GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtInspectorBytecodeIn_.st
R 
GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtInspectorBytesIn_.st
R 
GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtInspectorHeaderIn_.st
R 
GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtInspectorIrIn_.st
R 
GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtInspectorItemsIn_.st
R 
GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtInspectorPragmasIn_.st
R 
GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtInspectorSourceIn_.st
R 
GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtInspectorVariableValuePairs.st
M 
Kernel.package/BlockLocalTempCounter.class/instance/initialize-release/tempCountForBlockAt_in_.st
A Kernel.package/CompiledBlock.class/instance/accessing/debuggerMap.st
A Kernel.package/CompiledBlock.class/instance/accessing/methodNode.st
A Kernel.package/CompiledBlock.class/instance/accessing/pragmas.st
A Kernel.package/CompiledBlock.class/instance/accessing/selector.st
A Kernel.package/CompiledBlock.class/instance/additions/ast.st
A Kernel.package/CompiledBlock.class/instance/additions/hash.st
A Kernel.package/CompiledBlock.class/instance/additions/isTestMethod.st
A Kernel.package/CompiledBlock.class/instance/additions/pcInOuter.st
A Kernel.package/CompiledBlock.class/instance/additions/printOn_.st
A Kernel.package/CompiledBlock.class/instance/additions/properties.st
A Kernel.package/CompiledBlock.class/instance/additions/sameLiteralsAs_.st
A Kernel.package/CompiledBlock.class/instance/additions/sourceNode.st
A Kernel.package/CompiledBlock.class/instance/additions/sourceNodeForPC_.st
A Kernel.package/CompiledBlock.class/instance/additions/sourceNodeInOuter.st
A Kernel.package/CompiledCode.class/class/instance 
creation/newMethod_header_.st
R Kernel.package/CompiledMethod.class/class/instance 
creation/newMethod_header_.st
M Kernel.package/Context.class/instance/instruction decoding/jump_if_.st
A Kernel.package/Context.class/instance/instruction 
decoding/pushFullClosure_numCopied_receiverOnStack_ignoreOuterContext_.st
M 
Kernel.package/Context.class/instance/private/doPrimitive_method_receiver_args_.st
M Kernel.package/Context.class/instance/system 
simulation/stepToSendOrReturn.st
A Kernel.package/FullBlockClosure.class/instance/accessing/endPC.st
A Kernel.package/FullBlockClosure.class/instance/accessing/sourceNode.st
A Kernel.package/FullBlockClosure.class/instance/private/printOn_.st
A 
Kernel.package/FullBlockClosure.class/instance/simulation/simulateValueWithArguments_caller_.st
A Kernel.package/FullBlockClosure.class/instance/testing/hasMethodReturn.st
A Kernel.package/InstructionClient.class/instance/instruction 
decoding/pushFullClosure_numCopied_receiverOnStack_ignoreOuterContext_.st
M 
Kernel.package/InstructionStream.class/instance/decoding/interpretNext3ByteSistaV1Instruction_for_extA_extB_startPC_.st
M 
Kernel.package/InstructionStream.class/instance/decoding/interpretNextSistaV1InstructionFor_.st
A Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushFullClosure_numCopied_receiverOnStack_ignoreOuterContext_.st
R Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/trapIfNotInstanceOf_.st
M 
OpalCompiler-Core.package/AbstractCompiler.class

Re: [Pharo-dev] [pharo-project/pharo-core] 770d9c: 60222

[Marcus Denker]

> 
>  Log Message:
>  ---
>  60222
> 19085 Integrate Epicea 8
>   https://pharo.fogbugz.com/f/cases/19085


This is a big sync with Epicea, fixing and improving many things.

Change log:

- Pass on UI + search more consistent names (e.g. session -> log).

- Replace "Session Browser" by "Log Set" from EpiceaHiedra experimental package.

- Add EpMonitorModel, to manipulate EpMonitor via UI.

- Rename: apply/revert instead of redo/undo.

- Fix 18946: package does not exist when a category removal is announced.

- Fixes for Dark theme.

- Avoid using #name in some cases.

- Make EpLogBrowser composable (it needs to be correctly initialized when 
created with #new).

- Optimization: reuse entryReader with an instance variable.

- Encapsulate morph creation to a new class: EpMorphFactory.

- Delete Trait issue (case 19045): Avoid sending #name to nil.

- Add EpMonitor>>debug setting

- Ombu writing entries: Do not catch all Error but FileException.

- Ombu: Move writing error handling to EpMonitor.

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 770d9c: 60222

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 770d9c79e09519a835bf8150bbdec00018a3c054
  
https://github.com/pharo-project/pharo-core/commit/770d9c79e09519a835bf8150bbdec00018a3c054
  Author: Jenkins Build Server 
  Date:   2016-09-15 (Thu, 15 Sep 2016)

  Changed paths:
A 
ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/baselines/baseline800_.st
M 
ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/tags/development_.st
M 
ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/tags/stable_.st
A 
ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version800_.st
A 
ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version801_.st
M Epicea.package/EpAndFilter.class/definition.st
M 
Epicea.package/EpCategoryChange.class/instance/initialization/packageNameFromCategoryName_.st
R 
Epicea.package/EpCompositeRefactoring.class/instance/printing/summaryOn_.st
M Epicea.package/EpFilter.class/definition.st
R Epicea.package/EpGenericRefactoring.class/instance/printing/summaryOn_.st
A Epicea.package/EpLog.class/instance/accessing/firstEntryIfAbsent_.st
M Epicea.package/EpMonitor.class/class/accessing/logsDirectory.st
M Epicea.package/EpMonitor.class/definition.st
A Epicea.package/EpMonitor.class/instance/accessing/debug_.st
A Epicea.package/EpMonitor.class/instance/accessing/sessionStore.st
R Epicea.package/EpMonitor.class/instance/announcement handling/addEvent_.st
R Epicea.package/EpMonitor.class/instance/announcement 
handling/addEvent_triggerReference_.st
M Epicea.package/EpMonitor.class/instance/announcement 
handling/jobStarted_.st
A 
Epicea.package/EpMonitor.class/instance/private-deprecated/addEvent_triggerReference_.st
A Epicea.package/EpMonitor.class/instance/private/addEvent_.st
A Epicea.package/EpMonitor.class/instance/private/addEvent_newEntryDo_.st
A 
Epicea.package/EpMonitor.class/instance/private/addEvent_newEntryDo_triggerReference_.st
A Epicea.package/EpMonitor.class/instance/private/handleError_.st
A Epicea.package/EpMonitor.class/instance/testing/isDebug.st
A Epicea.package/EpMonticelloVersionsLoad.class/instance/comparing/=.st
A Epicea.package/EpMonticelloVersionsLoad.class/instance/comparing/hash.st
R Epicea.package/EpMonticelloVersionsLoad.class/instance/visitor/=.st
R Epicea.package/EpMonticelloVersionsLoad.class/instance/visitor/hash.st
M Epicea.package/EpOrFilter.class/definition.st
M Epicea.package/EpPluggableFilter.class/class/well-known 
filters/logBrowserOperationFilter.st
M Epicea.package/EpPluggableFilter.class/definition.st
R 
Epicea.package/EpPropagateRefactoring.class/instance/printing/summaryOn_.st
M 
Epicea.package/EpProtocolChange.class/instance/accessing/behaviorAffectedName.st
M Epicea.package/EpRBPropagateRefactoring.class/definition.st
M Epicea.package/EpRedo.class/instance/accessing/title.st
R Epicea.package/EpRefactoring.class/instance/printing/summaryOn_.st
R 
Epicea.package/EpRenameClassRefactoring.class/instance/printing/summaryOn_.st
R 
Epicea.package/EpRenameInstanceVariableRefactoring.class/instance/printing/summaryOn_.st
R 
Epicea.package/EpRenameMethodRefactoring.class/instance/printing/summaryOn_.st
M Epicea.package/EpTCodeChangeVisitor.class/definition.st
M Epicea.package/EpTEventVisitor.class/definition.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitBehaviorCategoryChange_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitBehaviorChange_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitBehaviorCommentChange_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitBehaviorNameChange_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitCategoryAddition_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitCategoryChange_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitCategoryRemoval_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitCategoryRename_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitClassAddition_.st
A Epicea.package/EpTEventVisitor.class/instance/visitor/visitClassChange_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitClassModification_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitClassRemoval_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitMethodAddition_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitMethodChange_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitMethodModification_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitMethodRemoval_.st
A 
Epicea.package/EpTEventVisitor.class/instance/visitor/visitProtocolAddition_.st
A 
Epicea.package