On 8 March 2013 10:07, Sven Van Caekenberghe <[email protected]> wrote: > > On 08 Mar 2013, at 09:45, Camillo Bruni <[email protected]> wrote: > >> On 2013-03-08, at 02:52, "David T. Lewis" <[email protected]> wrote: >> >>> On Thu, Mar 07, 2013 at 11:23:22PM +0100, Sven Van Caekenberghe wrote: >>>> Hi Eliot, >>>> >>>> On 07 Mar 2013, at 23:12, Eliot Miranda <[email protected]> wrote: >>>> >>>>> I seem to be talking to thin air. If you would use an up-to-date VM your >>>>> crashes would disappear. This bug was fixed this last week. You are >>>>> using a VM from December of last year. Of course if you don't want to >>>>> fix your bug lease continue to ignore anything I might have to say. >>>> >>>> I tried using your latest cog vm, but the Pharo 2.0 image side check >>>> complained: >>>> >>>> checkVMVersion >>>> "Display a warning if the VM is too old" >>>> | displayError | >>>> displayError := [ ^ self inform: 'Your VM is too old for this image. >>>> Please download the latest VM.' ]. >>>> [(VirtualMachine interpreterSourceDate > '2012-07-08+2:00' asDate) >>>> ifFalse: displayError >>>> ] on: Error do: [ :e| displayError value ]. >>>> >>>> I was unsure if this was a real problem or not ? >>> >>> This method in the image is completely wrong and misleading. The VM that >>> was being used is clearly *not* out of date. If the intent is to give the >>> user a message that says "please use only the latest Pharo VM", then it >>> should >>> say so. >> >> Pharo ships with the PharoVM, hence the targeted audience will have an >> outdated >> PharoVM, we can make the message more explicit, but it IS an outdate VM no >> matter >> what. >> >> Besides, we print the VM version date in a different format, which won't >> lead to >> a parsing error. If you run this on a VM not built by us you get a VM out of >> date. >> >>> To check explicitly for a Pharo VM I would suggest adding a primitive or VM >>> parameter that identifies the VM as Pharo-specific so the checkVMVersion can >>> distinguish an out-of-date Pharo VM and provide an appropriate warning >>> message. >> >> yes we could update the error message to inform that the user should download >> the latest PharoVM. But as I said before, Pharo is shipped with the branded >> PharoVM, to limit the confusion for newcomers. CogVM, NBCogCM, StackVM, >> SqueakVM >> and guess not what other names are simply not parseable by newcomers. >> >>> It is really not fair to ask Eliot to spend his time debugging "Cog >>> problems" >>> when the image is sending incorrect error messages. >> >> well, he is free to adopt our additions we made to the FileSystem primitives >> and >> integrate NativeBoost. >> >> Only if those are integrated I see reason to make this error message >> disappear on >> other VMs than ours. Otherwise not displaying the error message is misleading >> behavior as well FOR THE WHOLE COMMUNITY. > > Thanks for the explanation, Camillo. > > The crux of the matter is the point about the FileSystem primitives and > NativeBoost. > The test itself is misleading as it only seems to check a date and then > declares VM's too old. > Maybe it should test for the primitives, if that is possible.
> Also the warning 'Too old' should be changed to 'Does not contain the > necessary primitives to run Pharo' if I understand correctly. > hmm.. then your tests will define "today's old VM" but since things are moving, you have to throw this test away fairly soon.. to avoid that, i would check the version / VM release date.. but not some concrete feature, because at longer time scale it makes no sense. And to cover features, we have unit tests :) > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > -- Best regards, Igor Stasenko.
