Hello,
Is there something wrong with the latest Pharo 7.0 32bits image? I got this error from Pharo Launcher: Cannot determine image version: image version file not found! Try to run this command in a shell to get more information on the problem: cd "/Users/julien/Documents/Pharo/vms/private/6521/Pharo.app/Contents/MacOS" && "/Users/julien/Documents/Pharo/vms/private/6521/Pharo.app/Contents/MacOS/Pharo" --headless "/Users/julien/Documents/Pharo/images/RTFExperiment-Iceberg/RTFExperiment-Iceberg.image" eval "(Smalltalk imagePath asFileReference parent) / 'pharo.version' writeStreamDo: [ :stream | |major minor| major := SystemVersion current major. minor := SystemVersion current minor. (major = 6 and: [ SystemVersion current highestUpdate >= 60509 ]) ifTrue: [ minor := 1 ]. stream << major asString; << minor asString ]" When trying to start it. If I run this script in the terminal, nothing is print but the process crashes returning 1 as exit code. Can someone relate this issue as well? Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 |
Administrator
|
Julien wrote
> Is there something wrong with the latest Pharo 7.0 32bits image? > I got this error from Pharo Launcher: This happened to me because Launcher did not create the `pharo.version` file. I copied one from another Pharo 7 image and it then worked. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cheers,
Sean |
When starting the image by hand in normal mode (like this):
"/Users/julien/Documents/Pharo/vms/private/68021/Pharo.app/Contents/MacOS/Pharo" "/Users/julien/Documents/Pharo/images/DrTest/DrTest.image » The image starts but I get a PrimitiveFailed for #fileDescriptorType:. Maybe it could help to find where this comes from. Cheers, Julien --- Julien Delplanque Doctorant à l’Université de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
|
Hi Julien,
On Mon, 20 Aug 2018 at 18:22, Julien <[hidden email]> wrote: > > When starting the image by hand in normal mode (like this): > > "/Users/julien/Documents/Pharo/vms/private/68021/Pharo.app/Contents/MacOS/Pharo" "/Users/julien/Documents/Pharo/images/DrTest/DrTest.image » > > The image starts but I get a PrimitiveFailed for #fileDescriptorType:. > > Maybe it could help to find where this comes from. This sounds like you are using an old VM with a new image. Try updating to the latest stable VM (dated Jun 2018 or later). Cheers, Alistair |
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
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
|
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 <[hidden email]> a écrit : |
Hi Christophe,
On Wed, 22 Aug 2018 at 09:36, Christophe Demarey <[hidden email]> 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. Cheers, Alistair |
Hi Alistair,
> Le 22 août 2018 à 12:02, Alistair Grant <[hidden email]> a écrit : > > Hi Christophe, > > On Wed, 22 Aug 2018 at 09:36, Christophe Demarey > <[hidden email]> 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 |
Hi Christophe,
On Wed, 22 Aug 2018 at 15:33, Christophe Demarey <[hidden email]> wrote: > > Hi Alistair, > > > Le 22 août 2018 à 12:02, Alistair Grant <[hidden email]> a écrit : > > > > Hi Christophe, > > > > On Wed, 22 Aug 2018 at 09:36, Christophe Demarey > > <[hidden email]> 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 |
In reply to this post by demarey
On Wed, 22 Aug 2018 at 21:33, Christophe Demarey
<[hidden email]> wrote: > > Hi Alistair, > > > Le 22 août 2018 à 12:02, Alistair Grant <[hidden email]> a écrit : > > > > Hi Christophe, > > > > On Wed, 22 Aug 2018 at 09:36, Christophe Demarey > > <[hidden email]> 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. The VM version auto-evaluation is great, but it would be useful for another column to explicitly show which VM version to use start an image, which was also a drop-down list so the VM could be individually select for each image. Entries could be "Default" (per existing settings configuration), "Stable", "Latest" plus a list of names of previously downloaded VMs. This would put people in the drivers seat when the auto-evaluation misses a beat. cheers -ben |
Hi, considering how important this is, shouldn't this become standard part of the VM? e.g. ./pharo-x-vm --support pharo-y.image Which will return * 1/yes/... if the VM can launch it * 2/maybe/unclear... if the VM cannot determine it (this is futureproofing, e.g. if you tried to launch Pharo 9 image with Pharo 7 VM) * 0/no/maxVersion/... returns the latest known VM version that was capable of launching the image (so VM will have a lookup table to check past image versions) or something along those lines... is there some scenario that wouldn't be covered by these three? Peter On Wed, Aug 22, 2018 at 4:34 PM Ben Coman <[hidden email]> wrote: On Wed, 22 Aug 2018 at 21:33, Christophe Demarey |
Hi Peter,
On Wed, 22 Aug 2018 at 19:33, Peter Uhnak <[hidden email]> wrote: > > Hi, > > considering how important this is, shouldn't this become standard part of the VM? > e.g. > > ./pharo-x-vm --support pharo-y.image > > Which will return > * 1/yes/... if the VM can launch it > * 2/maybe/unclear... if the VM cannot determine it (this is futureproofing, e.g. if you tried to launch Pharo 9 image with Pharo 7 VM) > * 0/no/maxVersion/... returns the latest known VM version that was capable of launching the image (so VM will have a lookup table to check past image versions) > > or something along those lines... is there some scenario that wouldn't be covered by these three? The current scenario. As I understand it, the VM is compatible with the image format, it is just a bit old and is missing a new primitive (and since this is within the development cycle we're not trying to keep backward compatibility, if you're using the latest pharo 7 image you should be using the latest pharo 7 VM, the rules will change once pharo 7 is released). It would be useful to have a Pharo version embedded in the header of the image. That could then be queried and the latest VM for that version used to start the image. I think that would cover the majority of cases. Cheers, Alistair |
In reply to this post by alistairgrant
Hi,
I just published a new version of the launcher: 1.4 (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 <[hidden email]> a écrit : |
Administrator
|
demarey wrote
> I just published a new version of the launcher Thanks! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cheers,
Sean |
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? Thanks, On Thu, Aug 23, 2018 at 12:16 PM Sean P. DeNigris <[hidden email]> wrote: demarey wrote |
Hi Mariano,
Le 8 nov. 2018 à 20:47, Mariano Martinez Peck <[hidden email]> 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. |
On Fri, Nov 9, 2018, 10:06 Christophe Demarey <[hidden email] wrote: Hi Mariano, 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? Thanks!
|
Hi,
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. |
On Fri, Nov 9, 2018 at 11:15 AM Christophe Demarey <[hidden email]> wrote:
OK, I understand. Thanks for the explanation Christophe. I can also confirm that the workaround of removing by hand the VM directory did fix my issue. Thanks! |
In reply to this post by demarey
Hi Christophe,
On Fri, 9 Nov 2018 at 15:15, Christophe Demarey <[hidden email]> wrote: > > For now, to work around the problem, I will add a windows to easily update the VMs from the launcher UI. It should be possible to check if there is a new VM by just requesting the headers for the download URL. You could then add a "Check for new VM" button / menu item, and maybe even have a setting to do it each time the launcher is started. Cheers, Alistair |
Free forum by Nabble | Edit this page |