Temp directory for Squeak

 
Hi,

I propose that we add one more user directory to squeak - a volatile writable
directory that can used for temporary files. On most hosts, temporaryDirectory
will be mapped to RAM and not hard disk or flash memory. RAM has reduced I/O
latency, power drain and wear/tear.

mktemp family of calls can be used to create it (on first access) portably in
both plugin code and in launch scripts.

One use case was its use to convert LaTeX code into images on the fly (cf
LatexMorph) for typesetting Indic/Math text.

We could use it for Squeakets, for caching large remote files, for dealing with
A/V clips etc.

Subbu

On 12.06.2010, at 17:20, K. K. Subramaniam wrote:

> Hi,
>
> I propose that we add one more user directory to squeak - a volatile writable
> directory that can used for temporary files. On most hosts, temporaryDirectory
> will be mapped to RAM and not hard disk or flash memory. RAM has reduced I/O
> latency, power drain and wear/tear.

Would the VM be responsible for deleting that directory when it exits?

> mktemp family of calls can be used to create it (on first access) portably in
> both plugin code and in launch scripts.

What would mktemp have to do with this? You need to pass it the location, it just creates a unique file.

> One use case was its use to convert LaTeX code into images on the fly (cf
> LatexMorph) for typesetting Indic/Math text.
>
> We could use it for Squeakets, for caching large remote files, for dealing with
> A/V clips etc.
>
> Subbu

At least on the OLPC XO, the RAM-backed tmp folder may be as small as 1 MB:

http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Writable_Directories

That does not seem sufficient for "large remote files" or video clips. Or even for larger Etoys projects, for that matter.

- Bert -

 
On Saturday 12 Jun 2010 11:01:41 pm Bert Freudenberg wrote:
> On 12.06.2010, at 17:20, K. K. Subramaniam wrote:
> > Hi,
> >
> > I propose that we add one more user directory to squeak - a volatile
> > writable directory that can used for temporary files. On most hosts,
> > temporaryDirectory will be mapped to RAM and not hard disk or flash
> > memory. RAM has reduced I/O latency, power drain and wear/tear.
>
> Would the VM be responsible for deleting that directory when it exits?
Yes. To reclaim tmpfs space. In case of a crash, the host will reclaim the
same on reboot.
 
> > mktemp family of calls can be used to create it (on first access)
> > portably in both plugin code and in launch scripts.
>
> What would mktemp have to do with this? You need to pass it the location,
> it just creates a unique file.
mktemp refers to a family of calls. mkdtemp creates a directory. mktemp -d
creates the same in a script.
 
> At least on the OLPC XO, the RAM-backed tmp folder may be as small as 1 MB:
>
> http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Writab
> le_Directories
>
> That does not seem sufficient for "large remote files" or video clips. Or
> even for larger Etoys projects, for that matter.
mkdtemp takes a path. For low-RAM XO models, one could mount/symlink flash
onto, say, /tmp/squeak/ and use it as a temporary directory for Squeak. Of
course, the startup scripts will have to wipe /tmp/squeak/ to take care of VM
crashes.

Subbu

On 12.06.2010, at 20:50, K. K. Subramaniam wrote:

You still need to give a path to mkdtemp. Which will be different for each platform.

So that's nothing better, just more complicated, than what we do now (use the activity instance dir for squeaklets).

Note I'm not opposed to your proposal, I just do not see any urgent need for it.

- Bert -

 
On Sunday 13 Jun 2010 12:34:09 am Bert Freudenberg wrote:
> You still need to give a path to mkdtemp. Which will be different for each
> platform.
Yes. This path can be computed in SecurityPlugin, so that is not an issue.

>Note I'm not opposed to your proposal, I just do not see any urgent need for
>it.
If it were really urgent, I would have submitted a fix ;-). I gave you an
example of LatexMorph where the feature was needed. I posted a proposal to see
if there is wider need for such a feature.

Subbu