Re: Chunk order must be small to large
Richard Gaskin wrote: It may be tempting to want to implement some custom behavior for, say, the truncate function. Raney felt that all that did is risk confusing anyone who calls that function while your handler is in the message path, so in his view it didn't merely expode the size of the token table, it polluted it. I went to the mat with him over this one years ago when I was porting an HC project. He said, If you need a custom behavior, use a custom name. I said, But I *need* to override the built-in function! and he asked simply, 'Need'? Why? I couldn't think of a truly necessary case. I heckled him about the same thing once. I really did have a necessary case, but it was a one-time event. I was converting a HC stack for a client. The original author had added sound effects to every action, hundreds and hundreds of them, throughout the stack. It was a business stack. Every time the office worker used it, they had to turn off the sound on the computer or else the squeaks and beeps and plonks and tweets drove everyone nuts. They wanted me to take out the sounds, which I fully agreed with. It would have been *so* easy to write a single play trap handler in the stack script. But I couldn't do it, I had to search through thousands of lines of code in hundreds of cards and remove each instance. Blech. But I've never needed to override the engine in anything I've written myself. I've only needed it in self-defense of others. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Chunk order must be small to large
Richard Gaskin wrote: I went to the mat with him over this one years ago when I was porting an HC project. He said, If you need a custom behavior, use a custom name. I said, But I *need* to override the built-in function! and he asked simply, 'Need'? Why? I couldn't think of a truly necessary case. Truly necessary is never going to be a really objective measure, and hence is not an easy threshold to meet. Especially talking to someone who could insist that there was no need for a constant equal to numtochar(13) because real programmers wouldn't use it, and that a simple statement, legal in the syntax, which crashed Rev with 100% reliability shouldn't be marked critical because it could only affect the programmer, who should know better. So I'm not suggesting any of the following would have got you off the mat. However, here's a couple of cases: * Relating to a recent discussion: I'd quite like my IDE extensions to override answer with a version that always had a special 'emergency exit' control, which would cause it to exit to top in the thread that invoked answer. * RevBrowser responds to a javascript alert in the hosted page by invoking 'answer'. I'd really like to trap this - currently I can't see any way to do so. If I could override answer, I'd have a method. ...but really I'm playing devil's advocate: I'm very happy with the trade-offs Scott Raney made that give us blazing speed. Ben ___ 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: Chunk order must be small to large
Ben Rubinstein wrote: Richard Gaskin wrote: I went to the mat with him over this one years ago when I was porting an HC project. He said, If you need a custom behavior, use a custom name. I said, But I *need* to override the built-in function! and he asked simply, 'Need'? Why? I couldn't think of a truly necessary case. Truly necessary is never going to be a really objective measure, and hence is not an easy threshold to meet. True, and it may actually be impossible to meet, at least in a purely logical sense. In law, civil cases have the lower threshold of preponderance of evidence, while criminal cases use beyond a reasonable doubt. But even criminal cases don't require absolute proof. The closer a logical threshold approaches an absolute, the less likely it is that it can be satisfied. While he was fond of terse phrases like that, in practice my discussions with Raney about languages features were guided by a more pragmatic principle: Is it worth it? Most things in computing involve trade-offs, often of memory vs. speed, and in the case of supporting all of HypeTalk's options it's more of flexibility vs. speed. Rebecca Bettencourt recently shared this valid HyperTalk example on the HC list: put empty into a put a b c into item put 1 into char put 2 into word if true then repeat with word char of item = char char to word of word char of char to word char to char of char char of word answer aHyperTalk is a bitch to parse end repeat else beep She also included this note with it: [The fifth line (if true then repeat with...) is really long and may need to be unwrapped. The sixth line (answer a...) has no ending quote, but have no fear.] No ending quote? Hmmmseems odd to me, but I trust her judgment here as she has far more experience finding the boundaries of HyperCard's interpreter than I do. To fully support HyperTalk would require allowing syntax like that to compile and execute. For myself, and perhaps Dr. Raney, I don't see that as a desirable goal at all, even without taking into account the impact it has on execution speed. But once we consider how much faster an engine can be once the parser is pruned down to expressions that are more valuable, it seems an even simpler choice to just say no, moving the gun so that it no longer points at the programmer's foot to a more useful target. With overriding built-in functions, I agree with his edict that if you need a custom behavior, give it a custom name. It just makes the code more transparent; I've hated doing maintenance on someone else's code where they overrode built-in behaviors in ways that were concealed from the reader. Using custom names for custom behaviors makes it self-evident that it's custom, right in the context where it's called, without having to do a search across the code base to see if an overriding handler may exist. With using built-in tokens as variables, Ms. Bettencourt's exaample illustrates everything we might want to say. :) With chunk order, requiring parentheses not only allows Rev to handle many of the expressions we might enjoy in HyperTalk, but also helps guide the eye when skimming code. I'll admit I'm a bit fond of parens and use them where they aren't even necessary, in things like: if (dev is in the environment) AND (the optionKey is down) then Parens can aid skimming. Code is far more frequently skimmed than read, so anything that helps the eye move quickly to what it's looking for is valuable two years later when you need to go back to enhance a feature. Sure, these are all limitations, restrictions over what was originally implemented in HyperTalk. But when we ask, Is it worth it?, just benchmark compatible scripts in both HC and Rev: Aside from a very few specific actions (HC's patented search algorithm is hard for anyone to beat), Rev's performance is often faster. And not just two times or three times faster, but in some cases by orders of magnitude. ... a simple statement, legal in the syntax, which crashed Rev with 100% reliability shouldn't be marked critical because it could only affect the programmer, who should know better. What statement is that, and has it been fixed? So I'm not suggesting any of the following would have got you off the mat. However, here's a couple of cases: * Relating to a recent discussion: I'd quite like my IDE extensions to override answer with a version that always had a special 'emergency exit' control, which would cause it to exit to top in the thread that invoked answer. Agreed on it's usefulness, but overriding the answer command seems a workaround to a deeper issue: exit to top isn't honored when called from within any modal dialog. http://quality.runrev.com/qacenter/show_bug.cgi?id=294 If we address that root issue and added support for Cmd-. to invoke it in that dialog (at least within the IDE), the answer command itself would be
Re: Chunk order must be small to large
I dug out my old copy of the v.2 User Guide. This guide has stuff in it that the v.3 guide does not. It has a short section on Complex chunk expressions, where it states: - chars can't contains words - words can't contain items - items can't contain lines Now I know what must be small to large means; its right in the book, and apparently has been for a while. On the streamlining of the Rev parser, having to use parens or quotes is a small price to pay not to have HC forebearance. Rebecca's script ditty is hilarious. How many would get it? How many would laugh? There are plenty of other goodies in that book, as I say, that ought not to have been discarded in the v.3 User Guide. Its organization is different, read odd, but still... Craig Newman ** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1220439616x1201372437/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26hmpgID %3D62%26bcd%3DfebemailfooterNO62) ___ 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: Chunk order must be small to large
DunbarX wrote: I dug out my old copy of the v.2 User Guide. This guide has stuff in it that the v.3 guide does not. It has a short section on Complex chunk expressions, where it states: - chars can't contains words - words can't contain items - items can't contain lines Now I know what must be small to large means; its right in the book, and apparently has been for a while. On the streamlining of the Rev parser, having to use parens or quotes is a small price to pay not to have HC forebearance. Rebecca's script ditty is hilarious. How many would get it? How many would laugh? There are plenty of other goodies in that book, as I say, that ought not to have been discarded in the v.3 User Guide. Its organization is different, read odd, but still... Good catch on the docs. Anyone know if this is completely gone or merely moved? If it's gone, it would make a good enhancement request to put it back: http://quality.runrev.com/qacenter/ -- Richard Gaskin Fourth World Revolution training and consulting: http://www.fourthworld.com Webzine for Rev developers: 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: Chunk order must be small to large
Richard Gaskin wrote: Ben Rubinstein wrote: ... ... a simple statement, legal in the syntax, which crashed Rev with 100% reliability shouldn't be marked critical because it could only affect the programmer, who should know better. What statement is that, and has it been fixed? See http://quality.runrev.com/qacenter/show_bug.cgi?id=1634 apparently fixed but I've never checked ... Agreed on it's usefulness, but overriding the answer command seems a workaround to a deeper issue: exit to top isn't honored when called from within any modal dialog. http://quality.runrev.com/qacenter/show_bug.cgi?id=294 If we address that root issue and added support for Cmd-. to invoke it in that dialog (at least within the IDE), the answer command itself would be fine. * RevBrowser responds to a javascript alert in the hosted page by invoking 'answer'. I'd really like to trap this - currently I can't see any way to do so. If I could override answer, I'd have a method. Custom-handling the JS alert sounds very valuable indeed, and while I haven't done much with RevBrowser thus far I will be later this year and may need that myself. I wonder if this might be handled well with a property, maybe something like the JSAlert, which would let you assign any command in your stacks to handle JavaScript alerts. If left empty, the current behavior would remain. Do you have a RQCC request for this? http://quality.runrev.com/qacenter/show_bug.cgi?id=6986 My point is exactly that - I totally accept if you need a custom behavior, give it a custom name - all the cases that I can think of where we do want to override a built-in function are because that would give us a workaround while waiting for communication with RevBrowser to be implemented, or for cmd-period doing exit to top in all threads, etc... We've recently begun a new project, for which we've settled on using Qt. Rev would have been faster; but one of the reasons we decided against it was that if you hit a problem with Rev, you may have no option but to take another route; because you can't fix the problems, and you can't wait for RunRev to fix them. (By contrast, Qt is just a set of frameworks - when push comes to shove, if you need to, you can dig into the C++ code and fix it yourself.) ...but really I'm playing devil's advocate: I'm very happy with the trade-offs Scott Raney made that give us blazing speed. Amen, brother. I loved it when C++ Journal wrote a review of my Rev-build WebMerge app in which they mistakenly said it was written in C. :) I wish I could take credit for that, but its performance has more to do with Raney pruning the token table than my scripts. Absolutely. I've replaced C code with Rev, and had it go faster; because (a) Raney is a brilliant programmer and (b) his code is more optimised - it took me so long to write the C code just to do the job, that it wasn't fast. I'm going to stop doing devil's advocate now... Ben ___ 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: Chunk order must be small to large
planets can't contain suns mice can't contain cats leaves can't contain trees etc. ad nauseam ROFL. :-) Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Mar 13, 2009, at 10:12 AM, dunb...@aol.com wrote: - chars can't contains words - words can't contain items - items can't contain lines ___ 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: Chunk order must be small to large
On Mar 13, 2009, at 10:53 AM, Bob Sneidar wrote: planets can't contain suns mice can't contain cats leaves can't contain trees etc. ad nauseam ROFL. :-) Ah, but mice can, and have, contained chunks of cats. Jim Ault Las Vegas ___ 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: Chunk order must be small to large
Craig- Friday, March 13, 2009, 10:12:27 AM, you wrote: This guide has stuff in it that the v.3 guide does not. It has a short section on Complex chunk expressions, where it states: - words can't contain items Don't believe everything you read, though... set the itemdelimiter to comma put the number of words in hello,sailor,new,in,town? put the number of items in hello,sailor,new,in,town? -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Chunk order must be small to large
From the dictionary in OSX 2.9 Word Designates a space-delimited or quoted string as part of a chunk expression. hello,sailor,new,in,town? has no spaces and thus is only one word. On Mar 13, 2009, at 2:08 PM, Mark Wieder wrote: Craig- Friday, March 13, 2009, 10:12:27 AM, you wrote: This guide has stuff in it that the v.3 guide does not. It has a short section on Complex chunk expressions, where it states: - words can't contain items Don't believe everything you read, though... set the itemdelimiter to comma put the number of words in hello,sailor,new,in,town? put the number of items in hello,sailor,new,in,town? -- -Mark Wieder mwie...@ahsoftware.net ___ 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: Chunk order must be small to large
Mark, 1 and 5, no? Craig Newman In a message dated 3/13/09 5:10:50 PM, mwie...@ahsoftware.net writes: - words can't contain items Don't believe everything you read, though... set the itemdelimiter to comma put the number of words in hello,sailor,new,in,town? put the number of items in hello,sailor,new,in,town? ** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1220439616x1201372437/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26hmpgID %3D62%26bcd%3DfebemailfooterNO62) ___ 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: Chunk order must be small to large
Mark, Oh, I see. Words containing items. Literal strings without spaces of course are one word. But still, another scriptJoke. And a good one. Craig Newman In a message dated 3/13/09 5:10:50 PM, mwie...@ahsoftware.net writes: Don't believe everything you read, though... set the itemdelimiter to comma put the number of words in hello,sailor,new,in,town? put the number of items in hello,sailor,new,in,town? ** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1220439616x1201372437/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26hmpgID %3D62%26bcd%3DfebemailfooterNO62) ___ 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: Chunk order must be small to large
Jim- Friday, March 13, 2009, 2:28:32 PM, you wrote: From the dictionary in OSX 2.9 Word Designates a space-delimited or quoted string as part of a chunk expression. hello,sailor,new,in,town? has no spaces and thus is only one word. Exactly. Yet it contains six items... -- -Mark Wieder mwie...@ahsoftware.net ___ 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 : Chunk order must be small to large
Hi from Paris, Take for example 5 * 5 + 1. Did we mean (5 * 5) + 1? Or did we mean 5 * (5 + 1)? Well we know by math formula rules that the multiplication is calculated first, so 26 is the correct answer. It would have been clearer to just use the parenthesis and avoid any confusion, and many programmers would. So does Rev. But my point is, someone decided that was the rule, so we could never be mistaken about what the result would be. I learned, in school (in England), nearly 60 years ago - BODMAS Brackets Off/Divide/Multiply/Add/Subtract I don't think that the rules have changed ! -Francis Nothing should ever be done for the first time ! ___ 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: Re : Chunk order must be small to large
Translating British into English is always interesting. PEMDAS parentheses,exponentiation,mult/div,add/subt Craig Newman On Mar 13, 2009, at 7:24:35 PM, Francis Nugent Dixon effe...@wanadoo.fr wrote: Brackets Off/Divide/Multiply/Add/Subtract I don't think that the rules have changed ! ___ 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: Chunk order must be small to large
In a message dated 3/12/09 11:16:10 AM, m.schonewi...@economy-x-talk.com writes: Mark. Sure. Just couldn't resist. I usually debug long convoluted constructs (word item 3 of line whatever) by adding parentheses just to see where the breakdown (usually mental) occurs. This one seemed so simple I never even thought to try it, especially since HC does not need to. Thanks... Craig Dear Craig, Would you mind giving messages subjects that make sense? Use parantheses to tell Revolution to parse a large chunk before a small chunk: answer item 1 of (word 1 of aaa,bbb) ** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1219671244x1201345076/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26hmpgID %3D62%26bcd%3DfebemailfooterNO62) ___ 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: Chunk order must be small to large
Stephen; Right. I was cavalier in thinking I can validate Rev issues by emulating them in HC. This is not fair to Rev. I like parentheses. But is this really a bug? Or just the way the parser works? I have many constructs in HC (get word line item 3 of the...) and I hope that this probably common and well regarded methodology is fully transparent to Rev, too. If I have to use parentheses, well, OK. So report or no? Anyone? Craig Newman In a message dated 3/12/09 12:07:47 PM, stephenrevoluti...@barncard.com writes: Odd. Yet this works properly: get word 1 of aaa,bbb answer item 1 of it put it Congratulations. You found a bug. Please report it to the QC. FYI - parentheses are your friend. the below construction works and makes it clearer anyway: answer item 1 of (word 1 of aaa,bbb)this really a bug? Or just the way the parser works? ** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1219671244x1201345076/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668 072%26hmpgID%3D62%26bcd%3DfebemailfooterNO62) ___ 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: Chunk order must be small to large
dunb...@aol.com wrote: Stephen; Right. I was cavalier in thinking I can validate Rev issues by emulating them in HC. This is not fair to Rev. I like parentheses. But is this really a bug? Or just the way the parser works? I have many constructs in HC (get word line item 3 of the...) and I hope that this probably common and well regarded methodology is fully transparent to Rev, too. If I have to use parentheses, well, OK. So report or no? Anyone? I don't think it's a bug, it's just how the parser works. Rev is far more particular in many respects than HC, which is partly what gives it such a speed increase. Enforced quoting of literals is another example, along with the inability to use keywords as variable names. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Chunk order must be small to large
It's the old tradeoff between functionality and ease of use. If you think about it, there are a lot of things we might want to say in Transcript (or whatevertheheck we are calling it these days). But we can't because there has to be SOME rules in play to prevent us from thinking we are saying one thing, and having Revolution think we are saying something else. Take for example 5 * 5 + 1. Did we mean (5 * 5) + 1? Or did we mean 5 * (5 + 1)? Well we know by math formula rules that the multiplication is calculated first, so 26 is the correct answer. It would have been clearer to just use the parenthesis and avoid any confusion, and many programmers would. So does Rev. But my point is, someone decided that was the rule, so we could never be mistaken about what the result would be. Perhaps you could have said 'answer item 1 of word 1 of aaa,bbb' in Hypercard, and Hypercard would be perfectly happy to decide what you meant. But someone decided beforehand what the rules would be. It isn't that there ISN'T a rule, it's just that the rule was heretofore unknown to us. The looser things are in the language, the greater the possibility that you will not get the results you expect. How often has THAT happened to us? As flexible as Transcript is, (please no corrections you know what I mean) it actually has a TON of rules that we subscribe to every day without even thinking about it. So the Rev people decided to make a new rule that said, Chunk order must be small to large and it may have had to do with the internal mechanics of the parser, but more likely it was to keep us from saying things that had no meaning. I mean, how much sense would it have made to say, 'the short name of stack toobig of card toosmall', or 'word 1 of char 1 of This doesn't make any sense?' That's my My 2¢. (pun intended). Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Mar 12, 2009, at 10:00 AM, dunb...@aol.com wrote: Stephen; Right. I was cavalier in thinking I can validate Rev issues by emulating them in HC. This is not fair to Rev. I like parentheses. But is this really a bug? Or just the way the parser works? I have many constructs in HC (get word line item 3 of the...) and I hope that this probably common and well regarded methodology is fully transparent to Rev, too. If I have to use parentheses, well, OK. So report or no? Anyone? Craig Newman In a message dated 3/12/09 12:07:47 PM, stephenrevoluti...@barncard.com writes: Odd. Yet this works properly: get word 1 of aaa,bbb answer item 1 of it put it Congratulations. You found a bug. Please report it to the QC. FYI - parentheses are your friend. the below construction works and makes it clearer anyway: answer item 1 of (word 1 of aaa,bbb)this really a bug? Or just the way the parser works? ** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1219671244x1201345076/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668 072%26hmpgID%3D62%26bcd%3DfebemailfooterNO62) ___ 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: Chunk order must be small to large
Hi Craig, Personally, I don't consider this as a bug. It's just that obviously the Rev parser considers *word* to be a smaller chunk than *item*. So, even without parentheses *get word 1 of item 1 of line 1 of aaa,bbb* works fine and the error message, if you change the order, is indicative of this parsing order. And this is logical as, a. You can set itemDelimiter and lineDelimiter but not the word delimiter (smallest chunk, which word boundary has undergone a change recently in Rev 3.0), b. When parsing text, words are generally smaller chunks than phrases, which are usually delimited with commas, c. As has been pointed out, you can override this parsing order using parenthesis, and lastly d. All that's needed here is *item 1 of aaa,bbb* ;-) Aloha from Hawaii, Jim Bufalini -Original Message- From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution- boun...@lists.runrev.com] On Behalf Of dunb...@aol.com Sent: Thursday, March 12, 2009 7:01 AM To: use-revolution@lists.runrev.com Subject: Re: Chunk order must be small to large Stephen; Right. I was cavalier in thinking I can validate Rev issues by emulating them in HC. This is not fair to Rev. I like parentheses. But is this really a bug? Or just the way the parser works? I have many constructs in HC (get word line item 3 of the...) and I hope that this probably common and well regarded methodology is fully transparent to Rev, too. If I have to use parentheses, well, OK. So report or no? Anyone? Craig Newman In a message dated 3/12/09 12:07:47 PM, stephenrevoluti...@barncard.com writes: Odd. Yet this works properly: get word 1 of aaa,bbb answer item 1 of it put it Congratulations. You found a bug. Please report it to the QC. FYI - parentheses are your friend. the below construction works and makes it clearer anyway: answer item 1 of (word 1 of aaa,bbb)this really a bug? Or just the way the parser works? ** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1219671244x1201345076/aol?redi r=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668 072%26hmpgID%3D62%26bcd%3DfebemailfooterNO62) ___ 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: Chunk order must be small to large
Jim Bufalini wrote: ... And this is logical as, a. You can set itemDelimiter and lineDelimiter but not the word delimiter (smallest chunk, which word boundary has undergone a change recently in Rev 3.0), b. When parsing text, words are generally smaller chunks than phrases, which are usually delimited with commas, c. As has been pointed out, you can override this parsing order using parenthesis, and lastly d. All that's needed here is *item 1 of aaa,bbb* ;-) And there's also e. you get a lot of raw speed by letting the parser safely make logical assumptions about chunk order. I asked Dr. Raney about this once, and he said that the other interpreters waste a lot of clock cycles letting you shoot yourself in the foot. He trimmed a number of syntax elements down, often removing support for non-intuitive or rare uses (like the mystery world in which a word is longer than a line) so that he could deliver blazing performance in return. In addition to enforcing a logical order to chunk sizes, other examples of this sort of optimization include: - You cannot use reserved tokens as variable names. Writing put word 1 into word makes code hard to read. So hard, in his opinion that it wasn't worth the parsing cost. - You cannot override built-in functions and commands. It may be tempting to want to implement some custom behavior for, say, the truncate function. Raney felt that all that did is risk confusing anyone who calls that function while your handler is in the message path, so in his view it didn't merely expode the size of the token table, it polluted it. I went to the mat with him over this one years ago when I was porting an HC project. He said, If you need a custom behavior, use a custom name. I said, But I *need* to override the built-in function! and he asked simply, 'Need'? Why? I couldn't think of a truly necessary case. He said if I could ever find a true need for this he'd reconsider. I told most everyone I knew; we put a lot of time into trying to think of a case. No luck. In the end we came to appreciate his edict: If you need a custom behavior use a custom name. Keeps code readable, lets folks know what to expect when they call something. For those coming into Rev fresh from HC these things go against long-standing habits, and will appear strange or even wrong at first. And then you start really working with it, learning these differences and moving on, and the more you code with this new engine the more you find yourself saying, Man, this thing is fast!. It's no accident. It's a very carefully pruned token table. -- Richard Gaskin Fourth World Revolution training and consulting: http://www.fourthworld.com Webzine for Rev developers: 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: Chunk order must be small to large
And I never saw this problem because I intuitively use parentheses! Stephen Barncard - San Francisco http://barncard.com 2009/3/12 Richard Gaskin ambassa...@fourthworld.com Jim Bufalini wrote: ... And this is logical as, a. You can set itemDelimiter and lineDelimiter but not the word delimiter (smallest chunk, which word boundary has undergone a change recently in Rev 3.0), b. When parsing text, words are generally smaller chunks than phrases, which are usually delimited with commas, c. As has been pointed out, you can override this parsing order using parenthesis, and lastly d. All that's needed here is *item 1 of aaa,bbb* ;-) And there's also e. you get a lot of raw speed by letting the parser safely make logical assumptions about chunk order. ___ 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: Chunk order must be small to large
Hi Stephen, How about instead of just elevating this from a bug to a problem we elevate it to a feature which, as Richard was so kind as to take the time to elaborate on and explain, that if the natural order is respected, even if you use parentheses, makes your code run faster. ;-) Aloha from Hawaii, Jim Bufalini -Original Message- From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution- boun...@lists.runrev.com] On Behalf Of stephen barncard Sent: Thursday, March 12, 2009 6:24 PM To: How to use Revolution Subject: Re: Chunk order must be small to large And I never saw this problem because I intuitively use parentheses! Stephen Barncard - San Francisco http://barncard.com 2009/3/12 Richard Gaskin ambassa...@fourthworld.com Jim Bufalini wrote: ... And this is logical as, a. You can set itemDelimiter and lineDelimiter but not the word delimiter (smallest chunk, which word boundary has undergone a change recently in Rev 3.0), b. When parsing text, words are generally smaller chunks than phrases, which are usually delimited with commas, c. As has been pointed out, you can override this parsing order using parenthesis, and lastly d. All that's needed here is *item 1 of aaa,bbb* ;-) And there's also e. you get a lot of raw speed by letting the parser safely make logical assumptions about chunk order. ___ 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
