Hey guys,
I''m working on the start of incorperating wxSocket into a library that
can be included with the Core, and a part of this, is to create a
wxThread class, which will basically just be a barebone copy over of
Ruby''s own Thread class. (This should also help when we get Ruby 2.0,
which hopefully will have Native Threads, as we should still be able to
get the base Thread class there.) Now, I''m working on this, and trying
to find the best way in which to make this merger, so that we can get
this setup, so that users won''t have to look at how to do Threads, or
how to setup a timer, or some stuff like that. What I''m basically
setting up, is something similar to this:
Wx::Thread.new do
# some code here
end
Wx::App.new do
Wx::Frame.new(nil,:title=>"Threaded Example")
end.main_loop()
Or whatever, but they won''t have to worry about it, as Wx::Thread will
setup a timer, and set the default Pass Interval, to 25 milliseconds,
and if they want to change that, they can call
Wx::Thread.set_pass_interval(milliseconds) to change the default pass
interval, and it will change it on the fly as well. However, I''m
running into problems with dealing with the instance at which it''s in.
Meaning, that if I modify samples/etc/threaded.rb to use the new
threaded model, it''ll not find the guage variable. Which means the
instance binding is not being set to the one that calls it. Any
suggestions?
Thanks,
Mario Steele
Hey Guys, Actually, just figured out a way to incorporate this, in the best manner. I''ve added the following methods and constants to Wx::App Wx::App::THREAD_TIMER_ID -(Wx::ID_HIGHEST+1000) Wx::App#init_threaded_mode() This starts the Timer for Threads, which can be stopped with the method below. Wx::App#shutdown_threaded_mode() This stops the timer, and clears it out from being used again. Wx::App#set_threaded_interval(milliseconds) Set''s the number of milliseconds in which the Timer to pass control over to another thread ticks off. Wx::App#get_threaded_interval() Returns the current number of Milliseconds in which the Timer to pass control over to another thread ticks off. Added also threaded_interval= and threaded_interval for Ruby Based threads. Checked in Revision 1414, with Example for the new threads method, under samples/etc/threaded2.rb Let me know if you guys have any questions. Mario Steele Mario Steele wrote:> Hey guys, > > I''m working on the start of incorperating wxSocket into a library that > can be included with the Core, and a part of this, is to create a > wxThread class, which will basically just be a barebone copy over of > Ruby''s own Thread class. (This should also help when we get Ruby 2.0, > which hopefully will have Native Threads, as we should still be able > to get the base Thread class there.) Now, I''m working on this, and > trying to find the best way in which to make this merger, so that we > can get this setup, so that users won''t have to look at how to do > Threads, or how to setup a timer, or some stuff like that. What I''m > basically setting up, is something similar to this: > > Wx::Thread.new do > # some code here > end > > Wx::App.new do > Wx::Frame.new(nil,:title=>"Threaded Example") > end.main_loop() > > Or whatever, but they won''t have to worry about it, as Wx::Thread will > setup a timer, and set the default Pass Interval, to 25 milliseconds, > and if they want to change that, they can call > Wx::Thread.set_pass_interval(milliseconds) to change the default pass > interval, and it will change it on the fly as well. However, I''m > running into problems with dealing with the instance at which it''s > in. Meaning, that if I modify samples/etc/threaded.rb to use the new > threaded model, it''ll not find the guage variable. Which means the > instance binding is not being set to the one that calls it. Any > suggestions? > > Thanks, > > Mario Steele >
Mario Steele wrote:> Hey Guys, > > Actually, just figured out a way to incorporate this, in the best > manner. I''ve added the following methods and constants to Wx::App >Thanks. This looks OK, but I''m not convinced it adds anything to core over just documenting how to use Wx::Timer and Thread - which was why I created the threaded.rb sample. I guess many people using threads are going to want finer-grained control, eg in Weft QDA I have several timers for different kinds of background task (search indexing, autosaving). So, I would prefer that these extra methods went in wxSugar, and we just added a short tutorial to the main docs on how to use Thread. These methods won''t be useful anyway unless they''re documented. If you''re very keen to have something in core, my preferred implementation would be to have a Wx::ThreadedApp which sets up the timer in on_init, so there is no extra code needed. cheers alex
Hey Alex, I agree with you on that aspect, of finer-grained control, and adding something like Wx::ThreadedApp, which is why I was trying to implement Wx::Thread, but due to the Context problems being of an incorrect context, I''m having problems implementing it that way. I''ve just tried to implement Wx::ThreadedApp, to see if I could possibly do it this route, and it seems that it also doesn''t like this way to execution...... The problem lays in the fact, that if someone Sub-classes ThreadedApp, you''ll need to call super() in order to ensure the Wx::Timer gets created. The problem is, if you call super() before the creation of your Frame, it goes into an endless loop of switching contexts back to itself. This is further confirmed when you put it after the main frame creation, as hundreds upon hundreds of windows will continously open, leadings to a race condition. I''ve looked over both the current implementation that I have created, and the Implementation I wrote up for ThreadedApp, and nothing is changed, except for it switching from the context of Wx::App to Wx::ThreadedApp. Any suggestions? I would rather have this in the core, as it''s the foundation for the Sockets library I''m writing up, and can''t function without it. And I''d hate to have to write the Thread control into the Socket library, if we can possibly generalize it, and allow more people to be able to utilize Threads within wxRuby, with less hassle, and lessen the learning curve. L8ers, Mario Steele Alex Fenton wrote:> Thanks. This looks OK, but I''m not convinced it adds anything to core > over just documenting how to use Wx::Timer and Thread - which was why I > created the threaded.rb sample. I guess many people using threads are > going to want finer-grained control, eg in Weft QDA I have several > timers for different kinds of background task (search indexing, > autosaving). > > So, I would prefer that these extra methods went in wxSugar, and we just > added a short tutorial to the main docs on how to use Thread. These > methods won''t be useful anyway unless they''re documented. > > If you''re very keen to have something in core, my preferred > implementation would be to have a Wx::ThreadedApp which sets up the > timer in on_init, so there is no extra code needed. > > cheers > alex > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20071105/1f96c6fe/attachment.html
Mario Steele wrote:> Hey Alex, > > I agree with you on that aspect, of finer-grained control, and adding > something like Wx::ThreadedApp, which is why I was trying to implement > Wx::Thread, but due to the Context problems being of an incorrect > context, I''m having problems implementing it that way. I''ve just > tried to implement Wx::ThreadedApp, to see if I could possibly do it > this route, and it seems that it also doesn''t like this way to > execution...... The problem lays in the fact, that if someone > Sub-classes ThreadedApp, you''ll need to call super() in order to > ensure the Wx::Timer gets created. The problem is, if you call > super() before the creation of your Frame, it goes into an endless > loop of switching contexts back to itself. This is further confirmed > when you put it after the main frame creation, as hundreds upon > hundreds of windows will continously open, leadings to a race > condition. I''ve looked over both the current implementation that I > have created, and the Implementation I wrote up for ThreadedApp, and > nothing is changed, except for it switching from the context of > Wx::App to Wx::ThreadedApp. > > Any suggestions? I would rather have this in the core, as it''s the > foundation for the Sockets library I''m writing up, and can''t function > without it. And I''d hate to have to write the Thread control into the > Socket library, if we can possibly generalize it, and allow more > people to be able to utilize Threads within wxRuby, with less hassle, > and lessen the learning curve. > > L8ers, > > Mario SteeleOkay, I''m going to officially put out a retraction on that. It was just me being silly, and not thinking through on what I was doing. The problem was me calling super() in Wx::ThreadedApp, which caused the loop in the first place. So, after changing that, everything cleared up. No infinite loops. So, I''m finishing up the last bit of stuff here on my side, then I''ll do a commit for the new classes for Wx::ThreadedApp, and Wx::Socket. L8ers, Mario Steele -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20071105/ae803893/attachment.html
Hi Mario Mario Steele wrote:>> Any suggestions? I would rather have this in the core, as it''s the >> foundation for the Sockets library I''m writing up, and can''t function >> without it. And I''d hate to have to write the Thread control into >> the Socket library, if we can possibly generalize it, and allow more >> people to be able to utilize Threads within wxRuby, with less hassle, >> and lessen the learning curve.I see what you''re saying. I just don''t think that the bare API way running a threaded app is so painful - it''s only two or three lines. If you''ve still got to call "init_threaded_mode()" to make a Wx::App work with threads, you''ve still got to try an App with threads, notice it''s not working, scratch your head, google "wxRuby+threads" and see what comes back. So I''d rather users found a page that says: "use Timer like this". Then, people who just want to copy and paste three lines of Wx::Timer code can do so and forget about it. People who care more will understand what''s going on, and perhaps why they''d like to do things slightly differently.> The problem was me calling super() in Wx::ThreadedApp, which caused > the loop in the first place. So, after changing that, everything > cleared up. No infinite loops. So, I''m finishing up the last bit of > stuff here on my side, then I''ll do a commit for the new classes for > Wx::ThreadedApp, and Wx::Socket.OK, can you post for discussion first please? And consider whether ThreadedApp at least might live in wxSugar for a bit; that project''s been valuable in refining everything else we''ve done with wx''s ruby layer. Additions to the core wx API have been *very* sparse and cautious - barely two or three public methods (almost all the code in lib/wx/classes deals with internals like GC and error checking). E.g. I''m not sure "set_threaded_interval" isn''t just adding a method for the sake of method. It doesn''t really do what it says - child threads aren''t guaranteed to run at that interval. Just a comment on file/class matching conventions - code that extends Wx::Foo should be in lib/wx/classes/foo.rb. So code extending Wx::App should be in lib/wx/classes/app.rb not thread.rb. We need to think where ruby-only subclasses might live? Also please don''t touch or add a method without ensuring that docs are in place and correct. I hope I don''t sound negative - I''m really glad you''re working on Sockets b/c as I have neither time nor knowledge to do so - I''d just like you to be less hasty in committing when working on major core classes. cheers alex
> Any suggestions? I would rather have this in the core, as it''s the > foundation for the Sockets library I''m writing up, and can''t function > without it. And I''d hate to have to write the Thread control into the > Socket library, if we can possibly generalize it, and allow more people to > be able to utilize Threads within wxRuby, with less hassle, and lessen the > learning curve.I am with Alex on this and would like to see it go in wxSugar first then after testing and feedback move it into wxRuby core. My reasoning behind this is to make sure the core library stays/becomes more stable as we move towards 2.0. Sean
Hey Guys, Sean Long wrote:> I am with Alex on this and would like to see it go in wxSugar first > then after testing and feedback move it into wxRuby core. My reasoning > behind this is to make sure the core library stays/becomes more stable > as we move towards 2.0No problem with that, I understand the want to ensure wxRuby core remains stable, and I''m all for that, which is why I''m testing code long before I even commit it to the SVN. If you guys believe wxSugar would be a better place to start, not a problem there, just that I don''t use wxSugar at all. Alex Fenton wrote:> I see what you''re saying. I just don''t think that the bare API way > running a threaded app is so painful - it''s only two or three lines. >This is true, however, once you see how simplified the Socket''s Demo has become, cause of switching the code out to Sockets, and then adding in Wx::ThreadedApp, you may re-consider it.> If you''ve still got to call "init_threaded_mode()" to make a Wx::App > work with threads, you''ve still got to try an App with threads, notice > it''s not working, scratch your head, google "wxRuby+threads" and see > what comes back. > > So I''d rather users found a page that says: "use Timer like this". Then, > people who just want to copy and paste three lines of Wx::Timer code can > do so and forget about it. People who care more will understand what''s > going on, and perhaps why they''d like to do things slightly differently. >Understandable, but I''m looking at the development of the library, in a whole. Looking at it as a way to ensure learning curves remain to a minimal status, as wxRuby has a very low learning curve as it is. Might need to reference a few sections to figure out exactly what you want, but in the long run, it''s pretty easy to remember what you''ve learned previous, which also could be argued for using the 3 line code to initiate the Threaded model.> OK, can you post for discussion first please? And consider whether > ThreadedApp at least might live in wxSugar for a bit; that project''s > been valuable in refining everything else we''ve done with wx''s ruby layer. >I have no problems with Wx::ThreadedApp to be in wxSugar for a bit, to figure out the code, and get the API Finalized. Yeah, it''s going to take a bit of tweaking, and stuff to get it right, but I''m largely testing the code out, to ensure it''s working the way it''s meant to, then to pass it along with bugs and errors riddled through it.> Additions to the core wx API have been *very* sparse and cautious - > barely two or three public methods (almost all the code in > lib/wx/classes deals with internals like GC and error checking). E.g. > I''m not sure "set_threaded_interval" isn''t just adding a method for the > sake of method. It doesn''t really do what it says - child threads aren''t > guaranteed to run at that interval. >Possibly yes, possibly no on the "guaranteed to run at that interval" Many factors play into this, and it can never be a guarantee that everything will work as expected when Threads play into the mess, even natural OS Threads can cause major headaches, and don''t always run at the intervals that programmers write them to be executed at. Largely, the environment that the threaded application is running in, can degrade, and throw off the timing of the execution of said thread from what was originally desired. Hence why, even in C/C++ Programs, you still get large display lags, when there are several threads trying to run, in umpteen amount of processes at the same time on a Single CPU core.> Just a comment on file/class matching conventions - code that extends > Wx::Foo should be in lib/wx/classes/foo.rb. So code extending Wx::App > should be in lib/wx/classes/app.rb not thread.rb. We need to think where > ruby-only subclasses might live? >Understandable, and I agree 100 percent with the naming conventions, which is why threadedapp.rb is now there in classes, as a test phase in my sandbox. Not actually going to submit it to the SVN in that manner. Possible idea, is to use a directory such as: lib/wxruby/classes, or something similar, and notate it in the Docs, as well as in wx.rb, so that if people are curious, and want to know, can look at this, and see what is going on.> Also please don''t touch or add a method without ensuring that docs are > in place and correct. >Not a problem, I will ensure to have Documentation with methods, so that it can be understandable as to how everything works, before getting them uploaded.> I hope I don''t sound negative - I''m really glad you''re working on > Sockets b/c as I have neither time nor knowledge to do so - I''d just > like you to be less hasty in committing when working on major core classes. >No negativity, offense or mis-understanding taken. Understand, that this is my first major project that I''ve worked on with a library. Most of what I do, is simply suggest to the authors of possible fixes, give them some example code, and that''s the extent of what I do. My haste, is merely the idea of ensuring the product gets out there to the users. I will reserve my ambition to a more moderate level, so as to ensure that things are discussed properly, and thoughtfully, before lunging ahead with bashed out code. ;-) Speaking of bashed out code. Wx::ThreadedApp is working properly, with all expectations of what it is suppose to do. I will be uploading that to the wxSugar project SVN, if you guys approve of the API, which is what I have implemented so far: Constants: Wx::ThreadedApp::THREAD_TIMER_ID Unique ID created for Timer to be used with context switching. Wx::ThreadedApp::DEFAULT_TIMEOUT Default timeout used for the Timer to execute the context switching. (25 milliseconds) Instance Methods: Wx::ThreadedApp#on_init() Used to initiate the Timer, and setup the Event Handlers for said Timer, to run the Context Switching. Timer object is stored in @__thread_timer on Wx::ThreadedApp Wx::ThreadedApp#set_interval() -and- Wx::ThreadedApp#start_threads() Both methods are the same, as they ensure that the Timer is stopped, and restarted with the new delay in milliseconds. If -1 is passed, DEFAULT_TIMEOUT will be used. Wx::ThreadedApp#stop_threads() Stops the timer that will pass the context switch to a new thread. This will not destroy any threads, simply stop the context switching. Once re-started with set_interval() or start_threads(), it will immediately start back up from where the thread left off at, or can be programmed to start the thread whereever you want, through instance, class or global variables. I am currently finalizing the code, and running my hammer over the code to riddle out the bugs for the Socket''s API. From the Client and Server demo I''ve used before, it seems to be executing quite nicely, and keeps the code very readable, and understandable to go through, and figure out what is doing what. Right now, I''m keeping the API simple, and trying not to use as much of the WxWidgets code that they use to implement their sockets, for all the extra methods, and such. The only other methods I might implement is for ReadMsg() and WriteMsg() but more then likely will be setup differently. And as I''m not having all the stuff that wxWidgets core has to look out for, as far as Error codes, and the specific event of SOCKET_INPUT, I''m going to leave those constants out of the API, once everything has been corrected, and working as expected. Documentation on this library will be fun to say the least. I will switch the area in which the wxThreadedApp, and wxSocket libraries will be stored, to the wxSugar directory, so as to keep them clear. I don''t know how to remove the stuff I''ve uploaded concerning the thread.rb, and threaded2.rb from the SVN Server, so if you could, please remove those, so as to not mess up any final build from the SVN, it would be great. Thanks. L8ers, Mario Steele -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20071105/4d2f3984/attachment.html
Mario Steele wrote:> Speaking of bashed out code. Wx::ThreadedApp is working properly, > with all expectations of what it is suppose to do. I will be > uploading that to the wxSugar project SVN, if you guys approve of the > API, which is what I have implemented so far:This looks OK to me for addition to wxSugar. I''m up for integrating the Sockets libraries too into core later once they''ve been tested and refined.> Wx::ThreadedApp#set_interval() -and- Wx::ThreadedApp#start_threads() > Both methods are the same, as they ensure that the Timer is > stopped, and restarted with the new delay in milliseconds. If -1 is > passed, DEFAULT_TIMEOUT will be used.I''d suggest that set_interval restart the threads if they are running, but not if they''re not (not sure if this is what you intended, but the previous code you committed didn''t behave that way). Have two pairs of methods start/stop_threads and get/set_interval> I am currently finalizing the code, and running my hammer over the > code to riddle out the bugs for the Socket''s API. From the Client and > Server demo I''ve used before, it seems to be executing quite nicely, > and keeps the code very readable, and understandable to go through, > and figure out what is doing what.Perhaps you could post a revised version of the Client/Server demo to see how it changes and hopefully simplifies. The sample in the wxRuby core shouldn''t depend on something in wxSugar though.> I will switch the area in which the wxThreadedApp, and wxSocket > libraries will be stored, to the wxSugar directory, so as to keep them > clear. I don''t know how to remove the stuff I''ve uploaded concerning > the thread.rb, and threaded2.rb from the SVN Server, so if you could, > please remove those, so as to not mess up any final build from the > SVN, it would be great. Thanks.No problems, will do a sweep before the next release. cheers alex
Alex Fenton wrote:> Mario Steele wrote: > >> Speaking of bashed out code. Wx::ThreadedApp is working properly, >> with all expectations of what it is suppose to do. I will be >> uploading that to the wxSugar project SVN, if you guys approve of the >> API, which is what I have implemented so far: >> > This looks OK to me for addition to wxSugar. I''m up for integrating the > Sockets libraries too into core later once they''ve been tested and refined. > >> Wx::ThreadedApp#set_interval() -and- Wx::ThreadedApp#start_threads() >> Both methods are the same, as they ensure that the Timer is >> stopped, and restarted with the new delay in milliseconds. If -1 is >> passed, DEFAULT_TIMEOUT will be used. >> > I''d suggest that set_interval restart the threads if they are running, > but not if they''re not (not sure if this is what you intended, but the > previous code you committed didn''t behave that way). > > Have two pairs of methods start/stop_threads and get/set_interval >That was my intention, but my mind sometimes wanders off into no-where land, and tends not to bring that part into what I''m trying to do. I''m also thinking of possibly a better way of setting it up, cause of what you stated, that there may be those that want a finer grain of control, if not possibly writing this library up to be a sort of ThreadControlGroup, where you can setup individual groups of threads, on different timers, so that they can execute at these intervals. Say, you have a reading interval, that you want done at 500ms, instead of 25ms, but you have a Network IO that needs to run at 25ms. ThreadControlGroups would help in separating those, and put them into a finer grained control environment. What do you think?>> I am currently finalizing the code, and running my hammer over the >> code to riddle out the bugs for the Socket''s API. From the Client and >> Server demo I''ve used before, it seems to be executing quite nicely, >> and keeps the code very readable, and understandable to go through, >> and figure out what is doing what. >> > Perhaps you could post a revised version of the Client/Server demo to > see how it changes and hopefully simplifies. The sample in the wxRuby > core shouldn''t depend on something in wxSugar though. >I will post the new Sockets demos to the wxSugar, since they rely on both ThreadedApp (Right now), and the new Socket''s library. But still working a few quirks and bugs out of the code, so it will be a bit before I post anything. Just so you know.>> I will switch the area in which the wxThreadedApp, and wxSocket >> libraries will be stored, to the wxSugar directory, so as to keep them >> clear. I don''t know how to remove the stuff I''ve uploaded concerning >> the thread.rb, and threaded2.rb from the SVN Server, so if you could, >> please remove those, so as to not mess up any final build from the >> SVN, it would be great. Thanks. >> > No problems, will do a sweep before the next release. >Thanks. That also reminds me, when I do the .tar.gz package for the release of wxRuby 1.9.1 and 1.9.2, it''s missing stuff like accessors.rb, keyword_ctors.rb and keyword_defs.rb when I do my custom build on my Linux platform (Remember, different GLIB Version, so Gem is not compatable with my system.) Just thought I would let you know about that, as I think the rake for the tar.gz misses these files since their recently added to the core of the Library. L8ers, Mario Steele -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20071106/94b788ad/attachment-0001.html