From takowl at gmail.com Wed Jun 1 05:26:54 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 1 Jun 2011 10:26:54 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 1 June 2011 04:33, Brian Granger wrote: > * Moving away from ipython.scipy.org to simply ipython.org > This makes sense. I understand we can easily create a CNAME if we're hosting the site using Github pages. > * Using sphinx for the entire site as matplotlib does. > This I'm less sure about. Sphinx is great for documentation, but I don't think it works so well for a whole website: * The layout is really geared towards writing documentation. * With so many projects now using Sphinx for docs, people instantly recognise the layout and think 'docs'. Whenever I go to matplotlib's website, I have this feeling that I've missed the homepage somewhere and skipped straight to the docs. * We'll want to update parts of the website fairly often. If every small change requires the site to be checked out as source, rebuilt by Sphinx (with all its dependencies) and reuploaded, the site's just going to get out of date. > * Moving the wiki stuff over to github. > Again, this makes sense. I take it we're talking about turning on the wiki feature in Github, rather than just moving the content into github pages? I think the key thing is to work out how we want to divide content between: - Documentation - A wiki - A landing page (or a small collection of pages) Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Wed Jun 1 05:31:26 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 1 Jun 2011 10:31:26 +0100 Subject: [IPython-dev] %edit magic in new frontends In-Reply-To: References: Message-ID: On 1 June 2011 04:37, Brian Granger wrote: > * I vote that the -x flag be removed completely. Edit should just edit. This is already done in code - the -x flag isn't accepted when calling %edit in a ZMQ shell. It just hasn't been removed from the docstring yet. Or do you mean that the single process terminal frontend shouldn't execute code after editing? Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From harry at resolversystems.com Wed Jun 1 05:48:48 2011 From: harry at resolversystems.com (Harry Percival) Date: Wed, 01 Jun 2011 10:48:48 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: <4DE60B00.7020804@resolversystems.com> Hi all, we've been lurking on the list for a few weeks. We hope to have IPython support in PythonAnywhere in the next week or two. If you guys are keen, we could probably serve up a "try it now" iframe, with a live IPython interpreter for people to use, straight from your site... Here's a screenshot by way of a teaser. All nice colours, tab completion works... We'd probably need a couple more experience IPython users to beta test though? more info here: http://www.pythonanywhere.com/ rgds, Harry -- Harry Percival Developer harry at resolversystems.com +44 (0) 20 3051 2751 PythonAnywhere: a Python console in your browser 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK On 01/06/2011 10:26, Thomas Kluyver wrote: > On 1 June 2011 04:33, Brian Granger > wrote: > > * Moving away from ipython.scipy.org to > simply ipython.org > > > This makes sense. I understand we can easily create a CNAME if we're > hosting the site using Github pages. > > * Using sphinx for the entire site as matplotlib does. > > > This I'm less sure about. Sphinx is great for documentation, but I > don't think it works so well for a whole website: > > * The layout is really geared towards writing documentation. > * With so many projects now using Sphinx for docs, people instantly > recognise the layout and think 'docs'. Whenever I go to matplotlib's > website, I have this feeling that I've missed the homepage somewhere > and skipped straight to the docs. > * We'll want to update parts of the website fairly often. If every > small change requires the site to be checked out as source, rebuilt by > Sphinx (with all its dependencies) and reuploaded, the site's just > going to get out of date. > > * Moving the wiki stuff over to github. > > > Again, this makes sense. I take it we're talking about turning on the > wiki feature in Github, rather than just moving the content into > github pages? > > I think the key thing is to work out how we want to divide content > between: > - Documentation > - A wiki > - A landing page (or a small collection of pages) > > Thanks, > Thomas > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- Harry Percival Developer harry at resolversystems.com +44 (0) 20 3051 2751 Dirigible: a Python cloud spreadsheet 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From harry at resolversystems.com Wed Jun 1 05:56:01 2011 From: harry at resolversystems.com (Harry Percival) Date: Wed, 01 Jun 2011 10:56:01 +0100 Subject: [IPython-dev] Website In-Reply-To: <4DE60B00.7020804@resolversystems.com> References: <4DE60B00.7020804@resolversystems.com> Message-ID: <4DE60CB1.8090306@resolversystems.com> oops, and here's the screenshot. On 01/06/2011 10:48, Harry Percival wrote: > Hi all, > > we've been lurking on the list for a few weeks. We hope to have > IPython support in PythonAnywhere in the next week or two. If you > guys are keen, we could probably serve up a "try it now" iframe, with > a live IPython interpreter for people to use, straight from your site... > > Here's a screenshot by way of a teaser. All nice colours, tab > completion works... We'd probably need a couple more experience > IPython users to beta test though? > > more info here: http://www.pythonanywhere.com/ > > rgds, > Harry > > -- > Harry Percival > Developer > harry at resolversystems.com > +44 (0) 20 3051 2751 > > PythonAnywhere: a Python console in your browser > > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > > On 01/06/2011 10:26, Thomas Kluyver wrote: >> On 1 June 2011 04:33, Brian Granger > > wrote: >> >> * Moving away from ipython.scipy.org >> to simply ipython.org >> >> >> This makes sense. I understand we can easily create a CNAME if we're >> hosting the site using Github pages. >> >> * Using sphinx for the entire site as matplotlib does. >> >> >> This I'm less sure about. Sphinx is great for documentation, but I >> don't think it works so well for a whole website: >> >> * The layout is really geared towards writing documentation. >> * With so many projects now using Sphinx for docs, people instantly >> recognise the layout and think 'docs'. Whenever I go to matplotlib's >> website, I have this feeling that I've missed the homepage somewhere >> and skipped straight to the docs. >> * We'll want to update parts of the website fairly often. If every >> small change requires the site to be checked out as source, rebuilt >> by Sphinx (with all its dependencies) and reuploaded, the site's just >> going to get out of date. >> >> * Moving the wiki stuff over to github. >> >> >> Again, this makes sense. I take it we're talking about turning on the >> wiki feature in Github, rather than just moving the content into >> github pages? >> >> I think the key thing is to work out how we want to divide content >> between: >> - Documentation >> - A wiki >> - A landing page (or a small collection of pages) >> >> Thanks, >> Thomas >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- > Harry Percival > Developer > harry at resolversystems.com > +44 (0) 20 3051 2751 > > Dirigible: a Python cloud spreadsheet > > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK -- Harry Percival Developer harry at resolversystems.com +44 (0) 20 3051 2751 Dirigible: a Python cloud spreadsheet 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pythonanywhere_ipython_screenshot.PNG Type: image/png Size: 78855 bytes Desc: not available URL: From takowl at gmail.com Wed Jun 1 07:38:05 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 1 Jun 2011 12:38:05 +0100 Subject: [IPython-dev] Website In-Reply-To: <4DE60B00.7020804@resolversystems.com> References: <4DE60B00.7020804@resolversystems.com> Message-ID: On 1 June 2011 10:48, Harry Percival wrote: > we've been lurking on the list for a few weeks. We hope to have IPython > support in PythonAnywhere in the next week or two. If you guys are keen, we > could probably serve up a "try it now" iframe, with a live IPython > interpreter for people to use, straight from your site... Personally, I love the idea of a 'try it now' feature: its hard to give a good impression of an interactive environment using screenshots. My main concern would be to what extent it's actually IPython we're demoing. We don't currently have a web-based console, so I assume you've written a lot of your own code for the user interaction. On the one hand, we don't want people getting a poor impression due to the limitations of the web browser, or due to flaws in code we can't correct (not that I expect your code to be bad, but all non-trivial software has bugs). On the other hand, if you've added extra features, we don't want the demo to promise something we can't deliver on the desktop. In short, if we do this, what we show needs to be as 'pure IPython' as possible. Other thoughts: - Are you basing it on IPython 0.10.x (the current stable version), or 0.11 (the version we'll release soon)? - I assume your console will run in any modern web browser? It's not going to display an 'install Silverlight' button, like certain alternatives, is it? ;-) - I'm guessing your parts of the code are proprietary. I don't have a problem with that, but I honestly don't know whether it could stir up feelings if we're seen as promoting your business. I hope more people will chime in on this as it reaches a civilised time in their own time zones. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From harry at resolversystems.com Wed Jun 1 08:21:43 2011 From: harry at resolversystems.com (Harry Percival) Date: Wed, 01 Jun 2011 13:21:43 +0100 Subject: [IPython-dev] Website In-Reply-To: References: <4DE60B00.7020804@resolversystems.com> Message-ID: <4DE62ED7.1020501@resolversystems.com> Thanks Thomas, those are all very reasonable concerns. The beta is still in very early stages, so it may still be a little too buggy to be great promotion - in particular, it's rather sluggish at the moment, so probably not ready for public consumption. In terms of displaying "pure" IPython though, I think we should be quite close - we haven't really built in any bells and whistles over and above what you'd find in a normal local terminal session. Best thing is probably to take a look for yourselves! When you sign up, you'll get an automated email from us with a few questions. If you mention in your answers that you're on the ipython list, we'll bump you up the queue for invites. It's always good to have demanding users! rgds, Harry On 01/06/2011 12:38, Thomas Kluyver wrote: > On 1 June 2011 10:48, Harry Percival > wrote: > > we've been lurking on the list for a few weeks. We hope to have > IPython support in PythonAnywhere in the next week or two. If you > guys are keen, we could probably serve up a "try it now" iframe, > with a live IPython interpreter for people to use, straight from > your site... > > > Personally, I love the idea of a 'try it now' feature: its hard to > give a good impression of an interactive environment using screenshots. > > My main concern would be to what extent it's actually IPython we're > demoing. We don't currently have a web-based console, so I assume > you've written a lot of your own code for the user interaction. On the > one hand, we don't want people getting a poor impression due to the > limitations of the web browser, or due to flaws in code we can't > correct (not that I expect your code to be bad, but all non-trivial > software has bugs). On the other hand, if you've added extra features, > we don't want the demo to promise something we can't deliver on the > desktop. In short, if we do this, what we show needs to be as 'pure > IPython' as possible. > > Other thoughts: > - Are you basing it on IPython 0.10.x (the current stable version), or > 0.11 (the version we'll release soon)? > - I assume your console will run in any modern web browser? It's not > going to display an 'install Silverlight' button, like certain > alternatives , is it? ;-) > - I'm guessing your parts of the code are proprietary. I don't have a > problem with that, but I honestly don't know whether it could stir up > feelings if we're seen as promoting your business. > > I hope more people will chime in on this as it reaches a civilised > time in their own time zones. > > Thanks, > Thomas -- Harry Percival Developer harry at resolversystems.com +44 (0) 20 3051 2751 Dirigible: a Python cloud spreadsheet 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Wed Jun 1 08:59:13 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 1 Jun 2011 13:59:13 +0100 Subject: [IPython-dev] Website In-Reply-To: <4DE62ED7.1020501@resolversystems.com> References: <4DE60B00.7020804@resolversystems.com> <4DE62ED7.1020501@resolversystems.com> Message-ID: On 1 June 2011 13:21, Harry Percival wrote: > Best thing is probably to take a look for yourselves! > I've now got an invite and had a quick look. It's an interesting approach, quite different to what we're doing with the new frontends for IPython 0.11. They are actually emulating a terminal in the browser, to the point that you can run nano inside it (I'm impressed!). The upside of that is that you get essentially kosher terminal IPython. The downside is that there is, as Harry mentioned, a bit of lag. It seems to be sending every keystroke to the server before displaying it, so there's a noticeable gap between pressing a key and seeing it appear. I assume they're planning to improve that before it goes public. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason-sage at creativetrax.com Wed Jun 1 09:20:56 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Wed, 01 Jun 2011 08:20:56 -0500 Subject: [IPython-dev] pyzmq authentication In-Reply-To: References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> Message-ID: <4DE63CB8.7090108@creativetrax.com> On 5/31/11 10:07 PM, Brian Granger wrote: > Jason, > > The other thing to consider is that the main frontend that will need > security is the html notebook. For that, we do plan on having HTTPS > enabled by default. Yes, I agree that's a concern. Jason From jason-sage at creativetrax.com Wed Jun 1 09:40:31 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Wed, 01 Jun 2011 08:40:31 -0500 Subject: [IPython-dev] pyzmq authentication In-Reply-To: References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> Message-ID: <4DE6414F.3070002@creativetrax.com> On 5/31/11 1:45 PM, MinRK wrote: > On Tue, May 31, 2011 at 11:13, Jason Grout wrote: >> On 5/31/11 12:57 PM, MinRK wrote: >>> >>> We did briefly have an encrypted socket, but the zeromq community >>> rightly opposed that rather vehemently, largely because we aren't >>> security experts, and the illusion of security provided by a poor >>> implementation is really *less* secure than having no security at all. >>> >>> Our answer with IPython is that SSH provides our security. Typically >>> the Controller listens on localhost, and the best way to connect to it >>> from another machine is with an SSH tunnel (IPython does help create >>> the tunnels) rather than listening on a public port. We do provide a >>> small level of additional security by including an authentication key >>> in all messages that is checked when receiving to determine if the >>> sender is authorized to make a request. >> >> If I understand things correctly, if I have several frontends running code >> on a single backend server (with multiple kernels---the sage notebook is my >> usecase), then untrusted code from any of the kernels could connect to and >> mess with the other sessions, right? Is it correct to say that any user >> could connect with any kernel running on the same server? > > Oh, you are talking about the *non* parallel kernel. Yes, that code > has exactly zero security - anyone with access to the sockets can > execute arbitrary code. We really do need to replace > IPython.zmq.session with the one in the parallel code which does > include simple key checking, which should be per-kernel (or > per-cluster in the parallel code). I think simple key-checking is what I was talking about. Do you mean something equivalent to the Authentication Keys section of the multiprocessing module docs [1]? Basically, I pass in a shared secret as an argument when I start the kernel, and then the pyzmq connection is authenticated with this secret without transmitting the secret. Thanks, Jason [1] http://docs.python.org/dev/library/multiprocessing#authentication-keys From benjaminrk at gmail.com Wed Jun 1 12:41:55 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 1 Jun 2011 09:41:55 -0700 Subject: [IPython-dev] pyzmq authentication In-Reply-To: <4DE6414F.3070002@creativetrax.com> References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> Message-ID: On Wed, Jun 1, 2011 at 06:40, Jason Grout wrote: > On 5/31/11 1:45 PM, MinRK wrote: >> >> On Tue, May 31, 2011 at 11:13, Jason Grout >> ?wrote: >>> >>> On 5/31/11 12:57 PM, MinRK wrote: >>>> >>>> We did briefly have an encrypted socket, but the zeromq community >>>> rightly opposed that rather vehemently, largely because we aren't >>>> security experts, and the illusion of security provided by a poor >>>> implementation is really *less* secure than having no security at all. >>>> >>>> Our answer with IPython is that SSH provides our security. ?Typically >>>> the Controller listens on localhost, and the best way to connect to it >>>> from another machine is with an SSH tunnel (IPython does help create >>>> the tunnels) rather than listening on a public port. ?We do provide a >>>> small level of additional security by including an authentication key >>>> in all messages that is checked when receiving to determine if the >>>> sender is authorized to make a request. >>> >>> If I understand things correctly, if I have several frontends running >>> code >>> on a single backend server (with multiple kernels---the sage notebook is >>> my >>> usecase), then untrusted code from any of the kernels could connect to >>> and >>> mess with the other sessions, right? ?Is it correct to say that any user >>> could connect with any kernel running on the same server? >> >> Oh, you are talking about the *non* parallel kernel. ?Yes, that code >> has exactly zero security - anyone with access to the sockets can >> execute arbitrary code. ?We really do need to replace >> IPython.zmq.session with the one in the parallel code which does >> include simple key checking, which should be per-kernel (or >> per-cluster in the parallel code). > > > I think simple key-checking is what I was talking about. ?Do you mean > something equivalent to the Authentication Keys section of the > multiprocessing module docs [1]? ?Basically, I pass in a shared secret as an > argument when I start the kernel, and then the pyzmq connection is > authenticated with this secret without transmitting the secret. What we have currently is extremely primitive, and only meant to protect against accidental execution rather than malicious intrusion. The key is sent and checked with every message. Handshaking is particularly complicated with zeromq since it's connectionless, but I think applying it just to the execution socket is doable, though it's actually impossible on the other sockets as they are. -MinRK > > Thanks, > > Jason > > [1] http://docs.python.org/dev/library/multiprocessing#authentication-keys > From fperez.net at gmail.com Wed Jun 1 14:20:30 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 1 Jun 2011 11:20:30 -0700 Subject: [IPython-dev] pyzmq authentication In-Reply-To: References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> Message-ID: On Wed, Jun 1, 2011 at 9:41 AM, MinRK wrote: > What we have currently is extremely primitive, and only meant to > protect against accidental execution rather than > malicious intrusion. The key is sent and checked with every message. If I understand correctly the link Jason sent, and from a quick reading of the multiprocessing code, we should be able to use the same machinery to avoid sending/receving the keys. The main functions that do the work in MP are in the 'connection' submodule, and they are really two standalone functions: def deliver_challenge(connection, authkey): import hmac assert isinstance(authkey, bytes) message = os.urandom(MESSAGE_LENGTH) connection.send_bytes(CHALLENGE + message) digest = hmac.new(authkey, message).digest() response = connection.recv_bytes(256) # reject large message if response == digest: connection.send_bytes(WELCOME) else: connection.send_bytes(FAILURE) raise AuthenticationError('digest received was wrong') def answer_challenge(connection, authkey): import hmac assert isinstance(authkey, bytes) message = connection.recv_bytes(256) # reject large message assert message[:len(CHALLENGE)] == CHALLENGE, 'message = %r' % message message = message[len(CHALLENGE):] digest = hmac.new(authkey, message).digest() connection.send_bytes(digest) response = connection.recv_bytes(256) # reject large message if response != WELCOME: raise AuthenticationError('digest sent was rejected') They work with objects that have a basic socket interface, but adapting this to zmq sockets should be possible. Am I missing something? Cheers, f From benjaminrk at gmail.com Wed Jun 1 14:33:33 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 1 Jun 2011 11:33:33 -0700 Subject: [IPython-dev] pyzmq authentication In-Reply-To: References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> Message-ID: On Wed, Jun 1, 2011 at 11:20, Fernando Perez wrote: > On Wed, Jun 1, 2011 at 9:41 AM, MinRK wrote: >> What we have currently is extremely primitive, and only meant to >> protect against accidental execution rather than >> malicious intrusion. The key is sent and checked with every message. > > If I understand correctly the link Jason sent, and from a quick > reading of the multiprocessing code, we should be able to use the same > machinery to avoid sending/receving the keys. ?The main functions that > do the work in MP are in the 'connection' submodule, and they are > really two standalone functions: > > def deliver_challenge(connection, authkey): > ? ?import hmac > ? ?assert isinstance(authkey, bytes) > ? ?message = os.urandom(MESSAGE_LENGTH) > ? ?connection.send_bytes(CHALLENGE + message) > ? ?digest = hmac.new(authkey, message).digest() > ? ?response = connection.recv_bytes(256) ? ? ? ?# reject large message > ? ?if response == digest: > ? ? ? ?connection.send_bytes(WELCOME) > ? ?else: > ? ? ? ?connection.send_bytes(FAILURE) > ? ? ? ?raise AuthenticationError('digest received was wrong') > > def answer_challenge(connection, authkey): > ? ?import hmac > ? ?assert isinstance(authkey, bytes) > ? ?message = connection.recv_bytes(256) ? ? ? ? # reject large message > ? ?assert message[:len(CHALLENGE)] == CHALLENGE, 'message = %r' % message > ? ?message = message[len(CHALLENGE):] > ? ?digest = hmac.new(authkey, message).digest() > ? ?connection.send_bytes(digest) > ? ?response = connection.recv_bytes(256) ? ? ? ?# reject large message > ? ?if response != WELCOME: > ? ? ? ?raise AuthenticationError('digest sent was rejected') > > > They work with objects that have a basic socket interface, but > adapting this to zmq sockets should be possible. ?Am I missing > something? We have 3 main channels: Shell (XREQ-XREP) Stdin (XREQ-XREQ) (I think?) IOPub (PUB-SUB) Of these, *only* the XREP can authenticate connections. The reason is that none of the other sockets actually know where messages came from, so there's no mechanism for seeing if the sender previously had a successful handshake because you actually have no idea who the sender was. Even the client's XREQ socket cannot authenticate replies, it must trust that the replies are coming from the kernel. That said, the only easy one is the one that is the most important - the Kernel checking requests prior to execution. However, if you have someone sniffing on the line, it's trivial to spoof an authenticated socket - just copy the IDENT, which is sent in the clear over the wire, and the kernel will have exactly no idea that you aren't the original authenticated client. ZMQ has no mechanism for dropping connections (because it has no public notion of connections), so a one-time authenticated connection essentially turns your one key into a set of keys (the socket identities), which are still sent over the wire in exactly the same fashion as the key is now, and just as vulnerable as sending the key in the clear, except now you have more of them. -MinRK > > Cheers, > > f > From ellisonbg at gmail.com Wed Jun 1 16:06:28 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 1 Jun 2011 13:06:28 -0700 Subject: [IPython-dev] %edit magic in new frontends In-Reply-To: References: Message-ID: On Wed, Jun 1, 2011 at 2:31 AM, Thomas Kluyver wrote: > On 1 June 2011 04:37, Brian Granger wrote: >> >> * I vote that the -x flag be removed completely. ?Edit should just edit. > > This is already done in code - the -x flag isn't accepted when calling %edit > in a ZMQ shell. It just hasn't been removed from the docstring yet. > > Or do you mean that the single process terminal frontend shouldn't execute > code after editing? Yes, I have always found it confusing that "edit" actually meant "edit and run" in the terminal. Cheers, Brian > Thomas > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Wed Jun 1 16:32:58 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 1 Jun 2011 13:32:58 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: Hi Thomas, On Wed, Jun 1, 2011 at 2:26 AM, Thomas Kluyver wrote: > > This makes sense. I understand we can easily create a CNAME if we're hosting > the site using Github pages. > >> >> * Using sphinx for the entire site as matplotlib does. > > This I'm less sure about. Sphinx is great for documentation, but I don't > think it works so well for a whole website: > > * The layout is really geared towards writing documentation. > * With so many projects now using Sphinx for docs, people instantly > recognise the layout and think 'docs'. Whenever I go to matplotlib's > website, I have this feeling that I've missed the homepage somewhere and > skipped straight to the docs. > * We'll want to update parts of the website fairly often. If every small > change requires the site to be checked out as source, rebuilt by Sphinx > (with all its dependencies) and reuploaded, the site's just going to get out > of date. Mmh, I actually think that sphinx is a good choice, given your points above. Hear me out: - layout: that's just a matter of theming, and a small amount of theme/template work (that would need to be done anyway for any site) can make a sphinx-based site look completely different. - updates: I update my site (sphinx-based: http://fperez.org) with a simple make upload that runs 'make html' and then rsyncs the content up. I actually find that to be the easiest way to do it, since it reuses the tools I already use for everything else (make, git, sphinx, rsync). I *really* want the website content to be under version control, and also to be written in reST instead of hand-coded html (except possibly for a few visually key pages like the main page, if necessary). If it's in simple reST we're much more likely to actually keep it updated than if we have to hand-edit html, which I find fairly unpleasant. One of the things that I sadly let fall through the cracks when I came back from India, was that Komal (CC'd here), one of the students who participated in the IPython sprints, did make headway into this problem already: https://github.com/komal2608/ipython-website She took my advice of porting our existing content to sphinx and got things going, and unfortunately upon my return I never followed up on this (my apology, BTW). I haven't had a chance to review it yet, but that was done based on the plan of building with sphinx from our existing content on the moin wiki. >> * Moving the wiki stuff over to github. > > Again, this makes sense. I take it we're talking about turning on the wiki > feature in Github, rather than just moving the content into github pages? I think the main site shouldn't *be* a wiki, but that we should *have* a wiki. A wiki is good for certain things, and having one will be good. The github one may be OK, I haven't actually used it. Other things equal, github will win on the grounds of good tool reuse. > I think the key thing is to work out how we want to divide content between: > - Documentation > - A wiki > - A landing page (or a small collection of pages) I think the landing page should be visually very good (and I'm awful at that), and then we should have a few pages for specific areas of content that don't need to be in the manuals themselves. But I suspect with a bit of sphinx theming, all those could be done nicely in reST, leaving the wiki for community-edited material and the manual for full-on docs. Cheers, f From fperez.net at gmail.com Wed Jun 1 16:35:37 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 1 Jun 2011 13:35:37 -0700 Subject: [IPython-dev] %edit magic in new frontends In-Reply-To: References: Message-ID: On Wed, Jun 1, 2011 at 1:06 PM, Brian Granger wrote: > Yes, I have always found it confusing that "edit" actually meant "edit > and run" in the terminal. Let's not completely change this, though: while we can debate whether it was the right original choice for me to have made years ago, and I actually don't ever use %edit myself, I've seen (and received email feedback) about people who *only* use ipython this way, and who rely on this behavior as their natural workflow. I think that if we find glaring problems in our design we should definitely fix them and break backwards compatibility, but we should also give some consideration to the weight of habit that has been built in the worfklows of many people who may not necessarily be vocal on our -dev list. Cheers, f From jason-sage at creativetrax.com Wed Jun 1 19:04:55 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Wed, 01 Jun 2011 18:04:55 -0500 Subject: [IPython-dev] pyzmq authentication In-Reply-To: References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> Message-ID: <4DE6C597.1020201@creativetrax.com> On 6/1/11 1:33 PM, MinRK wrote: > On Wed, Jun 1, 2011 at 11:20, Fernando Perez wrote: >> On Wed, Jun 1, 2011 at 9:41 AM, MinRK wrote: >>> What we have currently is extremely primitive, and only meant to >>> protect against accidental execution rather than >>> malicious intrusion. The key is sent and checked with every message. >> >> If I understand correctly the link Jason sent, and from a quick >> reading of the multiprocessing code, we should be able to use the same >> machinery to avoid sending/receving the keys. The main functions that >> do the work in MP are in the 'connection' submodule, and they are >> really two standalone functions: >> >> def deliver_challenge(connection, authkey): >> import hmac >> assert isinstance(authkey, bytes) >> message = os.urandom(MESSAGE_LENGTH) >> connection.send_bytes(CHALLENGE + message) >> digest = hmac.new(authkey, message).digest() >> response = connection.recv_bytes(256) # reject large message >> if response == digest: >> connection.send_bytes(WELCOME) >> else: >> connection.send_bytes(FAILURE) >> raise AuthenticationError('digest received was wrong') >> >> def answer_challenge(connection, authkey): >> import hmac >> assert isinstance(authkey, bytes) >> message = connection.recv_bytes(256) # reject large message >> assert message[:len(CHALLENGE)] == CHALLENGE, 'message = %r' % message >> message = message[len(CHALLENGE):] >> digest = hmac.new(authkey, message).digest() >> connection.send_bytes(digest) >> response = connection.recv_bytes(256) # reject large message >> if response != WELCOME: >> raise AuthenticationError('digest sent was rejected') >> >> >> They work with objects that have a basic socket interface, but >> adapting this to zmq sockets should be possible. Am I missing >> something? > > We have 3 main channels: > Shell (XREQ-XREP) > Stdin (XREQ-XREQ) (I think?) > IOPub (PUB-SUB) > > Of these, *only* the XREP can authenticate connections. The reason is > that none of the other sockets actually know where messages came from, > so there's no mechanism for seeing if the sender previously had a > successful handshake because you actually have no idea who the sender > was. > > Even the client's XREQ socket cannot authenticate replies, it must > trust that the replies are coming from the kernel. > > That said, the only easy one is the one that is the most important - > the Kernel checking requests prior to execution. However, if you have > someone sniffing on the line, it's trivial to spoof an authenticated > socket - just copy the IDENT, which is sent in the clear over the > wire, and the kernel will have exactly no idea that you aren't the > original authenticated client. If we don't have the concept of connection, then maybe we can authenticate each request by "signing" the requests. For example, we could send a hash of the concatenation of the shared secret and the content of the message. So a message would look like: (signature, json_message) The receiving code would then do the same process: concatenate the bytes in json_message, right off the wire, with the shared secret, do the same hash, and check the signature. This would provide some assurance that whoever sent the message knew the shared secret. Another thing we could do for a sequence of messages is to always increment a sequence number appended to the shared secret before sending the message, and send the hash of the shared secret + sequence number. This provides a series of keys, but each is a one-time key (the receiver tracks the sequence number, so it can ignore people that try to reuse these hashes). Jason From benjaminrk at gmail.com Wed Jun 1 19:26:45 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 1 Jun 2011 16:26:45 -0700 Subject: [IPython-dev] pyzmq authentication In-Reply-To: <4DE6C597.1020201@creativetrax.com> References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> <4DE6C597.1020201@creativetrax.com> Message-ID: On Wed, Jun 1, 2011 at 16:04, Jason Grout wrote: > On 6/1/11 1:33 PM, MinRK wrote: >> >> On Wed, Jun 1, 2011 at 11:20, Fernando Perez ?wrote: >>> >>> On Wed, Jun 1, 2011 at 9:41 AM, MinRK ?wrote: >>>> >>>> What we have currently is extremely primitive, and only meant to >>>> protect against accidental execution rather than >>>> malicious intrusion. The key is sent and checked with every message. >>> >>> If I understand correctly the link Jason sent, and from a quick >>> reading of the multiprocessing code, we should be able to use the same >>> machinery to avoid sending/receving the keys. ?The main functions that >>> do the work in MP are in the 'connection' submodule, and they are >>> really two standalone functions: >>> >>> def deliver_challenge(connection, authkey): >>> ? ?import hmac >>> ? ?assert isinstance(authkey, bytes) >>> ? ?message = os.urandom(MESSAGE_LENGTH) >>> ? ?connection.send_bytes(CHALLENGE + message) >>> ? ?digest = hmac.new(authkey, message).digest() >>> ? ?response = connection.recv_bytes(256) ? ? ? ?# reject large message >>> ? ?if response == digest: >>> ? ? ? ?connection.send_bytes(WELCOME) >>> ? ?else: >>> ? ? ? ?connection.send_bytes(FAILURE) >>> ? ? ? ?raise AuthenticationError('digest received was wrong') >>> >>> def answer_challenge(connection, authkey): >>> ? ?import hmac >>> ? ?assert isinstance(authkey, bytes) >>> ? ?message = connection.recv_bytes(256) ? ? ? ? # reject large message >>> ? ?assert message[:len(CHALLENGE)] == CHALLENGE, 'message = %r' % message >>> ? ?message = message[len(CHALLENGE):] >>> ? ?digest = hmac.new(authkey, message).digest() >>> ? ?connection.send_bytes(digest) >>> ? ?response = connection.recv_bytes(256) ? ? ? ?# reject large message >>> ? ?if response != WELCOME: >>> ? ? ? ?raise AuthenticationError('digest sent was rejected') >>> >>> >>> They work with objects that have a basic socket interface, but >>> adapting this to zmq sockets should be possible. ?Am I missing >>> something? >> >> We have 3 main channels: >> Shell (XREQ-XREP) >> Stdin (XREQ-XREQ) (I think?) >> IOPub (PUB-SUB) >> >> Of these, *only* the XREP can authenticate connections. ?The reason is >> that none of the other sockets actually know where messages came from, >> so there's no mechanism for seeing if the sender previously had a >> successful handshake because you actually have no idea who the sender >> was. >> >> Even the client's XREQ socket cannot authenticate replies, it must >> trust that the replies are coming from the kernel. >> >> That said, the only easy one is the one that is the most important - >> the Kernel checking requests prior to execution. However, if you have >> someone sniffing on the line, it's trivial to spoof an authenticated >> socket - just copy the IDENT, which is sent in the clear over the >> wire, and the kernel will have exactly no idea that you aren't the >> original authenticated client. > > > If we don't have the concept of connection, then maybe we can authenticate > each request by "signing" the requests. ?For example, we could send a hash > of the concatenation of the shared secret and the content of the message. > ?So a message would look like: > > (signature, json_message) > > The receiving code would then do the same process: concatenate the bytes in > json_message, right off the wire, with the shared secret, do the same hash, > and check the signature. ?This would provide some assurance that whoever > sent the message knew the shared secret. I don't see a reason why this wouldn't work. If we don't have one-time keys, then there's nothing preventing sniffers from resubmitting the *same* message, though it would protect against arbitrary code. The only disadvantage is that you are digesting potentially large messages, but that's the way it goes. > > Another thing we could do for a sequence of messages is to always increment > a sequence number appended to the shared secret before sending the message, > and send the hash of the shared secret + sequence number. This provides a > series of keys, but each is a one-time key (the receiver tracks the sequence > number, so it can ignore people that try to reuse these hashes). With multiple clients, there would need to be a counter *per client*, since each client doesn't know how many messages the other clients are sending. > > Jason > > From jason-sage at creativetrax.com Wed Jun 1 19:35:17 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Wed, 01 Jun 2011 18:35:17 -0500 Subject: [IPython-dev] pyzmq authentication In-Reply-To: <4DE6C597.1020201@creativetrax.com> References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> <4DE6C597.1020201@creativetrax.com> Message-ID: <4DE6CCB5.5080706@creativetrax.com> On 6/1/11 6:04 PM, Jason Grout wrote: > For example, we > could send a hash of the concatenation of the shared secret and the > content of the message. Of course, as aptly stated by khrafra [1] and many others, it's always better to use the prebuilt libraries to do signing. Here are two standard modules that could do authentication: Standard Python module: http://docs.python.org/library/hmac.html Google Keyczar: http://www.keyczar.org/ Thanks, Jason [1] http://www.reddit.com/r/netsec/comments/attt2/dont_hash_secrets/c0jdilj : Haha.. you fool! You fell victim to one of the classic blunders. The most famous is: Never get involved in a land war in Asia. But only slightly less famous is this: Never attempt to roll your own crypto when there's a well-tested library that'll do it better! From benjaminrk at gmail.com Wed Jun 1 19:42:49 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 1 Jun 2011 16:42:49 -0700 Subject: [IPython-dev] pyzmq authentication In-Reply-To: <4DE6CCB5.5080706@creativetrax.com> References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> <4DE6C597.1020201@creativetrax.com> <4DE6CCB5.5080706@creativetrax.com> Message-ID: On Wed, Jun 1, 2011 at 16:35, Jason Grout wrote: > On 6/1/11 6:04 PM, Jason Grout wrote: >> For example, we >> could send a hash of the concatenation of the shared secret and the >> content of the message. > > Of course, as aptly stated by khrafra [1] and many others, it's always > better to use the prebuilt libraries to do signing. ?Here are two > standard modules that could do authentication: Certainly true. I've already started writing the signing code with hmac, but I have to run and meet some ZeroMQ folks in San Francisco. I should probably have a sample up tomorrow. > > Standard Python module: http://docs.python.org/library/hmac.html > > Google Keyczar: http://www.keyczar.org/ > > Thanks, > > Jason > > > [1] > http://www.reddit.com/r/netsec/comments/attt2/dont_hash_secrets/c0jdilj > : Haha.. you fool! You fell victim to one of the classic blunders. The > most famous is: Never get involved in a land war in Asia. But only > slightly less famous is this: Never attempt to roll your own crypto when > there's a well-tested library that'll do it better! > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From takowl at gmail.com Thu Jun 2 05:57:00 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 2 Jun 2011 10:57:00 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 1 June 2011 21:32, Fernando Perez wrote: > I *really* want the website content to be under version control, and > also to be written in reST instead of hand-coded html (except possibly > for a few visually key pages like the main page, if necessary). If > it's in simple reST we're much more likely to actually keep it updated > than if we have to hand-edit html, which I find fairly unpleasant. > I think in fact we're saying the same thing, but from two different angles. I'm not suggesting we write reams of content in straight HTML. Sphinx/RST is the right tool for the bulk of the stuff, augmented with a wiki for the more changeable stuff. But, as you say, a couple of key pages - certainly the landing page, and perhaps also the download page - need to be visually attractive. I think this is going to be easier to achieve by designing them in HTML than by trying to hammer Sphinx's output into the form we want. Sphinx can be themed, but the examples I've seen all still fit within a certain Sphinx model, which doesn't feel ideal for a homepage. I'll try building Komal's repository a bit later on. In terms of the landing page, have you had a look at the file I sent above? I'm by no means a designer, but that's how I envisage the basic shape of it - a little content, with the focus on a set of key links to downloads, docs, mailing lists, etc. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Thu Jun 2 11:37:34 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 2 Jun 2011 08:37:34 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: A few comments: * We are not very far off from being at the point where we hire a professional design firm to design a logo, color scheme and website for us. * I am very much in favor of us sticking with Sphinx for everything for now because we will spend dozens of hours getting a hand coded website to look as nice as Sphinx across all browsers. Sure we could do this, but I think it is not worth the effort at this point when a full blow professional designed site is just around the corner. * We can tweak the Sphinx css to "personalize" our design. * I think the websites that are using Sphinx throughout (networkx, matplotlib) have an extremely nice uniform look at the only sites that beat these in terms of looks (sqlalchemy) are done professional quality designed sites. * We could have a different Sphinx website for the docs and the main website with slightly different color themes to distinguish the two, but I don't think that is necessary. Cheers, Brian On Thu, Jun 2, 2011 at 2:57 AM, Thomas Kluyver wrote: > On 1 June 2011 21:32, Fernando Perez wrote: >> >> I *really* want the website content to be under version control, and >> also to be written in reST instead of hand-coded html (except possibly >> for a few visually key pages like the main page, if necessary). ?If >> it's in simple reST we're much more likely to actually keep it updated >> than if we have to hand-edit html, which I find fairly unpleasant. > > I think in fact we're saying the same thing, but from two different angles. > I'm not suggesting we write reams of content in straight HTML. Sphinx/RST is > the right tool for the bulk of the stuff, augmented with a wiki for the more > changeable stuff. But, as you say, a couple of key pages - certainly the > landing page, and perhaps also the download page - need to be visually > attractive. > > I think this is going to be easier to achieve by designing them in HTML than > by trying to hammer Sphinx's output into the form we want. Sphinx can be > themed, but the examples I've seen all still fit within a certain Sphinx > model, which doesn't feel ideal for a homepage. > > I'll try building Komal's repository a bit later on. > > In terms of the landing page, have you had a look at the file I sent above? > I'm by no means a designer, but that's how I envisage the basic shape of it > - a little content, with the focus on a set of key links to downloads, docs, > mailing lists, etc. > > Thomas > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Thu Jun 2 11:52:27 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 2 Jun 2011 16:52:27 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 2 June 2011 16:37, Brian Granger wrote: > > * We are not very far off from being at the point where we hire a > professional design firm to design a logo, color scheme and website > for us. > OK, I didn't know that. I shall let them handle it, then. * We can tweak the Sphinx css to "personalize" our design. > * I think the websites that are using Sphinx throughout (networkx, > matplotlib) have an extremely nice uniform look at the only sites that > beat these in terms of looks (sqlalchemy) are done professional > quality designed sites. To me, sphinx websites look like documentation. You can customise the design, but it's still obviously a sphinx website, and I still feel that I've missed the homepage when I look at the sites for matplotlib or networkx. But if we're just talking about a stopgap until we get professionals to design a website for us, let's not waste time arguing about how we do it. Do we have a rough timescale for when this design will be happening? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Thu Jun 2 14:41:55 2011 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 Jun 2011 11:41:55 -0700 Subject: [IPython-dev] pyzmq authentication In-Reply-To: <9FFA06C8-D32E-4C31-891E-90E7D9A041E9@gmail.com> References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> <4DE6C597.1020201@creativetrax.com> <4DE6CCB5.5080706@creativetrax.com> <4DE6D110.2010002@creativetrax.com> <9FFA06C8-D32E-4C31-891E-90E7D9A041E9@gmail.com> Message-ID: I'm realizing that, in the parallel code at least, there is no way to maintain these counters in a synchronized way. This is because the connections are in fact many-to-many, not one-to-many, so the receiver can't know the count for the sender, and for load-balanced execution the sender doesn't know who the receiver is. What I've done instead to prevent sniffed duplicates is to simply keep track of previously seen digests, and don't allow repeats. The code is pretty simple, and I'll merge it after the newconfig code is merged. -MinRK On Wed, Jun 1, 2011 at 17:29, Min RK wrote: > No, I will add it to the Session object in IPython. ?Like the ssh code, though, there is really nothing IPython specific in the session (aside from the use of traitlets). It's a perfectly general pyzmq utility that you could use anywhere, and might (someday) end up in pyzmq itself. > > -MinRK > > On Jun 1, 2011, at 16:53, Jason Grout wrote: > >> On 6/1/11 6:42 PM, MinRK wrote: >>> On Wed, Jun 1, 2011 at 16:35, Jason Grout ?wrote: >>>> On 6/1/11 6:04 PM, Jason Grout wrote: >>>>> For example, we >>>>> could send a hash of the concatenation of the shared secret and the >>>>> content of the message. >>>> >>>> Of course, as aptly stated by khrafra [1] and many others, it's always >>>> better to use the prebuilt libraries to do signing. ?Here are two >>>> standard modules that could do authentication: >>> >>> Certainly true. ?I've already started writing the signing code with >>> hmac, but I have to run >>> and meet some ZeroMQ folks in San Francisco. ?I should probably have a >>> sample up tomorrow. >> >> >> Fantastic! ?Thanks! ?Do you mean that you are adding this directly to pyzmq, as a layer above the library wrapper? ?That's where we would use it, though if it wasn't in pyzmq, I suppose we could always just incorporate the functions themselves into our codebase. >> >> Thanks, >> >> Jason >> >> -- >> Jason Grout > > From jason-sage at creativetrax.com Thu Jun 2 15:10:06 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Thu, 02 Jun 2011 14:10:06 -0500 Subject: [IPython-dev] pyzmq authentication In-Reply-To: References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> <4DE6C597.1020201@creativetrax.com> <4DE6CCB5.5080706@creativetrax.com> <4DE6D110.2010002@creativetrax.com> <9FFA06C8-D32E-4C31-891E-90E7D9A041E9@gmail.com> Message-ID: <4DE7E00E.6030200@creativetrax.com> On 6/2/11 1:41 PM, MinRK wrote: > I'm realizing that, in the parallel code at least, there is no way to > maintain these counters in a synchronized way. This is because the > connections are in fact many-to-many, not one-to-many, so the receiver > can't know the count for the sender, and for load-balanced execution > the sender doesn't know who the receiver is. What I've done instead to > prevent sniffed duplicates is to simply keep track of previously seen > digests, and don't allow repeats. That makes sense. > > The code is pretty simple, and I'll merge it after the newconfig code is merged. Did you happen to push it to a github branch somewhere? If so, we might use it pretty much immediately in our Sage "single-cell" web server. You're right that it should be simple enough to write myself, but I figure (*especially* with crypto) it's better to have two eyes looking at one piece of code rather than two people rewriting the same thing twice. Jason From benjaminrk at gmail.com Thu Jun 2 15:12:11 2011 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 Jun 2011 12:12:11 -0700 Subject: [IPython-dev] pyzmq authentication In-Reply-To: <4DE7E00E.6030200@creativetrax.com> References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> <4DE6C597.1020201@creativetrax.com> <4DE6CCB5.5080706@creativetrax.com> <4DE6D110.2010002@creativetrax.com> <9FFA06C8-D32E-4C31-891E-90E7D9A041E9@gmail.com> <4DE7E00E.6030200@creativetrax.com> Message-ID: On Thu, Jun 2, 2011 at 12:10, Jason Grout wrote: > On 6/2/11 1:41 PM, MinRK wrote: >> >> I'm realizing that, in the parallel code at least, there is no way to >> maintain these counters in a synchronized way. ?This is because the >> connections are in fact many-to-many, not one-to-many, so the receiver >> can't know the count for the sender, and for load-balanced execution >> the sender doesn't know who the receiver is. What I've done instead to >> prevent sniffed duplicates is to simply keep track of previously seen >> digests, and don't allow repeats. > > That makes sense. > >> >> The code is pretty simple, and I'll merge it after the newconfig code is >> merged. > > Did you happen to push it to a github branch somewhere? ?If so, we might use > it pretty much immediately in our Sage "single-cell" web server. > > You're right that it should be simple enough to write myself, but I figure > (*especially* with crypto) it's better to have two eyes looking at one piece > of code rather than two people rewriting the same thing twice. I'll push it this afternoon, I'm just cleaning up a few things first. > > Jason > From benjaminrk at gmail.com Thu Jun 2 18:05:06 2011 From: benjaminrk at gmail.com (MinRK) Date: Thu, 2 Jun 2011 15:05:06 -0700 Subject: [IPython-dev] pyzmq authentication In-Reply-To: References: <4DE52899.90402@creativetrax.com> <4DE52FC3.1080408@creativetrax.com> <4DE6414F.3070002@creativetrax.com> <4DE6C597.1020201@creativetrax.com> <4DE6CCB5.5080706@creativetrax.com> <4DE6D110.2010002@creativetrax.com> <9FFA06C8-D32E-4C31-891E-90E7D9A041E9@gmail.com> <4DE7E00E.6030200@creativetrax.com> Message-ID: Pushed to my hmac branch. The relevant code is in the sign method: https://github.com/minrk/ipython/blob/hmac/IPython/parallel/streamsession.py#L231 and the checking in unpack_message: https://github.com/minrk/ipython/blob/hmac/IPython/parallel/streamsession.py#L448 Note that this class is *not* used in IPython.zmq, but the two classes will be merged at some point. On Thu, Jun 2, 2011 at 12:12, MinRK wrote: > On Thu, Jun 2, 2011 at 12:10, Jason Grout wrote: >> On 6/2/11 1:41 PM, MinRK wrote: >>> >>> I'm realizing that, in the parallel code at least, there is no way to >>> maintain these counters in a synchronized way. ?This is because the >>> connections are in fact many-to-many, not one-to-many, so the receiver >>> can't know the count for the sender, and for load-balanced execution >>> the sender doesn't know who the receiver is. What I've done instead to >>> prevent sniffed duplicates is to simply keep track of previously seen >>> digests, and don't allow repeats. >> >> That makes sense. >> >>> >>> The code is pretty simple, and I'll merge it after the newconfig code is >>> merged. >> >> Did you happen to push it to a github branch somewhere? ?If so, we might use >> it pretty much immediately in our Sage "single-cell" web server. >> >> You're right that it should be simple enough to write myself, but I figure >> (*especially* with crypto) it's better to have two eyes looking at one piece >> of code rather than two people rewriting the same thing twice. > > I'll push it this afternoon, I'm just cleaning up a few things first. > >> >> Jason >> > From fperez.net at gmail.com Thu Jun 2 22:58:48 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 2 Jun 2011 19:58:48 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Thu, Jun 2, 2011 at 2:57 AM, Thomas Kluyver wrote: > I think in fact we're saying the same thing, but from two different angles. > I'm not suggesting we write reams of content in straight HTML. Sphinx/RST is > the right tool for the bulk of the stuff, augmented with a wiki for the more > changeable stuff. But, as you say, a couple of key pages - certainly the > landing page, and perhaps also the download page - need to be visually > attractive. > > I think this is going to be easier to achieve by designing them in HTML than > by trying to hammer Sphinx's output into the form we want. Sphinx can be > themed, but the examples I've seen all still fit within a certain Sphinx > model, which doesn't feel ideal for a homepage. We're saying mostly the same thing, though I'm still saying that sphinx *can* be the right tool even for what the part you have in mind: - sphinx makes it very easy to have specific pages in pure html (ideal for heavily manually designed pages) - while your statement above is true of most sphinx sites out there, I don't think it's a necessary outcome, just the fact that most people seem to do only minimal tweaking of the theme templates. But even the web ignoramus that I am was able to change my site (http://fperez.org) to look somewhat different. You can still recognize the right sidebar easily, but I think it doesn't feel quite as doc-like as others, and this was literally just a tiny bit of changing the default theme template, with *zero* hand-coded html. So I still think that a small amount of fiddling with shphinx, with the deliberate intent of making a theme that is deliberately designed *not* for documentation. I think mine is a decent starting point, since I already nuked many of the doc-driven elements out. It just needs a litlte more visual flair. > I'll try building Komal's repository a bit later on. > > In terms of the landing page, have you had a look at the file I sent above? > I'm by no means a designer, but that's how I envisage the basic shape of it > - a little content, with the focus on a set of key links to downloads, docs, > mailing lists, etc. I just did now, and I think that's on the right track. Back to Brian's comment and the question of resources, while we hope to have later this year some extra resources for this kind of thing, I honestly think that doing something now is not a bad idea at all, as long as it doesn't become a major project for anyone. It's not *certain* we'll have spare resources for this, and our current situation is so sad (an old moin wiki and a mishmash of github stuff) that an improvement would be very welcome, in my view. As long as it's not a huge sink of effort, I don't see any harm in improving this direction now, if you (or anyone else) has the energy for it. That's why I proposed it as one of the India projects, which Komal picked up. Cheers, f From jason-sage at creativetrax.com Thu Jun 2 23:23:02 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Thu, 02 Jun 2011 22:23:02 -0500 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: <4DE85396.8050109@creativetrax.com> On 6/2/11 9:58 PM, Fernando Perez wrote: > - sphinx makes it very easy to have specific pages in pure html (ideal > for heavily manually designed pages) I just browsed your site and checked out some of the show source links. Very nice! I'm now considering whether to move my personal DokuWiki site over to Sphinx. When you say easy above, do you mean having a rst page that basically just consists of a singe raw:: html block, like this snippet from your site [1]? .. raw:: html
Thanks, Jason [1] http://fperez.org/_sources/talks/index.txt From fperez.net at gmail.com Fri Jun 3 01:51:21 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 2 Jun 2011 22:51:21 -0700 Subject: [IPython-dev] Website In-Reply-To: <4DE85396.8050109@creativetrax.com> References: <4DE85396.8050109@creativetrax.com> Message-ID: Hi Jason, On Thu, Jun 2, 2011 at 8:23 PM, Jason Grout wrote: > I just browsed your site and checked out some of the show source links. > ?Very nice! ?I'm now considering whether to move my personal DokuWiki > site over to Sphinx. Thanks! If you want to get going quickly, feel free to grab my toolchain, it's available right there: http://fperez.org/code/index.html there are a few things that are needed to make building a normal website more convenient with sphinx, and I think I've taken care of that with the tools listed there (making it easy to automatically sync/upload any static files you have locally like pdfs of talks and papers is probably the main point). > When you say easy above, do you mean having a rst page that basically > just consists of a singe raw:: html block, like this snippet from your > site [1]? > > .. raw:: html > > ? ?
> Yes. I believe it's also possible to tell sphinx that certain pages are kept as pure html and never held in reST, though I'm not sure right now what the call/parameter is for that. Best, f From fperez.net at gmail.com Fri Jun 3 01:54:11 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 2 Jun 2011 22:54:11 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Thu, Jun 2, 2011 at 7:58 PM, Fernando Perez wrote: > - while your statement above is true of most sphinx sites out there, I > don't think it's a necessary outcome, just the fact that most people > seem to do only minimal tweaking of the theme templates. ?But even the > web ignoramus that I am was able to change my site (http://fperez.org) > to look somewhat different. ?You can still recognize the right sidebar > easily, but I think it doesn't feel quite as doc-like as others, and > this was literally just a tiny bit of changing the default theme > template, with *zero* hand-coded html. I think this proves my point much better than my lousy site: http://www.pocoo.org/ That's the site of the sphinx guys themselves, and it says at the bottom it was made with sphinx, yet I think it looks perfectly nice. Something along those lines (ideas-wise, I don't mean copying the design) is what I had in mind when I made my points above. Best, f From takowl at gmail.com Fri Jun 3 06:04:24 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 3 Jun 2011 11:04:24 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 3 June 2011 06:54, Fernando Perez wrote: > I think this proves my point much better than my lousy site: > > http://www.pocoo.org/ > > That's the site of the sphinx guys themselves, and it says at the > bottom it was made with sphinx, yet I think it looks perfectly nice. > Something along those lines (ideas-wise, I don't mean copying the > design) is what I had in mind when I made my points above. > Point conceded. I hadn't realised all the Pocoo sites were done in Sphinx. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Fri Jun 3 09:03:35 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 3 Jun 2011 14:03:35 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: I've cloned Komal's repository and started fiddling. There's some way to go, but it's looking promising. https://github.com/takluyver/ipython-website Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason-sage at creativetrax.com Fri Jun 3 09:15:00 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Fri, 03 Jun 2011 08:15:00 -0500 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: <4DE8DE54.2090906@creativetrax.com> On 6/3/11 8:03 AM, Thomas Kluyver wrote: > I've cloned Komal's repository and started fiddling. There's some way to > go, but it's looking promising. > > https://github.com/takluyver/ipython-website I cloned and tried building, but got an error: % make sphinx-build -b html -d _build/doctrees . _build/html Making output directory... Running Sphinx v1.0.7 Extension error: Could not import extension ipython_console_highlighting (exception: No module named ipython_console_highlighting) make: *** [html] Error 1 Do you know what I need to do? Is this a sphinx extension that should be installed? Thanks, Jason From takowl at gmail.com Fri Jun 3 09:34:11 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 3 Jun 2011 14:34:11 +0100 Subject: [IPython-dev] Website In-Reply-To: <4DE8DE54.2090906@creativetrax.com> References: <4DE8DE54.2090906@creativetrax.com> Message-ID: Oh yes, I got that too. I symlinked the sphinxext directory from /docs in the ipython repository, which seems to have the relevant extension. But we should work out a more permanent solution. Thomas On 3 June 2011 14:15, Jason Grout wrote: > On 6/3/11 8:03 AM, Thomas Kluyver wrote: > > I've cloned Komal's repository and started fiddling. There's some way to > > go, but it's looking promising. > > > > https://github.com/takluyver/ipython-website > > I cloned and tried building, but got an error: > > % make > sphinx-build -b html -d _build/doctrees . _build/html > Making output directory... > Running Sphinx v1.0.7 > > Extension error: > Could not import extension ipython_console_highlighting (exception: No > module named ipython_console_highlighting) > make: *** [html] Error 1 > > > Do you know what I need to do? Is this a sphinx extension that should > be installed? > > Thanks, > > Jason > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Fri Jun 3 10:55:57 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 3 Jun 2011 15:55:57 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: In terms of what goes where, I suggest that the cookbook and the lists of projects using IPython should stay in a wiki form somewhere. Of the 'developer zone', I think the more formal information belongs in the developer section of the docs, and the other useful information should live in a wiki. That would leave the "landing" site with: - homepage - download & installation page - news - presentations - FAQ - citation Thomas On 3 June 2011 14:03, Thomas Kluyver wrote: > I've cloned Komal's repository and started fiddling. There's some way to > go, but it's looking promising. > > https://github.com/takluyver/ipython-website > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Jun 3 12:21:25 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 3 Jun 2011 09:21:25 -0700 Subject: [IPython-dev] Website In-Reply-To: <4DE8DE54.2090906@creativetrax.com> References: <4DE8DE54.2090906@creativetrax.com> Message-ID: n Fri, Jun 3, 2011 at 6:15 AM, Jason Grout wrote: > Extension error: > Could not import extension ipython_console_highlighting (exception: No > module named ipython_console_highlighting) > make: *** [html] Error 1 > > > Do you know what I need to do? ?Is this a sphinx extension that should > be installed? Oh, sorry, just nuke that from the conf.py for now (look for that extension name towards the early part of the file). You don't really need it for a regular site in most cases. I haven't really bulletproofed that tool very much, it's just my own personal script, sorry. But with a small amount of fiddling it should be good to go for you later on. Cheers, f From fperez.net at gmail.com Fri Jun 3 12:23:55 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 3 Jun 2011 09:23:55 -0700 Subject: [IPython-dev] Website In-Reply-To: References: <4DE8DE54.2090906@creativetrax.com> Message-ID: On Fri, Jun 3, 2011 at 6:34 AM, Thomas Kluyver wrote: > Oh yes, I got that too. I symlinked the sphinxext directory from /docs in > the ipython repository, which seems to have the relevant extension. But we > should work out a more permanent solution. > I said to Jason he should nuke it, since for his personal site he likely won't need it. For us, we should just make that extension an installable part of ipython (I think there's even an open issue for that, but I can't find it right now), since we'll likely want to show nicely highlighted ipython examples in our docs. Cheers, f From fperez.net at gmail.com Fri Jun 3 12:26:41 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 3 Jun 2011 09:26:41 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Fri, Jun 3, 2011 at 7:55 AM, Thomas Kluyver wrote: > In terms of what goes where, I suggest that the cookbook and the lists of > projects using IPython should stay in a wiki form somewhere. Of the I'd like a link to a wiki for that, so that users can update that information, but it might be nice to have a more static version of the same with screenshots, etc. Basically I see the wiki as a way for the community to easily feed us information (already written up in reST), some of which once 'edited' gets baked into the docs in a more permanent fashion, with better formatting, etc. But if that's too much to commit to early on, no problem. > 'developer zone', I think the more formal information belongs in the > developer section of the docs, and the other useful information should live > in a wiki. > > That would leave the "landing" site with: > - homepage > - download & installation page And this should be mostly links to the PyPI and github download areas. > - news > - presentations > - FAQ > - citation Sounds good. Cheers, f From takowl at gmail.com Mon Jun 6 08:03:02 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 6 Jun 2011 13:03:02 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: The website in my fork of Komal's repository is now (hopefully) up to date and intact. https://github.com/takluyver/ipython-website Cookbook, Developer zone, and Projects using IPython are, for now, links pointing to the moin wiki. News is up to date, version numbers should be correct, and the content on the homepage has been cut down. The favicon is a bland placeholder until someone feels like designing a decent one. Please do build it and let me know if you spot any mistakes or omissions. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Mon Jun 6 21:39:09 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Mon, 6 Jun 2011 21:39:09 -0400 Subject: [IPython-dev] trying to compile pyzmq Message-ID: hi min and brian, trying to compile pyzmq, both from git clone master cheers, satra Configure: Autodetecting ZMQ settings... Custom ZMQ dir: /software/venvs/EPD/7.0/ipxi cc -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core -Izmq/devices -c detect/vers.c -o detect/vers.o cc -arch x86_64 -undefined dynamic_lookup detect/vers.o -L/software/venvs/EPD/7.0/ipxi/lib -lzmq -o detect/vers ZMQ version detected: 2.1.7 ****************************************** cythoning zmq/core/constants.pyx to zmq/core/constants.c building 'zmq.core.constants' extension creating build/temp.macosx-10.5-x86_64-2.7 creating build/temp.macosx-10.5-x86_64-2.7/zmq creating build/temp.macosx-10.5-x86_64-2.7/zmq/core gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -DNDEBUG -g -O3 -arch x86_64 -I/Library/Frameworks/EPD64.framework/Versions/7.0/include -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core -Izmq/devices -I/software/venvs/EPD/7.0/ipxi/include -I/Library/Frameworks/EPD64.framework/Versions/7.0/include/python2.7 -c zmq/core/constants.c -o build/temp.macosx-10.5-x86_64-2.7/zmq/core/constants.o -Wno-unused-function -Wno-strict-aliasing zmq/core/constants.c: In function ?initconstants?: zmq/core/constants.c:1024: error: ?ZMQ_XPUB? undeclared (first use in this function) zmq/core/constants.c:1024: error: (Each undeclared identifier is reported only once zmq/core/constants.c:1024: error: for each function it appears in.) zmq/core/constants.c:1036: error: ?ZMQ_XSUB? undeclared (first use in this function) zmq/core/constants.c:1662: error: ?ZMQ_FD? undeclared (first use in this function) zmq/core/constants.c:1674: error: ?ZMQ_EVENTS? undeclared (first use in this function) zmq/core/constants.c:1686: error: ?ZMQ_TYPE? undeclared (first use in this function) zmq/core/constants.c:1698: error: ?ZMQ_LINGER? undeclared (first use in this function) zmq/core/constants.c:1710: error: ?ZMQ_RECONNECT_IVL? undeclared (first use in this function) zmq/core/constants.c:1722: error: ?ZMQ_BACKLOG? undeclared (first use in this function) zmq/core/constants.c:1850: error: ?ZMQ_RECONNECT_IVL_MAX? undeclared (first use in this function) error: command 'gcc' failed with exit status 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Mon Jun 6 22:11:48 2011 From: benjaminrk at gmail.com (Min RK) Date: Mon, 6 Jun 2011 19:11:48 -0700 Subject: [IPython-dev] trying to compile pyzmq In-Reply-To: References: Message-ID: Hi, sorry you are having issues. Those values being undefined means the zmq.h that gcc is finding is old (pre-2.1.0, I think), but weirdly the libzmq the detection is finding is current. Try looking around for zmq.h, and removing the old one. -MinRK On Jun 6, 2011, at 18:39, Satrajit Ghosh wrote: > hi min and brian, > > trying to compile pyzmq, both from git clone master > > cheers, > > satra > > Configure: Autodetecting ZMQ settings... > Custom ZMQ dir: /software/venvs/EPD/7.0/ipxi > cc -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core -Izmq/devices -c detect/vers.c -o detect/vers.o > cc -arch x86_64 -undefined dynamic_lookup detect/vers.o -L/software/venvs/EPD/7.0/ipxi/lib -lzmq -o detect/vers > ZMQ version detected: 2.1.7 > ****************************************** > cythoning zmq/core/constants.pyx to zmq/core/constants.c > building 'zmq.core.constants' extension > creating build/temp.macosx-10.5-x86_64-2.7 > creating build/temp.macosx-10.5-x86_64-2.7/zmq > creating build/temp.macosx-10.5-x86_64-2.7/zmq/core > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -DNDEBUG -g -O3 -arch x86_64 -I/Library/Frameworks/EPD64.framework/Versions/7.0/include -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core -Izmq/devices -I/software/venvs/EPD/7.0/ipxi/include -I/Library/Frameworks/EPD64.framework/Versions/7.0/include/python2.7 -c zmq/core/constants.c -o build/temp.macosx-10.5-x86_64-2.7/zmq/core/constants.o -Wno-unused-function -Wno-strict-aliasing > zmq/core/constants.c: In function ?initconstants?: > zmq/core/constants.c:1024: error: ?ZMQ_XPUB? undeclared (first use in this function) > zmq/core/constants.c:1024: error: (Each undeclared identifier is reported only once > zmq/core/constants.c:1024: error: for each function it appears in.) > zmq/core/constants.c:1036: error: ?ZMQ_XSUB? undeclared (first use in this function) > zmq/core/constants.c:1662: error: ?ZMQ_FD? undeclared (first use in this function) > zmq/core/constants.c:1674: error: ?ZMQ_EVENTS? undeclared (first use in this function) > zmq/core/constants.c:1686: error: ?ZMQ_TYPE? undeclared (first use in this function) > zmq/core/constants.c:1698: error: ?ZMQ_LINGER? undeclared (first use in this function) > zmq/core/constants.c:1710: error: ?ZMQ_RECONNECT_IVL? undeclared (first use in this function) > zmq/core/constants.c:1722: error: ?ZMQ_BACKLOG? undeclared (first use in this function) > zmq/core/constants.c:1850: error: ?ZMQ_RECONNECT_IVL_MAX? undeclared (first use in this function) > error: command 'gcc' failed with exit status 1 > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From takowl at gmail.com Wed Jun 8 13:25:31 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 8 Jun 2011 18:25:31 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: I've put the built website up so it's easy to evaluate: http://takluyver.github.com/ipython-website/ Please have a look, and let me know of any broken links, out of date information, and so on. I think it's an improvement on the moin wiki, so barring any major problems, I'd hope it can go live alongside or before the 0.11 release. Thanks, Thomas On 6 June 2011 13:03, Thomas Kluyver wrote: > The website in my fork of Komal's repository is now (hopefully) up to date > and intact. > > > https://github.com/takluyver/ipython-website > > Cookbook, Developer zone, and Projects using IPython are, for now, links > pointing to the moin wiki. News is up to date, version numbers should be > correct, and the content on the homepage has been cut down. The favicon is a > bland placeholder until someone feels like designing a decent one. > > Please do build it and let me know if you spot any mistakes or omissions. > > Thanks, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdimiduk at physics.harvard.edu Wed Jun 8 13:27:13 2011 From: tdimiduk at physics.harvard.edu (Tom Dimiduk) Date: Wed, 08 Jun 2011 13:27:13 -0400 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: <4DEFB0F1.6020203@physics.harvard.edu> Mention that it works on python 2.7? On 06/08/2011 01:25 PM, Thomas Kluyver wrote: > I've put the built website up so it's easy to evaluate: > > http://takluyver.github.com/ipython-website/ > > Please have a look, and let me know of any broken links, out of date > information, and so on. I think it's an improvement on the moin wiki, so > barring any major problems, I'd hope it can go live alongside or before > the 0.11 release. > > Thanks, > Thomas > > On 6 June 2011 13:03, Thomas Kluyver > wrote: > > The website in my fork of Komal's repository is now (hopefully) up > to date and intact. > > > https://github.com/takluyver/ipython-website > > Cookbook, Developer zone, and Projects using IPython are, for now, > links pointing to the moin wiki. News is up to date, version numbers > should be correct, and the content on the homepage has been cut > down. The favicon is a bland placeholder until someone feels like > designing a decent one. > > Please do build it and let me know if you spot any mistakes or > omissions. > > Thanks, > Thomas > > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From takowl at gmail.com Wed Jun 8 14:04:34 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 8 Jun 2011 19:04:34 +0100 Subject: [IPython-dev] Website In-Reply-To: <4DEFB0F1.6020203@physics.harvard.edu> References: <4DEFB0F1.6020203@physics.harvard.edu> Message-ID: On 8 June 2011 18:27, Tom Dimiduk wrote: > Mention that it works on python 2.7? Good point, thanks. It's updated. I'll also remember to change it when we release 0.11, because we're dropping support for Python 2.5. Best wishes, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsdale24 at gmail.com Wed Jun 8 14:07:58 2011 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 8 Jun 2011 14:07:58 -0400 Subject: [IPython-dev] Message spec draft more fleshed out In-Reply-To: References: Message-ID: Hi Fernando, On Tue, Aug 10, 2010 at 4:02 AM, Fernando Perez wrote: > Hi folks, > > here: > > http://github.com/ipython/ipython/blob/106bc2e0587d315db67988c1803b8574fc54463a/docs/source/development/messaging.txt > > is a more fleshed out message spec document for feedback. I haven't been following this topic very closely, but a colleague just brought MessagePack to my attention: http://msgpack.org/ . I thought it might be of interest to the IPython devs. Darren From fperez.net at gmail.com Wed Jun 8 14:11:40 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 8 Jun 2011 11:11:40 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 10:25 AM, Thomas Kluyver wrote: > I've put the built website up so it's easy to evaluate: > > http://takluyver.github.com/ipython-website/ > > Please have a look, and let me know of any broken links, out of date > information, and so on. I think it's an improvement on the moin wiki, so > barring any major problems, I'd hope it can go live alongside or before the > 0.11 release. Awesome!!! I would really like to thank both Komal and Thomas for making this happen, as well as apologizing to Komal for having initially ignored your great work that got this ball moving. I hope you won't take it as a slight, and will be interested in participating again in the project (whether on website work or anything else). OK, how should we proceed? The only problem is that I'm knee-deep into the writing of *two* grants, both of which will directly benefit IPython in a major way if funded, but which are taking up a lot of my time. AKA, I'm swamped but happy to delegate. As far as I'm concerned, that is already so much nicer than what we had, that I'd be happy to move *today*. It would be great to give our scipy'11 talk with 0.11 off a nice new website :) The points I can think of are: - wiki: do we move off moin to the github one? That seems a no-brainer to me, but I haven't actually used the gh wiki, so perhaps it's not a good idea for some reason I'm not aware of. - logistics of moving: the hosting is currently off the scipy.org server. Thomas, I'm happy to give you login access on the ipython account if you just send me your public ssh key. Alternatively we can look into hosting it elsewhere if we want to have a more updated platform. The scipy.org server is stuck in a time dilation bubble running Fedora 4, released 6 years ago and unmaintained for almost as many, so doing anything useful on that server is a major exercise in frustration, since you're stuck running python2.4 and ages-old libraries. I do have a dreamhost account with unlimited hosting that is at least running debian 5 and has some more up-to-date tools (though we'd still need to do a home build of python2.6/3 on it). I also own the ipython.org domain, which currently just redirects to ipython.scipy.org, but we could switch to using that. Cheers, f From ellisonbg at gmail.com Wed Jun 8 14:20:37 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 8 Jun 2011 11:20:37 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 11:11 AM, Fernando Perez wrote: > On Wed, Jun 8, 2011 at 10:25 AM, Thomas Kluyver wrote: >> I've put the built website up so it's easy to evaluate: >> >> http://takluyver.github.com/ipython-website/ >> >> Please have a look, and let me know of any broken links, out of date >> information, and so on. I think it's an improvement on the moin wiki, so >> barring any major problems, I'd hope it can go live alongside or before the >> 0.11 release. > > Awesome!!! > > I would really like to thank both Komal and Thomas for making this > happen, as well as apologizing to Komal for having initially ignored > your great work that got this ball moving. ?I hope you won't take it > as a slight, and will be interested in participating again in the > project (whether on website work or anything else). > > OK, how should we proceed? ?The only problem is that I'm knee-deep > into the writing of *two* grants, both of which will directly benefit > IPython in a major way if funded, but which are taking up a lot of my > time. AKA, I'm swamped but happy to delegate. > > As far as I'm concerned, that is already so much nicer than what we > had, that I'd be happy to move *today*. ?It would be great to give our > scipy'11 talk with 0.11 off a nice new website :) > > The points I can think of are: > > - wiki: do we move off moin to the github one? ?That seems a > no-brainer to me, but I haven't actually used the gh wiki, so perhaps > it's not a good idea for some reason I'm not aware of. Yes, let's move the wiki to github, including the FAQ, Cookbook, etc. > - logistics of moving: the hosting is currently off the scipy.org > server. ?Thomas, I'm happy to give you login access on the ipython > account if you just send me your public ssh key. > > Alternatively we can look into hosting it elsewhere if we want to have > a more updated platform. ?The scipy.org server is stuck in a time > dilation bubble running Fedora 4, released 6 years ago and > unmaintained for almost as many, so doing anything useful on that > server is a major exercise in frustration, since you're stuck running > python2.4 and ages-old libraries. ?I do have a dreamhost account with > unlimited hosting that is at least running debian 5 and has some more > up-to-date tools (though we'd still need to do a home build of > python2.6/3 on it). ?I also own the ipython.org ?domain, which > currently just redirects to ipython.scipy.org, but we could switch to > using that. I am strongly in favor of moving to another hosting situation and using the ipython.org domain. Let's also create an official IPython repo for the site so all of us can commit/push directly to it. > Cheers, > > f > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Wed Jun 8 14:22:49 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 8 Jun 2011 19:22:49 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 8 June 2011 19:11, Fernando Perez wrote: > As far as I'm concerned, that is already so much nicer than what we > had, that I'd be happy to move *today*. It would be great to give our > scipy'11 talk with 0.11 off a nice new website :) > Excellent! > The points I can think of are: > > - wiki: do we move off moin to the github one? That seems a > no-brainer to me, but I haven't actually used the gh wiki, so perhaps > it's not a good idea for some reason I'm not aware of. > It's kind of orthogonal - so long as we leave the relevant parts of the current wiki up, we can link to them. We can move that stuff to Github and update the links at any point. > > - logistics of moving: the hosting is currently off the scipy.org > server. Thomas, I'm happy to give you login access on the ipython > account if you just send me your public ssh key. > > Alternatively we can look into hosting it elsewhere if we want to have > a more updated platform. The scipy.org server is stuck in a time > dilation bubble running Fedora 4, released 6 years ago and > unmaintained for almost as many, so doing anything useful on that > server is a major exercise in frustration, since you're stuck running > python2.4 and ages-old libraries. I do have a dreamhost account with > unlimited hosting that is at least running debian 5 and has some more > up-to-date tools (though we'd still need to do a home build of > python2.6/3 on it). I also own the ipython.org domain, which > currently just redirects to ipython.scipy.org, but we could switch to > using that. > I suggest we use github pages, have www.ipython.org as the primary domain, and ipython.scipy.org as a redirect to it. ipython.github.com would also automatically become a redirect. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Wed Jun 8 14:34:07 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 8 Jun 2011 11:34:07 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 11:20, Brian Granger wrote: > On Wed, Jun 8, 2011 at 11:11 AM, Fernando Perez > wrote: > > On Wed, Jun 8, 2011 at 10:25 AM, Thomas Kluyver > wrote: > >> I've put the built website up so it's easy to evaluate: > >> > >> http://takluyver.github.com/ipython-website/ > >> > >> Please have a look, and let me know of any broken links, out of date > >> information, and so on. I think it's an improvement on the moin wiki, so > >> barring any major problems, I'd hope it can go live alongside or before > the > >> 0.11 release. > Great! one small note: use the current logo in the docs, rather than the old one from scipy.org (the bevels make me sad). It's in docs/source/_static/logo.png > > > > Awesome!!! > > > > I would really like to thank both Komal and Thomas for making this > > happen, as well as apologizing to Komal for having initially ignored > > your great work that got this ball moving. I hope you won't take it > > as a slight, and will be interested in participating again in the > > project (whether on website work or anything else). > > > > OK, how should we proceed? The only problem is that I'm knee-deep > > into the writing of *two* grants, both of which will directly benefit > > IPython in a major way if funded, but which are taking up a lot of my > > time. AKA, I'm swamped but happy to delegate. > > > > As far as I'm concerned, that is already so much nicer than what we > > had, that I'd be happy to move *today*. It would be great to give our > > scipy'11 talk with 0.11 off a nice new website :) > > > > The points I can think of are: > > > > - wiki: do we move off moin to the github one? That seems a > > no-brainer to me, but I haven't actually used the gh wiki, so perhaps > > it's not a good idea for some reason I'm not aware of. > > Yes, let's move the wiki to github, including the FAQ, Cookbook, etc. > > > - logistics of moving: the hosting is currently off the scipy.org > > server. Thomas, I'm happy to give you login access on the ipython > > account if you just send me your public ssh key. > > > > Alternatively we can look into hosting it elsewhere if we want to have > > a more updated platform. The scipy.org server is stuck in a time > > dilation bubble running Fedora 4, released 6 years ago and > > unmaintained for almost as many, so doing anything useful on that > > server is a major exercise in frustration, since you're stuck running > > python2.4 and ages-old libraries. I do have a dreamhost account with > > unlimited hosting that is at least running debian 5 and has some more > > up-to-date tools (though we'd still need to do a home build of > > python2.6/3 on it). I also own the ipython.org domain, which > > currently just redirects to ipython.scipy.org, but we could switch to > > using that. > > I am strongly in favor of moving to another hosting situation and > using the ipython.org domain. > Is there any reason to not just point ipython.org to ipython.github.com, and host there? We definitely *shouldn't* put it back on scipy.org > > Let's also create an official IPython repo for the site so all of us > can commit/push directly to it. > > > Cheers, > > > > f > > > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Jun 8 14:53:34 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 8 Jun 2011 11:53:34 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 11:34 AM, MinRK wrote: > Is there any reason to not just point ipython.org to ipython.github.com, and > host there? ?We definitely *shouldn't* put it back on scipy.org Well, the question is, if we want to ever host anything other than the html, like static files, pdfs, videos, etc, or configure any other functionality, we may find the github hosting insufficient and a real shell account may be a welcome bit of functionality. BUT, since I'm so incredibly time-constrained right now, I'm more than happy to go with GH right away if you guys prefer that. I have made an 'ipython' user account on dreamhost and I can give any of the core devs ssh access to it if you want, so if you prefer to configure things off the ipython.org server, it will only take a few minutes. I'm kind of partial to having real shell access for this kind of work, so my vote is for going with a real server, but perhaps we don't really need that much... Thoughts? f From takowl at gmail.com Wed Jun 8 15:26:43 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 8 Jun 2011 20:26:43 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 8 June 2011 19:53, Fernando Perez wrote: > Well, the question is, if we want to ever host anything other than the > html, like static files, pdfs, videos, etc, or configure any other > functionality, we may find the github hosting insufficient and a real > shell account may be a welcome bit of functionality. > We can put static files there (as we do for the PDF docs at the moment). As far as I know, the only real limitation is that we can't have dynamic pages (e.g. a wiki, comment form, etc.). I don't think that's really an obstacle for what we want. I'd favour using Github, unless we've got some good reason not to, if only because all the core devs are already set up to use it. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Wed Jun 8 15:37:30 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 8 Jun 2011 20:37:30 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 8 June 2011 19:34, MinRK wrote: > > Great! one small note: use the current logo in the docs, rather than the > old one from scipy.org (the bevels make me sad). > It's in docs/source/_static/logo.png > Done, thanks. As a side note, if anyone with graphic design skills wants to design a bigger logo for the header, that would be good. Take a look at http://sphinx.pocoo.org/ or http://matplotlib.sourceforge.net/ to see the sort of thing I mean. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Wed Jun 8 16:32:49 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 8 Jun 2011 13:32:49 -0700 Subject: [IPython-dev] Message spec draft more fleshed out In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 11:07, Darren Dale wrote: > Hi Fernando, > > On Tue, Aug 10, 2010 at 4:02 AM, Fernando Perez > wrote: > > Hi folks, > > > > here: > > > > > http://github.com/ipython/ipython/blob/106bc2e0587d315db67988c1803b8574fc54463a/docs/source/development/messaging.txt > > > > is a more fleshed out message spec document for feedback. > > I haven't been following this topic very closely, but a colleague just > brought MessagePack to my attention: http://msgpack.org/ . I thought > it might be of interest to the IPython devs. > That is definitely cool. Perhaps we should provide a note in the message doc that describes how to use custom serialization, and various useful libraries such as this one. Once the Session object in the parallel code replaces the one in IPython.zmq (already done in a local branch, but waiting for newapp to merge), the message serialization will be user configurable, just like it is in the parallel code. The message spec only requires that messages be JSONable (simple dicts/lists of strings and numbers), and there is no code (or shouldn't be, anyway) outside the Session that deals with JSON directly. -MinRK > Darren > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Jun 8 16:58:12 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 8 Jun 2011 13:58:12 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 12:26 PM, Thomas Kluyver wrote: > > I'd favour using Github, unless we've got some good reason not to, if only > because all the core devs are already set up to use it. No objection from me for now then, we can always revisit this if the need arises. As long as github gets us moving *now*, it's already a win. I would, however, like to make sure that the publicly visible url is always ipython.org, not a redirect to a github.com url. Is that possible with their system (sorry if this is obvious, I just haven't had the time to investigate their setup). In that case, then we'd only need to set up the GH machinery, and someone let me know if I need to configure anything special with my webhost for the ipython.org domain (right now it redirects to ipython.scipy.org). Once ipython.org is working as we like it, we can ask Enthought's admin to change ipython.scipy.org to redirect to ipython.org. Cheers, f From benjaminrk at gmail.com Wed Jun 8 17:03:47 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 8 Jun 2011 14:03:47 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 13:58, Fernando Perez wrote: > On Wed, Jun 8, 2011 at 12:26 PM, Thomas Kluyver wrote: > > > > I'd favour using Github, unless we've got some good reason not to, if > only > > because all the core devs are already set up to use it. > > No objection from me for now then, we can always revisit this if the > need arises. As long as github gets us moving *now*, it's already a > win. > > I would, however, like to make sure that the publicly visible url is > always ipython.org, not a redirect to a github.com url. Is that > possible with their system (sorry if this is obvious, I just haven't > had the time to investigate their setup). > This is easy, see the pages doc: http://pages.github.com/#custom_domains > > In that case, then we'd only need to set up the GH machinery, and > someone let me know if I need to configure anything special with my > webhost for the ipython.org domain (right now it redirects to > ipython.scipy.org). Once ipython.org is working as we like it, we can > ask Enthought's admin to change ipython.scipy.org to redirect to > ipython.org. > > Cheers, > > f > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Wed Jun 8 17:09:20 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 8 Jun 2011 22:09:20 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 8 June 2011 22:03, MinRK wrote: > I would, however, like to make sure that the publicly visible url is >> always ipython.org, not a redirect to a github.com url. Is that >> possible with their system (sorry if this is obvious, I just haven't >> had the time to investigate their setup). >> > > This is easy, see the pages doc: http://pages.github.com/#custom_domains > To summarise: they'll make ipython.github.com redirect to ipython.org when we set it up. I think the first thing to do is if you (Fernando) can create two repositories under ipython: clone ipython-website for the source, and create ipython.github.com (as the repo name) for the built website. When we push to the latter, it should automatically appear at ipython.github.com. Then we can set it up to serve as ipython.org instead. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Jun 8 17:11:48 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 8 Jun 2011 14:11:48 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 2:09 PM, Thomas Kluyver wrote: > I think the first thing to do is if you (Fernando) can create two > repositories under ipython: clone ipython-website for the source, and create > ipython.github.com (as the repo name) for the built website. When we push to > the latter, it should automatically appear at ipython.github.com. Then we > can set it up to serve as ipython.org instead. Let's quckly chat on IRC to finish this up... f From satra at mit.edu Wed Jun 8 18:06:30 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Wed, 8 Jun 2011 18:06:30 -0400 Subject: [IPython-dev] trying to compile pyzmq In-Reply-To: References: Message-ID: hi min found the file. i'm using EPD and since it bundles pyzmq, the include path contains the old pyzmq. i'm trying to figure out a way to have this pyzmq compile with my zmq instead of EPD's. cheers, satra On Mon, Jun 6, 2011 at 10:11 PM, Min RK wrote: > Hi, sorry you are having issues. > > Those values being undefined means the zmq.h that gcc is finding is old > (pre-2.1.0, I think), but weirdly the libzmq the detection is finding is > current. > > Try looking around for zmq.h, and removing the old one. > > -MinRK > > On Jun 6, 2011, at 18:39, Satrajit Ghosh wrote: > > > hi min and brian, > > > > trying to compile pyzmq, both from git clone master > > > > cheers, > > > > satra > > > > Configure: Autodetecting ZMQ settings... > > Custom ZMQ dir: /software/venvs/EPD/7.0/ipxi > > cc -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core > -Izmq/devices -c detect/vers.c -o detect/vers.o > > cc -arch x86_64 -undefined dynamic_lookup detect/vers.o > -L/software/venvs/EPD/7.0/ipxi/lib -lzmq -o detect/vers > > ZMQ version detected: 2.1.7 > > ****************************************** > > cythoning zmq/core/constants.pyx to zmq/core/constants.c > > building 'zmq.core.constants' extension > > creating build/temp.macosx-10.5-x86_64-2.7 > > creating build/temp.macosx-10.5-x86_64-2.7/zmq > > creating build/temp.macosx-10.5-x86_64-2.7/zmq/core > > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -DNDEBUG -g > -O3 -arch x86_64 -I/Library/Frameworks/EPD64.framework/Versions/7.0/include > -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core -Izmq/devices > -I/software/venvs/EPD/7.0/ipxi/include > -I/Library/Frameworks/EPD64.framework/Versions/7.0/include/python2.7 -c > zmq/core/constants.c -o > build/temp.macosx-10.5-x86_64-2.7/zmq/core/constants.o -Wno-unused-function > -Wno-strict-aliasing > > zmq/core/constants.c: In function ?initconstants?: > > zmq/core/constants.c:1024: error: ?ZMQ_XPUB? undeclared (first use in > this function) > > zmq/core/constants.c:1024: error: (Each undeclared identifier is reported > only once > > zmq/core/constants.c:1024: error: for each function it appears in.) > > zmq/core/constants.c:1036: error: ?ZMQ_XSUB? undeclared (first use in > this function) > > zmq/core/constants.c:1662: error: ?ZMQ_FD? undeclared (first use in this > function) > > zmq/core/constants.c:1674: error: ?ZMQ_EVENTS? undeclared (first use in > this function) > > zmq/core/constants.c:1686: error: ?ZMQ_TYPE? undeclared (first use in > this function) > > zmq/core/constants.c:1698: error: ?ZMQ_LINGER? undeclared (first use in > this function) > > zmq/core/constants.c:1710: error: ?ZMQ_RECONNECT_IVL? undeclared (first > use in this function) > > zmq/core/constants.c:1722: error: ?ZMQ_BACKLOG? undeclared (first use in > this function) > > zmq/core/constants.c:1850: error: ?ZMQ_RECONNECT_IVL_MAX? undeclared > (first use in this function) > > error: command 'gcc' failed with exit status 1 > > > > > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Jun 8 18:19:27 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 8 Jun 2011 15:19:27 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: Hi all, On Wed, Jun 8, 2011 at 2:11 PM, Fernando Perez wrote: > > Let's quckly chat on IRC to finish this up... OK, we've just created a clean website repo: https://github.com/ipython/ipython-website which publishes to: http://ipython.github.com/ In a few hours, once DNS changes propagate, it will also work as ipython.org. Many thanks again to Komal and Thomas for getting us out of ugly land! Cheers, f From benjaminrk at gmail.com Wed Jun 8 18:30:25 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 8 Jun 2011 15:30:25 -0700 Subject: [IPython-dev] trying to compile pyzmq In-Reply-To: References: Message-ID: On Wed, Jun 8, 2011 at 15:06, Satrajit Ghosh wrote: > hi min > > found the file. i'm using EPD and since it bundles pyzmq, the include path > contains the old pyzmq. i'm trying to figure out a way to have this pyzmq > compile with my zmq instead of EPD's. > use `python setup.py configure --zmq=/path/to/install/prefix` to tell pyzmq where libzmq is installed. I'm a bit concerned by the how your configuration is inconsistent, such that LD finds your libzmq before EPD's, but gcc finds EPD's zmq.h before yours. In any case, specifying the zmq location should help. > > cheers, > > satra > > > > > On Mon, Jun 6, 2011 at 10:11 PM, Min RK wrote: > >> Hi, sorry you are having issues. >> >> Those values being undefined means the zmq.h that gcc is finding is old >> (pre-2.1.0, I think), but weirdly the libzmq the detection is finding is >> current. >> >> Try looking around for zmq.h, and removing the old one. >> >> -MinRK >> >> On Jun 6, 2011, at 18:39, Satrajit Ghosh wrote: >> >> > hi min and brian, >> > >> > trying to compile pyzmq, both from git clone master >> > >> > cheers, >> > >> > satra >> > >> > Configure: Autodetecting ZMQ settings... >> > Custom ZMQ dir: /software/venvs/EPD/7.0/ipxi >> > cc -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core >> -Izmq/devices -c detect/vers.c -o detect/vers.o >> > cc -arch x86_64 -undefined dynamic_lookup detect/vers.o >> -L/software/venvs/EPD/7.0/ipxi/lib -lzmq -o detect/vers >> > ZMQ version detected: 2.1.7 >> > ****************************************** >> > cythoning zmq/core/constants.pyx to zmq/core/constants.c >> > building 'zmq.core.constants' extension >> > creating build/temp.macosx-10.5-x86_64-2.7 >> > creating build/temp.macosx-10.5-x86_64-2.7/zmq >> > creating build/temp.macosx-10.5-x86_64-2.7/zmq/core >> > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -DNDEBUG -g >> -O3 -arch x86_64 -I/Library/Frameworks/EPD64.framework/Versions/7.0/include >> -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core -Izmq/devices >> -I/software/venvs/EPD/7.0/ipxi/include >> -I/Library/Frameworks/EPD64.framework/Versions/7.0/include/python2.7 -c >> zmq/core/constants.c -o >> build/temp.macosx-10.5-x86_64-2.7/zmq/core/constants.o -Wno-unused-function >> -Wno-strict-aliasing >> > zmq/core/constants.c: In function ?initconstants?: >> > zmq/core/constants.c:1024: error: ?ZMQ_XPUB? undeclared (first use in >> this function) >> > zmq/core/constants.c:1024: error: (Each undeclared identifier is >> reported only once >> > zmq/core/constants.c:1024: error: for each function it appears in.) >> > zmq/core/constants.c:1036: error: ?ZMQ_XSUB? undeclared (first use in >> this function) >> > zmq/core/constants.c:1662: error: ?ZMQ_FD? undeclared (first use in this >> function) >> > zmq/core/constants.c:1674: error: ?ZMQ_EVENTS? undeclared (first use in >> this function) >> > zmq/core/constants.c:1686: error: ?ZMQ_TYPE? undeclared (first use in >> this function) >> > zmq/core/constants.c:1698: error: ?ZMQ_LINGER? undeclared (first use in >> this function) >> > zmq/core/constants.c:1710: error: ?ZMQ_RECONNECT_IVL? undeclared (first >> use in this function) >> > zmq/core/constants.c:1722: error: ?ZMQ_BACKLOG? undeclared (first use in >> this function) >> > zmq/core/constants.c:1850: error: ?ZMQ_RECONNECT_IVL_MAX? undeclared >> (first use in this function) >> > error: command 'gcc' failed with exit status 1 >> > >> > >> > _______________________________________________ >> > IPython-dev mailing list >> > IPython-dev at scipy.org >> > http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Wed Jun 8 18:47:57 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Wed, 8 Jun 2011 18:47:57 -0400 Subject: [IPython-dev] trying to compile pyzmq In-Reply-To: References: Message-ID: hi min, unfortunately that didn't help. you can see from the output that the configuration simply uses a limited set of directories, while the gcc compilation during the build process lists the EPD include directory before the include dir found by configure or setup.cfg output at: https://gist.github.com/1015631 cheers, satra On Wed, Jun 8, 2011 at 6:30 PM, MinRK wrote: > > > On Wed, Jun 8, 2011 at 15:06, Satrajit Ghosh wrote: > >> hi min >> >> found the file. i'm using EPD and since it bundles pyzmq, the include path >> contains the old pyzmq. i'm trying to figure out a way to have this pyzmq >> compile with my zmq instead of EPD's. >> > > use `python setup.py configure --zmq=/path/to/install/prefix` to tell pyzmq > where libzmq is installed. I'm a bit concerned by the how your > configuration is inconsistent, such that LD finds your libzmq before EPD's, > but gcc finds EPD's zmq.h before yours. > > In any case, specifying the zmq location should help. > > >> >> cheers, >> >> satra >> >> >> >> >> On Mon, Jun 6, 2011 at 10:11 PM, Min RK wrote: >> >>> Hi, sorry you are having issues. >>> >>> Those values being undefined means the zmq.h that gcc is finding is old >>> (pre-2.1.0, I think), but weirdly the libzmq the detection is finding is >>> current. >>> >>> Try looking around for zmq.h, and removing the old one. >>> >>> -MinRK >>> >>> On Jun 6, 2011, at 18:39, Satrajit Ghosh wrote: >>> >>> > hi min and brian, >>> > >>> > trying to compile pyzmq, both from git clone master >>> > >>> > cheers, >>> > >>> > satra >>> > >>> > Configure: Autodetecting ZMQ settings... >>> > Custom ZMQ dir: /software/venvs/EPD/7.0/ipxi >>> > cc -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core >>> -Izmq/devices -c detect/vers.c -o detect/vers.o >>> > cc -arch x86_64 -undefined dynamic_lookup detect/vers.o >>> -L/software/venvs/EPD/7.0/ipxi/lib -lzmq -o detect/vers >>> > ZMQ version detected: 2.1.7 >>> > ****************************************** >>> > cythoning zmq/core/constants.pyx to zmq/core/constants.c >>> > building 'zmq.core.constants' extension >>> > creating build/temp.macosx-10.5-x86_64-2.7 >>> > creating build/temp.macosx-10.5-x86_64-2.7/zmq >>> > creating build/temp.macosx-10.5-x86_64-2.7/zmq/core >>> > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -DNDEBUG -g >>> -O3 -arch x86_64 -I/Library/Frameworks/EPD64.framework/Versions/7.0/include >>> -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core -Izmq/devices >>> -I/software/venvs/EPD/7.0/ipxi/include >>> -I/Library/Frameworks/EPD64.framework/Versions/7.0/include/python2.7 -c >>> zmq/core/constants.c -o >>> build/temp.macosx-10.5-x86_64-2.7/zmq/core/constants.o -Wno-unused-function >>> -Wno-strict-aliasing >>> > zmq/core/constants.c: In function ?initconstants?: >>> > zmq/core/constants.c:1024: error: ?ZMQ_XPUB? undeclared (first use in >>> this function) >>> > zmq/core/constants.c:1024: error: (Each undeclared identifier is >>> reported only once >>> > zmq/core/constants.c:1024: error: for each function it appears in.) >>> > zmq/core/constants.c:1036: error: ?ZMQ_XSUB? undeclared (first use in >>> this function) >>> > zmq/core/constants.c:1662: error: ?ZMQ_FD? undeclared (first use in >>> this function) >>> > zmq/core/constants.c:1674: error: ?ZMQ_EVENTS? undeclared (first use in >>> this function) >>> > zmq/core/constants.c:1686: error: ?ZMQ_TYPE? undeclared (first use in >>> this function) >>> > zmq/core/constants.c:1698: error: ?ZMQ_LINGER? undeclared (first use in >>> this function) >>> > zmq/core/constants.c:1710: error: ?ZMQ_RECONNECT_IVL? undeclared (first >>> use in this function) >>> > zmq/core/constants.c:1722: error: ?ZMQ_BACKLOG? undeclared (first use >>> in this function) >>> > zmq/core/constants.c:1850: error: ?ZMQ_RECONNECT_IVL_MAX? undeclared >>> (first use in this function) >>> > error: command 'gcc' failed with exit status 1 >>> > >>> > >>> > _______________________________________________ >>> > IPython-dev mailing list >>> > IPython-dev at scipy.org >>> > http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >> >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Wed Jun 8 19:01:54 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 8 Jun 2011 16:01:54 -0700 Subject: [IPython-dev] trying to compile pyzmq In-Reply-To: References: Message-ID: EPD has installed zmq.h to /Library/Frameworks/EPD64.framework/Versions/7.0/include, then? If adding locations to include_dirs explicitly does not take precedence over the system defaults, then this is honestly a huge, critical bug in EPD itself, but I'm not 100% what's responsible for EPD being inappropriately prepended to the include path. The dirty, hackish answer would be to remove (or rename) the zmq headers installed by EPD, or install libzmq with a prefix of '/Library/Frameworks/EPD64.framework/Versions/7.0', thus clobbering the old libzmq. There shouldn't be any EPD code that requires the existence of the zmq *headers*, but if they do similar horrible things with library paths, then you will only get one step further, and need to remove/replace libzmq in EPD entirely. -MinRK On Wed, Jun 8, 2011 at 15:47, Satrajit Ghosh wrote: > hi min, > > unfortunately that didn't help. you can see from the output that the > configuration simply uses a limited set of directories, while the gcc > compilation during the build process lists the EPD include directory before > the include dir found by configure or setup.cfg > > output at: https://gist.github.com/1015631 > > cheers, > > satra > > > > On Wed, Jun 8, 2011 at 6:30 PM, MinRK wrote: > >> >> >> On Wed, Jun 8, 2011 at 15:06, Satrajit Ghosh wrote: >> >>> hi min >>> >>> found the file. i'm using EPD and since it bundles pyzmq, the include >>> path contains the old pyzmq. i'm trying to figure out a way to have this >>> pyzmq compile with my zmq instead of EPD's. >>> >> >> use `python setup.py configure --zmq=/path/to/install/prefix` to tell >> pyzmq where libzmq is installed. I'm a bit concerned by the how your >> configuration is inconsistent, such that LD finds your libzmq before EPD's, >> but gcc finds EPD's zmq.h before yours. >> >> In any case, specifying the zmq location should help. >> >> >>> >>> cheers, >>> >>> satra >>> >>> >>> >>> >>> On Mon, Jun 6, 2011 at 10:11 PM, Min RK wrote: >>> >>>> Hi, sorry you are having issues. >>>> >>>> Those values being undefined means the zmq.h that gcc is finding is old >>>> (pre-2.1.0, I think), but weirdly the libzmq the detection is finding is >>>> current. >>>> >>>> Try looking around for zmq.h, and removing the old one. >>>> >>>> -MinRK >>>> >>>> On Jun 6, 2011, at 18:39, Satrajit Ghosh wrote: >>>> >>>> > hi min and brian, >>>> > >>>> > trying to compile pyzmq, both from git clone master >>>> > >>>> > cheers, >>>> > >>>> > satra >>>> > >>>> > Configure: Autodetecting ZMQ settings... >>>> > Custom ZMQ dir: /software/venvs/EPD/7.0/ipxi >>>> > cc -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core >>>> -Izmq/devices -c detect/vers.c -o detect/vers.o >>>> > cc -arch x86_64 -undefined dynamic_lookup detect/vers.o >>>> -L/software/venvs/EPD/7.0/ipxi/lib -lzmq -o detect/vers >>>> > ZMQ version detected: 2.1.7 >>>> > ****************************************** >>>> > cythoning zmq/core/constants.pyx to zmq/core/constants.c >>>> > building 'zmq.core.constants' extension >>>> > creating build/temp.macosx-10.5-x86_64-2.7 >>>> > creating build/temp.macosx-10.5-x86_64-2.7/zmq >>>> > creating build/temp.macosx-10.5-x86_64-2.7/zmq/core >>>> > gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -DNDEBUG -g >>>> -O3 -arch x86_64 -I/Library/Frameworks/EPD64.framework/Versions/7.0/include >>>> -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core -Izmq/devices >>>> -I/software/venvs/EPD/7.0/ipxi/include >>>> -I/Library/Frameworks/EPD64.framework/Versions/7.0/include/python2.7 -c >>>> zmq/core/constants.c -o >>>> build/temp.macosx-10.5-x86_64-2.7/zmq/core/constants.o -Wno-unused-function >>>> -Wno-strict-aliasing >>>> > zmq/core/constants.c: In function ?initconstants?: >>>> > zmq/core/constants.c:1024: error: ?ZMQ_XPUB? undeclared (first use in >>>> this function) >>>> > zmq/core/constants.c:1024: error: (Each undeclared identifier is >>>> reported only once >>>> > zmq/core/constants.c:1024: error: for each function it appears in.) >>>> > zmq/core/constants.c:1036: error: ?ZMQ_XSUB? undeclared (first use in >>>> this function) >>>> > zmq/core/constants.c:1662: error: ?ZMQ_FD? undeclared (first use in >>>> this function) >>>> > zmq/core/constants.c:1674: error: ?ZMQ_EVENTS? undeclared (first use >>>> in this function) >>>> > zmq/core/constants.c:1686: error: ?ZMQ_TYPE? undeclared (first use in >>>> this function) >>>> > zmq/core/constants.c:1698: error: ?ZMQ_LINGER? undeclared (first use >>>> in this function) >>>> > zmq/core/constants.c:1710: error: ?ZMQ_RECONNECT_IVL? undeclared >>>> (first use in this function) >>>> > zmq/core/constants.c:1722: error: ?ZMQ_BACKLOG? undeclared (first use >>>> in this function) >>>> > zmq/core/constants.c:1850: error: ?ZMQ_RECONNECT_IVL_MAX? undeclared >>>> (first use in this function) >>>> > error: command 'gcc' failed with exit status 1 >>>> > >>>> > >>>> > _______________________________________________ >>>> > IPython-dev mailing list >>>> > IPython-dev at scipy.org >>>> > http://mail.scipy.org/mailman/listinfo/ipython-dev >>>> >>> >>> >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >>> >> > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Wed Jun 8 19:43:07 2011 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 08 Jun 2011 18:43:07 -0500 Subject: [IPython-dev] trying to compile pyzmq In-Reply-To: References: Message-ID: On 6/8/11 6:01 PM, MinRK wrote: > EPD has installed zmq.h to > /Library/Frameworks/EPD64.framework/Versions/7.0/include, then? If adding > locations to include_dirs explicitly does not take precedence over the system > defaults, then this is honestly a huge, critical bug in EPD itself, but I'm not > 100% what's responsible for EPD being inappropriately prepended to the include path. > > The dirty, hackish answer would be to remove (or rename) the zmq headers > installed by EPD, or install libzmq with a prefix of > '/Library/Frameworks/EPD64.framework/Versions/7.0', thus clobbering the old > libzmq. There shouldn't be any EPD code that requires the existence of the zmq > *headers*, but if they do similar horrible things with library paths, then you > will only get one step further, and need to remove/replace libzmq in EPD entirely. You can easily remove the 0MQ libraries and pyzmq from EPD, which is probably best, regardless: $ egginst --remove zeromq pyzmq I don't *think* we've modified distutils to prepend {sys.prefix}/include/. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From satra at mit.edu Wed Jun 8 19:49:11 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Wed, 8 Jun 2011 19:49:11 -0400 Subject: [IPython-dev] trying to compile pyzmq In-Reply-To: References: Message-ID: thanks min and robert. i went with removing the EPD libraries for now and the current pyzmq installed fine. cheers, satra On Wed, Jun 8, 2011 at 7:43 PM, Robert Kern wrote: > On 6/8/11 6:01 PM, MinRK wrote: > > EPD has installed zmq.h to > > /Library/Frameworks/EPD64.framework/Versions/7.0/include, then? If > adding > > locations to include_dirs explicitly does not take precedence over the > system > > defaults, then this is honestly a huge, critical bug in EPD itself, but > I'm not > > 100% what's responsible for EPD being inappropriately prepended to the > include path. > > > > The dirty, hackish answer would be to remove (or rename) the zmq headers > > installed by EPD, or install libzmq with a prefix of > > '/Library/Frameworks/EPD64.framework/Versions/7.0', thus clobbering the > old > > libzmq. There shouldn't be any EPD code that requires the existence of > the zmq > > *headers*, but if they do similar horrible things with library paths, > then you > > will only get one step further, and need to remove/replace libzmq in EPD > entirely. > > You can easily remove the 0MQ libraries and pyzmq from EPD, which is > probably > best, regardless: > > $ egginst --remove zeromq pyzmq > > I don't *think* we've modified distutils to prepend {sys.prefix}/include/. > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." > -- Umberto Eco > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Wed Jun 8 19:51:05 2011 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 08 Jun 2011 18:51:05 -0500 Subject: [IPython-dev] trying to compile pyzmq In-Reply-To: References: Message-ID: On 6/8/11 6:49 PM, Satrajit Ghosh wrote: > thanks min and robert. > > i went with removing the EPD libraries for now and the current pyzmq installed fine. Is the EPD include/ directory still showing up in the compile line? -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From satra at mit.edu Wed Jun 8 19:56:45 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Wed, 8 Jun 2011 19:56:45 -0400 Subject: [IPython-dev] trying to compile pyzmq In-Reply-To: References: Message-ID: hi robert, in fact as you can see below, both the compile step and the linking step includes the EPD include/lib directories. gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -DNDEBUG -g -O3 -arch x86_64 -I/Library/Frameworks/EPD64.framework/Versions/7.0/include -I/software/venvs/EPD/7.0/ipxi/include -Izmq/utils -Izmq/core -Izmq/devices -I/Library/Frameworks/EPD64.framework/Versions/7.0/include/python2.7 -c zmq/devices/monitoredqueue.c -o build/temp.macosx-10.5-x86_64-2.7/zmq/devices/monitoredqueue.o -Wno-unused-function -Wno-strict-aliasing gcc -g -arch x86_64 -L/usr/local/lib -L/Library/Frameworks/EPD64.framework/Versions/7.0/lib -bundle -undefined dynamic_lookup -g -arch x86_64 -L/usr/local/lib -L/Library/Frameworks/EPD64.framework/Versions/7.0/lib -arch x86_64 build/temp.macosx-10.5-x86_64-2.7/zmq/devices/monitoredqueue.o -L/software/venvs/EPD/7.0/ipxi/lib -lzmq -o build/lib.macosx-10.5-x86_64-2.7/zmq/devices/monitoredqueue.so cheers, satra On Wed, Jun 8, 2011 at 7:51 PM, Robert Kern wrote: > On 6/8/11 6:49 PM, Satrajit Ghosh wrote: > > thanks min and robert. > > > > i went with removing the EPD libraries for now and the current pyzmq > installed fine. > > Is the EPD include/ directory still showing up in the compile line? > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." > -- Umberto Eco > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ischnell at enthought.com Thu Jun 9 19:35:03 2011 From: ischnell at enthought.com (Ilan Schnell) Date: Thu, 9 Jun 2011 18:35:03 -0500 Subject: [IPython-dev] trying to compile pyzmq Message-ID: Hello Group, it is true that EPD installs zmq.h (anf many other header file, other than the Python ones) in /include. This way the headers are always on the include path, if you use distutils to compile C extensions. > EPD has installed zmq.h to > /Library/Frameworks/EPD64.framework/Versions/7.0/include, then? If adding > locations to include_dirs explicitly does not take precedence over the > system defaults, then this is honestly a huge, critical bug in EPD itself, > but I'm not 100% what's responsible for EPD being inappropriately prepended > to the include path. distuils is responsible this, so it is not a hugh critical bug in EPD itself, although one could argue that it is a bug in distutils. However, we don't want to change distutils default behavior in EPD. > The dirty, hackish answer would be to remove (or rename) the zmq headers > installed by EPD, or install libzmq with a prefix of > '/Library/Frameworks/EPD64.framework/Versions/7.0', thus clobbering the old > libzmq. There shouldn't be any EPD code that requires the existence of the > zmq *headers*, but if they do similar horrible things with library paths, > then you will only get one step further, and need to remove/replace libzmq > in EPD entirely. removing the zeromq EPD package, which includes the headers is a good solution. - Ilan From benjaminrk at gmail.com Thu Jun 9 20:42:28 2011 From: benjaminrk at gmail.com (MinRK) Date: Thu, 9 Jun 2011 17:42:28 -0700 Subject: [IPython-dev] trying to compile pyzmq In-Reply-To: References: Message-ID: On Thu, Jun 9, 2011 at 16:35, Ilan Schnell wrote: > Hello Group, > > it is true that EPD installs zmq.h (anf many other header file, > other than the Python ones) in /include. This way > the headers are always on the include path, if you use > distutils to compile C extensions. > Yes, it's definitely appropriate to install the headers there for development. Their presence is not the problem. > > > EPD has installed zmq.h to > > /Library/Frameworks/EPD64.framework/Versions/7.0/include, then? If > adding > > locations to include_dirs explicitly does not take precedence over the > > system defaults, then this is honestly a huge, critical bug in EPD > itself, > > but I'm not 100% what's responsible for EPD being inappropriately > prepended > > to the include path. > > distuils is responsible this, so it is not a hugh critical bug in EPD > itself, > although one could argue that it is a bug in distutils. However, we don't > want to change distutils default behavior in EPD. > I agree that you wouldn't want to change the behavior of distutils, but it is not accurate that distutils is entirely responsible. EPD's config/Makefile specifies `-I/include` dir in OPT, which ends up in CFLAGS, which comes *before* any user-specified include dirs. Python.org builds do not have any include dirs in this variable, and thus do not have this problem (possibly for this reason). The result is that EPD includes sysprefix/include *twice* - in the highest priority position via CFLAGS, and in the lowest priority position via normal channels. The latter doesn't cause any problems, but the former breaks user-specified include paths. If you edit /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/Makefile and remove the trailing '-I/Library...', from line 61 (starting `OPT=`) then configuration will be properly respected. Note that this does not remove the -I/include from compilation flags, it only removes the *duplicate* entry that placed it at the highest priority inappropriately. Since this is an issue that makes EPD behavior different from Python.org installs in a build-breaking way, I think it can rightly be considered an EPD bug, though it is distutils that pulls the EPD configuration into the compilation commands. However, it could also be considered a deliberate feature that EPD prevents the use of multiple versions of compiled libraries by overriding user preferences during compilation. -MinRK > > > The dirty, hackish answer would be to remove (or rename) the zmq headers > > installed by EPD, or install libzmq with a prefix of > > '/Library/Frameworks/EPD64.framework/Versions/7.0', thus clobbering the > old > > libzmq. There shouldn't be any EPD code that requires the existence of > the > > zmq *headers*, but if they do similar horrible things with library paths, > > then you will only get one step further, and need to remove/replace > libzmq > > in EPD entirely. > > removing the zeromq EPD package, which includes the headers is a good > solution. > > - Ilan > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Fri Jun 10 05:26:30 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 10 Jun 2011 10:26:30 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: Thanks, Carl. I'm no designer, so unless someone else comes forwards about a banner, I'll probably get back to you about it. Best wishes, Thomas On 10 June 2011 01:00, Carl Joseph Younger wrote: > I might be able to help you with a banner, I'm just in the middle of > something not fun with Google's blobstore API. If you haven't got it > sorted in the next few days, give me a nudge and I'll put something > together. > > Nice one > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Fri Jun 10 12:56:50 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Fri, 10 Jun 2011 12:56:50 -0400 Subject: [IPython-dev] task client equivalence Message-ID: what would be the ipy:xi equivalent of: taskclient.clear(taskid) given that currently no taskid is returned but an async result object, how do i clear things related to that process after its done? cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Fri Jun 10 14:17:00 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 10 Jun 2011 11:17:00 -0700 Subject: [IPython-dev] task client equivalence In-Reply-To: References: Message-ID: Since the controller uses a database rather than storing everything in memory, it should be less important (from a memory footprint perspective, anyway) to clear the data. It is now Client.purge_results(msg_ids) to clear data in the Hub (Views wrap this method as well). It expects msg_ids, but you can pass it AsyncResults, since they are just really just containers of msg_ids. -MinRK On Fri, Jun 10, 2011 at 09:56, Satrajit Ghosh wrote: > what would be the ipy:xi equivalent of: > > taskclient.clear(taskid) > > given that currently no taskid is returned but an async result object, how > do i clear things related to that process after its done? > > cheers, > > satra > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Jun 10 15:05:11 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 10 Jun 2011 12:05:11 -0700 Subject: [IPython-dev] Website - static files? Message-ID: Hi folks, well, ipython.org is now officially functioning, and over the next few days ipython.scipy.org will at some point become a redirect to that. Wohoo! BUT, we now need to figure out the static file issue. For a long time we've had a simple, static directory: http://ipython.scipy.org/dist/ that houses release files and other static content. This is handy for many reasons (easy to use, simply scp a file in there and anyone can get it, convenient archive of old stuff, etc). Pypi and possibly many other locations point to that, so it would be nice if we could have ipython.org/dist with similar functionality. Thomas, do you have some ideas on how to approach this with the github setup? Cheers, f From ellisonbg at gmail.com Fri Jun 10 15:14:47 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 10 Jun 2011 12:14:47 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: The github files area should allow us to host all of these things just fine. On Fri, Jun 10, 2011 at 12:05 PM, Fernando Perez wrote: > Hi folks, > > well, ipython.org is now officially functioning, and over the next few > days ipython.scipy.org will at some point become a redirect to that. > Wohoo! ? BUT, we now need to figure out the static file issue. ?For a > long time we've had a simple, static directory: > > http://ipython.scipy.org/dist/ > > that houses release files and other static content. ?This is handy for > many reasons (easy to use, simply scp a file in there and anyone can > get it, convenient archive of old stuff, etc). ?Pypi and possibly many > other locations point to that, so it would be nice if we could have > ipython.org/dist with similar functionality. > > Thomas, do you have some ideas on how to approach this with the github setup? > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Fri Jun 10 15:19:42 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 10 Jun 2011 12:19:42 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 12:14 PM, Brian Granger wrote: > The github files area should allow us to host all of these things just fine. Do you know if there's an easy way to upload/rsync/whatever a bunch of stuff to the files area on one shot? In fact, I actually don't know what the 'files area' is... I see the 'downloads' button but that's auto-generated from git release tags, so it's tied to the repo. Which is the area for static files? f From scorpion032 at gmail.com Fri Jun 10 15:36:48 2011 From: scorpion032 at gmail.com (Lakshman Prasad) Date: Sat, 11 Jun 2011 01:06:48 +0530 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: Just add the folder into the gh-pages branch git add folder git commit git push It will be accessible via ipython.org/folder-name I figure there is a bandwidth and/or file-size restriction for direct downloads. On Sat, Jun 11, 2011 at 12:49 AM, Fernando Perez wrote: > On Fri, Jun 10, 2011 at 12:14 PM, Brian Granger > wrote: > > The github files area should allow us to host all of these things just > fine. > > Do you know if there's an easy way to upload/rsync/whatever a bunch of > stuff to the files area on one shot? In fact, I actually don't know > what the 'files area' is... I see the 'downloads' button but that's > auto-generated from git release tags, so it's tied to the repo. Which > is the area for static files? > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Fri Jun 10 15:42:06 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 10 Jun 2011 12:42:06 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 12:19, Fernando Perez wrote: > On Fri, Jun 10, 2011 at 12:14 PM, Brian Granger > wrote: > > The github files area should allow us to host all of these things just > fine. > > Do you know if there's an easy way to upload/rsync/whatever a bunch of > stuff to the files area on one shot? In fact, I actually don't know > what the 'files area' is... I see the 'downloads' button but that's > auto-generated from git release tags, so it's tied to the repo. Which > is the area for static files? > Tags are automatically *added* to the downloads, but you can upload anything you want. There isn't an API for uploading files, but there are scripts for it: https://github.com/tekkub/github-upload Also note that pages repos are expected to serve static files, so they can be put in the repo just fine. -MinRK > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Fri Jun 10 15:58:45 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 10 Jun 2011 12:58:45 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: Yes, I meant the download area. You can manually post files in the download area as well, which we do for pyzmq. I would use that for static files that are releases/downloads and use the github files for other static stuff. On Fri, Jun 10, 2011 at 12:19 PM, Fernando Perez wrote: > On Fri, Jun 10, 2011 at 12:14 PM, Brian Granger wrote: >> The github files area should allow us to host all of these things just fine. > > Do you know if there's an easy way to upload/rsync/whatever a bunch of > stuff to the files area on one shot? ?In fact, I actually don't know > what the 'files area' is... I see the 'downloads' button but that's > auto-generated from git release tags, so it's tied to the repo. ?Which > is the area for static files? > > f > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Fri Jun 10 16:43:21 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 10 Jun 2011 21:43:21 +0100 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On 10 June 2011 20:05, Fernando Perez wrote: > well, ipython.org is now officially functioning, and over the next few > days ipython.scipy.org will at some point become a redirect to that. > Will ipython.scipy.org/moin/ still exist, or do we need to move some stuff to a Github wiki quickly? At present, the cookbook, 'developer zone' and list of projects that use IPython are still based on the moin wiki. > Wohoo! BUT, we now need to figure out the static file issue. For a > long time we've had a simple, static directory: > > http://ipython.scipy.org/dist/ > > that houses release files and other static content. This is handy for > many reasons (easy to use, simply scp a file in there and anyone can > get it, convenient archive of old stuff, etc). Pypi and possibly many > other locations point to that, so it would be nice if we could have > ipython.org/dist with similar functionality. > > Thomas, do you have some ideas on how to approach this with the github > setup? > I'd go with roughly what other people are talking about: files to download (like the releases) go in the Github downloads area, and other things can be served straight from the website, as the PDF docs already are. Not quite as convenient at the command line, perhaps, but I think it's workable. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Jun 10 16:48:46 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 10 Jun 2011 13:48:46 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 1:43 PM, Thomas Kluyver wrote: > Will ipython.scipy.org/moin/ still exist, or do we need to move some stuff > to a Github wiki quickly? At present, the cookbook, 'developer zone' and > list of projects that use IPython are still based on the moin wiki. No, we'll need to move to a new wiki. But I did ask the Enthought admin to keep a domain like oldipython.scipy.org for a while, so we can go fish anything we may have missed (and I still have ssh access to the underlying account, if need be). >> Wohoo! ? BUT, we now need to figure out the static file issue. ?For a >> long time we've had a simple, static directory: >> >> http://ipython.scipy.org/dist/ >> >> that houses release files and other static content. ?This is handy for >> many reasons (easy to use, simply scp a file in there and anyone can >> get it, convenient archive of old stuff, etc). ?Pypi and possibly many >> other locations point to that, so it would be nice if we could have >> ipython.org/dist with similar functionality. >> >> Thomas, do you have some ideas on how to approach this with the github >> setup? > > I'd go with roughly what other people are talking about: files to download > (like the releases) go in the Github downloads area, and other things can be > served straight from the website, as the PDF docs already are. Not quite as > convenient at the command line, perhaps, but I think it's workable. Fine by me, but two questions: - places like pypi expect a base url for downloads (what our old dist/ one did) and they go fishing in there for files (eggs, sources, etc). Would the GH downloads area still work for that? - the dist/ area is BIG, as in 400MB big right now. Before I push that, I want to make sure everyone saying that we go that route is OK with it :) I don't have time right now to spend a few hours pruning old files, and I also *want* a public archive of all our old versions, so simply deleting all the old releases is not on the table. I can push that dist/ as-is right now, but the next git pull of that repo will be hefty for those working with it :) Cheers, f From benjaminrk at gmail.com Fri Jun 10 17:28:26 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 10 Jun 2011 14:28:26 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 13:48, Fernando Perez wrote: > On Fri, Jun 10, 2011 at 1:43 PM, Thomas Kluyver wrote: > > Will ipython.scipy.org/moin/ still exist, or do we need to move some > stuff > > to a Github wiki quickly? At present, the cookbook, 'developer zone' and > > list of projects that use IPython are still based on the moin wiki. > > No, we'll need to move to a new wiki. But I did ask the Enthought > admin to keep a domain like oldipython.scipy.org for a while, so we > can go fish anything we may have missed (and I still have ssh access > to the underlying account, if need be). > > >> Wohoo! BUT, we now need to figure out the static file issue. For a > >> long time we've had a simple, static directory: > >> > >> http://ipython.scipy.org/dist/ > >> > >> that houses release files and other static content. This is handy for > >> many reasons (easy to use, simply scp a file in there and anyone can > >> get it, convenient archive of old stuff, etc). Pypi and possibly many > >> other locations point to that, so it would be nice if we could have > >> ipython.org/dist with similar functionality. > >> > >> Thomas, do you have some ideas on how to approach this with the github > >> setup? > > > > I'd go with roughly what other people are talking about: files to > download > > (like the releases) go in the Github downloads area, and other things can > be > > served straight from the website, as the PDF docs already are. Not quite > as > > convenient at the command line, perhaps, but I think it's workable. > > Fine by me, but two questions: > > - places like pypi expect a base url for downloads (what our old dist/ > one did) and they go fishing in there for files (eggs, sources, etc). > Would the GH downloads area still work for that? > Yes - if you've ever pip installed pyzmq you got it from the GitHub downloads page. > > - the dist/ area is BIG, as in 400MB big right now. Before I push > that, I want to make sure everyone saying that we go that route is OK > with it :) I don't have time right now to spend a few hours pruning > old files, and I also *want* a public archive of all our old versions, > so simply deleting all the old releases is not on the table. I can > push that dist/ as-is right now, but the next git pull of that repo > will be hefty for those working with it :) > I didn't realize just how huge it was. As it stands, GitHub is not a good place to put lots of large files. We will quickly run into the free-account storage limit (300MB) if we dump every old binary release there. As Brian said, I think the IPython install downloads should *not* go in the pages repo, but rather in the GitHub Downloads section, but we may want to limit that to >= 0.10. If we want to keep bdists in perpetuity, we need somewhere else. *New* releases, though, should certainly be in the GitHub downloads section. -MinRK > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Fri Jun 10 17:35:08 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 10 Jun 2011 22:35:08 +0100 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On 10 June 2011 22:28, MinRK wrote: > As it stands, GitHub is not a good place to put lots of large files. We > will quickly run into the free-account storage limit (300MB) if we dump > every old binary release there. Would Enthought object to us simply leaving it where it already is? It's a bit of hard drive space, but if new releases are on Github, the bandwidth used should be minimal. Impressive, though, that we still have every version back to 0.0.1 (last modified almost a decade ago). Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Jun 10 18:19:22 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 10 Jun 2011 15:19:22 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 2:35 PM, Thomas Kluyver wrote: > > Would Enthought object to us simply leaving it where it already is? It's a > bit of hard drive space, but if new releases are on Github, the bandwidth > used should be minimal. I doubt it, it's not like they're kicking us out :) I just want a sensible solution from the DNS perspective, since ipython.scipy.org will redirect to ipython.org, we don't want a circular redirect. I don't know much about DNS... Is it possible to have ipython.org point to github, but something like archive.ipython.org be elsewhere? In that case, we can even host it at my dreamhost account, where I control the DNS and have unlimited storage. > Impressive, though, that we still have every version back to 0.0.1 (last > modified almost a decade ago). Yup, and I want to keep it that way. Those should remain publicly available for the foreseeable future, I think it's important to have a long-term archival view of these things. Cheers, f From fperez.net at gmail.com Fri Jun 10 18:36:18 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 10 Jun 2011 15:36:18 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 1:48 PM, Fernando Perez wrote: > No, we'll need to move to a new wiki. And BTW, it's worth asking whether the github wiki really is the best option: what I don't like about it, is that it has a very strongly developer-oriented feel, because it's inside the repo area. I wonder if for general user issues, a standalone wiki instance (we could just run a more recent version of moin, or something else, ourselves), isn't a nicer solution. I love github as much as anyone else, but I don't think we need to blindly use github for everything just because it's github. We should evaluate each of the tools they offer and use it only if it's a good fit for what we're trying to do. In this case, our wiki should be mostly a place to collect community/user feedback with a very low barrier of entry. Before it was also our main website, but that's gone, so we can focus on making it as nice and useful as possible for the use case we actually need it for. Best, f From takowl at gmail.com Fri Jun 10 18:47:21 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 10 Jun 2011 23:47:21 +0100 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On 10 June 2011 23:19, Fernando Perez wrote: > I don't know much about DNS... Is it possible to have ipython.org > point to github, but something like archive.ipython.org be elsewhere? > In that case, we can even host it at my dreamhost account, where I > control the DNS and have unlimited storage. > Yes, I think it should be. I'm not a DNS guru, but as far as I know you should be able to set an A or CNAME record for any subdomain. Re: wikis - Github has the advantage that it means most of our user interaction is on one system, so we're not needlessly giving people another username and password. That said, you're right that Github is really a developer site. Some of the content could be moved onto the website proper. But, I think we have some stuff - especially the 'cookbook', which people outside the core team should be able to update easily (without branching and sending a pull request). What's the best way to do this? We could almost put the recipes in something like gist, but with the idea of a collection. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Fri Jun 10 18:52:56 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 10 Jun 2011 15:52:56 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 15:47, Thomas Kluyver wrote: > On 10 June 2011 23:19, Fernando Perez wrote: > >> I don't know much about DNS... Is it possible to have ipython.org >> point to github, but something like archive.ipython.org be elsewhere? >> In that case, we can even host it at my dreamhost account, where I >> control the DNS and have unlimited storage. >> > > Yes, I think it should be. I'm not a DNS guru, but as far as I know you > should be able to set an A or CNAME record for any subdomain. > Yes, you can have (infinite?) subdomains that have no relation whatsoever to where your top domain points. I have used this to point to friends' computers who don't have a domain name, just so I don't have to remember their IP. > > Re: wikis - Github has the advantage that it means most of our user > interaction is on one system, so we're not needlessly giving people another > username and password. That said, you're right that Github is really a > developer site. > > Some of the content could be moved onto the website proper. But, I think we > have some stuff - especially the 'cookbook', which people outside the core > team should be able to update easily (without branching and sending a pull > request). What's the best way to do this? We could almost put the recipes in > something like gist, but with the idea of a collection. > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Jun 10 18:57:38 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 10 Jun 2011 15:57:38 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 3:47 PM, Thomas Kluyver wrote: > Some of the content could be moved onto the website proper. But, I think we > have some stuff - especially the 'cookbook', which people outside the core > team should be able to update easily (without branching and sending a pull > request). A FAQ is also a good thing for users to be able to contribute to, as is a list of projects using ipython, or of external talks/presentations, etc. There are good use cases for a wiki, and one that should be friendly to users beyond the git-oriented developers. That's why I'm not yet sold on github being the right place for the wiki. This is the exact reason why years ago we moved from Trac as our wiki, and I think the same applies to github. Cheers, f From ellisonbg at gmail.com Fri Jun 10 19:24:24 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 10 Jun 2011 16:24:24 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 1:48 PM, Fernando Perez wrote: > On Fri, Jun 10, 2011 at 1:43 PM, Thomas Kluyver wrote: >> Will ipython.scipy.org/moin/ still exist, or do we need to move some stuff >> to a Github wiki quickly? At present, the cookbook, 'developer zone' and >> list of projects that use IPython are still based on the moin wiki. > > No, we'll need to move to a new wiki. ?But I did ask the Enthought > admin to keep a domain like oldipython.scipy.org for a while, so we > can go fish anything we may have missed (and I still have ssh access > to the underlying account, if need be). > >>> Wohoo! ? BUT, we now need to figure out the static file issue. ?For a >>> long time we've had a simple, static directory: >>> >>> http://ipython.scipy.org/dist/ >>> >>> that houses release files and other static content. ?This is handy for >>> many reasons (easy to use, simply scp a file in there and anyone can >>> get it, convenient archive of old stuff, etc). ?Pypi and possibly many >>> other locations point to that, so it would be nice if we could have >>> ipython.org/dist with similar functionality. >>> >>> Thomas, do you have some ideas on how to approach this with the github >>> setup? >> >> I'd go with roughly what other people are talking about: files to download >> (like the releases) go in the Github downloads area, and other things can be >> served straight from the website, as the PDF docs already are. Not quite as >> convenient at the command line, perhaps, but I think it's workable. > > Fine by me, but two questions: > > - places like pypi expect a base url for downloads (what our old dist/ > one did) and they go fishing in there for files (eggs, sources, etc). > Would the GH downloads area still work for that? Yep: https://github.com/zeromq/pyzmq/downloads > - the dist/ area is BIG, as in 400MB big right now. ?Before I push > that, I want to make sure everyone saying that we go that route is OK > with it :) ?I don't have time right now to spend a few hours pruning > old files, and I also *want* a public archive of all our old versions, > so simply deleting all the old releases is not on the table. ?I can > push that dist/ as-is right now, but the next git pull of that repo > will be hefty for those working with it :) Let's not push all of this to the github files. Here is what I am thinking: * Prune older binary releases (pre 0.10). * Upload the newer binary+source releases and older source releases to github downloads. * See how big the rest of dist is and push that to the github files. > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From ellisonbg at gmail.com Fri Jun 10 19:31:33 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 10 Jun 2011 16:31:33 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 3:36 PM, Fernando Perez wrote: > On Fri, Jun 10, 2011 at 1:48 PM, Fernando Perez wrote: >> No, we'll need to move to a new wiki. > > And BTW, it's worth asking whether the github wiki really is the best > option: what I don't like about it, is that it has a very strongly > developer-oriented feel, because it's inside the repo area. ?I wonder > if for general user issues, a standalone wiki instance (we could just > run a more recent version of moin, or something else, ourselves), > isn't a nicer solution. ?I love github as much as anyone else, but I > don't think we need to blindly use github for everything just because > it's github. ?We should evaluate each of the tools they offer and use > it only if it's a good fit for what we're trying to do. I think that the github wiki is a good option, mainly because (I think) it solves all of the problem of who can edit the wiki. Moin is a nightmare for that and forces us to manage users by hand. Also, in my mind, github is not just for developers in that it hosts our issue and downloads which both are user focused. But if we do want a separate wiki, I am -1 on Moin. I have not been impressed with it at all. We would have to go searching for alternatives... > In this case, our wiki should be mostly a place to collect > community/user feedback with a very low barrier of entry. ?Before it > was also our main website, but that's gone, so we can focus on making > it as nice and useful as possible for the use case we actually need it > for. > > Best, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Fri Jun 10 20:00:03 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 10 Jun 2011 17:00:03 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 4:24 PM, Brian Granger wrote: > Let's not push all of this to the github files. ?Here is what I am thinking: > > * Prune older binary releases (pre 0.10). > * Upload the newer binary+source releases and older source releases to > github downloads. > * See how big the rest of dist is and push that to the github files. > Well, it seems the alternative of archive.ipython.org is simpler: just push everything we had in dist/ there and be done with it. All new releases would be archived there, but the official entry point would be the github downloads area. f From fperez.net at gmail.com Fri Jun 10 20:10:16 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 10 Jun 2011 17:10:16 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 4:31 PM, Brian Granger wrote: > I think that the github wiki is a good option, mainly because (I > think) it solves all of the problem of who can edit the wiki. ?Moin is The github wikis don't have a search feature at all, that seems to be a pretty major oversight to me... But I haven't played with them at all in practice, so perhaps it's hidden somewhere. > a nightmare for that and forces us to manage users by hand. ?Also, in Well, what is really the nightmare? Moin automatically manages user creation, it's just that we made an ACL to restrict writing to members of the WritersGroup. That means that for a new user to get write privileges, someone has to add them to this page: http://ipython.scipy.org/moin/WritersGroup Reading this: http://ipython.scipy.org/moin/WritersGroup?action=info This page has seen a total of 15 edits in the last three years, all by me. That hardly qualifies as a nightmare, and that's all there is to it. What else did you have in mind that's an actual, concrete problem with Moin? > my mind, github is not just for developers in that it hosts our issue > and downloads which both are user focused. That is true, though I think a class of user exists who just wants to read some info on a simple wiki (and who might get confused by all the UI controls at the top of every github wiki), that is different from the user willing to file a bug report. Basically what I'm saying is that I don't think github is the most newbie-friendly wiki environment out there, given its lack of search and the fact that all the Github-specific machinery remains exposed always. > But if we do want a separate wiki, I am -1 on Moin. ?I have not been > impressed with it at all. ?We would have to go searching for > alternatives... I'm not particularly partial to it, but honestly I don't see what the problem is either. What specific problems do you have with it? In my mind the only real issue was spam, and with the WritersGroup trick it simply vanished over three years ago. As for the rest, it: - supports reST natively (hugely important for us, so we can easily move wiki content over to the docs). - supports images and attachments - is searchable - we already know how to use it. I'm not opposed to changing systems, but I would like to see concrete problems with Moin that force us to change before we take that step (which will cost us time). Cheers, f From takowl at gmail.com Fri Jun 10 20:29:54 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 11 Jun 2011 01:29:54 +0100 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On 11 June 2011 01:10, Fernando Perez wrote: > That means that for a new user to get write > privileges, someone has to add them to this page: > > http://ipython.scipy.org/moin/WritersGroup > FWIW, whatever system we end up with, I think we should allow any registered (and captcha-ed) user to edit, except maybe for a couple of critical pages. If editing's any harder than it needs to be, the content just ends up out of date. If the software doesn't keep spam low enough that we can revert what gets through, then we should consider switching to a system that can. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Jun 10 20:37:52 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 10 Jun 2011 17:37:52 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 5:29 PM, Thomas Kluyver wrote: > FWIW, whatever system we end up with, I think we should allow any registered > (and captcha-ed) user to edit, except maybe for a couple of critical pages. > If editing's any harder than it needs to be, the content just ends up out of > date. If the software doesn't keep spam low enough that we can revert what > gets through, then we should consider switching to a system that can. The reason we added that was precisely because we were having to spend way too much time reverting stuff. But the version of Moin on scipy.org had no captcha, only registration. Basically the balance was: - register plus email once to get added to the list, edit at will, *zero* spam for three years. - register only: endless spam. I don't know where in that continuum of zero-to-infinite spam a captcha system would put us. Honestly, it doesn't seem to me that asking people to send a single email for human authorization is a huge burden that is really causing us to lose us a lot of contributors, and it does cut *completely* the spam problem. But perhaps it is causing them to go away... Cheers, f From takowl at gmail.com Fri Jun 10 20:58:32 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 11 Jun 2011 01:58:32 +0100 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On 11 June 2011 01:37, Fernando Perez wrote: > The reason we added that was precisely because we were having to spend > way too much time reverting stuff. But the version of Moin on > scipy.org had no captcha, only registration. > Then this is a failure in the software. Newer versions of Moin seem to be able to have CAPTCHAs, and there various other things you can do about spam: http://www.mediawiki.org/wiki/Manual:Combating_spam > I don't know where in that continuum of zero-to-infinite spam a > captcha system would put us. Honestly, it doesn't seem to me that > asking people to send a single email for human authorization is a huge > burden that is really causing us to lose us a lot of contributors, and > it does cut *completely* the spam problem. But perhaps it is causing > them to go away... > It's not so much that it's a burden. It's just that when you see a paragraph that's out of date, or a broken link, or whatever, and you can click edit and fix it immediately, people do (some people, anyway). If you've got to set up an account, then get someone to give you edit permission...never mind, there's better things to be getting on with. It's for a similar reason that I advocate using an existing, popular site like Github. If I have to register for a new account, or spend two minutes guessing which password I chose for this site two years ago, the chances that I will bother decay exponentially with the time I expect it to take. Maybe this is a solution, if we have a ruby-capable server somewhere: have a github wiki mirrored somewhere else, so we can link to it (read-only) without the github branding. http://smeagolrb.info/ Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Jun 10 21:10:27 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 10 Jun 2011 18:10:27 -0700 Subject: [IPython-dev] Website - static files? In-Reply-To: References: Message-ID: On Fri, Jun 10, 2011 at 5:58 PM, Thomas Kluyver wrote: > Then this is a failure in the software. Newer versions of Moin seem to be > able to have CAPTCHAs, and there various other things you can do about spam: > http://www.mediawiki.org/wiki/Manual:Combating_spam Yes, that's certainly true (though that's a mediawiki page, similar things apply to moin). The moin on scipy.org is ancient, I'm sure current versions at least have captcha (for the record, it might be possible to enable it on the scipy moin, it's just that dealing with so many old libraries there is too painful to consider). >> I don't know where in that continuum of zero-to-infinite spam a >> captcha system would put us. ?Honestly, it doesn't seem to me that >> asking people to send a single email for human authorization is a huge >> burden that is really causing us to lose us a lot of contributors, and >> it does cut *completely* the spam problem. ?But perhaps it is causing >> them to go away... > > It's not so much that it's a burden. It's just that when you see a paragraph > that's out of date, or a broken link, or whatever, and you can click edit > and fix it immediately, people do (some people, anyway). If you've got to > set up an account, then get someone to give you edit permission...never > mind, there's better things to be getting on with. It's for a similar reason > that I advocate using an existing, popular site like Github. If I have to > register for a new account, or spend two minutes guessing which password I > chose for this site two years ago, the chances that I will bother decay > exponentially with the time I expect it to take. Yes, that's true. I'm all for finding whatever balances ease of use/contributions with burden on maintainers. Because while it's very important that we make it as easy as possible to contribute, we really don't have the time to be doing spam cleanup frequently. We've had users in the past who have kindly helped with that boring task, but I'm not sure we want to rely on that, as I think that's a waste of *anyone's* time, not just mine :) > Maybe this is a solution, if we have a ruby-capable server somewhere: have a > github wiki mirrored somewhere else, so we can link to it (read-only) > without the github branding. > http://smeagolrb.info/ We can use the dreamhost setup for that, though it's a simple shared host with limited cpu quotas. But I can't imagine that kind of static mirroring being very cpu intensive. Let's think what the requirements are for a wiki for us: - reST support. - images/attachments. - search function - spam control - low barrier for new users to contribute (use existing authentication or allow on-the-spot editing with good captcha or similar). - ease of deployment and ongoing maintenance for the team (we have preciously little time for all of this, so even moin loses big on this front vs. github, which is already done). What else? With clear criteria we can see what meets which from the tools available, and then decide on the best compromise (likely nothing will be perfect on all). Cheers, f From takowl at gmail.com Sat Jun 11 08:07:55 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 11 Jun 2011 13:07:55 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: Hi Carl, The live site is at http://ipython.org/ , and the source code is at https://github.com/ipython/ipython-website . In terms of the logo, I think the only visually distinctive thing about IPython are the prompts, which inspired the existing IP[y] logo. We could also have some reference to the yellow & blue Python logo ( http://python.org/), but on the other hand, we're pitching this as an environment for data exploration and interactive computing in general, not only as a Python shell. I've CCed in the dev list - Carl has offered to design some sort of banner-style logo for the top of our website (see the sites for matplotlib and sphinx for examples). Any suggestions on what it should look like? Do we have any theme it should fit in with? Finally, don't spend too long doing this, because it's been suggested that if IPython gets some funding, some of it might go on professional design for this sort of thing. I understand that this isn't definite, though. Thanks, Thomas On 11 June 2011 02:51, Carl Joseph Younger wrote: > Hi Thomas ~ Can you send me a link to the new site, I can't find it in > my inbox. Also, if you can provide a few pointers as to what you'd > like for the banner and stuff, I'll have a look and see what I can do. > > All the best > Carl > > On Fri, Jun 10, 2011 at 10:26 AM, Thomas Kluyver wrote: > > Thanks, Carl. I'm no designer, so unless someone else comes forwards > about a > > banner, I'll probably get back to you about it. > > > > Best wishes, > > Thomas > > > > On 10 June 2011 01:00, Carl Joseph Younger wrote: > >> > >> I might be able to help you with a banner, I'm just in the middle of > >> something not fun with Google's blobstore API. If you haven't got it > >> sorted in the next few days, give me a nudge and I'll put something > >> together. > >> > >> Nice one > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From klonuo at gmail.com Sat Jun 11 09:06:52 2011 From: klonuo at gmail.com (Klonuo Umom) Date: Sat, 11 Jun 2011 15:06:52 +0200 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: <20110611150650.80B3.B1C76292@gmail.com> Hi, I just saw demo page, and please allow me to comments that Sphinx system looks great as always, but header on demo page does not look good. It's too dark with unnecessary gradient background image. Following Sphinx or matplotlib portal, with some graphic is good idea, and other is just try same colors as footer for header wrapper (together with 3/4px bottom border) Cheers On 11.06.2011 14:07:55 Thomas Kluyver wrote: > Hi Carl, > > The live site is at http://ipython.org/ , and the source code is at > https://github.com/ipython/ipython-website . > > In terms of the logo, I think the only visually distinctive thing about > IPython are the prompts, which inspired the existing IP[y] logo. We could > also have some reference to the yellow & blue Python logo ( > http://python.org/), but on the other hand, we're pitching this as an > environment for data exploration and interactive computing in general, not > only as a Python shell. > > I've CCed in the dev list - Carl has offered to design some sort of > banner-style logo for the top of our website (see the sites for matplotlib > and sphinx for examples). Any suggestions on what it should look like? Do we > have any theme it should fit in with? > > Finally, don't spend too long doing this, because it's been suggested that > if IPython gets some funding, some of it might go on professional design for > this sort of thing. I understand that this isn't definite, though. > > Thanks, > Thomas > From takowl at gmail.com Sat Jun 11 10:37:51 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 11 Jun 2011 15:37:51 +0100 Subject: [IPython-dev] Website In-Reply-To: <20110611150650.80B3.B1C76292@gmail.com> References: <20110611150650.80B3.B1C76292@gmail.com> Message-ID: On 11 June 2011 14:06, Klonuo Umom wrote: > Hi, I just saw demo page, and please allow me to comments that Sphinx > system looks great as always, but header on demo page does not look > good. It's too dark with unnecessary gradient background image. > I agree the header could be better. Let's work this out when we've got a banner logo, though. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Jun 11 11:02:12 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 11 Jun 2011 08:02:12 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Sat, Jun 11, 2011 at 5:07 AM, Thomas Kluyver wrote: > > In terms of the logo, I think the only visually distinctive thing about > IPython are the prompts, which inspired the existing IP[y] logo. We could > also have some reference to the yellow & blue Python logo > (http://python.org/), but on the other hand, we're pitching this as an > environment for data exploration and interactive computing in general, not > only as a Python shell. > > I've CCed in the dev list - Carl has offered to design some sort of > banner-style logo for the top of our website (see the sites for matplotlib > and sphinx for examples). Any suggestions on what it should look like? Do we > have any theme it should fit in with? I've never had any graphics design talent, unfortunately, so all I can do is thank those willing to help us on that front (it really is much appreciated). From the ideas side, though, I think it's worth opening up beyond the prompts metaphor. It's true that IPython is more of a library/environment and up until now it was only a console app and the twisted-based parallel code. That made it kind of hard to come up with nice visually impacting logos that would directly resonate with the project's everyday use. I think Min did a great job with the original logo, which we've used for a few years. But (hopefully Min or nobody else will object) I'd be open to some fresh thinking on that front, perhaps something can be designed that better conveys all the new machinery and use cases we now have: - terminal-based interactive work - rich console (Qt) with control over the Python VM (as embodied by an IPython kernel) - web console/notebook - lightweight parallel system, with interactive capabilities I know that IPython isn't the easiest project to capture in a logo. So go crazy with ideas, and please post anything you come up with for review! Many thanks in advance for this help. Cheers, f ps - in the end, whatever image(s) are chosen should be committed to the repo in inkscape-editable SVG format so they can be worked on with fully open source tools always (it's OK if the author works with other apps that may be better than inkscape, but the final version should be editable with open tools). For convenience, committing a couple of PNG renders at various common resolutions is fine, so people using the logos in everyday work don't have to re-render them all the time. From ellisonbg at gmail.com Sun Jun 12 18:18:51 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 12 Jun 2011 15:18:51 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: Some feeedback on the current design: * Some of the main elements that make the Sphinx design nice are missing: - The navigation bar between the banner and the rest of the content is not there. - In the right panel, the nice colored boxes that divide the content vertically are also gone. - The vertical colored regions to the L and R of the content are gone. These nicely frame the content. Can we *start* out using the default Sphinx template and then identify things we want to change/customize for our purposes. My preference would be the following order: 1. First address the content. This would include getting the navigation elements to point to our pages etc. 2. Then come up with a custom color scheme. There are a number of online tools for helping pick color schemes. 3. Then pick a font for "IPython" and create a banner based on that and the color scheme. 4. Only then start to make minor tweaks to the actual layout as needed. I recommend this order of things, because the layout should be created to support/frame the content, not the other way around. Cheers, Brian On Wed, Jun 8, 2011 at 10:25 AM, Thomas Kluyver wrote: > I've put the built website up so it's easy to evaluate: > > http://takluyver.github.com/ipython-website/ > > Please have a look, and let me know of any broken links, out of date > information, and so on. I think it's an improvement on the moin wiki, so > barring any major problems, I'd hope it can go live alongside or before the > 0.11 release. > > Thanks, > Thomas > > On 6 June 2011 13:03, Thomas Kluyver wrote: >> >> The website in my fork of Komal's repository is now (hopefully) up to date >> and intact. >> >> https://github.com/takluyver/ipython-website >> >> Cookbook, Developer zone, and Projects using IPython are, for now, links >> pointing to the moin wiki. News is up to date, version numbers should be >> correct, and the content on the homepage has been cut down. The favicon is a >> bland placeholder until someone feels like designing a decent one. >> >> Please do build it and let me know if you spot any mistakes or omissions. >> >> Thanks, >> Thomas > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From ellisonbg at gmail.com Sun Jun 12 18:22:16 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Sun, 12 Jun 2011 15:22:16 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: For example: http://colorschemedesigner.com/ On Sun, Jun 12, 2011 at 3:18 PM, Brian Granger wrote: > Some feeedback on the current design: > > * Some of the main elements that make the Sphinx design nice are missing: > > - The navigation bar between the banner and the rest of the content is > not there. > - In the right panel, the nice colored boxes that divide the content > vertically are also gone. > - The vertical colored regions to the L and R of the content are gone. > ?These nicely frame the content. > > Can we *start* out using the default Sphinx template and then identify > things we want to change/customize for our purposes. ?My preference > would be the following order: > > 1. ?First address the content. ?This would include getting the > navigation elements to point to our pages etc. > 2. ?Then come up with a custom color scheme. ?There are a number of > online tools for helping pick color schemes. > 3. ?Then pick a font for "IPython" and create a banner based on that > and the color scheme. > 4. ?Only then start to make minor tweaks to the actual layout as needed. > > I recommend this order of things, because the layout should be created > to support/frame the content, not the other way around. > > Cheers, > > Brian > > On Wed, Jun 8, 2011 at 10:25 AM, Thomas Kluyver wrote: >> I've put the built website up so it's easy to evaluate: >> >> http://takluyver.github.com/ipython-website/ >> >> Please have a look, and let me know of any broken links, out of date >> information, and so on. I think it's an improvement on the moin wiki, so >> barring any major problems, I'd hope it can go live alongside or before the >> 0.11 release. >> >> Thanks, >> Thomas >> >> On 6 June 2011 13:03, Thomas Kluyver wrote: >>> >>> The website in my fork of Komal's repository is now (hopefully) up to date >>> and intact. >>> >>> https://github.com/takluyver/ipython-website >>> >>> Cookbook, Developer zone, and Projects using IPython are, for now, links >>> pointing to the moin wiki. News is up to date, version numbers should be >>> correct, and the content on the homepage has been cut down. The favicon is a >>> bland placeholder until someone feels like designing a decent one. >>> >>> Please do build it and let me know if you spot any mistakes or omissions. >>> >>> Thanks, >>> Thomas >> >> > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Sun Jun 12 19:01:55 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 13 Jun 2011 00:01:55 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 12 June 2011 23:18, Brian Granger wrote: > - The navigation bar between the banner and the rest of the content is > not there. > I don't think it would fit with what we're doing. Navigation links are on the right. Arguably the most important part of this site is the 'menu' of the various resources related to IPython - we can't cram that into a horizontal bar, and splitting the links up would make it less clear. > - In the right panel, the nice colored boxes that divide the content > vertically are also gone. > - The vertical colored regions to the L and R of the content are gone. > These nicely frame the content. > These are style choices embedded in the theme we're using, called 'agogo'. It's easy enough to change each if you want to, but I'm not sure that they'd particularly improve the appearance. For reasons previously mentioned, I *don't* want this to look like other Sphinx sites. We're using Sphinx here as a tool to separate content (the rst files) from the layout, not to produce a documentation site. As long as the layout works technically and aesthetically, I don't want to change it to be more like the default Sphinx output. I'm quite happy to accept criticism on the layout, but please don't start with an expectation of the standard Sphinx layout. > 1. First address the content. This would include getting the > navigation elements to point to our pages etc. I think all the links are already correct - please let me know if not. > 2. Then come up with a custom color scheme. There are a number of > online tools for helping pick color schemes. I spent some time trying this (using Adobe Kuler), but eventually I decided to leave it to someone with more artistic talent - possibly someone paid to do it. That said, I don't think the colour scheme in agogo (grey, blue, orange) is too ugly. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Tue Jun 14 14:05:35 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 14 Jun 2011 11:05:35 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: Thomas, On Sun, Jun 12, 2011 at 4:01 PM, Thomas Kluyver wrote: > On 12 June 2011 23:18, Brian Granger wrote: >> >> - The navigation bar between the banner and the rest of the content is >> not there. > > I don't think it would fit with what we're doing. Navigation links are on > the right. Arguably the most important part of this site is the 'menu' of > the various resources related to IPython - we can't cram that into a > horizontal bar, and splitting the links up would make it less clear. I agree that the main navigation area is the R panel, but visually I think we need the division between the banner and content that the horizontal bar provides. This is a common design element seen in many website. The horizontal navigation area can include a reduced set of links (for example, on fperez.org, he just has a "Home" link). In terms of splitting up the links, I think there are some natural divisions on links: * Internal links to other places on the website. * Links to the "community": lists, github, wiki, IRC * Downloads. * Links to the documentation. I think it does make sense to put the internal links in the horizontal navigation bar, but there could be something else in this horizontal divider. Currently, these different types of links are all grouped together in the R panel, which creates a disorganized look. Splitting the R panel vertically and using visual elements to partition the different types of links makes sense - not because that is what Sphinx does by default, but because it organizes the material in a way that helps users. >> >> - In the right panel, the nice colored boxes that divide the content >> vertically are also gone. >> - The vertical colored regions to the L and R of the content are gone. >> ?These nicely frame the content. > > These are style choices embedded in the theme we're using, called 'agogo'. > It's easy enough to change each if you want to, but I'm not sure that they'd > particularly improve the appearance. > > For reasons previously mentioned, I *don't* want this to look like other > Sphinx sites. We're using Sphinx here as a tool to separate content (the rst > files) from the layout, not to produce a documentation site. As long as the > layout works technically and aesthetically, I don't want to change it to be > more like the default Sphinx output. I'm quite happy to accept criticism on > the layout, but please don't start with an expectation of the standard > Sphinx layout. This is what I meant to communicate: I don't think the current layout works technically and aesthetically. I am not particularly attached to the Sphinx layout specifically. The particular things the current design is missing are: * A horizontal divider between the banner and main content area. I don't particularly care that this has navigation links, but visually, we need something to divide these areas. * The width of the content needs to be made smaller than the browser Window to frame the content. Using an alternate color in the R and L page margines is one option (what Sphinx does), but we could simply leave it as white space. With todays wide screen monitors, content looks awkward if it spans the entire width of the Window - like reading a book without margins. * We need to use a single font for the entire website, not counting the one used for the banner. Mixing serif and sans-serif fonts creates a look that is visually disjoint. * The R panel needs to have vertical regions that are visually separated that allow us to group different categories of links together (internal, community, docs, downloads). I don't care that we use the same visual treatment that Sphinx does, but we need some consistent way of organizing this content visually and logically. I don't feel like these things will make the website look more like Sphinx as these are techniques used by almost all well designed websites out there. My desire to revert back to the default Sphinx layout is merely because it gives us a starting place that already has these elements in place and then we can tweak them to make it look as non-Sphinx-like as we want. As a simple example, here is my website: http://www.brianegranger.com/ It is is a WordPress site that uses a well-known commercial theme. Note that it has all of these basic elements I am talking about, but looks nothing like a Sphinx site. Many more examples of these design elements can be found on the web. There are obviously other layout patterns we could use: * L panel instead of R. * Both L and R panels (we probably don't have enough material for 2 panels) * Multiple columns of main content (I don't think our content is well suited to this.). * Put an image carousel below the banner for browsing screenshots. >> 1. ?First address the content. ?This would include getting the >> navigation elements to point to our pages etc. > > I think all the links are already correct - please let me know if not. > >> 2. ?Then come up with a custom color scheme. ?There are a number of >> online tools for helping pick color schemes. > > I spent some time trying this (using Adobe Kuler), but eventually I decided > to leave it to someone with more artistic talent - possibly someone paid to > do it. That said, I don't think the colour scheme in agogo (grey, blue, > orange) is too ugly. I may have some time to give this a shot later today. Cheers, Brian > Thanks, > Thomas > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Tue Jun 14 14:55:24 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 14 Jun 2011 19:55:24 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 14 June 2011 19:05, Brian Granger wrote: > In terms of splitting up the links, I think there are some natural > divisions on links: > > * Internal links to other places on the website. > * Links to the "community": lists, github, wiki, IRC > * Downloads. > * Links to the documentation. > > I think it does make sense to put the internal links in the horizontal > navigation bar, but there could be something else in this horizontal > divider. > Alright, I'll look into choosing a subset of links to try putting in a navbar. > > Currently, these different types of links are all grouped together in > the R panel, which creates a disorganized look. Splitting the R panel > vertically and using visual elements to partition the different types > of links makes sense - not because that is what Sphinx does by > default, but because it organizes the material in a way that helps > users. > I don't think there are such clear divisions - the wiki is between community and documentation, github is between downloads and community, and the pages on the website are kind of a miscellany - things which don't need to be on the wiki, but don't quite belong in docs, like the FAQ. At present, I've tried to divide links into a key group - docs, bug tracker, mailing list, and so on, and a secondary group, with a gap between them. Then the downloads and github links were pulled out to sit with the version info at the top. I think subdividing them into more than 2-3 groups will just make it slower to scan through them. I'll see if I can come up with a better arrangement when I try the navbar. > This is what I meant to communicate: I don't think the current layout > works technically and aesthetically. > While there's room for improvement, I'm happy enough with the current layout that I would prefer to build on it rather than reverting to the default Sphinx output and starting afresh. > * The width of the content needs to be made smaller than the browser > Window to frame the content. Using an alternate color in the R and L > page margines is one option (what Sphinx does), but we could simply > leave it as white space. With todays wide screen monitors, content > looks awkward if it spans the entire width of the Window - like > reading a book without margins. > I know, and the width is already constrained, although maybe it should be a bit narrower. The whole thing is limited to 80em, and the main text block to 60em. Obviously whether this fills the window depends on the width of your monitor/window. > * We need to use a single font for the entire website, not counting > the one used for the banner. Mixing serif and sans-serif fonts > creates a look that is visually disjoint. > I'm sure I've seen serif titles used with sans-serif text elsewhere, but I'll admit again that I'm not a designer, and agree to try your suggestion. I'll fiddle with the layout a bit, and let you know when I've got a preview. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Tue Jun 14 18:23:36 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 14 Jun 2011 23:23:36 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 14 June 2011 19:55, Thomas Kluyver wrote: > I'll fiddle with the layout a bit, and let you know when I've got a > preview. http://takluyver.github.com/ipython-website/ Using the banner Klonuo posted, and drawing inspiration from the page he posted. Brian, is this closer to what you were expecting? Specifically: - The dark background to the header is gone - Five links to pages on the same site have been brought up into a nav bar. - The sidebar is divided by thin grey lines, and the bottom section of links has its own heading - The overall page width is reduced to 75em - Headings are in the same font as the body text Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Tue Jun 14 19:02:00 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 14 Jun 2011 16:02:00 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: Thomas, On Tue, Jun 14, 2011 at 3:23 PM, Thomas Kluyver wrote: > On 14 June 2011 19:55, Thomas Kluyver wrote: >> >> I'll fiddle with the layout a bit, and let you know when I've got a >> preview. > > http://takluyver.github.com/ipython-website/ > > Using the banner Klonuo posted, and drawing inspiration from the page he > posted. Brian, is this closer to what you were expecting? Awesome, I am really starting to like how this is shaping up! > Specifically: > - The dark background to the header is gone This, along with the new banner design is a *massive* improvement! > - Five links to pages on the same site have been brought up into a nav bar. Yep, I like the formatting of these links as well and the "dot" separator. > - The sidebar is divided by thin grey lines, and the bottom section of links > has its own heading This too looks fantastic - I like the thin grey lines. > - The overall page width is reduced to 75em > - Headings are in the same font as the body text Again both of these are great as well. Some minor comments: * reduce max-width to something closer to 68-70. With the current font sizes, the page still looks slightly too "full" at 75em width. * reduce the padding on sphinxsidebar to 1em and increase width to 14em to give us a bit more room to content in the sidebar. * reduce div.document max-width to something around 55em. * Overall I like the partition of link in the R sidepanel. But I think the "Links" section should only contain external links as it is a bit odd to see a "link" to "Home" here. I think we need to get Fernando's thoughts (hopefully tonight) and then start to figure out a good color scheme and make final decisions on the logo. But this is a huge step forward - thanks everyone for putting time into this! Cheers, Brian > Thanks, > Thomas > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Tue Jun 14 19:17:25 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 Jun 2011 00:17:25 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 15 June 2011 00:02, Brian Granger wrote: > Some minor comments: > > * reduce max-width to something closer to 68-70. With the current > font sizes, the page still looks slightly too "full" at 75em width. > * reduce the padding on sphinxsidebar to 1em and increase width to > 14em to give us a bit more room to content in the sidebar. > * reduce div.document max-width to something around 55em. > * Overall I like the partition of link in the R sidepanel. But I > think the "Links" section should only contain external links as it is > a bit odd to see a "link" to "Home" here. > OK, I've sorted out all of these - thanks for the pointers. I'll deal with the documentation landing page tomorrow. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From epatters at enthought.com Tue Jun 14 21:52:46 2011 From: epatters at enthought.com (Evan Patterson) Date: Tue, 14 Jun 2011 20:52:46 -0500 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Tue, Jun 14, 2011 at 6:17 PM, Thomas Kluyver wrote: > On 15 June 2011 00:02, Brian Granger wrote: > >> Some minor comments: >> >> * reduce max-width to something closer to 68-70. With the current >> font sizes, the page still looks slightly too "full" at 75em width. >> * reduce the padding on sphinxsidebar to 1em and increase width to >> 14em to give us a bit more room to content in the sidebar. >> * reduce div.document max-width to something around 55em. >> * Overall I like the partition of link in the R sidepanel. But I >> think the "Links" section should only contain external links as it is >> a bit odd to see a "link" to "Home" here. >> > > OK, I've sorted out all of these - thanks for the pointers. I'll deal with > the documentation landing page tomorrow. > > Thanks, > Thomas Brian is right, the webpage is really starting to look good. Great work, Thomas! Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Jun 15 03:18:22 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Jun 2011 00:18:22 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: Hey, On Tue, Jun 14, 2011 at 4:17 PM, Thomas Kluyver wrote: > OK, I've sorted out all of these - thanks for the pointers. I'll deal with > the documentation landing page tomorrow. I'm to far behind on lots of stuff to comment on this massive thread, so just a few thoughts: - The nav bar at the top (Home . Download ...) is great, but the font for it should be larger, and/or boldfaced, I think. Right now that sort of gets lost between the banner logo and the title. - Perhaps a little more color somehwere? I don't think we need to turn the site into a circus tent, but it feels too bright white for my taste, enough to actually feel a little blinding. I think a small amount of color, in moderation (and with visual balance helped by some of the color scheme sites that have been mentioned), would look nice and reduce the glare a little. Just a thought. - Search box? Since it's made in sphinx, we can leave the default sphinx search and it will work inside the site automatically. But even if you were to leave it as-is, it's such a massive improvement already, that I can only cheer. Many, many thanks to everyone who has helped here, this is great. Cheers, f From takowl at gmail.com Wed Jun 15 05:25:28 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 Jun 2011 10:25:28 +0100 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On 15 June 2011 08:18, Fernando Perez wrote: > > - The nav bar at the top (Home . Download ...) is great, but the font > for it should be larger, and/or boldfaced, I think. Right now that > sort of gets lost between the banner logo and the title. > > - Perhaps a little more color somehwere? I don't think we need to > turn the site into a circus tent, but it feels too bright white for my > taste, enough to actually feel a little blinding. I think a small > amount of color, in moderation (and with visual balance helped by some > of the color scheme sites that have been mentioned), would look nice > and reduce the glare a little. Just a thought. > I'll have a play with these. > - Search box? Since it's made in sphinx, we can leave the default > sphinx search and it will work inside the site automatically. I not so convinced on this. There's relatively little content on this site that we want to search, and people might expect that it would search inside the docs as well. If we want a search box, I would use something like Google's custom search engine, so that it covered the docs and the wiki. But perhaps we should just let people go to a search engine themselves. Thoughts, anyone? Thanks for all the feedback everyone's sending, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason-sage at creativetrax.com Wed Jun 15 11:53:10 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Wed, 15 Jun 2011 08:53:10 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: <4DF8D566.1070601@creativetrax.com> On 6/15/11 2:25 AM, Thomas Kluyver wrote: > On 15 June 2011 08:18, Fernando Perez - Search box? Since it's made in sphinx, we can leave the default > sphinx search and it will work inside the site automatically. > > > I not so convinced on this. There's relatively little content on this > site that we want to search, and people might expect that it would > search inside the docs as well. If we want a search box, I would use > something like Google's custom search engine, so that it covered the > docs and the wiki. But perhaps we should just let people go to a search > engine themselves. Thoughts, anyone? You might look at the sagemath.org search box and the resulting page. I believe it was Harald Schilly who implemented a very nice search interface. I've CCd him on this email. Harald: this is an ongoing discussion about revamping the ipython.org website. Jason From takowl at gmail.com Wed Jun 15 12:31:30 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 Jun 2011 17:31:30 +0100 Subject: [IPython-dev] Website In-Reply-To: <4DF8D566.1070601@creativetrax.com> References: <4DF8D566.1070601@creativetrax.com> Message-ID: On 15 June 2011 16:53, Jason Grout wrote: > You might look at the sagemath.org search box and the resulting page. I > believe it was Harald Schilly who implemented a very nice search > interface. I've CCd him on this email. > > Harald: this is an ongoing discussion about revamping the ipython.org > website. > Thanks, Jason. I see that that's powered by Google. Was it much effort to set up? How many sites does it cover? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Wed Jun 15 12:32:50 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 15 Jun 2011 09:32:50 -0700 Subject: [IPython-dev] Website In-Reply-To: References: <4DF8D566.1070601@creativetrax.com> Message-ID: http://www.google.com/cse/ On Wed, Jun 15, 2011 at 9:31 AM, Thomas Kluyver wrote: > On 15 June 2011 16:53, Jason Grout wrote: >> >> You might look at the sagemath.org search box and the resulting page. ?I >> believe it was Harald Schilly who implemented a very nice search >> interface. ?I've CCd him on this email. >> >> Harald: this is an ongoing discussion about revamping the ipython.org >> website. > > Thanks, Jason. > > I see that that's powered by Google. Was it much effort to set up? How many > sites does it cover? > > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Wed Jun 15 12:38:07 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 Jun 2011 17:38:07 +0100 Subject: [IPython-dev] Website In-Reply-To: References: <4DF8D566.1070601@creativetrax.com> Message-ID: On 15 June 2011 17:32, Brian Granger wrote: > http://www.google.com/cse/ http://www.google.com/cse/home?cx=017950022472296044740:wfr9nyfshwo If we reckon it's a valuable approach, I'll spend more time customising it. It could also search mailing list archives, which I haven't added at present. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Jun 15 13:32:39 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Jun 2011 10:32:39 -0700 Subject: [IPython-dev] Website In-Reply-To: References: <4DF8D566.1070601@creativetrax.com> Message-ID: On Wed, Jun 15, 2011 at 9:38 AM, Thomas Kluyver wrote: > > If we reckon it's a valuable approach, I'll spend more time customising it. > It could also search mailing list archives, which I haven't added at > present. That would be excellent! f From takowl at gmail.com Wed Jun 15 15:39:52 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 Jun 2011 20:39:52 +0100 Subject: [IPython-dev] New favicon Message-ID: Hi everyone, I'm making a new topic for this because the old thread is moving so fast it's hard for people to keep up with. Klonuo has been brainstorming favicons for the new website, and we'd like to get feedback from more people. Take a look at the examples in the attached image. It's designed to tie in with a larger logo that we're working on at the same time. I've attached a couple of example concepts to compare, but there are plenty more if you hunt through the thread. Issues we've been considering: - The ][ is derived from a capital I for IPython. There are variations in spacing and colour. - The third bracket ] and the colon are from a concept for a logo, which has the form ][Py] . - The ][ is somewhat similar to a logo used in the 70s & 80s by Apple for the Apple II series of computers. So far, my favourites are A1 and B2 (despite the similarity in shape to Apple's ][ ). Klonuo, can you post which you prefer? Your thoughts are welcome, or you can send back different designs or variants of any of these. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicons.png Type: image/png Size: 5537 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ][.png Type: image/png Size: 13799 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ][Py].png Type: image/png Size: 18370 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ][3.png Type: image/png Size: 23684 bytes Desc: not available URL: From klonuo at gmail.com Wed Jun 15 15:51:51 2011 From: klonuo at gmail.com (Klonuo Umom) Date: Wed, 15 Jun 2011 21:51:51 +0200 Subject: [IPython-dev] New favicon In-Reply-To: References: Message-ID: <20110615215149.8EA6.B1C76292@gmail.com> Excellent move Thomas favicon sheet looks great :) I prefer B1 as for logo I attached my coloring and spacing version as "][2.png" which matches B1 favicon -------------- next part -------------- A non-text attachment was scrubbed... Name: ][2.png Type: image/png Size: 13797 bytes Desc: not available URL: From fperez.net at gmail.com Wed Jun 15 16:06:58 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Jun 2011 13:06:58 -0700 Subject: [IPython-dev] New favicon In-Reply-To: References: Message-ID: On Wed, Jun 15, 2011 at 12:39 PM, Thomas Kluyver wrote: > > Issues we've been considering: > - The ][ is derived from a capital I for IPython. There are variations in > spacing and colour. > - The third bracket ] and the colon are from a concept for a logo, which has > the form ][Py] . > - The ][ is somewhat similar to a logo used in the 70s & 80s by Apple for > the Apple II series of computers. I have to say that I'm not crazy about the ][ yet, but I'm trying to keep an open mind and it's slowly growing on me. So you guys may be onto something here :) Of the three banners, I really don't like #2, and I'm ~50/50 on 1 and 3. The larger spacing between ][ in #1 is visually nicer, but I think it moves away from an 'I' and ends up looking more like Apple's roman II. The one in #3 keeps the idea of the square brackets but almost completely blends into the capital I of IPython. So I guess that means I lean towards #3... That would make B2 the preferred favicon then. Cheers, f Cheers, f From ischnell at enthought.com Wed Jun 15 16:10:46 2011 From: ischnell at enthought.com (Ilan Schnell) Date: Wed, 15 Jun 2011 15:10:46 -0500 Subject: [IPython-dev] 0.11 release date Message-ID: Hello group, how close is ipython 0.11 to being released. I am hoping to update to the new version in the upcoming EPD 7.1 release, which is scheduled for the end of June (which is approaching quickly). Thanks Ilan From benjaminrk at gmail.com Wed Jun 15 16:15:47 2011 From: benjaminrk at gmail.com (Min RK) Date: Wed, 15 Jun 2011 13:15:47 -0700 Subject: [IPython-dev] 0.11 release date In-Reply-To: References: Message-ID: It is our intention to release 0.11 by the end of June as well. The last major change is under review now, and should be in master by the end of the week. After that, all that should remain are some documentation, packaging, and Windows updates. -MinRK On Jun 15, 2011, at 13:10, Ilan Schnell wrote: > Hello group, > > how close is ipython 0.11 to being released. I am hoping > to update to the new version in the upcoming EPD 7.1 > release, which is scheduled for the end of June (which is > approaching quickly). > > Thanks Ilan > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From ischnell at enthought.com Wed Jun 15 16:20:00 2011 From: ischnell at enthought.com (Ilan Schnell) Date: Wed, 15 Jun 2011 15:20:00 -0500 Subject: [IPython-dev] 0.11 release date In-Reply-To: References: Message-ID: Thanks for the quick reply. I hope the timing works out. - Ilan On Wed, Jun 15, 2011 at 3:15 PM, Min RK wrote: > It is our intention to release 0.11 by the end of June as well. > > The last major change is under review now, and should be in master by the end of the week. > > After that, all that should remain are some documentation, packaging, and Windows updates. > > -MinRK > > On Jun 15, 2011, at 13:10, Ilan Schnell wrote: > >> Hello group, >> >> how close is ipython 0.11 to being released. ?I am hoping >> to update to the new version in the upcoming EPD 7.1 >> release, which is scheduled for the end of June (which is >> approaching quickly). >> >> Thanks ? Ilan >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg at gmail.com Wed Jun 15 16:20:34 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 15 Jun 2011 13:20:34 -0700 Subject: [IPython-dev] New favicon In-Reply-To: References: Message-ID: Thanks for putting this together. For the favicons I like the B series best with B2 probably my top. For the banners, I don't really like the ][: designs of 1 and 3 at all, mainly because they are taking us away from our existing logo. I like the ][Py] design of 2, but prefer a small amount of space between the ] and [. I also still like our original IP[y]; design equally to 2. I should note that I am hoping we can come up with a logo/favicon that sticks with the same basic design we already have, but improves it. I know I sound like a broken record, but I don't think we should get into a full logo redesign at this point. Cheers, Brian On Wed, Jun 15, 2011 at 12:39 PM, Thomas Kluyver wrote: > Hi everyone, > > I'm making a new topic for this because the old thread is moving so fast > it's hard for people to keep up with. Klonuo has been brainstorming favicons > for the new website, and we'd like to get feedback from more people. Take a > look at the examples in the attached image. > > It's designed to tie in with a larger logo that we're working on at the same > time. I've attached a couple of example concepts to compare, but there are > plenty more if you hunt through the thread. > > Issues we've been considering: > - The ][ is derived from a capital I for IPython. There are variations in > spacing and colour. > - The third bracket ] and the colon are from a concept for a logo, which has > the form ][Py] . > - The ][ is somewhat similar to a logo used in the 70s & 80s by Apple for > the Apple II series of computers. > > So far, my favourites are A1 and B2 (despite the similarity in shape to > Apple's ][ ). Klonuo, can you post which you prefer? > > Your thoughts are welcome, or you can send back different designs or > variants of any of these. > > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From epatters at enthought.com Wed Jun 15 16:25:22 2011 From: epatters at enthought.com (Evan Patterson) Date: Wed, 15 Jun 2011 15:25:22 -0500 Subject: [IPython-dev] 0.11 release date In-Reply-To: References: Message-ID: I hope to knock out the last thing on my list this weekend. (That being the correct handling in the Qt console of output that arrives after the execution reply.) Evan On Jun 15, 2011, at 3:15 PM, Min RK wrote: > It is our intention to release 0.11 by the end of June as well. > > The last major change is under review now, and should be in master by the end of the week. > > After that, all that should remain are some documentation, packaging, and Windows updates. > > -MinRK > > On Jun 15, 2011, at 13:10, Ilan Schnell wrote: > >> Hello group, >> >> how close is ipython 0.11 to being released. I am hoping >> to update to the new version in the upcoming EPD 7.1 >> release, which is scheduled for the end of June (which is >> approaching quickly). >> >> Thanks Ilan >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From fperez.net at gmail.com Wed Jun 15 16:34:48 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Jun 2011 13:34:48 -0700 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: References: Message-ID: Howdy, On Wed, Jun 15, 2011 at 1:20 PM, Brian Granger wrote: > For the banners, I don't really like the ][: designs of 1 and 3 at > all, mainly because they are taking us away from our existing logo. ?I > like the ][Py] design of 2, but prefer a small amount of space between > the ] and [. > > I also still like our original IP[y]; design equally to 2. ?I should > note that I am hoping we can come up with a logo/favicon that sticks > with the same basic design we already have, but improves it. ?I know I > sound like a broken record, but I don't think we should get into a > full logo redesign at this point. The fact that we've gone in exactly opposite directions with our vote is then probably a good indication to stay put. We should only make a full change on this if we're all convinced we love the new one. Otherwise, staying closer to what we have should win. I'm OK staying with the current logo too. Perhaps this has been rehashed already (the previous thread had more than I was able to digest, forgive me), but why not keep the current one and simply change the font to one where the I has serifs? That seems to be the main limitation of the current one to me, as I do like the idea of the serifed I matching visually the []. Just a thought... f From ellisonbg at gmail.com Wed Jun 15 16:40:39 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 15 Jun 2011 13:40:39 -0700 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: References: Message-ID: On Wed, Jun 15, 2011 at 1:34 PM, Fernando Perez wrote: > Howdy, > > On Wed, Jun 15, 2011 at 1:20 PM, Brian Granger wrote: >> For the banners, I don't really like the ][: designs of 1 and 3 at >> all, mainly because they are taking us away from our existing logo. ?I >> like the ][Py] design of 2, but prefer a small amount of space between >> the ] and [. >> >> I also still like our original IP[y]; design equally to 2. ?I should >> note that I am hoping we can come up with a logo/favicon that sticks >> with the same basic design we already have, but improves it. ?I know I >> sound like a broken record, but I don't think we should get into a >> full logo redesign at this point. > > The fact that we've gone in exactly opposite directions with our vote > is then probably a good indication to stay put. ?We should only make a > full change on this if we're all convinced we love the new one. > Otherwise, staying closer to what we have should win. Yes, this is why I have been hesitant to get into a more complete redesign. The search space increases dramatically and reaching a final result that everyone likes will be a much more lengthy process. > I'm OK staying with the current logo too. ?Perhaps this has been > rehashed already (the previous thread had more than I was able to > digest, forgive me), but why not keep the current one and simply > change the font to one where the I has serifs? ?That seems to be the > main limitation of the current one to me, as I do like the idea of the > serifed I matching visually the []. I do like to "refreshing" of the IP[y]: design that has been done with the new font and the corresponding banner. Are other people OK with this? I also think changing the colors to match the color scheme we pick for the website makes sense. Cheers, Brian > Just a thought... > > f > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From klonuo at gmail.com Wed Jun 15 16:49:14 2011 From: klonuo at gmail.com (Klonuo Umom) Date: Wed, 15 Jun 2011 22:49:14 +0200 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: References: Message-ID: <20110615224912.8EAC.B1C76292@gmail.com> On 15.06.2011 22:34:48 Fernando Perez wrote: > The fact that we've gone in exactly opposite directions with our vote > is then probably a good indication to stay put. We should only make a > full change on this if we're all convinced we love the new one. > Otherwise, staying closer to what we have should win. > > I'm OK staying with the current logo too. Perhaps this has been > rehashed already (the previous thread had more than I was able to > digest, forgive me), but why not keep the current one and simply > change the font to one where the I has serifs? That seems to be the > main limitation of the current one to me, as I do like the idea of the > serifed I matching visually the []. > > Just a thought... We were discussing also that in "IP[y]:" IP associates too much on vastly used term IP (Internet protocol) and all it's derivations. To no surprise there is already IPy module for Python which does exactly that - Internet protocols. Then we (I) also discussed about braking term "Py" in "IP[y]:" or necessity to use such term in logo at all. Thinking about favicon and logo at same time as making website does not seem strange to me. Previous logo can't be put in favicon if that matters anything. Even if not, after these days tries, old logo seems weary now to me and it sure wont fit in new coloring scheme which I understand is to be prepared. I tried to summarise what I read this two days, without trying to impose anything. I'm fine with whatever you decide Cheers From epatters at enthought.com Wed Jun 15 16:54:09 2011 From: epatters at enthought.com (Evan Patterson) Date: Wed, 15 Jun 2011 15:54:09 -0500 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: References: Message-ID: <9143FED3-2BA4-4056-94B7-55E3DFA29D24@enthought.com> On Jun 15, 2011, at 3:40 PM, Brian Granger wrote: > On Wed, Jun 15, 2011 at 1:34 PM, Fernando Perez wrote: >> Howdy, >> >> On Wed, Jun 15, 2011 at 1:20 PM, Brian Granger wrote: >>> For the banners, I don't really like the ][: designs of 1 and 3 at >>> all, mainly because they are taking us away from our existing logo. I >>> like the ][Py] design of 2, but prefer a small amount of space between >>> the ] and [. >>> >>> I also still like our original IP[y]; design equally to 2. I should >>> note that I am hoping we can come up with a logo/favicon that sticks >>> with the same basic design we already have, but improves it. I know I >>> sound like a broken record, but I don't think we should get into a >>> full logo redesign at this point. >> >> The fact that we've gone in exactly opposite directions with our vote >> is then probably a good indication to stay put. We should only make a >> full change on this if we're all convinced we love the new one. >> Otherwise, staying closer to what we have should win. > > Yes, this is why I have been hesitant to get into a more complete > redesign. The search space increases dramatically and reaching a > final result that everyone likes will be a much more lengthy process. > >> I'm OK staying with the current logo too. Perhaps this has been >> rehashed already (the previous thread had more than I was able to >> digest, forgive me), but why not keep the current one and simply >> change the font to one where the I has serifs? That seems to be the >> main limitation of the current one to me, as I do like the idea of the >> serifed I matching visually the []. > > I do like to "refreshing" of the IP[y]: design that has been done with > the new font and the corresponding banner. Are other people OK with > this? I also think changing the colors to match the color scheme we > pick for the website makes sense. I prefer the "refresh" of the IP[y] design to both the old version and the ][ business. The new color scheme is definitely an improvement, but I think the ][ simply looks strange. Evan From takowl at gmail.com Wed Jun 15 17:38:00 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 Jun 2011 22:38:00 +0100 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: References: Message-ID: On 15 June 2011 21:34, Fernando Perez wrote: > I'm OK staying with the current logo too. Perhaps this has been > rehashed already (the previous thread had more than I was able to > digest, forgive me), but why not keep the current one and simply > change the font to one where the I has serifs? > It started off with that, then we just wandered on to other possibilities. I like the ][ form because it's fairly unambiguous (I think it's sufficiently distinctive from Apple's), and is easily made into a recognisable favicon. There's nothing obvious to do with the IP[y] logo at 16x16 pixels, and it could carry the 'IP' connotations Klonuo mentioned. (Aside: it's really tricky, trying to look at the logo as if I'd never seen it before.) If we want to just update the IP[y] design, does anyone have any good ideas for the favicon? Something like group C above? My plain 'IPy' favicon is only intended as a placeholder. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Wed Jun 15 17:59:13 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 Jun 2011 22:59:13 +0100 Subject: [IPython-dev] 0.11 release date In-Reply-To: References: Message-ID: On 15 June 2011 21:15, Min RK wrote: > > After that, all that should remain are some documentation, packaging, and > Windows updates. Critical bugs (i.e. blockers for 0.11): - 79 and 175 are about config - I assume they'll both be closed when the newapp work is merged in - 8 and 66 are docs related - 340, 351, 369, 378, 481 are Windows specific things to sort out. Pull requests: Most can wait until after the release - newapp (454) is going in soon - I'd quite like to get the changes to traitlets strings (462) in, so that the Python 3 port is closer to the main version for release. - The changes to keybindings for the Qt console (496) should be simple once the config stuff is in place. Anything else? Are there any of the 12 high-priority bugs (or any others) that really ought to be blockers? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Wed Jun 15 18:13:09 2011 From: carl.input at gmail.com (Carl Joseph Younger) Date: Wed, 15 Jun 2011 23:13:09 +0100 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: References: Message-ID: I think Even's right about the ][ looking strange. I'm not sure what you guys are trying to do, but it aint working. I don't want to sound arrogant, I just want to be frank ~ the artwork offered here sucks. The site itself is looking really nice and the new text in the banner looks good, but on the branding side of things, it's just crazy. I posted an attempt at a logo, it went nowhere, I can live with that, but I'm totally lost as to what to try next as there seems to be some kind of commitment to having that classic, mathematical community look ~ much like the old site. matplotlib's banner is ok, you wouldn't knock it if your saw it, but it's not a benchmark by any stretch? I really do want to help, but I just don't know what to aim for. I'll attach my logo here again ~ indulge me please ~ can anyone tell me where I'm going wrong. I really thought this logo was going to go down a treat. On Wed, Jun 15, 2011 at 10:38 PM, Thomas Kluyver wrote: > On 15 June 2011 21:34, Fernando Perez wrote: >> >> I'm OK staying with the current logo too. ?Perhaps this has been >> rehashed already (the previous thread had more than I was able to >> digest, forgive me), but why not keep the current one and simply >> change the font to one where the I has serifs? > > It started off with that, then we just wandered on to other possibilities. > > I like the ][ form because it's fairly unambiguous (I think it's > sufficiently distinctive from Apple's), and is easily made into a > recognisable favicon. There's nothing obvious to do with the IP[y] logo at > 16x16 pixels, and it could carry the 'IP' connotations Klonuo mentioned. > (Aside: it's really tricky, trying to look at the logo as if I'd never seen > it before.) > > If we want to just update the IP[y] design, does anyone have any good ideas > for the favicon? Something like group C above? My plain 'IPy' favicon is > only intended as a placeholder. > > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_on_grey.png Type: image/png Size: 27628 bytes Desc: not available URL: From fperez.net at gmail.com Wed Jun 15 18:14:04 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Jun 2011 15:14:04 -0700 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: References: Message-ID: On Wed, Jun 15, 2011 at 2:38 PM, Thomas Kluyver wrote: > > > I like the ][ form because it's fairly unambiguous (I think it's > sufficiently distinctive from Apple's), and is easily made into a > recognisable favicon. There's nothing obvious to do with the IP[y] logo at > 16x16 pixels, and it could carry the 'IP' connotations Klonuo mentioned. > (Aside: it's really tricky, trying to look at the logo as if I'd never seen > it before.) > One drawback of the ][ is that the prompts don't really look like that, it's just a play with brackets and the letter I. BTW, the IP connotation doesn't bother me in the slightest, we've had IPython with that spelling for so long that I have no problem with a bit of a name collision. It's impossible today to avoid all name collisions in any case... Sorry, I'll need to tune out again of this conversation at the worst possible time, but real job calls (more like yells)... It seems to me that, given the lack of any clear consensus/happiness on new ideas, a conservative approach should win. And honestly, if we simply keep what we have it won't be the end of the world: having a clean website we can update easily and control with git is the major win here, we don't need to burn too many cycles on the banner business. Much more importantly: we're starting to get close to release time deadline, and I think our energies would be better spent on that... I'm drowning in deadlines (some that will benefit ipython majorly if they work out, but those are longer term), so what little time I have for this now I'll spend on getting us closer to release. Cheers, f -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Wed Jun 15 18:34:40 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 Jun 2011 23:34:40 +0100 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: References: Message-ID: On 15 June 2011 23:13, Carl Joseph Younger wrote: > I think Even's right about the ][ looking strange. I'm not sure what > you guys are trying to do, but it aint working. I don't want to sound > arrogant, I just want to be frank ~ the artwork offered here sucks. > The site itself is looking really nice and the new text in the banner > looks good, but on the branding side of things, it's just crazy. > Thanks for your input, Carl. I think perhaps your artistic tastes are a bit different to most of the people commenting here. I think we're going for a more minimalistic look. Your logo is technically impressive, but (speaking for myself at least), the extra elements and colours look somewhat distracting. I agree matplotlib's logo isn't perhaps a perfect example. Perhaps Sphinx's banner shows better the sort of thing we're aiming for: http://sphinx.pocoo.org/ Fernando: > It seems to me that, given the lack of any clear consensus/happiness on new ideas, a conservative approach should win. OK. Does anyone want to have a crack at a favicon to fit in with that? This is the advantage of having a BDFL. These questions get resolved and we can get on. ;-) Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Wed Jun 15 18:35:37 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 15 Jun 2011 15:35:37 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch Message-ID: Hi, Min has done an absolutely fantastic job in finishing the config refactor. The result is in this branch: https://github.com/ipython/ipython/tree/newapp The changes are massive and affect all of the top level applications. A pretty solid code review has been done, but before we merge this, it would be fantastic if we could have other people help try it out. Somethings to look at: * The top level applications: ipython -h ipcluster -h * Subcommands: ipython profile ipython qtconsole ipcluster start * Command line options and flags (see the help strings). * Creation and selection of profiles. * Editing config files Any help would be greatly appreciated! And thanks to Min for doing such a great job. Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From jason-sage at creativetrax.com Wed Jun 15 18:41:30 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Wed, 15 Jun 2011 15:41:30 -0700 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: References: Message-ID: <4DF9351A.9030101@creativetrax.com> On 6/15/11 3:14 PM, Fernando Perez wrote: > Much more importantly: we're starting to get close to release time > deadline, and I think our energies would be better spent on that... I'm > drowning in deadlines (some that will benefit ipython majorly if they > work out, but those are longer term), so what little time I have for > this now I'll spend on getting us closer to release. +1. We are eagerly waiting for 0.11/0.12/1.0. Much more eager about that than the new website, as pretty and wonderful as the new website is. Thanks, Jason From benjaminrk at gmail.com Wed Jun 15 18:45:43 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 15 Jun 2011 15:45:43 -0700 Subject: [IPython-dev] 0.11 release date In-Reply-To: References: Message-ID: On Wed, Jun 15, 2011 at 14:59, Thomas Kluyver wrote: > On 15 June 2011 21:15, Min RK wrote: > >> >> After that, all that should remain are some documentation, packaging, and >> Windows updates. > > > Critical bugs (i.e. blockers for 0.11): > > - 79 and 175 are about config - I assume they'll both be closed when the > newapp work is merged in > These are both resolved in newapp > - 8 and 66 are docs related > > - 340, 351, 369, 378, 481 are Windows specific things to sort out. I've been looking at some of these - several of them are *make sure it works* things that may not need any work. > > Pull requests: > Most can wait until after the release > - newapp (454) is going in soon > Yes it is, in the next day or two. > - I'd quite like to get the changes to traitlets strings (462) in, so that > the Python 3 port is closer to the main version for release. > Yes, me too - as soon as newapp is merged, we should be able to get it in quite quickly (the various CStr traits in parallel will become Bytes, and use ObjectName various places that it is appropriate). > - The changes to keybindings for the Qt console (496) should be simple once > the config stuff is in place. > Not *super* simple, as the way the keybindings are written is not well suited to modular key-combos. I don't expect this to make it in by 0.11, but it will be very nice. > > Anything else? Are there any of the 12 high-priority bugs (or any others) > that really ought to be blockers? > 514 won't be fixed, but we should come up with a message somewhere to help prevent confusion. 478 only affects python 3 I think Evan said he is going to get to 476 this weekend 451 is resolved in newapp Nobody has been able to reproduce 440 as far as I know, so it can slip if we don't figure it out... 371 should be a small fix, but the cause is rare 136 and 124 both have to do with embedding, and I am not familiar with that code. Right now, embedding just doesn't work I think. I think 131 and 29 are really the same, and addressed as part of your Pickle PR that we will save for 0.12 13 is vague, and I don't think anything *needs* to be done for 0.11. -MinRK > > Thanks, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Wed Jun 15 18:47:07 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 Jun 2011 23:47:07 +0100 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: <4DF9351A.9030101@creativetrax.com> References: <4DF9351A.9030101@creativetrax.com> Message-ID: On 15 June 2011 23:41, Jason Grout wrote: > +1. We are eagerly waiting for 0.11/0.12/1.0. Much more eager about > that than the new website, as pretty and wonderful as the new website is. > Agreed, that's the important thing. I started doing the website while I was waiting for the release - I hadn't expected so much discussion about it. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Wed Jun 15 19:19:09 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 15 Jun 2011 16:19:09 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: Yes, please do test, as I don't doubt there are still tweaks that need to be made. A screenshot of the most exciting consequence of hooking up the config stuff to the qtconsole: http://img812.imageshack.us/img812/9314/screenshot20110615at155.png $> ipython qtconsole pylab=inline ConsoleWidget.font_family="Comic Sans MS" -MinRK On Wed, Jun 15, 2011 at 15:35, Brian Granger wrote: > > Hi, > > Min has done an absolutely fantastic job in finishing the config > refactor. ?The result is in this branch: > > https://github.com/ipython/ipython/tree/newapp > > The changes are massive and affect all of the top level applications. > A pretty solid code review has been done, but before we merge this, it > would be fantastic if we could have other people help try it out. > Somethings to look at: > > * The top level applications: > > ipython -h > ipcluster -h > > * Subcommands: > > ipython profile > ipython qtconsole > ipcluster start > > * Command line options and flags (see the help strings). > * Creation and selection of profiles. > * Editing config files > > Any help would be greatly appreciated! ?And thanks to Min for doing > such a great job. > > Cheers, > > Brian > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From takowl at gmail.com Wed Jun 15 19:33:40 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 16 Jun 2011 00:33:40 +0100 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On 16 June 2011 00:19, MinRK wrote: > > A screenshot of the most exciting consequence of hooking up the config > stuff to the qtconsole: The goggles, they do nothing ;-) More seriously: - ipython profile does nothing - should a command like that print out a brief usage message, like when you get the arguments wrong for many command line programs - ipcluster start throws an error, I don't know if this is something in my setup: Traceback (most recent call last): File "/home/thomas/Code/virtualenvs/ipy-trunk/bin/ipcluster", line 18, in launch_new_instance() File "/home/thomas/Code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/parallel/apps/ipclusterapp.py", line 438, in launch_new_instance app = IPBaseParallelApplication.instance() NameError: global name 'IPBaseParallelApplication' is not defined I'll do more testing soon, hopefully. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Jun 15 20:24:38 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Jun 2011 17:24:38 -0700 Subject: [IPython-dev] [IPython-User] New favicon In-Reply-To: References: <4DF9351A.9030101@creativetrax.com> Message-ID: On Wed, Jun 15, 2011 at 3:47 PM, Thomas Kluyver wrote: > Agreed, that's the important thing. I started doing the website while I was > waiting for the release - I hadn't expected so much discussion about it. Not trying to sound ungrateful to the new participants who have pitched in on this topic (really, we *do* appreciate your interest and contributions), but what happens is that a website/logo is something everybody can have an opinion on, while fixing the last nasty critical bugs for release is not. So the moment this opens up, lots of people jump in :) This shows us there's genuine interest in ipython, and that's great. But I think we've burned enough cycles on this for now, we can always revisit it later and I think that we already have what we needed: a git-controlled website that looks nice (perhaps not awesome, but perfectly nice) and that we can easily update with tools we like (aka sphinx). The rest of the polish can come later, as a celebratory gift to ourselves once we push a few releases. Cheers, f From fperez.net at gmail.com Wed Jun 15 20:27:47 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Jun 2011 17:27:47 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On Wed, Jun 15, 2011 at 4:19 PM, MinRK wrote: > A screenshot of the most exciting consequence of hooking up the config > stuff to the qtconsole: > > http://img812.imageshack.us/img812/9314/screenshot20110615at155.png > >>gt; ipython qtconsole pylab=inline ConsoleWidget.font_family="Comic Sans MS" You know, people go to hell for far lesser offences... :) f From satra at mit.edu Wed Jun 15 20:31:47 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Wed, 15 Jun 2011 20:31:47 -0400 Subject: [IPython-dev] profiles + enthought traits Message-ID: hi guys, do you already have a built in profile to suppress the additional fields of traits? if not is there a doc pointer somewhere i can use to create a new profile for ipy:xi (eye-pixie - that's my name for your new release :) )? cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Wed Jun 15 20:39:58 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 15 Jun 2011 17:39:58 -0700 Subject: [IPython-dev] profiles + enthought traits In-Reply-To: References: Message-ID: On Wed, Jun 15, 2011 at 5:31 PM, Satrajit Ghosh wrote: > hi guys, > > do you already have a built in profile to suppress the additional fields of > traits? if not is there a doc pointer somewhere i can use to create a new > profile for ipy:xi (eye-pixie - that's my name for your new release :) )? You just need to save it from deathrow by updating it to work with 0.11: https://github.com/ipython/ipython/blob/master/IPython/deathrow/ipy_traits_completer.py I see a pull request in your future... Cheers, f From benjaminrk at gmail.com Wed Jun 15 20:42:21 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 15 Jun 2011 17:42:21 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On Wed, Jun 15, 2011 at 16:33, Thomas Kluyver wrote: > On 16 June 2011 00:19, MinRK wrote: >> >> A screenshot of the most exciting consequence of hooking up the config >> stuff to the qtconsole: > > The goggles, they do nothing ;-) > > More seriously: > - ipython profile does nothing - should a command like that print out a > brief usage message, like when you get the arguments wrong for many command > line programs > - ipcluster start throws an error, I don't know if this is something in my > setup: > > Traceback (most recent call last): > ? File "/home/thomas/Code/virtualenvs/ipy-trunk/bin/ipcluster", line 18, in > > ??? launch_new_instance() > ? File > "/home/thomas/Code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/parallel/apps/ipclusterapp.py", > line 438, in launch_new_instance > ??? app = IPBaseParallelApplication.instance() > NameError: global name 'IPBaseParallelApplication' is not defined Right - there was some renaming and find/replacing in the last couple of commits, and I didn't run every script. Both of these are fixed now - `ipython profile` without a subcommand prints its usage, just like ipcluster. > > I'll do more testing soon, hopefully. > > Thomas > From ellisonbg at gmail.com Wed Jun 15 22:09:39 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 15 Jun 2011 19:09:39 -0700 Subject: [IPython-dev] Error in newapp with ipcluster Message-ID: I get the following behavior in newapp: (ipython-0.11)[laptop:ipython]$ ipcluster -h Traceback (most recent call last): File "/Users/bgranger/Documents/Computation/virtualenv/ipython-0.11/bin/ipcluster", line 8, in load_entry_point('ipython==0.11.dev', 'console_scripts', 'ipcluster')() File "/Users/bgranger/Documents/Computation/IPython/code/ipython/IPython/parallel/apps/ipclusterapp.py", line 438, in launch_new_instance app = IPBaseParallelApplication.instance() NameError: global name 'IPBaseParallelApplication' is not defined Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From kevin.buchs at gmail.com Wed Jun 15 22:09:39 2011 From: kevin.buchs at gmail.com (Kevin Buchs) Date: Wed, 15 Jun 2011 21:09:39 -0500 Subject: [IPython-dev] gitting newapp Message-ID: I am interested in helping out with testing newapp. The screenshot looks great. However, I am very new to git. I tried to fetch and clone from this https URL, but that is not working. The page that is brought up when I open it into a browser gives me a git command which clones the whole ipython tree, but there is nothing called newapp in that. So, a pointer or two, please. > Min has done an absolutely fantastic job in finishing the config > refactor. ?The result is in this branch: > > https://github.com/ipython/ipython/tree/newapp - Kevin Buchs From epatters at enthought.com Wed Jun 15 22:14:14 2011 From: epatters at enthought.com (Evan Patterson) Date: Wed, 15 Jun 2011 21:14:14 -0500 Subject: [IPython-dev] gitting newapp In-Reply-To: References: Message-ID: After cloning the IPython repo using the link provided by GitHub, navigate to the root of the repository and execute 'git checkout newapp'. Evan On Wed, Jun 15, 2011 at 9:09 PM, Kevin Buchs wrote: > I am interested in helping out with testing newapp. The screenshot > looks great. However, I am very new to git. I tried to fetch and clone > from this https URL, but that is not working. The page that is brought > up when I open it into a browser gives me a git command which clones > the whole ipython tree, but there is nothing called newapp in that. > So, a pointer or two, please. > > > Min has done an absolutely fantastic job in finishing the config > > refactor. ?The result is in this branch: > > > > https://github.com/ipython/ipython/tree/newapp > > - Kevin Buchs > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Wed Jun 15 22:18:34 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 15 Jun 2011 19:18:34 -0700 Subject: [IPython-dev] Error in newapp with ipcluster In-Reply-To: References: Message-ID: On Wed, Jun 15, 2011 at 19:09, Brian Granger wrote: > I get the following behavior in newapp: > > (ipython-0.11)[laptop:ipython]$ ipcluster -h > Traceback (most recent call last): > ?File "/Users/bgranger/Documents/Computation/virtualenv/ipython-0.11/bin/ipcluster", > line 8, in > ? ?load_entry_point('ipython==0.11.dev', 'console_scripts', 'ipcluster')() > ?File "/Users/bgranger/Documents/Computation/IPython/code/ipython/IPython/parallel/apps/ipclusterapp.py", > line 438, in launch_new_instance > ? ?app = IPBaseParallelApplication.instance() > NameError: global name 'IPBaseParallelApplication' is not defined This was fixed an hour or so ago. > > Cheers, > > Brian > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From erik.tollerud at gmail.com Thu Jun 16 03:50:33 2011 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Thu, 16 Jun 2011 03:50:33 -0400 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: Maybe I've just missed something really obvious, but when I pull the newapp branch and do either "python setup.py build" or "python setup.py develop", it fails with this message: error: package directory 'IPython/config/default' does not exist And the build or install gives up at that point. (This is on OS X 10.6, although it's not clear to me that that's relevant...) On Wed, Jun 15, 2011 at 8:42 PM, MinRK wrote: > On Wed, Jun 15, 2011 at 16:33, Thomas Kluyver wrote: >> On 16 June 2011 00:19, MinRK wrote: >>> >>> A screenshot of the most exciting consequence of hooking up the config >>> stuff to the qtconsole: >> >> The goggles, they do nothing ;-) >> >> More seriously: >> - ipython profile does nothing - should a command like that print out a >> brief usage message, like when you get the arguments wrong for many command >> line programs >> - ipcluster start throws an error, I don't know if this is something in my >> setup: >> >> Traceback (most recent call last): >> ? File "/home/thomas/Code/virtualenvs/ipy-trunk/bin/ipcluster", line 18, in >> >> ??? launch_new_instance() >> ? File >> "/home/thomas/Code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/parallel/apps/ipclusterapp.py", >> line 438, in launch_new_instance >> ??? app = IPBaseParallelApplication.instance() >> NameError: global name 'IPBaseParallelApplication' is not defined > > Right - there was some renaming and find/replacing in the last couple > of commits, and I didn't run every script. ?Both of these are fixed > now - `ipython profile` without a subcommand prints its usage, just > like ipcluster. > >> >> I'll do more testing soon, hopefully. >> >> Thomas >> > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Erik Tollerud From takowl at gmail.com Thu Jun 16 05:34:13 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 16 Jun 2011 10:34:13 +0100 Subject: [IPython-dev] gitting newapp In-Reply-To: References: Message-ID: You can also click the 'Downloads' button in github and get a tarball of the tip of the branch you're looking at. But when it's changing rapidly, it's easier to stay up to date by cloning the repo. Thomas On 16 June 2011 03:14, Evan Patterson wrote: > After cloning the IPython repo using the link provided by GitHub, navigate > to the root of the repository and execute 'git checkout newapp'. > > Evan > > > On Wed, Jun 15, 2011 at 9:09 PM, Kevin Buchs wrote: > >> I am interested in helping out with testing newapp. The screenshot >> looks great. However, I am very new to git. I tried to fetch and clone >> from this https URL, but that is not working. The page that is brought >> up when I open it into a browser gives me a git command which clones >> the whole ipython tree, but there is nothing called newapp in that. >> So, a pointer or two, please. >> >> > Min has done an absolutely fantastic job in finishing the config >> > refactor. ?The result is in this branch: >> > >> > https://github.com/ipython/ipython/tree/newapp >> >> - Kevin Buchs >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Thu Jun 16 06:03:08 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 16 Jun 2011 11:03:08 +0100 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On 16 June 2011 08:50, Erik Tollerud wrote: > Maybe I've just missed something really obvious, but when I pull the > newapp branch and do either "python setup.py build" or "python > setup.py develop", it fails with this message: > > error: package directory 'IPython/config/default' does not exist > I got that too. It looks like it was down to the recent commit which made the default config autogenerated. There was a line in setupbase.py which referenced that package. With that line changed, it installs for me, so I've pushed the change to the newapp branch. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdimiduk at physics.harvard.edu Thu Jun 16 10:57:24 2011 From: tdimiduk at physics.harvard.edu (Tom Dimiduk) Date: Thu, 16 Jun 2011 10:57:24 -0400 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: <4DFA19D4.6090707@physics.harvard.edu> The new qtconsole crashes on ubuntu 11.04 (see below). This crash clears right up when I upgrade to pyqmq version 2.1.7, but the app thinks it can run with pyzmq 2.0.10-1 and I got this crash with ubuntu packaged 2.0.10.1-1 so I thought you might like to know. ----- [tdimiduk at kBt:~|284]$ ipython qtconsole Starting the kernel at pid: 14841 --------------------------------------------------------------------------- AttributeError Python 2.7.1+: /usr/bin/python Thu Jun 16 10:22:19 2011 A problem occured executing Python code. Here is the sequence of function calls leading up to the error, with the most recent (innermost) call last. /usr/local/bin/ipython in () 1 #!/usr/bin/python 2 """Terminal-based IPython entry point. 3 4 Note: this is identical to IPython/frontend/terminal/scripts/ipython for now. 5 Once 0.11 is closer to release, we will likely need to reorganize the script 6 entry points.""" 7 8 from IPython.frontend.terminal.ipapp import launch_new_instance 9 ---> 10 launch_new_instance() global launch_new_instance = /usr/local/lib/python2.7/dist-packages/IPython/frontend/terminal/ipapp.pyc in launch_new_instance() 336 """Load the default config file from the default ipython_dir. 337 338 This is useful for embedded shells. 339 """ 340 if ipython_dir is None: 341 ipython_dir = get_ipython_dir() 342 profile_dir = os.path.join(ipython_dir, 'profile_default') 343 cl = PyFileConfigLoader(default_config_file_name, profile_dir) 344 config = cl.load_config() 345 return config 346 347 348 def launch_new_instance(): 349 """Create and run a full blown IPython instance""" 350 app = TerminalIPythonApp.instance() --> 351 app.initialize() 352 app.start() 353 354 355 if __name__ == '__main__': 356 launch_new_instance() 357 /usr/local/lib/python2.7/dist-packages/IPython/frontend/terminal/ipapp.pyc in initialize(self=, argv=None) 244 def _force_interact_changed(self, name, old, new): 245 if new: 246 self.interact = True 247 248 def _file_to_run_changed(self, name, old, new): 249 if new and not self.force_interact: 250 self.interact = False 251 _code_to_run_changed = _file_to_run_changed 252 253 # internal, not-configurable 254 interact=Bool(True) 255 256 257 def initialize(self, argv=None): 258 """Do actions after construct, but before starting the app.""" --> 259 super(TerminalIPythonApp, self).initialize(argv) 260 if self.subapp is not None: 261 # don't bother initializing further, starting subapp 262 return 263 if not self.ignore_old_config: 264 check_for_old_config(self.ipython_dir) 265 # print self.extra_args 266 if self.extra_args: 267 self.file_to_run = self.extra_args[0] 268 # create the shell 269 self.init_shell() 270 # and draw the banner 271 self.init_banner() 272 # Now a variety of things that happen after the banner is printed. 273 self.init_gui_pylab() 274 self.init_extensions() /usr/local/lib/python2.7/dist-packages/IPython/core/application.pyc in initialize(self=, argv=None) 265 else: 266 self.stage_default_config_file() 267 268 def stage_default_config_file(self): 269 """auto generate default config file, and stage it into the profile.""" 270 s = self.generate_config_file() 271 fname = os.path.join(self.profile_dir.location, self.config_file_name) 272 if self.overwrite or not os.path.exists(fname): 273 self.log.warn("Generating default config file: %r"%(fname)) 274 with open(fname, 'w') as f: 275 f.write(s) 276 277 278 def initialize(self, argv=None): 279 self.init_crash_handler() --> 280 self.parse_command_line(argv) 281 if self.subapp is not None: 282 # stop here if subapp is taking over 283 return 284 cl_config = self.config 285 self.init_profile_dir() 286 self.init_config_files() 287 self.load_config_file() 288 # enforce cl-opts override configfile opts: 289 self.update_config(cl_config) 290 /usr/local/lib/python2.7/dist-packages/IPython/config/application.pyc in parse_command_line(self=, argv=['qtconsole']) 300 self.__class__.clear_instance() 301 # instantiate 302 self.subapp = subapp.instance() 303 # and initialize subapp 304 self.subapp.initialize(argv) 305 306 def parse_command_line(self, argv=None): 307 """Parse the command line arguments.""" 308 argv = sys.argv[1:] if argv is None else argv 309 310 if self.subcommands and len(argv) > 0: 311 # we have subcommands, and one may have been specified 312 subc, subargv = argv[0], argv[1:] 313 if re.match(r'^\w(\-?\w)*$', subc) and subc in self.subcommands: 314 # it's a subcommand, and *not* a flag or class parameter --> 315 return self.initialize_subcommand(subc, subargv) 316 317 if '-h' in argv or '--help' in argv or '--help-all' in argv: 318 self.print_description() 319 self.print_help('--help-all' in argv) 320 self.exit(0) 321 322 if '--version' in argv: 323 self.print_version() 324 self.exit(0) 325 326 loader = KeyValueConfigLoader(argv=argv, aliases=self.aliases, 327 flags=self.flags) 328 try: 329 config = loader.load_config() 330 except ArgumentError as e: /usr/local/lib/python2.7/dist-packages/IPython/config/application.pyc in initialize_subcommand(self=, subc='qtconsole', argv=[]) 289 # events. 290 self.config = newconfig 291 292 def initialize_subcommand(self, subc, argv=None): 293 """Initialize a subcommand with argv.""" 294 subapp,help = self.subcommands.get(subc) 295 296 if isinstance(subapp, basestring): 297 subapp = import_item(subapp) 298 299 # clear existing instances 300 self.__class__.clear_instance() 301 # instantiate 302 self.subapp = subapp.instance() 303 # and initialize subapp --> 304 self.subapp.initialize(argv) 305 306 def parse_command_line(self, argv=None): 307 """Parse the command line arguments.""" 308 argv = sys.argv[1:] if argv is None else argv 309 310 if self.subcommands and len(argv) > 0: 311 # we have subcommands, and one may have been specified 312 subc, subargv = argv[0], argv[1:] 313 if re.match(r'^\w(\-?\w)*$', subc) and subc in self.subcommands: 314 # it's a subcommand, and *not* a flag or class parameter 315 return self.initialize_subcommand(subc, subargv) 316 317 if '-h' in argv or '--help' in argv or '--help-all' in argv: 318 self.print_description() 319 self.print_help('--help-all' in argv) /usr/local/lib/python2.7/dist-packages/IPython/frontend/qt/console/qtconsoleapp.pyc in initialize(self=, argv=[]) 383 # defaults to change 384 widget.set_default_style() 385 386 if self.stylesheet: 387 # we got an expicit stylesheet 388 if os.path.isfile(self.stylesheet): 389 with open(self.stylesheet) as f: 390 sheet = f.read() 391 widget.style_sheet = sheet 392 widget._style_sheet_changed() 393 else: 394 raise IOError("Stylesheet %r not found."%self.stylesheet) 395 396 def initialize(self, argv=None): 397 super(IPythonQtConsoleApp, self).initialize(argv) --> 398 self.init_kernel_manager() 399 self.init_qt_elements() 400 self.init_colors() 401 402 def start(self): 403 404 # draw the window 405 self.window.show() 406 407 # Start the application main loop. 408 self.app.exec_() 409 410 #----------------------------------------------------------------------------- 411 # Main entry point 412 #----------------------------------------------------------------------------- 413 /usr/local/lib/python2.7/dist-packages/IPython/frontend/qt/console/qtconsoleapp.pyc in init_kernel_manager(self=) 303 signal.signal(signal.SIGINT, signal.SIG_DFL) 304 305 # Create a KernelManager and start a kernel. 306 self.kernel_manager = QtKernelManager( 307 shell_address=(self.ip, self.shell_port), 308 sub_address=(self.ip, self.iopub_port), 309 stdin_address=(self.ip, self.stdin_port), 310 hb_address=(self.ip, self.hb_port), 311 config=self.config 312 ) 313 # start the kernel 314 if not self.existing: 315 kwargs = dict(ip=self.ip, ipython=not self.pure) 316 kwargs['extra_arguments'] = self.kernel_argv 317 self.kernel_manager.start_kernel(**kwargs) --> 318 self.kernel_manager.start_channels() 319 320 321 def init_qt_elements(self): 322 # Create the widget. 323 self.app = QtGui.QApplication([]) 324 local_kernel = (not self.existing) or self.ip in LOCAL_IPS 325 self.widget = self.widget_factory(config=self.config, 326 local_kernel=local_kernel) 327 self.widget.kernel_manager = self.kernel_manager 328 self.window = MainWindow(self.app, self.widget, self.existing, 329 may_close=local_kernel, 330 confirm_exit=self.confirm_exit) 331 self.window.setWindowTitle('Python' if self.pure else 'IPython') 332 333 def init_colors(self): /usr/local/lib/python2.7/dist-packages/IPython/frontend/qt/kernelmanager.pyc in start_channels(self=, *args=(), **kw={}) 200 201 #------ Kernel process management ------------------------------------------ 202 203 def start_kernel(self, *args, **kw): 204 """ Reimplemented for proper heartbeat management. 205 """ 206 if self._shell_channel is not None: 207 self._shell_channel.reset_first_reply() 208 super(QtKernelManager, self).start_kernel(*args, **kw) 209 210 #------ Channel management ------------------------------------------------- 211 212 def start_channels(self, *args, **kw): 213 """ Reimplemented to emit signal. 214 """ --> 215 super(QtKernelManager, self).start_channels(*args, **kw) 216 self.started_channels.emit() 217 218 def stop_channels(self): 219 """ Reimplemented to emit signal. 220 """ 221 super(QtKernelManager, self).stop_channels() 222 self.stopped_channels.emit() 223 224 @property 225 def shell_channel(self): 226 """ Reimplemented for proper heartbeat management. 227 """ 228 if self._shell_channel is None: 229 self._shell_channel = super(QtKernelManager, self).shell_channel 230 self._shell_channel.first_reply.connect(self._first_reply) /usr/local/lib/python2.7/dist-packages/IPython/zmq/kernelmanager.pyc in start_channels(self=, shell=True, sub=True, stdin=True, hb=True) 718 # atexit.register(self.context.term) 719 720 #-------------------------------------------------------------------------- 721 # Channel management methods: 722 #-------------------------------------------------------------------------- 723 724 def start_channels(self, shell=True, sub=True, stdin=True, hb=True): 725 """Starts the channels for this kernel. 726 727 This will create the channels if they do not exist and then start 728 them. If port numbers of 0 are being used (random ports) then you 729 must first call :method:`start_kernel`. If the channels have been 730 stopped and you call this, :class:`RuntimeError` will be raised. 731 """ 732 if shell: --> 733 self.shell_channel.start() 734 if sub: 735 self.sub_channel.start() 736 if stdin: 737 self.stdin_channel.start() 738 if hb: 739 self.hb_channel.start() 740 741 def stop_channels(self): 742 """Stops all the running channels for this kernel. 743 """ 744 if self.shell_channel.is_alive(): 745 self.shell_channel.stop() 746 if self.sub_channel.is_alive(): 747 self.sub_channel.stop() 748 if self.stdin_channel.is_alive(): AttributeError: 'QtKernelManager' object has no attribute 'shell_channel' ********************************************************************** Oops, ipython-qtconsole crashed. We do our best to make it stable, but... A crash report was automatically generated with the following information: - A verbatim copy of the crash traceback. - A copy of your input history during this session. - Data on your current ipython-qtconsole configuration. It was left in the file named: '/home/tdimiduk/.config/ipython/Crash_report_ipython-qtconsole.txt' If you can email this file to the developers, the information in it will help them in understanding and correcting the problem. You can mail it to: None at None with the subject 'ipython-qtconsole Crash Report'. If you want to do it now, the following command will work (under Unix): mail -s 'ipython-qtconsole Crash Report' None < /home/tdimiduk/.config/ipython/Crash_report_ipython-qtconsole.txt To ensure accurate tracking of this issue, please file a report about it at: None Hit to quit this message (your terminal may close):--------------------------------------------------------------------------- AttributeError Traceback (most recent call last) /home/tdimiduk/ in () /usr/local/lib/python2.7/dist-packages/IPython/zmq/ipkernel.pyc in main() 666 """Run an IPKernel as an application""" 667 app = IPKernelApp.instance() --> 668 app.initialize() 669 app.start() 670 /usr/local/lib/python2.7/dist-packages/IPython/zmq/ipkernel.pyc in initialize(self=, argv=None) 600 ) 601 def initialize(self, argv=None): --> 602 super(IPKernelApp, self).initialize(argv) 603 self.init_shell() 604 self.init_extensions() /usr/local/lib/python2.7/dist-packages/IPython/zmq/kernelapp.pyc in initialize(self=, argv=None) 201 self.init_session() 202 self.init_poller() --> 203 self.init_sockets() 204 self.init_io() 205 self.init_kernel() /usr/local/lib/python2.7/dist-packages/IPython/zmq/kernelapp.pyc in init_sockets(self=) 132 # Create a context, a session, and the kernel sockets. 133 io.raw_print("Starting the kernel at pid:", os.getpid()) --> 134 context = zmq.Context.instance() 135 # Uncomment this to try closing the context. 136 # atexit.register(context.term) AttributeError: type object 'zmq.core.context.Context' has no attribute 'instance' On 06/15/2011 06:35 PM, Brian Granger wrote: > Hi, > > Min has done an absolutely fantastic job in finishing the config > refactor. The result is in this branch: > > https://github.com/ipython/ipython/tree/newapp > > The changes are massive and affect all of the top level applications. > A pretty solid code review has been done, but before we merge this, it > would be fantastic if we could have other people help try it out. > Somethings to look at: > > * The top level applications: > > ipython -h > ipcluster -h > > * Subcommands: > > ipython profile > ipython qtconsole > ipcluster start > > * Command line options and flags (see the help strings). > * Creation and selection of profiles. > * Editing config files > > Any help would be greatly appreciated! And thanks to Min for doing > such a great job. > > Cheers, > > Brian > From robert.kern at gmail.com Thu Jun 16 14:56:27 2011 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 16 Jun 2011 13:56:27 -0500 Subject: [IPython-dev] profiles + enthought traits In-Reply-To: References: Message-ID: On 6/15/11 7:39 PM, Fernando Perez wrote: > On Wed, Jun 15, 2011 at 5:31 PM, Satrajit Ghosh wrote: >> hi guys, >> >> do you already have a built in profile to suppress the additional fields of >> traits? if not is there a doc pointer somewhere i can use to create a new >> profile for ipy:xi (eye-pixie - that's my name for your new release :) )? > > You just need to save it from deathrow by updating it to work with 0.11: > > https://github.com/ipython/ipython/blob/master/IPython/deathrow/ipy_traits_completer.py > > I see a pull request in your future... Ideally, it wouldn't load without Traits being loaded. I previously posted an idea for implementing that, though I didn't get any feedback. Is this something worth my implementing? http://mail.scipy.org/pipermail/ipython-dev/2011-May/007527.html -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From fperez.net at gmail.com Thu Jun 16 16:19:28 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 16 Jun 2011 13:19:28 -0700 Subject: [IPython-dev] profiles + enthought traits In-Reply-To: References: Message-ID: On Thu, Jun 16, 2011 at 11:56 AM, Robert Kern wrote: > Ideally, it wouldn't load without Traits being loaded. I previously posted an > idea for implementing that, though I didn't get any feedback. Is this something > worth my implementing? > > http://mail.scipy.org/pipermail/ipython-dev/2011-May/007527.html Replied there to keep the thread/context consistent. Cheers, f From fperez.net at gmail.com Thu Jun 16 16:18:58 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 16 Jun 2011 13:18:58 -0700 Subject: [IPython-dev] Package-specific extensions: an idea In-Reply-To: References: Message-ID: On Tue, May 17, 2011 at 3:48 PM, Robert Kern wrote: > There's a general problem for writing package-specific extensions to IPython. > Namely, you want to be able to write and enable an extension to IPython that > provides special behavior for particular objects, say numpy arrays, without > requiring that a particular package be imported at startup. You can often get by > in ad hoc ways. For example, in the pretty-printing code, I added the ability to > register deferred type-checking. For magic functions, you can usually just do > local imports inside the magics. > > However, I've had an idea for a general solution. I'm kind of -1 on this approach right now, mostly because I really don't want to add more special paths to our execution logic. Instead, we have already the ability for users to register any function they desire to execute afterwards: https://github.com/ipython/ipython/blob/master/IPython/core/interactiveshell.py#L689 So my suggestion would be for this to be done by the user as a post-execute function. We can certainly provide it pre-canned to eliminate the need for users to rewrite boilerplate, but I'd rather keep the main run* methods as tight as they can reasonably be in the main codebase. How does that sound? f From robert.kern at gmail.com Thu Jun 16 17:16:08 2011 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 16 Jun 2011 16:16:08 -0500 Subject: [IPython-dev] Package-specific extensions: an idea In-Reply-To: References: Message-ID: On 6/16/11 3:18 PM, Fernando Perez wrote: > On Tue, May 17, 2011 at 3:48 PM, Robert Kern wrote: >> There's a general problem for writing package-specific extensions to IPython. >> Namely, you want to be able to write and enable an extension to IPython that >> provides special behavior for particular objects, say numpy arrays, without >> requiring that a particular package be imported at startup. You can often get by >> in ad hoc ways. For example, in the pretty-printing code, I added the ability to >> register deferred type-checking. For magic functions, you can usually just do >> local imports inside the magics. >> >> However, I've had an idea for a general solution. > > I'm kind of -1 on this approach right now, mostly because I really > don't want to add more special paths to our execution logic. Instead, > we have already the ability for users to register any function they > desire to execute afterwards: > > https://github.com/ipython/ipython/blob/master/IPython/core/interactiveshell.py#L689 > > So my suggestion would be for this to be done by the user as a > post-execute function. We can certainly provide it pre-canned to > eliminate the need for users to rewrite boilerplate, but I'd rather > keep the main run* methods as tight as they can reasonably be in the > main codebase. What would the user experience look like in this scenario? -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From takowl at gmail.com Thu Jun 16 17:22:19 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 16 Jun 2011 22:22:19 +0100 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: Some more thoughts about newapp: - If I do 'ipython -h', I get a long block of text sent back. How simple would it be to feed that into a pager (as 'man x' and 'git log' do) for easier viewing? - It would be good to have tab completion for the various subcommands & options. In Ubuntu, /etc/bash_completions.d/ is the relevant place. Anyone good at shell scripting? We should probably chat with packagers about this. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Thu Jun 16 19:51:55 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 17 Jun 2011 00:51:55 +0100 Subject: [IPython-dev] String encoding Message-ID: J?rgen's found that there's still a unicode problem in trunk, which I don't think can be completely resolved, but we'd like to get some more opinions on it. The issue is that, while we can parse Python code as either unicode or bytes, there's no way to indicate what encoding is used in either case. So: 1. If we parse as unicode, non-ascii characters which occur inside byte literals are always interpreted as bytes by encoding with utf-8. This is what we now do in trunk. 2. If we parse as bytes, bytes occurring inside unicode literals are always interpreted as characters by decoding with cp1252. The necessary parameter is not going to be included in Python, because it's not a problem in Python 3: http://bugs.python.org/issue5911 The practical upshot is platform dependent: 1 will always work correctly when the user enters u"???" (unicode literals), and will coincidentally work with byte literals where the terminal uses utf-8 (as I believe most Linux and Mac terminals do). 2 will always work as you'd expect when the user enters "???" (bytes literals), and will coincidentally work with unicode literals where the terminal uses cp1252 (Windows computers in English speaking countries and parts of Europe). I'm fairly confident that 1 is the better approach - it's critical that you can enter those characters as part of a unicode string, but less so that you can enter them in a byte string. Also, most of our users are on Linux or Mac, so it should 'just work' for more people. The question is whether we want to try to include a workaround for other cases. Where stdin_encoding is cp1252, we could encode each cell as cp1252 before parsing it. That would then behave as expected in the two commonest situations (UTF-8 unix terminals and cp1252 windows terminals). On the downside, it's an horrendously ugly hack, and I don't know what it would do on platforms other than CPython. J?rgen also suggested making it an option, although I wonder how many people will ever find it. My own inclination is simply to say that non-ascii characters will be interpreted correctly in unicode literals, but their behaviour in byte literals is undefined, and you should use the '\xe9' notation to write bytes above 127. Note that Python 3 actually enforces this rule: b"?" is a SyntaxError. But I'd like to collect some more thoughts, or see if we can come up with a way to avoid the problem (short of writing our own parser). Thanks for reading this - it took me a while to properly understand the problem, so I hope I've explained it clearly. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Fri Jun 17 00:08:44 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Thu, 16 Jun 2011 21:08:44 -0700 Subject: [IPython-dev] String encoding In-Reply-To: References: Message-ID: Thomas, Thanks for summarizing this. Is this the type of thing that we would want to add a config=True attribute to InteractiveShell to control this behavior? We could default to (1), but allow (2) if needed. Cheers, Brian On Thu, Jun 16, 2011 at 4:51 PM, Thomas Kluyver wrote: > J?rgen's found that there's still a unicode problem in trunk, which I don't > think can be completely resolved, but we'd like to get some more opinions on > it. > > The issue is that, while we can parse Python code as either unicode or > bytes, there's no way to indicate what encoding is used in either case. So: > 1. If we parse as unicode, non-ascii characters which occur inside byte > literals are always interpreted as bytes by encoding with utf-8. This is > what we now do in trunk. > 2. If we parse as bytes, bytes occurring inside unicode literals are always > interpreted as characters by decoding with cp1252. > > The necessary parameter is not going to be included in Python, because it's > not a problem in Python 3: http://bugs.python.org/issue5911 > > The practical upshot is platform dependent: > 1 will always work correctly when the user enters u"???" (unicode literals), > and will coincidentally work with byte literals where the terminal uses > utf-8 (as I believe most Linux and Mac terminals do). > 2 will always work as you'd expect when the user enters "???" (bytes > literals), and will coincidentally work with unicode literals where the > terminal uses cp1252 (Windows computers in English speaking countries and > parts of Europe). > > I'm fairly confident that 1 is the better approach - it's critical that you > can enter those characters as part of a unicode string, but less so that you > can enter them in a byte string. Also, most of our users are on Linux or > Mac, so it should 'just work' for more people. > > The question is whether we want to try to include a workaround for other > cases. Where stdin_encoding is cp1252, we could encode each cell as cp1252 > before parsing it. That would then behave as expected in the two commonest > situations (UTF-8 unix terminals and cp1252 windows terminals). On the > downside, it's an horrendously ugly hack, and I don't know what it would do > on platforms other than CPython. J?rgen also suggested making it an option, > although I wonder how many people will ever find it. > > My own inclination is simply to say that non-ascii characters will be > interpreted correctly in unicode literals, but their behaviour in byte > literals is undefined, and you should use the '\xe9' notation to write bytes > above 127. Note that Python 3 actually enforces this rule: b"?" is a > SyntaxError. But I'd like to collect some more thoughts, or see if we can > come up with a way to avoid the problem (short of writing our own parser). > > Thanks for reading this - it took me a while to properly understand the > problem, so I hope I've explained it clearly. > > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Fri Jun 17 02:39:46 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 16 Jun 2011 23:39:46 -0700 Subject: [IPython-dev] String encoding In-Reply-To: References: Message-ID: On Thu, Jun 16, 2011 at 4:51 PM, Thomas Kluyver wrote: > My own inclination is simply to say that non-ascii characters will be > interpreted correctly in unicode literals, but their behaviour in byte > literals is undefined, and you should use the '\xe9' notation to write bytes > above 127. Note that Python 3 actually enforces this rule: b"?" is a > SyntaxError. But I'd like to collect some more thoughts, or see if we can > come up with a way to avoid the problem (short of writing our own parser). > > Thanks for reading this - it took me a while to properly understand the > problem, so I hope I've explained it clearly. Many thanks for the excellent summary, Thomas. I concur with you, both because (even if slightly less convenient in py2 due to needing the explicit u prefix) it's semantically consistent with how unicode objects work, and because of it being the natural path for py3. I guess we could make it a configurable option, but I'm not even sure it's worth the added complexity, so I'm mildly -1 on going down that road, unless I can be convinced that the implementation isn't that complicated and that there's really a *major* usability win for certain users for whom the default is just too annoying to bear. Cheers, f From fperez.net at gmail.com Fri Jun 17 02:45:33 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 16 Jun 2011 23:45:33 -0700 Subject: [IPython-dev] Package-specific extensions: an idea In-Reply-To: References: Message-ID: On Thu, Jun 16, 2011 at 2:16 PM, Robert Kern wrote: > What would the user experience look like in this scenario? Since the config file is executed when IPython isn't fully up yet, it's not the place to put code that depends on IPython itself, that's why we have the exec_files field. So I have in my config file this: c.Global.exec_files = ['extras.py'] and extras.py is a simple python file where I do ip = get_ipython() and then call whatever I need on that object. So in this case, you could write: ip = get_ipython() ip.register_post_execute(yourfunc) where yourfunc is defined to be precisely the little blurb of code you suggested, that does the deferred module hooking. yourfunc is any callable, so you could have something like handler = DeferredHandler() ... handler.register('numpy', my_numpy_formatter) handler.register('traits', my_traits_completer) ... ip.register_post_execute(handler.execution_hook) or whatever method in this object implements the logic you suggested. I realize there's a tiny bit more work here, but I think the bulk of the boilerplate can be packaged in an easy to use way, and instead of adding special-case code to one of the most sensitive codepaths we have, we'd be reusing a generic mechanism we have. Cheers, f From takowl at gmail.com Fri Jun 17 06:24:11 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 17 Jun 2011 11:24:11 +0100 Subject: [IPython-dev] String encoding In-Reply-To: References: Message-ID: On 17 June 2011 07:39, Fernando Perez wrote: > I guess we could make it a configurable option, but I'm not even sure > it's worth the added complexity, so I'm mildly -1 on going down that > road, unless I can be convinced that the implementation isn't that > complicated and that there's really a *major* usability win for > certain users for whom the default is just too annoying to bear. > The complexity in terms of code is fairly minimal - a boolean config variable, and an if/else inside run_cell should cover it. The main downside would be the added load on testing and maintenance - if the variable became widely used, any bug report relating to unicode would leave us asking which way the user had it set. I'll leave it to J?rgen to put the case for usability. In fact, I've just worked out a way round the issue, although it's not pretty. If we were to encode each cell, and prepend the "# coding: " magic comment before parsing it, it seems to work. However, the line numbers within the cell are then out by 1 (i.e. if you see a traceback). As far as I can tell, there's no way to store this state between compile/parse calls - codeop.Compile doesn't remember it. I don't much like the idea of doing this, though. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Fri Jun 17 13:04:55 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 17 Jun 2011 10:04:55 -0700 Subject: [IPython-dev] Package-specific extensions: an idea In-Reply-To: References: Message-ID: On Thu, Jun 16, 2011 at 11:45 PM, Fernando Perez wrote: > On Thu, Jun 16, 2011 at 2:16 PM, Robert Kern wrote: >> What would the user experience look like in this scenario? > > Since the config file is executed when IPython isn't fully up yet, > it's not the place to put code that depends on IPython itself, that's > why we have the exec_files field. ?So I have in my config file this: But wait, extensions are loaded later when IPython has come up fully. Why not put this logic in the extension itself. IOW, have the extension call: ip.register_post_execute(yourfunc) that would fully keep all of the logic localized in the extension as it should be. Brian > c.Global.exec_files = ['extras.py'] > > and extras.py is a simple python file where I do > > ip = get_ipython() > > and then call whatever I need on that object. ?So in this case, you could write: > > ip = get_ipython() > ip.register_post_execute(yourfunc) > > where yourfunc is defined to be precisely the little blurb of code you > suggested, that does the deferred module hooking. ?yourfunc is any > callable, so you could have something like > > handler = DeferredHandler() > ... > handler.register('numpy', my_numpy_formatter) > handler.register('traits', my_traits_completer) > > ... > > ip.register_post_execute(handler.execution_hook) > > or whatever method in this object implements the logic you suggested. > > I realize there's a tiny bit more work here, but I think the bulk of > the boilerplate can be packaged in an easy to use way, and instead of > adding special-case code to one of the most sensitive codepaths we > have, we'd be reusing a generic mechanism we have. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From ellisonbg at gmail.com Fri Jun 17 13:08:04 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 17 Jun 2011 10:08:04 -0700 Subject: [IPython-dev] String encoding In-Reply-To: References: Message-ID: On Fri, Jun 17, 2011 at 3:24 AM, Thomas Kluyver wrote: > On 17 June 2011 07:39, Fernando Perez wrote: >> >> I guess we could make it a configurable option, but I'm not even sure >> it's worth the added complexity, so I'm mildly -1 on going down that >> road, unless I can be convinced that the implementation isn't that >> complicated and that there's really a *major* usability win for >> certain users for whom the default is just too annoying to bear. > > The complexity in terms of code is fairly minimal - a boolean config > variable, and an if/else inside run_cell should cover it. The main downside > would be the added load on testing and maintenance - if the variable became > widely used, any bug report relating to unicode would leave us asking which > way the user had it set. > > I'll leave it to J?rgen to put the case for usability. > > In fact, I've just worked out a way round the issue, although it's not > pretty. If we were to encode each cell, and prepend the "# coding: " > magic comment before parsing it, it seems to work. However, the line numbers > within the cell are then out by 1 (i.e. if you see a traceback). As far as I > can tell, there's no way to store this state between compile/parse calls - > codeop.Compile doesn't remember it. I don't much like the idea of doing > this, though. This sounds too complex. I would say let's just go with (1). Cheers, Brian > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Fri Jun 17 14:13:10 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 17 Jun 2011 11:13:10 -0700 Subject: [IPython-dev] Package-specific extensions: an idea In-Reply-To: References: Message-ID: On Fri, Jun 17, 2011 at 10:04 AM, Brian Granger wrote: > > But wait, extensions are loaded later when IPython has come up fully. > Why not put this logic in the extension itself. ?IOW, have the > extension call: > > ip.register_post_execute(yourfunc) > > that would fully keep all of the logic localized in the extension as > it should be. Yup, that should work fine indeed. Cheers, f From fperez.net at gmail.com Fri Jun 17 14:14:58 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 17 Jun 2011 11:14:58 -0700 Subject: [IPython-dev] String encoding In-Reply-To: References: Message-ID: On Fri, Jun 17, 2011 at 10:08 AM, Brian Granger wrote: > This sounds too complex. ?I would say let's just go with (1). That's my feeling too. Jorgen, does that sound like a show stopper to you? It does require the explicit u"" prefix for unicode literals, but that seems like a reasonable thing to ask, given the semantics of byte strings and unicode. Cheers, f From jorgen.stenarson at bostream.nu Fri Jun 17 14:25:12 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Fri, 17 Jun 2011 20:25:12 +0200 Subject: [IPython-dev] Fwd: Re: String encoding Message-ID: <4DFB9C08.10305@bostream.nu> I accidentaly sent this only to Thomas. Here it is for the list. Thomas Kluyver skrev 2011-06-17 12:24: > > I'll leave it to J?rgen to put the case for usability. When typing new stuff interactively it is only a case of remembering to add a u before the string which is not such a big deal. I think the most annoying thing will be when trying to reevaluate a repr of some string object that happens to contain non-ascii characters, I do not know how often that happens. I guess we will see how many questions/"bugs reports" we get about this, because alternative 1 is different from how the regular prompt works. I think we should go with 1 and revisit this decision if we get a lot of questions/"bug reports". /J?rgen From robert.kern at gmail.com Fri Jun 17 14:26:01 2011 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 17 Jun 2011 13:26:01 -0500 Subject: [IPython-dev] Package-specific extensions: an idea In-Reply-To: References: Message-ID: On 6/17/11 12:04 PM, Brian Granger wrote: > On Thu, Jun 16, 2011 at 11:45 PM, Fernando Perez wrote: >> On Thu, Jun 16, 2011 at 2:16 PM, Robert Kern wrote: >>> What would the user experience look like in this scenario? >> >> Since the config file is executed when IPython isn't fully up yet, >> it's not the place to put code that depends on IPython itself, that's >> why we have the exec_files field. So I have in my config file this: > > But wait, extensions are loaded later when IPython has come up fully. > Why not put this logic in the extension itself. IOW, have the > extension call: > > ip.register_post_execute(yourfunc) > > that would fully keep all of the logic localized in the extension as > it should be. Except that you don't want to register a separate function for each extension. You want to have a single function that deals with all of the delayed activations. And you want to implement this logic exactly once, not reimplement it in each extension that needs it. How about this: we implement the logic that goes through the list of ('module_name', 'extension_name') pairs in an InteractiveShell.check_deferred_extensions() method. We keep the configuration in c.Global.deferred_extensions as I had it. We make no modifications to the run_cell() method. Upon configuration, *if* deferred_extensions is not empty, then the InteractiveShell uses self.register_post_execute(self.check_deferred_extensions). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From takowl at gmail.com Fri Jun 17 15:54:44 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Fri, 17 Jun 2011 20:54:44 +0100 Subject: [IPython-dev] String encoding In-Reply-To: <4DFB94D5.2080909@bostream.nu> References: <4DFB94D5.2080909@bostream.nu> Message-ID: On 17 June 2011 18:54, J?rgen Stenarson wrote: > I think the most annoying thing will be when trying to reevaluate a repr of > some string object that happens to contain non-ascii characters, I do not > know how often that happens. As far as I know, the repr never displays those characters in a byte string - it always uses the '\xe9' notation, which should work with no problems. > I guess we will see how many questions/"bugs reports" we get about this, > because alternative 1 is different from how the regular prompt works. Unfortunately, both alternatives are different from how the pure Python prompt works, at least for some users (e.g. with cp850, neither alternative will work for both unicode and bytes literals). The Python interactive shell must be able to call the parser in a way that's not exposed to pure Python code. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Jun 18 18:40:54 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 18 Jun 2011 15:40:54 -0700 Subject: [IPython-dev] python3.2 + ipython : KO [Numpy-discussion] IPython on python3, for the adventurous... In-Reply-To: References: Message-ID: Hi Olivier, please send your messages about IPython to the list, not directly to me, so that others can also assist with the problem and the discussion is publicly archived. Here is the mailing list info: http://mail.scipy.org/mailman/listinfo/ipython-dev http://mail.scipy.org/mailman/listinfo/ipython-user On Sat, Jun 18, 2011 at 7:41 AM, Olivier Darge wrote: > hello Fernando, > > I consider switching to python3, > currently 3.2 on mac. > I really want to continue using this nice IPython :-) > > I found this page off course... http://ipython.scipy.org/moin/Python3 > > I cant' succeed running the last ipython3. > > installation of this package seems ok : > > mbp13:ipython-ipython-py3k-9c4fead odar$ python3 setup.py install > ============================================================================ > BUILDING IPYTHON > ??????????????? python: 3.2 (r32:88452, Feb 20 2011, 11:12:31)? [GCC 4.2.1 > ??????????????????????? (Apple Inc. build 5664)] > ????????????? platform: darwin > > OPTIONAL DEPENDENCIES > ??????????????? sphinx: Not found (required for building documentation) > ????????????? pygments: Not found (required for syntax highlighting > ??????????????????????? documentation) > ????????????????? nose: Not found (required for running the test suite) > ?????????????? pexpect: no (required for running standalone doctests) > ???????????????? pyzmq: no (required for qtconsole and parallel computing > ??????????????????????? capabilities) > ????????????? readline: yes > running install > running build > running build_py > creating build > creating build/lib > creating build/lib/IPython > > > but, when running ipython3 executable... : > > mbp13:~ odar$ /Library/Frameworks/Python.framework/Versions/3.2/bin/ipython3 > ; exit; > Error in sys.excepthook: > Traceback (most recent call last): > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", > line 736, in __init__ > ??? restore_signals, start_new_session) > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", > line 1330, in _execute_child > ??? raise child_exception_type(errno_num, err_msg) > OSError: [Errno 2] No such file or directory: 'otool' > > Original exception was: > Traceback (most recent call last): > ? File "/Library/Frameworks/Python.framework/Versions/3.2/bin/ipython3", > line 10, in > ??? launch_new_instance() > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/frontend/terminal/ipapp.py", > line 662, in launch_new_instance > ??? app.start() > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/core/application.py", > line 219, in start > ??? self.initialize() > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/core/application.py", > line 211, in initialize > ??? self.construct() > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/frontend/terminal/ipapp.py", > line 478, in construct > ??? self.shell = > TerminalInteractiveShell.instance(config=self.master_config) > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/config/configurable.py", > line 203, in instance > ??? inst = cls(*args, **kwargs) > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/frontend/terminal/interactiveshell.py", > line 86, in __init__ > ??? user_global_ns=user_global_ns, custom_exceptions=custom_exceptions > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/core/interactiveshell.py", > line 400, in __init__ > ??? self.init_readline() > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/core/interactiveshell.py", > line 1542, in init_readline > ??? import IPython.utils.rlineimpl as readline > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/utils/rlineimpl.py", > line 59, in > ??? p = Popen(['otool', '-L', _rl.__file__], stdout=PIPE, stderr=PIPE) > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", > line 736, in __init__ > ??? restore_signals, start_new_session) > ? File > "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", > line 1330, in _execute_child > ??? raise child_exception_type(errno_num, err_msg) > OSError: [Errno 2] No such file or directory: 'otool' > logout > > [Op?ration termin?e] > > > really strange. > What can be missing in my way of launching ipython3 executable ? > > btw, thanks a lot for providing IPython ! > > cheers from Belgium, > > -- > Olivier DARGE Indeed, as you already found out, it seems XCode is needed on the mac because of the unconditional call to otool. That sounds like a bug to me that we've effectively made Xcode a dependency on OSX, we shouldn't do that. But I'd like correction from our osx experts in case I'm wrong, before opening a ticket on this... Cheers, f From benjaminrk at gmail.com Sat Jun 18 18:47:10 2011 From: benjaminrk at gmail.com (Min RK) Date: Sat, 18 Jun 2011 15:47:10 -0700 Subject: [IPython-dev] python3.2 + ipython : KO [Numpy-discussion] IPython on python3, for the adventurous... In-Reply-To: References: Message-ID: I did not know otool was part of XCode. That should definitely be conditional, and perhaps there is a better way to detect libedit without it. -MinRK On Jun 18, 2011, at 15:40, Fernando Perez wrote: > Hi Olivier, > > please send your messages about IPython to the list, not directly to > me, so that others can also assist with the problem and the discussion > is publicly archived. Here is the mailing list info: > > http://mail.scipy.org/mailman/listinfo/ipython-dev > http://mail.scipy.org/mailman/listinfo/ipython-user > > > On Sat, Jun 18, 2011 at 7:41 AM, Olivier Darge wrote: >> hello Fernando, >> >> I consider switching to python3, >> currently 3.2 on mac. >> I really want to continue using this nice IPython :-) >> >> I found this page off course... http://ipython.scipy.org/moin/Python3 >> >> I cant' succeed running the last ipython3. >> >> installation of this package seems ok : >> >> mbp13:ipython-ipython-py3k-9c4fead odar$ python3 setup.py install >> ============================================================================ >> BUILDING IPYTHON >> python: 3.2 (r32:88452, Feb 20 2011, 11:12:31) [GCC 4.2.1 >> (Apple Inc. build 5664)] >> platform: darwin >> >> OPTIONAL DEPENDENCIES >> sphinx: Not found (required for building documentation) >> pygments: Not found (required for syntax highlighting >> documentation) >> nose: Not found (required for running the test suite) >> pexpect: no (required for running standalone doctests) >> pyzmq: no (required for qtconsole and parallel computing >> capabilities) >> readline: yes >> running install >> running build >> running build_py >> creating build >> creating build/lib >> creating build/lib/IPython >> >> >> but, when running ipython3 executable... : >> >> mbp13:~ odar$ /Library/Frameworks/Python.framework/Versions/3.2/bin/ipython3 >> ; exit; >> Error in sys.excepthook: >> Traceback (most recent call last): >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", >> line 736, in __init__ >> restore_signals, start_new_session) >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", >> line 1330, in _execute_child >> raise child_exception_type(errno_num, err_msg) >> OSError: [Errno 2] No such file or directory: 'otool' >> >> Original exception was: >> Traceback (most recent call last): >> File "/Library/Frameworks/Python.framework/Versions/3.2/bin/ipython3", >> line 10, in >> launch_new_instance() >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/frontend/terminal/ipapp.py", >> line 662, in launch_new_instance >> app.start() >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/core/application.py", >> line 219, in start >> self.initialize() >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/core/application.py", >> line 211, in initialize >> self.construct() >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/frontend/terminal/ipapp.py", >> line 478, in construct >> self.shell = >> TerminalInteractiveShell.instance(config=self.master_config) >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/config/configurable.py", >> line 203, in instance >> inst = cls(*args, **kwargs) >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/frontend/terminal/interactiveshell.py", >> line 86, in __init__ >> user_global_ns=user_global_ns, custom_exceptions=custom_exceptions >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/core/interactiveshell.py", >> line 400, in __init__ >> self.init_readline() >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/core/interactiveshell.py", >> line 1542, in init_readline >> import IPython.utils.rlineimpl as readline >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/IPython/utils/rlineimpl.py", >> line 59, in >> p = Popen(['otool', '-L', _rl.__file__], stdout=PIPE, stderr=PIPE) >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", >> line 736, in __init__ >> restore_signals, start_new_session) >> File >> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/subprocess.py", >> line 1330, in _execute_child >> raise child_exception_type(errno_num, err_msg) >> OSError: [Errno 2] No such file or directory: 'otool' >> logout >> >> [Op?ration termin?e] >> >> >> really strange. >> What can be missing in my way of launching ipython3 executable ? >> >> btw, thanks a lot for providing IPython ! >> >> cheers from Belgium, >> >> -- >> Olivier DARGE > > Indeed, as you already found out, it seems XCode is needed on the mac > because of the unconditional call to otool. > > That sounds like a bug to me that we've effectively made Xcode a > dependency on OSX, we shouldn't do that. But I'd like correction from > our osx experts in case I'm wrong, before opening a ticket on this... > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From fperez.net at gmail.com Sat Jun 18 18:57:39 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 18 Jun 2011 15:57:39 -0700 Subject: [IPython-dev] python3.2 + ipython : KO [Numpy-discussion] IPython on python3, for the adventurous... In-Reply-To: References: Message-ID: On Sat, Jun 18, 2011 at 3:47 PM, Min RK wrote: > I did not know otool was part of XCode. > > That should definitely be conditional, and perhaps there is a better way to detect libedit without it. https://github.com/ipython/ipython/issues/524 Made it critical, b/c we'll make a ton of osx users pretty unhappy out of the gate otherwise (anyone without xcode). Cheers, f From benjaminrk at gmail.com Sat Jun 18 19:42:34 2011 From: benjaminrk at gmail.com (MinRK) Date: Sat, 18 Jun 2011 16:42:34 -0700 Subject: [IPython-dev] python3.2 + ipython : KO [Numpy-discussion] IPython on python3, for the adventurous... In-Reply-To: References: Message-ID: See here for a possible fix: https://github.com/ipython/ipython/pull/525 -MinRK On Sat, Jun 18, 2011 at 15:57, Fernando Perez wrote: > On Sat, Jun 18, 2011 at 3:47 PM, Min RK wrote: > > I did not know otool was part of XCode. > > > > That should definitely be conditional, and perhaps there is a better way > to detect libedit without it. > > https://github.com/ipython/ipython/issues/524 > > Made it critical, b/c we'll make a ton of osx users pretty unhappy out > of the gate otherwise (anyone without xcode). > > Cheers, > > f > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agardelein at yahoo.fr Sun Jun 19 12:09:14 2011 From: agardelein at yahoo.fr (Arnaud Gardelein) Date: Sun, 19 Jun 2011 18:09:14 +0200 Subject: [IPython-dev] Docstrings for magic functions Message-ID: <1308499754.5586.16.camel@bomberx> Hi, I'm Arnaud, new to this mailing list but using ipython since a little more than a year now. I really like IPython features and decided to write an application on top of it, oscopy, a kind of oscilloscope to view electrical simulation results (oscopy.org). It consist of a framework and an application that use heavily magic functions to facilitate the access to framework functions. I have documented those functions with docstrings, that can be displayed by typing %magic_name?, for the user it would be simpler to use 'help magic_name'. For instance I have tried to do 'help lsmagic' but of course lsmagic is not defined in global scope. Is there a way have this working ? Regards, Arnaud. From takowl at gmail.com Sun Jun 19 14:02:14 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 19 Jun 2011 19:02:14 +0100 Subject: [IPython-dev] Docstrings for magic functions In-Reply-To: <1308499754.5586.16.camel@bomberx> References: <1308499754.5586.16.camel@bomberx> Message-ID: On 19 June 2011 17:09, Arnaud Gardelein wrote: > Hi, > > I'm Arnaud, new to this mailing list but using ipython since a little > more than a year now. I really like IPython features and decided to > write an application on top of it, oscopy, a kind of oscilloscope to > view electrical simulation results (oscopy.org). > > It consist of a framework and an application that use heavily magic > functions to facilitate the access to framework functions. I have > documented those functions with docstrings, that can be displayed by > typing %magic_name?, for the user it would be simpler to use 'help > magic_name'. For instance I have tried to do 'help lsmagic' but of > course lsmagic is not defined in global scope. > Is there a way have this working ? > Hi Arnaud, You can already call 'pinfo lsmagic', which works as you'd describe. pinfo is short for print information. If magic calls are very important to your application, it should be possible for you to make 'help' an alias for pinfo. Then again, I prefer to type 'lsmagic?' rather than 'help lsmagic'. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From johann.cohentanugi at gmail.com Sun Jun 19 15:31:44 2011 From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi) Date: Sun, 19 Jun 2011 21:31:44 +0200 Subject: [IPython-dev] [IPython-User] [Windows] pyzmq 2.1.7 installation In-Reply-To: <20110617233052.C1C2.B1C76292@gmail.com> References: <20110616022515.8EB8.B1C76292@gmail.com> <20110617233052.C1C2.B1C76292@gmail.com> Message-ID: <4DFE4EA0.8050609@gmail.com> hi there, is anyone working on LSF support for the parallel engines? best, Johann From benjaminrk at gmail.com Sun Jun 19 16:10:44 2011 From: benjaminrk at gmail.com (MinRK) Date: Sun, 19 Jun 2011 13:10:44 -0700 Subject: [IPython-dev] [IPython-User] [Windows] pyzmq 2.1.7 installation In-Reply-To: <4DFE4EA0.8050609@gmail.com> References: <20110616022515.8EB8.B1C76292@gmail.com> <20110617233052.C1C2.B1C76292@gmail.com> <4DFE4EA0.8050609@gmail.com> Message-ID: On Sun, Jun 19, 2011 at 12:31, Johann Cohen-Tanugi wrote: > hi there, is anyone working on LSF support for the parallel engines? Not yet, though I do see it in 0.10.2. I imagine LSF support would be another trivial subclass of the PBS Launcher like SGE. If you want to contribute/test LSF Launchers, that would be great! See https://github.com/ipython/ipython/blob/0.10.2/IPython/kernel/scripts/ipcluster.py for the old LSF support and https://github.com/ipython/ipython/blob/newapp/IPython/parallel/apps/launcher.py for the file containing the Launchers in 0.11. -MinRK > best, > Johann > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From agardelein at yahoo.fr Sun Jun 19 17:14:34 2011 From: agardelein at yahoo.fr (Arnaud Gardelein) Date: Sun, 19 Jun 2011 23:14:34 +0200 Subject: [IPython-dev] Docstrings for magic functions In-Reply-To: References: <1308499754.5586.16.camel@bomberx> Message-ID: <1308518074.3922.0.camel@bomberx> Thanks Thomas for the tip. I will implement an alias to pinfo. Arnaud. Le dimanche 19 juin 2011 ? 19:02 +0100, Thomas Kluyver a ?crit : > On 19 June 2011 17:09, Arnaud Gardelein wrote: > Hi, > > I'm Arnaud, new to this mailing list but using ipython since a > little > more than a year now. I really like IPython features and > decided to > write an application on top of it, oscopy, a kind of > oscilloscope to > view electrical simulation results (oscopy.org). > > It consist of a framework and an application that use heavily > magic > functions to facilitate the access to framework functions. I > have > documented those functions with docstrings, that can be > displayed by > typing %magic_name?, for the user it would be simpler to use > 'help > magic_name'. For instance I have tried to do 'help lsmagic' > but of > course lsmagic is not defined in global scope. > Is there a way have this working ? > > Hi Arnaud, > > You can already call 'pinfo lsmagic', which works as you'd describe. > pinfo is short for print information. If magic calls are very > important to your application, it should be possible for you to make > 'help' an alias for pinfo. Then again, I prefer to type 'lsmagic?' > rather than 'help lsmagic'. > > Thanks, > Thomas > From benjaminrk at gmail.com Mon Jun 20 03:34:43 2011 From: benjaminrk at gmail.com (Min RK) Date: Mon, 20 Jun 2011 00:34:43 -0700 Subject: [IPython-dev] [IPython-User] [Windows] pyzmq 2.1.7 installation In-Reply-To: <4DFEF2D7.6010906@lupm.univ-montp2.fr> References: <20110616022515.8EB8.B1C76292@gmail.com> <20110617233052.C1C2.B1C76292@gmail.com> <4DFE4EA0.8050609@gmail.com> <4DFEF2D7.6010906@lupm.univ-montp2.fr> Message-ID: <8A1F8D08-A6FA-4584-8A18-EA1A77610C03@gmail.com> Yes, trivial might be an exaggeration, but it should just be a matter of subclassing PBSLauncher and using bsub instead of qsub, and making appropriate adjustments to job templates etc. Looking at how the SGE classes derive from PBS should provide most of what you need. You may not even need to override any methods, but I'm not sufficiently familiar with LSF to be sure. That should be easier for someone who actually has an LSF system to test, rather than just hoping there are no typos as I would have to do. -MinRK On Jun 20, 2011, at 0:12, Johann Cohen-Tanugi wrote: > hi Min, > ok I will be happy to try out, once I understand enough of what is there already ;) > Given the impressive amount of work in this 0.11 release, I am suspicious as to what you call 'trivial' :) > > best, > Johann > > On 06/19/2011 10:10 PM, MinRK wrote: >> On Sun, Jun 19, 2011 at 12:31, Johann Cohen-Tanugi >> wrote: >>> hi there, is anyone working on LSF support for the parallel engines? >> Not yet, though I do see it in 0.10.2. I imagine LSF support would be >> another trivial subclass of the PBS Launcher like SGE. >> >> If you want to contribute/test LSF Launchers, that would be great! >> >> See https://github.com/ipython/ipython/blob/0.10.2/IPython/kernel/scripts/ipcluster.py >> for the old LSF support >> >> and https://github.com/ipython/ipython/blob/newapp/IPython/parallel/apps/launcher.py >> for the file containing the Launchers in 0.11. >> >> -MinRK >> >>> best, >>> Johann >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> From takowl at gmail.com Mon Jun 20 08:53:18 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 20 Jun 2011 13:53:18 +0100 Subject: [IPython-dev] Website Message-ID: This is now RC1 for the new website: http://takluyver.github.com/ipython-website/ Hopefully the only thing still to be sorted out is the banner font - Klonuo, can we try a couple of different possibilities for that? The tiles in the sidebar now have a pale blue background, thanks to Klonuo. I think this looks much better than the previous grey. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Mon Jun 20 09:00:23 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 20 Jun 2011 14:00:23 +0100 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: I'm getting ipython-qtconsole failing in newapp: Traceback (most recent call last): File "/home/thomas/code/virtualenvs/ipy-trunk/bin/ipython-qtconsole", line 6, in main() File "/home/thomas/code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/frontend/qt/console/ipythonqt.py", line 224, in main kernel_manager.start_kernel(**kwargs) File "/home/thomas/code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/frontend/qt/kernelmanager.py", line 208, in start_kernel super(QtKernelManager, self).start_kernel(*args, **kw) File "/home/thomas/code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/zmq/kernelmanager.py", line 794, in start_kernel stdin_port=stdin[1], hb_port=hb[1], **kw) File "/home/thomas/code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/zmq/ipkernel.py", line 662, in launch_kernel *args, **kwargs) TypeError: base_launch_kernel() got an unexpected keyword argument 'colors' Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Mon Jun 20 12:44:20 2011 From: benjaminrk at gmail.com (MinRK) Date: Mon, 20 Jun 2011 09:44:20 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: I think your environment is stale, because ipythonqt.py has been renamed to qtconsole.py, and you might be launching the old script via a lingering .pyc or something. Note that ipython-qtconsole has been removed in favor of `ipython qtconsole` per Brian's request, except as a GUI script with setuptools. -MinRK On Mon, Jun 20, 2011 at 06:00, Thomas Kluyver wrote: > I'm getting ipython-qtconsole failing in newapp: > > Traceback (most recent call last): > ? File "/home/thomas/code/virtualenvs/ipy-trunk/bin/ipython-qtconsole", line > 6, in > ??? main() > ? File > "/home/thomas/code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/frontend/qt/console/ipythonqt.py", > line 224, in main > ??? kernel_manager.start_kernel(**kwargs) > ? File > "/home/thomas/code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/frontend/qt/kernelmanager.py", > line 208, in start_kernel > ??? super(QtKernelManager, self).start_kernel(*args, **kw) > ? File > "/home/thomas/code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/zmq/kernelmanager.py", > line 794, in start_kernel > ??? stdin_port=stdin[1], hb_port=hb[1], **kw) > ? File > "/home/thomas/code/virtualenvs/ipy-trunk/lib/python2.7/site-packages/IPython/zmq/ipkernel.py", > line 662, in launch_kernel > ??? *args, **kwargs) > TypeError: base_launch_kernel() got an unexpected keyword argument 'colors' > > Thomas > From takowl at gmail.com Mon Jun 20 12:56:17 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 20 Jun 2011 17:56:17 +0100 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On 20 June 2011 17:44, MinRK wrote: > I think your environment is stale, because ipythonqt.py has been > renamed to qtconsole.py, and you might be launching the old script via > a lingering .pyc or something. > Oh yes, my mistake, I was doing ipython-qtconsole. We seem to have broken non-ascii input at the Qt console. I'm looking into it. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From klonuo at gmail.com Mon Jun 20 13:14:17 2011 From: klonuo at gmail.com (Klonuo) Date: Mon, 20 Jun 2011 19:14:17 +0200 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: <20110620191414.89CC.B1C76292@gmail.com> On Mon, 20 Jun 2011 13:53:18 +0100 Thomas Kluyver wrote: > This is now RC1 for the new website: > > http://takluyver.github.com/ipython-website/ > > Hopefully the only thing still to be sorted out is the banner font - Klonuo, > can we try a couple of different possibilities for that? > > The tiles in the sidebar now have a pale blue background, thanks to Klonuo. > I think this looks much better than the previous grey. > OK, Thomas :) Are there any suggestions which fonts should be used, as I'm not in with free fonts? Also about blue color used in logo image: should we maybe use blue color from H1 (darker) or H2 element (slightly lighter) or? I'd comment on footer - I think that font should be reduced, as it seems it's in same size as body text Cheers From benjaminrk at gmail.com Mon Jun 20 14:10:09 2011 From: benjaminrk at gmail.com (MinRK) Date: Mon, 20 Jun 2011 11:10:09 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: I think we should merge newapp into master. It is a big change, and needs to spend some time there before release, and that time is quickly running out. We should be releasing 0.11 in less than 2 weeks. It also makes other pull requests hard, because it touches so much of the code base. -MinRK On Mon, Jun 20, 2011 at 09:56, Thomas Kluyver wrote: > On 20 June 2011 17:44, MinRK wrote: >> >> I think your environment is stale, because ipythonqt.py has been >> renamed to qtconsole.py, and you might be launching the old script via >> a lingering .pyc or something. > > Oh yes, my mistake, I was doing ipython-qtconsole. > > We seem to have broken non-ascii input at the Qt console. I'm looking into > it. > > Thomas > From takowl at gmail.com Mon Jun 20 14:12:44 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 20 Jun 2011 19:12:44 +0100 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On 20 June 2011 17:56, Thomas Kluyver wrote: > > We seem to have broken non-ascii input at the Qt console. I'm looking into > it. IPython/zmq/session.py, line 76 - we're bludgeoning unicode out of a dict. So the console sends the execute request OK, but the kernel flattens it out in retrieving it. I'm not quite sure why we're squashing on unpacking: both the server and the client should be capable of handling unicode strings. Made PR 532. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Mon Jun 20 15:58:48 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 20 Jun 2011 12:58:48 -0700 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: On Mon, Jun 20, 2011 at 5:53 AM, Thomas Kluyver wrote: > > Hopefully the only thing still to be sorted out is the banner font - Klonuo, > can we try a couple of different possibilities for that? > Minor comment: whatever text is used should be rendered with rgba subpixel antialiasing, currently it's only using simple font-color antialiasing, and the difference is pretty noticeable on a modern LCD. Cheers, f From takowl at gmail.com Mon Jun 20 16:30:37 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 20 Jun 2011 21:30:37 +0100 Subject: [IPython-dev] Website In-Reply-To: <20110620191414.89CC.B1C76292@gmail.com> References: <20110620191414.89CC.B1C76292@gmail.com> Message-ID: On 20 June 2011 18:14, Klonuo wrote: > > Are there any suggestions which fonts should be used, as I'm not in with > free fonts? > I'm not in with fonts at all, I'm afraid. I think Min suggested Anonymous Pro, another monospace font. Let's also try with a sans-serif variable width font. There's a list here: http://www.google.com/webfonts?subset=latin&category=sans-serif > Also about blue color used in logo image: should we maybe use blue color > from H1 (darker) or H2 element (slightly lighter) or? > It's up to you! > I'd comment on footer - I think that font should be reduced, as it seems > it's in same size as body text I'll fiddle with it. Thanks again! Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Mon Jun 20 17:00:03 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 20 Jun 2011 22:00:03 +0100 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On 20 June 2011 19:10, MinRK wrote: > I think we should merge newapp into master. It is a big change, and > needs to spend some time there before release, and that time is > quickly running out. We should be releasing 0.11 in less than 2 > weeks. > > It also makes other pull requests hard, because it touches so much of > the code base. > I'll second this - we're not going to reject it, the diff is too big to really get a handle on, and various other pull requests will need to be rebased once it's merged, so we may as well get on with it. The only thing I would suggest is: can we tag* the commit immediately before we merge, so that we've got a reference point if we think there are regressions. *I'm guessing this is how git tags work - if not, substitute the appropriate term. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Mon Jun 20 17:15:10 2011 From: benjaminrk at gmail.com (MinRK) Date: Mon, 20 Jun 2011 14:15:10 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On Mon, Jun 20, 2011 at 14:00, Thomas Kluyver wrote: > On 20 June 2011 19:10, MinRK wrote: >> >> I think we should merge newapp into master. ?It is a big change, and >> needs to spend some time there before release, and that time is >> quickly running out. ?We should be releasing 0.11 in less than 2 >> weeks. >> >> It also makes other pull requests hard, because it touches so much of >> the code base. > > I'll second this - we're not going to reject it, the diff is too big to > really get a handle on, and various other pull requests will need to be > rebased once it's merged, so we may as well get on with it. > > The only thing I would suggest is: can we tag* the commit immediately before > we merge, so that we've got a reference point if we think there are > regressions. > > *I'm guessing this is how git tags work - if not, substitute the appropriate > term. Tags are typically a permanent, lasting reference point, though I suppose we could have a transient tag pointing to pre-newapp HEAD. Alternatively, we could ensure that newapp gets a proper merge, which would make the previous head obvious (merge commits have two parents), but that's not quite as convenient for easy checkout as a proper tag. -MinRK > > Thomas > From klonuo at gmail.com Mon Jun 20 17:35:19 2011 From: klonuo at gmail.com (Klonuo) Date: Mon, 20 Jun 2011 23:35:19 +0200 Subject: [IPython-dev] Website In-Reply-To: References: <20110620191414.89CC.B1C76292@gmail.com> Message-ID: <20110620233512.7BB9.B1C76292@gmail.com> On Mon, 20 Jun 2011 21:30:37 +0100 Thomas Kluyver wrote: > On 20 June 2011 18:14, Klonuo wrote: > > > > > Are there any suggestions which fonts should be used, as I'm not in with > > free fonts? > > > > I'm not in with fonts at all, I'm afraid. I think Min suggested Anonymous > Pro, another monospace font. Let's also try with a sans-serif variable width > font. There's a list here: > > http://www.google.com/webfonts?subset=latin&category=sans-serif > I couldn't find anything interesting to me except Droid Sans Mono Added Anonymous Pro as suggested and Quicksend to add more exotic > > Also about blue color used in logo image: should we maybe use blue color > > from H1 (darker) or H2 element (slightly lighter) or? > > > > It's up to you! > I choose H2 blue -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_fonts_sample_1.pdf Type: application/octet-stream Size: 26252 bytes Desc: not available URL: From takowl at gmail.com Mon Jun 20 18:09:57 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 20 Jun 2011 23:09:57 +0100 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On 20 June 2011 22:15, MinRK wrote: > Tags are typically a permanent, lasting reference point, though I > suppose we could have a transient tag pointing to pre-newapp HEAD. > Alternatively, we could ensure that newapp gets a proper merge, which > would make the previous head obvious (merge commits have two parents), > but that's not quite as convenient for easy checkout as a proper tag. Let's have a tag for a bit, just for easy use with checkout and bisect. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Mon Jun 20 19:22:27 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 20 Jun 2011 16:22:27 -0700 Subject: [IPython-dev] Website In-Reply-To: <20110620233512.7BB9.B1C76292@gmail.com> References: <20110620191414.89CC.B1C76292@gmail.com> <20110620233512.7BB9.B1C76292@gmail.com> Message-ID: On Mon, Jun 20, 2011 at 2:35 PM, Klonuo wrote: > > I couldn't find anything interesting to me except Droid Sans Mono > Added Anonymous Pro as suggested and Quicksend to add more exotic I actually like quicksend a lot, though it's perhaps a bit too thin, and I think we said we wanted to stick to a serifed 'I'. I have one comment for all: the size of the brackets and the location of the y. The current logo pushes the y up and make the brackets a little smaller, so that they are better balanced visually. I know that y is normally a drop letter, so I think it's fine to leave it droppped, but I think we should then make the [] little smaller. Otherwise, in all but the Droid sample, the y feels a little lost with a lot of empty space above it inside the []. Cheers, f From fperez.net at gmail.com Mon Jun 20 19:24:15 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 20 Jun 2011 16:24:15 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On Mon, Jun 20, 2011 at 3:09 PM, Thomas Kluyver wrote: > > Let's have a tag for a bit, just for easy use with checkout and bisect. > +1 for a tag. Since our release tags are all prefixed with rel-, I think it's perfectly reasonable to use another prefix for tags for development use. Say 'dev', feeling creative :) f From benjaminrk at gmail.com Mon Jun 20 19:38:35 2011 From: benjaminrk at gmail.com (MinRK) Date: Mon, 20 Jun 2011 16:38:35 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On Mon, Jun 20, 2011 at 16:24, Fernando Perez wrote: > On Mon, Jun 20, 2011 at 3:09 PM, Thomas Kluyver wrote: >> >> Let's have a tag for a bit, just for easy use with checkout and bisect. >> > > +1 for a tag. ?Since our release tags are all prefixed with rel-, I > think it's perfectly reasonable to use another prefix for tags for > development use. ?Say 'dev', feeling creative :) Is that a 'go' for merge? If so, I'll tag&merge once I get home in an hour or so. Or we can wait a day or so for objections. -MinRK > > f > From klonuo at gmail.com Mon Jun 20 19:40:01 2011 From: klonuo at gmail.com (Klonuo) Date: Tue, 21 Jun 2011 01:40:01 +0200 Subject: [IPython-dev] Website In-Reply-To: References: <20110620233512.7BB9.B1C76292@gmail.com> Message-ID: <20110621013955.7BBE.B1C76292@gmail.com> Nice spottings :) I actually first made adjustments on Droid Sans Mono, then just changed font for other samples In all samples however [y]: is smaller then IP part (30pt vs 36pt), but we could make [] with same height as IP, and adjust "y" per font When you select desired font, or suggest other for try, I could make subpixel antialiasing on final image Cheers On Mon, 20 Jun 2011 16:22:27 -0700 Fernando Perez wrote: > On Mon, Jun 20, 2011 at 2:35 PM, Klonuo wrote: > > > > I couldn't find anything interesting to me except Droid Sans Mono > > Added Anonymous Pro as suggested and Quicksend to add more exotic > > I actually like quicksend a lot, though it's perhaps a bit too thin, > and I think we said we wanted to stick to a serifed 'I'. > > I have one comment for all: the size of the brackets and the location > of the y. The current logo pushes the y up and make the brackets a > little smaller, so that they are better balanced visually. I know > that y is normally a drop letter, so I think it's fine to leave it > droppped, but I think we should then make the [] little smaller. > Otherwise, in all but the Droid sample, the y feels a little lost with > a lot of empty space above it inside the []. > > Cheers, > > f -------------------- Full-quoting makes you scroll past the same junk over and over. From fperez.net at gmail.com Mon Jun 20 23:09:15 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 20 Jun 2011 20:09:15 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On Mon, Jun 20, 2011 at 4:38 PM, MinRK wrote: > Is that a 'go' for merge? If so, I'll tag&merge once I get home in an > hour or so. ?Or we can wait a day or so for objections. > >From my side, it's a go. The ideas are sound, and we're at the point where what we need is battle testing to shake out the problems. So I don't see holding on having much value at this point. Some minor comments: - This variable seems to be ignored now, it worked in master: c.Global.ignore_old_config = True for people who have a single ipython_dir (like me) because they need to handle both 0.10 and 0.11 series simultaneously, it's nice to have a way to silence all those warnings. - I don't think we should print the profile name in the default case, it's just noise. I realize we now have a more consistent structure for profiles and even the default case is now a profile, but we should keep the amount of printed stuff to a minimum in the default cases. Otherwise, it looks good, passes the test suite, etc. Cheers, f From benjaminrk at gmail.com Mon Jun 20 23:38:21 2011 From: benjaminrk at gmail.com (MinRK) Date: Mon, 20 Jun 2011 20:38:21 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On Mon, Jun 20, 2011 at 20:09, Fernando Perez wrote: > On Mon, Jun 20, 2011 at 4:38 PM, MinRK wrote: >> Is that a 'go' for merge? If so, I'll tag&merge once I get home in an >> hour or so. ?Or we can wait a day or so for objections. >> > > From my side, it's a go. ?The ideas are sound, and we're at the point > where what we need is battle testing to shake out the problems. ?So I > don't see holding on having much value at this point. Okay, I will go ahead with the merge this evening, then. Since this is merging newapp, I'll call the pre-merge tag 'oldapp'. > > Some minor comments: > > - This variable seems to be ignored now, it worked in master: > > c.Global.ignore_old_config = True Nothing looks at the Global config anymore. This is now application-level, in c.InteractiveShellApp.ignore_old_config I believe (I don't see these warnings with my default config). Perhaps it should be moved to BaseIPythonApplication, though. > > for people who have a single ipython_dir (like me) because they need > to handle both 0.10 and 0.11 series simultaneously, it's nice to have > a way to silence all those warnings. > > - I don't think we should print the profile name in the default case, > it's just noise. ?I realize we now have a more consistent structure > for profiles and even the default case is now a profile, but we should > keep the amount of printed stuff to a minimum in the default cases. Easy enough, I'll do this before merging. -MinRK > > Otherwise, it looks good, passes the test suite, etc. > > Cheers, > > f > From fperez.net at gmail.com Tue Jun 21 00:02:33 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 20 Jun 2011 21:02:33 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On Mon, Jun 20, 2011 at 8:38 PM, MinRK wrote: > Nothing looks at the Global config anymore. This is now > application-level, in c.InteractiveShellApp.ignore_old_config I > believe (I don't see these warnings with my default config). ?Perhaps > it should be moved to BaseIPythonApplication, though. Yup, that works, thanks. We should probably indicate the silencing variable along with the warning msg (that's how I found out about the right variable with the previous setup). >> - I don't think we should print the profile name in the default case, >> it's just noise. ?I realize we now have a more consistent structure >> for profiles and even the default case is now a profile, but we should >> keep the amount of printed stuff to a minimum in the default cases. > > Easy enough, I'll do this before merging. Great, thanks. Cheers, f From benjaminrk at gmail.com Tue Jun 21 00:22:38 2011 From: benjaminrk at gmail.com (MinRK) Date: Mon, 20 Jun 2011 21:22:38 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: newapp has been merged into master. On Mon, Jun 20, 2011 at 21:02, Fernando Perez wrote: > On Mon, Jun 20, 2011 at 8:38 PM, MinRK wrote: >> Nothing looks at the Global config anymore. This is now >> application-level, in c.InteractiveShellApp.ignore_old_config I >> believe (I don't see these warnings with my default config). ?Perhaps >> it should be moved to BaseIPythonApplication, though. > > Yup, that works, thanks. ?We should probably indicate the silencing > variable along with the warning msg (that's how I found out about the > right variable with the previous setup). specific Config variable noted in the warning message. > >>> - I don't think we should print the profile name in the default case, >>> it's just noise. ?I realize we now have a more consistent structure >>> for profiles and even the default case is now a profile, but we should >>> keep the amount of printed stuff to a minimum in the default cases. >> >> Easy enough, I'll do this before merging. > > Great, thanks. > > Cheers, > > f > From benjaminrk at gmail.com Tue Jun 21 01:37:12 2011 From: benjaminrk at gmail.com (Min RK) Date: Mon, 20 Jun 2011 22:37:12 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: <4E002819.4080504@lupm.univ-montp2.fr> References: <4E002819.4080504@lupm.univ-montp2.fr> Message-ID: <9CDA3147-8799-48E5-AC35-6392F9A8D8D4@gmail.com> Yes, it is going to be standard for the cluster profile and interactive IPython to be different - the profile for the Client is principally for connection info, and the shell profile is for configuring your interactive environment. There's no reason to change your interactive config just to connect to a different cluster. That said, the default profile of the Client should probably be that of the current application, not just 'default'. -MinRK On Jun 20, 2011, at 22:11, Johann Cohen-Tanugi wrote: > hi- I don't think we should print the profile name in the default case, >> it's just noise. I realize we now have a more consistent structure >> for profiles and even the default case is now a profile, but we should >> keep the amount of printed stuff to a minimum in the default cases. >> > Actually I have a question here : I was trying newapp, following Min's advice, to try to add the LSF support in parallel.apps. From what I could gather > I did > ipcluster start -p lsf -n 2 > which created profile_lsf in my $HOME/.ipython directory, but then when I started another terminal window for the ipython session, I typed > ipython profile=lsf > and this loaded the default profile, so that I had to type : > > from IPython.parallel import Client > c = Client(profile='lsf') > > so that unless this is a bug or an operator mistake, there seems to be 2 'profiles' in such a use case : the ipython global one, and the parallel lsf one. I find that a bit confusing, and maybe there is a way to merge the 2? > > best, > Johann From fperez.net at gmail.com Tue Jun 21 04:05:49 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 21 Jun 2011 01:05:49 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: On Mon, Jun 20, 2011 at 9:22 PM, MinRK wrote: > newapp has been merged into master. > Thanks! BTW, I think we should add back the (ugly, I know) special-case of honoring -pylab with a single dash. We've talked about this before, while it's ugly, this is written in *many* places, including books and published papers, as the way to start ipython with plotting/numerical support. I think it's worth the friendliness to users who arrive via that path to have that option just work, even if it means an ugly two lines of code special-casing '-pylab' in sys.argv... Cheers, f From hans_meine at gmx.net Tue Jun 21 05:15:19 2011 From: hans_meine at gmx.net (Hans Meine) Date: Tue, 21 Jun 2011 11:15:19 +0200 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: <201106211115.19408.hans_meine@gmx.net> Am Montag, 20. Juni 2011, um 21:58:48 schrieb Fernando Perez: > On Mon, Jun 20, 2011 at 5:53 AM, Thomas Kluyver wrote: > > Hopefully the only thing still to be sorted out is the banner font - > > Klonuo, can we try a couple of different possibilities for that? > > Minor comment: whatever text is used should be rendered with rgba > subpixel antialiasing, currently it's only using simple font-color > antialiasing, and the difference is pretty noticeable on a modern LCD. OTOH, subpixel-antialised images will look awful on monitors with a different (or no) subpixel layout! Since I don't see a way to detect this, I'd vote for the simpler antialiasing (maybe trying to align with pixels such that antialiasing is minimized, e.g. in Inkscape). HTH, Hans From takowl at gmail.com Tue Jun 21 05:37:17 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 21 Jun 2011 10:37:17 +0100 Subject: [IPython-dev] Website In-Reply-To: <201106211115.19408.hans_meine@gmx.net> References: <201106211115.19408.hans_meine@gmx.net> Message-ID: On 21 June 2011 10:15, Hans Meine wrote: > OTOH, subpixel-antialised images will look awful on monitors with a > different > (or no) subpixel layout! > > Since I don't see a way to detect this, I'd vote for the simpler > antialiasing > (maybe trying to align with pixels such that antialiasing is minimized, > e.g. > in Inkscape). > Then again, most people looking at it will be doing so on an LCD screen with standard RGB pixel layout, so it makes sense to optimise for the common case. However, maybe we can let the browser render the banner. If we deliver it as SVG with a fallback, or as HTML using the @font-face directive in CSS, we should be able to have it rendered the best way on any screen, and degrade gracefully in older browsers. On the logos, I'd agree with Fernando that there's a lot of empty space above the y - especially for Anonymous Pro and Quicksend. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Tue Jun 21 11:23:06 2011 From: benjaminrk at gmail.com (Min RK) Date: Tue, 21 Jun 2011 08:23:06 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: Message-ID: <6AB57500-429E-425A-A587-9FA914672D85@gmail.com> On Jun 21, 2011, at 1:05, Fernando Perez wrote: > On Mon, Jun 20, 2011 at 9:22 PM, MinRK wrote: >> newapp has been merged into master. >> > > Thanks! > > BTW, I think we should add back the (ugly, I know) special-case of > honoring -pylab with a single dash. We've talked about this before, > while it's ugly, this is written in *many* places, including books and > published papers, as the way to start ipython with plotting/numerical > support. I think it's worth the friendliness to users who arrive via > that path to have that option just work, even if it means an ugly two > lines of code special-casing '-pylab' in sys.argv... It doesn't have to be ugly - we could easily allow flags to be specified with one or two leading '-'. Currently, one '-' cannot be valid, so it is safe to allow it. -MinRK > > Cheers, > > f From benjaminrk at gmail.com Tue Jun 21 11:27:35 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 21 Jun 2011 08:27:35 -0700 Subject: [IPython-dev] new doc for parallel sessions on clusters In-Reply-To: <4E00AA40.3070802@lupm.univ-montp2.fr> References: <4E002819.4080504@lupm.univ-montp2.fr> <9CDA3147-8799-48E5-AC35-6392F9A8D8D4@gmail.com> <4E00AA40.3070802@lupm.univ-montp2.fr> Message-ID: On Tue, Jun 21, 2011 at 07:27, Johann Cohen-Tanugi wrote: > hi there, I tried to build the sphinx doc on my machine after a pull of the > head (after Min announced the merge of newapp into master), and I see the > following in docs/source/parallel/parallel_process.txt : > 1/ A trivial typo at : > :command:`ipcluster` has a notion of Launchers that can start controllers > and engines with various remote execution schemes. ?Currently supported > models include :command:`ssh`, :command`mpiexec`, PBS-style (Torque, SGE), > and Windows HPC Server. > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|_____> > should be :command:`mpiexec` > 2/ I can read the following lines : > ? ?$ ipython profile create --parallel profile=mpi > or > ? ?$ ipython profile create --parallel profile=pbs > > while ipython profile create does *not* accept a --parallel option AFAICT, > but rather --cluster or --no-cluster. Then you do not have current master, because the flag is indeed '--parallel'. > > best, > Johann > > On 06/21/2011 07:37 AM, Min RK wrote: >> >> Yes, it is going to be standard for the cluster profile and interactive >> IPython to be different - the profile for the Client is principally for >> connection info, and the shell profile is for configuring your interactive >> environment. ?There's no reason to change your interactive config just to >> connect to a different cluster. >> >> That said, the default profile of the Client should probably be that of >> the current application, not just 'default'. >> >> -MinRK >> >> On Jun 20, 2011, at 22:11, Johann >> Cohen-Tanugi ?wrote: >> >>> hi- I don't think we should print the profile name in the default case, >>>> >>>> it's just noise. ?I realize we now have a more consistent structure >>>> for profiles and even the default case is now a profile, but we should >>>> keep the amount of printed stuff to a minimum in the default cases. >>>> >>> Actually I have a question here : I was trying newapp, following Min's >>> advice, to try to add the LSF support in parallel.apps. From what I could >>> gather >>> I did >>> ipcluster start -p lsf -n 2 >>> which created profile_lsf in my $HOME/.ipython directory, but then when I >>> started another terminal window for the ipython session, I typed >>> ipython profile=lsf >>> and this loaded the default profile, so that I had to type : >>> >>> from IPython.parallel import Client >>> c = Client(profile='lsf') >>> >>> so that unless this is a bug or an operator mistake, there seems to be 2 >>> 'profiles' in such a use case : the ipython global one, and the parallel lsf >>> one. I find that a bit confusing, and maybe there is a way to merge the 2? >>> >>> best, >>> Johann > From robert.kern at gmail.com Tue Jun 21 12:12:32 2011 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 21 Jun 2011 11:12:32 -0500 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: <6AB57500-429E-425A-A587-9FA914672D85@gmail.com> References: <6AB57500-429E-425A-A587-9FA914672D85@gmail.com> Message-ID: On 6/21/11 10:23 AM, Min RK wrote: > > On Jun 21, 2011, at 1:05, Fernando Perez wrote: > >> On Mon, Jun 20, 2011 at 9:22 PM, MinRK wrote: >>> newapp has been merged into master. >>> >> >> Thanks! >> >> BTW, I think we should add back the (ugly, I know) special-case of >> honoring -pylab with a single dash. We've talked about this before, >> while it's ugly, this is written in *many* places, including books and >> published papers, as the way to start ipython with plotting/numerical >> support. I think it's worth the friendliness to users who arrive via >> that path to have that option just work, even if it means an ugly two >> lines of code special-casing '-pylab' in sys.argv... > > It doesn't have to be ugly - we could easily allow flags to be specified with one or two leading '-'. Currently, one '-' cannot be valid, so it is safe to allow it. Well, '-pylab' gets parsed the same as '-p ylab'. Maybe just add an alias "ylab" for the pylab profile? -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From benjaminrk at gmail.com Tue Jun 21 12:20:47 2011 From: benjaminrk at gmail.com (Min RK) Date: Tue, 21 Jun 2011 09:20:47 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: <6AB57500-429E-425A-A587-9FA914672D85@gmail.com> Message-ID: <9C35B0E7-6BDE-4AD9-96FB-B9A31437AEA4@gmail.com> On Jun 21, 2011, at 9:12, Robert Kern wrote: > On 6/21/11 10:23 AM, Min RK wrote: >> >> On Jun 21, 2011, at 1:05, Fernando Perez wrote: >> >>> On Mon, Jun 20, 2011 at 9:22 PM, MinRK wrote: >>>> newapp has been merged into master. >>>> >>> >>> Thanks! >>> >>> BTW, I think we should add back the (ugly, I know) special-case of >>> honoring -pylab with a single dash. We've talked about this before, >>> while it's ugly, this is written in *many* places, including books and >>> published papers, as the way to start ipython with plotting/numerical >>> support. I think it's worth the friendliness to users who arrive via >>> that path to have that option just work, even if it means an ugly two >>> lines of code special-casing '-pylab' in sys.argv... >> >> It doesn't have to be ugly - we could easily allow flags to be specified with one or two leading '-'. Currently, one '-' cannot be valid, so it is safe to allow it. > > Well, '-pylab' gets parsed the same as '-p ylab'. Maybe just add an alias "ylab" > for the pylab profile? -pylab is rejected as an invalid argument, just as anything prefixed with just one leading '-'. Flags currently require a '--' prefix, but that is entirely artificial. Allowing the shorter leading '-' is a trivial change, and might ease the transition for people. -MinRK > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless enigma > that is made terrible by our own mad attempt to interpret it as though it had > an underlying truth." > -- Umberto Eco > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From johann.cohentanugi at gmail.com Tue Jun 21 12:31:18 2011 From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi) Date: Tue, 21 Jun 2011 18:31:18 +0200 Subject: [IPython-dev] new doc for parallel sessions on clusters In-Reply-To: References: <4E002819.4080504@lupm.univ-montp2.fr> <9CDA3147-8799-48E5-AC35-6392F9A8D8D4@gmail.com> <4E00AA40.3070802@lupm.univ-montp2.fr> Message-ID: <4E00C756.4080400@gmail.com> hmmm ok, after the merge is this the right way to get the code : git clone git://github.com/ipython/ipython.git ipython I removed the whole source directory, and the local install stuff related to python, and I started from scratch using the git command above. then : python setup.py install --prefix=/afs/slac/g/glast/users/cohen/IPYDEV/local/which python perhaps the problem is that there is an ipython installed with the native python that I use above, and I am wrong to assume that having /afs/slac/g/glast/users/cohen/IPYDEV/local/.../site-packages at the top of PYTHONPATH is enough to ensure that it overrides the one installed with python? Anyway, I will continue investigating.... sorry for the noise, JOhann On 06/21/2011 05:27 PM, MinRK wrote: > On Tue, Jun 21, 2011 at 07:27, Johann Cohen-Tanugi > wrote: >> hi there, I tried to build the sphinx doc on my machine after a pull of the >> head (after Min announced the merge of newapp into master), and I see the >> following in docs/source/parallel/parallel_process.txt : >> 1/ A trivial typo at : >> :command:`ipcluster` has a notion of Launchers that can start controllers >> and engines with various remote execution schemes. Currently supported >> models include :command:`ssh`, :command`mpiexec`, PBS-style (Torque, SGE), >> and Windows HPC Server. >> |_____> >> should be :command:`mpiexec` >> 2/ I can read the following lines : >> $ ipython profile create --parallel profile=mpi >> or >> $ ipython profile create --parallel profile=pbs >> >> while ipython profile create does *not* accept a --parallel option AFAICT, >> but rather --cluster or --no-cluster. > Then you do not have current master, because the flag is indeed '--parallel'. > >> best, >> Johann >> >> On 06/21/2011 07:37 AM, Min RK wrote: >>> Yes, it is going to be standard for the cluster profile and interactive >>> IPython to be different - the profile for the Client is principally for >>> connection info, and the shell profile is for configuring your interactive >>> environment. There's no reason to change your interactive config just to >>> connect to a different cluster. >>> >>> That said, the default profile of the Client should probably be that of >>> the current application, not just 'default'. >>> >>> -MinRK >>> >>> On Jun 20, 2011, at 22:11, Johann >>> Cohen-Tanugi wrote: >>> >>>> hi- I don't think we should print the profile name in the default case, >>>>> it's just noise. I realize we now have a more consistent structure >>>>> for profiles and even the default case is now a profile, but we should >>>>> keep the amount of printed stuff to a minimum in the default cases. >>>>> >>>> Actually I have a question here : I was trying newapp, following Min's >>>> advice, to try to add the LSF support in parallel.apps. From what I could >>>> gather >>>> I did >>>> ipcluster start -p lsf -n 2 >>>> which created profile_lsf in my $HOME/.ipython directory, but then when I >>>> started another terminal window for the ipython session, I typed >>>> ipython profile=lsf >>>> and this loaded the default profile, so that I had to type : >>>> >>>> from IPython.parallel import Client >>>> c = Client(profile='lsf') >>>> >>>> so that unless this is a bug or an operator mistake, there seems to be 2 >>>> 'profiles' in such a use case : the ipython global one, and the parallel lsf >>>> one. I find that a bit confusing, and maybe there is a way to merge the 2? >>>> >>>> best, >>>> Johann From benjaminrk at gmail.com Tue Jun 21 12:41:25 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 21 Jun 2011 09:41:25 -0700 Subject: [IPython-dev] new doc for parallel sessions on clusters In-Reply-To: <4E00C756.4080400@gmail.com> References: <4E002819.4080504@lupm.univ-montp2.fr> <9CDA3147-8799-48E5-AC35-6392F9A8D8D4@gmail.com> <4E00AA40.3070802@lupm.univ-montp2.fr> <4E00C756.4080400@gmail.com> Message-ID: On Tue, Jun 21, 2011 at 09:31, Johann Cohen-Tanugi wrote: > hmmm ok, after the merge is this the right way to get the code : > ?git clone git://github.com/ipython/ipython.git ipython > I removed the whole source directory, and the local install stuff related to > python, and I started from scratch using the git command above. > then : > python setup.py install > --prefix=/afs/slac/g/glast/users/cohen/IPYDEV/local/which python > > perhaps the problem is that there is an ipython installed with the native > python that I use above, and I am wrong to assume that having > /afs/slac/g/glast/users/cohen/IPYDEV/local/.../site-packages at the top of > PYTHONPATH is enough to ensure that it overrides the one installed with > python? If it was installed with setuptools/easy_install, yes - they inject packages at the front sys.path at runtime, ending up ahead of PYTHONPATH. easy_installed packages can even come before '.'. You can check which one you are importing by looking at `IPython.__file__`. It's possible that I've messed something up, but the source looks right (https://github.com/ipython/ipython/blob/master/IPython/core/profileapp.py#L127) > > Anyway, I will continue investigating.... > sorry for the noise, > JOhann > > On 06/21/2011 05:27 PM, MinRK wrote: >> >> On Tue, Jun 21, 2011 at 07:27, Johann Cohen-Tanugi >> ?wrote: >>> >>> hi there, I tried to build the sphinx doc on my machine after a pull of >>> the >>> head (after Min announced the merge of newapp into master), and I see the >>> following in docs/source/parallel/parallel_process.txt : >>> 1/ A trivial typo at : >>> :command:`ipcluster` has a notion of Launchers that can start controllers >>> and engines with various remote execution schemes. ?Currently supported >>> models include :command:`ssh`, :command`mpiexec`, PBS-style (Torque, >>> SGE), >>> and Windows HPC Server. >>> >>> ?|_____> >>> should be :command:`mpiexec` >>> 2/ I can read the following lines : >>> ? ?$ ipython profile create --parallel profile=mpi >>> or >>> ? ?$ ipython profile create --parallel profile=pbs >>> >>> while ipython profile create does *not* accept a --parallel option >>> AFAICT, >>> but rather --cluster or --no-cluster. >> >> Then you do not have current master, because the flag is indeed >> '--parallel'. >> >>> best, >>> Johann >>> >>> On 06/21/2011 07:37 AM, Min RK wrote: >>>> >>>> Yes, it is going to be standard for the cluster profile and interactive >>>> IPython to be different - the profile for the Client is principally for >>>> connection info, and the shell profile is for configuring your >>>> interactive >>>> environment. ?There's no reason to change your interactive config just >>>> to >>>> connect to a different cluster. >>>> >>>> That said, the default profile of the Client should probably be that of >>>> the current application, not just 'default'. >>>> >>>> -MinRK >>>> >>>> On Jun 20, 2011, at 22:11, Johann >>>> Cohen-Tanugi ? ?wrote: >>>> >>>>> hi- I don't think we should print the profile name in the default case, >>>>>> >>>>>> it's just noise. ?I realize we now have a more consistent structure >>>>>> for profiles and even the default case is now a profile, but we should >>>>>> keep the amount of printed stuff to a minimum in the default cases. >>>>>> >>>>> Actually I have a question here : I was trying newapp, following Min's >>>>> advice, to try to add the LSF support in parallel.apps. From what I >>>>> could >>>>> gather >>>>> I did >>>>> ipcluster start -p lsf -n 2 >>>>> which created profile_lsf in my $HOME/.ipython directory, but then when >>>>> I >>>>> started another terminal window for the ipython session, I typed >>>>> ipython profile=lsf >>>>> and this loaded the default profile, so that I had to type : >>>>> >>>>> from IPython.parallel import Client >>>>> c = Client(profile='lsf') >>>>> >>>>> so that unless this is a bug or an operator mistake, there seems to be >>>>> 2 >>>>> 'profiles' in such a use case : the ipython global one, and the >>>>> parallel lsf >>>>> one. I find that a bit confusing, and maybe there is a way to merge the >>>>> 2? >>>>> >>>>> best, >>>>> Johann > From robert.kern at gmail.com Tue Jun 21 12:47:09 2011 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 21 Jun 2011 11:47:09 -0500 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: <9C35B0E7-6BDE-4AD9-96FB-B9A31437AEA4@gmail.com> References: <6AB57500-429E-425A-A587-9FA914672D85@gmail.com> <9C35B0E7-6BDE-4AD9-96FB-B9A31437AEA4@gmail.com> Message-ID: On 6/21/11 11:20 AM, Min RK wrote: > > On Jun 21, 2011, at 9:12, Robert Kern wrote: > >> On 6/21/11 10:23 AM, Min RK wrote: >>> >>> On Jun 21, 2011, at 1:05, Fernando Perez wrote: >>> >>>> On Mon, Jun 20, 2011 at 9:22 PM, MinRK wrote: >>>>> newapp has been merged into master. >>>>> >>>> >>>> Thanks! >>>> >>>> BTW, I think we should add back the (ugly, I know) special-case of >>>> honoring -pylab with a single dash. We've talked about this before, >>>> while it's ugly, this is written in *many* places, including books and >>>> published papers, as the way to start ipython with plotting/numerical >>>> support. I think it's worth the friendliness to users who arrive via >>>> that path to have that option just work, even if it means an ugly two >>>> lines of code special-casing '-pylab' in sys.argv... >>> >>> It doesn't have to be ugly - we could easily allow flags to be specified with one or two leading '-'. Currently, one '-' cannot be valid, so it is safe to allow it. >> >> Well, '-pylab' gets parsed the same as '-p ylab'. Maybe just add an alias "ylab" >> for the pylab profile? > > -pylab is rejected as an invalid argument, just as anything prefixed with just one leading '-'. Flags currently require a '--' prefix, but that is entirely artificial. Allowing the shorter leading '-' is a trivial change, and might ease the transition for people. Well, yes. Changing "-i" to "--i" is just gratuitous, as is disallowing the short aliases for "-p/--profile" and "-l/--log". It makes IPython more non-standard in addition to backwards-incompatible. The manual parsing in KeyValueConfigLoader exacerbates this (e.g. it seems to require "--profile=scipy" rather than "--profile scipy" like most applications would accept). I know it's late in the game to be commenting on this, but that's an unpleasant change. I see an ArgParseConfigLoader, but it seems unfinished and unused. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From johann.cohentanugi at gmail.com Tue Jun 21 13:00:15 2011 From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi) Date: Tue, 21 Jun 2011 19:00:15 +0200 Subject: [IPython-dev] new doc for parallel sessions on clusters In-Reply-To: References: <4E002819.4080504@lupm.univ-montp2.fr> <9CDA3147-8799-48E5-AC35-6392F9A8D8D4@gmail.com> <4E00AA40.3070802@lupm.univ-montp2.fr> <4E00C756.4080400@gmail.com> Message-ID: <4E00CE1F.3000609@gmail.com> ok found the problem : I still had the ipython-newapp source code in the same dir as the new ipython, I did everything from this new ipython dir, but at execution it was looking into ipython-newapp. Obviously there is something I was not expecting.... Anyway now it works. sorry again, Johann On 06/21/2011 06:41 PM, MinRK wrote: > On Tue, Jun 21, 2011 at 09:31, Johann Cohen-Tanugi > wrote: >> hmmm ok, after the merge is this the right way to get the code : >> git clone git://github.com/ipython/ipython.git ipython >> I removed the whole source directory, and the local install stuff related to >> python, and I started from scratch using the git command above. >> then : >> python setup.py install >> --prefix=/afs/slac/g/glast/users/cohen/IPYDEV/local/which python >> >> perhaps the problem is that there is an ipython installed with the native >> python that I use above, and I am wrong to assume that having >> /afs/slac/g/glast/users/cohen/IPYDEV/local/.../site-packages at the top of >> PYTHONPATH is enough to ensure that it overrides the one installed with >> python? > If it was installed with setuptools/easy_install, yes - they inject > packages at the front sys.path at runtime, ending up ahead of > PYTHONPATH. easy_installed packages can even come before '.'. > > You can check which one you are importing by looking at `IPython.__file__`. > > It's possible that I've messed something up, but the source looks > right (https://github.com/ipython/ipython/blob/master/IPython/core/profileapp.py#L127) > >> Anyway, I will continue investigating.... >> sorry for the noise, >> JOhann >> >> On 06/21/2011 05:27 PM, MinRK wrote: >>> On Tue, Jun 21, 2011 at 07:27, Johann Cohen-Tanugi >>> wrote: >>>> hi there, I tried to build the sphinx doc on my machine after a pull of >>>> the >>>> head (after Min announced the merge of newapp into master), and I see the >>>> following in docs/source/parallel/parallel_process.txt : >>>> 1/ A trivial typo at : >>>> :command:`ipcluster` has a notion of Launchers that can start controllers >>>> and engines with various remote execution schemes. Currently supported >>>> models include :command:`ssh`, :command`mpiexec`, PBS-style (Torque, >>>> SGE), >>>> and Windows HPC Server. >>>> >>>> |_____> >>>> should be :command:`mpiexec` >>>> 2/ I can read the following lines : >>>> $ ipython profile create --parallel profile=mpi >>>> or >>>> $ ipython profile create --parallel profile=pbs >>>> >>>> while ipython profile create does *not* accept a --parallel option >>>> AFAICT, >>>> but rather --cluster or --no-cluster. >>> Then you do not have current master, because the flag is indeed >>> '--parallel'. >>> >>>> best, >>>> Johann >>>> >>>> On 06/21/2011 07:37 AM, Min RK wrote: >>>>> Yes, it is going to be standard for the cluster profile and interactive >>>>> IPython to be different - the profile for the Client is principally for >>>>> connection info, and the shell profile is for configuring your >>>>> interactive >>>>> environment. There's no reason to change your interactive config just >>>>> to >>>>> connect to a different cluster. >>>>> >>>>> That said, the default profile of the Client should probably be that of >>>>> the current application, not just 'default'. >>>>> >>>>> -MinRK >>>>> >>>>> On Jun 20, 2011, at 22:11, Johann >>>>> Cohen-Tanugi wrote: >>>>> >>>>>> hi- I don't think we should print the profile name in the default case, >>>>>>> it's just noise. I realize we now have a more consistent structure >>>>>>> for profiles and even the default case is now a profile, but we should >>>>>>> keep the amount of printed stuff to a minimum in the default cases. >>>>>>> >>>>>> Actually I have a question here : I was trying newapp, following Min's >>>>>> advice, to try to add the LSF support in parallel.apps. From what I >>>>>> could >>>>>> gather >>>>>> I did >>>>>> ipcluster start -p lsf -n 2 >>>>>> which created profile_lsf in my $HOME/.ipython directory, but then when >>>>>> I >>>>>> started another terminal window for the ipython session, I typed >>>>>> ipython profile=lsf >>>>>> and this loaded the default profile, so that I had to type : >>>>>> >>>>>> from IPython.parallel import Client >>>>>> c = Client(profile='lsf') >>>>>> >>>>>> so that unless this is a bug or an operator mistake, there seems to be >>>>>> 2 >>>>>> 'profiles' in such a use case : the ipython global one, and the >>>>>> parallel lsf >>>>>> one. I find that a bit confusing, and maybe there is a way to merge the >>>>>> 2? >>>>>> >>>>>> best, >>>>>> Johann From klonuo at gmail.com Tue Jun 21 13:33:33 2011 From: klonuo at gmail.com (Klonuo) Date: Tue, 21 Jun 2011 19:33:33 +0200 Subject: [IPython-dev] Website In-Reply-To: References: <201106211115.19408.hans_meine@gmx.net> Message-ID: <20110621193331.BE09.B1C76292@gmail.com> On Tue, 21 Jun 2011 10:37:17 +0100 Thomas Kluyver wrote: > On 21 June 2011 10:15, Hans Meine wrote: > > > OTOH, subpixel-antialised images will look awful on monitors with a > > different > > (or no) subpixel layout! > > > > Since I don't see a way to detect this, I'd vote for the simpler > > antialiasing > > (maybe trying to align with pixels such that antialiasing is minimized, > > e.g. > > in Inkscape). > > > > Then again, most people looking at it will be doing so on an LCD screen with > standard RGB pixel layout, so it makes sense to optimise for the common > case. > > However, maybe we can let the browser render the banner. If we deliver it as > SVG with a fallback, or as HTML using the @font-face directive in CSS, we > should be able to have it rendered the best way on any screen, and degrade > gracefully in older browsers. SVG usage as header logo is interesting idea, although a bit avant garde, as I'm not sure how wide spread is this approach and what are browser considerations with embedded fonts. Then how browsers renders this fonts? For example IE9 font rendering engine looks very different then FireFox or IE8 or other browsers. What would be difference if we use vector objects instead fonts? And is SVG font rendered, subpixel antialiased or standard antialiased? About "@font-face directive in CSS" I'm not sure what you mean? I attached two examples: standard antialiased and subpixel antialiased and wait for users with CRT to comment. I don't have CRT monitor near. > On the logos, I'd agree with Fernando that there's a lot of empty space > above the y - especially for Anonymous Pro and Quicksend. At the end, I'm not sure also about "[y]" size/spacing reconsiderations? Do you expect me to redo logos or you can choose font without redoing? I think this is not that big drawback and we can choose font besides it, afterwhich I'll adjust elements on chosen font (in case of Droid it already looks fine to me) And if you have other font ideas, point at it Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: standard_antialiased.png Type: image/png Size: 6104 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: subpixel_antialiased.png Type: image/png Size: 13129 bytes Desc: not available URL: From benjaminrk at gmail.com Tue Jun 21 13:50:27 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 21 Jun 2011 10:50:27 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: <6AB57500-429E-425A-A587-9FA914672D85@gmail.com> <9C35B0E7-6BDE-4AD9-96FB-B9A31437AEA4@gmail.com> Message-ID: On Tue, Jun 21, 2011 at 09:47, Robert Kern wrote: > On 6/21/11 11:20 AM, Min RK wrote: >> >> On Jun 21, 2011, at 9:12, Robert Kern ?wrote: >> >>> On 6/21/11 10:23 AM, Min RK wrote: >>>> >>>> On Jun 21, 2011, at 1:05, Fernando Perez ? wrote: >>>> >>>>> On Mon, Jun 20, 2011 at 9:22 PM, MinRK ? wrote: >>>>>> newapp has been merged into master. >>>>>> >>>>> >>>>> Thanks! >>>>> >>>>> BTW, I think we should add back the (ugly, I know) special-case of >>>>> honoring -pylab with a single dash. ?We've talked about this before, >>>>> while it's ugly, this is written in *many* places, including books and >>>>> published papers, as the way to start ipython with plotting/numerical >>>>> support. ?I think it's worth the friendliness to users who arrive via >>>>> that path to have that option just work, even if it means an ugly two >>>>> lines of code special-casing '-pylab' in sys.argv... >>>> >>>> It doesn't have to be ugly - we could easily allow flags to be specified with one or two leading '-'. ?Currently, one '-' cannot be valid, so it is safe to allow it. >>> >>> Well, '-pylab' gets parsed the same as '-p ylab'. Maybe just add an alias "ylab" >>> for the pylab profile? >> >> -pylab is rejected as an invalid argument, just as anything prefixed with just one leading '-'. Flags currently require a '--' prefix, but that is entirely artificial. Allowing the shorter leading '-' is a trivial change, and might ease the transition for people. > > Well, yes. Changing "-i" to "--i" is just gratuitous, as is disallowing the > short aliases for "-p/--profile" and "-l/--log". It makes IPython more > non-standard in addition to backwards-incompatible. The only reason '-' is not allowed for flags now is in case we want to add something like short aliases. > The manual parsing in > KeyValueConfigLoader exacerbates this (e.g. it seems to require > "--profile=scipy" rather than "--profile scipy" like most applications would > accept). Command-line args are unambiguous - flags, prefixed with `--` *never* take arguments, and setting values is always simply a Python assignment, thus never prefixed by '-', so now specifying which pylab backend to use and using the auto backend are different: # use matplotlib default: ipython --pylab # equivalent to ipython pylab=auto # specify Qt: ipython pylab=qt Neither of the following works: ipython --pylab=qt ipython --pylab qt > > I know it's late in the game to be commenting on this, but that's an unpleasant > change. I see an ArgParseConfigLoader, but it seems unfinished and unused. I don't know if it's unfinished, but it's definitely unused. The KeyValue command-line args are definitely not as nice as argparse. The advantage, though, is that 100% of configurable IPython is available on the command-line, and adding/updating/changing configurable traits themselves updates the command-line arguments and helpstrings. Specifying command-line args is also identical to specifying the same values in a config file, so users familiar with configuring IPython are also familiar with the command-line options. It's a rough change, and it's going to be difficult/unattractive for some people. If people really do hate it, we can drop back to argparse in 0.12, but the net effect this change has had on the IPython code base itself has been positive. -MinRK > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless enigma > ?that is made terrible by our own mad attempt to interpret it as though it had > ?an underlying truth." > ? -- Umberto Eco > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From benjaminrk at gmail.com Tue Jun 21 13:58:04 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 21 Jun 2011 10:58:04 -0700 Subject: [IPython-dev] new doc for parallel sessions on clusters In-Reply-To: <4E00CE1F.3000609@gmail.com> References: <4E002819.4080504@lupm.univ-montp2.fr> <9CDA3147-8799-48E5-AC35-6392F9A8D8D4@gmail.com> <4E00AA40.3070802@lupm.univ-montp2.fr> <4E00C756.4080400@gmail.com> <4E00CE1F.3000609@gmail.com> Message-ID: Glad you were able to fix it. I just pushed an update to the online docs, so they should be up to date now. On Tue, Jun 21, 2011 at 10:00, Johann Cohen-Tanugi wrote: > ok found the problem : I still had the ipython-newapp source code in the > same dir as the new ipython, I did everything from this new ipython dir, > but at execution it was looking into ipython-newapp. Obviously there is > something I was not expecting.... Anyway now it works. > > sorry again, > Johann > > On 06/21/2011 06:41 PM, MinRK wrote: >> >> On Tue, Jun 21, 2011 at 09:31, Johann Cohen-Tanugi >> ?wrote: >>> >>> hmmm ok, after the merge is this the right way to get the code : >>> ?git clone git://github.com/ipython/ipython.git ipython >>> I removed the whole source directory, and the local install stuff related >>> to >>> python, and I started from scratch using the git command above. >>> then : >>> python setup.py install >>> --prefix=/afs/slac/g/glast/users/cohen/IPYDEV/local/which python >>> >>> perhaps the problem is that there is an ipython installed with the native >>> python that I use above, and I am wrong to assume that having >>> /afs/slac/g/glast/users/cohen/IPYDEV/local/.../site-packages at the top >>> of >>> PYTHONPATH is enough to ensure that it overrides the one installed with >>> python? >> >> If it was installed with setuptools/easy_install, yes - they inject >> packages at the front sys.path at runtime, ending up ahead of >> PYTHONPATH. easy_installed packages can even come before '.'. >> >> You can check which one you are importing by looking at >> `IPython.__file__`. >> >> It's possible that I've messed something up, but the source looks >> right >> (https://github.com/ipython/ipython/blob/master/IPython/core/profileapp.py#L127) >> >>> Anyway, I will continue investigating.... >>> sorry for the noise, >>> JOhann >>> >>> On 06/21/2011 05:27 PM, MinRK wrote: >>>> >>>> On Tue, Jun 21, 2011 at 07:27, Johann Cohen-Tanugi >>>> ? ?wrote: >>>>> >>>>> hi there, I tried to build the sphinx doc on my machine after a pull of >>>>> the >>>>> head (after Min announced the merge of newapp into master), and I see >>>>> the >>>>> following in docs/source/parallel/parallel_process.txt : >>>>> 1/ A trivial typo at : >>>>> :command:`ipcluster` has a notion of Launchers that can start >>>>> controllers >>>>> and engines with various remote execution schemes. ?Currently supported >>>>> models include :command:`ssh`, :command`mpiexec`, PBS-style (Torque, >>>>> SGE), >>>>> and Windows HPC Server. >>>>> >>>>> ?|_____> >>>>> should be :command:`mpiexec` >>>>> 2/ I can read the following lines : >>>>> ? ?$ ipython profile create --parallel profile=mpi >>>>> or >>>>> ? ?$ ipython profile create --parallel profile=pbs >>>>> >>>>> while ipython profile create does *not* accept a --parallel option >>>>> AFAICT, >>>>> but rather --cluster or --no-cluster. >>>> >>>> Then you do not have current master, because the flag is indeed >>>> '--parallel'. >>>> >>>>> best, >>>>> Johann >>>>> >>>>> On 06/21/2011 07:37 AM, Min RK wrote: >>>>>> >>>>>> Yes, it is going to be standard for the cluster profile and >>>>>> interactive >>>>>> IPython to be different - the profile for the Client is principally >>>>>> for >>>>>> connection info, and the shell profile is for configuring your >>>>>> interactive >>>>>> environment. ?There's no reason to change your interactive config just >>>>>> to >>>>>> connect to a different cluster. >>>>>> >>>>>> That said, the default profile of the Client should probably be that >>>>>> of >>>>>> the current application, not just 'default'. >>>>>> >>>>>> -MinRK >>>>>> >>>>>> On Jun 20, 2011, at 22:11, Johann >>>>>> Cohen-Tanugi ? ? ?wrote: >>>>>> >>>>>>> hi- I don't think we should print the profile name in the default >>>>>>> case, >>>>>>>> >>>>>>>> it's just noise. ?I realize we now have a more consistent structure >>>>>>>> for profiles and even the default case is now a profile, but we >>>>>>>> should >>>>>>>> keep the amount of printed stuff to a minimum in the default cases. >>>>>>>> >>>>>>> Actually I have a question here : I was trying newapp, following >>>>>>> Min's >>>>>>> advice, to try to add the LSF support in parallel.apps. From what I >>>>>>> could >>>>>>> gather >>>>>>> I did >>>>>>> ipcluster start -p lsf -n 2 >>>>>>> which created profile_lsf in my $HOME/.ipython directory, but then >>>>>>> when >>>>>>> I >>>>>>> started another terminal window for the ipython session, I typed >>>>>>> ipython profile=lsf >>>>>>> and this loaded the default profile, so that I had to type : >>>>>>> >>>>>>> from IPython.parallel import Client >>>>>>> c = Client(profile='lsf') >>>>>>> >>>>>>> so that unless this is a bug or an operator mistake, there seems to >>>>>>> be >>>>>>> 2 >>>>>>> 'profiles' in such a use case : the ipython global one, and the >>>>>>> parallel lsf >>>>>>> one. I find that a bit confusing, and maybe there is a way to merge >>>>>>> the >>>>>>> 2? >>>>>>> >>>>>>> best, >>>>>>> Johann > From takowl at gmail.com Tue Jun 21 14:19:58 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 21 Jun 2011 19:19:58 +0100 Subject: [IPython-dev] Website In-Reply-To: <20110621193331.BE09.B1C76292@gmail.com> References: <201106211115.19408.hans_meine@gmx.net> <20110621193331.BE09.B1C76292@gmail.com> Message-ID: On 21 June 2011 18:33, Klonuo wrote: > SVG usage as header logo is interesting idea, although a bit avant > garde, as I'm not sure how wide spread is this approach and what are > browser considerations with embedded fonts. > > Then how browsers renders this fonts? For example IE9 font rendering > engine looks very different then FireFox or IE8 or other browsers. > > What would be difference if we use vector objects instead fonts? > And is SVG font rendered, subpixel antialiased or standard antialiased? > > About "@font-face directive in CSS" I'm not sure what you mean? > I don't know the details of font rendering, but if we converted it to letter shapes, it should look the same on any supporting browser, I think. Then we could include a PNG as a fallback. @font-face is a way to load a reference to a font that you can then use in a CSS font-family definition. Most browsers now support it, although IE only had partial support until v9 (http://caniuse.com/#feat=fontface ). Browsers that don't support it would just use fallback font families as is normal with CSS. > At the end, I'm not sure also about "[y]" size/spacing reconsiderations? > Do you expect me to redo logos or you can choose font without redoing? I > think this is not that big drawback and we can choose font besides it, > afterwhich I'll adjust elements on chosen font (in case of Droid it > already looks fine to me) > > And if you have other font ideas, point at it > The top ones look fine to me, but I'll let other people comment on typographic matters! Hope this isn't getting too frustrating - we should have a decision soon. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From klonuo at gmail.com Tue Jun 21 14:40:34 2011 From: klonuo at gmail.com (Klonuo) Date: Tue, 21 Jun 2011 20:40:34 +0200 Subject: [IPython-dev] Fw: Re: Website Message-ID: <20110621204032.1030.B1C76292@gmail.com> On Tue, 21 Jun 2011 19:19:58 +0100 Thomas Kluyver wrote: > I don't know the details of font rendering, but if we converted it to letter > shapes, it should look the same on any supporting browser, I think. Then we > could include a PNG as a fallback. AFAIK subpixel rendering is only applied to fonts. Images don't have that possibility (information) unless you hardcode that effect (or use some format as DjVu) > @font-face is a way to load a reference to a font that you can then use in a > CSS font-family definition. Most browsers now support it, although IE only > had partial support until v9 (http://caniuse.com/#feat=fontface ). Browsers > that don't support it would just use fallback font families as is normal > with CSS. Sorry, but I still don't get it. What will you reference with that directive? Do you mean to put logo as text in html? > The top ones look fine to me, but I'll let other people comment on > typographic matters! Hope this isn't getting too frustrating - we should > have a decision soon. No. I was asking as I wasn't sure if you are implying to redo. I'm in Droid from those samples Cheers From klonuo at gmail.com Tue Jun 21 14:56:19 2011 From: klonuo at gmail.com (Klonuo) Date: Tue, 21 Jun 2011 20:56:19 +0200 Subject: [IPython-dev] Website In-Reply-To: <20110621204032.1030.B1C76292@gmail.com> References: <20110621204032.1030.B1C76292@gmail.com> Message-ID: <20110621205613.1034.B1C76292@gmail.com> On Tue, 21 Jun 2011 20:40:34 +0200 Klonuo wrote: > > I don't know the details of font rendering, but if we converted it to letter > > shapes, it should look the same on any supporting browser, I think. Then we > > could include a PNG as a fallback. > > AFAIK subpixel rendering is only applied to fonts. Images don't have > that possibility (information) unless you hardcode that effect (or use > some format as DjVu) Small update (for LCD on Windows 7): If text in SVG is as vector object instead font then is rendered without subpixel aa If text in SVG is as text object then is rendered with subpixel aa I checked on IE9 and FireFox 5 From ellisonbg at gmail.com Tue Jun 21 15:37:21 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 21 Jun 2011 12:37:21 -0700 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: <6AB57500-429E-425A-A587-9FA914672D85@gmail.com> <9C35B0E7-6BDE-4AD9-96FB-B9A31437AEA4@gmail.com> Message-ID: On Tue, Jun 21, 2011 at 10:50 AM, MinRK wrote: > On Tue, Jun 21, 2011 at 09:47, Robert Kern wrote: >> On 6/21/11 11:20 AM, Min RK wrote: >>> >>> On Jun 21, 2011, at 9:12, Robert Kern ?wrote: >>> >>>> On 6/21/11 10:23 AM, Min RK wrote: >>>>> >>>>> On Jun 21, 2011, at 1:05, Fernando Perez ? wrote: >>>>> >>>>>> On Mon, Jun 20, 2011 at 9:22 PM, MinRK ? wrote: >>>>>>> newapp has been merged into master. >>>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> BTW, I think we should add back the (ugly, I know) special-case of >>>>>> honoring -pylab with a single dash. ?We've talked about this before, >>>>>> while it's ugly, this is written in *many* places, including books and >>>>>> published papers, as the way to start ipython with plotting/numerical >>>>>> support. ?I think it's worth the friendliness to users who arrive via >>>>>> that path to have that option just work, even if it means an ugly two >>>>>> lines of code special-casing '-pylab' in sys.argv... >>>>> >>>>> It doesn't have to be ugly - we could easily allow flags to be specified with one or two leading '-'. ?Currently, one '-' cannot be valid, so it is safe to allow it. >>>> >>>> Well, '-pylab' gets parsed the same as '-p ylab'. Maybe just add an alias "ylab" >>>> for the pylab profile? >>> >>> -pylab is rejected as an invalid argument, just as anything prefixed with just one leading '-'. Flags currently require a '--' prefix, but that is entirely artificial. Allowing the shorter leading '-' is a trivial change, and might ease the transition for people. >> >> Well, yes. Changing "-i" to "--i" is just gratuitous, as is disallowing the >> short aliases for "-p/--profile" and "-l/--log". It makes IPython more >> non-standard in addition to backwards-incompatible. > > The only reason '-' is not allowed for flags now is in case we want to > add something like short aliases. > >> The manual parsing in >> KeyValueConfigLoader exacerbates this (e.g. it seems to require >> "--profile=scipy" rather than "--profile scipy" like most applications would >> accept). > > Command-line args are unambiguous - flags, prefixed with `--` *never* > take arguments, and setting values is always simply a Python > assignment, thus never prefixed by '-', so now specifying which pylab > backend to use and using the auto backend are different: > > # use matplotlib default: > ipython --pylab # equivalent to ipython pylab=auto > # specify Qt: > ipython pylab=qt > > Neither of the following works: > ipython --pylab=qt > ipython --pylab qt > > >> >> I know it's late in the game to be commenting on this, but that's an unpleasant >> change. I see an ArgParseConfigLoader, but it seems unfinished and unused. > > I don't know if it's unfinished, but it's definitely unused. Yes, this is an important point that we will have to highlight and clarify in the docs. We have *completely* moved away from the argparse style command line parsing. > The KeyValue command-line args are definitely not as nice as argparse. > ?The advantage, though, is that 100% of configurable IPython is > available on the command-line, and adding/updating/changing > configurable traits themselves updates the command-line arguments and > helpstrings. ?Specifying command-line args is also identical to > specifying the same values in a config file, so users familiar with > configuring IPython are also familiar with the command-line options. I am biased because I helped to design the new config system and command line parsing, but I do think the new style is a much better approach for IPython that users will quickly adapt to and like. Personally, I actually like this command line syntax *better* than that of argparse as it looks more like Python code (it is!) and has a very attractive uniformity between the code, command line and config files. I won't deny though that it is a huge change though. Cheers, Brian > It's a rough change, and it's going to be difficult/unattractive for > some people. If people really do hate it, we can drop back to argparse > in 0.12, but the net effect this change has had on the IPython code > base itself has been positive. > -MinRK > >> >> -- >> Robert Kern >> >> "I have come to believe that the whole world is an enigma, a harmless enigma >> ?that is made terrible by our own mad attempt to interpret it as though it had >> ?an underlying truth." >> ? -- Umberto Eco >> >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From robert.kern at gmail.com Tue Jun 21 15:47:42 2011 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 21 Jun 2011 14:47:42 -0500 Subject: [IPython-dev] Helping battle testing the newapp branch In-Reply-To: References: <6AB57500-429E-425A-A587-9FA914672D85@gmail.com> <9C35B0E7-6BDE-4AD9-96FB-B9A31437AEA4@gmail.com> Message-ID: On 6/21/11 12:50 PM, MinRK wrote: > On Tue, Jun 21, 2011 at 09:47, Robert Kern wrote: >> On 6/21/11 11:20 AM, Min RK wrote: >>> >>> On Jun 21, 2011, at 9:12, Robert Kern wrote: >>> >>>> On 6/21/11 10:23 AM, Min RK wrote: >>>>> >>>>> On Jun 21, 2011, at 1:05, Fernando Perez wrote: >>>>> >>>>>> On Mon, Jun 20, 2011 at 9:22 PM, MinRK wrote: >>>>>>> newapp has been merged into master. >>>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> BTW, I think we should add back the (ugly, I know) special-case of >>>>>> honoring -pylab with a single dash. We've talked about this before, >>>>>> while it's ugly, this is written in *many* places, including books and >>>>>> published papers, as the way to start ipython with plotting/numerical >>>>>> support. I think it's worth the friendliness to users who arrive via >>>>>> that path to have that option just work, even if it means an ugly two >>>>>> lines of code special-casing '-pylab' in sys.argv... >>>>> >>>>> It doesn't have to be ugly - we could easily allow flags to be specified with one or two leading '-'. Currently, one '-' cannot be valid, so it is safe to allow it. >>>> >>>> Well, '-pylab' gets parsed the same as '-p ylab'. Maybe just add an alias "ylab" >>>> for the pylab profile? >>> >>> -pylab is rejected as an invalid argument, just as anything prefixed with just one leading '-'. Flags currently require a '--' prefix, but that is entirely artificial. Allowing the shorter leading '-' is a trivial change, and might ease the transition for people. >> >> Well, yes. Changing "-i" to "--i" is just gratuitous, as is disallowing the >> short aliases for "-p/--profile" and "-l/--log". It makes IPython more >> non-standard in addition to backwards-incompatible. > > The only reason '-' is not allowed for flags now is in case we want to > add something like short aliases. > >> The manual parsing in >> KeyValueConfigLoader exacerbates this (e.g. it seems to require >> "--profile=scipy" rather than "--profile scipy" like most applications would >> accept). > > Command-line args are unambiguous - flags, prefixed with `--` *never* > take arguments, and setting values is always simply a Python > assignment, thus never prefixed by '-', so now specifying which pylab > backend to use and using the auto backend are different: > > # use matplotlib default: > ipython --pylab # equivalent to ipython pylab=auto > # specify Qt: > ipython pylab=qt > > Neither of the following works: > ipython --pylab=qt > ipython --pylab qt Okay, I was under a misapprehension, then. >> I know it's late in the game to be commenting on this, but that's an unpleasant >> change. I see an ArgParseConfigLoader, but it seems unfinished and unused. > > I don't know if it's unfinished, but it's definitely unused. By "unfinished", I meant that one still needs to implement a method to configure it. It can't determine what arguments it allows from a data structure in the same way that KeyValueConfigLoader does. And PS: *please* stop Ccing me. I'm subscribed to the list! -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From takowl at gmail.com Tue Jun 21 15:58:02 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 21 Jun 2011 20:58:02 +0100 Subject: [IPython-dev] Website In-Reply-To: <20110621203958.102D.B1C76292@gmail.com> References: <20110621193331.BE09.B1C76292@gmail.com> <20110621203958.102D.B1C76292@gmail.com> Message-ID: On 21 June 2011 19:40, Klonuo wrote: > AFAIK subpixel rendering is only applied to fonts. Images don't have > that possibility (information) unless you hardcode that effect (or use > some format as DjVu) > OK, scratch that idea. I'd assumed it could antialias lines and curves in the same way. > > @font-face is a way to load a reference to a font that you can then use > in a > > CSS font-family definition. Most browsers now support it, although IE > only > > had partial support until v9 (http://caniuse.com/#feat=fontface ). > Browsers > > that don't support it would just use fallback font families as is normal > > with CSS. > > Sorry, but I still don't get it. What will you reference with that > directive? Do you mean to put logo as text in html? > Yes, you'd put the logo in as HTML, and style it with CSS. Newer browsers let you reference fonts, so that you can use a font which isn't installed on the user's computer. See Google's instructions for Droid Sans Mono, for example: http://www.google.com/webfonts/family?family=Droid+Sans+Mono&subset=latin#code > > The top ones look fine to me, but I'll let other people comment on > > typographic matters! Hope this isn't getting too frustrating - we should > > have a decision soon. > > No. I was asking as I wasn't sure if you are implying to redo. > I'm in Droid from those samples If you've got spare time, it would be interesting to see them with the [y] adjusted so that there's less space above the y (whether you move the y or shrink the [ ] is up to you). But don't worry too much about it. Primarily I'd like to get some more opinions - Brian, Min, Evan, you've all weighed in on logos previously - what do you think of the different fonts Klonuo has tried? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From klonuo at gmail.com Tue Jun 21 16:15:12 2011 From: klonuo at gmail.com (Klonuo) Date: Tue, 21 Jun 2011 22:15:12 +0200 Subject: [IPython-dev] Website In-Reply-To: References: <20110621203958.102D.B1C76292@gmail.com> Message-ID: <20110621221505.1038.B1C76292@gmail.com> On Tue, 21 Jun 2011 20:58:02 +0100 Thomas Kluyver wrote: > Yes, you'd put the logo in as HTML, and style it with CSS. Newer browsers > let you reference fonts, so that you can use a font which isn't installed on > the user's computer. See Google's instructions for Droid Sans Mono, for > example: > > http://www.google.com/webfonts/family?family=Droid+Sans+Mono&subset=latin#code > So you are saying to use image only for IP[y]: part in logo and use html and webfont feature for description part? If it's not complicated for you to manage it, that could solve antialiasing thing, as we are not concerned about antialiasing in IP[y]: part as it uses large enough font > If you've got spare time, it would be interesting to see them with the [y] > adjusted so that there's less space above the y (whether you move the y or > shrink the [ ] is up to you). But don't worry too much about it. I'll wait on comments, then adjust winner font > I'd like to get some more opinions - Brian, Min, Evan, you've all weighed in > on logos previously - what do you think of the different fonts Klonuo has > tried? Maybe they don't browse topics named "Website" :D Cheers From epatters at enthought.com Tue Jun 21 16:16:47 2011 From: epatters at enthought.com (Evan Patterson) Date: Tue, 21 Jun 2011 15:16:47 -0500 Subject: [IPython-dev] Website In-Reply-To: References: <20110621193331.BE09.B1C76292@gmail.com> <20110621203958.102D.B1C76292@gmail.com> Message-ID: <010497E2-70C3-4745-8035-093A1204D3ED@enthought.com> On Jun 21, 2011, at 2:58 PM, Thomas Kluyver wrote: > On 21 June 2011 19:40, Klonuo wrote: > AFAIK subpixel rendering is only applied to fonts. Images don't have > that possibility (information) unless you hardcode that effect (or use > some format as DjVu) > > OK, scratch that idea. I'd assumed it could antialias lines and curves in the same way. > > > @font-face is a way to load a reference to a font that you can then use in a > > CSS font-family definition. Most browsers now support it, although IE only > > had partial support until v9 (http://caniuse.com/#feat=fontface ). Browsers > > that don't support it would just use fallback font families as is normal > > with CSS. > > Sorry, but I still don't get it. What will you reference with that > directive? Do you mean to put logo as text in html? > > Yes, you'd put the logo in as HTML, and style it with CSS. Newer browsers let you reference fonts, so that you can use a font which isn't installed on the user's computer. See Google's instructions for Droid Sans Mono, for example: > > http://www.google.com/webfonts/family?family=Droid+Sans+Mono&subset=latin#code > > > The top ones look fine to me, but I'll let other people comment on > > typographic matters! Hope this isn't getting too frustrating - we should > > have a decision soon. > > No. I was asking as I wasn't sure if you are implying to redo. > I'm in Droid from those samples > > If you've got spare time, it would be interesting to see them with the [y] adjusted so that there's less space above the y (whether you move the y or shrink the [ ] is up to you). But don't worry too much about it. Primarily I'd like to get some more opinions - Brian, Min, Evan, you've all weighed in on logos previously - what do you think of the different fonts Klonuo has tried? I like Droid Sans Mono. Quicksend is too dainty, and I don't like how low the y's are compared to the brackets in Inconsolata and Anonymous Pro. I believe Fernando made a similar comment about the placement of the 'y'. Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Tue Jun 21 16:29:30 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 21 Jun 2011 21:29:30 +0100 Subject: [IPython-dev] Website In-Reply-To: <20110621221505.1038.B1C76292@gmail.com> References: <20110621203958.102D.B1C76292@gmail.com> <20110621221505.1038.B1C76292@gmail.com> Message-ID: On 21 June 2011 21:15, Klonuo wrote: > > So you are saying to use image only for IP[y]: part in logo and use html > and webfont feature for description part? > > If it's not complicated for you to manage it, that could solve > antialiasing thing, as we are not concerned about antialiasing > in IP[y]: part as it uses large enough font Actually, I was thinking of doing the lot in html/css. I don't relish the idea of trying to make it behave, but it does sidestep all the arguments about subpixel antialiasing. Let's do a PNG first, so we can get the website up, then worry about doing anything clever later - as Fernando said before, the focus is on the upcoming release (and it would be nice to have the website ready by then). >Maybe they don't browse topics named "Website" :D Maybe! I see Evan's responded (thanks, Evan). We'll give the others a bit more time. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From johann.cohentanugi at gmail.com Tue Jun 21 16:45:48 2011 From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi) Date: Tue, 21 Jun 2011 22:45:48 +0200 Subject: [IPython-dev] new doc for parallel sessions on clusters In-Reply-To: References: <4E002819.4080504@lupm.univ-montp2.fr> <9CDA3147-8799-48E5-AC35-6392F9A8D8D4@gmail.com> <4E00AA40.3070802@lupm.univ-montp2.fr> <4E00C756.4080400@gmail.com> <4E00CE1F.3000609@gmail.com> Message-ID: <4E0102FC.6010407@gmail.com> On 06/21/2011 07:58 PM, MinRK wrote: > Glad you were able to fix it. I am still a bit puzzled by what I see in the $HOME/.config/ipython/profile_lsf/ipcluster_config.py I do not see c.Global, but for instance : -bash-3.2$ grep engine_launcher ~/.config/ipython/profile_lsf/* /u/ec/cohen/.config/ipython/profile_lsf/ipcluster_config.py:# c.IPClusterStart.engine_launcher_class = 'LSFEngineSetLauncher' /u/ec/cohen/.config/ipython/profile_lsf/ipcluster_config.py:# c.IPClusterEngines.engine_launcher_class = 'LSFEngineSetLauncher' (where LSF replaces Local as I just edited it) Johann > I just pushed an update to the online docs, so they should be up to date now. thanks a lot. Where is it? http://ipython.org/ipython-doc/dev/parallel/parallel_process.html seems to still be the old version.... best, JCT > On Tue, Jun 21, 2011 at 10:00, Johann Cohen-Tanugi > wrote: >> ok found the problem : I still had the ipython-newapp source code in the >> same dir as the new ipython, I did everything from this new ipython dir, >> but at execution it was looking into ipython-newapp. Obviously there is >> something I was not expecting.... Anyway now it works. >> >> sorry again, >> Johann >> >> On 06/21/2011 06:41 PM, MinRK wrote: >>> On Tue, Jun 21, 2011 at 09:31, Johann Cohen-Tanugi >>> wrote: >>>> hmmm ok, after the merge is this the right way to get the code : >>>> git clone git://github.com/ipython/ipython.git ipython >>>> I removed the whole source directory, and the local install stuff related >>>> to >>>> python, and I started from scratch using the git command above. >>>> then : >>>> python setup.py install >>>> --prefix=/afs/slac/g/glast/users/cohen/IPYDEV/local/which python >>>> >>>> perhaps the problem is that there is an ipython installed with the native >>>> python that I use above, and I am wrong to assume that having >>>> /afs/slac/g/glast/users/cohen/IPYDEV/local/.../site-packages at the top >>>> of >>>> PYTHONPATH is enough to ensure that it overrides the one installed with >>>> python? >>> If it was installed with setuptools/easy_install, yes - they inject >>> packages at the front sys.path at runtime, ending up ahead of >>> PYTHONPATH. easy_installed packages can even come before '.'. >>> >>> You can check which one you are importing by looking at >>> `IPython.__file__`. >>> >>> It's possible that I've messed something up, but the source looks >>> right >>> (https://github.com/ipython/ipython/blob/master/IPython/core/profileapp.py#L127) >>> >>>> Anyway, I will continue investigating.... >>>> sorry for the noise, >>>> JOhann >>>> >>>> On 06/21/2011 05:27 PM, MinRK wrote: >>>>> On Tue, Jun 21, 2011 at 07:27, Johann Cohen-Tanugi >>>>> wrote: >>>>>> hi there, I tried to build the sphinx doc on my machine after a pull of >>>>>> the >>>>>> head (after Min announced the merge of newapp into master), and I see >>>>>> the >>>>>> following in docs/source/parallel/parallel_process.txt : >>>>>> 1/ A trivial typo at : >>>>>> :command:`ipcluster` has a notion of Launchers that can start >>>>>> controllers >>>>>> and engines with various remote execution schemes. Currently supported >>>>>> models include :command:`ssh`, :command`mpiexec`, PBS-style (Torque, >>>>>> SGE), >>>>>> and Windows HPC Server. >>>>>> >>>>>> |_____> >>>>>> should be :command:`mpiexec` >>>>>> 2/ I can read the following lines : >>>>>> $ ipython profile create --parallel profile=mpi >>>>>> or >>>>>> $ ipython profile create --parallel profile=pbs >>>>>> >>>>>> while ipython profile create does *not* accept a --parallel option >>>>>> AFAICT, >>>>>> but rather --cluster or --no-cluster. >>>>> Then you do not have current master, because the flag is indeed >>>>> '--parallel'. >>>>> >>>>>> best, >>>>>> Johann >>>>>> >>>>>> On 06/21/2011 07:37 AM, Min RK wrote: >>>>>>> Yes, it is going to be standard for the cluster profile and >>>>>>> interactive >>>>>>> IPython to be different - the profile for the Client is principally >>>>>>> for >>>>>>> connection info, and the shell profile is for configuring your >>>>>>> interactive >>>>>>> environment. There's no reason to change your interactive config just >>>>>>> to >>>>>>> connect to a different cluster. >>>>>>> >>>>>>> That said, the default profile of the Client should probably be that >>>>>>> of >>>>>>> the current application, not just 'default'. >>>>>>> >>>>>>> -MinRK >>>>>>> >>>>>>> On Jun 20, 2011, at 22:11, Johann >>>>>>> Cohen-Tanugi wrote: >>>>>>> >>>>>>>> hi- I don't think we should print the profile name in the default >>>>>>>> case, >>>>>>>>> it's just noise. I realize we now have a more consistent structure >>>>>>>>> for profiles and even the default case is now a profile, but we >>>>>>>>> should >>>>>>>>> keep the amount of printed stuff to a minimum in the default cases. >>>>>>>>> >>>>>>>> Actually I have a question here : I was trying newapp, following >>>>>>>> Min's >>>>>>>> advice, to try to add the LSF support in parallel.apps. From what I >>>>>>>> could >>>>>>>> gather >>>>>>>> I did >>>>>>>> ipcluster start -p lsf -n 2 >>>>>>>> which created profile_lsf in my $HOME/.ipython directory, but then >>>>>>>> when >>>>>>>> I >>>>>>>> started another terminal window for the ipython session, I typed >>>>>>>> ipython profile=lsf >>>>>>>> and this loaded the default profile, so that I had to type : >>>>>>>> >>>>>>>> from IPython.parallel import Client >>>>>>>> c = Client(profile='lsf') >>>>>>>> >>>>>>>> so that unless this is a bug or an operator mistake, there seems to >>>>>>>> be >>>>>>>> 2 >>>>>>>> 'profiles' in such a use case : the ipython global one, and the >>>>>>>> parallel lsf >>>>>>>> one. I find that a bit confusing, and maybe there is a way to merge >>>>>>>> the >>>>>>>> 2? >>>>>>>> >>>>>>>> best, >>>>>>>> Johann From benjaminrk at gmail.com Tue Jun 21 17:41:55 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 21 Jun 2011 14:41:55 -0700 Subject: [IPython-dev] new doc for parallel sessions on clusters In-Reply-To: <4E0102FC.6010407@gmail.com> References: <4E002819.4080504@lupm.univ-montp2.fr> <9CDA3147-8799-48E5-AC35-6392F9A8D8D4@gmail.com> <4E00AA40.3070802@lupm.univ-montp2.fr> <4E00C756.4080400@gmail.com> <4E00CE1F.3000609@gmail.com> <4E0102FC.6010407@gmail.com> Message-ID: On Tue, Jun 21, 2011 at 13:45, Johann Cohen-Tanugi wrote: > > > On 06/21/2011 07:58 PM, MinRK wrote: >> >> Glad you were able to fix it. > > I am still a bit puzzled by what I see in the > $HOME/.config/ipython/profile_lsf/ipcluster_config.py > I do not see c.Global, but for instance : > -bash-3.2$ grep engine_launcher ~/.config/ipython/profile_lsf/* > /u/ec/cohen/.config/ipython/profile_lsf/ipcluster_config.py:# > c.IPClusterStart.engine_launcher_class = 'LSFEngineSetLauncher' > /u/ec/cohen/.config/ipython/profile_lsf/ipcluster_config.py:# > c.IPClusterEngines.engine_launcher_class = 'LSFEngineSetLauncher' Sorry, c.Global is not used for anything anymore. The generated default config files are accurate. > > (where LSF replaces Local as I just edited it) > > Johann >> >> I just pushed an update to the online docs, so they should be up to date >> now. > > thanks a lot. Where is it? > http://ipython.org/ipython-doc/dev/parallel/parallel_process.html seems to > still be the old version.... Oops, I managed to push the update to my own branch. The real docs are up to date now. > > best, > JCT >> >> On Tue, Jun 21, 2011 at 10:00, Johann Cohen-Tanugi >> ?wrote: >>> >>> ok found the problem : I still had the ipython-newapp source code in the >>> same dir as the new ipython, I did everything from this new ipython dir, >>> but at execution it was looking into ipython-newapp. Obviously there is >>> something I was not expecting.... Anyway now it works. >>> >>> sorry again, >>> Johann >>> >>> On 06/21/2011 06:41 PM, MinRK wrote: >>>> >>>> On Tue, Jun 21, 2011 at 09:31, Johann Cohen-Tanugi >>>> ? ?wrote: >>>>> >>>>> hmmm ok, after the merge is this the right way to get the code : >>>>> ?git clone git://github.com/ipython/ipython.git ipython >>>>> I removed the whole source directory, and the local install stuff >>>>> related >>>>> to >>>>> python, and I started from scratch using the git command above. >>>>> then : >>>>> python setup.py install >>>>> --prefix=/afs/slac/g/glast/users/cohen/IPYDEV/local/which python >>>>> >>>>> perhaps the problem is that there is an ipython installed with the >>>>> native >>>>> python that I use above, and I am wrong to assume that having >>>>> /afs/slac/g/glast/users/cohen/IPYDEV/local/.../site-packages at the top >>>>> of >>>>> PYTHONPATH is enough to ensure that it overrides the one installed with >>>>> python? >>>> >>>> If it was installed with setuptools/easy_install, yes - they inject >>>> packages at the front sys.path at runtime, ending up ahead of >>>> PYTHONPATH. easy_installed packages can even come before '.'. >>>> >>>> You can check which one you are importing by looking at >>>> `IPython.__file__`. >>>> >>>> It's possible that I've messed something up, but the source looks >>>> right >>>> >>>> (https://github.com/ipython/ipython/blob/master/IPython/core/profileapp.py#L127) >>>> >>>>> Anyway, I will continue investigating.... >>>>> sorry for the noise, >>>>> JOhann >>>>> >>>>> On 06/21/2011 05:27 PM, MinRK wrote: >>>>>> >>>>>> On Tue, Jun 21, 2011 at 07:27, Johann Cohen-Tanugi >>>>>> ? ? ?wrote: >>>>>>> >>>>>>> hi there, I tried to build the sphinx doc on my machine after a pull >>>>>>> of >>>>>>> the >>>>>>> head (after Min announced the merge of newapp into master), and I see >>>>>>> the >>>>>>> following in docs/source/parallel/parallel_process.txt : >>>>>>> 1/ A trivial typo at : >>>>>>> :command:`ipcluster` has a notion of Launchers that can start >>>>>>> controllers >>>>>>> and engines with various remote execution schemes. ?Currently >>>>>>> supported >>>>>>> models include :command:`ssh`, :command`mpiexec`, PBS-style (Torque, >>>>>>> SGE), >>>>>>> and Windows HPC Server. >>>>>>> >>>>>>> ?|_____> >>>>>>> should be :command:`mpiexec` >>>>>>> 2/ I can read the following lines : >>>>>>> ? ?$ ipython profile create --parallel profile=mpi >>>>>>> or >>>>>>> ? ?$ ipython profile create --parallel profile=pbs >>>>>>> >>>>>>> while ipython profile create does *not* accept a --parallel option >>>>>>> AFAICT, >>>>>>> but rather --cluster or --no-cluster. >>>>>> >>>>>> Then you do not have current master, because the flag is indeed >>>>>> '--parallel'. >>>>>> >>>>>>> best, >>>>>>> Johann >>>>>>> >>>>>>> On 06/21/2011 07:37 AM, Min RK wrote: >>>>>>>> >>>>>>>> Yes, it is going to be standard for the cluster profile and >>>>>>>> interactive >>>>>>>> IPython to be different - the profile for the Client is principally >>>>>>>> for >>>>>>>> connection info, and the shell profile is for configuring your >>>>>>>> interactive >>>>>>>> environment. ?There's no reason to change your interactive config >>>>>>>> just >>>>>>>> to >>>>>>>> connect to a different cluster. >>>>>>>> >>>>>>>> That said, the default profile of the Client should probably be that >>>>>>>> of >>>>>>>> the current application, not just 'default'. >>>>>>>> >>>>>>>> -MinRK >>>>>>>> >>>>>>>> On Jun 20, 2011, at 22:11, Johann >>>>>>>> Cohen-Tanugi ? ? ? ?wrote: >>>>>>>> >>>>>>>>> hi- I don't think we should print the profile name in the default >>>>>>>>> case, >>>>>>>>>> >>>>>>>>>> it's just noise. ?I realize we now have a more consistent >>>>>>>>>> structure >>>>>>>>>> for profiles and even the default case is now a profile, but we >>>>>>>>>> should >>>>>>>>>> keep the amount of printed stuff to a minimum in the default >>>>>>>>>> cases. >>>>>>>>>> >>>>>>>>> Actually I have a question here : I was trying newapp, following >>>>>>>>> Min's >>>>>>>>> advice, to try to add the LSF support in parallel.apps. From what I >>>>>>>>> could >>>>>>>>> gather >>>>>>>>> I did >>>>>>>>> ipcluster start -p lsf -n 2 >>>>>>>>> which created profile_lsf in my $HOME/.ipython directory, but then >>>>>>>>> when >>>>>>>>> I >>>>>>>>> started another terminal window for the ipython session, I typed >>>>>>>>> ipython profile=lsf >>>>>>>>> and this loaded the default profile, so that I had to type : >>>>>>>>> >>>>>>>>> from IPython.parallel import Client >>>>>>>>> c = Client(profile='lsf') >>>>>>>>> >>>>>>>>> so that unless this is a bug or an operator mistake, there seems to >>>>>>>>> be >>>>>>>>> 2 >>>>>>>>> 'profiles' in such a use case : the ipython global one, and the >>>>>>>>> parallel lsf >>>>>>>>> one. I find that a bit confusing, and maybe there is a way to merge >>>>>>>>> the >>>>>>>>> 2? >>>>>>>>> >>>>>>>>> best, >>>>>>>>> Johann > From fperez.net at gmail.com Tue Jun 21 17:56:23 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 21 Jun 2011 14:56:23 -0700 Subject: [IPython-dev] Website In-Reply-To: <010497E2-70C3-4745-8035-093A1204D3ED@enthought.com> References: <20110621193331.BE09.B1C76292@gmail.com> <20110621203958.102D.B1C76292@gmail.com> <010497E2-70C3-4745-8035-093A1204D3ED@enthought.com> Message-ID: On Tue, Jun 21, 2011 at 1:16 PM, Evan Patterson wrote: > I like Droid Sans Mono. Quicksend is too dainty, and I don't like how low > the y's are compared to the brackets in Inconsolata and Anonymous Pro. I > believe Fernando made a similar comment about the placement of the 'y'. My thoughts precisely. Having said that, I'm back to silent mode, so that any cycles I may have go towards reviewing critical pull requests for the release. We can release with an ugly banner, not with major blocker bugs :) Cheers, f From klonuo at gmail.com Tue Jun 21 18:05:31 2011 From: klonuo at gmail.com (Klonuo) Date: Wed, 22 Jun 2011 00:05:31 +0200 Subject: [IPython-dev] Website In-Reply-To: References: <010497E2-70C3-4745-8035-093A1204D3ED@enthought.com> Message-ID: <20110622000524.103C.B1C76292@gmail.com> On Tue, 21 Jun 2011 14:56:23 -0700 Fernando Perez wrote: > On Tue, Jun 21, 2011 at 1:16 PM, Evan Patterson wrote: > > I like Droid Sans Mono. Quicksend is too dainty, and I don't like how low > > the y's are compared to the brackets in Inconsolata and Anonymous Pro. I > > believe Fernando made a similar comment about the placement of the 'y'. > > My thoughts precisely. > > Having said that, I'm back to silent mode, so that any cycles I may > have go towards reviewing critical pull requests for the release. We > can release with an ugly banner, not with major blocker bugs :) I attached enhanced banner some hours ago, with Droid Sans in standard and subpixel antialiasing versions, which can be used instead current From takowl at gmail.com Tue Jun 21 18:21:24 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 21 Jun 2011 23:21:24 +0100 Subject: [IPython-dev] Website In-Reply-To: <20110622000524.103C.B1C76292@gmail.com> References: <010497E2-70C3-4745-8035-093A1204D3ED@enthought.com> <20110622000524.103C.B1C76292@gmail.com> Message-ID: On 21 June 2011 23:05, Klonuo wrote: > I attached enhanced banner some hours ago, with Droid Sans in standard > and subpixel antialiasing versions, which can be used instead current Right, I've put that up on http://takluyver.github.com/ipython-website/ . I think the standard anti-aliased version looks OK on an LCD screen. If there's no objections, I'll flip the switch on this design tomorrow evening. We can, of course, carry on tweaking later. Klonuo, can we have an SVG version of the Droid Sans Mono banner, since that seems to be what we're going with for now. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Tue Jun 21 18:27:30 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 21 Jun 2011 15:27:30 -0700 Subject: [IPython-dev] Website In-Reply-To: References: <010497E2-70C3-4745-8035-093A1204D3ED@enthought.com> <20110622000524.103C.B1C76292@gmail.com> Message-ID: Quicksend and Droid Sans are pretty nice, but the space around/above the 'y' needs to be addressed (in all of them). The logo actually on the website should *not* be SVG, it should be a simple PNG for browser consistency. The SVG is for keeping a source so we can build new images for various sizes, etc., and make changes most easily. -MinRK On Tue, Jun 21, 2011 at 15:21, Thomas Kluyver wrote: > On 21 June 2011 23:05, Klonuo wrote: >> >> I attached enhanced banner some hours ago, with Droid Sans in standard >> and subpixel antialiasing versions, which can be used instead current > > Right, I've put that up on http://takluyver.github.com/ipython-website/ . I > think the standard anti-aliased version looks OK on an LCD screen. > > If there's no objections, I'll flip the switch on this design tomorrow > evening. We can, of course, carry on tweaking later. > > Klonuo, can we have an SVG version of the Droid Sans Mono banner, since that > seems to be what we're going with for now. > > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > From klonuo at gmail.com Tue Jun 21 18:57:58 2011 From: klonuo at gmail.com (Klonuo) Date: Wed, 22 Jun 2011 00:57:58 +0200 Subject: [IPython-dev] Website In-Reply-To: References: <20110622000524.103C.B1C76292@gmail.com> Message-ID: <20110622005751.1040.B1C76292@gmail.com> On Tue, 21 Jun 2011 23:21:24 +0100 Thomas Kluyver wrote: > Klonuo, can we have an SVG version of the Droid Sans Mono banner, since that > seems to be what we're going with for now. Attached SVG files are with embedded font characters - won't work in browsers but in vector application will (CorelDraw, Inkscape...) Attached files: 1. IPy_Droid-Sans-Mono.svg As in PDF sample 2. IPy_Droid-Sans-Mono_rev1.svg "y" enlarged to match IP size and vertical placing In summary: "[y]:" uses -15% kerning Letters "IPy" follow text flow (bottom line) at size 36pt, while symbols are at 30pt 3. logo_droid_rev1.png.png Bitmap from above Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: IPy_Droid-Sans-Mono.svg Type: application/octet-stream Size: 13154 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IPy_Droid-Sans-Mono_rev1.svg Type: application/octet-stream Size: 13182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_droid_rev1.png Type: image/png Size: 5960 bytes Desc: not available URL: From fperez.net at gmail.com Tue Jun 21 19:48:48 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 21 Jun 2011 16:48:48 -0700 Subject: [IPython-dev] Website In-Reply-To: References: <010497E2-70C3-4745-8035-093A1204D3ED@enthought.com> <20110622000524.103C.B1C76292@gmail.com> Message-ID: On Tue, Jun 21, 2011 at 3:21 PM, Thomas Kluyver wrote: > > Right, I've put that up on http://takluyver.github.com/ipython-website/ . I > think the standard anti-aliased version looks OK on an LCD screen. > > If there's no objections, I'll flip the switch on this design tomorrow > evening. We can, of course, carry on tweaking later. Awesome! And modulo minor cleanups that are still in flight, I'd then like to call for a friendly moratorium on all website design discussions for a little while :) I really, enormously appreciate the time you've all taken to help out with this, and Klonuo's patience is commendable. But I think it's time we shift our attention completely from design back to content, both in the code and even on the website. Let's hold off on more color/font/size debates for a few weeks, at least until we have 0.11 AND 0.12 done and released. Thanks to all who have helped, and I hope it's clear that I don't have the illusion that in a volunteer project, I can "tell" people how to spend their time. It's just that I'm worried that the clock is ticking on a release, and right now I'm to my neck in grant/talks/paper writing (most of it to benefit ipython in the long haul) so I would like to see our collective energies directed now towards not missing our long-promised 0.11 release. Cheers, f From ischnell at enthought.com Tue Jun 21 21:15:18 2011 From: ischnell at enthought.com (Ilan Schnell) Date: Tue, 21 Jun 2011 20:15:18 -0500 Subject: [IPython-dev] ANN: ETS 4.0 released Message-ID: Hello, I am happy to announce the release of ETS 4.0. This is the first major release of the Enthought Tool Suite in almost three years. This release removes the 'enthought' namespace from all projects. For example: from enthought.traits.api import HasTraits is now simply:: from traits.api import HasTraits For backwards compatibility, a proxy package 'etsproxy' has been added, which should permit existing code to work. For convenience this package also contains a refactor tool 'ets3to4' to convert projects to the new namespace (so that they don't rely on the 'etsproxy' package). If you want to download the source code of all ETS projects, you can download http://www.enthought.com/repo/ets/ALLETS-4.0.0.tar (41MB). The projects themselves are now hosted on: https://github.com/enthought We understand that the namespace refactor (which prompted this major release in the first place) is a big change, and even though we have tested examples and some of our own code against this ETS version, we expect there to be little glitches. We are therefore already planning a 4.0.1 bug-fix release in about 2-3 weeks. We are looking forward to your feedback (the development mailing list is enthought-dev at enthought.com), and hope you enjoy ETS 4. - Ilan From takowl at gmail.com Wed Jun 22 06:36:30 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 22 Jun 2011 11:36:30 +0100 Subject: [IPython-dev] To do before 0.11 release Message-ID: What still needs to be done before 0.11 is released: - Docs need to be updated (2 critical bugs) - Checking things on Windows (5 critical bugs) - Fix for unicode output on Windows (#529, pull request #534) Plus I'd like to land pull requests 462 (making traitlets compatible with Python 3) and 533 (removing dead code). As far as I know, both are ready and passing all tests, but I'd like someone else to OK them. Fernando, you're assigned on the docs bugs and one other critical bug. I know you've got a lot to do, so Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From johann.cohentanugi at gmail.com Wed Jun 22 11:39:36 2011 From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi) Date: Wed, 22 Jun 2011 17:39:36 +0200 Subject: [IPython-dev] client connection in shared filesystem for a farm of machines Message-ID: <4E020CB8.6060006@gmail.com> Hello, I am using a farm of several machines, and I log in to it using ssh and a generic farm name, ending up on one specific machine depending on loads etc.... All the machines of the farm see the AFS filesystem, on which a json file was created when I fired ipcluster after a first login to the farm. Then I start another terminal and log in again to the farm, ending up on another machine than the one the ipcluster is running on. If I then do : from IPython.parallel import Client c = Client() it hangs.... If I do: c = Client('/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json') it returns : --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /a/wain006/g.glast.u54/cohen/IPYDEV/test_directory/ in () ----> 1 c = Client('/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json') TypeError: __new__() takes exactly 1 argument (2 given) so I guess the doc in http://ipython.org/ipython-doc/dev/parallel/parallel_intro.html#getting-started needs a patch. Finally if I do : c = Client(url_or_file='/afs/slac/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json') it also hangs, while on the same ipython session I can immediately check : In [8]: ls -ltr /afs/slac/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json -rw------- 1 cohen ec 130 Jun 22 08:06 /afs/slac/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json that indeed the JSON file is accessible via the AFS file sharing. I checked that if I forced connecting to the same machine instead of using the generic farm name, c=Client() immediately returns with the engines attached and I can proceed normally. Thanks in advance for the help, johann From benjaminrk at gmail.com Wed Jun 22 14:41:42 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 22 Jun 2011 11:41:42 -0700 Subject: [IPython-dev] client connection in shared filesystem for a farm of machines In-Reply-To: <4E020CB8.6060006@gmail.com> References: <4E020CB8.6060006@gmail.com> Message-ID: On Wed, Jun 22, 2011 at 08:39, Johann Cohen-Tanugi wrote: > Hello, > I am using a farm of several machines, and I log in to it using ssh and > a generic farm name, ending up on one specific machine depending on > loads etc.... All the machines of the farm see the AFS filesystem, on > which a json file was created when I fired ipcluster after a first login > to the farm. > Then I start another terminal and log in again to the farm, ending up on > another machine than the one the ipcluster is running on. > If I then do : > from IPython.parallel import Client > c = Client() > > it hangs.... If I do: > c = > Client('/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json') > it returns : > --------------------------------------------------------------------------- > TypeError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call last) > /a/wain006/g.glast.u54/cohen/IPYDEV/test_directory/ > in () > ----> 1 c = > Client('/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json') > > TypeError: __new__() takes exactly 1 argument (2 given) > > so I guess the doc in > http://ipython.org/ipython-doc/dev/parallel/parallel_intro.html#getting-started > needs a patch. The docs are right - I just introduced a bug when I made the Client inherit from HasTraits. I pushed a simple fix to master, so it does accept positional arguments. I also included a fix for the 'hang', which is actually a units problem in pyzmq's select - trying to connect to a nonexistent controller will now timeout after 10 seconds (timeout is an arg in the Client constructor, so you can make it shorter if you like). > > Finally if I do : > c = > Client(url_or_file='/afs/slac/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json') > it also hangs, while on the same ipython session I can immediately check : > In [8]: ls -ltr > /afs/slac/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json > -rw------- 1 cohen ec 130 Jun 22 08:06 > /afs/slac/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json > > that indeed the JSON file is accessible via the AFS file sharing. > > > I checked that if I forced connecting to the same machine instead of > using the generic farm name, > c=Client() immediately returns with the engines attached and I can > proceed normally. The Controller only listens on loopback by default for security reasons. If you want to connect to a different machine, you must instruct the Controller to listen on a public interface (e.g. ip=0.0.0.0), which you should only do if your cluster is safely behind a firewall. Otherwise, you must use ssh tunnels to connect to the Controller, via the Client's 'ssh' arg. -MinRK > > Thanks in advance for the help, > johann > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From jason-sage at creativetrax.com Wed Jun 22 14:52:01 2011 From: jason-sage at creativetrax.com (Jason Grout) Date: Wed, 22 Jun 2011 13:52:01 -0500 Subject: [IPython-dev] Website In-Reply-To: References: Message-ID: <4E0239D1.4010801@creativetrax.com> On 6/20/11 7:53 AM, Thomas Kluyver wrote: > This is now RC1 for the new website: > > http://takluyver.github.com/ipython-website/ > A short comment (yes, I saw there was a moratorium; I'm just posting so that the comment doesn't get lost when website work is renewed :). I notice lots of links to .html files. For example, on the front page, you have: `More news... `_ Wouldn't it be better to use the sphinx linking syntax [1], so you could do something like this instead: :doc:`More news... ` That way you aren't hardcoding in the .html filename, so presumably links would work in other formats as well. You could also explicitly add a label and use a :ref: link instead. Thanks, Jason [1] http://sphinx.pocoo.org/markup/inline.html From benjaminrk at gmail.com Wed Jun 22 16:40:03 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 22 Jun 2011 13:40:03 -0700 Subject: [IPython-dev] client connection in shared filesystem for a farm of machines In-Reply-To: <4E024EF1.9000709@lupm.univ-montp2.fr> References: <4E020CB8.6060006@gmail.com> <4E024EF1.9000709@lupm.univ-montp2.fr> Message-ID: Sorry, A recent pull request broke the Controller. Should be fixed now. On Wed, Jun 22, 2011 at 13:22, Johann Cohen-Tanugi wrote: > hmm, I just did a "git pull", but now when starting the controller I get : > [IPClusterStart] [IPEngineApp] Using existing profile dir: > '/u/ec/cohen/.config/ipython/profile_default' > [IPClusterStart] ERROR:root:Error in periodic callback > [IPClusterStart] Traceback (most recent call last): > [IPClusterStart] ? File > "/afs/slac/g/glast/users/cohen/IPYDEV/local/lib/python2.6/site-packages/zmq/eventloop/ioloop.py", > line 432, in _run > [IPClusterStart] ? ? self.callback() > [IPClusterStart] ? File > "/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/parallel/controller/heartmonitor.py", > line 112, in beat > [IPClusterStart] ? ? map(self.handle_new_heart, newhearts) > [IPClusterStart] ? File > "/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/parallel/controller/heartmonitor.py", > line 123, in handle_new_heart > [IPClusterStart] ? ? handler(heart) > [IPClusterStart] ? File > "/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/parallel/controller/hub.py", > line 530, in handle_new_heart > [IPClusterStart] ? ? self.finish_registration(heart) > [IPClusterStart] ? File > "/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/parallel/controller/hub.py", > line 977, in finish_registration > [IPClusterStart] ? ? control=control, heartbeat=heart) > [IPClusterStart] ? File > "/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/utils/traitlets.py", > line 420, in __init__ > [IPClusterStart] ? ? setattr(self, key, value) > [IPClusterStart] ? File > "/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/utils/traitlets.py", > line 302, in __set__ > [IPClusterStart] ? ? new_value = self._validate(obj, value) > [IPClusterStart] ? File > "/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/utils/traitlets.py", > line 310, in _validate > [IPClusterStart] ? ? return self.validate(obj, value) > [IPClusterStart] ? File > "/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/utils/traitlets.py", > line 967, in validate > [IPClusterStart] ? ? self.error(obj, value) > [IPClusterStart] ? File > "/a/wain006/g.glast.u54/cohen/IPYDEV/ipython/IPython/utils/traitlets.py", > line 333, in error > [IPClusterStart] ? ? raise TraitError(e) > [IPClusterStart] TraitError: The 'control' trait of an EngineConnector > instance must be a string, but a value of > u'218df526-7c37-4bb1-bb57-652ce02cd122' was specified. > [IPClusterStart] INFO:IPControllerApp:heartbeat::ignoring new heart: > '218df526-7c37-4bb1-bb57-652ce02cd122' > > > On 06/22/2011 08:41 PM, MinRK wrote: >> >> On Wed, Jun 22, 2011 at 08:39, Johann Cohen-Tanugi >> ?wrote: >>> >>> Hello, >>> I am using a farm of several machines, and I log in to it using ssh and >>> a generic farm name, ending up on one specific machine depending on >>> loads etc.... All the machines of the farm see the AFS filesystem, on >>> which a json file was created when I fired ipcluster after a first login >>> to the farm. >>> Then I start another terminal and log in again to the farm, ending up on >>> another machine than the one the ipcluster is running on. >>> If I then do : >>> from IPython.parallel import Client >>> c = Client() >>> >>> it hangs.... If I do: >>> c = >>> >>> Client('/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json') >>> it returns : >>> >>> --------------------------------------------------------------------------- >>> TypeError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call >>> last) >>> >>> /a/wain006/g.glast.u54/cohen/IPYDEV/test_directory/ >>> in() >>> ----> ?1 c = >>> >>> Client('/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json') >>> >>> TypeError: __new__() takes exactly 1 argument (2 given) >>> >>> so I guess the doc in >>> >>> http://ipython.org/ipython-doc/dev/parallel/parallel_intro.html#getting-started >>> needs a patch. >> >> The docs are right - I just introduced a bug when I made the Client >> inherit from HasTraits. ?I pushed a simple fix to master, so it does >> accept positional arguments. >> I also included a fix for the 'hang', which is actually a units >> problem in pyzmq's select - trying to connect to a nonexistent >> controller will now timeout after 10 seconds (timeout is an arg in the >> Client constructor, so you can make it shorter if you like). >> >>> Finally if I do : >>> c = >>> >>> Client(url_or_file='/afs/slac/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json') >>> it also hangs, while on the same ipython session I can immediately check >>> : >>> In [8]: ls -ltr >>> >>> /afs/slac/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json >>> -rw------- 1 cohen ec 130 Jun 22 08:06 >>> >>> /afs/slac/u/ec/cohen/.config/ipython/profile_default/security/ipcontroller-client.json >>> >>> that indeed the JSON file is accessible via the AFS file sharing. >>> >>> >>> I checked that if I forced connecting to the same machine instead of >>> using the generic farm name, >>> c=Client() immediately returns with the engines attached and I can >>> proceed normally. >> >> The Controller only listens on loopback by default for security >> reasons. If you want to connect to a different machine, you must >> instruct the Controller to listen on a public interface (e.g. >> ip=0.0.0.0), which you should only do if your cluster is safely behind >> a firewall. Otherwise, you must use ssh tunnels to connect to the >> Controller, via the Client's 'ssh' arg. >> >> -MinRK >> >>> Thanks in advance for the help, >>> johann >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> > From fperez.net at gmail.com Thu Jun 23 17:25:30 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 23 Jun 2011 14:25:30 -0700 Subject: [IPython-dev] website banner filename change Message-ID: Hey, thanks to everyone for the work on the site, it looks great and it's now live at ipython.org! Thomas, quick thing: could you change the name of the banner file to something other than 'banner'? The reason for this odd request is that I noticed that in certain configurations, AdBlock will block any image file called 'banner.png'. So anyone who goes to our site and happens to have adblock installed with those settings simply won't see our banner at all, and they won't even know there's a problem, they'll simply see the site without the banner anywhere (and hence, will have no navigation pointer back to the homepage either). It seems safest simply to name it something else, like header_logo, or anything that doesn't match an aggressive *banner* regexp... Thanks! f From takowl at gmail.com Thu Jun 23 17:53:46 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 23 Jun 2011 22:53:46 +0100 Subject: [IPython-dev] website banner filename change In-Reply-To: References: Message-ID: On 23 June 2011 22:25, Fernando Perez wrote: > > It seems safest simply to name it something else, like header_logo, or > anything that doesn't match an aggressive *banner* regexp... Done. It's now IPy_header.png :-) Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Thu Jun 23 17:54:45 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 23 Jun 2011 14:54:45 -0700 Subject: [IPython-dev] website banner filename change In-Reply-To: References: Message-ID: On Thu, Jun 23, 2011 at 2:53 PM, Thomas Kluyver wrote: > > Done. It's now IPy_header.png :-) > Great, thanks! I now see our beautiful banner with all my browsers :) Best, f From klonuo at gmail.com Fri Jun 24 09:47:50 2011 From: klonuo at gmail.com (Klonuo) Date: Fri, 24 Jun 2011 15:47:50 +0200 Subject: [IPython-dev] website banner filename change In-Reply-To: References: Message-ID: <20110624154748.B254.B1C76292@gmail.com> On Thu, 23 Jun 2011 22:53:46 +0100 Thomas Kluyver wrote: > On 23 June 2011 22:25, Fernando Perez wrote: > > > > > It seems safest simply to name it something else, like header_logo, or > > anything that doesn't match an aggressive *banner* regexp... > > > Done. It's now IPy_header.png :-) > > Thomas Looks good :) Although I attached PNG/SVG logo that covered complains about empty spacing in brackets etc, as revision 1 in latest SVG attachments, but anyway it looks much better then previous logo and miles away then old rusty logo :D Footer (c) font is still unnecessary too big if I may notice From klonuo at gmail.com Fri Jun 24 09:50:03 2011 From: klonuo at gmail.com (Klonuo) Date: Fri, 24 Jun 2011 15:50:03 +0200 Subject: [IPython-dev] website banner filename change In-Reply-To: References: Message-ID: <20110624154957.B25B.B1C76292@gmail.com> On Thu, 23 Jun 2011 22:53:46 +0100 Thomas Kluyver wrote: > On 23 June 2011 22:25, Fernando Perez wrote: > > > > > It seems safest simply to name it something else, like header_logo, or > > anything that doesn't match an aggressive *banner* regexp... > > > Done. It's now IPy_header.png :-) > > Thomas Sorry forgot previously to mention necessity of more top padding for logo/header From ellisonbg at gmail.com Fri Jun 24 14:01:38 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 24 Jun 2011 11:01:38 -0700 Subject: [IPython-dev] Requiring distribute on Windows Message-ID: Hi, In the course of testing IPython.parallel on Windows, Min and I have discovered that ipcluster won't work on Windows unless distribute is installed and used to install IPython. The reason is that setuptools has a bug that interacts with multiprocessing in a subtle, nasty way. Min has been using distribute all along for testing and dev., so we didn't see it until now. This leads to a question: Should we required distribute to be installed and used to install IPython on Windows? I am not sure how this will affect the .msi installer. We might be able to relax the requirement for that installer as the command line scripts are created differently. Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From benjaminrk at gmail.com Fri Jun 24 14:52:55 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 24 Jun 2011 11:52:55 -0700 Subject: [IPython-dev] Requiring distribute on Windows In-Reply-To: References: Message-ID: On Fri, Jun 24, 2011 at 11:01, Brian Granger wrote: > Hi, > > In the course of testing IPython.parallel on Windows, Min and I have > discovered that ipcluster won't work on Windows unless distribute is > installed and used to install IPython. ?The reason is that setuptools > has a bug that interacts with multiprocessing in a subtle, nasty way. > Min has been using distribute all along for testing and dev., so we > didn't see it until now. ?This leads to a question: > > Should we required distribute to be installed and used to install > IPython on Windows? The issue is that distribute writes scripts with the traditional `if __name__ == '__main__'` block, whereas vanilla setuptools does not, breaking any use of multiprocessing in entry points on Windows (all child processes will enter the outer loop, launching an infinite number of children). I *have* figured out a way to catch this in the entry point itself using inspect, so we shouldn't have to depend on distribute, if this fix is acceptable: https://github.com/minrk/ipython/commit/ab437a4d476f7819cf47a5dbb5ee6d40f66a7958 -MinRK > > I am not sure how this will affect the .msi installer. ?We might be > able to relax the requirement for that installer as the command line > scripts are created differently. > > Cheers, > > Brian > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From ellisonbg at gmail.com Fri Jun 24 15:20:07 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Fri, 24 Jun 2011 12:20:07 -0700 Subject: [IPython-dev] Requiring distribute on Windows In-Reply-To: References: Message-ID: On Fri, Jun 24, 2011 at 11:52 AM, MinRK wrote: > On Fri, Jun 24, 2011 at 11:01, Brian Granger wrote: >> Hi, >> >> In the course of testing IPython.parallel on Windows, Min and I have >> discovered that ipcluster won't work on Windows unless distribute is >> installed and used to install IPython. ?The reason is that setuptools >> has a bug that interacts with multiprocessing in a subtle, nasty way. >> Min has been using distribute all along for testing and dev., so we >> didn't see it until now. ?This leads to a question: >> >> Should we required distribute to be installed and used to install >> IPython on Windows? > > The issue is that distribute writes scripts with the traditional `if > __name__ == '__main__'` block, whereas > vanilla setuptools does not, breaking any use of multiprocessing in > entry points on Windows (all child processes will enter the outer > loop, launching an infinite number of children). > > I *have* figured out a way to catch this in the entry point itself > using inspect, so we shouldn't have to depend on distribute, if this > fix is acceptable: > > https://github.com/minrk/ipython/commit/ab437a4d476f7819cf47a5dbb5ee6d40f66a7958 I will look at this later today. That would probably be better than requiring distribute though. Cheers, Brian > -MinRK > >> >> I am not sure how this will affect the .msi installer. ?We might be >> able to relax the requirement for that installer as the command line >> scripts are created differently. >> >> Cheers, >> >> Brian >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> bgranger at calpoly.edu and ellisonbg at gmail.com >> _______________________________________________ >> IPython-dev mailing list >> IPython-dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From benjaminrk at gmail.com Fri Jun 24 15:20:53 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 24 Jun 2011 12:20:53 -0700 Subject: [IPython-dev] Requiring distribute on Windows In-Reply-To: References: Message-ID: On Fri, Jun 24, 2011 at 12:20, Brian Granger wrote: > On Fri, Jun 24, 2011 at 11:52 AM, MinRK wrote: >> On Fri, Jun 24, 2011 at 11:01, Brian Granger wrote: >>> Hi, >>> >>> In the course of testing IPython.parallel on Windows, Min and I have >>> discovered that ipcluster won't work on Windows unless distribute is >>> installed and used to install IPython. ?The reason is that setuptools >>> has a bug that interacts with multiprocessing in a subtle, nasty way. >>> Min has been using distribute all along for testing and dev., so we >>> didn't see it until now. ?This leads to a question: >>> >>> Should we required distribute to be installed and used to install >>> IPython on Windows? >> >> The issue is that distribute writes scripts with the traditional `if >> __name__ == '__main__'` block, whereas >> vanilla setuptools does not, breaking any use of multiprocessing in >> entry points on Windows (all child processes will enter the outer >> loop, launching an infinite number of children). >> >> I *have* figured out a way to catch this in the entry point itself >> using inspect, so we shouldn't have to depend on distribute, if this >> fix is acceptable: >> >> https://github.com/minrk/ipython/commit/ab437a4d476f7819cf47a5dbb5ee6d40f66a7958 > > I will look at this later today. ?That would probably be better than > requiring distribute though. I discovered a cleaner check using multiprocessing instead of inspect: https://github.com/minrk/ipython/commit/3d64c96440751be38fe2a61400134eec3609457e > > Cheers, > > Brian > >> -MinRK >> >>> >>> I am not sure how this will affect the .msi installer. ?We might be >>> able to relax the requirement for that installer as the command line >>> scripts are created differently. >>> >>> Cheers, >>> >>> Brian >>> >>> -- >>> Brian E. Granger >>> Cal Poly State University, San Luis Obispo >>> bgranger at calpoly.edu and ellisonbg at gmail.com >>> _______________________________________________ >>> IPython-dev mailing list >>> IPython-dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/ipython-dev >>> >> > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > bgranger at calpoly.edu and ellisonbg at gmail.com > From fperez.net at gmail.com Fri Jun 24 15:23:23 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 24 Jun 2011 12:23:23 -0700 Subject: [IPython-dev] Requiring distribute on Windows In-Reply-To: References: Message-ID: On Fri, Jun 24, 2011 at 11:52 AM, MinRK wrote: > > I *have* figured out a way to catch this in the entry point itself > using inspect, so we shouldn't have to depend on distribute, if this > fix is acceptable: > > https://github.com/minrk/ipython/commit/ab437a4d476f7819cf47a5dbb5ee6d40f66a7958 It's not pretty, but seems tightly localized enough that it won't have a big ripple effect, and hopefully post 0.11 we can spend some time building the installation code to deploy ipython without requiring either setuptools or distribute. If we had a penny for every hour setuptools has cost us, we'd be rich :) Cheers, f From erik.tollerud at gmail.com Sun Jun 26 03:41:21 2011 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Sun, 26 Jun 2011 02:41:21 -0500 Subject: [IPython-dev] No newapp gui=osx option? Message-ID: There's some behavior in the newapp configuration system I don't entirely understand under Mac OS X. The "%gui" magic seems to still accept the "osx" GUI integration (although it's not in the docstring), but it doesn't work in the command line "gui=xxx" option. On the other hand, "pylab=osx" does seem to work. Some I'm confused as to why the "gui" option has no osx choice, but pylab does. This may not matter, as the macosx backend it matplotlib seems to work fine regardless of the state of the gui magic, but it's a bit confusing what exactly the point of the osx option is, in that case. -- Erik Tollerud From benjaminrk at gmail.com Sun Jun 26 14:32:25 2011 From: benjaminrk at gmail.com (Min RK) Date: Sun, 26 Jun 2011 11:32:25 -0700 Subject: [IPython-dev] No newapp gui=osx option? In-Reply-To: References: Message-ID: <3A00D530-230F-496A-828E-088C765F1B51@gmail.com> the GUI integration is for making IPython work with the eventloop of various GUI toolkits when the basic IPython won't. Nothing needs to change for the Mac backend to work, so there is no special GUI integration for the mac eventloop. The pylab flag selects the matplotlib backend *and* the appropriate eventloop integration, which for macosx is None. -MinRK On Jun 26, 2011, at 0:41, Erik Tollerud wrote: > There's some behavior in the newapp configuration system I don't > entirely understand under Mac OS X. The "%gui" magic seems to still > accept the "osx" GUI integration (although it's not in the docstring), > but it doesn't work in the command line "gui=xxx" option. On the > other hand, "pylab=osx" does seem to work. Some I'm confused as to > why the "gui" option has no osx choice, but pylab does. > > This may not matter, as the macosx backend it matplotlib seems to work > fine regardless of the state of the gui magic, but it's a bit > confusing what exactly the point of the osx option is, in that case. > > -- > Erik Tollerud > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From benjaminrk at gmail.com Sun Jun 26 22:02:09 2011 From: benjaminrk at gmail.com (MinRK) Date: Sun, 26 Jun 2011 19:02:09 -0700 Subject: [IPython-dev] 0.11 update Message-ID: Hello, Another update on currently outstanding issues marked for 0.11, so we can see how we are doing. I think we are quite close, and documentation is really where the focus needs to be this week. I'm sure there are several places where docs and examples refer to stale 0.10 APIs or patterns. critical issues: --------- #281: pyreadline doesn't appear to play nice with the matplotlib qt backend on Windows. I don't know anything about how to address this issue. J?rgen said that it does not affect the qtconsole (logical, because the qtconsole doesn't use readline). This is a pretty big deal, but it doesn't *technically* appear to be an IPython issue, though IPython is where interactive matplotlib and pyreadline meet each other. It does *only* affect qt+terminal IPython with pyreadline, though. #66: What's New. It appears to be fairly up to date (https://github.com/ipython/ipython/blob/master/docs/source/whatsnew/development.txt), but anything devs notice as missing should be added. We can leave this open as a reminder until the last minute. #8: mayavi+qt - This appears to be fixed by the recently released ETS4, but Evan said he will test to be sure #269: mainloop() API - this code seems to be ready, so the issue now just involves a doc update, and the embedding IPython docs and examples don't appear to have been touched since 0.10, so they obviously need to be revisited. I've started working on this, and I'll push updates probably this evening. high: ----- #440: qtconsole crash on %run completion on Linux+EPD when run from a launcher without a terminal window - since this is solved by requiring the qtconsole to have a terminal window, I'm not too concerned with letting this stand in 0.11, though we should definitely figure it out. #378: Windows path issues - Windows path completion appears to have never been particularly good when using absolute paths and/or backslash escapes. I thought this was a bad regression, but when I tried testing with 0.10, it doesn't appear to be any worse as far as I can tell, though I am not well experienced with Windows. Since fixing this would be a major improvement over 0.10, rather than fixing a regression, I'm okay with slipping to 0.12. Any Windows developers who can explore this would be much appreciated. At this point, I think all medium and low priority issues will not make the cut for 0.11, unless someone feels the need to take care of a few of them. Anyone who thinks we should block on one of these, should suggest it be promoted to high/critical. I don't think letting these slip is a huge deal, since we plan to have a relatively quick succession of releases as bugs are inevitably revealed once we actually get 0.11 out the door. I think we should be able to cut 0.11 (or possibly 0.11 rc1) by this Friday, 07/01. -MinRK From takowl at gmail.com Mon Jun 27 06:35:15 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 27 Jun 2011 11:35:15 +0100 Subject: [IPython-dev] 0.11 update In-Reply-To: References: Message-ID: On 27 June 2011 03:02, MinRK wrote: > > #66: What's New. It appears to be fairly up to date > ( > https://github.com/ipython/ipython/blob/master/docs/source/whatsnew/development.txt > ), > but anything devs notice as missing should be added. We can leave this > open as a reminder until the last minute. I made some updates to it a while back, but I don't know most of what's been going on since the last release, so it could definitely do with other people checking it. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Tue Jun 28 16:43:40 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 28 Jun 2011 21:43:40 +0100 Subject: [IPython-dev] get_ipython() versus _ip Message-ID: Something I've been wondering for a while now: in previous versions, the user namespace had a reference to the shell object with a name like _ip. In trunk, we've replaced that with a get_ipython() callable, which returns the same reference. What was the reasoning behind that? I find that when I want to use it, I inevitably end up typing "ip = get_ipython()", both for brevity and so I get tab completion. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Tue Jun 28 19:55:46 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 28 Jun 2011 16:55:46 -0700 Subject: [IPython-dev] get_ipython() versus _ip In-Reply-To: References: Message-ID: The logic was that we want to minimize the things we insert into the global namespace. The name get_ipython is 1) less likely to run into collisions than generic things like _ip and 2) get_ipython suggest that it is a public API, whereas all of the _ and __ names suggest that it is a private API. I know it is not great, but I like having something that is public but we want to avoid name collisions. I am definitely open to ideas though. Brian On Tue, Jun 28, 2011 at 1:43 PM, Thomas Kluyver wrote: > Something I've been wondering for a while now: in previous versions, the > user namespace had a reference to the shell object with a name like _ip. In > trunk, we've replaced that with a get_ipython() callable, which returns the > same reference. What was the reasoning behind that? I find that when I want > to use it, I inevitably end up typing "ip = get_ipython()", both for brevity > and so I get tab completion. > > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Tue Jun 28 20:15:09 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 29 Jun 2011 01:15:09 +0100 Subject: [IPython-dev] get_ipython() versus _ip In-Reply-To: References: Message-ID: On 29 June 2011 00:55, Brian Granger wrote: > The name get_ipython is 1) less likely to run into collisions than > generic things like _ip and 2) > get_ipython suggest that it is a public API, whereas all of the _ and > __ names suggest that > it is a private API. > That makes sense. I'd prefer to have a reference rather than a callable, though. Would it make sense to have a public reference called something like ipy, and a backup copy called something like __ipy? The public name would act like the built in variables - you can replace it if you want, but it's not advised. Our own code would use the 'hidden' name, so magic functions etc. would carry on working even if you did ipy = 2. Then again, I'm comfortable with the idea of using 'hidden' name like _ip as the only available name: it's a bit special, because it reaches outside of the environment you're working in, so it makes sense to mark it as different. It's also not something I'd expect most end users to be using regularly. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Wed Jun 29 22:45:52 2011 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 29 Jun 2011 19:45:52 -0700 Subject: [IPython-dev] Connection info for qtconsole kernels Message-ID: I just noticed that on the current master, the message indicating the connection details needed to use "--existing" are no longer printed when an ipython qtconsole is started, but instead prints the kernel pid. Is this intentional? Is there some way to output that information when the first qtconsole is started, or retrieve it if I know the kernel pid? It seems to defeat the point of the --existing option if it's impossible to get the information needed to make the connection. I know "--debug" includes the information, but printing all the debug information to be able to connect a second console seems confusing/difficult. (Oh, and the debug line says "--external shell=##### iopub=##### stdin=##### hb=#####", which I think is supposed to be "--existing shell=##### iopub=##### stdin=##### hb=#####" - I can submit a bug report on that if desired, although it seems pretty trivial) On a related note, with the newapp configuration system is there any way to connect to an already-existing kernel via a terminal-based frontend, or is qtconsole currently the only way to do this? -- Erik Tollerud From benjaminrk at gmail.com Wed Jun 29 23:18:58 2011 From: benjaminrk at gmail.com (MinRK) Date: Wed, 29 Jun 2011 20:18:58 -0700 Subject: [IPython-dev] Connection info for qtconsole kernels In-Reply-To: References: Message-ID: On Wed, Jun 29, 2011 at 19:45, Erik Tollerud wrote: > I just noticed that on the current master, the message indicating the > connection details needed to use "--existing" are no longer printed > when an ipython qtconsole is started, but instead prints the kernel > pid. ?Is this intentional? ?Is there some way to output that > information when the first qtconsole is started, or retrieve it if I > know the kernel pid? ?It seems to defeat the point of the --existing > option if it's impossible to get the information needed to make the > connection. I noticed this too, and actually fixed it a few hours ago in https://github.com/ipython/ipython/commit/cc9aebe90611bde507fa6cf7206a4afda421179b > > I know "--debug" includes the information, but printing all the debug > information to be able to connect a second console seems > confusing/difficult. (Oh, and the debug line says "--external > shell=##### iopub=##### stdin=##### hb=#####", which I think is > supposed to be "--existing shell=##### iopub=##### stdin=##### > hb=#####" - I can submit a bug report on that if desired, although it > seems pretty trivial) > > > On a related note, with the newapp configuration system is there any > way to connect to an already-existing kernel via a terminal-based > frontend, or is qtconsole currently the only way to do this? There are plans for other two-process frontends, but there is not yet a working terminal version. Currently there is only the QtConsole in master, and the html notebook is in a branch. -MinRK > > -- > Erik Tollerud > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From takowl at gmail.com Thu Jun 30 05:11:57 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Thu, 30 Jun 2011 10:11:57 +0100 Subject: [IPython-dev] Connection info for qtconsole kernels In-Reply-To: References: Message-ID: On 30 June 2011 04:18, MinRK wrote: > There are plans for other two-process frontends, but there is not yet > a working terminal version. Currently there is only the QtConsole in > master, and the html notebook is in a branch. > There's a basic working prototype for a terminal frontend, although it's not yet adapted to use newapp. It's here if you want to hack on it: https://github.com/ipython/ipython/pull/433 Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: