Re: [Pharo-dev] PharoLauncher : Image version determination error

[nacho]

I have the same problem.
Just erased everything and downloaded a new pharo-launcher and the problem
is still there
I'm using PharoLauncher 1.3-2018.06.21 (21.0)
All the images are useless.



-
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Extension methods in p7

[Denis Kudriashov]

Yes, the problem related to some changes.

In latest image I have two packages: Gofer-Core and Gofer-core-accessing.
So all such extensions force separate packages.

2018-08-21 10:10 GMT+01:00 Torsten Bergmann :

> Hi Norbert,
>
> maybe it is unrelated - but I saw strange behavior with extensions and
> upper/lowercase
> leading to Iceberg showing "Uncomitted changes in latest image" as I wrote
> in
> http://lists.pharo.org/pipermail/pharo-dev_lists.
> pharo.org/2018-August/272816.html
>
> My scenario:
> I use my https://github.com/astares/pharo-contributor project to
> automatically get the most recent
> pharo image (Pharo-7.0+alpha.build.1185) and synch my github fork with the
> development branch
> of pharo-project as shown in the video of this project.
>
> When Iceberg synchs it should usually SHOW A CLEAN IMAGE WITHOUT CHANGES
> DONE but since a week or
> so (maybe after the latest Iceberg integration) I see that there are
> uncommitted changes (see screenshot)
> although it is a fresh image.
>
> But my forks development branch is definitely in synch with the
> pharo-project development branch
> and the latest image (as it was green in CI) should be in synch with the
> sources as well.
>
> If I look more detailed on what Iceberg display as "changed" or
> "uncommitted" then one will notice
> that these are all extensions methods look different in the browser.
>
> For instance #goferPriority is an extension on package "Gofer-Core" but
> the extension is displayed
> in Calypso as "Gofer-core-accessing" with lowercase in the name.
>
> Maybe there was a change related to package detection ...
>
> Dont know if it is a known problem but for Iceberg I found something here
> from Pablo:
> (https://github.com/pharo-vcs/iceberg/pull/981)
>
> Bye
> T.
>
>
> > Gesendet: Dienstag, 21. August 2018 um 09:31 Uhr
> > Von: "Norbert Hartl" 
> > An: "Pharo Dev" 
> > Betreff: [Pharo-dev] Extension methods in p7
> >
> > I’m about preparing magritte to be loadable in pharo 7. I encountered a
> bit strange behaviour where I had to take cumbersome measures. Magritte has
> method extensions that are called e.g.
> >
> > *Magritte-model-builder
> >
> > These methods get loaded but when I commit something all of these
> methods are to be removed. The only thing I could do was to rename the
> extension methods. Is this intended?
> > Doing the renaming I encountered of few things. Magritte had the
> extension method above in the Magritte-Model package. When I rename the
> category *Magritte-model-builder to *Magritte-Model the method gets
> removed. Not a very usual case but still strange.
> > In order to create a method extension one needs first to create a new
> protocol before converting to extension method. If the new protocol is
> empty and you convert it to an extension method it gets removed. So I had
> to first create a protocol, move a method in and then convert. This
> combined with the behaviour that if you select two methods the method pane
> jumps to the beginning of the list is a lot of work just to do this job.
> Still it is not a very usual case but some might be interested.
> >
> > Norbert
> >
> >
> >
>

Re: [Pharo-dev] Reducing the cost of documentation

[Alistair Grant]

Hi Torsten,

Thanks for your feedback.


On Mon, Aug 20, 2018 at 09:29:35AM +0200, Torsten Bergmann wrote:
> Hi Alistair,
> 
> I don't think the contribution process hold people back from writing 
> documentation since providing a contribution is easy to do now (see [1] and 
> [2]).
>
> And (even when more cumbersome) I like the review process - as it helped
> several times in the past to discuss contributions or even fixing them or 
> find trivial typos.
>
> I guess the primary problem is lazyness: people dont like to write 
> documentation as it is always additional effort. Remember that often people 
> do not even write a simple comment on a class to inform about the purpose 
> it was created...
>
> I personally doubt that we increase the number and quality of the provided 
> in-image docu with the proposal. 

I agree that code reviews are good - my code is much better for all 
the feedback I get from various members of this community (I'm not going 
to name names since I'm bound to leave someone out).

And I agree that "laziness" plays a significant role - programmers are 
renowned for not wanting to write documentation / comments.

However I think wikis are a good example demonstrating that 
documentation can be generated under the right conditions.

Admitedly there's more required than making it easy to submit a change - 
having formatted class comments would also encourage people to maintain 
the documentation.  From memory there are plans to support Pillar in 
class comments, and the work the Feenk are doing will no doubt improve 
things.  So hopefully formatting will not be an issue soon(ish).

So I still think that reducing the cost of submitting documentation 
changes would be worthwhile.

But, given the lack of other replies, it looks like I'm in the minority, 
so I'll keep quiet (for now :-)).


Thanks again,
Alistair


> Bye 
> T.
> 
> [1] https://github.com/pharo-project/pharo/blob/development/CONTRIBUTING.md
> [2] https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo
> 
> 
> 
> > Gesendet: Montag, 20. August 2018 um 08:37 Uhr
> > Von: "Alistair Grant" 
> > An: "Pharo Development List" 
> > Betreff: [Pharo-dev] Reducing the cost of documentation
> >
> > Hi Everyone,
> > 
> > The topic of documentation recently came up again on the squeak list and
> > it made me wonder about some of the blocks that currently prevent more
> > contributions to in-image documentation.
> > 
> > One of the things holding back the in-image documentation is that the
> > cost of contributing is too high: apart from actually making the change
> > we currently have to (maybe) open an issue, create a branch, commit and
> > open a PR.  Someone with commit privileges then has to review the PR
> > enough and decide to merge it.  We then need to manually delete the
> > branch some time later.
> > 
> > This is one of the reasons that wikis have been successful, they lower
> > the cost of making changes.
> > 
> > We could extend iceberg to automatically submit PRs for documentation
> > only commits (it could be a separate option, so that the doco only
> > requirement is enforced), and set up github to auto-accept the PR.
> > Modifying in-image documentation would then become a few extra clicks,
> > significantly lowering the cost.
> > 
> > I'm not familiar with Jenkins, or any other CI system, but hunting
> > around google it looks like it may be possible to directly implement
> > this, if not there are services such as https://mergify.io/ which
> > advertise being able to do this by using flags in the CI to determine
> > whether the PR should be merged (disclaimer, I've never looked at
> > mergify.io, just found it while thinking about this).
> > 
> > Thoughts?
> > 
> > 
> > Cheers,
> > Alistair
> > 
> > 
> 

[Pharo-dev] [Pharo 7.0-dev] Build #1190: 22352 Better tagging in ReflectionMirrors-Primitives and related tests

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1190 was: SUCCESS.

The Pull Request #1708 was integrated: "22352 Better tagging in 
ReflectionMirrors-Primitives and related tests"
Pull request url: https://github.com/pharo-project/pharo/pull/1708

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

[Pharo-dev] [Pharo 7.0-dev] Build #1189: 22293-Sendersimplementors-searching-can-cause-DNU-in-Rubric

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1189 was: SUCCESS.

The Pull Request #1668 was integrated: 
"22293-Sendersimplementors-searching-can-cause-DNU-in-Rubric"
Pull request url: https://github.com/pharo-project/pharo/pull/1668

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

[Pharo-dev] [update 6.0] #60543

[Marcus Denker]

60543
-

22346 #mustBeBooleanDeOptimizeIn: needs to clean semantic annotation before 
recompile
https://pharo.fogbugz.com/f/cases/22346

22356 CompiledMethod: #methodNode should reuse #parseTree
https://pharo.fogbugz.com/f/cases/22356

[Pharo-dev] [Pharo 7.0-dev] Build #1188: 22324-Wrong-implementation-of-stop-in-RBMethodNode

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1188 was: FAILURE.

The Pull Request #1713 was integrated: 
"22324-Wrong-implementation-of-stop-in-RBMethodNode"
Pull request url: https://github.com/pharo-project/pharo/pull/1713

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

[Pharo-dev] Submit your Project to the ESUG Awards

[N. Bouraqadi]

Hi everyone!

This is a reminder to submit your projects to the ESUG Innovation Technology 
Awards. It will be held on september the 10th as part of the ESUG conference in 
Sardinia (https://esug.github.io/2018-Conference/conf2018.html).

Any Pharo Smalltalk-related project is eligible.
All you need to do is provide me with few info and give a short demo during the 
awards session.

I hope to hear from you soon,
Noury

Re: [Pharo-dev] Extension methods in p7

[Norbert Hartl]

Denis,

I have the same in voyage, too. Marcus gave a possible reference for this

https://github.com/pharo-project/pharo/pull/1685/files 


Norbert

> Am 21.08.2018 um 10:05 schrieb Denis Kudriashov :
> 
> Hi Norbert.
> 
> In Calypso there are no protocols for extensions. You should simply call 
> command Move methods to package either from menu or drag and drop to package 
> (where you see it).
> 
> I don't know what the reason for commit and removal. I will check.
> 
> вт, 21 авг. 2018 г., 8:32 Norbert Hartl  >:
> I’m about preparing magritte to be loadable in pharo 7. I encountered a bit 
> strange behaviour where I had to take cumbersome measures. Magritte has 
> method extensions that are called e.g.
> 
> *Magritte-model-builder
> 
> These methods get loaded but when I commit something all of these methods are 
> to be removed. The only thing I could do was to rename the extension methods. 
> Is this intended? 
> Doing the renaming I encountered of few things. Magritte had the extension 
> method above in the Magritte-Model package. When I rename the category 
> *Magritte-model-builder to *Magritte-Model the method gets removed. Not a 
> very usual case but still strange.
> In order to create a method extension one needs first to create a new 
> protocol before converting to extension method. If the new protocol is empty 
> and you convert it to an extension method it gets removed. So I had to first 
> create a protocol, move a method in and then convert. This combined with the 
> behaviour that if you select two methods the method pane jumps to the 
> beginning of the list is a lot of work just to do this job. Still it is not a 
> very usual case but some might be interested.
> 
> Norbert
> 
> 

[Pharo-dev] [Pharo 7.0-dev] Build #1187: 22355-TestRunner-got-broken-because-baseClass-is-not-baseClass

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1187 was: SUCCESS.

The Pull Request #1710 was integrated: 
"22355-TestRunner-got-broken-because-baseClass-is-not-baseClass"
Pull request url: https://github.com/pharo-project/pharo/pull/1710

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

[Pharo-dev] [Pharo 7.0-dev] Build #1186: 22340-Cleanup-String-new-comment

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #1186 was: FAILURE.

The Pull Request #1712 was integrated: "22340-Cleanup-String-new-comment"
Pull request url: https://github.com/pharo-project/pharo/pull/1712

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

Re: [Pharo-dev] Extension methods in p7

[Denis Kudriashov]

Hi Norbert.

In Calypso there are no protocols for extensions. You should simply call
command Move methods to package either from menu or drag and drop to
package (where you see it).

I don't know what the reason for commit and removal. I will check.

вт, 21 авг. 2018 г., 8:32 Norbert Hartl :

> I’m about preparing magritte to be loadable in pharo 7. I encountered a
> bit strange behaviour where I had to take cumbersome measures. Magritte has
> method extensions that are called e.g.
>
> *Magritte-model-builder
>
> These methods get loaded but when I commit something all of these methods
> are to be removed. The only thing I could do was to rename the extension
> methods. Is this intended?
> Doing the renaming I encountered of few things. Magritte had the extension
> method above in the Magritte-Model package. When I rename the category
> *Magritte-model-builder to *Magritte-Model the method gets removed. Not a
> very usual case but still strange.
> In order to create a method extension one needs first to create a new
> protocol before converting to extension method. If the new protocol is
> empty and you convert it to an extension method it gets removed. So I had
> to first create a protocol, move a method in and then convert. This
> combined with the behaviour that if you select two methods the method pane
> jumps to the beginning of the list is a lot of work just to do this job.
> Still it is not a very usual case but some might be interested.
>
> Norbert
>
>
>

[Pharo-dev] Extension methods in p7

[Norbert Hartl]

I’m about preparing magritte to be loadable in pharo 7. I encountered a bit 
strange behaviour where I had to take cumbersome measures. Magritte has method 
extensions that are called e.g.

*Magritte-model-builder

These methods get loaded but when I commit something all of these methods are 
to be removed. The only thing I could do was to rename the extension methods. 
Is this intended? 
Doing the renaming I encountered of few things. Magritte had the extension 
method above in the Magritte-Model package. When I rename the category 
*Magritte-model-builder to *Magritte-Model the method gets removed. Not a very 
usual case but still strange.
In order to create a method extension one needs first to create a new protocol 
before converting to extension method. If the new protocol is empty and you 
convert it to an extension method it gets removed. So I had to first create a 
protocol, move a method in and then convert. This combined with the behaviour 
that if you select two methods the method pane jumps to the beginning of the 
list is a lot of work just to do this job. Still it is not a very usual case 
but some might be interested.

Norbert