Re: [Pharo-users] Creating the smallest server runtime footprint

[Tim Mackinnon]

I wasn’t clear on which image to retry - the 
https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip
 

 one still shows as being last updated 7 days ago.

The 
https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-ConfigurationOfMinimalPharo/
 

 one gives me a mismatch error: This interpreter (vers. 68021) cannot read 
image file (vers. 6521).

The 
https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip
 

 one gives me a walkback when trying to run my install script :

25 UndefinedObject(Object)>>doesNotUnderstand: #addTo:
26 MCRepositoryGroup>>addRepository:
27 createRepository
  | repo |
  repo := self project createRepository: self.
  ^ MCRepositoryGroup default repositories
detect: [ :each | each = repo ]
ifNone: [ 
  MCRepositoryGroup default addRepository: repo.
  repo ] in MetacelloRepositorySpec>>createRepository

I think this is because the image doesn’t support Metacello? As in:
Metacello new
repository: 'filetree://../src';
baseline: 'Lambda';
load.

How do you guys load things into the minimal images (I thought you used 
Metacello - but maybe you do it some other way?)

I can use a big 6.1 image fine (as it has Metacello loaded) but I’d really like 
a minimal solution - that can load in libraries like AWS S3, or XML parsing 
etc. and it seems like I should be a good customer for kicking the tires on all 
of this.

Tim

> On 31 Jul 2017, at 14:42, Pavel Krivanek  wrote:
> 
> 
> 
> 2017-07-31 15:28 GMT+02:00 Tim Mackinnon  >:
> Ok (I am reading there is a lot going on for you guys to sort out at the 
> moment).
> 
> It sounds like a more stable conversion of Pharo 6.1 for 64 bit would be best 
> to give me a stable platform to run on.
> 
> In that minimal image - what can I rely on to load code (in trying the 7.0 
> version it seems like Gofer isn’t there, and I’m now wondering if Metacello 
> isn’t there either) - so I’m wondering how you guys load baselinesOf of 
> configurationsOf?
> 
> Try it again, there was a bug in the job configuration
> 
> .. Pavel
>  
> 
> Tim
> 
>> On 31 Jul 2017, at 14:17, Pavel Krivanek > > wrote:
>> 
>> H Tim
>> 
>> 2017-07-31 15:07 GMT+02:00 Tim Mackinnon > >:
>> Hi Pavel - I’m just revisiting a few of your previous messages on minimal 
>> images as I’m trying to get things working again with Pharo 6.1 now that you 
>> guys have rejigged all of the build pipelines.
>> 
>> I tried a previous suggestion of:
>> 
>> For Pharo 6: 
>> https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip
>>  
>> 
>> For Pharo 7: 
>> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip
>>  
>> 
>> 
>> However the Pharo 6 version is no longer being built, and it doesn’t seem to 
>> work well with the newer 64bit vm (? I seem to get a load error that I 
>> didn’t have before - although its possible that I’m loading a new pre-req 
>> with metacello and this is tipping it over the edge).
>> 
>> Anyway - a prev suggestion for 6.x from you was:
>>> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-ConfigurationOfMinimalPharo/
>>>  
>>> 
>> However this is a 32bit image. Is there an equivalent 64bit image for 6.1?  
>> OR should I use the Pharo 7 one for now (I guess the minimal image will 
>> probably be pretty stable for a little while as I’m sure the action is 
>> higher up the chain?)
>> 
>> You should use an image that is bootstrapped, so version from SysConf jobs 
>> or Pharo 7. For Pharo 7 we are preparing a lot of big changes in the kernel 
>> so do not expect it will be stable. We can do a conversion job of of it to 
>> 64-bit version as soon as the CI infrastructure will be on knees again.
>> 
>> -- Pavel
>> 
>>  
>> 
>> Tim
>> 
>> 
>>> On 15 Jul 2017, at 09:35, Pavel Krivanek >> > wrote:
>>> 
>>> If you want to stay with Pharo 6 image, you can try the bootstrapped 
>>> version of the 

Re: [Pharo-users] Problems verifying the cryptographic signature of a file.

[Esteban A. Maringolo]

How do check the signature of a file?

I guess you must ensure the file creation is complete as well as its
digital signing. So if these steps are done asynchronously you should
synchronize them by means of a semaphore or similar.

Regards!

Esteban A. Maringolo


2017-07-31 14:11 GMT-03:00 Offray Vladimir Luna Cárdenas
:
> Hi,
>
> I'm having problems to verify the cryptographic signature of a file. It
> seems that the test is running, some times, while the file is being created,
> and some times when the file writing is finished (which is my purpose). How
> can I run the cryptographic signature verification only after the writing of
> the file is finished? I imagine that is something related with jobs and
> completion, but I don't know where to look for, specifically.
>
> Any hints and suggestions are welcomed.
>
> Cheers,
>
> Offray

[Pharo-users] Problems verifying the cryptographic signature of a file.

[Offray Vladimir Luna Cárdenas]

Hi,

I'm having problems to verify the cryptographic signature of a file. It
seems that the test is running, some times, while the file is being
created, and some times when the file writing is finished (which is my
purpose). How can I run the cryptographic signature verification only
after the writing of the file is finished? I imagine that is something
related with jobs and completion, but I don't know where to look for,
specifically.

Any hints and suggestions are welcomed.

Cheers,

Offray

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[Guillermo Polito]

Also,
- How did you install pharo? Command line and zero conf? Website download
link?
- What does it mean to "freeze"?
- Do you have an exception? a PharoDebug.log file? a crash.dmp?

Can you try to open you image from the command line?

 $ Pharo.app/Contents/Pharo Pharo.image #I do not remember the exact path
to the vm executable...

like that you will be able to capture any exceptions from the terminal.

Alternatively, you can try to download pharo using zeroconf if you did not,
and you can try:

 $ pharo-ui Pharo.image

Guille

On Mon, Jul 31, 2017 at 4:58 PM, stephan  wrote:

> On 31-07-17 16:42, TedVanGaalen wrote:
>
>> I've just installed the 32bit version. same problems here. freezes
>>
>
> Where did you install what versions of vm and image on what OS X version?
>
> Stephan
>
>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Threads safety in Pharo

[Guillermo Polito]

I believe there is no such a document. It would be however interesting to
investigate it a bit deeper. In general, the problem we talk about when we
talk about thread safety is the following: Can we run a workspace in a
separate thread than a browser and provide correct results? Can we run two
browsers concurrently and change code from both of them?

The thread safety problem has several levels I'd say:

 - the kernel of the language (classes, methods, compilation, and so on)
cannot safely be modified while other threads are running. Thus, if we
compile a new version of a method in a thread, that could break a separate
thread that was using that method.

 - there are several libraries using global state. We should investigate if
they work correctly when using them concurrently.
E.g., source code management is not thread safe. This could cause a
source code corruption if several methods are modified concurrently.
Like that, we should investigate all libraries and see what should be
adapted and if there is a need at all.

 - in a third level, general core libraries (collections, networking,
files, etc) are not designed to be thread safe and that is natural. For
example, most of the time you don't want that your collection is accessed
concurrently. For such cases, some libraries could provide some
extensions/wrappers/whatsoever to provide some synchronization mechanism.
Otherwise it is the responsibility of the user to synchronize usages with
semaphores/mutexes.


On Mon, Jul 31, 2017 at 1:38 AM, Alidra Abdelghani via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Alidra Abdelghani 
> To: pharo-users@lists.pharo.org
> Cc: "Stéphane Ducasse" , farid arfi <
> arf...@hotmail.com>
> Bcc:
> Date: Mon, 31 Jul 2017 01:38:58 +0200
> Subject: Threads safety in Pharo
> Hi,
>
> Somebody once evoked the problem of threads safety in Pharo. With a friend
> of mine who is expert in formal methods and process scheduling, we would
> like to have a look on it.
> Does anyone knows a good document describing the problem of Pharo with
> threads safety or at least any document that we can start with?
>
> Thanks in advance,
> Abdelghani
>
>
>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[stephan]

On 31-07-17 16:42, TedVanGaalen wrote:

I've just installed the 32bit version. same problems here. freezes


Where did you install what versions of vm and image on what OS X version?

Stephan

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

I've just installed the 32bit version. same problems here. freezes



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4957982.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Iceberg: SCP urls are not limited to 'git@'

[Herby Vojčík]

I put this hotfix in my script:

