Re: Arrays in Rev (long)

Wouter wrote: Another machine-dependant and environment-dependant comparison on my PowerBook G4 (400 MHz): Metacard: Props: 457 Vars: 40411 Array: 247 Revolution: Props: 1043 Vars: 38715 Array: 441 Completely depressed :^) What could the Rev IDE be doing that could so adversely affect all custom

Re: Arrays in Rev (long)

On 13 Jul 2004, at 17:09, [EMAIL PROTECTED] wrote: Message: 15 Date: Tue, 13 Jul 2004 07:08:51 -0700 From: Jim Hurley <[EMAIL PROTECTED]> Subject: Re: Arrays in Rev (long) To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" ;

Re: Arrays in Rev (long)

on 7/13/04 8:32 AM, Klaus Major at [EMAIL PROTECTED] wrote: > Does that stand for: "Mark" the "Mark" language? ;-) > >> Mark > > Regards > > Klaus Major Answer yes: Yes it does Klaus. ... and little green men have opened a coffee shop on the dark side of the moon. Why don't you go get some.

Re: Arrays in Rev (long)

on 7/13/04 8:23 AM, Troy Rollins at [EMAIL PROTECTED] wrote: > In the end, I'm seriously hoping that RunRev finds a way to implement > true Multi-D arrays natively, which hopefully will also ripple into > customkeys. > -- > Troy Now wait a second I want a high speed pull-parser first... :) mb _

Re: Arrays in Rev (long)

on 7/12/04 7:53 PM, Troy Rollins at [EMAIL PROTECTED] wrote: > Good lord, am I going to have to write or adapt one of the custom > solutions like the other guys have, just in order to get variables that > have power like I am used to? I think I'd rather just continue my huge > unlearning process a

Re: Arrays in Rev (long)

-- Message: 7 Date: Mon, 12 Jul 2004 21:33:56 -0700 From: Richard Gaskin <[EMAIL PROTECTED]> Subject: Re: Arrays in Rev (long) To: How to use Revolution <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-885

Re: Arrays in Rev (long)

Globals and script locals have the fastest access. Custom props are pretty fast, but still slower than variables. Stack-based data stored in a separate stack is slower yet it seems like there is a choice between power, speed, and pathing elegance being made here, and for the nature of many of m

Re: Arrays in Rev (long)

I have one gig space in www.wecode.org I can provide FTP, HTTP and Rev as CGI installed for you if you need. That would be great, Andre! Lets talk privately when you have a chance. -- Rob Cozens CCW, Serendipity Software Company "And I, which was two fooles, do so grow three; Who are a little wise

Re: Arrays in Rev (long)

On Jul 13, 2004, at 12:33 AM, Richard Gaskin wrote: Does 0.124ms per access have you tapping your foot with impatience? ;) Generally, no. Obviously not. As you say, speed is relative, and Rev is undeniably fast. I wonder what accounts for the difference. My PB has an L3 cache, 768MB RAM, OS X 1

Re: Arrays in Rev (long)

On Jul 13, 2004, at 12:27 AM, Dar Scott wrote: Right. Keys are always strings. However the elements (values) can be in internal numeric form. Yes, I just determined that when I added the key count at the end of the benchmark. My first attempt looked like - put the number of keys of tMyVar into

Re: Arrays in Rev (long)

Even more interesting, addressing the keys of the array by string name rather than integer key location, doesn't increase the time appreciably (then again, I imagine even the element location is a string in Transcript.) - That's because they're associative arrays (as opposed to numeric)... not

Re: Arrays in Rev (long)

Troy Rollins wrote: On Jul 12, 2004, at 11:41 PM, Richard Gaskin wrote: Yes, it takes almost six times longer to access a property than it does to access a local var. Run the benchmarking script below; on my modest single-processor G4 it gets: Props: 62 ms Vars: 12 ms Hmm. Very interesting, my

Re: Arrays in Rev (long)

On Jul 12, 2004, at 10:24 PM, Troy Rollins wrote: Even more interesting, addressing the keys of the array by string name rather than integer key location, doesn't increase the time appreciably (then again, I imagine even the element location is a string in Transcript.) - Right. Keys are always

Re: Arrays in Rev (long)

On Jul 13, 2004, at 12:08 AM, Troy Rollins wrote: But then, here is something interesting, based on an adaptation of your benchmark script (note that the array even uses a slower repeat structure.) - Even more interesting, addressing the keys of the array by string name rather than integer key l

Re: Arrays in Rev (long)

I timed these a different way on my dual 1.25 G4... On Jul 12, 2004, at 9:41 PM, Richard Gaskin wrote: set the uTest of this stack to "hello world" get the uTest of this stack 21.159 microseconds put "Hello World" into tMyVar get tMyVar .940 microseconds I got a much higher contrast

Re: Arrays in Rev (long)

On Jul 12, 2004, at 11:41 PM, Richard Gaskin wrote: Yes, it takes almost six times longer to access a property than it does to access a local var. Run the benchmarking script below; on my modest single-processor G4 it gets: Props: 62 ms Vars: 12 ms Hmm. Very interesting, my "modest" 1gHz G4 sho

Re: Arrays in Rev (long)

Troy Rollins wrote: On Jul 12, 2004, at 10:10 PM, J. Landman Gay wrote: If speed doesn't matter, then base your storage methods on convenience. If speed does matter, use variables. Alright. Noted. (Though Richard's article on stack properties suggested otherwise.) It depends on what you mean by "

Re: Arrays in Rev (long)

On Jul 12, 2004, at 10:10 PM, J. Landman Gay wrote: If speed doesn't matter, then base your storage methods on convenience. If speed does matter, use variables. Alright. Noted. (Though Richard's article on stack properties suggested otherwise.) BUT, variables are less powerful (or at least more

Re: Arrays in Rev (long)

On 7/12/04 12:25 PM, Troy Rollins wrote: So, it further occurred to me that leaving the inherent stack mechanisms out of my list of data storage tools for session data might be limiting my best choice (at times.) It depends on what you are doing. Note that while stack-based storage is expandable

Re: Arrays in Rev (long)

On Jul 12, 2004, at 12:58 PM, J. Landman Gay wrote: Global and script-local variables have always been enough, I've never needed anything else. Yes, thanks. I've become a big fan of script locals myself. I've learned to consider them like "object properties" once I realized they were persistent.

Re: Arrays in Rev (long)

Rob, I have one gig space in www.wecode.org I can provide FTP, HTTP and Rev as CGI installed for you if you need. I am setting up a nice portal there... I would be glad to help mirror and host your creations while you get out of this limbo. Cheers Andre On Jul 12, 2004, at 3:36 PM, Rob Cozens w

Re: Arrays in Rev (long)

Or as disk-based, client/server databases a la SDB. Rob, what is your URL for this tool? You should include it in your sig. Unfortunately, Troy, I'm currently in cyberspace limbo: Recent changes in my priorities & focus (see my sig) call for changes in my 'net presence. Unfortunately, my old web

Re: Arrays in Rev (long)

On 7/12/04 9:45 AM, Troy Rollins wrote: I can't believe people are using arrays in any of the fashions that have been described - so therefore people are using some other means of storing and retrieving similar data types. For temporary data, I use script-local and/or global variables. I've neve

Re: Arrays in Rev (long)

On Jul 12, 2004, at 11:50 AM, Rob Cozens wrote: Or as disk-based, client/server databases a la SDB. Rob, what is your URL for this tool? You should include it in your sig. -- Troy RPSystems, Ltd. http://www.rpsystems.net ___ use-revolution mailing list [E

Re: Arrays in Rev (long)

It helps if I think of stacks as very flexible databases... I think it does; yes, RAM-based databases. Or as disk-based, client/server databases a la SDB. -- Rob Cozens CCW, Serendipity Software Company "And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee." fro

Re: Arrays in Rev (long)

Hi Trevor, ... Know what i mean? Looks like this does NOT work with IT... I saw the other response to this but wanted to mention that when working with Custom Properties you can do something like this as well: put line 1 of fld 2 into array_name put line 3 of fld 5 into key_name set the customPro

Re: Arrays in Rev (long)

Troy Rollins wrote: On Jul 12, 2004, at 10:54 AM, Richard Gaskin wrote: One nice thing about using stacks for storage, though: you're always only one line away from saving that data if you ever need that somewhere down the road. ;-) Good point(s). And your point about using what the engine provi

Re: Arrays in Rev (long)

on 7/11/04 7:19 PM, Andre Garzia at [EMAIL PROTECTED] wrote: > you can use a XMLTree... nodes can contain nodes, you can structure > them like nested lists, and they are portable! > > :-) XML is like PCs vs Macs for me. I wish all my competitiors to use PCs and XML. MTML is nonSGML compliant and

