Temp snapshot file not cleared upon close of program or extended time causing out of Hard disk space.

[Eloi]

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.

[niceday (chowchi)]

in APPLE osx got the same problem,may be you can just put these files in RAM,cause i don't need them any more after very match runction

[niceday (chowchi)]

this is another big program,please try to solved it

thank you verymuch

the best way,put the capture pic in memory,do not reapeat write disk,it's no use any more

thanks!!!!!!!!!!!!!!!!!!!!!!1

[niceday (chowchi)]

too many files
please

[niceday (chowchi)]

please fix this first

i know in new version the IDE will del all the files.

But if a long running program,will cause the temp files too big,and I have to delete myslef.

use
import os
os.system("del c:\\temp\\*.png /Q /S")
after every loop
please
happy new year

[Tsung-Hsiang Chang (vgod)]

This issue is a little bit tricky. Since each screenshot can be used with spatial operators (e.g. inside) and more find() within it. It's hard to know when we can delete the temp files in run time unless we parse users' jython scripts by ourselves.
If anyone has ideas or suggestions, please let us know.

[Eloi (eloi)]

I was thinking along the line of processing the image in memory and release
the memory once the Image goes out of context, for example the find done
within the loop will only exist within the loop and so on and so fore. One
easy way might be force the user to declare a holding variable to store the
image to do inside and such and the lifespan of the variable is within a
certain context for example one single loop.

If all this still require parsing of jython scripts then maybe an
alternative is expose a command to let us release the image directly for
advance user and the rest have to bear with the increase in hard disk usage
all the time.

On Mon, Feb 8, 2010 at 10:40 PM, Tsung-Hsiang Chang <email address hidden> wrote:

> This issue is a little bit tricky. Since each screenshot can be used with
> spatial operators (e.g. inside) and more find() within it. It's hard to know
> when we can delete the temp files in run time unless we parse users' jython
> scripts by ourselves.
> If anyone has ideas or suggestions, please let us know.
>
> ** Changed in: sikuli
> Status: New => Confirmed
>
> --
> 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
>

[RaiMan (raimund-hocke)]

@Eloi
Standing here and clapping hands.

Thought about something like that some minutes ago, remembering how all these things are managed with Apples Objective C including the functionality of the autorelease pool.

[niceday (chowchi)]

First thank you very much again,sorry my chinese english:)
the low level funciton in SikuliScript.java
Matches _find(String img, String region, float similarity, int numMatches)

every time _find called,a screenshot files put in temp directory,and more match works done.
You can just put this screenshot in ram not in files,i mean this full screen snapshot or Subregion file
actually involved the inside().find(),just like you web how to's •How to click on a particular check box? all theses
you don't have to use the full screen snapshot,just the files in the ????.sikuli directory
x = find("some.png") \\here you got the some.png position.
click(x.inside().find("s.png")) \\here don't have to use the full screen snapshot,just search in some.png,and got relative coordinates so absolute coordinates can be get use + or -

god bless me you can understand my english T_T

[niceday (chowchi)]

the problem is not how to delete these files
the right thing is do not put them in disk!!

[Eloi (eloi)]

Hi
I roughly can understand what you meant but the same thing will apply
whether it is in memory or disk, the problem now is knowing the contextual
lifespan of a particular image file. If there is a way to clearly define
when to remove it. It does not matter if the image is in memory or disk as
both can be remove easily.

On Tue, Feb 9, 2010 at 12:14 AM, niceday <email address hidden> wrote:

> First thank you very much again,sorry my chinese english:)
> the low level funciton in SikuliScript.java
> Matches _find(String img, String region, float similarity, int numMatches)
>
> every time _find called,a screenshot files put in temp directory,and more
> match works done.
> You can just put this screenshot in ram not in files,i mean this full
> screen snapshot or Subregion file
> actually involved the inside().find(),just like you web how to's •How to
> click on a particular check box? all theses
> you don't have to use the full screen snapshot,just the files in the
> ????.sikuli directory
> x = find("some.png") \\here you got the some.png
> position.
> click(x.inside().find("s.png")) \\here don't have to use the
> full screen snapshot,just search in some.png,and got relative coordinates
> so absolute coordinates can be get use + or -
>
>
> god bless me you can understand my english T_T
>
> --
> 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
>

[Tsung-Hsiang Chang (vgod)]

@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.

[Eloi (eloi)]

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
>

[Tsung-Hsiang Chang (vgod)]

@Eloi:
I wrote extra code to delete the temp files. ( I haven't committed this. Here is the piece of code that I added in sikuli-script/src/main/java/edu/mit/csail/uid/Match.java.)

   protected void finalize() {
      File f = new File(parent);
      if(f!=null && f.exists())
         f.delete();
   }

Actually, I have the same thought as yours. That's why I was trying finalize(). If GC clears the lost references, the Match.finalize() should be called. But it turns out JVM didn't do GC on the Match objects while running a jython script, so nothing is cleared.

[niceday (chowchi)]

@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.

maybe i don't understand you,the files you said up --> do.inside().find()
these files maybe not so many,and you can put them in temp
hope you can find a way to put them in memory

and now I will creat a ram disk for my app,and del *.png /after every main loop

[niceday (chowchi)]

cause I use sikuli to control a game
after a day workaround,34200 files in tmp,GOD

in the waiting time.

if you use MAC,you can do this

import os
os.system("rm $TMPDIR/*.png >nul")

[Krasus (specialswif)]

why not changing the syntax ? The user can specify exactly when he needs the keep the screenshot !
When you make a find :

x = image1.find(image2) {
    // the "x" var is defined here and only here
    x.doSomething()
}
// now, the screenshot has been deleted.

[Eloi (eloi)]

Hi
That is what they are trying to do and still haven got it to work. I am
still stuck at the stage of setting up an environment to develop and test.
So for now I guess everyone just have to keep deleting.

On Mon, Feb 22, 2010 at 7:54 PM, Krasus <email address hidden> wrote:

> why not changing the syntax ? The user can specify exactly when he needs
> the keep the screenshot !
> When you make a find :
>
> x = image1.find(image2) {
> // the "x" var is defined here and only here
> x.doSomething()
> }
> // now, the screenshot has been deleted.
>
> --
> 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
>

[RaiMan (raimund-hocke)]

version 0.10: does not use tempfiles for screenshots anymore. processed completely in memory.