Re: [Pharo-dev] pillar latex and code listings

[Damien Pollet]

On 7 November 2016 at 23:03, Nicolai Hess  wrote:

> I look at the pdf for the update PBE and the references to code example
> don't
> work (just show ??, it works for figures).
>

Could be that the reference or label simply don't match…


> The code in the code example isn't highlight and
> does't have a dark background (as it is in the html output).
>

Don't expect PDF and HTML to look the same. Pillar does its job at a
semantic level, not at form level. Both have their own independent way of
styling stuff. For LaTeX it relies on a specific document class setup,
including some macros to have a layer of decoupling between pillar's output
and what some packages offer. The listing environment you're mentioning is
an example; I haven't looked at pre-EnterprisePharo books in a while, but
it should indeed just be defined as an alias to the lstlisting provided by
listings.sty.

BTW I'd recommend migrating the books to the EnterprisePharo layout… but
that requires being somehow versed in the dark arts of LaTeX and ready to
spend a couple days checking for problems and matching format conventions…

-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

[Pharo-dev] pillar latex and code listings

[Nicolai Hess]

How are latex output of (named) code listings supposed to work /look ?
I look at the pdf for the update PBE and the references to code example
don't
work (just show ??, it works for figures). The code in the code example
isn't highlight and
does't have a dark background (as it is in the html output).
The generated tex looks like this:

\begin{listing}[caption={Decomposing aPen go: 100 + 20},
label=scr:decColor2, language=smalltalk]
  aPen go: 100 + 20
(1) 100 + 20   "binary message first"
   -->   120
(2)  aPen go: 120   "then keyword message"
\end{listing}

the pdf output:

Any idea what is wrong ? Is a postprocessing step necessary ? Should it be
\begin{lstlisting} instead of \begin{listing} ?

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60284
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 4df786: 60284

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 4df786d8d29480e5cd2f631f3d3ea9f701e89cda
  
https://github.com/pharo-project/pharo-core/commit/4df786d8d29480e5cd2f631f3d3ea9f701e89cda
  Author: Jenkins Build Server 
  Date:   2016-11-07 (Mon, 07 Nov 2016)

  Changed paths:
