Contributing to Pharo

> On 16 Jan 2016, at 02:42, Ben Coman <[hidden email]> wrote:
>
> So if occasionally if everything seems against you, after trying a
> fresh Image as you already did,  slide back to the last build that
> worked for you (I don't think the issues you experience are Spur
> related, but 50496 might be a good fallback as Pre-Spur and
> Pre-GTDebugger).  Then create a fresh Image from the latest build to
> test your Slice and in that time maybe the other issues have gone.

Ok. So my earlier question (in Slack, I think) about how "unstable" is unstable in Pharo is now answered. It's really unstable, not "Debian-like unstable".

It would also be nice to add some public info about that. I'll create an issue.

At the moment, I am stuck with GTDebugger, because it seems the old debugger does not have any keyboard shortcut form stepping through code. And that's something I would really really miss. So I'll suffer the pain of all the other glitches, and see how that goes.

Le 16/1/16 00:15, Henrik Sperre Johansen a écrit :
> Or, try a stable release.
> Whenever I try developing on the latest version, I end up getting
> disrupted by bugs in the core tools 70-80% of the time.
> For released versions, in 1.4 it was maybe 5%, in 2.0 40%, in 3.0 20%,
> in 4.0 10%
> So at least it's been trending downwards, though I expect a totally
> new debugger, image format, RBParser unification and new FFI in 5.0
> will keep causing problems for a quite a while.
>

Yes the point is really to understand that we changed a lot of things
because they had to.
So this is important to put bugs in perspective to changes.

Now we should improve the test coverage too
Stef

Hi david
>> On 16 Jan 2016, at 02:42, Ben Coman <[hidden email]> wrote:
>>
>> So if occasionally if everything seems against you, after trying a
>> fresh Image as you already did,  slide back to the last build that
>> worked for you (I don't think the issues you experience are Spur
>> related, but 50496 might be a good fallback as Pre-Spur and
>> Pre-GTDebugger).  Then create a fresh Image from the latest build to
>> test your Slice and in that time maybe the other issues have gone.
> Ok. So my earlier question (in Slack, I think) about how "unstable" is unstable in Pharo is now answered. It's really unstable, not "Debian-like unstable".

No this is not really the case. In general we try hard to get alpha
stable after you get some hiccups.
This is not every day that we change FFI, GC, object internal
representations and the text editors, syntax highli
And our problems is that sometimes often we just jump over glitches
(this is why I'm getting mad because when I do videos
or other I see them in my face). Now I would love to have task forces
that check glitches.
>
> It would also be nice to add some public info about that. I'll create an issue.
>
> At the moment, I am stuck with GTDebugger, because it seems the old debugger does not have any keyboard shortcut form stepping through code. And that's something I would really really miss. So I'll suffer the pain of all the other glitches, and see how that goes.
>

On 16 Jan 2016, at 02:15, Ben Coman <[hidden email]> wrote:

On Sat, Jan 16, 2016 at 3:45 AM, David Allouche <[hidden email]> wrote:

1. it shows a bunch of packages I have not touched
2. it does not show the package that contains my fix (Spec-Tools)

I am curious on item 2.  Was this just because the dirty package was sorted to the top of the list (per Nicolai's snapshots)?

I think that was indeed the source of confusion.

But, really, this "list of dirty packages" should really only list dirty packages. What is the use case for selecting a non-dirty package?

because you never know
Sometimes you save a package then you do a slice and you should be able to decide.

I looked in the world menu, and I found this menu item called "Komitter". That sounded like a good candidate.

I see how the term "Commit" is misleading here without context.  Probably "Press the <Save> button to commit your slice to the inbox repository"   would probably be better.

Yes, that would help, too.

https://pharo.fogbugz.com/default.asp?17398

Cool!

I get the picture now. I just checked in when the lobby, the roof and the plumbing of the hotel were undergoing renovations: it's not how it is usually.

I could question whether it's a good idea to cram so much in a single release cycle. But release management is a difficult topic, and often there is no good solution, just one that has less downsides than the others.

Cheers.

> On 16 Jan 2016, at 12:14, stepharo <[hidden email]> wrote:
>
> Le 16/1/16 09:59, David Allouche a écrit :
>>
>> But, really, this "list of dirty packages" should really only list dirty packages. What is the use case for selecting a non-dirty package?
>
> because you never know
> Sometimes you save a package then you do a slice and you should be able to decide.

That does not make sense to me. I guess it will, when I understand Monticello better.

On Sat, Jan 16, 2016 at 7:25 PM, David Allouche <[hidden email]> wrote:
Its a very corner case.  I've had to do it on occasion but I can't
exactly remember the circumstance.  Now what might be useful is a
checkbox for displaying non-dirty packages - so we only display the
short list in the usual case. (??)

cheers -ben

On 16-01-16 12:25, David Allouche wrote:
> That does not make sense to me. I guess it will, when I understand Monticello better.

Ideally, you start with the fresh, latest clean Pharo image to start
working on an issue and make the changes in one go to create a slice.
Then you only have to select the dirty packages.

If the changes you are making risk killing the image, or there are
simply a lot of them, you might commit intermediate steps where you
detail your thought process/assumptions. The slice for the issue then
can consist of packages that are already committed.

Stephan

+100 it is very confusing right now

> cheers -ben
>

>> No this is not really the case. In general we try hard to get alpha stable after you get some hiccups.
>> This is not every day that we change FFI, GC, object internal representations and the text editors, syntax highli
>> And our problems is that sometimes often we just jump over glitches (this is why I'm getting mad because when I do videos
>> or other I see them in my face). Now I would love to have task forces that check glitches.
> I get the picture now. I just checked in when the lobby, the roof and the plumbing of the hotel were undergoing renovations: it's not how it is usually.
>
> I could question whether it's a good idea to cram so much in a single release cycle. But release management is a difficult topic, and often there is no good solution, just one that has less downsides than the others.

We do not control all the agendas. We were hesitating to get Pharo 50
without spur and for some people
it would have been sad. Then it would have meant 2 months in beta and
slow mode.
And Esteban worked a lot on the new FFI because it was needed: you do
not change an object header internal representation
without impact and since the previous FFI was generating assembly on the
fly and few people knew its implementation
and Igor got a depression we got stuck.
Then this is important to get the new FFI out because Ronie is coming to
visit us and he should work with Clement and esteban
on a faster version.
This is as simple as that. It means that all the libraries using FFI
would not have been available with Spur = no use for certain people like
roassal, moose, synectique.

Stef

Ben Coman wrote

checkbox for displaying non-dirty packages - so we only display the
short list in the usual case. (??)

Ah! That would be very helpful. Particularly annoying is when you commit one of your project's dirty packages, the list auto-scrolls to the package's new location among the non-dirty packages, and you have to manually scroll back to the top of the package list to find your next dirty package.

I've been wondering no-one in the Pharo community has started building a "Project Browser" to replace the "Package Browser" .... I've had a "project browser" in tODE for several years now and you work with a manageble list of Metacello projects like the following:

Ben Coman wrote

checkbox for displaying non-dirty packages - so we only display the
short list in the usual case. (??)

Ah! That would be very helpful. Particularly annoying is when you commit one
of your project's dirty packages, the list auto-scrolls to the package's new
location among the non-dirty packages, and you have to manually scroll back
to the top of the package list to find your next dirty package.



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Contributing-to-Pharo-tp4871604p4873422.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Hi Dale,

Le 27 janv. 2016 à 04:11, Dale Henrichs a écrit :

> I've been wondering no-one in the Pharo community has started building a "Project Browser" to replace the "Package Browser" .... I've had a "project browser" in tODE for several years now and you work with a manageble list of Metacello projects like the following:

Of course, we have that in mind. We would love to have it but lack of time / manpower ...
We are not happy with the current browser (Nautilus). We could have something really more powerful. It will come but we have other projects to achieve before ;)
If someone comes with a better browser, we would love to set it as default.

Cheers,
Christophe

Haha, I certainly understand the lack of time/manpower ... Just in case it wasn't clear, when I said "project browser" I wasn't talking about replacing the code browser (Nautilus), but replacing/augmenting the Monticello Browser - which should turn out to be a much simpler undertaking ---  "Project Browser" that manages the projects within the image - load, save, changes, etc.:

Hi Dale,

Le 27 janv. 2016 à 04:11, Dale Henrichs a écrit :

I've been wondering no-one in the Pharo community has started building a "Project Browser" to replace the "Package Browser" .... I've had a "project browser" in tODE for several years now and you work with a manageble list of Metacello projects like the following:

Of course, we have that in mind. We would love to have it but lack of time / manpower ...
We are not happy with the current browser (Nautilus). We could have something really more powerful. It will come but we have other projects to achieve before ;)
If someone comes with a better browser, we would love to set it as default.

Cheers,
Christophe

Dale,

That looks like something very interesting and worth considering.

How easy is it to load tODE in a current (4.x 5.x) Pharo image ? I assume there is a Metacello configuration ;-) Is it possible to experiment with it in Pharo, independent from Gemstone ? I did not see it in the Catalog Browser (our current point & click installer).

Making tODE easily loadable would, IMHO, be the first step to a broader adaption of your work (in one form or another). The next step would be a getting started tutorial.

Sven

On 1/27/16 12:03 AM, Thierry Goubier wrote:
> Hi Dale,
>
> then a question: how does one query a baselineOf or a configOf to
> retrieve the current project state (i.e. packages) loaded in the image?
>
> Thierry
>
Thierry,

Good question:)

To start with in tODE I have a class
TDMetacelloProjectRegistrationDefinition which is part of the following
hierarchy:

Object
  TDDefinition
   TDPackageBasedDefinition
    TDAbstractProjectRegistrationDefinition
     TDGitProjectRegistrationDefinition
     TDMetacelloProjectRegistrationDefinition
      TDMetacelloRegistrationDefinition
       TDMetacelloBaselineRegistrationDefinition
       TDMetacelloConfigurationRegistrationDefinition
       TDMetacelloHybridRegistrationDefinition
      TDMetacelloUnloadedProjectRegistrationDefinition

The method TDMetacelloProjectRegistrationDefinition>>workingCopies[1]
calculates the list of MCWorkingCopy instances for the loaded packages
associated with a project (including the configurationof or
baselineof... or both).

The key Metacello methods called include:

   MetacelloProjectRegistration>>projectVersion[2]
   MetacelloMCVersion>>packages[3]
   MetacelloPackageSpec>>workingCopy[4]
   MetacelloMCProjectSpec>>projectPackage[5]

This is really the key information for doing all of the other operations
for a "Project Browser" like "save all dirty packages and commit" and
"give me diffs for all dirty packages in project"...

Dale

[1]
https://github.com/dalehenrich/tode/blob/master/repository/Topez-Server-Core.package/TDMetacelloProjectRegistrationDefinition.class/instance/workingCopies.st
[2]
https://github.com/dalehenrich/metacello-work/blob/master/repository/Metacello-Core.package/MetacelloProjectRegistration.class/instance/projectVersion.st
[3]
https://github.com/dalehenrich/metacello-work/blob/master/repository/Metacello-MC.package/MetacelloMCVersion.class/instance/packages.st
[4]
https://github.com/dalehenrich/metacello-work/blob/master/repository/Metacello-MC.package/MetacelloPackageSpec.class/instance/workingCopy.st
[5]
https://github.com/dalehenrich/metacello-work/blob/master/repository/Metacello-MC.package/MetacelloMCProjectSpec.class/instance/projectPackage.st

On 1/27/16 6:24 AM, Sven Van Caekenberghe wrote:
> Dale,
>
> That looks like something very interesting and worth considering.
Thanks for the interest Sven!
>
> How easy is it to load tODE in a current (4.x 5.x) Pharo image ? I assume there is a Metacello configuration ;-) Is it possible to experiment with it in Pharo, independent from Gemstone ? I did not see it in the Catalog Browser (our current point & click installer).
As it stands right now, tODE is not loadable/functional in Pharo ... In
my earlier tODE work, I implemented it in both Pharo and GemStone, but
this current version of tODE started out life as a remote development
environment for GemStone with emphasis on the remote aspect --- so a
significant chunk of tODE is devoted to managing windows running in a
Pharo image while executing all of the functionality in GemStone ...

With that said, I have architected tODE to isolate the basic tool
functionality from the GUI/command line and the model has evolved to the
point where all tools (both GUI and CommandLine --- yes there are
bash-like command mappings for all GUI functionality) share the same
basic algorithms behind a smalltalk api --- so developers can easily tap
into the functionality behind every GUI window/tODE shell command.

If you want to experiment today, you'll have to do that in GemStone with
GsDevKit_home[1]

[1] https://github.com/GsDevKit/GsDevKit_home
>
> Making tODE easily loadable would, IMHO, be the first step to a broader adaption of your work (in one form or another). The next step would be a getting started tutorial.
>

Haha, I am bandwidth limited myself and as tODE and GsDevKit_home are
still works in progress (quite functional, but still evolving:) I do not
have the cycles to worry about getting tODE to work in Pharo.... I've
got my hands full with tODE and GemStone ...

Sooo at the end of the day, I would be willing to work with folks in
porting the interesting bits of tODE to Pharo, but "interesting bits" is
in the eye of the beholder and in this case I am not the beholder ...

I think it's more important to share some of the structural (on disk)
and architectural (in-image) lessons that I've learned about working
with tODE, git and Metacello ...

For example a "Project Browser" is a critical tool that needs to exist
... I've started sharing some of the implementation details with Thierry
already ... I would recommend that the "project browser" be implemented
in a set of classes totally independent of the GUI --- let the menu
items and functionality expressed in the "Project Browser" drive a
smalltalk api that can be called from a variety endpoints beyond the
initial "project browser" implementation (take the approach that
developers will want to incorporate all of the functionality in the
"project browser" in their own GT tool) so every menu item and every
meaningful click should call this "smalltalk api) and very little
"business logic" should be present in the GUI itself ...

The details of the functionality of the tool will depend upon the set of
work flows that will be supported and on this point I do have 4 years of
experience to bring to bear on this matter, but I want to share
information and opinions rather than dictate functionality: that is the
job of the tool builder:)

Since there seems to be interest, I intend to write a series of posts
describing the disk architecture and workflows used in GsDevKit_home for
incorporating git (or any other disk-based SCM) into smalltalk dev
environments ...

Dale

Thierry,

I should mention that to get a registration for a project in the first
place, you call:

   MetacelloProjectRegistration
class>>registrationForClassNamed:ifAbsent:[1]

... and yes you pass in the full class name for the ConfigurationOf or
BaselineOf ...

Dale

[1]
https://github.com/dalehenrich/metacello-work/blob/master/repository/Metacello-Core.package/MetacelloProjectRegistration.class/class/registrationForClassNamed.ifAbsent..st

On 1/27/16 6:41 AM, Dale Henrichs wrote: