Binger David | 25 Jun 2010 22:54

Re: apparently random bug in durus


On Jun 25, 2010, at 4:30 PM, Alex Hall wrote:

> On 6/25/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>> Please edit c:\python26\lib\site-packages\durus\connection.py to get more
>> information.
>> In particular, insert at line 137, just before the klass = loads(data) line,
>> some lines that print or write to a file,
>> the values of sys.version, sys.path, sys.executable
>> You might also insert an explicit "import durus.persistent_dict" there
>> too, to see if that works as it should.
> I did, and got the usual error.
>> Also print out repr(data) while you are at it.
>> Perhaps some change to sys.path or a chdir occurs
>> that puts a directory containing a "durus" entry other
>> than the durus installation directory on your path
>> before the durus installation directory.
> Here is the output I got when printing the three sys attributes to a
> file. Hopefully the repr(data) one makes sense to you, because I have
> no idea what it means. BTW, thanks for continuing to pursue this.
> 
> path: c:\qwitter\src
> C:\Windows\system32\python26.zip
> c:\python26\DLLs
> c:\python26\lib
> c:\python26\lib\plat-win
> c:\python26\lib\lib-tk
> c:\python26
> c:\python26\lib\site-packages
> c:\python26\lib\site-packages\PIL
(Continue reading)

Alex Hall | 26 Jun 2010 00:10
Picon
Gravatar

Re: apparently random bug in durus

On 6/25/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>
> On Jun 25, 2010, at 4:30 PM, Alex Hall wrote:
>
>> On 6/25/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>>> Please edit c:\python26\lib\site-packages\durus\connection.py to get more
>>> information.
>>> In particular, insert at line 137, just before the klass = loads(data)
>>> line,
>>> some lines that print or write to a file,
>>> the values of sys.version, sys.path, sys.executable
>>> You might also insert an explicit "import durus.persistent_dict" there
>>> too, to see if that works as it should.
>> I did, and got the usual error.
>>> Also print out repr(data) while you are at it.
>>> Perhaps some change to sys.path or a chdir occurs
>>> that puts a directory containing a "durus" entry other
>>> than the durus installation directory on your path
>>> before the durus installation directory.
>> Here is the output I got when printing the three sys attributes to a
>> file. Hopefully the repr(data) one makes sense to you, because I have
>> no idea what it means. BTW, thanks for continuing to pursue this.
>>
>> path: c:\qwitter\src
>> C:\Windows\system32\python26.zip
>> c:\python26\DLLs
>> c:\python26\lib
>> c:\python26\lib\plat-win
>> c:\python26\lib\lib-tk
>> c:\python26
(Continue reading)

Neil Schemenauer | 28 Jun 2010 21:56

Re: apparently random bug in durus

Binger David <dbinger <at> mems-exchange.org> wrote:
>
> On Jun 25, 2010, at 4:30 PM, Alex Hall wrote:
>> Repr(data): '\x80\x02cdurus.durus.persistent_dict\nPersistentDict\nq\x01.x\x9c\xb5Z}`\\E\x11O\x8e\x92\xa6I\x9a\xb6iB\xcbw
>> 
>> ...
>
> The string should start with '\x80\x02cdurus.persistent_dict\nPersistentDict\nq'
> not
> '\x80\x02cdurus.durus.persistent_dict\nPersistentDict\nq'.
>
> I think this is the problem.  I'm not sure how it originates.

Definitely a problem.  I wonder if somewhere the Connection class
got passed a bad 'root_class' argument.  I can't see any way Durus
itself can create such a thing.

As a hack so you can load your data, add this early in the startup
(e.g. before Durus is imported):

    import sys
    import durus
    durus.durus = durus
    sys.modules['durus.durus'] = durus

After that you should be able to execute:

    import durus.durus.persistent_dict

without errors.
(Continue reading)

Binger David | 28 Jun 2010 22:26

Re: apparently random bug in durus

I think I saw over on the qwitter list that this occurred because
someone had a durus installation directory inside a durus installation
directory at the time that the root was instantiated,
I'm not sure what the installation method was, but the results
were bad.  

On Jun 28, 2010, at 3:56 PM, Neil Schemenauer wrote:

> Binger David <dbinger <at> mems-exchange.org> wrote:
>> 
>> On Jun 25, 2010, at 4:30 PM, Alex Hall wrote:
>>> Repr(data): '\x80\x02cdurus.durus.persistent_dict\nPersistentDict\nq\x01.x\x9c\xb5Z}`\\E\x11O\x8e\x92\xa6I\x9a\xb6iB\xcbw
>>> 
>>> ...
>> 
>> The string should start with '\x80\x02cdurus.persistent_dict\nPersistentDict\nq'
>> not
>> '\x80\x02cdurus.durus.persistent_dict\nPersistentDict\nq'.
>> 
>> I think this is the problem.  I'm not sure how it originates.
> 
> Definitely a problem.  I wonder if somewhere the Connection class
> got passed a bad 'root_class' argument.  I can't see any way Durus
> itself can create such a thing.
> 
> As a hack so you can load your data, add this early in the startup
> (e.g. before Durus is imported):
> 
>    import sys
>    import durus
(Continue reading)

Neil Schemenauer | 28 Jun 2010 23:48

Re: apparently random bug in durus

On Mon, Jun 28, 2010 at 04:26:07PM -0400, Binger David wrote:
> I think I saw over on the qwitter list that this occurred because
> someone had a durus installation directory inside a durus installation
> directory at the time that the root was instantiated,

Ah, implicit relative import bites us.  I wonder if it would be time
to switch to using absolute imports.  i.e, add

    from  __future__ import absolute_import

to the Durus modules.  That would make Durus depend on Python 2.5.

  Neil
Michael Watkins | 29 Jun 2010 00:41
Picon
Favicon

Re: apparently random bug in durus

On Mon, June 28, 2010 14:48, Neil Schemenauer wrote:
> Ah, implicit relative import bites us.  I wonder if it would be time
> to switch to using absolute imports.  i.e, add
>
>     from  __future__ import absolute_import
>
> to the Durus modules.  That would make Durus depend on Python 2.5.

Never having once used relative imports in all these years, +1 from me.
Running 2.6.x and 3.1.x or higher these days.
Binger David | 29 Jun 2010 03:39

Re: apparently random bug in durus

I would like this idea fine if we were not still running
most of our sites on 2.4.  It will still be a while before we
are ready to leave 2.4 behind. 

It seems we could guard against this particular problem by adding
something to the durus/__init__.py 
It does seem odd, though, to write code to detect broken installations,

On Jun 28, 2010, at 6:41 PM, Michael Watkins wrote:

> On Mon, June 28, 2010 14:48, Neil Schemenauer wrote:
>> Ah, implicit relative import bites us.  I wonder if it would be time
>> to switch to using absolute imports.  i.e, add
>> 
>>    from  __future__ import absolute_import
>> 
>> to the Durus modules.  That would make Durus depend on Python 2.5.
> 
> Never having once used relative imports in all these years, +1 from me.
> Running 2.6.x and 3.1.x or higher these days.
Neil Schemenauer | 29 Jun 2010 03:53

Re: apparently random bug in durus

Binger David <dbinger <at> mems-exchange.org> wrote:
> I would like this idea fine if we were not still running
> most of our sites on 2.4.  It will still be a while before we
> are ready to leave 2.4 behind. 

You could have the root class loaded by __import__, checking at
runtime if it supports the 'level' keyword.  Use level=0 if it's
supported.

I wonder if changing pickle.__import__ to use level=0 would make
sense too.  The classes that Durus is pickling should all have
absolute names, right?

> It seems we could guard against this particular problem by adding
> something to the durus/__init__.py 
> It does seem odd, though, to write code to detect broken installations,

Yeah, that's hokey.  My __import__ magic explained above is perhaps
not worth it too.

  Neil
Neil Schemenauer | 29 Jun 2010 04:06

Python 2.7+ (Re: apparently random bug in durus)

Michael Watkins <python <at> mikewatkins.ca> wrote:
> Never having once used relative imports in all these years, +1 from me.
> Running 2.6.x and 3.1.x or higher these days.

from __future__ only affects the module it appears in.  Aside from
package install errors, I guess it doesn't buy us too much.  Since
people are still using Python 2.4 we should probably forget for now.

BTW, I wonder how people are interested in a Python 2.7+?  Most of
the core Python developers want to stop the 2.x branch after 2.7.
I'm considering making my own branch, incorporating some of the
patches that didn't make it in 2.7.

  Neil
Michael Watkins | 29 Jun 2010 06:34
Picon
Favicon

Re: Python 2.7+ (Re: apparently random bug in durus)

On Mon, June 28, 2010 19:06, Neil Schemenauer wrote:
> from __future__ only affects the module it appears in.  Aside from
> package install errors, I guess it doesn't buy us too much.

Of course, forgot that. Given I also agree with David's observation please
consider my +1 comment to now mean that I don't have any particular
hangups about Python version support.

> BTW, I wonder how people are interested in a Python 2.7+?  Most of
> the core Python developers want to stop the 2.x branch after 2.7.
> I'm considering making my own branch, incorporating some of the
> patches that didn't make it in 2.7.

I'm ambivalent. I'd like to move everything to 3.x but haven't quite been
able to quite do that in all our projects due to package availability
although we don't use a lot of third party packages.
Alex Hall | 28 Jun 2010 23:37
Picon
Gravatar

Re: apparently random bug in durus

True, but that is not the case here; I have only one Durus directory
inside site-packages.

On 6/28/10, Binger David <dbinger <at> mems-exchange.org> wrote:
> I think I saw over on the qwitter list that this occurred because
> someone had a durus installation directory inside a durus installation
> directory at the time that the root was instantiated,
> I'm not sure what the installation method was, but the results
> were bad.
>
> On Jun 28, 2010, at 3:56 PM, Neil Schemenauer wrote:
>
>> Binger David <dbinger <at> mems-exchange.org> wrote:
>>>
>>> On Jun 25, 2010, at 4:30 PM, Alex Hall wrote:
>>>> Repr(data):
>>>> '\x80\x02cdurus.durus.persistent_dict\nPersistentDict\nq\x01.x\x9c\xb5Z}`\\E\x11O\x8e\x92\xa6I\x9a\xb6iB\xcbw
>>>>
>>>> ...
>>>
>>> The string should start with
>>> '\x80\x02cdurus.persistent_dict\nPersistentDict\nq'
>>> not
>>> '\x80\x02cdurus.durus.persistent_dict\nPersistentDict\nq'.
>>>
>>> I think this is the problem.  I'm not sure how it originates.
>>
>> Definitely a problem.  I wonder if somewhere the Connection class
>> got passed a bad 'root_class' argument.  I can't see any way Durus
>> itself can create such a thing.
(Continue reading)

Neil Schemenauer | 28 Jun 2010 23:50

Re: apparently random bug in durus

On Mon, Jun 28, 2010 at 05:37:06PM -0400, Alex Hall wrote:
> True, but that is not the case here; I have only one Durus
> directory inside site-packages.

It matters how the package was setup when the root object was
created and stored in the DB.  IOW, if your setup had a 'durus'
package inside the 'durus' package in the past then that would
explain this error.

Regards,

  Neil
Neil Schemenauer | 29 Jun 2010 03:55

Re: apparently random bug in durus

> IOW, if your setup had a 'durus' package inside the 'durus'
> package in the past then that would explain this error.

Yo, dawg... never mind. ;-)
Binger David | 29 Jun 2010 19:19

Re: apparently random bug in durus

Hi Alex,

I forgot to ask you if you have tried removing your
qwitter database file since getting your installation
fixed.  By fixed, I mean there is no durus* file or directory
inside your durus installation directory.

On Jun 28, 2010, at 5:37 PM, Alex Hall wrote:

> True, but that is not the case here; I have only one Durus directory
> inside site-packages.
Alex Hall | 29 Jun 2010 21:19
Picon
Gravatar

Re: apparently random bug in durus

Yes. I just moved all .db files into a subfolder of the qwitter folder
(%appdata%\qwitter) and got the same error.

On 6/29/10, Binger David <dbinger <at> mems-exchange.org> wrote:
> Hi Alex,
>
> I forgot to ask you if you have tried removing your
> qwitter database file since getting your installation
> fixed.  By fixed, I mean there is no durus* file or directory
> inside your durus installation directory.
>
> On Jun 28, 2010, at 5:37 PM, Alex Hall wrote:
>
>> True, but that is not the case here; I have only one Durus directory
>> inside site-packages.
>
>

--

-- 
Have a great day,
Alex (msg sent from GMail website)
mehgcap <at> gmail.com; http://www.facebook.com/mehgcap
Binger David | 29 Jun 2010 22:38

Re: apparently random bug in durus

Could you try this procedure in a python command window please?

from durus.connection import Connection
c = Connection('testfile.durus')
print( c.get_root().__class__)
from pickle import dumps
print(dumps(c.get_root().__class__, 2))

If working correctly, we should not see any durus.durus names.

Is it possible that qwitter, or one of the many qwitter dependencies
listed below, changes the way import works before durus gets imported
in a qwitter application?  I'm trying to figure out what makes a
qwitter application different from the direct use of durus.


On Jun 29, 2010, at 3:19 PM, Alex Hall wrote:

Yes. I just moved all .db files into a subfolder of the qwitter folder
(%appdata%\qwitter) and got the same error.

On 6/29/10, Binger David <dbinger <at> mems-exchange.org> wrote:
Hi Alex,

I forgot to ask you if you have tried removing your
qwitter database file since getting your installation
fixed.  By fixed, I mean there is no durus* file or directory
inside your durus installation directory.

On Jun 28, 2010, at 5:37 PM, Alex Hall wrote:

True, but that is not the case here; I have only one Durus directory
inside site-packages.




--
Have a great day,
Alex (msg sent from GMail website)
mehgcap <at> gmail.com; http://www.facebook.com/mehgcap

_______________________________________________
Durus-users mailing list
Durus-users <at> mems-exchange.org
http://mail.mems-exchange.org/mailman/listinfo/durus-users
Alex Hall | 29 Jun 2010 22:45
Picon
Gravatar

Re: apparently random bug in durus

Here is what I get when I put your code into c:\misc\durus_test.py and
then ran it.

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Alex>python c:\misc\durus_test.py
Using Python base classes for persistence.
Transaction at [2010-06-29 16:43:58.858000] end=145
<class 'durus.persistent_dict.PersistentDict'>
Ç☻cdurus.persistent_dict
PersistentDict
q .

C:\Users\Alex>

On 6/29/10, Binger David <dbinger <at> mems-exchange.org> wrote:
> Could you try this procedure in a python command window please?
>
> from durus.connection import Connection
> c = Connection('testfile.durus')
> print( c.get_root().__class__)
> from pickle import dumps
> print(dumps(c.get_root().__class__, 2))
>
> If working correctly, we should not see any durus.durus names.
>
> Is it possible that qwitter, or one of the many qwitter dependencies
> listed below, changes the way import works before durus gets imported
> in a qwitter application?  I'm trying to figure out what makes a
> qwitter application different from the direct use of durus.
> PIL-1.1.6.win32-py2.6.exe
> PyDispatcher-2.0.1.win32.exe
> Skype4Py-1.0.32.1.win32.exe
> bingapi-0.02.win32.exe
> comtypes-0.6.1.win32.exe
> configobj-4.6.0.win32-py2.6.msi
> feedparser-4.1.win32.exe
> numpy-1.3.0rc2-win32-superpack-python2.6.exe
> py26-pysvn-svn161-1.7.0-1177.exe
> py2exe-0.6.9.win32-py2.6.exe
> pyaudiere-0.2.win32-py2.6.msi
> pygooglevoice-0.5.win32.exe
> pywin32-214.win32-py2.6.exe
> speech-0.5.2.win32.exe
> urlunshort-0.2.4.win32.exe
> wxPython2.9-win32-unicode-2.9.0.1.pre20100113-py26.exe
>
>
>
> On Jun 29, 2010, at 3:19 PM, Alex Hall wrote:
>
>> Yes. I just moved all .db files into a subfolder of the qwitter folder
>> (%appdata%\qwitter) and got the same error.
>>
>> On 6/29/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>>> Hi Alex,
>>>
>>> I forgot to ask you if you have tried removing your
>>> qwitter database file since getting your installation
>>> fixed.  By fixed, I mean there is no durus* file or directory
>>> inside your durus installation directory.
>>>
>>> On Jun 28, 2010, at 5:37 PM, Alex Hall wrote:
>>>
>>>> True, but that is not the case here; I have only one Durus directory
>>>> inside site-packages.
>>>
>>>
>>
>>
>> --
>> Have a great day,
>> Alex (msg sent from GMail website)
>> mehgcap <at> gmail.com; http://www.facebook.com/mehgcap
>
>

--

-- 
Have a great day,
Alex (msg sent from GMail website)
mehgcap <at> gmail.com; http://www.facebook.com/mehgcap
_______________________________________________
Durus-users mailing list
Durus-users <at> mems-exchange.org
http://mail.mems-exchange.org/mailman/listinfo/durus-users
Binger David | 29 Jun 2010 22:56

Re: apparently random bug in durus


On Jun 29, 2010, at 4:45 PM, Alex Hall wrote:

> Here is what I get when I put your code into c:\misc\durus_test.py and
> then ran it.
> 
> Microsoft Windows [Version 6.1.7600]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
> 
> C:\Users\Alex>python c:\misc\durus_test.py
> Using Python base classes for persistence.
> Transaction at [2010-06-29 16:43:58.858000] end=145
> <class 'durus.persistent_dict.PersistentDict'>
> Ç☻cdurus.persistent_dict
> PersistentDict
> q .

That looks normal.

Somehow, the class durus.persistent_dict.PersistentDict is apparently being imported
as durus.durus.persistent_dict.PersistentDict, but only inside the qwitter application.
What could cause that?

> 
> C:\Users\Alex>
> 
> On 6/29/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>> Could you try this procedure in a python command window please?
>> 
>> from durus.connection import Connection
>> c = Connection('testfile.durus')
>> print( c.get_root().__class__)
>> from pickle import dumps
>> print(dumps(c.get_root().__class__, 2))
>> 
>> If working correctly, we should not see any durus.durus names.
>> 
>> Is it possible that qwitter, or one of the many qwitter dependencies
>> listed below, changes the way import works before durus gets imported
>> in a qwitter application?  I'm trying to figure out what makes a
>> qwitter application different from the direct use of durus.
>> PIL-1.1.6.win32-py2.6.exe
>> PyDispatcher-2.0.1.win32.exe
>> Skype4Py-1.0.32.1.win32.exe
>> bingapi-0.02.win32.exe
>> comtypes-0.6.1.win32.exe
>> configobj-4.6.0.win32-py2.6.msi
>> feedparser-4.1.win32.exe
>> numpy-1.3.0rc2-win32-superpack-python2.6.exe
>> py26-pysvn-svn161-1.7.0-1177.exe
>> py2exe-0.6.9.win32-py2.6.exe
>> pyaudiere-0.2.win32-py2.6.msi
>> pygooglevoice-0.5.win32.exe
>> pywin32-214.win32-py2.6.exe
>> speech-0.5.2.win32.exe
>> urlunshort-0.2.4.win32.exe
>> wxPython2.9-win32-unicode-2.9.0.1.pre20100113-py26.exe
>> 
>> 
>> 
>> On Jun 29, 2010, at 3:19 PM, Alex Hall wrote:
>> 
>>> Yes. I just moved all .db files into a subfolder of the qwitter folder
>>> (%appdata%\qwitter) and got the same error.
>>> 
>>> On 6/29/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>>>> Hi Alex,
>>>> 
>>>> I forgot to ask you if you have tried removing your
>>>> qwitter database file since getting your installation
>>>> fixed.  By fixed, I mean there is no durus* file or directory
>>>> inside your durus installation directory.
>>>> 
>>>> On Jun 28, 2010, at 5:37 PM, Alex Hall wrote:
>>>> 
>>>>> True, but that is not the case here; I have only one Durus directory
>>>>> inside site-packages.
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Have a great day,
>>> Alex (msg sent from GMail website)
>>> mehgcap <at> gmail.com; http://www.facebook.com/mehgcap
>> 
>> 
> 
> 
> -- 
> Have a great day,
> Alex (msg sent from GMail website)
> mehgcap <at> gmail.com; http://www.facebook.com/mehgcap

_______________________________________________
Durus-users mailing list
Durus-users <at> mems-exchange.org
http://mail.mems-exchange.org/mailman/listinfo/durus-users
Alex Hall | 30 Jun 2010 04:17
Picon
Gravatar

Re: apparently random bug in durus

I am not sure. Would posting this output make any sense on the Qwitter
list? That is, would one of the devs be able to help? Q (or maybe it
was HLLF) says he found the solution, but you said that what he found
is not causing the problem...

On 6/29/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>
> On Jun 29, 2010, at 4:45 PM, Alex Hall wrote:
>
>> Here is what I get when I put your code into c:\misc\durus_test.py and
>> then ran it.
>>
>> Microsoft Windows [Version 6.1.7600]
>> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>>
>> C:\Users\Alex>python c:\misc\durus_test.py
>> Using Python base classes for persistence.
>> Transaction at [2010-06-29 16:43:58.858000] end=145
>> <class 'durus.persistent_dict.PersistentDict'>
>> Ç☻cdurus.persistent_dict
>> PersistentDict
>> q .
>
> That looks normal.
>
> Somehow, the class durus.persistent_dict.PersistentDict is apparently being
> imported
> as durus.durus.persistent_dict.PersistentDict, but only inside the qwitter
> application.
> What could cause that?
>
>>
>> C:\Users\Alex>
>>
>> On 6/29/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>>> Could you try this procedure in a python command window please?
>>>
>>> from durus.connection import Connection
>>> c = Connection('testfile.durus')
>>> print( c.get_root().__class__)
>>> from pickle import dumps
>>> print(dumps(c.get_root().__class__, 2))
>>>
>>> If working correctly, we should not see any durus.durus names.
>>>
>>> Is it possible that qwitter, or one of the many qwitter dependencies
>>> listed below, changes the way import works before durus gets imported
>>> in a qwitter application?  I'm trying to figure out what makes a
>>> qwitter application different from the direct use of durus.
>>> PIL-1.1.6.win32-py2.6.exe
>>> PyDispatcher-2.0.1.win32.exe
>>> Skype4Py-1.0.32.1.win32.exe
>>> bingapi-0.02.win32.exe
>>> comtypes-0.6.1.win32.exe
>>> configobj-4.6.0.win32-py2.6.msi
>>> feedparser-4.1.win32.exe
>>> numpy-1.3.0rc2-win32-superpack-python2.6.exe
>>> py26-pysvn-svn161-1.7.0-1177.exe
>>> py2exe-0.6.9.win32-py2.6.exe
>>> pyaudiere-0.2.win32-py2.6.msi
>>> pygooglevoice-0.5.win32.exe
>>> pywin32-214.win32-py2.6.exe
>>> speech-0.5.2.win32.exe
>>> urlunshort-0.2.4.win32.exe
>>> wxPython2.9-win32-unicode-2.9.0.1.pre20100113-py26.exe
>>>
>>>
>>>
>>> On Jun 29, 2010, at 3:19 PM, Alex Hall wrote:
>>>
>>>> Yes. I just moved all .db files into a subfolder of the qwitter folder
>>>> (%appdata%\qwitter) and got the same error.
>>>>
>>>> On 6/29/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>>>>> Hi Alex,
>>>>>
>>>>> I forgot to ask you if you have tried removing your
>>>>> qwitter database file since getting your installation
>>>>> fixed.  By fixed, I mean there is no durus* file or directory
>>>>> inside your durus installation directory.
>>>>>
>>>>> On Jun 28, 2010, at 5:37 PM, Alex Hall wrote:
>>>>>
>>>>>> True, but that is not the case here; I have only one Durus directory
>>>>>> inside site-packages.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Have a great day,
>>>> Alex (msg sent from GMail website)
>>>> mehgcap <at> gmail.com; http://www.facebook.com/mehgcap
>>>
>>>
>>
>>
>> --
>> Have a great day,
>> Alex (msg sent from GMail website)
>> mehgcap <at> gmail.com; http://www.facebook.com/mehgcap
>
>

--

-- 
Have a great day,
Alex (msg sent from GMail website)
mehgcap <at> gmail.com; http://www.facebook.com/mehgcap
_______________________________________________
Durus-users mailing list
Durus-users <at> mems-exchange.org
http://mail.mems-exchange.org/mailman/listinfo/durus-users
Binger David | 30 Jun 2010 13:03

Re: apparently random bug in durus


On Jun 29, 2010, at 10:17 PM, Alex Hall wrote:

> I am not sure. Would posting this output make any sense on the Qwitter
> list? That is, would one of the devs be able to help? Q (or maybe it
> was HLLF) says he found the solution, but you said that what he found
> is not causing the problem...

What I said is that there are *two* problems.
1) The double-installation one is one of them, and I think
that is what causes the durus.durus pickle trouble that you
have seen.  I don't know what might cause the double
installation, but Q reports seeing it.
2) The other problem, which Q was incorrectly attributing
to the double-installation problem, was that record in the
database was corrupted (I think) so that it could not be
decompressed.  I don't know the reason for the corrupt record.
I think qwitter might be using one connection from multiple threads,
and if so, I think that could be the reason.  

> On Jun 25, 2010, at 6:06 PM, Q wrote:
> 
>> This issue is actually caused by something a bit more insidious.  
> 
> That's not correct. There are two different problems.  
> One is you have not installed durus properly.  How are you installing it?  
> The other is that the record would not decompress because
> it is somehow corrupted.
Alex Hall | 30 Jun 2010 15:05
Picon
Gravatar

Re: apparently random bug in durus

Oh, I see. I am not seeing a double installation, though, at least not
as far as I can tell; I only have one durus directory.

On 6/30/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>
> On Jun 29, 2010, at 10:17 PM, Alex Hall wrote:
>
>> I am not sure. Would posting this output make any sense on the Qwitter
>> list? That is, would one of the devs be able to help? Q (or maybe it
>> was HLLF) says he found the solution, but you said that what he found
>> is not causing the problem...
>
>
> What I said is that there are *two* problems.
> 1) The double-installation one is one of them, and I think
> that is what causes the durus.durus pickle trouble that you
> have seen.  I don't know what might cause the double
> installation, but Q reports seeing it.
> 2) The other problem, which Q was incorrectly attributing
> to the double-installation problem, was that record in the
> database was corrupted (I think) so that it could not be
> decompressed.  I don't know the reason for the corrupt record.
> I think qwitter might be using one connection from multiple threads,
> and if so, I think that could be the reason.
>
>
>> On Jun 25, 2010, at 6:06 PM, Q wrote:
>>
>>> This issue is actually caused by something a bit more insidious.
>>
>> That's not correct. There are two different problems.
>> One is you have not installed durus properly.  How are you installing it?
>>
>> The other is that the record would not decompress because
>> it is somehow corrupted.
>

--

-- 
Have a great day,
Alex (msg sent from GMail website)
mehgcap <at> gmail.com; http://www.facebook.com/mehgcap
Binger David | 30 Jun 2010 16:09

Re: apparently random bug in durus


>> 2) The other problem, which Q was incorrectly attributing
>> to the double-installation problem, was that record in the
>> database was corrupted (I think) so that it could not be
>> decompressed.  I don't know the reason for the corrupt record.
>> I think qwitter might be using one connection from multiple threads,
>> and if so, I think that could be the reason.

A quick look at the qwitter source code makes me think that they
are using Durus instances from the same Connection in multiple
threads.  Durus does not support that usage pattern.
Alex Hall | 1 Jul 2010 04:18
Picon
Gravatar

Re: apparently random bug in durus

Oh... Probably worth mentioning on the Qwitter list, if you do not
mind; I would, but I am not experienced enough at programming,
especially in Python, to explain things right. It is odd that only
some people experience this when running from source.

On 6/30/10, Binger David <dbinger <at> mems-exchange.org> wrote:
>
>>> 2) The other problem, which Q was incorrectly attributing
>>> to the double-installation problem, was that record in the
>>> database was corrupted (I think) so that it could not be
>>> decompressed.  I don't know the reason for the corrupt record.
>>> I think qwitter might be using one connection from multiple threads,
>>> and if so, I think that could be the reason.
>
> A quick look at the qwitter source code makes me think that they
> are using Durus instances from the same Connection in multiple
> threads.  Durus does not support that usage pattern.
>
>

--

-- 
Have a great day,
Alex (msg sent from GMail website)
mehgcap <at> gmail.com; http://www.facebook.com/mehgcap

Gmane