"Work around scp url hardwired 'git@'"
IceScpRemote class compile: 'canHandleUrl: aRepositoryUrl
"Very simplistic implementation that does not cover all cases"
^ aRepositoryUrl matchesRegex: ''([\w.-]+@|ssh\://).*'''.
IceScpRemote compile: ((IceScpRemote >> #parseUrl) sourceCode 
copyReplaceAll: 'git@' with: '[\w.-]+@').


Is it ok for Iceberg devs to make those (or similar) changes into 
Iceberg code itself?


Herby

Herby Vojčík wrote:

Hello!

Once I finally added remote to my localgit repo, I cannot build my image
any more because Iceberg fails to parse the url. After first error I
tried ssh://, but it is protected as well.

The problem is, g...@host.site is just the way to say which user to log
in via ssh into the host. We use on-premise gogs installed via apt, and
it installs 'gogs' user, not 'git' user. As such, we were being able to
successfully use 'g...@our.site:org/towergame.git' type of remote URLs,
but Iceberg code has 'git@' hardcoded.

How to overcome this?

Herby

Re: [Pharo-users] Creating the smallest server runtime footprint

[Pavel Krivanek]

2017-07-31 15:28 GMT+02:00 Tim Mackinnon :

> Ok (I am reading there is a lot going on for you guys to sort out at the
> moment).
>
> It sounds like a more stable conversion of Pharo 6.1 for 64 bit would be
> best to give me a stable platform to run on.
>
> In that minimal image - what can I rely on to load code (in trying the 7.0
> version it seems like Gofer isn’t there, and I’m now wondering if Metacello
> isn’t there either) - so I’m wondering how you guys load baselinesOf of
> configurationsOf?
>

Try it again, there was a bug in the job configuration

.. Pavel


>
> Tim
>
> On 31 Jul 2017, at 14:17, Pavel Krivanek  wrote:
>
> H Tim
>
> 2017-07-31 15:07 GMT+02:00 Tim Mackinnon :
>
>> Hi Pavel - I’m just revisiting a few of your previous messages on minimal
>> images as I’m trying to get things working again with Pharo 6.1 now that
>> you guys have rejigged all of the build pipelines.
>>
>> I tried a previous suggestion of:
>>
>> For Pharo 6: https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-M
>> inimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip
>> For Pharo 7: https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit
>> -Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip
>>
>> However the Pharo 6 version is no longer being built, and it doesn’t seem
>> to work well with the newer 64bit vm (? I seem to get a load error that I
>> didn’t have before - although its possible that I’m loading a new pre-req
>> with metacello and this is tipping it over the edge).
>>
>> Anyway - a prev suggestion for 6.x from you was:
>>
>> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-
>> Step-04-01-ConfigurationOfMinimalPharo/
>>
>>
>> However this is a 32bit image. Is there an equivalent 64bit image for
>> 6.1?  OR should I use the Pharo 7 one for now (I guess the minimal image
>> will probably be pretty stable for a little while as I’m sure the action is
>> higher up the chain?)
>>
>
> You should use an image that is bootstrapped, so version from SysConf jobs
> or Pharo 7. For Pharo 7 we are preparing a lot of big changes in the kernel
> so do not expect it will be stable. We can do a conversion job of of it to
> 64-bit version as soon as the CI infrastructure will be on knees again.
>
> -- Pavel
>
>
>
>>
>> Tim
>>
>>
>> On 15 Jul 2017, at 09:35, Pavel Krivanek 
>> wrote:
>>
>> If you want to stay with Pharo 6 image, you can try the bootstrapped
>> version of the minimal image:
>> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-
>> Step-04-01-ConfigurationOfMinimalPharo/
>>
>> -- Pavel
>>
>> 2017-07-15 10:33 GMT+02:00 Pavel Krivanek :
>>
>>> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is
>>> already converting to 64bit). There should be no problem with STON because
>>> whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal
>>> image is done differently (by shrinking) and not so well tested.
>>>
>>> For the conversion of 32-bit image to 64-bit image you need a VMMaker
>>> image:
>>> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfu
>>> lBuild/artifact/vmmaker-image.zip
>>> and then evaluate:
>>> ./pharo generator.image eval "[Spur32to64BitBootstrap new
>>> bootstrapImage: 'conversion.image'] on: AssertionFailure do: [ :fail | fail
>>> resumeUnchecked: nil ]"
>>>
>>> -- Pavel
>>>
>>>
>>>
>>> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon :
>>>
 Hi Pavel - thanks for getting me to the point where I could even have a
 minimal image. As I’m on the edge of my Pharo knowledge here, I’ll try and
 run with this as best I can.

 I’d been using the 6.0 image you suggested to me - but maybe I could
 use a 70 image with Pharo 6 for a while (until the VM diverges) right?

 The bit I haven’t quite understood however, is how the 64bit image is
 created - as your reference is to a 32bit version? Is the 64bit one
 converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I
 right in thinking the pipeline stage after this one is the one you sent me
 - and the travis.yml file shows me what it does? But I can’t see a
 trivis.yml in the conversion stage so I’m not sure how it does that.
 (Question - how do I see what the pipelines do to answer my own questions?)

 I was hoping that there was a basic image that got me up to metacello
 baseline level to load git file tree packages/baselines  in my own repo as
 well baselines on the internet. The one you sent me is fairly close to that
 (its just missing STON in the image and seems to have an issue with
 resolving undeclared classes that get loaded in - should do a fogbugz on
 that?)

 The follow-on from a metacello image is how we can get people to create
 better baselines that give you more minimal loading options (e.g.
 conditionally leave out the test cases 

[Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[Ted F.A.van Gaalen]

Hi, I reverted to 5.0 because Pharo 6.0 and 6.1 64 bit hangs on 
my Mac Mini with UDH 4K screen (may that has to do with?)
with its maiden image (at first start after download
when:  I resize or go to full screen. Maybe VM problem?
my mac Mini metrics:
Hardware Overview:

  Model Name:   Mac mini
  Model Identifier: Macmini6,2
  Processor Name:   Intel Core i7
  Processor Speed:  2,6 GHz
  Number of Processors: 1
  Total Number of Cores:4
  L2 Cache (per Core):  256 KB
  L3 Cache: 6 MB
  Memory:   4 GB
  Boot ROM Version: MM61.0106.B1F
  SMC Version (system): 2.8f0

maybe this problem was already reported, but could find it. 


Kind Regards
TedvG
 
   

Re: [Pharo-users] Creating the smallest server runtime footprint

[Tim Mackinnon]

Ok (I am reading there is a lot going on for you guys to sort out at the 
moment).

It sounds like a more stable conversion of Pharo 6.1 for 64 bit would be best 
to give me a stable platform to run on.

In that minimal image - what can I rely on to load code (in trying the 7.0 
version it seems like Gofer isn’t there, and I’m now wondering if Metacello 
isn’t there either) - so I’m wondering how you guys load baselinesOf of 
configurationsOf?

Tim

> On 31 Jul 2017, at 14:17, Pavel Krivanek  wrote:
> 
> H Tim
> 
> 2017-07-31 15:07 GMT+02:00 Tim Mackinnon  >:
> Hi Pavel - I’m just revisiting a few of your previous messages on minimal 
> images as I’m trying to get things working again with Pharo 6.1 now that you 
> guys have rejigged all of the build pipelines.
> 
> I tried a previous suggestion of:
> 
> For Pharo 6: 
> https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip
>  
> 
> For Pharo 7: 
> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip
>  
> 
> 
> However the Pharo 6 version is no longer being built, and it doesn’t seem to 
> work well with the newer 64bit vm (? I seem to get a load error that I didn’t 
> have before - although its possible that I’m loading a new pre-req with 
> metacello and this is tipping it over the edge).
> 
> Anyway - a prev suggestion for 6.x from you was:
>> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-ConfigurationOfMinimalPharo/
>>  
>> 
> However this is a 32bit image. Is there an equivalent 64bit image for 6.1?  
> OR should I use the Pharo 7 one for now (I guess the minimal image will 
> probably be pretty stable for a little while as I’m sure the action is higher 
> up the chain?)
> 
> You should use an image that is bootstrapped, so version from SysConf jobs or 
> Pharo 7. For Pharo 7 we are preparing a lot of big changes in the kernel so 
> do not expect it will be stable. We can do a conversion job of of it to 
> 64-bit version as soon as the CI infrastructure will be on knees again.
> 
> -- Pavel
> 
>  
> 
> Tim
> 
> 
>> On 15 Jul 2017, at 09:35, Pavel Krivanek > > wrote:
>> 
>> If you want to stay with Pharo 6 image, you can try the bootstrapped version 
>> of the minimal image:
>> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-ConfigurationOfMinimalPharo/
>>  
>> 
>> 
>> -- Pavel
>> 
>> 2017-07-15 10:33 GMT+02:00 Pavel Krivanek > >:
>> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is 
>> already converting to 64bit). There should be no problem with STON because 
>> whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal 
>> image is done differently (by shrinking) and not so well tested.
>> 
>> For the conversion of 32-bit image to 64-bit image you need a VMMaker image:
>> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact/vmmaker-image.zip
>>  
>> 
>> and then evaluate:
>> ./pharo generator.image eval "[Spur32to64BitBootstrap new bootstrapImage: 
>> 'conversion.image'] on: AssertionFailure do: [ :fail | fail resumeUnchecked: 
>> nil ]"
>> 
>> -- Pavel
>> 
>> 
>> 
>> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon > >:
>> Hi Pavel - thanks for getting me to the point where I could even have a 
>> minimal image. As I’m on the edge of my Pharo knowledge here, I’ll try and 
>> run with this as best I can.
>> 
>> I’d been using the 6.0 image you suggested to me - but maybe I could use a 
>> 70 image with Pharo 6 for a while (until the VM diverges) right? 
>> 
>> The bit I haven’t quite understood however, is how the 64bit image is 
>> created - as your reference is to a 32bit version? Is the 64bit one 
>> converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I 
>> right in thinking the pipeline stage after this one is the one you sent me - 
>> and the travis.yml file shows me what it does? But I can’t see a trivis.yml 
>> in the conversion stage so I’m not sure how it does that. (Question - how do 
>> I see what the pipelines do to answer my own questions?)
>> 
>> I was hoping that there was a basic image that got me up to metacello 
>> baseline level to load git 

Re: [Pharo-users] Creating the smallest server runtime footprint

[Pavel Krivanek]

H Tim

2017-07-31 15:07 GMT+02:00 Tim Mackinnon :

> Hi Pavel - I’m just revisiting a few of your previous messages on minimal
> images as I’m trying to get things working again with Pharo 6.1 now that
> you guys have rejigged all of the build pipelines.
>
> I tried a previous suggestion of:
>
> For Pharo 6: https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-
> Minimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip
> For Pharo 7: https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-
> 32bit-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip
>
> However the Pharo 6 version is no longer being built, and it doesn’t seem
> to work well with the newer 64bit vm (? I seem to get a load error that I
> didn’t have before - although its possible that I’m loading a new pre-req
> with metacello and this is tipping it over the edge).
>
> Anyway - a prev suggestion for 6.x from you was:
>
> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-
> ConfigurationOfMinimalPharo/
>
>
> However this is a 32bit image. Is there an equivalent 64bit image for
> 6.1?  OR should I use the Pharo 7 one for now (I guess the minimal image
> will probably be pretty stable for a little while as I’m sure the action is
> higher up the chain?)
>

You should use an image that is bootstrapped, so version from SysConf jobs
or Pharo 7. For Pharo 7 we are preparing a lot of big changes in the kernel
so do not expect it will be stable. We can do a conversion job of of it to
64-bit version as soon as the CI infrastructure will be on knees again.

-- Pavel



>
> Tim
>
>
> On 15 Jul 2017, at 09:35, Pavel Krivanek  wrote:
>
> If you want to stay with Pharo 6 image, you can try the bootstrapped
> version of the minimal image:
> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-
> ConfigurationOfMinimalPharo/
>
> -- Pavel
>
> 2017-07-15 10:33 GMT+02:00 Pavel Krivanek :
>
>> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is
>> already converting to 64bit). There should be no problem with STON because
>> whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal
>> image is done differently (by shrinking) and not so well tested.
>>
>> For the conversion of 32-bit image to 64-bit image you need a VMMaker
>> image:
>> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfu
>> lBuild/artifact/vmmaker-image.zip
>> and then evaluate:
>> ./pharo generator.image eval "[Spur32to64BitBootstrap new bootstrapImage:
>> 'conversion.image'] on: AssertionFailure do: [ :fail | fail
>> resumeUnchecked: nil ]"
>>
>> -- Pavel
>>
>>
>>
>> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon :
>>
>>> Hi Pavel - thanks for getting me to the point where I could even have a
>>> minimal image. As I’m on the edge of my Pharo knowledge here, I’ll try and
>>> run with this as best I can.
>>>
>>> I’d been using the 6.0 image you suggested to me - but maybe I could use
>>> a 70 image with Pharo 6 for a while (until the VM diverges) right?
>>>
>>> The bit I haven’t quite understood however, is how the 64bit image is
>>> created - as your reference is to a 32bit version? Is the 64bit one
>>> converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I
>>> right in thinking the pipeline stage after this one is the one you sent me
>>> - and the travis.yml file shows me what it does? But I can’t see a
>>> trivis.yml in the conversion stage so I’m not sure how it does that.
>>> (Question - how do I see what the pipelines do to answer my own questions?)
>>>
>>> I was hoping that there was a basic image that got me up to metacello
>>> baseline level to load git file tree packages/baselines  in my own repo as
>>> well baselines on the internet. The one you sent me is fairly close to that
>>> (its just missing STON in the image and seems to have an issue with
>>> resolving undeclared classes that get loaded in - should do a fogbugz on
>>> that?)
>>>
>>> The follow-on from a metacello image is how we can get people to create
>>> better baselines that give you more minimal loading options (e.g.
>>> conditionally leave out the test cases perhaps)
>>>
>>> Tim
>>>
>>> On 15 Jul 2017, at 08:24, Pavel Krivanek 
>>> wrote:
>>>
>>> Hi Tim,
>>>
>>> you can base the your work on the bootstrapped image, see
>>> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/, file
>>> Pharo7.0-core-*.zip
>>>
>>> This image does not have a lot of basic components like Monticello or
>>> network but it has a compiler so the code can be imported as *.st files.
>>> Then we have Pharo7.0-monticello-*.zip which will be easier to use and
>>> probably can fit your needs. Monticello and network support are included.
>>> But you cannot use baselines nor configurations to load your code.
>>>
>>> -- Pavel
>>>
>>> 2017-07-14 9:59 GMT+02:00 Tim Mackinnon :
>>>
 Hi - buoyed by the success of a 

Re: [Pharo-users] Creating the smallest server runtime footprint

[Tim Mackinnon]

Hi Pavel - I’m just revisiting a few of your previous messages on minimal 
images as I’m trying to get things working again with Pharo 6.1 now that you 
guys have rejigged all of the build pipelines.

I tried a previous suggestion of:

For Pharo 6: 
https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip
 

For Pharo 7: 
https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip
 


However the Pharo 6 version is no longer being built, and it doesn’t seem to 
work well with the newer 64bit vm (? I seem to get a load error that I didn’t 
have before - although its possible that I’m loading a new pre-req with 
metacello and this is tipping it over the edge).

Anyway - a prev suggestion for 6.x from you was:
> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-ConfigurationOfMinimalPharo/
>  
> 
However this is a 32bit image. Is there an equivalent 64bit image for 6.1?  OR 
should I use the Pharo 7 one for now (I guess the minimal image will probably 
be pretty stable for a little while as I’m sure the action is higher up the 
chain?)

Tim


> On 15 Jul 2017, at 09:35, Pavel Krivanek  wrote:
> 
> If you want to stay with Pharo 6 image, you can try the bootstrapped version 
> of the minimal image:
> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-ConfigurationOfMinimalPharo/
>  
> 
> 
> -- Pavel
> 
> 2017-07-15 10:33 GMT+02:00 Pavel Krivanek  >:
> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is 
> already converting to 64bit). There should be no problem with STON because 
> whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal 
> image is done differently (by shrinking) and not so well tested.
> 
> For the conversion of 32-bit image to 64-bit image you need a VMMaker image:
> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact/vmmaker-image.zip
>  
> 
> and then evaluate:
> ./pharo generator.image eval "[Spur32to64BitBootstrap new bootstrapImage: 
> 'conversion.image'] on: AssertionFailure do: [ :fail | fail resumeUnchecked: 
> nil ]"
> 
> -- Pavel
> 
> 
> 
> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon  >:
> Hi Pavel - thanks for getting me to the point where I could even have a 
> minimal image. As I’m on the edge of my Pharo knowledge here, I’ll try and 
> run with this as best I can.
> 
> I’d been using the 6.0 image you suggested to me - but maybe I could use a 70 
> image with Pharo 6 for a while (until the VM diverges) right? 
> 
> The bit I haven’t quite understood however, is how the 64bit image is created 
> - as your reference is to a 32bit version? Is the 64bit one converted from 32 
> in a later stage? (For AWS Lambda I need 64bit) - am I right in thinking the 
> pipeline stage after this one is the one you sent me - and the travis.yml 
> file shows me what it does? But I can’t see a trivis.yml in the conversion 
> stage so I’m not sure how it does that. (Question - how do I see what the 
> pipelines do to answer my own questions?)
> 
> I was hoping that there was a basic image that got me up to metacello 
> baseline level to load git file tree packages/baselines  in my own repo as 
> well baselines on the internet. The one you sent me is fairly close to that 
> (its just missing STON in the image and seems to have an issue with resolving 
> undeclared classes that get loaded in - should do a fogbugz on that?)
> 
> The follow-on from a metacello image is how we can get people to create 
> better baselines that give you more minimal loading options (e.g. 
> conditionally leave out the test cases perhaps)
> 
> Tim
> 
>> On 15 Jul 2017, at 08:24, Pavel Krivanek > > wrote:
>> 
>> Hi Tim,
>> 
>> you can base the your work on the bootstrapped image, see 
>> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ 
>> , file 
>> Pharo7.0-core-*.zip 
>> 
>> This image does not have a lot of basic components like Monticello or 
>> network but it has a compiler so the code can be imported as *.st files. 
>> Then we have Pharo7.0-monticello-*.zip which will be easier to use and 
>> probably can fit your needs. Monticello 

Re: [Pharo-users] Iceberg and removing packages

[Esteban A. Maringolo]

Hi,

Yes, I commited.

I noticed the package wasn't remove from disk because in Github the
MyPackage-Tests.package folder was still there. And in the iceberg
local directory it was there as well.
I removed it manually with this commit:


Regards!

Esteban A. Maringolo


2017-07-31 9:30 GMT-03:00 Esteban Lorenzano :
> Did you commit?
>
>> On 31 Jul 2017, at 14:06, Esteban A. Maringolo  wrote:
>>
>> That's exactly what I did. But after synchronizing the repo, the
>> package wasn't listed on Iceberg but it still was in in the repo.
>> It happened with another package in another repo as well.
>>
>> If it happens again I'll let you know.

Re: [Pharo-users] Iceberg and removing packages

[Esteban Lorenzano]

Did you commit?

> On 31 Jul 2017, at 14:06, Esteban A. Maringolo  wrote:
> 
> That's exactly what I did. But after synchronizing the repo, the
> package wasn't listed on Iceberg but it still was in in the repo.
> It happened with another package in another repo as well.
> 
> If it happens again I'll let you know.
> 
> Regards!
> 
> Esteban A. Maringolo
> 
> 
> 2017-07-31 7:03 GMT-03:00 Esteban Lorenzano :
>> Hi,
>> 
>> In iceberg, you have to go to package tab and say "remove package from disk"
>> 
>> Esteban
>> 
>>> On 30 Jul 2017, at 17:01, Esteban A. Maringolo  wrote:
>>> 
>>> I got into the pharo-local/iceberg/... and git rm'ed the directory,
>>> commited and synchronized the project in Iceberg.
>>> 
>>> I hope it doesn't break anything since I don't know how much "magic"
>>> does Iceberg behind the scenes other than automating the git commands
>>> and providing a centralized UI.
>>> 
>>> What is the "This is all you need to read to understand Iceberg?"
>>> document I should read? I read its wiki, but it seems there is more to
>>> go.
>>> 
>>> Regards!
>>> 
>>> Esteban A. Maringolo
>>> 
>>> 
>>> 2017-07-30 11:28 GMT-03:00 Peter Uhnak :
 This was supposedly fixed in April 
 https://github.com/pharo-vcs/iceberg/issues/317
 
 however I had the same issue ~two months ago, so I had to delete the 
 packages by hand.
 
 P
 
 
> On Sun, Jul 30, 2017 at 11:04:20AM -0300, Esteban A. Maringolo wrote:
> Hi,
> 
> I'm playing around with Iceberg in Pharo 6, and even when I find the
> workflow streamlined, but since it doesn't map 1:1 with git workflow
> from other IDEs or command line, I find myself not knowing how to do
> certain tasks.
> 
> One thing that happened is that I published a few packages to one of
> my repos in Github, then I decided to remove one of the packages from
> the repo, then I synchronized it but in the repo there is still is the
> package folder for the package I removed.
> 
> What should I do to definitely remove those files from the commit?
> 
> Regards!
> 
> Esteban A. Maringolo
> 
 
>>> 
>> 
> 

Re: [Pharo-users] Iceberg and removing packages

[Esteban A. Maringolo]

That's exactly what I did. But after synchronizing the repo, the
package wasn't listed on Iceberg but it still was in in the repo.
It happened with another package in another repo as well.

If it happens again I'll let you know.

Regards!

Esteban A. Maringolo


2017-07-31 7:03 GMT-03:00 Esteban Lorenzano :
> Hi,
>
> In iceberg, you have to go to package tab and say "remove package from disk"
>
> Esteban
>
>> On 30 Jul 2017, at 17:01, Esteban A. Maringolo  wrote:
>>
>> I got into the pharo-local/iceberg/... and git rm'ed the directory,
>> commited and synchronized the project in Iceberg.
>>
>> I hope it doesn't break anything since I don't know how much "magic"
>> does Iceberg behind the scenes other than automating the git commands
>> and providing a centralized UI.
>>
>> What is the "This is all you need to read to understand Iceberg?"
>> document I should read? I read its wiki, but it seems there is more to
>> go.
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>>
>> 2017-07-30 11:28 GMT-03:00 Peter Uhnak :
>>> This was supposedly fixed in April 
>>> https://github.com/pharo-vcs/iceberg/issues/317
>>>
>>> however I had the same issue ~two months ago, so I had to delete the 
>>> packages by hand.
>>>
>>> P
>>>
>>>
 On Sun, Jul 30, 2017 at 11:04:20AM -0300, Esteban A. Maringolo wrote:
 Hi,

 I'm playing around with Iceberg in Pharo 6, and even when I find the
 workflow streamlined, but since it doesn't map 1:1 with git workflow
 from other IDEs or command line, I find myself not knowing how to do
 certain tasks.

 One thing that happened is that I published a few packages to one of
 my repos in Github, then I decided to remove one of the packages from
 the repo, then I synchronized it but in the repo there is still is the
 package folder for the package I removed.

 What should I do to definitely remove those files from the commit?

 Regards!

 Esteban A. Maringolo

>>>
>>
>

Re: [Pharo-users] Zinc Crash / semaphores

[p...@highoctane.be]

I am doing external REST calls indeed.

No caching across WASessions.

Phil

On Mon, Jul 31, 2017 at 1:00 PM, Sven Van Caekenberghe  wrote:

> Do you make any external (REST/network) calls yourself while handling your
> requests ?
>
> Do you do any kind of caching yourself ?
>
> > On 31 Jul 2017, at 12:40, p...@highoctane.be wrote:
> >
> > I have this crash log on a server.
> >
> > https://gist.github.com/philippeback/9527b74c081629c2b05466353c4326b3
> >
> > It is running on Windows 2012 R2 with a Pharo 5.0
> > There is a SeasideApp.
> >
> > Is there any known semaphore leak?
> >
> > Because this app is very lightly used and I was suprised to see this.
> >
> > Windows may be the cause but never had such an issue in the environment.
> >
> > TIA
> > Phil
>
>
>
>

Re: [Pharo-users] Zinc Crash / semaphores

[Sven Van Caekenberghe]

Do you make any external (REST/network) calls yourself while handling your 
requests ?

Do you do any kind of caching yourself ?

> On 31 Jul 2017, at 12:40, p...@highoctane.be wrote:
> 
> I have this crash log on a server.
> 
> https://gist.github.com/philippeback/9527b74c081629c2b05466353c4326b3
> 
> It is running on Windows 2012 R2 with a Pharo 5.0
> There is a SeasideApp.
> 
> Is there any known semaphore leak?
> 
> Because this app is very lightly used and I was suprised to see this. 
> 
> Windows may be the cause but never had such an issue in the environment.
> 
> TIA
> Phil

[Pharo-users] Zinc Crash / semaphores

[p...@highoctane.be]

I have this crash log on a server.

https://gist.github.com/philippeback/9527b74c081629c2b05466353c4326b3

It is running on Windows 2012 R2 with a Pharo 5.0
There is a SeasideApp.

Is there any known semaphore leak?

Because this app is very lightly used and I was suprised to see this.

Windows may be the cause but never had such an issue in the environment.

TIA
Phil

Re: [Pharo-users] Iceberg and removing packages

[Esteban Lorenzano]

Hi,

In iceberg, you have to go to package tab and say "remove package from disk"

Esteban 

> On 30 Jul 2017, at 17:01, Esteban A. Maringolo  wrote:
> 
> I got into the pharo-local/iceberg/... and git rm'ed the directory,
> commited and synchronized the project in Iceberg.
> 
> I hope it doesn't break anything since I don't know how much "magic"
> does Iceberg behind the scenes other than automating the git commands
> and providing a centralized UI.
> 
> What is the "This is all you need to read to understand Iceberg?"
> document I should read? I read its wiki, but it seems there is more to
> go.
> 
> Regards!
> 
> Esteban A. Maringolo
> 
> 
> 2017-07-30 11:28 GMT-03:00 Peter Uhnak :
>> This was supposedly fixed in April 
>> https://github.com/pharo-vcs/iceberg/issues/317
>> 
>> however I had the same issue ~two months ago, so I had to delete the 
>> packages by hand.
>> 
>> P
>> 
>> 
>>> On Sun, Jul 30, 2017 at 11:04:20AM -0300, Esteban A. Maringolo wrote:
>>> Hi,
>>> 
>>> I'm playing around with Iceberg in Pharo 6, and even when I find the
>>> workflow streamlined, but since it doesn't map 1:1 with git workflow
>>> from other IDEs or command line, I find myself not knowing how to do
>>> certain tasks.
>>> 
>>> One thing that happened is that I published a few packages to one of
>>> my repos in Github, then I decided to remove one of the packages from
>>> the repo, then I synchronized it but in the repo there is still is the
>>> package folder for the package I removed.
>>> 
>>> What should I do to definitely remove those files from the commit?
>>> 
>>> Regards!
>>> 
>>> Esteban A. Maringolo
>>> 
>> 
> 

Re: [Pharo-users] Performance of zero conf install since 6.1 seems very slow?

[Guillermo Polito]

I think it's the entire file server. The thing, i think, is that the VM is
much smaller than the image or the sources to download.

On Mon, Jul 31, 2017 at 2:26 AM, Tim Mackinnon  wrote:

> Actually its all over the place - the times vary from seconds (like it
> used to work) to 5-10 mins. It’s not very reliable - so. I hope it can be
> fixed (although it does seem that the image download is usually the one
> I’ve noticed to slow down dramatically). I’m still trying to sort out some
> caching on my end to hopefully lessen the impact of this down stream where
> my CI lives.
>
> Tim
>
> On 31 Jul 2017, at 00:12, Tim Mackinnon  wrote:
>
> I’m still seeing very slow download response times - so I’ve started to
> work on better caching Inria downloads in my build script - however in
> doing this, I notice that its not the VM that takes time to download (its
> as quick as always) its the image? e.g. (http://files.pharo.org/
> get-files/61/pharo64.zip)
>
> Why would this file take so much longer than than the vm? (As in minutes
> vs. Seconds)
>
> Tim
>
> On 26 Jul 2017, at 12:59, Tim Mackinnon  wrote:
>
> Yes I see the same - it was seconds and now minutes.
>
> Maybe it is worth having a mirror for CI (or does it get edge cached
> anyway- probably not from what we are seeing, but possibly if could be?)
>
> Tim
>
> Sent from my iPhone
>
> On 26 Jul 2017, at 09:17, Esteban Lorenzano  wrote:
>
> it may been related to recent INRIA infrastructure changes.
> there is nothing 6.1 itself can do with that (6.1 is just a bunch of zips)
>
> Esteban
>
> On 26 Jul 2017, at 09:44, Guillermo Polito 
> wrote:
>
> We were also seeing it yesterday. In travis, 10m to download an image (and
> thus timeout). Before it took seconds.
>
> On Wed, Jul 26, 2017 at 9:41 AM, Denis Kudriashov 
> wrote:
>
>> Hi.
>>
>> I don't know answer. But what time it takes before?
>>
>> 2017-07-26 9:30 GMT+02:00 Tim Mackinnon :
>>
>>> Hi - has anyone else noticed that since 6.1 - using zero conf for
>>> installs is very very slow (it takes minutes to download pharo64.zip when
>>> using
>>>
>>> curl get.pharo.org/64/ | bash
>>>
>>>
>>> This is both on my local computer but also on the gitlab ci server? Is
>>> it possibly something isn’t configured right?
>>>
>>> Tim
>>>
>>
>>
>
>
> --
>
> Guille Polito
>
> Research Engineer
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
> *Web:* *http://guillep.github.io* 
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>
>
>
>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] How to export critics from Critic Browser?

[Hernán Morales Durand]

It looks super cool.
Thank you Peter!

Hernán


2017-07-31 4:07 GMT-03:00 Peter Uhnak :
> Hi,
>
> I did a small experiment on Travis short while ago that collects the QAs and 
> prints them to output log.
>
> Script (you would be interested only in the Smalltalk part of the code): 
> https://github.com/peteruhnak/ugly-pharo-code/blob/master/qa-testing.sh
>
> Travis output (expand line 400): 
> https://travis-ci.org/peteruhnak/ugly-pharo-code#L400
>
> Peter
>
> On Mon, Jul 31, 2017 at 01:38:31AM -0300, Hernán Morales Durand wrote:
>> Hi,
>>
>> I'm using Pharo 6.1 and I want to export a report of Critics Browser results.
>> Is there a way to save the results?
>>
>> It would be nice to have a CSV, to record historical analysis of my
>> progress, then plot using Roassal, etc.
>>
>> Cheers,
>>
>> Hernán
>>
>

Re: [Pharo-users] How to export critics from Critic Browser?

[Peter Uhnak]

Hi,

I did a small experiment on Travis short while ago that collects the QAs and 
prints them to output log.

Script (you would be interested only in the Smalltalk part of the code): 
https://github.com/peteruhnak/ugly-pharo-code/blob/master/qa-testing.sh

Travis output (expand line 400): 
https://travis-ci.org/peteruhnak/ugly-pharo-code#L400

Peter

On Mon, Jul 31, 2017 at 01:38:31AM -0300, Hernán Morales Durand wrote:
> Hi,
> 
> I'm using Pharo 6.1 and I want to export a report of Critics Browser results.
> Is there a way to save the results?
> 
> It would be nice to have a CSV, to record historical analysis of my
> progress, then plot using Roassal, etc.
> 
> Cheers,
> 
> Hernán
>