[REBOL] REBOL/View/Command guidance Re:
Hi Ryan, sounds good. The critical issue for me here would be to check that REBOL/Command can work well with the serial drivers you are using. Since in Linux / U*x systems, serial drivers are implemented as special files (if my memory serves me well, it's been ~ 15 years since I did serial programming on u*x machine), even REBOL/Core should be able to handle it using non-buffered file ports. That shouldn't be a problem, but I'd test it anyway. In MS OSs you would have to access the serial port through a dll. And this may be a little tougher to get right. REBOL's event-driven environment does not scale well to IRQ driven, or polling driven Serial I/O. Haven't played with Serial ports since Win 3.x, so again, my advice may be antiquated. If you run into problems, you may want to try using one of the thoroughly tested serial i/o libraries for MS Win, compile a dll application that does the low-level serial i/o stuff, and use REBOL/Command to interface with the dll. At 12:04 PM 5/30/00 -0700, you wrote: I need some guidance as to whether REBOL/View/Command has the capabilities for an upcoming project. A friend of mine is going to migrate a Visual BASIC security system product to another language and maybe even from the Win9x platform. This is a good time for him to learn REBOL, that is if REBOL/View and REBOL/Command will be able to handle the problem at hand. The system will need to communicate to two other devices via the serial port. I assume REBOL/Command will do that with the help of some serial driver programs. It needs to run solely with a touch screen interface, which operates like a mouse. REBOL/View should do this job I suppose. There needs to be the ability to have multiple terminals/clients, which run of a single server. I expect that REBOL/Command could help us there, since I could do that with REBOL/Core. I assume REBOL/View can work as a client to REBOL/Command. REBOL/View being a visual version of REBOL/Core and REBOL/Command being a binary executing version of REBOL/Core (amongst other things). Am I on the right track here? Will REBOL do this? --Ryan ;- Elan [: - )]
[REBOL] REBOL/View/Command guidance Re:
[EMAIL PROTECTED] wrote: I need some guidance as to whether REBOL/View/Command has the capabilities for an upcoming project. A friend of mine is going to migrate a Visual BASIC security system product to another language and maybe even from the Win9x platform. This is a good time for him to learn REBOL, that is if REBOL/View and REBOL/Command will be able to handle the problem at hand. The system will need to communicate to two other devices via the serial port. I assume REBOL/Command will do that with the help of some serial driver programs. Not a problem, lights on my parallel port tester are already blinking :-) It needs to run solely with a touch screen interface, which operates like a mouse. REBOL/View should do this job I suppose. Hmm, don't know what do you expect of REBOL/View, but I think touch screen should be irrelevant to REBOL/View directly, as it should be some kind of driver, which should do the work. There needs to be the ability to have multiple terminals/clients, which run of a single server. I expect that REBOL/Command could help us there, since I could do that with REBOL/Core. Maybe REBOL/Serve, as it will have tasking/threading, security (probably SSL?) etc. I assume REBOL/View can work as a client to REBOL/Command. REBOL/View being a visual version of REBOL/Core and REBOL/Command being a binary executing version of REBOL/Core (amongst other things). Am I on the right track here? Will REBOL do this? The only one question is what do you expect of REBOL/View gui. I would still more like to see /Core's multitasking ability than being dependant on /Serve, /Command and having to launch yet-another-rebol from harddrive. -pekr- --Ryan
[REBOL] REBOL/View/Command guidance Re:(2)
[EMAIL PROTECTED] wrote: Hi Ryan, sounds good. The critical issue for me here would be to check that REBOL/Command can work well with the serial drivers you are using. It all depends, but there is no problem with making a driver if needed. Since in Linux / U*x systems, serial drivers are implemented as special files (if my memory serves me well, it's been ~ 15 years since I did serial programming on u*x machine), even REBOL/Core should be able to handle it using non-buffered file ports. That shouldn't be a problem, but I'd test it anyway. Ah! Good point. I did'nt think about that. In MS OSs you would have to access the serial port through a dll. And this may be a little tougher to get right. REBOL's event-driven environment does not scale well to IRQ driven, or polling driven Serial I/O. Haven't played with Serial ports since Win 3.x, so again, my advice may be antiquated. If you run into problems, you may want to try using one of the thoroughly tested serial i/o libraries for MS Win, compile a dll application that does the low-level serial i/o stuff, and use REBOL/Command to interface with the dll. I have suffered a few of the pains and labors of the serial port on windows myself. Sounds like great advice. Thanks a whole lot, --Ryan At 12:04 PM 5/30/00 -0700, you wrote: I need some guidance as to whether REBOL/View/Command has the capabilities for an upcoming project. A friend of mine is going to migrate a Visual BASIC security system product to another language and maybe even from the Win9x platform. This is a good time for him to learn REBOL, that is if REBOL/View and REBOL/Command will be able to handle the problem at hand. The system will need to communicate to two other devices via the serial port. I assume REBOL/Command will do that with the help of some serial driver programs. It needs to run solely with a touch screen interface, which operates like a mouse. REBOL/View should do this job I suppose. There needs to be the ability to have multiple terminals/clients, which run of a single server. I expect that REBOL/Command could help us there, since I could do that with REBOL/Core. I assume REBOL/View can work as a client to REBOL/Command. REBOL/View being a visual version of REBOL/Core and REBOL/Command being a binary executing version of REBOL/Core (amongst other things). Am I on the right track here? Will REBOL do this? --Ryan ;- Elan [: - )]
[REBOL] REBOL/View/Command guidance Re:(2)
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I need some guidance as to whether REBOL/View/Command has the capabilities for an upcoming project. A friend of mine is going to migrate a Visual BASIC security system product to another language and maybe even from the Win9x platform. This is a good time for him to learn REBOL, that is if REBOL/View and REBOL/Command will be able to handle the problem at hand. The system will need to communicate to two other devices via the serial port. I assume REBOL/Command will do that with the help of some serial driver programs. Not a problem, lights on my parallel port tester are already blinking :-) It needs to run solely with a touch screen interface, which operates like a mouse. REBOL/View should do this job I suppose. Hmm, don't know what do you expect of REBOL/View, but I think touch screen should be irrelevant to REBOL/View directly, as it should be some kind of driver, which should do the work. There needs to be the ability to have multiple terminals/clients, which run of a single server. I expect that REBOL/Command could help us there, since I could do that with REBOL/Core. Maybe REBOL/Serve, as it will have tasking/threading, security (probably SSL?) etc. REBOL/Serve? Maybe. Tasking and threading would be real handy. I assume REBOL/View can work as a client to REBOL/Command. REBOL/View being a visual version of REBOL/Core and REBOL/Command being a binary executing version of REBOL/Core (amongst other things). Am I on the right track here? Will REBOL do this? The only one question is what do you expect of REBOL/View gui. I would still more like to see /Core's multitasking ability than being dependant on /Serve, /Command and having to launch yet-another-rebol from harddrive. Yes, /View is the big question now. Basically /View would need to present graphical represention of a building with buttons on it. When you push a unlock door button, /View would send the request to the server (/Core, /Command, or /Serve) that would handle the request. Some method of accessing controls not in immediate view would be nice, like multiple pages or scroll bars. Another thing is a way to put /View into a kiosk (full screen no escape) mode. However I am sure RT would add this functionality without too much lobbying. --Ryan -pekr- --Ryan
[REBOL] REBOL/View/Command guidance Re:(3)
[EMAIL PROTECTED] wrote: I assume REBOL/View can work as a client to REBOL/Command. REBOL/View being a visual version of REBOL/Core and REBOL/Command being a binary executing version of REBOL/Core (amongst other things). Am I on the right track here? Will REBOL do this? The only one question is what do you expect of REBOL/View gui. I would still more like to see /Core's multitasking ability than being dependant on /Serve, /Command and having to launch yet-another-rebol from harddrive. Yes, /View is the big question now. Basically /View would need to present graphical represention of a building with buttons on it. When you push a unlock door button, /View would send the request to the server (/Core, /Command, or /Serve) that would handle the request. Some method of accessing controls not in immediate view would be nice, like multiple pages or scroll bars. It can be done imho in current state of things. However, I don't understand that client/server aproach. What I need is ability to load View as a component to /Command version, or just tasking/threading together with shell execution moved to /Core (/View). I would like to see REBOL being more async, as /View's capability of multiple windows is nice, but what for, if we are e.g. downloading some image to one window, the behavior of REBOL is its blocked state. Another thing is a way to put /View into a kiosk (full screen no escape) mode. However I am sure RT would add this functionality without too much lobbying. Hmm, you can take the whole screen. It's there from beta 2 IIRC. Anyway, we should move such discussion to Ally list -pekr- --Ryan -pekr- --Ryan
