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 tw
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.
Jerr
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.r
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
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 comp
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 bi
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
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...
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 "Expo
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 discovere
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
:) 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 Servi
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 re
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
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 t
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 be
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
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 proc
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 t
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 a
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 a
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
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
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
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 cryst
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.
Mar
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
"
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
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 i
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 ki
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
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
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 i
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 "count
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
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 exp
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 be
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 -
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,
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 m
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 t
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
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 mous
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
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
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 bac
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 i
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
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 5
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
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 ba
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 backg
52 matches
Mail list logo
