importing a bunch of files

[Thierry]

Hi,

Another thread about kind of Database :-)


For a specific project, I need to implement this:

I have an arbitrary set of text files stored on the disk in an
arbitrary numbers of directories, within a root one, ie:

dirRoot/
dirRoot/f1
dirRoor/f2
dirRoot/dir2/f3
dirRoot/dir2/dir3/f4
dirRoot/dir4/f5
...

When it comes to deliver the project,
I want to import all theses files,
and the tree organization
inside a stack ( datas only stack ).

I'm thinking of mapping each directory
to a group; the first group would be named dirRoot,
dir2 and dir4 would become groups named dir2 and dir4,
 children of the first group,
dir3 a group inside dir2 group, etc...

and for the files, importing them in custom properties
of these groups with the same name as the original files.

Let say it could be a hundred files or even more

One extreme could be one group with a hundred properties,
another one a hundred  nested groups with one property for each group.

Do you think this is realistic to do so,
and what kind of pitfalls i can find on the way ?

Another solution could be to create as many text fields as files,
with each field named with the full path of the corresponding  
file. ?


Any hints or thoughts are welcome, before I jump into it.

Regards,
Thierry


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

importing a bunch of files

[Randall Lee Reetz]

Thanks richard.  I would have thnked you off line but this samsung blackjack of 
mine is a minefield of hopelessness... It stuck me here so here i am.  Looks 
like rev does lots of things SC doesnt, what about the other way around?
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Eric Chatonet]

Bonjour Thierry,

Why don't you store directly your text files into custom properties,  
the name of which would be the path?
Of course you have to replace spaces and slashes with some string  
that will not break the name of the custom prop into several parts :-)
BTW note that custom props names are limited to 255 chars but I  
assume it should be enough.
Using fields will be cross platform straight on. With custom props  
you'll have to use macToIso or isoToMac to get the right text  
according to the platform.


Le 16 janv. 08 à 17:25, Thierry a écrit :


Hi,

Another thread about kind of Database :-)


For a specific project, I need to implement this:

I have an arbitrary set of text files stored on the disk in an
arbitrary numbers of directories, within a root one, ie:

dirRoot/
dirRoot/f1
dirRoor/f2
dirRoot/dir2/f3
dirRoot/dir2/dir3/f4
dirRoot/dir4/f5
...

When it comes to deliver the project,
I want to import all theses files,
and the tree organization
inside a stack ( datas only stack ).

I'm thinking of mapping each directory
to a group; the first group would be named dirRoot,
dir2 and dir4 would become groups named dir2 and dir4,
 children of the first group,
dir3 a group inside dir2 group, etc...

and for the files, importing them in custom properties
of these groups with the same name as the original files.

Let say it could be a hundred files or even more

One extreme could be one group with a hundred properties,
another one a hundred  nested groups with one property for each group.

Do you think this is realistic to do so,
and what kind of pitfalls i can find on the way ?

Another solution could be to create as many text fields as files,
with each field named with the full path of the corresponding  
file. ?


Any hints or thoughts are welcome, before I jump into it.

Regards,
Thierry


Best regards from Paris,
Eric Chatonet.

Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: [EMAIL PROTECTED]/



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: importing a bunch of files

[Randall Lee Reetz]

Wholy moly... The file system was definately NOT made to be a live data store.  
For one, disc IO is several orders of magnitude slower than memory IO.  Maybe 
soon a memory/file system meld will revolutionize computing, be we are about 30 
years behind this.  Retrieve your data from disc and unpack it ... Then do the 
reverse ... You can even do this in a background thread (in chunks on idle) all 
the time... But do your data work from within vars and custom props.  In the 
absence of native object inheritence handling in xtalk, it is tempting to use 
the file system's built in object tree (ontology) structure as an 
organizational tructure for data storage... But your question indiates a need 
to parse object heirarchies (a navigation algorithm) anyway, and once you have 
this its just as easy to use it to structure your data as use the file system 
for the same.  Am i helping you here?  It is sad that this level of data 
organization i not natively supported within xtalk (hint hint) but you have to 
roll your own... And that times every scripter = some serious waisted meat mips.

-Original Message-
From: "Thierry" <[EMAIL PROTECTED]>
To: "RevList" 
Sent: 1/16/2008 8:25 AM
Subject: importing a bunch of files

Hi,

Another thread about kind of Database :-)


For a specific project, I need to implement this:

I have an arbitrary set of text files stored on the disk in an
arbitrary numbers of directories, within a root one, ie:

dirRoot/
dirRoot/f1
dirRoor/f2
dirRoot/dir2/f3
dirRoot/dir2/dir3/f4
dirRoot/dir4/f5
...

When it comes to deliver the project,
I want to import all theses files,
and the tree organization
inside a stack ( datas only stack ).

