Glut #742

Merged
merged 13 commits into from Sep 19, 2011

Projects

None yet

3 participants

@rougier
Contributor
rougier commented Aug 29, 2011

This is the experimental glut event loop integration.
It requires PyOpenGL.

@fperez fperez and 1 other commented on an outdated diff Aug 29, 2011
IPython/lib/inputhook.py
+ import OpenGL.platform as platform
+
+ def timer_none(fps):
+ ''' Dummy timer function '''
+ pass
+
+ def display():
+ ''' Dummy display function '''
+ pass
+
+ def timer(fps):
+ # We should normally set the active window to 1 and post a
+ # redisplay for each window. The problem is that we do not know
+ # how much active windows we have and there is no function in glut
+ # to get that number.
+ # glut.glutSetWindow(1)
fperez
fperez Aug 29, 2011 Owner

This is commented out, but it's not clear to me if you mean that eventually there will be a better solution or not. With the code as it stands, it states the problem but doesn't let us know what we should do next...

Did you mean this comment for discussion with us, or for future authors to perhaps make improvements?

rougier
rougier Aug 29, 2011 Contributor

In fact, I do not see a better solution by now but if someone comes with a better solution, that would be great. However, since glut is very old (but widely used) and pretty frozen, it might not be that easy. So to answer your question is more a comment for future authors to make improvements.

@fperez fperez and 1 other commented on an outdated diff Aug 29, 2011
IPython/lib/inputhook.py
+ # to get that number.
+ # glut.glutSetWindow(1)
+ glut.glutTimerFunc( int(1000.0/fps), timer, fps)
+ glut.glutPostRedisplay()
+
+ glutMainLoopEvent = None
+ if sys.platform == 'darwin':
+ try:
+ glutCheckLoop = platform.createBaseFunction(
+ 'glutCheckLoop', dll=platform.GLUT, resultType=None,
+ argTypes=[],
+ doc='glutCheckLoop( ) -> None',
+ argNames=(),
+ )
+ except AttributeError:
+ raise RuntimeError,\
fperez
fperez Aug 29, 2011 Owner

Exceptions should be raised as

raise RuntimeError("message....")

using (), as the raise E, "msg" syntax is valid but deprecated.

rougier
rougier Aug 29, 2011 Contributor

Corrected.

@fperez fperez and 1 other commented on an outdated diff Aug 29, 2011
IPython/lib/inputhook.py
+ try:
+ glutCheckLoop = platform.createBaseFunction(
+ 'glutCheckLoop', dll=platform.GLUT, resultType=None,
+ argTypes=[],
+ doc='glutCheckLoop( ) -> None',
+ argNames=(),
+ )
+ except AttributeError:
+ raise RuntimeError,\
+ 'Your glut implementation does not allow interactive sessions' \
+ 'Consider installing freeglut.'
+ glutMainLoopEvent = glutCheckLoop
+ elif glut.HAVE_FREEGLUT:
+ glutMainLoopEvent = glut.glutMainLoopEvent
+ else:
+ raise RuntimeError,\
fperez
fperez Aug 29, 2011 Owner

Same comment as above about exceptions.

rougier
rougier Aug 29, 2011 Contributor

Corrected.

@fperez fperez and 1 other commented on an outdated diff Aug 29, 2011
IPython/lib/inputhook.py
+ 'Consider installing freeglut.'
+ glutMainLoopEvent = glutCheckLoop
+ elif glut.HAVE_FREEGLUT:
+ glutMainLoopEvent = glut.glutMainLoopEvent
+ else:
+ raise RuntimeError,\
+ 'Your glut implementation does not allow interactive sessions. ' \
+ 'Consider installing freeglut.'
+
+ def inputhook_glut():
+ """ Process pending GLUT events only. """
+ # We need to protect against a user pressing Control-C when IPython is
+ # idle and this is running. We trap KeyboardInterrupt and pass.
+ try:
+ glutMainLoopEvent()
+ except KeyboardInterrupt:
fperez
fperez Aug 29, 2011 Owner

I see you're trapping it here, but I still get a traceback from the crash handler if I hit Ctrl-C. Do you have any idea why? Does it work ok for you? I'm on linux...

rougier
rougier Aug 29, 2011 Contributor

Same on OSX. I did not test that simple case and I'm investigating why I can't catch the KeyboardInterrupt. Is suspect that the keyboard interrupt is disturbing the glutMainLoopEvent for some reason and it do something weird. I also tried to catch any other exception but still get the traceback from the crash handler.

rougier
rougier Aug 29, 2011 Contributor

I found this thread that seems to explain the situation and provide a solution but I'm unable to translate it for my case (lack some comments in the code):
http://osdir.com/ml/python.ctypes/2006-10/msg00001.html

Asking for help if someone is able to decrypt the code...

rougier
rougier Aug 29, 2011 Contributor

Using the following code before the glutMainLoopEvent, I'm able to catch the SIGINT but it'll bring more problems I guess:

import signal
def handler(signum, frame): return 0
signal.signal(signal.SIGINT, handler)

@fperez fperez and 1 other commented on an outdated diff Aug 29, 2011
IPython/lib/inputhook.py
+ integration within IPython since original GLUT does not allow to handle
+ events one by one. Instead, it requires for the mainloop to be entered
+ and never returned (there is not even a function to exit he
+ mainloop). Fortunately, there are alternatives such as freeglut
+ (available for linux and windows) and the OSX implementation gives
+ access to a glutCheckLoop() function that blocks itself until a new
+ event is received. This means we have to setup a default timer to
+ ensure we got at least one event that will unblock the function. We set
+ a default timer of 60fps.
+
+ Furthermore, it is not possible to install these handlers without a
+ window being first created. We choose to make this window invisible and
+ the user is supposed to make it visible when needed (see gui-glut.py in
+ the docs/examples/lib directory). This means that display mode options
+ are set at this level and user won't be able to change them later
+ without modifying the code. This should probably be made available via
fperez
fperez Aug 29, 2011 Owner

Since this is a user-facing docstring and the comment about making it an option is more of a note/discussion for developers, that sentence should be removed from the docstring (it's indicated below in the code in any case, for the developers).

rougier
rougier Aug 29, 2011 Contributor

I've reorganized into docstrings and comments.

@fperez fperez and 1 other commented on an outdated diff Aug 29, 2011
IPython/lib/inputhook.py
+ """ Process pending GLUT events only. """
+ # We need to protect against a user pressing Control-C when IPython is
+ # idle and this is running. We trap KeyboardInterrupt and pass.
+ try:
+ glutMainLoopEvent()
+ except KeyboardInterrupt:
+ pass
+ return 0
+
+ # Frame per second : 60
+ # Should be probably an IPython option
+ fps = 60
+ if not self._apps.has_key(GUI_GLUT):
+ glut.glutInit(sys.argv)
+
+ # Display mode shoudl be also an Ipython option since user won't be able
fperez
fperez Aug 29, 2011 Owner

typo: shoudl -> should

fperez
fperez Aug 29, 2011 Owner

@minrk, what are your thoughts on hooking up these gl/glut options into the config system? Also, since you have more experience with GL in general than I do, your thoughts on this PR would be welcome.

rougier
rougier Aug 29, 2011 Contributor

The display mode is quite important for people working with OpenGL. Basically it tells OpenGL what kind of buffers are needed (color buffer, depth buffer, double buffer, stencil buyer, etc.). I provided reasonable default values but user might want to be able to specify them in the python configuration.

Concerning fps, it is bit more tricky since it is also a quite common setting for OpenGL developers but the actual value is not really free to set since it will directly impact console responsiveness. For example if you set it to 4, it means glutMainLoopEvent will sleep for 250ms, hence making the console quite unusable. 60fps is quite standard and makes both things smooth on screen and make console quite responsive.

For options, I do not know yet very well the internal system but I will read the doc.

Owner
minrk commented Aug 29, 2011

@fperez, Sure, anything that's likely to have multiple options should be configurable. I don't think there's any inputhook configuration, so we really have two options:

  1. Configurable per-eventloop
  2. Single Configurable for the InputHookManager, that handles options

While 2. is more extensible/O-O friendly, I think 1. would probably be cleaner in the long run.
We already need to make the timers in the Wx backend configurable as well (see #96).

Owner
fperez commented Sep 12, 2011

@rougier, I tried testing it by running the gui-glut.py example script, but the moment I close the GUI window, ipython crashes completely and leaves the terminal in a broken state that doesn't echo any characters typed. I can restore the terminal by typing reset<ENTER> blind, but this isn't a very good long-term solution. Does it work on your side of things normally?

Basically we want to integrate these GUI modes if they provide users the ability to repeatedly run a GUI script while maintaining an interactive shell working. But if they only allow for a script to execute once ever and everything crashes after that, it doesn't seem too useful. What do you think?

Contributor
rougier commented Sep 13, 2011

Argghh… Same here on a virtual linux env. I tested it on my mac where I was not able to close the window and did not see the problem.
Things are getting a bit more complicated than expected and I need to find some proper way to do things for regular glut. One option would be to stick to the freeglut implementation and to abandon compatibility with the regular glut because it is really a mess to make things to work properly.

On Sep 12, 2011, at 23:44 , Fernando Perez wrote:

@rougier, I tried testing it by running the gui-glut.py example script, but the moment I close the GUI window, ipython crashes completely and leaves the terminal in a broken state that doesn't echo any characters typed. I can restore the terminal by typing reset<ENTER> blind, but this isn't a very good long-term solution. Does it work on your side of things normally?

Basically we want to integrate these GUI modes if they provide users the ability to repeatedly run a GUI script while maintaining an interactive shell working. But if they only allow for a script to execute once ever and everything crashes after that, it doesn't seem too useful. What do you think?

Reply to this email directly or view it on GitHub:
#742 (comment)

Owner
fperez commented Sep 13, 2011

I know very little about this, but given what you've told me, I'd suggest you go for the freeglut-only route at this point. It's better to have something robust and easy to implement that works, even if it works with some restrictions, than to try to make something very general that's impossible to maintain later on.

Once this is out, if there's a user out there for whom the freeglut restriction is a problem, then it's their job to improve the code towards full glut support. But that shouldn't be your problem for now :)

In general, when in doubt, go for the simpler solution. It's almost always the right one :)

Contributor
rougier commented Sep 13, 2011

I think I might have an almost working version (to be tested). I would only need a way to print the last ipython prompt because I have to print 'KeyboardInterrupt' by hand and I then need to reprint the prompt.

On Sep 13, 2011, at 21:41 , Fernando Perez wrote:

I know very little about this, but given what you've told me, I'd suggest you go for the freeglut-only route at this point. It's better to have something robust and easy to implement that works, even if it works with some restrictions, than to try to make something very general that's impossible to maintain later on.

Once this is out, if there's a user out there for whom the freeglut restriction is a problem, then it's their job to improve the code towards full glut support. But that shouldn't be your problem for now :)

In general, when in doubt, go for the simpler solution. It's almost always the right one :)

Reply to this email directly or view it on GitHub:
#742 (comment)

Owner
fperez commented Sep 13, 2011

I just replied on list a second ago. short story: don't worry, just print 'KeyboardInterrupt' and let the user hit 'enter' to get a new prompt.

By the way, I just noticed that right now this doesn't merge cleanly anymore, there are conflicts. You may want to rebase it on top of master (and just do a push --force) so it can be merged.

Contributor
rougier commented Sep 13, 2011

I've been trying to "rebase" my branch on master but it's sort of a nightmare.

First I did not understood that "rebase" was a git command and tried to 'pull' from my master repository but get into a lot of trouble and switch back to the directory I did just before. Then I tried 'git rebase master' from my glut branch but some code disappeared (compared to my file before the rebase) in the conflicted file 'inputook.py'.

Now I'm bit lost because I'm note quite sure of what I did.

Nicolas

On Sep 13, 2011, at 22:15 , Fernando Perez wrote:

I just replied on list a second ago. short story: don't worry, just print 'KeyboardInterrupt' and let the user hit 'enter' to get a new prompt.

By the way, I just noticed that right now this doesn't merge cleanly anymore, there are conflicts. You may want to rebase it on top of master (and just do a push --force) so it can be merged.

Reply to this email directly or view it on GitHub:
#742 (comment)

rougier added some commits Aug 26, 2011
@rougier @fperez rougier Added code for the GLUT interactive session f4b8b67
@rougier @fperez rougier Event loop integration example 0afe6a7
@rougier @fperez rougier Canceled window reshape to 1x1 since the idea is now for the user to …
…use this window as the main one because of weird seg-faults problem after user creates its own window (any subsequent gl error would lead to a segfault, even a simple one line requiring a non existent function
c92f130
@rougier @fperez rougier Fixed typos in comments eb76eab
@rougier @fperez rougier Replaced deprecated raise call 81308e3
Contributor
rougier commented Sep 14, 2011

Finally managed to rebase (I did not understood that conflicts were to be resolved "several times" on the same file").
I pushed (--force) changed on the glut branch and it should be ready for merge.

Thanks for your patience...

Nicolas

On Sep 13, 2011, at 22:15 , Fernando Perez wrote:

I just replied on list a second ago. short story: don't worry, just print 'KeyboardInterrupt' and let the user hit 'enter' to get a new prompt.

By the way, I just noticed that right now this doesn't merge cleanly anymore, there are conflicts. You may want to rebase it on top of master (and just do a push --force) so it can be merged.

Reply to this email directly or view it on GitHub:
#742 (comment)

Owner
fperez commented Sep 14, 2011

Hi Nicolas,

I'm really sorry you're having trouble! As it turns out, this really was a fairly tricky rebase/merge to do, because it was going to inevitably lead to conflicts, since the pyglet code and the glut one were pretty much in the same place.

So I went ahead and manually, carefully rebased the whole thing and cleared all the conflicts, ensuring that there's a glut branch that now sits cleanly on top of master (so it has the pyglet code in it). You can get it here:

https://github.com/fperez/ipython/tree/glut-rebased

This has the last changes you had pushed to github from your glut branch, but all rebased to apply correctly on top of master, with all conflicts against the pyglet code fixed.

So I suggest you grab my rebased branch above and start working from this one, if you had any additional local changes.

By the way, a very useful thing to know about git, when you get into trouble, is the reflog command. This is a history of everything you've done in a git repo, for example in my ipython repo:

0c6df48 HEAD@{0}: checkout: moving from rougier-glut to glut-rebased
80f77d9 HEAD@{1}: checkout: moving from glut-rebased to rougier-glut
0c6df48 HEAD@{2}: rebase: Added the command line option
02ff6fe HEAD@{3}: rebase: Fix code in disable_glut which was not tested and quite buggy
cf4c326 HEAD@{4}: rebase: Tried to fix the CTRL-C problem (https://github.com/ipython/ipython/pull/742) and take other comments/typos into account
81308e3 HEAD@{5}: rebase: Replaced deprecated raise call
eb76eab HEAD@{6}: rebase: Fixed typos in comments
etc...

If you realize that any of those points was the one you wanted to be at, you can always manually go to it. Let's say that 02ff6fe was a 'safe' point and that you want to undo things after that. You can:

git checkout 02ff6fe
git branch "new branch name here"

The first command puts you in that point in the history, and the second makes it a named branch so you can start working again.

Sorry if this one turned out to be a little complicated, unfortunately the pyglet and glut changes were in the same parts of a file and they caused a conflict... But I'm willing to help you until we sort things out, so just let me know how it goes and I'm sure we'll be able to finish it.

Once you're OK again, we'll resume review. There is enough complexity in the glut code that I'd like to break some of that into a separate file rather than having so many nested function definitions, which make the code very hard to read and test.

Owner
fperez commented Sep 14, 2011

Ah!! I did all that yesterday night to try to help you, but once I finished my internet connection died, and I wasn't able to send it until this morning. Which means you ended up repeating the same work :)

Oh well, good learning experience nonetheless!

By the way, it seems you changed the original branch name, so now github is showing us a diff against the wrong branch. I think the simplest solution will be to open a new pull request, so that we start with a clean slate for review. Can you do that? Just open a fresh pull request with your currently clean branch, and we'll take it from there. I can add a link back to this discussion to make it easy to find previous parts of the conversation.

Sorry this one turned out to be so tricky... Thanks for your patience!

Contributor
rougier commented Sep 14, 2011

Ah too bad. My fault. I'm really sorry for all the extra work I'm giving you.

I just removed my ipython repository on github and clone yours to start from a clean state (I guess there should exist better ways but I think you may have lost too much time helping me).

I'm trying to refactor things as you suggested so code will be cleaner hopfully. I'm adding a glut_support.py file to factorize code in the IPython/lib/ directory.

I will make a new pull request once things are working properly and contact you in case of a problem. Well, at least I'm learning a lot and I will try to extend documentation on the workflow for git dummies like me.

Nicolas

On Sep 14, 2011, at 21:05 , Fernando Perez wrote:

Ah!! I did all that yesterday night to try to help you, but once I finished my internet connection died, and I wasn't able to send it until this morning. Which means you ended up repeating the same work :)

Oh well, good learning experience nonetheless!

By the way, it seems you changed the original branch name, so now github is showing us a diff against the wrong branch. I think the simplest solution will be to open a new pull request, so that we start with a clean slate for review. Can you do that? Just open a fresh pull request with your currently clean branch, and we'll take it from there. I can add a link back to this discussion to make it easy to find previous parts of the conversation.

Sorry this one turned out to be so tricky... Thanks for your patience!

Reply to this email directly or view it on GitHub:
#742 (comment)

Owner
fperez commented Sep 14, 2011

Quite the opposite, it's my fault for not giving you clearer instructions at the start! In any case, thanks for being patient, and we'll work together through it, don't worry :)

One more thing I should have told you that I didn't: when I said to pull from my branch, I meant that you could grab my branch, while keeping your fork off the official one. In general, it's not a good idea to fork off personal repos that may or may not be normally updated. For example, I don't update my master branch regularly at all, since I only use my repo for development of new branches, and when I want the official branch I just follow the ipython/ipython repo.

So what I meant was that you could keep your fork like you had it, and you could have just pulled that one branch from me with

git pull origin master  # assuming 'origin' is the name you have for the official one, if not adjust
git checkout -b glut
git reset --hard master
git pull git://github.com/fperez/ipython.git glut-rebased
git push rougier glut  # assuming 'rougier' is the name you have for your fork, if not adjust

That would have given you a copy of my branch as your new starting point.

If you want to update to this, I'm happy to help you. Let me know if you'd like a bit of help via skype or on IRC and I'm happy to do so.

Contributor
rougier commented Sep 14, 2011

I think the problem is that I do not master git at all. I was quite sure there as a way to "grab your branch" but I needed to translate into a git command and here came problems...

I will switch back to the main ipython branch once we get this glut things integrated.

I just push the refactoring code: rougier@560fff6 and when I tried the pull request, it told me there was more than 1000 changes. So I guess this what your explain with you repo not being updated…

Can you find a way to merge only this change ? After that I think things will be ok.

Thanks again for the help and I hope things will get smother for pygame (planning to add it).

Nicolas

On Sep 14, 2011, at 21:22 , Fernando Perez wrote:

Quite the opposite, it's my fault for not giving you clearer instructions at the start! In any case, thanks for being patient, and we'll work together through it, don't worry :)

One more thing I should have told you that I didn't: when I said to pull from my branch, I meant that you could grab my branch, while keeping your fork off the official one. In general, it's not a good idea to fork off personal repos that may or may not be normally updated. For example, I don't update my master branch regularly at all, since I only use my repo for development of new branches, and when I want the official branch I just follow the ipython/ipython repo.

So what I meant was that you could keep your fork like you had it, and you could have just pulled that one branch from me with

git pull origin master  # assuming 'origin' is the name you have for the official one, if not adjust
git checkout -b glut
git reset --hard master
git pull git://github.com/fperez/ipython.git glut-rebased
git push rougier glut  # assuming 'rougier' is the name you have for your fork, if not adjust

That would have given you a copy of my branch as your new starting point.

If you want to update to this, I'm happy to help you. Let me know if you'd like a bit of help via skype or on IRC and I'm happy to do so.

Reply to this email directly or view it on GitHub:
#742 (comment)

Owner
fperez commented Sep 14, 2011

On Wed, Sep 14, 2011 at 12:31 PM, Nicolas Rougier
reply@reply.github.com
wrote:

I just push the refactoring code: rougier@560fff6 and when I tried the pull request, it told me there was more than 1000 changes. So I guess this what your explain with you repo not being updated…

See my comment inline, there's an error in the code as it is right now...

rougier added some commits Sep 15, 2011
@rougier rougier Merge branch 'glut-rebased' of git://github.com/fperez/ipython into glut
* 'glut-rebased' of git://github.com/fperez/ipython:
  Added the command line option
  Fix code in disable_glut which was not tested and quite buggy
  Tried to fix the CTRL-C problem (ipython#742) and take other comments/typos into account
  Replaced deprecated raise call
  Fixed typos in comments
  Canceled window reshape to 1x1 since the idea is now for the user to use this window as the main one because of weird seg-faults problem after user creates its own window (any subsequent gl error would lead to a segfault, even a simple one line requiring a non existent function
  Event loop integration example
  Added code for the GLUT interactive session
89161a5
@rougier rougier Factorized glut code into glut_support.py e095f42
Contributor
rougier commented Sep 15, 2011

I Did not find the error you're talking about. Where is the comment exactly ?

Owner
fperez commented Sep 16, 2011

Mmh, actually I have no idea! Sorry, I can't find the comment either and I don't remember what I was referring to...

But anyway: right now there's still the problem that if I close the glut window, it crashes ipython immediately and leaves the terminal 'wedged', so that you have to type reset blind (no echo) to restore it to a functional state.

Do you have a way to fix that problem? Or do you not get it on your box? I'm seeing it on an ubuntu 10.10 machine...

@rougier rougier Removed the timer callback in favor of the idle one and re-use wx wai…
…ting time after an event is processed. This make things more reactive. Also, the created window is now made insivisible and is not supposed to be ever show or detroyed. Finally, fixed the bug in window closing for linux platform using the glutSetOption available on Freeglut.
c675614
Contributor
rougier commented Sep 16, 2011

I think I fixed the problem (works now on osx and also on a virtualized ubuntu (was not working before)). I made some conceptual changes and hopefully it should run better and should be more responsive.

On Sep 16, 2011, at 2:01 , Fernando Perez wrote:

Mmh, actually I have no idea! Sorry, I can't find the comment either and I don't remember what I was referring to...

But anyway: right now there's still the problem that if I close the glut window, it crashes ipython immediately and leaves the terminal 'wedged', so that you have to type reset blind (no echo) to restore it to a functional state.

Do you have a way to fix that problem? Or do you not get it on your box? I'm seeing it on an ubuntu 10.10 machine...

Reply to this email directly or view it on GitHub:
#742 (comment)

Owner
fperez commented Sep 16, 2011

Ah, I found the error I was talking about earlier! I don't know why it disappeared from the comments, probably got lost in the rebase confusion.

In any case, if you now try to run ipython with --gui glut, you get these error messages:

/home/fperez/usr/lib/python2.6/site-packages/IPython/lib/inputhook.py:289: SyntaxWarning: import * only allowed at module level
  def enable_glut(self, app=None):
/home/fperez/usr/lib/python2.6/site-packages/IPython/lib/inputhook.py:339: SyntaxWarning: import * only allowed at module level
  def disable_glut(self):

the reason is that you are never allowed to say from x import * inside a function. The import * idiom is only allowed at the module level. In a function, you can only use from x import a, b, c.

I suggest that you always test your changes both with --gui glut and with %gui glut, to catch these issues.

But we're almost there :) The crash is indeed gone, and the code looks much cleaner. So once you fix the above little problem by importing specifically the functions you need, or using import x; x.a() inside your functions, I'll be able to merge.

Thanks for your patience in working through this, I know it's hard work but we need the code that goes in to be really clean and solid, as we'll need to maintain it for a long time to come... This is one of the pull requests with the highest number of comments we've had in a while, but in the end I'm sure it will be worth it :)

Contributor
rougier commented Sep 17, 2011

Thanks for the report. I've been testing the two cases and did not see that error on my machine.
Anyway, I made the proposed changes since it is definitely cleaner.

Nicolas

On Sep 16, 2011, at 21:11 , Fernando Perez wrote:

Ah, I found the error I was talking about earlier! I don't know why it disappeared from the comments, probably got lost in the rebase confusion.

In any case, if you now try to run ipython with --gui glut, you get these error messages:

/home/fperez/usr/lib/python2.6/site-packages/IPython/lib/inputhook.py:289: SyntaxWarning: import * only allowed at module level
 def enable_glut(self, app=None):
/home/fperez/usr/lib/python2.6/site-packages/IPython/lib/inputhook.py:339: SyntaxWarning: import * only allowed at module level
 def disable_glut(self):

the reason is that you are never allowed to say from x import * inside a function. The import * idiom is only allowed at the module level. In a function, you can only use from x import a, b, c.

I suggest that you always test your changes both with --gui glut and with %gui glut, to catch these issues.

But we're almost there :) The crash is indeed gone, and the code looks much cleaner. So once you fix the above little problem by importing specifically the functions you need, or using import x; x.a() inside your functions, I'll be able to merge.

Thanks for your patience in working through this, I know it's hard work but we need the code that goes in to be really clean and solid, as we'll need to maintain it for a long time to come... This is one of the pull requests with the highest number of comments we've had in a while, but in the end I'm sure it will be worth it :)

Reply to this email directly or view it on GitHub:
#742 (comment)

Owner
fperez commented Sep 19, 2011

In its final form it looks great, thanks a lot Nicolas! Merging now.

@fperez fperez merged commit 833bbcc into ipython:master Sep 19, 2011
@mattvonrocketstein mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014
@rougier @fperez rougier + fperez Tried to fix the CTRL-C problem (ipython#742) and take other comments…
…/typos into account
d9cd725
@mattvonrocketstein mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014
@rougier rougier Merge branch 'glut-rebased' of git://github.com/fperez/ipython into glut
* 'glut-rebased' of git://github.com/fperez/ipython:
  Added the command line option
  Fix code in disable_glut which was not tested and quite buggy
  Tried to fix the CTRL-C problem (ipython#742) and take other comments/typos into account
  Replaced deprecated raise call
  Fixed typos in comments
  Canceled window reshape to 1x1 since the idea is now for the user to use this window as the main one because of weird seg-faults problem after user creates its own window (any subsequent gl error would lead to a segfault, even a simple one line requiring a non existent function
  Event loop integration example
  Added code for the GLUT interactive session
c21461b
@minrk minrk pushed a commit to jupyter/qtconsole that referenced this pull request Apr 20, 2015
@rougier rougier Merge branch 'glut-rebased' of git://github.com/fperez/ipython into glut
* 'glut-rebased' of git://github.com/fperez/ipython:
  Added the command line option
  Fix code in disable_glut which was not tested and quite buggy
  Tried to fix the CTRL-C problem (ipython/ipython#742) and take other comments/typos into account
  Replaced deprecated raise call
  Fixed typos in comments
  Canceled window reshape to 1x1 since the idea is now for the user to use this window as the main one because of weird seg-faults problem after user creates its own window (any subsequent gl error would lead to a segfault, even a simple one line requiring a non existent function
  Event loop integration example
  Added code for the GLUT interactive session
80c3046
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment