Re: [Pharo-dev] Deploying using the latest minimal image of Pharo (6.1)

[Stephane Ducasse]

My idea was even to create objects that generate even bash scripts and
all the rest
but have objects that we can control and probably to be loaded in another image.
I just hate all the undebuggable scripts.


On Fri, Nov 24, 2017 at 3:16 AM, Ben Coman  wrote:
>
>
> On 24 November 2017 at 05:13, despotadesdibujau
>  wrote:
>>
>> >Hi Gabriel
>>
>> >This is cool.
>> >Thanks for sharing it with us.
>> >I really want an object responsible for deploying an app. :)
>> >Your effort is nice in that directory. Keep pushing
>>
>> >Stef
>> Thanks!!!
>>
>> Maxi Tabacman suggests me to reify the deployment process.
>> I thought of something like to get up a minimal image from inside the
>> development image, then to start the deployment process from the
>> development
>> image.
>> I suppose that I would need to use Espell Object Spaces (Guillermo
>> Polito),
>> but in this case, I would need a special virtual machine (Oz Virtual
>> Machine)... Something like Tornado, but not using the "Run Fail Grow"
>> approach, but using a BaselineOf or ConfigurationOf approach.
>
>
>
>>
>> Another idea (simpler than the idea above) is to communicate the two
>> images
>> using Teapot or Sockets: The Development image sends orders to the minimal
>> image until it becomes on the deployment image.
>
>
> This sounds like a good initiative, but Teapot seems a bit too specific and
> Sockets seems a bit too low level.
> Consider building on top of TelePharo,  or being its sibling by building on
> top of Seamless.
> These seem better suited to being part of every image than Teapot.
> *
> http://forum.world.st/Ann-PharmIDE-is-renamed-to-TelePharo-and-moved-to-github-td4963638.htm
> *
> https://dionisiydk.blogspot.com.au/2017/01/pharmide-pharo-remote-ide-to-develop.html
> * http://forum.world.st/Ann-Major-Seamless-update-td4907335.html
>
> Others might comment on which is the best level abstraction to use.
>
> cheers -ben
>
>
>> For the moment I need to test the process (on Pharo 6 and 7) using more
>> complex applications until it becomes a reliable process.
>>
>> Gabriel
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>

Re: [Pharo-dev] Bloc Tutorial Feedback

[Stephane Ducasse]

Aliaksei told me that he should do another pass to add animations and
layout chapters.
I imagine that he did some refactorings so this is good that you spotted them.


On Fri, Nov 24, 2017 at 8:36 AM, Stephane Ducasse
 wrote:
> Thanks Sean I will have a look when I get some time.
>
>
> On Fri, Nov 24, 2017 at 4:41 AM, Sean P. DeNigris  
> wrote:
>> I did a native English review pass on the first half and submitted a PR on
>> GH.
>>
>> A few other items:
>> - When clipping is used to initially draw the card outline as a rounded
>> rect, instead of using the rect as a path, it's not immediately obvious why
>> this is done. It's only way later when the cross is drawn on the back of the
>> card that one /may/ realize that it's so card contents (e.g. the cross)
>> don't get drawn outside the rounded bounds. It would be good to explain this
>> upfront.
>> - The booklet reached from the GH readme seems out of sync with Bloc. I had
>> to alter a lot of the animations from the loaded code e.g.
>> BlTransformAnimation did not exist (I used BlScaleAnimation instead),
>> animations didn't understand #absolute, ` animation startOn: target` needed
>> to be changed to `animation target: target; start`, etc.
>>
>> Otherwise a very nice tutorial. Thanks!
>>
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>

Re: [Pharo-dev] [Pharo-users] I love the launcher!!!!

[Stephane Ducasse]

Yes I do something similar to ben.

Stef

On Fri, Nov 24, 2017 at 4:43 AM, Ben Coman  wrote:
> Every time I investigate an issue from the tracker, I start with a new fresh
> image.
> Often its useful to track down which build introduced a bug, so I need to
> bisect the last 500 builds or so.
> I select a build version from the "Template" side and create an image named
> "CaseC-B"
> where C is the issue number and B is the build number.
> I'll quickly end up with a dozen images then delete all but the two either
> side of where the bug was introduced,
> to examine the differences between them, and develop a fix for the later
> build, then testing that fix in the latest build.
>
> Also when someone announces a new library, I can quickly create a new image
> "SomeProject-B"
> which I can dip my toes into as I get time available.
>
> Nowadays the matching VM is automatically downloaded, which makes it easier
> to keep up with the latest VM+Image.
>
> cheers -ben
>
> On 23 November 2017 at 19:56, Herby Vojčík  wrote:
>>
>> Stephane Ducasse wrote:
>>>
>>> Hi
>>>
>>> I love the PharoLauncher.
>>
>>
>> Pardon my question, I have downloaded it and looked at it, but I don't get
>> it. What does it do / what are the use cases (honest question)?
>>
>> Thanks, Herby
>>
>>
>>> It helps me to manage my parallel development and projects.
>>>
>>> We should put a link on the Pharo web site because
>>>
>>> http://files.pharo.org/platform/launcher/
>>>
>>> is arcane.
>>>
>>> Stef
>>>
>>
>>
>

Re: [Pharo-dev] Bloc Tutorial Feedback

[Stephane Ducasse]

Thanks Sean I will have a look when I get some time.


On Fri, Nov 24, 2017 at 4:41 AM, Sean P. DeNigris  wrote:
> I did a native English review pass on the first half and submitted a PR on
> GH.
>
> A few other items:
> - When clipping is used to initially draw the card outline as a rounded
> rect, instead of using the rect as a path, it's not immediately obvious why
> this is done. It's only way later when the cross is drawn on the back of the
> card that one /may/ realize that it's so card contents (e.g. the cross)
> don't get drawn outside the rounded bounds. It would be good to explain this
> upfront.
> - The booklet reached from the GH readme seems out of sync with Bloc. I had
> to alter a lot of the animations from the loaded code e.g.
> BlTransformAnimation did not exist (I used BlScaleAnimation instead),
> animations didn't understand #absolute, ` animation startOn: target` needed
> to be changed to `animation target: target; start`, etc.
>
> Otherwise a very nice tutorial. Thanks!
>
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] [Pharo-users] I love the launcher!!!!

[Ben Coman]

Every time I investigate an issue from the tracker, I start with a new
fresh image.
Often its useful to track down which build introduced a bug, so I need to
bisect the last 500 builds or so.
I select a build version from the "Template" side and create an image named
"CaseC-B"
where C is the issue number and B is the build number.
I'll quickly end up with a dozen images then delete all but the two either
side of where the bug was introduced,
to examine the differences between them, and develop a fix for the later
build, then testing that fix in the latest build.

Also when someone announces a new library, I can quickly create a new image
"SomeProject-B"
which I can dip my toes into as I get time available.

Nowadays the matching VM is automatically downloaded, which makes it easier
to keep up with the latest VM+Image.

cheers -ben

On 23 November 2017 at 19:56, Herby Vojčík  wrote:

> Stephane Ducasse wrote:
>
>> Hi
>>
>> I love the PharoLauncher.
>>
>
> Pardon my question, I have downloaded it and looked at it, but I don't get
> it. What does it do / what are the use cases (honest question)?
>
> Thanks, Herby
>
>
> It helps me to manage my parallel development and projects.
>>
>> We should put a link on the Pharo web site because
>>
>> http://files.pharo.org/platform/launcher/
>>
>> is arcane.
>>
>> Stef
>>
>>
>
>

[Pharo-dev] Bloc Tutorial Feedback

[Sean P. DeNigris]

I did a native English review pass on the first half and submitted a PR on
GH.

A few other items:
- When clipping is used to initially draw the card outline as a rounded
rect, instead of using the rect as a path, it's not immediately obvious why
this is done. It's only way later when the cross is drawn on the back of the
card that one /may/ realize that it's so card contents (e.g. the cross)
don't get drawn outside the rounded bounds. It would be good to explain this
upfront.
- The booklet reached from the GH readme seems out of sync with Bloc. I had
to alter a lot of the animations from the loaded code e.g.
BlTransformAnimation did not exist (I used BlScaleAnimation instead),
animations didn't understand #absolute, ` animation startOn: target` needed
to be changed to `animation target: target; start`, etc.

Otherwise a very nice tutorial. Thanks!




-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Deploying using the latest minimal image of Pharo (6.1)

[Ben Coman]

On 24 November 2017 at 05:13, despotadesdibujau  wrote:

> >Hi Gabriel
>
> >This is cool.
> >Thanks for sharing it with us.
> >I really want an object responsible for deploying an app. :)
> >Your effort is nice in that directory. Keep pushing
>
> >Stef
> Thanks!!!
>
> Maxi Tabacman suggests me to reify the deployment process.
> I thought of something like to get up a minimal image from inside the
> development image, then to start the deployment process from the
> development
> image.
> I suppose that I would need to use Espell Object Spaces (Guillermo Polito),
> but in this case, I would need a special virtual machine (Oz Virtual
> Machine)... Something like Tornado, but not using the "Run Fail Grow"
> approach, but using a BaselineOf or ConfigurationOf approach.
>



> Another idea (simpler than the idea above) is to communicate the two images
> using Teapot or Sockets: The Development image sends orders to the minimal
> image until it becomes on the deployment image.
>

This sounds like a good initiative, but Teapot seems a bit too specific and
Sockets seems a bit too low level.
Consider building on top of TelePharo,  or being its sibling by building on
top of Seamless.
These seem better suited to being part of every image than Teapot.
*
http://forum.world.st/Ann-PharmIDE-is-renamed-to-TelePharo-and-moved-to-github-td4963638.htm
*
https://dionisiydk.blogspot.com.au/2017/01/pharmide-pharo-remote-ide-to-develop.html
* http://forum.world.st/Ann-Major-Seamless-update-td4907335.html

Others might comment on which is the best level abstraction to use.

cheers -ben


For the moment I need to test the process (on Pharo 6 and 7) using more
> complex applications until it becomes a reliable process.
>
> Gabriel
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Clément Bera]

On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse 
wrote:

> Did you talk with marcus?
>

I don't understand the connection between slots and this problem with
primitives.

>
>
> On Wed, Nov 22, 2017 at 10:12 PM, Clément Bera 
> wrote:
> >
> >
> > On Wed, Nov 22, 2017 at 9:05 PM, Stephane Ducasse <
> stepharo.s...@gmail.com>
> > wrote:
> >>
> >> Hi clement
> >>
> >> you should discuss with marcus. I had the impression that he was
> >> thinking that slot should disappear.
> >
> >
> > Then let's use fieldAt:/fieldAt:put:
> >
> >>
> >>
> >> Stef
> >>
> >> On Wed, Nov 22, 2017 at 2:35 PM, Clément Bera 
> >> wrote:
> >> > Hi All,
> >> >
> >> > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that
> >> > the
> >> > instVarAt: / instVarAt:put: primitive is not doing what it says it
> does.
> >> > When I look at Object>>#instVarAt: I see:
> >> >
> >> > "[...]Answer a fixed variable in an object. The numbering of the
> >> > variables
> >> > corresponds to the named instance variables, followed by the indexed
> >> > instance
> >> > variables. Fail if the index is not an Integer or is not the index of
> a
> >> > fixed variable[...]"
> >> >
> >> > Now in Pharo 7 when one does:
> >> >
> >> > #(iv1) instVarAt: 1, one gets #iv1.
> >> >
> >> > So the comment is wrong.
> >> >
> >> > The reason for this is that instVarAt: / instVarAt:put: should be
> >> > primitive
> >> > 73/74, while they are in Pharo 173/174 (primitive
> slotAt:/slotAt:put:).
> >> > The
> >> > slot primitive access pointer slots of objects, whichever inst var or
> >> > variable fields. A good example would be:
> >> >
> >> > | t |
> >> > t := #temp.
> >> > [ t ] instVarAt: 4, one gets #temp
> >> >
> >> > So I have two solutions for this problem:
> >> > 1) We change the instVarAt: / instVarAt:put: primitives comments to
> >> > match
> >> > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
> >> > instVarAt:put:
> >> > means in factslotAt: / slotAt:put: .
> >> > 2) We change the instVarAt: / instVarAt:put: primitives to primitive
> 73
> >> > and
> >> > 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we
> ask
> >> > everyone to fix their code relying on instVarAt: / instVarAt:put:
> acting
> >> > as
> >> > slotAt: / slotAt:put:
> >> >
> >> > What do you think ?
> >> >
> >> > Best,
> >> >
> >> >
> >> > --
> >> > Clément Béra
> >> > Pharo consortium engineer
> >> > https://clementbera.wordpress.com/
> >> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
> >>
> >
> >
> >
> > --
> > Clément Béra
> > Pharo consortium engineer
> > https://clementbera.wordpress.com/
> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Stephane Ducasse]

Did you talk with marcus?


On Wed, Nov 22, 2017 at 10:12 PM, Clément Bera  wrote:
>
>
> On Wed, Nov 22, 2017 at 9:05 PM, Stephane Ducasse 
> wrote:
>>
>> Hi clement
>>
>> you should discuss with marcus. I had the impression that he was
>> thinking that slot should disappear.
>
>
> Then let's use fieldAt:/fieldAt:put:
>
>>
>>
>> Stef
>>
>> On Wed, Nov 22, 2017 at 2:35 PM, Clément Bera 
>> wrote:
>> > Hi All,
>> >
>> > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that
>> > the
>> > instVarAt: / instVarAt:put: primitive is not doing what it says it does.
>> > When I look at Object>>#instVarAt: I see:
>> >
>> > "[...]Answer a fixed variable in an object. The numbering of the
>> > variables
>> > corresponds to the named instance variables, followed by the indexed
>> > instance
>> > variables. Fail if the index is not an Integer or is not the index of a
>> > fixed variable[...]"
>> >
>> > Now in Pharo 7 when one does:
>> >
>> > #(iv1) instVarAt: 1, one gets #iv1.
>> >
>> > So the comment is wrong.
>> >
>> > The reason for this is that instVarAt: / instVarAt:put: should be
>> > primitive
>> > 73/74, while they are in Pharo 173/174 (primitive slotAt:/slotAt:put:).
>> > The
>> > slot primitive access pointer slots of objects, whichever inst var or
>> > variable fields. A good example would be:
>> >
>> > | t |
>> > t := #temp.
>> > [ t ] instVarAt: 4, one gets #temp
>> >
>> > So I have two solutions for this problem:
>> > 1) We change the instVarAt: / instVarAt:put: primitives comments to
>> > match
>> > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
>> > instVarAt:put:
>> > means in factslotAt: / slotAt:put: .
>> > 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73
>> > and
>> > 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we ask
>> > everyone to fix their code relying on instVarAt: / instVarAt:put: acting
>> > as
>> > slotAt: / slotAt:put:
>> >
>> > What do you think ?
>> >
>> > Best,
>> >
>> >
>> > --
>> > Clément Béra
>> > Pharo consortium engineer
>> > https://clementbera.wordpress.com/
>> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>>
>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Bloc Naming Suggestion

[Stephane Ducasse]

In Opal I would keep it because this is about error and warning and
you are not all the time manipulating them
while for Bloc as soon as you use text you will have  to.

On Wed, Nov 22, 2017 at 9:37 PM, Nicolas Cellier
 wrote:
> I see same kind of names in Opal exceptions
> Maybe the intention was to clearly distinguish Error from Warning
> (proceedable), but the hierarchy tells already.
>
> OCSemanticError
> OCStoreIntoReadOnlyVariableError could be just OCStoreIntoReadOnlyVariable
> OCStoreIntoSpecialVariableError -> OCStoreIntoSpecialVariable
>
> OCSemanticWarning
> OCShadowVariableWarning
> OCUndeclaredVariableWarning
>
> Note that removing the Warning suffix might lead to ambiguous names...
> OCUndeclaredVariable might be confused as being a Variable.
> So maybe OCVariableUndeclared or OCVariableIsUndeclared
>
> 2017-11-22 21:25 GMT+01:00 Stephane Ducasse :
>>
>> +1
>>
>>
>> On Sun, Nov 19, 2017 at 4:34 PM, Tudor Girba  wrote:
>> > I think it’s not a bad idea.
>> >
>> > Doru
>> >
>> >> On Nov 19, 2017, at 4:31 PM, Sean P. DeNigris 
>> >> wrote:
>> >>
>> >> What do you think about removing the #Attribute suffix from all the
>> >> BrTextAttribute subclasses? The names seem pretty long (e.g.
>> >> BrFontGenericFamilyAttribute, the longest) and IMHO `BrTextAttribute
>> >> subclass: #BrFontWeight` is adequately intention revealing. Thoughts?
>> >>
>> >>
>> >>
>> >> -
>> >> Cheers,
>> >> Sean
>> >> --
>> >> Sent from:
>> >> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>> >>
>> >
>> > --
>> > www.tudorgirba.com
>> > www.feenk.com
>> >
>> > "Problem solving efficiency grows with the abstractness level of problem
>> > understanding."
>> >
>> >
>> >
>> >
>> >
>>
>

Re: [Pharo-dev] Deploying using the latest minimal image of Pharo (6.1)

[Stephane Ducasse]

Yes your second scenario looks cool to me :).
Keep us informed because this is really exciting.

Stef

On Thu, Nov 23, 2017 at 10:13 PM, despotadesdibujau
 wrote:
>>Hi Gabriel
>
>>This is cool.
>>Thanks for sharing it with us.
>>I really want an object responsible for deploying an app. :)
>>Your effort is nice in that directory. Keep pushing
>
>>Stef
> Thanks!!!
>
> Maxi Tabacman suggests me to reify the deployment process.
> I thought of something like to get up a minimal image from inside the
> development image, then to start the deployment process from the development
> image.
> I suppose that I would need to use Espell Object Spaces (Guillermo Polito),
> but in this case, I would need a special virtual machine (Oz Virtual
> Machine)... Something like Tornado, but not using the "Run Fail Grow"
> approach, but using a BaselineOf or ConfigurationOf approach.
> Another idea (simpler than the idea above) is to communicate the two images
> using Teapot or Sockets: The Development image sends orders to the minimal
> image until it becomes on the deployment image.
>
> For the moment I need to test the process (on Pharo 6 and 7) using more
> complex applications until it becomes a reliable process.
>
> Gabriel
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] [PHARO 7.0A] NEXT ENHANCEMENTS

[Stephane Ducasse]

+ 1 :)


On Thu, Nov 23, 2017 at 8:53 PM, Torsten Bergmann  wrote:
> What is not visible in the list are the many enhancements happening also on
> Calypso, Bloc,
> Grease and many many others.
>
> Nonetheless the core image still needs love from more people. Remember even
> the smallest change
> can make a difference and shape the future. Also "a contribution per day
> keeps bad systems away".
> Even one contribution per week or month.
>
> So jump in - the water is just fine!
>
> Bye
> T. (aka astares)
>
> Gesendet: Donnerstag, 23. November 2017 um 12:37 Uhr
> Von: "p...@highoctane.be" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] [PHARO 7.0A] NEXT ENHANCEMENTS
> Yes, very.
>
> Phil
>
> On Thu, Nov 23, 2017 at 12:26 PM, Alexandre Bergel 
> wrote:
>>
>> Impressive!!
>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>> On Nov 23, 2017, at 7:12 AM, Stephane Ducasse 
>> wrote:
>>
>> eport period: 5 November 2017 to 23 November 2017
>>
>> *  20739-Remove-dead-stream-primitives
>>
>> https://pharo.fogbugz.com/f/cases/20739/Remove-dead-stream-primitives
>>
>>
>>  Issue URL: https://pharo.fogbugz.com/f/cases/20739
>>  PR URL: https://github.com/pharo-project/pharo/pull/524
>>  Diff URL: https://github.com/pharo-project/pharo/pull/524/files
>>
>>  Thanks to clementbera
>>
>> *  20645-Windows-rebuildFieldAccessors-problem
>>
>> Fixing the creation of annonymous classes for FFITypeArray.
>> It was affecting all the platforms.
>>
>> Issue:
>> https://pharo.fogbugz.com/f/cases/20645/Windows-rebuildFieldAccessors-problem
>>
>>
>>  Issue URL: https://pharo.fogbugz.com/f/cases/20645
>>  PR URL: https://github.com/pharo-project/pharo/pull/521
>>  Diff URL: https://github.com/pharo-project/pharo/pull/521/files
>>
>>  Thanks to tesonep
>>
>> *
>> 20735-ComposablePresenter-classowneron-is-missing-the-initialization-call
>>
>>
>> https://pharo.fogbugz.com/f/cases/20735/ComposablePresenter-class-owner-on-is-missing-the-initialization-call
>>
>>
>>  Issue URL: https://pharo.fogbugz.com/f/cases/20735
>>  PR URL: https://github.com/pharo-project/pharo/pull/517
>>  Diff URL: https://github.com/pharo-project/pharo/pull/517/files
>>
>>  Thanks to pavel-krivanek
>>
>> *  Fix the sign of FloatNegativeZero
>>
>> Like any other zero, the sign of Float negativeZero should be zero…
>> Introduce signBit to differentiate Float negativeZero from Float zero.
>>
>> This is issue
>>
>> https://pharo.fogbugz.com/f/cases/19629/0-0-sign-answers-1-should-be-zero
>>
>>
>> Note that this PR does not implement isSignMinus which is not
>>
>> strictly necessary.
>>
>> If it’s for ISO 10967 compliance, then there will be other
>>
>> functions missing.
>>
>> Maybe open a new issue for this one?
>>
>>
>>  Issue URL: https://pharo.fogbugz.com/f/cases/Fix the sign of
>> FloatNegativeZero
>>  PR URL: https://github.com/pharo-project/pharo/pull/515
>>  Diff URL: https://github.com/pharo-project/pharo/pull/515/files
>>
>>  Thanks to nicolas-cellier-aka-nice
>>
>> *  20717-Duplicities-of-themes-in-the-list-2
>>
>> https://pharo.fogbugz.com/f/cases/20717/Duplicities-of-themes-in-the-list
>>
>> alternative version by Torsten
>>
>>
>>  Issue URL: https://pharo.fogbugz.com/f/cases/20717
>>  PR URL: https://github.com/pharo-project/pharo/pull/499
>>  Diff URL: https://github.com/pharo-project/pharo/pull/499/files
>>
>>  Thanks to pavel-krivanek
>>
>> *  20730 Unused temps in FileReferenceTest, FLHeaderSerializationTest,
>> FLHookedSubstitutionTest, FT2GlyphRenderer, ...
>>
>> Fix unused temps in
>>
>> FileReferenceTest>>#testRename
>> FileReferenceTest>>#testDeleteAllChildren
>> FileReferenceTest>>#testHasChildren
>> FileReferenceTest>>#testHasDirectories
>> FileReferenceTest>>#testHasFiles
>> FLHeaderSerializationTest>>#testAdditionalObjects
>> FLHookedSubstitutionTest>>#testAvoidRecursion
>> FT2GlyphRenderer>>#loadSurfaceTransform
>> FT2GlyphRenderer>>#loadUnicode:
>> FileDialogWindowTest>>#testIssue6406
>> FileReferenceTest>>#testDeleteAll
>>
>>
>>  Issue URL: https://pharo.fogbugz.com/f/cases/20730 Unused temps
>> in FileReferenceTest, FLHeaderSerializationTest,
>> FLHookedSubstitutionTest, FT2GlyphRenderer, ...
>>  PR URL: https://github.com/pharo-project/pharo/pull/510
>>  Diff URL: https://github.com/pharo-project/pharo/pull/510/files
>>
>>  Thanks to astares
>>
>> *  20731 Unused temps in HDCoverageReport and HDLintReport
>>
>> fix unused temps
>>
>> HDCoverageReport>>#generatePackage:method:on:
>> HDLintReport>>#generateClass:source:on:
>>
>>
>>
>> https://pharo.fogbugz.com/f/cases/20731/Unused-temps-in-HDCoverageReport-and-HDLintReport
>>
>>
>>  Issue URL: https://pharo.fogbugz.com/f/cases/20731 Unused temps
>> in 

Re: [Pharo-dev] OpalCompiler evaluate speed

[Clément Bera]

Hi Nicolas.

Just some comments:

Another thing you can try is to remove the allocation of Opal's IR. It
seems people use the IR only through the IRBuilder, so the API can be kept
but it can generate directly bytecode instead of IR then bytecode. Removing
those allocations would speed things up. It means merging IRFix /
IRTranslator / IRBytecodeGenerator somehow and have the IRBuilder API
directly call the new resulting merged class.

Another thing is that when Opal became the default compiler, I evaluated
the speed and saw it was slower, but when loading large projects it seemed
loading time was dominated by Monticello / source reading / source loading
and the compilation time was overall not that significant (< 20% of time).
I don't know if this is still the case with GIT. I have problems currently
when editing some large methods (it seems in the IDE the method is compiled
at each keystroke...) and when doing OpalCompiler recompileAll (which I do
often since I edit bytecode sets) but else the performance of Opal seems to
be OK. Evaluate performance may be relevant in some cases but I've never
found such cases outside of the IDE in production.

Best !

Clement


On Thu, Nov 23, 2017 at 9:41 PM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

