[Pharo-dev] Esteban's ChangeLog week of 7 January 2019

[estebanlm]

Hello!

This is my weekly ChangeLog, from 7 January 2019 to 13 January 2019.
You can see it in a better format by going here: 
http://log.smallworks.eu/web/search?from=7/1/2019=13/1/2019

ChangeLog
=

11 January 2019:


*Finally fixed bootstrap issues related to Pharo8.0 development. 

Now we are ready to go :)

Issues fixed: 

* 
[https://github.com/pharo-project/pharo/pull/2214](https://github.com/pharo-project/pharo/pull/2214)
* 
[https://github.com/pharo-project/pharo/issues/2212](https://github.com/pharo-project/pharo/issues/2212)
* 
[https://github.com/pharo-project/pharo/issues/2129](https://github.com/pharo-project/pharo/issues/2129)
* 
[https://github.com/pharo-project/pharo/issues/2211](https://github.com/pharo-project/pharo/issues/2211)
* 
[https://github.com/pharo-project/pharo/issues/2130](https://github.com/pharo-project/pharo/issues/2130)


9 January 2019:
---

*I've been working on release Pharo7.0 as soon as possible. 

For that, Pharo8.0 development needs to be in place and there were some 
errors on the bootstrap. I'm working on those: 

* [2129](https://github.com/pharo-project/pharo/issues/2129)
* [2130](https://github.com/pharo-project/pharo/issues/2130)

Both are kind of related, since it depends on how to take correctly the 
working branch. 

Anyway... not finished, but almost :)


cheers! 
Esteban

Re: [Pharo-dev] Availability of Smallapack in Pharo6.0

[Nicolas Cellier]

Le sam. 12 janv. 2019 à 14:14, Denis Kudriashov  a
écrit :

> Hi Nicolas
>
> пт, 11 янв. 2019 г. в 23:34, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com>:
>
>> Hi,
>> I announce the availability of Smallapack in Pharo6.
>>
>> The ConfigurationOfSmallapack is in
>> http://www.squeaksource.com/MetacelloRepository and there is a copy in
>> meta repo for Pharo 3/4/5/6.
>>
>> Currently, the ported version uses a derivative of OpalCompiler patched
>> to handle method with 16+ arguments.
>> External function calls have not been converted yet to UnifiedFFI, but
>> the patched compiler rather has hook to compile legacy FFI.
>> Though I did not install the hook to call FFI with more than 15
>> arguments, so there is at least 1 unit test failing (but not crashing).
>>
>> I have auto-re-generated all the source code for using UnifiedFFI
>> formats, so the dependency on legacy FFI is not a necessity (apart for
>> simplifying cross dialect maintenance).
>>
>> But I want to review the generated code method by method rather than
>> filing it in blindly (the wrapper functions are also generated, and I might
>> loose comments or improvments if I'm careless). Unfortunately, the state of
>> diff tools in Pharo6, be it thru MC or worse than all, thru legacy change
>> lists, does not enable such a large scale review, so I think that I will
>> edit in Squeak and run in Pharo...
>>
>> Now that Smallapack supports Opal, there should be no major problem for
>> porting to Pharo7, but I did not have time to try yet. A few more MC
>> regressions, and the fact to forbid protocol beginning with a * was too
>> serious a cross compatibility hurdle for me.
>>
>
> Protocol with star is still convention to store class extensions in files.
> No compatibility issues here. Calypso just hides it from user because
> package and protocol is not the same thing. And I hope in Pharo 8 we will
> support multiple protocols and separate packaging. But more important is to
> finely clean RPackage implementation. The current way how method is became
> bound to package is horrible.
>
>

Hi Denis,
OK, but hiding is troubling...
When I came from VW, I found that Squeak categories matching package names
was a quick and dirty hack.
Since then, I find it works remarkably well, it is somehow a declarative
meta information (method property), and I much prefer that to hidden
package classification accessible from an IDE only.
It still happens to me to loose methods in VW because they are not packaged
or wrongly packaged, so I'm not sure that cleaning is winning in that case.
And if you go with multiple classifications, then there's no reason to not
keep the hack.

But I'll come back to it, tools are generally better in ph7 than ph6. Stay
>> tuned.
>>
>>

Re: [Pharo-dev] Shortcut for programmatically executing a class side method ?

[Gabriel Cotelli]

String perform: #method

On Sun, Jan 13, 2019, 18:42 Sven Van Caekenberghe  Hi,
>
> Does there exist a shortcut for programmatically executing a class side
> method ?
>
> For example,
>
> String class>>#loremIpsum in: [ :method |
>   method methodClass instanceSide perform: method selector ].
>
> I was looking for a shortcut, like #eval, #execute, #value or something
> like that.
>
> (String class>>#loremIpsum) eval.
>
> Sven
>

Re: [Pharo-dev] Shortcut for programmatically executing a class side method ?

[Nicolas Cellier]

Normally, primitive 188 and 189 execute a method (the receiver is the
method receiver).
Maybe search for senders...

Le dim. 13 janv. 2019 à 22:42, Sven Van Caekenberghe  a
écrit :

> Hi,
>
> Does there exist a shortcut for programmatically executing a class side
> method ?
>
> For example,
>
> String class>>#loremIpsum in: [ :method |
>   method methodClass instanceSide perform: method selector ].
>
> I was looking for a shortcut, like #eval, #execute, #value or something
> like that.
>
> (String class>>#loremIpsum) eval.
>
> Sven
>

[Pharo-dev] Shortcut for programmatically executing a class side method ?

[Sven Van Caekenberghe]

Hi,

Does there exist a shortcut for programmatically executing a class side method ?

For example,

String class>>#loremIpsum in: [ :method | 
  method methodClass instanceSide perform: method selector ].

I was looking for a shortcut, like #eval, #execute, #value or something like 
that.

(String class>>#loremIpsum) eval.

Sven

Re: [Pharo-dev] Development process: testing the GUI

[Nicolas Cellier]

Sure, it will require more uniform API.
Elm has an advantage with static typing, but I'm sure we can do without it.
Maybe this should be integrated in the requirements/objectives of next
frameworks.

Le dim. 13 janv. 2019 à 10:53, Esteban Lorenzano  a
écrit :

> Hi,
>
> Well… we “plan” to have tests also on UI.
> But this is hard.
> And not just because of the tooling, but also because having a coherent
> metaphor to organise everything is hard.
> We are working (very slowly) in that direction.
> And eventually, we would like to have also UI tests.
>
> Esteban
>
>
> On 12 Jan 2019, at 23:34, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
> Hi all,
> Pharo team is attaching great care in securing and improving the
> development process, notably by promoting usage of tests and continuous
> integration.
>
> I think a very good job is already done in the libraries provided by
> Pharo. But sometimes I encounter more hickups with the development tools
> themselves.
> So I wonder: does this apply to the GUI yet?
> This is a difficult area, but nowadays this exists elsewhere.
> For example, with Elm and Elmer (
> https://medium.com/@brian.watkins/test-driving-elm-with-elmer-649e2e7e02a8),
> TDD can be applied on UI, providing both a formal specification and non
> regression tests.
> Do we have something similar?
> Don't we wish having something similar?
>
>
>

[Pharo-dev] [Pharo 7.0] Build #121: 22885-Rename-Calypso-Queries-to-have-Query-suffix

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #121 was: SUCCESS.

The Pull Request #2223 was integrated: 
"22885-Rename-Calypso-Queries-to-have-Query-suffix"
Pull request url: https://github.com/pharo-project/pharo/pull/2223

Issue Url: https://pharo.fogbugz.com/f/cases/22885
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/121/

Re: [Pharo-dev] Development process: testing the GUI

[Esteban Lorenzano]

Hi, 

Well… we “plan” to have tests also on UI. 
But this is hard. 
And not just because of the tooling, but also because having a coherent 
metaphor to organise everything is hard. 
We are working (very slowly) in that direction.
And eventually, we would like to have also UI tests. 

Esteban


> On 12 Jan 2019, at 23:34, Nicolas Cellier 
>  wrote:
> 
> Hi all,
> Pharo team is attaching great care in securing and improving the development 
> process, notably by promoting usage of tests and continuous integration.
> 
> I think a very good job is already done in the libraries provided by Pharo. 
> But sometimes I encounter more hickups with the development tools themselves.
> So I wonder: does this apply to the GUI yet?
> This is a difficult area, but nowadays this exists elsewhere.
> For example, with Elm and Elmer 
> (https://medium.com/@brian.watkins/test-driving-elm-with-elmer-649e2e7e02a8 
> ),
>  TDD can be applied on UI, providing both a formal specification and non 
> regression tests.
> Do we have something similar?
> Don't we wish having something similar?