Re: The Trunk: MorphicExtras-nice.130.mcz
Locked
Re: The Trunk: MorphicExtras-nice.130.mcz
 
|
On one hand, I find those bytes very useful if ever we'd like to recreate an image.
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...But on the other hand, it creates a dependency. This makes a nice packaging problem, how to handle it? 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 <[hidden email]> Nicolas Cellier uploaded a new version of MorphicExtras to project The Trunk: |
Re: The Trunk: MorphicExtras-nice.130.mcz
|
|
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 <[hidden email]> 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 <[hidden email]> > >> 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@140). >> >> colorMemory delete. "delete old one" >> colorMemory := PaintBoxColorPicker new image: openForm. >> ! >> >> > > > > |
Re: The Trunk: MorphicExtras-nice.130.mcz
|
|
Well, above code depends on some bytes left on some file on the internet, plus a bunch of methods to retrieve/decode/install those bytes as an image. We could as well imagine a shorter path... 2013/12/8 Chris Muller <[hidden email]> MorphicExtras is "extras" so we can expect it to depend on myriad |
Re: The Trunk: MorphicExtras-nice.130.mcz
|
|
On Sun, Dec 8, 2013 at 2:48 PM, Nicolas Cellier
<[hidden email]> 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 <[hidden email]> >> >> 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 >> <[hidden email]> 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 <[hidden email]> >> > >> >> 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@140). >> >> >> >> colorMemory delete. "delete old one" >> >> colorMemory := PaintBoxColorPicker new image: openForm. >> >> ! >> >> >> >> >> > >> > >> > >> > >> > > > > |
Re: The Trunk: MorphicExtras-nice.130.mcz
|
|
On 8 December 2013 20:54, Chris Muller <[hidden email]> wrote:
> On Sun, Dec 8, 2013 at 2:48 PM, Nicolas Cellier > <[hidden email]> wrote: >> Well, above code depends on some bytes left on some file on the internet, > > Not necessarily. See Installer class>>#airplaneMode. And I greatly appreciate this. See the rant below for why. > Besides, even if it did, it's 2013 so developers are accustomed to > working with remote code repositories. That would be an excellent way of stopping all my work on Squeak. I may not work on open source stuff during work time, I have children to look after in the evenings, so pretty much the _only_ time I have to work on Squeak is in offline mode. I often pull in mczs before I leave home just so that I can work offline. frank >> 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 <[hidden email]> >>> >>> 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 >>> <[hidden email]> 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 <[hidden email]> >>> > >>> >> 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@140). >>> >> >>> >> colorMemory delete. "delete old one" >>> >> colorMemory := PaintBoxColorPicker new image: openForm. >>> >> ! >>> >> >>> >> >>> > >>> > >>> > >>> > >>> >> >> >> >> > |
Re: The Trunk: MorphicExtras-nice.130.mcz
|
|
In reply to this post by Chris Muller-3
On 8 December 2013 20:43, Chris Muller <[hidden email]> wrote:
> 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. Because it's irrelevant. System is a far more difficult problem, and actually necessary. One thing at a time. I'll get to it. > I thought to test the waters of making it a dynamic-dependency. I _hate_ dynamic dependencies. They will make my work impossible. At least direct dependencies on classes make it possible to track what depends on what. OK. After I've calmed down from my state of hyperventilation, what exactly do you mean by "dynamic dependency"? The #at:ifPresent: idiom is already problematic enough, even if I can see half its point. frank > On Sat, Dec 7, 2013 at 8:27 AM, Nicolas Cellier > <[hidden email]> 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 <[hidden email]> >> >>> 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@140). >>> >>> colorMemory delete. "delete old one" >>> colorMemory := PaintBoxColorPicker new image: openForm. >>> ! >>> >>> >> >> >> >> > |
Re: The Trunk: MorphicExtras-nice.130.mcz
|
|
On 8 December 2013 21:13, Frank Shearar <[hidden email]> wrote:
> On 8 December 2013 20:43, Chris Muller <[hidden email]> wrote: >> 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. > > Because it's irrelevant. System is a far more difficult problem, and > actually necessary. One thing at a time. I'll get to it. Specifically, MorphicExtras is irrelevant because (a) it's involved in far fewer cycles than System (Tools, System (of course), Protocols, and I think that's it), (b) it's a very high level package, (c) because in the very long term I aim to make Morphic unloadable, and MorphicExtras along with it. frank |
Re: The Trunk: MorphicExtras-nice.130.mcz
|
|
In reply to this post by Chris Muller-3
A few things: 1) PaintBoxMorph new is cloning a Prototype much like the self way.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.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. A possible alternative is to directly store those bytes in some literal (string -> uudecode -> unzip -> bits). 2013/12/8 Chris Muller <[hidden email]>
|
Re: The Trunk: MorphicExtras-nice.130.mcz
|
|
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 <[hidden email]>
|
Re: The Trunk: MorphicExtras-nice.130.mcz
|
|
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 <[hidden email]>
|
Re: The Trunk: MorphicExtras-nice.130.mcz
|
|
I have created two methods for reconstructing those images: But I now see that those images are exactly like ColorChart class var, plus a border (made with some blue gradient).PaintBoxMorph new colorMemory image writePNGfileNamed: 'pb_colorMemory.png'. PaintBoxMorph class compile: 'colorMemoryImage ^ColorMemoryImage ifNil: [ColorMemoryImage := Form fromBinaryStream: (Base64MimeConverter mimeDecodeToBytes: ' , ((FileStream fileNamed: 'pb_colorMemory.png') binary; contentsOfEntireFile) asString base64Encoded storeString , ' readStream)]' classified: 'resources'. (PaintBoxMorph new instVarNamed: 'colorMemoryThin') image writePNGfileNamed: 'pb_colorMemoryThin.png'. PaintBoxMorph class compile: 'colorMemoryThinImage ^ColorMemoryThinImage ifNil: [ColorMemoryThinImage := Form fromBinaryStream: (Base64MimeConverter mimeDecodeToBytes: ' , ((FileStream fileNamed: 'pb_colorMemoryThin.png') binary; contentsOfEntireFile) asString base64Encoded storeString , ' readStream)]' classified: 'resources'. ColorChart is constructed, so the right way to initialize would be to reconstruct rather than storing resulting bits. But I also see that there are two ways to create this ColorChart, one in class method #initializeColorChart, which creates a rather large one, the other in instance method #fixUpColorPicker which is more inline with current Prototype.It's good to have a plethora of options, alas, if only a single one would work... If we unload MorphicExtras, then reload it, I doubt we can open a PaintBoxMorph, because none of the init3, init4, etc.. does work from trunk.BTW, does unloading MorphicExtras work for anyone? For me it results in an emergency evaluator... So I could not even try this. Sometimes, it makes me think Pharo has taken the most reasonnable path :(. I agree that it's not necessary/desirable to have a programmatic way to reconstruct everything, I would not like to program Mona Lisa, but then, if we really want to use this style in trunk, we should better stop using wrong tools like MC or try to engineer the image into programmed components. 2013/12/8 Nicolas Cellier <[hidden email]>
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |