RE: getting into the url cache
Actually I think you should doubt me most of the time ;-) I've been accused of writing "speculative drivel" on the rev list today ;-P > > On 12/12/02 7:43 PM, Monte Goulding wrote: > >It works ;-) > > I never really doubted you for a moment. ;) > > -- > Jacqueline Landman Gay | [EMAIL PROTECTED] > HyperActive Software | http://www.hyperactivesw.com > > ___ > metacard mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/metacard ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: getting into the url cache
On 12/12/02 7:43 PM, Monte Goulding wrote: It works ;-) I never really doubted you for a moment. ;) -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: getting into the url cache
Dave Cragg wrote:
> I use this technique a lot so don't give up. Monte's point about
> using compress on the "binfile" when making the compressed file may
> be significant.
These are coming over the 'Net, and it seems the "go url" command faithfully
transfers binary files as such -- thanks to you and Mpnte, I found the
limple logic error ib my script and now it works great.
Thanks! Hopefully the lil' toy I'm making with this wil be useful for you
folks as well
>> The "go stack" command takes a stack descriptor rather than stack data, so
>> it would seem your example is expecting MC to treat the decompressed stack
>> data as a stack descriptor, no?
>
> I thought the same until I started messing around one day.
Monte's explanation made it clear for me: even a stack descriptor
ultimately becomes evaluated to stack data. Just when you think you've
learned everything about a language there's always another few thousand
things to learn. :)
> Another trick is to set a custom property to a compressed stack file. E.g.
>
> set the cMagicStack of this stack to compress(url
> ("binfile:path/to/file.mc"))
>
> Then do this:
>
> go stack decompress(the cMagicStack of this stack)
>
> I've never used this for anything practical, but I've often wondered
> about employing this technique as a way of creating configuration
> palettes for distributable widgets that you create as a group of
> objects. Normally you would use a substack as a palette, but you
> can't copy substacks with groups.
>
> For example, you might make some kind of table object as a group of
> fields and buttons. And you've made it in a way that you can
> configure various settings, for example, the number of columns or
> rows. You might do this with some setprop handlers in the group. Then
> you want to copy the object into various other stacks. But you want
> to be able to configure the settings of these copies with a visual
> interface instead of relying on scripting. So you create a stack that
> lets you set the configurable options for the widget (rows, columns,
> whatever) and put the stack inside a custom property of the group.
> You also provide a means in the group (option-clicking for example)
> to open this "magic window". Feasible?
I would imagine so.
Ever since MC added gzip support I've been a happy boy, with the limitation
that gzip files contain only one file and lose the Mac meta data.
But enamored as I am of using custom props as carriers for binary daa, I've
been working on a simple tool to compress a folder's contents into gzipped
customm props in a stack file, with Mac meta data preserved on
decompression. Time permitting I'll have that done in a couple weeks after
I clear some more urgent projects off my plate.
In the meantime I wrote a very simple utility for gzipping and un-gzipping
single files, with the mdest benefit of having the Mac filetype set
appropriately if the decompressed file ends with ".mc" or ".rev". I just
uploaded it to the RunRev user contributions page -- hopefully it will
appear there soon.
--
Richard Gaskin
Fourth World Media Corporation
Developer of WebMerge 2.1: Publish any database on any site
___
[EMAIL PROTECTED] http://www.FourthWorld.com
Tel: 323-225-3717 AIM: FourthWorldInc
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard
RE: getting into the url cache
> Kind of cool, if it works. Very cool if you write an app that needs to transfer data from one user's version to another via email and want to save bandwidth. I didn't just come up with the script off the top of my head I cut and pasted from the file management library of my app. It works ;-) ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: getting into the url cache
On 12/12/02 7:22 PM, Richard Gaskin wrote: I appreciate your chiming in here, Monte. I'll double-check my code, but the implications of your presumably functioning code example above are quite a change to my understanding of things: I can use raw data (from a valid stack file, of course) instead of a stack descriptor with the "go stack" command? Hmmm It doesn't sound like the script actually loads raw stack data directly; instead, it puts the binary data into a variable, and then the variable functions as a sort of mutant stack reference. Kind of cool, if it works. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: getting into the url cache
> > I appreciate your chiming in here, Monte. I'll double-check my code, but > the implications of your presumably functioning code example > above are quite > a change to my understanding of things: I can use raw data (from a valid > stack file, of course) instead of a stack descriptor with the "go stack" > command? Hmmm > It's reasonably easy to understand. It's just an order of operations thing. go stack url "http://mydomain.com/myfile.mc"; is go stack (url "http://mydomain.com/myfile.mc";) I had the same challenge understanding: put url "http://mydomain.com/myfile.gif"; into image "myimage" Obviously you can think of it as: go stack ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: getting into the url cache
Monte Goulding wrote:
> It may be a problem on the compression side. I use a compressed stack as a
> custom file format for one of my apps and I use:
>
> -- saving
> save stack tName as pSave
> put compress(url ("binfile:"&pSave)) into url ("binfile:"&pSave)
> -- opening
> put decompress(url ("binfile:"&tOpen)) into tStack
> go stack tStack
>
> I was having errors like to ones you said until I started treating the stack
> as a binary file and the compressed data as binary.
I appreciate your chiming in here, Monte. I'll double-check my code, but
the implications of your presumably functioning code example above are quite
a change to my understanding of things: I can use raw data (from a valid
stack file, of course) instead of a stack descriptor with the "go stack"
command? Hmmm
--
Richard Gaskin
Fourth World Media Corporation
Developer of WebMerge 2.1: Publish any database on any site
___
[EMAIL PROTECTED] http://www.FourthWorld.com
Tel: 323-225-3717 AIM: FourthWorldInc
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard
Re: getting into the url cache
At 3:47 pm -0800 12/12/02, Richard Gaskin wrote:
First:
load url "http://whatever.com/whatever.gz"; ##now in cache
then later:
go stack decompress(url "http://whatever.com/whatever.gz";) ##will
take it from the cache
I don't think so. Here I get a "not a stack" error, which seems logical
once I thought it through.
I use this technique a lot so don't give up. Monte's point about
using compress on the "binfile" when making the compressed file may
be significant.
The "go stack" command takes a stack descriptor rather than stack data, so
it would seem your example is expecting MC to treat the decompressed stack
data as a stack descriptor, no?
I thought the same until I started messing around one day.
Another trick is to set a custom property to a compressed stack file. E.g.
set the cMagicStack of this stack to compress(url
("binfile:path/to/file.mc"))
Then do this:
go stack decompress(the cMagicStack of this stack)
I've never used this for anything practical, but I've often wondered
about employing this technique as a way of creating configuration
palettes for distributable widgets that you create as a group of
objects. Normally you would use a substack as a palette, but you
can't copy substacks with groups.
For example, you might make some kind of table object as a group of
fields and buttons. And you've made it in a way that you can
configure various settings, for example, the number of columns or
rows. You might do this with some setprop handlers in the group. Then
you want to copy the object into various other stacks. But you want
to be able to configure the settings of these copies with a visual
interface instead of relying on scripting. So you create a stack that
lets you set the configurable options for the widget (rows, columns,
whatever) and put the stack inside a custom property of the group.
You also provide a means in the group (option-clicking for example)
to open this "magic window". Feasible?
Cheers
Dave
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard
RE: getting into the url cache
>
> I don't think so. Here I get a "not a stack" error, which seems logical
> once I thought it through.
Hi Richard
It may be a problem on the compression side. I use a compressed stack as a
custom file format for one of my apps and I use:
-- saving
save stack tName as pSave
put compress(url ("binfile:"&pSave)) into url ("binfile:"&pSave)
-- opening
put decompress(url ("binfile:"&tOpen)) into tStack
go stack tStack
I was having errors like to ones you said until I started treating the stack
as a binary file and the compressed data as binary.
Hope this helps
Monte
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard
Re: getting into the url cache
Dave Cragg wrote: > At 10:53 am -0800 12/12/02, Richard Gaskin wrote: >> Dave Cragg wrote: >> How can we accss the cache to alter it before using the go url command? >>> >>> go stack decompress(url "http://whatever.com/whatever.gz";) >> >> How can that be used with the load command? > > First: > > load url "http://whatever.com/whatever.gz"; ##now in cache > > then later: > > go stack decompress(url "http://whatever.com/whatever.gz";) ##will > take it from the cache I don't think so. Here I get a "not a stack" error, which seems logical once I thought it through. The "go stack" command takes a stack descriptor rather than stack data, so it would seem your example is expecting MC to treat the decompressed stack data as a stack descriptor, no? -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.1: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: getting into the url cache
At 10:53 am -0800 12/12/02, Richard Gaskin wrote: Dave Cragg wrote: How can we accss the cache to alter it before using the go url command? go stack decompress(url "http://whatever.com/whatever.gz";) How can that be used with the load command? First: load url "http://whatever.com/whatever.gz"; ##now in cache then later: go stack decompress(url "http://whatever.com/whatever.gz";) ##will take it from the cache Or were you meaning something else? Cheers Dave ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: getting into the url cache
Dave Cragg wrote: >> How can we accss the cache to alter it before using the go url command? > > go stack decompress(url "http://whatever.com/whatever.gz";) How can that be used with the load command? -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.1: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: getting into the url cache
Dave Cragg wrote: > At 10:21 am -0800 12/12/02, Richard Gaskin wrote: >> We can download stacks easily using the load command, followed by a go url >> command once the file is cached. >> >> However, if we want to transfer gzipped stacks we need some way to run the >> url cache through the decompress function. >> >> How can we accss the cache to alter it before using the go url command? > > go stack decompress(url "http://whatever.com/whatever.gz";) Of course! Thank you. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.1: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: getting into the url cache
At 10:21 am -0800 12/12/02, Richard Gaskin wrote: We can download stacks easily using the load command, followed by a go url command once the file is cached. However, if we want to transfer gzipped stacks we need some way to run the url cache through the decompress function. How can we accss the cache to alter it before using the go url command? go stack decompress(url "http://whatever.com/whatever.gz";) Cheers Dave ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
