Euphoria
Ticket #521:
Eu 4 RC2 can't compile most of my programs
-
Reported by
FredRansom
Dec 09, 2010
This has been traced to the fact that parts of the public interface of machine.e have been removed. I've no idea how much of the rest of the include library has been similarly destroyed. Once a module has been deployed, it is all right to add functionality, but removing it can be disastrous for anybody anywhere who has used that module.
Details
1. Comment by jeremy
Dec 09, 2010
Euphoria 4 is not directly compatible with Euphoria 3. When there are additions, there can sometimes be conflict. We strive for complete compatibility in a .x release, but a major release may break things. This is similar for any product.
Can you give us an example of what broke? Maybe its something simple, mis-configured or an easy work around. Most 3.x programs we've tried work w/o issue.
2. Comment by DerekParnell
Dec 09, 2010
Which parts of the public interface of machine.e are you having trouble with?
I suspect that this module is the most difficult one to be 100% compatible with existing code as Eu4 no longer supports MS-DOS, and a lot of the machine.e code dealt with MS-DOS functionality.
3. Comment by ne1uno
Dec 09, 2010
if something was moved, it may have been moved to std/memory.e and std/safe.e and still available through std/machine.e
choosing memory or safe routines automatically by with define SAFE or -D SAFE option
4. Comment by FredRansom
Dec 11, 2010
Eu 3 has nothing to do with it. I've used Eu 4 since the first stable version came out. All of my programs compile with Eu 4 RC 1. Almost none compile with RC 2 due to the removal of parts of the API, for example, the removal of global function dos_interrupt that is used by win32lib. Unfortunately this has left no suitable migration path from RC 1 to RC 2. This makes RC 1 the end of the line. As I've indicated before it's all right to add to the API of a deployed library, but not all right to subtract from it. This is serious because these removals hake RC 2 useless.
5. Comment by jeremy
Dec 11, 2010
DOS support was removed long before RC1. I think before alphas even. I was just looking through the release notes about RC2 and didn't see in the remove section where dos_interrupt was removed in RC2.
Ok, I just found it, dos_interrupt was removed in revision 2443. That was after alpha 3 and before beta 1. So if you have been using dos_interrupt in RC1 then you have been including old include files somehow.
There are versions of win32 that are designed to be run on 4.0. I'll let Derek comment on that.
6. Comment by jeremy
Dec 11, 2010
About removing. This is true once things hit release candidate status. Even after RC status it is sometimes necessary to remove somthing and is beneficial to do so. For example, replace_all. This was an inferior method that slipped through the cracks. match_replace is a much better method. It was better to remove replace_all and make a RC note that instances of replace_all need to be updated to match_replace than to leave an inferior method in the standard library and have half of the community using one and the half the other.
That was not the case with the dos_interrupt though, it was gone a long time ago, pre-beta.
7. Comment by jimcbrown
Dec 11, 2010
Are you sure? r2443 appears to refer to std/machine.e (the 4.0 stdlib), looking at machine.e (the 3.1.1 compatibility lib) I see that r3651 did it - but that commit was done prior to Halloween 2010.
I'm not sure that removing dos_interrupt() from the 3.1.1 compatibility stdlib was the right decision. For 3.1.1 mouse.e, stubs were left in for include file level compatibility even though the entire library file was removed from the 4.0 stdlib.
If this is considered the right decision, then I guess the make40.ex preprocessor will not only have to deal with stubbing out removed builtin routines but also removed 3.1.1 stdlib routines. (The easiest way to do this would be to add include/make40/make40.e as a compatibility lib, of course.)
8. Comment by jeremy
Dec 11, 2010
Yes, that's what I was talking about, from std/machie.e. I thought the program in question was using the 4.0 std/ libs? Or was it still using all the old 3.x includes?
In regards to 3651, not sure. If the stub exists then the program would parse but fail to execute some time later due to dos_interrupt not doing what they thought it should. Its possible that the result of the interrupt call may not be noticed or realized until very much later in the application execution.
Seems to me that it should fail early.
3651 was still way before RC1. RC1 was tagged as revision 3949. The program in question ran fine in RC1.
9. Comment by jimcbrown
Dec 11, 2010
I agree, the real issue seems to be FredRansom's reliance on Win32Lib.
Discussions with CKLester suggested that the issue was that win32lib included machine.e and referenced dos_interrupt() but did not actually ever call it. (Likewise, references to pixel() and get_pixel() existed but they also were never called.) So, fail early and every win32lib app breaks. Fail late, and no win32lib app breaks.
Since CKLester and Derek both have versions of Win32lib that work fine on 3.1.1 or 4.0 without modification, it seems the real solution here is just to upgrade Win32lib.
I'm not sure why the issue would show up in RC2 but not in RC1. The only thing I can think of is perhaps that the order of include file and/or eu.cfg parsing was changed. In that case, it'd be a bug in RC1 (wrongly including 3.1.1 includes from a 3.1.1 install or something) masking a more serious win32lib bug. bug + bug = working program?? What are the odds.
10. Comment by jimcbrown
Dec 11, 2010
It occurs to me we have an inconsistency in the 3.1.1 compatibility stdlib. mouse.e is stubbed out, for a fail-late philosophy, while machine.e has routines entirely deleted for a fail-eary philosophy. This should at least be made consistent.
11. Comment by jeremy
Dec 11, 2010
If it were me, I'd want it to fail to even parse. Another option (I feel is not as good, but we should discuss w/dev team) is to stub the methods out but put in a crash() so when they are called, it says crash("abc is not supported on 4.0") so at least their app fails the momement they call the method. The third option (not sure what mouse.e does) is to have the stubs do nothing, thus silently ignoring potential fatal reliance.
12. Comment by mattlewis
Dec 11, 2010
dos_interrupt() was removed from the legacy std lib in svn:3651, on 10/28/2010, which was prior to RC1.
Fred, from the directory where you translate your program, could you run this program with the same -i options:
include std/console.e
display( option_switches() )
display( include_paths(0) )
Look at those directories, and make sure the 4.0 include directory is before any 3.1 include directory.
13. Comment by jimcbrown
Dec 11, 2010
Yeah, I'm mostly biased to a fail-late setup because that makes make40.ex maintaince easier. Otherwise, I'd say fail-early.
I'm not sure what the point of the 3.1.1 compatibility stdlib is if one needs to use a preprocessor to ensure their 3.1.1 code runs under 4.0, though.
Regardless, I can fix make40.ex to work no matter what decision is taken.
14. Comment by mattlewis
Dec 11, 2010
As for the preprocessor, even though the user might not use any DOS routines, there are new reserved words.
15. Comment by DerekParnell
Dec 11, 2010
dos_interrupt has never been used or even referenced by any code in the official Win32lib.
Win32lib does include machine.e which means that programs that include win32lib.e could also access global stuff in machine.e, but that is not the fault of Win32lib.
16. Comment by jimcbrown
Dec 11, 2010
I'm just reporting what I heard at http://openeuphoria.org/forum/m/113493.wc
17. Comment by DerekParnell
Dec 11, 2010
Well all I can think is that someone has released an edition of Win32lib with those DOS routines in it. I never have and it seems ludicrous for anyone to include DOS specific routines in a Windows library.
The current Win32lib (0,70,20, "13-Nov-2010"), which is available at Sourceforge, works with Eu 4, both interpreted and translated.
18. Comment by jeremy
Dec 11, 2010
Is this ticket valid any longer now that we seem to be to the bottom of things, i.e. an updated Win32lib?
Fred, were there other programs that wouldn't execute or are all of your apps that will not execute Win32Lib apps?
19. Comment by FredRansom
Dec 12, 2010
Yes, updating to the most recent version of win32lib took care of most of the problems. I feel Euphoria is an excellent language, better IMHO than Java, although I've done most of my programming in C. But, if you want it to become a major language, a position it deserves, then you need to provide easy upgrade migration paths. This can be done by supporting the earlier API with additions, and/or providing an upgrade engine, even if the engine does nothing more than looks at the libraries and suggests updates.
This ticket can probably be closed now.
20. Comment by FredRansom
Dec 12, 2010
Apparently two plus sighs has some sort of format meaning here. I meant C plus plus.
21. Comment by jeremy
Dec 12, 2010
Fred, very few languages remain functional throughout their life without breaking changes. Some do, most do not. For example, Python 3. It is a major language yet the 3.0 release breaks all sorts of things.
This is not the desired and is the exception but in some cases it just has to happen. If not as time progresses the language will be a royal mess. For example, imagine if Euphoria was created when the Comodore 64 was popular? Would you expect to still see routines in the standard library that rewinds the tape drive or pokes a 4 bit color to the screen? Likewise, DOS.
Removing the DOS functions was necessary and since 4.0 no longer supports DOS (as it wouldn't support Comodore 64 today if it were that old), those methods have been removed for the benefit of the language today and forward.
GitHub