Re: Arrays in Rev (long)

On Jul 12, 2004, at 12:07 PM, Troy Rollins wrote: It helps if I think of stacks as very flexible databases... Troy, take your time and point your browser to http://home.soapdog.org:8082/ it's a webserver implemented in Revolution. Look for http://home.soapdog.org:8082/feedback and to the register

Re: Arrays in Rev (long)

On Jul 12, 2004, at 2:20 AM, Klaus Major wrote: Hi Ken and all, I did not get an answer on this one, maybe you can give a hint? Does anybody know how to access CPsets/arrays without knowing either the arrayname nor the keyname? I mean the keys can be variables, but can the name also be a variable?

Re: Arrays in Rev (long)

On Jul 12, 2004, at 10:54 AM, Richard Gaskin wrote: One nice thing about using stacks for storage, though: you're always only one line away from saving that data if you ever need that somewhere down the road. ;-) Good point(s). And your point about using what the engine provides in order to make

Re: Arrays in Rev (long)

Troy Rollins wrote: > On Jul 11, 2004, at 10:35 PM, Richard Gaskin wrote: > >> > In my previous world, it was nested lists... and here in RevLand? >> >> The best answer would depend on usage -- can you give us a scenario >> for what you have in mind? >> >> Here's one option: >>

Re: Arrays in Rev (long)

On Jul 12, 2004, at 9:50 AM, Rob Cozens wrote: Rev can support non-keyed multidimensional arrays using multiple delimiter characters. While that is certainly an impressive approach, I really don't want to use arrays THAT much. I want to elegantly store and retrieve temporary associated data. I'm

Re: Arrays in Rev (long)

On Jul 12, 2004, at 3:09 AM, Ken Ray wrote: Transcript, this has certainly helped me to understand Rev's under-the-hood approach to them. Adding CRs, and doing splits somehow seems a bit less than straightforward, as you must then do mental translation from string lines, etc. in order to develop ap

Re: Arrays in Rev (long)

that's a very usefull code :D I wish I had this before! Thanks! You are most welcome, Andre. I would note further that syntax to support two dimensional arrays with no returns or commas in any element is even simpler: put thisValue into item yCoord of line xCoord of myArray ge

Re: Arrays in Rev (long)

Rob, that's a very usefull code :D I wish I had this before! Thanks! andre On Jul 12, 2004, at 10:50 AM, Rob Cozens wrote: A temporary stack as an advanced multi-dimensional variable? If this is the case, I think I like that much better than trying to force my own metaphor down the throat

Re: Arrays in Rev (long)

A temporary stack as an advanced multi-dimensional variable? If this is the case, I think I like that much better than trying to force my own metaphor down the throat of Rev by trying to create multidimensional arrays inside something which really has no support for them. Troy, et al: Rev c

Re: Arrays in Rev (long)

Hi Martin, Klaus Major Wrote: Does anybody know how to access CPsets/arrays without knowing either the arrayname nor the keyname? I mean the keys can be variables, but can the name also be a variable??? Something like: ... put line 1 of fld 2 into array_name put line 3 of fld 5 into key_name put t

Re: Arrays in Rev (long)

>Klaus Major Wrote: >Does anybody know how to access CPsets/arrays without knowing either >the arrayname nor the keyname? > >I mean the keys can be variables, but can the name also be a variable??? > >Something like: > >... >put line 1 of fld 2 into array_name >put line 3 of fld 5 into key_name >pu

Re: Arrays in Rev (long)

Hi Ken and all, I did not get an answer on this one, maybe you can give a hint? Does anybody know how to access CPsets/arrays without knowing either the arrayname nor the keyname? I mean the keys can be variables, but can the name also be a variable??? Something like: ... put line 1 of fld 2 into a

RE: Arrays in Rev (long)

> > Director: > > set myList = ["Troy","Ken","Richard"] > > put getAt(myList, 2) > > --> Ken > > Or in "modern dot-lingo" - > put myList[2] See, I TOLD you I was rusty! ;-) > Very awesome dissertation. While Director's techniques for array > handling are probably the only reason that I pe

