# RFC: Epoch Programming Language, Release 8

This topic is 3016 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## 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.
• 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 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 on other sites
I see that you're using a custom compiler backend. Wouldn't it be better to use an existing one (LLVM springs to mind)?

##### Share on other sites
Quote:
 Original post by HeptagonalI'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 KonfusiusI 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 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 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 on other sites
Quote:
 Original post by RoboguyI'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 HeptagonalI'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 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.exeEXEGEN - Epoch development toolkit[Plenty of stuff saying that the program has been built successfully]C:\Users\Martin\Desktop\Epoch Release 8\Tools>guessinggameC:\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 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 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]

• 9
• 23
• 10
• 19