|
My brain is built of paths and slides and ladders and lasers and I have invited all of you to enter its pavilion. My brain, as you enter, will smell of tangerines and brand-new running shoes.
  And now, the moment you haven't been waiting for | 
Posted - 6/14/2009 7:15:16 PM | Epoch Release 7 is Now Available
The seventh major snapshot of the Epoch programming language is now available for download from our Google Code web site.
This release introduces infix operators, fixes a large number of issues, and adds some polishing here and there.
Please note that this release is still an experimental version of the language. Many features are still missing and the design of existing features is still fluid. However, should you discover any defects or deficiencies, please do not hesitate to post them on our issue tracker, or contact me directly via PM here on GameDev.
Also, please note that I have posted an RFC thread over on the forums. Please direct your discussion of R7 to that thread so things are easier to keep track of.
Enjoy the release, and we look forward to hearing your opinions!
| |
| R7 and your imminent doom | |
Posted - 6/13/2009 11:21:28 AM | If you've been desperately F5'ing my journal for the last few days, you'll have noticed that every evening or so I manage to scratch off yet another item or three from the Evil To-Do List.
If you've noticed that, chances are you've also noticed that the list is down to a single item - namely, updating the bytecode system to handle all the new features and such that are coming in R7. This job is fairly minor, but very tedious - which is why I've postponed it for so long.
However, I now face an empty, lonely Saturday afternoon in the wastelands of boredom. This means I'm going to break down and get that last item ticked off.
Once that's taken care of, I'll immediately begin packaging R7. There will be a new format for distributions from now on, based loosely on the GDC'09 release structure. And of course all downloads are now hosted over on the Epoch Language site on Google Code.
Another big item is that the R7 code will be checked in to the Mercurial repository provided by GC. This means that you can get stable snapshots of the code in release packages, unstable snapshots at any time from the repository, and of course there will be a comprehensive listing of changes and fixes made in the code. There's also now an official bug/request tracker.
From here on out I plan to be very detailed in keeping track of updates in each release. So in the future it should be much easier to get an idea of what each release actually contains.
For now, though, I have to stare at this really boring bytecode crap until my urge to kick R7 out the door overcomes my desire to be hideously lazy.
| |
| My kingdom for feedback... | |
Posted - 6/9/2009 6:24:44 PM | So, guess what I'm going to talk about today!
Are you bored of this stuff yet?
- Integrate new features with the assembler and bytecode systems
Fix some bugs in nested response map support
Complete code review of all example programs to ensure they use the latest syntax and features
Type validation for structure/tuple initializers
Type validation for nested structures
Examine possibility of factoring out NumOperationsForParam in favor of CountTailOps
Exception safety in ParserState::CacheTailOperations()
Exception safety in ParserState::FinalizeInfixExpression
Organization in ParserState.h
Type safety for nested structure l-values
Update documentation in Grammars.h
Organize ActivatedScope class files
Organize ScopeDescription implementation files
Examine possibility of combining byte-buffer and string pools into a general pool class
As you can see, the code review turned up a few new items that need to be taken care of before I consider R7 clean enough for general consumption.
Thankfully, most of the items are small and can be done easily in my evenings and weekends. With any luck, R7 should be out within a week. (Yes, shock horror, I just gave an estimated release date.)
I decided to ease up a bit on the code review for two reasons. First, I could be anal retentive about things for months, and never actually ship R7; clearly, this is kind of a dumb choice. Secondly, I think it's important to get R7 into real-world usage testing ASAP; so you guys will actually be able to find all the problems that I've missed 
As soon as R7 goes live I'll be updating the Epoch language site and posting a general RFC thread over in the forums. I'm hoping to garner some real feedback to help guide the development of R8, so if you have any interest in Epoch whatsoever and can spare five minutes, please give it a shot and let me know what you think.
There may or may not be cookies involved for those who actually respond to the release of R7.
Think about it. Can you afford not to check out R7? I mean, cookies are at stake, man! Think of the children! Or whatever.
For now, I'm off to not work on Epoch, because I really need a break. I'll be back on the job tomorrow evening.
| |
| R7: Like falling into a black hole | |
Posted - 6/7/2009 10:55:09 PM | Gather 'round, kiddies! It's time for our daily task list update! Yayy!
- Integrate new features with the assembler and bytecode systems
Pop the parser stack correctly to improve error responses
- Fix some bugs in nested response map support
Improve syntax for initializing nested structures
Improve syntax for accessing nested structures
Organize ParserState class a bit better
Add support for empty lists
Change from using char to a Byte typedef to highlight code that manipulates single bytes
- Perform complete code review for exception safety, documentation, code cleanliness, error handling robustness, and elimination of hardcoded strings/magic numbers
- Complete code review of all example programs to ensure they use the latest syntax and features
As you can see, this is slightly shorter than the last task list, but it also contains a couple of extra things that snuck their way in and caused havoc.
Release 7 continues to be a tantalizing prospect: just when I think I'm ready to quit fixing bugs and making tiny tweaks, I discover another set of fairly significant problems. Bummer.
On the plus side I got plenty of stuff done over the weekend, so at least progress continues to be made. On the down side, though, I now have to go back to work again for the week, which means very little time and energy for Epoch.
I'll be hacking away most of the night, I suspect, and we'll see what I can manage to get done before the work week kicks in. After that, it's anybody's guess.
Oh, be sure to check out the Google Code page for Epoch. I'm (slowly) putting together a complete description of the language, it's design philosophy and goals, and current capabilities. I'll continue posting most of my updates here, but anything significant (like, say, shipping a release) will get a news entry on the GC site.
This is of course a perfect opportunity to remind all my awesome readers that Epoch is an open-source project, and additional contributors would be very welcome indeed.
Just a hint 
| |
| R7 == Duke Nukem Forever? | |
Posted - 6/6/2009 2:04:43 PM | Development on R7 today has been a mixed bag. At times it feels like I make one step forward and three steps back. The infix operator logic needed a complete rewrite, which has made it (and some peripherally related areas) much more robust - but at the cost of quite a bit of programming time. So I've spent my entire weekend thus far working on something that wasn't even on the task list.
As R7 has dragged out to much more of a prolonged affair than I ever intended, motivation has been steadily leaking away. There are times when it's hard to sit down and look at the code because I've spent so much time crawling towards the release. At the same time, though, the tantalizing nearness of completion makes it hard to think about anything else.
Epoch is unquestionably both the most difficult and most enjoyable project I've ever worked on. The only thing that's ever come close was the old Freon 2/7 realtime raytracing/global illumination system that I worked on several years ago. Epoch is a controlled substance. It provides a hell of a rush, a bewildering high, and only a slightly annoying crash at the end. Hacking through the midnight hours on this language is just ridiculously fun.
There's a lot of things I wish I had done differently in my life, and one of the big ones was abandoning the Freon project. Back in those days, I had predicted that within a few years we would see the end of major advances in scanline rasterization technology, and people would start exploring raytracing on the GPU to gain those next few shiny features. My plan at the time was to design a hardware system that could accelerate raytracing and global illumination, and use it alongside existing GPU systems as a sort of video coprocessor card.
I dropped that project for a variety of reasons; but the big one was that I had gone from working contract jobs whenever I felt like it, to holding not just one but two full-time programming jobs. I barely had time in the day to eat and sleep, let alone hack on a major project.
And I've regretted dropping Freon ever since.
So in a very real way, I'm trying to avoid repeating old mistakes. I don't want to burn out on Epoch and then discover in another year that someone else has accomplished what I set out to do. I don't necessarily have to be the first one (I'll settle for being the best one  ) but I'm completely committed to getting this language out there. If nothing else I think it will be an important benchmark of what kinds of features and power are needed in the next generation of programming languages.
But first things first. I have to get R7 done before I can get into the giant messy blob of awesome that will be R8. And in order to get R7 done, I have to do all of this jazz:
- Integrate new features with the assembler and bytecode systems
- Pop the parser stack correctly to improve error responses
Implement support for named lists
Implement allocators properly, remove hacked code
- Fix some bugs in nested response map support
- Improve syntax for initializing and accessing nested structures
Type validation with lists
Stack sanity checks when reducing infix expressions
Type validation for operate-assign ops (e.g. += and --)
Extend support for operate-assign ops to all numeric types
Implement concatenate-and-assign operator ;=
Improve validation of forked tasks (esp. when tracking the task name)
- Perform complete code review for exception safety, documentation, code cleanliness, error handling robustness, and elimination of hardcoded strings/magic numbers
- Complete code review of all example programs to ensure they use the latest syntax and features
As you can see, although a few things are marked off, there's a few newcomers as well. I have no idea how long I will continue in this pattern, but hopefully I'll start making net forward progress very soon.
Unfortunately for Epoch, my weekend involves having a Real Life, so I won't be able to hack straight through until Monday. I will be doing as much as I can cram into my schedule, though 
| |
| Epoch's New Home | |
Posted - 6/4/2009 11:05:18 PM | I've officially opened up the Google Code site for Epoch, at http://code.google.com/p/epoch-language/ (alternatively reachable at http://epoch-language.googlecode.com/ as well).
So far there's no content there, but as R7 nears completion I'll start setting up more stuff. The finished R7 code will be the first code committed to the VCS trunk, and the R8 project will fork a branch shortly thereafter. R8 has some really cool stuff coming so I'm looking forward to letting everyone play with the R8 code while it's in development.
On a totally unrelated note, I discovered a hideously bad bug in the infix operator logic today, so I'm in the process of rewriting that. By forfeiting a couple of really trivial optimizations (evaluating arithmetic expressions at compile time) I've simplified the work of the parser dramatically, so it should be easier to get correct results robustly and reliably now. The optimizations will go back in much later, as part of a separate multi-pass code improvement system. (Right now the optimizer is seriously far off in the future, unfortunately.)
I'm still torn on whether I want to track most of my stuff on the GC side or over here. (Or, worse yet, I could cross-post all my updates to both sites. Eurgh!) I'm leaning towards staying here, largely out of habit, and largely because there's already people watching this space for Epoch news. Pulling the plug on the main channel of information sounds rather pointless to me.
We shall see, I suppose. For now, I'm going to go back to burying my head in R7, and hopefully we'll see that sucker ship here sometime soon.
| |
| Light at the end of the R7 tunnel | |
Posted - 6/3/2009 11:03:04 PM | More headway on Release 7 today. As you can see in the previous post, a lot of items are getting checked off. In fact, it's worth taking a look at the remaining items in a fresh list. So here it is:
- Integrate new features with the assembler and bytecode systems
- Pop the parser stack correctly to improve error responses
- Implement support for named lists
- Fix(?) boost static_assert weirdness
- Implement allocators properly, remove hacked code
- Fix some bugs in nested response map support
- Improve syntax for initializing and accessing nested structures
Change task IDs to string variables for easier metaprogramming
- Perform complete code review for exception safety, documentation, code cleanliness, error handling robustness, and elimination of hardcoded strings/magic numbers
Unfortunately most of this stuff isn't terribly exciting, which means I probably won't be going out of my way to make time to work on it. However, things still progress towards the release.
R7 will also be the first release hosted outside of GDNet; I plan to set up a Google Code space and migrate my development setup over to there. In particular I'm looking forward to starting to use Mercurial for version control; up until now I've been doing the "make lots of backup CDs" version of code control, which just plain sucks.
Another nice thing is that having the code open on a well-known project site is bound to attract some attention eventually. Since, y'know, none of you wankers here ever show any interest in it
| |
| R7: May or may not be better than cheese | |
Posted - 6/2/2009 12:08:19 AM | After working on tuning up the inter-thread message passing system, I kind of got onto an optimization kick, and started exploring other options for gaining better performance in the Epoch VM.
The biggest change is in the way lexical scopes are handled. Lexical scopes basically consist of two chunks of data: static information like type details and so on, and dynamic data, which basically amounts to the current value of variables and such.
Previously, whenever a new scope was entered, the VM would create a complete copy of the scope, including the static data. This meant spending a lot of time copying trees and arrays around, which obviously isn't optimal. So I refactored the scope system so that dynamic information is now stored in a separate class entirely. The static data is no longer cloned, which gives us a healthy speed boost and a bit of memory savings as well.
I've also hacked in a variety of other fixes and improvements, many of which came as fallout from the scope handling changes. I'm not convinced that the code is truly optimal yet (there's some wizardry that could be done to improve cache coherency and some other stuff) but it is pretty damned fast.
For comparison, in my last post, I mentioned that stress testing reveals that 60,000 messages can be sent per second between threads. That number is now hovering around 102,000. Most of that was accomplished by minimizing the scope performance overhead, because each message handled represents one scope entry and one scope exit.
I've played around with some special allocators for data that tends to have heavy churn and short lifetimes, such as RValue wrappers; so far it looks like there won't be any benefit to writing special allocators in general. There's a few places where they work well (including a spot in the messaging system) but overall, due to thread safety issues, it's just simpler and easier to let the standard library do its thing directly.
On another front, I discovered a brilliant little Schroedinbug in the external DLL call system. For some mystical reason, the compiler produced the exact right code to keep things from blowing up. In working on something totally unrelated, I disrupted the careful balance, and the compiler started emitting code differently.
The new code stomped randomly all over the stack, and produced some truly horrific crashes that were inconsistent, difficult to reproduce, and often manifested simply as programs giving the wrong results instead of outright exploding.
As it turns out, the issue was related to the way I pushed parameters onto the stack when invoking external DLL functions. Pushing parameters shifted the stack pointer; when the code later tried to use the stack pointer to access a local variable, all hell broke loose, doing wonderfully random and unpredictable stuff to the running app.
I managed to get around the problem by rewriting the DLL call invocation routine mostly in assembler, which seems to be holding pretty solid.
So although some major headway has been made on the VM, I failed to check off any major items on the TODO list. In fact, I've just run a search of the codebase for TODO items, and the revised list comes up something like this:
- Integrate new features with the bytecode system
Respect 16-bit wide parameters when invoking DLL calls
Double check operator precedences
Finish support for user-defined infix operators
Fix a bug where types are ignored during infix computations
Retest all infix assignment variants for correctness
Fix bug with prefix unary operators applied to non-literal values
- Pop the parser stack correctly; many sections of the parser are guilty of leaving their junk hanging around, making error reporting messy
- Implement support for named lists
Type safety when passing list parameters
- Fix(?) boost static_assert weirdness
- Implement allocators properly
- Remove allocator hacks
Make x++ and related operations work correctly
Vomit if we allocate too many messages
Better handling of name collision detection
Reorganize some files
Consider trading off code duplication for speed in a few cases
Make it legal to access global constants from a task
- Fix some bugs in nested response map support
- Improve syntax for nested structure initialization
Type aliases (aka. typedefs)
- Change task IDs to string variables for easier metaprogramming
- Perform complete code review for exception safety, documentation, code cleanliness, error handling robustness, and elimination of hardcoded strings/magic numbers
So yeah. R7 is moving along fast, and will still take a billion years to actually arrive. We will literally evolve the ability to implement entire programming languages with our toes before I finish this release. But the release will occur.
Eventually.
| |
In locus hic, omnes res dementes sunt.
|
| S | M | T | W | T | F | S | | | 2 | | | 5 | | | 8 | | 10 | 11 | 12 | | | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | | | | |
OPTIONS
Track this Journal
ARCHIVES
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
