Menu
▾
▴
evlan-devel — Discussion of Evlan's implementation and development.
You can subscribe to this list here.
| 2003 |
Jan
(6) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-21 08:57:21
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Kenton V. <tem...@ga...> - 2003-09-29 03:29:55
|
Well, this is all way out in the future, and more of a technical detail compared to the things I'm working on now. I imagine Evlan will have its own GUI library of some sort, and this library will be platform-independent. Whether it will wrap existing C/C++-based widget sets or draw its own I do not know yet. Similar things can be said regarding 3D and sound. Evlan will provide some sort of cross-platform interface for these things, but the details are a long way away. -Kenton Varda At 06:04 PM 9/28/2003, you wrote: >Kenton, > >You've mentioned on another project that you want to write the whole >project in Evlan. > >I am curious if you have any ideas on how Evlan is going to implement the >gui/3d/sound chunks? Will we be using some Java-esque swing environment >or will the local Evlan compile have modules for that systems native gui >routines and such? > >How will Evlan get around the GUI diffences on different platforms? (ie, a >standard win button is smaller than a standard OS X button which is also >different from a GTK button etc) > >I realize this might be putting the cart before the horse but I am >interested in hearing the project lead's direction before I start doing >any major hacking. > >Les |
|
From: Les H. <lha...@co...> - 2003-09-28 23:05:18
|
Kenton, You've mentioned on another project that you want to write the whole = project in Evlan. I am curious if you have any ideas on how Evlan is going to implement = the gui/3d/sound chunks? Will we be using some Java-esque swing = environment or will the local Evlan compile have modules for that = systems native gui routines and such? How will Evlan get around the GUI diffences on different platforms? (ie, = a standard win button is smaller than a standard OS X button which is = also different from a GTK button etc) I realize this might be putting the cart before the horse but I am = interested in hearing the project lead's direction before I start doing = any major hacking. Les |
|
From: Kenton V. <tem...@ga...> - 2003-08-22 23:36:14
|
>I've pretty much read everything on the Evlan website, Whoah! Someone is actually paying attention to Evlan? :) >I've done quite a bit of event driven programming myself, in C, ObjC and >Python, and I've never seen a portable and efficient way around using the >select call for async programming with file descriptors. How do you plan >to get around this limitation in Evlan? Short of using a thread dedicated >to sitting on select(), or polling (using a short or no timeout on select, >if there is other processing to be done) I can't think of any way. Many operating systems provide better methods of waiting on multiple events than select(). Unfortunately, every OS seems to be different. In particular, Win32 has message queues, APC's, and I/O completion ports, while FreeBSD (and thus also OSX, I think) offers something called "kernel queues" (which are quite nice). Supposedly Linux has very recently caught up and implemented an interface they call "/dev/epoll", though from what I've seen it's not very pretty. In any case, the Evlan libraries will use the best method on each OS, abstracting it so that the programmer won't need to know the difference. In cases where select() is the only option, the libs will just have to fall back on it (and servers on those OS's just won't be as scalable). >How do you plan to support timed events (sleep for a while, call this >function later, etc.)? Just like any other events... The system will provide an interface to the timer which will allow for such things. >What are your ideas for how the scheduler will work in Evlan, given that >today's processors are basically serial? Usually, independent operations will just be performed in some arbitrary order. However, if an event handler spends a particularly long time processing one event, a new thread could be created to process more events in the meantime. I haven't really thought a lot about the details of this yet, as it will be quite a while before we get into implementing such things. >Also I didn't see any mention of exceptions anywhere. Do you plan to >implement exceptions, or something functionally equivalent to them? I think that, for small-scale code, the predicate-based type stuff will make exceptions unnecessary in most cases. That is, simple function calls won't have a whole lot of use for them. However, I can see exceptions being a whole lot more useful at the message-passing level -- that is, it should be possible to send an exception back in response to a message. The message passing stuff is, however, more of an API than a language feature, so exceptions don't need to exist in the core language to be used there. Of course, the "process" dialect turns message-passing into more of a language feature, and so I would expect to integrate exceptions into that dialect. Bleh. The last paragraph was rather confusing. Basically, while there aren't exceptions now, I have thought about them, and I am a fan of exceptions in C++. I just want to experiment with the language more before I decide exactly where and how I want to integrate them. Evlan will have some form of exceptions eventually. -Kenton Varda |
|
From: Bob I. <bo...@re...> - 2003-08-22 21:13:02
|
I've pretty much read everything on the Evlan website, and I have a few questions.. The concepts document says: > The usual alternative is to use event-driven programming, where a single > thread (or a small group of them) is notified whenever something happens > that it needs to attend to. This technique is much more scalable (provided > the programmer doesn't make the mistake of using poorly-designed system > calls like select(2)), but is also much more difficult to write. Many > programmers avoid event-driven programming because of the extra work > involved. Evlan, however, is designed to make event-driven programming > easier. I've done quite a bit of event driven programming myself, in C, ObjC and Python, and I've never seen a portable and efficient way around using the select call for async programming with file descriptors. How do you plan to get around this limitation in Evlan? Short of using a thread dedicated to sitting on select(), or polling (using a short or no timeout on select, if there is other processing to be done) I can't think of any way. How do you plan to support timed events (sleep for a while, call this function later, etc.)? What are your ideas for how the scheduler will work in Evlan, given that today's processors are basically serial? Also I didn't see any mention of exceptions anywhere. Do you plan to implement exceptions, or something functionally equivalent to them? -bob |
|
From: Kenton V. <tem...@ga...> - 2003-08-20 12:14:46
|
Well, it's been all of three days since I released 0.1.0, and I've already released a new version... It turns out that v0.1.0 had all sorts of problems working on systems other that Windows (Cygwin), most due to bugs in various GNU software. New release fixes all that. I went and tested in on Mac OSX, Free BSD, and even (reluctantly) Linux (ick), and it seems to work on all of them... should work on any 32-bit POSIX platform. If all that weren't enough, it turns out that the packaged copy of v0.1.0 which I had up for download was corrupted by the command-line ftp client, which conveniently performed newline translation on my binary file. Grr. Anyway, I'm really not going to be working on this again for a loooong time. Really. I want to, but I can't. Too much other stuff to do. -Kenton Varda |
|
From: Kenton V. <tem...@ga...> - 2003-02-22 23:20:39
|
- Added support for GNU readline (configure script will check if you have it). This means that the interpreter now allows advanced line editing as well as command history like you would find in a unix shell. - Got "basic" dialect working. This is now the default for the interpreter. This makes most arithmetic operators usable. There seem to be some arithmetic bugs involved with real numbers... hmm... will fix later. -Kenton Varda |
|
From: Kenton V. <tem...@ga...> - 2003-02-21 15:45:46
|
I finally finished the interactive interpreter... well, not finished, but
it's working. At present, the only way to execute Evlan code is to type it
in at the prompt and run it. Of course, only the kernel dialect is
supported so far.
Here is an example of some code which I tested:
fib = x => result where
loop = counter => last => last2 =>
if counter.equals 1
then last
else loop (counter.subtract 1) (last.add last2) last
result =
if x.isLessThan 1
then 0
else loop x 1 0
I must say I'm rather surprised by how little debugging I have had to do to
get things running as well as they are. I expected to be debugging for
days before code like the above worked! :)
TODO:
Short-term:
- Revise language description
- "Basic" dialect (mainly, adds arithmetic operators)
- Bytecode loading and management
- Very simple API facilities (containers, string ops, etc.)
Medium-term:
- Event system
- "Process" dialect (? perhaps this should be delayed until the
compiler is written in Evlan. I don't think the compiler itself is in dire
need of it.)
- C native interface
Long-term:
- Rewrite compiler in Evlan.
- Design API
-Kenton Varda
|
|
From: Kenton V. <tem...@ga...> - 2003-02-14 18:50:55
|
Yeah, so things have been taking some time, as you probably noticed. The
thing is, as I have been implementing, I started coming up with new
ideas. One big one is a complete revision of how types work... which I
will now attempt to explain.
First, forget everything you know about types and objects. As a matter of
fact, start thinking about objects in a first-order predicate calculus
fashion. An object is some abstract thing which has a set of
properties. We define these properties using predicates.
Now, what is a type? A type is simply a set of predicates... or, rather,
it's an implication:
isa(object, Array) =>
hasField(object, elementType) &
hasField(object, size) &
isa(object.elementType, type) &
isa(object.size, Integer)
Here we have said that if "object" is of type "Array", then it has fields
"elementType" and "size", where "elementType" is some type, and "size" is
an Integer.
Now, if we have some particular object "MyArray" which is an array of
integers, we could specify this like so:
isa(MyArray, Array) & equals(myArray.elementType, Integer)
Now, where this gets interesting is, say we have a function which gets an
element of the array:
getElement = array => index => #...
To specify the types of "array" and "index", we say the following:
isa(array, Array)
isa(index, Integer)
But, predicates are not just limited to discussing types and fields. We
could also say:
isLess(index, array.size)
isGreaterOrEqual(index, 0)
And, thus, we have specified that the index taken by getElement must be
within the array's range. This fact becomes a precondition to the
function, just as the types of the inputs are preconditions.
Now, the compiler would only allow a function to be called if all of its
preconditions were met. So, the preconditions would have to be provable
within the calling function. The easiest way to satisfy the range
precondition would be to do this:
if (myIndex < array.size) & (myIndex > 0)
then getElement array myIndex
else #handle error...
The compiler would see, in this case, that the precondition must be
valid. This forces people to check these things, which eliminates
potential bugs. Of course, in many (perhaps most) cases, the fact that the
index is within the array's range will already be implied naturally from
the code. (Imagine a for loop which iterates through an array. If the
initial condition is "i = 0" and the loop test is "i < array.size", which
is the usual case, then you automatically know that i is within the range
of the array. Of course, functional languages don't have for loops, but
you get the idea.)
Of course, I have mentioned this idea before. Dusty earlier pointed out
the example of matrix multiplication, where we might want to add the
precondition that the left matrix's width should be equal to the left
matrix's height.
Adding this form of types to the language would do wonders for compile-time
bug catching. Many errors which are currently signaled using exceptions
could be eliminated by using proper preconditions. Catching errors at
compile time is certainly much better than runtime, especially since it's
often the end user who gets stuck with the runtime errors.
This method would also lend itself quite nicely to optimization. The
optimizer would probably keep track of facts using the same logic the
compiler uses, and thus would have all kinds of extra info about the types
and objects in use.
The down side is that the compiler will often have to use resolution (a la
AI) to check if preconditions are met. This is a rather complicated thing
to do. For the prototype, we can just assume that preconditions are met,
or use runtime checks... but eventually we will have to implement the real
thing. Previously, I did not think this was worth it, but I think I have
changed my mind.
What do you think? Dusty, have you come across this sort of scheme in your
research?
-Kenton Varda
|
|
From: Kenton V. <tem...@ga...> - 2003-01-28 05:54:01
|
- Added debug mode to compiler. Enable using "--debug" option. Among other things, this will cause a parse tree to be printed between the parsing and compiling phases. - Debugged the parser a bit more. -Kenton Varda |
|
From: Kenton V. <tem...@ga...> - 2003-01-26 15:03:45
|
The compiler is mostly written. It's also mostly untested. I managed to
compile a basic expression (including a "where" block) and disassemble the
resulting bytecode, but that doesn't mean a whole lot.
The VM is not yet written, so there's no way to run anything. Just
compile. Yay.
Compiler currently spews lots of debug info. It's a bit difficult to find
the actual errors among it all, if any. Bytecode will not be output if
errors occurred, of course.
"evlanc --help" to get usage info. ("make install" will put evlanc.exe in
your path.)
Me sleep now.
-Kenton Varda
|
|
From: Kenton V. <tem...@ga...> - 2003-01-20 05:02:50
|
- added "bytecode" package, which defines the bytecode format. - wrote "evlan::bytecode::Bytecode", which represents a loaded bytecode file. - wrote "evlan::bytecode::Loader", which reads and writes bytecode files. In order to have a working prototype implementation, we need to: - Write the simulator, which evaluates expressions. - Write the translator from a token stream to bytecode (the compiler). - Write an interactive expression interpreter. I don't think any of these tasks will be very hard. The syntax translator will probably be the most difficult part. I am aiming to have this all done within a week or so. The ability to write executable programs will have to wait until the API has been defined, of course. For now, all we will have is an expression evaluator. -Kenton Varda |
|
From: Kenton V. <tem...@ga...> - 2003-01-16 23:25:15
|
- Updated basic dialect to include keywords recently added to language description. - Moved all test programs to the base source directory (evlan-proto/evlan/). - Moved all basic token processing stuff to new evlan/compiler/syntax package. - Moved dialects to new evlan/compiler/dialects package, with a sub-package for each dialect. - Created "kernel" dialect (in addition to existing "basic" dialect). BTW, rule about CVS updates: Always e-mail the mailing list when you make one. Also: automake sucks. -Kenton Varda |
|
From: Kenton V. <tem...@ga...> - 2003-01-16 21:06:48
|
I made more changes to the language description: - Added exceptions - Changed upcasting method. Now uses "switch" expression. Note that "try" and "switch" use basically the same syntax. - Added concept of "closed" classes. A closed class is one which has a given set of subclasses and/or implementations, but which cannot be extended or implemented further. This is useful for, say, defining Boolean to be only "true" or "false" and nothing else. My writing seems to be even more confusing than usual today. Hopefully the changes make sense. http://www.evlan.org/docs/informal/values.xml http://www.evlan.org/docs/informal/types.xml I'm going to do some actual coding now. :) -Kenton Varda |
|
From: Kenton V. <tem...@ga...> - 2003-01-16 20:56:48
|
Just making sure this works before I send anything important out. |
