Menu
▾
▴
gmailagent-devel
|
From: Stas Z <sta...@gm...> - 2005-09-21 18:32:08
|
Hello, I've released version 0.1.3. This release fixes a number of bugs that leads to a crash when accessing small or empty accounts. Also the problem that not all the messaged were returned in large accounts is resolved. To download: http://sourceforge.net/project/showfiles.php?group_id=3D113492&package_id= =3D122807 Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Sebastien D. <sde...@gm...> - 2005-09-21 19:19:13
|
Unfortunately this doesn't fix gmailfs: I am still getting errors on
the gmailfs share, mounted on /mnt:
~ # sudo ls /mnt
~ #
This is fine, as my share is a new one, so it's empty. But then:
~ # sudo touch /mnt/test
Empty account
Traceback (most recent call last):
File "/usr/share/gmailfs/gmailfs.py", line 1094, in getinodemsg
return thread._messages[len(thread._messages)-1]
IndexError: list index out of range
Yet the file has been created:
~ # sudo ls /mnt
test
~ #
Another quirk appears when you create a directory:
~ # sudo mkdir /mnt/bar
Empty account
Traceback (most recent call last):
File "/usr/share/gmailfs/gmailfs.py", line 1094, in getinodemsg
return thread._messages[len(thread._messages)-1]
IndexError: list index out of range
And then listing it doesn't yield an exception, but something even
weirder:
~ # sudo ls /mnt/bar
Empty account
Has there been an API change somewhere, among all those
bugfixes/security fixes ?
Cheers,
--Seb
|
|
From: Stas Z <sta...@gm...> - 2005-09-21 19:48:52
|
On 9/21/05, Sebastien Delafond <sde...@gm...> wrote: > Unfortunately this doesn't fix gmailfs: I am still getting errors on First of all, I know nothing about gmailfs, but I see some trouble spots. [...] > ~ # sudo touch /mnt/test > Empty account > Traceback (most recent call last): > File "/usr/share/gmailfs/gmailfs.py", line 1094, in getinodemsg > return thread._messages[len(thread._messages)-1] > IndexError: list index out of range Just guessing here, but I suspect this is the GmailThread._messages attribu= te. If so it's better not to use attributes directly but to use the API Further more if indeed GmailThread._messages is used, this class hasn't changed since libgmail version 0.1.0. [....] > And then listing it doesn't yield an exception, but something even > weirder: > > ~ # sudo ls /mnt/bar > Empty account Yet another result of accessing class attributes directly rather then through an API. It's part of a exception catch I added to test for empty message threads. I suspect because gmailfs interacts with the internal message threads rather then through an API, it gets into trouble because there are changes to these int= ernal class attributes. > > Has there been an API change somewhere, among all those > bugfixes/security fixes ? Changes yes, to an API no. I hope richard can comment on this, because I don't know how gmailfs (ab)us= es libgmail. Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Richard J. <jo...@gm...> - 2005-09-23 02:58:05
|
On 9/22/05, Stas Z <sta...@gm...> wrote:
> On 9/21/05, Sebastien Delafond <sde...@gm...> wrote:
> > Unfortunately this doesn't fix gmailfs: I am still getting errors on
> First of all, I know nothing about gmailfs, but I see some trouble spots.
>
> [...]
> > ~ # sudo touch /mnt/test
> > Empty account
> > Traceback (most recent call last):
> > File "/usr/share/gmailfs/gmailfs.py", line 1094, in getinodemsg
> > return thread._messages[len(thread._messages)-1]
> > IndexError: list index out of range
> Just guessing here, but I suspect this is the GmailThread._messages attri=
bute.
> If so it's better not to use attributes directly but to use the API
> Further more if indeed GmailThread._messages is used, this class
> hasn't changed since
> libgmail version 0.1.0.
>
> [....]
> > And then listing it doesn't yield an exception, but something even
> > weirder:
> >
> > ~ # sudo ls /mnt/bar
> > Empty account
> Yet another result of accessing class attributes directly rather then
> through an API.
> It's part of a exception catch I added to test for empty message threads.
>
> I suspect because gmailfs interacts with the internal message threads
> rather then
> through an API, it gets into trouble because there are changes to these i=
nternal
> class attributes.
>
> >
> > Has there been an API change somewhere, among all those
> > bugfixes/security fixes ?
> Changes yes, to an API no.
>
> I hope richard can comment on this, because I don't know how gmailfs (ab)=
uses
> libgmail.
>
Hi Stas,
You are quite correct I shouldn't be messing with the internal class
attributes, however I don't think this is the core problem here
(although it doesn't help).
If you look at the GmailSearchResult initialisation method below:
class GmailSearchResult:
"""
"""
def __init__(self, account, search, threadsInfo):
"""
`threadsInfo` -- As returned from Gmail but unbunched.
"""
#print "\nthreadsInfo\n",threadsInfo
try:
if not type(threadsInfo[0]) is types.ListType:
threadsInfo =3D [threadsInfo]
except IndexError:
print "Empty account"
threadsInfo =3D [ ['']*13 ]
self._account =3D account
self.search =3D search # TODO: Turn into object + format nicely.
self._threads =3D []
#print "\nthreadInfo\n",pprint.pprint(threadsInfo)
####### debug code #########
## f =3D open('out.txt','w')
## pprint.pprint(threadsInfo,f,4)
## f.close()
#############################
for thread in threadsInfo:
self._threads.append(GmailThread(self, thread))
Based on the error message "Empty Account" you seem to be assuming
that threadsInfo[0] will be an illegal index only when the account is
empty. In fact there appears to be a much more common reason for
threadsInfo to be empty, this seems to occur (based on my limited
testing) when the query returns no results. By catching the error in
the way you are doing and filling threadsInfo with some value to
prevent it being empty you are causing len on a GmailSearchResult to
return 1, when really there were no results. The gmailfs errors occur
when after checking the len and finding it is one I then grab some
stuff on the assumption that there are results when really there are
none. If you can make the len return 0 when there were no results
(which seems to make sense) then the other gmailfs problems should go
away (although I am still being silly and accessing internal
attributes, I couldn't find an API supported way of directly indexing
particular thread and message numbers, please tell me if I'm missing
something).
Regards,
Richard.
|
|
From: Stas Z <sta...@gm...> - 2005-09-23 13:06:12
|
On 9/22/05, Richard Jones <jo...@gm...> wrote:
> > I suspect because gmailfs interacts with the internal message threads
> > rather then
> > through an API, it gets into trouble because there are changes to these=
internal
> > class attributes.
[....]
> You are quite correct I shouldn't be messing with the internal class
> attributes, however I don't think this is the core problem here
> (although it doesn't help).
>
> If you look at the GmailSearchResult initialisation method below:
[...]
> except IndexError:
> print "Empty account"
[...]
> Based on the error message "Empty Account" you seem to be assuming
> that threadsInfo[0] will be an illegal index only when the account is
> empty. In fact there appears to be a much more common reason for
> threadsInfo to be empty, this seems to occur (based on my limited
> testing) when the query returns no results.
Your right the message is wrong it should say "Empty thread"
[...]
> attributes, I couldn't find an API supported way of directly indexing
> particular thread and message numbers, please tell me if I'm missing
> something).
Well I guess if you using libgmail in such a way as you do in gmailfs
your better of with a abstraction layer that can function as a interface
to libgmail.
My proposal to you as your a "libgmail-poweruser" is this;
If you describe which methods you need then we will provide a object
that act as a interface between gmailfs and libgmail.
We will maintain this class so that any change we make to libgmail
will also be changed in the interface class.
We will put it into a module of it's own so that it doesn't affect the 'nor=
mal'
libgmail usage.
For example:
You want to know how many messages there are in a thread.
So you want to do something like:
from FsInter import FsInter # This is the abstraction class
ga is FsInter.GMAccount("name","pass")
ga.login()
thread =3D ga.getMessages.......
....
def getinodemsg():
......
......
return thread.NumberOf Messages()
Or something like that.
Then you don't have to care about our changes :-)
We will make sure that the abstraction class gets to the internals in
a proper way.
Stas
--
A nation that continues year after year to spend more money on military def=
ense
than on programs of social uplift is approaching spiritual doom.
Martin Luther King, Jr.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X