Chunk format

Hi all,
   I'm writing preinstall scripts and postinstall scripts in PB.
   I guessed that these must be coded in chunk format but I'm not acquainted
with it.
   Can anyone tell me where to find the complete documents or tutorials
about the topics
   on the details of package or chunk format ? ( I've read one long ago but
forgot where it is)
       what's the difference in using PAX source format?
       what's the use to deploy binary package?

   ...or reply in brief to give me some outlines, I'm still learning on the
SmalltalkSystem.

Best regards,

Tk Kuo

On Thu, 21 Oct 2004 18:59:33 +0800, kuo <[hidden email]> wrote:

> Hi all,
>    I'm writing preinstall scripts and postinstall scripts in PB.
>    I guessed that these must be coded in chunk format but I'm not  
> acquainted
> with it.

If I understand your question correctly, you only need to write "normal"  
Smalltalk code just like how you write and run code in a workspace.

--
Regards
HweeBoon
MotionObj

"Yar Hwee Boon" <[hidden email]> wrote:
> If I understand your question correctly, you only need to write "normal"
> Smalltalk code just like how you write and run code in a workspace.
>
Yes, I've just coded them the same way I'm doing in the plain workspace.

But after performing 'accep' to the codes in these PB's workspaces, a '!'
was automatically added at the end of the codes, which probably meaning that
they are indeed stored as chunk format.

This gave me some suggestion that it could accept any chunk format inside
it, so, I do an experiment, that I create a new package that just put in
Ian's 'CB clipboard' package into it's preinstall script workspace, it could
be installed eventually without errors.


Best regards,

Tk Kuo

Kuo,

This chapter in the Education Centre should answer your questions:

http://www.object-arts.com/Lib/EducationCentre4/htm/chunkfiles.htm

Chunk files are a (very flexible) means of delivering Smalltalk source.
Our package files (since they contain source) are in chunk file format.
We also deliver live updates to the Dolphin system using chunk files.

Binary packages are discussed here:

http://www.object-arts.com/Lib/EducationCentre4/htm/binarypackages2.htm

Although that article deals with them as part of the web deployment kit
(where Dolphin applets could run inside a web browser) this kit is no
longer supported. However, binary packages can still be used for other
purposes. Typically, you might use them to add plug-in functionality to
a deployed application where you don't want to ship this as source and
use the compiler to load it (presumably to keep the source private).

AFAIK, not many people make use of the Binary Package mechanism (it
currently has some limitations discussed in the above document).
However, I did give an example of their use in this newsgroup posting
from a couple of months back:

http://groups.google.com/groups?q=Dolphin+Smalltalk+webstart&hl=en&lr=&i
e=UTF-8&selm=40773ac9%40news.totallyobjects.com&rnum=1

Hope this helps.

Best regards

Andy Bower
Dolphin Support
www.object-arts.com

kuo wrote:

> But after performing 'accep' to the codes in these PB's workspaces, a
> '!' was automatically added at the end of the codes, which probably
> meaning that they are indeed stored as chunk format.

I queried the appearance of the ! with Blair during the beta test and he
replied  ...

"
It is by design. The scripts are in chunk format (which is more useful than
a single expression since it allows one to define things in one chunk that
are referenced in later chunks). The chunk marker makes that clear.
"

> This gave me some suggestion that it could accept any chunk format
> inside it, so, I do an experiment, that I create a new package that
> just put in Ian's 'CB clipboard' package into it's preinstall script
> workspace, it could be installed eventually without errors.

That would work, but I can't see any advantage of doing that over saving the
code I posted into a "normal" st file.  If the next release of the CB
includes the additions (which is obviously the intention) you wouldn't be
able to load your new package anyway because of package content collisions.

The only reason I can see for using the chunk format, rather than a normal
workspace format, is when the compilation would fail.  For example, in a
script (or workspace)  the following (silly example) would fail as X would
not be defined  when the compiler tried to compile the second statement ...

Smalltalk at: #X put: Array.
X new

... but using two chunks in the script would work

Smalltalk at: #X put: Array.
!
X new
!

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian Bartholomew (allegedly) wrote:

>                          If the next
> release of the CB includes the additions (which is obviously the
> intention) you wouldn't be able to load your new package anyway
> because of package content collisions.

Ummm, ignore that bit.  I think my computer has a virus that is randomly
inserting silly paragraphs into my replies :-)

I still can't see any advantage though ....

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote:    Yes, the package could be installed only with the later 2-chunk codes but
not the normal workspace one.
   Does it mean that when installing the chunk scripts in the package, the
compiler would be forced to do immediate compilation  on each chunk?
   But why the compiler would fail on the first expression? ( i.e. it could
not know what X is when the whole expression is do-ited in one piece..)
   Quite puzzling.


Tk Kuo

kuo wrote:

>   Does it mean that when installing the chunk scripts in the package,
> the compiler would be forced to do immediate compilation  on each
>   chunk? But why the compiler would fail on the first expression? (
> i.e. it could not know what X is when the whole expression is do-ited
>   in one piece..) Quite puzzling.

Smalltalk at: #X put: Array.
X new

When you select and doIt on all the above then two things happen.
1) The compiler converts the source code into byte codes
2) The bytes codes are evaluated to perform the required operations

When you highlight and doIt on _both lines together_ then the compilation
fails because _at the time of the compilation_ X is undefined.

If, in a workspace, you highlight and evaluate each line _on its own_ then
everything is OK.  The doIt on the first line creates an X object so the
compilation of the second line will succeed as, now, the compiler knows
about the X object.

When you file in anything in chunk format each chunk is evaluated (compiled
and doIted) separately and in sequence so if each line of the above is in
its own chunk then everything will work.

Just to complicate things a bit more :-) there is a way of inlining an
evaluation into a compilation.  If you evaluate all of the following in a
workspace then you won't get an error.

##(Smalltalk at: #X put: Array).
X new

There have been a number of discussions of the ##() construct in the
newsgroup so I won't repeat them here - ask if you can't locate them.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Hi Ian,
you wrote:
> Just to complicate things a bit more :-) there is a way of inlining an
> evaluation into a compilation.  If you evaluate all of the following in a
> workspace then you won't get an error.
>
> ##(Smalltalk at: #X put: Array).
> X new
> There have been a number of discussions of the ##() construct in the
> newsgroup so I won't repeat them here - ask if you can't locate them.

Yes, I got the idea from the post 'use of ##() in 1998/5/21 discussion that
this is a non-ANSI standard in using "inlining an evaluation while
compilation", which IMHO, maybe c/w Forth interpreter's behaviour of using
the immediate compiling words to do inline interpretation at compile time.
  e.g. codes like using [ ] in :xyz ( n - n1) [ code snippet ] other codes .
         the code snippet between [ and ] would be interpreted immediately
and compile inlined literals to the dictionary when the word xyz got
compiled.

  This is the struct in creating this kind of defining and compiling words
that make Forth so powerful and flexible ( sorry, I've been a Forth fancy
before.).

   IMHO, Smalltalk is compared to Lisp in its reflective ability, and
likewise, in using inlining construct, it may also be compared to Forth like
languages in compiling ability.
   Smalltalk would become more powerful on this way of absorbing more
languages' advantages, I liked it.


Tk Kuo

Ian Bartholomew wrote:


So I went to my closet, dug out an old straw hat,
and put it on.  Sure enough, the above explanation
made perfect sense.  First, you compile the universe.
Then, and only then, do you attempt to utilize any
partial results thereof.  One wants to stream ahead
through the entire source at full speed - because it
can take a long time to compile several 100 KLOCS.
Truly absurd notions like single pass compilation often
win out, even though they impose rather severe
constraints on the source language. Etc., etc., etc.

Anyone have an explanation that remains
sensible even while one is wearing an
incrementally compiled, fully reflective
OO hat constructed of many, many very short
strands of source material?

I can't think of one.

Cheers,

-cstb