Oops, wrong project name:
Metacello image
project: 'Seaside3';
list
I'll send mail to you privately to exchange the image ..
Thanks,
Dale
On 02/21/2017 11:00 AM, Hilaire wrote:
Hi Dale,
Le 21/02/2017 à 18:30, Dale Henrichs a écrit :
Metacello image
project: 'Seaside';
Hi Dale,
Le 21/02/2017 à 18:30, Dale Henrichs a écrit :
> Metacello image
> project: 'Seaside';
> list
It returns an empty list in this image.
Can you send me privately your email at hilaire [AT] drgeo.eu so I can
send you a link? (I am reading through gmane news forum and email
address
On 02/20/2017 09:08 AM, Hilaire wrote:
Dale,
I try out the lock feature on an archived image, the seaside uprade was
still operating :(
Hmm, do you think it would be possible to share your image with me ...
it's bad enough that the Seaside is getting updated in a mysterious
manner, but now
On 02/19/2017 11:21 PM, Stephan Eggermont wrote:
On 19/02/17 18:50, Dale Henrichs wrote:
Hilaire,
I mentioned last night that I thought that there was a better solution
to your problem and I think that if you load the latest Metacello and
then lock Seaside3:
Metacello image
Dale,
I try out the lock feature on an archived image, the seaside uprade was
still operating :(
I updated this image with latest Metacello, then I locked it as:
Metacello image
configuration: 'Seaside3';
version: '3.1.4.2'; "most recent 3.1.x version"
lock.
It was the version
I will try to get a look at your lock feature, and report.
Thanks
Hilaire
Le 19/02/2017 à 18:50, Dale Henrichs a écrit :
> I mentioned last night that I thought that there was a better solution
> to your problem and I think that if you load the latest Metacello and
> then lock Seaside3:
--
Le 20/02/2017 à 08:19, Stephan Eggermont a écrit :
>> May be it is more a policy problem on the quality of the configuration
>> than a tool problem, a lot can be learn from Debian packaging.
>
> I don't have that impression. They seem to have the same problem with
> old and less-used stuff.
As
On 19/02/17 18:50, Dale Henrichs wrote:
Hilaire,
I mentioned last night that I thought that there was a better solution
to your problem and I think that if you load the latest Metacello and
then lock Seaside3:
Metacello image
configuration: 'Seaside3';
version: '3.1.5'; "most recent
On 18/02/17 16:32, Hilaire wrote:
update, this should NOT happen.
Now image comes with a Configuration Browser, if I understand correctly
its intend, an user is expected those configurations to work happily
together, but it looks like not, some configurations will request update
breaking package
Hilaire,
I mentioned last night that I thought that there was a better solution
to your problem and I think that if you load the latest Metacello and
then lock Seaside3:
Metacello image
configuration: 'Seaside3';
version: '3.1.5'; "most recent 3.1.x version"
lock.
Then load
On 2/18/17 7:32 AM, Hilaire wrote:
Dale,
May be you don't want to waste anymore time on that. Thanks for your
effort. I got a way to get Voyage installed in my development image.
Well I am still curious why you are having trouble ...
Not sure what wrong, because something is wrong[1], but
Dale,
May be you don't want to waste anymore time on that. Thanks for your
effort. I got a way to get Voyage installed in my development image.
Not sure what wrong, because something is wrong[1], but I got the things
installed, first update to Seaside, which break when upgrading the
Seaside
The configuration of seaside is the same before and after the
'Monticello new' loads. #278
It match the fact you don't see a ConfigurationOfSeaside3 download in
the transcript.
As I wrote in a previous email, if Seaside is not installed, the install
of Voyage doesn't trigger a Seaside install.
Again, thanks for detailed info ...
The fact that you loaded Seaside3.1.x is good enough for my purposes
.. the fact that Seaside3.2 is getting installed implies that there is a
hard dependency on Seaside in one of the projects (Magritte3 perhaps?)
... odd that ConfigurationOfSeaside3
Hi Dale,
Thanks for your detailed suggestions. I follow instructions, here the
report bellow.
Installed newest Metacello, then Voyage with new style:
Metacello new
baseline: 'Metacello';
repository: 'github://dalehenrich/metacello-work:master/repository';
get.
Metacello new
baseline:
Hilaire,
Thanks for the detailed information ...
I see that you are using the old-style loading of Voyage
(`ConfigurationOfVoyageMongo load`) ... when using this style of
loading, Metacello has to guess about which projects are loaded and what
version of the project is loaded. I is possible
Hi Dale,
At first I was more thinking of a problem in the dependencies of Voyage,
but then it seems not as with unload Seaside, Voyage get load. It did
not help anyway becasue Seaside can't be reinstalled (Obsolete class
syndrom hit there)
Voyage is installed as:
"VoyageMongo
Hilaire,
You don't mention how you are loading Voyage. If I had the load
expression and Transcript output from the load, I'd pretty much be able
to tell pretty much what is going on.
I have a couple of theories about what could be going wrong, but without
the load expression and Transcript
Trying to understand this problem:
>From my development image, I uninstalled all seaside, then I installed
Voyage. This time it went fine AND Seaside-core *was not* installed
during the process.
What the heck is going on?
When Seaside was present in my dev. image, installing Voyage make
Some more info.
Installing the configuration of Voyage from Pharo4 itself also breaks
the installed Seaside, which was previously installed from the Pharo4
configuration too.
Now when installing the Voyage configuration, it warns about installing
Seaside-Core and the conflict with installed
Hi,
I need to test Voyage for a project in development but...
installing Voyage on Pharo4 with Seaside already installed (from Pharo4
configuration) produces a broken Seaside installation.
Voyage installation installs Seaside-core, which in turn break the
installed Seaside. It is strange
21 matches
Mail list logo
