Hannes, that's great. JPG support would be awesome to have; eventually, in some wonderful someday, it'd be cool to add support for other media types like mpeg and mp3, it's just a matter of having a way to bring disk-representations in, and some means to reduce them to base64 or some other convenient textual encoding (and also possibly the need to adjust a limitation to the size of a change set, IIRC.)<div>
<br></div><div>One of the things I'd like to do with Cuis is games, and so multimedia support is something I care about. It's just a matter of finding the time. I will try to work on the documentation part soon.<br>
<br><div class="gmail_quote">On Thu, Jan 3, 2013 at 6:24 AM, H. Hirzel <span dir="ltr"><<a href="mailto:hannes.hirzel@gmail.com" target="_blank">hannes.hirzel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thank you Juan, for giving more details. A follow up question<br>
regarding jpg support below....<br>
<br>
--Hannes<br>
<div class="im"><br>
On 1/3/13, Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br>
> Hi Hannes,<br>
><br>
> H. Hirzel wrote:<br>
>> In the meantime I found out that<br>
>><br>
>><br>
>> ContentPack seems to be a persistence mechanism for a dictionary which<br>
>> may contain other dictionaries and instances of Form and ColorForm.<br>
>><br>
>> Forms are written out to the file system as *.png files and ColorForms<br>
>> are written as *.bmp files.<br>
>><br>
>> Is this correct?<br>
>><br>
>> --Hannes<br>
>><br>
>><br>
><br>
> Yes it is correct. It is a bit more than that, though. Forms (and<br>
> potentially other media types) can exist in three forms:<br>
> 1) As external files, such as jpg, png, etc. This is the representation<br>
> we need to use external tools (such as image processing apps, cameras,<br>
> scanners, web, etc) to work on them.<br>
<br>
</div>Speaking of cameras. I'd like to include jpg files. However I do not<br>
see a support of for them. On the class side of ContentPack we have<br>
the method<br>
<br>
<br>
<br>
mapping<br>
<br>
        ^ {<br>
                ColorForm -> #bmp .<br>
                Form -> #png<br>
<div class="HOEnZb"><div class="h5">        }<br>
<br>
<br>
> 2) As methods. Non human readable, base-64 encoded binary data. We need<br>
> this to be able to include such stuff in the update stream, or in<br>
> packages. After we update an image, we usually delete these methods,<br>
> just keeping 3).<br>
> 3) Live objects in the image, for example, stored in class variables.<br>
> This is to make use of them in Cuis.<br>
><br>
> Most of the time, we use 3). But we need 2) for the update stream. We<br>
> also need 1) sometimes to work on them. ContentPack supports the<br>
> conversion between these 3 formats. The implementation is quite simple.<br>
> What is really great is that Casey realized we need some tool to move<br>
> comfortably between these 3 representations. And he also implemented it.<br>
><br>
> Please grab <a href="http://www.jvuletich.org/Cuis/CuisUpdatesUpTo1511.zip" target="_blank">http://www.jvuletich.org/Cuis/CuisUpdatesUpTo1511.zip</a> and<br>
> take a look at updates 966, 967 and 968.<br>
><br>
> Maybe it is time for a bit more documentation, and usage examples...<br>
><br>
> Cheers,<br>
> Juan Vuletich<br>
><br>
>> On 1/2/13, H. Hirzel <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>> wrote:<br>
>><br>
>>> Hello Juan and Casey<br>
>>><br>
>>> Is the ContentPack something like Fuel?<br>
>>> <a href="http://rmod.lille.inria.fr/web/pier/software/Fuel" target="_blank">http://rmod.lille.inria.fr/web/pier/software/Fuel</a><br>
>>> (BTW it is now available for Squeak as well, see announcement on the<br>
>>> Squeak list)?<br>
>>><br>
>>><br>
>>><br>
>>> I found class 'ContentPack', I copy it in below. The nice thing is<br>
>>> that it only has 11 instance methods and 7 class methods. However most<br>
>>> of the comment I do not understand.<br>
>>><br>
>>> I copy in the class comment below.<br>
>>> I put in comments in uppercase.<br>
>>><br>
>>> Kind regards<br>
>>> Hannes<br>
>>><br>
>>><br>
>>> ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////<br>
>>> ContentPack lets you read in and write out the (supported files in<br>
>>> the) contents of a directory on your file system. It also allows you<br>
>>> to trivially create "messenger" subclasses that capture the<br>
>>> information containted (TYPO) in these directory trees, including any<br>
>>> implicit communication that's there in the structure of the directory<br>
>>> hierarchy itself, which are captured in your changes file.<br>
>>><br>
>>> NOTE: I DO NOT UNDERSTAND THIS LANGUAGE. EXAMPLES of supported file<br>
>>> types?<br>
>>><br>
>>><br>
>>> You can then file out a change set that contains a representation of<br>
>>> the (supported file/object types and directory structurein) TYPO the<br>
>>> stuff on your disk, or in your image. This subclass is a dummy which<br>
>>> ContentPack compiles methods into containing base 64 encoded data. You<br>
>>> can load this into another image, as long as that image has<br>
>>> ContentPack loaded. The filed in class can then recreate the<br>
>>> ContentPack on the other end with the media files and structure<br>
>>> intact.<br>
>>><br>
>>> The current implementation is based on #storeString, but the plan is<br>
>>> to change that to SmartRefStream in the long run to support<br>
>>> serializing things like morphs.<br>
>>><br>
>>> ContentPack instances hang onto the actual tree of media objects.(I DO<br>
>>> NOT UNDERSTAND)  It has a nice simple EDSL ???? that just interprets<br>
>>> an array of strings from beginning to end as a "path" to a file<br>
>>> (really a series of dictionary lookups to a Smalltalk object, wherin<br>
>>> the dictionaries mirror the structure of what was on the disk, sans<br>
>>> unsupported files.) This mechanism will likely change a little bit at<br>
>>> some point,<br>
>>><br>
>>><br>
>>> ContentPack came into the world a little faster than I expected, as I<br>
>>> ended up using it to send some icons back in time to fix the Cuis<br>
>>> update stream without having to sort my changes all over again. As<br>
>>> such it had some unusual design pressures... it had to be able to<br>
>>> carry information in and out of both the change set stream and the<br>
>>> filesystem, as well as function in a slightly earlier (unreleased)<br>
>>> version of Cuis than it was written in, and not break anything on it's<br>
>>> way back up through the build to head.<br>
>>><br>
>>> SENDING ICONS BACK IN TIME????<br>
>>><br>
>>><br>
>>> The code, in particular the way things are named, has not settled yet,<br>
>>> and that's why this comment contains no code examples. Use with care<br>
>>> and read the code first, for now.<br>
>>><br>
>>> IN THE MEANTIME THE CODE SEEMS TO HAVE SETTLED OTHERWISE IT WOULD NOT<br>
>>> BE IN CORE.<br>
>>><br>
>>><br>
>>> Currently, .bmp import and .png import are implemented, and both can<br>
>>> be exported. Anything you can import, you can also shuffle into a<br>
>>> change set. Plans are in the works to support audio, change sets, and<br>
>>> text files.<br>
>>><br>
>>> PLEASE DO SO. GIVEN THE FACT THAT THIS CLASS ONLY HAS 18 METHODS THIS<br>
>>> SHOULD NOT BE A LARGE EFFORT.<br>
>>><br>
>>> I'll support video if someone has a good importer, exporter, and<br>
>>> player under the MIT license that'll work under Cuis.<br>
>>><br>
>>> Currently, objects are serialized into single methods, which works for<br>
>>> small icons, but likely doesn't work well (if at all) for larger<br>
>>> files. My intent is to add some behavior that breaks up large objects<br>
>>> into smaller chunks so that this becomes a non-issue. I'll likely get<br>
>>> to that when I've removed most of the repetitive subtle variations of<br>
>>> the same recursive tree walking visitor-trick from the code, and<br>
>>> renamed everything. I think in essence this class is slightly smaller<br>
>>> than it is as represented currently.<br>
>>><br>
>>> Hopefully I will be able to explain all of this better once I've<br>
>>> clarified the code a bit so that I can show off some examples.<br>
>>><br>
>>> YES.   EXAMPLES WILL HELP A LOT   :-)<br>
>>><br>
>>>     - cbr<br>
>>><br>
>>> On 1/2/13, Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br>
>>><br>
>>>> Hi Folks,<br>
>>>><br>
>>>> I think it should work ok. I don't recall doing any changes that would<br>
>>>> obviously affect it.<br>
>>>><br>
>>>> BTW, a bit more of documentation wouldn't hurt, but the code is all<br>
>>>> there, and there's a reasonable class comment. It is just a matter of<br>
>>>> learning and playing a bit with it.<br>
>>>><br>
>>>> Cheers,<br>
>>>> Juan Vuletich<br>
>>>><br>
>>>> Casey Ransberger wrote:<br>
>>>><br>
>>>>> Oh wow and ouch. I wrote it. My fault. I didn't document it. I<br>
>>>>> expected, after I'd used it to muck with the time stream, that we'd<br>
>>>>> throw it away once the paradox was resolved, but Juan liked it, and<br>
>>>>> wanted to keep it.<br>
>>>>><br>
>>>>> Anyway, it's my dog and I've been terrible about feeding it. I should<br>
>>>>> fix that.<br>
>>>>><br>
>>>>> On Tue, Jan 1, 2013 at 9:58 PM, H. Hirzel <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a><br>
>>>>> <mailto:<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>>> wrote:<br>
>>>>><br>
>>>>>     Hello Casey and Juan<br>
>>>>><br>
>>>>>     Good to see you active on this list.<br>
>>>>>     How to I try out the ContentPack in Cuis 4.1?<br>
>>>>><br>
>>>>>     Casey mentions in another thread that it might not work anymore.<br>
>>>>><br>
>>>>>     --Hannes<br>
>>>>><br>
>>>>>     On 12/30/12, Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a><br>
>>>>>     <mailto:<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>>> wrote:<br>
>>>>>     > Hi Hannes,<br>
>>>>>     ><br>
>>>>>     > You might be thinking on Casey's ContentPack, that is part of<br>
>>>>>     Cuis. It<br>
>>>>>     > allows us to use only change sets for updating Cuis, while at<br>
>>>>>     the same<br>
>>>>>     > time, using external tools for editing resources (like .bmp,<br>
>>>>>     .png and<br>
>>>>>     > jpg files, etc).<br>
>>>>>     ><br>
>>>>>     > Cheers,<br>
>>>>>     > Juan Vuletich<br>
>>>>>     ><br>
>>>>>     > H. Hirzel wrote:<br>
>>>>>     .....<br>
>>>>>     >><br>
>>>>>     >> If I remember well you once did a package for managing<br>
>>>>>     resources, right?<br>
>>>>>     >><br>
>>>>>     >> Where is it?<br>
>>>>>     >><br>
>>>>>     >> --Hannes<br>
>>>>>     >><br>
>>>>><br>
>>>>>     _______________________________________________<br>
>>>>>     Cuis mailing list<br>
>>>>>     <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a> <mailto:<a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a>><br>
>>>>>     <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Casey Ransberger<br>
>>>>> ------------------------------------------------------------------------<br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Cuis mailing list<br>
>>>>> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
>>>>> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
>>>>><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> Cuis mailing list<br>
>>>> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
>>>> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
>>>><br>
>>>><br>
>><br>
>> _______________________________________________<br>
>> Cuis mailing list<br>
>> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
>> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
>><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Cuis mailing list<br>
> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
><br>
<br>
_______________________________________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Casey Ransberger
</div>