I'm thinking of mapping each directory
to a group; the first group would be named dirRoot,
dir2 and dir4 would become groups named dir2 and dir4,
  children of the first group,
dir3 a group inside dir2 group, etc...

and for the files, importing them in custom properties
of these groups with the same name as the original files.

Let say it could be a hundred files or even more

One extreme could be one group with a hundred properties,
another one a hundred  nested groups with one property for each group.

Do you think this is realistic to do so,
and what kind of pitfalls i can find on the way ?

Another solution could be to create as many text fields as files,
with each field named with the full path of the corresponding  
file. ?

Any hints or thoughts are welcome, before I jump into it.

Regards,
Thierry


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: importing a bunch of files

[Randall Lee Reetz]

Not only that but using your disc files as dat fields or even record will 
seriously overburden your file system's day to day efficiency.  You could 
easily add orders of magnitude to the number of files and directories on disc.. 
Seriously slowing down a lot of OS (and finder) functionality.  Be good to your 
disc.

-Original Message-
From: "Randall Lee Reetz" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 1/16/2008 9:38 AM
Subject: RE: importing a bunch of files

Wholy moly... The file system was definately NOT made to be a live data store.  
For one, disc IO is several orders of magnitude slower than memory IO.  Maybe 
soon a memory/file system meld will revolutionize computing, be we are about 30 
years behind this.  Retrieve your data from disc and unpack it ... Then do the 
reverse ... You can even do this in a background thread (in chunks on idle) all 
the time... But do your data work from within vars and custom props.  In the 
absence of native object inheritence handling in xtalk, it is tempting to use 
the file system's built in object tree (ontology) structure as an 
organizational tructure for data storage... But your question indiates a need 
to parse object heirarchies (a navigation algorithm) anyway, and once you have 
this its just as easy to use it to structure your data as use the file system 
for the same.  Am i helping you here?  It is sad that this level of data 
organization i not natively supported within xtalk (hint hint) but you have to 
roll your own... And that times every scripter = some serious waisted meat mips.

-Original Message-
From: "Thierry" <[EMAIL PROTECTED]>
To: "RevList" 
Sent: 1/16/2008 8:25 AM
Subject: importing a bunch of files

Hi,

Another thread about kind of Database :-)


For a specific project, I need to implement this:

I have an arbitrary set of text files stored on the disk in an
arbitrary numbers of directories, within a root one, ie:

dirRoot/
dirRoot/f1
dirRoor/f2
dirRoot/dir2/f3
dirRoot/dir2/dir3/f4
dirRoot/dir4/f5
...

When it comes to deliver the project,
I want to import all theses files,
and the tree organization
inside a stack ( datas only stack ).

I'm thinking of mapping each directory
to a group; the first group would be named dirRoot,
dir2 and dir4 would become groups named dir2 and dir4,
  children of the first group,
dir3 a group inside dir2 group, etc...

and for the files, importing them in custom properties
of these groups with the same name as the original files.

Let say it could be a hundred files or even more

One extreme could be one group with a hundred properties,
another one a hundred  nested groups with one property for each group.

Do you think this is realistic to do so,
and what kind of pitfalls i can find on the way ?

Another solution could be to create as many text fields as files,
with each field named with the full path of the corresponding  
file. ?

Any hints or thoughts are welcome, before I jump into it.

Regards,
Thierry


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Thierry]

Le 16 janv. 08 à 17:39, Eric Chatonet a écrit :


Bonjour Thierry,

Why don't you store directly your text files into custom  
properties, the name of which would be the path?


Why not

Ok, it's a mix solution from the 2 I exposed :-)

Of course you have to replace spaces and slashes with some string  
that will not break the name of the custom prop into several parts :-)


Yes, I'm aware of that.
and it would be better to manage this  in the import function,  
running once,

when I build the final project.


BTW note that custom props names are limited to 255 chars but I  
assume it should be enough.


No, it could be more :-(
So, i have to split the path.
That's why I thought of nested groups.


Using fields will be cross platform straight on. With custom props  
you'll have to use macToIso or isoToMac to get the right text  
according to the platform.


Good point !
Thanks for this one, it will probably saved me some debug time :-)


Merci :-)
Bonne soiree


Le 16 janv. 08 à 17:25, Thierry a écrit :


Hi,

Another thread about kind of Database :-)


For a specific project, I need to implement this:

I have an arbitrary set of text files stored on the disk in an
arbitrary numbers of directories, within a root one, ie:

dirRoot/
dirRoot/f1
dirRoor/f2
dirRoot/dir2/f3
dirRoot/dir2/dir3/f4
dirRoot/dir4/f5
...

When it comes to deliver the project,
I want to import all theses files,
and the tree organization
inside a stack ( datas only stack ).

I'm thinking of mapping each directory
to a group; the first group would be named dirRoot,
dir2 and dir4 would become groups named dir2 and dir4,
 children of the first group,
dir3 a group inside dir2 group, etc...

and for the files, importing them in custom properties
of these groups with the same name as the original files.

Let say it could be a hundred files or even more

One extreme could be one group with a hundred properties,
another one a hundred  nested groups with one property for each  
group.


Do you think this is realistic to do so,
and what kind of pitfalls i can find on the way ?

Another solution could be to create as many text fields as files,
with each field named with the full path of the corresponding  
file. ?


Any hints or thoughts are welcome, before I jump into it



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Eric Chatonet]

Well :-)
You can also set a specific custom property set with custom  
properties the name of which does not matter and parse it:
In each custom property, line 1 will be the path and line 2 to -1  
contents :-)


Le 16 janv. 08 à 18:51, Thierry a écrit :



Le 16 janv. 08 à 17:39, Eric Chatonet a écrit :


Bonjour Thierry,

Why don't you store directly your text files into custom  
properties, the name of which would be the path?


Why not

Ok, it's a mix solution from the 2 I exposed :-)

Of course you have to replace spaces and slashes with some string  
that will not break the name of the custom prop into several  
parts :-)


Yes, I'm aware of that.
and it would be better to manage this  in the import function,  
running once,

when I build the final project.


BTW note that custom props names are limited to 255 chars but I  
assume it should be enough.


No, it could be more :-(
So, i have to split the path.
That's why I thought of nested groups.


Using fields will be cross platform straight on. With custom props  
you'll have to use macToIso or isoToMac to get the right text  
according to the platform.


Good point !
Thanks for this one, it will probably saved me some debug time :-)


Merci :-)
Bonne soiree


Le 16 janv. 08 à 17:25, Thierry a écrit :


Hi,

Another thread about kind of Database :-)


For a specific project, I need to implement this:

I have an arbitrary set of text files stored on the disk in an
arbitrary numbers of directories, within a root one, ie:

dirRoot/
dirRoot/f1
dirRoor/f2
dirRoot/dir2/f3
dirRoot/dir2/dir3/f4
dirRoot/dir4/f5
...

When it comes to deliver the project,
I want to import all theses files,
and the tree organization
inside a stack ( datas only stack ).

I'm thinking of mapping each directory
to a group; the first group would be named dirRoot,
dir2 and dir4 would become groups named dir2 and dir4,
 children of the first group,
dir3 a group inside dir2 group, etc...

and for the files, importing them in custom properties
of these groups with the same name as the original files.

Let say it could be a hundred files or even more

One extreme could be one group with a hundred properties,
another one a hundred  nested groups with one property for each  
group.


Do you think this is realistic to do so,
and what kind of pitfalls i can find on the way ?

Another solution could be to create as many text fields as files,
with each field named with the full path of the corresponding  
file. ?


Any hints or thoughts are welcome, before I jump into it



Best regards from Paris,
Eric Chatonet.

Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: [EMAIL PROTECTED]/



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Thierry]

Hi Randall,


Not only that but using your disc files as dat fields or even  
record will seriously overburden your file system's day to day  
efficiency.  You could easily add orders of magnitude to the number  
of files and directories on disc.. Seriously slowing down a lot of  
OS (and finder) functionality.  Be good to your disc.



M,
 I was probably not precise enough on what I need to do.



-Original Message-
From: "Randall Lee Reetz" <[EMAIL PROTECTED]>

Wholy moly...


can you teach me the meaning :-)


In this project, all the files I'm talking  are there !
Can't do anything against this, that's the start.

The main idea is to embed all the groups of files and directory inside
Revolution to avoid installing back to the user's space all these files,
plus as a security behavior because it's not possible to modify  
simply these files.


Am I a bit clearer ?

Thanks,

Regards,
Thierry


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Richard Gaskin]

Thierry wrote:

Of course you have to replace spaces and slashes with some string  
that will not break the name of the custom prop into several parts :-)


Yes, I'm aware of that.


I think such failure depends on how it's done.

I just ran this test:

on mouseUp
  put "some/thing" into v1
  put "some thing" into v2
  set the uTest[v1] of of this stack to "test"
  set the uTest[v2] of of this stack to "test"
end mouseUp

...and it worked well, with "some/thing" and "some thing" appearing 
among the lines of the customKeys of property set uTest, and I can also 
retrieve their values with the same notation.


Does anyone recall the specific syntax which might cause this to fail?

--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Eric Chatonet]

I posted the mail below but it did not appear in the list: so I  
apologize if it should appear twice.


Well :-)
You can also set a specific custom property set with custom  
properties the name of which does not matter and parse it:
In each custom property, line 1 will be the path and line 2 to -1  
contents :-)


Le 16 janv. 08 à 18:51, Thierry a écrit :



Le 16 janv. 08 à 17:39, Eric Chatonet a écrit :


Bonjour Thierry,

Why don't you store directly your text files into custom  
properties, the name of which would be the path?


Why not

Ok, it's a mix solution from the 2 I exposed :-)

Of course you have to replace spaces and slashes with some string  
that will not break the name of the custom prop into several  
parts :-)


Yes, I'm aware of that.
and it would be better to manage this  in the import function,  
running once,

when I build the final project.


BTW note that custom props names are limited to 255 chars but I  
assume it should be enough.


No, it could be more :-(
So, i have to split the path.
That's why I thought of nested groups.


Using fields will be cross platform straight on. With custom props  
you'll have to use macToIso or isoToMac to get the right text  
according to the platform.


Good point !
Thanks for this one, it will probably saved me some debug time :-)


Merci :-)
Bonne soiree


Le 16 janv. 08 à 17:25, Thierry a écrit :


Hi,

Another thread about kind of Database :-)


For a specific project, I need to implement this:

I have an arbitrary set of text files stored on the disk in an
arbitrary numbers of directories, within a root one, ie:

dirRoot/
dirRoot/f1
dirRoor/f2
dirRoot/dir2/f3
dirRoot/dir2/dir3/f4
dirRoot/dir4/f5
...

When it comes to deliver the project,
I want to import all theses files,
and the tree organization
inside a stack ( datas only stack ).

I'm thinking of mapping each directory
to a group; the first group would be named dirRoot,
dir2 and dir4 would become groups named dir2 and dir4,
 children of the first group,
dir3 a group inside dir2 group, etc...

and for the files, importing them in custom properties
of these groups with the same name as the original files.

Let say it could be a hundred files or even more

One extreme could be one group with a hundred properties,
another one a hundred  nested groups with one property for each  
group.


Do you think this is realistic to do so,
and what kind of pitfalls i can find on the way ?

Another solution could be to create as many text fields as files,
with each field named with the full path of the corresponding  
file. ?


Any hints or thoughts are welcome, before I jump into it



Best regards from Paris,
Eric Chatonet.

Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: [EMAIL PROTECTED]/



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: importing a bunch of files

[Randall Lee Reetz]

If you follow shuch a scheme, you will have to keep your internal data in 
lockstep with your stored data structure.  Choose one as master and let the 
other slave to it (always sticking to this heirarchy).  Either way, you will 
have to navigate some form of object tree... And translate that out to the 
other half of your memory/storage scheme.  People using xtalk talk about tables 
and arrays alot cause these are so much easier than ontologies.  Even a 
relational data structure is easier than a true object scheme as it is more 
hyper-linking than object inheritence (pointers without a seporate schema as 
formal map).

And there are causal limits at play here... How much data can your computer 
handle in memory?  If you are chunking up your data into seporate files, how do 
you keep annother file(s) as index for fast search and pointing into the data 
itself?  There are ideal ballances to shoot for in terms of data file size and 
index file size.  I have used schemes that maintain this ideal by cleaving and 
or combining data files when they reach arbitrary size thresholds (pointer 
index files updated in step).  All of this points to why it makes sense at 
times to interface your stack to a professional data base and let it do all of 
this structural efficiency heavylifting (that is what it is there for).  I like 
to build my own cause i like to learn... But the obsession is almost killing 
me.   

-Original Message-
From: "Thierry" <[EMAIL PROTECTED]>
To: "RevList" 
Sent: 1/16/2008 8:25 AM
Subject: importing a bunch of files

Hi,

Another thread about kind of Database :-)


For a specific project, I need to implement this:

I have an arbitrary set of text files stored on the disk in an
arbitrary numbers of directories, within a root one, ie:

dirRoot/
dirRoot/f1
dirRoor/f2
dirRoot/dir2/f3
dirRoot/dir2/dir3/f4
dirRoot/dir4/f5
...

When it comes to deliver the project,
I want to import all theses files,
and the tree organization
inside a stack ( datas only stack ).

I'm thinking of mapping each directory
to a group; the first group would be named dirRoot,
dir2 and dir4 would become groups named dir2 and dir4,
  children of the first group,
dir3 a group inside dir2 group, etc...

and for the files, importing them in custom properties
of these groups with the same name as the original files.

Let say it could be a hundred files or even more

One extreme could be one group with a hundred properties,
another one a hundred  nested groups with one property for each group.

Do you think this is realistic to do so,
and what kind of pitfalls i can find on the way ?

Another solution could be to create as many text fields as files,
with each field named with the full path of the corresponding  
file. ?

Any hints or thoughts are welcome, before I jump into it.

Regards,
Thierry


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: importing a bunch of files

[Randall Lee Reetz]

This 256 char path limit... who's is it... File system?  Rev?

-Original Message-
From: "Thierry" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 1/16/2008 9:51 AM
Subject: Re: importing a bunch of files


Le 16 janv. 08 à 17:39, Eric Chatonet a écrit :

