language and "built-in objects" in the new prop
ALIBE
Posts: 299
As the parallax team is heads down on coming up w/ the next rev of the Prop chip, I am curious in knowing if (and to the extent of coverage) you guys are planning on new language features and if there will be objects of "most widely used in nature" baked into the new prop
can someone comment
thanks
ALIBE
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
·
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
can someone comment
thanks
ALIBE
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
·
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
Comments
Since I'm not on the "Parallax Team", I can't offer anything other than some observations:
1) There will be a 3rd party C development system for the current Propeller within about 6 months. That's been announced here and I'm sure it will be pretty much on-time. My understanding is that it will produce code for a "large memory model" scheme that's been discussed here in detail that will execute at close to native cog speed, but will be more memory intensive than Spin interpretive code since it will be based on long word instructions rather than a more compact byte code. I suspect that, once the version 2 Propeller is defined in sufficient detail, that the compiler will be extended to be able to produce code for that as well, making good use of the additional instructions. The version 2 Propeller will be a better fit for this than the current Propeller, partly because of the larger memory and partly due to the added instructions (particularly multiply).
2) There's not a lot that needs to be added to the Spin language itself and little that needs to be added to the assembly language. My personal opinion is that there needs to be a relaxation of some of the rules on how the object hierarchy is handled. In particular, objects can be used to provide functionality to more than one object (like a display routine). How do you refer to an object to say "I want the same instance as everyone else", yet sometimes you may want more than one instance, like if you have two displays that you may want to share widely among other objects. This requires some kind of notational extension.
3) There needs to be some kind of macro preprocessing so that: 1) The language can be extended, particularly the assembly language. 2) You can have conditional compilation.
4) There are a variety of changes that need to be made to the compiler (as opposed to the language): 1) Some of the error checking needs to be improved and there needs to be an ability for the compiler to generate warning messages. 2) The compiler itself needs to be split off from the IDE, partly to support #3, but partly to make it possible to support other operating systems than Windows XP/Vista. 3) Obviously, the compiler will need to be able to generate code for either Propeller version. I would prefer to specify this with a compiler/IDE option that can be overwritten by an option directive in the source code.
That is the suggestions/recommendations for changes/improvements to the IDE/compiler/interpreter.
It would be a big help to everyone if there were an ongoing single place where we could see a summary of:
1. The suggestions submitted by the users, organized by IDE/compiler/interpreter.
2. The improvements/schedule that Parallax is planning to actually implement.
There are many ideas for improvement that we all see but they just seem to get lost in the noise, with no real feedback as to whether there is any plan/schedule to implement them. I know I have my pet list but sometimes it seems like more trouble than it's worth to post suggestions. If we knew our ideas would at least get summarized on a want list, it would encourage more people to try to help. It would also give Parallax something to prioritize when they're assigning projects...
I was hoping that the new prop will encompass a set of "in-built" object type behaviors.·Parallax has seen and got a lot of experience from this forum that there is at least a dozen objects that are being used by folks on a more regular basis - viz, TV, VGA, Servos, KB, Mouse, Graphics, Serial Comm, etc.· Objects that are most of the time needed or asked for by the consumer (us).These are all very useful to have as built in as opposed to having to worry abt DIY.· I believe implementing these at ASM level (since they would be built-in), will be very helpful.
I understand this is a different way of thinking than the current rev's behavior.
Having a dedicated "namespace" of features and built-in objects, will be HUGELY beneficial to have and frees up the dev to have him/her spend time doing other stuff
thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
·
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
The current crop of drivers have evolved piecemeal over time and probably ought to be cleaned up before the next Propeller version is available. For example, the keyboard and mouse drivers can be combined into one cog (someone did that already, but it needs to also work for both PS/2 I/O conventions ... Demo Board and Hydra). I've started on that, but it may be a while. The TV/VGA drivers need to be cleaned up so they're compatible at the user level and there's support for a compatible cursor in the TV driver. If conditional compilation is ever added, perhaps these can be combined into one source object. The FullDuplexSerial object could also be polished with a few additional methods added and, again if conditional compilation is added, the Extended Full Duplex Serial object could be better integrated, possibly made to work with other types of serial I/O like SPI and I2C like in the Stamp series' mostly compatible I/O statements.
Parallax is not going to have the time or resources to do this, but perhaps it could be done as a series of open source projects by users. There would have to be a series of project administrators and some discussion of ground rules for format, function, etc. and the trade offs between object size and functionality, etc. In a way, this has been going on already in terms of contributions to the Object Exchange, but the design and planning needs to be done as a group so there's some consistancy.
It didn't sound like the point you were trying to make nor did you explain that to the people who are supposed to have shot you down. The OO nature of spin isn't really the issue, Mike's really talking about managing code and coders, objects in spin are really just related collections of functions.
Graham
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Before including any objects, it may be worth letting us know which objects. I'm sure many of us are willing to offer a free peer review.
Eg. FullDuplexSerial - Nice object, but I don't use the Parallax version because it doesn't check for the stop bit! Also it can't be invoked on a single port from multiple objects - for debugging.
If it's gonna get stuck in the ROM then it's best to make sure that it's as good as it can be!
If I was given the choice in the current Propeller I'd ask to throw away the cos/sin/log and font tables. Give that space all back to me as RAM, as I don't use the tables.
Just my 10cents worth. (They've eliminated 1 & 2 cent coins in Australia - so the least you can run together is two 5 cent coins).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
ex- manual transmission - involves gear number tracking (remembering what gear your in), recalling shift points, and cordination with three foot pedals.
automatic trans - selection of foward/reverse direction, gas & brake pedal
while the automatic is much more user friendly, your loosing control over most of the transmission, like gear selection, shift points, and other tech stuff, (yeah, i'm an autobody/mech)
what i'm trying to say is much like the newly developed auto-stick transmissions in most mid grade cars now, might there be a way of keeping the power of functionality to the selected included objects while making them more user friendly to greenhorns like me. say you include some polished objects like the TV, VGA, KB, Mouse, Serial object in a propeller twice as fast with 4 times the memory (and I/O pins... we love I/O pins!)
Couldn't you arange it so setup of the features/options of each of these objects could be setup like a "preferences" page where "simple serial" could be configured from "extended full duplex serial" (or whatever the politicaly correct name is), something like a .ini binary file? like a double long that would act like DNA for the onboard objects that you configure to your liking.... arent there some longs you can view on the prop to get system info?
enough rambling, you guys get the picture. I say include the basic objects TV, VGA, Graphix, KB, mouse, serial (config-able to SPI/IC2), maybe some others like a memory card object or an audio object that can play back small files, cuz we don't get enough disrespect in our up-time, lol
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"