Hi We''re all keen to get a release out, for lots of reasons: getting more people testing, showing people the progress we''ve made, etc. So I suggest that we now look to release an alpha version very soon, based pretty much on the current state of CVS plus pending check-ins. Sure, it has some bugs, some missing features and segfaults occasionally - but my experience on OS X suggests it''s not horribly worse than 0.6.0, and is lots better in other ways (i18n, additional classes and methods, GTK2 + OS X support). Particularly, I think it''s not the end of the world if we don''t support all 0.6.0 classes in a first release, and if memory mgmt is not completely sorted. Looking over blogs, newsgroups, mailing lists etc, the main things that people don''t seem to like about wxRuby are: 1) Instability, 2) the docs, or lack of, and 3) the API being very C++ish. So I humbly propose the following goals for an alpha release, and am prepared to work on getting these done. But please do disagree with the goals.. A) Fix the samples B) Fix any big-time, regular crashers C) Add some documentation, if possible D) Add some easy, cheap ruby-ification to the API E) Binary gems A) Quite a few of the samples have got a little bit-rotted. We''ll make sure each one runs at least and looks correct, even if not every method works. B) Nail crasher bugs that affect lots of code. But I think it''s fine, for things like ItemData, to tell people not to use it, rather than trying to fix the difficult memory management problems in full. C) Zach''s work from early 2005 on the docs seemed really promising. He seemed to have developed a way of reading SWIG output and headers to make RDoc-ish output. Does anyone have this somewhere? It would be great to supply some rudimentary RDoc with a package. D) I think we can do some things to make the API a bit more Rubyish without having to hack the interface files. Eg. a few lines that alias set_attr, get_attr and is_attr to more ruby-ish attr=(), attr() and attr?(). We can put in better plumbing later ;) E) This is one where we can use help. Suggest we release as source tarball and gems. I''m happy to bundle binaries into platform gems. OS X: Alex. Sean are you able to check on Mactel? Win32: Roy? Curt? anyone? Linux: Kevin? anyone? Hope this sounds like a reasonable way forward - but please disagree. And shout if your manager has just offered you two months off your normal job to workk on wxruby ;) cheers alex
> So I suggest that we now look to release an alpha version very soon, based > pretty much on the current state of CVS plus pending check-ins.Sounds good to me, I am using that code base for a custom in house program that is used nearly every day.> Sure, it has some bugs, some missing features and segfaults occasionallyThe most annoying bug I have is that pre built dialogs are starting out with a negative x value for the dialog location and are not being shown on screen when show() is called. An example of this is in the caret sample when Wx::message_box() is called for the about box as well as when Wx::get_number_from_user() is called. This problem exists on Mac OS X Intel and PPC.> A) Fix the samplesConsistent structure and style across all of them would be nice.> B) Fix any big-time, regular crashersUsing Wx::GridCellBoolRender in a Wx::Grid crashes for me, have not bothered to look into it too much.> C) Add some documentation, if possibleI am pretty happy just using the standard wxWidgets HTML documentation and knowing the naming rules for wxRuby. - classes like wxDialog become Wx::Dialog - methods like ShowModal() become show_modal() - enums and constants like wxDefaultPosition become Wx::DEFAULT_POSITION - etc. Maybe we should just document the parts that stray from the C++ interface, like the wxWidgets docs do for wxPython and wxPerl.> D) Add some easy, cheap ruby-ification to the APII think for the first version we should leave this out and just try to get a release under our belt. We can add it on later easy enough.> E) Binary gemsI can help here by creating one for Mac OS X 10.4 PPC and Intel as long as someone with more experience creates the gem spec. I also have Ubuntu & Windows XP virtualized under Parallels on the Intel Mac so I could help there if I have time. I also think we should rip out all the comment fragments from the include files, they are leftover from long ago the new classes added do not have them.> And shout if your manager has just offered you two months off your > normal job to workk on wxruby ;)I wish :) Sean
On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote:> Alex wrote: > > So I suggest that we now look to release an alpha version very soon, based > > pretty much on the current state of CVS plus pending check-ins. >Sounds good, although we will need to agree on what "pretty much" really means.> > A) Fix the samples > > Consistent structure and style across all of them would be nice.As long as someone is willing to take this on, fine. But I''m not sure if it would be worth delaying an alpha release for better samples. That is, getting something out there with the problems documented might be better than waiting (and waiting, and waiting). See below for related thoughts.> > B) Fix any big-time, regular crashers > > Using Wx::GridCellBoolRender in a Wx::Grid crashes for me, have not > bothered to look into it too much.Again, I would lean toward defining this as something like "if it causes a sample to crash under simple usage, fix it". Otherwise, we run the risk of trying to make it perfect before releasing, instead of following the FLOSS rule of "release early and often".> > C) Add some documentation, if possible > > I am pretty happy just using the standard wxWidgets HTML documentation > and knowing the naming rules for wxRuby.I''m inclined to agree. This initial release should probably only be used by "motivated" developers who are willing to put up with a little pain.> > D) Add some easy, cheap ruby-ification to the API > > I think for the first version we should leave this out and just try to > get a release under our belt. We can add it on later easy enough.I would rather postpone this, partly because I would like to really think it through rather than making a little tweak here and there that might end up being replaced by a better rubification a little later.> > E) Binary gems > > I can help here by creating one for Mac OS X 10.4 PPC and Intel as > long as someone with more experience creates the gem spec. > > I also have Ubuntu & Windows XP virtualized under Parallels on the > Intel Mac so I could help there if I have time.I can certainly create a Ubuntu-compatible Linux tarball. I have never created a gem of any kind, so I would hope to get some guidance on that part.> I also think we should rip out all the comment fragments from the > include files, they are leftover from long ago the new classes added > do not have them.I don''t view that as critical, although I think it''s a good idea to do eventually. So I guess my take might be "release JUST what we have right now, including pending patches, with known problems documented". I''m just afraid that fixing anything will delay the release by weeks, or months. A looser version would be to freeze the library code right away, and the samples a week later, or some other "reasonable" amount of time. Kevin
My two cents on this would be to get an alpha out ASAP that documents known issues. It would be helpful if the naming conventions and parameters are generally the same as WxRuby1, but other, stylistic changes can wait. I found the "Poor Man''s Documentation" to WxRuby1, as well as the code samples to be mostly adequate in combination with the general WxWidgets documentation. A later documentation choice might be to annotate the WxWidgets documentation with Ruby differences (that cannot be stated in general terms like naming conventions). I found such documentation for WxPython and WxPerl to be helpful. Essentially, the main WxWidgets documentation had insertions at the beginning of each class description that pointed out what was added, missing, or different in the calling syntax or behavior of the Python or Perl implementation. I would guess that the release of an alpha version will help to create momentum for subsequent iterations of the project, stirring more intrest, feedback, and contributions from the Ruby community. Regards, Jamal
hi Basically, I think all Kevin and Sean''s preceding suggestions in this thread are excellent. So, for alpha1, in summary: - no new classes/methods, bar pending patches - fix major crashers, only, in samples - a bit of extra docs, on known bugs and how to use the WxW C++ docs - I''m happy to make gems from supplied Linux & Win binaries as well as OS X Kevin Smith wrote:> Sounds good, although we will need to agree on what "pretty much" really > means. >how about, for the sake of alpha release - no new classes and methods. Everyone - yell if there''s something that you think MUST be in there that isn''t. And, preferably, follow the yell with a patch.>> Consistent structure and style across all of them would be nice. >> > As long as someone is willing to take this on, fine. But I''m not sure if > it would be worth delaying an alpha release for better samples. >I agree> I would lean toward defining this as something like "if it causes > a sample to crash under simple usage, fix it".I agree> I''m inclined to agree. This initial release should probably only be used > by "motivated" developers who are willing to put up with a little pain. >OK. Let''s just make sure we add a brief, obvious note on how to use the WxWidgets C++ docs.> I would rather postpone this, partly because I would like to really > think it through rather than making a little tweak here and there that > might end up being replaced by a better rubification a little later. >Yes, I think you and Sean are right. I''ll release my pure-ruby syntax sugar extensions shortly after the main alpha release to get some discussion going.> I can certainly create a Ubuntu-compatible Linux tarball. I have never > created a gem of any kind, so I would hope to get some guidance on that > part. >I''m have a working gemspec, and am happy to create binary gems for all platforms, if you supply me with a strip-ped platform .so/.lib/.bundle Also I think we should supply a pre-swigged set of source files, for those that like that sort of thing. As a tarball and source gem?> So I guess my take might be "release JUST what we have right now, > including pending patches, with known problems documented".Let''s do it! Roy/Kevin/Curt - are any of you able to review & commit mine and Sean''s pending patches some time in the next few days? I can htve a go otherwise. And throw anything back that causes probs, and if there''s no quick fix, we can integrate after we release.> A looser version would be to freeze the library code right away, and the > samples a week later, or some other "reasonable" amount of time. >ditto all the best alex
> Also I think we should supply a pre-swigged set of source files, for > those that like that sort of thing. As a tarball and source gem?The problem I see with the pre-swigged source files is that they are specific for each platform. So for example we would need a release like the following: wxRuby2_alpha_1_src wxRuby2_alpha_1_mac_os_x_ppc_gem wxRuby2_alpha_1_mac_os_x_x86_gem wxRuby2_alpha_1_windows_gem wxRuby2_alpha_1_ubuntu_x86_gem wxRuby2_alpha_1_mac_os_x_ppc_swigged_src wxRuby2_alpha_1_mac_os_x_x86_swigged_src #this one probably is the exact same as ppc wxRuby2_alpha_1_windows_swigged_src wxRuby2_alpha_1_ubuntu_x86_swigged_src That is a heck of a lot of files for an alpha release, especially since it can not all be done on one machine by one dev (2 machine minimum - a ppc mac, intel mac and virtualization software) I say we shoot for the raw src and the 4 gem files. SWIG is not too hard to install if someone is curious.> > So I guess my take might be "release JUST what we have right now, > > including pending patches, with known problems documented". > Let''s do it!I agree fire up CVS and lets add some patches! Sean
On Thu, 2006-08-03 at 16:01 -0700, Sean Long wrote:> The problem I see with the pre-swigged source files is that they are > specific for each platform.> That is a heck of a lot of files for an alpha release, especially > since it can not all be done on one machine by one dev (2 machine > minimum - a ppc mac, intel mac and virtualization software) > > I say we shoot for the raw src and the 4 gem files. SWIG is not too > hard to install if someone is curious.I agree. Kevin
On Thu, 2006-08-03 at 19:27 +0100, Alex Fenton wrote:> Let''s do it! Roy/Kevin/Curt - are any of you able to review & commit > mine and Sean''s pending patches some time in the next few days? I can > htve a go otherwise. And throw anything back that causes probs, and if > there''s no quick fix, we can integrate after we release.I don''t expect to have any time until the middle of next week, at the earliest. Total chaos here. If things go according to plan, I should start to free up by the 12th. Kevin
Just FYI: I am going to try really hard to set aside half a day this weekend to catch up on wxruby cvs work. Really, really hard. I''m announcing this as a further incentive to myself, to avoid breaking a public commitment. The good news is that two of the four "real life" pressures that have been taking up my time for the last few months should be mostly finished tomorrow. The other two are weekday activities, so hopefully I will be able to put in some wxruby time each weekend for a while. Kevin
Kevin Smith
2006-Aug-13 19:07 UTC
[Wxruby-users] Backlog is cleared (was: wxruby2 alpha release goals)
On Fri, 2006-08-11 at 01:04 -0400, Kevin Smith wrote:> Just FYI: I am going to try really hard to set aside half a day this > weekend to catch up on wxruby cvs work. Really, really hard. I''m > announcing this as a further incentive to myself, to avoid breaking a > public commitment.And fortunately I was able to follow through. All the July/August patches have been merged (except one that I rejected). I still have a bunch of messages from April to go through, but I believe they were all problem reports, technical discussions, etc. If anyone has submitted patches that I have not responded to, please let me know.> The good news is that two of the four "real life" pressures that have > been taking up my time for the last few months should be mostly finished > tomorrow. The other two are weekday activities, so hopefully I will be > able to put in some wxruby time each weekend for a while.I remain optimistic that I will be able to give wxruby at least 4-8 hours a week this month. Hopefully more after that, but it''s hard to predict that far in the future. Kevin
Kevin Smith
2006-Aug-13 19:12 UTC
[Wxruby-users] message_box showing up off-screen on Mac (was: wxruby2 alpha release goals)
On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote:> The most annoying bug I have is that pre built dialogs are starting > out with a negative x value for the dialog location and are not being > shown on screen when show() is called. An example of this is in the > caret sample when Wx::message_box() is called for the about box as > well as when Wx::get_number_from_user() is called. This problem exists > on Mac OS X Intel and PPC.Strange. The wx api clearly shows default values of -1 for the x and y parameters. Looking at the wxruby code, it would seem that we are indeed passing -1, -1 if those are not passed in from ruby. So it sounds like an upstream bug in the Mac version of wx. Kevin
This is a SWIG bug, the same as I was mentioning before. Roy Kevin Smith wrote:> On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote: > >> The most annoying bug I have is that pre built dialogs are starting >> out with a negative x value for the dialog location and are not being >> shown on screen when show() is called. An example of this is in the >> caret sample when Wx::message_box() is called for the about box as >> well as when Wx::get_number_from_user() is called. This problem exists >> on Mac OS X Intel and PPC. >> > > Strange. The wx api clearly shows default values of -1 for the x and y > parameters. Looking at the wxruby code, it would seem that we are indeed > passing -1, -1 if those are not passed in from ruby. So it sounds like > an upstream bug in the Mac version of wx. > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > >
There may be a SWIG bug, but that''s not what is causing the message box to come up in the wrong place. At least, not from what I am seeing. Unless it''s a Mac-specific SWIG bug, which seems unlikely. The C++ wrapper generated by swig appears to correctly default x and y to -1 values. It then calls the wx MessageBox function. At that point, if wx doesn''t recognize -1,-1 as being the "default position", that would be a bug in the Mac implementation of wx. Maybe I''m missing something. Kevin On Sun, 2006-08-13 at 16:22 -0400, Roy Sutton wrote:> This is a SWIG bug, the same as I was mentioning before. > > Roy > > Kevin Smith wrote: > > On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote: > > > >> The most annoying bug I have is that pre built dialogs are starting > >> out with a negative x value for the dialog location and are not being > >> shown on screen when show() is called. An example of this is in the > >> caret sample when Wx::message_box() is called for the about box as > >> well as when Wx::get_number_from_user() is called. This problem exists > >> on Mac OS X Intel and PPC. > >> > > > > Strange. The wx api clearly shows default values of -1 for the x and y > > parameters. Looking at the wxruby code, it would seem that we are indeed > > passing -1, -1 if those are not passed in from ruby. So it sounds like > > an upstream bug in the Mac version of wx. > > > > Kevin > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users
Kevin, What you''re missing is that deep down in the bowels of Wx it''s calling back to a function wrapped by SWIG. When it gets passed off through the director the return values for where it should go aren''t returned to the calling function. At least, that''s what I recall. It took me quite a while to discover what was happening. It may be my recollection is off. I know the problem occurs with wrapping GetTextExtent. I think it also affected a couple others. Roy Kevin Smith wrote:> There may be a SWIG bug, but that''s not what is causing the message box > to come up in the wrong place. At least, not from what I am seeing. > Unless it''s a Mac-specific SWIG bug, which seems unlikely. > > The C++ wrapper generated by swig appears to correctly default x and y > to -1 values. It then calls the wx MessageBox function. At that point, > if wx doesn''t recognize -1,-1 as being the "default position", that > would be a bug in the Mac implementation of wx. > > Maybe I''m missing something. > > Kevin > > On Sun, 2006-08-13 at 16:22 -0400, Roy Sutton wrote: > >> This is a SWIG bug, the same as I was mentioning before. >> >> Roy >> >> Kevin Smith wrote: >> >>> On Wed, 2006-08-02 at 14:21 -0700, Sean Long wrote: >>> >>> >>>> The most annoying bug I have is that pre built dialogs are starting >>>> out with a negative x value for the dialog location and are not being >>>> shown on screen when show() is called. An example of this is in the >>>> caret sample when Wx::message_box() is called for the about box as >>>> well as when Wx::get_number_from_user() is called. This problem exists >>>> on Mac OS X Intel and PPC. >>>> >>>> >>> Strange. The wx api clearly shows default values of -1 for the x and y >>> parameters. Looking at the wxruby code, it would seem that we are indeed >>> passing -1, -1 if those are not passed in from ruby. So it sounds like >>> an upstream bug in the Mac version of wx. >>> >>> Kevin >>> >>> >>> _______________________________________________ >>> wxruby-users mailing list >>> wxruby-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wxruby-users >>> >>> >>> >>> >>> >> _______________________________________________ >> wxruby-users mailing list >> wxruby-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wxruby-users >> > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > >