Re: [Pharo-dev] Do we remove TClass?

[teso...@gmail.com]

Hi Stef,
in the new implementation of Traits I have moved that traits to a
package, they are not used at all in the image but they are used by other
projects. For example, they are used by Ficus.

Cheers,
Pablo

On Sun, Feb 11, 2018 at 6:01 PM, Stephane Ducasse 
wrote:

> Then I do not get it what it this
>
> Trait >> private_subclass: t instanceVariableNames: f
> classVariableNames: d poolDictionaries: s package: cat
>"Compatibility purposes"
>^self error: 'Traits cannot have subclasses'.
>
> How raising an error would make something compatible
> To be this is stupid code.
>
> Stef
>
>
>
> On Sun, Feb 11, 2018 at 5:51 PM, Stephane Ducasse
>  wrote:
> > Hi Happy core developers
> >
> > do we remove TClass? Because it is duplicated code, no?
> >
> > Stef
>
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] Cleaning up... baseClass, instanceSide, theNonMetaclass

[Ben Coman]

I found it quite insightful when I read someone describe that the way
Smalltalk uses Classes is essentially the Factory Pattern.
That makes me wonder whether classClass and classSide of a class might
confuse newcomers
and maybe factorySide of a class would make more sense.

The again...
https://xkcd.com/927/

cheers -ben


On 12 February 2018 at 16:45, Guillermo Polito 
wrote:

> In my code I use to use instanceSide and classSide. don't know why. Maybe
> they are clearer to me?
>
> On Sun, Feb 11, 2018 at 8:59 PM, Denis Kudriashov 
> wrote:
>
>> 2018-02-11 18:14 GMT+01:00 Stephane Ducasse :
>>
>>> Hi
>>>
>>> We already got this discussion and I plan to address it.
>>> Now I discovered that in addition to instanceSide and theNonMetaclass we
>>> have
>>>
>>> - classClass and baseClass
>>> - theMetaclass and theNonMetaclass
>>> - instanceSide and classSide
>>>
>>> https://pharo.fogbugz.com/f/cases/20941/deprecate-theMetacla
>>> ss-and-the-theNonMeta
>>>
>>> Even if instanceSide and classSide come from UI concerns I think that
>>> there are much
>>> better than the others.
>>>
>>
>> + 100
>>
>>
>>>
>>> So have you any concerns and prefer one of the other couples? Because
>>> we should stop
>>> accumulate cruft in the system. We do not need three ways to do the same.
>>>
>>> Stef
>>>
>>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

[Pharo-dev] Pavel's ChangeLog week of 2018-02-05

[Pavel Krivanek]

Hi,

among other less interesting things, I spent some time on existing
PosixSharedMemory project. It is a UFFI binding for the LibC methods
that provide support for the memory allocation between several
separate processes. I significantly improved the performance by
implementing the block access. Writing of 10MB byte array takes about
1 millisecond, reading of it from other image took me about 4
milliseconds. While serialization with Fuel is very fast, it opens
interesting possibilities.
To have a shared memory without synchronization tools is not very
useful so I wrote a basic UFFI interface for the POSIX named
semaphores. They are quite easy to use and work nicely with Pharo. The
VM can all wait on the semaphore or it can check the status of it
periodically in an image thread. It has two small disadvantages. It
requires to dynamically link the next library (pthread) and they must
be cleaned manually. I plan to look at System V alternative in future.
Now we should write a nice framework for inter-image communication on
top of it or/and adopt Seamless for it ;-)

Cheers,
-- Pavel

[Pharo-dev] [Pharo 7.0-dev] Build #532: 21312 Remove unnecessary "self run:" in ClassTraitTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #532 was: FAILURE.

The Pull Request #844 was integrated: "21312 Remove unnecessary "self run:" in 
ClassTraitTest"
Pull request url: https://github.com/pharo-project/pharo/pull/844

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

[Pharo-dev] [Pharo 7.0-dev] Build #533: 21310 Remove unnecessary "self run:" in WeakMessageSendTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #533 was: SUCCESS.

The Pull Request #845 was integrated: "21310 Remove unnecessary "self run:" in 
WeakMessageSendTest"
Pull request url: https://github.com/pharo-project/pharo/pull/845

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

[Pharo-dev] [Pharo 7.0-dev] Build #531: 21297 Remove unnecessary "self run:" in SortedCollectionTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #531 was: SUCCESS.

The Pull Request #859 was integrated: "21297 Remove unnecessary "self run:" in 
SortedCollectionTest"
Pull request url: https://github.com/pharo-project/pharo/pull/859

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

[Pharo-dev] [Pharo 7.0-dev] Build #535: 21299 Remove unnecessary "self run:" in ClassTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #535 was: FAILURE.

The Pull Request #857 was integrated: "21299 Remove unnecessary "self run:" in 
ClassTest"
Pull request url: https://github.com/pharo-project/pharo/pull/857

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

[Pharo-dev] [Pharo 7.0-dev] Build #534: 21294 Remove unnecessary "self run:" in HeapTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #534 was: SUCCESS.

The Pull Request #863 was integrated: "21294 Remove unnecessary "self run:" in 
HeapTest"
Pull request url: https://github.com/pharo-project/pharo/pull/863

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

[Pharo-dev] Point>>#rotateBy:about: has a bad comment

[Julien]

Hello,

Concerning this case I just opened: 
https://pharo.fogbugz.com/f/cases/21329/Point-rotateBy-about-has-a-bad-comment 


I’d like your opinion about it.

I just copy in this mail what I said on the case:

rotateBy: angle about: center 
"Even though Point.theta is measured CW, this rotates with the more 
conventional CCW interpretateion of angle."
[...]
I think this comment does not explain what this method does.

What should be something like:

This method returns the point obtained after rotating myself around #center 
point of an #angle given as parameter. The #angle provided as parameter is 
interpreted as being in radian.

Additionally, I think the name of this method is bad, maybe it should be 
renamed to something more explicit like #rotateBy:around: or 
#rotateByRadians:around:.

Maybe, if this method is renamed as #rotateByRadians:around:, the method 
#rotateByDegrees:around: should be added as well.

Cheers,

Julien

---
Julien Delplanque
Doctorant à l’Université de Lille 1
http://juliendelplanque.be/phd.html
Equipe Rmod, Inria
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40

[Pharo-dev] [Pharo 7.0-dev] Build #536: 21315 Remove unnecessary "self run:" in ChangeSetClassChangesTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #536 was: FAILURE.

The Pull Request #841 was integrated: "21315 Remove unnecessary "self run:" in 
ChangeSetClassChangesTest"
Pull request url: https://github.com/pharo-project/pharo/pull/841

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

Re: [Pharo-dev] what is

[Nicolas Cellier]

It sounds like thinking data vs thinking behavior.
Eliot teaches that pragmas should better be used as behavior.
>From what you describe, some of Pharo usage is like behaviorless metadata...

2018-02-12 9:48 GMT+01:00 Thierry Goubier :

> Hi Hernan,
>
> 2018-02-12 7:48 GMT+01:00 Hernán Morales Durand  >:
> > Hi Eliot,
> >
> > One could say that a pragma is a message without a method?
> >
> > I think pragmas were never been integrated properly into the system
> > browser. We can browses pragmas with the PragmaCollection but what I
> > mean is a pragma-aware browser. See for example, there are some
> > pragmas where is easy to infer the meaning: ,
> > , and others  where is not
> > so clear. So even if we take  is not
> > easy with the current tools to find of which parameters makes sense. I
> > always missed something like the annotation pane plugin or the quality
> > assistant plugin in Nautilus, but for pragmas.
>
> What Eliot is pointing out, is that integration is very easy to do as
> long as you implement it the way Eliot describes it: you see a pragma,
> you select it, search for implementors, and, voilà, you know what the
> pragma is for and how it is used (and you may even get a comment for
> the parameters).
>
> Now, you can try to do that in Pharo, and, of course that doesn't
> work: I can select the pragma ,
> search for implementors, and I get none. If I search for senders,
> among the few hundreds of senders I get into my pharo 6 image, and
> knowing that this should be inside the GT-Inspector-Core package, I
> find:
>
> #GTInspector class >>#extensionsPragma
>
> Now, following senders of #extensionsPragma, I find about a dozen
> senders (because there are multiple implementors of #extensionsPragma,
> probably). One of the senders is probably the key:
>
> ProtoObject>>#gtInspectorPresentationsIn:inContext:
>
> And the use of #allNamed:from:to:sortedUsing: should give you a clue
> about the argument (because, yes there is no comment about the
> argument... or even if the pragma should have one...).
>
> > This could be an excellent opportunity for Calypso to see how pragmas
> > can be exploited in the way you describe.
>
> As I said above, if used like Eliot describes, then it could be done
> just by searching implementors of the pragma symbol.
>
> Now, implemented as it is in Pharo, I suspect it will be hard to do
> even for Calypso.
>
> Regards,
>
> Thierry
>
> > Thanks for the kind explanation.
> >
> > Cheers,
> >
> > Hernán
> >
> >
> > 2018-02-12 1:09 GMT-03:00 Eliot Miranda :
> >> Hi Hernan,
> >>
> >>
> >>
> >>
> >> _,,,^..^,,,_ (phone)
> >>> On Feb 11, 2018, at 10:47 AM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
> >>>
> >>> I don't know, but how you you find documentation about specific
> pragmas?
> >>
> >> The best way is to ensure the pragma has at least one implementation,
> i.e. there is at least one method in the system that has the same signature
> as the pragma.  This implementation should document the pragma, but even
> better it should be the method that extracts information from the pragma.
> >>
> >> An example will help.  Imagine a pragma that specifies a method belongs
> on some menu.  The method containing the pragma is intended to be an action
> of the menu, do that when the menu item is selected, the method containing
> the pragma will b executed.  The pragma defines the menu the method belongs
> to, where in the method, the string to appear in the menu, the hot key for
> the menu item, etc.
> >>
> >> If the pragma is implemented by a menu builder then
> >> - yes, certainly the pragma can be documented in the m by builder's
> implementation, but also
> >> - the menu can be built by performing the pragma by the menu builder
> >>
> >> This was my intent when Steve Dahl and I invented pragmas, that there
> would always be implementations of the pragma in classes that were designed
> to extract the information from the pragma and add the method containing
> the pragma to whatever structure the pragma was intended to facilitate
> updating (menus, inspectors, exported apis, etc).  So the most powerful way
> of use my pragmas is via a visitor pattern:
> >>
> >> When a method with a particular pragma is added or removed, the class
> containing the method triggers some action.  This action collects all the
> relevant pragma methods in the class hierarchy, creates some builder
> object, and has the builder perform each method containing a relevant
> pragma.
> >>
> >> Using pragmas as arbitrary labels is fine, bug doesn't exploit the fact
> that pragmas are messages, and that hence one can do senders and
> implementors /and/ perform them.
> >>
> >> HTH
> >>
> >>>
> >>> Hernán
> >>>
> >>>
> >>> 2018-02-11 14:48 GMT-03:00 Stephane Ducasse :
>  Hi
> 
>  what is this pragma in metaclass method?
> 
>  Stef
> 
> >>>
> >>
> >
>
>

[Pharo-dev] [Pharo 7.0-dev] Build #537: 21301 Remove unnecessary "self run:" in Base64MimeConverterTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #537 was: SUCCESS.

The Pull Request #855 was integrated: "21301 Remove unnecessary "self run:" in 
Base64MimeConverterTest"
Pull request url: https://github.com/pharo-project/pharo/pull/855

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

Re: [Pharo-dev] what is

[Hernán Morales Durand]

Hi Thierry,

2018-02-12 5:48 GMT-03:00 Thierry Goubier :
> Hi Hernan,
>
> 2018-02-12 7:48 GMT+01:00 Hernán Morales Durand :
>> Hi Eliot,
>>
>> One could say that a pragma is a message without a method?
>>
>> I think pragmas were never been integrated properly into the system
>> browser. We can browses pragmas with the PragmaCollection but what I
>> mean is a pragma-aware browser. See for example, there are some
>> pragmas where is easy to infer the meaning: ,
>> , and others  where is not
>> so clear. So even if we take  is not
>> easy with the current tools to find of which parameters makes sense. I
>> always missed something like the annotation pane plugin or the quality
>> assistant plugin in Nautilus, but for pragmas.
>
> What Eliot is pointing out, is that integration is very easy to do as
> long as you implement it the way Eliot describes it: you see a pragma,
> you select it, search for implementors, and, voilà, you know what the
> pragma is for and how it is used (and you may even get a comment for
> the parameters).
>
> Now, you can try to do that in Pharo, and, of course that doesn't
> work: I can select the pragma ,
> search for implementors, and I get none. If I search for senders,
> among the few hundreds of senders I get into my pharo 6 image, and
> knowing that this should be inside the GT-Inspector-Core package, I
> find:
>
> #GTInspector class >>#extensionsPragma
>
> Now, following senders of #extensionsPragma, I find about a dozen
> senders (because there are multiple implementors of #extensionsPragma,
> probably). One of the senders is probably the key:
>
> ProtoObject>>#gtInspectorPresentationsIn:inContext:
>
> And the use of #allNamed:from:to:sortedUsing: should give you a clue
> about the argument (because, yes there is no comment about the
> argument... or even if the pragma should have one...).
>

As you noted, that's a long way to find a pragma information.
It should be a lot easier.

>> This could be an excellent opportunity for Calypso to see how pragmas
>> can be exploited in the way you describe.
>
> As I said above, if used like Eliot describes, then it could be done
> just by searching implementors of the pragma symbol.
>
> Now, implemented as it is in Pharo, I suspect it will be hard to do
> even for Calypso.
>

I see. I would love a popup after each new pragma is defined to write
some description.
The system can enforce to write documentation! ;)

Best regards,

Hernán

> Regards,
>
> Thierry
>
>> Thanks for the kind explanation.
>>
>> Cheers,
>>
>> Hernán
>>
>>
>> 2018-02-12 1:09 GMT-03:00 Eliot Miranda :
>>> Hi Hernan,
>>>
>>>
>>>
>>>
>>> _,,,^..^,,,_ (phone)
 On Feb 11, 2018, at 10:47 AM, Hernán Morales Durand 
  wrote:

 I don't know, but how you you find documentation about specific pragmas?
>>>
>>> The best way is to ensure the pragma has at least one implementation, i.e. 
>>> there is at least one method in the system that has the same signature as 
>>> the pragma.  This implementation should document the pragma, but even 
>>> better it should be the method that extracts information from the pragma.
>>>
>>> An example will help.  Imagine a pragma that specifies a method belongs on 
>>> some menu.  The method containing the pragma is intended to be an action of 
>>> the menu, do that when the menu item is selected, the method containing the 
>>> pragma will b executed.  The pragma defines the menu the method belongs to, 
>>> where in the method, the string to appear in the menu, the hot key for the 
>>> menu item, etc.
>>>
>>> If the pragma is implemented by a menu builder then
>>> - yes, certainly the pragma can be documented in the m by builder's 
>>> implementation, but also
>>> - the menu can be built by performing the pragma by the menu builder
>>>
>>> This was my intent when Steve Dahl and I invented pragmas, that there would 
>>> always be implementations of the pragma in classes that were designed to 
>>> extract the information from the pragma and add the method containing the 
>>> pragma to whatever structure the pragma was intended to facilitate updating 
>>> (menus, inspectors, exported apis, etc).  So the most powerful way of use 
>>> my pragmas is via a visitor pattern:
>>>
>>> When a method with a particular pragma is added or removed, the class 
>>> containing the method triggers some action.  This action collects all the 
>>> relevant pragma methods in the class hierarchy, creates some builder 
>>> object, and has the builder perform each method containing a relevant 
>>> pragma.
>>>
>>> Using pragmas as arbitrary labels is fine, bug doesn't exploit the fact 
>>> that pragmas are messages, and that hence one can do senders and 
>>> implementors /and/ perform them.
>>>
>>> HTH
>>>

 Hernán


 2018-02-11 14:48 GMT-03:00 Stephane Ducasse :
> Hi
>
> what is this pragma in 

[Pharo-dev] [Pharo 7.0-dev] Build #530: 21314 Remove unnecessary "self run:" in IntervalTest and IdentityBagTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #530 was: SUCCESS.

The Pull Request #842 was integrated: "21314 Remove unnecessary "self run:" in 
IntervalTest and IdentityBagTest"
Pull request url: https://github.com/pharo-project/pharo/pull/842

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

Re: [Pharo-dev] Cleaning up... baseClass, instanceSide, theNonMetaclass

[Guillermo Polito]

In my code I use to use instanceSide and classSide. don't know why. Maybe
they are clearer to me?

On Sun, Feb 11, 2018 at 8:59 PM, Denis Kudriashov 
wrote:

> 2018-02-11 18:14 GMT+01:00 Stephane Ducasse :
>
>> Hi
>>
>> We already got this discussion and I plan to address it.
>> Now I discovered that in addition to instanceSide and theNonMetaclass we
>> have
>>
>> - classClass and baseClass
>> - theMetaclass and theNonMetaclass
>> - instanceSide and classSide
>>
>> https://pharo.fogbugz.com/f/cases/20941/deprecate-theMetacla
>> ss-and-the-theNonMeta
>>
>> Even if instanceSide and classSide come from UI concerns I think that
>> there are much
>> better than the others.
>>
>
> + 100
>
>
>>
>> So have you any concerns and prefer one of the other couples? Because
>> we should stop
>> accumulate cruft in the system. We do not need three ways to do the same.
>>
>> Stef
>>
>>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] what is

[Thierry Goubier]

Hi Hernan,

2018-02-12 7:48 GMT+01:00 Hernán Morales Durand :
> Hi Eliot,
>
> One could say that a pragma is a message without a method?
>
> I think pragmas were never been integrated properly into the system
> browser. We can browses pragmas with the PragmaCollection but what I
> mean is a pragma-aware browser. See for example, there are some
> pragmas where is easy to infer the meaning: ,
> , and others  where is not
> so clear. So even if we take  is not
> easy with the current tools to find of which parameters makes sense. I
> always missed something like the annotation pane plugin or the quality
> assistant plugin in Nautilus, but for pragmas.

What Eliot is pointing out, is that integration is very easy to do as
long as you implement it the way Eliot describes it: you see a pragma,
you select it, search for implementors, and, voilà, you know what the
pragma is for and how it is used (and you may even get a comment for
the parameters).

Now, you can try to do that in Pharo, and, of course that doesn't
work: I can select the pragma ,
search for implementors, and I get none. If I search for senders,
among the few hundreds of senders I get into my pharo 6 image, and
knowing that this should be inside the GT-Inspector-Core package, I
find:

#GTInspector class >>#extensionsPragma

Now, following senders of #extensionsPragma, I find about a dozen
senders (because there are multiple implementors of #extensionsPragma,
probably). One of the senders is probably the key:

ProtoObject>>#gtInspectorPresentationsIn:inContext:

And the use of #allNamed:from:to:sortedUsing: should give you a clue
about the argument (because, yes there is no comment about the
argument... or even if the pragma should have one...).

> This could be an excellent opportunity for Calypso to see how pragmas
> can be exploited in the way you describe.

As I said above, if used like Eliot describes, then it could be done
just by searching implementors of the pragma symbol.

Now, implemented as it is in Pharo, I suspect it will be hard to do
even for Calypso.

Regards,

Thierry

> Thanks for the kind explanation.
>
> Cheers,
>
> Hernán
>
>
> 2018-02-12 1:09 GMT-03:00 Eliot Miranda :
>> Hi Hernan,
>>
>>
>>
>>
>> _,,,^..^,,,_ (phone)
>>> On Feb 11, 2018, at 10:47 AM, Hernán Morales Durand 
>>>  wrote:
>>>
>>> I don't know, but how you you find documentation about specific pragmas?
>>
>> The best way is to ensure the pragma has at least one implementation, i.e. 
>> there is at least one method in the system that has the same signature as 
>> the pragma.  This implementation should document the pragma, but even better 
>> it should be the method that extracts information from the pragma.
>>
>> An example will help.  Imagine a pragma that specifies a method belongs on 
>> some menu.  The method containing the pragma is intended to be an action of 
>> the menu, do that when the menu item is selected, the method containing the 
>> pragma will b executed.  The pragma defines the menu the method belongs to, 
>> where in the method, the string to appear in the menu, the hot key for the 
>> menu item, etc.
>>
>> If the pragma is implemented by a menu builder then
>> - yes, certainly the pragma can be documented in the m by builder's 
>> implementation, but also
>> - the menu can be built by performing the pragma by the menu builder
>>
>> This was my intent when Steve Dahl and I invented pragmas, that there would 
>> always be implementations of the pragma in classes that were designed to 
>> extract the information from the pragma and add the method containing the 
>> pragma to whatever structure the pragma was intended to facilitate updating 
>> (menus, inspectors, exported apis, etc).  So the most powerful way of use my 
>> pragmas is via a visitor pattern:
>>
>> When a method with a particular pragma is added or removed, the class 
>> containing the method triggers some action.  This action collects all the 
>> relevant pragma methods in the class hierarchy, creates some builder object, 
>> and has the builder perform each method containing a relevant pragma.
>>
>> Using pragmas as arbitrary labels is fine, bug doesn't exploit the fact that 
>> pragmas are messages, and that hence one can do senders and implementors 
>> /and/ perform them.
>>
>> HTH
>>
>>>
>>> Hernán
>>>
>>>
>>> 2018-02-11 14:48 GMT-03:00 Stephane Ducasse :
 Hi

 what is this pragma in metaclass method?

 Stef

>>>
>>
>

Re: [Pharo-dev] Iceberg experience report - synchronising README change made on github

[Guillermo Polito]

On Thu, Feb 8, 2018 at 6:28 AM, Ben Coman  wrote:

> Could the Iceberg gurus try and comment on the following workflow.
>
> Please familiarise with the first four commits here...
> https://github.com/Traadh/cloudflareun/network
>
> from these actions...
>
> "first commit" -- on github I created it as an unitialized repo to try
> to push a "new repo" to it per my other post, but when that failed
> from the command line I did `git init; git add README; git remote ...;
> git push ...`)
>
> "First Pharo code" -- cloned the repo with Iceberg, added a package,
> synchronised, added commit comment and clicked  master>
>
> "Update class comment" -- edited the class comment, then from Iceberg
> synchronised, added commit comment and clicked  master>
>
> "Updated README" -- on github, used the built-in editor to easily
> preview markdown.  Clicked its 
>
>
> PROBLEM...
>
> Now I'm at a point having trouble synchronising Iceberg to pick up
> that last change.
> 1. Right-clicked on "cloudflareun" and chose "Synchronise repository..."
> 2. In [Update] tab, clicked 
> and listed under [commits to be imported] is "Updated README". Good.
> 3. Then clicked on  which I expected would load that commit into
> the Image,
> and a new commit "Merge with ref/remotes/origin/master" showed up in
> [commit to be imported]
>
> So now I'm lost.
> It seems the  only operates on the disk?
> But why does it create a merge commit?
> It should have fast-forwarded.


> Checking from the command line, only shows the first three commits are
> common with the github network graph. The fourth commit is the new
> merge commit.
> $ git log
> commit f49c64a7751f95712acc30dab692fc7e85e0c810
> Merge: c818e9a 52ab6ac
> Author: Ben Coman 
> Date:   Thu Feb 8 11:55:34 2018 +0800
> Merge with refs/remotes/origin/master
>
> commit c818e9adebeb6be001b202aa48da009be97920eb
> Author: Ben Coman 
> Date:   Thu Feb 8 11:42:57 2018 +0800
> Update class comment.
>
> commit 6f2df89b219c56530412252ace96bc95eb78373a
> Author: Ben Coman 
> Date:   Thu Feb 8 11:37:01 2018 +0800
> First Pharo code
>
> commit 52ab6ac696760a60fe56af57e45f2e2ceaaae35e
> Author: Ben Coman 
> Date:   Thu Feb 8 11:31:28 2018 +0800
> first commit
>
> Checking the remote...
> $ git log origin/master
> commit 52ab6ac696760a60fe56af57e45f2e2ceaaae35e
> Author: Ben Coman 
> Date:   Thu Feb 8 11:31:28 2018 +0800
> first commit
>
> Whoops... not what I expected but I don't think that affected anything
> now.  Probably it was left over from early attempts to create a "new"
> "cloudflareun" repo.
>
> Try again...
> $ git remote --v
> origin g...@github.com:Traadh/cloudflareun.git (fetch)
> origin g...@github.com:Traadh/cloudflareun.git (push)
> traadh g...@github.com:Traadh/cloudflareun.git (fetch)
> traadh g...@github.com:Traadh/cloudflareun.git (push)
>
> $ git log traadh/master
> commit 587bed95c4b8fb3986c9962c9206405c81c99e3d
> Author: Ben Coman 
> Date:   Thu Feb 8 11:54:20 2018 +0800
> Updated README
>
> commit c818e9adebeb6be001b202aa48da009be97920eb
> Author: Ben Coman 
> Date:   Thu Feb 8 11:42:57 2018 +0800
> Update class comment.
>
> commit 6f2df89b219c56530412252ace96bc95eb78373a
> Author: Ben Coman 
> Date:   Thu Feb 8 11:37:01 2018 +0800
> First Pharo code
>
> commit 52ab6ac696760a60fe56af57e45f2e2ceaaae35e
> Author: Ben Coman 
> Date:   Thu Feb 8 11:31:28 2018 +0800
> first commit
>
> So there are the four commits matching github.  So it seems that
> Iceberg's FETCH did the right thing updating the remote. But the disk
> working directory should have just fast-forwarded rather than merging.
>
> Now seeing both these commits...
> * Merge with ref/remotes/origin/master
> * Updated README
> in the one [New commits to be imported] seems to be mixing results
> from the working repo and the remote repo in a way that makes it hard
> to guess the consequence of any next action here.
>
> I do see a  option when I right-click on one of those
> commits.
> Perhaps the "load" means to load from the disk working directory into
> the Image(?) but its a bit hidden compared to the  and 
> that are buttons.
> It seems dangerous to take that action right now, since I guess the
> Image would diverge from the disk working directory.
>
>
> FIXING...
>
> What I ended up doing was remove the "merge commit" from the disk
> working directory
> $ git reset --hard HEAD^
>
> then opened a new Iceberg which for [Updates] only showed only the
> single commit  "Updated README" fetched into the remote repo.  Good.
> I right-clicked on that and did  which correctly
> fast-forwarded the disk working directory...
> $ git log
> commit 587bed95c4b8fb3986c9962c9206405c81c99e3d
> Author: Ben Coman 
> Date:   Thu Feb 8 11:54:20 2018 

[Pharo-dev] [Pharo 7.0-dev] Build #538: 21302 Remove unnecessary "self run:" in DictionaryTest

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #538 was: SUCCESS.

The Pull Request #854 was integrated: "21302 Remove unnecessary "self run:" in 
DictionaryTest"
Pull request url: https://github.com/pharo-project/pharo/pull/854

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