[Pharo-dev] GSOC Mentors - We need you.

[Serge Stinckwich]

Dear mentors,

we are currently reviewing all the students proposals. Please join the
#gsoc-planning on Discord for giving your insights about the students.
The deadline for the final selection will be Monday 24th 6pm CEST.

As a reminder, we have 5 slots given by Google this year.
Regards,
-- 
Serge Stinckwich
UCN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-dev] Help browser topic ordering

[Juraj Kubelka]

> El 22-04-2017, a las 01:04, Ben Coman  escribió:
> 
> What is it that defines the ordering of topics in the help browser?
> 
> I see slice 19963 added a "Travis Integration" topic into build 60468
> http://forum.world.st/pharo-project-pharo-core-7bde98-60468-td4942945.html
> 

This is an error that Alexandre likely forgot to submit, because I was with 
him, when we noticed it and fixed it. 

> and its ended up at the top of the list above "Welcome",
> but I determine from the slice or other existing help topics
> where the order is defined?

It is ordered by topic name, but you can notice that Welcome Help has String 
withValue: 0 at the beginning in order to be the first.

Juraj

> 
> cheers -ben
> 

Re: [Pharo-dev] Traits methods flattened

[Hilaire]

Hi Stef,

I shared with Pavel my package because the fix for pharo5 did not work
on my package.

Since years because of my incurable disease I need to take rest during
the day. When things get break in Pharo and I get stuck, I behave like
an impatient and I fell I am running out of time.

Take rest, cherish your health like your kids!

Hilaire

Le 22/04/2017 à 18:34, Stephane Ducasse a écrit :
> Thanks Pavel!!!
> I'm so tired and exhausted I nearly slept all the afternoon :(
> Not good. But I will recover. 

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] DarkTheme - tool bar icon color inconsistent

[Stephane Ducasse]

oversight :)

On Sat, Apr 22, 2017 at 6:16 AM, Ben Coman  wrote:

> n the previous white theme, toolbar icons matched the colour of their text.
> This makes a lot sense and is pleasant.
>
> In the dark theme, there is no correlation.
> Is this oversight or deliberate intent?  It jars my senses.
>
> https://pharo.fogbugz.com/f/cases/19973/DarkTheme-tool-bar-icons
>
> cheers -ben
>

Re: [Pharo-dev] [Vm-dev] Order of evaluation bug with in lined to:do: in both Opal and Squeak compilers.

[Stephane Ducasse]

I'm happy that we can remove bugs. We should redo a pass on Opal and
enhance it because we need a better architecture for our future.

Stef

On Fri, Apr 21, 2017 at 9:20 AM, Nicolai Hess  wrote:

> John Brant discovered this bug recenlty:
>
> (see bottom of his post)
> http://forum.world.st/collection-flatCollect-something-VS-collection-
> collect-something-flattened-tp4929422p4929479.html
>
>
>
> 2017-04-21 1:56 GMT+02:00 Eliot Miranda :
>
>>
>>
>>
>> On Thu, Apr 20, 2017 at 4:41 PM, Eliot Miranda 
>> wrote:
>>
>>> Hi All,
>>>
>>> just stumbled across a bytecode compiler bug that's in both the
>>> Squeak compiler and the Opal compiler.  I'm told by Clément that Opal
>>> mimics the bug to avoid crashing legacy code.  So there may be places that
>>> depend on this bug.  It would be good to eliminate the dependencies and the
>>> bug.
>>>
>>> For illustration look at the to:do: loop in the ifNil: arm in
>>> Context>>privRefresh:
>>>
>>> Context>>privRefresh
>>> "Reinitialize the receiver so that it is in the state it was at its
>>> creation."
>>> closureOrNil
>>> ifNotNil:
>>> [pc := closureOrNil startpc.
>>> self stackp: closureOrNil numArgs + closureOrNil numCopiedValues.
>>> 1 to: closureOrNil numCopiedValues do:
>>> [:i | self tempAt: closureOrNil numArgs + i put: (closureOrNil at: i)]]
>>> ifNil:
>>> [pc := method initialPC.
>>> self stackp: method numTemps.
>>> method numArgs+1 to: method numTemps do:
>>> [:i | self tempAt: i put: nil]]
>>>
>>>
>>> This should evaluate method numArgs + 1 then method numTemps.  If it
>>> were written as a non-in-lined (method numArgs+1 to: method numTemps) do:
>>> [:i| self tempAt: i put: nil] then the [self tempAt: i put: nil] block
>>> would be created next.  But the bytecode for the inlined version is
>>>
>>> self stackp: method numTemps.
>>> 63 <70> self
>>> 64 <84 40 03> pushRcvr: 3
>>> 67  send: numTemps
>>> 68  send: stackp:
>>> 69 <87> pop
>>>
>>> iLimit := method numTemps
>>> 70 <84 40 03> pushRcvr: 3
>>> 73  send: numTemps
>>> 74 <69> popIntoTemp: 1
>>>
>>> i := method numArgs + 1
>>> 75 <84 40 03> pushRcvr: 3
>>> 78  send: numArgs
>>> 79 <76> pushConstant: 1
>>> 80  send: +
>>> 81 <81 40> storeIntoTemp: 0 (squeak) <69> popIntoTemp: 1 (pharo)
>>> 83 <10> pushTemp: 0
>>> 84 <11> pushTemp: 1
>>> 85  send: <=
>>> 86  jumpFalse: 99
>>>
>>> There is a second bug in the Squeak bytecode; storeIntoTemp: is used to
>>> load i whereas it should be popIntoTemp:.  It was this second bug that
>>> alerted me to the order-of-evaluation bug.
>>>
>>
>> The second bug (Squeak's use of storeIntoTemp:) is actually only a poor
>> implementation of the value/effect distinction through the inlined
>> ifNil:ifNotNil:.  Because ifNil:ifNotNil: has a value (albeit one that is
>> discarded) the Squeak compiler generates a storeIntoTemp: to p[reserve the
>> value of the to:do: lop, which is the initial index.  So the bug is not
>> within the generation of the to:do: (the only bug there being the
>> order-of-evaluation one).  The bug is actually outside; the loop should be
>> being generated for effect but is being evaluated for value.
>>
>> On the order of evaluation bug, does anyone have any memory of which
>> methods depended on this bug?
>>
>> _,,,^..^,,,_
>>> best, Eliot
>>>
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>

Re: [Pharo-dev] Traits methods flattened

[Stephane Ducasse]

Thanks Pavel!!!
I'm so tired and exhausted I nearly slept all the afternoon :(
Not good. But I will recover.

On Sat, Apr 22, 2017 at 4:42 PM, Pavel Krivanek 
wrote:

> backported:
> https://pharo.fogbugz.com/f/cases/19974/backport-Traits-
> methods-flattened-case-19938
>
> Test please...
> -- Pavel
>
> 2017-04-22 16:31 GMT+02:00 Hilaire :
>
>> Hello again,
>>
>> The slice did not load the necessary dependency.
>>
>> Now, the test code provided in the bug ticket pass.
>>
>> However my package with non trivial Traits use is still not saved
>> correctly: traits methods are flattened in the user classes.
>>
>> I can share a fileout of the package for testing and bug tracking.
>>
>> Hilaire
>>
>>
>> Le 21/04/2017 à 19:24, Ben Coman a écrit :
>> > On Sat, Apr 22, 2017 at 12:54 AM, Hilaire  wrote:
>> >> Hi,
>> >>
>> >> I installed the slice in a Pharo5 image. It does not work on my
>> package,
>> >> nor the the test package.
>> >>
>> >> https://pharo.fogbugz.com/f/cases/19938
>> >>
>> >> Does the slice only work on Pharo6?
>> > I don't know, but I see sixty Trait related issues integrated into
>> Pharo 6.
>> > https://tinyurl.com/Pharo60IssuesTraits
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>>
>

Re: [Pharo-dev] Traits methods flattened

[Pavel Krivanek]

backported:
https://pharo.fogbugz.com/f/cases/19974/backport-Traits-methods-flattened-case-19938

Test please...
-- Pavel

2017-04-22 16:31 GMT+02:00 Hilaire :

> Hello again,
>
> The slice did not load the necessary dependency.
>
> Now, the test code provided in the bug ticket pass.
>
> However my package with non trivial Traits use is still not saved
> correctly: traits methods are flattened in the user classes.
>
> I can share a fileout of the package for testing and bug tracking.
>
> Hilaire
>
>
> Le 21/04/2017 à 19:24, Ben Coman a écrit :
> > On Sat, Apr 22, 2017 at 12:54 AM, Hilaire  wrote:
> >> Hi,
> >>
> >> I installed the slice in a Pharo5 image. It does not work on my package,
> >> nor the the test package.
> >>
> >> https://pharo.fogbugz.com/f/cases/19938
> >>
> >> Does the slice only work on Pharo6?
> > I don't know, but I see sixty Trait related issues integrated into Pharo
> 6.
> > https://tinyurl.com/Pharo60IssuesTraits
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-dev] Traits methods flattened

[Hilaire]

Hello again,

The slice did not load the necessary dependency.

Now, the test code provided in the bug ticket pass.

However my package with non trivial Traits use is still not saved
correctly: traits methods are flattened in the user classes.

I can share a fileout of the package for testing and bug tracking.

Hilaire


Le 21/04/2017 à 19:24, Ben Coman a écrit :
> On Sat, Apr 22, 2017 at 12:54 AM, Hilaire  wrote:
>> Hi,
>>
>> I installed the slice in a Pharo5 image. It does not work on my package,
>> nor the the test package.
>>
>> https://pharo.fogbugz.com/f/cases/19938
>>
>> Does the slice only work on Pharo6?
> I don't know, but I see sixty Trait related issues integrated into Pharo 6.
> https://tinyurl.com/Pharo60IssuesTraits

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] Traits methods flattened

[Hilaire]

I mean Pavel, not Peter, sorry.


Le 22/04/2017 à 11:08, Hilaire a écrit :
> Hello,
>
> I don't know either, that's why I asked ;)
>
> I hope Peter can tell us, he provided this SLICE for this specific
> problem with Traits.
>
> Hilaire

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] Implementers code pane undo goes too far

[Nicolai Hess]

2017-04-22 5:21 GMT+02:00 Ben Coman :

> This issue was introduced into build 50245 [1].  If no one has noticed
> before, its not critical for Pharo 6 (unless it exposes something that
> may bite others more widely.)
>

As far as I remember, there were a couple of issues (maybe autoclosed)
related to rubrics undo-behavior.
17601

bad undo behavior after discard changes

Some are fixed by a workaround (unset #hasUnacceptedEdits when new code is
loaded).




>
> Can reproduce by loading slice for Case 15774 on top of build 50244.
> "Make Spec using RubPluggableTextMorph instead of PluggableTextMorph "
>
> [1] http://forum.world.st/pharo-project-pharo-core-03b7d7-
> 50245-td4843802.html
>
> cheers -ben
>
> On Sat, Apr 22, 2017 at 10:54 AM, Ben Coman  wrote:
> > I hit some strange behaviour...
> >
> > Setup...
> > 1. In playground, type... green
> > 2. Open implementers on it
> > 3. Select the second line "Color class(defaults)green"
> > 4. Click in the code pane
> > Observe that "green" is pre-selected and the cursor is flashing at
> > end of first line
> > 5. Start typing... self halt.
> > Observe the method name is overwritten
> >
> > Problem...
> > 6. Hit CTRL-Z three times.
> > Observe the instance side #green is displayed rather than the class
> side.
> >
> > Auxiliary...
> > Now save it and work out how to get out of the mess
> > (pretending you didn't notice what had happened)
> >
> > https://pharo.fogbugz.com/f/cases/19972/Implementers-code-
> pane-undo-goes-too-far
> >
> > cheers -ben
>
>

Re: [Pharo-dev] Traits methods flattened

[Hilaire]

Hello,

I don't know either, that's why I asked ;)

I hope Peter can tell us, he provided this SLICE for this specific
problem with Traits.

Hilaire


Le 21/04/2017 à 19:24, Ben Coman a écrit :
>> Hi,
>>
>> I installed the slice in a Pharo5 image. It does not work on my package,
>> nor the the test package.
>>
>> https://pharo.fogbugz.com/f/cases/19938
>>
>> Does the slice only work on Pharo6?
> I don't know, but I see sixty Trait related issues integrated into Pharo 6.
> https://tinyurl.com/Pharo60IssuesTraits
>
> cheers -ben
>
>

-- 
Dr. Geo
http://drgeo.eu