Re: What is the status of Euphoria V4.10?
- Posted by SDPringle Feb 02, 2019
- 2949 views
First, fix all errors indicated by the failing unit tests!
AGREED! A lot of the tests seem broken, so they're false failures.
I argue that many of them are false failures but not all. I have been working on t_callc.e errors and they are very real. I made a branch of that off of my forked copy. If you want to work on it you can put a similar branch in original openeuphoria/euphoria repo and I can start pulling from there. The HTTP is failing because the example sites are using HTTPS. Others fail because differing numerical limits between distinct machines.
In particular with respect to std/net/http.e:
- Adapt the std/net/http.e routines to use the CURL library so that the other http tests actually pass. See https://github.com/shawnpringle/euphoria/tree/http-curl for an implementation of this.
- Fix the [[OpenEuphoria.org]] web server to provide the resources that the above tests rely on.
- The curl branch needs documentation that EUPHORIA requires CURL, curl needs to be a requirement in the install and deb file creation.
You're using WinInet on Windows, correct? We should assume that library is always available since it was added in Windows 2000.
When using CURL on Linux (or OS X) I recommend we fall back to the existing routines if we can't find CURL, and issue a warning like "CURL not found. HTTPS will not be available."
Also, since the existing HTTP routines support tasking, let's make sure to include task_yield() in the WinInet/CURL call backs, assuming it's safe to do so.
Unit tests that deal with literal numbers that are too small to be put into a Euphoria atom, and should report an error rather than being read as zero or worse a huge number, are failing on my machine and probably most machines because these limits are different depending on the processor capabilities. The path of least resistance is to create an alternative set of control files for machines that have this capability and possibly adapt the testing program to use those.
I'm not sure I follow. Can you provide an example?
-Greg
On the topic of http.e, I am treating both platforms as if they are one here. Let the Windows users get CURL as far as I am concerned. Although, someone could do all of the porting work for a Windows special case as well, I guess. If we cannot even get all the unit-tests passing on Linux, we should just deprecate http_get and http_post and tell the users they should implement their own in the docs.
On the subject of these other tests that are false failures: Run eutest on the file t_c_underflow_sci.e. If you do so on a machine that uses 64-bit atoms, it will create an accepted error message according to the control file, but if your machine uses 80-bit atoms, it will create a different error message.
I wanted to use the biggest positive number that [Edit:] was too small to be represented as a 64-bit atom for this test. It is important that this value and smaller values will throw an error and this border-case is what needs to be tested. The biggest positive number that is too small to be represented as an 80-bit double is of course much smaller, so the literal gets assigned. I worked out what the biggest positive number which was too small for an 80-bit double would be back then but I didn't have a processor that I could test with at the time.
I made a test report and dropped it here http://openeuphoria.steemfiles.com/c8c0000000358383c30cdf8ea64de9b4a2536fec.html#summary.
For that issue we need to create control files for 80-bit doubles