A BaselineOfPharoBootstrap.package/BaselineOfPharoBootstrap.class/README.md
A 
BaselineOfPharoBootstrap.package/BaselineOfPharoBootstrap.class/definition.st
A 
BaselineOfPharoBootstrap.package/BaselineOfPharoBootstrap.class/instance/accessing/minimalGroupPackageNames.st
A 
BaselineOfPharoBootstrap.package/BaselineOfPharoBootstrap.class/instance/baseline/baseline_.st
A 
BaselineOfPharoBootstrap.package/BaselineOfPharoBootstrap.class/instance/utilities/exportProtocolsFrom_.st
A Colors.package/Color.class/README.md
A Colors.package/Color.class/class/accesing/named_.st
A Colors.package/Color.class/class/accesing/unregisterColorNamed_.st
A Colors.package/Color.class/class/accessing/registeredColorNames.st
A Colors.package/Color.class/class/accessing/registeredNameOf_.st
A Colors.package/Color.class/class/colormaps/aaFontsColormapDepth.st
A Colors.package/Color.class/class/defaults/black.st
A Colors.package/Color.class/class/defaults/blue.st
A Colors.package/Color.class/class/defaults/brown.st
A Colors.package/Color.class/class/defaults/cyan.st
A Colors.package/Color.class/class/defaults/darkGray.st
A Colors.package/Color.class/class/defaults/defaultColors.st
A Colors.package/Color.class/class/defaults/defaultColors2.st
A Colors.package/Color.class/class/defaults/defaultColors3.st
A Colors.package/Color.class/class/defaults/defaultColors4.st
A Colors.package/Color.class/class/defaults/gray.st
A Colors.package/Color.class/class/defaults/green.st
A Colors.package/Color.class/class/defaults/lightBlue.st
A Colors.package/Color.class/class/defaults/lightBrown.st
A Colors.package/Color.class/class/defaults/lightCyan.st
A Colors.package/Color.class/class/defaults/lightGray.st
A Colors.package/Color.class/class/defaults/lightGreen.st
A Colors.package/Color.class/class/defaults/lightMagenta.st
A Colors.package/Color.class/class/defaults/lightOrange.st
A Colors.package/Color.class/class/defaults/lightRed.st
A Colors.package/Color.class/class/defaults/lightYellow.st
A Colors.package/Color.class/class/defaults/magenta.st
A Colors.package/Color.class/class/defaults/orange.st
A Colors.package/Color.class/class/defaults/paleBlue.st
A Colors.package/Color.class/class/defaults/paleBuff.st
A Colors.package/Color.class/class/defaults/paleGreen.st
A Colors.package/Color.class/class/defaults/paleMagenta.st
A Colors.package/Color.class/class/defaults/paleOrange.st
A Colors.package/Color.class/class/defaults/palePeach.st
A Colors.package/Color.class/class/defaults/paleRed.st
A Colors.package/Color.class/class/defaults/paleTan.st
A Colors.package/Color.class/class/defaults/paleYellow.st
A Colors.package/Color.class/class/defaults/pink.st
A Colors.package/Color.class/class/defaults/purple.st
A Colors.package/Color.class/class/defaults/red.st
A Colors.package/Color.class/class/defaults/tan.st
A Colors.package/Color.class/class/defaults/transparent.st
A Colors.package/Color.class/class/defaults/veryDarkGray.st
A Colors.package/Color.class/class/defaults/veryLightGray.st
A Colors.package/Color.class/class/defaults/veryPaleRed.st
A Colors.package/Color.class/class/defaults/veryVeryDarkGray.st
A Colors.package/Color.class/class/defaults/veryVeryLightGray.st
A Colors.package/Color.class/class/defaults/white.st
A Colors.package/Color.class/class/defaults/yellow.st
A Colors.package/Color.class/class/examples/wheel_.st
A Colors.package/Color.class/class/examples/wheel_saturation_brightness_.st
A Colors.package/Color.class/class/initialize-release/initialize.st
A 
Colors.package/Color.class/class/initialize-release/initializeColorRegistry.st
A 
Colors.package/Color.class/class/initialize-release/initializeGrayToIndexMap.st
A 
Colors.package/Color.class/class/initialize-release/initializeIndexedColors.st
A 
Colors.package/Color.class/class/initialize-release/registerColor_named_.st
A Colors.package/Color.class/class/instance 
creation/colorFromPixelValue_depth_.st
A Colors.package/Color.class/class/instance creation/colorFrom_.st
A Colors.package/Color.class/class/instance creation/fromArray_.st
A Colors.package/Color.class/class/instance creation/fromHexString_.st
A Colors.package/Color.class/class/instance creation/fromRgbTriplet_.st
A Colors.package/Color.class/class/instance creation/fromString_.st
A Colors.package/Color.class/class/instance creation/gray_.st
A Colors.package/Color.class/class/instance creation/h_s_l_.st
A 

Re: [Pharo-dev] [how about] Exceptions as first class objects *in Debugger*

[Andrei Chis]

+1

I had a prototype working at a certain point that send the exception to the
debugger.
I'll see if I can dig it up. It just involved chancing the API methods that
open the debugger. Maybe a bit late for Pharo 6.

On Sun, Nov 6, 2016 at 11:04 PM, Bernardo Ezequiel Contreras <
vonbecm...@gmail.com> wrote:

> +1, with that information you could describe or show the cause of the
> exception
>
> On Sun, Nov 6, 2016 at 6:46 AM, Sven Van Caekenberghe 
> wrote:
>
>> Indeed this has bothered me a lot as well.
>>
>> At least an 'Inspect Exception' would be useful.
>>
>> It would also encourage people to put more useful information inside
>> exception objects.
>>
>> > On 6 Nov 2016, at 10:38, Yuriy Tymchuk  wrote:
>> >
>> > Hi,
>> >
>> > we have this supercool exception handling mechanism, but as soon as we
>> open a debugger the exception object is gone… I understand that we didn’t
>> need this in old times, but now with a moldable debugger, we could create
>> hooks to allow exceptions to define how they should be addressed (and
>> objects are really powerful).
>> >
>> > Cheers.
>> > Uko
>>
>>
>>
>
>
> --
> Bernardo E.C.
>
> Sent from a cheap desktop computer in South America.
>

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Esteban Lorenzano]

> On 7 Nov 2016, at 14:53, Nicolas Passerini  wrote:
> 
> Well, maybe we can do it for Pharo 7.

unless of course we find that doing it like this is incredibly easy and also we 
can do an “automigration tool” style the autodeprecation tool ;)

Esteban

> 
> 2016-11-07 14:46 GMT+01:00 Esteban Lorenzano  >:
> 
>> On 7 Nov 2016, at 14:39, Nicolas Passerini > > wrote:
>> 
>> 
>> 2016-11-07 10:37 GMT+01:00 Denis Kudriashov > >:
>> NativeStructure 
>>subclass : #SDL_Point
>>layout : StructureLayout
>>slots: { #x &=> #int. #y &=> #int}
>> ...
>> (I got example of Ronie definition from his paper 
>> https://hal.inria.fr/hal-01353884/document 
>> ).
>> So all offsets logic will go to one place StructureLayout and slots. And 
>> also we will not forced to use accessors anymore.
>> 
>> I like this idea.
>> But one question, would it be backwards compatible? (I mean, if I have 
>> current FFI invocations that use a structure in the traditional way, will I 
>> have to change all these functions if I try to migrate to this new idea?)
> 
> no, and that’s why I didn’t considered it for now. 
> this is an api change, non backwards compatible and then it breaks my own 
> criteria about Pharo6 development: no more API changes. 
> 
> but yes, in general, I like the idea… just we cannot break things just like 
> that (I know, I break things… but this is not willingly :P)
> 
> Esteban
> 
> 

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Nicolas Passerini]

Well, maybe we can do it for Pharo 7.

2016-11-07 14:46 GMT+01:00 Esteban Lorenzano :

>
> On 7 Nov 2016, at 14:39, Nicolas Passerini  wrote:
>
>
> 2016-11-07 10:37 GMT+01:00 Denis Kudriashov :
>
>> NativeStructure
>>subclass : #SDL_Point
>>layout : StructureLayout
>>slots: { #x &=> #int. #y &=> #int}
>> ...
>> (I got example of Ronie definition from his paper
>> https://hal.inria.fr/hal-01353884/document).
>> So all offsets logic will go to one place StructureLayout and slots. And
>> also we will not forced to use accessors anymore.
>>
>
> I like this idea.
> But one question, would it be backwards compatible? (I mean, if I have
> current FFI invocations that use a structure in the traditional way, will I
> have to change all these functions if I try to migrate to this new idea?)
>
>
> no, and that’s why I didn’t considered it for now.
> this is an api change, non backwards compatible and then it breaks my own
> criteria about Pharo6 development: no more API changes.
>
> but yes, in general, I like the idea… just we cannot break things just
> like that (I know, I break things… but this is not willingly :P)
>
> Esteban
>
>

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Esteban Lorenzano]

> On 7 Nov 2016, at 14:39, Nicolas Passerini  wrote:
> 
> 
> 2016-11-07 10:37 GMT+01:00 Denis Kudriashov  >:
> NativeStructure 
>subclass : #SDL_Point
>layout : StructureLayout
>slots: { #x &=> #int. #y &=> #int}
> ...
> (I got example of Ronie definition from his paper 
> https://hal.inria.fr/hal-01353884/document 
> ).
> So all offsets logic will go to one place StructureLayout and slots. And also 
> we will not forced to use accessors anymore.
> 
> I like this idea.
> But one question, would it be backwards compatible? (I mean, if I have 
> current FFI invocations that use a structure in the traditional way, will I 
> have to change all these functions if I try to migrate to this new idea?)

no, and that’s why I didn’t considered it for now. 
this is an api change, non backwards compatible and then it breaks my own 
criteria about Pharo6 development: no more API changes. 

but yes, in general, I like the idea… just we cannot break things just like 
that (I know, I break things… but this is not willingly :P)

Esteban

Re: [Pharo-dev] Belgian Pharoers and coding day proposal

[Sven Van Caekenberghe]

If I can (calendar wise), I would be happy to join !

> On 7 Nov 2016, at 14:37, p...@highoctane.be wrote:
> 
> I would like to propose a coding day about Pharo.
> 
> Here is the concept: people come over to my place(max 8) we do Pharo coding 
> and have some nice food and drinks in the process.
> 
> I wrote Belgian pharoers but that is not a limitation, just that it would be 
> easier if you are near the place (Wavre).
> 
> I can also organize this at startup coworking spaces as well.
> 
> Takers?
> 
> Phil
> 
> 
> 
> 

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Nicolas Passerini]

2016-11-07 10:37 GMT+01:00 Denis Kudriashov :

> NativeStructure
>subclass : #SDL_Point
>layout : StructureLayout
>slots: { #x &=> #int. #y &=> #int}
> ...
> (I got example of Ronie definition from his paper https://hal.inria.fr/
> hal-01353884/document).
> So all offsets logic will go to one place StructureLayout and slots. And
> also we will not forced to use accessors anymore.
>

I like this idea.
But one question, would it be backwards compatible? (I mean, if I have
current FFI invocations that use a structure in the traditional way, will I
have to change all these functions if I try to migrate to this new idea?)

[Pharo-dev] Belgian Pharoers and coding day proposal

[p...@highoctane.be]

I would like to propose a coding day about Pharo.

Here is the concept: people come over to my place(max 8) we do Pharo coding
and have some nice food and drinks in the process.

I wrote Belgian pharoers but that is not a limitation, just that it would
be easier if you are near the place (Wavre).

I can also organize this at startup coworking spaces as well.

Takers?

Phil

Re: [Pharo-dev] Accessing Virtual machine internal?

[Clément Bera]

Yes.

Evaluate "Smalltalk vm parameterAt: 46" it should get you the machine code
zone size.

You can look into the comment in the VirtualMachine class or in
VirtualMachine>>getParameters method comment to see what VM internal is
available.

On Nov 7, 2016 19:37, "Alexandre Bergel"  wrote:

> Hi!
>
> Is there a way to get access to the VM internals? For example the size of
> the method cache and the number of JIT-compiled methods?
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] Accessing Virtual machine internal?

[Nicolai Hess]

2016-11-07 13:37 GMT+01:00 Alexandre Bergel :

> Hi!
>
> Is there a way to get access to the VM internals? For example the size of
> the method cache and the number of JIT-compiled methods?
>

I don't know about the method cache siize, but for the number of
JIT-Compiled methods is a primitive (a VMParameter)


>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

[Pharo-dev] Accessing Virtual machine internal?

[Alexandre Bergel]

Hi!

Is there a way to get access to the VM internals? For example the size of the 
method cache and the number of JIT-compiled methods?

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] [Pharo-users] About balkanisation