> Bonjour Thierry,
>
> Why don't you store directly your text files into custom  
> properties, the name of which would be the path?

Why not

Ok, it's a mix solution from the 2 I exposed :-)

> Of course you have to replace spaces and slashes with some string  
> that will not break the name of the custom prop into several parts :-)

Yes, I'm aware of that.
and it would be better to manage this  in the import function,  
running once,
when I build the final project.


> BTW note that custom props names are limited to 255 chars but I  
> assume it should be enough.

No, it could be more :-(
So, i have to split the path.
That's why I thought of nested groups.


> Using fields will be cross platform straight on. With custom props  
> you'll have to use macToIso or isoToMac to get the right text  
> according to the platform.

Good point !
Thanks for this one, it will probably saved me some debug time :-)


Merci :-)
Bonne soiree

> Le 16 janv. 08 à 17:25, Thierry a écrit :
>
>> Hi,
>>
>> Another thread about kind of Database :-)
>>
>>
>> For a specific project, I need to implement this:
>>
>> I have an arbitrary set of text files stored on the disk in an
>> arbitrary numbers of directories, within a root one, ie:
>>
>> dirRoot/
>> dirRoot/f1
>> dirRoor/f2
>> dirRoot/dir2/f3
>> dirRoot/dir2/dir3/f4
>> dirRoot/dir4/f5
>> ...
>>
>> When it comes to deliver the project,
>> I want to import all theses files,
>> and the tree organization
>> inside a stack ( datas only stack ).
>>
>> I'm thinking of mapping each directory
>> to a group; the first group would be named dirRoot,
>> dir2 and dir4 would become groups named dir2 and dir4,
>>  children of the first group,
>> dir3 a group inside dir2 group, etc...
>>
>> and for the files, importing them in custom properties
>> of these groups with the same name as the original files.
>>
>> Let say it could be a hundred files or even more
>>
>> One extreme could be one group with a hundred properties,
>> another one a hundred  nested groups with one property for each  
>> group.
>>
>> Do you think this is realistic to do so,
>> and what kind of pitfalls i can find on the way ?
>>
>> Another solution could be to create as many text fields as files,
>> with each field named with the full path of the corresponding  
>> file. ?
>>
>> Any hints or thoughts are welcome, before I jump into it


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Randall Lee Reetz]

Richard,

In your script, it appears that a custom prop is dynamically declared  
just by setting it's value?  Is this all you have to do?  In  
SuperCard, one has to specifically declare a "user" property with a  
"define" statement before ever setting it's value.  Otherwise it  
doesn't know if you are declaring a var or a prop... how does Rev do  
this (oh, maybe it is the use of "set")?


Randall

On Jan 16, 2008, at 10:18 AM, Richard Gaskin wrote:


Thierry wrote:

Of course you have to replace spaces and slashes with some  
string  that will not break the name of the custom prop into  
several parts :-)

Yes, I'm aware of that.


I think such failure depends on how it's done.

I just ran this test:

on mouseUp
  put "some/thing" into v1
  put "some thing" into v2
  set the uTest[v1] of of this stack to "test"
  set the uTest[v2] of of this stack to "test"
end mouseUp

...and it worked well, with "some/thing" and "some thing" appearing  
among the lines of the customKeys of property set uTest, and I can  
also retrieve their values with the same notation.


Does anyone recall the specific syntax which might cause this to fail?

--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Jeanne A. E. DeVoto]

At 10:18 AM -0800 1/16/2008, Richard Gaskin wrote:

Thierry wrote:


 Of course you have to replace spaces and slashes with some string
that will not break the name of the custom prop into several parts
:-)



I just ran this test:

on mouseUp
  put "some/thing" into v1
  put "some thing" into v2
  set the uTest[v1] of of this stack to "test"
  set the uTest[v2] of of this stack to "test"
end mouseUp

...and it worked well, with "some/thing" and "some thing" appearing
among the lines of the customKeys of property set uTest, and I can
also retrieve their values with the same notation.



Quoting the custom property name will also work:

  set the uTest["some\thing"] of this stack to "test"

But I seem to recall Mr. Raney cautioning against naming custom 
properties anything that wouldn't be legal for variables, on the 
grounds that it may work now but might not work forever. (Of course, 
Mark would be the one to ask at this point whether that's still true 
- I had the impression that it was a peculiarity of the way custom 
properties are parsed, but I don't know whether it might change at 
this point. But something to consider...)

--
Jeanne A. E. DeVoto, Transcript Language Curmudgeon
[EMAIL PROTECTED]
http://www.jaedworks.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Eric Chatonet]

Hi Randall,

Le 16 janv. 08 à 19:41, Randall Lee Reetz a écrit :


This 256 char path limit... who's is it... File system?  Rev?


Obviously a Rev choice about used variables.
See 'Documentation/rev/Memory and Limits Reference.rev'

Best regards from Paris,
Eric Chatonet.

Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: [EMAIL PROTECTED]/



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Richard Gaskin]

Randall Lee Reetz wrote:
In your script, it appears that a custom prop is dynamically declared  
just by setting it's value?  Is this all you have to do?  In  
SuperCard, one has to specifically declare a "user" property with a  
"define" statement before ever setting it's value.


Yeah, and that extra line needed to declare every custom property used 
to drive me crazy.  I submitted a request to change that back when Gary 
Poppitz was SC's lead engineer, but he felt strongly about it so it 
never happened.  I was sure tickled to find it in Rev.


Gary's thinking was that he wanted to avoid having requests for props 
that didn't exist, but in practice that's rarer than assigning them so 
the tradeoff doesn't buy you any additional productivity.


When you try to access a property that doesn't exist in Rev, it just 
returns empty.  So how do you know whether it's not there or perhaps 
there but merely empty?  In such cases you can query the customKeys 
property:


  get the customKeys of btn 1

This returns a return-delimited list of all custom props in the current 
property set.   Keep in mind that you can have any number of property 
sets in an object, and switch between then with:


  set the customPropertySet of btn 1 to "UserData"

This can be especially handy when you have lots of different data for 
which it would be useful to use a single key.


For example, if you had some info about users you could do this:

  put "bob" into tName
  put "Age,Rank,Serial" into tSets
  repeat for each item tPropSet in tSets
 set the customPropertSet to tPropSet
 put the tName of this stack into fld tName
  end repeat

Lots of tricky things can be done with property arrays.


Now kindly allow me to blow your mind:

How many times have you wanted to replicate an object, but using copy 
and paste seemed cumbersome and you didn't want to muck with the user's 
clipboard?


In Rev, you can use "copy...to...", e.g.:

  copy btn 1 of stack "templates" to this cd

This copies the object into the current stack, and using the "to" form 
of "copy" leaves the clipboard alone.


But it gets better:

Just as you can get all of the customKeys of an object's property set as 
I noted above, you can even get all of the modifiable built-in 
properties as well, returned to you in a convenient array - try this, 
which also combines the array elements into a list for easy viewing:


put the properties of this stack into tmp
combine tmp with cr and tab
put tmp

So you can get and set all modifiable properties in a single line.

But if that's not convenient enough, you can also transfer all built-in 
properties from any object to any other of the same type in one line:


  set the properties of btn 1 to the properties of btn 2


Let's take this one step further:

Suppose you needed to create a hundred graphics on the fly, each with 
specific properties.  You could create them and then assign their 
properties, but Rev also gives us template objects, virtual objects from 
which anything created with the "Create" command will adopt all their 
properties.


So you could make those graphics like this:

   --  Just set up the template object...
   set the properties of the templateGraphic to \
 the properties of grc "MyTemplate"
   --
   -- ...and create the objects as normal:
   repeat with i = 1 to 100
  create grc
   end repeat


Ah, the limitless possibilities

:)


Rev's associative arrays and property sets are so useful that I 
recommend everyone take at least half a day just to play with them. 
Once you get a good feel for them a great many solutions become quick 
and easy, and often fun.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Thierry]

  set the uTest["some\thing"] of this stack to "test"

  cautioning against naming custom properties anything that  
wouldn't be legal for variables, on the grounds that it may work  
now but might not work forever.



Where can we see more about:  "be legal for variables"  ?

Regards,
Thierry


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Thierry]

Hi Randall,


If you follow shuch a scheme,   <...>


All of this points to why it makes sense at times to interface your  
stack to a professional data base and let it do all of this  
structural efficiency heavylifting (that is what it is there for).   
I like to build my own cause i like to learn...




But the obsession is almost killing me.


Well, as far as I can see with your emails,
it seems you're full alive :-)

Thanks for all your remarks.

M, without explaining all the project,
I can give some rules which can be seen as formal facts:

- No database engine wanted !

-  No databases needed for this tree files It's only a tree !
   These files are Text and only Text ,
and they are read only once,
but don't know when and in which order.

- From the user's point of view, it will makes no
   differences at all ( even fully invisible ) that the file is read  
from the disk
   or from whatever revolution's container where the text will be  
stored in.


- Revolution will be absolutely ignorant about the meaning of these  
files


- If all the files to be imported in a stack are too big,
   they can be compressed as an option.

- must work on Mac/Windows/Linux boxes

Here is the context of my question about transforming a tree of files.
By now, I will try  to do this with custompropertysets,
and see what happens.

Regards,
Thierry

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Devin Asay]

On Jan 17, 2008, at 5:56 AM, Thierry wrote:



  set the uTest["some\thing"] of this stack to "test"

  cautioning against naming custom properties anything that  
wouldn't be legal for variables, on the grounds that it may work  
now but might not work forever.



Where can we see more about:  "be legal for variables"  ?



From our tutorials at http://revolution.byu.edu/transcript/ 
Transcript1.php

A Revolution variable name:

May be any single string (no spaces) of letters, numbers, or  
underscores.

Must begin with a letter or underscore (never a number).
Cannot be a Transcript key word.
Is not case sensitive, but capital letters are often useful to  
improve readability.


I forget where I found these rules, but they were somewhere in the  
documentation. (Which begs the question that things should be easier  
to find in the docs.


HTH

Devin

Devin Asay
Humanities Technology and Research Support Center
Brigham Young University

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Devin Asay]

On Jan 17, 2008, at 9:29 AM, Devin Asay wrote:



On Jan 17, 2008, at 5:56 AM, Thierry wrote:


Where can we see more about:  "be legal for variables"  ?



From our tutorials at http://revolution.byu.edu/transcript/ 
Transcript1.php

A Revolution variable name:

May be any single string (no spaces) of letters, numbers, or  
underscores.

Must begin with a letter or underscore (never a number).
Cannot be a Transcript key word.
Is not case sensitive, but capital letters are often useful to  
improve readability.


I forget where I found these rules, but they were somewhere in the  
documentation. (Which begs the question that things should be  
easier to find in the docs.)



Ah, found it: The Revolution User Guide PDF, section 5.5.5 - Variable  
Names. (Open Documentation, click User Guide, then launch PDF.)


Devin

Devin Asay
Humanities Technology and Research Support Center
Brigham Young University

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: importing a bunch of files

[Randall Lee Reetz]

Have you written a file tree spider?

-Original Message-
From: "Thierry" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 1/17/2008 4:54 AM
Subject: Re: importing a bunch of files

Hi Randall,

> If you follow shuch a scheme,   <...>

> All of this points to why it makes sense at times to interface your  
> stack to a professional data base and let it do all of this  
> structural efficiency heavylifting (that is what it is there for).   
> I like to build my own cause i like to learn...


> But the obsession is almost killing me.

Well, as far as I can see with your emails,
it seems you're full alive :-)

Thanks for all your remarks.

M, without explaining all the project,
I can give some rules which can be seen as formal facts:

- No database engine wanted !

-  No databases needed for this tree files It's only a tree !
These files are Text and only Text ,
 and they are read only once,
 but don't know when and in which order.

- From the user's point of view, it will makes no
differences at all ( even fully invisible ) that the file is read  
from the disk
or from whatever revolution's container where the text will be  
stored in.

- Revolution will be absolutely ignorant about the meaning of these  
files

- If all the files to be imported in a stack are too big,
they can be compressed as an option.

- must work on Mac/Windows/Linux boxes

Here is the context of my question about transforming a tree of files.
By now, I will try  to do this with custompropertysets,
and see what happens.

Regards,
Thierry

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Stephen Barncard]

Where can we see more about:  "be legal for variables"  ?

Regards,
Thierry



The 'rules' for this might not be documented.

I've had problems with custom properties that are named like this:

1 a number  or begin with a number can be a problem
2 spaces in the name doesn't always work
3 use only alphanumeric characters except for underscore  (and maybe dashes)
4 no command token names
5 no object property names

this is why Richard's 'Hungarian Notation' works for this:

 'c'  prefix for custom property

cSQBMailPreferences<--good custom prop name - this will always work
cSQB_mailPreferences  <--with an underscore delimiter


of course any character, even binary is welcome inside any custom 
property. We're talking about property NAMES and Array key names.



--


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Thierry]

Hi Devin,



On Jan 17, 2008, at 5:56 AM, Thierry wrote:


Where can we see more about:  "be legal for variables"  ?


Ah, found it: The Revolution User Guide PDF, section 5.5.5 -  
Variable Names. (Open Documentation, click User Guide, then launch  
PDF.)


Ok, read it again, and there one can read:

   see the section of "Good Design Recommendation"

can't find this section :-(

Any ideas ?

Thanks,
Thierry

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Thierry]

Where can we see more about:  "be legal for variables"  ?


The 'rules' for this might not be documented.

I've had problems with custom properties that are named like this:

1 a number  or begin with a number can be a problem
2 spaces in the name doesn't always work
3 use only alphanumeric characters except for underscore  (and  
maybe dashes)

4 no command token names
5 no object property names

cSQBMailPreferences<--good custom prop name - this will always  
work

cSQB_mailPreferences  <--with an underscore delimiter




We're talking about property NAMES and Array key names.


and variables names too.

Ok, then, by quoting keys.
which is what I do most of the time with my hash,
all these recommandations can be dropped, no ?

or still some dark forces looking for other kind of bad writing ?

Regards,
Thierry

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Thierry]

Le 17 janv. 08 à 19:31, Randall Lee Reetz a écrit :


Have you written a file tree spider?


Not at all :-)

It's only a kind of administration tool to embed in *one* file
everything we need to run a complex application.

Interesting for Quality and Ease of deployment

I promess to show you the results when all this works !
Should be very soon, Mmmm, crossing fingers  :-)


and thanks all of you for your ideas and comments,

Regards,
Thierry

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Devin Asay]

On Jan 18, 2008, at 3:58 AM, Thierry wrote:


Hi Devin,



On Jan 17, 2008, at 5:56 AM, Thierry wrote:


Where can we see more about:  "be legal for variables"  ?


Ah, found it: The Revolution User Guide PDF, section 5.5.5 -  
Variable Names. (Open Documentation, click User Guide, then launch  
PDF.)


Ok, read it again, and there one can read:

   see the section of "Good Design Recommendation"

can't find this section :-(

Any ideas ?


Yikes! Looks like it must be in the part of the User Guide that still  
is not complete. My guess is that the missing section will talk about  
naming conventions like usingUpperCase in variable names and the  
Hungarian notation-lite that some developers recommend.


Devin

Devin Asay
Humanities Technology and Research Support Center
Brigham Young University

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Ken Ray]

On Wed, 16 Jan 2008 12:19:44 -0800, Randall Lee Reetz wrote:

> Richard,
> 
> In your script, it appears that a custom prop is dynamically declared 
> just by setting it's value?  Is this all you have to do?  In 
> SuperCard, one has to specifically declare a "user" property with a 
> "define" statement before ever setting it's value.  Otherwise it 
> doesn't know if you are declaring a var or a prop... how does Rev do 
> this (oh, maybe it is the use of "set")?

That's correct, Randall - you only need to "set" to both define and set 
the value of a custom property. Plus Rev has custom property *sets* as 
well, so you can keep arrays of data in custom properties.

So:

  set the age of fld 1 to 10  
  -- defines and sets 'age' custom prop

  set the scores["Ken"] of me to 75 
  -- defines the custom property set "scores" with one 
  -- key (element) called "Ken" and sets its value to 75
  set the scores["Randall"] of me to 90
  -- adds another key to "scores"

  put the keys of scores
  --> Ken
Randall

HTH,

Ken Ray
Sons of Thunder Software, Inc.
Email: [EMAIL PROTECTED]
Web Site: http://www.sonsothunder.com/
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Richard Gaskin]

Randall Lee Reetz wrote:
> Looks like rev does lots of things SC doesnt, what about the
> other way around?

Glad you asked. I'd made myself somewhat tiresome to some here over the 
last several years with my constant nagging about the two issues below, 
but since you asked I'll make this my now-only-annual plea for them:





In brief, it's infinitely easier to create custom drawing environments 
in SC than it is in Rev today, which could be corrected with those 
enhancements.


Also, Mark Lucas (SC's co-owner and lead engineer) is uncommonly 
passionate about the Mac and is perhaps the most tenacious programmer 
I've ever personally known.  As a result, I think it's fair to say that 
it's a tad easier to make truly Mac-HIG-conformant apps in SC than it is 
in Rev.


For example, you can mock up image wells in Rev using a group, but 
there's a few pixels difference in the curve between a group and a true 
image well, and IIRC SC allows you to make true image wells.


In all fairness to the good folks at RunRev, with the many platforms 
they support I can understand if some aspects of OS-specific features 
get prioritized lower than they would for a platform-specific tools like SC.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: importing a bunch of files

[Ken Ray]

On Fri, 18 Jan 2008 11:51:13 -0800, Randall Lee Reetz wrote:

> Thanks richard.  I would have thnked you off line but this samsung 
> blackjack of mine is a minefield of hopelessness... It stuck me here 
> so here i am.  Looks like rev does lots of things SC doesnt, what 
> about the other way around?

Apart from Richard's post, here's my take on what SC does that Rev 
doesn't (yet ;-) :

- SC has more flexibility with manipulating embedded imagedata 
(pictureData) than Rev (for example, you can pan, zoom, etc., 
especially now with 'quads'), but Rev lets you address and change 
individual pixels/alpha levels of an image. 

- IMHO, SC handles "larger-than-the-card" stacks (windows) much more 
fluidly than Rev - simply set the backSize of a window to something 
larger than the size of the window, and you're done... and scrolling 
windows as a window style let you move around this area more easily. 
You can do the same things in Rev, it just takes more work and more 
steps.

- SC 4.5 added a lot better field manipulation with rulers, 
per-paragraph alignment, etc.

 - I think that they're online language guide (SC Help) is better 
structured and easier to use, but that's not really SC itself (but I 
just thought I'd mention it).

I'm sure there's a handful of other items, but those are my top 3 (or 
4) places where SC does things Rev doesn't (or not as easily). 

Ken Ray
Sons of Thunder Software, Inc.
Email: [EMAIL PROTECTED]
Web Site: http://www.sonsothunder.com/
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution