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: Memory Leak on export png????
On 20 Mar 2007, at 20:44, Stephen Barncard wrote: Dave wrote: Where does it say this in their product advertising? I must have missed that bit. you know very well they wouldn't say that, neither would you. Not sure what you mean here, but I thought it important to to make this crystal clear. If I were selling a product like RunRev and I did not have the resources to test it on all the Platforms it shipped on, then I would say that in all my advertising and on my web site etc. etc. etc. What I wouldn't do is to not say a word anywhere and continue to advertise like all platforms are fully tested. To me that is dishonest and unprofessional. 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. 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 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: Memory Leak on export png????
Dave wrote: If I were selling a product like RunRev and I did not have the resources to test it on all the Platforms it shipped on, then I would say that in all my advertising and on my web site etc. etc. etc. What I wouldn't do is to not say a word anywhere and continue to advertise like all platforms are fully tested. To me that is dishonest and unprofessional. I suppose it would be, but that has nothing to do with what I wrote. Let me refresh your memory: I'm glad you recognize that it's up to us to test the specific implementations we use Rev for. The combinatorial explosion of all possible uses would make it impossible for RunRev to do that. I never said Rev doesn't test on the platforms they deploy to. That's just silly. I said that it's not possible to test the nearly infinite variety of things that can be done with a tool so flexible. Only the most trivial applications make it possible for the vendor to test all possible uses firsthand. My WebMerge product has a modest 5GL with fewer than two dozen tokens, and yet even with that the combinatorial explosion means that only a subset are able to be tested here before release. All others rely on Beta testing. Since our support costs are less than a fourth of industry average we must be doing something right, but still from time to time we have valid bug reports come on from customers for scenarios we hadn't tested. My recent thread on the token token came from one, but it's worth noting that the bug hadn't been evidenced in any real-world workflow for more than five years. Imagine how disappointed my customers would be if I held back the benefits my software delivers while I attempt to test all possible usage scenarios. The same goes with any software. Your comment about expecting payment for testing was equally snarky: 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? If you pay all of your Beta testers please let us know the URL for your products so some of the folks here can help out with that. It might even be helpful for the rest of us, as I'm sure there's much we can all learn from uncommonly successful products built with such unusually high standards. More commonly software publishers rely on volunteer Beta testers. Many, myself included, also pay professionals for specific types of testing during the Beta phase, but the bulk of workflow testing in real-world scenarios happens at volunteer Beta sites. Over the last 20 years I've been a beta tester for companies bigger and smaller than Rev, including Adobe, Oracle, Microsoft, and a dozen others, and not one of them ever suggested they might pay beta testers. Which companies gave you the impression that it's in any way conventional to expect payment for beta testing? -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.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: Memory Leak on export png????
On 21 Mar 2007, at 15:28, Richard Gaskin wrote: Dave wrote: If I were selling a product like RunRev and I did not have the resources to test it on all the Platforms it shipped on, then I would say that in all my advertising and on my web site etc. etc. etc. What I wouldn't do is to not say a word anywhere and continue to advertise like all platforms are fully tested. To me that is dishonest and unprofessional. I suppose it would be, but that has nothing to do with what I wrote. Let me refresh your memory: I'm glad you recognize that it's up to us to test the specific implementations we use Rev for. The combinatorial explosion of all possible uses would make it impossible for RunRev to do that. We are talking at cross purposes. Let me refresh your memory: Dave wrote: All I know is that if I were to write something like this (a file/ image data exporter) then once I'd got it working past the the point where I could write an image file in all the different formats then I'd run a soak test on it and let it run for *loads* of (like 10,000 +) of iterations and I would have checked that memory was being released. In fact I wrote an external command module that does something similar (it analyzes movie frames) and I *did* soak test it and I *did* find memory leaks. For me, this is software engineering 101. Richard wrote: And it turns out that you did write an image exporter, and did run it through a soak test. Good job. You are talking about beta testing, I was talking about testing your code after developing it. As an example: I wrote a module that does things with movies and/or images. There are two parts to this, the RunRev Test Script and the C/C++ External. Since I am working with Movies and Images, this means there is a lot of memory being allocated and therefore a chance that a memory leak will occur. Over a period of a day or two I develop the C/ C++ code and the Test Script together. At some point I get to the stage where I am Read/Writing/Analyzing a Movie/Image. As soon as I get to this stage, I then soak test the C/C++ Command Handler. I do this by testing it processing many thousands (like 10,000+) of Movies/ Files. What I was saying is that the code I wrote was very similar to the export snapshot command both in terms of usage (it uses a lot RAM) and in terms of development both have a C/C++ core and a RunRev script. Obviously this type of testing wasn't performed on the export snapshot command. That was what I meant. In my case it was for Mac only, but in the past I have developed both for Mac and Windows and in the case I would soak test it on Mac and at least one version of Windows before checking it in and before it even got as far as QA and Beta Testing. Your comment about expecting payment for testing was equally snarky: 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? Not sure what snarky means! As I said I wasn't talking about beta testing, I was talking about first level soak testing after you have got a part of your code working. In the case where I don't have enough time to do this myself I employ someone I trust and have worked with in the past to do it. 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 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
Re: Memory Leak on export png????
That implies that the release of the purchased versions of RunRev were betas... Cheers, Luis. On 21 Mar 2007, at 16:01, Dave wrote: On 21 Mar 2007, at 15:28, Richard Gaskin wrote: Dave wrote: If I were selling a product like RunRev and I did not have the resources to test it on all the Platforms it shipped on, then I would say that in all my advertising and on my web site etc. etc. etc. What I wouldn't do is to not say a word anywhere and continue to advertise like all platforms are fully tested. To me that is dishonest and unprofessional. I suppose it would be, but that has nothing to do with what I wrote. Let me refresh your memory: I'm glad you recognize that it's up to us to test the specific implementations we use Rev for. The combinatorial explosion of all possible uses would make it impossible for RunRev to do that. We are talking at cross purposes. Let me refresh your memory: Dave wrote: All I know is that if I were to write something like this (a file/ image data exporter) then once I'd got it working past the the point where I could write an image file in all the different formats then I'd run a soak test on it and let it run for *loads* of (like 10,000 +) of iterations and I would have checked that memory was being released. In fact I wrote an external command module that does something similar (it analyzes movie frames) and I *did* soak test it and I *did* find memory leaks. For me, this is software engineering 101. Richard wrote: And it turns out that you did write an image exporter, and did run it through a soak test. Good job. You are talking about beta testing, I was talking about testing your code after developing it. As an example: I wrote a module that does things with movies and/or images. There are two parts to this, the RunRev Test Script and the C/C++ External. Since I am working with Movies and Images, this means there is a lot of memory being allocated and therefore a chance that a memory leak will occur. Over a period of a day or two I develop the C/C++ code and the Test Script together. At some point I get to the stage where I am Read/Writing/Analyzing a Movie/Image. As soon as I get to this stage, I then soak test the C/C++ Command Handler. I do this by testing it processing many thousands (like 10,000+) of Movies/Files. What I was saying is that the code I wrote was very similar to the export snapshot command both in terms of usage (it uses a lot RAM) and in terms of development both have a C/C++ core and a RunRev script. Obviously this type of testing wasn't performed on the export snapshot command. That was what I meant. In my case it was for Mac only, but in the past I have developed both for Mac and Windows and in the case I would soak test it on Mac and at least one version of Windows before checking it in and before it even got as far as QA and Beta Testing. Your comment about expecting payment for testing was equally snarky: 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? Not sure what snarky means! As I said I wasn't talking about beta testing, I was talking about first level soak testing after you have got a part of your code working. In the case where I don't have enough time to do this myself I employ someone I trust and have worked with in the past to do it. 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 ___ 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: Memory Leak on export png????
Yet more information, I tried running it under 2.6.6.152 (using the older screen rectangle command syntax) and I got it to export 2000 image files. It ran a *lot* slower but it didn't leak memory, so the problem must have been introduced in version 2.7.x. I can't see that this could have been tested past a cursory glance before releasing it. All the Best Dave Hi, Some more information: I built a standalone, this writes 288 files but I don't get the error dialog and it doesn't complete correctly, e.g. I don't get the Done! dialog at the end. Looking at the System Activity Monitor it only grabs around 35 MB of real memory 377 MB of virtual - it doesn't allocate the Gigabytes as it does while running under the IDE. Anyone got *any* ideas how to work around this? I am working on a demo and need this to work ASAP, otherwise I may as well just stop work on it now. All the Best Dave On 19 Mar 2007, at 15:14, Ian Wood wrote: On 19 Mar 2007, at 14:56, Richard Gaskin wrote: Is that physical memory or virtual? On OS X I've seen seemingly small apps take up a surprising amount of virtual memory, but operate in a much smaller physical space. Although FWIW I've not seen my Rev usage climb that high while running these tests. Are there plugins or other stacks running which may play a role here When I tried it, Rev was grabbing 3.5GB of physical RAM (out of 4GB), and quite a bit of virtual RAM as well. Ian Yes, I've just verified it again, it takes 1.8 GB and never gives it back. If I put the counter field back, it stops at file 289 with a write error, if I don't have the counter (or if the counter is pushed behind the rectangle (which is filled with red)) then it writes a lot more files before it hangs. Did you try this on Windows or just on the Mac? Thanks a lot 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 ___ 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: Memory Leak on export png????
Dave wrote: Yet more information, I tried running it under 2.6.6.152 (using the older screen rectangle command syntax) and I got it to export 2000 image files. It ran a *lot* slower but it didn't leak memory, so the problem must have been introduced in version 2.7.x. FWIW, last night I experienced crashes in one of my apps built with v2.8 that has never crashes before. This app is different from most others I work on mainly because of the number and frequency of file-writing operations. There may be a connection to what you're seeing, or something else. If I find a pattern I'll get back to you. I can't see that this could have been tested past a cursory glance before releasing it. While RunRev has had a history of some of the shorted Beta cycles I've ever seen, in this case the time between v2.6 and the current v2.8 spans more than a year and during most of that time this issue eluded a recipe. That this is being seen now and a recipe is being honed in on is a good thing, but I'd hate to see RunRev err too far the other direction with Beta cycles extending longer than a year. Some bugs are not immediately evident, and will take time to discover amidst the nearly infinite combination of tokens that can be executed. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.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: Memory Leak on export png????
On 20 Mar 2007, at 14:14, Richard Gaskin wrote: Dave wrote: Yet more information, I tried running it under 2.6.6.152 (using the older screen rectangle command syntax) and I got it to export 2000 image files. It ran a *lot* slower but it didn't leak memory, so the problem must have been introduced in version 2.7.x. FWIW, last night I experienced crashes in one of my apps built with v2.8 that has never crashes before. This app is different from most others I work on mainly because of the number and frequency of file-writing operations. There may be a connection to what you're seeing, or something else. If I find a pattern I'll get back to you. I can't see that this could have been tested past a cursory glance before releasing it. While RunRev has had a history of some of the shorted Beta cycles I've ever seen, in this case the time between v2.6 and the current v2.8 spans more than a year and during most of that time this issue eluded a recipe. That this is being seen now and a recipe is being honed in on is a good thing, but I'd hate to see RunRev err too far the other direction with Beta cycles extending longer than a year. Some bugs are not immediately evident, and will take time to discover amidst the nearly infinite combination of tokens that can be executed. All I know is that if I were to write something like this (a file/ image data exporter) then once I'd got it working past the the point where I could write an image file in all the different formats then I'd run a soak test on it and let it run for *loads* of (like 10,000 +) of iterations and I would have checked that memory was being released. In fact I wrote an external command module that does something similar (it analyzes movie frames) and I *did* soak test it and I *did* find memory leaks. For me, this is software engineering 101. 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: Memory Leak on export png????
on mouseUp set the directory to /Users/marksmith/Desktop/xpics/ repeat with x = 1 to 1000 if the mouse is down then exit to top end if put x .png into tDest set the backgroundColor of grp counter to any item of red,blue set the backgroundColor of fld counter to any item of green,yellow put x into fld counter of grp counter export snapshot from grp counter to file tDest as PNG wait 1 millisec end repeat end mouseUp Weird...I set this up earlier and was finding that it would stop with an error, at various points, but usually at the 256th iteration, and never later. The error was something along the lines of 'could not write to file' However, if I changed put x into fld counter of grp counter to put x= x into fld counter of grp counter, it completed without problem every time. Activity Monitor (I'm on a G4 mac laptop, Rev 2.8.0) reported only a tiny increase in real and virtual memory use. I had to go out, and quit Revolution. Now I've come back, the same stack works correctly whatever I put in the put x into... line. Best, Mark ___ 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: Memory Leak on export png????
Dave wrote: All I know is that if I were to write something like this (a file/ image data exporter) then once I'd got it working past the the point where I could write an image file in all the different formats then I'd run a soak test on it and let it run for *loads* of (like 10,000 +) of iterations and I would have checked that memory was being released. In fact I wrote an external command module that does something similar (it analyzes movie frames) and I *did* soak test it and I *did* find memory leaks. For me, this is software engineering 101. And it turns out that you did write an image exporter, and did run it through a soak test. Good job. I'm glad you recognize that it's up to us to test the specific implementations we use Rev for. The combinatorial explosion of all possible uses would make it impossible for RunRev to do that. 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. What was the final recipe for this error (I was unable to reproduce the last one), and what's the BZ #? -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Memory Leak on export png????
On 20 Mar 2007, at 15:17, Richard Gaskin wrote: Dave wrote: All I know is that if I were to write something like this (a file/ image data exporter) then once I'd got it working past the the point where I could write an image file in all the different formats then I'd run a soak test on it and let it run for *loads* of (like 10,000 +) of iterations and I would have checked that memory was being released. In fact I wrote an external command module that does something similar (it analyzes movie frames) and I *did* soak test it and I *did* find memory leaks. For me, this is software engineering 101. And it turns out that you did write an image exporter, and did run it through a soak test. Good job. Better to do it before anyone else find the problem and the best time to do that it right after you have finished coding it. That way it still fresh in your mind. I'm glad you recognize that it's up to us to test the specific implementations we use Rev for. The combinatorial explosion of all possible uses would make it impossible for RunRev to do that. Where does it say this in their product advertising? I must have missed that bit. 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? What was the final recipe for this error (I was unable to reproduce the last one), and what's the BZ #? Jacque is looking into it at the moment and will report it. I will let you know the BZ # when I get it. 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: Memory Leak on export png????
Hi, This is the kind of thing I was experiencing. I think there may be two related problems, although one may cause the other. When I tested it, it would run up to file 288 and not write file 289. I then started it at file 289 and it would go wrong on the first file. e.g. change your loop to read like this: put WHATEVER into myStartOffset repeat with x = (1 + myStartOffset) to (1000 + myStartOffset) and see what happens. With my image I see 1.8 GB allocated to RunRev over 1000 iterations. I am only running at a quarter of the frame size needed in the real app so my limit is going to be around 250 frames, this is not good enough for my demo where I am going to need 3000 frames minimum. I've just tried it on a PowerPC (Mac Mini) Running Panther and it still leaks. I am just installing Tiger on that machine and will see what happens then. Thanks a lot All the Best Dave On 20 Mar 2007, at 14:26, Mark Smith wrote: on mouseUp set the directory to /Users/marksmith/Desktop/xpics/ repeat with x = 1 to 1000 if the mouse is down then exit to top end if put x .png into tDest set the backgroundColor of grp counter to any item of red,blue set the backgroundColor of fld counter to any item of green,yellow put x into fld counter of grp counter export snapshot from grp counter to file tDest as PNG wait 1 millisec end repeat end mouseUp Weird...I set this up earlier and was finding that it would stop with an error, at various points, but usually at the 256th iteration, and never later. The error was something along the lines of 'could not write to file' However, if I changed put x into fld counter of grp counter to put x= x into fld counter of grp counter, it completed without problem every time. Activity Monitor (I'm on a G4 mac laptop, Rev 2.8.0) reported only a tiny increase in real and virtual memory use. I had to go out, and quit Revolution. Now I've come back, the same stack works correctly whatever I put in the put x into... line. Best, Mark ___ 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: Memory Leak on export png????
Dave, as I said, it's now working as you would hope, and I can't reproduce the problem. Just out of interest, in view of what was happening here before, have you tried putting x= x into fld counter, rather than just x? Best, Mark On 20 Mar 2007, at 16:05, Dave wrote: This is the kind of thing I was experiencing. I think there may be two related problems, although one may cause the other. When I tested it, it would run up to file 288 and not write file 289. I then started it at file 289 and it would go wrong on the first file. e.g. change your loop to read like this: put WHATEVER into myStartOffset repeat with x = (1 + myStartOffset) to (1000 + myStartOffset) and see what happens. ___ 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: Memory Leak on export png????
Hi, I have got it working so I don't get the file name problem (giving an error at file N) but it still leaks like there is no tomorrow. I have tried doing the x = trick as well as well as taking out the counter field altogether and it still leaks. I can't get it to work beyond 2000 images and that is at one quarter size, if I make them full size then I will have no chance! I've tried this on Intel and PowerPC Under Tiger and Panther and I get the leak on both machines and both versions of the OS. When you run the stack, do you have the system activity monitor running? If so after 1000 images how much RAM is allocated to RunRev (Real and Physical) ? For me: Real MemoryVirtual Memory 887.14 MB1.25 GB1000 Images 1.68 GB 2.07 GB2000 Images At this point the system becomes unusable and RunRev will either quit itself or you will have to quit or force quit. Thanks a lot All the Best Dave On 20 Mar 2007, at 16:20, Mark Smith wrote: Dave, as I said, it's now working as you would hope, and I can't reproduce the problem. Just out of interest, in view of what was happening here before, have you tried putting x= x into fld counter, rather than just x? Best, Mark On 20 Mar 2007, at 16:05, Dave wrote: This is the kind of thing I was experiencing. I think there may be two related problems, although one may cause the other. When I tested it, it would run up to file 288 and not write file 289. I then started it at file 289 and it would go wrong on the first file. e.g. change your loop to read like this: put WHATEVER into myStartOffset repeat with x = (1 + myStartOffset) to (1000 + myStartOffset) and see what happens. ___ 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: Memory Leak on export png????
Dave wrote: Where does it say this in their product advertising? I must have missed that bit. you know very well they wouldn't say that, neither would you. 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... -- 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: Memory Leak on export png????
Dave, Yeah, I'm with Stephen about your *attitude*. But, here's what I would suggest you trying: Insert a wait 1 second with messages into your loop. See if you're just not giving Rev enough time to garbage collect. If it stops leaking, then you can adjust the time to wait. Don't forget the with messages part! -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: Memory Leak on export png????
On my machine it's showing Real:30-40 MB VM:200-300 MB. It doesn't seem to change from beginning to end of the 1000 iterations...however many times I run it. Rev 2.8.0, Mac 10.4.8, 1.5 Mhz G4 PB with 768 MB RAM. Standard Rev Studio installation with a few plugins loaded. Mysterious. Mark On 20 Mar 2007, at 16:59, Dave wrote: Hi, I have got it working so I don't get the file name problem (giving an error at file N) but it still leaks like there is no tomorrow. I have tried doing the x = trick as well as well as taking out the counter field altogether and it still leaks. I can't get it to work beyond 2000 images and that is at one quarter size, if I make them full size then I will have no chance! I've tried this on Intel and PowerPC Under Tiger and Panther and I get the leak on both machines and both versions of the OS. When you run the stack, do you have the system activity monitor running? If so after 1000 images how much RAM is allocated to RunRev (Real and Physical) ? For me: Real MemoryVirtual Memory 887.14 MB1.25 GB1000 Images 1.68 GB 2.07 GB2000 Images At this point the system becomes unusable and RunRev will either quit itself or you will have to quit or force quit. Thanks a lot All the Best Dave On 20 Mar 2007, at 16:20, Mark Smith wrote: Dave, as I said, it's now working as you would hope, and I can't reproduce the problem. Just out of interest, in view of what was happening here before, have you tried putting x= x into fld counter, rather than just x? Best, Mark On 20 Mar 2007, at 16:05, Dave wrote: This is the kind of thing I was experiencing. I think there may be two related problems, although one may cause the other. When I tested it, it would run up to file 288 and not write file 289. I then started it at file 289 and it would go wrong on the first file. e.g. change your loop to read like this: put WHATEVER into myStartOffset repeat with x = (1 + myStartOffset) to (1000 + myStartOffset) and see what happens. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Memory Leak on export png????
Hi, Mac OS X 10.4.8, MacBook Pro 2.16GHz Core Duo, 2GB RAM Ok, are you using the standard RunRev IDE and not running anything other that the standard RunRev stuff? I set the fill color via the Property Inspector, not via a script, not sure if that would make a difference. I have removed all fill colors and I still get the error when writing file number 289. I've also tried making the object/rectangle smaller, still stops on file 289. Then I tried adding a wait .25 seconds after the export operation, same problem. I then replaced the repeat statement like this: repeat with x = (1 + 288 to (tNum + 288) And it still gave an error on 289! I then tried (300) to (tNum + 300) and got the error on file 608! Then 290 to (tNum + 290), the error occurred on file 298. This is very strange problem! It happens every time on my system and Ian appears to have had the same problem too. would be good to track why it works ok on yours. All the Best Dave on mouseUp local tNum local twID local tFol local tDest put the colorNames into tColors -- NEW put 500 into tNum put the windowID of this stack into twID put /Users/rg/Desktop/untitled folder/ into tFol set the defaultfolder to tFol repeat with x = 1 to tNum if the mouse is down then exit to top end if put x .png into tDest put x into fld counter set the backgroundColor of grp 1 to any line of tColors -- NEW export snapshot from grp 1 to file tDest as PNG end repeat answer Done! end mouseUp Then I added a graphic in case there was something specific to that object type, changing the color of the graphic instead of the group. Same good result. ___ 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: Memory Leak on export png????
Hi, Some more information on this. If I delete the Text counter object from the group that gets exported the it will output many more images (once it actually did all 500) before stopping. Doing this it will just continue forever, e.g. Most of the time I don't get the error dialog and mouseUp handler never exits. I looked at the system activity monitor and found that 1.68 GB OUT of my 2 GB was allocated to RunRev, so I guess it really is leaking! I also tried storing the image into a variable instead of a file and get the same problems. Not sure what else to try? Would be interesting to find out why it works on your system and not mine or Ian's. Anyone what to try this on their system? Haven't tried this at all under Windows. Thanks a lot and All the Best Dave Hi, Mac OS X 10.4.8, MacBook Pro 2.16GHz Core Duo, 2GB RAM Ok, are you using the standard RunRev IDE and not running anything other that the standard RunRev stuff? I set the fill color via the Property Inspector, not via a script, not sure if that would make a difference. I have removed all fill colors and I still get the error when writing file number 289. I've also tried making the object/rectangle smaller, still stops on file 289. Then I tried adding a wait .25 seconds after the export operation, same problem. I then replaced the repeat statement like this: repeat with x = (1 + 288 to (tNum + 288) And it still gave an error on 289! I then tried (300) to (tNum + 300) and got the error on file 608! Then 290 to (tNum + 290), the error occurred on file 298. This is very strange problem! It happens every time on my system and Ian appears to have had the same problem too. would be good to track why it works ok on yours. All the Best Dave on mouseUp local tNum local twID local tFol local tDest put the colorNames into tColors -- NEW put 500 into tNum put the windowID of this stack into twID put /Users/rg/Desktop/untitled folder/ into tFol set the defaultfolder to tFol repeat with x = 1 to tNum if the mouse is down then exit to top end if put x .png into tDest put x into fld counter set the backgroundColor of grp 1 to any line of tColors -- NEW export snapshot from grp 1 to file tDest as PNG end repeat answer Done! end mouseUp Then I added a graphic in case there was something specific to that object type, changing the color of the graphic instead of the group. Same good result. ___ 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: Memory Leak on export png????
Dave wrote: Some more information on this. If I delete the Text counter object from the group that gets exported the it will output many more images (once it actually did all 500) before stopping. Doing this it will just continue forever, e.g. Most of the time I don't get the error dialog and mouseUp handler never exits. I looked at the system activity monitor and found that 1.68 GB OUT of my 2 GB was allocated to RunRev, so I guess it really is leaking! Is that physical memory or virtual? On OS X I've seen seemingly small apps take up a surprising amount of virtual memory, but operate in a much smaller physical space. Although FWIW I've not seen my Rev usage climb that high while running these tests. Are there plugins or other stacks running which may play a role here? I also tried storing the image into a variable instead of a file and get the same problems. Not sure what else to try? Would be interesting to find out why it works on your system and not mine or Ian's. Anyone what to try this on their system? Haven't tried this at all under Windows. Thanks a lot and All the Best Dave Hi, Mac OS X 10.4.8, MacBook Pro 2.16GHz Core Duo, 2GB RAM Ok, are you using the standard RunRev IDE and not running anything other that the standard RunRev stuff? I did the test both in Rev with only the default installaton, and in MetaCard loaded up with several megs of my own tools. Same good result with each. I set the fill color via the Property Inspector, not via a script, not sure if that would make a difference. I have removed all fill colors and I still get the error when writing file number 289. I've also tried making the object/rectangle smaller, still stops on file 289. In theory it should make no difference, since the Inspector is setting the same property I set in script. If anything, one might expect the script to do a better job of exposing any issue with that since it's working harder, setting the color over and over with each iteration. Unfortunately this week I'm up to my gills in client work, so I won't be able to run another test on this. It may be helpful to submit a test stack which reproduces the problem reliably on your system to [EMAIL PROTECTED], so they can reproduce it there. With their low-level debugging tools I'm sure that if they can reproduce it they'll be able to fix it in short order. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.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: Memory Leak on export png????
On 19 Mar 2007, at 14:56, Richard Gaskin wrote: Is that physical memory or virtual? On OS X I've seen seemingly small apps take up a surprising amount of virtual memory, but operate in a much smaller physical space. Although FWIW I've not seen my Rev usage climb that high while running these tests. Are there plugins or other stacks running which may play a role here When I tried it, Rev was grabbing 3.5GB of physical RAM (out of 4GB), and quite a bit of virtual RAM as well. Ian ___ 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: Memory Leak on export png????
On 19 Mar 2007, at 15:14, Ian Wood wrote: On 19 Mar 2007, at 14:56, Richard Gaskin wrote: Is that physical memory or virtual? On OS X I've seen seemingly small apps take up a surprising amount of virtual memory, but operate in a much smaller physical space. Although FWIW I've not seen my Rev usage climb that high while running these tests. Are there plugins or other stacks running which may play a role here When I tried it, Rev was grabbing 3.5GB of physical RAM (out of 4GB), and quite a bit of virtual RAM as well. Ian Yes, I've just verified it again, it takes 1.8 GB and never gives it back. If I put the counter field back, it stops at file 289 with a write error, if I don't have the counter (or if the counter is pushed behind the rectangle (which is filled with red)) then it writes a lot more files before it hangs. Did you try this on Windows or just on the Mac? Thanks a lot 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: Memory Leak on export png????
On 19 Mar 2007, at 14:56, Richard Gaskin wrote: Dave wrote: Some more information on this. If I delete the Text counter object from the group that gets exported the it will output many more images (once it actually did all 500) before stopping. Doing this it will just continue forever, e.g. Most of the time I don't get the error dialog and mouseUp handler never exits. I looked at the system activity monitor and found that 1.68 GB OUT of my 2 GB was allocated to RunRev, so I guess it really is leaking! Is that physical memory or virtual? On OS X I've seen seemingly small apps take up a surprising amount of virtual memory, but operate in a much smaller physical space. Real Memory, I can watch free memory drop and get allocated to RunRev until around 1.7 GB level then thing start to slow way down and I either get the error dialog, RunRev hangs or it manages to finish ok. When it does finish ok, if I run it again Free Memory continues to shrink until it reaches the point where I get the error dialog or it hangs. If I close the stack it still doesn't get de-allocated, the only thing that appears to cause it to be de-allocated is quitting RunRev. Although FWIW I've not seen my Rev usage climb that high while running these tests. Are there plugins or other stacks running which may play a role here? The only plug-in I have loaded is the stackFormat plugin, other than that it's a Standard RunRev Install. I have tried it with the stackFileVersion property set to 2.4 and 2.7. I also tried storing the image into a variable instead of a file and get the same problems. Not sure what else to try? Would be interesting to find out why it works on your system and not mine or Ian's. Anyone what to try this on their system? Haven't tried this at all under Windows. Thanks a lot and All the Best Dave Hi, Mac OS X 10.4.8, MacBook Pro 2.16GHz Core Duo, 2GB RAM Ok, are you using the standard RunRev IDE and not running anything other that the standard RunRev stuff? I did the test both in Rev with only the default installaton, and in MetaCard loaded up with several megs of my own tools. Same good result with each. I set the fill color via the Property Inspector, not via a script, not sure if that would make a difference. I have removed all fill colors and I still get the error when writing file number 289. I've also tried making the object/rectangle smaller, still stops on file 289. In theory it should make no difference, since the Inspector is setting the same property I set in script. If anything, one might expect the script to do a better job of exposing any issue with that since it's working harder, setting the color over and over with each iteration. Unfortunately this week I'm up to my gills in client work, so I won't be able to run another test on this. It may be helpful to submit a test stack which reproduces the problem reliably on your system to [EMAIL PROTECTED], so they can reproduce it there. With their low-level debugging tools I'm sure that if they can reproduce it they'll be able to fix it in short order. Ok will do. 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: Memory Leak on export png????
Hi, Some more information: I built a standalone, this writes 288 files but I don't get the error dialog and it doesn't complete correctly, e.g. I don't get the Done! dialog at the end. Looking at the System Activity Monitor it only grabs around 35 MB of real memory 377 MB of virtual - it doesn't allocate the Gigabytes as it does while running under the IDE. Anyone got *any* ideas how to work around this? I am working on a demo and need this to work ASAP, otherwise I may as well just stop work on it now. All the Best Dave On 19 Mar 2007, at 15:14, Ian Wood wrote: On 19 Mar 2007, at 14:56, Richard Gaskin wrote: Is that physical memory or virtual? On OS X I've seen seemingly small apps take up a surprising amount of virtual memory, but operate in a much smaller physical space. Although FWIW I've not seen my Rev usage climb that high while running these tests. Are there plugins or other stacks running which may play a role here When I tried it, Rev was grabbing 3.5GB of physical RAM (out of 4GB), and quite a bit of virtual RAM as well. Ian Yes, I've just verified it again, it takes 1.8 GB and never gives it back. If I put the counter field back, it stops at file 289 with a write error, if I don't have the counter (or if the counter is pushed behind the rectangle (which is filled with red)) then it writes a lot more files before it hangs. Did you try this on Windows or just on the Mac? Thanks a lot 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
Memory Leak on export png????
Hi All, Please take a look at the handler copied below. This is an adaptation of Ian Wood's export snapshot.rev stack that can be downloaded from Rev Online. I have changed in to use .png files instead of JPEG file, changed the counter rectangle graphic object to have an all green background (RGB = 0,255,0), I then select 500 iterations and press the export from snapshot from object button, this writes 288 files and then gives an execution error: export can't write to file, mask file or container 289.png export snapshot from grp counter to file tDest as PNG I also tried this without setting the background color and this does write all 500 files, but RunRev crashes (unexpectedly quits) doing something unrelated a short while later. Also when this is running, the first 50 to 100 files go quite quickly but after that it starts to slow down. Has anyone else seen this? I'm running on a Mac Pro, Mac OS 10.4.9 RunRev 2.8.0.350. I really need to get this to work correctly as I have do another demo next week and this is 90% of it! Thanks a lot All the Best Dave on doExport tType local tNum local twID local tFol local tDest 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 tNum if the mouse is down then exit to top end if put x .png into tDest -- do all your animation etc. here put x into fld counter of grp counter -- now export the file -- if using rev 2.7 and above you can use the 'object' syntax where the image will not be affected by other objects or windows on top of the object if tType is object then export snapshot from grp counter to file tDest as PNG end if -- If using Rev 2.6 or below, you will have to do use the older syntax and makes sure this is the frontmost window! if tType is area then export snapshot from rect (rect of grp counter) of window twID to file tDest as PNG end if end repeat answer Done! end doExport ___ 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: Memory Leak on export png????
Dave wrote: Please take a look at the handler copied below. This is an adaptation of Ian Wood's export snapshot.rev stack that can be downloaded from Rev Online. I have changed in to use .png files instead of JPEG file, changed the counter rectangle graphic object to have an all green background (RGB = 0,255,0), I then select 500 iterations and press the export from snapshot from object button, this writes 288 files and then gives an execution error: export can't write to file, mask file or container 289.png export snapshot from grp counter to file tDest as PNG I also tried this without setting the background color and this does write all 500 files, but RunRev crashes (unexpectedly quits) doing something unrelated a short while later. Also when this is running, the first 50 to 100 files go quite quickly but after that it starts to slow down. Has anyone else seen this? I'm running on a Mac Pro, Mac OS 10.4.9 RunRev 2.8.0.350. I simplified the script to make it easier to set up here, and since you're using v2.8 I removed the portion for earlier versions: on mouseUp local tNum local twID local tFol local tDest put 500 into tNum put the windowID of this stack into twID put /Users/rg/Desktop/untitled folder/ into tFol set the defaultfolder to tFol repeat with x = 1 to tNum if the mouse is down then exit to top end if put x .png into tDest put x into fld counter export snapshot from grp 1 to file tDest as PNG end repeat answer Done! end mouseUp Running this script twice in both MC and Rev completed without error, and afterwards the memory allocation for each was roughly the same as before. What suggests this crash is specifically a memory leak? -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.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: Memory Leak on export png????
On 16 Mar 2007, at 17:25, Dave wrote: Hi All, Please take a look at the handler copied below. This is an adaptation of Ian Wood's export snapshot.rev stack that can be downloaded from Rev Online. Oops. What I *hadn't* said about the stack is that it was put together as part of a bug-hunting exercise which I haven't yet reported on Bugzilla. :-( Export snapshot appears not to release RAM once it has been used an unknown number of times. BUT - it's only in the IDE as standalones are fine. This is with 10.4.8, Rev 2.7.4 2.8.0. How did I find this out? Running a soak test on my QTVR to video app, only to come back later and find that a G5 with 4GB RAM was running out of memory... Ian ___ 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: Memory Leak on export png????
On 3/16/07 10:25 AM, Dave [EMAIL PROTECTED] wrote: Please take a look at the handler copied below. This is an adaptation of Ian Wood's export snapshot.rev stack that can be downloaded from Rev Online. I also tried this without setting the background color and this does write all 500 files, but RunRev crashes (unexpectedly quits) doing something unrelated a short while later. Also when this is running, the first 50 to 100 files go quite quickly but after that it starts to slow down. Has anyone else seen this? I'm running on a Mac Pro, Mac OS 10.4.9 RunRev 2.8.0.350. I really need to get this to work correctly as I have do another demo next week and this is 90% of it! I don't do much of this, but there are a couple bug reports dealing with import, export and images. You might check this out before building too much on something that is not fixed yet. The slow down part is probably related to the Mac Finder and the HD maint. I see the same type of speed change writing text files on WinXP. You might see if -- adding a slight wait of 30 milliseconds helps Rev -- exporting from a substack that you close out of Rev memory and thus maybe purge a dangling heap address in the subStack (possible cause of a crash) --re-think the demo as a beta that runs slower --run as a slower-timed background process --does the crash occur if tested by exporting to a single variable repeatedly, thus not dealing with the hard drive file writing Of course, there may be a more robust way of doing this with an AppleScript app as an agent. Hope this helps 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: Memory Leak on export png????
On 16 Mar 2007, at 17:59, Richard Gaskin wrote: I simplified the script to make it easier to set up here, and since you're using v2.8 I removed the portion for earlier versions: on mouseUp local tNum local twID local tFol local tDest put 500 into tNum put the windowID of this stack into twID put /Users/rg/Desktop/untitled folder/ into tFol set the defaultfolder to tFol repeat with x = 1 to tNum if the mouse is down then exit to top end if put x .png into tDest put x into fld counter export snapshot from grp 1 to file tDest as PNG end repeat answer Done! end mouseUp Running this script twice in both MC and Rev completed without error, and afterwards the memory allocation for each was roughly the same as before. What suggests this crash is specifically a memory leak? Hi, Just a guess really, I have had this kind of problem when my external commands (not being used in this test) had a memory leak and the performance went right down and RunRev acted in a similar way. Not really sure if it is a leak, just seems like the most likely. It's interesting that it works on you setup though. What version of Mac OS are you using? 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: Memory Leak on export png????
On 16 Mar 2007, at 18:02, Ian Wood wrote: On 16 Mar 2007, at 17:25, Dave wrote: Hi All, Please take a look at the handler copied below. This is an adaptation of Ian Wood's export snapshot.rev stack that can be downloaded from Rev Online. Oops. What I *hadn't* said about the stack is that it was put together as part of a bug-hunting exercise which I haven't yet reported on Bugzilla. :-( Export snapshot appears not to release RAM once it has been used an unknown number of times. BUT - it's only in the IDE as standalones are fine. This is with 10.4.8, Rev 2.7.4 2.8.0. How did I find this out? Running a soak test on my QTVR to video app, only to come back later and find that a G5 with 4GB RAM was running out of memory... Ok, thanks for this. I only have 2GB of RAM so it hits the problem sooner. Richard reports that it works ok on his system, - Richard did you set the Fill Color of the Graphic to Green? Actually any color seems to cause it. 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: Memory Leak on export png????
On 16 Mar 2007, at 18:13, Jim Ault wrote: On 3/16/07 10:25 AM, Dave [EMAIL PROTECTED] wrote: Please take a look at the handler copied below. This is an adaptation of Ian Wood's export snapshot.rev stack that can be downloaded from Rev Online. I also tried this without setting the background color and this does write all 500 files, but RunRev crashes (unexpectedly quits) doing something unrelated a short while later. Also when this is running, the first 50 to 100 files go quite quickly but after that it starts to slow down. Has anyone else seen this? I'm running on a Mac Pro, Mac OS 10.4.9 RunRev 2.8.0.350. I really need to get this to work correctly as I have do another demo next week and this is 90% of it! I don't do much of this, but there are a couple bug reports dealing with import, export and images. You might check this out before building too much on something that is not fixed yet. The slow down part is probably related to the Mac Finder and the HD maint. I see the same type of speed change writing text files on WinXP. You might see if -- adding a slight wait of 30 milliseconds helps Rev -- exporting from a substack that you close out of Rev memory and thus maybe purge a dangling heap address in the subStack (possible cause of a crash) --re-think the demo as a beta that runs slower --run as a slower-timed background process --does the crash occur if tested by exporting to a single variable repeatedly, thus not dealing with the hard drive file writing Of course, there may be a more robust way of doing this with an AppleScript app as an agent. Hope this helps Thanks Jim, I am doing some playing around now. I'm sure one of your suggestions will help. 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: Memory Leak on export png????
Dave wrote: What suggests this crash is specifically a memory leak? Just a guess really, I have had this kind of problem when my external commands (not being used in this test) had a memory leak and the performance went right down and RunRev acted in a similar way. Not really sure if it is a leak, just seems like the most likely. It's interesting that it works on you setup though. What version of Mac OS are you using? Mac OS X 10.4.8, MacBook Pro 2.16GHz Core Duo, 2GB RAM Richard reports that it works ok on his system, - Richard did you set the Fill Color of the Graphic to Green? Actually any color seems to cause it. I just added a line to set the color of the group to a random color -- works just as well: on mouseUp local tNum local twID local tFol local tDest put the colorNames into tColors -- NEW put 500 into tNum put the windowID of this stack into twID put /Users/rg/Desktop/untitled folder/ into tFol set the defaultfolder to tFol repeat with x = 1 to tNum if the mouse is down then exit to top end if put x .png into tDest put x into fld counter set the backgroundColor of grp 1 to any line of tColors -- NEW export snapshot from grp 1 to file tDest as PNG end repeat answer Done! end mouseUp Then I added a graphic in case there was something specific to that object type, changing the color of the graphic instead of the group. Same good result. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.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
