Error when importing ipy_vimserver.py

[Brian Granger]

I get this when trying to setup the socket server:

In [1]: import ipy_vimserver; ipy_vimserver.setup('ipython-session')
---------------------------------------------------------------------------
AttributeError Traceback (most recent call
last)

/Users/bgranger/<ipython console> in <module>()

/Users/bgranger/Documents/Computation/IPython/Code/ipython-editor-mate/
IPython/Extensions/ipy_vimserver.py in <module>()
74 import re
75
---> 76 ERRCONDS = select.POLLHUP|select.POLLERR
77 SERVER = None
78 ip = IPython.ipapi.get()

AttributeError: 'module' object has no attribute 'POLLHUP'


Any thoughts?

Brian

[Barry Wark]

I also get the same thing. OS X 10.5.5, system Python 2.5.

[Matt Foster]

That's interesting. I just borrowed a mac pro (intel, 10.5.5) from a
colleague and installed ipython 0.9.1.
I don't see any errors at all.

I can think of a couple of things to check, but I'm not sure how
helpful they'll be!

Are you running 0.9.1? I've only tried using the version of
ipy_vimserver bundled with that, and so far it's worked fine.

Is it possible that you have another module called 'select' that's
getting in the way?

Could your ipy_vimserver file be broken/corrupt somehow?

Hope this helps, and please let us know if you get anywhere!

Matt
--
Matt Foster | http://hackerific.net

[Brian Granger]

In [1]: import select

In [2]: select
Out[2]: <module 'select' from
'/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/select.so'>

In [3]: select.
select.__class__ select.__hash__ select.__repr__
select.__delattr__ select.__init__ select.__setattr__
select.__dict__ select.__name__ select.__str__
select.__doc__ select.__new__ select.error
select.__file__ select.__reduce__ select.select
select.__getattribute__ select.__reduce_ex__

Those attributes simply aren't there.

Brian

[Brian Granger]

Same thing happens from python, so it is not just ipython.

Hmmmm...

[Brian Granger]

See also this thread...

http://mail.python.org/pipermail/pythonmac-sig/2006-July/017971.html

Brian

On Wed, Nov 26, 2008 at 7:14 AM, Brian Granger <elliso...@gmail.com> wrote:

[Brian Granger]

It seems that the built-in python for leopard has a bug, that is not
present for the 2.5 build from python.org. Mark, can you confirm what
python you are using?

Brian

On Wed, Nov 26, 2008 at 1:59 AM, Matt Foster <matt.p...@gmail.com> wrote:
>

[Matt Foster]

On Wed, Nov 26, 2008 at 3:24 PM, Brian Granger <elliso...@gmail.com> wrote:
>
> It seems that the built-in python for leopard has a bug, that is not
> present for the 2.5 build from python.org. Mark, can you confirm what
> python you are using?

The mac pro I borrowed is running apple's python. I'm not in the
office atm, so I can't check the exact version, but I'll look
tomorrow.

My python is EPD's:
2.5.2 |EPD with Py2.5 4.0.30002 | (r252:60911, Oct 15 2008, 16:58:38)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)]

Both machines have intel CPUs.

[Matt Foster]

The machine at work is running EPD as well. Sorry if that caused any confusion.

I'll try and play with a vanilla version later today.

[Brian Granger]

Matt,

I am writing a nice clean twisted version of the server. My version
will work with either poll or select and will be much easier to
extend. I will create an ipython branch for this later and let you
know. But, my prototype so far works fine.

Cheers,

Brian

[Matt Foster]

On Fri, Nov 28, 2008 at 7:49 PM, Brian Granger <elliso...@gmail.com> wrote:
>
> Matt,
>
> I am writing a nice clean twisted version of the server. My version
> will work with either poll or select and will be much easier to
> extend. I will create an ipython branch for this later and let you
> know. But, my prototype so far works fine.

Brian,

That sounds like a great idea! I'm looking forward to being able to play.

I'd been thinking about attempting to extend the server to add support
for things like printing the commands to execute (like demo.py does),
but I'll hold off until it's easier!

Thanks,

[Brian Granger]

Matt,

> That sounds like a great idea! I'm looking forward to being able to play.
>
> I'd been thinking about attempting to extend the server to add support
> for things like printing the commands to execute (like demo.py does),
> but I'll hold off until it's easier!

Just a question, how much control do you have over what gets written
to the socket from the TextMate side? Could you support more
complicated protocols?

Brian

[Matt Foster]

On Fri, Nov 28, 2008 at 10:45 PM, Brian Granger <elliso...@gmail.com> wrote:
>
> Matt,
>
>> That sounds like a great idea! I'm looking forward to being able to play.
>>
>> I'd been thinking about attempting to extend the server to add support
>> for things like printing the commands to execute (like demo.py does),
>> but I'll hold off until it's easier!
>
> Just a question, how much control do you have over what gets written
> to the socket from the TextMate side? Could you support more
> complicated protocols?
>

We've got complete control over what gets written from the TM side. We
can basically run whatever scripts or code we like, so more complex
protocols wouldn't be a problem. That sounds interesting, what do you
have in mind?

I haven't yet thought of a way of making connections persistent within
TextMate though, so as it stands we reconnect to the server each time
we send lines to run. I don't know if that might cause problems.

Cheers,

[Brian Granger]

> We've got complete control over what gets written from the TM side. We
> can basically run whatever scripts or code we like, so more complex
> protocols wouldn't be a problem. That sounds interesting, what do you
> have in mind?

A couple of things:

* The current approach could fail for large blocks or files because
all the file may not be read from the socket in a single shot. It
would be better to have some way of telling IPython "OK, TM is done
sending this blocks and it should be executed now." The Easiest way
of dong this is using a simple lines based protocol where we mark each
blocks using sometag like "BLOCKBEGIN/BLOCKEND"

* Currently there is only one thing that TM can tell IPython to do:
runlines. By moving to a slightly more formal line base protocol we
could introduce additional capabilties (like access to IPython's
completion or help).

If you think this would be a good idea, I can sketch out something and
write a simple prototype so you can try it out.

> I haven't yet thought of a way of making connections persistent within
> TextMate though, so as it stands we reconnect to the server each time
> we send lines to run. I don't know if that might cause problems.

Not a problem at all actually. I wouldn't worry about it for now.

Brian

[Matt Foster]

On Sat, Nov 29, 2008 at 6:13 PM, Brian Granger <elliso...@gmail.com> wrote:
>
>> We've got complete control over what gets written from the TM side. We
>> can basically run whatever scripts or code we like, so more complex
>> protocols wouldn't be a problem. That sounds interesting, what do you
>> have in mind?
>
> A couple of things:
>
> * The current approach could fail for large blocks or files because
> all the file may not be read from the socket in a single shot. It
> would be better to have some way of telling IPython "OK, TM is done
> sending this blocks and it should be executed now." The Easiest way
> of dong this is using a simple lines based protocol where we mark each
> blocks using sometag like "BLOCKBEGIN/BLOCKEND"
>
> * Currently there is only one thing that TM can tell IPython to do:
> runlines. By moving to a slightly more formal line base protocol we
> could introduce additional capabilties (like access to IPython's
> completion or help).
>
> If you think this would be a good idea, I can sketch out something and
> write a simple prototype so you can try it out.

That all sounds good to me.

Maybe embedding the begin/end tags in comments would be a good idea, too.

Thanks for doing this,

[Barry Wark]

On Sat, Nov 29, 2008 at 10:13 AM, Brian Granger <elliso...@gmail.com> wrote:
>
>> We've got complete control over what gets written from the TM side. We
>> can basically run whatever scripts or code we like, so more complex
>> protocols wouldn't be a problem. That sounds interesting, what do you
>> have in mind?
>
> A couple of things:
>
> * The current approach could fail for large blocks or files because
> all the file may not be read from the socket in a single shot. It
> would be better to have some way of telling IPython "OK, TM is done
> sending this blocks and it should be executed now." The Easiest way
> of dong this is using a simple lines based protocol where we mark each
> blocks using sometag like "BLOCKBEGIN/BLOCKEND"
>
> * Currently there is only one thing that TM can tell IPython to do:
> runlines. By moving to a slightly more formal line base protocol we
> could introduce additional capabilties (like access to IPython's
> completion or help).
>
> If you think this would be a good idea, I can sketch out something and
> write a simple prototype so you can try it out.

I'm joining the discussion late, just coming online after a vacation,
and I haven't even had a chance to try Brian's new Twsited-based
textmate server yet, so my comments may be way off base. Why couldn't
you use EngineService API for the TextMate-IPython communication?
There's some setup overhead when using foolscap and all, but it seems
like we would gain a lot of power. Just a thought...

barry

[Brian Granger]

> I'm joining the discussion late, just coming online after a vacation,
> and I haven't even had a chance to try Brian's new Twsited-based
> textmate server yet, so my comments may be way off base. Why couldn't
> you use EngineService API for the TextMate-IPython communication?
> There's some setup overhead when using foolscap and all, but it seems
> like we would gain a lot of power. Just a thought...

In the long term, this is definitely the way to go. However, for this
case I would continue to use a Unix socket and a simpler network
protocol rather than full Foolscap protocol as security is not an
issue in this case. But, I would like to have the underlying entity
an EngineService rather than the old IPython.

The reason I haven't done this yet is that we still don't have a full
IPython that is based on EngineService.

But, you can begin to imagine where we are headed. Eventually, it
will be trivial to have the IPython core embedded everywhere and
exposed through different network protocols. It will be a happy
world.

We just need to find the time to refactor the core now :-) so that
everything can be based on the EngineService.

Brian