>Though it bugs me to qualify scripting as not really
>programming, include me in that group nonetheless. I
>have been confronted head-on with this sterile debate
>of late, notably in the context of my doctoral studies
>in Cognitive Computing. It's an uphill battle.
Alain,
since I believe scripting to be much better than programming, as you do
not have to memorize all that cryptic syntax, you may see this as a
compliment :-)
>Excellent. This is exactly what I need right now. I
>have been saving and restoring the properties of
>FreeGUI's components by writing and reading text
>files. My way is a kludge though. I would much prefer
>using your XBF. Is it in the format of an external
>cmd/function ?
I did write a wrapper XCMD for XBF, but for one the property/part etc.
stuff is in XStackFile, and apart from that XBF is C++ code which I can't
put inside an XCMD. I have to make it a shared library that you have to
drop into the system extensions folder to be able to use it from the XCMD.
But I think XBF will be quite useful on its own, as you can arrange the
blocks and sub-blocks however you like.
>My first impression is that I would set it to true
>almost invariably. When would it be astute to set the
>"create" parameter to false?
E.g. when checking whether a certain block exists.
>Good thinking. In which case you would set the
>"create" parameter to true, correct?
Whenever you want to retrieve a block without having to care whether it
already exists. Of course, sometimes you have to set up some default values
first, which is when you'd probably not create it initially.
>That's pretty much how I handled the properties in
>FreeGUI. The content and the script have their own
>individual files, while the fixed-length props are all
>in one tab-delimited text-file.
Sounds interesting. Could you give us a quick update on what FreeGUI does
currently?
>Makes sense, although I have often noticed that long
>processes are often not as long as we fear they will
>be. Perhaps this is merely because knowing ALL that is
>going on (as a developer) makes us more patient as a
>user. Who knows. (shrug)
Probably, but if you have a button with a 2 GB script and 2 GB of
contents, it'll take quite a while until a change in the script can be
applied because it'd first have to shift the 2 GB of contents around.
Especially since it would probably happen on-disk using streaming.
>You could chain through the pointers of the objects
>composing the set/list each and every time. But I
>suppose this entails loading all of the objects (e.g.
>inefficient). Or you could do this once and create a
>list (e.g. index them).
Probably. However, generating an indexed list would mean additional RAM
requirements... with big stacks you'd have the names once in the block and
once in the indexed list in RAM. I've been thinking of keeping a list of
names of named blocks separately at the end of the file. This would mean
that there would only be entries for blocks that really have names there,
however, I'd have to find a way of uniquely identifying any block or
sub-block in the file.
Coming to think of it, maybe I should just keep a list of names in a block
of the owning object. After all, if you want to access a button, you'll
also have to load its card most of the time, so why not keep button names
with the card. Then the card can load the list of names without loading any
of the buttons.
>In my text-file architecture, I merely have to list
>the folders of the proper level of the HFS. Makes me
>wonder, by the way, how the Macintosh Finder handles
>this, and by extension whether we should do something
>similar to what the Finder does. Or something radical
>like an SQL database management system. Comments?
The Finder does this similarly to my file format, I suppose. But since
every file *must* have a name, it can safely make that assumption. However,
this doesn't work for XBF, as a button consists of one named container
block and lots of blocks inside that for the different parts of the button,
which aren't named. If we allowed every block to have a name, then we'd
waste lots of space on empty names for the sub-blocks.
>Any idea how HyperCard does this now? Or some other
>program's way of doing this? Some open source library
>perhaps?
Not really. And I'm reluctant to have a look at other file formats as then
I might be subject to claims that I had swiped their ideas.
>> But I will very likely hide this away inside
>> XStackFile, because there streaming can be employed
>> to avoid loading all sub-objects of a card or stack
>> just to look up one by name.
>
>Hard to disagree with that. ;-)
If you're on Mac, yes. However, where MetaCard came from this was a moot
point, as their virtual memory makes it pretty irrelevant whether you load
1 GB into RAM or just 2 bytes.
>Does that add another level of complexity to XBF, or
>is it relatively straightforward? If it unduly
>complicates things, then I naively suggest that we aim
>for a single stack file-format (e.g. to be more
>expeditious).
It's not a problem. I just have to add another block at the top level of
the block file to get another stack.
>With XBF and FreeGUI knitted together, we will almost
>have a full-fledged application on our hands. For,
>with FreeGUI, we will be able to browse a stack, view
>& edit its properties ; and with XBF, the properties
>will be saved and restored efficiently. Moreover, if
>XBF is packaged as an XCMD, then FreeGUI does not need
>anything other than HyperCard to run .. immediately.
>And, of course, there is always MetaCard's Starter-Kit
>too.... while we await FreeCard's own HyperTalk
>interpreter.
It will certainly provide a way to get going while things are still being
worked on. However, we won't be able to rely on MC or HC forever.
>More on this tomorrow and throughout the week, Uli,
>because it is getting late here in Quebec (Canada).
Well, I'm off to work now. See y'all in 7 hours.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
The future of programming: http://freecard.sourceforge.net
_______________________________________________
Freecard-general mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freecard-general
