Re: having to help Rev (was: Re: Memory Leak on export png????)
As there has been talk of 'thorough testing' and in light of the recent posts trying to steer this thread into a different direction I thought I'd share my own recent tests. Not really Rev related, but as I'm sure everyone here does regular and thorough backups this may be of interest to one or two others. Also I'm waiting for Rev to download gm-4:-) For a while I've had this impression that my FW400 2.5 5400rpm portable HD backed up faster than my USB2 3.5 7200rpm External HD so I finally got around to actually sitting down and timing it and was extremely surprised. My test was 'real world' but not fair in that I 'Carbon Copy Cloned' one partition on my MacBook Pro to the FW400 2.5 and a different partition to the USB2 3.5 and used Activity Monitor to record the time at 1GB write intervals plus total time vs total GBs written. Of course there is a host of reasons why one partition may backup faster than another, but the results were so disparate (in favour of FW400) that I decided I needed a proper test. So using Drive Genius' 'Benchmark' facility I set about testing my 3.5 External HD which has both FW400 and USB2 connections. I've been using the USB2 connection because the advertised speed is suppose to be 120% that of FW400. Sustained Read Speeds measures how many times single-block reads can be performed in one second. This test is affected by read caching (the larger the read cache, the faster the performance). DataFW400USB2FW/USB 32K32.653 MB/s10.390 MB/s314% 64K36.364 MB/s15.534 MB/s234% 128K38.095 MB/s20.779 MB/s183% 256K39.024 MB/s21.477 MB/s182% 0.5M39.506 MB/s21.333 MB/s185% 1M40.000 MB/s21.192 MB/s189% 2M40.000 MB/s20.915 MB/s191% 4M39.506 MB/s21.769 MB/s181% 8M39.506 MB/s21.769 MB/s181% 16M39.025 MB/s22.535 MB/s173% Sustained Write Speeds measures how many times single-block writes can be performed in 1 second. This test is affected by write caching (the larger the write cache, the faster the performance). 32K17.978 MB/s7.805 MB/s230% 64K30.769 MB/s12.500 MB/s246% 128K32.323 MB/s17.297 MB/s187% 0.5M33.333 MB/s17.204 MB/s194% 1M33.684 MB/s17.297 MB/s195% 2M33.684 MB/s17.391 MB/s194% 4M33.684 MB/s17.204 MB/s196% 8M33.684 MB/s17.680 MB/s191% 16M33.684 MB/s17.204 MB/s196% Random Read measures drive performance for reads of blocks of data from 2 kilobytes to 16 megabytes. For small block sizes, seek time and rotational latency are weighted more heavily. For large block sizes, the transfer rate is weighted more heavily. 32K5.624 MB/s4.552 MB/s124% 64K9.143 MB/s8.020 MB/s114% 128K15.920 MB/s12.749 MB/s125% 256K22.857 MB/s15.610 MB/s146% 0.5M26.891 MB/s17.978 MB/s150% 1M32.653 MB/s19.632 MB/s166% 2M35.165 MB/s20.915 MB/s168% 4M37.647 MB/s21.333 MB/s176% 8M39.024 MB/s21.333 MB/s183% 16M39.024 MB/s21.192 MB/s184% Random Write measures drive performance for writes of blocks of data from 2 kilobytes to 16 megabytes. For small block sizes, seek time and rotational latency are weighted more heavily. For large block sizes, the transfer rate is weighted more heavily. 32K10.561 MB/s5.964 MB/s177% 64K15.842 MB/s9.846 MB/s161% 128K23.358 MB/s15.385 MB/s152% 256K30.476 MB/s16.410 MB/s186% 0.5M32.990 MB/s16.842 MB/s196% 1M33.684 MB/s17.021 MB/s198% 2M33.684 MB/s17.021 MB/s198% 4M33.684 MB/s16.754 MB/s201% 8M33.684 MB/s17.297 MB/s195% 16M33.684 MB/s17.486 MB/s193% The Drive Genius guff about each of the tests and what effects the speed is irrelevant in my case as the HD is the same, the only 'variables' are the bus controllers, the bus and the wire between them. Interestingly, although theoretically USB2 is suppose to be 120% FW400 my results are the exact opposite, FW400 only once fell below 120% the speed of USB2 and consistently ran at close to 200%. Guess I'll be disconnecting the USB2 and going with FW400:-) I'm assuming that my 3.5 HD must have a cheap and 'speed challenged' USB2 controller because if every other USB2 drive produced these kind of results I'm sure there'd be an uproar. I just wish I'd gone with my 'gut feeling' earlier and gone with FW400, I'd have saved myself half the time waiting for backups to complete:-( ___ 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: having to help Rev (was: Re: Memory Leak on export png????)
On 22 Mar 2007, at 18:29, Richard Gaskin wrote: Dave continued: I suppose my point is that in order to have a beta test, you need to have gone thru the steps to get there. It's no good producing mountains of code, doing little or no testing at the development phase and then throwing that out for beta. With 20/20 hindsight it's easy to suggest that stress testing would have found this leak, and indeed it might well have. But I don't think it would be a cost-effective practice for RunRev to adopt across this product. In the ten years I've been working with this engine this is the first verified leak I've seen. Let's be generous and say that maybe one or two others might have been discovered in that time. Even then, over a decade that's really quite good -- and accomplished without automated stress testing. There were three problems, the leak was just one of them. The export command appears to work well when run once or even a dozen times. Unit testing should always be done, and in this case would yield a good result. Only a sustained test with a great many iterations will expose this specific problem, and only in the Rev IDE. The leak doesn't exist in a standalone or in other IDEs, and since some issues may be specific to standalones it would be necessary to run any soak tests in at least those two environments. Not really if you were to write files 1 to 300 you would hit it at 288 and I had it happen earlier than that to start with. In fact the memory leak would be visible straight away, all you have to do is run once it and look at the memory allocations. And because Rev supports multiple operating systems, each with differing APIs and idiosyncrasies, each of those two tests would need to be run on all supported OSes. Here we already have a combinatorial explosion of test scenarios: 2 engines X Win 98, Win2K, WinME, WinXP, Vista, Mac OS 9, OS X 10.2, OS X 10.3, OS X 10.4, at least one Linux, and for anything that involves QT multiply 9 of those by the number of supported QT versions. That's 20 tests without QT, and just for one command. Agreed. To test it all those platforms would be hard. But in this case it just needed to be tested on the development machine of the person doing the coding and stressed for a lot of operations. I do this automatically without even thinking about it. I agree that you'd have to run it under the IDE and as a Standalone. To start with you just run it in the IDE, then at some point when you feel the time is right you build a standalone. To build a standalone for Mac and Windows takes literally seconds and in the case of the export snapshot the tests take 2 minutes to run. Consider all the effort to design, build, and run these tests, release after release, year after year, and after a decade of that we might turn up a leak or two and maybe a relative handful of other errors of the sort which can be exposed through that specific form of testing. Took me 10 minutes to build the test for the export snapshot command and 2 minutes to run it. On the first part I was working on (last week) it took me 30 minutes to build the tests and about the same to run the tests. I then ran it at least once a day (after I'd added/ changed things) to make sure I hadn't broken something. Another problem here is that people may have different ideas on what Beta means and I haven't seen it defined in terms of RunRev. One company I worked for defined it as meaning Feature Complete, No Known Crashing Bugs. That's the ideal, but I've known no company that ships every Beta in a state that meets that definition. Well, I've beta tested Photoshop and I AFAIK there were no known crashing bugs and AFAIR it was feature complete. I've participated in tests for Adobe, Microsoft, Apple, Oracle, and others who have shipped Betas while still developing new features. Feature Complete was just the way that company did it, I've also seen that beta versions that still being developed. I was trying to find out what beta meant in the wonderful world of RunRev. That you're able to run stress tests on all features and identify 100% of requirements to complete satisfaction before your first Beta is quite an accomplishment, Could you tell me where I said that? I run Stress Tests while developing my software as for requirements and when Beta testing is performed is up to the company I am working for in this case. In the past I have worked where this was the case though. However stress testing is not an accomplishment at all it's really easy, that's why I really can't see why you are going on about it, I do it without even thinking about it! In fact I was absolutely gobsmacked that you were surprised that this was my way of working. and we look forward to URLs of the products you ship so we can all learn how to improve the quality of our own work. Now
Re: having to help Rev (was: Re: Memory Leak on export png????)
ARRGHHH!!! MAKE IT STOP, PLEASE! Dave continued: However stress testing is not an accomplishment at all it's really easy, that's why I really can't see why you are going on about it, I do it without even thinking about it! In fact I was absolutely gobsmacked that you were surprised that this was my way of working. and we look forward to URLs of the products you ship so we can all learn how to improve the quality of our own work. Now you're just being silly! How will looking at the products I have worked on help you learn how to improve the quality of your own work? Besides which unless you just happen to have £50,000+ worth of video equipment lying around it wouldn't do you much good! And Apart from all that - I've told you how to do it already! Take Care and All the Best Dave -- 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: having to help Rev (was: Re: Memory Leak on export png????)
Dave persisted: On 22 Mar 2007, at 18:29, Richard Gaskin wrote: In the ten years I've been working with this engine this is the first verified leak I've seen. Let's be generous and say that maybe one or two others might have been discovered in that time. Even then, over a decade that's really quite good -- and accomplished without automated stress testing. There were three problems, the leak was just one of them. The third problem (garbage collection appearing to only be done at idle) was based on a misunderstanding of results and turned out to have no supporting evidence in this case, as I noted earlier: http://lists.runrev.com/pipermail/use-revolution/2007-March/095651.html That leaves only two, both of which require multiple iterations to be evident. The export command appears to work well when run once or even a dozen times. Unit testing should always be done, and in this case would yield a good result. Only a sustained test with a great many iterations will expose this specific problem, and only in the Rev IDE. The leak doesn't exist in a standalone or in other IDEs, and since some issues may be specific to standalones it would be necessary to run any soak tests in at least those two environments. Not really if you were to write files 1 to 300 you would hit it at 288 and I had it happen earlier than that to start with. Agreed: more than 288 iterations would be needed to see that problem. In fact the memory leak would be visible straight away, all you have to do is run once it and look at the memory allocations. That memory fluctuates while a program is running is normal. The cumulative effect in which some of that memory isn't released is only evident with multiple iterations. Consider all the effort to design, build, and run these tests, release after release, year after year, and after a decade of that we might turn up a leak or two and maybe a relative handful of other errors of the sort which can be exposed through that specific form of testing. Took me 10 minutes to build the test for the export snapshot command and 2 minutes to run it. On the first part I was working on (last week) it took me 30 minutes to build the tests and about the same to run the tests. I then ran it at least once a day (after I'd added/ changed things) to make sure I hadn't broken something. Hindsight. I'm sure you're aware that good soak tests commonly run far longer than 2 minutes, and in most cases for good reason. That this one isolated case was discoverable in less is as much of an anomaly as the rarity of the bug itself. Another problem here is that people may have different ideas on what Beta means and I haven't seen it defined in terms of RunRev. One company I worked for defined it as meaning Feature Complete, No Known Crashing Bugs. That's the ideal, but I've known no company that ships every Beta in a state that meets that definition. Well, I've beta tested Photoshop and I AFAIK there were no known crashing bugs and AFAIR it was feature complete. You wrote Known crashing bugs. That would require a level of testing rarely if ever possible in commercial application development. In fact other apps from Adobe (and other large companies as well) have been delivered to Beta with bugs which were discovered to cause crashes, and crashing issues sometimes even survive undetected into final builds. I've participated in tests for Adobe, Microsoft, Apple, Oracle, and others who have shipped Betas while still developing new features. Feature Complete was just the way that company did it, I've also seen that beta versions that still being developed. I was trying to find out what beta meant in the wonderful world of RunRev. It seems their definition is in keeping with industry norms. That you're able to run stress tests on all features and identify 100% of requirements to complete satisfaction before your first Beta is quite an accomplishment, Could you tell me where I said that? The sum of your posts suggest an expectation for other developers of that level of effort. It would seem reasonable that such expectations are at least met in your own shop. I run Stress Tests while developing my software Great. Another 10,000 function points and your work will begin to approach the complexity of Rev. However stress testing is not an accomplishment at all it's really easy ...for small programs, or with selective testing possible only with hindsight. that's why I really can't see why you are going on about it You might review your posts to see where this ongoing discussion of stress testing originated. You're welcome to stop going on about it at any time. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ use-revolution mailing
Re: having to help Rev (was: Re: Memory Leak on export png????)
:) ok Guys... you heard the man... I think you've both made your point/s, as thoroughly as is reasonably possible. Its been an interesting discussion. Let this be the last data point, please. Shake hands and agree to differ amicably. Warm Regards, Heather Heather Nagey Customer Services Manager and Listmom Runtime Revolution Ltd http://www.runrev.com On 23 Mar 2007, at 14:37, Stephen Barncard wrote: ARRGHHH!!! MAKE IT STOP, PLEASE! Dave continued: However stress testing is not an accomplishment at all it's really easy, that's why I really can't see why you are going on about it, I do it without even thinking about it! In fact I was absolutely gobsmacked that you were surprised that this was my way of working. and we look forward to URLs of the products you ship so we can all learn how to improve the quality of our own work. Now you're just being silly! How will looking at the products I have worked on help you learn how to improve the quality of your own work? Besides which unless you just happen to have £50,000+ worth of video equipment lying around it wouldn't do you much good! And Apart from all that - I've told you how to do it already! Take Care and All the Best Dave -- Heather Nagey Customer Services Manager Runtime Revolution Ltd http://www.runrev.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: having to help Rev (was: Re: Memory Leak on export png????)
Dave wrote: Took me 10 minutes to build the test for the export snapshot command and 2 minutes to run it. And, as it turns out, we were all wrong. There is a leak, and they will fix it, but the reason there is a leak makes perfect sense. The bug I posted about this problem only a day or two ago has already been verified and answered. This is a *strong* recommendation that those of you who don't want to submit reports should change your mind. Since I was the submitter, the respone came directly to my inbox. If Dave had submitted, he'd have received the response instead. Here is what they said, and now that I think of it, I'm almost embarrassed that I didn't think of the reason myself: The memory leak that has been observed here occurs for all forms of 'export snapshot' and any image format - however, it *only* occurs if the alwaysBuffer of the templateImage is set to true. To eliminate the leak: set the alwaysBuffer of the templateImage to false Before using the export command. The setting of this property is set differently in the Revolution and MC IDE's and in standalones (and on Mac OS X and Windows) - explaining the difficulty in reproducing it for some people. While I admit the leak needs to be fixed, the reason for it become obvious; alwaysbuffer reserves memory space for the image in an offscreen buffer. The bug does not show up on some platforms, and the alwaysbuffer setting varies from one IDE to another. It would be difficult to stress-test this bug; it only seems to occur in one very specific circumstance, in only one IDE, and only on one OS. Dave, your original script should work just fine if you change the alwaysbuffer of the templateimage to false. -- Jacqueline Landman Gay | [EMAIL PROTECTED] 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: having to help Rev (was: Re: Memory Leak on export png????)
On 23 Mar 2007, at 15:00, Richard Gaskin wrote: Dave persisted: On 22 Mar 2007, at 18:29, Richard Gaskin wrote: In the ten years I've been working with this engine this is the first verified leak I've seen. Let's be generous and say that maybe one or two others might have been discovered in that time. Even then, over a decade that's really quite good -- and accomplished without automated stress testing. There were three problems, the leak was just one of them. The third problem (garbage collection appearing to only be done at idle) was based on a misunderstanding of results and turned out to have no supporting evidence in this case, as I noted earlier: http://lists.runrev.com/pipermail/use-revolution/2007-March/ 095651.html That leaves only two, both of which require multiple iterations to be evident. The export command appears to work well when run once or even a dozen times. Unit testing should always be done, and in this case would yield a good result. Only a sustained test with a great many iterations will expose this specific problem, and only in the Rev IDE. The leak doesn't exist in a standalone or in other IDEs, and since some issues may be specific to standalones it would be necessary to run any soak tests in at least those two environments. Not really if you were to write files 1 to 300 you would hit it at 288 and I had it happen earlier than that to start with. Agreed: more than 288 iterations would be needed to see that problem. Not necessarily. For instance others have reported it happening at less. In fact the memory leak would be visible straight away, all you have to do is run once it and look at the memory allocations. That memory fluctuates while a program is running is normal. The cumulative effect in which some of that memory isn't released is only evident with multiple iterations. Not if the memory allocated is large as is the case of images and movies. Consider all the effort to design, build, and run these tests, release after release, year after year, and after a decade of that we might turn up a leak or two and maybe a relative handful of other errors of the sort which can be exposed through that specific form of testing. Took me 10 minutes to build the test for the export snapshot command and 2 minutes to run it. On the first part I was working on (last week) it took me 30 minutes to build the tests and about the same to run the tests. I then ran it at least once a day (after I'd added/ changed things) to make sure I hadn't broken something. Hindsight. I'm sure you're aware that good soak tests commonly run far longer than 2 minutes, and in most cases for good reason. That this one isolated case was discoverable in less is as much of an anomaly as the rarity of the bug itself. I agree, but the Another problem here is that people may have different ideas on what Beta means and I haven't seen it defined in terms of RunRev. One company I worked for defined it as meaning Feature Complete, No Known Crashing Bugs. That's the ideal, but I've known no company that ships every Beta in a state that meets that definition. Well, I've beta tested Photoshop and I AFAIK there were no known crashing bugs and AFAIR it was feature complete. You wrote Known crashing bugs. That would require a level of testing rarely if ever possible in commercial application development. In fact other apps from Adobe (and other large companies as well) have been delivered to Beta with bugs which were discovered to cause crashes, and crashing issues sometimes even survive undetected into final builds. Ok, this is just a language problem. By known, what I meant was that if a crashing bug was reported, it would be fixed before the next beta was released. I've participated in tests for Adobe, Microsoft, Apple, Oracle, and others who have shipped Betas while still developing new features. Feature Complete was just the way that company did it, I've also seen that beta versions that still being developed. I was trying to find out what beta meant in the wonderful world of RunRev. It seems their definition is in keeping with industry norms. Where is that defined? That you're able to run stress tests on all features and identify 100% of requirements to complete satisfaction before your first Beta is quite an accomplishment, Could you tell me where I said that? The sum of your posts suggest an expectation for other developers of that level of effort. It would seem reasonable that such expectations are at least met in your own shop. I was referring to requirements and beta testing. I run Stress Tests while developing my software Great. Another 10,000 function points and your work will begin to approach the complexity of Rev. And if RunRev stress tested while developing they would have a much more solid product.
Re: having to help Rev (was: Re: Memory Leak on export png????)
Hi, Here is the original script: on doExport local tNum local twID local tFol local tDest local myImageData put text of fld number into tNum put the windowID of this stack into twID put text of fld export folder into tFol if there is not a folder tFol then answer Export folder not found! exit to top end if set the defaultfolder to tFol repeat with x = 1 to (0 + tNum) put F- x .png into tDest put x into field FieldCounter of group GroupCounter set the alwaysBuffer of the templateImage to false --export snapshot from group GroupCounter to file tDest as PNG export snapshot from group GroupCounter to myImageData as PNG end repeat answer Done! end doExport I still get the error at file 289, is this what you thought would happen? Thanks a lot for this All the Best Dave On 23 Mar 2007, at 15:38, J. Landman Gay wrote: Dave wrote: Took me 10 minutes to build the test for the export snapshot command and 2 minutes to run it. And, as it turns out, we were all wrong. There is a leak, and they will fix it, but the reason there is a leak makes perfect sense. The bug I posted about this problem only a day or two ago has already been verified and answered. This is a *strong* recommendation that those of you who don't want to submit reports should change your mind. Since I was the submitter, the respone came directly to my inbox. If Dave had submitted, he'd have received the response instead. It's not that I don't want to, it's that I can't log on from here and when I get home at the weekends I am so tired and busy catching up with home stuff that it's hard to find the time. Here is what they said, and now that I think of it, I'm almost embarrassed that I didn't think of the reason myself: The memory leak that has been observed here occurs for all forms of 'export snapshot' and any image format - however, it *only* occurs if the alwaysBuffer of the templateImage is set to true. To eliminate the leak: set the alwaysBuffer of the templateImage to false Before using the export command. The setting of this property is set differently in the Revolution and MC IDE's and in standalones (and on Mac OS X and Windows) - explaining the difficulty in reproducing it for some people. While I admit the leak needs to be fixed, the reason for it become obvious; alwaysbuffer reserves memory space for the image in an offscreen buffer. The bug does not show up on some platforms, and the alwaysbuffer setting varies from one IDE to another. It would be difficult to stress-test this bug; it only seems to occur in one very specific circumstance, in only one IDE, and only on one OS. Dave, your original script should work just fine if you change the alwaysbuffer of the templateimage to false. ___ 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: having to help Rev (was: Re: Memory Leak on export png????)
We're only having a bit of fun! None of it is meant with any real venom well not on my part anyway and I'd be shocked if Richard felt differently! Take Care and Have a Great Weekend! All the Best Dave On 23 Mar 2007, at 15:11, Heather Nagey wrote: :) ok Guys... you heard the man... I think you've both made your point/s, as thoroughly as is reasonably possible. Its been an interesting discussion. Let this be the last data point, please. Shake hands and agree to differ amicably. Warm Regards, Heather Heather Nagey Customer Services Manager and Listmom Runtime Revolution Ltd http://www.runrev.com On 23 Mar 2007, at 14:37, Stephen Barncard wrote: ARRGHHH!!! MAKE IT STOP, PLEASE! Dave continued: However stress testing is not an accomplishment at all it's really easy, that's why I really can't see why you are going on about it, I do it without even thinking about it! In fact I was absolutely gobsmacked that you were surprised that this was my way of working. and we look forward to URLs of the products you ship so we can all learn how to improve the quality of our own work. Now you're just being silly! How will looking at the products I have worked on help you learn how to improve the quality of your own work? Besides which unless you just happen to have £50,000+ worth of video equipment lying around it wouldn't do you much good! And Apart from all that - I've told you how to do it already! Take Care and All the Best Dave -- Heather Nagey Customer Services Manager Runtime Revolution Ltd http://www.runrev.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: having to help Rev (was: Re: Memory Leak on export png????)
We're only having a bit of fun! fun for you, obviously. Annoying for most of us. None of it is meant with any real venom well not on my part anyway and I'd be shocked if Richard felt differently! Take Care and Have a Great Weekend! All the Best Dave -- 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: having to help Rev (was: Re: Memory Leak on export png????)
Hi, I really don't understand why you get so upset, if you don't like the subject just don't read it. There are loads of topics on this list I don't read them all. Most of them in fact stay unread. All the Best Dave On 23 Mar 2007, at 16:21, Stephen Barncard wrote: We're only having a bit of fun! fun for you, obviously. Annoying for most of us. None of it is meant with any real venom well not on my part anyway and I'd be shocked if Richard felt differently! Take Care and Have a Great Weekend! All the Best Dave ___ 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: having to help Rev (was: Re: Memory Leak on export png????)
Hi I found out from a complaint about one of my posts that some of the readers of this list get it in digest form instead of individual emails and it is difficult for them to ignore posts by headings (they have to scroll through them). So that might be why they're complaining. After I got the complaint about my post if made me very reluctant to post again as there were about three post immediately after agreeing with how annoying my posts were. Bill On 3/23/07 12:36 PM, Dave [EMAIL PROTECTED] wrote: I really don't understand why you get so upset, if you don't like the subject just don't read it. There are loads of topics on this list I don't read them all. Most of them in fact stay unread. ___ 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: having to help Rev (was: Re: Memory Leak on export png????)
Hi, Sounds like a good excuse to write a filter application - in RunRev of course! I don't think that Stephen receives the list via digest though. All the Best Dave On 23 Mar 2007, at 17:42, Bill wrote: Hi I found out from a complaint about one of my posts that some of the readers of this list get it in digest form instead of individual emails and it is difficult for them to ignore posts by headings (they have to scroll through them). So that might be why they're complaining. After I got the complaint about my post if made me very reluctant to post again as there were about three post immediately after agreeing with how annoying my posts were. Bill On 3/23/07 12:36 PM, Dave [EMAIL PROTECTED] wrote: I really don't understand why you get so upset, if you don't like the subject just don't read it. There are loads of topics on this list I don't read them all. Most of them in fact stay unread. ___ 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: having to help Rev (was: Re: Memory Leak on export png????)
This is a test. I'm sure it's imperative Dave 'get in' the last word. So, let's see. ___ 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: having to help Rev (was: Re: Memory Leak on export png????)
From: Dave [EMAIL PROTECTED] Hi, Sounds like a good excuse to write a filter application - in RunRev of course! I don't think that Stephen receives the list via digest though. I do read the list as a digest. I would have expressed my annoyance if Stephen hadn't beaten me to it. Jerry Jensen ___ 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: having to help Rev (was: Re: Memory Leak on export png????)
On 21 Mar 2007, at 18:29, Björnke von Gierke wrote: On 21 Mar 2007, at 18:47, Dave wrote: On 21 Mar 2007, at 15:17, Björnke von Gierke wrote: ... Actually we started the discussion at cross purposes I think. I was talking about first level soak (stress) testing in the development process before the code is checked in, before it goes to QA and *way* before it gets to beta stage. I know where you started, I'm neither knowledgeable nor interested enough to comment on your low level techniques. ... Having said that, I really wouldn't mind doing the beta testing for free on a volunteer basis, but not as an expectation! The mentioned expectation of forcing people to be beta tester hugely depends on three things: First, there's the expectation from the community, which can be perceived this or that way. For me there are some community members (as in any community) who want you to do as they would want to do themselves. Mostly I ignore those. However, If the most verbose members of a community expect the rest of the community to change according to their own ideals, the community will rupture, dwindle, die. So we as a community of Rev users must watch out for that. Secondly there's the expectation of RunRev to deliver meaningful bug reports, if you make any. Also before that they want you to look if the bug is already reported. I have no problem with that whatsoever. The last and most important part of this is How you perceive a message of a demand. This of course depends on the tone of the demand, and how strongly it correlates with your own expectation. Imagine someone demanding from you to breathe. In most situations you'd greatly agree, as you yourself deem breathing (vitally) important. Now imagine someone telling you not to breathe. In most situations that would run counter your own experience and principles, and you would declare him stupid. The problem is that not all concepts are as all-encompassing for every human as breathing. So what's one persons breathing bugs is another persons not breathing bugs. Note: I don't want to say you belong to either of the breathing/non breathing people. No one does. Almost every one is somewhere in between these two extremes. As are you, or the people that demand the filing of bugs of you. I signed up for the Beta Program a while back, but I heard nothing for months, then a short while ago I was contacted with the details, unfortunately I don't have enough time now. When I signed up I could have put aside a couple of hours a day. See, you breathe make beta's immediately after announcing them, and someone else doesn't. I really don't care if they are made available immediately or not. Would have been nice to have known what was going on, but after a few days and hearing nothing I forgot all about until it I got the message a week or so ago. If I have time I will do some testing, I had time then and I don't have time now. No problem, for me anyway. I only mentioned it since we were on the subject of being paid to do beta testing. You shouldn't ask yourself how to force the other person to breathe what you breathe. If the situation bothers you, you should try to find a form of breathing of which you think that both can agree upon, and propose that to the other person. Of course that person might still put you down, but the likelihood is probably quite a lot smaller. I really don't want to force anyone to do anything! Most situations don't bother me! I found a horrible problem in RunRev that prevented me doing something. I spent 1.5 days trying to find a work around. A few people from this list also took a look at the problem. I am guessing that the whole thing probably took around 3 man days, Once I had found a work around I commented that stress testing at the development stage would have saved this time, the discussion then drifted into beta testing. I suppose my point is that in order to have a beta test, you need to have gone thru the steps to get there. It's no good producing mountains of code, doing little or no testing at the development phase and then throwing that out for beta. Another problem here is that people may have different ideas on what Beta means and I haven't seen it defined in terms of RunRev. One company I worked for defined it as meaning Feature Complete, No Known Crashing Bugs. To me. the three main stages of development are: Development - Non feature complete may crash at any time. Alpha - Not Feature Complete, with any known crashing bugs documented and workarounds for other problems. Beta - Feature Complete, No Known Crashing bugs. If a crashing bug is found in the Beta stage, then it reverts back to Alpha. It would obviously be good to know what Beta means in terms of RunRev. All the Best Dave ___ use-revolution mailing list
Re: having to help Rev (was: Re: Memory Leak on export png????)
Dave continued: I suppose my point is that in order to have a beta test, you need to have gone thru the steps to get there. It's no good producing mountains of code, doing little or no testing at the development phase and then throwing that out for beta. With 20/20 hindsight it's easy to suggest that stress testing would have found this leak, and indeed it might well have. But I don't think it would be a cost-effective practice for RunRev to adopt across this product. In the ten years I've been working with this engine this is the first verified leak I've seen. Let's be generous and say that maybe one or two others might have been discovered in that time. Even then, over a decade that's really quite good -- and accomplished without automated stress testing. The export command appears to work well when run once or even a dozen times. Unit testing should always be done, and in this case would yield a good result. Only a sustained test with a great many iterations will expose this specific problem, and only in the Rev IDE. The leak doesn't exist in a standalone or in other IDEs, and since some issues may be specific to standalones it would be necessary to run any soak tests in at least those two environments. And because Rev supports multiple operating systems, each with differing APIs and idiosyncrasies, each of those two tests would need to be run on all supported OSes. Here we already have a combinatorial explosion of test scenarios: 2 engines X Win 98, Win2K, WinME, WinXP, Vista, Mac OS 9, OS X 10.2, OS X 10.3, OS X 10.4, at least one Linux, and for anything that involves QT multiply 9 of those by the number of supported QT versions. That's 20 tests without QT, and just for one command. Now let's look at what needs to be tested. With the export command alone, its various options would introduce maybe 8 tests. 8 permutations X 2 engines X 10 OSes = 160 tests. With hindsight we can limit the tokens to be tested to just those which have been worked on, but given the complexity of the engine and the interaction between tokens we'd want to test as many tokens as possible, ideally all of them. Looking at commands alone, not accounting for functions and various options for each command, we have 134. 134 commands X 2 engines X 10 OSes = 2680 tests, give or take a few. At a minimum we'd want to run each test for at least one hour See where this is going? Consider all the effort to design, build, and run these tests, release after release, year after year, and after a decade of that we might turn up a leak or two and maybe a relative handful of other errors of the sort which can be exposed through that specific form of testing. There are many methods by which a company can improve the quality of their work, of which stress testing is only one. There's also code review, unit testing, Beta testing, and more. Each has its strengths and weaknesses, and each is better at exposing certain types of errors than the others. Choosing the right mix of QA options for a given product at a given stage will take into account a great many factors, not the least of which is ROI. For a limited subset of features, stress testing can be very useful. But it isn't practical to design, build, and run stress tests for every feature, and I know of no vendor who does. That leaves us with the fine art of deciding which features get stress-tested and which ones don't. I know RunRev has stress-tested some features, but I don't know how they decide which ones they do. I'm pretty sure this one will be stress-tested now that it's been identified as a leak. Bringing this all back home, the leak you've discovered might well be the only one of its kind in more than a decade, and in less than two days since it was first reported an alternative solution was found that achieves the same result without error. A bug report has been filed, you're back to work, and all is well, in a fraction of the time one might expect with similar issues in a great many products. So looking at the minimal real-world impact of leak issues in Rev, I wouldn't be able to arrive at a cost justification for the type of stress testing which might have exposed this issue before Beta. But I'll meet you halfway: For a software as complex as Rev and which is used in so many very different circumstances, and one which appeals to a relatively slender audience (those who enjoy programming are such a small slice of the gene pool), the nature of the product will require a strong dependence on Beta testing. Historically, RunRev has often had Beta test cycles shorter than industry norms, and for a product with more complexity than average. So while I can't justify stress testing across the product, I would suggest that lengthening the Beta cycles to something closer to, and ideally exceeding, industry norms would likely improve product quality well above the cost of
Re: having to help Rev (was: Re: Memory Leak on export png????)
Richard, I typically hate to post 'me too' posts, but I have to agree with your most thorough analysis of this problem. While I haven't used the engine yet for 10 years, I have logged quite a number of hours and commercial project releases with it. I've never had a problem with memory leaks. I believe I do have some of the more graphical applications in development. ButtonGadget and ButtonGaget2, close to 5 years old and 1000's of commercial sales on both Mac and PC, has never had a single report of memory leakage-- nor for that matter random crashing. Hemingway PC, our content management system, stays open for weeks at a time without any problems. Same is true for our Enterprise development apps. We recently finished a product which was shipped in over 1 million devices and we expect no problems. I could go on and on, but you get my point. I'd *MUCH RATHER* RunRev focus their efforts on know bugs, feature additions and customer support than start running down this particular rabbit trail. Thanks for your eloquent post on this subject. best, Chipp ___ 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: having to help Rev (was: Re: Memory Leak on export png????)
On 21 Mar 2007, at 15:38, Dave wrote: On 20 Mar 2007, at 20:44, Stephen Barncard wrote: Dave wrote: RunRev can help by having Beta cycles whose length is more in keeping with industry norms, but the actual testing can't be done by them; there are just too many possibilities. I'd be happy to test it for them. How much are they paying? Unless you are trying to be funny, that sounds like you still don't get what Rev and this support community is about. Of course they can't pay you - why are you saying this? You know they only have x amount of resources - for me this support model really rocks - much better than other methods... Ok, if they don't have enough money to pay me now, then they can owe it to me, and, *if* and when they do make lots of money they can pay me then. How does that sound? I would charge £15.00 per hour, that's a lot cheaper than they are advertising their consultancy services for! Presumably the people at RunRev are getting paid a good salary or if not are being rewarded in terms of shares and/or the promise of money if and when they hit the big time. I do agree with Dave's general direction (if not with the way he expresses it). We all pay RunRev money so they can produce a good product. It's not our duty nor our responsibility to do any testing on their behave. Actually it should be the other way around. If there's a bug we should get an easy accessible list of workarounds, until the bug is fixed with the next release of Rev, of course in addition to every Feature anyone requested. On the other hand there's the open source approach. Users don't pay to use software, they commit time and effort to make the product better, so their own stuff based on the open source software gets better. Every user always puts equal effort into the open source foundation as into his own project. Bugs are fixed within minutes of their discovery, and every feature a user needs is implemented by that same user within even less time. But alas this world is not perfection wonderland, bugs are hard to find and to track down, feature additions make a product complicated, and aggravate people who are used to the old way. RunRev is walking a middle ground here. In my opinion, it's crucial for their future to not adopt the worst of both the commercial way and the open source way, but to work out a methodic to get the strengths of both worlds. That is not easy for such a small company, but if they have a clear vision about how they want to interact with their customers, then it is possible. Specifically, Bugzilla is a workaround for having no clue where bugs come from. Customers that find a bug are asked to make an effort to increase the product they paid for, and these bugs could linger for years due to time constrains. Unfortunately for everyone involved, that's how RunRev's software currently works. The existing system does not rock in any way. It's a patch on reality forced upon everyone by legacy, money and priority management, not more and not less. In hopes for a constructive discussion Björnke von Gierke -- official ChatRev page: http://chatrev.bjoernke.com Chat with other RunRev developers: go stack URL http://homepage.mac.com/bvg/chatrev1.3.rev; ___ 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: having to help Rev (was: Re: Memory Leak on export png????)
On 21 Mar 2007, at 15:17, Björnke von Gierke wrote: Ok, if they don't have enough money to pay me now, then they can owe it to me, and, *if* and when they do make lots of money they can pay me then. How does that sound? I would charge £15.00 per hour, that's a lot cheaper than they are advertising their consultancy services for! Presumably the people at RunRev are getting paid a good salary or if not are being rewarded in terms of shares and/or the promise of money if and when they hit the big time. I do agree with Dave's general direction (if not with the way he expresses it). We all pay RunRev money so they can produce a good product. It's not our duty nor our responsibility to do any testing on their behave. Actually it should be the other way around. If there's a bug we should get an easy accessible list of workarounds, until the bug is fixed with the next release of Rev, of course in addition to every Feature anyone requested. On the other hand there's the open source approach. Users don't pay to use software, they commit time and effort to make the product better, so their own stuff based on the open source software gets better. Every user always puts equal effort into the open source foundation as into his own project. Bugs are fixed within minutes of their discovery, and every feature a user needs is implemented by that same user within even less time. But alas this world is not perfection wonderland, bugs are hard to find and to track down, feature additions make a product complicated, and aggravate people who are used to the old way. RunRev is walking a middle ground here. In my opinion, it's crucial for their future to not adopt the worst of both the commercial way and the open source way, but to work out a methodic to get the strengths of both worlds. That is not easy for such a small company, but if they have a clear vision about how they want to interact with their customers, then it is possible. Specifically, Bugzilla is a workaround for having no clue where bugs come from. Customers that find a bug are asked to make an effort to increase the product they paid for, and these bugs could linger for years due to time constrains. Unfortunately for everyone involved, that's how RunRev's software currently works. The existing system does not rock in any way. It's a patch on reality forced upon everyone by legacy, money and priority management, not more and not less. Actually we started the discussion at cross purposes I think. I was talking about first level soak (stress) testing in the development process before the code is checked in, before it goes to QA and *way* before it gets to beta stage. In hopes for a constructive discussion Sounds good to me! Björnke von Gierke There are more ways of paying for something than money! Even if you only got a free T-Shirt or free hard copy of the manual it would be something. There really is no such thing as a free lunch. Having said that, I really wouldn't mind doing the beta testing for free on a volunteer basis, but not as an expectation! I signed up for the Beta Program a while back, but I heard nothing for months, then a short while ago I was contacted with the details, unfortunately I don't have enough time now. When I signed up I could have put aside a couple of hours a day. All the Best Dave ___ 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: having to help Rev (was: Re: Memory Leak on export png????)
On 21 Mar 2007, at 18:47, Dave wrote: On 21 Mar 2007, at 15:17, Björnke von Gierke wrote: ... Actually we started the discussion at cross purposes I think. I was talking about first level soak (stress) testing in the development process before the code is checked in, before it goes to QA and *way* before it gets to beta stage. I know where you started, I'm neither knowledgeable nor interested enough to comment on your low level techniques. ... Having said that, I really wouldn't mind doing the beta testing for free on a volunteer basis, but not as an expectation! The mentioned expectation of forcing people to be beta tester hugely depends on three things: First, there's the expectation from the community, which can be perceived this or that way. For me there are some community members (as in any community) who want you to do as they would want to do themselves. Mostly I ignore those. However, If the most verbose members of a community expect the rest of the community to change according to their own ideals, the community will rupture, dwindle, die. So we as a community of Rev users must watch out for that. Secondly there's the expectation of RunRev to deliver meaningful bug reports, if you make any. Also before that they want you to look if the bug is already reported. I have no problem with that whatsoever. The last and most important part of this is How you perceive a message of a demand. This of course depends on the tone of the demand, and how strongly it correlates with your own expectation. Imagine someone demanding from you to breathe. In most situations you'd greatly agree, as you yourself deem breathing (vitally) important. Now imagine someone telling you not to breathe. In most situations that would run counter your own experience and principles, and you would declare him stupid. The problem is that not all concepts are as all-encompassing for every human as breathing. So what's one persons breathing bugs is another persons not breathing bugs. Note: I don't want to say you belong to either of the breathing/non breathing people. No one does. Almost every one is somewhere in between these two extremes. As are you, or the people that demand the filing of bugs of you. I signed up for the Beta Program a while back, but I heard nothing for months, then a short while ago I was contacted with the details, unfortunately I don't have enough time now. When I signed up I could have put aside a couple of hours a day. See, you breathe make beta's immediately after announcing them, and someone else doesn't. You shouldn't ask yourself how to force the other person to breathe what you breathe. If the situation bothers you, you should try to find a form of breathing of which you think that both can agree upon, and propose that to the other person. Of course that person might still put you down, but the likelihood is probably quite a lot smaller. Don't let the non-breather keep you down Björnke von Gierke -- official ChatRev page: http://chatrev.bjoernke.com Chat with other RunRev developers: go stack URL http://homepage.mac.com/bvg/chatrev1.3.rev; ___ 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
