Smalltalk › Cincom › VisualWorks

[VW 7.7] What is the best ( compact )way to store images in VW ?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Mark Pirogovsky-3

[VW 7.7] What is the best ( compact )way to store images in VW ?

Hello All,

I need to build very graphical interface with a lot of pictures imported
from various JPG and PNG files.

What I am finding that when I import those files and install the
resulting images into the methods using normal VW facilities -- the
resulting method sizes are enormous.
For example, reasonable size PNG file ( 64 kb) which contains the
400@100 extent image - results in the method with size of about a 1 MB
when saved as Parcel with no sources.

Is there any way to store the Graphics information in the VW images
without blowing off disk and RAM sizes or the network download time?

I tried couple of things and here is the method I came up with:

1. I load the contents of the PNG file as Byte Array into the smalltalk
method.
2. then I read the Byte Array using the Image reader to produce an
Image when needed.

By doing this my the resulting Parcel size is about 100 kb ( order of
magnitude less) but I can see a delay when Interface rebuilds.
I think it should be something better out there, but I can't thing of
anything at the moment.

What others are doing in the situation like this ?

Any Information is greatly appreciated...

--Mark Pirogovsky

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris Popov, DeepCove Labs (SNN)

Re: [VW 7.7] What is the best ( compact )way to store images inVW ?

Have a look at Assets package (and Assets-IDE), it was mentioned on the
list recently. It doesn't store images as original bytes, but rather
packed string for the kind of image it stores (or bytes for non-image
resources), not sure about size implications. It also caches these
resources using #once pattern.

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Mark Pirogovsky
Sent: Wednesday, March 09, 2011 5:27 PM
To: [hidden email]
Subject: [vwnc] [VW 7.7] What is the best ( compact )way to store images
inVW ?

Hello All,

I need to build very graphical interface with a lot of pictures imported
from various JPG and PNG files.

What I am finding that when I import those files and install the
resulting images into the methods using normal VW facilities -- the
resulting method sizes are enormous.
For example, reasonable size PNG file ( 64 kb) which contains the
400@100 extent image - results in the method with size of about a 1 MB
when saved as Parcel with no sources.

Is there any way to store the Graphics information in the VW images
without blowing off disk and RAM sizes or the network download time?

I tried couple of things and here is the method I came up with:

1. I load the contents of the PNG file as Byte Array into the smalltalk

method.
2. then I read the Byte Array using the Image reader to produce an
Image when needed.

By doing this my the resulting Parcel size is about 100 kb ( order of
magnitude less) but I can see a delay when Interface rebuilds.
I think it should be something better out there, but I can't thing of
anything at the moment.

What others are doing in the situation like this ?

Any Information is greatly appreciated...

--Mark Pirogovsky

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

mkobetic

Re: [VW 7.7] What is the best ( compact )way to store images inVW ?

"Boris Popov, DeepCove Labs"<[hidden email]> wrote:

> Date: March 9, 2011 5:38:49 PM
> From: "Boris Popov, DeepCove Labs" <[hidden email]>
> To: "Mark Pirogovsky"<[hidden email]>, <[hidden email]>
> Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images inVW ?
>
> Have a look at Assets package (and Assets-IDE), it was mentioned on the
> list recently. It doesn't store images as original bytes, but rather
> packed string for the kind of image it stores (or bytes for non-image
> resources), not sure about size implications. It also caches these
> resources using #once pattern.

I used Assets to store few fairly small images for my ESUG presentation. However importing them as they were added 9M of source code. Compressing the image bits took it down to about 250K. The simplest way to make that happen seemed to be tweaking the ByteArray>>storeOn: to compress the bytes before turning them into the packed string thing. That's what the attached does. It only goes for the compressed bytes if they are significantly smaller than the uncompressed ones would be. The way I understand the "packing" it turns every 6 bits into a character, so packed string should be ~ 20% larger than the original array. So it compares the compressed packed string to the size of the original array, which should give us the margin of 20% compression at least. Of course there's the minor down-side that it needs Compression-ZLib so it won't work in vanilla visual.im.

HTH,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

ByteArray-asCompressedPackedString.st (2K) Download Attachment

Steven Kelly

Re: [VW 7.7] What is the best ( compact )way to store images inVW ?

In reply to this post by Mark Pirogovsky-3

[vwnc] [VW 7.7] What is the best ( compact )way to store images inVW ?

If you're storing as parcels with no source, I imagine the best way is as a literal ByteArray of the original PNG/JPG file contents. If you're worried about source length, packedString will be shorter in the .pst, but longer in the .pcl, and slower to reconstruct into the PNG/JPG.

In either case you'll need to reconstruct to a Smalltalk image or pixmap, and as Boris said, you should make sure you only do that once for each image. Since the images will be displayed as part of your UI, i.e. redisplayed a lot, it's probably worth taking the extra initial time to make sure they are in the current image's palette (convertToPalette: Screen default colorPalette), and store the native OS resources (CachedImage on: myImage). That makes redisplay a lot faster.

If you can use WinGDIPlusInterface (i.e. you're just on Windows XP or newer), you may be able to use some of the GDI+ library's functions to read a PNG/JPG ByteArray and give you a native graphics handle, without ever making a Smalltalk Image. Something like "Graphics.WinGDIPlus.GDIPlusBitmap fromBytes: myPngByteArray". CairoGraphics might be able to do this too.

You can also think about when you want to convert the method into the final graphics resource you use. Doing all the images at parcel load time may make loading the parcel seem slow. Doing each image only when it is used may make displaying each window noticeably slow for the first time. One approach would be have each image converted as needed if it hasn't been yet, but also add a background process at a low priority that goes through all the images after parcel load and forces their conversion. You'd need to make sure the main UI process and this background process don't interfere with each other on the same image at the same time (I'm not sure how #once deals with this; doing it manually you'd probably use a Semaphore forMutualExclusion on whatever stores the resulting image).

HTH,

Steve

From: [hidden email] on behalf of Mark Pirogovsky
Sent: Thu 10/03/2011 00:26
To: [hidden email]
Subject: [vwnc] [VW 7.7] What is the best ( compact )way to store images inVW ?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Claus Kick

Re: [VW 7.7] What is the best ( compact )way to store images in VW ?

In reply to this post by Mark Pirogovsky-3

Probably a stupid question, but why do you need to store the images in the image at all?
Is reading from the file system in startup, using them and discarding them on VM-exit no alternative?

--
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy.
More clearly, on the narrow path between lunacy and panic.
Right around the corner of fear of death,
not far away from idiocy and insanity."

-----Ursprüngliche Nachricht-----
Von: "Mark Pirogovsky" <[hidden email]>
Gesendet: 09.03.2011 23:26:56
An: [hidden email]
Betreff: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?

>Hello All,
>
>I need to build very graphical interface with a lot of pictures imported
>from various JPG and PNG files.
>
>What I am finding that when I import those files and install the
>resulting images into the methods using normal VW facilities -- the
>resulting method sizes are enormous.
>For example, reasonable size PNG file ( 64 kb) which contains the
>400@100 extent image - results in the method with size of about a 1 MB
>when saved as Parcel with no sources.
>
>Is there any way to store the Graphics information in the VW images
>without blowing off disk and RAM sizes or the network download time?
>
>
>I tried couple of things and here is the method I came up with:
>
>1. I load the contents of the PNG file as Byte Array into the smalltalk
>method.
>2. then I read the Byte Array using the Image reader to produce an
>Image when needed.
>
>By doing this my the resulting Parcel size is about 100 kb ( order of
>magnitude less) but I can see a delay when Interface rebuilds.
>I think it should be something better out there, but I can't thing of
>anything at the moment.
>
>What others are doing in the situation like this ?
>
>Any Information is greatly appreciated...
>
>
>--Mark Pirogovsky
>
>_______________________________________________
>vwnc mailing list
>[hidden email]
>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris Popov, DeepCove Labs (SNN)

Re: [VW 7.7] What is the best ( compact )way to store images in VW ?

Claus,

The immediate benefit of storing them with the source code is 'free' version control and simplified deployment. I believe there's a way to attach arbitrary files to bucka...^^...pundles, but I'm not sure it's mature enough or exercised enough to recommend, but I hadn't actually played with it much, so I may be totally off on my assessment of this bit of functionality.

Regards,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Claus Kick
Sent: Friday, March 11, 2011 8:30 AM
To: [hidden email]; Mark Pirogovsky
Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?

Probably a stupid question, but why do you need to store the images in the image at all?
Is reading from the file system in startup, using them and discarding them on VM-exit no alternative?

--
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiocy and insanity."

-----Ursprüngliche Nachricht-----
Von: "Mark Pirogovsky" <[hidden email]>
Gesendet: 09.03.2011 23:26:56
An: [hidden email]
Betreff: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?

>Hello All,
>
>I need to build very graphical interface with a lot of pictures
>imported from various JPG and PNG files.
>
>What I am finding that when I import those files and install the
>resulting images into the methods using normal VW facilities -- the
>resulting method sizes are enormous.
>For example, reasonable size PNG file ( 64 kb) which contains the
>400@100 extent image - results in the method with size of about a 1 MB
>when saved as Parcel with no sources.
>
>Is there any way to store the Graphics information in the VW images
>without blowing off disk and RAM sizes or the network download time?
>
>
>I tried couple of things and here is the method I came up with:
>
>1. I load the contents of the PNG file as Byte Array into the
>smalltalk method.
>2. then I read the Byte Array using the Image reader to produce an
>Image when needed.
>
>By doing this my the resulting Parcel size is about 100 kb ( order of
>magnitude less) but I can see a delay when Interface rebuilds.
>I think it should be something better out there, but I can't thing of
>anything at the moment.
>
>What others are doing in the situation like this ?
>
>Any Information is greatly appreciated...
>
>
>--Mark Pirogovsky
>
>_______________________________________________
>vwnc mailing list
>[hidden email]
>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dennis smith-4

Re: [VW 7.7] What is the best ( compact )way to store images in VW ?

In reply to this post by Claus Kick

I realize I am jumping into this in the middle, sorry about that.

We use Gemstone as a database.

We keep things called "documents" and things called "images".
We have two types of images
- those associated with the code (e.g. icons for buttons), kept in
the code
- those associated with the data

Documents and Images (those associated with the data) we finally decided
to keep as files.
We "manage" the files -- we don't just point to the original source file
(which might be on
a personal PC). It gets a bit tricky to handle commit/abort while
juggling files, but we do
a pretty good job.

For "Documents" the user can "open one" which just asks windows to open
the file (we maintain the
extension and log the original source path as "information" - the
filename gets changed).
For images we maintain two (or more) files of the image
1. a .gif to quickly load and display in the Image
2. the original (gif/jpeg/...)
we use a free file manipulation utility named "EzThumbs" to convert to
gif, resize etc -- we always retain
the original file in the full resolution of the source so that we can DO
manipulations without losing information.

We USED to keep the gif's in Gemstone, but we stopped doing that.

On Mar 11/11 8:30 AM, Claus Kick wrote:

> Probably a stupid question, but why do you need to store the images in the image at all?
> Is reading from the file system in startup, using them and discarding them on VM-exit no alternative?
>
> --
> Claus Kick
>
> "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
> Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
> Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."
>
> "If you are looking for me: I am somewhere near to lunacy.
> More clearly, on the narrow path between lunacy and panic.
> Right around the corner of fear of death,
> not far away from idiocy and insanity."
>
> -----Ursprüngliche Nachricht-----
> Von: "Mark Pirogovsky"<[hidden email]>
> Gesendet: 09.03.2011 23:26:56
> An: [hidden email]
> Betreff: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>
>> Hello All,
>>
>> I need to build very graphical interface with a lot of pictures imported
> >from various JPG and PNG files.
>> What I am finding that when I import those files and install the
>> resulting images into the methods using normal VW facilities -- the
>> resulting method sizes are enormous.
>> For example, reasonable size PNG file ( 64 kb) which contains the
>> 400@100 extent image - results in the method with size of about a 1 MB
>> when saved as Parcel with no sources.
>>
>> Is there any way to store the Graphics information in the VW images
>> without blowing off disk and RAM sizes or the network download time?
>>
>>
>> I tried couple of things and here is the method I came up with:
>>
>> 1. I load the contents of the PNG file as Byte Array into the smalltalk
>> method.
>> 2. then I read the Byte Array using the Image reader to produce an
>> Image when needed.
>>
>> By doing this my the resulting Parcel size is about 100 kb ( order of
>> magnitude less) but I can see a delay when Interface rebuilds.
>> I think it should be something better out there, but I can't thing of
>> anything at the moment.
>>
>> What others are doing in the situation like this ?
>>
>> Any Information is greatly appreciated...
>>
>>
>> --Mark Pirogovsky
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Dennis Smith +1 416.798.7948
Cherniak Software Development Corporation Fax: +1 416.798.0948
509-2001 Sheppard Avenue East [hidden email]
Toronto, ON M2J 4Z8 sip:[hidden email]
Canada http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Claus Kick

Re: [VW 7.7] What is the best ( compact )way to store images in VW ?

In reply to this post by Boris Popov, DeepCove Labs (SNN)

Alright, version control makes sense. But still, if its so much a hassle to do, why not do it another way?
I would use subversion instead and use a couple of methods to commit assets to svn and store the version number in a class variable.
That way, there would be an easy way to retrieve the correct version for each deployment version.

--
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy.
More clearly, on the narrow path between lunacy and panic.
Right around the corner of fear of death,
not far away from idiocy and insanity."

-----Ursprüngliche Nachricht-----
Von: "Boris Popov, DeepCove Labs" <[hidden email]>
Gesendet: 11.03.2011 14:36:03
An: "Claus Kick" <[hidden email]>, [hidden email], "Mark Pirogovsky" <[hidden email]>
Betreff: RE: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?

>Claus,
>
>The immediate benefit of storing them with the source code is 'free' version control and simplified deployment. I believe there's a way to attach arbitrary files to bucka...^^...pundles, but I'm not sure it's mature enough or exercised enough to recommend, but I hadn't actually played with it much, so I may be totally off on my assessment of this bit of functionality.
>
>Regards,
>
>-Boris
>
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf Of Claus Kick
>Sent: Friday, March 11, 2011 8:30 AM
>To: [hidden email]; Mark Pirogovsky
>Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>
>
>Probably a stupid question, but why do you need to store the images in the image at all?
>Is reading from the file system in startup, using them and discarding them on VM-exit no alternative?
>
>--
>Claus Kick
>
>"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."
>
>"If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiocy and insanity."
>
>-----Ursprüngliche Nachricht-----
>Von: "Mark Pirogovsky" <[hidden email]>
>Gesendet: 09.03.2011 23:26:56
>An: [hidden email]
>Betreff: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>
>>Hello All,
>>
>>I need to build very graphical interface with a lot of pictures
>>imported from various JPG and PNG files.
>>
>>What I am finding that when I import those files and install the
>>resulting images into the methods using normal VW facilities -- the
>>resulting method sizes are enormous.
>>For example, reasonable size PNG file ( 64 kb) which contains the
>>400@100 extent image - results in the method with size of about a 1 MB
>>when saved as Parcel with no sources.
>>
>>Is there any way to store the Graphics information in the VW images
>>without blowing off disk and RAM sizes or the network download time?
>>
>>
>>I tried couple of things and here is the method I came up with:
>>
>>1. I load the contents of the PNG file as Byte Array into the
>>smalltalk method.
>>2. then I read the Byte Array using the Image reader to produce an
>>Image when needed.
>>
>>By doing this my the resulting Parcel size is about 100 kb ( order of
>>magnitude less) but I can see a delay when Interface rebuilds.
>>I think it should be something better out there, but I can't thing of
>>anything at the moment.
>>
>>What others are doing in the situation like this ?
>>
>>Any Information is greatly appreciated...
>>
>>
>>--Mark Pirogovsky
>>
>>_______________________________________________
>>vwnc mailing list
>>[hidden email]
>>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>_______________________________________________
>vwnc mailing list
>[hidden email]
>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris Popov, DeepCove Labs (SNN)

Re: [VW 7.7] What is the best ( compact )way to store images in VW ?

Simplified deployment is also attractive, we sync images up to our servers and don't have to worry about the assets. Similar simplicity also plays into building headful apps where image containing all resources can be bundled with the vm into one executable etcetera.

Sent from my iPhone

On 2011-03-20, at 16:24, "Claus Kick" <[hidden email]> wrote:

>
> Alright, version control makes sense. But still, if its so much a hassle to do, why not do it another way?
> I would use subversion instead and use a couple of methods to commit assets to svn and store the version number in a class variable.
> That way, there would be an easy way to retrieve the correct version for each deployment version.
>
>
> --
> Claus Kick
>
> "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
> Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
> Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."
>
> "If you are looking for me: I am somewhere near to lunacy.
> More clearly, on the narrow path between lunacy and panic.
> Right around the corner of fear of death,
> not far away from idiocy and insanity."
>
> -----Ursprüngliche Nachricht-----
> Von: "Boris Popov, DeepCove Labs" <[hidden email]>
> Gesendet: 11.03.2011 14:36:03
> An: "Claus Kick" <[hidden email]>, [hidden email], "Mark Pirogovsky" <[hidden email]>
> Betreff: RE: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>
>> Claus,
>>
>> The immediate benefit of storing them with the source code is 'free' version control and simplified deployment. I believe there's a way to attach arbitrary files to bucka...^^...pundles, but I'm not sure it's mature enough or exercised enough to recommend, but I hadn't actually played with it much, so I may be totally off on my assessment of this bit of functionality.
>>
>> Regards,
>>
>> -Boris
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Claus Kick
>> Sent: Friday, March 11, 2011 8:30 AM
>> To: [hidden email]; Mark Pirogovsky
>> Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>>
>>
>> Probably a stupid question, but why do you need to store the images in the image at all?
>> Is reading from the file system in startup, using them and discarding them on VM-exit no alternative?
>>
>> --
>> Claus Kick
>>
>> "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."
>>
>> "If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiocy and insanity."
>>
>> -----Ursprüngliche Nachricht-----
>> Von: "Mark Pirogovsky" <[hidden email]>
>> Gesendet: 09.03.2011 23:26:56
>> An: [hidden email]
>> Betreff: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>>
>>> Hello All,
>>>
>>> I need to build very graphical interface with a lot of pictures
>>> imported from various JPG and PNG files.
>>>
>>> What I am finding that when I import those files and install the
>>> resulting images into the methods using normal VW facilities -- the
>>> resulting method sizes are enormous.
>>> For example, reasonable size PNG file ( 64 kb) which contains the
>>> 400@100 extent image - results in the method with size of about a 1 MB
>>> when saved as Parcel with no sources.
>>>
>>> Is there any way to store the Graphics information in the VW images
>>> without blowing off disk and RAM sizes or the network download time?
>>>
>>>
>>> I tried couple of things and here is the method I came up with:
>>>
>>> 1. I load the contents of the PNG file as Byte Array into the
>>> smalltalk method.
>>> 2. then I read the Byte Array using the Image reader to produce an
>>> Image when needed.
>>>
>>> By doing this my the resulting Parcel size is about 100 kb ( order of
>>> magnitude less) but I can see a delay when Interface rebuilds.
>>> I think it should be something better out there, but I can't thing of
>>> anything at the moment.
>>>
>>> What others are doing in the situation like this ?
>>>
>>> Any Information is greatly appreciated...
>>>
>>>
>>> --Mark Pirogovsky
>>>
>>> _______________________________________________
>>> vwnc mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Paul Baumann

Re: [VW 7.7] What is the best ( compact )way to store images in VW ?

If your source defines the ByteArray like this:

'#[0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255]'

size 916

Then Base64 is a more compact encoding that can be embedded in source code.

| stream |
stream := (ByteArray new withEncoding: #BASE64) writeStream.
0 to: 255 do: [:v | stream nextPut: (Character value: v) ].
stream close stream contents asString size.

344

'AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/w=='

size 344

You might also try compressing the bytes before encoding it.

Sorry, that probably isn't good example code for the base64 encoder that comes with VW. I use the one in SRP.

Paul Baumann

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Boris Popov, DeepCove Labs
Sent: Sunday, March 20, 2011 16:30
To: Claus Kick
Cc: [hidden email]
Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?

Simplified deployment is also attractive, we sync images up to our servers and don't have to worry about the assets. Similar simplicity also plays into building headful apps where image containing all resources can be bundled with the vm into one executable etcetera.

Sent from my iPhone

On 2011-03-20, at 16:24, "Claus Kick" <[hidden email]> wrote:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Steven Kelly

Re: [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

The original question was about PNGs and JPGs, and the size of parcel files without source. In that case, a ByteArray of the PNG file contents is the best approach: 256 bytes for the example below. Trying to compress the bytes of a PNG is unlikely to help, given they're already compressed with zlib. The default zlib compression level is a sweet spot of speed vs. size.

The OP's problem was speed, presumably because the images were being built from the PNG bytes each time they were displayed. Caching with #once should sort that out, plus palette and CachedImage stuff as I mentioned before.

For version control, I'm happy to take the slight hit of ByteArray source versus base64. (Well, 3x bigger, but that's slight compared to a 1MB increase in parcel size for a 64K PNG image!). The version of base64 loaded by StoreForPostgres used to be GPL, which if still true may be another reason to be wary of it.

Steve

From: [hidden email] on behalf of Paul Baumann
Sent: Mon 21/03/2011 19:51
To: Boris Popov, DeepCove Labs; Claus Kick
Cc: [hidden email]
Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

If your source defines the ByteArray like this:

'#[0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255]'

size 916

Then Base64 is a more compact encoding that can be embedded in source code.

| stream |
stream := (ByteArray new withEncoding: #BASE64) writeStream.
0 to: 255 do: [:v | stream nextPut: (Character value: v) ].
stream close stream contents asString size.

344

'AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/w=='

size 344

You might also try compressing the bytes before encoding it.

Sorry, that probably isn't good example code for the base64 encoder that comes with VW. I use the one in SRP.

Paul Baumann

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Boris Popov, DeepCove Labs
Sent: Sunday, March 20, 2011 16:30
To: Claus Kick
Cc: [hidden email]
Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?

Simplified deployment is also attractive, we sync images up to our servers and don't have to worry about the assets. Similar simplicity also plays into building headful apps where image containing all resources can be bundled with the vm into one executable etcetera.

Sent from my iPhone

On 2011-03-20, at 16:24, "Claus Kick" <[hidden email]> wrote:

>
> Alright, version control makes sense. But still, if its so much a hassle to do, why not do it another way?
> I would use subversion instead and use a couple of methods to commit assets to svn and store the version number in a class variable.
> That way, there would be an easy way to retrieve the correct version for each deployment version.
>
>
> --
> Claus Kick
>
> "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
> Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
> Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."
>
> "If you are looking for me: I am somewhere near to lunacy.
> More clearly, on the narrow path between lunacy and panic.
> Right around the corner of fear of death,
> not far away from idiocy and insanity."
>
> -----Ursprüngliche Nachricht-----
> Von: "Boris Popov, DeepCove Labs" <[hidden email]>
> Gesendet: 11.03.2011 14:36:03
> An: "Claus Kick" <[hidden email]>, [hidden email], "Mark Pirogovsky" <[hidden email]>
> Betreff: RE: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>
>> Claus,
>>
>> The immediate benefit of storing them with the source code is 'free' version control and simplified deployment. I believe there's a way to attach arbitrary files to bucka...^^...pundles, but I'm not sure it's mature enough or exercised enough to recommend, but I hadn't actually played with it much, so I may be totally off on my assessment of this bit of functionality.
>>
>> Regards,
>>
>> -Boris
>>
>> -----Original Message-----
>> From: [hidden email] [[hidden email]] On Behalf Of Claus Kick
>> Sent: Friday, March 11, 2011 8:30 AM
>> To: [hidden email]; Mark Pirogovsky
>> Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>>
>>
>> Probably a stupid question, but why do you need to store the images in the image at all?
>> Is reading from the file system in startup, using them and discarding them on VM-exit no alternative?
>>
>> --
>> Claus Kick
>>
>> "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."
>>
>> "If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiocy and insanity."
>>
>> -----Ursprüngliche Nachricht-----
>> Von: "Mark Pirogovsky" <[hidden email]>
>> Gesendet: 09.03.2011 23:26:56
>> An: [hidden email]
>> Betreff: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>>
>>> Hello All,
>>>
>>> I need to build very graphical interface with a lot of pictures
>>> imported from various JPG and PNG files.
>>>
>>> What I am finding that when I import those files and install the
>>> resulting images into the methods using normal VW facilities -- the
>>> resulting method sizes are enormous.
>>> For example, reasonable size PNG file ( 64 kb) which contains the
>>> 400@100 extent image - results in the method with size of about a 1 MB
>>> when saved as Parcel with no sources.
>>>
>>> Is there any way to store the Graphics information in the VW images
>>> without blowing off disk and RAM sizes or the network download time?
>>>
>>>
>>> I tried couple of things and here is the method I came up with:
>>>
>>> 1. I load the contents of the PNG file as Byte Array into the
>>> smalltalk method.
>>> 2. then I read the Byte Array using the Image reader to produce an
>>> Image when needed.
>>>
>>> By doing this my the resulting Parcel size is about 100 kb ( order of
>>> magnitude less) but I can see a delay when Interface rebuilds.
>>> I think it should be something better out there, but I can't thing of
>>> anything at the moment.
>>>
>>> What others are doing in the situation like this ?
>>>
>>> Any Information is greatly appreciated...
>>>
>>>
>>> --Mark Pirogovsky
>>>
>>> _______________________________________________
>>> vwnc mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris Popov, DeepCove Labs (SNN)

Re: [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Steven,

Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?

#[1 2 3 4 5] asBase64String

-Boris

From: Steven Kelly [mailto:[hidden email]]
Sent: Monday, March 21, 2011 2:15 PM
To: Paul Baumann; Boris Popov, DeepCove Labs; Claus Kick
Cc: [hidden email]
Subject: RE: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Steve

If your source defines the ByteArray like this:

'#[0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255]'

size 916

Then Base64 is a more compact encoding that can be embedded in source code.

| stream |
stream := (ByteArray new withEncoding: #BASE64) writeStream.
0 to: 255 do: [:v | stream nextPut: (Character value: v) ].
stream close stream contents asString size.

344

'AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/w=='

size 344

You might also try compressing the bytes before encoding it.

Sorry, that probably isn't good example code for the base64 encoder that comes with VW. I use the one in SRP.

Paul Baumann

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Boris Popov, DeepCove Labs
Sent: Sunday, March 20, 2011 16:30
To: Claus Kick
Cc: [hidden email]
Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?

Simplified deployment is also attractive, we sync images up to our servers and don't have to worry about the assets. Similar simplicity also plays into building headful apps where image containing all resources can be bundled with the vm into one executable etcetera.

Sent from my iPhone

On 2011-03-20, at 16:24, "Claus Kick" <[hidden email]> wrote:

>
> Alright, version control makes sense. But still, if its so much a hassle to do, why not do it another way?
> I would use subversion instead and use a couple of methods to commit assets to svn and store the version number in a class variable.
> That way, there would be an easy way to retrieve the correct version for each deployment version.
>
>
> --
> Claus Kick
>
> "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
> Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
> Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."
>
> "If you are looking for me: I am somewhere near to lunacy.
> More clearly, on the narrow path between lunacy and panic.
> Right around the corner of fear of death,
> not far away from idiocy and insanity."
>
> -----Ursprüngliche Nachricht-----
> Von: "Boris Popov, DeepCove Labs" <[hidden email]>
> Gesendet: 11.03.2011 14:36:03
> An: "Claus Kick" <[hidden email]>, [hidden email], "Mark Pirogovsky" <[hidden email]>
> Betreff: RE: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>
>> Claus,
>>
>> The immediate benefit of storing them with the source code is 'free' version control and simplified deployment. I believe there's a way to attach arbitrary files to bucka...^^...pundles, but I'm not sure it's mature enough or exercised enough to recommend, but I hadn't actually played with it much, so I may be totally off on my assessment of this bit of functionality.
>>
>> Regards,
>>
>> -Boris
>>
>> -----Original Message-----
>> From: [hidden email] [[hidden email]] On Behalf Of Claus Kick
>> Sent: Friday, March 11, 2011 8:30 AM
>> To: [hidden email]; Mark Pirogovsky
>> Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>>
>>
>> Probably a stupid question, but why do you need to store the images in the image at all?
>> Is reading from the file system in startup, using them and discarding them on VM-exit no alternative?
>>
>> --
>> Claus Kick
>>
>> "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."
>>
>> "If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiocy and insanity."
>>
>> -----Ursprüngliche Nachricht-----
>> Von: "Mark Pirogovsky" <[hidden email]>
>> Gesendet: 09.03.2011 23:26:56
>> An: [hidden email]
>> Betreff: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?
>>
>>> Hello All,
>>>
>>> I need to build very graphical interface with a lot of pictures
>>> imported from various JPG and PNG files.
>>>
>>> What I am finding that when I import those files and install the
>>> resulting images into the methods using normal VW facilities -- the
>>> resulting method sizes are enormous.
>>> For example, reasonable size PNG file ( 64 kb) which contains the
>>> 400@100 extent image - results in the method with size of about a 1 MB
>>> when saved as Parcel with no sources.
>>>
>>> Is there any way to store the Graphics information in the VW images
>>> without blowing off disk and RAM sizes or the network download time?
>>>
>>>
>>> I tried couple of things and here is the method I came up with:
>>>
>>> 1. I load the contents of the PNG file as Byte Array into the
>>> smalltalk method.
>>> 2. then I read the Byte Array using the Image reader to produce an
>>> Image when needed.
>>>
>>> By doing this my the resulting Parcel size is about 100 kb ( order of
>>> magnitude less) but I can see a delay when Interface rebuilds.
>>> I think it should be something better out there, but I can't thing of
>>> anything at the moment.
>>>
>>> What others are doing in the situation like this ?
>>>
>>> Any Information is greatly appreciated...
>>>
>>>
>>> --Mark Pirogovsky
>>>
>>> _______________________________________________
>>> vwnc mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Steven Kelly

Base64 frameworks and licences

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

In 7.7.1 (and earlier) StoreForPostgreSQL prereqs PostgreSQLEXDI which prereqs Base64Encoding, which is licensed under LGPL. Its classes are Base64Encoding[|Read|Write]Stream, so different from those in Protocols-Common. At a glance it seems there’s some functionality in the LGPL classes not provided by Protocols-Common, e.g. #disableLineBreaks.

An unelaborated mention of LGPL could be ambiguous in Smalltalk, opening the path for hostile lawyers to claim any software containing the library should be open sourced too. At least that’s my recollection. Since I haven’t needed Base64Encoding in our deployed apps, I haven’t worried about this.

Good that Cincom also supplies unencumbered Base64 support (since 7.1). Maybe Postgres could start using that at some point. The quick hack test below shows (unsurprisingly) that they give the same answer for encoding Object’s comment, although their interfaces are somewhat different.

Steve

postgresStream := Base64EncodingWriteStream on: String new.

postgresStream disableLineBreaks.

postgresStream nextPutAll: (Object comment copy changeClassTo: ByteArray). " :-) "

postgresStream close.

postgresResult := postgresStream contents.

cincomStream := (ByteArray new withEncoding: #BASE64) writeStream.

cincomStream nextPutAll: Object comment.

cincomStream close.

cincomResult := (cincomStream encodedContents withEncoding: #ASCII) readStream contents.

postgresResult = cincomResult "true"

From: Boris Popov, DeepCove Labs [mailto:[hidden email]]
Sent: 21. maaliskuuta 2011 20:25
To: Steven Kelly; Paul Baumann; Claus Kick
Cc: [hidden email]
Subject: RE: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Steven,

Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?

#[1 2 3 4 5] asBase64String

-Boris

…

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Knight-2

Re: Base64 frameworks and licences

You don't need to dive that far down. PostgresqlEXDI is licensed under LGPL. I don't believe that the primary author of it (Bruce Badger) subscribes to the theory that it would require software containing or using that library to be released under the same license, but if it is an issue for you, you'd want to avoid the entire Postgresql driver.

[hidden email]
March 21, 2011 3:54 PM

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

In 7.7.1 (and earlier) StoreForPostgreSQL prereqs PostgreSQLEXDI which prereqs Base64Encoding, which is licensed under LGPL. Its classes are Base64Encoding[|Read|Write]Stream, so different from those in Protocols-Common. At a glance it seems there’s some functionality in the LGPL classes not provided by Protocols-Common, e.g. #disableLineBreaks.

An unelaborated mention of LGPL could be ambiguous in Smalltalk, opening the path for hostile lawyers to claim any software containing the library should be open sourced too. At least that’s my recollection. Since I haven’t needed Base64Encoding in our deployed apps, I haven’t worried about this.

Good that Cincom also supplies unencumbered Base64 support (since 7.1). Maybe Postgres could start using that at some point. The quick hack test below shows (unsurprisingly) that they give the same answer for encoding Object’s comment, although their interfaces are somewhat different.

Steve

postgresStream := Base64EncodingWriteStream on: String new.

postgresStream disableLineBreaks.

postgresStream nextPutAll: (Object comment copy changeClassTo: ByteArray). " :-) "

postgresStream close.

postgresResult := postgresStream contents.

cincomStream := (ByteArray new withEncoding: #BASE64) writeStream.

cincomStream nextPutAll: Object comment.

cincomStream close.

cincomResult := (cincomStream encodedContents withEncoding: #ASCII) readStream contents.

postgresResult = cincomResult "true"

From: Boris Popov, DeepCove Labs [[hidden email]]
Sent: 21. maaliskuuta 2011 20:25
To: Steven Kelly; Paul Baumann; Claus Kick
Cc: [hidden email]
Subject: RE: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Steven,

Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?

#[1 2 3 4 5] asBase64String

-Boris

From: Steven Kelly [[hidden email]]
Sent: Monday, March 21, 2011 2:15 PM
To: Paul Baumann; Boris Popov, DeepCove Labs; Claus Kick
Cc: [hidden email]
Subject: RE: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

…

For version control, I'm happy to take the slight hit of ByteArray source versus base64. (Well, 3x bigger, but that's slight compared to a 1MB increase in parcel size for a 64K PNG image!). The version of base64 loaded by StoreForPostgres used to be GPL, which if still true may be another reason to be wary of it.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 2:25 PM

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Steven,

Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?

#[1 2 3 4 5] asBase64String

-Boris

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 2:15 PM

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

The original question was about PNGs and JPGs, and the size of parcel files without source. In that case, a ByteArray of the PNG file contents is the best approach: 256 bytes for the example below. Trying to compress the bytes of a PNG is unlikely to help, given they're already compressed with zlib. The default zlib compression level is a sweet spot of speed vs. size.

The OP's problem was speed, presumably because the images were being built from the PNG bytes each time they were displayed. Caching with #once should sort that out, plus palette and CachedImage stuff as I mentioned before.

For version control, I'm happy to take the slight hit of ByteArray source versus base64. (Well, 3x bigger, but that's slight compared to a 1MB increase in parcel size for a 64K PNG image!). The version of base64 loaded by StoreForPostgres used to be GPL, which if still true may be another reason to be wary of it.

Steve

From: [hidden email] on behalf of Paul Baumann
Sent: Mon 21/03/2011 19:51
To: Boris Popov, DeepCove Labs; Claus Kick
Cc: [hidden email]
Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

If your source defines the ByteArray like this:

'#[0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255]'

size 916

Then Base64 is a more compact encoding that can be embedded in source code.

| stream |
stream := (ByteArray new withEncoding: #BASE64) writeStream.
0 to: 255 do: [:v | stream nextPut: (Character value: v) ].
stream close stream contents asString size.

344

'AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/w=='

size 344

You might also try compressing the bytes before encoding it.

Sorry, that probably isn't good example code for the base64 encoder that comes with VW. I use the one in SRP.

Paul Baumann

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 1:51 PM

If your source defines the ByteArray like this:

'#[0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255]'

size 916

Then Base64 is a more compact encoding that can be embedded in source code.

| stream |
stream := (ByteArray new withEncoding: #BASE64) writeStream.
0 to: 255 do: [:v | stream nextPut: (Character value: v) ].
stream close stream contents asString size.

344

'AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/w=='

size 344

You might also try compressing the bytes before encoding it.

Sorry, that probably isn't good example code for the base64 encoder that comes with VW. I use the one in SRP.

Paul Baumann

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Boris Popov, DeepCove Labs
Sent: Sunday, March 20, 2011 16:30
To: Claus Kick
Cc: [hidden email]
Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?

Simplified deployment is also attractive, we sync images up to our servers and don't have to worry about the assets. Similar simplicity also plays into building headful apps where image containing all resources can be bundled with the vm into one executable etcetera.

Sent from my iPhone

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 20, 2011 4:29 PM

Simplified deployment is also attractive, we sync images up to our servers and don't have to worry about the assets. Similar simplicity also plays into building headful apps where image containing all resources can be bundled with the vm into one executable etcetera.

Sent from my iPhone

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Knight-2

Re: Base64 frameworks and licences

For that matter, Glorp, which is currently used as the underpinnings of Store, is under LGPL, which might also be an issue for people. However, in that case, I can say from close personal knowledge that the author does not subscribe to the interpretation that this should affect software using it, and went out of his way to make it clear in the license. He is also in the process of switching the license over to something more permissive, precisely because this is an issue for some people, but has had too many things coming up as urgent to spend the necessary time diving through old paperwork and emails to get it finished yet.

[hidden email]
March 21, 2011 5:31 PM

You don't need to dive that far down. PostgresqlEXDI is licensed under LGPL. I don't believe that the primary author of it (Bruce Badger) subscribes to the theory that it would require software containing or using that library to be released under the same license, but if it is an issue for you, you'd want to avoid the entire Postgresql driver.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 3:54 PM

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

In 7.7.1 (and earlier) StoreForPostgreSQL prereqs PostgreSQLEXDI which prereqs Base64Encoding, which is licensed under LGPL. Its classes are Base64Encoding[|Read|Write]Stream, so different from those in Protocols-Common. At a glance it seems there’s some functionality in the LGPL classes not provided by Protocols-Common, e.g. #disableLineBreaks.

An unelaborated mention of LGPL could be ambiguous in Smalltalk, opening the path for hostile lawyers to claim any software containing the library should be open sourced too. At least that’s my recollection. Since I haven’t needed Base64Encoding in our deployed apps, I haven’t worried about this.

Good that Cincom also supplies unencumbered Base64 support (since 7.1). Maybe Postgres could start using that at some point. The quick hack test below shows (unsurprisingly) that they give the same answer for encoding Object’s comment, although their interfaces are somewhat different.

Steve

postgresStream := Base64EncodingWriteStream on: String new.

postgresStream disableLineBreaks.

postgresStream nextPutAll: (Object comment copy changeClassTo: ByteArray). " :-) "

postgresStream close.

postgresResult := postgresStream contents.

cincomStream := (ByteArray new withEncoding: #BASE64) writeStream.

cincomStream nextPutAll: Object comment.

cincomStream close.

cincomResult := (cincomStream encodedContents withEncoding: #ASCII) readStream contents.

postgresResult = cincomResult "true"

From: Boris Popov, DeepCove Labs [[hidden email]]
Sent: 21. maaliskuuta 2011 20:25
To: Steven Kelly; Paul Baumann; Claus Kick
Cc: [hidden email]
Subject: RE: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Steven,

Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?

#[1 2 3 4 5] asBase64String

-Boris

From: Steven Kelly [[hidden email]]
Sent: Monday, March 21, 2011 2:15 PM
To: Paul Baumann; Boris Popov, DeepCove Labs; Claus Kick
Cc: [hidden email]
Subject: RE: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

…

For version control, I'm happy to take the slight hit of ByteArray source versus base64. (Well, 3x bigger, but that's slight compared to a 1MB increase in parcel size for a 64K PNG image!). The version of base64 loaded by StoreForPostgres used to be GPL, which if still true may be another reason to be wary of it.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 2:25 PM

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Steven,

Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?

#[1 2 3 4 5] asBase64String

-Boris

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 2:15 PM

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

The original question was about PNGs and JPGs, and the size of parcel files without source. In that case, a ByteArray of the PNG file contents is the best approach: 256 bytes for the example below. Trying to compress the bytes of a PNG is unlikely to help, given they're already compressed with zlib. The default zlib compression level is a sweet spot of speed vs. size.

The OP's problem was speed, presumably because the images were being built from the PNG bytes each time they were displayed. Caching with #once should sort that out, plus palette and CachedImage stuff as I mentioned before.

For version control, I'm happy to take the slight hit of ByteArray source versus base64. (Well, 3x bigger, but that's slight compared to a 1MB increase in parcel size for a 64K PNG image!). The version of base64 loaded by StoreForPostgres used to be GPL, which if still true may be another reason to be wary of it.

Steve

From: [hidden email] on behalf of Paul Baumann
Sent: Mon 21/03/2011 19:51
To: Boris Popov, DeepCove Labs; Claus Kick
Cc: [hidden email]
Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

If your source defines the ByteArray like this:

'#[0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255]'

size 916

Then Base64 is a more compact encoding that can be embedded in source code.

| stream |
stream := (ByteArray new withEncoding: #BASE64) writeStream.
0 to: 255 do: [:v | stream nextPut: (Character value: v) ].
stream close stream contents asString size.

344

'AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/w=='

size 344

You might also try compressing the bytes before encoding it.

Sorry, that probably isn't good example code for the base64 encoder that comes with VW. I use the one in SRP.

Paul Baumann

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 1:51 PM

If your source defines the ByteArray like this:

'#[0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255]'

size 916

Then Base64 is a more compact encoding that can be embedded in source code.

| stream |
stream := (ByteArray new withEncoding: #BASE64) writeStream.
0 to: 255 do: [:v | stream nextPut: (Character value: v) ].
stream close stream contents asString size.

344

'AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/w=='

size 344

You might also try compressing the bytes before encoding it.

Sorry, that probably isn't good example code for the base64 encoder that comes with VW. I use the one in SRP.

Paul Baumann

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Boris Popov, DeepCove Labs
Sent: Sunday, March 20, 2011 16:30
To: Claus Kick
Cc: [hidden email]
Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?

Simplified deployment is also attractive, we sync images up to our servers and don't have to worry about the assets. Similar simplicity also plays into building headful apps where image containing all resources can be bundled with the vm into one executable etcetera.

Sent from my iPhone

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Steven Kelly

Re: Base64 frameworks and licences

The original question (and indeed this thread) was about Base64 encoding, so I wasn’t diving down but rather climbing up. The license of StoreForPostgres or PostgresqlEXDI isn’t so relevant, since they’re not needed for Base64, and also they’re not as widely needed in deployed apps as Base64.

I know the licensing of Glorp, and appreciate your clarification in that license of how you understand LGPL for Smalltalk. I’d hope that your expression of that would stand up in court. Bruce’s unelaborated mention of LGPL would be a risk, regardless of his personal position – it’s not his opinion that matters, but whether someone looking at his Base64 package could reasonably assume from its license that the rest of the app would be open sourced too. At least that’s my understanding.

And of course I too find it frustrating that we even have to have this discussion, but the evidence is that when some jerk^^^^ individual decides to look at these, the friendly programmer point of view goes out the window. Java, Oracle, Android, Google, Unix, SCO, and even Cincom’s own current issues with providing downloads should be ample evidence of this. Regardless of how those battles turn out, I prefer to avoid them.

The MIT license seems the best choice for “I just want to let anyone use my stuff as they like”. It’s short, widely-used, not strongly associated to one language or product, has no copyleft worries, and no problems in any of its versions (it only has one version. E.g. BSD has problems in earlier versions).

http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses

Steve

From: Alan Knight [mailto:[hidden email]]
Sent: 22. maaliskuuta 2011 0:14
To: [hidden email]
Cc: Steven Kelly; [hidden email]
Subject: Re: [vwnc] Base64 frameworks and licences

[hidden email]
March 21, 2011 5:31 PM

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 3:54 PM

Steve

postgresStream := Base64EncodingWriteStream on: String new.

postgresStream disableLineBreaks.

postgresStream nextPutAll: (Object comment copy changeClassTo: ByteArray). " :-) "

postgresStream close.

postgresResult := postgresStream contents.

cincomStream := (ByteArray new withEncoding: #BASE64) writeStream.

cincomStream nextPutAll: Object comment.

cincomStream close.

cincomResult := (cincomStream encodedContents withEncoding: #ASCII) readStream contents.

postgresResult = cincomResult "true"

From: Boris Popov, DeepCove Labs [[hidden email]]
Sent: 21. maaliskuuta 2011 20:25
To: Steven Kelly; Paul Baumann; Claus Kick
Cc: [hidden email]
Subject: RE: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Steven,

Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?

#[1 2 3 4 5] asBase64String

-Boris

From: Steven Kelly [[hidden email]]
Sent: Monday, March 21, 2011 2:15 PM
To: Paul Baumann; Boris Popov, DeepCove Labs; Claus Kick
Cc: [hidden email]
Subject: RE: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

…

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 2:25 PM

Steven,

Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?

#[1 2 3 4 5] asBase64String

-Boris

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 2:15 PM

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 1:51 PM

If your source defines the ByteArray like this:

'#[0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255]'

size 916

Then Base64 is a more compact encoding that can be embedded in source code.

| stream |
stream := (ByteArray new withEncoding: #BASE64) writeStream.
0 to: 255 do: [:v | stream nextPut: (Character value: v) ].
stream close stream contents asString size.

344

'AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/w=='

size 344

You might also try compressing the bytes before encoding it.

Sorry, that probably isn't good example code for the base64 encoder that comes with VW. I use the one in SRP.

Paul Baumann

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Boris Popov, DeepCove Labs
Sent: Sunday, March 20, 2011 16:30
To: Claus Kick
Cc: [hidden email]
Subject: Re: [vwnc] [VW 7.7] What is the best ( compact )way to store images in VW ?

Simplified deployment is also attractive, we sync images up to our servers and don't have to worry about the assets. Similar simplicity also plays into building headful apps where image containing all resources can be bundled with the vm into one executable etcetera.

Sent from my iPhone

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Knight-2

Re: Base64 frameworks and licences

Well, my understanding is that if it goes to court, you would have to have standing (i.e. be the copyright owner) in order to take it to court. So the copyright holder's interpretation is in fact an overriding consideration. In the case of much of the GPL and LGPL code that's out there, copyright has been assigned to the FSF, so they would get to decide on the interpretation. But that's not the case with either Glorp or PostgresqlEXDI.

The bigger worry, at least for me, is not in court but in preventing people from using it. If someone looks at the package and the license worries them, or their lawyers, then they're less likely to use it.

But I agree on the conclusion, something like the MIT license is best.

[hidden email]
March 22, 2011 5:24 AM

The original question (and indeed this thread) was about Base64 encoding, so I wasn’t diving down but rather climbing up. The license of StoreForPostgres or PostgresqlEXDI isn’t so relevant, since they’re not needed for Base64, and also they’re not as widely needed in deployed apps as Base64.

I know the licensing of Glorp, and appreciate your clarification in that license of how you understand LGPL for Smalltalk. I’d hope that your expression of that would stand up in court. Bruce’s unelaborated mention of LGPL would be a risk, regardless of his personal position – it’s not his opinion that matters, but whether someone looking at his Base64 package could reasonably assume from its license that the rest of the app would be open sourced too. At least that’s my understanding.

And of course I too find it frustrating that we even have to have this discussion, but the evidence is that when some jerk^^^^ individual decides to look at these, the friendly programmer point of view goes out the window. Java, Oracle, Android, Google, Unix, SCO, and even Cincom’s own current issues with providing downloads should be ample evidence of this. Regardless of how those battles turn out, I prefer to avoid them.

The MIT license seems the best choice for “I just want to let anyone use my stuff as they like”. It’s short, widely-used, not strongly associated to one language or product, has no copyleft worries, and no problems in any of its versions (it only has one version. E.g. BSD has problems in earlier versions).

http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses

Steve

[hidden email]
March 21, 2011 6:14 PM

For that matter, Glorp, which is currently used as the underpinnings of Store, is under LGPL, which might also be an issue for people. However, in that case, I can say from close personal knowledge that the author does not subscribe to the interpretation that this should affect software using it, and went out of his way to make it clear in the license. He is also in the process of switching the license over to something more permissive, precisely because this is an issue for some people, but has had too many things coming up as urgent to spend the necessary time diving through old paperwork and emails to get it finished yet.

[hidden email]
March 21, 2011 5:31 PM

You don't need to dive that far down. PostgresqlEXDI is licensed under LGPL. I don't believe that the primary author of it (Bruce Badger) subscribes to the theory that it would require software containing or using that library to be released under the same license, but if it is an issue for you, you'd want to avoid the entire Postgresql driver.

[hidden email]
March 21, 2011 3:54 PM

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

In 7.7.1 (and earlier) StoreForPostgreSQL prereqs PostgreSQLEXDI which prereqs Base64Encoding, which is licensed under LGPL. Its classes are Base64Encoding[|Read|Write]Stream, so different from those in Protocols-Common. At a glance it seems there’s some functionality in the LGPL classes not provided by Protocols-Common, e.g. #disableLineBreaks.

An unelaborated mention of LGPL could be ambiguous in Smalltalk, opening the path for hostile lawyers to claim any software containing the library should be open sourced too. At least that’s my recollection. Since I haven’t needed Base64Encoding in our deployed apps, I haven’t worried about this.

Good that Cincom also supplies unencumbered Base64 support (since 7.1). Maybe Postgres could start using that at some point. The quick hack test below shows (unsurprisingly) that they give the same answer for encoding Object’s comment, although their interfaces are somewhat different.

Steve

postgresStream := Base64EncodingWriteStream on: String new.

postgresStream disableLineBreaks.

postgresStream nextPutAll: (Object comment copy changeClassTo: ByteArray). " :-) "

postgresStream close.

postgresResult := postgresStream contents.

cincomStream := (ByteArray new withEncoding: #BASE64) writeStream.

cincomStream nextPutAll: Object comment.

cincomStream close.

cincomResult := (cincomStream encodedContents withEncoding: #ASCII) readStream contents.

postgresResult = cincomResult "true"

From: Boris Popov, DeepCove Labs [[hidden email]]
Sent: 21. maaliskuuta 2011 20:25
To: Steven Kelly; Paul Baumann; Claus Kick
Cc: [hidden email]
Subject: RE: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Steven,

Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?

#[1 2 3 4 5] asBase64String

-Boris

From: Steven Kelly [[hidden email]]
Sent: Monday, March 21, 2011 2:15 PM
To: Paul Baumann; Boris Popov, DeepCove Labs; Claus Kick
Cc: [hidden email]
Subject: RE: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

…

For version control, I'm happy to take the slight hit of ByteArray source versus base64. (Well, 3x bigger, but that's slight compared to a 1MB increase in parcel size for a 64K PNG image!). The version of base64 loaded by StoreForPostgres used to be GPL, which if still true may be another reason to be wary of it.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
March 21, 2011 2:25 PM

Re: [vwnc] [VW 7.7] What is the best ( compact )way to storeimages in VW ?

Steven,

Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?

#[1 2 3 4 5] asBase64String

-Boris

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc