oopic-compiler-devel Mailing List for OOPic Compiler
Status: Planning
Brought to you by:
ndurant
Menu
▾
▴
oopic-compiler-devel — A mailing list for discussion of design and development of the OOPic compiler
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(36) |
May
(52) |
Jun
(17) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(6) |
|---|
|
From: Neil D. <nd...@us...> - 2004-12-29 01:44:53
|
Neil Durant wrote: > When I get round to it I'll upload the code to the CVS code repository on > sourceforget.net. In the meantime, I thought I'd just attach the thing > to a posting. Hmm. Unfortunately Sourceforge is currently blocking .zip attachments, presumably as an anti-virus measure. So I've uploaded the file here: <http://www.neildurant.co.uk/public/preproc.zip> Enjoy! Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-12-29 01:21:42
|
Hi guys, Over Christmas I knocked together the beginnings of a C preprocessor in Python. It was mostly as a project to teach me Python, but I think I've managed to get enough functionality into it to be useful. Perhaps it could form the beginnings of this OOPic compiler we've been discussing. This is totally separate from Andy's OOPic-specific preprocessor, and it has nothing OOPic-specific about it. It just implements a subset of the standard C preprocessor directives. I suspect that if we're creating a compiler from scratch for the OOPic, many of the tasks handled by Andy's preprocessor such as constant handling etc, should be done by the compiler itself, as it will need to fully tokenise/parse the source code anyway. Here's what the preprocessor can currently handle: #include "path/to/file.h" (including ../../file.h etc) #include <file.h> using current directory and paths specified in INCLUDE environment variable (: is used as the delimiter) #define MACRO substitution text including recursive macro substitution, eg macros defined in terms of other macros. However parameterised macros and multi-line macros (using a trailing backslash) are not yet implemented #undef For undefining macros #ifdef NAME and #ifndef NAME For enabling/disabling sections of code depending on existence of a macro #if expression For enabling/disabling sections of code depending on result of an expression. Expressions can be as simple as 0, or as complex as something like !(MACRO + 5 > OTHERMACRO*(PI -7)) etc #elif expression For further #if type clauses #else Can be used with #if, #ifdef and #ifndef #endif For use with #if, #ifdef, #ifndef and #elif Furthermore, the preprocessor strips out comments (C and C++ style), and tracks initial file and line-numbers (so that errors/warnings given by the subsequent compilation stage can provide the original line numbers, regardless of #inclusion, #ifdefs changing the number of lines of code etc). I believe I have added sufficient error-checking to alert the developer to incorrect use of the preprocessor directives (currently the preprocessor will abort all preprocessing upon the first fatal error, although it will continue if warnings are generated). I've tested it on the Mac, but as it's Python it should work perfectly well on Windows and Linux without change. However there may be some issues I hadn't considered. To run it you'll need Python installed (www.python.org), then just unzip the attached file into a folder, and from a DOS box (in Windows) or console (Mac/Linux/other), type something like: python preproc.py myfile.c ...where myfile.c is the file you want to preprocess. Type this to get full usage information (eg command line options etc): python preproc.py --help If you have the time/inclination, check it out, and please hammer it with some complex preprocessor work (especially #if expressions) to see if you can break it and find bugs. Any suggestions, feedback, bug reports, bug fixes, or code for other preprocessor directives very welcome!!! When I get round to it I'll upload the code to the CVS code repository on sourceforget.net. In the meantime, I thought I'd just attach the thing to a posting. Happy New Year, Neil -- Neil Durant <nd...@us...> |
|
From: Andrew P. <wa...@ic...> - 2004-12-17 10:10:22
|
At 12:56 AM 17/12/2004 +0000, Neil Durant wrote: >Following a bit of abortive discussion on the OOPic mailing list about an >OOPic emulator, it strikes me that actually it wouldn't be so hard to do. >We have the spec of the byte code, and it's a relatively simple stack-based >machine. I guess the hard part would be modelling the VCs, but again, not >all that difficult. A useful emulator has to handle real world programs - large, complicated ones. Those programs need lots of simulated inputs that mimic what will be seen in real life. I see that as a problem area. Also, a simulator that doesn't mimic all the OOPic's bugs (like the broken LCD handling) will make the user's life miserable. ...Andy |
|
From: Neil D. <nd...@us...> - 2004-12-17 02:29:53
|
D. Daniel McGlothin wrote: > Based on the Python discussion earlier, I introduced a work collegue to it, > and he went ahead and wrote a PLC (ladder logic) program > comparison/differences tool. I still have to write my first "Hello World", > although I have read the manual and think I have the gist of the language. I find that once you "dig in", with the manual within easy reach, it's fairly easy to be productive with Python. I've found that it's also exceptionally well suited to what we're doing, at least the text lexing/parsing side of things. The amount of code I've written so far for the preprocessor would have taken several times more code if written in C, and all the string handling would have been painful in comparison! Symbol table? Piece of cake! No need to implement a hash table or anything. And it looks like it will be extremely good at handling the complex data structures (trees etc) in the core of the compiler. Incidentally, I've been reading a book about the assembly code generation aspect of compiler design, and it's truly fascinating and far deeper than I had imagined. I suspect there will be lots of scope for interesting optimisations with that aspect on the OOPic compiler. Furthermore I've been thining about the linker side of things, and I don't think that will be too hard to do, once we clarify the required memory organisation of an OOPic program image. I'm really excited about getting this project underway (half for the satisfaction of writing a fairly complex piece of open source software, and half for the practical aspect of making the OOPic more usable!). It's just a matter of available free time! > Once the emulator is written, then why not just compile it directly to > PIC/SX/AVR chips and bypass the oopic altogether? I suppose that is > probably going a bit father than where we are headed, though. And if we are > up to that level of effort, wouldn't we be writting directly for the chips > already? I guess the tricky part is making the microcontroller actually run the code fast enough. It's not too difficult to make a multi-gigahertz desktop machine act like a little microcontroller, but actually performing those calculations on a little chip is another matter! Still, worth investigating if we ever reach that stage and have the inclination! > Incidently, have you noticed the recent release of Parallax's SX/B basic > preprocessor for the SX chips? No, but I have now! Looks like interesting technology! Neil -- Neil Durant <nd...@us...> |
|
From: D. D. M. <dd...@mc...> - 2004-12-17 01:20:43
|
Based on the Python discussion earlier, I introduced a work collegue to it, and he went ahead and wrote a PLC (ladder logic) program comparison/differences tool. I still have to write my first "Hello World", although I have read the manual and think I have the gist of the language. Once the emulator is written, then why not just compile it directly to PIC/SX/AVR chips and bypass the oopic altogether? I suppose that is probably going a bit father than where we are headed, though. And if we are up to that level of effort, wouldn't we be writting directly for the chips already? Incidently, have you noticed the recent release of Parallax's SX/B basic preprocessor for the SX chips? Daniel ----- Original Message ----- From: "Neil Durant" <nd...@us...> To: <oop...@li...> Sent: Thursday, 16 December 2004 19:56 Subject: [Oopic-compiler-devel] Emulator > Following a bit of abortive discussion on the OOPic mailing list about an > OOPic emulator, it strikes me that actually it wouldn't be so hard to do. > We have the spec of the byte code, and it's a relatively simple stack-based > machine. I guess the hard part would be modelling the VCs, but again, not > all that difficult. > > Btw, regarding the OOPic compiler, I'm half way through writing a > preprocessor for it, in Python, and it's fitting together nicely. I'm > going to get some time over Christmas to work on it, so I should have > something usable to upload by the New Year. I chose to start on a > preprocessor because (a) it would be useful, and (b) it's a gentle > introduction to Python for me, before embarking on the compiler fully. > > Have a good Christmas, guys! > > Neil > -- > Neil Durant > <nd...@us...> > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel |
|
From: Neil D. <nd...@us...> - 2004-12-17 00:56:12
|
Following a bit of abortive discussion on the OOPic mailing list about an OOPic emulator, it strikes me that actually it wouldn't be so hard to do. We have the spec of the byte code, and it's a relatively simple stack-based machine. I guess the hard part would be modelling the VCs, but again, not all that difficult. Btw, regarding the OOPic compiler, I'm half way through writing a preprocessor for it, in Python, and it's fitting together nicely. I'm going to get some time over Christmas to work on it, so I should have something usable to upload by the New Year. I chose to start on a preprocessor because (a) it would be useful, and (b) it's a gentle introduction to Python for me, before embarking on the compiler fully. Have a good Christmas, guys! Neil -- Neil Durant <nd...@us...> |
|
From: Andrew P. <wa...@ic...> - 2004-10-19 05:10:26
|
At 12:57 AM 19/10/2004 +0100, Neil Durant wrote: >Hiya folks! > >Long time no traffic on this list! Just thought I'd post something to see >if everyone is still interested in going ahead with this project? I thought you'd have it done by now! >After the discussion about using Python as an implementation language for >the OOPic compiler, I bought a book on Python and have spent the last >couple of months learning it, and I have to say, it's an ideal language for >this kind of project. I kept thinking as I read parts of the book, "That >would be excellent for writing a parser" or suchlike. And the >platform-independent aspect comes for free. > >So now, having finished the book, I'm keen to launch into some >development, and I really think we should use Python! I don't think I'll be doing my part in Python, but that doesn't mean others can't do their modules that way. >Thoughts? Let's get this project moving! I've made available my initial efforts at a .oex file disassembler; it's still fairly rough, but hopefully it will inspire y'all. It's at: <http://home.ica.net/~phoenix/wap/OOPic/OEX-VIEW.ZIP> The .c file is the original OOPic source code and the .txt file is the disassembler output of the .oex file. The .xlat file has to be built by the human in charge... I'd be interested in knowing how the disassembler handles your own .oex files. ...Andy |
|
From: Brian <br...@po...> - 2004-10-19 01:56:20
|
Neil-- I got pretty disillusioned with the OOPic after spending hours over the summer trying to get the serial interface to work. Despite assurances from the OOPic book author that this interface works, I didn't find it to be at all stable. While I don't doubt there are folks who have stable serial transfer working, they don't seem too keen on sharing their secrets. I'll monitor the list here for a bit and see if I can get my interest up again... --Brian On Tue, Oct 19, 2004 at 12:57:02AM +0100, Neil Durant wrote: > Hiya folks! > > Long time no traffic on this list! Just thought I'd post something to see > if everyone is still interested in going ahead with this project? > > After the discussion about using Python as an implementation language for > the OOPic compiler, I bought a book on Python and have spent the last > couple of months learning it, and I have to say, it's an ideal language for > this kind of project. I kept thinking as I read parts of the book, "That > would be excellent for writing a parser" or suchlike. And the > platform-independent aspect comes for free. > > So now, having finished the book, I'm keen to launch into some > development, and I really think we should use Python! > > Thoughts? Let's get this project moving! > > Neil > -- > Neil Durant > <nd...@us...> > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > |
|
From: Neil D. <nd...@us...> - 2004-10-18 23:57:09
|
Hiya folks! Long time no traffic on this list! Just thought I'd post something to see if everyone is still interested in going ahead with this project? After the discussion about using Python as an implementation language for the OOPic compiler, I bought a book on Python and have spent the last couple of months learning it, and I have to say, it's an ideal language for this kind of project. I kept thinking as I read parts of the book, "That would be excellent for writing a parser" or suchlike. And the platform-independent aspect comes for free. So now, having finished the book, I'm keen to launch into some development, and I really think we should use Python! Thoughts? Let's get this project moving! Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-06-18 06:11:20
|
Brian wrote: > --I noticed the consensus is to use C for this project. While I'm > comfortable with that, won't this become something of a maintenance > nightmare to support several different platforms? Has any > consideration been given to writing some or all of this project in a > truly portable language such as Python? I've been playing with Python a bit over the last week or so, and I love it!! It seems very easy to get into, and quick to develop with. Furthermore, it's really straightforward to use pieces of C code within a Python program, and in fact some people apparently use Python for prototyping, and then work through the various Python modules rewriting them in C/C++ if and when they need extra speed (however Python is very fast anyway). Translated into our project, it means we could write in Python, and in the unlikely scenario that we need to use C for something, we could, without any problem. Another nifty thing is that you can create "frozen binaries" which are single executible files that contain the compiled Python byte-code, along with a small Python virtual machine. In other words, you can ship this single executable, with nothing else, and it'll run on the chosen target platform. This will make life extremely easy for installing the OOPic compiler on Windows machines, as we would not need an installer, and would not have to worry about installing Python etc. Ideal for OOPic users who just want an easy life. Another really nifty thing about Python is that you can run your code, with no need to port, on Palm and PocketPC based PDAs, Ataris, Amigas, VMS mainframes and Cray supercomputers! Although I doubt there'll be many OOPic users doing this, it's a pretty cool selling point that our compiler would run on all of those platforms as well as the usual Windows/Mac/Linux. In fact the Palm aspect is interesting, because of the SCP example in Dennis' book. In conjunction with what he writes, you could use a Palm-based PDA as a development environment, editing/compiling code and uploading it to the OOPic, entirely separated from a conventional computer! So I think my current vote is swinging more over to the Python side now, than the C side.... :-) Anyone else got any further thoughts? Still looking forward to Andy's thoughts on all this...... Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-06-05 16:38:43
|
I've been having a look at the parsers / compiler generators that Brian mentioned (http://www.python.org/topics/parsing.html), and there are plenty of options, all with varying degrees of development, features etc. One of them, Spark, has a very interesting tutorial describing the process of creating a compiler using Spark, which gives some very interesting insights into creating a compiler using Python. I'm not suggesting we necessarily use Spark, but I think the article is well worth a read, as it clarifies how the lexing, parsing, semantic analysis and code generation all fit together. The article is here: <http://www.foretec.com/python/workshops/1998-11/proceedings/papers/aycock-little/aycock-little.html> Whether we use Python or C, or whether we use Spark or not, I think this article is worth reading. I have a 2-inch thick book on compiler design which is pretty heavy reading, but the above article is quite readable. Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-06-05 16:30:02
|
Brian wrote: > For this project, I'm not partial. However, we might want to check > with Scott first to see if there is any information we are receiving > from him (code, etc.) that we do *not* have the right to release under > an open-source license (i.e., there are no patent issues, IP rights > etc.). Definitely agreeed!! From Scott's attitude so far he has seemed pretty open and flexible. However it would be only courteous to check with him, and having a comment from him agreeing to our licence terms ought to shield us from hassles in the future. > Also, note that the BSD license allows 3rd parties to modify the code > base without having to release modified source code (i.e., release > under a closed-source license, much like Microsoft has done with major > portions of BSD-licensed network/TCP/IP stack code). Some folks > favor this appropach in that the BSD license doesn't "taint" future > forks by requiring release under the same open licensing scheme. Of > course, the GPL purists believe this simply encourages people to steal > the hard work of others without requiring them to "give back" to the > open source community. I tend to be cautious about BSD-style licenses. I think I would feel aggrieved if I contributed a load of code, free, to the open-source world, and then some company subsequently took my work and released it without the code, and sold it. If my understanding of the BSD licence is correct, it permits that - am I right? > A license worth looking at is the Mozilla Public License...this one > has a provision that in the event of patent-based challenges, the > offending code can be removed from under the provisions of the MPL. > With the GPL, it's pretty much an all-or-nothing deal: If any part of > your code is found to be infringing, the entire code base is at risk > (just check out http://www.groklaw.com to see this attack on the GPL > in action!). That does sound worth considering. I can imagine parts of the code generation phase being tied up with IP or patents etc (but probably not), whereas the parser side would be entirely unconnected. Preserving the ability to compartmentalise what we do could be valuable. Neil -- Neil Durant <nd...@us...> |
|
From: Brian <bri...@po...> - 2004-06-05 16:13:16
|
On Sat, Jun 05, 2004 at 08:09:21AM -0400, D. Daniel McGlothin wrote: > All, > > As a matter of procedure, has there been a 'license' or 'copyright' terms > decided upon? > > A quick survey of the discussion so far didn't sow any, and I do not recall > any such discussion. > > Does SourceForge 'impose' any license terms? (I didn't check.) Daniel-- I believe SourceForge requires an open-source license that is compatible with the open source definition (and licenses) listed at OSI (http://www.opensource.org/licenses/index.php). For this project, I'm not partial. However, we might want to check with Scott first to see if there is any information we are receiving from him (code, etc.) that we do *not* have the right to release under an open-source license (i.e., there are no patent issues, IP rights etc.). Also, note that the BSD license allows 3rd parties to modify the code base without having to release modified source code (i.e., release under a closed-source license, much like Microsoft has done with major portions of BSD-licensed network/TCP/IP stack code). Some folks favor this appropach in that the BSD license doesn't "taint" future forks by requiring release under the same open licensing scheme. Of course, the GPL purists believe this simply encourages people to steal the hard work of others without requiring them to "give back" to the open source community. A license worth looking at is the Mozilla Public License...this one has a provision that in the event of patent-based challenges, the offending code can be removed from under the provisions of the MPL. With the GPL, it's pretty much an all-or-nothing deal: If any part of your code is found to be infringing, the entire code base is at risk (just check out http://www.groklaw.com to see this attack on the GPL in action!). --Brian |
|
From: Neil D. <nd...@us...> - 2004-06-05 14:41:23
|
D. Daniel McGlothin wrote: > However, since the firmware commands (the op-codes) also vary by version, > won't the generator also need to be firmware aware? I've just spotted something else in the op-codes. Look at op-code 128, "Aversion_Version". The description says: "Compares the top stack item to the firmware version. Resets the OOPic if not equal or above." This suggests the OOPic is backwards-compatible with code targeting older OOPics, otherwise this instruction would be pointless. So this indicates that our code generator can be firmware-independent for all of the op-codes supported on the first firmware version, and then we can have conditional logic to allow the use of newer op-codes when targeting newer firmware versions wherever it is appropriate. My gut feeling is that the newly-added op-codes are either to allow optimisations to be made, or special instructions needed for the newer VC objects. Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-06-05 14:21:32
|
D. Daniel McGlothin wrote: > > I think we should be able to use the same code generator. I would > > suggest that we pass in a parameter to the compiler to specify the > > firmware version, and the parser will throw an error if the input code > > includes stuff not allowed for that firmware version. Once the parser > > has successfully parsed the input code and generated an internal > > representation, the code generator should just be able to do its stuff, > > regardless of the firmware version (I think). It sounds to me as > > though the code generator should generate exactly the same code > > irrespective of firmware version setting, as long as the input code is > > legal on the respective firmware versions. > > > > If I'm right about this, all we need to do is put some conditional > > logic in the parser to disallow certain things, which I imagine would > > simply be the instantiation of VC objects that aren't supported on a > > given version. > > I think you are partly right. > > The parser will need to filter by firmware so as to not allow unsupported > objects. > > However, since the firmware commands (the op-codes) also vary by version, > won't the generator also need to be firmware aware? Yes, you're right, I wasn't thinking straight. We will need the code generator to know which op-codes are permissible for a given version of the firmware. I imagine most of the code generation will use "standard" instructions available on all firmware, but perhaps newer firmware supports instructions that allow more optimisations to be made etc. Looking at opcode 251, "CommandSet2", it looks like this might be where new instructions have been added from previous firmware versions. So it looks like each version of the firmware is backwards-compatible with the older instruction sets at least. I can confirm this because several times I have successfully run code on my 2+ which I'd accidentally compiled for an older version of the firmware. We only have the B.2.x+ instruction set documentation at the moment, so I guess that's all we can really target. We should ensure that both the parser and the code generator are capable of being aware of what input code is legal and what output instructions are legal, for a given firmware version. For maintainability, I suspect it would be best to do this with conditional logic, rather than having mutliple versions of the code generator. At some point it would be nice if we could get hold of documentation for the op-codes supported on older versions of the firmware. Neil -- Neil Durant <nd...@us...> |
|
From: D. D. M. <dd...@mc...> - 2004-06-05 13:59:45
|
Neil, > > 3. How would the project accomodate different versions of the firmware? Is > > it a matter of a different code generator for each firmware, or does one > > generator handle the differences conditionally? > > I think we should be able to use the same code generator. I would suggest > that we pass in a parameter to the compiler to specify the firmware > version, and the parser will throw an error if the input code includes > stuff not allowed for that firmware version. Once the parser has > successfully parsed the input code and generated an internal > representation, the code generator should just be able to do its stuff, > regardless of the firmware version (I think). It sounds to me as though > the code generator should generate exactly the same code irrespective of > firmware version setting, as long as the input code is legal on the > respective firmware versions. > > If I'm right about this, all we need to do is put some conditional logic in > the parser to disallow certain things, which I imagine would simply be the > instantiation of VC objects that aren't supported on a given version. I think you are partly right. The parser will need to filter by firmware so as to not allow unsupported objects. However, since the firmware commands (the op-codes) also vary by version, won't the generator also need to be firmware aware? Daniel |
|
From: Neil D. <nd...@us...> - 2004-06-05 13:35:56
|
D. Daniel McGlothin wrote: > As a matter of procedure, has there been a 'license' or 'copyright' terms > decided upon? No. > Does SourceForge 'impose' any license terms? (I didn't check.) All it imposes is that projects should be open-source. When I set up the Sourceforge project I was given a long list of different open source licenses to choose from (just for informational purposes for people looking at the project site) and I just put GPL because it's pretty much the most common open source license and one I've used before on various projects. I put this pending a proper discussion about it later, and it's easy to change if. > If this is an open issue, my instinct would tell me to promote this to a top > priority. Yes, we should pin down the license terms before we upload any of our code to Sourceforge (where it becomes open source). Does anyone have any preferences to the licensing terms? I would tend to prefer whatever licencing terms help to promote the project and encourage people to contribute. As the GPL seems to be the most popular open-source licence, I'm guessing that would be a good contender. There are some comparisons of the various more common open-source licencing terms here: <http://www.invis.co.uk/oslct/> <http://www.croftsoft.com/library/tutorials/opensource/> Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-06-05 13:26:52
|
D. Daniel McGlothin wrote: > <quote> > Yes new commands and object were added with each version. > > However, the sales of the versions below II+ are only about 10% of total > sales. > > Given that, I think it would be best to work with just the II+ version. > > Give me a few more days on the Object database. > </quote> > > Several points: > > 1. Although have not yet received the 'Object database', we do have some > information about the firmware differences. It's certainly encouraging to see that it sounds like just a series of extensions to the op-codes, rather than anything more fundamental. Presumably there's zero difference between the C/BASIC/Java language support when targeting different firmware versions? > 2. Since firmware version II+ is 90% new sales, that is the reasonable first > target for the toolchain. However, the statitistic does not comment to the > relative sizes of the shipped populations. Agreed. > 3. How would the project accomodate different versions of the firmware? Is > it a matter of a different code generator for each firmware, or does one > generator handle the differences conditionally? I think we should be able to use the same code generator. I would suggest that we pass in a parameter to the compiler to specify the firmware version, and the parser will throw an error if the input code includes stuff not allowed for that firmware version. Once the parser has successfully parsed the input code and generated an internal representation, the code generator should just be able to do its stuff, regardless of the firmware version (I think). It sounds to me as though the code generator should generate exactly the same code irrespective of firmware version setting, as long as the input code is legal on the respective firmware versions. If I'm right about this, all we need to do is put some conditional logic in the parser to disallow certain things, which I imagine would simply be the instantiation of VC objects that aren't supported on a given version. Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-06-05 13:17:43
|
Good points. It'll give us a much better insight into the ramifications of the decision of Python vs C. I already have Python installed as part of my Linux distribution, so I'll have a play with it, write a few "Hello World" type apps, and maybe check out those parsers / compiler-generators. Maybe we could all do this and report back with our more enlightened opinions on Python! Neil D. Daniel McGlothin wrote: > Group buy-in....a suggestion. > > Since we're all 'willing to learn', what's the harm in starting the python > investigation into 'how to do', toolchain setup, etc. Surely it would not > an 'irrevokable' decision until significant amounts of OOpic specific effort > is being expended. > > Upside is that we learn something new, and then have a experiential basis > for making the Python vs. C decision. > > And, <grinning> doesn't 2 'ayes' and 1 'present' vote constitute a quorum? > > Best Regards, > Daniel > > ----- Original Message ----- > From: "Neil Durant" <nd...@us...> > To: "OOPic Compiler List" <oop...@li...> > Sent: Friday, 04 June 2004 22:32 > Subject: Re: [Oopic-compiler-devel] Python > > > > I agree that we want as much buy-in from the group. So far we have you, > > Andy, Daniel and myself. Daniel as said he's fairly easy either way, and > > I'm the same, but also intrigued to learn more about Python. I'm guessing > > Andy is the big C fan and may take some persuading. However he doesn't > > appear to be responding to e-mails or postings on here. > > > > I'm torn really, between us waiting for everyone (maybe Andy's away for 6 > > months!) and also being keen to get the project moving. > > > > We can mix Python and C if necessary, although I'm sure it would make more > > sense to use one or the other rather than mix languages depending on > > developer preference! > > > > Thoughs? > > > > Neil > > > > Brian wrote: > > > Neil-- > > > > > > No, but I'm willing to learn. > > > > > > Wouldn't it be better, though, if there was buy-in from the group? If > > > the rest of the group wants to go the C route, then we're not going to > > > accomplish an awful lot together. > > > > > > --Brian > > > > > > On Sat, Jun 05, 2004 at 03:02:28AM +0100, Neil Durant wrote: > > > > Neil Durant wrote: > > > > > I've been reading more about Python, and it really does look like a > good > > > > > implementation language for the OOPic compiler. I'd be all for > going for > > > > > it, but I'd really like to hear Andy's thoughts on it! > > > > > > > > > > I notice that you can call C functions from Python and vice versa, > > > > > relatively easily, meaning that if there's anything we find we > really need > > > > > C for, then we can do it in C. Details here: > > > > > > > > > > <http://docs.python.org/ext/ext.html> > > > > > > > > > > I'm really keen to get on with development, but deciding on the > > > > > implemntation language is pretty critical! > > > > > > > > > > Andy, are you still with us? > > > > > > > > Well, in the absense of any word from Andy about this, what do you all > say > > > > we go ahead and try this in Python? > > > > > > > > Brian, do you have any experience using those Python parsers and > compiler > > > > generators you mentioned? > > > > > > > > Neil > > > > -- > > > > Neil Durant > > > > <nd...@us...> > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email is sponsored by the new InstallShield X. > > > > From Windows to Linux, servers to mobile, InstallShield X is the one > > > > installation-authoring solution that does it all. Learn more and > > > > evaluate today! http://www.installshield.com/Dev2Dev/0504 > > > > _______________________________________________ > > > > Oopic-compiler-devel mailing list > > > > Oop...@li... > > > > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by the new InstallShield X. > > > From Windows to Linux, servers to mobile, InstallShield X is the one > > > installation-authoring solution that does it all. Learn more and > > > evaluate today! http://www.installshield.com/Dev2Dev/0504 > > > _______________________________________________ > > > Oopic-compiler-devel mailing list > > > Oop...@li... > > > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > > > > > > -- > > Neil Durant > > <nd...@us...> > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the new InstallShield X. > > From Windows to Linux, servers to mobile, InstallShield X is the one > > installation-authoring solution that does it all. Learn more and > > evaluate today! http://www.installshield.com/Dev2Dev/0504 > > _______________________________________________ > > Oopic-compiler-devel mailing list > > Oop...@li... > > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > From Windows to Linux, servers to mobile, InstallShield X is the one > installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > -- Neil Durant <nd...@us...> |
|
From: D. D. M. <Da...@Mc...> - 2004-06-05 12:10:43
|
All, As a matter of procedure, has there been a 'license' or 'copyright' terms decided upon? A quick survey of the discussion so far didn't sow any, and I do not recall any such discussion. Does SourceForge 'impose' any license terms? (I didn't check.) If this is an open issue, my instinct would tell me to promote this to a top priority. Best Regards, Daniel |
|
From: D. D. M. <Da...@Mc...> - 2004-06-05 12:01:31
|
Something I received from Scott Savage, but had not passed on yet. I asked: >With regard to the 'OOPicObjectCommandList', am I correct in understanding >that >each newer firmware version only added objects or commands? > >In other words, to support multiple firmware versions, is it only a matter >of >filtering the commands/objects by the version they first appeared in? If >so, >and for the case of the object commands, would you have available a >cross-reference as to which firmware version the object command became >available. and Scott replied on 07-MAY-2004: <quote> Yes new commands and object were added with each version. However, the sales of the versions below II+ are only about 10% of total sales. Given that, I think it would be best to work with just the II+ version. Give me a few more days on the Object database. </quote> Several points: 1. Although have not yet received the 'Object database', we do have some information about the firmware differences. 2. Since firmware version II+ is 90% new sales, that is the reasonable first target for the toolchain. However, the statitistic does not comment to the relative sizes of the shipped populations. 3. How would the project accomodate different versions of the firmware? Is it a matter of a different code generator for each firmware, or does one generator handle the differences conditionally? Daniel |
|
From: D. D. M. <dd...@mc...> - 2004-06-05 11:47:50
|
Group buy-in....a suggestion. Since we're all 'willing to learn', what's the harm in starting the python investigation into 'how to do', toolchain setup, etc. Surely it would not an 'irrevokable' decision until significant amounts of OOpic specific effort is being expended. Upside is that we learn something new, and then have a experiential basis for making the Python vs. C decision. And, <grinning> doesn't 2 'ayes' and 1 'present' vote constitute a quorum? Best Regards, Daniel ----- Original Message ----- From: "Neil Durant" <nd...@us...> To: "OOPic Compiler List" <oop...@li...> Sent: Friday, 04 June 2004 22:32 Subject: Re: [Oopic-compiler-devel] Python > I agree that we want as much buy-in from the group. So far we have you, > Andy, Daniel and myself. Daniel as said he's fairly easy either way, and > I'm the same, but also intrigued to learn more about Python. I'm guessing > Andy is the big C fan and may take some persuading. However he doesn't > appear to be responding to e-mails or postings on here. > > I'm torn really, between us waiting for everyone (maybe Andy's away for 6 > months!) and also being keen to get the project moving. > > We can mix Python and C if necessary, although I'm sure it would make more > sense to use one or the other rather than mix languages depending on > developer preference! > > Thoughs? > > Neil > > Brian wrote: > > Neil-- > > > > No, but I'm willing to learn. > > > > Wouldn't it be better, though, if there was buy-in from the group? If > > the rest of the group wants to go the C route, then we're not going to > > accomplish an awful lot together. > > > > --Brian > > > > On Sat, Jun 05, 2004 at 03:02:28AM +0100, Neil Durant wrote: > > > Neil Durant wrote: > > > > I've been reading more about Python, and it really does look like a good > > > > implementation language for the OOPic compiler. I'd be all for going for > > > > it, but I'd really like to hear Andy's thoughts on it! > > > > > > > > I notice that you can call C functions from Python and vice versa, > > > > relatively easily, meaning that if there's anything we find we really need > > > > C for, then we can do it in C. Details here: > > > > > > > > <http://docs.python.org/ext/ext.html> > > > > > > > > I'm really keen to get on with development, but deciding on the > > > > implemntation language is pretty critical! > > > > > > > > Andy, are you still with us? > > > > > > Well, in the absense of any word from Andy about this, what do you all say > > > we go ahead and try this in Python? > > > > > > Brian, do you have any experience using those Python parsers and compiler > > > generators you mentioned? > > > > > > Neil > > > -- > > > Neil Durant > > > <nd...@us...> > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by the new InstallShield X. > > > From Windows to Linux, servers to mobile, InstallShield X is the one > > > installation-authoring solution that does it all. Learn more and > > > evaluate today! http://www.installshield.com/Dev2Dev/0504 > > > _______________________________________________ > > > Oopic-compiler-devel mailing list > > > Oop...@li... > > > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the new InstallShield X. > > From Windows to Linux, servers to mobile, InstallShield X is the one > > installation-authoring solution that does it all. Learn more and > > evaluate today! http://www.installshield.com/Dev2Dev/0504 > > _______________________________________________ > > Oopic-compiler-devel mailing list > > Oop...@li... > > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > > > -- > Neil Durant > <nd...@us...> > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > From Windows to Linux, servers to mobile, InstallShield X is the one > installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > |
|
From: Neil D. <nd...@us...> - 2004-06-05 02:32:34
|
I agree that we want as much buy-in from the group. So far we have you, Andy, Daniel and myself. Daniel as said he's fairly easy either way, and I'm the same, but also intrigued to learn more about Python. I'm guessing Andy is the big C fan and may take some persuading. However he doesn't appear to be responding to e-mails or postings on here. I'm torn really, between us waiting for everyone (maybe Andy's away for 6 months!) and also being keen to get the project moving. We can mix Python and C if necessary, although I'm sure it would make more sense to use one or the other rather than mix languages depending on developer preference! Thoughs? Neil Brian wrote: > Neil-- > > No, but I'm willing to learn. > > Wouldn't it be better, though, if there was buy-in from the group? If > the rest of the group wants to go the C route, then we're not going to > accomplish an awful lot together. > > --Brian > > On Sat, Jun 05, 2004 at 03:02:28AM +0100, Neil Durant wrote: > > Neil Durant wrote: > > > I've been reading more about Python, and it really does look like a good > > > implementation language for the OOPic compiler. I'd be all for going for > > > it, but I'd really like to hear Andy's thoughts on it! > > > > > > I notice that you can call C functions from Python and vice versa, > > > relatively easily, meaning that if there's anything we find we really need > > > C for, then we can do it in C. Details here: > > > > > > <http://docs.python.org/ext/ext.html> > > > > > > I'm really keen to get on with development, but deciding on the > > > implemntation language is pretty critical! > > > > > > Andy, are you still with us? > > > > Well, in the absense of any word from Andy about this, what do you all say > > we go ahead and try this in Python? > > > > Brian, do you have any experience using those Python parsers and compiler > > generators you mentioned? > > > > Neil > > -- > > Neil Durant > > <nd...@us...> > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the new InstallShield X. > > From Windows to Linux, servers to mobile, InstallShield X is the one > > installation-authoring solution that does it all. Learn more and > > evaluate today! http://www.installshield.com/Dev2Dev/0504 > > _______________________________________________ > > Oopic-compiler-devel mailing list > > Oop...@li... > > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > From Windows to Linux, servers to mobile, InstallShield X is the one > installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > -- Neil Durant <nd...@us...> |
|
From: Brian <bri...@po...> - 2004-06-05 02:13:49
|
Neil-- No, but I'm willing to learn. Wouldn't it be better, though, if there was buy-in from the group? If the rest of the group wants to go the C route, then we're not going to accomplish an awful lot together. --Brian On Sat, Jun 05, 2004 at 03:02:28AM +0100, Neil Durant wrote: > Neil Durant wrote: > > I've been reading more about Python, and it really does look like a good > > implementation language for the OOPic compiler. I'd be all for going for > > it, but I'd really like to hear Andy's thoughts on it! > > > > I notice that you can call C functions from Python and vice versa, > > relatively easily, meaning that if there's anything we find we really need > > C for, then we can do it in C. Details here: > > > > <http://docs.python.org/ext/ext.html> > > > > I'm really keen to get on with development, but deciding on the > > implemntation language is pretty critical! > > > > Andy, are you still with us? > > Well, in the absense of any word from Andy about this, what do you all say > we go ahead and try this in Python? > > Brian, do you have any experience using those Python parsers and compiler > generators you mentioned? > > Neil > -- > Neil Durant > <nd...@us...> > > > ------------------------------------------------------- > This SF.Net email is sponsored by the new InstallShield X. > From Windows to Linux, servers to mobile, InstallShield X is the one > installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > |
|
From: Neil D. <nd...@us...> - 2004-06-05 02:02:39
|
Neil Durant wrote: > I've been reading more about Python, and it really does look like a good > implementation language for the OOPic compiler. I'd be all for going for > it, but I'd really like to hear Andy's thoughts on it! > > I notice that you can call C functions from Python and vice versa, > relatively easily, meaning that if there's anything we find we really need > C for, then we can do it in C. Details here: > > <http://docs.python.org/ext/ext.html> > > I'm really keen to get on with development, but deciding on the > implemntation language is pretty critical! > > Andy, are you still with us? Well, in the absense of any word from Andy about this, what do you all say we go ahead and try this in Python? Brian, do you have any experience using those Python parsers and compiler generators you mentioned? Neil -- Neil Durant <nd...@us...> |
