1.2 beta release date/roadmap

[anatoly techtonik]

What is the current status of 1.2 branch?

Is there a roadmap with real action items that should be fixed for release?

[Nathan]

Tristam gave a good answer to that question a couple months ago:

https://groups.google.com/group/pyglet-users/msg/a73796cda1bf6fb7

I merged your AVbin patch from 4 months ago in today, by the way. I
wish I had more spare time to work on these projects.

~ Nathan

On Mon, May 14, 2012 at 2:41 AM, anatoly techtonik <tech...@gmail.com> wrote:
> What is the current status of 1.2 branch?
> Is there a roadmap with real action items that should be fixed for release?
>

> --
> You received this message because you are subscribed to the Google Groups
> "pyglet-users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/pyglet-users/-/8cssmZwsjT4J.
> To post to this group, send email to pyglet...@googlegroups.com.
> To unsubscribe from this group, send email to
> pyglet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pyglet-users?hl=en.

[Nathan]

Oh, I do have a roadmap for AVbin though. I would welcome help from
anyone on that:

http://avbin.github.com/AVbin/Roadmap.html

I'm lucky if I get a few minutes a day to work on it.

~ Nathan

[anatoly techtonik]

On Thu, May 24, 2012 at 6:29 AM, Nathan <nathan...@gmail.com> wrote:
> Oh, I do have a roadmap for AVbin though.  I would welcome help from
> anyone on that:
>
> http://avbin.github.com/AVbin/Roadmap.html
>
> I'm lucky if I get a few minutes a day to work on it.

Every day has a guaranteed 15 minutes to work on everything you need. =)
When you have the time, split each task into action items - high level
Roadmap is essential to realize how far is the final goal for release,
but everybody needs an item to evaluate if it is possible to spend
next 15 minutes to solve it.

The same is actual for pygame. Right now the problem is that there is
no dedicated project lead. Ok. If the reason is that there is nobody
to just wrap a package and upload to PyPI then that's not a problem.

So, what's the next problem that should be solved to get 1.2 out of the door?
Or should we also release 1.1.5?
--
anatoly t.

[anatoly techtonik]

s/pygame/pyglet/

[Rui Carmo]

Also, could there be some update on the website, along the lines of "hi, we're working on 1.2?"

Call me picky, but I don't think prospective contributors/users will come digging into the ML for more info...

R.

> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.

[Winston Wolff]

People have been mentioning that we should release 1.2 for a long time now. But it never happens, probably because nobody has the time. Can we make it less time consuming? By for example just releasing the current HG head as 1.2? It's gotta be better than 1.1.4 because 1.1.4 has so many troubles with 32/64 bit versions of python.

-Winston

[Tristam MacDonald]

On Tue, Jun 12, 2012 at 5:15 PM, Winston Wolff <winsto...@cal.berkeley.edu> wrote:

People have been mentioning that we should release 1.2 for a long time now. But it never happens, probably because nobody has the time. Can we make it less time consuming?

My understanding is that the time-consuming part is actually the silly things like building the double-clickable Windows installer. If we were to do a source-only release and tell people to use easy_install, making a release would be as simple as writing a readme and incrementing the version number...

The one downside here (apart from source installs sometimes scaring newbies) is that the graphical installer takes care of installing AVBin for you - could we bounce this responsibility to the AVBin project instead?

 

By for example just releasing the current HG head as 1.2? It's gotta be better than 1.1.4 because 1.1.4 has so many troubles with 32/64 bit versions of python.

Seconded. Preferably integrating the latest ctypes branch into main, so that we get proper Mac/Lion support at last.

--

Tristam MacDonald

http://swiftcoder.wordpress.com/

[Winston Wolff]

A source-only version sounds good to me. Installing AV-Bin manually is going to be easier than digging through all the mailing lists to figure out which branch of Pyglet I should use.

-Winston

[Steve]

Thirded.

Also, it's kind of hard (or unclear how) to fork the project and submit patches. While the web site is being updated, updates to the Contribute page would be nice. (Or a move off of Google Code for the canonical repo.)

[Richard Jones]

At the moment there is no formal process. You create an issue and
provide the patch / fork details there.

Google Code doesn't support automated pull requests like
bitbucket/github. I think that's a big failing and a reasonable
motivation to move to bitbucket, but that's probably just a
distraction from doing more productive things. It might also make the
website maintenance simpler too - at the moment I'm the only (active)
person with access to update the website. If it was hosted via
bitbucket with post-commit hooks then things would be simpler. Also,
we need to fix or replace epydoc as I cannot make it work - which is
why the website hasn't been updated in quite some time. I am still
trying but I suspect I'll be tossing it out and using Sphinx soon.

I believe the biggest hurdle in getting a 1.2 release out is that the
cocoa port needs to be merged into the default branch. Once that's
done I'd be happy to push out a source 1.2 release.


Richard

[Nathan]

On Tue, Jun 12, 2012 at 4:22 PM, Tristam MacDonald <swift...@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 5:15 PM, Winston Wolff
> <winsto...@cal.berkeley.edu> wrote:
>>
>> People have been mentioning that we should release 1.2 for a long time
>> now. But it never happens, probably because nobody has the time. Can we make
>> it less time consuming?
>
>
> My understanding is that the time-consuming part is actually the silly
> things like building the double-clickable Windows installer. If we were to
> do a source-only release and tell people to use easy_install, making a
> release would be as simple as writing a readme and incrementing the version
> number...
>
> The one downside here (apart from source installs sometimes scaring newbies)
> is that the graphical installer takes care of installing AVBin for you -
> could we bounce this responsibility to the AVBin project instead?

I'd love to in theory...but in practice I've never made a graphical
installer for _any_ operating system before, yet. I haven't even made
it to the point of trying to make a standalone graphical installer for
AVbin. I'm having trouble finding people to test AVbin releases on
different OS's and let me know if they work at all, so even if I got
an installer including AVbin working, I'm not sure if the installed
product would work. If I could just quit my day job and spend more
time on this stuff... ;-)

I did actually spend some time this week attempting to find some free,
high quality "raw" video files that I could use to generate test video
files. I found some in YUV4MPEG format here
http://media.xiph.org/video/derf/ -- but I can't figure out how to get
that raw format into something readable by Final Cut Pro X or
Quicktime. I should probably stop trying to find the perfect solution
and just convert a short home video clip into the different formats.

>> By for example just releasing the current HG head as 1.2? It's gotta be
>> better than 1.1.4 because 1.1.4 has so many troubles with 32/64 bit versions
>> of python.
>
>
> Seconded. Preferably integrating the latest ctypes branch into main, so that
> we get proper Mac/Lion support at last.

Thirded, especially the Mac/Lion part, since that's my setup too.

~ Nathan

[anatoly techtonik]

So, what are the action items [ ] and stumbling blocks (s)?

---Pri-1---
[ ] update web site
[ ] fix epydoc
[ ] add an issue to tracker
[ ] move web site to Bitbucket
[ ] create group 'pyglet'
[ ] add repository pyglet.bitbucket.org
(see https://confluence.atlassian.com/display/BITBUCKET/Publishing+a+Website+on+bitbucket)
[ ] add CNAME for pyglet.org to pyglet.bitbucket.org
(I am not sure, but it should work)
[ ] mention 1.2
[ ] direct link to Google Code from top menu
[ ] update Contribute to be clear
[ ] send patches
[ ] site in repository is broken
http://code.google.com/p/pyglet/source/browse/#hg%2Fwebsite
[ ] write instructions / fix it to work from checkout
(s) Richard needs time

[ ] merge cocoa port

[ ] write README
(s) how is pyglet 1.2 different from 1.1?
[ ] support 64bit Python
[ ] write ANNOUNCEMENT
(s) what's new?

---Pri-2---
[ ] update wiki pages
[ ] draw a line on http://code.google.com/p/pyglet/wiki/ReleaseSchedule
[ ] integrate patches
(s) Richard

[ ] update issue tracker
[ ] add website label to issue tracker
[ ] allow users to assign labels when creating new issues
[ ] add 1.2 milestone
(s) Richard

---Pri-3---
[ ] build a windows installer
[ ] try
[ ] list problems


So, who can help with any of the stuff above?
Is there anything is missing?
Is there anybody besides Richard with an access to wiki?
Or we can use http://wiki.python.org/moin/Pyglet, because:
1. it is free-for-all
2. you can subscribe to pages to be notified about changes

Yes/No?
--
anatoly t.

[Jonathan Hartley]

I don't have any experience with epydoc but I'm sitting here with the source tree in front of me right now, I'll have a look just in case I can help. Am I right that the issue is that generating API docs doesn't currently work? I'll report any progress or problems on a new thread.

      Jonathan


On Wednesday, June 13, 2012 8:27:07 AM UTC+1, anatoly techtonik wrote:

[Andreas Schiefer]

On Wed, Jun 13, 2012 at 3:19 AM, Richard Jones <r1char...@gmail.com> wrote:
> Also,
> we need to fix or replace epydoc as I cannot make it work - which is
> why the website hasn't been updated in quite some time. I am still
> trying but I suspect I'll be tossing it out and using Sphinx soon.

Someone already worked in that direction, see
https://groups.google.com/d/msg/pyglet-users/CPJ_MQeRycU/deYGMNp-km8J

I don't now the current state of it, but it looks like most things
already work (except events?).

[Jonathan Hartley]

On Wednesday, June 13, 2012 9:26:06 AM UTC+1, Andreas Schiefer wrote:

On Wed, Jun 13, 2012 at 3:19 AM, Richard Jones  wrote:
> Also,
> we need to fix or replace epydoc as I cannot make it work - which is
> why the website hasn't been updated in quite some time. I am still
> trying but I suspect I'll be tossing it out and using Sphinx soon.

Someone already worked in that direction, see
https://groups.google.com/d/msg/pyglet-users/CPJ_MQeRycU/deYGMNp-km8J

I don't now the current state of it, but it looks like most things
already work (except events?).

Acknowledged, thanks. I'll see if I can tidy up any loose ends there.

[Rui Carmo]

I'm volunteering for testing (default environment is Lion, but I have a stock Ubuntu 12 - with Unity, alas - I can test the examples).

On Jun 13, 2012, at 08:27 , anatoly techtonik wrote:

(cropped for legibility)

[Winston Wolff]

I can help with any of these items. I can probably spend one full day on it on Friday.

-ww

[Richard Jones]

On 14 June 2012 02:13, Winston Wolff <winsto...@cal.berkeley.edu> wrote:
> I can help with any of these items. I can probably spend one full day on it on Friday.

At the moment running tests is a really good thing to do so we know
what's broken before the 1.2 release. Additionally figuring out a
patch if you run into any brokenness would be nice :-)


Richard

[Nathan]

Since it seems like a Pyglet 1.2 release is gaining momentum, I'll
spend some time trying to get AVbin cleaned up. Who knows, maybe
we'll be able to put together working bundled graphical installers.

I updated the AVbin roadmap and converted it into a set of milestones
and issues on Github:

http://avbin.github.com/AVbin/Roadmap.html
https://github.com/AVbin/AVbin/issues/milestones

~ Nathan

[Winston Wolff]

Friday is my "20% day" so I'm going to do some stuff to help release Pyglet.

I'm taking Anatoly's to-do list and posting it on this wiki page as a central coordinating point. Anybody who wants to do an item, put your name next to it. When it's done, put a DONE next to it.

http://wiki.python.org/moin/Pyglet

-Winston

On Jun 13, 2012, at 12:27 AM, anatoly techtonik wrote:

[Winston Wolff]

wiki.python.org/moin is too slow. It takes 10 seconds each time I want to save my page. Can someone give me permission for editing http://code.google.com/p/pyglet/wiki and I can put stuff there?

I'm going to post:
- a To Do list so we can coordinate who is doing what
- A list of configurations to be tested, with how has tested them and the outcomes.

[Winston Wolff]

Do you mean this port:
http://code.google.com/r/evilphillip-cocoa-ctypes2/
or this port:
http://code.google.com/p/cocoa-python/

It seems like they are the same, and that the evilphillips one is a clone of Pyglet so it might be easier to merge. I'll start working on that now.

-Winston

[Winston Wolff]

Oh, I see, cocoa-python is the PyObjC replacement that evilphillip-cocoa-ctypes2 uses.

[Winston Wolff]

Here is a testing report. I didn't get all the way through the tests--whew the windows section is very long and time consuming. I'd say the problems are not show stoppers however--I think we should still do a release candidate for example. Maybe a 1.2rc1 release will get some attention and some folks can contribute patches.

----------------

Testing report for http://code.google.com/r/evilphillip-cocoa-ctypes2/
Commit hash: 3bc7a0f501e9

Capabilities are: GENERIC, OSX
OSX v 10.7.4
sys.platform = darwin
Python: Framework build 2.7.2 at /Library/Frameworks/Python.framework/Versions/2.7/bin/python

app.EVENT_LOOP - File "tests/../tests/app/EVENT_LOOP.py", line 37, in f
AssertionError: 1.9151411056518555 != 1 within 2 places
window.WINDOW_ACTIVATE -- fail - window does not activate until I click on another app and then on icon
window.WINDOW_SET_VISIBLE - fail - does not disappear when it should
window.WINDOW_MINIMIZE_MAXIMIZE - fail -- when maximised, it's filled with a mangled version of my screen.
window.MULTIPLE_SCREEN - I have two monitors but both times the main monitor was used, and it was all black, not a color.
window.EVENT_MOUSE_MOTION - relative Y motion is wrong direction. The origin is lower-left so I expect moving to right would give relative +1, 0 motion, and up would give 0, +1 motion. Instead right is correct but up is 0,-1
image.MATRIX_RGB -- GL_ARB_imaging is not present, skipping test.
image.MATRIX_RGBA -- GL_ARB_imaging is not present, skipping test.
font.WRAP_INVARIANT -- doesn't show anything.
media.* -- Heard nothing in the media section


