1. Updates on Eu 4.2.0

Hello,

I'm just curious if there has been any recent development on Euphoria 4.2.0?

new topic     » topic index » view message » categorize

2. Re: Updates on Eu 4.2.0

Icy_Viking said...

Hello,

I'm just curious if there has been any recent development on Euphoria 4.2.0?

I've been trying to put the memstruct feature through its paces and I've run into a few bugs with parsing and other runtime crashes that I need to sort out. I'm also still debating renaming the keywords for memstruct. I'm open to input and suggestions on this. Pretty sure it's a trivial change in the parser. If we eventually pull in Matt's OOEU to add classes, I'd definitely want to avoid his current "euclass" keyword and just use "class" instead.

Current Proposed
memstruct struct
memunion union
memtype typedef

I'm also trying to get a continuous integration environment set up using Docker and GitHub Actions so that we can have more regular release cycles. Ideally you'd be able to run something like docker run openeuphoria/euphoria-build:latest on your own machine to get a complete build, and GitHub would run the same thing on pushes and merges to verify the build was passing. Then when we tag new versions, it could package everything and publish it to the project's "Releases" page.

-Greg

new topic     » goto parent     » topic index » view message » categorize

3. Re: Updates on Eu 4.2.0

Hi

My 2 new pence worth - if the meanings follow C, then I have no problem - if it's significantly different then it could create confusion. ie if a struct in Euphoria can create a struct that C can use, then that's good. If you have to do much fiddling to get the eu struct to a c struct then that is not good. I take it the idea is to get direct insertion into C created DLLs?

Andy's probably wrapped it already anyway.

Cheers

Chris

new topic     » goto parent     » topic index » view message » categorize

4. Re: Updates on Eu 4.2.0

ChrisB said...

My 2 new pence worth - if the meanings follow C, then I have no problem - if it's significantly different then it could create confusion. ie if a struct in Euphoria can create a struct that C can use, then that's good. If you have to do much fiddling to get the eu struct to a c struct then that is not good. I take it the idea is to get direct insertion into C created DLLs?

Yes, that's the intent. Here's the introduction from the docs. You can read more here: Memory Structures

docs said...

Introduction

Writing Euphoria code to interact with the operating system or external libraries often requires communicating via data structures stored in memory. In addition to using peeks and pokes to read and write to memory locations, Euphoria programmers can also define structures that can be used to more easily read and write values from and into memory.

The conventions used are similar to those found in the C programming language, since that's the way the most commonly encountered structures are defined and meant to be used. This is meant to provide a familiar syntax to those who already know C, and also to make it easy to define and use memory structures.

I'd say the only thing "Euphorian" about the syntax is that we're avoiding the use of the asterisk * for pointer declarations, and instead using the literal keyword pointer. However, it seems Matt still chose to use an asterisk for dereferencing pointers, which I'm not fond of.

docs said...

Reading and assigning with pointers

A memstruct member that is itself a pointer has an additional way to be used. The normal assignment and reading operations deal with the value of the pointer itself. To access the value to which the pointer points, use an additional dot, then an asterisk:

memstruct PTR_TO_INT 
    pointer int a 
end memstruct 
 
atom ptr = allocate( sizeof( PTR_TO_INT ) ) 
ptr.PTR_TO_INT.a = allocate( sizeof( int ) ) 
 
ptr.PTR_TO_INT.a.* = 5 
ptr.PTR_TO_INT.a.* += 5 
 
? ptr.PTR_TO_INT.a.* -- prints 10 

I think I'd rather see this syntax go away and instead encourage use of peek() and poke(). Internally, we'd have to adapt the parser to account for memstructs the same way it does for sizeof(). Given the example above, this would probably require introducing some new routines for operating on values memory, like incr() as shown below.

--ptr.PTR_TO_INT.a.* = 5 
poke( ptr.PTR_TO_INT.a, 5 ) 
 
--ptr.PTR_TO_INT.a.* += 5 
incr( ptr.PTR_TO_INT.a, 5 ) 
 
--? ptr.PTR_TO_INT.a.* -- prints 10 
? peek( ptr.PTR_TO_INT.a ) 

I'm not trying to hide pointers from those who want to use them. But I feel like mixing in little bits of C breaks the syntax and readability of Euphoria code. Plus, using routines to do things like this may help people better understand what the code is supposed to be doing.

This seems clear to me. It says, "increment the value at ptr.PTR_TO_INT.a by a value of 5."

incr( ptr.PTR_TO_INT.a, 5 ) 

Where as this... uh... what's that asterisk for again? I guess it's adding 5 to something?

ptr.PTR_TO_INT.a.* += 5 

One thing I've gleaned from playing around with newer languages like Go, Rust, etc. is that they really love their punctuation-based and abbreviated-keyword syntax, to the point where a newcomer to the language can't make sense of what's going on without keeping a reference manual in their hand. The power of Euphoria, I believe, is that anyone can read the code out loud and make sense of it. I want to ensure we maintain this. I'm not sure we can lean hard on "the fastest" any more, but we can still promote "clean and readable" code.

Again, I'm open to suggestions. Changes like these may be worthwhile but will also take more time.

-Greg

new topic     » goto parent     » topic index » view message » categorize

5. Re: Updates on Eu 4.2.0

I like having the names changed from memstruct to struct and so on. I think it makes the coder easier to read. I also like the idea of using poke and peek in dealing with pointers.

new topic     » goto parent     » topic index » view message » categorize

6. Re: Updates on Eu 4.2.0

ghaberek said...

One thing I've gleaned from playing around with newer languages like Go, Rust, etc. is that they really love their punctuation-based and abbreviated-keyword syntax, to the point where a newcomer to the language can't make sense of what's going on without keeping a reference manual in their hand. The power of Euphoria, I believe, is that anyone can read the code out loud and make sense of it. I want to ensure we maintain this. I'm not sure we can lean hard on "the fastest" any more, but we can still promote "clean and readable" code.

I completely agree with this.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu