Norbert,


On 10/22/16 3:56 AM, Norbert Hartl wrote:
Dale,

Am 21.10.2016 um 22:15 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:



On 10/21/2016 07:30 AM, Norbert Hartl wrote:
Dale,

Am 21.10.2016 um 16:12 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:

Norbert,

I didn't realize that you were claiming that the new text model for Sparta was (potentially) inferior.

The other day you were expressing sadness about having to use the newer version of Metacello (which is *only* 3 years old), so I assumed that you were just being generally cranky about change:).

it might be true it is a current topic for me. In my struggle to establish a solid devlopment process I have sometimes the feeling it is impossible. Especially when the new metacello thingie improves something I don't know but at the same time I loose Versionner and the commandline handlers which I know :)��
The current (!) complaint is rather based on the fact that everything regarding the graphics backend, widget and tools appears sometimes as an indefinite loop of reinventing stuff and improving and never get the job done. Did I mention 64bit, UFFI,��� I'm glad all these topics are worked one and I see a bright future if half of them are done. But then sometimes it looks rather dark and the light at the end of the tunnel just went off :)

<dark mode off/>

Okay, so you _are_ being generally cranky:)

Seems to be the case ;) Please, don't take it personal. I like others here are trying to propose pharo to other people and doing software projects with it. I can see the need for change and I'm able to adjust. If I complain publicly (and I keep myself from doing that for some time) it is just a sign that I'm not able to deal with all of this. It might be just me having that problem. If not it means that it might be a general problem and that's something to think about.
I do not take it personally ... and I agree with you completely, there is great value in "well-tempered crankiness"

FWIW, I took great pains to ensure the the old way of using Metacello continued to work the old (buggy) way while introducing the new (non-buggy) way and that you should be happy to only start feeling the pain of this new feature 3 years after it was introduced:)

I don't care which way it is. I took the freedom to take metacello as granted and didn't see the need to adjust my way of doing until now. It is quite handy to have a few parts in your workflow that are not moving. And I didn't know until now that there is an old and a new way. If Cyril is right and the commandline handler is using the "new way" then my complaint is as wrong as annoying. But that would be the perfect case that it changed without infecting me.��
Well, it is just the case that using the pharo commandline handler does not work while eval plus the new way works. So if I didn't do something wrong we should remove the handler for configurations. And as I said I was so happy having Versionner and now it is more or less useless. Well, I think others might do it the same way by managing their dependencies with Versionner and then copy the baseline method into the baseline class. Awkward, annoying and the best I can imagine.
Yes, Metacello tools have been a great sticking point ... I decided early on that I could not afford to get involved in creating and maintaining GUI tools (for three platforms) not only because I don't have the time, but because creating GUI tools is one of those thankless jobs:) Not to mention that it is incredibly difficult to put together a comprehensive and complete GUI tool.

I think that the original reason that Versionner did not handle BaselineOf is that support for BaselineOf was missing from the MetacelloToolBox ... I have since added BaselineOf support to MetacelloToolBox, but of course the developer of Versionner is most likely busy with something else ...

With the MetacelloToolBox support for BaselineOf an enterprising individual should be able to add BaselineOf support to Versionner:)

I should also note that I have no plans to remove the old way of doing things, even though I don't recommend that anyone use the old way anymore ... At GemStone we have users running on 20 year old versions of our product, so I have an appreciation for "legacy users."

I'm sorry if you meant my complaint includes you. No, there are a few people that I would need to exclude from my complaint explicitly. But that is not possible without punching everyone else in the face :) I like the way you handle things. And I know you enjoy getting annoying questions from people like me.
As I said, I appreciate "well-tempered crankiness" as it keeps me honest:) But crankiness begets crankiness and I apologize for going over the top in my response as well:)

If you are using filetree based projects then the only way to access them is the new way...

Yes, but you know ��� things are moving and the "new way" is so "first half of 2016" because now we have iceberg which makes the situation potentially better but actually more complicated (you see ;) ). Loading projects do not anymore depend on a tool like metacello that loads but also on the kind of repository is created for all the projects inside of metacello. I'm nagging Nico to establish a workflow where I can checkout a git repo, load my project using metacello and then can use iceberg to management my development.
Yeah, I really think that when working with git repos that the tools need to de-emphasize packages and instead focus on the fact that there is a one-to-one correspondence between a github project and a Metacello project. In the following screen shot from tODE, each line represents a Metacello project and I can save, diff and load without ever looking at a package:

tODE project list screen shot

As I mentioned in another email this morning I will be talking about this approach in more detail in my talk with the working title "Dangerous Liaisons: Smalltalk, Files, and Git" ...

But that is a problem we need to tackle anyway. In my metacello baseline I have��

spec repository: 'filetree://repository/'.

to load my code from a sub-directory of that git working copy. That's ok but if I like to develop on that project I would need gitfiletree or iceberg to do that in image. So while for loading the project the filetree scheme based url is ok for doing actually work it is not. And I'm not sure where is the right place to put it. I could also imaging that I can instruct metacello to create the right kind of repository.
��
I think that you need to look into Metacello locks[1]. You use a lock, to associate a Metacello project with a repository that may be different that that specified in a baselineof.

This feature was specifically invented to make it possible to create a BaselineOf that references the official download location like: `gitfiletree://github.com/dalehenrich/metacello-work:master/repository` but then in my working image, lock the project to point at the filetree directory on my local disk ...

If you've seen my comments about TDProjectSpecEntryDefinition and MetacelloProjectLoadSpecs there is a `locked` field[2] that is meant to allow you to specify that the repository location in the TDProjectSpecEntryDefinition should be locked.

At this point it is also important to note that you can lock unloaded projects ...

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandReference.md#lock-command-reference
[2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Metacello.ston#L10

Regarding the "command-line", did you know that once you've loaded a project using the new way, that you can re-load a project using the following shorter smalltalk script:

�� Metacello image baseline: 'AAA'; load

That's good and will try that.

I made a sweep through the docs a couple of years ago, but since no one seemed to be interested in using the new API I found other things to do ... and now that there's more interest in the "new way" I simply don't have the time (right now) to make another pass through the docs ... so you can be cranky about that too :)

Come on! Now you sound a bit cranky :P


haha ... "well-tempered crankiness" my friend, "well-tempered crankiness"

Dale