extprosys-devel Mailing List for XPS: eXtensible Programming System (Page 2)
Status: Alpha
Brought to you by:
raspencer
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
(7) |
Sep
(9) |
Oct
|
Nov
(1) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Reid S. <ras...@re...> - 2002-08-19 05:53:02
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* XPSers, I have added automatic CVS commit notification to the project. Anyone who is a developer with this project (not necessarily everyone on the this mailing list) will automatically get notified about any commits made by anyone to the CVS repository. This is intended to improve communication and cooperation between developers. You may have already seen a few of the notices. This will, undoubtedly, end up being quite "chatty". So, if you find this volume of email to be annoying, please let me know and I will remove your name from the list. When implementing this feature, I was tempted to simply email the notifications to this list, but I thought that might become a nuisance for the non-developer subscribers to the list. Could we take a vote on this? Do you non-developers want to receive the commit notifications? Do you developers think the notifications should be posted to the mailing list? Let me know what you think. I can implement it either way quite easily. Best Regards, Reid |
From: Reid S. <ras...@re...> - 2002-08-16 01:26:11
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* Developers, I just had an inquiry from a potential XPS developer about what kinds of programming tasks need to be done on XPS right now. Below is the part of my response to him that describes those tasks. I thought I'd include the larger group in this information as well in case one of these appeals to you. 1. XPL critique. I've published my first draft of the XPL language schema (with limited documentation) and am looking for feedback on it. You may have already downloaded it. I really need to know what's bad about it so I can correct the design. Your thoughts would be welcome. 2. Schema Specific XML Compression. XPS will be transferring a lot of data around the network. I'd like to transfer that data with the least overhead possible. XML is extremely verbose but it compresses well. This task involves generation of compression software for specific XML schemas. That is, you would be writing a compiler that parses XML Schemas and produces the source code for a C++ class that compresses instances of that schema. The initial version can live with all kinds of restrictions as long as text and elements are supported. I have specific design ideas about this that I will share with you if you want to take on this task. 3. CVS Encapsulation. Source code in XPS will be managed by CVS. I need some C++ code that complete encapsulates the CVS tool. You'll need to understand CVS at a pretty deep level for this one. If you've used it and want to learn it, it might be a fun, isolated project. 4. Unit Tests. I have various modules in the software now that need their unit tests upgraded. This is important work in order to prove the reliability and correctness of the system! 5. I18N and L10N. If you've got experience with Internationalization and Localization, I need your help! I'm currently planning on using the gettext tool from GNU for string translation. However, there are competing open source technologies such as ICU to consider. First, I need a review of which technology is most appropriate for XPS and then some work to integrate it into the growing software base. As always, my best regards, Reid |
From: Reid S. <re...@re...> - 2002-08-09 17:57:55
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* I have checked into CVS a basic development framework for the XPS project. I'm preparing a series of "Developer's Guidelines" documents to help you find your way around. Until then, I suggest you just check out the software and browse. Its pretty straight forward stuff. Here's a quick overview: 1. Use CVS to check out the entire set of sources to your local machine (Linux or cygwin at this point) 2. run the "bootstrap.sh" script that is at the top level. This should successfully configure your source tree for your platform (let me know if you have problems) 3. All the goodies are in the "src" directory. The "xps" link that configure creates is so that we can #include <xps/module/header.h> instead of <src/module/header.h>. This is preferred because we want to ensure that our software doesn't conflict with any 3rd party software (of which we'll be using a lot). 4. The directories under "src" contain the following: doc -- all documentation, guides, howtos, web site, papers, etc. mem -- the memory management module (incomplete, still working on it) obj -- the XVM runtime object management module (TBD) schema -- the XPL schemas and examples (moved from xplc/schema) test -- a unit testing framework (complete, works) util -- various utilites for debugging, etc (complete, works) www -- defunct (I'll remove this eventually) xplc -- the XPL Compiler (have at it Vic!) xplec -- the XPL Extension Compiler (no code yet) xvm -- the XVM program (trivial framework committed) xvmapi -- the XVM API (basic macros defined) xvmsh -- the XVM shell to send commands to XVM (no code yet) Configuration.h -- high level #defines config.h -- generated by configure, platform config stuff. I am currently working the xvmapi so that we have a standard "output" format for the XPL compiler. It's time to start cutting some code! Reid. |
From: Reid S. <re...@re...> - 2002-08-05 08:00:39
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* Hi, I have added various bits of software to the CVS tree for XPS. I've spent a bit of time getting the "configure.in" for autoconf working correctly and documenting it. The makefile system is now up and running for the various directories under "src". Two of the directories under src now contain software that compiles correctly with automake on my Red Hat Linux 7.3 system. Hopefully it will on yours too. The two directories are "util" and "test". "util" provides various utilities for exception handling, assertions, etc. Our interface to internationalization will go here as will other "kitchen sink" type software that doesn't really belong anywhere else. The "test" directory is a reincarnation of a unit test facility that I've had kicking around for a couple of years. It provides various C++ classes and #defines to make writing test suites/scenarios/cases easier. I'll write some documentation on that because I would like each module that we write to have a Unit test capability to show that it works (in isolation). Let me know if you have any difficulties .. there's lots more coming. Reid |
From: Reid S. <ras...@re...> - 2002-08-01 08:36:48
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* FYI, I have committed several changes to the XPS CVS tree. There is now an initial directory structure, various documents, the schema files, some initial code, the automake/autoconf stuff, etc. This is rudimentary and preliminary but if you want to try it out and let me know of any issues you have, I would appreciate it. I'll be working on getting a skeletal build system up and running over the next week or so. I would be specifically interested if any of you have systems that fail the configuration tests I've set up. I've always had in my head that XPS would be targeted at 64-bit machines with modern operating systems. I'm interested in working with as many relevant platforms as possible but not interested in supporting arcane or little utilized platforms/systems just for the sake of it. Still, autoconf is supposed to be a cure-all for these things. Let me know if you have a glaring inconsistency on your build machine. Best Regards, Reid. |
From: Reid S. <ras...@re...> - 2002-07-30 06:15:48
|
XPLers, I have updated the schema definition for XPL as a new release, release 0.1.1. This release contains numerous corrections and additions but retains the basic structure of the language. Included with the release is full documentation (in case you don't have XML-Spy) and a full example of the use of the XPL-en schema. Please download and comment, you'll find this version much more amenable than the 0.1 version. I would like to solicit your feedback on a variety of topics about the language definition so far. When you get to the point that you grok what I've done, please see if you can provide your feedback on the following topics. 1. Incorporating Memory Management (Regions and Segments) Into The Language. I wanted to do this to be explicit in the language about how memory is organized and allocated so that it isn't shuffled off to some "library routine" that varies from machine to machine and uses different strategies. By incorporating memory management in the language, the programmer has greater control of how the program utilizes memory. 2. Defining Files, Streams, Documents, Transforms, Segments, and Regions as Object Classes. Regardless of whether you think it is useful for these things to be in the language (as opposed to some "standard library"), what do you think about including these things in the class inheritance hierarchy. I think its a nifty idea because it allows you to build a type hierarchy around things that interact with "external entities" (i.e. files, streams, documents, memory, etc. are all external to the XVM). 3. Using Lisp Style Expressions. The operator expressions in XPL are similar to LISP. That is, an expression is built from the inside out. Instead of saying a+b, we say +(a,b). Instead of writing (a*(b/c)) we write *(a,/(b,c)). This structure falls naturally in line with XML content models and makes it very easy to correctly parse the programming expressions with an XML parser. I believe that it will also be very efficient way to program and generate code. However, it is not necessarily intuitive for the novice. The last example above in XPL look like: <mult_ii> <get_i> <value_loc>a</value_loc> </get_i> <div_ii> <get_i> <value_loc>b</value_loc> </get_i> <get_i> <value_loc>c</value_loc> </get_i> </div_ii> </mult_ii> Its rather verbose, but functionally elegant. I haven't worried about how "pretty" XPL is because I don't think anyone is going to program directly in the XML text. A visual editor (emacs mode?) that simplified editing XPL would be an excellent tool to build for XPL. Any volunteers out there? Does the inelegance of the syntax bother you? What if the entire structure of the program was represented in 3D and manipulated in a VR kind of way? Would it bother you then? Because its XML, we can do all kinds of transformations from other languages, syntaxes and editing systems and still end up with XPL as the basic language that gets compiled. It is this latter aspect of the language that is important (rigid semantic specifications, fast compilation, accurate results). 4. Everything In A Method/Function Is An Operator. I wanted to provide a simplicity of design such that program could be constructed by arbitrarily nesting various operators. The fact that the control flow operators (if, repeat, for, foreach, select, switch...) can return values means they can be used directly in a computational expression. C++ provides a very limited form of this with the ?: operator. I've generalized it so that all control flow operators may be used in computation expressions. For example, XPL permits the following C++ equivalent: int array[maxlen]; /* ... */ int i = for (int j = 0; j < maxlen; j++) { if (array[j] == 15) { result j; break; } Note that I take the liberty that this C++ code can (a) assign the result of a for loop to an integer variable and (b) has an operator "results" which specifies the result for the enclosing block. I won't write the equivalent XPL because there is an example similar to this in the release. But, what I would like to know is what you think of this ability? Power or confusion? 5. Method Discriminants. Unlike some other popular object-oriented languages, I differentiate between the messages sent to an object and the methods that implement those messages. To me, these are not the same things. While the message send can be optimized to a simple function call in many cases, XPL also directly supports active objects (running in their own thread) in which case message sending is an asynchronous operation. Furthermore, I allow a class to implement a method multiple times. To disambiguate which methods get run on which message sends, I have introduced the notion of a method discriminant. Discriminants are simply boolean expressions that are computed at runtime to determine which methods get run. While the same ends can be achieved with if/unless/switch operators in the body of a single method, the use of discriminants provides the programmer with some syntactic sugar to help keep the program organized. First, method names are not necessarily the same as the message names. Since multiple methods can be defined for a single message on a class, this must be true. Consequently, the method can be named after what it does, not what the message means. Extensibility is enhanced because adding a new behavior for a message is as simple as adding a new method, leaving the existing methods alone and simply defining a boolean expression that determines the conditions under which the method executes. This style of programming greatly aids state machine development since the state of the machine can be used as the discriminant. Finally, the XPL compiler can eliminate any apparent overheads by simply recombining all the discriminant expressions into a single function that implements all the methods. I'd like to hear your opinions about this. 6. Overlays -- Anyone Need 'em? Overlays in XPL are like unions in C/C++. They provide a way for using the same memory for multiple fields. However, because XPL is a type safe language, Overlays can't be used for type coercion or bit fiddling. Any attempt to extract a field other than the last one set will yield an error. So, what's the difference between that and just using individual variables or a struct? Is memory consumption these days really that big a concern? 7. Documents & Transforms Needed? Since XPL is based on XML and the XPS will use XSLT heavily, I thought that it would be useful to incorporate the notion of an XML document and an XSLT transformation directly into the language. However, I haven't been able to think up many operators that could be invoked on these kinds of objects. Perhaps I just haven't thought about enough (a lot has gotten deferred), but it occurs to me that perhaps these things are just not as fundamental to an XML programming language as I had originally thought. The basic idea is that you could invoke an XSLT transform on one document and get a different document instance after transformation. Documents could be parsed by sending messages to a parser class much the same way as DOM/SAX do. In fact, it could just be the DOM or SAX APIs. How important is it to put this in the core language as opposed to supporting it in a standard library? Is it something that every XPL program might need? 8. Multiple Natural Language Support. One of my original goals in designing XPL was to allow the language to support multiple natural languages. That is why the specification is broken into two parts, XPL-Abstract.xsd and XPL-en.xsd. The abstract definition defines all abstract elements using verbose and precise names in English. The English language version (XPL-en) defines concrete elements using shorter english names. The intent is to also create XPL-fr.xsd (Francaise), XPL-de.xsd (Deutch), XPL-sp (Espanol), and other natural language versions of the abstract language definition. All these natural language versions would be compilable as XPL because the compiler will only look at the abstract substitution group names for the elements, not the actual names of the elements for a given natural language. I think this is very useful and would make XPL much more friendly and amenable to programmers in other languages. Your opinions on this? I hope to hear back from you on these topics and any others you care to bring up. Best Regards, Reid Spencer XPS Project Lead |
From: Reid S. <ras...@re...> - 2002-07-23 07:21:36
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* I am currently working toward an example XPL file that contains one definition of each type of XPL schema component. I'm using the languages "<doc>" take to provide commentary as needed. However, in doing so, I've noticed several glaring errors in the schema definition published this past Thursday. So, there will be a 0.1.1 release in about a weeks time after I get through creating a full instance of an XPL package. Please continue to use the existing schema as a way of learning about XPL. It is still mostly relevant. Most of the changes I'm making are cosmetic (required elements that should be optional, concrete elements that should be abstract, etc.). The basic structure won't change (well, for now anyway). I'll post the modifications to schema just as fast as I can. Sorry if this causes you any grief. BTW, I was hoping for a little discussion on the schema. Did anyone review it? Any questions? Reid |
From: Reid S. <ras...@re...> - 2002-07-19 07:30:47
|
*This message was transferred with a trial version of CommuniGate(tm) Pro* Gentlemen, Now that the first XPL definition has been released for review, I would like us to start getting active in a few areas. I hope you're ready for the ride ahead because XPL/XPS is going to be revolutionary in programming. So, let's get busy .... I know that you've been waiting for months for this release, so you're going to need some time to review it. For the first stage of activity, I would like to suggest that you refrain from making comments too early. The schema is long and not particularly well documented (yet!). Please seek to understand it first. This will save both of us a lot of time. However, I want to encourage you to ask questions that further your understanding of the schema. Ask your questions right here on the eXtProSys-devel mailing list so that newcomers can benefit from your learning as well. I will attempt to respond as quickly as I can (24 hour turn around in general). While you're getting to know XPL, I am going to document the language to some degree. I intend to cover the basic concepts, the ideas and styles of the language, and basic structure and content. I will leave the detailed, element by element definitional work until we all are in agreement about what XPL should look like. Your questions will form a large part of the content of the XPL guide so please feel free to ask if there is anything you don't understand. The specification is fairly large and the descriptions in the schema components are pretty terse. Once everyone is on the same page in terms of understanding the schema definition, it will be time to let your criticisms fly. I'm of the mind that "bad news is actionable" so please don't be bashful in making your comments. My goal is to seek the best possible definition for XPL through interlocution and debate. While I may argue vociferously if I think a particular idea is better than another, I am quite amenable to be convinced if better ideas are suggested. After we've revised the schema, we'll start implementing the compiler for it, in baby steps. Simultaneously, we'll build the XPS execution environment for the language; again, in baby steps. One of my "to do" items over the next month or so is to define the work tasks in source forge so we know what the road ahead looks like. I look forward to working with you in developing the world's best programming environment. Thanks for your help with this project, its will be fun .. Best Regards, Reid. |
From: Reid S. <dev...@re...> - 2002-06-03 05:37:55
|
I had a request to provide the paper in larger fonts. This has now been taken care of. Both the CVS repository and online web sites have been updated with a new version of PLANX-paper.pdf. The older, smaller print version, has been renamed PLANX-print.pdf because it was aimed at being printed, not viewed online. Hope that takes some of the eye strain off. Reid Spencer XPS Project Lead |
From: Victor K. <vi...@mo...> - 2002-06-03 01:46:24
|
> Would someone volunteer to set up the home page properly? Assuming I'm not treading on anyone's toes, I'll volunteer for this. It would give me the opportunity to so something while I'm learning the ropes. Would anyone have any objections to me using php or would plain html be prefered? I have a couple of days of work so I will be able to find some time to flesh something out. Vic |
From: Victor K. <vi...@mo...> - 2002-06-03 00:59:46
|
Hi, Thanks for the paper Reid, I thought it was a very good introduction to the aims of the project, something which is particularly useful to me at this point. I noticed one minor typo. On page 7, second column: Line 8. A function named "main" is declared. Main has ->not<- arguments and returns no result. Regards, Vic |