vmmaker.h?
Locked
 
|
David - Is it possible to have VMMaker create a vmmaker.h file that one can include to determine the VMMaker version the VM was generated from? It would be enough if it says, e.g., #define VMMAKER_VERSION "3.11.3" This way we could use that in the relevant places to ensure we display which version the VM was generated from. Cheers, - Andreas |
|
|
On Tue, Sep 01, 2009 at 08:43:19PM -0700, Andreas Raab wrote: > > Is it possible to have VMMaker create a vmmaker.h file that one can > include to determine the VMMaker version the VM was generated from? It > would be enough if it says, e.g., > > #define VMMAKER_VERSION "3.11.3" > > This way we could use that in the relevant places to ensure we display > which version the VM was generated from. Good idea, this is in VMMaker-dtl.138 on SqueakSource. I put the macro in the existing interp.h header file, which is generated as src/vm/interp.h, so you should not need to #include anything. Dave |
|
|
2009/9/2 David T. Lewis <[hidden email]>: > > On Tue, Sep 01, 2009 at 08:43:19PM -0700, Andreas Raab wrote: >> >> Is it possible to have VMMaker create a vmmaker.h file that one can >> include to determine the VMMaker version the VM was generated from? It >> would be enough if it says, e.g., >> >> #define VMMAKER_VERSION "3.11.3" i think, it would be much better to have: #define VMMAKER_VERSION "VMMaker-dtl.138" and also, maybe: #define VMMAKER_DATESTAMP "3 Sep 2009 10:05 pm" >> >> This way we could use that in the relevant places to ensure we display >> which version the VM was generated from. > > Good idea, this is in VMMaker-dtl.138 on SqueakSource. > > I put the macro in the existing interp.h header file, which is generated > as src/vm/interp.h, so you should not need to #include anything. > > Dave > > -- Best regards, Igor Stasenko AKA sig. |
|
|
On 02.09.2009, at 23:38, Igor Stasenko wrote: > > 2009/9/2 David T. Lewis <[hidden email]>: >> >> On Tue, Sep 01, 2009 at 08:43:19PM -0700, Andreas Raab wrote: >>> >>> Is it possible to have VMMaker create a vmmaker.h file that one can >>> include to determine the VMMaker version the VM was generated >>> from? It >>> would be enough if it says, e.g., >>> >>> #define VMMAKER_VERSION "3.11.3" > > i think, it would be much better to have: > #define VMMAKER_VERSION "VMMaker-dtl.138" > > and also, maybe: > #define VMMAKER_DATESTAMP "3 Sep 2009 10:05 pm" That could be in addition to the actual version. But a release numbering scheme makes much more sense. Glad Dave introduced it. - Bert - |
|
|
2009/9/2 Bert Freudenberg <[hidden email]>: > > > On 02.09.2009, at 23:38, Igor Stasenko wrote: > >> >> 2009/9/2 David T. Lewis <[hidden email]>: >>> >>> On Tue, Sep 01, 2009 at 08:43:19PM -0700, Andreas Raab wrote: >>>> >>>> Is it possible to have VMMaker create a vmmaker.h file that one can >>>> include to determine the VMMaker version the VM was generated from? It >>>> would be enough if it says, e.g., >>>> >>>> #define VMMAKER_VERSION "3.11.3" >> >> i think, it would be much better to have: >> #define VMMAKER_VERSION "VMMaker-dtl.138" >> >> and also, maybe: >> #define VMMAKER_DATESTAMP "3 Sep 2009 10:05 pm" > > That could be in addition to the actual version. But a release numbering > scheme makes much more sense. Glad Dave introduced it. > oh, it looks like i missed something, but hey, what is the reason to introduce the numbering, while we already having a numbering scheme which going straight from MC? I think its a most easiest way for anyone to tell: i have a VM , based on VMMaker-bla-bla instead of X.Y.Z so, you can quickly determine where you should look at and try to fix it , instead of "converting" a numeric version to corresponding MC package. As to me it looks like an unnecessary brain muscles excersise :) > > - Bert - > > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Igor Stasenko
On Wed, Sep 02, 2009 at 02:38:05PM -0700, Igor Stasenko wrote: > > 2009/9/2 David T. Lewis <[hidden email]>: > > > > On Tue, Sep 01, 2009 at 08:43:19PM -0700, Andreas Raab wrote: > >> > >> Is it possible to have VMMaker create a vmmaker.h file that one can > >> include to determine the VMMaker version the VM was generated from? It > >> would be enough if it says, e.g., > >> > >> #define VMMAKER_VERSION "3.11.3" > > i think, it would be much better to have: > #define VMMAKER_VERSION "VMMaker-dtl.138" > > and also, maybe: > #define VMMAKER_DATESTAMP "3 Sep 2009 10:05 pm" Class VMMaker has a #versionString method that currently answers '3.11.3'. The value is changed (manually iff I remember to do so) when changes are made to the VMMaker package as a whole. This is a convention that Tim put in place a long time ago (at my suggestion actually), so it now provides a convenient way to provide an approximate version identification for the VM source that is generated from VMMaker. Ian has started identifying the Unix VM version (as reported in one of the system attributes at run time) using a string consisting of the VMMaker version and the Subversion revision level. This gives a reasonably good identification of the platforms code plus VMMaker code. Andreas suggested making the VMMaker versionString accessible as a macro definition, presumably so that he can do something similar to what Ian did, but without all the grepping and sedding. Hence this change to add the VMMAKER_VERSION macro in a header file. Generating the VMMAKER_VERSION macro is automatic now, so the only thing that a person who updates the VMMaker package needs to remember is to update the VMMaker class>>versionString method whenever something significant changes in the VMMaker package. Dave |
|
|
2009/9/2 David T. Lewis <[hidden email]>: > > On Wed, Sep 02, 2009 at 02:38:05PM -0700, Igor Stasenko wrote: >> >> 2009/9/2 David T. Lewis <[hidden email]>: >> > >> > On Tue, Sep 01, 2009 at 08:43:19PM -0700, Andreas Raab wrote: >> >> >> >> Is it possible to have VMMaker create a vmmaker.h file that one can >> >> include to determine the VMMaker version the VM was generated from? It >> >> would be enough if it says, e.g., >> >> >> >> #define VMMAKER_VERSION "3.11.3" >> >> i think, it would be much better to have: >> #define VMMAKER_VERSION "VMMaker-dtl.138" >> >> and also, maybe: >> #define VMMAKER_DATESTAMP "3 Sep 2009 10:05 pm" > > Class VMMaker has a #versionString method that currently answers '3.11.3'. > The value is changed (manually iff I remember to do so) when changes are > made to the VMMaker package as a whole. This is a convention that Tim > put in place a long time ago (at my suggestion actually), so it now provides > a convenient way to provide an approximate version identification for the > VM source that is generated from VMMaker. > > Ian has started identifying the Unix VM version (as reported in one of > the system attributes at run time) using a string consisting of the > VMMaker version and the Subversion revision level. This gives a reasonably > good identification of the platforms code plus VMMaker code. > > Andreas suggested making the VMMaker versionString accessible as a > macro definition, presumably so that he can do something similar to > what Ian did, but without all the grepping and sedding. Hence this change > to add the VMMAKER_VERSION macro in a header file. > > Generating the VMMAKER_VERSION macro is automatic now, so the only thing > that a person who updates the VMMaker package needs to remember is to > update the VMMaker class>>versionString method whenever something > significant changes in the VMMaker package. > "3.11.3" -> VMMaker.dtl.123 or -> VMMaker.dtl.345 and so on, in order to quickly find the package version and then load it and check it out... Now consider , you are resigned, and all current VM devs are resigned. But someone else joined and couldn't find any specs in mailing archives, how to translate the numeric version into corresponding package version.. And from then on, the only choice he's having is to download a VMMaker packages one by one, hoping that one of then will have the same version he looking for... Ask yourself, do you want to be in place of such pool soul? > Dave > > -- Best regards, Igor Stasenko AKA sig. |
|
|
Igor Stasenko wrote: > Ask yourself, do you want to be in place of such pool soul? Yes. Absolutely, 100%, yes. If that is *actually* an issue (which it has never been in the past) I'd be happy to include the VMMaker MCZ that was used in the source release. The thing that I *don't* want is to ship versions of VMs where an end-user needs to figure out whether she is going to use "SqueakVM-Win32-ar.467" or "SqueakVM-Win32-dtl.468". These numbering schemes make no sense whatseover outside of this tiny community. I like schemes that are roughly in sync with the image release. That way a user who has a Squeak-3.5 image has a chance to figure out that in order to run it they probably need a Squeak-3.5.x VM. Cheers, - Andreas |
|
|
2009/9/2 Andreas Raab <[hidden email]>: > > Igor Stasenko wrote: >> >> Ask yourself, do you want to be in place of such pool soul? i meant "poor soul". > > Yes. Absolutely, 100%, yes. If that is *actually* an issue (which it has > never been in the past) I'd be happy to include the VMMaker MCZ that was > used in the source release. > > The thing that I *don't* want is to ship versions of VMs where an end-user > needs to figure out whether she is going to use "SqueakVM-Win32-ar.467" or > "SqueakVM-Win32-dtl.468". These numbering schemes make no sense whatseover > outside of this tiny community. > > I like schemes that are roughly in sync with the image release. That way a > user who has a Squeak-3.5 image has a chance to figure out that in order to > run it they probably need a Squeak-3.5.x VM. which didn't helped me last time when i tried to run closure-enabled image using old non-closure VM. Its simply refusing to run, saying that i'm having a wrong file format (blah blah whatever). Partly, because after unpacking the archive, i getting a Squeak.exe , not a Squeak.X.y.z.exe and from that point its really easy to mix thing up. In reverse (when VM is much more recent than image) i doubt that we (and consequently - noobs) have any problems, because VM's always trying to play nicely with old images. A command-line option ,like squeak --version which prints an extensional information about VM would help a lot. concerning keeping VM/Image versions roughly in sync.. well , it maybe having some sense for a outsiders and newbies, but admit that for developers it doing contrary - adds a bit confusion :) > > Cheers, > - Andreas > -- Best regards, Igor Stasenko AKA sig. |
|
|
Igor Stasenko wrote: > which didn't helped me last time when i tried to run closure-enabled > image using old non-closure VM. Its simply refusing > to run, saying that i'm having a wrong file format (blah blah whatever). > Partly, because after unpacking the archive, i getting a Squeak.exe , > not a Squeak.X.y.z.exe and from that point its > really easy to mix thing up. Yes, you got a point there. I'll fix that. Cheers, - Andreas |
|
|
In reply to this post by Igor Stasenko
On Wed, Sep 02, 2009 at 03:23:29PM -0700, Igor Stasenko wrote: > > and then you have to keep a list of versions, like: > > "3.11.3" -> VMMaker.dtl.123 > or -> VMMaker.dtl.345 > and so on, > in order to quickly find the package version and then load it and > check it out... If you know that your VM was built with sources generated from a version 3.11.3 level of VMMaker, then you can open your Monticello browser, look at the version history, and see that versionString "3.11.3" was set as of VMMaker-dtl.137, "3.11.2" was VMMaker-dtl.136, "3.11.1" was VMMaker-dtl.134, and so on. This is not perfect, but it is better than nothing. > Now consider , you are resigned, and all current VM devs are resigned. > But someone else joined and couldn't find any specs in mailing > archives, how to translate the > numeric version into corresponding package version.. > And from then on, the only choice he's having is to download a VMMaker > packages one by one, > hoping that one of then will have the same version he looking for... > Ask yourself, do you want to be in place of such pool soul? Well, I actually *am* such a poor soul, and I have personally been in exactly that position. That is that reason that I try to remember to note the VMMaker version string in the Montecello update comments whenever it changes (look though the update history with a Monticello browser, or look at the "News" tab of the VMMaker project on SqueakSource). That is also the reason that I try to make updates that tie back to Mantis entries whenever possible (even though I probably annoy people by entering "bugs" in Mantis and then "resolving" them myself). If I get run over by a truck today, you can take responsibility for VMMaker tomorrow and nothing will be lost. Dave |
|
|
2009/9/2 David T. Lewis <[hidden email]>: > > On Wed, Sep 02, 2009 at 03:23:29PM -0700, Igor Stasenko wrote: >> >> and then you have to keep a list of versions, like: >> >> "3.11.3" -> VMMaker.dtl.123 >> or -> VMMaker.dtl.345 >> and so on, >> in order to quickly find the package version and then load it and >> check it out... > > If you know that your VM was built with sources generated from a version > 3.11.3 level of VMMaker, then you can open your Monticello browser, look > at the version history, and see that versionString "3.11.3" was set as of > VMMaker-dtl.137, "3.11.2" was VMMaker-dtl.136, "3.11.1" was VMMaker-dtl.134, > and so on. This is not perfect, but it is better than nothing. > >> Now consider , you are resigned, and all current VM devs are resigned. >> But someone else joined and couldn't find any specs in mailing >> archives, how to translate the >> numeric version into corresponding package version.. >> And from then on, the only choice he's having is to download a VMMaker >> packages one by one, >> hoping that one of then will have the same version he looking for... >> Ask yourself, do you want to be in place of such pool soul? > > Well, I actually *am* such a poor soul, and I have personally been in > exactly that position. That is that reason that I try to remember to > note the VMMaker version string in the Montecello update comments whenever > it changes (look though the update history with a Monticello browser, or > look at the "News" tab of the VMMaker project on SqueakSource). That is > also the reason that I try to make updates that tie back to Mantis > entries whenever possible (even though I probably annoy people by entering > "bugs" in Mantis and then "resolving" them myself). If I get run over > by a truck today, you can take responsibility for VMMaker tomorrow and > nothing will be lost. > So, can we have a cake and eat it too? Like having a #define as following: #define COMPLETE_VERSION_STRING VM_VERSION VM_MAKER_VERSION SVN_VERSION and user could usually see something like: Squeak VM 3.4.5. (VMMaker.dtl.xyz) (SVN-bla-bla-x,y,z) > Dave > > -- Best regards, Igor Stasenko AKA sig. |
|
|
On Thu, Sep 03, 2009 at 03:00:35AM -0700, Igor Stasenko wrote: > > So, can we have a cake and eat it too? > > Like having a #define as following: > > > #define COMPLETE_VERSION_STRING VM_VERSION VM_MAKER_VERSION SVN_VERSION > > and user could usually see something like: > > Squeak VM 3.4.5. (VMMaker.dtl.xyz) (SVN-bla-bla-x,y,z) That is similar to what Ian is doing now. It's implemented in the script platforms/unix/cmake/configure. Maybe you can borrow some ideas from Ian's script. Dave |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |