1. The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 12, 2012
- 5174 views
Forked from Re: Colored Euphoria editor
A Euphoria IDE that is similar to Visual Studio would be great. I know that would take a lot of work, but it would be nice.
I have been musing about this myself for some time now. So far I have come up with this roadmap to make it happen:
- Standardize on a single GUI toolkit for the IDE (probably wxEuphoria)
- Bring that toolkit up to a "complete and stable" status (i.e. match the lastest stable/dev release on a feature-for-feature basis)
- Build a simple IDE framework onto which other modules can be loaded
- Write modules to extend/enhance IDE until it becomes "complete"
- Continue extending with more "extension" modules
Step #2 can probably be done in parallel with the development itself, adding and updating features as they are needed to make the IDE work. However, when the IDE itself is released as "stable", the toolkit should be as well, otherwise it could be crippling.
Modules and features required by this new IDE:
Code editor
- syntax highlighting
- code completion or "Intellisense"
- code folding, auto-indent, etc.
- display code errors on-the-fly
Forms designer
- drag-and-drop toolbox
- modular control support (design-time drawing, property editors, event handlers)
- support for "virtual" design features (e.g. sizers and non-visual components)
Project management
- new project wizard and templates
- solution/workspace management (document tree, etc.)
- build configurations (run/bind/compile, debug/release)
Runtime support
- display errors/output during execution
- automatically jump to last error on exit
- integrate with tracing for step-in/out/over
I am totally willing to work on and/or lead this project, especially if I have some helpful volunteers.
I'm going to start putting the next big version of wxEuphoria together, which will utilize a lot more Euphoria 4.0 features, like namespaces, enum types, etc. As I get that rolling, I will start building a framework onto which an IDE can be built.
Watch this space for details...
-Greg
2. Re: The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 12, 2012
- 5187 views
Here's my original mockup for a new IDE from years ago.
-Greg
3. Re: The Euphoria IDE Project
- Posted by jeremy (admin) Jun 12, 2012
- 5143 views
Are you going to host the repo publicly such as on bitbucket.org? It's nice to host Euphoria code there as Euphoria itself is tracked with Mercurial.
Jeremy
4. Re: The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 12, 2012
- 5148 views
Are you going to host the repo publicly such as on bitbucket.org? It's nice to host Euphoria code there as Euphoria itself is tracked with Mercurial.
Indeed I was! Once I start coding something, to BitBucket it shall go!
-Greg
5. Re: The Euphoria IDE Project
- Posted by Lone_EverGreen_Ranger Jun 12, 2012
- 5132 views
All this sounds good. Will this be an open-source effort?
6. Re: The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 13, 2012
- 5086 views
All this sounds good. Will this be an open-source effort?
Yessir. Probably GPLv3.
-Greg
7. Re: The Euphoria IDE Project
- Posted by jeremy (admin) Jun 13, 2012
- 5079 views
All this sounds good. Will this be an open-source effort?
Yessir. Probably GPLv3.
-Greg
Will that mean that apps created with it will not be able to be commercial? i.e You plan on having a designer and it writing code. I don't know if you plan on linking to any IDE specific code, if so GPL would prevent a lot of people from using it.
Jeremy
8. Re: The Euphoria IDE Project
- Posted by mattlewis (admin) Jun 13, 2012
- 5050 views
All this sounds good. Will this be an open-source effort?
Yessir. Probably GPLv3.
Will that mean that apps created with it will not be able to be commercial? i.e You plan on having a designer and it writing code. I don't know if you plan on linking to any IDE specific code, if so GPL would prevent a lot of people from using it.
That seems unusual. I assumed he meant the IDE code itself would be GPL3. The copyright of the output would be owned by the guy using the IDE, and not any sort of derivative of the IDE itself.
Matt
9. Re: The Euphoria IDE Project
- Posted by jimcbrown (admin) Jun 13, 2012
- 5083 views
All this sounds good. Will this be an open-source effort?
Yessir. Probably GPLv3.
Will that mean that apps created with it will not be able to be commercial? i.e You plan on having a designer and it writing code. I don't know if you plan on linking to any IDE specific code, if so GPL would prevent a lot of people from using it.
That seems unusual. I assumed he meant the IDE code itself would be GPL3. The copyright of the output would be owned by the guy using the IDE, and not any sort of derivative of the IDE itself.
Matt
Also, I imagine that any code emitted by the IDE itself as part of the designer process (any auto-template code) would become the property of IDE user (or at least be considered public domain), rather than being the property of Greg, and thus subject to the copyright of the user rather than Greg's copyright.
I am not sure abotu GPLv3, but GPLv2 wouldn't allow you to release autogenerated code (from e.g. a preprocessor) under it, you had to release the original source code too.
10. Re: The Euphoria IDE Project
- Posted by jimcbrown (admin) Jun 13, 2012
- 5049 views
All this sounds good. Will this be an open-source effort?
Yessir. Probably GPLv3.
-Greg
Will that mean that apps created with it will not be able to be commercial? i.e You plan on having a designer and it writing code. I don't know if you plan on linking to any IDE specific code, if so GPL would prevent a lot of people from using it.
Jeremy
I'd guess that the only code that needed 'linking' to would be the wxEuphoria libraries and their dependencies (wxWidgets itself, et al.). So this shouldn't even be an issue.
11. Re: The Euphoria IDE Project
- Posted by jeremy (admin) Jun 13, 2012
- 5048 views
Sounds good, as long as the IDE doesn't implement any supporting code/helper library that your app links to instead of being generated.
Jeremy
12. Re: The Euphoria IDE Project
- Posted by Lone_EverGreen_Ranger Jun 13, 2012
- 5022 views
Perhaps the IDE could be released under a custom license. Something that would allow users to release projects or programs they create in the IDE royalty free. Since the GPL is iffy in different regards to releasing derivatives works and stuff like that. Although if the IDE was licensed under the GPL, if you made a program in the IDE, the program you made could be released under any license you wanted, right?
13. Re: The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 13, 2012
- 5061 views
Many open-source IDEs are released under GPL: CodeLite, Geany, and wxDev-C++, to name a few.
At no point is the output created by using a GPL application required to be covered by the GPL, unless that output also somehow includes part of the original application (which is rare).
My original choice in GPLv3 was to keep things open-sourced if they are built on the framework design I plan to use. However, I may release this into two parts: an LGPL "framework library" and a GPLv3 "IDE application" based on that framework.
I will give it some more thought as I start putting things together. I will make sure to choose the correct open-source license to allow users to create commercial works, should they see fit, I promise.
-Greg
14. Re: The Euphoria IDE Project
- Posted by jeremy (admin) Jun 13, 2012
- 5052 views
Many open-source IDEs are released under GPL: CodeLite, Geany, and wxDev-C++, to name a few.
At no point is the output created by using a GPL application required to be covered by the GPL, unless that output also somehow includes part of the original application (which is rare).
My original choice in GPLv3 was to keep things open-sourced if they are built on the framework design I plan to use. However, I may release this into two parts: an LGPL "framework library" and a GPLv3 "IDE application" based on that framework.
I will give it some more thought as I start putting things together. I will make sure to choose the correct open-source license to allow users to create commercial works, should they see fit, I promise.
The application (IDE) is fine to be released as GPL, even if it generates source code. If, however, you do have a framework library, if you want anyone to be able to use it for commercial or many open source situations, it can not be licensed as GPL. It could be LGPL. If you have no framework library, then there is no need to worry about about GPL or not.
Jeremy
15. Re: The Euphoria IDE Project
- Posted by Lone_EverGreen_Ranger Jun 13, 2012
- 4988 views
Everything seems fine now that the license issues are out of the way. Is the project still in the deciding what tools to use stage?I won't keep asking questions about development. I'm just wondering how far along the project is, so far.
16. Re: The Euphoria IDE Project
- Posted by m_sabal Jun 14, 2012
- 4932 views
If WX is the GUI toolkit of choice, has any work been done yet on implementing a wxEuphoria project on Mac without having to install the whole toolkit independently? If the toolkit does have to be distributed independently on Mac, does anybody know where there might be a pre-compiled dmg. I have a number of people asking for Euphoria based applications I've written for Windows to be available for Mac, and these people don't have any idea that Mac comes with a terminal application, much less know how to use a command line.
17. Re: The Euphoria IDE Project
- Posted by mattlewis (admin) Jun 14, 2012
- 4945 views
If WX is the GUI toolkit of choice, has any work been done yet on implementing a wxEuphoria project on Mac without having to install the whole toolkit independently? If the toolkit does have to be distributed independently on Mac, does anybody know where there might be a pre-compiled dmg. I have a number of people asking for Euphoria based applications I've written for Windows to be available for Mac, and these people don't have any idea that Mac comes with a terminal application, much less know how to use a command line.
It should be possible to build a version of wxEuphoria for OSX.
I think it may not work as-is right now, however, due to various parts of the library that may or may not be part of a "normal" OSX build of wxWidgets. Someone was looking to do this, and found some of these issues. Basically, wxWidgets has various bits, many of which are optional. The wxEuphoria wrappers may not correctly detect when some modules aren't available in the version of wxWidgets being used (e.g., it may exclude the wxMediaCtrl). This is usually as simple as adding some #ifdefs to the wxEuphoria C++ code.
Matt
18. Re: The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 14, 2012
- 4879 views
Everything seems fine now that the license issues are out of the way. Is the project still in the deciding what tools to use stage?I won't keep asking questions about development. I'm just wondering how far along the project is, so far.
I've pretty much decided on wxEuphoria as the GUI toolkit; I'd like this project to be entirely cross-platform. I'm still working out the logistics of the framework - that needs to be done properly from the start.
If WX is the GUI toolkit of choice, has any work been done yet on implementing a wxEuphoria project on Mac without having to install the whole toolkit independently? If the toolkit does have to be distributed independently on Mac, does anybody know where there might be a pre-compiled dmg. I have a number of people asking for Euphoria based applications I've written for Windows to be available for Mac, and these people don't have any idea that Mac comes with a terminal application, much less know how to use a command line.
I have an old eMac that I plan on doing some development on. I'd like to see wxEuphoria applications run on PowerPC computers as well.
-Greg
19. Re: The Euphoria IDE Project
- Posted by tbohon Jun 16, 2012
- 4663 views
This is an exciting development guys ... looking forward to following the process!
Thanks
20. Re: The Euphoria IDE Project
- Posted by petelomax Jun 17, 2012
- 4610 views
I'm going to start putting the next big version of wxEuphoria together
I had a look this weekend at getting wxEuphoria to run on Phix, and I made some notes on the matter. My apologies if this isn't helpful.
It seems I would need to suck alot of complexity out of libwxeu.dll (C++) into wxeud.e, specifically defaults, reference counting, and delete routines. In short, libwxeu.dll/so should contain absolutely no knowledge whatsoever of underlying data structures, and hence be compatible with both OpenEu and Phix.
Routines must be called/defined with atoms/pointers (C_INT etc), rather than E_SEQUENCE/E_OBJECT/E_ATOM/E_INTEGER. The logic for defaulted parameters would need to be moved out of wxeu.cpp, so for example (simplified/untested) instead of:
global function create(integer class, sequence params) object rid rid = WX_CREATE_ARRAY[class] return c_func(rid, {params}) end function
and
#define NEW_CONTROL(control) \ s1_ptr p = SEQ_PTR( params );\ wxPoint pos = wxDefaultPosition;\ wxSize size = wxDefaultSize;\ intptr_t style = 0;\ wxWindowID id = -1;\ wxString caption(wxT(""));\ \ switch( p->length ){\ case 8:\ style = get_int( params, 8 );\ \ case 7:\ size = wxSize( get_int( params, 6 ), get_int( params, 7 ) );\ \ case 6:\ case 5:\ pos = wxPoint( get_int( params, 4 ), get_int( params, 5) );\ \ case 4:\ case 3:\ caption = get_string( params, 3 );\ case 2:\ id = get_int( params, 2 );\ default:\ break;\ }\ control * cont = new control( (wxWindow *)get_int(params, 1),\ id, caption,\ pos, size, style );\ wxDeRefDS(params);\ return BOX_INT( cont );It would be more like:
global function create(integer class, sequence params) object rid integer style = 0 integer sizeX = -1, sizeY = -1 integer posX = -1, posY = -1 sequence caption = "" integer id = -1 integer parent switch length(params) with fallthrough 8: style = params[8] 7: sizeX = params[6] sizeY = params[7] 6,5: posX = params[4] posY = params[5] 4,3: caption = params[3] 2: id = params[2] 1: parent = params[1] end switch rid = WX_CREATE_ARRAY[class] return c_func(rid, {parent,id,caption,posX,posY,sizeX,sizeY,style}) end function
and
#define NEW_CONTROL(control) \ wxPoint pos = {posX,posY};\ wxSize size = {sizeX,sizeY};\ return new control( (wxWindow *)parent, id, caption, pos, size, style );
I appreciate that with some 1,400 routines that may be a massive amount of work and I have no idea what impact it would have on performance, but it may lead to better errors, eg "type check error, caption is 0".
Also, I don't really understand why it needs wxDeRefDS() etc; I can only assume that because it is using E_SEQUENCE; params gets incref'd and ends up in libwxeu.dll with a ref count >=2? Unless you do on-the-fly creation in wxeud.e then the actual deallocation/calling of any delete routine etc will occur not in libwxeu.dll but in exeud.e when "params" gets decref'd or when some callee variable drops out of scope.
Anyway, that's where I got, like I said don't know if that is of any interest or use.
The alternative would be to rewrite wxeu.cpp pretty much from scratch, but embed the knowledge of the underlying Phix data structures rather than those of OpenEu.
Regards, Pete
21. Re: The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 17, 2012
- 4664 views
I had a look this weekend at getting wxEuphoria to run on Phix, and I made some notes on the matter. My apologies if this isn't helpful.
It seems I would need to suck alot of complexity out of libwxeu.dll (C++) into wxeud.e, specifically defaults, reference counting, and delete routines. In short, libwxeu.dll/so should contain absolutely no knowledge whatsoever of underlying data structures, and hence be compatible with both OpenEu and Phix.
Routines must be called/defined with atoms/pointers (C_INT etc), rather than E_SEQUENCE/E_OBJECT/E_ATOM/E_INTEGER. The logic for defaulted parameters would need to be moved out of wxeu.cpp, so for example (simplified/untested) instead of:
I appreciate that with some 1,400 routines that may be a massive amount of work and I have no idea what impact it would have on performance, but it may lead to better errors, eg "type check error, caption is 0".
Actually Pete, you and I are on a similar page here. For the next major release of wxEuphoria, I am working on separating all functionality back out into namespaces that match the existing class structure of wxWidgets.
A few nice side-effect of this will be:
- all default parameters would be part of the Euphoria code
- custom types will allow type-checking on all wxWidgets controls
- the API will more closely match native wxWidgets code (and wxPerl, wxPython, etc.)
- you will only have to include the files necessary for the controls you use
Here's a chunk of an include file:
-- wxFrame.e namespace wxFrame -- wxFrame inherits from wxTopLevelWindow public include "wxeu/wxTopLevelWindow.e" constant wxFrame_Create = define_c_func( libwxeu, "wxFrame_Create", {C_POINTER,C_UINT,E_OBJECT,C_INT,C_INT,C_INT,C_INT,C_LONG,E_OBJECT}, C_POINTER ) constant wxFrame_IsTypeOf = define_c_func( libwxeu, "wxFrame_IsTypeOf", {C_POINTER}, C_UINT ) public type wxFrame( atom x ) return c_func( wxFrame_IsTypeOf, {x} ) end type public function Create( wxWindow parent, integer id = -1, sequence text = "", integer x = -1, integer y = -1, integer width = -1, integer height = -1, atom flags = wxDEFAULT_FRAME_STYLE, sequence name = wxFrameNameStr ) return c_func( wxFrame_Create, {parent, id, text, x, y, width, height, flags, name} ) end function
Hopefully when I'm done, we'll be writing code like this:
-- demo.exw include "wxeu/wxFrame.e" include "wxeu/wxPanel.e" include "wxeu/wxStaticText.e" wxFrame frame1 = wxFrame:Create( 0, -1, "Demo" ) wxPanel panel1 = wxPanel:Create( frame1 ) wxStaticText staticText1 = wxStaticText:Create( panel1, -1, "Text" ) wxMain( wxFrame )
Also, I don't really understand why it needs wxDeRefDS() etc; I can only assume that because it is using E_SEQUENCE; params gets incref'd and ends up in libwxeu.dll with a ref count >=2? Unless you do on-the-fly creation in wxeud.e then the actual deallocation/calling of any delete routine etc will occur not in libwxeu.dll but in exeud.e when "params" gets decref'd or when some callee variable drops out of scope.
Anyway, that's where I got, like I said don't know if that is of any interest or use.
The alternative would be to rewrite wxeu.cpp pretty much from scratch, but embed the knowledge of the underlying Phix data structures rather than those of OpenEu.
The calls to wxDeRefDS() are necessary to decrement the reference counter on Euphoria objects, which happens automatically in translated Euphoria code, but has to be done manually in our hand-coded C++ library. It's really just this simple macro...
#define wxDeRefDS(a) assert(DBL_PTR(a)->ref); --(DBL_PTR(a)->ref);
-Greg
22. Re: The Euphoria IDE Project
- Posted by EUWX Jun 17, 2012
- 4544 views
I'm going to start putting the next big version of wxEuphoria together
I had a look this weekend at getting wxEuphoria to run on Phix, and I made some notes on the matter. My apologies if this isn't helpful.............
I appreciate that with some 1,400 routines that may be a massive amount of work and I have no idea what impact it would have on performance, but it may lead to better errors, eg "type check error, caption is 0". .............
Regards, Pete
I am a simple programmer. I am sure there are many others like me, who are not too particular about changes in the structure of wxEuphoria, but would like a good working wxEuphoria IDE. I would think that making changes in the IDE to make it a nice working IDE would be far easier and much less time consuming.
Even a good working editor for wxEuphoria integrated with version 4, would be a great help
23. Re: The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 18, 2012
- 4491 views
I am a simple programmer. I am sure there are many others like me, who are not too particular about changes in the structure of wxEuphoria, but would like a good working wxEuphoria IDE. I would think that making changes in the IDE to make it a nice working IDE would be far easier and much less time consuming.
Even a good working editor for wxEuphoria integrated with version 4, would be a great help
I first need to get wxEuphoria to a "complete, stable, and released" state on wxWidgets 2.9. This affords us many more features which will make an IDE and a simple editor much easier to write, including wxStyledTextCtrl (the Scintilla editor component) and wxPropertyGrid. I'll probably end up rebuilding wxEditor first, because its functionality is really the "core" of the IDE. So you'll have your editor and an IDE, too!
-Greg
24. Re: The Euphoria IDE Project
- Posted by Fendaril Jun 18, 2012
- 4483 views
I am a simple programmer. I am sure there are many others like me, who are not too particular about changes in the structure of wxEuphoria, but would like a good working wxEuphoria IDE. I would think that making changes in the IDE to make it a nice working IDE would be far easier and much less time consuming.
Even a good working editor for wxEuphoria integrated with version 4, would be a great help
I first need to get wxEuphoria to a "complete, stable, and released" state on wxWidgets 2.9. This affords us many more features which will make an IDE and a simple editor much easier to write, including wxStyledTextCtrl (the Scintilla editor component) and wxPropertyGrid. I'll probably end up rebuilding wxEditor first, because its functionality is really the "core" of the IDE. So you'll have your editor and an IDE, too!
-Greg
Speaking of this, I would love a gui designer that generated wxEuphoria code. That would attract lazy bums like me to euphoria, and lazy bums are prevalent in this age of RAD!
25. Re: The Euphoria IDE Project
- Posted by euphoric (admin) Jun 18, 2012
- 4475 views
Speaking of this, I would love a gui designer that generated wxEuphoria code. That would attract lazy bums like me to euphoria, and lazy bums are prevalent in this age of RAD!
Fendaril, I currently use wxFormBuilder to build the interface, then write the program in Crimson/Emerald. This is a really easy route right now until we get that wxIDE.
26. Re: The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 18, 2012
- 4456 views
Speaking of this, I would love a gui designer that generated wxEuphoria code. That would attract lazy bums like me to euphoria, and lazy bums are prevalent in this age of RAD!
A GUI designer will be part of this IDE. That is my first and highest priority. I want to "do RAD right" this time around. (The Win32Lib IDE does a decent job with GUI design, but it's outdated and leaves a lot to be desired, plus Win32Lib doesn't really play to the cross-platform strengths of Euphoria 4.)
-Greg
27. Re: The Euphoria IDE Project
- Posted by euphoric (admin) Jun 18, 2012
- 4448 views
A GUI designer will be part of this IDE. That is my first and highest priority.
I'm ready to alpha/beta test. Let's go! XD
28. Re: The Euphoria IDE Project
- Posted by mattlewis (admin) Jun 18, 2012
- 4419 views
I had a look this weekend at getting wxEuphoria to run on Phix, and I made some notes on the matter. My apologies if this isn't helpful.
It seems I would need to suck alot of complexity out of libwxeu.dll (C++) into wxeud.e, specifically defaults, reference counting, and delete routines. In short, libwxeu.dll/so should contain absolutely no knowledge whatsoever of underlying data structures, and hence be compatible with both OpenEu and Phix.
Routines must be called/defined with atoms/pointers (C_INT etc), rather than E_SEQUENCE/E_OBJECT/E_ATOM/E_INTEGER. The logic for defaulted parameters would need to be moved out of wxeu.cpp, so for example (simplified/untested) instead of:
First, I would like to emphasize that if you have used C_INT, C_LONG (or their unsigned counterparts) for a pointer, you're doing it wrong, as these are not portable. Euphoria 4.1 will also run on 64-bit operating systems, so this is important.
Previous versions of wxEuphoria required that the manipulation of pointers, peeking and poking be done on the euphoria side. Not surprisingly, it's a lot easier to work with C++ data in C++ than in euphoria. Also, moving the creation macros into euphoria code would mean writing a lot more code.
Also, I don't really understand why it needs wxDeRefDS() etc; I can only assume that because it is using E_SEQUENCE; params gets incref'd and ends up in libwxeu.dll with a ref count >=2? Unless you do on-the-fly creation in wxeud.e then the actual deallocation/calling of any delete routine etc will occur not in libwxeu.dll but in exeud.e when "params" gets decref'd or when some callee variable drops out of scope.
wxEuphoria follows "normal" euphoria reference counting semantics, which makes using it very simple from a euphoria point of view, and is necessary to take E_SEQUENCE, etc, parameters and prevent memory leaks.
Anyway, that's where I got, like I said don't know if that is of any interest or use.
The alternative would be to rewrite wxeu.cpp pretty much from scratch, but embed the knowledge of the underlying Phix data structures rather than those of OpenEu.
Yes, it sounds like that's what would have to happen. After a lot of experimenting, I think that the way I've got wxEuphoria working is the easiest way to go about wrapping a C++ library.
Matt
29. Re: The Euphoria IDE Project
- Posted by jimcbrown (admin) Jun 18, 2012
- 4397 views
The alternative would be to rewrite wxeu.cpp pretty much from scratch, but embed the knowledge of the underlying Phix data structures rather than those of OpenEu.
Yes, it sounds like that's what would have to happen. After a lot of experimenting, I think that the way I've got wxEuphoria working is the easiest way to go about wrapping a C++ library.
Matt
What about a unified library interface? Once that defined C macros that allowed you to switch the build between Phix and OpenEuphoria simply by changing an ifdef or something?
So we'd have a WXEU_POINTER that would be C_POINTER for 4.1 and C_INT for Phix, and a WXEU_DEREF_DS that'd call the right version of deref for 4.1 or Phix...
30. Re: The Euphoria IDE Project
- Posted by EUWX Jun 18, 2012
- 4377 views
I first need to get wxEuphoria to a "complete, stable, and released" state on wxWidgets 2.9. This affords us many more features which will make an IDE and a simple editor much easier to write, including wxStyledTextCtrl (the Scintilla editor component) and wxPropertyGrid. I'll probably end up rebuilding wxEditor first, because its functionality is really the "core" of the IDE. So you'll have your editor and an IDE, too!
-Greg
I have some other concerns too. I generated a small program using, pure Euphoria and also some wxEuphoria (2.8) code. I used Wordpad. The moment you save the file as Unicode, you can't use it.
I then tried with the trial version of EditPlus which is a sophisticated Editor, and again the same problem, Save it as any type of Unicode file and it s unusable by Euphoria.
I understand that wxWidgets 2.9 is totally Unicode, so there may be other problems using it with Euphoria.
31. Re: The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 18, 2012
- 4344 views
I have some other concerns too. I generated a small program using, pure Euphoria and also some wxEuphoria (2.8) code. I used Wordpad. The moment you save the file as Unicode, you can't use it.
I then tried with the trial version of EditPlus which is a sophisticated Editor, and again the same problem, Save it as any type of Unicode file and it s unusable by Euphoria.
I understand that wxWidgets 2.9 is totally Unicode, so there may be other problems using it with Euphoria.
Euphoria itself still reads plain ASCII source code files. The "Unicode" support in wxWidgets is internal: it natively stores strings in Unicode format and makes calls to the appropriate Unicode system functions. I am already using wxWidgets 2.9 with Euphoria 4.0, so I know it works. I don't think you have anything to worry about.
-Greg
32. Re: The Euphoria IDE Project
- Posted by EUWX Jun 18, 2012
- 4332 views
I have some other concerns too. I generated a small program using, pure Euphoria and also some wxEuphoria (2.8) code. I used Wordpad. The moment you save the file as Unicode, you can't use it.
I then tried with the trial version of EditPlus which is a sophisticated Editor, and again the same problem, Save it as any type of Unicode file and it s unusable by Euphoria.
I understand that wxWidgets 2.9 is totally Unicode, so there may be other problems using it with Euphoria.
Euphoria itself still reads plain ASCII source code files. The "Unicode" support in wxWidgets is internal: it natively stores strings in Unicode format and makes calls to the appropriate Unicode system functions. I am already using wxWidgets 2.9 with Euphoria 4.0, so I know it works. I don't think you have anything to worry about.
-Greg
Thanks. I shall wait for your big swing to wxWidget2.9 and the corresponding wsEuphoria with all the proposed namespaces (Oh, I so dislike Namespaces and Includes)
33. Re: The Euphoria IDE Project
- Posted by mattlewis (admin) Jun 18, 2012
- 4350 views
The alternative would be to rewrite wxeu.cpp pretty much from scratch, but embed the knowledge of the underlying Phix data structures rather than those of OpenEu.
Yes, it sounds like that's what would have to happen. After a lot of experimenting, I think that the way I've got wxEuphoria working is the easiest way to go about wrapping a C++ library.
What about a unified library interface? Once that defined C macros that allowed you to switch the build between Phix and OpenEuphoria simply by changing an ifdef or something?
So we'd have a WXEU_POINTER that would be C_POINTER for 4.1 and C_INT for Phix, and a WXEU_DEREF_DS that'd call the right version of deref for 4.1 or Phix...
I'm not really against this or anything, but personally I have no motivation to do anything Phix related. I can't even keep up with all of the euphoria stuff I want to do.
Matt
34. Re: The Euphoria IDE Project
- Posted by petelomax Jun 19, 2012
- 4353 views
First, I would like to emphasize that if you have used C_INT, C_LONG (or their unsigned counterparts) for a pointer, you're doing it wrong, as these are not portable. Euphoria 4.1 will also run on 64-bit operating systems, so this is important.
Just checking: C_PTR is fine on 64-bit? And 64-bit is what you meant by "portable"?
Previous versions of wxEuphoria required that the manipulation of pointers, peeking and poking be done on the euphoria side.
Hmm. Maybe I should start with an old version then. Is there one still available?
What about a unified library interface? Once that defined C macros that allowed you to switch the build between Phix and OpenEuphoria simply by changing an ifdef or something?
So we'd have a WXEU_POINTER that would be C_POINTER for 4.1 and C_INT for Phix, and a WXEU_DEREF_DS that'd call the right version of deref for 4.1 or Phix...
I thought about that but quickly realised it's a longer-term goal. There would need to be two different builds/names of libwxeu.dll. Get something (anything!) working first.
I'm not really against this or anything, but personally I have no motivation to do anything Phix related.
Quite right. Phix is asm-based and you're a C++-head so I wouldn't want your help anyway
Regards,
Pete
35. Re: The Euphoria IDE Project
- Posted by jimcbrown (admin) Jun 19, 2012
- 4295 views
First, I would like to emphasize that if you have used C_INT, C_LONG (or their unsigned counterparts) for a pointer, you're doing it wrong, as these are not portable. Euphoria 4.1 will also run on 64-bit operating systems, so this is important.
Just checking: C_PTR is fine on 64-bit? And 64-bit is what you meant by "portable"?
Pete
C_POINTER is fine.
We also support 32bit ARM in 4.1, though I'm not sure if wxEuphoria works on that platform yet.
36. Re: The Euphoria IDE Project
- Posted by ghaberek (admin) Jun 19, 2012
- 4370 views
We also support 32bit ARM in 4.1, though I'm not sure if wxEuphoria works on that platform yet.
I plan on getting either a Raspberry Pi and/or an Android PC System so I can develop against ARM with wxEuphoria. (Assuming I can install something like Debian/Ubuntu on the APC).
-Greg
37. Re: The Euphoria IDE Project
- Posted by mattlewis (admin) Jun 19, 2012
- 4313 views
First, I would like to emphasize that if you have used C_INT, C_LONG (or their unsigned counterparts) for a pointer, you're doing it wrong, as these are not portable. Euphoria 4.1 will also run on 64-bit operating systems, so this is important.
Just checking: C_PTR is fine on 64-bit? And 64-bit is what you meant by "portable"?
Yes. C_POINTER and C_LONG change size depending on the architecture and operating system. In general, if you're wrapping some C/C++, try to use exactly what the documentation says it wants. Of course, this is difficult with Microsoft stuff, since they have their own ecosystem of typedefs.
Previous versions of wxEuphoria required that the manipulation of pointers, peeking and poking be done on the euphoria side.
Hmm. Maybe I should start with an old version then. Is there one still available?
There doesn't appear to be a download available any more for any versions previous to the current wrapping method. It's all there in the source control history, though.
I'm not really against this or anything, but personally I have no motivation to do anything Phix related.
Quite right. Phix is asm-based and you're a C++-head so I wouldn't want your help anyway
Thanks for letting me off the hook.
Matt
38. Re: The Euphoria IDE Project
- Posted by EUWX Jun 19, 2012
- 4301 views
Quite right. Phix is asm-based and you're a C++-head so I wouldn't want your help anyway
If you have not yet looked at it, Randy Hyde's HLA is worth looking at.
http://tech.groups.yahoo.com/group/aoaprogramming/
It gives you a very good way of writing in Assembler and easy connection to C++, including interfacing to DLLs, etc
http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/HighLevelAsm/dnld.html
39. Re: The Euphoria IDE Project
- Posted by Jerome Jul 21, 2012
- 3538 views
We also support 32bit ARM in 4.1, though I'm not sure if wxEuphoria works on that platform yet.
I plan on getting either a Raspberry Pi and/or an Android PC System so I can develop against ARM with wxEuphoria. (Assuming I can install something like Debian/Ubuntu on the APC).
-Greg
I have cross-compiled wxWidgets-2.9.4 for the Raspberry Pi without any issues, and I'm excited about the possiblities of using the new wxEuphoria for development! If you need any testing/debugging done for the arm platform, I would like to help!
Thanks,
Ira
40. Re: The Euphoria IDE Project
- Posted by SDPringle Nov 08, 2012
- 3121 views
Don't misunderstand: The C types C_LONG, C_INT, C_SHORT are as portable as C_POINTER. Get the alternative literals branch. It has cross enum type checking.