Since Cygwin bash is "transparent" to Java when you run ej, File.separator (and all other System.getProperty() dependent things) is set to '' on Windows and you cannot load kilim/S_* classes in the EModuleClassLoader. I have fixed it through a fallback to '/' when the first load attempt didn't work. Now it's possible to run ej from a Cygwin shell.
Please feel free to review, I will go look for "real important" tasks :)
PS: commiting the cfg.properties file was an oops, sorry
Regards - Pavlo
enabled loading of kilim/S_ classes when running from within a Cygwin…
started implementation of the binary module. Prepared skeletons of al…
…l methods throwing NotImplemented now.
added the skeleton for the binary module coveragy test (erlang)
redesigned AllTests to enable execution of single tests
implemented generation/execution of single test classes for compiled …
separated test compilation from test execution
You'll have to live with EUnsigned I'm afraid because it's really tricky to tinker with the number classes and adding extra classes/cases will reduce performance for other cases.
You mean leave the EInteger and check for its positive sign inplace where necessary? Ok. BigInt's signum should do the job - need to play with it in this context.
I think I will have to differentiate between EBig and ESmall - didn't get to this point yet.
Merge remote branch 'upstream/master'
TODOs now more concrete
You're welcome to add virtual methods to number/small/bigint as needed of cause
EFile: FD numbers can't be obtained on Windows in the same way the ca…
…n on Mac/Linux. Falling back to usable dummy number.
added ~/.erjang/*.jar to the test classpath
fix: implemented precompilation/preloading of erlang modules for sing…
RabbitMQ depends on fd numbers being unique, so we should consider a map from absolute paths to unique integers to support that.
maybe it would be more "clean" to use the "handle" field on Windows acc. to: http://elliotth.blogspot.com/2005/08/javaiofiledescriptor-on-win32.html . We would need to get an fd out of a Windows file handle (http://msdn.microsoft.com/en-us/library/bdts1c9x%28v=vs.71%29.aspx).
But if you mean to generelly avoid the "dirty" breaking into the FileDescriptor, stealing its provate fields (fd or handle, no matter), I guess this would be the best solution :). A unique integer would map to a FileDescriptor object, no matter on which platform, right?