Hi, > Le 9 nov. 2018 à 14:11, Mariano Martinez Peck <marianop...@gmail.com> a écrit > : > > > > On Fri, Nov 9, 2018, 10:06 Christophe Demarey <christophe.dema...@inria.fr > <mailto:christophe.dema...@inria.fr> wrote: > Hi Mariano, > > Le 8 nov. 2018 à 20:47, Mariano Martinez Peck <marianop...@gmail.com > <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.
