Smalltalk › Pharo › Pharo Smalltalk Developers

GitFileTree dependencies

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Uko2

GitFileTree dependencies

Hi,

when loading GitFileTree in Pharo 5, I get:

This package depends on the following classes:
StringHolder
You must resolve these dependencies before you will be able to load these definitions:
CrLfFileEditor
…

Does anybody know if this was caused by any recent changes?

Uko

P.S. we should add some mechanics to report dependency issues at CI server. Because when one loads Moose (for example) from scratch, he will encounter dependency issues, but as most of people who work on Moose download the ready-made image from CI, it’s not a visible problem.

stepharo

Re: GitFileTree dependencies

Yes StringHolder does not exist anymore.
So may be you can load an old version and change GitFileTree but
GitFileTree should not rely on this old and bad class.
It took us 3 years to remove it.

Stef

Le 19/6/15 11:32, Yuriy Tymchuk a écrit :

> Hi,
>
> when loading GitFileTree in Pharo 5, I get:
>
> This package depends on the following classes:
> StringHolder
> You must resolve these dependencies before you will be able to load these definitions:
> CrLfFileEditor
> …
>
> Does anybody know if this was caused by any recent changes?
>
> Uko
>
>
> P.S. we should add some mechanics to report dependency issues at CI server. Because when one loads Moose (for example) from scratch, he will encounter dependency issues, but as most of people who work on Moose download the ready-made image from CI, it’s not a visible problem.
>
>

Thierry Goubier

Re: GitFileTree dependencies

GitFileTree does not depend on StringHolder. CommandShell does. The next update of CommandShell will solve that, but it needs some testing first.

Thierry

Le 26 juin 2015 10:41 PM, "stepharo" <[hidden email]> a écrit :

Yes StringHolder does not exist anymore.
So may be you can load an old version and change GitFileTree but GitFileTree should not rely on this old and bad class.
It took us 3 years to remove it.

Stef

Le 19/6/15 11:32, Yuriy Tymchuk a écrit :

Hi,

when loading GitFileTree in Pharo 5, I get:

This package depends on the following classes:
StringHolder
You must resolve these dependencies before you will be able to load these definitions:
CrLfFileEditor
…

Does anybody know if this was caused by any recent changes?

Uko

P.S. we should add some mechanics to report dependency issues at CI server. Because when one loads Moose (for example) from scratch, he will encounter dependency issues, but as most of people who work on Moose download the ready-made image from CI, it’s not a visible problem.

stepharo

Re: GitFileTree dependencies

thanks!

Le 27/6/15 00:27, Thierry Goubier a écrit :

GitFileTree does not depend on StringHolder. CommandShell does. The next update of CommandShell will solve that, but it needs some testing first.

Thierry

Le 26 juin 2015 10:41 PM, "stepharo" <[hidden email]> a écrit :

Yes StringHolder does not exist anymore.
So may be you can load an old version and change GitFileTree but GitFileTree should not rely on this old and bad class.
It took us 3 years to remove it.

Stef

Le 19/6/15 11:32, Yuriy Tymchuk a écrit :

Hi,

when loading GitFileTree in Pharo 5, I get:

This package depends on the following classes:
StringHolder
You must resolve these dependencies before you will be able to load these definitions:
CrLfFileEditor
…

Does anybody know if this was caused by any recent changes?

Uko

P.S. we should add some mechanics to report dependency issues at CI server. Because when one loads Moose (for example) from scratch, he will encounter dependency issues, but as most of people who work on Moose download the ready-made image from CI, it’s not a visible problem.

Thierry Goubier

Re: GitFileTree dependencies

Le 05/07/2015 12:45, stepharo a écrit :
> thanks!

CommandShell has been updated.

I may look at one point into adding support for pseudo-tty. Does anybody
knows if pseudo-tty are available with Microsoft Windows?

Thierry

> Le 27/6/15 00:27, Thierry Goubier a écrit :
>>
>> GitFileTree does not depend on StringHolder. CommandShell does. The
>> next update of CommandShell will solve that, but it needs some testing
>> first.
>>
>> Thierry
>>
>> Le 26 juin 2015 10:41 PM, "stepharo" <[hidden email]
>> <mailto:[hidden email]>> a écrit :
>>
>> Yes StringHolder does not exist anymore.
>> So may be you can load an old version and change GitFileTree but
>> GitFileTree should not rely on this old and bad class.
>> It took us 3 years to remove it.
>>
>> Stef
>>
>> Le 19/6/15 11:32, Yuriy Tymchuk a écrit :
>>
>> Hi,
>>
>> when loading GitFileTree in Pharo 5, I get:
>>
>> This package depends on the following classes:
>> StringHolder
>> You must resolve these dependencies before you will be able to
>> load these definitions:
>> CrLfFileEditor
>> …
>>
>> Does anybody know if this was caused by any recent changes?
>>
>> Uko
>>
>>
>> P.S. we should add some mechanics to report dependency issues
>> at CI server. Because when one loads Moose (for example) from
>> scratch, he will encounter dependency issues, but as most of
>> people who work on Moose download the ready-made image from
>> CI, it’s not a visible problem.
>>
>>
>>
>>
>

Peter Uhnak

Re: GitFileTree dependencies

On Mon, Jul 6, 2015 at 10:44 PM, Thierry Goubier <[hidden email]> wrote:

I may look at one point into adding support for pseudo-tty. Does anybody knows if pseudo-tty are available with Microsoft Windows?

Maybe PuTTY? But I've only ever used that for ssh, so I don't know if it has the functionality you need.

David T. Lewis

Re: GitFileTree dependencies

On Mon, Jul 06, 2015 at 11:03:06PM +0200, Peter Uhn??k wrote:
> On Mon, Jul 6, 2015 at 10:44 PM, Thierry Goubier <[hidden email]>
> wrote:
>
> >
> > I may look at one point into adding support for pseudo-tty. Does anybody
> > knows if pseudo-tty are available with Microsoft Windows?
> >

I don't know of any direct equivalent on Windows. But people do write
good terminal emulators that run on Windows, so there must be a way to
do it.

>
> Maybe PuTTY? But I've only ever used that for ssh, so I don't know if it
> has the functionality you need.

Googling for "putty api" turns up quite a few links, so maybe something
there would help.

Dave