Dale,

> Am 21.10.2016 um 22:15 schrieb Dale Henrichs 
> <dale.henri...@gemtalksystems.com>:
> 
> 
> 
> On 10/21/2016 07:30 AM, Norbert Hartl wrote:
>> Dale,
>> 
>>> Am 21.10.2016 um 16:12 schrieb Dale Henrichs 
>>> <dale.henri...@gemtalksystems.com 
>>> <mailto:dale.henri...@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.
> 
> 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.

> 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.

> 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.

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.
  

> 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

Norbert

Reply via email to