image file name changed on image save 
Author Message
 image file name changed on image save
I have run into a rather disturbing 'feature' in VW, which is especially
impractical for MS-Windows users. I use Win2k and I like to start an image
by double-clicking on the image file. The simple but effective mechanism
that MS-Windows offers for this is to set up a file type that will be
associated with a specific file extension. This works quite well and it also
makes it easy to keep several Smalltalk installations, with their own VMs
and other asssociated files, around at the same time, and start each image
with the correct VM anyway.

extension --> VM

.va552 --> VisualAge 5.5.2 runtime
.va6 --> VisualAge 6.0 runtime
.vw5i4 --> VisualWorks 5i.4 runtime
.vw7b --> VisualWorks 7 beta runtime
...etc...

And not only does double-clicking work to start each image in the correct
way, I can also see immediately what kind of image file I'm dealing with,
just by looking at its name.

So, everything is wonderful and life is great, except...when I save the
image in VisualWorks, the prompter that asks me for the file name to save
the image to, cuts off the file extension. Then when I put it back myself,
it adds .im to the file name, whether I want this or not. This is extremely
inconvenient. Perhaps some part of the system expected image files to have a
.im extension? In any case, this is not required now, so I would suggest
that thsi feature be removed. While that is being done, using the standard
platform file dialog might be a good idea as well.

VA is different, and respects my choice of naming the image as well as using
a normal platform file dialog.

Any chance this behavior will be changed in VW, or is there some reason I am
unaware of that the system should make sure it always saves images to .im
files, and always removes other file name extensions?

Regards,

Peter van Rooijen



Mon, 03 Jan 2005 19:18:01 GMT  
 image file name changed on image save

Quote:

> extension --> VM

VW now comes with a loader program that will decide which VM version to
start depending on the image's version bytes. For windows this is the
VisualWorks.exe/VisualWorks.ini pair.

So associate .im --> VisualWorks.exe, tweak its VisualWorks.ini to point
to the relevant VMs and you're up and running. Note that this system
does an additional thing: it sets the $VISUALWORKS environment variable
correctly for the image's version, an essential feature your setup does
not accomplish.

Quote:
> So, everything is wonderful and life is great, except...when I save the
> image in VisualWorks, the prompter that asks me for the file name to save
> the image to, cuts off the file extension. Then when I put it back myself,
> it adds .im to the file name, whether I want this or not. This is extremely
> inconvenient. Perhaps some part of the system expected image files to have a
> ..im extension? In any case, this is not required now, so I would suggest
> that thsi feature be removed. While that is being done, using the standard
> platform file dialog might be a good idea as well.

Do you realize that the prompter is asking for _two_ filenames: xxx.im
and xxx.cha?

Anyway, you know how simple it is to tweak the dialog and the default
extentions ;-)

Quote:
> And not only does double-clicking work to start each image in the correct
> way, I can also see immediately what kind of image file I'm dealing with,
> just by looking at its name.

Nothing wrong with making the default extention version dependent, just
associate all these extentions with the same VisualWorks.exe mentioned
above so the env variable gets set at startup.

Reinout
-------



Mon, 03 Jan 2005 20:05:34 GMT  
 image file name changed on image save
you should use the VisualWorks exe instead, and the associated .ini
mapping file - it will allow the same thing (for VW)

On Thu, 18 Jul 2002 13:18:01 +0200, "Peter van Rooijen"

Quote:

>I have run into a rather disturbing 'feature' in VW, which is especially
>impractical for MS-Windows users. I use Win2k and I like to start an image
>by double-clicking on the image file. The simple but effective mechanism
>that MS-Windows offers for this is to set up a file type that will be
>associated with a specific file extension. This works quite well and it also
>makes it easy to keep several Smalltalk installations, with their own VMs
>and other asssociated files, around at the same time, and start each image
>with the correct VM anyway.

>extension --> VM

>.va552 --> VisualAge 5.5.2 runtime
>.va6 --> VisualAge 6.0 runtime
>.vw5i4 --> VisualWorks 5i.4 runtime
>.vw7b --> VisualWorks 7 beta runtime
>...etc...

>And not only does double-clicking work to start each image in the correct
>way, I can also see immediately what kind of image file I'm dealing with,
>just by looking at its name.

>So, everything is wonderful and life is great, except...when I save the
>image in VisualWorks, the prompter that asks me for the file name to save
>the image to, cuts off the file extension. Then when I put it back myself,
>it adds .im to the file name, whether I want this or not. This is extremely
>inconvenient. Perhaps some part of the system expected image files to have a
>.im extension? In any case, this is not required now, so I would suggest
>that thsi feature be removed. While that is being done, using the standard
>platform file dialog might be a good idea as well.

>VA is different, and respects my choice of naming the image as well as using
>a normal platform file dialog.

>Any chance this behavior will be changed in VW, or is there some reason I am
>unaware of that the system should make sure it always saves images to .im
>files, and always removes other file name extensions?

>Regards,

>Peter van Rooijen



Mon, 03 Jan 2005 20:21:26 GMT  
 image file name changed on image save

Quote:

> > extension --> VM

> VW now comes with a loader program that will decide which VM version to
> start depending on the image's version bytes. For windows this is the
> VisualWorks.exe/VisualWorks.ini pair.

Hi Reinout,

I know, but it does not do everything I want.

Quote:
> So associate .im --> VisualWorks.exe, tweak its VisualWorks.ini to point
> to the relevant VMs and you're up and running. Note that this system
> does an additional thing: it sets the $VISUALWORKS environment variable
> correctly for the image's version, an essential feature your setup does
> not accomplish.

I did not know that, thanks. It is unfortunate that this variable is needed.
Even the location of the source file is specified relative to it.

Quote:
> > So, everything is wonderful and life is great, except...when I save the
> > image in VisualWorks, the prompter that asks me for the file name to
save
> > the image to, cuts off the file extension. Then when I put it back
myself,
> > it adds .im to the file name, whether I want this or not. This is
extremely
> > inconvenient. Perhaps some part of the system expected image files to
have a
> > ..im extension? In any case, this is not required now, so I would
suggest
> > that thsi feature be removed. While that is being done, using the
standard
> > platform file dialog might be a good idea as well.

> Do you realize that the prompter is asking for _two_ filenames: xxx.im
> and xxx.cha?

You mean implicitly? If so, yes.

Quote:
> Anyway, you know how simple it is to tweak the dialog and the default
> extentions ;-)

I just tried and it looks easiest to just change the forced extension to
.vw7b for the moment.

Quote:
> > And not only does double-clicking work to start each image in the
correct
> > way, I can also see immediately what kind of image file I'm dealing
with,
> > just by looking at its name.

> Nothing wrong with making the default extention version dependent, just
> associate all these extentions with the same VisualWorks.exe mentioned
> above so the env variable gets set at startup.

Yup, as soon as you want to double-click multiple versions, that could be
the easiest route. Would be nice if the environment vars would be completely
eliminated, though (as VA does).

Regards,

Peter van Rooijen

- Show quoted text -

Quote:
> Reinout
> -------



Mon, 03 Jan 2005 21:33:32 GMT  
 image file name changed on image save
Peter,

Quote:
>>VW now comes with a loader program

> I know, but it does not do everything I want.

Please share with us what you think is missing.

Quote:
> It is unfortunate that this variable is needed.

The variable was a PITA in the past if you develeoped on multiple
versions, but the loader program solved that.

 > Even the location of the source file is specified relative to it.

The main purpose of $VISUALWORKS is to locate sources and parcels, what
are your qualms with it?
IMO the extra indirection is a good thing, I can share dev images with
other developers regardless of their VW setup or OS.

 > Would be nice if the environment vars would be completely

Quote:
> eliminated, though (as VA does).

You'll need to educate me:
How does VA find it's shared installation if you have development images
in several directories?
Is it inferred from the VM location?
Can VA share a single installation directory for multiple platforms
(like I sometimes do for Linux / Windows dual boot machines)?

Reinout
-------



Mon, 03 Jan 2005 22:06:38 GMT  
 image file name changed on image save

Quote:
> Peter,

> >>VW now comes with a loader program

> > I know, but it does not do everything I want.

> Please share with us what you think is missing.

I would like the ability to choose my image file names arbitrarily. I don't
care too much the system takes that name and appends .cha to it, although I
would prefer it was called something like .changeLog, or that I could set
the name (or the name derivation policy) freely in the image itself, or even
that the source would be saved in the image file.

It would be really nice, and very productive, if I could take a .vw5i4 image
file and send it to a friend or colleague, where it would run by
double-clicking. This was not realistic in the past, but at this point in
time I would not think twice about sending 10 or 20 MB to a colleague if it
means zero work and guaranteed reproduction of what I have on my machine.

Quote:
> > It is unfortunate that this variable is needed.

> The variable was a PITA in the past if you developed on multiple
> versions, but the loader program solved that.

Well that is great. Would it be fair to say it is still a workaround?
Creates a lot of coupling between installations, and I wonder if you could
support several installations of the same product-level (e.g., for running
development images and runtime images of the same product-level from
different installations).

Quote:
>  > Even the location of the source file is specified relative to it.

> The main purpose of $VISUALWORKS is to locate sources and parcels, what
> are your qualms with it?
> IMO the extra indirection is a good thing,

I agree.

Quote:
> can share dev images with
> other developers regardless of their VW setup or OS.

>  > Would be nice if the environment vars would be completely
> > eliminated, though (as VA does).

> You'll need to educate me:
> How does VA find it's shared installation if you have development images
> in several directories?
> Is it inferred from the VM location?

Well. I don't know all the rules by heart, but I normally don't need
per-image customized .ini files, so I simply tell the VM in a command-line
option (this is encapsulated in the Windows file type) where the .ini file
is, and this leads to the location of the Envy manager library and some
other (non-essential) files.

There is no sources file (the source is in Envy), and the doits are
maintained in a doit-log that is generated in the image directory. I hardly
ever use the doit-log though, which has to do with having Envy, no doubt. If
I want to override certain .ini file settings for a particular image, I can
create an .ini file with the same name prefix as the image file, and with
just the settings I want to override from the default .ini file.

Quote:
> Can VA share a single installation directory for multiple platforms
> (like I sometimes do for Linux / Windows dual boot machines)?

I have never tried that and I would not be surprised if this is not
possible. I suppose the Envy library could be shared, but I don't know how
much difference there is between the Windows and the Unix versions of the
rest of the product.

Regards,

Peter van Rooijen

Quote:
> Reinout
> -------



Mon, 03 Jan 2005 23:21:41 GMT  
 image file name changed on image save

Quote:
>>>I know, but it does not do everything I want.

>>Please share with us what you think is missing.

> I would like the ability to choose my image file names arbitrarily. I don't
> care too much the system takes that name and appends .cha to it, although I
> would prefer it was called something like .changeLog, or that I could set
> the name (or the name derivation policy) freely in the image itself,

OK, so you are not talking about the loader. This is the interaction
between OS convention (extention implies file type) and development
image. I guess it's obvious to us both that you will need to
roll-your-own here and that that is perfectly possible from within the
image.

 > or even that the source would be saved in the image file.

That is harder, we are talking not only about the .sou file but also
about the various .pst sources. IMO use of the $VISUALWORKS variable
solves this elegantly, moving all those sources into the image or it's
.cha file requires serious hacking I'd expect.

Quote:
> It would be really nice, and very productive, if I could take a .vw5i4 image
> file and send it to a friend or colleague, where it would run by
> double-clicking. This was not realistic in the past, but at this point in
> time I would not think twice about sending 10 or 20 MB to a colleague if it
> means zero work and guaranteed reproduction of what I have on my machine.

In the case of VW I send a .zip of the .im+.cha, bit more work but no
big deal. Using Store complicates it bit though, you'll need to add a
subdirectory of your image's dir which caches the sources of the Store
packages used, somewhat messy but not really a big deal. Obviously one
could have the image create such a .zip, but I haven't felt the need for
that yet.

If you are talking about a collegue without a development installation
the above won't work. Solving that seems questionable from the legal (VW
license) point of view.

Quote:
>>>It is unfortunate that this variable is needed.

>>The variable was a PITA in the past if you developed on multiple
>>versions, but the loader program solved that.

> Well that is great. Would it be fair to say it is still a workaround?
> Creates a lot of coupling between installations,

Huh?
It decouples the installation from the developement .im+.cha as you seem
to say later on:

 >>IMO the extra indirection is a good thing,
 >
 > I agree.

Anyway, IMO $VISUALWORKS plus the loader shows the right direction, but
isn't there yet. It would be nice if I could pass extra (version
specific) env vars or command line options without resorting to yet
another indirection like a batch file.

Quote:
> and I wonder if you could
> support several installations of the same product-level (e.g., for running
> development images and runtime images of the same product-level from
> different installations).

What problem do you anticipate?

As a developer I have one installation per product rev and start
deployment and development images with the same VM.

When I deploy I distribute a VM and a .im and a way to start them
(shortcut or batch file). In the case of MSWindows .im+VM can be
combined into a single .exe. Deployment images don't need/use $VISUALWORKS.

Quote:
>  so I simply tell the VM in a command-line
> option (this is encapsulated in the Windows file type) where the .ini file
> is, and this leads to the location of the Envy manager library and some
> other (non-essential) files.

You could try similair stuff with VW but you'll need to implement image
level command line switches for that. See the docu (AppDevGuide.pdf) for
ways to capture the commandline switches at image startup time.
You may want to pass $VISUALWORKS on the command line and import that
into the image, but that seems questionable to me, since the loader
nicely centralizes that info (nicer than the MS file associations at least).
Alternatively you could load a .st from the command line so you can have
arbritrary centralized settings, this could be useful. Again: you'll
have to roll your own (not difficult, see the docu mentioned above).

Quote:
> There is no sources file (the source is in Envy), and the doits are
> maintained in a doit-log that is generated in the image directory. I hardly
> ever use the doit-log though, which has to do with having Envy, no doubt.

Exactly. VW without envy requires use of the .cha if you lose control
over your image (even if you use Store).

Quote:
> If
> I want to override certain .ini file settings for a particular image, I can
> create an .ini file with the same name prefix as the image file, and with
> just the settings I want to override from the default .ini file.

VW does not support this level of granularity out of the box, see above.

In case you contemplate some hacking, you may want to consider the
following for yet another aproach:

http://wiki.cs.uiuc.edu/VisualWorks/How+to+run+an+image

Cheers!

Reinout
-------



Tue, 04 Jan 2005 01:20:18 GMT  
 image file name changed on image save

Quote:

> I would like the ability to choose my image file names arbitrarily. I don't
> care too much the system takes that name and appends .cha to it, although I
> would prefer it was called something like .changeLog, or that I could set
> the name (or the name derivation policy) freely in the image itself, or even
> that the source would be saved in the image file.

See Filename class>>changeExtension and Filename class>>#imageExtension
which are implemented in terms of #privateChangeExtension and
#privateImageExtension.

Quote:
> It would be really nice, and very productive, if I could take a .vw5i4 image
> file and send it to a friend or colleague, where it would run by
> double-clicking. This was not realistic in the past, but at this point in
> time I would not think twice about sending 10 or 20 MB to a colleague if it
> means zero work and guaranteed reproduction of what I have on my machine.

This is easy using either VisualWorks.exe or using your special
extensions above.  But you can also package up an image with the
VM as a single .exe. The image is stored in the VM .exe's resources
and can be gzipped to save ~50%.  See the betas\packaging directory
in vw5i.4 and packaging\win or packaging\mac in vw7.

Quote:
> > > It is unfortunate that this variable is needed.

> > The variable was a PITA in the past if you developed on multiple
> > versions, but the loader program solved that.

> Well that is great. Would it be fair to say it is still a workaround?
> Creates a lot of coupling between installations, and I wonder if you could
> support several installations of the same product-level (e.g., for running
> development images and runtime images of the same product-level from
> different installations).

The problem is how to locate a VM from the image file.
A "super" Smalltalk.exe would need to know the image
header formats of a wide variety of dialects, and have
a registry of engines, e.g. in an .ini file.  I think
this would make a great CampSmalltalk project.  It could
even be implemented in Smalltalk/MT or SmallScript.  I
have no problem with revealing the VW image header format,
and can't imagine that the other commercial vendors would
have a problem either.  Its only the image header, after all.

--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd



Tue, 04 Jan 2005 07:43:30 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. import Image vs from PIL import Image vs import PIL.Image

2. Saving images to file without display

3. To save Report preview image to file

4. save image Blob in a file

5. Saving multiple images into one tiff file.

6. Save viewport image to file

7. saving the font image to a file

8. TCL code to extract image information from uploaded image file

9. save canvas into an image file

10. How to save canvas contents to image file?

11. file-out from Envy image for use in non-envy image

12. Different Image file names in VAST 5.0

 

 
Powered by phpBB® Forum Software