Sign in to follow this  
ApochPiQ

RFC: Epoch Programming Language, Release 8

Recommended Posts

Release 8 of the Epoch programming language is now available. Epoch aims to provide rich, first-class support for parallel processing and concurrent programming. Check out the Epoch Release 8 download for a big chunk of new features and fixes:
  • Prototype/POC integration with CUDA is now available; our samples repository includes an example program that runs some simple calculations on the GPU, assuming CUDA support is available.
  • Thread pooling has been added to supplement the use of general threads via task blocks. See the example for more details.
  • Build Windows executables easily with the new Exegen option /makeexe
  • Empty loop bodies no longer cause infinite looping
  • Functions can now return structure types
  • Numerous fixes to infix syntax
  • Changed definition of custom infix functions to use a tag on the function definition, rather than a separate global-scope flag
  • Bitwise operators now include 16-bit integer support
  • Fixed use of wildcards with Exegen
  • Fixed structure copy constructors
  • Several fixes and updates to the compile/assemble pipeline
  • Fixed support for .eprj project files
  • ... and a host of other minor fixes and improvements to the code base.
For more information about the project, please see the Epoch project website. Any and all feedback is welcome and appreciated. Enjoy Release 8!

Share this post


Link to post
Share on other sites
I've been silently following this, and I'd like to pop in and throw a bucket of support at you. Interesting and inspiring project; I'll definitely have a look at this new release in a jiffy.

Share this post


Link to post
Share on other sites
Quote:
Original post by Heptagonal
I've been silently following this, and I'd like to pop in and throw a bucket of support at you. Interesting and inspiring project; I'll definitely have a look at this new release in a jiffy.


Thanks! It's hard to know sometimes if anyone is paying attention.


Quote:
Original post by Konfusius
I see that you're using a custom compiler backend. Wouldn't it be better to use an existing one (LLVM springs to mind)?


I need an FAQ for this [smile] The general reasoning behind my approach is spelled out here.

Share this post


Link to post
Share on other sites
I've been thinking about this project since I read your first thread about the idea. I'm looking forward to trying it, but are there any plans for Mac OS X support in the near future (I do most of my coding on a Mac and have for some years now)?
Also, did you ever post anything on Lambda the Ultimate about this project? They might give some good feedback.

Share this post


Link to post
Share on other sites
I've been laying about with the latest Epoch release a little I've found some problems, so here's that feedback you were asking for.

The sample programs don't function properly. The guessing game, which I'm quite positive I've managed to get working in release 7, throws an error at runtime about an illegal cast. The scribble project doesn't even build, giving me two inexplicable compile errors, and I had to move the project to the "Tools" folder because Exegen couldn't find the source files in a remote directory.

When programs do run they appear to do nothing. A trivial example such as the one below, while building without errors, produces no output when run from the command line.

entrypoint : () -> ()
{
debugwritestring("Test")
}


Am I missing something here?

Share this post


Link to post
Share on other sites
Quote:
Original post by Roboguy
I've been thinking about this project since I read your first thread about the idea. I'm looking forward to trying it, but are there any plans for Mac OS X support in the near future (I do most of my coding on a Mac and have for some years now)?
Also, did you ever post anything on Lambda the Ultimate about this project? They might give some good feedback.


I don't have access to a development Mac, so sadly for now we're a Windows-only operation. I do accept donated hardware/software/cash, though... [wink]

I haven't been through the LtU gauntlet yet, no. I'm holding off on that until I finish the design and implementation of some of the more useful features of the language; right now it's still pretty primitive and wouldn't really arouse much interest over at LtU. Once the object model is in place though I will definitely be throwing it that direction for review.


Quote:
Original post by Heptagonal
I've been laying about with the latest Epoch release a little I've found some problems, so here's that feedback you were asking for.

The sample programs don't function properly. The guessing game, which I'm quite positive I've managed to get working in release 7, throws an error at runtime about an illegal cast. The scribble project doesn't even build, giving me two inexplicable compile errors, and I had to move the project to the "Tools" folder because Exegen couldn't find the source files in a remote directory.

When programs do run they appear to do nothing. A trivial example such as the one below, while building without errors, produces no output when run from the command line.
*** Source Snippet Removed ***
Am I missing something here?


Can you run me through the command line ops you're doing? I'm having problems recreating the issues (although you are correct that Scribble is, yet again, broken; I could have sworn I had it building before I packaged the release, but oh well).

I really do need a quick "how to use this mess" guide included in the release kit... [grin]

Share this post


Link to post
Share on other sites
Here's the log from the command line window:

C:\Users\Martin\Desktop\Epoch Release 8\Tools>exegen /makeexe guessinggame.epoch guessinggame.exe
EXEGEN - Epoch development toolkit

[Plenty of stuff saying that the program has been built successfully]

C:\Users\Martin\Desktop\Epoch Release 8\Tools>guessinggame

C:\Users\Martin\Desktop\Epoch Release 8\Tools>

This error is given when running the guessing game:

Epoch Subsystem
---------------------------
Failed to cast value; possible causes are overflow or malformed data

Share this post


Link to post
Share on other sites
Ah, thanks - that's quite helpful! I tracked the problem down to a mistake in the implementation of the console attachment routines.

For the curious, essentially what happens is the stdin handle does not bind correctly, so any attempt to read from the console input results in an error. It just so happens that in this case the error propagates through the exception handlers and ends up reporting (more or less erroneously) that an invalid data cast was attempted.


Also, one thing I failed to note properly - when building console-reliant programs with /makeexe, you'll need to specify the /console switch as well, in order to have the program attach to the console during startup. Otherwise you will get a running, valid EXE that doesn't actually show any output. I will modify this so that either a /console or /noconsole switch is required with /makeexe so that it can't be accidentally overlooked.


My plan at the moment is to take care of some of these usability issues, then re-release R8 with the improvements in place.

Share this post


Link to post
Share on other sites
OK... fixes and improvements are all in place and have been deployed. For the whopping four of you that have downloaded the release, please download it again from here to get the fixes.

I'll also put in some time to improve the "getting started" wiki article, so that hopefully things will be much smoother for newcomers to the project [smile]

Share this post


Link to post
Share on other sites
Yayy triple post... who moderates this place, anyways? He should be shot!


I've posted two articles that should hopefully provide a gentle but thorough introduction to the language and its features:



In addition, the installation guide is much improved... as in, it actually exists now, and actually walks you through the install process rather than assuming you have the time and patience to figure it out without any hints [grin]

These should hopefully make it much easier to poke around and explore the language as a whole.



Right... three posts in a row is plenty, I think. Feel free to keep posting feedback as the urge strikes you; for my part, I'll stay quiet until R9 is ready for general consumption [smile]

Share this post


Link to post
Share on other sites
I looked at this before, but it kept coming to the top ^^.

So I checked the site again, and must say I like the philosophy and the syntax didn't scare me away. I like the () -> () syntax for functions, this was also proposed in a C++-improved-syntax language which name I forgot.

I can confirm this runs on my Win7 32-bit build (guess the number). The CUDA example, however, crashed exegen (Exegen stopped working), is this because I don't support CUDA (my GPU is a very recent Nvidia one)?

Maybe you had your reasons, but it might be easier for people if the directory names were a bit standard, it's not important really...would just be less typing if it was Epoch/samples/parallel/stress.epoch then Epoch/Sample Epoch Programs/Parallel Examples/stress.epoch. But that's my POV.

Also, exegen sounds very generic, why is it not called epoch.exe?

For the rest, nicely done, good job! This looks likes it's going to be handy ;)

PS: any support for doubles and 64-bit integers? And can I display more behind the comma / dot for floats? No for loops?

[Edited by - Decrius on February 17, 2010 3:16:17 PM]

Share this post


Link to post
Share on other sites
Do you have the latest CUDA SDK installed? Compiling CUDA-dependent programs without it currently doesn't work. (I'm planning on a more robust handling of that situation in R9.)

Directory names are kind of a subjective thing; I personally prefer more descriptive names over compact names, but that may turn out to bite me when porting over to Unixes. I'll think about renaming them for the future, although it's a low priority thing at best.

Doubles and int64 types are planned for the future, but I need to clean up some of the code before wedging in additional types, because at the moment it's a royal pain to do.

Output formatting is considered a really low priority for now, because the existing debug read/write mechanism isn't really intended to do much more than let you dump trace information to the console. (It will be replaced with dumping trace information to an attached debugger in the future.)

Last but not least - for loops. There are two basic things that a for loop is traditionally used for: iteration across a container or sequence of some kind, and counting. I have plans for a powerful foreach that will take care of the first case, and I'd rather have a specific syntax for the second case. Something like this:

count(i, [100..1])
{
debugwritestring(cast(string, i) ; " bottles of beer on the wall.")
}


That depends on the syntax I end up using for numeric ranges, though, and may just change entirely if I feel the need. For now, though, the do and do-while loops are sufficient, until I get around to doing for loops properly.

Share this post


Link to post
Share on other sites
Yeah, I asked about getting rid of for loops in favor of foreach loops and range operations earlier here. The overwhelming consensus was that foreach/range was perfectly fine. It was a bit of a surprise actually. When I implemented that for Tangent it was never a problem, for what it's worth.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this