| | Re: text location for apps and q?
|
| (...) I just have to ask why you're doing this, just for the heck of it? I mean, the output device you're writing two can hold a whopping five characters at a time. I don't really see the benefit of changing to a more complicated interface. Of (...) (24 years ago, 26-Oct-00, to lugnet.robotics.rcx.legos)
| | | | Re: text location for apps and q?
|
| (...) You can't implement a true fork() anyway, since you don't have memory management and therefore can't copy the address space of the parent process. John A. Tamplin LiveOnTheNet.COM, Inc. jat@LiveOnTheNet.COM 2104 West Ferry Way 256/705-7007 - (...) (24 years ago, 26-Oct-00, to lugnet.robotics.rcx.legos)
| | | | Re: text location for apps and q?
|
| (...) for the output device thing, the lcd isn't the only device. sensors and motors are also can be implemented as files. (...) well it's still just an idea, maybe the fork() will turn out as rfork(). doesn't really matter now. but see my other (...) (24 years ago, 27-Oct-00, to lugnet.robotics.rcx.legos)
| | | | Re: text location for apps and q?
|
| (...) Ok, but why? Again, if you're just having fun, go for it, but don't expect it to be useful. Personally, the current interface is simple and highly functional, and a change to a file paradigm would just make it more complicated with no benefit. (...) (24 years ago, 27-Oct-00, to lugnet.robotics.rcx.legos)
| |