| |
My only concern with these proposed changes is possible increased memory
usage.
Encapsulation, error reporting, thread synchronisation etc are nice; but
with just 32k of RAM I would question whether these are appropriate for
some applications. For my final year Computer Science project (a maze
naviagting robot) I had to disable dynamic linking + some LegOS features
to get it to fit into RAM.
Of course, if conditional compilation can be used to disable these
features (as can be done with mem management, etc) at present, then this
is less of a problem.
I do wonder though if there is a danger here that LegOS will become
bloated as people add 'hey, what a neat idea' kind of features - e.g.
filesystem, clock, etc. Just a thought, anyway.
However, reliable networking support would definitely be a plus - I had
to design my own transport + presentation layers for my project. I was
intending to tidy them up + release them, but if something similar is
planned for LegOS, I may not bother.
Kieran
|
|
Message has 1 Reply:
 | | Re: API changes
|
| (...) I don't imagine that these changes will increase memory usage much, since they are largely just re-working existing features. I will look into the memory usage before releasing, though. In fact, I think that after I redid the networking a bit (...) (23 years ago, 12-May-01, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | API changes
|
| In using legOS, I've found that many of the design decisions seem somewhat backwards, and I think that this is due to a desire to keep the interface as similar as possible to NQC. I was wondering what people would think about changing the core API (...) (23 years ago, 10-May-01, to lugnet.robotics.rcx.legos)
|
6 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
