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