Installing MockGemstone into Pharo

> OK, I'm thoroughly frustrated.... how *do* I load MockGemStone? I've tried
> just about every incantation of Gofer I can think of (and Gofer project) but
> nothing can find it.
> --chris
>
> On Wed, Oct 6, 2010 at 3:34 AM, Norbert Hartl <[hidden email]> wrote:
>>
>> On 06.10.2010, at 07:18, Friedrich Dominicus wrote:
>>
>> > Dale Henrichs <[hidden email]> writes:
>> >> You _could_ use the same Pharo image for developing in Pharo and
>> >> GemStone, but for me it is too easy to forget where I'm making changes
>> >> (the code is the same and browsers look similar)..So I prefer to have
>> >> separate pharo vms: 1 for Pharo-based development and 1 for
>> >> GemTools-based defelopment.
>> > Let me be a bit more penetrant. As I understand the suggestion is "NOT"
>> > using the GemStone Tools (intergrated) into Pharo. But just writing the
>> > code "happy" away in the Pharo image. If you feel kind of comfortable
>> > you migrate than?
>> >
>> What you describe you have to do anyway. You write code anywhere than you
>> need to create a monticello package and pull that back in into gemstone. I
>> think Dales point was about how you work with images. You can have one image
>> for your application and one for gemtools. Or you can have an image where
>> the application and gemtools is installed. I think that is what Dale means
>> with "you _could_ use the same". The latter approach can be confusing.
>> Shortcuts do work in gemtools and in pharo. So while pressing cmd-B to get a
>> browser it really depends which context you are working in. So you will
>> often get e.g. a pharo system browser when your intension was to get one of
>> gemstone.  All those things can go wrong.
>> I used the latter approach but I changed that. There are several good
>> reasons for me to have it changed:
>>
>> - it is indeed confusing if you are working with two different code bases
>> in the same image. And sometimes I changed accidentially code in gemstone
>> which I like to see as my production server and every change should come
>> with monticello not by hand.
>> - I have several projects that are deployed in gemstone. No need to put
>> the gemtools in every project image I have.
>> - if you like to be up to date to the pharo enhancements than the gemtools
>> may prevent that. Until a few weeks ago you could only use pharo 1.0 for
>> gemtools. Even in newer versions the tools that have been ported to gemstone
>> are somewhat behind. So to divide project and gemtools image solves this
>> problem
>>
>> > I understand what you mean with the "Gemstone" image and the Pharo
>> > image. But the suggestion is doing development in Pharo FIRST?
>> >
>> Yep. I think it is not a good idea to work in both directions
>> (pharo->gemstone and gemstone->pharo). In the beginning this might be the
>> case until you are aware of cross platform problems. But to have a stable
>> process is good to have. And that could be (it is nearly the same that
>> Stephan writes):
>>
>> - develop your application in pharo with the newest cool tools. That
>> maximizes the fun for you
>> - write as much tests as it needs to trigger most of your code so you can
>> detect errros early
>> - get used to Grease/SPort for streams and such. That helps to get around
>> the most annoying thing in smalltalk: dialects
>> - use slime to check your code. Helps ironing out some mistakes that
>> occurr often
>> - if you have code that needs gemstone internals than use MockGemstone to
>> make it load in pharo and work in gemstone. If something is missing just add
>> it to the MockGemstone package it is supposed to be used like that
>> - if you need some pharo methods that aren't present in gemstone than you
>> can add them to the Squeak compatibility package in gemstone
>> - write a metacello configuration to wire all dependent libraries to your
>> project
>> - write a upgrading/migrating utility class because sometimes you need to
>> adjust something in the remote image and shouldn't do this manually
>>
>> I like to say that taking all of these into account you will make it to
>> deploy easily in gemstone. There are always nuts and bolts that don't fit
>> that well. But as you get used to the process the rate will be decreasing.
>> With metacello it is easy to have a configuration of the stable version of
>> your application and one for development. You could than install the stable
>> on production servers and the developement version on a test server.
>>
>> > And you write your code such that it "ends" in a Monticello repository.
>> > Then you do the migration by checking it out the Monticello repository
>> > and "start porting" ?
>> >
>> >
>> No, if you take all the advizes from above you just write code that runs
>> in both. Porting is always kind of a last resort. Dale is doing a lot to
>> lower the barrier between pharo and gemstone. For what does not fit there
>> are Squeak compatibility package, MockGemstone and method extensions in
>> monticello. With the advent of metacello you can have a package split into
>> cross-platform code and platform-dependent code. Platform-dependent code is
>> put into a platform package. Metacello can load the right packages
>> automatically. And so on and on and....
>>
>> hope this gives a little insight,
>>
>> Norbert
>> > --
>> > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
>> > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
>>
>
>