OpenEuphoria

1. An illuminating experiment using platform().

• Posted by Shawn Pringle B.Sc. Jul 12, 2008
• 875 views

The topic of platform() getting depricated has come up again. If there is one thing that should be depricated it is the depricate function. It keeps getting called at random and is only useful for breaking software.

Seriously, there is little cost involved using platform() as compared to say ifdef with the correct parameters. I wrote a seven line program called example:

include os.e 
 
if platform() = WIN32 then 
    printf(1, "Hello Windows", {} ) 
end if 
 
if platform() = DOS32 then 
    printf(1, "Hello DOS32", {} ) 
end if 
 
if platform() = LINUX then 
    printf(1, "Hello LINUX", {} ) 
end if 

Okay, so we will expect to see a comparison in the C code jumping over some display code after we compile. A branch seems like a little thing but some say that it is too ineficient to let us keep it. Just for curiosity, lets see how the branch is implemented. Is it a goto? I translated it using the options -plat DOS -wat and got this:

// ifdef WIN32 then

// if platform() = WIN32 then

// if platform() = DOS32 then

// printf(1, "Hello DOS32", {} )

EPrintf(1, _1153, _10);

L1:

// if platform() = LINUX then

Cleanup(0);

So, as you can see, the EPrintf() is there to replace the EUPHORIA printf but only the DOS32 version is there. The branches that include platform() = to other platforms are not even included.

There is absolutely no branching cost of using platform() rather than ifdef when translating to C.

Shawn Pringle B.Sc.

3. Re: An illuminating experiment using platform().

• Posted by Jim C. Brown Jul 12, 2008
• 876 views

Agreed. However, platform() has two flags which make it inferior to the platform detection support available via ifdef.

First, ifdef supports using UNIX and making finer distinguishment via LINUX/FREEBSD/OSX (and perhaps more to come). platform() is inconsistent, with the builtint version only separating OSX from UNIX.

Second, platform() is inconsistent. The machine_func(53) call will return a 3 on OSX but the builtint platform() returns a 4. At one point in time, both versions of platform returned a 4 for FreeBSD.

It is possible to clean up platform() and give it the ability to tell you if you are just on a UNIX, or tell you more fine grained information (linux vs osx vs bsd). This will never happen since we have the ifdef system now.

5. Re: An illuminating experiment using platform().

• Posted by Shawn Pringle B.Sc. Jul 12, 2008
• 887 views
• Last edited Jul 13, 2008

You give some good examples of how flexible ifdef is: Especially for DEBUG and defining functions. It is not a question of speed but flexibility of what you can do at parse time.

You haven't explained why anyone should care if machine_func(53,{}) and platform() return the same result or not. Who has ever heard of machine_func(53,{}). I don't think it is necessary and I do think it is a bad idea to remove something that already exists and is relied on just because there is a more capable method now.

It is rather analogous to banning radio because people can go buy tvs.

Shawn

7. Re: An illuminating experiment using platform().

• Posted by CChris Jul 13, 2008
• 845 views

For cross compilation purposes.

I'm on a Windows platflrom, and wish to output code that might run under Unix. An ifdef WIN32 statement will indeed cut off any Unix specific code, and the code won't ever show up in generated IL.

The easiest way out is to distribute ckear source code, so that it is ILed on the same machine where it will run. Perhaps some licensing agreement about using some third party code will prevent that. Or perhaps your app is payware, so there must be some copy protection.

platform() is obviously less versatile than ifdef. But it is the only currently known way to defer cutting code off whie having parsed it already, and still distribute only one file. Cross-translating is fine, but then you must distribute as ùmany executables as psupported platforms.

If we had a deferred_ifdef, then platform() could be deprecated.

CChris

9. Re: An illuminating experiment using platform().

• Posted by Jeremy Cowgar Jul 13, 2008
• 846 views

I do not fully understand what you are saying here. Are you saying that the cross-translation sets up the wrong PLATFORM ? If so, that's a bug that needs to be fixed.

Why would you want that? Also, if you are not cross-translating, then what are you doing? ifdef works just fine in interpreted applications as well. There is no need what-so-ever to translate to make ifdef work.

What exactly would deferred_ifdef do that cannot be done with ifdef?

Jeremy

11. Re: An illuminating experiment using platform().

• Posted by Jeremy Cowgar Jul 13, 2008
• 835 views

We have cross-translator abilities. The cross-translator should be defining UNIX, LINUX when on a Windows machine during the translation process. This shouldn't be a problem at all. I am not saying their is not a bug in it. I have not tried this process. However, I am saying that if it does not work then it is a bug that is easily fixed.

Jeremy

13. Re: An illuminating experiment using platform().

• Posted by Jim C. Brown Jul 13, 2008
• 836 views

ecw.exe -GCC -PLAT LINUX thesource.exu

These last two steps assume you have MSYS or some similar environment installed, as well as a gcc cross compiler:

sed.exe -i s/gcc/i686-unknown-linux-gnu-gcc.exe/g emake

sh.exe emake

15. Re: An illuminating experiment using platform().

• Posted by Jeremy Cowgar Jul 13, 2008
• 955 views

Yes, which is what most people do when distributing applications. Usually they have an installer and offer pre-compiled binaries.

That would take away almost any benefit of ifdef? Then, how would you decide if you want to use ifdef or deferred_ifdef ? And this is only for shrouded code? i.e. interpreted, bound or translated code will all work fine with ifdef.

A shrouded file only runs if the user has downloaded Euphoria for their platform and installed it. Do most applications expect the user to do this? Sure, it's fine for developers, but users?

I would suggest that having defered_ifdef would be pretty confusing and counter productive.

Jeremy

17. Re: An illuminating experiment using platform().

• Posted by Jim C. Brown Jul 13, 2008
• 859 views

If I understand correctly then, its basically an ifdef that is outputed into the IL and then interpretered by the backend at run time....

It is possible to take IL and reverse engineer it into almost the original euphoria source code quite easily. I think there is a tool provided to do this. We no longer seem to have shrouding as in the old days where the source was completely hidden (or scrambling?). I therefore do not think having a deferred_ifdef solely for the benefit of shrouded code makes sense. If it benefits translated or interpreted code as well, then it could still be worthwhile.

For interpreted code, we don't need the ifdef to be deferred, since from the user's point of view parse time is the same as run time. So no benefit here.

For translated code, the deferred_ifdef would need to be parsed and evaluated before the conversion to C code anyways. (Even if it wasn't, the result C code is only expected to work on a single platform, so there is no benefit to preventing optimization.) If we care, a similar argument applies to the case of bound executables.

So it looks like a deferred_ifdef only helps the shrouded code case be more portable. The use of raw IL files seems to be rare.

If we had a way to cross-compile IL files, and perhaps do cross-binding, I'd say there was no need for an deferred_ifdef even for shrouded code.

19. Re: An illuminating experiment using platform().

• Posted by Jeremy Cowgar Jul 13, 2008
• 818 views

I'm not really convinced of this. Who would use IL code? Not end users, only developers. Now, would developers really use IL code? I would want source. I wouldn't use IL code and I suspect that will be the opinion of most, but don't want to speak solely for them, so speak up if you disagree.

Now, let's say that you do have a product that you distribute to your end users and you want to give them IL code for some reason. You have presumably (hopefully) already had to give them a platform dependent copy of euphoria. Thus, you are already maintaining platform dependent installs. Further, you have hopefully provided the end user with an installer? Further making your install platform dependent.

Now, let's say you do not give them euphoria and you do not give them an installer and just a bunch of IL files in a zip file and leave the rest up to them. Wow... what percentage of applications is this actually? 1%? 0.1%?

I do not see how distributed IL code is beneficial. I see great benefit in distributing bound and translated code. I suspect that we will begin to see much more translated code out there because it's so easy and because it's totally free now. Both in Euphoria and with open source compilers. OpenWatcom is literally cake to install. gcc comes with Linux/FreeBSD platforms so there is not even the need to do that there.

Jeremy

21. Re: An illuminating experiment using platform().

• Posted by Jim C. Brown Jul 13, 2008
• 825 views

Cross-output of IL is a prerequite of cross-binding (binding an .exe from a GNU/Linux box for example). With cross compilers its possible to use a single box of one platform to go from eu source to executable for a completely different platform. I do not believe that we have this flexibility when creating bound executables.

23. Re: An illuminating experiment using platform().

• Posted by Unkmar Jul 13, 2008
• 829 views

Effectively, He wants platform() to work in shrouded code.

    Unkmar 

25. Re: An illuminating experiment using platform().

• Posted by Unkmar Jul 13, 2008
• 836 views

Some developers will release IL code. They will think of it as shrouding. Mind you, it is rather pointless.

Ask Liquid Nitrogen what I did to his bound copy of Lemon Heads. This was before shrouding was possible. Back then, the euphoria code ended up with all functions and variables renamed to meaningless names. Comments were stripped and all includes became part of the code. All the pretty indentions and whitespace was also removed. This ugly representation of the original code was then appended to the end of the interpreter.

I discovered where the values of health and so forth where and created an invincible character that was no longer limited to 3 shots on screen at a time along with automated firing. And I did all this before the debinding or whatever it was called was created and released.

My point. If you use IL to hide your code, and someone really wants that code. They will get it pretty easily. Shrouding made it not worth my while to get the code. However, I'm not a full force cracker with leet abilities.

    Unkmar