from:"Christophe Demarey"

Hi Mariano,

> Le 27 nov. 2017 à 03:08, Mariano Martinez Peck  a 
> écrit :
> 
> Hi guys,
> 
> Thank you Christophe for continue pushing this useful tool!
> 
> One small request which might be easy to do... Quite frequently I want to do 
> something and re-save an image I have previosuly saved as a custom template 
> (under Local root tree). Right now what I have to do so:
> 
> 1) Make a new image from that template
> 2) remove template
> 2) do the thing and save the opened image.
> 3) go back to laucher and save that image as a new template (with the same 
> name of the one I deleted)
> 4) delete the created image
> 
> All that would be simplified if I could also launch my local templates. Is 
> there any reason why is that not allowed? (at least for Local tree).

I needed to get a bit into the code to see what is done.
In PharoLauncher, when you download a template from the we, the template is 
stored in a folder (e.g. /Users/john/Library/Preferences/pharo/templateCache/) 
as well as some metadata for it.
PhLLocalTemplate class is used to build a list of locally available templates 
from the metadata file store in this folder.
As this folder is intended to be a cache, that’s why you cannot run it 
directly. You first need to unzip the template, create its metadata file.

Maybe an action on images: « create template from image and delete image » 
would help you (if it allows overriding of an existing template)?
You also have a « recreate » action on images able to recreate the image from 
the specified origin template.

Christophe

Re: [Pharo-dev] I love the launcher!!!!

Hi,


> Le 25 nov. 2017 à 21:45, Volkert  a écrit :
> 
> The PharoLauncher is really nice ...
> 
> Is it possible to use a 64Bit VM run an Image (6.1 >)? Per default a
> 32bit VM is downloaded.

Yes, Pharo Launcher manages 32-bits and 64-bits VM. 
(https://github.com/pharo-project/pharo-launcher/issues/35)
Maybe you do not have the latest version?

Re: [Pharo-dev] I love the launcher!!!!


> Le 25 nov. 2017 à 20:08, Sean P. DeNigris  a écrit :
> 
> bpi wrote
>> UndefinedObject(Object)>>doesNotUnderstand: #,
>> PhLVirtualMachineManager>>vmFileName
> 
> I usually get an error that looks like that when I try to launch a pre
> Pharo-5 image. IIUC when Launcher is determining which VM to use…

It probably means that the command used to determine the image version failed!
Could you reproduce with the latest version? If so, please open an issue and a 
way to reproduce.

Thanks,
Christophe

Re: [Pharo-dev] I love the launcher!!!!

Hi Bernhard,

> Le 25 nov. 2017 à 16:24, Bernhard Pieber  a écrit :
> 
> Hi Stef,
> 
> I just found download links on this page:
> https://github.com/pharo-project/pharo-launcher
> They point to Jenkins build artefacts.
> 
> Thank you for implementing the launcher. As a newbie I ran into some 
> questions:
> 
> I guess the launcher is not self-updating, right?

right.

> If not, how can I find out if I already have the latest version?

There is no way for now: 
https://github.com/pharo-project/pharo-launcher/issues/23
What you can do is to open Monticello and see if you have latest versions of 
the Launcher packages.

Latest version is available at:
http://files.pharo.org/platform/launcher/Pharo_1.0.1.dmg (os X)
http://files.pharo.org/platform/launcher/Pharo-linux-1.0.1.zip (linux)
http://files.pharo.org/platform/launcher/pharo_installer-1.0.1.exe (win)

> I don’t really understand what Local means. Is there a difference between 
> Local > Pharo 6.1 (stable) and Official distributions > Pharo 6.1 (stable)?

Local category lists templates you have on your machine.

> And what is the difference between Local > Pharo6.1 (stable) and Local > 
> latest? Hmm, when I launched Local > latest I got a debugger[1].

Probably you downloaded an image called Latest with the Launcher. It then has 
been added to the local category.

> What also bothers me is that I cannot switch to the white theme in the 
> settings. I just can’t read the UI on the dark theme.

We could add these setting easily. Could you open an issue ? 
https://github.com/pharo-project/pharo-launcher/issues


Regards,
Christophe.

Re: [Pharo-dev] I love the launcher!!!!

2017-11-29 Thread Christophe Demarey


> Le 28 nov. 2017 à 21:53, Volkert <volk...@komponentenwerkstatt.de> a écrit :
> 
> 
> 
> On 28.11.2017 17:33, Christophe Demarey wrote:
>> Hi,
>> 
>> 
>>> Le 25 nov. 2017 à 21:45, Volkert <volk...@komponentenwerkstatt.de> a écrit :
>>> 
>>> The PharoLauncher is really nice ...
>>> 
>>> Is it possible to use a 64Bit VM run an Image (6.1 >)? Per default a
>>> 32bit VM is downloaded.
>> Yes, Pharo Launcher manages 32-bits and 64-bits VM. 
>> (https://github.com/pharo-project/pharo-launcher/issues/35)
>> Maybe you do not have the latest version?
> i use PharoLauncher-user-stable-2017.11.24.
> 
> How do i choose the 64-bit image? In ~/Pharo/vms if find only xx-x86 vms

You can choose, from Pharo 6.0 templates group, latest-64 by example. Pharo 
Launcher will then download a 64-bits vm to run this image

Re: [Pharo-dev] I love the launcher!!!!

2017-11-29 Thread Christophe Demarey

Hi Torsten,

I think I have a fix for your problem. I opened an issue fot it: 
https://github.com/pharo-project/pharo-launcher/issues/55.
Could you confirm if it is ok now?

> Le 28 nov. 2017 à 20:11, Torsten Bergmann  a écrit :
> 
> Hi,
> 
> Launcher is a power tool and has helped many of us so far. Thanks to all who 
> helped moving 
> it forward, especially Christophe who is currently caring a lot.
> 
> Unfortunately one primary issue is not yet solved:
> 
> The downloadable files for Pharo 7 are not correctly displayed (see 
> Screenshot attached). 
> 
> I guess this is because the image file names have changed (initially the 
> build process was set up 
> to include the git hash but now we also have the build number returned again, 
> see [1])
> 
> So with the current Launcher one can not directly load a specific build 
> number for Pharo 7 or see which
> build number is the latest available. So for Pharo 7 it is usable to download 
> "latest", "latest-32"
> or "latest-64" but it is not possible to really distinguish all the 
> "Pharorpackage-7" entries.
> 
> It would be really a step forward if this could be fixed somehow and also for 
> Pharo 7 display the
> image build number to make Launcher usable also for contributors to Pharo 7 
> again.
> 
> Thanks
> T.
> 
> [1] 
> http://forum.world.st/SystemVersion-cleanup-or-the-return-of-the-explicit-build-number-in-latest-Pharo-7-td4977073.html

Re: [Pharo-dev] I love the launcher!!!!

2017-11-29 Thread Christophe Demarey


> Le 29 nov. 2017 à 00:52, Sean P. DeNigris  a écrit :
> 
> demarey wrote
>>> pre Pharo-5 image
>> It probably means that the command used to determine the image version
>> failed!
> 
> Oh, are Pharo 4 and prior supposed to work? I figured they were just not
> intended to be supported

Yes, I'm able to run pharo 1.4 images.
Maybe it could be related to this bug:  
https://github.com/pharo-project/pharo-launcher/issues/52

Re: [Pharo-dev] I love the launcher!!!!

2017-11-30 Thread Christophe Demarey

Hi Eduardo,

Sadly, as far as I know, PPA are outdated, at least for pharo-launcher.
That’s why it does not work. You have an old version using an old VM unable to 
open recent images.
you should use http://files.pharo.org/platform/launcher/Pharo-linux-1.0.1.zip 
 for now.

Christophe

> Le 30 nov. 2017 à 00:25, Eduardo de Oliveira Padoan 
>  a écrit :
> 
> I liked the launcher a lot, but It took me a while to get a version working 
> out-of-the-box on Ubuntu.
> 
> It's not available with the VM on the /download page for Linux. My preferred 
> choice would be the PPA anyway, as I like to keep stuff under APT control, 
> but I had to dig a lot to find a sources.list entry combination that worked: 
> not all packages are available on all repositories, and some old repos have 
> invalid crypto signatures. In the end, what worked was:
> 
> - Xenial AND Trusty
> deb http://ppa.launchpad.net/pharo/stable/ubuntu 
>  xenial main 
> deb http://ppa.launchpad.net/pharo/stable/ubuntu 
>  trusty main
> deb-src http://ppa.launchpad.net/pharo/stable/ubuntu 
>  xenial main 
> deb-src http://ppa.launchpad.net/pharo/stable/ubuntu 
>  trusty main
> 
> - Disabled signatures checking (at my own risk):
> sudo apt -o Acquire::AllowInsecureRepositories=true \
>  -o 
> Acquire::AllowDowngradeToInsecureRepositories=true \
>  update
> - Finally:
> sudo apt install pharo-vm-core pharo-launcher 
> 
> But if I try to load a Pharo 5.0 image (created from the launcher's list, 
> marked as beta), I get this on the terminal:
> 
> "This interpreter (vers. 6505) cannot read image file (vers. 6521)."
> 
> Pharo 4.0 is the most recent on that list that works, at least that I could 
> find -- there are too many branches under Pharo Jenkins for instance, and I 
> couldn't find a suitable image there.
> 
> 
> Att,
> 
> On Wed, Nov 29, 2017 at 5:13 PM Sean P. DeNigris  > wrote:
> demarey wrote
> > Maybe it could be related to this bug:
> > https://github.com/pharo-project/pharo-launcher/issues/52 
> > 
> 
> It is a different bug in the same behavior.
> 
> The easy workaround is to manually create a pharo.version file for the
> offending image.
> 
> As to the bug…
> 
> The immediate problem turned out to be that I had a startup error in certain
> images due to a startup script that only worked in more recent Pharo
> versions. So, suggestion #1: check that pharo.version has actually been
> created, and if not produce a better error message. Also, ideally there
> should probably also be a timeout in determining the image version because
> sometimes the process returns without creating the file and other times it
> doesn't return at all.
> 
> However, even after disabling the startup scripts, I was only able to
> generate pharo.version by replacing
> "~/Documents/Pharo/vms/private/6505/Pharo.app" with
> "~/Documents/Pharo/vms/30-x86/Pharo.app", so there does also seem to be
> something fishy with the 6505 VM
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html 
> 
>

Re: [Pharo-dev] Failing tests in #development

2017-12-19 Thread Christophe Demarey


> Le 19 déc. 2017 à 10:50, Esteban Lorenzano  a écrit :
> 
> but this is because we still need to stabilise the CI: what happens now is 
> that we know some tests are failing randomly then we do not trust the CI to 
> tell us everything is ok. 
> Then we accept PRs in red state. 
> Of course, this will fail eventually, and that’s what we are seeing.
> 
> Most important thing, IMO is to fix the CI: those  tests that fails randomly 
> (I think most of them are networking problems) needs to be fixed or removed. 

I think we should not rely on external services for our tests.
We should mock every network service call to have a local version (still using 
the network). Then, you will not have failing tests because of timeout or 
network problem.
With Zinc or Teapot it’s quite easy to set up a network service on a local port 
of the machine running tests.

Re: [Pharo-dev] How to update currently used VM for PharoLauncher?

2017-11-04 Thread Christophe Demarey

Hi Stefan,

> Le 3 nov. 2017 à 17:23, stephan  a écrit :
> 
> I've noticed a few VM updates I want to use with PharoLauncher.
> What is the currently recommended way to update my PharoLauncher to use
> a non-stable version?

For now, the way to get a fresh VM for the current development image (i.e. 70) 
is to delete it from the VM store ($HOME/Documents/Pharo/vms/70 on OS X) and 
try to run again the image will download the latest stable VM.
If you need another VM, you will have to install it by hand in the same 
directory. There is currently no option to get an alpha VM. It makes sense only 
for the development image but it could be a nice option to add to the launcher. 
Do you think it will be used?

Christophe

Re: [Pharo-dev] Pharo Launcher endless loop opening debuggers in Pharo 6.1

2017-12-04 Thread Christophe Demarey

Hi,

I cannot reproduce this bug.
Do you have the log or the stack trace?

> Le 2 déc. 2017 à 14:51, Bernhard Pieber  a écrit :
> 
> I ran into an annoying problem using the latest Pharo 6.1 (stable) from Pharo 
> Launcher. I am on macOS Sierra Version 10.12.6.
> 
> Steps to reproduce:
> 1. Open Pharo Launcher
> 2. Create new Pharo 6.1 (stable) image from the official distributions, named 
> Test
> 3. Launch the Test image
> 4. Open a File Browser
> 5. Right click on the selected Test directory in the left file tree pane.
> 6. Debuggers start opening on KeyNotFound: key #arg4 not found in Dictionary
> 7. Image hangs
> 
> Interestingly the problem does not happen if I create the image using „curl 
> get.pharo.org | bash“ and start it with „./pharo-ui Pharo.image“ although 
> About Pharo shows the same information:
> Pharo 6.0
> Latest update: #60523
> 
> Can someone please confirm the bug?
> 
> Bernhard

Re: [Pharo-dev] SessionManager Questions

2018-06-19 Thread Christophe Demarey

Hi Sean,

> Le 17 juin 2018 à 20:20, Sean P. DeNigris  a écrit :
> 
> What is the SessionManager equivalent to `Smalltalk addToStartupList: self
> after: AnotherClass`?
> To do it manually, I don't see an easy way to query the priority/category of
> AnotherClass(edited)

SessionManager was designed to avoid dependencies between classes / packages 
that have nothing in common.
The best way is to find the best category to register your class in but in some 
cases, it s not enough.
ex: you rely on a class registered in user category but you need that another 
class startup happens after.
In this case, you need to use priorities. You can check dependent class 
category by inspection the session category but, indeed, there is no way to 
query the priority/category of a registered handler. It was not needed until 
now.
Do you need to compute the priority dynamically? What is the use case?

> Also, it seems that "higher" priority in SessionManager means a lower
> number! This seems opposite of both logic and precedent (see Process), no?

You’re right. It simplifies sorting but indeed is counter-intuitive.
Changing that now will probably break things for people relying on the current 
behavior.

Cheers,
Christophe

Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

2018-06-19 Thread Christophe Demarey

Hi Norbert,

> Le 19 juin 2018 à 14:06, Norbert Hartl  a écrit :
> 
> I have no use for an environment where people only care about coding new cool 
> stuff. If it would be like this I would quit all my pharo businesses, move to 
> mainstream and would use pharo only for hobbyist projects because that would 
> be the level that can be met.

I do not think Guille has this state of mind. He spends time to write lot of 
tests for code other people wrote (not the funniest part), to clean code in the 
image (old code, bad dependencies, better API), to improve existing stuff, 
answering questions on the ML, and so on.
He is one of the few people that really tries to push semantic versioning. He 
could have made some errors (like everyone) but I find your sentence not fair 
for him.

Regards,
Christophe

[Pharo-dev] [ANN] Pharo Launcher v1.2 release

2018-06-19 Thread Christophe Demarey

Hi all,

I just released PharoLauncher 1.2. It includes a new windows installer that you 
can use without administrator privileges as well as binary signing for OS X and 
Windows. Also, Pharo Launcher is not anymore identified as ‘Pharo’ application 
and comes with its own icon.

Here is the changelog (details on 
https://github.com/pharo-project/pharo-launcher/issues 
):
New features:
#21 Bless the DMG
#46 sign pharo launcher app for windows
#103 No way to rename a local template
#107 Unable to add a description for the image using the Launcher UI
#121 You can't see/sort images by last modified date
Improvements:
#69 Import command should also import pharo-local directory
#70 Import command should delete origin folder if empty
#73 Managers of Download of VMs and images should be in their own 
packages
#76 Use https instead of http to requests the pharo file server
#82 Official Distributions loads 32bit versions on 64bit System (i.e. 
provide better information on templates architecture)
#86 Sort Existing Images Case-Insensitive
#98 Copy and subfolders problem (contents no copied)
#101 Templates from a local image are listed in "downloaded". "local" 
would be a better name
#102 Template Cleared at Startup setting is enabled, making it weird 
when trying to use the template feature
#106 Import could work if we select the parent folder of an image
#109 Use latest pre-Spur VM to determine the image version
#122 The Run without settings icon looks like a funny grey/which blob 
(missing alpha correction)
Bux fixes:
#41 #selectedMorphList was sent to nil
#67 bash is not a command usable under windows
#68 Does not launch images on Windows
#85 Double click on an existing image open a file selector
#88 Pharo Launcher on Windows > Failing
#104 GUI bug makes Launcher unusable
#110 Image launch not reliable on Windows
#119 MessageNotUnderstood exception on launch
#123 The status bar of the Launcher is broken, so can't easily show 
image descriptions 


Big thanks to all contributors: code, issues report, comments, advices.

You can get platform bundles from pharo download page or files.pharo.org 
: http://files.pharo.org/pharo-launcher/1.2/ 

Regards,
Christophe.

Re: [Pharo-dev] Launcher 1.2 External Processes Hang

2018-06-27 Thread Christophe Demarey

Hi Sean,

Thanks for the report.

> Le 24 juin 2018 à 14:58, Sean P. DeNigris  a écrit :
> 
> Sean P. DeNigris wrote
>> I tried to launch an image with Launcher 1.2. "Determining image version"
>> appeared, but the image didn't not launch. 
> 
> Fixed with `ThisOSProcess initialize`. Not sure why that was needed, but…

Strange indeed.
Did the hang only happened after a fresh install?
Could it be related to 
https://github.com/pharo-project/pharo-launcher/issues/78?

Re: [Pharo-dev] Hello, Im and a litle confused. Can you help me get started please?

2018-01-11 Thread Christophe Demarey

Hi,


> Le 11 janv. 2018 à 11:35, Photon  a écrit :
> 
> oh yes I allready started with the book as I decided that it looked the most
> usefull and complete of the available material online. I did not know that
> you wrote it. TDD is a fun topic aswell. 
> I have a little question tho. Am I supossed to know all the answers in
> Chapter 3 challenges? Should I redo chapter 1-2 untill I know all the
> answers?

I think you should be able to answer most questions of the chapter 3 before 
going further.
Be able to identify messages, literals and evaluating basic expressions is 
really important. If you only miss a few answers, it is not a big deal. They 
will come with experience.
My advice would be to not only re-read the book but use Pharo playground / 
inspector in the same time to try the examples and find out similar ones.

Regards,
Christophe

[Pharo-dev] [ANN] PharoLauncher v1.1 released!

2018-01-16 Thread Christophe Demarey

Hi all,

I just released PharoLauncher 1.1. There are now 64-bits versions for Mac and 
Linux. Jenkins build is now managed through a Jenkins file.

Here is the changelog (details on 
https://github.com/pharo-project/pharo-launcher/issues):
New features:
#66 new command: import an image into the launcher default image folder 
#65 new command: remove a template from "Downloaded templates"
#64 new command: create a local template from an image and remove the 
image
#57 new option: run an image from a login shell to inherit from shell 
startup scripts to set up environment variables.
#54 It is now possible to run an image anywhere on your file system if 
you click "launch" and no image is selected
#23 Pharo Launcher now has an "about" box giving its description, 
version and a link to the bug tracker.
Improvements:
#62 Pharo Launcher should not load default Pharo settings 
#51 Pharo Launcher now sets the current directory to the directory 
containing the image (was the VM directory). Avoid confusions in Pharo 7 images.
Bux fixes:
#60 hardReset option causes troubles to PharoLauncher 
#56 #, was sent to nil
#55 Display name of Pharo 7 images unusable 
#52 Cannot open a Pharo 2 image
#47 Cannot run pharo 50 pre-Spur images

You can get platform bundles from files.pharo.org : 
http://files.pharo.org/pharo-launcher/1.1/

Regards,
Christophe.

Re: [Pharo-dev] Iceberg UI feedback - synchronise v. status

2018-01-29 Thread Christophe Demarey


> Le 29 janv. 2018 à 14:16, Ben Coman  a écrit :
> 
> I hear Iceberg UI is getting a redesign.
> To feed into that... I'm trying to analyse myself, why I've not been
> comfortable with the "Synchronise..." menu item.   I think maybe its
> because that term feels like an "action" that going to "do something"
> when I'm not sure what that something is.But as I'm getting
> familiar with Iceberg it seems that "Synchronise" might not change the
> state of anything, but first shows current "status" like a combination
> of  `git status` and `git diff`  from the shell, and presents buttons
> and tabs where you *then* perform actions that actually change the
> state of the system.
> 
> So I may have the wrong end of the stick, but perhaps replacing
> "Synchronise..." with "Status..." might seem less intimidating.

Why not « Synchronization view » like in Eclipse?

Re: [Pharo-dev] [Launcher][Win]Cannot download the VM from Pharo

2018-02-01 Thread Christophe Demarey

Hi Vincent,

If I understand well, it is not a Launcher issue. If so, you should rename the 
thread subject so that people having knowledge about network issues can answer.

Could you give try with a concrete example with wget / curl or an equivalent on 
windows 
(https://superuser.com/questions/362152/native-alternative-to-wget-in-windows-powershell
 and post the result?
Could it  be a problem with your company proxy or firewall?
If it works with Firefox, it probably means it does something more (or 
different) than others.


> Le 1 févr. 2018 à 09:33, Vincent BLONDEAU 
>  a écrit :
> 
> This issue is still there….
>  
> At work, I can download the zip properly with Firefox, but not with Chrome, 
> IE, Pharo, and VisualWorks.
> When I use another connection than the one behind the company firewall, it 
> works.
> I tried on the laptop of one of my colleagues: same issue…
>  
> By analyzing the HTTP packets with Wireshark, a Reset of the connection is 
> send by the server, I don’t know why…
> I really don’t know how to solve or reproduce this issue. Has someone an idea?
>  
> Thanks, 
>  
>  
> Vincent
>  
>  
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
> vincent.blond...@lamresearch.com
> Sent: mercredi 24 janvier 2018 09:11
> To: pharo-dev@lists.pharo.org
> Subject: Re: [Pharo-dev] [Launcher][Win]Cannot download the VM from Pharo
>  
> Hi,
>  
> I think that is not related… I have this problem since last week and it is 
> still there today.
>  
> Vincent
>  
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org 
> ] On Behalf Of Marcus Denker
> Sent: Wednesday, January 24, 2018 0:01
> To: Pharo Development List  >
> Subject: Re: [Pharo-dev] [Launcher][Win]Cannot download the VM from Pharo
>  
> Hi,
>  
> My watchdog detected problems connecting to files.pharo.org 
> 
>  this night (local time).
>  
> It seems to not happen anymore. It might have been related (that is, there 
> might have been problems
> on the OVH side this night).
>  
> Marcus
>  
> 
>> On 24 Jan 2018, at 00:09, > > > > wrote:
>>  
>> Hi,
>> 
>> With the Pharo launcher, the VM are automatically downloaded from the 
>> files.pharo.org 
>> 
>>  server.
>> However, it seems that the download of some VMs doesn't work at least under 
>> Windows 10.
>> For the P7 image, the download stops at 38% (~2.5Mo) with the error 
>> "ConnectionClosed: Cannot Read Data", and, I obtain the same error with this 
>> cmd:
>> 
>> ZnEasy get: 'http://files.pharo.org/get-files/70/pharo-win-stable.zip 
>> '.
>> 
>> However, I can fully download the image through the Internet Browser. The 
>> download with Pharo is working: ZnEasy get: 'https://files.pharo.org/ 
>> '.
>>  give me a 200 OK response.
>> 
>> Thanks in advance for your help,
>> 
>> Cheers,
>> Vincent
>> 
>> 
>>

Re: [Pharo-dev] PharoLauncher : Image version determination error

2018-08-22 Thread Christophe Demarey

Hi all,

Indeed, there is now a problem to run recent Pharo 7 images from the launcher.
The problem comes from the integration of this change: 
https://github.com/pharo-project/pharo/pull/1684. This change is good but 
requires the last VM.
If you do not have a recent VM, you won’t be able to run latest Pharo 7 images. 
It does not affect other images.

Assuming you use a PharoLauncher 64-bits:
For now, there is a workaround to run latest Pharo 7 32-bits images: remove the 
vms folder from Documents/Pharo, then start Pharo Launcher. It will 
automatically get the latest 32-bits VM.
For Pharo 7 64-bits images, the problem is a bit harder:
- Pharo Launcher uses the VM shipped with itself to determine image version. 
This image has to be updated.
- It looks like the latest 61 VM does not have the code required to avoid the 
problem (code change in Pharo 70, fix in Pharo 70 VM). Maybe it would be best 
that Pharo Launcher never uses its own VM to determine pharo version of images 
having a compatible image format number? If so, a solution could be to always 
use the latest available VM compatible  with the  image format number to 
determine the pharo version. It does not guarantee that it will always work but 
we have to deal with the problem that, for now, it is impossible to know the 
pharo version of an image without running it. In the future, it would be nice 
to embed this information in the image header. As a workaround for now, we are 
thinking to ship the pharo.version file along with the image to avoid to run 
images with compatible VMs that we cannot ensure they work well with a given 
image.

I will come back to you once we have a fix for this problem.

Sorry for the inconvenience.
Christophe


> Le 22 août 2018 à 02:10, nacho <0800na...@gmail.com> a écrit :
> 
> I have the same problem.
> Just erased everything and downloaded a new pharo-launcher and the problem
> is still there
> I'm using PharoLauncher 1.3-2018.06.21 (21.0)
> All the images are useless.
> 
> 
> 
> -
> Nacho
> Smalltalker apprentice.
> Buenos Aires, Argentina.
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] PharoLauncher : Image version determination error

2018-08-22 Thread Christophe Demarey

Hi Alistair,

> Le 22 août 2018 à 12:02, Alistair Grant  a écrit :
> 
> Hi Christophe,
> 
> On Wed, 22 Aug 2018 at 09:36, Christophe Demarey
>  wrote:
>> 
>> ...
>> 
>> As a workaround for now, we are thinking to ship the pharo.version file 
>> along with the image to avoid to run images with compatible VMs that we 
>> cannot ensure they work well with a given image.
> 
> Part of the issue here is that Pharo 7 is still  in development.  My
> understanding is that within the development cycle we assume that the
> latest VM is being used (if I'm wrong, I'm sure someone will correct
> me :-)).
> 
> I don't use Pharo Launcher, so I'm not familiar with it, but it seems
> to me that for the current development version (currently Pharo 7) the
> launcher needs to ensure that it has the latest stable VM.

You’re right but the problem is that Pharo Launcher has no way to know what is 
the pharo version of an image before running it and evaluate a small 
expression. To achieve that, Pharo Launcher uses a VM that is, at least, 
compatible with the image format number. We do not have any guarantee that the 
expression evaluation of the VM will work fine for all images. For now, to 
detect the pharo version of Spur images, we use Pharo 61 VM. You can assume it 
will work well for 6. images. What if we use the 70 VM to determine pharo 
version of 6.* images? It will probably work better for Pharo 7 images 
(assuming we use the latest 70 VM) but then, no guarantee it will work for 61 
images.

The core of the problem is that we should not be forced to run an image to 
determine its pharo version. Nevertheless, I think it would be good to use the 
latest available VM for a given image format to determine its pharo version. It 
should work in most cases.

Cheers,
Christophe

Re: [Pharo-dev] PharoLauncher : Image version determination error

2018-08-23 Thread Christophe Demarey

Hi,

I just published a new version of the launcher: 1.4 (http://pharo.org/download 
<http://pharo.org/download>)
Improvements:
Add Origin Template Column
Simplify Timestamp Printing
Bug fixes:
#233 Cannot launch recent Pharo 7 images

This version mainly solves the problem of launching recent Pharo 7.0 images. 
Once this version is downloaded, do not forget to delete the folders related to 
70 vms in the Pharo/vms folder. This way, Pharo Launcher will download the 
latest one.
By the way, it also comes with some UI improvements (contributed by Sean and 
Tim).
I will work on a new version with a VM manager able to list locally available 
VMs, and a way to update or delete them. This new version will be based on 
Pharo 7 because Pharo Launcher development switched to github 
(https://github.com/pharo-project/pharo-launcher) and upcoming features are 
based on Pharo 7 (new UI, model refactoring).

Cheers,
Christophe


> Le 22 août 2018 à 15:54, Alistair Grant  a écrit :
> 
> Hi Christophe,
> 
> On Wed, 22 Aug 2018 at 15:33, Christophe Demarey
>  wrote:
>> 
>> Hi Alistair,
>> 
>>> Le 22 août 2018 à 12:02, Alistair Grant  a écrit :
>>> 
>>> Hi Christophe,
>>> 
>>> On Wed, 22 Aug 2018 at 09:36, Christophe Demarey
>>>  wrote:
>>>> 
>>>> ...
>>>> 
>>>> As a workaround for now, we are thinking to ship the pharo.version file 
>>>> along with the image to avoid to run images with compatible VMs that we 
>>>> cannot ensure they work well with a given image.
>>> 
>>> Part of the issue here is that Pharo 7 is still  in development.  My
>>> understanding is that within the development cycle we assume that the
>>> latest VM is being used (if I'm wrong, I'm sure someone will correct
>>> me :-)).
>>> 
>>> I don't use Pharo Launcher, so I'm not familiar with it, but it seems
>>> to me that for the current development version (currently Pharo 7) the
>>> launcher needs to ensure that it has the latest stable VM.
>> 
>> You’re right but the problem is that Pharo Launcher has no way to know what 
>> is the pharo version of an image before running it and evaluate a small 
>> expression. To achieve that, Pharo Launcher uses a VM that is, at least, 
>> compatible with the image format number. We do not have any guarantee that 
>> the expression evaluation of the VM will work fine for all images. For now, 
>> to detect the pharo version of Spur images, we use Pharo 61 VM. You can 
>> assume it will work well for 6. images. What if we use the 70 VM to 
>> determine pharo version of 6.* images? It will probably work better for 
>> Pharo 7 images (assuming we use the latest 70 VM) but then, no guarantee it 
>> will work for 61 images.
>> 
>> The core of the problem is that we should not be forced to run an image to 
>> determine its pharo version. Nevertheless, I think it would be good to use 
>> the latest available VM for a given image format to determine its pharo 
>> version. It should work in most cases.
> 
> Thanks very much for the explanation, it makes sense now.
> 
> My understanding is that the Pharo 7 VM is backward compatible with
> Pharo 6.1 (for now).  Esteban's process is to release a new stable
> Pharo 7 VM, and then a month later upgrade the Pharo 6.1 VM as well.
> Of course, that will be superseded by the availability of
> pharo.version.
> 
> Thanks again,
> Alistair

Re: [Pharo-dev] Pharo BOF at ESUG

2018-09-11 Thread Christophe Demarey

yes, why not after « show us your project » today

> Le 10 sept. 2018 à 15:50, Guillermo Polito  a 
> écrit :
> 
> Ok by me, so tuesday or wednesday?
> 
> On Mon, Sep 10, 2018 at 2:46 PM Stéphane Ducasse  > wrote:
> Hello 
> 
> We would like to have a BOF around Pharo. 
> Since there are many topics to talk about. 
>   Tuesday after the show us your project?
>   We can have one at the beach before the social event aroun 17h?
> 
> Stef
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr 
> http://www.synectique.eu  / http://www.pharo.org 
>  
> 03 59 35 87 52
> Assistant: Julie Jonas 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr 
> 
> 
> Web: http://guillep.github.io 
> Phone: +33 06 52 70 66 13

Re: [Pharo-dev] [Pharo-Launcher] call for tests on Windows

2018-04-17 Thread Christophe Demarey

Hi Phil, Eliot,

> Le 16 avr. 2018 à 23:58, Eliot Miranda  a écrit :
> 
> Hi Phil,
> 
> On Mon, Apr 16, 2018 at 12:54 PM, p...@highoctane.be 
>  > 
> wrote:
> I have downloaded the 
> https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/build.win32x86/pharo.cog.spur.lowcode/Pharo.exe.manifest
>  
> 
>  and put it in the folder that contains the PharoLauncher Pharo.exe and then 
> the pointers are correct again (they have their masking done correctly.
> 
> Good!  
>  
> So, there is a packaging issue somewhere for Pharo Windows VMs as downloaded 
> by the Laucher.
> 
> Indeed, we must include the manifest files on Windows.

I did not get this problem. Is this manifest file new? Is there only one 
manifest file to include or many?

Thanks for reporting this issue.
Christophe

Re: [Pharo-dev] [Pharo-Launcher] call for tests on Windows

2018-04-17 Thread Christophe Demarey

Windows 10 on top of virtual box

> Le 17 avr. 2018 à 10:29, p...@highoctane.be a écrit :
> 
> Hi Christophe,
> 
> What Windows version do you have?
> 
> I have Windows 10 and a 4K screen.
> 
> Phil
> 
> On Tue, Apr 17, 2018 at 9:43 AM, Christophe Demarey 
> <christophe.dema...@inria.fr <mailto:christophe.dema...@inria.fr>> wrote:
> Hi Phil, Eliot,
> 
>> Le 16 avr. 2018 à 23:58, Eliot Miranda <eliot.mira...@gmail.com 
>> <mailto:eliot.mira...@gmail.com>> a écrit :
>> 
>> Hi Phil,
>> 
>> On Mon, Apr 16, 2018 at 12:54 PM, p...@highoctane.be 
>> <mailto:p...@highoctane.be> <p...@highoctane.be <mailto:p...@highoctane.be>> 
>> wrote:
>> I have downloaded the 
>> https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/build.win32x86/pharo.cog.spur.lowcode/Pharo.exe.manifest
>>  
>> <https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/build.win32x86/pharo.cog.spur.lowcode/Pharo.exe.manifest>
>>  and put it in the folder that contains the PharoLauncher Pharo.exe and then 
>> the pointers are correct again (they have their masking done correctly.
>> 
>> Good!  
>>  
>> So, there is a packaging issue somewhere for Pharo Windows VMs as downloaded 
>> by the Laucher.
>> 
>> Indeed, we must include the manifest files on Windows.
> 
> I did not get this problem. Is this manifest file new? Is there only one 
> manifest file to include or many?
> 
> Thanks for reporting this issue.
> Christophe
> 
>

Re: [Pharo-dev] pharo-contribution CI machines out of disk space

2018-04-17 Thread Christophe Demarey


> Le 17 avr. 2018 à 06:02, monty  a écrit :
> 
> https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/1820/console
> 

You’re right.
I did some cleaning and put slaves back on line.

Thanks for the report.

Re: [Pharo-dev] pharo-contribution CI machines out of disk space

2018-04-18 Thread Christophe Demarey


> Le 18 avr. 2018 à 05:05, monty  a écrit :
> 
> Not quite fixed: 
> https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/1822/PHARO=30,VERSION=bleedingEdge,VM=vm/console
> 
> Should we start reconfiguring jobs to keep fewer builds?

I do not think so.
The problem here is that the root partition of the slaves are full  because 
/tmp has thousands of zip files that are downloaded by metacello from github.
There is no problem with job workspace or the number of builds to keep.
I will define a job running on slaves daily to remove tmp folder content.

Re: [Pharo-dev] pharo-contribution CI machines out of disk space

2018-04-18 Thread Christophe Demarey


> Le 18 avr. 2018 à 09:52, Christophe Demarey <christophe.dema...@inria.fr> a 
> écrit :
> 
> 
>> Le 18 avr. 2018 à 05:05, monty <mon...@programmer.net> a écrit :
>> 
>> Not quite fixed: 
>> https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/1822/PHARO=30,VERSION=bleedingEdge,VM=vm/console
>> 
>> Should we start reconfiguring jobs to keep fewer builds?
> 
> I do not think so.
> The problem here is that the root partition of the slaves are full  because 
> /tmp has thousands of zip files that are downloaded by metacello from github.
> There is no problem with job workspace or the number of builds to keep.
> I will define a job running on slaves daily to remove tmp folder content.

done: https://ci.inria.fr/pharo-contribution/job/temp-folder-cleaner/

[Pharo-dev] [Pharo-Launcher] call for tests on Windows

2018-04-16 Thread Christophe Demarey

Hi,

Regarding the various problems Pharo Launchers had on Windows, we worked on a 
new installer based on Advanced Installer [1] to avoid UAC (User Account 
Control) and write permissions problems. This new installer now installs Pharo 
Launcher in the user’s local app data folder (where for sure, he has write 
permissions). Pharo Launcher also now have its own icon and use its own name 
instead of Pharo. Also, the uninstaller now works as expected. Last but not 
least, the installer is now signed to avoid warning of Windows Defender.
Thanks to Ben Coman who did the first version of the packaging using Advanced 
Installer (was NSIS).
This version should also improve the launch of Pharo images on Windows.

So, please could you install and test this new version: and report any problem 
with it? http://files.pharo.org/pharo-launcher/win-alpha/
We do not have windows users around so it’s hard to know if it works outside 
our tests boxes.

Thanks,
Christophe

[1] https://www.advancedinstaller.com/

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

2018-03-27 Thread Christophe Demarey

Hi Ben,

> Le 26 mars 2018 à 17:21, Ben Coman  a écrit :
> 
> 2. Double-clicked it and got "Windows Defender SmartScreen prevented an 
> unrecognized app from starting." [1]
> (btw, I didn't get this with the msi-installer generated from Advanced 
> Installer which I linked above.  But maybe that was because the msi-installer 
> was created and installed on the same PC, so it was just trusting itself by 
> default.  The msi wasn't signed, so is the experience different on other 
> people's machine?)

For this, I can get a signed version with Inria. It just requires manual 
signing by some Inria security unit.
So I will only do this for release versions

> 3. Clicked "More Info" which allowed me to click "Run Anyway" and got...
> "To continue, enter admin user name and password" [2]
> so this is not really suited to students doing a user-level install on locked 
> down lab machines.

agree but with app signed, the problem should be solved

> 4. After entering the password for user "Admin" (i.e. not Administrator, just 
> another account in Administrators group)
> the install location was (as expected) given as 
>  "C:\Users\Admin\AppData\Local\PharoLauncher" [3]

Ah, I missed that. Not what I expected.

> which again is not friendly to non-admin users. 
> But just for kicks, I changed the install location to...  
>   "C:\Users\Ben\AppData\Local\PharoLauncher"
> and clicking on the PharoLauncher icon in the Start Menu
> it opened okay, and downloaded a 60539 image and associated VM
> and that image ran okay.
> 
> So its a step in the right direction, however...
> the Start Menu shortcut entry is for All User per its location here...
>C:\ProgramData\Microsoft\Windows\Start Menu\Programs\PharoLauncher
> and the target of the shortcut is... 
>C:\Users\Ben\AppData\Local\PharoLauncher\Pharo.exe
> so it only worked coincidentally because I'm clicking the Start Menu icon as 
> user "Ben"
> and it would be broken for a second Standard User.
> 
> From my reading it will be a struggle to get NSIS working smoothly
> for multiple use cases at different privilege levels. i.e. both non-admin and 
> admin users.

I will probably give a change to AdvancedInstaller.

Thanks for the feedback.
Christophe

[Pharo-dev] Pharo application packager for OS X

2018-03-29 Thread Christophe Demarey

Hi,

At this time, we do not have a utility to easily create an OS X application 
(dmg or pkg) from a Pharo image.
It would be nice to have a tool like javapackager[1] but for Pharo.
What does javapackager? It creates a pkg installer for OS X. At the end of the 
installation, you get an OS X application (you can specify the name, the icon, 
the version) that embed the JRE, the application jar file, the plist file, the 
resources, and a binary that I guess is small wrapper used to run the jre with 
adequate parameters.
You can see at [2] how it is esay to build an app (even possible to sign it).

I would like to have the same utility for a Pharo app. Instead of shipping a 
jar + the JRE, we ship Pharo VM + the image file.
Nevertheless, I do not know a lot on OS X and I do not know what to do to 
create a wrapper for Pharo like the one of pkg installer. Does anyone have an 
interest to create it or can give information to build it?

Regards,
Christophe


[1] https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
[2] http://centerkey.com/mac/java/

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

Hi Cédrick,

You could give a chance to this version (not official): 
https://ci.inria.fr/pharo-ci-jenkins2/job/PharoLauncher/lastSuccessfulBuild/artifact/pharo-launcher-installer-bleedingEdge-2018.03.23-x86.exe
It does not require anymore admin mode. I think the error below comes from 
missing write permissions on the file system.

Thanks for the feedback,
Christophe


> Le 22 mars 2018 à 22:14, Cédrick Béler  a écrit :
> 
> Hi,
> 
> I just saw students and they still have some problem on windows with the 
> launcher.
> 
> First, the launcher has to be run in admin mode.
> 
> Then, the image download starts but there is an error when uncompressing. 
> Here is the stack.
> 
> Any idea on how to fix that ?
> 
> 
> 
> FileHandle>>streamError
> FileHandle>>writeStream
> FileSystem>>writeStreamOn:
> FileReference>>writeStream
> FileReference(AbstractFileReference)>>writeStreamDo:
> ZipFileMember(ZipArchiveMember)>>extractInDirectory:overwrite:
> [ :entry | 
> | response |
> entry isDirectory
>   ifFalse: [ bar ifNotNil: [ bar label: 'Extracting ' , entry fileName ].
>   response := entry
>   extractInDirectory: aDirectory
>   overwrite: overwriteAll.
>   response == #retryWithOverwrite
>   ifTrue: [ overwriteAll := true.
>   response := entry
>   extractInDirectory: aDirectory
>   overwrite: overwriteAll ].
>   response == #abort
>   ifTrue: [ ^ self ].
>   response == #failed
>   ifTrue: [ (self confirm: 'Failed to extract ' , entry 
> fileName , '. Proceed?')
>   ifFalse: [ ^ self ] ] ] ] in 
> ZipArchive>>extractAllTo:informing:overwrite: in Block: [ :entry | ...
> OrderedCollection>>do:
> ZipArchive>>extractAllTo:informing:overwrite:
> ZipArchive>>extractAllTo:informing:
> [ :bar | self extractAllTo: aDirectory informing: bar ] in 
> ZipArchive>>extractAllTo: in Block: [ :bar | self extractAllTo: aDirectory 
> informing: ...etc...
> [ :bar | aBlock value: bar ] in MorphicUIManager>>informUserDuring: in Block: 
> [ :bar | aBlock value: bar ]
> BlockClosure>>cull:
> [ ^ block cull: self ] in [ self prepareForRunning.
> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in Block: 
> [ ^ block cull: self ]
> [ activeProcess psValueAt: index put: anObject.
> aBlock value ] in CurrentJob(DynamicVariable)>>value:during: in Block: [ 
> activeProcess psValueAt: index put: anObject
> BlockClosure>>ensure:
> CurrentJob(DynamicVariable)>>value:during:
> CurrentJob class(DynamicVariable class)>>value:during:
> [ self prepareForRunning.
> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in Block: 
> [ self prepareForRunning
> BlockClosure>>ensure:
> Job>>run
> MorphicUIManager(UIManager)>>displayProgress:from:to:during:
> MorphicUIManager>>informUserDuring:
> ZipArchive>>extractAllTo:
> PhLRemoteTemplate(PhLAbstractTemplate)>>extractZipArchive:to:
> PhLRemoteTemplate(PhLAbstractTemplate)>>extractTo:named:
> PhLDirectoryBasedImageRepository>>extractTemplate:to:
> PhLCreateImageFromTemplateCommand>>execute
> PhLCreateImageFromTemplateCommand(PhLCommand)>>executeIfApplicable
> PhLCommandButton>>performAction
> 
> 
> 
> Thanks 
> 
> Cédrick

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

Hi Milton,

Thanks for the report.
It is important that Pharo Launcher works out of the box.

For Windows, I did some fixes:
- launch images from the shell in background to avoid to have the process 
killed,
- installation directory is now LOCALAPPDATA folder where user always have 
write permissions.
- new icon

Could you try it and tell me if it solves problems you had? 
https://ci.inria.fr/pharo-ci-jenkins2/job/PharoLauncher/lastSuccessfulBuild/artifact/pharo-launcher-installer-bleedingEdge-2018.03.23-x86.exe
I still need to investigate the problem on OS X.

Thanks,
Christophe.

> Le 18 mars 2018 à 11:47, Tudor Girba  a écrit :
> 
> +1
> 
> Doru
> 
> 
>> On Mar 18, 2018, at 10:30 AM, Stephane Ducasse  
>> wrote:
>> 
>> Thanks Milton!!!
>> 
>> Can you open issue on the bug tracker?
>> 
>> https://github.com/pharo-project/pharo-launcher/issues
>> 
>> This way we are sure that it is not lost.
>> 
>> Stef
>> 
>> On Sat, Mar 17, 2018 at 11:17 PM, milton mamani  wrote:
>>> I have issues with Pharo Launcher.
>>> 
>>> Pharo Launcher version
>>> version 1.1.1
>>> http://files.pharo.org/pharo-launcher/tmp-1.1.1/
>>> 
>>> version 1.1
>>> http://files.pharo.org/pharo-launcher/1.1/
>>> 
>>> You can get these links in https://github.com/pharo-project/pharo-launcher/
>>> 
>>> OS Version
>>> Mac OS - 10.13.3
>>> 
>>> Issues
>>> 
>>> Issue #1, version 1.1 does not run in Mac OS - 10.13.3
>>> * Load P.L version 1.1
>>> * Copy the application in `Applications` folder
>>> * Try to open the program, with right-click, open
>>> * Current result the program P.L. does not run.
>>> 
>>> Issue #2 Can not open/run downloaded images
>>> * Load P.L version 1.1.1
>>> * Copy the application in `Applications` folder
>>> * Open the program, first time the program does not run
>>> * Open again the program, now the program shows a window
>>> * Try to load a pharo image, In `Templates` >> `Official distributions`>>
>>> `Pharo 6.1 stable`.
>>> * Right-click in the pharo image, then select option `Create Image`
>>> * A popup ask for a name
>>> * Introduce one name, eg: `PImage`
>>> * A loading process appears
>>> * Try to run the image with button `Launch`
>>> * Current result the image `PImage` does not run, and P.L. 1.1.1 quit on
>>> that launch.
>>> 
>>> Issue #3 Pharo debugger error appear when navigating in templates
>>> * load P.L version 1.1.1
>>> * Open the P.L
>>> * In templates area, try to load some templates
>>> * Then select one template
>>> * A debugger error window appears with the message  #selectMorphList was
>>> sent to nil
>>> * Current result: Sometimes when you try to load and select some templates
>>> an error window appear
>>> 
>>> Please tell me If you need more details about these issues
>>> 
>>> 
>>> 
>>> 2018-03-17 16:42 GMT-03:00 Stephane Ducasse :
 
 On Sat, Mar 17, 2018 at 12:59 PM, Alexandre Bergel
  wrote:
> Yesterday we also experienced many problem when using Launcher on OSX
> :-(
 
 Which version of Launcher?
 Which version of your OS?
 What problems?
 Can we reproduce it?
 
 Could we get pro in reporting problems?
 
 
> Is the Launcher still maintained?
 
 Alexandre
 
 Christophe spent two months fixing tons of issues.
 So could you report problems in a nicer way?
 
 
 
 
> 
> Alexandre
> 
> 
>> On Mar 17, 2018, at 8:57 AM, kmo  wrote:
>> 
>> I tried the default download of Pharo Launcher on my Windows 7 (32 bit)
>> PC at
>> work. It installs. Runs fine - creates images and vms  but when you try
>> to
>> run them nothing happens. It fails to start the selected image. It just
>> fails to run the vm at all as far as I can see.
>> 
>> I tried it on my Windows 10 (32 bit) laptop and got exactly the same
>> result.
>> 
>> This is not important for me as I use pharo on Linux - but I thought
>> I'd
>> point it out. If having the launcher as the default download causes
>> more
>> problems than the traditional vm and image download then perhaps it
>> should
>> be reconsidered. A pity since I love the launcher.
>> 
>> 
>> 
>> --
>> Sent from:
>> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>> 
> 
> 
 
>>> 
>> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Every now and then stop and ask yourself if the war you're fighting is the 
> right one."
> 
> 
> 
> 
>

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

Hi Alexandre,

Yes, Pharo Launcher is maintained.
But if maintainer(s) is not aware that there are issues, they will never be 
fixed.
So please, open issues at 
https://github.com/pharo-project/pharo-launcher/issues with details as 
mentioned by Sean.

Thanks,
Christophe

> Le 17 mars 2018 à 17:42, Sean P. DeNigris  a écrit :
> 
> abergel wrote
>> Yesterday we also experienced many problem when using Launcher on OSX :-(
> 
> Hmm, I've been using exclusively daily for many months with minimal
> glitches. Please post OS, Pharo system report, download method and any other
> relevant details. The major "gotchas" of the past were: 1) The app has to be
> in the "Applications" folder 2) the first time it was started you needed to
> work around a signing issue e.g. via [right click]->Open->[Confirm dialog].
> The app will not open, but from now on you can just open in the normal way
> (e.g. double clicking the .app). HTH
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

Hi Ben,

> Le 23 mars 2018 à 04:31, Ben Coman  a écrit :
> 
> P.S.  I was going to suggest also renaming  Pharo.exe  to  PharoLauncher.exe
> but with an empty Documents\Pharo\vms
> I get... "Error: Cannot detect Pharo executable in 
> C:\Temp\MyPharoLauncher\PharoLauncher"
> in PhLVirtualMachine>>initializeOn: "File @ 
> C:\Temp\MyPharoLauncher\PharoLauncher"
> since "executables := aFolder allChildrenMatching: self class executableName."
> is empty since "self class executableName" ==> "Pharo.exe"
> 
> It would be nice for that to not be hard coded.

Where would you put this information?

>   I tried digging further but ran out of time.
> I am curious it mattered since using "Pharo.exe" the Launcher went on to 
> download a VM anyway.

I use the vm shipped with the launcher when possible (e.g. to determine pharo 
images version format or run current stable images.
If I cannot find the proper vm, then I download it from files.pharo.org.

> P.S.2.
> I believe the best path forward for system-wide PharoLauncher installed under 
> "C:\Program Files"
> would be to install there only...
> * the VM 
> * PharoLauncher.ZIP 
> * a tiny non-Pharo wrapper program as the shortcut linked from AllUsers > 
> Start Menu > PharoLauncher 
> that extracts PharoLauncher.ZIP to the user's data area and then starts that 
> user specific PharoLauncher.  
> 
> Then regardless whether:
> * they individually download/extract  PharoLauncher.ZIP
> * the system-wide-wrapper extracts  PharoLauncher.ZIP
> its a similar experience for users which should aid reliability by reducing 
> the number of "different " use cases.

I now install PharoLauncher in user LOCALAPPDATA folder on windows.
Does it solve the issue for you?

Christophe

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

Hi Ben,

> Le 23 mars 2018 à 19:53, Ben Coman  a écrit :
> 
> Coincidentally I have returned to Windows for a short while so thought I 
> should 
> put my money where my mouth is and have a stab at this.  After a few hours 
> trying with NSIS, 
> I went searching for an alternative and Advanced Installer looked like a good 
> chance.
> https://www.advancedinstaller.com/feats-list.html 
> 
> The important part of  (free) Basic Features  is "Windows 10/8/7/Vista and 
> UAC installs"
> Also further down are some CI options. 

What bothers me is that it is not a free tool.
I can see the list of features here: 
https://www.advancedinstaller.com/feats-list.html

> 
> After just the "Simple Installation" tutorial and experimenting a few hours I 
> ironed out 
> a potential solution uploaded for testing to 
> http://www.mediafire.com/file/3g579bmzqspt8e1/BCPharoLauncher.msi 
> 
> with the full build tree at  
> http://www.mediafire.com/file/5ijiww848lbkk7m/PharoLauncher%20Advanced%20Installer.zip
>  
> 
> Links should be live for 30 days.
> I've directly attached the much smaller installer-configuration file 
> "PharoLauncher.aip". 
> 
> 
> PharoLauncher was built with some minor changes from above... 
> 1. Download/extracted  http://files.pharo.org/platform/Pharo6.1-win.zip 
> 
> 
> 2. Renamed  Pharo6.1folder to  BCPharoLauncher
> Renamed  Pharo6.1.*  files toPharoLauncher1.1.* 
> 
> 3. Metacello new
>smalltalkhubUser: 'Pharo'
>project: 'PharoLauncher';
>configuration: 'PharoLauncher';
> load.  
>  PharoLauncher hardResetPersistanceState: true.
>  PhLDeploymentScript doAll. 
>  PhLDeploymentScript  closeWindowsAndOpenLauncher.
>  Smalltalk snapshot: true  andQuit: true. 
> 
> 4. Moved the  image & changes  files into a subfolder "PerUserFiles"
> 
> 5. Built  BCPharoLauncher.msi
> 
> I prefixed my initials to distinguish it from the current official 
> PharoLauncher installer.
> Hopefully this can be adopted as the official installer and they can be 
> dropped off.
> 
> 
> Key features:
> a.  Provides a choice to install for "Everybody" (i.e. C:\Program Files 
> (x86)\Pharo\BCPharoLauncher\)
>  or "Only for me" (i.e. 
> C:\Users\Ben\AppData\Local\Programs\Pharo\BCPharoLauncher\)
>  per attached screen snapshot.
> 
> b.  Start the install as a Standard User and it escalates only as needed.
> 
> c.  The Desktop and Start Menu shortcuts run the following script...   
>   // File: PharoLauncher.js
>   // Author: Ben Coman 2018.03.24
>   // Purpose: Facilitate each user to run a personal copy of 
> PharoLauncher.image in their own data area.
>   
>   // Locations
>   basename = "\\PharoLauncher1.1 ";
>   WshShell = WScript.CreateObject("WScript.Shell");
>   fso = WScript.CreateObject("Scripting.FileSystemObject");
>   systemFolder = fso.GetAbsolutePathName(".");
>   vmFilename = systemFolder + "\\Pharo.exe "
>   systemBasename = systemFolder + "\\PerUserFiles 
> " + basename;
>   userFolder = 
> WshShell.ExpandEnvironmentStrings("%LOCALAPPDATA%\\Pharo");
>   userFolder2 = userFolder + "\\PharoLauncher ";
>   userBasename = userFolder2 + basename;
>   
>   // Ensure user data folder exists for PharoLauncher
>   if( ! fso.FolderExists(userFolder))
>   {   fso.CreateFolder(userFolder);
>   fso.CreateFolder(userFolder2)
>   }
>   
>   // If either  image or changes  files missing from user folder,  
> copy from system folder.  
>   if( ! fso.FileExists(userBasename + ".image") || ! 
> fso.FileExists(userBasename + ".changes")) 
>   {
>   //WScript.Echo("Setting up user environment");
>   fso.CopyFile(systemBasename + ".image",userBasename + 
> ".image", true);
>   fso.CopyFile(systemBasename + ".changes",  userBasename + 
> ".changes", true);
>   }
>   
>   // Start personal copy of PharoLauncher
>   WshShell.Exec(vmFilename + " " + userBasename + ".image »)

UAC support is really nice.
I would like to have the community opinion on using a non-free tool like 
advancedinstaller.
If there is no objection, I would consider it seriously for a next Pharo 
Launcher version.

Thanks for this work Ben!

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

Hi,

> Le 17 mars 2018 à 12:57, kmo  a écrit :
> 
> I tried the default download of Pharo Launcher on my Windows 7 (32 bit) PC at
> work. It installs. Runs fine - creates images and vms  but when you try to
> run them nothing happens. It fails to start the selected image. It just
> fails to run the vm at all as far as I can see.
> 
> I tried it on my Windows 10 (32 bit) laptop and got exactly the same result. 

Thanks for the report.
Could you tell me if this version works better? 
https://ci.inria.fr/pharo-ci-jenkins2/job/PharoLauncher/lastSuccessfulBuild/artifact/pharo-launcher-installer-bleedingEdge-2018.03.23-x86.exe

> 
> This is not important for me as I use pharo on Linux - but I thought I'd
> point it out. If having the launcher as the default download causes more
> problems than the traditional vm and image download then perhaps it should
> be reconsidered. A pity since I love the launcher.

True. We need the launcher to run in all cases if it is the first thing a 
newbie will see from Pharo.

Christophe

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

Hi Ben,

> Le 17 mars 2018 à 14:26, Ben Coman  a écrit :
> 
> 
> 
> On 17 March 2018 at 19:57, kmo > 
> wrote:
> I tried the default download of Pharo Launcher on my Windows 7 (32 bit) PC at
> work. It installs. Runs fine - creates images and vms  but when you try to
> run them nothing happens. It fails to start the selected image. It just
> fails to run the vm at all as far as I can see.
> 
> I tried it on my Windows 10 (32 bit) laptop and got exactly the same result.
> 
> This is not important for me as I use pharo on Linux - but I thought I'd
> point it out. If having the launcher as the default download causes more
> problems than the traditional vm and image download then perhaps it should
> be reconsidered. A pity since I love the launcher.
> 
> We've seen before when features are promoted in visibility (e.g. each GT tool)
> they come under more scrutiny and bump a wider set of environments 
> that cause hiccups.  Ultimately this feedback is beneficial to the tool.
> So I don't think there is any need to panic into a reversal.
> Lets give a chance to work through the issues.

Yes, that is the idea.
Testing on all OS, different versions is just not possible.
Nevertheless, it looks that there are some common bugs that I did not 
encountered when testing.
So, please test PharoLauncher and if you have issues, report them with the 
maximum information because it is hard to reproduce: 
https://github.com/pharo-project/pharo-launcher/issues

> (but it might be good for the older links to be also available further down 
> the page
> while Launcher issues are sorted out)
> 
> cheers -ben

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

Hi Peter,

> Le 17 mars 2018 à 19:00, Peter Uhnák  a écrit :
> 
> > Runs fine - creates images and vms  but when you try to
> > run them nothing happens. It fails to start the selected image. It just
> > fails to run the vm at all as far as I can see. 
> 
> I am also experiencing this...
> 
> With ProcessWrapper the image launches maybe 1 out of 10 times...
> So I hacked for myself a solution based on Torsten's OS-Window (which uses 
> WinAPI) ... but even then the launch success rate is below 90%...
> 
> I guess Pharo really doesn't like talking to Windows…

It looks like Windows OS integration is not the top priority of the community. 
We have to do with the current situation before hoping a better support.
Could you test this version and tell me if the situation goes better? 
https://ci.inria.fr/pharo-ci-jenkins2/job/PharoLauncher/lastSuccessfulBuild/artifact/pharo-launcher-installer-bleedingEdge-2018.03.23-x86.exe

Thanks, 
Christophe

Re: [Pharo-dev] Windows PharoLauncher cannot create "C:\Program Files (x86)\Pharo\Pharo.image"


> Le 16 mars 2018 à 17:05, Ben Coman  a écrit :
> 
> 
> 
> On 16 March 2018 at 22:23, Peter Uhnák  > wrote:
> > For now, if you are admin, you could install PharoLauncher under « Program 
> > Files » but then, you also need to be admin to run it. If you are not 
> > admin, you should install PharoLauncher elsewhere.
> 
> As I see this recommendation for the Nth time, maybe it is time the default 
> location to C:\Pharo (or C:\PharoLauncher) ... 
> 
> other languages don't seem to have any problem with that whatsoever (I see in 
> my dir C:\Python27, C:\Ruby24-x64, cygwin, msys, mingw, ...)
> 
> If the installer cannot escalate on its own, it shouldn't try in the first 
> place. Otherwise it's just bad experience in literally the first step people 
> will take with Pharo.
> 
> Interestingly Python 3 has installed itself in 
> %APPDATA%\Local\Programs\Python\Python36-32 ... so maybe that's also a 
> location to consider which doesn't require admin rights.
> 
> Peter
> 
> I think Python 3 has it right.  Its also where GitForWindows installs itself.
> 
> Alternatively the parent %APPDATA%\Local\
> (equivalently %LOCALAPPDATA% which can be typed into Windows Explorer)
> is where many apps seem to put their main executable.
> On my system I discover...
> %LOCALAPPDATA% \ Discord \ app-0.0.298 \ Discord.exe
> %LOCALAPPDATA% \ Atom \ atom.exe
> %LOCALAPPDATA% \ GitHubDesktop \ GitHubDesktop.exe 
> %LOCALAPPDATA% \ slack \ slack.exe
> %LOCALAPPDATA% \ Roblox \ Versions \ RobloxStudioLauncherBeta.exe

Very good idea. I updated Pharo Launcher to use LOCALAPPDATA.
Thanks Ben

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

2018-04-03 Thread Christophe Demarey

Nice addition!
I should say that names are not really intention revealing.
What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment 
?

> Le 2 avr. 2018 à 21:12, Marcus Denker  a écrit :
> 
> Hi,
> 
> As we can not very easily decide if we are inside a test execution or not 
> there was the idea to have special #halt messages 
> 
>   https://pharo.fogbugz.com/f/cases/20151/new-halt-messages 
> 
> 
> This PR implements them:
> 
>   https://github.com/pharo-project/pharo/pull/1177 
> 
> 
> There is now #haltIfInsideTest and #haltfOutsideTest. In addition, the PR 
> adds a helper method to make checking if the current
> execution environment is a test run a bit easier:  
> "CurrentExecutionEnvironment value isTest”.
> 
>   Marcus

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

2018-04-04 Thread Christophe Demarey


> Le 4 avr. 2018 à 04:34, Sean P. DeNigris  a écrit :
> 
> demarey wrote
>> What about haltIfTestExecutionEnvironment and
>> haltIfDefaultExecutionEnvironment ?
> 
> I thought the names were okay. What did you think was unclear about them?

At a first look #haltInsideTest and #haltOutsideTest do not tell me that they 
are conditional breakpoints.
maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

2018-03-16 Thread Christophe Demarey


> Le 15 mars 2018 à 09:27, Esteban Lorenzano  a écrit :
> 
> - OBS for the launcher (to have linux packaging)

yes, would be nice

> - signing the launcher on mac (we already did this for the VM, we can do the 
> same for launcher).

you sign the executable, so it mean signe the VM with another certificate => 
rebuild the VM

> And distribute it as dmg, not zip (a dmg is just a zip renamed so no problem 
> here).

It is already a dmg. Did you try it? ;)

> - a windows installer

Here also, it is already like that.
You forgot to mention: sign Windows app so that Windows Defender does not warn 
you that it is a malicious software and you should not install it

Christophe

Re: [Pharo-dev] Windows PharoLauncher cannot create "C:\Program Files (x86)\Pharo\Pharo.image"

2018-03-16 Thread Christophe Demarey

Hi Ben,

> Le 16 mars 2018 à 13:22, Ben Coman  a écrit :
> 
> I popped over to Windows for a moment to try to make my CloudflareUn 
> crossplatform,
> and installed PharoLauncher from the downloads page...
> http://files.pharo.org/pharo-launcher/1.1/pharo-launcher-installer-1.1-x86.exe
>  
> 
> 
> I logged in as an Admin to do this, but when I open it I get an error...
>"PrimitiveFailed: primitive #createDirectory: in WindowsStore failed »

Did you try to right-click on the installer and select « Run as administrator « 
? I’m not sure that apps are all run with admin privileges even if you are 
logged in with an admin account.

> Also, I would expect trouble for Non-Admin users trying to use the Admin 
> installed Pharo Launcher.trying to write to "pharo-local" under "Program 
> Files ». 

Yes, that for sure!
For now, if you are admin, you could install PharoLauncher under « Program 
Files » but then, you also need to be admin to run it. If you are not admin, 
you should install PharoLauncher elsewhere.

I did not yet had time to test what Vincent on app packaging but probably, it 
will solve the issue as Pharo Launcher does not need to write anything to the 
installation directory (was needed by tools like GT, epicea, stdout).

>   Does PharoLauncher have its own CI testing to ensure it can open okay and 
> run an image?   I'm glad to see it promoted in importance but with this it 
> probably needs such CI testing of its own separate to the usual Pharo CI 
> testing.  On Windows such CI testing *should* run as a Non-Admin user.

Functional testing like this is done by hand for this part. There are unit 
tests. you can check that on CI: 
https://ci.inria.fr/pharo-ci-jenkins2/job/PharoLauncher/
There is room for improvement here. If you have an idea on how to automate 
functional testing like this, it would be a great addition!

> btw, requiring Administrative privileges to install PharoLauncher is going to 
> lock out people who don't have administrative control over their PCs e.g. 
> University student labs.

It was like that before. I removed this check from the installer so that 
standard users can install PharoLauncher in a folder where they have write 
access. This way, PharoLauncher works.

> Wanting to run a quick demo for someone in a corporate office.  Why don't we 
> make it the same as OSX and Linux and be usable without Admin privileges.   
> That would lower a barrier to entry.

It is already possible. Just, do not install PharoLauncher in a folder 
requiring admin rights.

Thanks for feedbacks,
Christophe

Re: [Pharo-dev] Laucher cannot start a fresh 7 image

2018-10-12 Thread Christophe Demarey

Do you have a pointer to the issue?
If you do not use the latest Pharo Launcher, please update it: 
http://files.pharo.org/pharo-launcher/1.4.5/
Once done, you could also remove the pharo 7 VM from the vm folder and also the 
private vm folder to ensure the latest VM is downloaded.

If you still have an issue, please post it on 
https://github.com/pharo-project/pharo-launcher/issues

Christophe

> Le 11 oct. 2018 à 20:49, Esteban A. Maringolo  a écrit :
> 
> I reported this a week or so ago, same issue.
> 
> On 11/10/2018 03:09, p...@highoctane.be wrote:
>> Used to work. Then does not anymore.
>> 
>> Phil
> 
> -- 
> Esteban A. Maringolo
>

Re: [Pharo-dev] PharoLauncher : Image version determination error

2018-11-09 Thread Christophe Demarey

Hi,

> Le 9 nov. 2018 à 14:11, Mariano Martinez Peck  a écrit 
> :
> 
> 
> 
> On Fri, Nov 9, 2018, 10:06 Christophe Demarey  <mailto:christophe.dema...@inria.fr> wrote:
> Hi Mariano,
> 
> Le 8 nov. 2018 à 20:47, Mariano Martinez Peck  <mailto:marianop...@gmail.com>> a écrit :
> > 
> > Hi All,
> > 
> > I am having this same problem with the #fileDescriptorType: in a 
> > PharoLauncher 1.4.6  64 bits trying to launch a 
> > Pharo-7.0.0+rc1.build.1373.sha.c50749c3452952c3572527bed9ea18ec8c674855 (64 
> > Bit).
> > 
> > Any ideas?
> 
> It is because your pharo 70 vm is too old.
> You can drop the pharo/vm folder (or just 70 vm in pharo/vm and in 
> pharo/vm/private) and it should work.
> 
> 
> 
> 
> Hi Christophe, 
> 
> Thanks for the workaround. But let me ask.. Wasn't one of the launcher 
> purposes to automatically download the necessary correct VM for the image you 
> are creating? To avoid this exact kind of issue? 

Launcher magic has its boundaries.
The information available to the launcher to determine the appropriate VM to 
run an image is:
- the image format number (encoded in the image header)
- the pharo version (system version) of the image (need to run the image to 
know that information).

In your case, you have an image with the same image format number, same pharo 
version (7.0) but with incompatible changes requiring a new VM. Pharo Launcher 
has no way to get this information.
This problem only happens with moving Pharo versions : the development version.

The best option would be to encode the Pharo version as a semantic version in 
the header of the image file but it requires a lot of changes.

For now, to work around the problem, I will add a windows to easily update the 
VMs from the launcher UI.

Re: [Pharo-dev] PharoLauncher : Image version determination error

2018-11-09 Thread Christophe Demarey

Hi Mariano,

Le 8 nov. 2018 à 20:47, Mariano Martinez Peck  a écrit :
> 
> Hi All,
> 
> I am having this same problem with the #fileDescriptorType: in a 
> PharoLauncher 1.4.6  64 bits trying to launch a 
> Pharo-7.0.0+rc1.build.1373.sha.c50749c3452952c3572527bed9ea18ec8c674855 (64 
> Bit).
> 
> Any ideas?

It is because your pharo 70 vm is too old.
You can drop the pharo/vm folder (or just 70 vm in pharo/vm and in 
pharo/vm/private) and it should work.

Cheers,
Christophe.

Re: [Pharo-dev] ZipArchive and symbolic links

2018-10-02 Thread Christophe Demarey

Hi Cyril,

> Le 2 oct. 2018 à 13:41, Cyril Ferlicot  a écrit :
> 
> Hi!
> 
> I just found that ZipArchive does not honor symbolic links (at least
> in Pharo 7).
> 
> I would like to know if this is a known bug? I found out because I was
> using Pharo to unzip some Pharo vms and it broke all the dynamic
> libraries :(

It is a known limitation of ZipArchive. It does not honor symbolic links nor 
preserve permissions on files …

Christophe

Re: [Pharo-dev] Laucher cannot start a fresh 7 image

2018-10-11 Thread Christophe Demarey

Hi Phil,

It could be a problem due to the introduction of a the use of a new primitive 
in the image some weeks ago.
What is the version of Pharo Launcher you use?
Did you try to update the pharo 7 vm? (you could just drop the vm folders in 
Documents).

Christophe

> Le 11 oct. 2018 à 08:09, p...@highoctane.be a écrit :
> 
> Used to work. Then does not anymore.
> 
> Phil
>

Re: [Pharo-dev] Pharo image don't restart

2018-12-13 Thread Christophe Demarey

Hi,

The problem seems to come from: "no room in eden for 
allocateSmallNewSpaceSlots:format:classIndex:"
Eden is a part of the heap where new objects are allocated.
Basically, it appears that Pharo cannot create objects any more.
You can get information about gc and eden space here: 
https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/
 


Could you try to run your image in headless mode to see if it starts?
ex: 

I would try to start your image with a bigger size for the eden.
Clément recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm 
parameterAt: 44) * 4.
but it means you need an image that is started …

You can also set it as an argument to the VM: --eden [mk]

You could try with —eden 15207744 for example:
~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 
~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ \(development\ version\)/Pharo\ 
7.0\ -\ 64bit\ \(development\ version\).image 

Regards,
Christophe


> Le 13 déc. 2018 à 09:25, Trussardi Dario Romano  
> a écrit :
> 
> Ciao,
> 
>   i have a Ubuntu system
>  where i defined a Pharo 7.0 - 64bit image managed with 
> PharoLauncher.
> 
>   I work with it for a month and all work fine.
> 
>   Now after a save the image the system begin unstabled.
> 
>   When the mouse go on the windows summary bar ( at the bottom of the 
> Pharo window ) the image go down.
> 
>   The first time i can launch the same image from the PharoLauncher,
> 
>   but after a new  image  save ( the image go down ) i can't 
> relaunch the image.
> 
>   When i do the launch the pharoLauch shell report:
> 
> 
> 
>   I have some important work in the image ( and i don't have a backup )
> 
>   Some consideration?
> 
>   Thanks,
>   Dario
>

Re: [Pharo-dev] Pharo image don't restart

2018-12-13 Thread Christophe Demarey


> Le 13 déc. 2018 à 17:31, Trussardi Dario Romano  
> a écrit :
> 
> Ciao,
> 
>> Hi,
>> 
>> The problem seems to come from: "no room in eden for 
>> allocateSmallNewSpaceSlots:format:classIndex:"
>> Eden is a part of the heap where new objects are allocated.
>> Basically, it appears that Pharo cannot create objects any more.
>> You can get information about gc and eden space here: 
>> https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/
>>  
>> 
>> 
>> Could you try to run your image in headless mode to see if it starts?
>> ex: 
>> 
>> I would try to start your image with a bigger size for the eden.
>> Clément recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm 
>> parameterAt: 44) * 4.
>> but it means you need an image that is started …
>> 
>> You can also set it as an argument to the VM: --eden [mk]
>> 
>> You could try with —eden 15207744 for example:
>> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 
>> ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ \(development\ 
>> version\)/Pharo\ 7.0\ -\ 64bit\ \(development\ version\).image 
> 
> After copy the pharoLauncher entry with the error  into 
> Pharo7.0-64DTRDevErr entry
> 
> i do this:
> 
> /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 
> /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image
> 
> the shell report: 
> 
> pthread_setschedparam failed: Operation not permitted
> 
> *  This VM uses a separate heartbeat thread to update its internal clock
> and handle events.  For best operation, this thread should run at a
> higher priority, however the VM was unable to change the priority.  The
> effect is that heavily loaded systems may experience some latency
> issues.  If this occurs, please create the appropriate configuration
> file in /etc/security/limits.d/ as shown below:
> 
> cat < *  hardrtprio  2
> *  softrtprio  2
> END
> 
> and report to the pharo mailing list whether this improves behaviour.
> 
> You will need to log out and log back in for the limits to take effect.
> For more information please see
> ...r3732#linux
> Errore di segmentazione (core dump creato)
> 
> Any idea  about it?

So you have a segmentation fault. It means the image tries to access a memory 
address outside the memory range of its process.
using gdb on the core dump could help to have more clues: 
https://www.cprogramming.com/debugging/segfaults.html 

Do you also have a segmentation fault if you run the image without the eden 
parameter?

> The * message required some action ?

this message is just a warning. If you want to avoid it, just execute this as 
root:
> cat < *  hardrtprio  2
> *  softrtprio  2
> END

> P.S. I have to conclude that there is no solution?

For now, it is too early to have a conclusion because we do not know what 
caused the crash.
As Eliot said, it could be useful to get the crash.dmp file and the 
PharoDebug.log file.

Re: [Pharo-dev] Pharo image don't restart

2018-12-14 Thread Christophe Demarey


> Le 14 déc. 2018 à 12:41, Trussardi Dario Romano  
> a écrit :
> 
> Some consideration:
> 
> 
>   At 12 December: 
> 
>   I work all day with the image.
> 
>   at: 19:xx   I save the image without any problem.
> 
>   But after saved the image the 
> system begin unstable.
> 
>   When the mouse go on the 
> windows summary bar ( at the bottom of the Pharo window ) the image crash.
> 
>   Some time i can launch - 
> relaunch the same image from the PharoLauncher ( the pharo run but was 
> unstable )
> 
>   at: 19:45 After reload the unstable image ( as mentioned 
> above )
> 
>   i do the save command ( saving 
> it on itself ) and  the system crash.
> 
>   After this crash ( when i do 
> the image save command ),
> 
>   i have not been able to 
> launch the image.
> 
>   I do not know the status of 
> this image ( I call this corrupt image  )
> 
>   
>   At 13 December:
> 
>   A) From pharoLauncher i launch the corrupt 
> image some time,
> 
>   the  shell report the issue, 
>   
> 
> 
>   but don't create the crash.dmp file.
>   
> 
> 
>   B) After copy the pharoLauncher corrupt image   
> into Pharo7.0-64DTRDevErr entry
> 
>   i do this:
> 
>   /opt/pharolauncher/pharo-vm$ ./pharo --eden 
> 15207744 
> /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image
> 
>   the shell report:   
> 
> pthread_setschedparam failed: Operation not permitted
> This VM uses a separate heartbeat thread to update its internal clock
> and handle events.  For best operation, this thread should run at a
> higher priority, however the VM was unable to change the priority.  The
> effect is that heavily loaded systems may experience some latency
> issues.  If this occurs, please create the appropriate configuration
> file in /etc/security/limits.d/ as shown below:
> 
> cat < *  hardrtprio  2
> *  softrtprio  2
> END
> 
> and report to the pharo mailing list whether this improves behaviour.
> 
> You will need to log out and log back in for the limits to take effect.
> For more information please see
> ...r3732#linux
> Errore di segmentazione (core dump creato)
> 
>   C) i have a PharoDebug.log  but has the 
> size of 16MB.
> 
>   How can I send it to you?

you can try something like https://wetransfer.com

Re: [Pharo-dev] Pharo image don't restart

2018-12-14 Thread Christophe Demarey

I did not notice the link in the previous link. I got the PharoDebug.log file.
It is very big because there are a lot of traces there.

The last one is the following.
Does it correspond to your crash?
To be sure, you could rename this file and try to run again your image to see 
if we have logs.

—
THERE_BE_DRAGONS_HERE
Halt
12 December 2018 6:47:50.168135 pm

VM: unix - x86_64 - linux-gnu - CoInterpreter VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: 
Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git

Image: Pharo7.0.0alpha [Build information: 
Pharo-7.0.0+alpha.build.1271.sha.7e89f61c1e268f08b871d6c9bf4c64536cca6c32 (64 
Bit)]

MATimedIvaModel(Object)>>halt
Receiver: a MATimedIvaModel : 1 August 2014
Arguments and temporary variables: 

Receiver's instance variables: 
data:   1 August 2014
bloccato:   true
aliquotaIva:20
symbolIva:  '20'


MATimedIvaModel(MATimedInstanceModel)>>blockAtData
Receiver: a MATimedIvaModel : 1 August 2014
Arguments and temporary variables: 

Receiver's instance variables: 
data:   1 August 2014
bloccato:   true
aliquotaIva:20
symbolIva:  '20'


MASelectorAccessor>>read:
Receiver: (MASelectorAccessor read: #blockAtData write: #blockAtData:)
Arguments and temporary variables: 
aModel: a MATimedIvaModel : 1 August 2014
Receiver's instance variables: 
properties: nil
readSelector:   #blockAtData
writeSelector:  #blockAtData:


MADescribedColumn(MAColumn)>>valueFor:
Receiver: a MADescribedColumn
Arguments and temporary variables: 
aRow:   a MATimedIvaModel : 1 August 2014
Receiver's instance variables: 
properties: a Dictionary()
report: a MAReport
accessor:   (MASelectorAccessor read: #blockAtData write: 
#blockAtData:)
description:a MABooleanDescription label: 'Bloccato' 
comment: 'Definisce se co...etc...


MADescribedColumn>>valueFor:
Receiver: a MADescribedColumn
Arguments and temporary variables: 
aRow:   a MATimedIvaModel : 1 August 2014
Receiver's instance variables: 
properties: a Dictionary()
report: a MAReport
accessor:   (MASelectorAccessor read: #blockAtData write: 
#blockAtData:)
description:a MABooleanDescription label: 'Bloccato' 
comment: 'Definisce se co...etc...


MADescribedColumn(MAColumn)>>renderCellContent:on:
Receiver: a MADescribedColumn
Arguments and temporary variables: 
anObject:   a MATimedIvaModel : 1 August 2014
html:   a WAHtmlCanvas
Receiver's instance variables: 
properties: a Dictionary()
report: a MAReport
accessor:   (MASelectorAccessor read: #blockAtData write: 
#blockAtData:)
description:a MABooleanDescription label: 'Bloccato' 
comment: 'Definisce se co...etc...


MessageSend>>valueWithEnoughArguments:
Receiver: MessageSend(#renderCellContent:on: -> a MADescribedColumn)
Arguments and temporary variables: 
anArray:an Array(a MATimedIvaModel : 1 August 2014 a 
WAHtmlCanvas 7)
args:   an Array(a MATimedIvaModel : 1 August 2014 a 
WAHtmlCanvas)
Receiver's instance variables: 
receiver:   a MADescribedColumn
selector:   #renderCellContent:on:
arguments:  #()


[ self renderer
valueWithEnoughArguments: (Array with: anObject with: html with: 
anInteger) ] in MADescribedColumn(MAColumn)>>renderCell:index:on:
Receiver: a MADescribedColumn
Arguments and temporary variables: 
anObject:   a MATimedIvaModel : 1 August 2014
anInteger:  7
html:   a WAHtmlCanvas
Receiver's instance variables: 
properties: a Dictionary()
report: a MAReport
accessor:   (MASelectorAccessor read: #blockAtData write: 
#blockAtData:)
description:a MABooleanDescription label: 'Bloccato' 
comment: 'Definisce se co...etc...


BlockClosure>>renderOn:
Receiver: [ self renderer
valueWithEnoughArguments: (Array with: anObject with: html with: 
anIntege...etc...
Arguments and temporary variables:

Re: [Pharo-dev] can I get Pharo7 release candidate images in PharoLauncher

2018-12-03 Thread Christophe Demarey

Hi Ben,

> Le 3 déc. 2018 à 12:41, Ben Coman  a écrit :
> 
> I updated PharoLauncher by...
> loading ConfigurationOfPharoLauncher-ChristopheDemarey.92
> running ```ConfigurationOfPharoLauncher load```
> then in settings clicked "Hard reset persistent state"
> 
> But I'm not seeing any of the release candidate images.
> Should I be?
> 
> cheers -ben

I wanted to publish a new release of PL today but we have issues with the 
windows certificate.
To know more about the problem: 
https://github.com/pharo-project/pharo-launcher/issues/281 

To solve the problem quickly (waiting for the new PL release): 
in your Pharo Launcher app, hit cmd+p to open monticello browser and 
load PharoLauncher-Core-TorstenBergmann.209

The new PL release solves this problem and externalize the definition of 
template sources.

Cheers,
Christophe

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

2018-11-22 Thread Christophe Demarey

Hi,

Why not following git flow?
Keep the development branch for dev and open a 70-release branch to prepare the 
release.
This way, there is no change for most people.

Christophe

> Le 22 nov. 2018 à 11:40, Esteban Lorenzano  a écrit :
> 
> Hi list,
> 
> Well, subject says pretty much all. 
> We are planning to release Pharo 7.0 very soon now, and while preparing the 
> release process, we came to the conclusion that we will need a branch for 
> version to develop, and because of that we will need to rename what is not 
> “development” to “dev-7.0”.
> Then, it will be a “dev-8.0” and so on…
> 
> So, be prepared to submit your PRs to dev-7.0 instead development :)
> 
> Cheers,
> Esteban

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

2018-11-22 Thread Christophe Demarey


> Le 22 nov. 2018 à 13:25, Esteban Lorenzano  a écrit :
> 
>> On 22 Nov 2018, at 13:21, Esteban Lorenzano > <mailto:esteba...@gmail.com>> wrote:
>> 
>>> On 22 Nov 2018, at 12:48, Christophe Demarey >> <mailto:christophe.dema...@inria.fr>> wrote:
>>> 
>>> Hi,
>>> 
>>> Why not following git flow?
>>> Keep the development branch for dev and open a 70-release branch to prepare 
>>> the release.
>>> This way, there is no change for most people.
>> 
>> Because our scripts are automated in branch and tag basis. 
>> dev-7.0 will generate SNAPSHOT versions for files.pharo.org/70 
>> <http://files.pharo.org/70> and tags (v7.0.0-rc1, for example) will generate 
>> a release.

maybe not for now but we can update the scripts to check:
- master branch => release (only release tags there)
- development branch => snapshot
- release branch => snapshots or realease (rcx) if a tag is defined
- all other branches => do nothing

>> 
>> We could have another flow, but this was what we decided last week and we 
>> will try it (maybe this is wrong and we will need to change it, but well… 
>> we’ll see… good part of having a process is that we can iterate on it :P)
> 
> Btw, I’m not complete happy with this either: as it is previewed now, there 
> will not be stable branch, and I feel this is incorrect. But again… good 
> thing is we can iterate, we’ll see if this works.

we could use the master branch for that =>  commits to master are only merges 
from release branches and hotfix branches.

[Pharo-dev] ZipArchive

2019-02-08 Thread Christophe Demarey

Hi,

I did some update to ZipArchive so that it uses FileReference instead of path 
strings: 
https://github.com/demarey/pharo/commit/30120d3284cef5cd2f442f00d71da6f6aff5dd54
It also allows to use a memory file system for tests.
Tests are green but I’m not sure they cover a lot of things.

If you use ZipArchive could you tell me if changes are ok for you?

Thanks,
Christophe

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

2019-02-13 Thread Christophe Demarey

Hi Sean,

There was a similar issue on Linux: 
https://github.com/pharo-project/pharo-launcher/issues/307

It works with 1.7.2 on my laptop but I’m able to reproduce the error if I put 
PharoLauncher in a location containing non ASCII characters, I get the same 
error.
To fix this, in PL image, edit VirtualMachine>>#fullPath with:
^(self getSystemAttribute: 0) asByteArray utf8Decoded

It is a problem with the Pharo image. Encoding is not managed everywhere.

Tell me if it fixes your problem.

Christophe


> Le 13 févr. 2019 à 03:42, Sean P. DeNigris  a écrit :
> 
> Just dl-ed launcher from Pharo.org. Attempting to open Iceberg gives:
> "NotFound: Could not find repository from '/'". Seems to be coming from
> libgit. Anyone else seeing this?
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave



> Le 13 févr. 2019 à 19:23, Sean P. DeNigris  a écrit :
> 
> Max Leske wrote
>> Nope. I downloaded launcher just 20 minutes ago on Mojave and am using 
>> it without problems.
> 
> Weird. Nuked startup preferences folder just in case. fullPath modification
> didn't help.
> 
>> Where did you extract it to? 
> ~/Application
> 
>> Did you extract it as a different user? 
> Doesn't look like it
> 
>> Did you try to run it from within the .dmg directly?
> No. Opened the dmg, dragged it into apps folder, then opened that

ok. I see.
When building PharoLauncher, Metacello loads PL code with url: 
Metacello new 
baseline: 'PharoLauncher’; 
repository: 'gitlocal://src'; 
load
In PL, if you inspect IceRepository registry, you will notice a repository 
IceLibGitRepository(.) corresponding to the above expression.
when you run PL from UI, working directory is /, IceLibGitRepository(.) then is 
resolved to / => no git repo there.
That’s why you get: Could not find repository from ‘/'

Here is a fix for it:
(IceRepository registeredRepositoryIncludingPackage: (RPackageOrganizer default 
packageNamed: 'PharoLauncher-Core'))
name: 'pharo-launcher';
location: nil

Christophe

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

https://github.com/pharo-project/pharo-launcher/issues/311

> Le 14 févr. 2019 à 10:57, Christophe Demarey  a 
> écrit :
> 
>> 
>> Le 13 févr. 2019 à 19:23, Sean P. DeNigris  a écrit :
>> 
>> Max Leske wrote
>>> Nope. I downloaded launcher just 20 minutes ago on Mojave and am using 
>>> it without problems.
>> 
>> Weird. Nuked startup preferences folder just in case. fullPath modification
>> didn't help.
>> 
>>> Where did you extract it to? 
>> ~/Application
>> 
>>> Did you extract it as a different user? 
>> Doesn't look like it
>> 
>>> Did you try to run it from within the .dmg directly?
>> No. Opened the dmg, dragged it into apps folder, then opened that
> 
> ok. I see.
> When building PharoLauncher, Metacello loads PL code with url: 
>   Metacello new 
>   baseline: 'PharoLauncher’; 
>   repository: 'gitlocal://src'; 
>   load
> In PL, if you inspect IceRepository registry, you will notice a repository 
> IceLibGitRepository(.) corresponding to the above expression.
> when you run PL from UI, working directory is /, IceLibGitRepository(.) then 
> is resolved to / => no git repo there.
> That’s why you get: Could not find repository from ‘/'
> 
> Here is a fix for it:
> (IceRepository registeredRepositoryIncludingPackage: (RPackageOrganizer 
> default packageNamed: 'PharoLauncher-Core'))
>   name: 'pharo-launcher';
>   location: nil
> 
> Christophe

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave



> Le 14 févr. 2019 à 18:37, Sean P. DeNigris  a écrit :
> 
> demarey wrote
>> Here is a fix for it:
>> (IceRepository registeredRepositoryIncludingPackage: (RPackageOrganizer
>> default packageNamed: 'PharoLauncher-Core'))
>>  name: 'pharo-launcher';
>>  location: nil
> 
> That worked! Thanks. I wonder why Max did not get the error, though…


Probably because the email title is « can’t install launcher … » and the issue 
only raises if you try to open Iceberg ;)

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave



> Le 14 févr. 2019 à 22:34, Sean P. DeNigris  a écrit :
> 
> demarey wrote
>> Probably because the email title is « can’t install launcher … » and the
>> issue only raises if you try to open Iceberg ;)
> 
> Except Max said:
> I downloaded it again... and opened Iceberg without issues.
> !!

Good catch. I should have read more carefully!
Indeed, strange that Max did not get the issue.

Could it be that Max tried to open it in a launched image?

Re: [Pharo-dev] Can't Install Launcher on Mac Mojave

2019-02-15 Thread Christophe Demarey

So, problem solved.
Thanks for the clarification Max.

> Le 15 févr. 2019 à 10:43, Max Leske  a écrit :
> 
> Yeah. I hadn't realized that you were launching Iceberg within launcher. I 
> launched an image first and then opened Iceberg in there.
> 
> Max
> 
> On 14 Feb 2019, at 23:26, Christophe Demarey wrote:
> 
> Le 14 févr. 2019 à 22:34, Sean P. DeNigris s...@clipperadams.com 
> <mailto:s...@clipperadams.com> a écrit :
> 
> demarey wrote
> 
> Probably because the email title is « can’t install launcher … » and the
> issue only raises if you try to open Iceberg ;)
> 
> Except Max said:
> I downloaded it again... and opened Iceberg without issues.
> !!
> 
> Good catch. I should have read more carefully!
> Indeed, strange that Max did not get the issue.
> 
> Could it be that Max tried to open it in a launched image?
>

Re: [Pharo-dev] pharo.prg is down

2019-02-05 Thread Christophe Demarey

There is a documentation I wrote when preparing server migration (none before) 
hosted at https://gitlab.inria.fr/RMOD/servers.
It is a private repository as it contains sensitive information.

> Le 5 févr. 2019 à 14:58, ducasse  a écrit :
> 
> Do we have a document somwhere to know what to do
> if knowing people are in vacation?
> 
> 
> 
>> On 5 Feb 2019, at 13:57, Christophe Demarey  
>> wrote:
>> 
>> Thanks for the report.
>> I restarted the service. It is now back on line.
>> 
>> Cheers,
>> Christophe
>> 
>>> Le 5 févr. 2019 à 13:41, Tudor Girba  a écrit :
>>> 
>>> Hi,
>>> 
>>> pharo.org looks down:
>>> https://downforeveryoneorjustme.com/pharo.org
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> --
>>> www.feenk.com
>>> 
>>> “How do you feenk today?"
>>> 
>>> 
>> 
>> 
> 
> 
>

Re: [Pharo-dev] pharo.prg is down

2019-02-05 Thread Christophe Demarey

Thanks for the report.
I restarted the service. It is now back on line.

Cheers,
Christophe

> Le 5 févr. 2019 à 13:41, Tudor Girba  a écrit :
> 
> Hi,
> 
> pharo.org looks down:
> https://downforeveryoneorjustme.com/pharo.org
> 
> Cheers,
> Doru
> 
> --
> www.feenk.com
> 
> “How do you feenk today?"
> 
>

Re: [Pharo-dev] [ANN] OSWinSubprocess a library to spawn Windows System processes

2019-07-09 Thread Christophe Demarey

Hi Torsten,


> Le 8 juil. 2019 à 20:44, Torsten Bergmann  a écrit :
> 
> Without having a deeper look I guess what was done for Windows now is 
> wrapping the usual STARTUPINFO, CreateProcess()
> functions and friends yet again …

Indeed.
A subtle difference is that we use the Unicode version of this API.

> 
> Such wrappers and many other native friends were created from my side already 
> years ago with my "OS-XXX" series
> of projects for different platforms:
> 
> - http://smalltalkhub.com/#!/~OS/OS-Windows

I know this library as doing a lot of cool things for the integration with the 
OS but I was not aware there was an implementation of processes forking. I 
thought it used one of the existing library to do that.

> - http://smalltalkhub.com/#!/~OS/OS-OSX
> - http://smalltalkhub.com/#!/~OS/OS-Unix
> - http://smalltalkhub.com/#!/~OS/OS-Linux-CentOS
> - http://smalltalkhub.com/#!/~OS/OS-Linux-Ubuntu
> - http://smalltalkhub.com/#!/~OS/OS-Raspbian
> 
> So for instance on Windows you could easily use
> 
>   WinProcess createProcess: 'explorer.exe'
> 
> or
> 
>   WinProcess createAndWaitForProcess: 'cmd.exe'.
> 
> The projects are available on Github now since 2018 and kept up to date for 
> recent Pharo versions.
> 
> - https://github.com/astares/Pharo-OS-Windows
> - https://github.com/astares/Pharo-OS-OSX
> - https://github.com/astares/Pharo-OS-Unix
> - https://github.com/astares/Pharo-OS-Linux-Ubuntu
> - https://github.com/astares/Pharo-OS-Raspbian
> 
> All of them are available in Catalog.
> 
> I have no problem with more and more implementations and the double efforts. 
> But for Pharo users I have the feeling
> that it gets more and more confusing in the area of OSProcess, OSSubProcess, 
> OSWinSubprocess,  and more wrappers
> for basically the same thing …

I think you are right on this point. I have the same feeling.
Also, OSSubprocess is now the recommended way to fork processes on Linux like 
systems, and there is no support yet for Windows, I took the opportunity to 
create the OSWinSubprocess project that could be easily merged into 
OSSubprocess once it gets all required features. I based my work on a PR done 
on Pharo Launcher by Keldon Alleyne. If I knew about the process support in 
OS-Windows, I would for sure, at least, had a look at it and possibly re-use it.

I see you have some support for pipes / streams. If you are willing to we could 
work together to merge both implementation. The only thing is that we should 
keep the OSSubprocess API when possible to allow a merge with it in a future.
WDYT?

Christophe.

Re: [Pharo-dev] [ANN] Pharo Launcher 1.9.1 released

2019-07-09 Thread Christophe Demarey



> Le 8 juil. 2019 à 19:48, Esteban Maringolo  a écrit :
> 
> On Mon, Jul 8, 2019 at 9:39 AM Christophe Demarey
>  wrote:
>> 
>> Hi Esteban,
>> 
>>> Le 8 juil. 2019 à 14:24, Esteban Maringolo  a écrit :
>>> 
>>> Thanks,
>>> 
>>> I downloaded the latest one for Windows, and it seems to work, but the
>>> "About" says Pharo Launcher is 1.6.
>> 
>> Strange because the version is set during the build on the CI server: 
>> ./pharo PharoLauncher.image eval --save 'PhLAboutCommand version: 
>> '\’'1.9.1'\'''
>> 
>>> Looking at the installation directory at
>>>  the right files are
>>> there, so it's just a matter of the text in the About dialog.
>> 
>> Are you sure, you use the right version? To ensure, by using shif+entre in 
>> PharoLauncher, you should see OSWSWinProcess class.
> 
> I am sure, and also checked, because you never know... and the
> installer copied the files in the same directory as the previous one,
> but didn't overwrite them.
> 
> So I uninstalled the previous version and re-installed the latest one
> and now it works fine (and faster, it seems).
> Which makes me suspicious about whether the 1.8 was installed at all
> last time I did it.

Hum. Good to know.
I will have to investigate on the installer behavior.

Thanks.

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Launcher 1.9.1 released

2019-07-09 Thread Christophe Demarey


> Le 9 juil. 2019 à 07:57, Stéphane Ducasse  a écrit 
> :
> 
> christophe 
> 
> the name of the archive is confusing to me. 
> what is the diff between x64 and x86 

x64: 64 bits version
x86: 32 bit version
For OS X, choose one of these with a dmg extension. The recommended version is 
always the 64-bits one.

> which one is for mac?
> S
> 
>> On 8 Jul 2019, at 10:32, Christophe Demarey > <mailto:christophe.dema...@inria.fr>> wrote:
>> 
>> Hi all,
>> 
>> We are pleased to announce Pharo Launcher 1.9.1 release!
>> The goal of this release is to have a better Windows support. Indeed Pharo 
>> Launcher now uses a new library OSWinSubprocess 
>> (https://github.com/pharo-contributions/OSWinSubprocess 
>> <https://github.com/pharo-contributions/OSWinSubprocess>) created for Pharo 
>> Launcher needs. This library allows to create Windows processes through ffi 
>> calls to the Windows API. It uses the unicode api, allowing paths with 
>> non-ascii characters.
>> In the same time, we switched from OSProcess to  OSSubprocess (Linux and OS 
>> X) that is now the preferred library to use to fork processes on Linux-based 
>> systems.
>> 
>> This release is not yet the default download of Pharo Launcher on Pharo web 
>> site because we want more feedback before promoting it.
>> Please use this link to install it: 
>> https://files.pharo.org/pharo-launcher/1.9 
>> <https://files.pharo.org/pharo-launcher/1.9> and let us know if this version 
>> works fine/better for you.
>> 
>> ps: For now, the binary is not signed but it will come soon.
>> ps2: Thanks to Keldon Alleyne for his PR on Pharo Launcher offering the 
>> first FFI binding to Windows process API
>> 
>> Regards,
>> The Pharo team.
>> 
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/>
> http://www.synectique.eu <http://www.synectique.eu/> / http://www.pharo.org 
> <http://www.pharo.org/> 
> 03 59 35 87 52
> Assistant: Julie Jonas 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>

[Pharo-dev] [ANN] Pharo Launcher 1.9.1 released

Hi all,

We are pleased to announce Pharo Launcher 1.9.1 release!
The goal of this release is to have a better Windows support. Indeed Pharo 
Launcher now uses a new library OSWinSubprocess 
(https://github.com/pharo-contributions/OSWinSubprocess 
) created for Pharo 
Launcher needs. This library allows to create Windows processes through ffi 
calls to the Windows API. It uses the unicode api, allowing paths with 
non-ascii characters.
In the same time, we switched from OSProcess to  OSSubprocess (Linux and OS X) 
that is now the preferred library to use to fork processes on Linux-based 
systems.

This release is not yet the default download of Pharo Launcher on Pharo web 
site because we want more feedback before promoting it.
Please use this link to install it: https://files.pharo.org/pharo-launcher/1.9 
 and let us know if this version 
works fine/better for you.

ps: For now, the binary is not signed but it will come soon.
ps2: Thanks to Keldon Alleyne for his PR on Pharo Launcher offering the first 
FFI binding to Windows process API

Regards,
The Pharo team.

[Pharo-dev] [ANN] OSWinSubprocess a library to spawn Windows System processes

Hi,

Pharo Launcher had stability problems to spawn new processes (launch Pharo 
images) on Windows as well as limitations (paths could only contain ASCII 
characters).
To solve this problem, we developed a new library: OSWinSubprocess 
(https://github.com/pharo-contributions/OSWinSubprocess 
) and decided to make 
it a standalone library so that people can use it if they need to.
We tried to use the same API as OSSubprocess when possible. This library uses 
the Windows API to create process from both 32-bit and 64-bit Pharo images. It 
also supports Unicode characters.

Here are some examples on how to use it:
process := OSWSWinProcess new 
command: 'C:\Windows\notepad.exe';
run.
...
process terminate.

OSWSWinProcess new 
command: 'C:\Windows\notepad.exe';
arguments: #('notepad.exe' 'C:\foo.txt');
runAndWait.
Important note: As of now, this library does not yet support standard streams 
(stdin, stdout and stderr). It could be done by setting the appropriate 
information in the STARTUPINFO structutre.

You can check the README for more information.

Regards,
Christophe.

Re: [Pharo-dev] Pharo Launcher is broken out of the box.

2019-09-15 Thread Christophe Demarey

Hi Todd,

Thanks for the report.
Could you create an issue on Github and explain the way to reproduce?

https://github.com/pharo-project/pharo-launcher/issues

Regards,
Christophe

> Le 15 sept. 2019 à 21:04, Todd Blanchard via Pharo-dev 
>  a écrit :
> 
> 
> De: Todd Blanchard 
> Objet: Pharo Launcher is broken out of the box.
> Date: 15 septembre 2019 à 21:04:43 UTC+2
> À: Pharo Development List 
> 
> 
> I just downloaded the latest Pharo Launcher.
> 
> It is throwing some errors.
> 
> 
> 
>

Re: [Pharo-dev] Pharo Launcher 1.9.2 Crash

2019-08-02 Thread Christophe Demarey

Hi Sean,

I suspect a build problem on the CI server.
I did a new build with the same files and it works ok for me on Mac OS 10.11.4 
and 10.14.6.
Could you test it? It’s updated on files.pharo.org.

Thanks for the report,
Christophe.

> Le 26 juil. 2019 à 15:14, Sean P. DeNigris  a écrit :
> 
> PharoLauncher-1.9.2-x64.dmg does not open on Mac OS 10.14.1. Crash dump shows
> Freetype related:
> 
> Segmentation fault Fri Jul 26 09:07:17 2019
> 
> VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6
> Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> 
> C stack backtrace & registers:
>   rax 0x000111ae3be0 rbx 0x0001121a1878 rcx 0x rdx
> 0x018c
>   rdi 0x000111ae3be0 rsi 0x000111ae3be0 rbp 0x7ffee922c1b0 rsp
> 0x7ffee922c1b0
>   r8  0x r9  0x r10 0x000106a935a0 r11
> 0x000111ae3be0
>   r12 0x r13 0x0010 r14 0x r15
> 0x
>   rip 0x7fff67353dd0
> 0   libsystem_platform.dylib0x7fff67353dd0
> _platform_memmove$VARIANT$Haswell + 240
> 1   Pharo   0x000106a25642 reportStackState
> + 952
> 2   Pharo   0x000106a25987 sigsegv + 174
> 3   libsystem_platform.dylib0x7fff67356b3d _sigtramp + 29
> 4   ??? 0x 0x0 + 0
> 5   Pharo   0x000106a5e5aa
> primitiveCalloutWithArgs + 164
> 
> Smalltalk stack dump:
>0x7ffee923a2d0 M LibC>memCopy:to:size: 0x10ec722d8: a(n) LibC
>0x7ffee923a318 M LibC class>memCopy:to:size: 0x10e4c65e0: a(n) LibC
> class
>0x7ffee923a380 I ExternalAddress>copyFrom:to: 0x111bab200: a(n)
> ExternalAddress
>   0x111baea18 s FreeTypeFace(FT2Face)>renderGlyphIntoForm:pixelMode:
>   0x111bbc5b8 s FreeTypeFace(FT2Face)>renderGlyphIntoForm:
>   0x111bc2db0 s
> FreeTypeSubPixelAntiAliasedGlyphRenderer>renderStretchedGlyph:depth:subpixelPosition:font:
>   0x111bc6a70 s
> FreeTypeSubPixelAntiAliasedGlyphRenderer>subGlyphOf:colorValue:mono:subpixelPosition:font:
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] [ANN] Pharo Launcher 1.9.1 released

2019-08-06 Thread Christophe Demarey

Hi Sean,

> Le 26 juil. 2019 à 15:23, Sean P. DeNigris  a écrit :
> 
> demarey wrote
>> we want more feedback before promoting it.
> 
> "Show in folder" doesn't work - still trying to use OSProcess which appears
> to no longer be loaded. BTW IMHO it would be better to create a layer to
> hide the process differences on different OSes. This new world of a
> different lib for each OS is hopefully a milestone on a path to a more
> unified future, and it will be harder to clean out all the "if windows"
> conditionals later.

True. I also discovered that juste after the 1.9.1 release.
That’s why I did the 1.9.2 release (see 
https://github.com/pharo-project/pharo-launcher/releases/tag/1.9.2 
).
It is fixed in this version.

Christophe.

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Launcher 1.9.1 released

Better with the right url: https://files.pharo.org/pharo-launcher/1.9.1 
<https://files.pharo.org/pharo-launcher/1.9.1>
> Le 8 juil. 2019 à 10:32, Christophe Demarey  a 
> écrit :
> 
> Hi all,
> 
> We are pleased to announce Pharo Launcher 1.9.1 release!
> The goal of this release is to have a better Windows support. Indeed Pharo 
> Launcher now uses a new library OSWinSubprocess 
> (https://github.com/pharo-contributions/OSWinSubprocess 
> <https://github.com/pharo-contributions/OSWinSubprocess>) created for Pharo 
> Launcher needs. This library allows to create Windows processes through ffi 
> calls to the Windows API. It uses the unicode api, allowing paths with 
> non-ascii characters.
> In the same time, we switched from OSProcess to  OSSubprocess (Linux and OS 
> X) that is now the preferred library to use to fork processes on Linux-based 
> systems.
> 
> This release is not yet the default download of Pharo Launcher on Pharo web 
> site because we want more feedback before promoting it.
> Please use this link to install it: 
> https://files.pharo.org/pharo-launcher/1.9 
> <https://files.pharo.org/pharo-launcher/1.9> and let us know if this version 
> works fine/better for you.
> 
> ps: For now, the binary is not signed but it will come soon.
> ps2: Thanks to Keldon Alleyne for his PR on Pharo Launcher offering the first 
> FFI binding to Windows process API
> 
> Regards,
> The Pharo team.
>

Re: [Pharo-dev] [ANN] Pharo Launcher 1.9.1 released

Hi Esteban,

> Le 8 juil. 2019 à 14:24, Esteban Maringolo  a écrit :
> 
> Thanks,
> 
> I downloaded the latest one for Windows, and it seems to work, but the
> "About" says Pharo Launcher is 1.6.

Strange because the version is set during the build on the CI server: ./pharo 
PharoLauncher.image eval --save 'PhLAboutCommand version: '\’'1.9.1'\'''

> Looking at the installation directory at
>  the right files are
> there, so it's just a matter of the text in the About dialog.

Are you sure, you use the right version? To ensure, by using shif+entre in 
PharoLauncher, you should see OSWSWinProcess class.

Thanks for the feedback,
Christophe.

Re: [Pharo-dev] [ANN] OSWinSubprocess a library to spawn Windows System processes

Hi Cédric,

> Le 8 juil. 2019 à 12:39, Cédrick Béler  a écrit :
> 
> Hi,
> 
> Really nice Christophe.
> 
> I wonder then if OSSubProcess shroud be « renamed » OSUnixSubProcess ?

In my vision, I would like to see OsWinSubprocess merged into OSSubprocess once 
we have full support (e.g. std input/outputs).

> A related question is the the limitation of LibC, iow. When to use LibC or 
> the couple OSSubProcess/OSWinSubProcess ?

Basically, OSSubprocess uses LibC and OSWinSubprocess uses the windows 
equivalent of LibC (Kernel32 and msvcrt).
I would say it is easier to use a more high level library like OSSubprocess or 
OSWinSubprocess but it is still possible to use LibC directly.
They can be used independently.
On Windows, to workaround std input/output support you could just make the 
launched program write into a file and read it afterwards from Pharo.
Also I think OSWinSubprocess is the only process  library working on 64-bit 
images.

HTH,
Christophe.

Re: [Pharo-dev] [Spec] Selected item in a list off screen

2020-04-09 Thread Christophe Demarey

Hi Hilaire,

You may want to follow https://github.com/pharo-spec/Spec/issues/866 .
What you could do for now in your presenter is:
 self selectIndex: anInteger.
 self verticalAlignment desiredVisibleRow: anInteger.
Hope this helps,
Christophe

> Le 9 avr. 2020 à 10:44, Esteban Lorenzano  a écrit :
> 
> Hi,
> 
>> On 9 Apr 2020, at 10:17, Hilaire  wrote:
>> 
>> Thanks Esteban. There is not hurry. I just want to be sure about my own 
>> doing.
>> 
>> I will now write a dedicated workspace to let kids write, save and execute 
>> easily DrGeo script.
> 
> SpCodePresenter is your friend there :)
> (And I’m polishing details on it)
> 
> Esteban
> 
>> 
>> Hilaire
>> 
>> Le 08/04/2020 à 22:00, Esteban Lorenzano a écrit :
>>> There is an ongoing bug about list selections, I hope to work on it 
>>> tomorrow if time allows me.
>> 
>> -- 
>> Dr. Geo
>> http://drgeo.eu
>> 
>> 
>> 
> 
>

[Pharo-dev] [ANN] Pharo Launcher 2.0 released!

2020-04-17 Thread Christophe Demarey

Hi all,

Pharo Launcher 2.0 has just been released! It is available from
http://pharo.org/download .

This new version introduces major changes:
The UI has been fully rewritten using the new Spec2 framework
and the Commander2 library
. UI has been revamped to increase
usability, especially for newcomers. The main window is now composed of a
toolbar and the list of images. The template list is now available when
clicking on the new image button.
Documentation web site : All Pharo Launcher features are now explained in the
new documentation available at https://pharo-project.github.io/pharo-launcher.
You can contribute easily by clicking the *edit on GitHub* button.
You can now have many launch configurations for an image (VM to use, vm and
image arguments). It means you can use headless Pharo VM from Pharo Launcher.
When creating a new image, you can specify an initialisation script that will
be run once at the first image launch. It is useful to load your project code
in a stock Pharo image for example. See
https://pharo-project.github.io/pharo-launcher/create-images/#image-initialization-script
You can now define your own template sources in addition to official sources
(see
https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-list-of-template-categories),
including authenticated sources.
Improved image metadata. Pharo Launcher now manages all image metadata in a
single STON file (including description, Pharo version).

Big thanks to all contributors, including issue reports. It is also the
opportunity to thanks Damien Cassou, the original author of Pharo Launcher.

Here is the changelog:
Pharo Launcher v2.0

The list of closed issue is too long (68) to be listed but you can browse it
here:
https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Aclosed+closed%3A2019-07-09..2020-04-17
Here are some highlights:
New features:

Documentation web site
Image initialisation script
Launch configurations, headless VM support
User template file in addition to the official template file
Jenkins server template now support pipeline projects
Support of private Jenkins server
Support of authenticated HTTP server
Improvements:

Monitoring of image launch failures to give back the error message (if any)
Newly created image is automatically selected in the image list
Allow to set image description at creation time
Better error management (you will have the choice to ignore them or debug them)
Add a poor version column in image list
Speedup (especially when image repository has a lot of images)

Bug fixes:

Fix use of system unzip on Windows

Regards,
The Pharo team.

Re: [Pharo-dev] [SPAM] Re: [Pharo-users] [ANN] Pharo Launcher 2.0 released!

2020-04-18 Thread Christophe Demarey

Hi Graham,


> Le 18 avr. 2020 à 11:30, Graham McLeod  a écrit :
> 
> Hi
> 
> This looks like a major update with some very welcome features and improved 
> UI. 
> Very welcome and thanks for the work!
> 
> One item I would like to see is a mention in the help on implications of 
> upgrading from the existing 
> Pharo launcher. Bit nervous to install when I don't know what will become of 
> existing configurations in the old one. 
> I am assuming that the new one is independent and will simply start off 
> blank. It would be nice to have this tackled in the
> documentation. Maybe a short section on "Moving your configurations / images 
> from the old Launcher ».

Yes, you’re right!
Pharo Launcher is mostly compatible with the previous one.
When using Pharo Launcher 2.0, image metadata will be converted from the old 
format to the new one.
I added an upgrade section on Pharo Launcher documentation: 
https://pharo-project.github.io/pharo-launcher/installation/#upgrade-notes

Tell me if this is enough.
Regards,
Christophe

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Launcher 2.0 released!

2020-04-20 Thread Christophe Demarey

Hi Cédrick,

> Le 18 avr. 2020 à 10:09, Cédrick Béler  a écrit :
> 
> Great Job. It looks indeed nicer.
> 
> I found the docs great too (https://pharo-project.github.io/pharo-launcher 
> <https://pharo-project.github.io/pharo-launcher>).
> 
> One suggestion would be to add the help contextually. I tried to look at. 
> There is description of commands and SpLinkPresenter but don’t think it’s 
> easy to add. I wanted to add the ling in the help description.

Indeed, good idea. Unfortunately, Spec2 does not yet allow to mix text and 
links.
Probably a new presenter would be needed to support this scenario. Also, it 
depends on what is doable with the gtk backend.
Esteban?

Cheers,
Christophe

> 
> For instance, the one to create an image for template:
> WebBrowser openOn: 
> 'https://pharo-project.github.io/pharo-launcher/create-images/‘ 
> <https://pharo-project.github.io/pharo-launcher/create-images/%E2%80%98>
> 
> Any way of doing that ?
> 
> 
> 
> Cheers,
> 
> Cédrick
> 
> 
> 
>> Le 17 avr. 2020 à 18:08, Christophe Demarey > <mailto:christophe.dema...@inria.fr>> a écrit :
>> 
>> Hi all,
>> 
>> Pharo Launcher 2.0 has just been released! It is available from 
>> http://pharo.org/download <http://pharo.org/download>.
>> 
>> This new version introduces major changes:
>> The UI has been fully rewritten using the new Spec2 framework 
>> <https://github.com/pharo-spec/Spec> and the Commander2 library 
>> <https://github.com/pharo-spec/Commander2>. UI has been revamped to increase 
>> usability, especially for newcomers. The main window is now composed of a 
>> toolbar and the list of images. The template list is now available when 
>> clicking on the new image button.
>> Documentation web site : All Pharo Launcher features are now explained in 
>> the new documentation available at 
>> https://pharo-project.github.io/pharo-launcher 
>> <https://pharo-project.github.io/pharo-launcher>. You can contribute easily 
>> by clicking the *edit on GitHub* button.
>> You can now have many launch configurations for an image (VM to use, vm and 
>> image arguments). It means you can use headless Pharo VM from Pharo Launcher.
>> When creating a new image, you can specify an initialisation script that 
>> will be run once at the first image launch. It is useful to load your 
>> project code in a stock Pharo image for example. See 
>> https://pharo-project.github.io/pharo-launcher/create-images/#image-initialization-script
>>  
>> <https://pharo-project.github.io/pharo-launcher/create-images/#image-initialization-script>
>> You can now define your own template sources in addition to official sources 
>> (see 
>> https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-list-of-template-categories
>>  
>> <https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-list-of-template-categories>),
>>  including authenticated sources.
>> Improved image metadata. Pharo Launcher now manages all image metadata in a 
>> single STON file (including description, Pharo version).
>> 
>> Big thanks to all contributors, including issue reports. It is also the 
>> opportunity to thanks Damien Cassou, the original author of Pharo Launcher.
>> 
>> Here is the changelog:
>> Pharo Launcher v2.0 
>> <https://github.com/pharo-project/pharo-launcher/releases/tag/2.0>
>> 
>> The list of closed issue is too long (68) to be listed but you can browse it 
>> here: 
>> https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Aclosed+closed%3A2019-07-09..2020-04-17
>>  
>> <https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Aclosed+closed%3A2019-07-09..2020-04-17>
>> Here are some highlights:
>> New features:
>> 
>> Documentation web site
>> Image initialisation script
>> Launch configurations, headless VM support
>> User template file in addition to the official template file
>> Jenkins server template now support pipeline projects
>> Support of private Jenkins server
>> Support of authenticated HTTP server
>> Improvements:
>> 
>> Monitoring of image launch failures to give back the error message (if any)
>> Newly created image is automatically selected in the image list
>> Allow to set image description at creation time
>> Better error management (you will have the choice to ignore them or debug 
>> them)
>> Add a poor version column in image list
>> Speedup (especially when image repository has a lot of images)
>> 
>> Bug fixes:
>> 
>> Fix use of system unzip on Windows
>> 
>> Regards,
>> The Pharo team.
>

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

2020-08-30 Thread Christophe Demarey

Hi Dale,

> Le 29 août 2020 à 19:40, Dale Henrichs  a 
> écrit :
> 
> So close, the interactive tests are passing, but there is a use case that 
> is popping up in a travis job[1] where this url 
> http://smalltalkhub.com/mc/Swazoo/Swazoo/main 
>  is being used (no trailing 
> slash) and this form of the url still produces the `raw` listing,
> 

Are you sure? For me, http://smalltalkhub.com/mc/Swazoo/Swazoo/main 
 produces the html listing

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

Hi Dale,

Thanks for the very detailed explanation.
I updated the href link to only include the mcz file name. I also took the 
opportunity to display a nicer URL and set up a permanent redirection to the 
current mc repository folder (else links would be broken : we must keep only 
file names, paths prohibited).
Tell me if it is ok.

Also, I will not reinvent the past but I think It was a mistake to use an html 
listing as input for tools. A raw list of files contained in the Monticello 
repository would have been better.It is also strange to use an href link value 
as the name of the mcz file. If the displayed text of the link was used, it 
would have allow to store mcz files at any place on the web server.
But anyway, if things work fine now, we are done!

Cheers,
Christophe

> Le 31 août 2020 à 21:02, Dale Henrichs  a 
> écrit :
> 
> Okay, I've finally sorted things out ... and it gets down to the difference 
> between MCHttpRepository>>parseFileNamesFromStream: returning an empty list 
> (the original problem) and returning a list of the wrong thing the current 
> problem). When I reported that the "manual test" was passing, that was true, 
> but instead of listing the names of the packages, the "manual test" was 
> returning a list of urls, and not a list of packageNames and I didn't 
> recognize the difference --- but the code that is executing in the travis 
> test does recognize the difference. 
> 
> The GemStone code does not special case SmalltalkHub, while Pharo does handle 
> SmalltalkHub as a special case and to actually see the difference between the 
> two, you have to use the following expression (the  MCHttpRepository 
> class>>location:user:password: is intercepted and creates an 
> MCSqueaksourceRepository instance, which has different implementation of 
> parseFileNamesFromStream:):
> 
> (MCHttpRepository new
> location: 'http://smalltalkhub.com/mc/Swazoo/Swazoo/main 
> <http://smalltalkhub.com/mc/Swazoo/Swazoo/main>';
> user: '';
> password: '';
> yourself) allFileNames
> Both Pharo and GemStone, use the pretty much same code for 
> MCHttpRepository>>parseFileNamesFromStream: (this is the GemStone version):
> 
> parseFileNamesFromStream: aStream
>   | names fullName |
>   names := OrderedCollection new.
>   [ aStream atEnd ]
> whileFalse: [ 
>   [ 
>   aStream upTo: $<.
>   aStream atEnd
> ifTrue: [ true ]
> ifFalse: [ 
>   {$a.
>   $A.
>   nil} includes: aStream next ] ]
> whileFalse.
>   aStream upTo: $".
>   aStream atEnd
> ifFalse: [ 
>   fullName := aStream upTo: $".
>   names add: fullName unescapePercents ] ].
>   ^ names
> and both return the same result when pointed at 
> http://www.squeaksource.com/MooseSQL <http://www.squeaksource.com/MooseSQL> 
> (you should recognize the EyeCollectionInspector from Pharo3.0:) and the 
> other inspector is from tODE ... Note that both are producing a list of .mcz 
> file names:
> 
> 
> 
> And when the expression:
> (MCHttpRepository new
> location: 'http://smalltalkhub.com/mc/Swazoo/Swazoo/main 
> <http://smalltalkhub.com/mc/Swazoo/Swazoo/main>';
> user: '';
> password: '';
> yourself) allFileNames
> 
> is used, both Pharo and GemStone produce the same (wrong) list of package 
> names from SmalltalkHub:
> 
> The travis test is trying to scan for 
> ConfigurationOfSwazoo2 package names in the list and that algorithm is 
> failing because it expects only a list of .mcz file names as produced like 
> that produced for http://www.squeaksource.com/MooseSQL 
> <http://www.squeaksource.com/MooseSQL> ... 
> 
> The difference boils down to how the `href` statements are formed. The Here 
> is the relevant statement from SqueakSource:
> 
>  href="Moose-SQL-Importer-FabrizioPerin.22.mcz">Moose-SQL-Importer-FabrizioPerin.22.mcz
> 
> and here is the statement from SmalltalkHub with the full url included in the 
> href field):
> 
> http://smalltalkhub.com/Swazoo/Swazoo/mc/Swazoo-HTTP-avi.4.mcz; 
> <http://smalltalkhub.com/Swazoo/Swazoo/mc/Swazoo-HTTP-avi.4.mcz>>Swazoo-HTTP-avi.4.mcz
> 
> So only the .mcz filename should be included in the href field as the code in 
> MCHttpRepository>>parseFileNamesFromStream: _is parsing the package name from 
> the href field_.
> 
> Dale
> 
> On 8/30/20 7:31 PM, Dale Henrichs wrote:
>> 
>> On 8/30/20 3:07 AM, Christophe Demarey wrote:
>>> Hi Dale,
>>> 
>>>> Le 29 août 2020 à 19:40, Dale Henrichs >>> <mailto:dale.henri...@gemtalksystems.com>> a écrit :
>&

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com



> Le 1 sept. 2020 à 12:21, Christophe Demarey  a 
> écrit :
> 
> Hi Tom,
> 
>> Le 1 sept. 2020 à 12:14, Tom Beckmann > <mailto:tomjon...@gmail.com>> a écrit :
>> 
>> Hi everyone,
>> 
>> not quite sure what's happening yet, but bootstrapping Metacello in Squeak 
>> will attempt to download
>> http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz 
>> <http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz>
>> which currently returns a 302 to
>> http://smalltalkhub.com/dkh/metacello/mc?format=raw-html 
>> <http://smalltalkhub.com/dkh/metacello/mc?format=raw-html>
>> which just returns the index page's HTML instead of the mcz file.
>> 
>> Is this possibly a slip in the matching rules you added recently?-
> 
> I think so. I did not see it while testing in my browser (probably because of 
> its cache) but I can see it with curl.
> I will fix that ASAP.

Should be ok now.
Let me know.

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

Hi Tom,

> Le 1 sept. 2020 à 12:14, Tom Beckmann  a écrit :
> 
> Hi everyone,
> 
> not quite sure what's happening yet, but bootstrapping Metacello in Squeak 
> will attempt to download
> http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz 
> 
> which currently returns a 302 to
> http://smalltalkhub.com/dkh/metacello/mc?format=raw-html 
> 
> which just returns the index page's HTML instead of the mcz file.
> 
> Is this possibly a slip in the matching rules you added recently?-

I think so. I did not see it while testing in my browser (probably because of 
its cache) but I can see it with curl.
I will fix that ASAP.

Thanks for reporting.
Christophe

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com