Hi Dario,

this is good that you tested with Roassal. We have a more general issue...

2016-11-29 15:56 GMT+01:00 Trussardi Dario Romano <dario.trussardi@tiscali.it>:
Ciao,

Hi Dario,

2016-11-29 14:00 GMT+01:00 Trussardi Dario Romano <dario.trussardi@tiscali.it>:



2016-11-29 11:55 GMT+01:00 Trussardi Dario Romano <dario.trussardi@tiscali.it>:
Ciao,

IMPORTANT CONSIDERATION:

If i started the Pharo 5.0 image from the desktop icon all works fine.

Do you note this difference?!

Of course. Paths/environment may be (is probably) different when you start from the desktop icon and when you start it from Contents/Resource.


But i��have a working ��Pharo5.0-161126.image into the Pharo 5.0 package Contents/ Resource/ directory.

I open it with Pharo5.0 ( Pharo5.0 ) ��application.

The Pharo image is right open�� but the GitFileTree loading generates the exception in this case.





These are the step i do for load:

I��open the Catalogs Browser and select the��GitFileTree project.

On it ��i press the right mouse button and do the option: Instal stable version

The system browse a dialog with:��

" GitFileTree has not been marked as tested for Pharo5.0!
Do you want to continue ( installation could fail )?

Ok. Will have a look into the catalog browser source code to get rid of that. I know that the catalog browser uses the Pharo6 ConfigurationOfGitFileTree instead of the Pharo5 one.

But the same procedure and relative��ConfigurationOfGitFileTree,

��works fine when i load it to Pharo launched from Pharo desktop icon.

The problematic is when i load it into ��Pharo5.0-161126.image from ��the Pharo 5.0 package Contents/ Resource/ subdirectory.

I have noticed and my questions relate to that.
��

��

I confirm.

The Pharo load some 'package' �� and after the image ��use the 100% of the CPU.

After some times the CPU load don't change ( 100% ) and the Pharo don't answer. ( the User interrupt alt ��Cmd - : �� is not intercepted )

Yes, this one is problematic.

Could you try to load OSSubprocess from the configuration browser? Tell me if it locks-up while trying to load that.

Like above, ��load��OSSubprocess:

A ) Into Pharo launched from desktop icon all works fine.

B) Into��Pharo5.0-161126.image��launched from :�� �� the Pharo 5.0 package Contents/ Resource/ subdirectory
the system locks-up

Does this lockup happens if you load something else from the catalog, such as Roassal2?

I load he Roassal2 without problem��in both images ( Pharo desktop and����Pharo5.0��Contents/ Resource/Pharo5.0-161126.image )

When i run Roassal2 example (��RTLayoutExample new exampleCircle ) ��in both images the system answer:

Error: External module not found

ExternalLibraryFunction(Object)>>error:
ExternalLibraryFunction(Object)>>externalCallFailed
ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
AthensCairoSurface class>>primImage:width:height:
AthensCairoSurface class>>extent:format:
AthensCairoSurface class>>extent:
TRCanvas>>initialize
TRCanvas class(Behavior)>>new
RTView>>initialize
RTView class(Behavior)>>new
RTMondrian(RTBuilder)>>createView
RTMondrian>>createView
RTMondrian(RTBuilder)>>initialize
RTMondrian>>initialize
RTMondrian class(Behavior)>>new
UndefinedObject>>DoIt
Compiler>>evaluate:in:to:notifying:ifFail:logged:
Compiler class>>evaluate:for:notifying:logged:
Compiler class>>evaluate:for:logged:
Compiler class>>evaluate:
RTLayoutExample(RTAbstractExample)>>installTitle:code:
RTLayoutExample class>>DoIt
OpalCompiler>>evaluate
RubSmalltalkEditor>>evaluate:andDo:
RubSmalltalkEditor>>evaluateSelectionAndDo:
RubSmalltalkEditor>>printIt
[ :target | target editor printIt ] in RubSmalltalkEditor class>>buildShortcutsOn: in Block: [ :target | target editor printIt ]
BlockClosure>>cull:
BlockClosure>>cull:cull:
BlockClosure>>cull:cull:cull:

thanks,

Pharo is unable to access a library it needs; this is the native boost plugin which is normally bundled with it (and the cairo lib?)...

Guys, anybody with a mac around there?

Thierry

��

Dario


My hypothesis is that, since you have two different ways of starting Pharo with a different system environment (and preloaded libraries, and maybe LD_LIBRARY_PATH set/unset, and maybe different PATH, etc...), something at init of OSSubprocess never returns and lock-up the image.

Or, anything you load from the catalog in the second case locks-up, in which case something linked to code run after completing a project load locks-up when you don't use the environment provided by the desktop link.

Could someone with a Mac check that, please?

Regards,

Thierry

��

Dario


Thierry
��

I need to shut Pharo ��and reopen the image.

Thanks,

Dario


Hi Dario,

can you tell a bit more about what is happening exactly?

Thierry

2016-11-29 10:57 GMT+01:00 Trussardi Dario Romano <dario.trussardi@tiscali.it>:
Ciao,

�� �� �� �� i have a�� �� �� �� �� �� �� �� Pharo5.0�� �� �� �� Latest update: #50763�� image�� �� run on MacBook Pro with OS X�� �� ��10.7.5.

�� �� �� �� When i load the�� �� �� �� �� �� �� �� ��GitFileTree�� �� ��support the environment go in loop and i need to shut it.

�� �� �� �� Considerations?

�� �� �� �� Thanks,

�� �� �� �� �� �� �� �� Dario