Re: having to help Rev (was: Re: Memory Leak on export png????)

[Kay C Lan]

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????)

[Jerry J]

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????)

[Chipp Walters]

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????)

[Dave]

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????)

[Bill]

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????)

[Dave]

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????)

[Stephen Barncard]

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????)

[Dave]

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????)

[Dave]

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????)

[Dave]

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:



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 

Re: having to help Rev (was: Re: Memory Leak on export png????)

[J. Landman Gay]

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????)

[Heather Nagey]

:) 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????)

[Richard Gaskin]

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:



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-revol

Re: having to help Rev (was: Re: Memory Leak on export png????)

[Stephen Barncard]

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]

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.

Re: having to help Rev (was: Re: Memory Leak on export png????)

[Chipp Walters]

Richard,

I typically hate to post 'me too' posts, but I have to agree with your most
thorough analysis of this problem. While I haven't used the engine yet for
10 years, I have logged quite a number of hours and commercial project
releases with it. I've never had a problem with memory leaks. I believe I do
have some of the more graphical applications in development. ButtonGadget
and ButtonGaget2, close to 5 years old and 1000's of commercial sales on
both Mac and PC, has never had a single report of memory leakage-- nor for
that matter random crashing.

Hemingway PC, our content management system, stays open for weeks at a time
without any problems. Same is true for our Enterprise development apps. We
recently finished a product which was shipped in over 1 million devices and
we expect no problems. I could go on and on, but you get my point.

I'd *MUCH RATHER* RunRev focus their efforts on know bugs, feature additions
and customer support than start running down this particular rabbit trail.

Thanks for your eloquent post on this subject.

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

Re: having to help Rev (was: Re: Memory Leak on export png????)

[Richard Gaskin]

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 doin

Re: having to help Rev (was: Re: Memory Leak on export png????)

[Dave]

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 li

Re: Memory Leak on export png????

[Luis]

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: having to help Rev (was: Re: Memory Leak on export png????)

[Björnke von Gierke]

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: having to help Rev (was: Re: Memory Leak on export png????)

[Dave]

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: Memory Leak on export png????

[Dave]

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: Memory Leak on export png????

[Richard Gaskin]

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: having to help Rev (was: Re: Memory Leak on export png????)

[Björnke von Gierke]

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]

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: Memory Leak on export png????

[Mark Smith]

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 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????

[Chipp Walters]

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????

[Stephen Barncard]

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]

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 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????

[Mark Smith]

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 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????

[Dave]

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 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  to
, 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  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]

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????

[Richard Gaskin]

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????

[Mark Smith]

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  to
, 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  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]

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????

[Richard Gaskin]

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????

[Dave]

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]

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

Re: Memory Leak on export png????

[Dave]

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????

[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

Re: Memory Leak on export png????

[Ian Wood]

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????

[Richard Gaskin]

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????

[Dave]

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]

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????

[Richard Gaskin]

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

Re: Memory Leak on export png????

[Dave]

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]

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????

[Dave]

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????

[Jim Ault]

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????

[Ian Wood]

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????

[Richard Gaskin]

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

Memory Leak on export png????

[Dave]

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