OpenEuphoria

1. UI Committee Round 2

• Posted by xecronix Dec 11, 2015
• 4020 views

Forked from Re: Is there a good Windows or cross-platform Euphoria IDE?

The idea of a committee was first born with the above goals in mind. If these are still OE goals, I'm happy to continue working on it by driving conversations that address cross platform distribution and build integration. These conversations will need to keep in mind the 3 primary roles (ie developer, OE user, and OE user's customer) for both compiled and interpreted programs. The goals of these conversations are to create direction, mile stones, and tickets for this effort.

My question for the community is this: Do we still want these goals realized?

-xecronix

3. Re: UI Committee Round 2

• Posted by xecronix Dec 13, 2015
• 3902 views

At this time there are 131 views and 1 response. I’m not sure how to interpret these numbers except to conclude that as a community, we are not interested in a fully integrated UI/Editor solution.

If that’s true this is good news for several reasons:

• The development team can focus on new features the community actually wants. Like mem- structs?
• I was wrong about the failure of the committee idea. In fact the committee idea was a huge success and was able to drill down to the heart of the problem very quickly.
• Ed can be dropped and consequently less code/docs maintained.

Maybe we should turn our focus towards creating a “General Best Practices” documentation on developing and deploying applications that use community provided DLL wrappers? While we’re at it, some “Best Practices” guide on packaging DLL wrappers for cross platform development? Such training/guides could be beneficial beyond the UI discussions we’ve had recently.

I’ve learned a lot about this problem domain and some of that knowledge will serve me well while working on my EuDrop Project. Additionally, I feel like my experience with this committee will benefit me if I’m involved in another one in the future.

-xecronix

5. Re: UI Committee Round 2

• Posted by SDPringle Dec 14, 2015
• 3774 views

There is a cost in including even more into a project. More bugs and more docs. The concern is that the bugs will come and the docs will not. The bugs wont get fixed and will only compound. We already have this kind of thing it is called AIO. To me it is fine to have multiple and competing GUIs for a computing language.

The net version AIO downloads the things dynamically. I was going to make it use eubins but the binaries produced were bad and now eubins has been abandoned. ( A lot of my time was wasted tracking a bug that only existed in eubins (added)) I thought Jim Brown was maintaining it but I guess I misunderstood his words. The eubins are hosted on this server, the building process I suppose happens somewhere else.

The installer, comes with a 4.0 version of Euphoria and then downloads a 64-bit version of Euphoria. It also downloads other packages. EuGTK has more Euphoria points behind it than IUP which is a newer contender and EuGTK comes with scores of demos.

I just do not have much time to add another toolkit these days to the installer. I have a new job now. I'll be building myself a proper dev box in a month or two. :)

Shawn

7. Re: UI Committee Round 2

• Posted by xecronix Dec 14, 2015
• 3862 views

I'm trying something different.

• Developer: Someone directly responsible for hacking or packing OE.
• User: Someone who uses OE with the intention of writing a program.
• Customer: (aka OE User's Customer) The person that consumes a program written by a OE User.

DLL Option:

Concern: Where are the DLLs on the OE Users box?
Potential Solution: DLLs are located in a directory relative to $EUBIN
Discussion Point: Developers would be responsible for packaging DLLs for each supported platform.

Concern: How did the DLLs on OE User's box get there?
Potential Solution: Included with OE
Discussion Point: Developers would be responsible for packaging DLLs for each supported platform.

Concern: Where are the DLLs on the OE User Customer's box?
Potential Solution: In a location as determined by the OS and/or OS Distribution
Discussion Point: This makes it difficult to keep the DLL and wrapper in sync. The customer would be free to upgrade DLLs without even realizing the affect it could have on an installed program. This is especially true if the program is compiled. Who's area of concern is this? Developer, User, or Customer?

Potential Solution: In a location relative to the program executable. (This is currently our best solution IMO)
Discussion Point: This can be accomplished using eu.cfg as is demonstrated the Euphoria Editor written using IUP. However the customer is in no way obligated to run the program from the executable's directory. (thus affecting the path) The solution can then be enhanced by the use of a launcher program or script but this could feel a bit odd to a customer. (again as is demonstrated the Euphoria Editor written using IUP) This solution puts sits squarely in the User's domain. Does it belong there? Is there any help that could be offered at the developer level to help standardize/streamline this process?

Concern: How did the DLLs get on the OE User Customer's box?
Potential Solution: The OE User includes the DLL with his program.
Discussion Point: This puts the burden of deploying the needed DLL and potentially supporting DLLs with the user. Some might argue that this is fine but is it? One advantage of using OE is cross platform programming. I might not even have a Mac, for example, but I would expect my OE program to run on one. How would I know what needs to be included with my program for a Mac if I don't have a Mac? How would I get the DLLs? Would developers need to package the DLLs for every platform with each OE installer just so that I could build cross platform packages? (Potentially uncompiled programs because I may not be able to cross compile). Much of this might be addressable with documentation/tutorials on the subject. I'm not sure. (Hence the plea for discussions) BTW, in the above we could easily replace Mac with Windows or ARM. It is not as uncommon as some people may think that a person does not have access to a Windows box. I don't have access to one at work or at home for example. And some of you reading this may not have access to an ARM box.

Potential Solution: Dynamic installation of DLLs
Discussion Point: This requires the customer to have internet connection at least for the first run of the program. There are also other concerns related to managing a distributed deploy system.

Further Discussions:
The domain of the DLL problems becomes much simpler when limited to interpreted programs only. If limited this way, then DLLs could be located in a place relative to $EUBIN and the open_dll function modified to look there for DLLs.

BTW, these question have not been discussed yet either:
Is it a goal of this project to be able to create a "write once run anywhere" solution like Java and Mono for example?
Is it a goal of this project to be able to create a "write once compile anywhere" solution like Free Pascal?

Static Linking Option:

Some discussion on this has happened. I can easily see the benefit for interpreted programs but it's unclear to me how this would be beneficial for compiled programs. Does anyone have any input on this? Especially as it relates to cross compiled programs?

Runtime:

Could creating a "Runtime" DLL (or static lib) be a decent solution for cross compiled programs? Does anyone have any input on this potential solution? Essentially a single DLL (or static lib) that provides UI features. In this case it would mean building a single monolithic IUP DLL (or static lib). (Warning: this could easily evolve to include other "stuff" cross-platform... like ssl for example. Of course, that is beyond the scope of these discussions.)

9. Re: UI Committee Round 2

• Posted by xecronix Dec 15, 2015
• 3677 views

This is a required step in the process but why would you expect this to be the next step in the process? There is no question as to whether or not we can create error messages. Anyone with a corkscrew, a bottle of wine, and a several of hours of time can build VMs and create these informative messages. I volunteer to do this personally (for Linux 32/64 and Raspberry Pi) if the task becomes part of a milestone for the UI project. This is not the unknown here.

This however, is a little closer to the next step in the process, but still not the next step. The obvious unknown with regards to IUP is whether or not anyone in the community has the Time, Talent, and Tech to make this happen on a Mac. All three T's are required. What we know is that there are some google searches that result in the claim that IUP can be made to work on Mac. That makes IUP a theoretical option on the Mac. Whether or not we can do it has yet to be seen. Without a "zip" file like the others Greg has provided, it's still just theory. We can't provide instructions for a solution that doesn't yet exist.

Possibly true, but again there is no way of knowing that. Why? Because there is no focal point for the project. Aka no stated goals. The probing questions I've been asking are intended to bring some sort of clarity to what success looks like and to illuminate some of the roads to get there. The above statement sounds more like 2 potential requirements for the project rather than an absolute fact.

Potential Requrements:

• Solution should not involve pre-installing Eu+bundle
• Solution should be identical to the way OE handles the problem

Thank you. I've captured these 2 potential requirements in a document entitled "Community Objectives".

• We can't build detailed instructions until we have a solution that works on all supported platforms.
• We can't implement a solution until we've identified the problem and set goals
• We can't design a solution until we've established requirements
• We can't have requirements until we've answered some of these probing questions

"Even a blind squirrel gets a nut every once in a while." With that quote in mind I acknowledge the fact that it is possible to eventually meander and stumble our way to a successful project. But I think the squirrel would reach that nut a little faster if he could foresee obstacles and focus on his goal. We would too.

-xecronix