On Jun 14, 2012, at 6:06 PM, Tom Ray wrote:

> There are already graphical installers for pyglet 1.2 and avbin 8 here:
> http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml2

>
> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/IC1sFvs3me8J.

[Winston Wolff]

Here is a testing report. I didn't get all the way through the tests--whew the windows section is very long and time consuming. I'd say the problems are not show stoppers however--I think we should still do a release candidate for example. Maybe a 1.2rc1 release will get some attention and some folks can contribute patches.

-Winston

[Winston Wolff]

FYI, I'm trying a merge of evilphillip-cocoa-ctypes2 into pyglet. There are 16 files updated and three files with conflicts:
- pyglet/app/cocoa.py
- pyglet/image/codecs/quartz.py
- pyglet/window/cocoa/__init__.py

They don't look too bad but I think it would be better if someone more familiar with the code tried to fix it. Below are snippets to give you an idea of what we're up against.

================
pyglet/app/cocoa.py
================

class CocoaEventLoop(PlatformEventLoop):

def __init__(self):
super(CocoaEventLoop, self).__init__()
# Prepare the default application.
self.NSApp = NSApplication.sharedApplication()
# Create an autorelease pool for menu creation and finishLaunching
<<<<<<< local
pool = NSAutoreleasePool.alloc().init()
self._create_application_menu()
NSApp().setActivationPolicy_(0) # Mac OS X 10.6
NSApp().finishLaunching()
NSApp().activateIgnoringOtherApps_(True)
# Then get rid of the pool when we're done.
del pool

def _create_application_menu(self):
# Sets up a menu and installs a "quit" item so that we can use
# Command-Q to exit the application.
# See http://cocoawithlove.com/2010/09/minimalist-cocoa-programming.html
# This could also be done much more easily with a NIB.
menubar = NSMenu.alloc().init()
appMenuItem = NSMenuItem.alloc().init()
menubar.addItem_(appMenuItem)
NSApp().setMainMenu_(menubar)
appMenu = NSMenu.alloc().init()
processName = NSProcessInfo.processInfo().processName()
hideItem = NSMenuItem.alloc().initWithTitle_action_keyEquivalent_(
"Hide " + processName, "hide:", "h")
appMenu.addItem_(hideItem)
appMenu.addItem_(NSMenuItem.separatorItem())
quitItem = NSMenuItem.alloc().initWithTitle_action_keyEquivalent_(
"Quit " + processName, "terminate:", "q")
appMenu.addItem_(quitItem)
appMenuItem.setSubmenu_(appMenu)
=======
self.pool = NSAutoreleasePool.alloc().init()
create_menu()
self.NSApp.setActivationPolicy_(NSApplicationActivationPolicyRegular)
self.NSApp.finishLaunching()
self.NSApp.activateIgnoringOtherApps_(True)
>>>>>>> other



=====================
pyglet/image/codecs/quartz.py
========================

class QuartzImageDecoder(ImageDecoder):
def get_file_extensions(self):
# Quartz can actually decode many more formats, but these are the most common.
return [ '.bmp', '.cur', '.gif', '.ico', '.jp2', '.jpg', '.jpeg',
'.pcx', '.png', '.tga', '.tif', '.tiff', '.xbm', '.xpm' ]

def get_animation_file_extensions(self):
return ['.gif']

def _get_pyglet_ImageData_from_source_at_index(self, sourceRef, index):
<<<<<<< local
imageRef = Quartz.CGImageSourceCreateImageAtIndex(sourceRef, index, None)

=======
imageRef = c_void_p(quartz.CGImageSourceCreateImageAtIndex(sourceRef, index, None))

>>>>>>> other
# Regardless of the internal format of the image (L, LA, RGB, RGBA, etc)
# we just automatically convert everything to an RGBA format.
format = 'RGBA'
<<<<<<< local
rgbColorSpace = Quartz.CGColorSpaceCreateDeviceRGB()
=======
rgbColorSpace = c_void_p(quartz.CGColorSpaceCreateDeviceRGB())
>>>>>>> other
bitsPerComponent = 8
<<<<<<< local
width = Quartz.CGImageGetWidth(imageRef)
height = Quartz.CGImageGetHeight(imageRef)
=======
width = quartz.CGImageGetWidth(imageRef)
height = quartz.CGImageGetHeight(imageRef)
>>>>>>> other
bytesPerRow = 4 * width

# Create a buffer to store the RGBA formatted data.
bufferSize = height * bytesPerRow
buffer = (c_byte * bufferSize)()

# Create a bitmap context for the RGBA formatted data.
<<<<<<< local
bitmap = Quartz.CGBitmapContextCreate(buffer,
width, height,
bitsPerComponent,
bytesPerRow,
rgbColorSpace,
Quartz.kCGImageAlphaPremultipliedLast)

=======
# Note that premultiplied alpha is required:
# http://developer.apple.com/library/mac/#qa/qa1037/_index.html
bitmap = c_void_p(quartz.CGBitmapContextCreate(buffer,
width, height,
bitsPerComponent,
bytesPerRow,
rgbColorSpace,
kCGImageAlphaPremultipliedLast))

>>>>>>> other
# Write the image data into the bitmap.
<<<<<<< local
Quartz.CGContextDrawImage(bitmap, Quartz.CGRectMake(0,0,width, height), imageRef)

del bitmap, imageRef, rgbColorSpace
=======
quartz.CGContextDrawImage(bitmap, NSMakeRect(0,0,width,height), imageRef)

quartz.CGImageRelease(imageRef)
quartz.CGContextRelease(bitmap)
quartz.CGColorSpaceRelease(rgbColorSpace)
>>>>>>> other

pitch = bytesPerRow
return ImageData(width, height, format, buffer, -pitch)

[Winston Wolff]

After working on this for a day, here is my idea of what needs to be done

= Pyglet 1.2 Release To Do =

== High priority ==
* merge cocoa port, i.e. hg+https://code.google.com/r/evilphillip-cocoa-ctypes2/

* Create a release checklist so anyone can help. E.g.
* See if we have test coverage on major platforms and it passes. Ask for testers if needed.
* Write readme
* Create the packages - .zip/tgz? .dmg/msi? easy_install/pip?
* submit the packages to pypi? or publish on website?
* update website with new docs.

* Release 1.2_RC_1 -- no need to get it perfect before releasing.

* write README (s) how is pyglet 1.2 different from 1.1?
* support 64bit Python
* write ANNOUNCEMENT (s) what's new?

* Get docs working, either epydoc or switch to Sphinx
* fix epydoc
* add an issue to tracker

* Release 1.2_RC_2

* There are some patches in the issue tracker that seem worthwhile such as
http://code.google.com/p/pyglet/issues/detail?id=482

* More releases...


== Medium Priority ==
* Make it easier for people to submit unit-test results on different platforms so that we have more confidence that changes are good.
* Page describing testing process -- e.g. it can take an hour
* Have a place to submit testing results and have it summarized, e.g. tests passed, tests failed, what platform, python version, commit #
* Let people see what areas have been tested and what areas need testing.
* Let people test just a section of the test plan (the whole thing can take an hour) and submit it.
* Make output of test runner easier to use, i.e. easy to send to us and easy to summarize.

* update web site
* move web site to Bitbucket
* create group 'pyglet'
* add repository pyglet.bitbucket.org (see https://confluence.atlassian.com/display/BITBUCKET/Publishing+a+Website+on+bitbucket)
* add CNAME for pyglet.org to pyglet.bitbucket.org (I am not sure, but it should work)
* mention 1.2
* direct link to Google Code from top menu
* update Contribute to be clear
* send patches
* site in repository is broken http://code.google.com/p/pyglet/source/browse/#hg%2Fwebsite
* write instructions / fix it to work from checkout. (s) Richard needs time

* update wiki pages
* draw a line on http://code.google.com/p/pyglet/wiki/ReleaseSchedule
* integrate patches (s) Richard

* update issue tracker
* add website label to issue tracker
* allow users to assign labels when creating new issues
* add 1.2 milestone (s) Richard

== Low Priority ==
* build a windows installer

[Rui Carmo]

The I have only glanced at evilphilip's stuff once out of curiosity, but c_void_p appears to be a straightforward wrapper, and the initial diff is mostly about setting up the app menu (which I think should be kept or toggled as a preference, since well-behaved Cocoa apps take the trouble to put up something on the menu bar).

The third bit (quartz) appears to be merely added cleanups. My Quartz is a little rusty, but those feel like they ought to be required.

R.

> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.

[Rui Carmo]

On Jun 16, 2012, at 24:06 , Winston Wolff wrote:

   * Create the packages - .zip/tgz? .dmg/msi? easy_install/pip? 

.zip ought to cover everybody, I think. 

One question, though. Why bitbucket and not github? (I'm partial on this because I use Github a lot and find their forking/pull request mechanism astounding for handling patches and contributions, but... I'm just curious).

R.

[Petr Viktorin]

I assume the reason is that Pyglet is in a Mercurial repository.
Github only does Git.

[Richard Jones]

On 16 June 2012 09:10, Rui Carmo <rui....@gmail.com> wrote:
> On Jun 16, 2012, at 24:06 , Winston Wolff wrote:
>
>    * Create the packages - .zip/tgz? .dmg/msi? easy_install/pip?
>
>
> .zip ought to cover everybody, I think.

It's easy enough to generate tgz for the Unix users who prefer those tools.

> One question, though. Why bitbucket and not github? (I'm partial on this
> because I use Github a lot and find their forking/pull request mechanism
> astounding for handling patches and contributions, but... I'm just curious).

Bitbucket and github are pretty much on feature parity in that regard,
and the pyglet repos is in Mercurial (and that is not up for debate,
so don't even start.)


Richard

[Richard Jones]

Thanks for your efforts and welcome to the project!

I've added your roadmap update to the project wiki:
http://code.google.com/p/pyglet/wiki/RoadMap12

I've made some tweaks to the "what packages we should release" bit.


Richard

[Nathan]

On Fri, Jun 15, 2012 at 5:10 PM, Rui Carmo <rui....@gmail.com> wrote:
> One question, though. Why bitbucket and not github? (I'm partial on this
> because I use Github a lot and find their forking/pull request mechanism
> astounding for handling patches and contributions, but... I'm just curious).

I'm also a fan of GitHub. I would presume they prefer Bitbucket
because the current repository is stored in mercurial ("hg"), which
Bitbucket supports and Github does not.

~ Nathan

[Phillip Nguyen]

On Friday, June 15, 2012 5:07:55 PM UTC-5, Winston wrote:

FYI, I'm trying a merge of evilphillip-cocoa-ctypes2 into pyglet. There are 16 files updated and three files with conflicts:
        - pyglet/app/cocoa.py
        - pyglet/image/codecs/quartz.py
        - pyglet/window/cocoa/__init__.py

They don't look too bad but I think it would be better if someone more familiar with the code tried to fix it. Below are snippets to give you an idea of what we're up against.

Hey, thanks for doing all of this testing.  I can work through some of this tomorrow and go ahead and merge the cocoa-ctypes code into the main repository.  The merge process is really just a matter of wholesale replacing all of the cocoa-related pyobjc files with the new files that are in the clone.  I should be able to look at some of the other issues you brought up too, it will just take me a while to get familiar with the code again.  Some issues that I'm worried about are that I haven't tested the ctypes clone against Python 3 or the latest version of PyPy, and I think there have been reports of problems with both.

--phillip

[Winston Wolff]

Test report for https://code.google.com/p/pyglet/

I just realized that tests/test.py didn't print errors to the console, only to the log file. So my previous test report for the cocoa-ctypes branch might not be complete. I have changed test.py so that errors are mentioned in the terminal, and the filename for the log file containing details is also shown.

I also wrote a bit on the wiki http://code.google.com/p/pyglet/wiki/TestingAndDebugging about the different sections of the plan.txt and how long they take. It includes advice on which groups to run.

And finally, below is my test report for Mac OS X 10.7.2, Python 2.7.2 framework build, hg id 91d235c8ee84

I do notice that there are a number of little things that are nicer in the pyglet repo than in evilphilip's branch such as the way windows behave. So I'm even more motivated now to get them merged.

---------

ERROR Failure in graphics.RETAINED_INDEXED
ERROR Traceback (most recent call last):
File "tests/../tests/graphics/RETAINED_INDEXED.py", line 76, in test_v3f_c4f_t4f
self.generic_test('v3f', v3f_data, 'c4f', c4f_data, 't4f', t4f_data)
File "tests/../tests/graphics/RETAINED_INDEXED.py", line 42, in generic_test
self.check(get_ordered_data(v_data, n_v), vertices, n_v)
File "tests/../tests/graphics/RETAINED_INDEXED.py", line 25, in check
(e, r))
AssertionError: Feedback array is in error: 0.3088235294117647, 0.8823529481887817


ERROR Error in media.PLAYER_STATIC_STATIC
ERROR Traceback (most recent call last):
File "tests/../tests/media/PLAYER_STATIC_STATIC.py", line 26, in test_method
player.dispatch_events()
AttributeError: 'Player' object has no attribute 'dispatch_events'


ERROR Cannot load test for text.HTML_IMAGE


ERROR Failure in font.WRAP_INVARIANT
ERROR Traceback (most recent call last):
File "tests/../tests/font/base_text.py", line 47, in test_main
self.render()
File "tests/../tests/font/WRAP_INVARIANT.py", line 25, in render
self.label2 = font.Text(fnt, 'SPAM SPAM\nSPAM', 10, 50)
File "tests/../pyglet/font/__init__.py", line 347, in __init__
group=self._group)
File "tests/../pyglet/text/layout.py", line 779, in __init__
assert not multiline or width, 'Must specify width with multiline'
AssertionError: Must specify width with multiline


window.WINDOW_FULLSCREEN_SIZE -- goes full screen but ESC does not bring me back. Also "green rectangle which should be completely visible" is not visible

> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/xiJnR6oDiVwJ.

[Nathan]

On Thu, Jun 14, 2012 at 7:06 PM, Tom Ray <tae...@gmail.com> wrote:
> There are already graphical installers for pyglet 1.2 and avbin 8 here:
> http://www.lfd.uci.edu/~gohlke/pythonlibs/#pysfml2

I think you are mistaken. On that page the avbin downloads aren't
graphical installers and the Pyglet installers don't seem to include
AVbin at all.

~ Nathan

[anatoly techtonik]

Roadmap on Google Code wiki is not a good move, because nobody except a few
people can update it. Wiki patches are also lay dormant in the tracker
for a long time.

[Richard Jones]

Thanks for the impetus and original copy, but

a) all committers are able to update it,
b) I believe it's better than nothing, and
c) having non-committers able to edit it is ... dangerous :-)

[until something better comes along, perhaps]


Richard

[Winston Wolff]

Anatoly-

I agree that a more accessible wiki page would be better but this works for right now.

-ww

> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.

[Rui Carmo]

On Jun 16, 2012, at 24:56 , Richard Jones wrote:

> It's easy enough to generate tgz for the Unix users who prefer those tools.

As a Mac user, either is good for me. As a cross-platform developer that happens to prefer using a Mac, .dmg is something I actually am not keen on. :)

>> One question, though. Why bitbucket and not github? (I'm partial on this
>> because I use Github a lot and find their forking/pull request mechanism
>> astounding for handling patches and contributions, but... I'm just curious).
>
> Bitbucket and github are pretty much on feature parity in that regard,
> and the pyglet repos is in Mercurial (and that is not up for debate,
> so don't even start.)

I won't. My web site (the.taoofmac.com) was completely managed using hg until I surrendered to the git hordes (then I gave up on either and just started using Dropbox and rdiff-backup, but that's another story).

Incidentally, a few kind words regarding another Python project: I've been puttering about bitbucket and found Whoosh (which I use extensively) there as well, so I set up an account (rcarmo).

So that means I'll be able to do "github-like" pull requests via hg on Bitbucket?

R.

[Richard Jones]

On 17 June 2012 07:32, Rui Carmo <rui....@gmail.com> wrote:
> Incidentally, a few kind words regarding another Python project: I've been puttering about bitbucket and found Whoosh (which I use extensively) there as well, so I set up an account (rcarmo).

Whoosh is awesome.

> So that means I'll be able to do "github-like" pull requests via hg on Bitbucket?

That's the idea, yes.


Richard

[Jonathan Hartley]

Is it useful to split the 'See if we have test coverage on major platforms and it passes.' line into one entry for each platform, with tester's names next to them? Then it's visible which platforms have no testers.

I'm about to start on OSX 10.6 (Snow Leopard), if that's useful. But if there's a major merge of evilphilip's branch underway, should I hold off until that's complete?

    Jonathan
 

[T.J. Jankun-Kelly]

Does Phillips's branch support the Core Profile/OpenGL 3? When I checked last year it didn't, which was not ideal. I submitted a patch (532), but that was some time ago.

[Phillip Nguyen]

On Sunday, June 17, 2012 6:03:12 AM UTC-5, Jonathan Hartley wrote:

Is it useful to split the 'See if we have test coverage on major platforms and it passes.' line into one entry for each platform, with tester's names next to them? Then it's visible which platforms have no testers.

I'm about to start on OSX 10.6 (Snow Leopard), if that's useful. But if there's a major merge of evilphilip's branch underway, should I hold off until that's complete?

    Jonathan
 

I've finished merging the ctypes-based cocoa branch back into the main repository now, so go ahead and test away.  

One unfortunate new quirk that just got introduced is a console warning message on initialization that looks like:

 Python[3572:d07] *** -[NSLock unlock]: lock (<NSLock: 0x102208320> '(null)') unlocked when not locked

 Python[3572:d07] *** Break on _NSLockError() to debug.

This seems to be a result of the call to NSScreen.screens() in pyglet/canvas/cocoa.py.  It doesn't appear to be hurting anything, but I don't know how to get rid of it either.

--phillip

[Rui Carmo]

On Jun 18, 2012, at 10:23 , Phillip Nguyen wrote:

This seems to be a result of the call to NSScreen.screens() in pyglet/canvas/cocoa.py.  It doesn't appear to be hurting anything, but I don't know how to get rid of it either.

How can I check out that particular rev and have a look?

R.

[Richard Jones]

On 18 June 2012 19:23, Phillip Nguyen <evil.p...@gmail.com> wrote:
> I've finished merging the ctypes-based cocoa branch back into the main
> repository now, so go ahead and test away.

This is awesome, thanks!

I think that after some sanity checking if everyone agrees I'll push
out 1.2 alpha1?

I'll push the documentation (as "dev" documentation and look at moving
the 1.1 documentation aside) to the website as well, though I'd prefer
to have the style fixed for that before that push.


Richard

[anatoly techtonik]

To speed up the sync with people with no commit access there can be a
contact point for updating RoadMap12 at the top of the page.

[anatoly techtonik]

On Mon, Jun 18, 2012 at 12:41 PM, Richard Jones <r1char...@gmail.com> wrote:
> On 18 June 2012 19:23, Phillip Nguyen <evil.p...@gmail.com> wrote:
>> I've finished merging the ctypes-based cocoa branch back into the main
>> repository now, so go ahead and test away.
>
> This is awesome, thanks!
>
> I think that after some sanity checking if everyone agrees I'll push
> out 1.2 alpha1?

I agree.) I don't know the difference in API between 1.1 and 1.2
though. If there is a significant overhaul, then perhaps 2.0 would be
a better name.

> I'll push the documentation (as "dev" documentation and look at moving
> the 1.1 documentation aside) to the website as well, though I'd prefer
> to have the style fixed for that before that push.

Can you also describe what is required to make website run on a local
machine? The repository seems missing info on some vital parts.

[Richard Jones]

On 18 June 2012 20:14, anatoly techtonik <tech...@gmail.com> wrote:
> On Mon, Jun 18, 2012 at 12:41 PM, Richard Jones <r1char...@gmail.com> wrote:
>> On 18 June 2012 19:23, Phillip Nguyen <evil.p...@gmail.com> wrote:
>>> I've finished merging the ctypes-based cocoa branch back into the main
>>> repository now, so go ahead and test away.
>>
>> This is awesome, thanks!
>>
>> I think that after some sanity checking if everyone agrees I'll push
>> out 1.2 alpha1?
>
> I agree.) I don't know the difference in API between 1.1 and 1.2
> though. If there is a significant overhaul, then perhaps 2.0 would be
> a better name.

There's minimal API changes - the implementation for OSX has changed,
as has 64-bit Windows.

I'll be looking to go through the commit logs at some point to update
the CHANGELOG.

>> I'll push the documentation (as "dev" documentation and look at moving
>> the 1.1 documentation aside) to the website as well, though I'd prefer
>> to have the style fixed for that before that push.
>
> Can you also describe what is required to make website run on a local
> machine? The repository seems missing info on some vital parts.

The relevant scripts are in the tools directory. They need to be
updated for sphinx though.


Richard

[Winston Wolff]

T.J.-

Can you tell me what OpenGL 3 will help with? And how would I test it to see if it was working?

-ww

On Jun 17, 2012, at 5:14 AM, T.J. Jankun-Kelly wrote:

> Does Phillips's branch support the Core Profile/OpenGL 3? When I checked last year it didn't, which was not ideal. I submitted a patch (532), but that was some time ago.
>

> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/cIx8roVGGJ0J.

[Winston Wolff]

HI T.J.-

Thanks for your working making the patch. I'm just a newcomer but my preference would be to cut a first release candidate to have it out. Then go through and try to add various patches to see if they work. I think having something released is better than a delaying since we haven't had the resources to get 1.2 out for so long.

Once we've cut one release, I'll take a look at your patch.

-Winston

On Jun 17, 2012, at 5:14 AM, T.J. Jankun-Kelly wrote:

> Does Phillips's branch support the Core Profile/OpenGL 3? When I checked last year it didn't, which was not ideal. I submitted a patch (532), but that was some time ago.
>