[squeak-dev] The Trunk: MorphicExtras-nice.130.mcz

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Dec 8 22:30:11 UTC 2013


PaintBoxMorph new colorMemory image writePNGfileNamed: 'pb_colorMemory.png'.
(Form fromBinaryStream: (Base64MimeConverter mimeDecodeToBytes:
    ((FileStream fileNamed: 'pb_colorMemory.png')
        binary;
        contentsOfEntireFile) asString base64Encoded readStream)) asMorph
openInWorld



2013/12/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>

> And a drawback of storing the bytes in a literal is that it doubles the
> space required...
> But then we don't need to clone a prototype (veryDeepCopy !!!)
> If we're really chasing kbytes, then we should ban the prototype, so this
> can't be an argument.
>
>
> 2013/12/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
>
>> A few things:
>> 1) PaintBoxMorph new is cloning a Prototype much like the self way.
>> 2) above code is memorizing how the prototype was once initialized.
>> 2.a) it will never be invoked again, unless we recreate a whole image
>> 2.b) it does so partially... It does tell which file, but not from which
>> server.
>> The information of well known update server is no more in the image.
>> You could find ftp.squeak.org recently in Utilities before I removed the
>> class var...
>> ... but ftp.squeak.org doesn't seem to know about colorPalClosed.obj.
>> 3) I don't see an updateStream dependency in Installer core, only a
>> dependency on its successor MCMcmUpdater
>>
>> 2.a) makes me think we don't need something complex.
>> 2.b) makes me think it's time to replace/update the initialize mechanism
>>
>> I looked at the cached images, it's about 35kbytes, 16kBytes zipped.
>> A possible alternative is to directly store those bytes in some literal
>> (string -> uudecode -> unzip -> bits).
>>
>>
>> 2013/12/8 Chris Muller <asqueaker at gmail.com>
>>
>>> On Sun, Dec 8, 2013 at 2:48 PM, Nicolas Cellier
>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>> > Well, above code depends on some bytes left on some file on the
>>> internet,
>>>
>>> Not necessarily.  See Installer class>>#airplaneMode.
>>>
>>> Besides, even if it did, it's 2013 so developers are accustomed to
>>> working with remote code repositories.
>>>
>>> > plus a bunch of methods to retrieve/decode/install those bytes as an
>>> image.
>>>
>>> Which is a requirement of #core.  See comment for Installer>>#core.
>>>
>>> > We could as well imagine a shorter path...
>>>
>>> Like what?
>>>
>>>
>>> > 2013/12/8 Chris Muller <asqueaker at gmail.com>
>>> >>
>>> >> MorphicExtras is "extras" so we can expect it to depend on myriad
>>> >> other packages.  I'm surprised you and Frank aren't harping on such a
>>> >> "catch-all" package.
>>> >>
>>> >> I thought to test the waters of making it a dynamic-dependency.
>>> >>
>>> >> On Sat, Dec 7, 2013 at 8:27 AM, Nicolas Cellier
>>> >> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>> >> > On one hand, I find those bytes very useful if ever we'd like to
>>> >> > recreate an
>>> >> > image.
>>> >> > But on the other hand, it creates a dependency.
>>> >> > This makes a nice packaging problem, how to handle it?
>>> >> > One possibility would be to encode image data in some kind of
>>> literal
>>> >> > (packed string, byte array, ...), and store & decode this literal in
>>> >> > some
>>> >> > class initialization method...
>>> >> > Anyway, the name and location of file does not bring much value now
>>> >> > (just
>>> >> > save a few bytes by avoiding duplication of image in a literal).
>>> >> >
>>> >> >
>>> >> > 2013/12/7 <commits at source.squeak.org>
>>> >> >
>>> >> >> Nicolas Cellier uploaded a new version of MorphicExtras to project
>>> The
>>> >> >> Trunk:
>>> >> >> http://source.squeak.org/trunk/MorphicExtras-nice.130.mcz
>>> >> >>
>>> >> >> ==================== Summary ====================
>>> >> >>
>>> >> >> Name: MorphicExtras-nice.130
>>> >> >> Author: nice
>>> >> >> Time: 7 December 2013, 3:18:35 pm
>>> >> >> UUID: f1cfb1fa-c101-4329-b528-963fb90eef45
>>> >> >> Ancestors: MorphicExtras-fbs.129
>>> >> >>
>>> >> >> Some initialization performed once in last century is depending on
>>> >> >> UpdateStream.
>>> >> >>
>>> >> >> =============== Diff against MorphicExtras-fbs.129 ===============
>>> >> >>
>>> >> >> Item was changed:
>>> >> >>   ----- Method: PaintBoxMorph>>loadColorChooser (in category
>>> >> >> 'initialization') -----
>>> >> >>   loadColorChooser
>>> >> >>         "Load Forms for ColorMemoryMorph."
>>> >> >>
>>> >> >>         | doc closedForm openForm |
>>> >> >> +       doc := UpdateStreamDownloader default
>>> objectStrmFromUpdates:
>>> >> >> 'colorPalClosed.obj'.
>>> >> >> -       doc := Utilities objectStrmFromUpdates:
>>> 'colorPalClosed.obj'.
>>> >> >>         closedForm := doc fileInObjectAndCode mapColor: Color
>>> >> >> transparent
>>> >> >> to: Color black.
>>> >> >> +       doc := UpdateStreamDownloader default
>>> objectStrmFromUpdates:
>>> >> >> 'colorPalOpen.obj'.
>>> >> >> -       doc := Utilities objectStrmFromUpdates: 'colorPalOpen.obj'.
>>> >> >>         openForm := doc fileInObjectAndCode mapColor: Color
>>> transparent
>>> >> >> to: Color black.
>>> >> >>
>>> >> >>         colorMemoryThin image: closedForm.
>>> >> >>         colorMemoryThin position: self position + (0 at 140).
>>> >> >>
>>> >> >>         colorMemory delete.     "delete old one"
>>> >> >>         colorMemory := PaintBoxColorPicker new image: openForm.
>>> >> >>   !
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131208/8c8ee9bc/attachment-0001.htm


More information about the Squeak-dev mailing list