{5} Assigned, Active Tickets by Owner (Full Description) (21 matches)

reST is much easier to use than DocBook? and it since it is plain text it's easy to make a control for editing it. So do you know anything about DocBook?->reST convertion? I found a reST->DocBook? convertor at http://docutils.sourceforge.net/sandbox/oliverr/docbook, but I need both. I'll study some XML, DocBook? and Docutils to see if it can be done, but I have little experience in that matter.

We really need to be able to take advantage of PBs paging capabilities. But they are broken. Here is a discussions of the problems:

Overview of PB Paging =====================

There are two sides involved, the sender and the receiver.

There are three basic Twisted classes involved:

* Pager: Instantiated on sender side with reference to remote collector. * CallbackPageCollector?: Instantiated on receiver side. * Broker: Manages things on both sides.

First, a collector is created on the receiver. It has two methods::

def remote_gotPage(self, page):

self.pages.append(page)

def remote_endedPaging(self):

self.callback(self.pages)

The first methods, remote_gotPage, is called by the sender to send a page. The second, remote_endedPaging, is called by the sender when there are no more pages.

Second, the sender creates a Pager with a reference to the remote collector. This causes the Pager to be registered with the collectors broker in registerPageProducer. This appends the pager to a list of producers (pageProducers). Also, if there is exactly one pageProducer in this list, the Broker is registered as a producer with its transport.

From this point on, it is really the Producer machinery that runs the show. The main method that gets triggered is::

def resumeProducing(self):

for pageridx in xrange(len(self.pageProducers)-1, -1, -1):

pager = self.pageProducers[pageridx] pager.sendNextPage() if not pager.stillPaging():

del self.pageProducers[pageridx]

if not self.pageProducers:

self.transport.unregisterProducer()

The important thing here is the this calls sendNextPage when needed. This looks like this::

def sendNextPage(self):

self.collector.callRemote("gotPage", self.nextPage())

This is one source of dangling deferreds. These should probably be collected::

def sendNextPage(self):

d = self.collector.callRemote("gotPage", self.nextPage())

self.deferreds.append(d)

Then the stillPaging method gets called to see if the Pager still has pages. Here is that method::

def stillPaging(self):

if not self._stillPaging:

self.collector.callRemote("endedPaging") if self.callback is not None:

self.callback(*self.callbackArgs, **self.callbackKeyword)

return self._stillPaging

This calls endedPaging, which create another dangling deferred.

Currently the ipython1 configuration system uses ConfigObj? and .ini files. Fernando has completed a prototype of a higher level interface to this in sandbox/tconfig. The problem with tconfig is that it uses enthought.traits, which has C extension code. Per our new policy of keeping the ipython1 core pure python, we need to get rid of the actual usage of traits. Our thought is to build a very simple traits-like module that does 3 things:

1) validation 2) exposes configuration attributes as attributes rather than dictionaries. 3) Has events on attribute changes.

We need to make this traitslite module and then port tconfig to use it. Finally we need to write tests for tconfig and then move it into place where subpackages can begin to use it for configuration.

Hi!

In a heterogenous cluster, when only a few tasks are left, it often happens that most of the nodes are idle and wait for one or two nodes before the full job is done. This can get annoying if a very slow machine manages to receive the last task.

It would be great if the scheduler could be switched to a more aggressive setting, i.e. whenever it runs out of "fresh" tasks it would send out tasks which are already in progress to idle nodes. Whoever finishes the job first wins and all other nodes processing the same task are interrupted.

Original report:

From: "Remy X.O. Martin" <rmvsxop at gmail.com>
Date: Sat, 30 Sep 2006 15:13:24 +0200

I am embedding Python in one of my C apps, and use IPythonShellEmbed to support an interactive Python shell, using

      if( !called ){
           PyRun_SimpleString( "from IPython.Shell import IPythonShellEmbed" );
           PyRun_SimpleString( "xgraph.ipshell=IPythonShellEmbed()" );
           PyRun_SimpleString( "xgraph.ipshell.set_banner('Entering
xgraph.ipshell IPython shell')" );
           PyRun_SimpleString( "xgraph.ipshell.set_exit_msg('Leaving
xgraph.ipshell IPython shell')" );
            // Not clear if this is needed or actually does anything:
           PyRun_SimpleString( "xgraph.ipshell.restore_system_completer()" );
           called= 1;
      }

If I call this upon initialising the embedded interpreter, (some) syntax errors in user code no longer generate useful error messages:

def RedrawNow:
      return None

---------------------------------------------------------------------------
None                                      Traceback (most recent call last)


None: None

If I do *not* initialise the interactive shell, I get the usual message

def RedrawNow:
      return None

   File "<string>", line 1
     def RedrawNow:
                  ^
SyntaxError: invalid syntax

This is of course quite annoying: execution of the Python code stops at the offending statement, but there is no way to find out what that statement was.

To be honest, I don't see why IPython would become active outside an eventual call to xgraph.ipshell() as defined above...?!

End of original report.

See

http://lists.ipython.scipy.org/pipermail/ipython-dev/2006-October/002425.html

for the email report and possible replies.

Note: this is a port of issue 27 from the old roundup tracker.

Original information follows.

This bug was reported by Michael Foord <mike at pcblokes.com>, he ran into it in his moveable python project.

All the details are in this thread:

http://www.scipy.net/pipermail/ipython-user/2005-January/000624.html

Unfortunately fixing this will take a lot of architectural work, so for now I'm deferring it.

Note: this is a port of issue 2 from the old roundup tracker.

Original information follows.

Currently, unittesting with embedded ipython breaks becausea FakeModule instance overwrites __main__. Maybe python should revert back to using __main__ directly as the user namespace? Handling a separate namespace is proving very tricky in all corner cases.

Could it also be possible to add an option to log the exceptions and tracebacks in the output of logstart?

Tzanko has already added a basic description of the system to the ipython manual. For the long run, I think we should consider making the help system be a set of notebooks itself.

This way users could see the capabilities of the system by executing and modifying said notebooks. If we can get this to work well, it opens the door for all sorts of notebooks as a mechanism for distributing python-based tutorials in many fields.

Should we run the help against a separate kernel? This has pros and cons:

• It shields the user from side-effects induced by executing the help code in his own namespace.

• But the presence of two kernels may confuse some users.

In the end, I still think it's better to have a separate kernel for the help. Users can always reopen a help file in their own notebook, or copy/paste code, if they want it absorbed. This can be well explained to avoid confusion, but in the long run I think it's technically a much cleaner solution.

Currently for every class that defines __getattr__ to retrun a callable, I have to define these to work around ipython: __repr__, _getAttributeNames, __methods__, trait_names.

First three could be worked around by disallowing underscore names in __getattr__, but there's hardly any generic logic that could exclude trait_names.

I think that if ipython thinks my object might be trait-able (whatever that is) it should first interrogate some underscore method or type or something else.

In any event ipython cannot arbitratily call an innocently named method like trait_names() because ipython doesn't know what side effects that might cause.

Example:

# usage:
# server = rpc_caller("http://....")
# rv = server.get_customer_info(arg1, arg2, ...)

class rpc_caller:
  def __init__(self, base):
    self.base = base

  def __getattr__(self, name):
    return lambda *args, **kwargs: do_rpc_call(self.base, name, args, kwargs)

# initialize some caller
rpc = rpc_caller("http://...")

after this, tab-expansion in ipython results in aweful side-effects, because ipython eventually calls rpc.trait_names() which the system is completely unprepared for.

also globals() may fail with exception

another case where this caused a serious bug for me was when __getattr__ returned a gtk widget

last checked against ipython 0.8.1