>
>
> 2017-11-22 0:31 GMT+01:00 Ben Coman :
>
>>
>>
>> On 22 November 2017 at 05:49, Nicolas Cellier <
>> nicolas.cellier.aka.n...@gmail.com> wrote:
>>
>>>
>>>
>>> 2017-11-21 14:19 GMT+01:00 Nicolas Cellier <
>>> nicolas.cellier.aka.n...@gmail.com>:
>>>
 I have an ArbitraryPrecisionFloatTests doing an exhaustive test for
 printing and reevaluating all positve half precision float.

 That's about 2^15 or approximately 32k loop which evaluate snippets like

 (ArbitraryPrecisionFloat readFrom: '1.123' readStream numBits: 10)

 The test was naively written with Compiler evaluate: and was using the
 legacy Compiler.

 If I rewrite self class compiler evaluate: the test times out.
 Let's see what increase is necessary:

 [ ArbitraryPrecisionFloatTest new testPrintAndEvaluate  ] timeToRun.
 -> 3s with legacy Compiler
 -> 14s with OpalCompiler

 It's not unexpected that intermediate representation (IR) reification
 has a cost, but here the 4.5x is a bit too much...
 This test did account for 1/4 of total test duration already (3s out of
 12s).
 With Opal, the total test duration doubles... (14s out of 23s)

 So let's analyze the hot spot with:

 MessageTally  spyOn: [ ArbitraryPrecisionFloatTest new
 testPrintAndEvaluate  ].

 (I didn't use AndreasSystemProfiler becuase outputs seems a bit
 garbbled, no matter since the primitives do not account that much, a
 MessageTally will do the job)

 I first see a hot spot which does not seem that necessary:

   ||24.6% {3447ms} RBMethodNode(RBProgramNode)>>formattedCode

 From the comments I understand that AST-based stuff requires a pattern
 (DoIt) and an explicit return (^), but this expensive formatting seems too
 much for just evaluating. i think that we should change that.

 Then comes:

   ||20.7% {2902ms} RBMethodNode>>generate:

 which is split in two halves, ATS->IR and IR->bytecode

   ||  |9.3% {1299ms} RBMethodNode>>generateIR

   ||  |  |11.4% {1596ms} IRMethod>>generate:

 But then I see this cost a 2nd time which also leave room for progress:

   ||10.9% {1529ms} RBMethodNode>>generateIR

   ||  |12.9% {1814ms} IRMethod>>generate:

 The first is in RBMethodNode>>generateWithSource, the second in
 OpalCompiler>>compile

 Last comes the parse time (sourceCode -> AST)

   |  13.2% {1858ms} OpalCompiler>>parse

 Along with semantic analysis

   |  6.0% {837ms} OpalCompiler>>doSemanticAnalysis

 ---

 For comparison, the legacy Compiler decomposes into:

   ||61.5% {2223ms} Parser>>parse:class:category:n
 oPattern:context:notifying:ifFail:

 which more or less covers parse time + semantic analysis time.
 That means that Opal does a fair work for this stage.

 Then, the direct AST->byteCode phase is:

  |  16.9% {609ms} MethodNode>>generate

 IR costs almost a 5x on this phase, but we know it's the price to pay
 for the additional features that it potentially offers. If only we would do
 it once...

 And that's all for the legacy one...

 --

 This little exercize shows that a 2x acceleration of OpalCompiler
 evaluate seems achievable:
 - simplify the uselessely expensive formatted code
 - generate bytecodes 

Re: [Pharo-dev] Deploying using the latest minimal image of Pharo (6.1)

[despotadesdibujau]

>Hi Gabriel

>This is cool.
>Thanks for sharing it with us.
>I really want an object responsible for deploying an app. :)
>Your effort is nice in that directory. Keep pushing

>Stef
Thanks!!!

Maxi Tabacman suggests me to reify the deployment process. 
I thought of something like to get up a minimal image from inside the
development image, then to start the deployment process from the development
image.
I suppose that I would need to use Espell Object Spaces (Guillermo Polito),
but in this case, I would need a special virtual machine (Oz Virtual
Machine)... Something like Tornado, but not using the "Run Fail Grow"
approach, but using a BaselineOf or ConfigurationOf approach.
Another idea (simpler than the idea above) is to communicate the two images
using Teapot or Sockets: The Development image sends orders to the minimal
image until it becomes on the deployment image. 

For the moment I need to test the process (on Pharo 6 and 7) using more
complex applications until it becomes a reliable process.

Gabriel



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] OpalCompiler evaluate speed

[Nicolas Cellier]

2017-11-22 0:31 GMT+01:00 Ben Coman :

>
>
> On 22 November 2017 at 05:49, Nicolas Cellier  gmail.com> wrote:
>
>>
>>
>> 2017-11-21 14:19 GMT+01:00 Nicolas Cellier > l.com>:
>>
>>> I have an ArbitraryPrecisionFloatTests doing an exhaustive test for
>>> printing and reevaluating all positve half precision float.
>>>
>>> That's about 2^15 or approximately 32k loop which evaluate snippets like
>>>
>>> (ArbitraryPrecisionFloat readFrom: '1.123' readStream numBits: 10)
>>>
>>> The test was naively written with Compiler evaluate: and was using the
>>> legacy Compiler.
>>>
>>> If I rewrite self class compiler evaluate: the test times out.
>>> Let's see what increase is necessary:
>>>
>>> [ ArbitraryPrecisionFloatTest new testPrintAndEvaluate  ] timeToRun.
>>> -> 3s with legacy Compiler
>>> -> 14s with OpalCompiler
>>>
>>> It's not unexpected that intermediate representation (IR) reification
>>> has a cost, but here the 4.5x is a bit too much...
>>> This test did account for 1/4 of total test duration already (3s out of
>>> 12s).
>>> With Opal, the total test duration doubles... (14s out of 23s)
>>>
>>> So let's analyze the hot spot with:
>>>
>>> MessageTally  spyOn: [ ArbitraryPrecisionFloatTest new
>>> testPrintAndEvaluate  ].
>>>
>>> (I didn't use AndreasSystemProfiler becuase outputs seems a bit
>>> garbbled, no matter since the primitives do not account that much, a
>>> MessageTally will do the job)
>>>
>>> I first see a hot spot which does not seem that necessary:
>>>
>>>   ||24.6% {3447ms} RBMethodNode(RBProgramNode)>>formattedCode
>>>
>>> From the comments I understand that AST-based stuff requires a pattern
>>> (DoIt) and an explicit return (^), but this expensive formatting seems too
>>> much for just evaluating. i think that we should change that.
>>>
>>> Then comes:
>>>
>>>   ||20.7% {2902ms} RBMethodNode>>generate:
>>>
>>> which is split in two halves, ATS->IR and IR->bytecode
>>>
>>>   ||  |9.3% {1299ms} RBMethodNode>>generateIR
>>>
>>>   ||  |  |11.4% {1596ms} IRMethod>>generate:
>>>
>>> But then I see this cost a 2nd time which also leave room for progress:
>>>
>>>   ||10.9% {1529ms} RBMethodNode>>generateIR
>>>
>>>   ||  |12.9% {1814ms} IRMethod>>generate:
>>>
>>> The first is in RBMethodNode>>generateWithSource, the second in
>>> OpalCompiler>>compile
>>>
>>> Last comes the parse time (sourceCode -> AST)
>>>
>>>   |  13.2% {1858ms} OpalCompiler>>parse
>>>
>>> Along with semantic analysis
>>>
>>>   |  6.0% {837ms} OpalCompiler>>doSemanticAnalysis
>>>
>>> ---
>>>
>>> For comparison, the legacy Compiler decomposes into:
>>>
>>>   ||61.5% {2223ms} Parser>>parse:class:category:n
>>> oPattern:context:notifying:ifFail:
>>>
>>> which more or less covers parse time + semantic analysis time.
>>> That means that Opal does a fair work for this stage.
>>>
>>> Then, the direct AST->byteCode phase is:
>>>
>>>  |  16.9% {609ms} MethodNode>>generate
>>>
>>> IR costs almost a 5x on this phase, but we know it's the price to pay
>>> for the additional features that it potentially offers. If only we would do
>>> it once...
>>>
>>> And that's all for the legacy one...
>>>
>>> --
>>>
>>> This little exercize shows that a 2x acceleration of OpalCompiler
>>> evaluate seems achievable:
>>> - simplify the uselessely expensive formatted code
>>> - generate bytecodes once, not twice
>>>
>>> Then it will be a bit more 2x slower than legacy, which is a better
>>> trade for yet to come superior features potentially brought by Opal.
>>>
>>> It would be interesting to carry same analysis on method compilation
>>>
>>
>> Digging further here is what I find:
>>
>> compile sends generate: and answer a CompiledMethod
>> translate sends compile but throw the CompiledMethod away, and just
>> answer the AST.
>> Most senders of translate will also generate: (thus we generate: twice
>> quite often, loosing a 2x factor in compilation).
>>
>> A 2x gain is a huge gain when installing big code bases, especially if
>> the custom is to throw image away and reconstruct.
>> No matter if a bot does the job, it does it for twice many watts and at
>> the end, we're waiting for the bot.
>>
>> However, before changing anything, further clarification is required:
>> translate does one more thing, it catches ReparseAfterSourceEditing and
>> retry compilation (once).
>> So my question: are there some cases when generate: will cause
>> ReparseAfterSourceEditing?
>>
>
> I don't know the full answer about other cases, but I can provide the
> background why ReparseAfterSourceEditing was added.
>
> IIRC, a few years ago with the move to an AST based system, there was a
> problem with syntax highlighting where
> the AST referenced its original source which caused 

Re: [Pharo-dev] [PHARO 7.0A] NEXT ENHANCEMENTS

[Torsten Bergmann]

What is not visible in the list are the many enhancements happening also on Calypso, Bloc,  

Grease and many many others.


Nonetheless the core image still needs love from more people. Remember even the smallest change
can make a difference and shape the future. Also "a contribution per day keeps bad systems away".

Even one contribution per week or month.

So jump in - the water is just fine!

Bye
T. (aka astares)

 

Gesendet: Donnerstag, 23. November 2017 um 12:37 Uhr
Von: "p...@highoctane.be" 
An: "Pharo Development List" 
Betreff: Re: [Pharo-dev] [PHARO 7.0A] NEXT ENHANCEMENTS


Yes, very.
 

Phil


 
On Thu, Nov 23, 2017 at 12:26 PM, Alexandre Bergel  wrote:


Impressive!!
 

 
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

 

 

On Nov 23, 2017, at 7:12 AM, Stephane Ducasse  wrote:
 


eport period: 5 November 2017 to 23 November 2017

*  20739-Remove-dead-stream-primitives

https://pharo.fogbugz.com/f/cases/20739/Remove-dead-stream-primitives


 Issue URL: https://pharo.fogbugz.com/f/cases/20739
 PR URL: https://github.com/pharo-project/pharo/pull/524
 Diff URL: https://github.com/pharo-project/pharo/pull/524/files

 Thanks to clementbera

*  20645-Windows-rebuildFieldAccessors-problem

Fixing the creation of annonymous classes for FFITypeArray.
It was affecting all the platforms.

Issue: https://pharo.fogbugz.com/f/cases/20645/Windows-rebuildFieldAccessors-problem


 Issue URL: https://pharo.fogbugz.com/f/cases/20645
 PR URL: https://github.com/pharo-project/pharo/pull/521
 Diff URL: https://github.com/pharo-project/pharo/pull/521/files

 Thanks to tesonep

*  20735-ComposablePresenter-classowneron-is-missing-the-initialization-call

https://pharo.fogbugz.com/f/cases/20735/ComposablePresenter-class-owner-on-is-missing-the-initialization-call


 Issue URL: https://pharo.fogbugz.com/f/cases/20735
 PR URL: https://github.com/pharo-project/pharo/pull/517
 Diff URL: https://github.com/pharo-project/pharo/pull/517/files

 Thanks to pavel-krivanek

*  Fix the sign of FloatNegativeZero

Like any other zero, the sign of Float negativeZero should be zero…
Introduce signBit to differentiate Float negativeZero from Float zero.

This is issue

https://pharo.fogbugz.com/f/cases/19629/0-0-sign-answers-1-should-be-zero



Note that this PR does not implement isSignMinus which is not

strictly necessary.


If it’s for ISO 10967 compliance, then there will be other

functions missing.


Maybe open a new issue for this one?


 Issue URL: https://pharo.fogbugz.com/f/cases/Fix the sign of
FloatNegativeZero
 PR URL: https://github.com/pharo-project/pharo/pull/515
 Diff URL: https://github.com/pharo-project/pharo/pull/515/files

 Thanks to nicolas-cellier-aka-nice

*  20717-Duplicities-of-themes-in-the-list-2

https://pharo.fogbugz.com/f/cases/20717/Duplicities-of-themes-in-the-list

alternative version by Torsten


 Issue URL: https://pharo.fogbugz.com/f/cases/20717
 PR URL: https://github.com/pharo-project/pharo/pull/499
 Diff URL: https://github.com/pharo-project/pharo/pull/499/files

 Thanks to pavel-krivanek

*  20730 Unused temps in FileReferenceTest, FLHeaderSerializationTest,
FLHookedSubstitutionTest, FT2GlyphRenderer, ...

Fix unused temps in

FileReferenceTest>>#testRename
FileReferenceTest>>#testDeleteAllChildren
FileReferenceTest>>#testHasChildren
FileReferenceTest>>#testHasDirectories
FileReferenceTest>>#testHasFiles
FLHeaderSerializationTest>>#testAdditionalObjects
FLHookedSubstitutionTest>>#testAvoidRecursion
FT2GlyphRenderer>>#loadSurfaceTransform
FT2GlyphRenderer>>#loadUnicode:
FileDialogWindowTest>>#testIssue6406
FileReferenceTest>>#testDeleteAll


 Issue URL: https://pharo.fogbugz.com/f/cases/20730 Unused temps
in FileReferenceTest, FLHeaderSerializationTest,
FLHookedSubstitutionTest, FT2GlyphRenderer, ...
 PR URL: https://github.com/pharo-project/pharo/pull/510
 Diff URL: https://github.com/pharo-project/pharo/pull/510/files

 Thanks to astares

*  20731 Unused temps in HDCoverageReport and HDLintReport

fix unused temps

HDCoverageReport>>#generatePackage:method:on:
HDLintReport>>#generateClass:source:on:


https://pharo.fogbugz.com/f/cases/20731/Unused-temps-in-HDCoverageReport-and-HDLintReport


 Issue URL: https://pharo.fogbugz.com/f/cases/20731 Unused temps
in HDCoverageReport and HDLintReport
 PR URL: https://github.com/pharo-project/pharo/pull/511
 Diff URL: https://github.com/pharo-project/pharo/pull/511/files

 Thanks to astares

*  20732 Unused temps in HistoryNodeTest

fix unused temps

HistoryNodeTest>>#testTwoConsecutiveCloseGroup
HistoryNodeTest>>#testTwoGroups

https://pharo.fogbugz.com/f/cases/20732/Unused-temps-in-HistoryNodeTest


 Issue URL: 

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo TechTalk 21 Nov: Discord Demo

[Juraj Kubelka]

Hi, the new version is available here: 
https://www.youtube.com/watch?v=y1EzOnfHUe0 
 

Hopefully it helps :-)
Juraj

> On Nov 22, 2017, at 15:45, Sean P. DeNigris  wrote:
> 
> Juraj Kubelka wrote
>> I will upload recording I have on my computer. It is clear.
> 
> Thanks!
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

[Pharo-dev] [Pharo 7.0-dev] Build #322: 18217-Settings-What-are-Renkaku-rules

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #322 was: SUCCESS.

The Pull Request #527 was integrated: "18217-Settings-What-are-Renkaku-rules"
Pull request url: https://github.com/pharo-project/pharo/pull/527

Issue Url: https://pharo.fogbugz.com/f/cases/18217
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/322/

Re: [Pharo-dev] nil inspect

[Sven Van Caekenberghe]

> On 23 Nov 2017, at 17:01, Dimitris Chloupis  wrote:
> 
> yeah i see it now, I asked earlier on because I did not have access to a 
> computer (was replying from my tablet). I see now that is an object, though 
> its weird that nil is an instance of UndefinedObject but yet, that class has 
> nil as instance variable

What do you mean ?

UndefinedObject has no instance variables, it is empty. It defines behaviour 
that is specific to its instances like any class. It just happens that there is 
only one unique system defined instance of it, with a reserved literal name. 
Just like true and false (classes True and False, subclasses of Boolean).

> not one of the good designs of Smalltalk, if this is not Pharo specific.

I would not make such comments unless you know what you are talking about ;-) 

These are actually quite elegant design decisions.

> I do not see the point of being an instance of a class and also an instance 
> variable of that class. Is there a point ?
> 
> On Thu, Nov 23, 2017 at 12:23 PM Guillermo Polito  
> wrote:
> Hi Dimitris,
> 
> nil **is** an object. A normal object.
> 
> From your wikipedia quote: The true, false, and nil pseudo-variables are 
> singleton instances.
> 
> You can try many things to try to convince yourself:
> 
>   - nil class => UndefinedObject
>   - nil sizeInMemory => 8 (2 object headers, no instance variables)
> 
> You can also take a look at the bootstrap and see how it is created.
> 
> And it may make sense to have the same inspection tabs as any other normal 
> object that has no instance variables.
> 
> On Thu, Nov 23, 2017 at 11:14 AM, Dimitris Chloupis  
> wrote:
> looks like wikipedia agrees with me, but I have to confess never looked at 
> the Pharo implementation so I may still be wrong
> 
> "Smalltalk-80 syntax is rather minimalist, based on only a handful of 
> declarations and reserved words. In fact, only six "keywords" are reserved in 
> Smalltalk: true, false, nil, self, super, and thisContext. These are actually 
> called pseudo-variables, identifiers that follow the rules for variable 
> identifiers but denote bindings that the programmer cannot change. The true, 
> false, and nil pseudo-variables are singleton instances. self and super refer 
> to the receiver of a message within a method activated in response to that 
> message, but sends to super are looked up in the superclass of the method's 
> defining class rather than the class of the receiver, which allows methods in 
> subclasses to invoke methods of the same name in superclasses. thisContext 
> refers to the current activation record. The only built-in language 
> constructs are message sends, assignment, method return and literal syntax 
> for some objects. From its origins as a language for children of all ages, 
> standard Smalltalk syntax uses punctuation in a manner more like English than 
> mainstream coding languages. The remainder of the language, including control 
> structures for conditional evaluation and iteration, is implemented on top of 
> the built-in constructs by the standard Smalltalk class library. (For 
> performance reasons, implementations may recognize and treat as special some 
> of those messages; however, this is only an optimization and is not hardwired 
> into the language syntax.)"
> 
> https://en.wikipedia.org/wiki/Smalltalk
> 
> Or maybe there is more here tha meets the eye ?
> 
> On Thu, Nov 23, 2017 at 12:10 PM Dimitris Chloupis  
> wrote:
> is it ? I always thought it was just one of those things that is not an 
> object , together with super and self. I vaguelly remember that 5-6 words in 
> Smalltalk are not objects. 
> 
> If it is an actual object and not something else wrapped in a very thin 
> object, I can see the reason for inspection. Otherwise I cannot say I see it. 
> 
> On Thu, Nov 23, 2017 at 10:45 AM Denis Kudriashov  
> wrote:
> But it is not nothing. It is real object.
> 
> 2017-11-23 9:03 GMT+01:00 Dimitris Chloupis :
> Personally I love it
> 
>  what you find when you search for nothing ?
> 
> Nothing 
> 
> :D 
> 
> On Wed, Nov 22, 2017 at 10:23 PM Stephane Ducasse  
> wrote:
> Indeed I do not really like the blank window. 
> 
> On Sat, Nov 18, 2017 at 10:18 PM, Nicolas Cellier 
>  wrote:
> Ah OK, it's expected then?
> I find that surprising, because I could maybe want to look at meta side like 
> I can for other elementary objects:
> 
> 
> 
> 2017-11-18 22:03 GMT+01:00 Aliaksei Syrel :
> Yes
> 
> 
> 
> Cheers,
> Alex
> 
> On 18 November 2017 at 21:56, Nicolas Cellier 
>  wrote:
> Anyone tried 'nil inspect' recently?
> 
> 
> 
> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 

[Pharo-dev] [Pharo 7.0-dev] Build #321: 17641-remove-HasNewFinalization-class-var-from-WeakFinalizationList

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #321 was: SUCCESS.

The Pull Request #520 was integrated: 
"17641-remove-HasNewFinalization-class-var-from-WeakFinalizationList"
Pull request url: https://github.com/pharo-project/pharo/pull/520

Issue Url: https://pharo.fogbugz.com/f/cases/17641
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/321/

[Pharo-dev] [Pharo 7.0-dev] Build #320: 20736-update-iceberg-to-063

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #320 was: SUCCESS.

The Pull Request #518 was integrated: "20736-update-iceberg-to-063"
Pull request url: https://github.com/pharo-project/pharo/pull/518

Issue Url: https://pharo.fogbugz.com/f/cases/20736
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/320/

[Pharo-dev] [Pharo 7.0-dev] Build #319: 20742 Unused temps in Morph, MalSccNodeDecomposition and MethodNode

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #319 was: SUCCESS.

The Pull Request #525 was integrated: "20742 Unused temps in Morph, 
MalSccNodeDecomposition and MethodNode"
Pull request url: https://github.com/pharo-project/pharo/pull/525

Issue Url: https://pharo.fogbugz.com/f/cases/20742
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/319/

Re: [Pharo-dev] [PHARO 7.0A] NEXT ENHANCEMENTS

[p...@highoctane.be]

Yes, very.

Phil

On Thu, Nov 23, 2017 at 12:26 PM, Alexandre Bergel 
wrote:

> Impressive!!
>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Nov 23, 2017, at 7:12 AM, Stephane Ducasse 
> wrote:
>
> eport period: 5 November 2017 to 23 November 2017
>
> *  20739-Remove-dead-stream-primitives
>
> https://pharo.fogbugz.com/f/cases/20739/Remove-dead-stream-primitives
>
>
>  Issue URL: https://pharo.fogbugz.com/f/cases/20739
>  PR URL: https://github.com/pharo-project/pharo/pull/524
>  Diff URL: https://github.com/pharo-project/pharo/pull/524/files
>
>  Thanks to clementbera
>
> *  20645-Windows-rebuildFieldAccessors-problem
>
> Fixing the creation of annonymous classes for FFITypeArray.
> It was affecting all the platforms.
>
> Issue: https://pharo.fogbugz.com/f/cases/20645/Windows-
> rebuildFieldAccessors-problem
>
>
>  Issue URL: https://pharo.fogbugz.com/f/cases/20645
>  PR URL: https://github.com/pharo-project/pharo/pull/521
>  Diff URL: https://github.com/pharo-project/pharo/pull/521/files
>
>  Thanks to tesonep
>
> *  20735-ComposablePresenter-classowneron-is-missing-the-
> initialization-call
>
> https://pharo.fogbugz.com/f/cases/20735/ComposablePresenter-class-
> owner-on-is-missing-the-initialization-call
>
>
>  Issue URL: https://pharo.fogbugz.com/f/cases/20735
>  PR URL: https://github.com/pharo-project/pharo/pull/517
>  Diff URL: https://github.com/pharo-project/pharo/pull/517/files
>
>  Thanks to pavel-krivanek
>
> *  Fix the sign of FloatNegativeZero
>
> Like any other zero, the sign of Float negativeZero should be zero…
> Introduce signBit to differentiate Float negativeZero from Float zero.
>
> This is issue
>
> https://pharo.fogbugz.com/f/cases/19629/0-0-sign-answers-1-should-be-zero
>
>
> Note that this PR does not implement isSignMinus which is not
>
> strictly necessary.
>
> If it’s for ISO 10967 compliance, then there will be other
>
> functions missing.
>
> Maybe open a new issue for this one?
>
>
>  Issue URL: https://pharo.fogbugz.com/f/cases/Fix the sign of
> FloatNegativeZero
>  PR URL: https://github.com/pharo-project/pharo/pull/515
>  Diff URL: https://github.com/pharo-project/pharo/pull/515/files
>
>  Thanks to nicolas-cellier-aka-nice
>
> *  20717-Duplicities-of-themes-in-the-list-2
>
> https://pharo.fogbugz.com/f/cases/20717/Duplicities-of-themes-in-the-list
>
> alternative version by Torsten
>
>
>  Issue URL: https://pharo.fogbugz.com/f/cases/20717
>  PR URL: https://github.com/pharo-project/pharo/pull/499
>  Diff URL: https://github.com/pharo-project/pharo/pull/499/files
>
>  Thanks to pavel-krivanek
>
> *  20730 Unused temps in FileReferenceTest, FLHeaderSerializationTest,
> FLHookedSubstitutionTest, FT2GlyphRenderer, ...
>
> Fix unused temps in
>
> FileReferenceTest>>#testRename
> FileReferenceTest>>#testDeleteAllChildren
> FileReferenceTest>>#testHasChildren
> FileReferenceTest>>#testHasDirectories
> FileReferenceTest>>#testHasFiles
> FLHeaderSerializationTest>>#testAdditionalObjects
> FLHookedSubstitutionTest>>#testAvoidRecursion
> FT2GlyphRenderer>>#loadSurfaceTransform
> FT2GlyphRenderer>>#loadUnicode:
> FileDialogWindowTest>>#testIssue6406
> FileReferenceTest>>#testDeleteAll
>
>
>  Issue URL: https://pharo.fogbugz.com/f/cases/20730 Unused temps
> in FileReferenceTest, FLHeaderSerializationTest,
> FLHookedSubstitutionTest, FT2GlyphRenderer, ...
>  PR URL: https://github.com/pharo-project/pharo/pull/510
>  Diff URL: https://github.com/pharo-project/pharo/pull/510/files
>
>  Thanks to astares
>
> *  20731 Unused temps in HDCoverageReport and HDLintReport
>
> fix unused temps
>
> HDCoverageReport>>#generatePackage:method:on:
> HDLintReport>>#generateClass:source:on:
>
>
> https://pharo.fogbugz.com/f/cases/20731/Unused-temps-in-
> HDCoverageReport-and-HDLintReport
>
>
>  Issue URL: https://pharo.fogbugz.com/f/cases/20731 Unused temps
> in HDCoverageReport and HDLintReport
>  PR URL: https://github.com/pharo-project/pharo/pull/511
>  Diff URL: https://github.com/pharo-project/pharo/pull/511/files
>
>  Thanks to astares
>
> *  20732 Unused temps in HistoryNodeTest
>
> fix unused temps
>
> HistoryNodeTest>>#testTwoConsecutiveCloseGroup
> HistoryNodeTest>>#testTwoGroups
>
> https://pharo.fogbugz.com/f/cases/20732/Unused-temps-in-HistoryNodeTest
>
>
>  Issue URL: https://pharo.fogbugz.com/f/cases/20732 Unused temps
> in HistoryNodeTest
>  PR URL: https://github.com/pharo-project/pharo/pull/512
>  Diff URL: https://github.com/pharo-project/pharo/pull/512/files
>
>  Thanks to astares
>
> *  20733-update-bootstrap-emulation
>
> https://pharo.fogbugz.com/f/cases/20733/update-bootstrap-emulation
>
>
>  Issue URL: https://pharo.fogbugz.com/f/cases/20733
>  PR URL: 

Re: [Pharo-dev] [PHARO 7.0A] NEXT ENHANCEMENTS

[Alexandre Bergel]

Impressive!!


-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Nov 23, 2017, at 7:12 AM, Stephane Ducasse  wrote:
> 
> eport period: 5 November 2017 to 23 November 2017
> 
> *  20739-Remove-dead-stream-primitives
>>> https://pharo.fogbugz.com/f/cases/20739/Remove-dead-stream-primitives
> 
>  Issue URL: https://pharo.fogbugz.com/f/cases/20739
>  PR URL: https://github.com/pharo-project/pharo/pull/524
>  Diff URL: https://github.com/pharo-project/pharo/pull/524/files
> 
>  Thanks to clementbera
> 
> *  20645-Windows-rebuildFieldAccessors-problem
>>> Fixing the creation of annonymous classes for FFITypeArray.
>>> It was affecting all the platforms.
>>> 
>>> Issue: 
>>> https://pharo.fogbugz.com/f/cases/20645/Windows-rebuildFieldAccessors-problem
> 
>  Issue URL: https://pharo.fogbugz.com/f/cases/20645
>  PR URL: https://github.com/pharo-project/pharo/pull/521
>  Diff URL: https://github.com/pharo-project/pharo/pull/521/files
> 
>  Thanks to tesonep
> 
> *  20735-ComposablePresenter-classowneron-is-missing-the-initialization-call
>>> https://pharo.fogbugz.com/f/cases/20735/ComposablePresenter-class-owner-on-is-missing-the-initialization-call
> 
>  Issue URL: https://pharo.fogbugz.com/f/cases/20735
>  PR URL: https://github.com/pharo-project/pharo/pull/517
>  Diff URL: https://github.com/pharo-project/pharo/pull/517/files
> 
>  Thanks to pavel-krivanek
> 
> *  Fix the sign of FloatNegativeZero
>>> Like any other zero, the sign of Float negativeZero should be zero…
>>> Introduce signBit to differentiate Float negativeZero from Float zero.
>>> 
>>> This is issue
> https://pharo.fogbugz.com/f/cases/19629/0-0-sign-answers-1-should-be-zero
>>> 
>>> Note that this PR does not implement isSignMinus which is not
> strictly necessary.
>>> If it’s for ISO 10967 compliance, then there will be other
> functions missing.
>>> Maybe open a new issue for this one?
> 
>  Issue URL: https://pharo.fogbugz.com/f/cases/Fix the sign of
> FloatNegativeZero
>  PR URL: https://github.com/pharo-project/pharo/pull/515
>  Diff URL: https://github.com/pharo-project/pharo/pull/515/files
> 
>  Thanks to nicolas-cellier-aka-nice
> 
> *  20717-Duplicities-of-themes-in-the-list-2
>>> https://pharo.fogbugz.com/f/cases/20717/Duplicities-of-themes-in-the-list
>>> 
>>> alternative version by Torsten
> 
>  Issue URL: https://pharo.fogbugz.com/f/cases/20717
>  PR URL: https://github.com/pharo-project/pharo/pull/499
>  Diff URL: https://github.com/pharo-project/pharo/pull/499/files
> 
>  Thanks to pavel-krivanek
> 
> *  20730 Unused temps in FileReferenceTest, FLHeaderSerializationTest,
> FLHookedSubstitutionTest, FT2GlyphRenderer, ...
>>> Fix unused temps in
>>> 
>>> FileReferenceTest>>#testRename
>>> FileReferenceTest>>#testDeleteAllChildren
>>> FileReferenceTest>>#testHasChildren
>>> FileReferenceTest>>#testHasDirectories
>>> FileReferenceTest>>#testHasFiles
>>> FLHeaderSerializationTest>>#testAdditionalObjects
>>> FLHookedSubstitutionTest>>#testAvoidRecursion
>>> FT2GlyphRenderer>>#loadSurfaceTransform
>>> FT2GlyphRenderer>>#loadUnicode:
>>> FileDialogWindowTest>>#testIssue6406
>>> FileReferenceTest>>#testDeleteAll
> 
>  Issue URL: https://pharo.fogbugz.com/f/cases/20730 Unused temps
> in FileReferenceTest, FLHeaderSerializationTest,
> FLHookedSubstitutionTest, FT2GlyphRenderer, ...
>  PR URL: https://github.com/pharo-project/pharo/pull/510
>  Diff URL: https://github.com/pharo-project/pharo/pull/510/files
> 
>  Thanks to astares
> 
> *  20731 Unused temps in HDCoverageReport and HDLintReport
>>> fix unused temps
>>> 
>>> HDCoverageReport>>#generatePackage:method:on:
>>> HDLintReport>>#generateClass:source:on:
>>> 
>>> 
>>> https://pharo.fogbugz.com/f/cases/20731/Unused-temps-in-HDCoverageReport-and-HDLintReport
> 
>  Issue URL: https://pharo.fogbugz.com/f/cases/20731 Unused temps
> in HDCoverageReport and HDLintReport
>  PR URL: https://github.com/pharo-project/pharo/pull/511
>  Diff URL: https://github.com/pharo-project/pharo/pull/511/files
> 
>  Thanks to astares
> 
> *  20732 Unused temps in HistoryNodeTest
>>> fix unused temps
>>> 
>>> HistoryNodeTest>>#testTwoConsecutiveCloseGroup
>>> HistoryNodeTest>>#testTwoGroups
>>> 
>>> https://pharo.fogbugz.com/f/cases/20732/Unused-temps-in-HistoryNodeTest
> 
>  Issue URL: https://pharo.fogbugz.com/f/cases/20732 Unused temps
> in HistoryNodeTest
>  PR URL: https://github.com/pharo-project/pharo/pull/512
>  Diff URL: https://github.com/pharo-project/pharo/pull/512/files
> 
>  Thanks to astares
> 
> *  20733-update-bootstrap-emulation
>>> https://pharo.fogbugz.com/f/cases/20733/update-bootstrap-emulation
> 
>  Issue URL: https://pharo.fogbugz.com/f/cases/20733
>  PR URL: https://github.com/pharo-project/pharo/pull/516
>  Diff URL: 

[Pharo-dev] [PHARO 7.0A] NEXT ENHANCEMENTS

[Stephane Ducasse]

eport period: 5 November 2017 to 23 November 2017

*  20739-Remove-dead-stream-primitives
 >> https://pharo.fogbugz.com/f/cases/20739/Remove-dead-stream-primitives

  Issue URL: https://pharo.fogbugz.com/f/cases/20739
  PR URL: https://github.com/pharo-project/pharo/pull/524
  Diff URL: https://github.com/pharo-project/pharo/pull/524/files

  Thanks to clementbera

*  20645-Windows-rebuildFieldAccessors-problem
 >> Fixing the creation of annonymous classes for FFITypeArray.
 >> It was affecting all the platforms.
 >>
 >> Issue: 
https://pharo.fogbugz.com/f/cases/20645/Windows-rebuildFieldAccessors-problem

  Issue URL: https://pharo.fogbugz.com/f/cases/20645
  PR URL: https://github.com/pharo-project/pharo/pull/521
  Diff URL: https://github.com/pharo-project/pharo/pull/521/files

  Thanks to tesonep

*  20735-ComposablePresenter-classowneron-is-missing-the-initialization-call
 >> 
https://pharo.fogbugz.com/f/cases/20735/ComposablePresenter-class-owner-on-is-missing-the-initialization-call

  Issue URL: https://pharo.fogbugz.com/f/cases/20735
  PR URL: https://github.com/pharo-project/pharo/pull/517
  Diff URL: https://github.com/pharo-project/pharo/pull/517/files

  Thanks to pavel-krivanek

*  Fix the sign of FloatNegativeZero
 >> Like any other zero, the sign of Float negativeZero should be zero…
 >> Introduce signBit to differentiate Float negativeZero from Float zero.
 >>
 >> This is issue
https://pharo.fogbugz.com/f/cases/19629/0-0-sign-answers-1-should-be-zero
 >>
 >> Note that this PR does not implement isSignMinus which is not
strictly necessary.
 >> If it’s for ISO 10967 compliance, then there will be other
functions missing.
 >> Maybe open a new issue for this one?

  Issue URL: https://pharo.fogbugz.com/f/cases/Fix the sign of
FloatNegativeZero
  PR URL: https://github.com/pharo-project/pharo/pull/515
  Diff URL: https://github.com/pharo-project/pharo/pull/515/files

  Thanks to nicolas-cellier-aka-nice

*  20717-Duplicities-of-themes-in-the-list-2
 >> 
https://pharo.fogbugz.com/f/cases/20717/Duplicities-of-themes-in-the-list
 >>
 >> alternative version by Torsten

  Issue URL: https://pharo.fogbugz.com/f/cases/20717
  PR URL: https://github.com/pharo-project/pharo/pull/499
  Diff URL: https://github.com/pharo-project/pharo/pull/499/files

  Thanks to pavel-krivanek

*  20730 Unused temps in FileReferenceTest, FLHeaderSerializationTest,
FLHookedSubstitutionTest, FT2GlyphRenderer, ...
 >> Fix unused temps in
 >>
 >> FileReferenceTest>>#testRename
 >> FileReferenceTest>>#testDeleteAllChildren
 >> FileReferenceTest>>#testHasChildren
 >> FileReferenceTest>>#testHasDirectories
 >> FileReferenceTest>>#testHasFiles
 >> FLHeaderSerializationTest>>#testAdditionalObjects
 >> FLHookedSubstitutionTest>>#testAvoidRecursion
 >> FT2GlyphRenderer>>#loadSurfaceTransform
 >> FT2GlyphRenderer>>#loadUnicode:
 >> FileDialogWindowTest>>#testIssue6406
 >> FileReferenceTest>>#testDeleteAll

  Issue URL: https://pharo.fogbugz.com/f/cases/20730 Unused temps
in FileReferenceTest, FLHeaderSerializationTest,
FLHookedSubstitutionTest, FT2GlyphRenderer, ...
  PR URL: https://github.com/pharo-project/pharo/pull/510
  Diff URL: https://github.com/pharo-project/pharo/pull/510/files

  Thanks to astares

*  20731 Unused temps in HDCoverageReport and HDLintReport
 >> fix unused temps
 >>
 >> HDCoverageReport>>#generatePackage:method:on:
 >> HDLintReport>>#generateClass:source:on:
 >>
 >>
 >> 
https://pharo.fogbugz.com/f/cases/20731/Unused-temps-in-HDCoverageReport-and-HDLintReport

  Issue URL: https://pharo.fogbugz.com/f/cases/20731 Unused temps
in HDCoverageReport and HDLintReport
  PR URL: https://github.com/pharo-project/pharo/pull/511
  Diff URL: https://github.com/pharo-project/pharo/pull/511/files

  Thanks to astares

*  20732 Unused temps in HistoryNodeTest
 >> fix unused temps
 >>
 >> HistoryNodeTest>>#testTwoConsecutiveCloseGroup
 >> HistoryNodeTest>>#testTwoGroups
 >>
 >> https://pharo.fogbugz.com/f/cases/20732/Unused-temps-in-HistoryNodeTest

  Issue URL: https://pharo.fogbugz.com/f/cases/20732 Unused temps
in HistoryNodeTest
  PR URL: https://github.com/pharo-project/pharo/pull/512
  Diff URL: https://github.com/pharo-project/pharo/pull/512/files

  Thanks to astares

*  20733-update-bootstrap-emulation
 >> https://pharo.fogbugz.com/f/cases/20733/update-bootstrap-emulation

  Issue URL: https://pharo.fogbugz.com/f/cases/20733
  PR URL: https://github.com/pharo-project/pharo/pull/516
  Diff URL: https://github.com/pharo-project/pharo/pull/516/files

  Thanks to pavel-krivanek

*  20384-Converted-rules-to-Renraku-architecture-2
 >> Let's try this one, it should work

  Issue URL: 

Re: [Pharo-dev] Advent of code

[philippe.b...@highoctane.be]

I made an adventofcode channel in Discord. Time for bots...

Phil

On Nov 22, 2017 21:25, "Stephane Ducasse"  wrote:

> Ok can you put a link on the advent of code web page?
>
> On Wed, Nov 22, 2017 at 9:11 PM, Julien 
> wrote:
>
>> I’ll write a README with some instructions to avoid clash when merging
>> pull requests.
>>
>> For example, each participant could create a directory with its name and
>> put all his stuff inside it.
>>
>> Julien
>>
>> Le 22 nov. 2017 à 21:09, Stephane Ducasse  a
>> écrit :
>>
>> Tx I forked it.
>>
>> On Wed, Nov 22, 2017 at 5:38 PM, Julien 
>> wrote:
>>
>>> Ok I created one [1], maybe if multiple people are playing with me we
>>> can gather the different solutions we get for each puzzle in this
>>> repository.
>>>
>>> Julien
>>>
>>> [1]: https://github.com/juliendelplanque/AdventOfCode2017WithPharo
>>>
>>> Le 22 nov. 2017 à 16:55, Stephane Ducasse  a
>>> écrit :
>>>
>>> Julien
>>>
>>> could you open a github project so that we can do the same as norviq?
>>> And get a log of the problems and solution?
>>>
>>> Stef
>>>
>>> On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich <
>>> serge.stinckw...@gmail.com> wrote:
>>>
 BTW, the Japanese Smalltalk community is doing an advent Calendar every
 year:

 https://qiita.com/advent-calendar/2016/smalltalk

 The 2017 edition is in preparation here: https://qiita.com/advent-calen
 dar/2017/smalltalk



 On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse <
 stepharo.s...@gmail.com> wrote:

> Hi pharoers
>
> I would like to know if you would like to participate to
> http://adventofcode.com/2016
>
> For example we could do the same as
> https://github.com/norvig/pytudes/blob/master/ipynb/Advent%2
> 0of%20Code.ipynb
>
> Stef
>
>


 --
 Serge Stinckwich
 UMI UMMISCO 209 (IRD/UPMC/UY1)
 "Programs must be written for people to read, and only incidentally for
 machines to execute."http://www.doesnotunderstand.org/

>>>
>>>
>>>
>>
>>
>

[Pharo-dev] I love the launcher!!!!

[Stephane Ducasse]

Hi

I love the PharoLauncher.
It helps me to manage my parallel development and projects.

We should put a link on the Pharo web site because

http://files.pharo.org/platform/launcher/

is arcane.

Stef

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo TechTalk 21 Nov: Discord Demo

[Dimitris Chloupis]

On Wed, Nov 22, 2017 at 6:03 PM Juraj Kubelka 
wrote:

>
> On Nov 21, 2017, at 19:54, Dimitris Chloupis 
> wrote:
>
> Well done :)
>
> Now you can make a discord client inside the Pharo image if you want.
>
>
> Exactly :-) I am looking for integrations that improve the developer
> experience. Maybe the interface should be different from the standard
> client. The question is how to integrate and why? What do you think?
>
> Cheers,
> Juraj
>

Well its a highly personally question

For me it was easy to, well realtive easy, because my Atlas pharo library
allows me to use any python library fron inside Pharo , so techically I
could use the existing Python API to make a Discord client inside Pharo ,
without a need to create a wrapper (live tranlation and executing of code).

I was already familiar with the Discord API because I made a bot for the
Discord server (I am the one that created the Discord server for Pharo. I
did not intend to move the community from Slack to Discord , but Esteban
liked its so much that pused it forward as an idea and it did happen). The
API its quite simple so making a client inside Pharo should not be hard.

But never felt the need to have a Discord client inside Pharo. On the other
hand I never expected our Discord community to grow so large and so active,
so fast. Unfortunately I decided to take on creating a Python project so I
did not have much usage for Pharo (Python is embeded so it makes Pharo
usage quite tricky for me) lately but I am still available for advice,
recommendations and so forth.

If you start making a Discord client inside the image, make sure you join
the Discord API server, they are extremely helpful and they even have a
channel for testing bots. A Discord bot uses the same API as a potential
client.

Now on the how...

What I would have done would have been to add the client as tab to the
welcome dialog we have when ones first open the image and also as an option
to GTSpotter , it would be in the form of "Ask Pharo a Question" and it
would send the question directly to our help channel so that beginners
could get real time help with any problem they had even those unaware of
the existance of Discord. Obviously the option would also exist to expand
it to a full Discord interface but my idea was mostly to keep it simple and
minimal. One channel, one line, one inpute, and one short list of messages
scrolling back and forward.

Thats one way, there are obviously billions of other ways to do this.