On Wednesday 14 Jan 2004 3:04 pm, Wiggins d Anconia wrote: > > On Tuesday 13 Jan 2004 5:05 pm, Wiggins d Anconia wrote: > > > > On Tuesday 13 Jan 2004 3:04 pm, James Edward Gray II wrote: > > > > > On Jan 13, 2004, at 6:24 AM, Gary Stainburn wrote: > > <snip old posts> > > > Hi, > > > > I've not responded to these two comments yet as my head was struggling > > enough with the read of the thread. > > No problem, lots to take in, but good information... > > > I've looked at POE before, and at the time thought it looked far too > > complicated. However, looking again now may produce a different > > opinion. I still think that it will be a bit OTT for my project. > > It is pretty complicated, the tough part is that so is your project ;-)! > As the others have expressed. I am concerned (take that loosely) that, > while your attempts to learn OOP in this context are certainly > worthwhile and giving you progress, the OOP may be hiding the > complicated part of your problem that is yet to come which has been > mentioned briefly before. In other words how do you keep the parts of > the system running in a constant nature while attempting to receive > inputs from external sources in possibly multiple ways. The problem I > foresee is that you have multiple objects that are all possibly > (usually?) doing something independently but also must detect and handle > signals from other objects in some unscheduled manner which is fine to > say, but the problem becomes that a single Perl process *blocks* > (usually), which essentially means your objects can't work independently > and concurrently. In more concrete terms, you have to have a way to have > a train move along a track, have a signal box receiving signals, having > a trainset manager (can't remember the name you gave it) inputting data > (aka using the controls), having the controls waiting for inputs and > handling them, etc. *at the same time* all the while with some way to > get the various parts talking while they work. The problem becomes how > to do this, how to prevent the blocking, three options come to mind (for > me) threads, forked separate processes (using IPC or shared memory > (yikes)), or some type of time slicing aka POE, Select, or Loop (group > have I missed any?). I am curious if the discussion about the "owner" > and managing all of those tasks is the reason why the object structure > hasn't been as obvious as it should. Essentially this is the jump that > must be made from simple scripts to long running programs, essentially a > server, where rather than serving data of some sort you are really > serving trainset events (which of course is just data), then a client > plugs in to control those events. I am thinking that you can resolve > your object system and make it seem like it will work, but when you go > to flip the on switch it is just going to sit there because how to get > the different parts moving hasn't been worked out fully in the design, > that or you will have a series of events that must happen in the > essentially in the same order at the same time, which is hardly like the > real life system you are trying to emulate. But then I could just be > off my rocker.... in the end if I am not loco, POE is going to be one > easy way to get this type of system running.
Now you're starting to scare me! I don't think that I'll have a problem with the various objects talking to each other, but I can definitely see the problem regarding multiple inputs. When running the signalbox training simulator there will be no external stimulus, just the input from the user. However, with the model train set I hope to have feedback confirming train movements etc. I like the server idea, and may well develop with that in mind. This would then enable the server to simply run the model and allow people running clients to log in to operate the different signalboxes. The interface to the model railway could also be remote then (headless Linux box under the model even). I guess I'll be taking a closer look at POE. On a side note: I'm developing on Linux because that's what my workstations are. However, I target audience will be mostly on Windows. I understand that ActiveState (?) have a .exe generator. If I start using networking, POE etc., will my app still be portable? What pitfalls will I need to look out for? > > > The idea of named parameters is worth considering as my project and > > therefore > > the methods is starting to get far more comprehensive and complex. > > Yeh, its extra work to get used to but worth it in the end... > > http://danconia.org -- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
