Hi
I believe that finalize command do not clear up files just release the file
handle or did you write extra code to do the delete? I am thinking of the
following way, let say all the screen shots is dump into the memory, once we
lose reference to the memory for example after the loop ended, JVM should do
a GC eventually to clear up the memory right? I am kind of rusty with Java
after losing touch for like years, but I believe the concept of GC should be
same for java as with .NET.
I will do some testing and see if I can find a solution for this problem.
On Tue, Feb 9, 2010 at 12:54 AM, Tsung-Hsiang Chang <email address hidden> wrote:
> @Eloi:
> Yes, I agree with you. If we can know the lifespan of run-time objects,
> everything would be easy. But I haven't figured out a way to do this yet. :(
> We want to keep the good usability of Sikuli Script so everyone can learn
> it without learning too many rules and syntax.
> I tried to add finalize() in Match objects, so in theory once the Match
> objects are cleaned by JVM's garbage collection, the temp screenshot file
> belong to them should be deleted too. However, it didn't worked as I
> expected.
> Adding a command for advanced users to delete the temp files may be a good
> workaround now, if we can't figure out a way to resolve this issue.
>
> @niceday:
> I don't think that putting the temp files in memory would solve this issue.
> Every time a find() is called, the system captures a new screenshot and
> stores it somewhere. The problem is we don't know when we can release this
> screenshot, because users may do further find() within it.
> You illustrated an example that may not need the original screenshots.
> However, we shouldn't do .inside().find() within a pattern images,
> i.e."some.png", because the pattern image may be not exactly the same as the
> screenshots.
>
> --
> Temp snapshot file not cleared upon close of program or extended time
> causing out of Hard disk space.
> https://bugs.launchpad.net/bugs/515003
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Sikuli: Confirmed
>
> Bug description:
> Sikuli 0.9.7
> 64 Bit Windows 7
>
> Just run application on endless while loop to seek and find any zone.
> After extended usage, there will be a lot of png file formed at
> C:\Users\UserName\AppData\Local\Temp\ and not cleared even after hours
> causing it to bloat to over 10gb in size.
> Or is this behaviour intended.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/sikuli/+bug/515003/+subscribe
>
Hi
I believe that finalize command do not clear up files just release the file
handle or did you write extra code to do the delete? I am thinking of the
following way, let say all the screen shots is dump into the memory, once we
lose reference to the memory for example after the loop ended, JVM should do
a GC eventually to clear up the memory right? I am kind of rusty with Java
after losing touch for like years, but I believe the concept of GC should be
same for java as with .NET.
I will do some testing and see if I can find a solution for this problem.
On Tue, Feb 9, 2010 at 12:54 AM, Tsung-Hsiang Chang <email address hidden> wrote:
> @Eloi: /bugs.launchpad .net/bugs/ 515003 UserName\ AppData\ Local\Temp\ and not cleared even after hours /bugs.launchpad .net/sikuli/ +bug/515003/ +subscribe
> Yes, I agree with you. If we can know the lifespan of run-time objects,
> everything would be easy. But I haven't figured out a way to do this yet. :(
> We want to keep the good usability of Sikuli Script so everyone can learn
> it without learning too many rules and syntax.
> I tried to add finalize() in Match objects, so in theory once the Match
> objects are cleaned by JVM's garbage collection, the temp screenshot file
> belong to them should be deleted too. However, it didn't worked as I
> expected.
> Adding a command for advanced users to delete the temp files may be a good
> workaround now, if we can't figure out a way to resolve this issue.
>
> @niceday:
> I don't think that putting the temp files in memory would solve this issue.
> Every time a find() is called, the system captures a new screenshot and
> stores it somewhere. The problem is we don't know when we can release this
> screenshot, because users may do further find() within it.
> You illustrated an example that may not need the original screenshots.
> However, we shouldn't do .inside().find() within a pattern images,
> i.e."some.png", because the pattern image may be not exactly the same as the
> screenshots.
>
> --
> Temp snapshot file not cleared upon close of program or extended time
> causing out of Hard disk space.
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Sikuli: Confirmed
>
> Bug description:
> Sikuli 0.9.7
> 64 Bit Windows 7
>
> Just run application on endless while loop to seek and find any zone.
> After extended usage, there will be a lot of png file formed at
> C:\Users\
> causing it to bloat to over 10gb in size.
> Or is this behaviour intended.
>
> To unsubscribe from this bug, go to:
> https:/
>