Re: Arrays in Rev (long)

can't we pack this data as I don't know, base64 or CDATA... it will be a complex XML but I think it would work... or Rev XML engine got size limitations? like if we base64 a 2.2mb image and insert on a node, will it explode? Andre On Jul 11, 2004, at 11:39 PM, Troy Rollins wrote: On Jul 11, 200

Re: Arrays in Rev (long)

On Jul 11, 2004, at 10:19 PM, Andre Garzia wrote: you can use a XMLTree... nodes can contain nodes, you can structure them like nested lists, and they are portable! Yes, I strongly considered this, but am wondering about things like imageData, binary content, etc. -- Troy RPSystems, Ltd. http://

Re: Arrays in Rev (long)

On Jul 11, 2004, at 10:35 PM, Richard Gaskin wrote: The best answer would depend on usage -- can you give us a scenario for what you have in mind? For the most part, I mean "generally." In Director, the use of nested lists is... well, it is how you store working data, at least if you are at any

Re: Arrays in Rev (long)

Troy Rollins wrote: > What is the recommended way, in Rev, to store large amounts of > session temporary, relational data which includes both text > and non-text (binary) information? In terms of speed of access, > ease of access, ease of maintenance, etc. > > In my previous world, it was nested li

Re: Arrays in Rev (long)

On Jul 11, 2004, at 7:59 PM, Troy Rollins wrote: You can fetch box primer from http://www.swcp.com/dsc/revstacks.html Uh. I haven't put it there. I need to think on this. ;-) Fair enough. I was at the site, and I was about to say, "I don't think Dar has made that one generally available." So, my

Re: Arrays in Rev (long)

On Jul 11, 2004, at 10:59 PM, Troy Rollins wrote: ;-) Fair enough. I was at the site, and I was about to say, "I don't think Dar has made that one generally available." So, my question is still open... you can use a XMLTree... nodes can contain nodes, you can structure them like nested lists, a

Re: Arrays in Rev (long)

On Jul 11, 2004, at 9:49 PM, Dar Scott wrote: You can fetch box primer from http://www.swcp.com/dsc/revstacks.html Uh. I haven't put it there. I need to think on this. ;-) Fair enough. I was at the site, and I was about to say, "I don't think Dar has made that one generally available." So, my q

Re: Arrays in Rev (long)

On Jul 11, 2004, at 7:39 PM, Andre Garzia wrote: You can fetch box primer from http://www.swcp.com/dsc/revstacks.html Uh. I haven't put it there. I need to think on this. Dar ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailm

Re: Arrays in Rev (long)

Troy, I am a big advocate of Dar Scott Box Sequences. Box are containers, they can contain anything, even other boxes, so you can make nested boxes if you like. I use them in most my internal developments. My CS studies were done in Scheme, so I also am a big fan of lists and nested lists, usin

Re: Arrays in Rev (long)

On Jul 11, 2004, at 7:12 PM, Dar Scott wrote: Oh. There is one very positive thing. The best I can tell, you can put any string into an array element, including binary (arbitrary byte) values such as images. (The best I can tell, only keys cannot take arbitrary binary data.) I wrote a MUCH lo

Re: Arrays in Rev (long)

On Jul 11, 2004, at 3:31 PM, Dar Scott wrote: There are some things to watch for in array values. Array elements cannot (yet!) be arrays. The result of arithmetic retains full precision when saved as an element (numberFormat is not applied at saving) and is not coerced to a string. When conve

Re: Arrays in Rev (long)

Ken- Thanks for the great writeup on arrays. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Arrays in Rev (long)

On Jul 11, 2004, at 5:16 PM, Ken Ray wrote: LINEAR LISTS The simple linear lists in Director are straightforward - compare: Director: set myList = ["Troy","Ken","Richard"] put getAt(myList, 2) --> Ken Or in "modern dot-lingo" - put myList[2] More complex linear lists compare this

Re: Arrays in Rev (long)

on 7/11/04 2:31 PM, Dar Scott at [EMAIL PROTECTED] wrote: > Cool essay, Ken. I agree, very cool. > Director: > set myList = ["Troy","Ken","Richard"] > put getAt(myList, 2) > --> Ken by the way, this is also true in Director: Director: set myList = ["Troy","Ken","Richard"] put myList[2] & "