[Esteban Lorenzano]

> On 7 Nov 2016, at 11:28, Dale Henrichs  
> wrote:
> 
> 
> 
> On 11/7/16 4:52 AM, Esteban Lorenzano wrote:
>> btw this is pharo-dev discussion, redirecting there.
>> 
>> Esteban
>> 
>>> On 7 Nov 2016, at 08:50, Esteban Lorenzano  wrote:
>>> 
>>> We are developing Iceberg… and I know is not enough :)
>>> Which “unifying tools” are you referring ?
> The main unifying tool is a Metacello Project Browser (or something like the 
> tODE project list).
> 
> You have a nice tool with the CatalogBrowser (modulo BaselineOf support) ... 
> but you know that already:) but once you load a Project into the image with 
> the CatalogBrowser it sort of disappears ...
> 
> There needs to be a way to see the _projects_ are loaded in the image ... 
> right now you can see the package loaded into the image, and you can see the 
> dirty packages, but the package is at too low a level
> 
> From the project browser you should be able to commit a project --- which 
> saves all of the dirty packages in the project --- in one commit for a git 
> project --- all of the dirty packages written in one operation for mcz 
> packages ...
> 
> This project browser can provide the same set of services for an mcz project 
> (ConfigurationOf) or a filetree project (BaselineOf):
>  - save
>  - load-- this is a bit more complicated to explain (I tried at 
> the Metacello Dr. talk, but more discussion is needed)
>  - diff  -- project level diff over a collection of packages
>  - commit log -- For ConfigurationOf, list the commit history of the 
> Configuration.
>For a BaselineOf list the commit log for the git 
> repository
> 
> The workflow at the project level is not that different between Mcz and 
> Filetree, so it is straightforward to work with …

this is what is provided by iceberg… it still needs some work, but this is 
precisely what is supposed to do :)
(and btw, this is why I disagree with Thierry some mails below).

> 
> The unification comes because you can use one metaphor (project) to work with 
> both Mcz and Filetree ... the underlying implementation will ultimately...
> 
> The next layer of unified tools is when you look at version history, for a 
> method, you need to provide the ability to view the git commit history for 
> the method (if stored in git) or the image history ... git commit hisotry can 
> be provided at the project/package/class/method ... whereever possible the 
> equivalent mcz/git service should be provided so that the two systems are on 
> an even par …

also, this is supposed to be provided by iceberg. 

> 
> The Monticello Browser and Iceberg GUI's don't go away, because it is often 
> necessary to do work at the package level, but I think that putting focus on 
> the project is the key ingredient to success for integrating git …

Iceberg is not package-oriented. It just show 
repositories/packages/classes/methods… this is a good way to do it and I do not 
thing anything is lost like this.
You need to take a second look at Iceberg :) 

> 
> Since git repos are persistent on disk and will be shared ... it is important 
> that there be a way for developers to easily access the git repos for 
> projects that have been cloned locally but not yet loaded in the image itself 
> ... I am really struggling with getting how important this point as this is 
> the also a point that ties a Catalog Browser and Project Browser together

this is something to think… I do not get what catalog browser  can do here (but 
yes, a way to browse local repositories needs to be provided).

> 
> I've been using this approach for several years now and once you have the 
> tools and can see at a glance what's "going on in your image" it is fun to 
> work in a mixed environment ... all of this frustration that is bubbling on 
> the list is largely due to not having these missing tools and underlying 
> support --- I think …

I do not think we are so far from your vision. I think you did not get it 
Iceberg right… please, take a second look :)
now… is true that now everything you say is already done… but this is general 
orientation :)

Esteban

ps: all of this is *clearly* not pharo-users but pharo-dev discussion, let’s 
move there.

>>> 
>>> I have followed very close your TOdE development… in a moment I was 
>>> planning a migration of it for pure-pharo, just… lack of time as always and 
>>> then later we started iceberg.
> Yes, I have intended to do a port of tODE to Pharo, but of time is the killer 
> :)
>>> now, we are in the process of defining a process ;) who works for pharo and 
>>> is the moment to build the bridges we need, but in general I think that 
>>> staying "with a foot in two boats” can just work during a very short lapse 
>>> of time, after that, the stream continues going and if you do not finish 
>>> your jump into one of the boats you will be very fast in the water.
> Yes but the two boat environment will 

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Denis Kudriashov]

Hi Esteban.

2016-11-06 17:51 GMT+01:00 Esteban Lorenzano :

>
> height
> "This method was automatically generated"
> ^handle doubleAt: 17
>
> height: anObject
> "This method was automatically generated"
> handle doubleAt: 17 put: anObject
>
> which of course does not work.
> with my idea this will become like this:
>
> height
> "This method was automatically generated"
> ^handle doubleAt: HEIGHT_OFFSET
>
> height: anObject
> "This method was automatically generated"
> handle doubleAt: HEIGHT_OFFSET put: anObject
>

I have feeling that Slots could solve this problem really well and also
improve the way how we work with external structures.
If you saw how Ronie describes external structures then you could imaging
what I am talking about.
For now on class side we always have #fieldDesc: method like:

SDL_Point>>fieldsDesc
"
self initializeAccessors
"
^#(
int x;
int y;
  )

where code in comments generates accessors.
And with Ronie approach this description will go directly to class
definition:

NativeStructure
   subclass : #SDL_Point
   layout : StructureLayout
   slots: { #x &=> #int. #y &=> #int}
...
(I got example of Ronie definition from his paper
https://hal.inria.fr/hal-01353884/document).
So all offsets logic will go to one place StructureLayout and slots. And
also we will not forced to use accessors anymore.

What you think?

Best regards,
Denis

Re: [Pharo-dev] why sparta depends on Taskit?

[Tudor Girba]

Hi,

> On Nov 7, 2016, at 8:51 AM, Esteban Lorenzano  wrote:
> 
> 
>> On 7 Nov 2016, at 07:41, Aliaksei Syrel  wrote:
>> 
>> Hi
>> 
>> It is a library :) Even that there is an important difference between plugin 
>> and library we always refer to library in this thread.
>> 
> I was thinking that but then Doru mentioned “Moz2D plugin” and I got confused 
> :)

I am a bit at a loss with the naming given that libMoz2D.dylib library lies in 
the Plugins folder of the VM :).

But, the good thing is that we talk about the same thing :).

Cheers,
Doru


> Esteban
>> Cheers
>> Alex
>> 
>> 
>> On Nov 6, 2016 22:31, "Esteban Lorenzano"  wrote:
>> 
>> > On 6 Nov 2016, at 21:47, Tudor Girba  wrote:
>> >
>> > Hi,
>> >
>> >> On Nov 6, 2016, at 9:43 PM, stepharo  wrote:
>> >>
>> >> I tried to open the image that glenn gave me and I can browse the code (I 
>> >> got an FFI problem due to the fact that the lib is not present).
>> >>
>> >> I tried and I could open the image from the ci with the vm glenn sent me.
>> >>
>> >> So I will update my vm.
>> >
>> > Thanks!
>> >
>> > So, the default Pharo VM does not have the Moz2D plugin, and likely that 
>> > is what Glenn gave you. Could you try with that VM to run 2 examples? I 
>> > still have a funky issue with my machine that I can only run one example, 
>> > and then I get a black screen for the second one.
>> 
>> why do you need a plugin and not just a regular library?
>> 
>> Esteban
>> 
>> >
>> > Cheers,
>> > Doru
>> >
>> >> Stef
>> >>
>> >>
>> >>
>> >> Le 6/11/16 à 20:19, Tudor Girba a écrit :
>> >>> Hi,
>> >>>
>> >>> It does not work to run the Bloc examples with the regular VM, but it 
>> >>> does work to browse the code. Stef is saying that he cannot browse code 
>> >>> in the Bloc image.
>> >>>
>> >>> This is a significant problem, but I just do not see why this is so. So, 
>> >>> it would be very useful for us to learn where this problem could come 
>> >>> from.
>> >>>
>> >>> Doru
>> >>>
>> >>>
>>  On Nov 6, 2016, at 7:01 PM, Aliaksei Syrel  wrote:
>> 
>>  Hi
>> 
>>  Just taking Bloc image from CI does not work. Don't forget that you 
>>  need Sparta plugin (libMoz2D.dylib/DLL/so). I didn't find a way how to 
>>  ship plugin with image, sorry...
>> 
>>  It can be downloaded from bintray 
>>  https://bintray.com/syrel/Moz2D/libMoz2D.
>> 
>>  Cheers
>>  Alex
>> 
>> 
>>  On Nov 6, 2016 4:58 PM, "Tudor Girba"  wrote:
>>  Hi,
>> 
>>  I think there are a couple of thinks that are mixed up.
>> 
>>  First, the image from CI:
>>  - download the latest image built on October 12 on Jenkins:
>>  https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=60,VERSION=development,VM=vm/lastSuccessfulBuild/artifact/Bloc.zip
>>  - run it either with the stable of the latest VM
>>  ==> you should get no crash when opening the image (I just checked 
>>  again)
>> 
>>  The code loading is a bit strange. I just tried and I do now know why 
>>  this does not work from the command line on Mac. For me it somehow 
>>  hanged while loading PetitCSS. There is something strange with 
>>  Metacello and projects that depend on Glamour that I could not quite 
>>  fully understand yet and I am looking at it since a month. Dale, I need 
>>  your help, but I will follow up on this :).
>> 
>>  At the same time, I can reliably load the code using this script from a 
>>  fresh Pharo image and the latest VM:
>> 
>>  Gofer it
>>    smalltalkhubUser: 'Pharo' project: 'Bloc';
>>    configuration;
>>    loadDevelopment.
>> 
>>  Can you please try this one?
>> 
>>  Cheers,
>>  Doru
>> 
>> 
>> 
>> > On Nov 6, 2016, at 11:24 AM, stepharo  wrote:
>> >
>> > I got to the ci and I click on the image and download and drop it on 
>> > my vm=> crash.
>> > Why doing a video?
>> >
>> > open a shell
>> >
>> >wget -O - http://get.pharo.org/60+vm | bash
>> > ./pharo Pharo.image config 
>> > http://www.smalltalkhub.com/mc/Pharo/Bloc/main ConfigurationOfBloc 
>> > --install=development
>> >
>> > And it fails loading taskit.
>> >
>> > Stef
>> >
>> >
>> >
>> >
>> > Le 6/11/16 à 11:01, Aliaksei Syrel a écrit :
>> >> The best would be if you could make a video of how you install Bloc 
>> >> and send to Glenn. Because it works for us and for Travis CI. 
>> >> Sound like you face a strange and not so easy to catch issue.
>> >>
>> >> Cheers
>> >> Alex
>> >>
>> >>
>> >> On Nov 5, 2016 6:54 PM, "stepharo"  wrote:
>> >> why sparta depends on Taskit?
>> >>
>> >>
>> >> Since I cannot load it I cannot try to understand. I