1. development ideas for 4.1
- Posted by SDPringle Feb 11, 2011
- 1888 views
There is talk about making C structs easier and less error prone in EUPHORIA. The reason we need to interface with C is it is that most of the APIs are written in C. In addition of wrapping C structs you also have to declare your routines separately and you also must define the constant values.
Rather than doing all of this wouldn't be better if we could simply include the C header from the EUPHORIA file? We would need a way to tokenize preprocessor syntax and also C header syntax. I am taking this idea to the forum as it might attract ideas.
There is no way to record sound in EUPHORIA. All of the API wrappers for EUPHORIA only support playing.
Shawn
2. Re: development ideas for 4.1
- Posted by mattlewis (admin) Feb 11, 2011
- 1860 views
There is talk about making C structs easier and less error prone in EUPHORIA. The reason we need to interface with C is it is that most of the APIs are written in C. In addition of wrapping C structs you also have to declare your routines separately and you also must define the constant values.
Rather than doing all of this wouldn't be better if we could simply include the C header from the EUPHORIA file? We would need a way to tokenize preprocessor syntax and also C header syntax. I am taking this idea to the forum as it might attract ideas.
In theory, and for some really simple headers, this would probably work pretty well. But many headers will rely on other included headers for things like data types. Also, ifdefs and other preprocessor macros make this a lot more complicated. So, I'm sure that it's possible to do this for really simple headers, it wouldn't be a general solution, unless euphoria were also able to parse C.
I'd be happy to be proven wrong, of course.
Matt
3. Re: development ideas for 4.1
- Posted by coconut Feb 11, 2011
- 1904 views
There is talk about making C structs easier and less error prone in EUPHORIA. The reason we need to interface with C is it is that most of the APIs are written in C. In addition of wrapping C structs you also have to declare your routines separately and you also must define the constant values.
Rather than doing all of this wouldn't be better if we could simply include the C header from the EUPHORIA file? We would need a way to tokenize preprocessor syntax and also C header syntax. I am taking this idea to the forum as it might attract ideas.
In theory, and for some really simple headers, this would probably work pretty well. But many headers will rely on other included headers for things like data types. Also, ifdefs and other preprocessor macros make this a lot more complicated. So, I'm sure that it's possible to do this for really simple headers, it wouldn't be a general solution, unless euphoria were also able to parse C.
The same is true for others complex toolkit as GTK+...
I'd be happy to be proven wrong, of course.
Matt
I agree with Matt, as in the past I tried to write a program that would convert C header to something usable directly by euphoria. I abandoned the project as I realized it would be more works that I thought at first. Just take windows SDK. In C to write a windows application one include windows.h but windows.h is only a top level include that itself includes others headers. And the include dept is deep, and as Matt says there is a lot of macros and ifdef...
Jacques.
4. Re: development ideas for 4.1
- Posted by DerekParnell (admin) Feb 11, 2011
- 1845 views
There is talk about making C structs easier and less error prone in EUPHORIA. The reason we need to interface with C is it is that most of the APIs are written in C. In addition of wrapping C structs you also have to declare your routines separately and you also must define the constant values.
Rather than doing all of this wouldn't be better if we could simply include the C header from the EUPHORIA file? We would need a way to tokenize preprocessor syntax and also C header syntax. I am taking this idea to the forum as it might attract ideas.
In theory, and for some really simple headers, this would probably work pretty well. But many headers will rely on other included headers for things like data types. Also, ifdefs and other preprocessor macros make this a lot more complicated. So, I'm sure that it's possible to do this for really simple headers, it wouldn't be a general solution, unless euphoria were also able to parse C.
I'd be happy to be proven wrong, of course.
Matt
Matt's right. We would have to write and maintain a full C parser and C macro processor to be able to translate C headers for Euphoria usage.
I don't think that the cost would justify the benefit.
5. Re: development ideas for 4.1
- Posted by SDPringle Feb 11, 2011
- 1888 views
It would need to be a full preprocessor but it wouldn't have to be a full C parser. It just would need to parse C expressions. That means there would be no need to parse function definitions.
Shawn
6. Re: development ideas for 4.1
- Posted by DerekParnell (admin) Feb 11, 2011
- 1864 views
It would need to be a full preprocessor but it wouldn't have to be a full C parser. It just would need to parse C expressions. That means there would be no need to parse function definitions.
My point still remains ... the exercise will cost more than its worth.
It would still need to parse function headers.
typedef char *f(int a) cf; cf *F1;
And function definitions are simply ..
FuncHeader StatementBlockSo not being able to parse that is not a big deal.
7. Re: development ideas for 4.1
- Posted by mattlewis (admin) Feb 11, 2011
- 1910 views
It would need to be a full preprocessor but it wouldn't have to be a full C parser. It just would need to parse C expressions. That means there would be no need to parse function definitions.
My point still remains ... the exercise will cost more than its worth.
It might be time for someone to try adding euphoria support to SWIG again.
Matt
8. Re: development ideas for 4.1
- Posted by SDPringle Feb 15, 2011
- 1746 views
Jacques,
would you still happen to have some of that code? Mine parses macro conditions and constants so far. I am trying to get all of the conditionals right before moving on the parsing the C stuff. I am using some of the constants from euphoria/tokenize.e.
9. Re: development ideas for 4.1
- Posted by coconut Feb 15, 2011
- 1676 views
Jacques,
would you still happen to have some of that code? Mine parses macro conditions and constants so far. I am trying to get all of the conditionals right before moving on the parsing the C stuff. I am using some of the constants from euphoria/tokenize.e.
It would not be of any use to you, my code only parse macro that define constants, something you already have done.
jacques
10. Re: development ideas for 4.1
- Posted by jimcbrown (admin) Feb 16, 2011
- 1590 views
It would need to be a full preprocessor but it wouldn't have to be a full C parser. It just would need to parse C expressions. That means there would be no need to parse function definitions.
My point still remains ... the exercise will cost more than its worth.
It might be time for someone to try adding euphoria support to SWIG again.
Matt
I liked SWIG.
