[projects] recycler.py does not build the recycler binary

[GoogleCodeExporter]

I think the __main__ script doesn't work. I found a couple of issues:

1) the regexp used to substitute the new base64encoded binary doesn't match
because uses match instead of search.
2) fixing that, the binary is not correctly built because it is not opened
in binary mode.

Tested on XP and Vista, Python 2.5.1.

I attach a patch the fixes 1) and 2) but you should consider just the
__main__ method (the base64 encoded program is wrong because i'm running it
on a custom recycler.exe)

Original issue reported on code.google.com by rudi.pet...@gmail.com on 30 Jan 2009 at 9:33

Attachments:

• recycler.patch

[GoogleCodeExporter]

Hello,

I will check this more closely this evening if I get a chance. But what was 
wrong 
with this file it has been working (and unchanged) for more than a year?

Whats your custom recycler.exe do thats different?

Original comment by CodyPrec...@gmail.com on 30 Jan 2009 at 10:26

• Changed state: Pending

[GoogleCodeExporter]

I don't know. Maybe the base64 string has not been generated with that script? 
Or
maybe something changed between python 2.5.1 and newer versions. For sure the 
string
generation part does not work now, nor on Vista neither on xp. 

My custom recycler has a couple of features:
1) uses the windows subsystem so that the console doesn't flash when you 
execute it
2) uses a smaller buffer to hold the filename (win32 defines a constant, 
MAX_PATH,
that is actually 260 characters. You can't - normally - create longer paths 
even if
ntfs permits it)

C:\Users\rd\test>python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> filename = os.path.join('c:\users\rd\test', 'a'*244)
>>> open(filename, 'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory:
'c:\\users\rd\test\\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaa'
>>> 

It uses wide chars too, but I'm not sure this makes a difference for paths (NTFS
accepts unicode filenames but I don't know if you can actually handle them 
using win32).

I can attach my custom recycler but i'd like to test it some more. I'm 
wondering if
it is worth porting it to plain python with ctypes too, so it would be better 
integrated.

Original comment by rudi.pet...@gmail.com on 30 Jan 2009 at 10:50

[GoogleCodeExporter]

Ok thanks. I think it may have been generated with python2.4 but I don't 
remember so 
clearly anymore.

Yea it would be great not to have that console window be splashed, and even 
better 
if it was done using ctypes. I had tried to do it in ctypes a few times but 
IIRC I 
couldn't find where to build that struct from.

Thanks,

cody

Original comment by CodyPrec...@gmail.com on 30 Jan 2009 at 10:57

[GoogleCodeExporter]

Maybe I'll give it a try with ctypes this week. 
FYI I attach my custom recycler, but be warned that it needs some testing! It
compiles with mingw32 or with VS (with VS the binary is only 7KB, bu maybe I 
forgot
some flag with mingw32).

Original comment by rudi.pet...@gmail.com on 30 Jan 2009 at 11:32

Attachments:

• recycle.c

[GoogleCodeExporter]

Applied thanks,

Haven't rebuilt the exe yet but will before the next release.

Cody

Original comment by CodyPrec...@gmail.com on 31 Jan 2009 at 12:42

• Changed state: Fixed

[GoogleCodeExporter]

I forgot: with the actual recycler, I had a few crash while deleting. Not real
crashes: editra hanging until I killed it. That happened  in the project 
browser and
in the file browser. Now I'm trying my new version to see if it happens again 
and if
the cause was the exe or something else (maybe some sync issue between the file
deletion in another process and the tree refreshing itself? Just guessing). I 
haven't
seen any pending issue regarding this but I suspect that the old issue that 
prevented
Vista to be detected, prevented that function to be executed as well.

One more thing I should test: deleting with UAC enabled.

Original comment by rudi.pet...@gmail.com on 31 Jan 2009 at 1:52

[GoogleCodeExporter]

Yea every now and then when deleting files either through the plugin or from
elsewhere while the plugin opens there are some crashes. Need to do more traces,
something on a background thread must be touching the gui.

Original comment by CodyPrec...@gmail.com on 31 Jan 2009 at 1:58

[GoogleCodeExporter]

small fix. Actually win32 MAX_PATH includes the nul terminator so the path 
should be
no more than MAX_PATH-1 (the buffer should be MAX_PATH anyway because of the 
second
terminator required by the shell op).

Original comment by rudi.pet...@gmail.com on 31 Jan 2009 at 12:31

Attachments:

• recycle.patch

[GoogleCodeExporter]

ctypes version. I haven't integrated yet, I just tested from the command line. 
Maybe
you could version it so it remains.

Original comment by rudi.pet...@gmail.com on 31 Jan 2009 at 2:31

Attachments:

• win32shell.py

[GoogleCodeExporter]

applied thanks!

Original comment by CodyPrec...@gmail.com on 31 Jan 2009 at 3:31

[GoogleCodeExporter]

Hello, 

I tried integrating the ctypes version in Trash.py. It works but the path 
should not
be escaped with quotes like when calling an external program (the api handles
whitespaces) 

rc = _win_trash.Win32Delete('%s' % path, True)

On the other hand, I must say that whatever version I use (old recycler, new
recycler, ctypes) I can almost always crash editra. I create 3 folders under a
project and delete them backward. It usually crashes at the second folder. 
I was really curious to know if this happens under macosx and linux too, so to
exclude that it is related with the various recycler implementations.

Original comment by rudi.pet...@gmail.com on 31 Jan 2009 at 5:40

[GoogleCodeExporter]

Yes it happens on OSX/Linux as well. It used to happen much more, its most 
likely
(99.9%) caused by a background thread accessing something that belongs to the 
gui.
There are threads fired off to monitor the status of files and remove them from 
the
tree when they are removed on the file system.

I will try to investigate this sometime soon, I am planning to do another round 
of
work on this plugin for the 0.9 release.

Cody

Original comment by CodyPrec...@gmail.com on 1 Feb 2009 at 4:54

[GoogleCodeExporter]

Good luck :-) Hope you find the solution.

By the way, I started the openmodule feature, because I wanted to take a break 
from
the hard and boring javascript parsing (it's really tricky to get right the 
different
idioms). 
Maybe you can version it. It is mostly done and it misses only the hook to 
actually
open the file in editra and some analysis to understand if loading modules that 
way
should deserve some checks (no double loading, maybe unloading them).

At the moment, it is an exact search. An approximate search needs an index and
building an index deserves some planning imho. Maybe the openmodule module is 
not the
right one to do that (a module index can be useful for a lot of 
functionalities). 

Original comment by rudi.pet...@gmail.com on 1 Feb 2009 at 3:18

Attachments:

• openmodule.py

[GoogleCodeExporter]

looks like a nice improvement. I added access to the repo to your google 
acount. So
feel free to check it into the pytool plugin.

Thanks,

Cody

Original comment by CodyPrec...@gmail.com on 1 Feb 2009 at 4:31

[GoogleCodeExporter]

Hello,

I looked through all the project tree code fairly carefully again. I found one
possible cause of the crashes. If you could test and see if there is any 
improvement
that would be great.

Thanks,

Cody

Original comment by CodyPrec...@gmail.com on 1 Feb 2009 at 7:46

[GoogleCodeExporter]

Same thing for me (AppHang). I tried with an unversioned project to see if it 
was the
versioning code fault but it keeps hanging. I just need to create new folders 
and
click them. It takes max 4 folders and a few random clicks to crash it. 

If I do a delete in the middle, it takes me less tries.

If it can helps, here on Vista you can see that there's something strange going 
on 
just looking at the way new folder are created: 

right click -> create new folder -> nothing happens 

If you click on another folder, suddenly the new folder appear. 

Looking at the code, I've seen a few "while True:" loops here and then. Maybe 
some
bug in that iterators (just guessing), loop corrputed when the cardinality of 
the
tree changes?

Original comment by rudi.pet...@gmail.com on 1 Feb 2009 at 9:29

[GoogleCodeExporter]

By the way when hanging, it uses 49/50% of the cpu. Same as running something 
like:

while True: pass

Original comment by rudi.pet...@gmail.com on 1 Feb 2009 at 9:40

[GoogleCodeExporter]

Ok, I thought you said it was crashing before. So the problem is that its 
hanging?

Not sure that it will help much but I couldn't follow all that was going on 
very well
in the directory watcher code so I re-wrote/factored a some of it today. I can't
reproduce the crashes on my machine very often so if you could check again that 
would
be great.

If the issue still persists lets open a new issue to track progress on it. This 
one
is getting a little crowded.

Thanks,

Cody

Original comment by CodyPrec...@gmail.com on 2 Feb 2009 at 1:58

[GoogleCodeExporter]

I had crashes and hangs both in the file browser and in the project explorer, 
but the 
hanging problem in the Project Explorer is the one I can easily reproduce. 
Now I'm trying on XP and it is not hanging anymore. There are some other 
issues. I'll 
open up a new issue.

Original comment by rudi.pet...@gmail.com on 2 Feb 2009 at 10:51

[GoogleCodeExporter]

Move old 'fixed' issues to verified

Original comment by CodyPrec...@gmail.com on 3 Feb 2009 at 8:18

• Changed state: Verified