Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorganization #334

Merged
merged 4 commits into from Aug 8, 2018

Conversation

Projects
None yet
2 participants
@Thrameos
Copy link
Contributor

commented Jul 1, 2018

Here is the "complete" log of the changes I think I made. Sorry for the extend of this pull request. I had to go a bit deeper than I hoped to get rid of that dead layer. Unfortunately, with a multi month refactor like this, I tend to fix stuff I run into just because I won't be able to track of the whole list of TODOs. But after one false start I managed to land it with a working test bench once more. Now lets see what breaks on other architectures.

Ignoring the comments and the extra project files it should actually be a much smaller code base.

Module _jpype changes:

  • Moved python module objects to namespace PyJP so that they are consistent with a python module namespace. Renamed module classes presented to _jpype extension to PyJP* to match the internal classes. Though not exactly a standard convention, the types were internal anyway and having the names match the C structure makes it more clear what resource is being accessed. It also eliminates the confusion between jpype and _jpype resources.
  • Removed all usage of Capsule from the extension module. This was bridging between python versions and had to be replicated on old platforms. As the capsules were functioning as crippled objects, they could not have methods of their own. Thus functionality that properly belonged to a specific class would get pushed to the base class. This affected former capsules of JPObject, JPProxy, and JPArray. These are now formal classes in the module as PyJPValue, PyJPProxy, and PyJPArray.
  • Moved the initialization of each class to the __init__ function. Thus rather than creating the resource at the top level _jpype module (such as _jpype.findClass('cls')), the resource is created by allocating a new object (such as _jpype.PyJPClass('cls')).
  • The presentation of JPArrayClass has been merged as a generic JPClass. The only requirement for creation of an array instance is that the supplied PyJPClass satisfy isArray().
  • Removed direct dependencies that objects holding resource be exactly the type in jpype module. This reduces the restrictions in the underlying python layer and allows for multiple classes such as JavaArray, JWrapper, and JavaClass to all be recognized as holding resources. This simplifies some paths in the jpype module where we needed to simply access a single method during bootstrapping and we were forced to construct complete classes necessitating the order of resource loading.
  • Remove JPObject concept and replaced it with JPValue. JPValue holds the type of the object and a jvalue union. Both JavaClass and JWrapper now point to these classes as __javavalue__. Anything with a __javavalue__ with type _jpype.PyJPValue is now recognized as being a java object.
  • Changed the recognization of a JavaClass to any object holding __javaclass__ with type _jpype.PyJPClass. This allows array classes, object classes, and wrappers classes to be used together.
  • Added hooks to direct convert PyJPClass to a PyJPValue with a type of java.lang.class and an object to the class. This replaces the need for calling forName to get to the existing class.
  • Changed PyJPField and PyJPMethod to descriptors so that we do not need to mess with __getattribute__ and __setattr__ in many places.
  • Eliminated the unnecessary class bound method.

C++ Reorg:

  • Reorganized the type tree in the C++ layer to better match the Java structures.
  • Flattened out the redundant layers so that JPType is now JPClass corresponding to an instance of a jclass.
  • JPClass is not the base class. Arrays are now objects and have base classes and methods.
  • Split JPClass into a separate type for each specialized object class for boxed, java.lang.Object, and java.lang.Class which all required specialized conversion rules.
  • Boxed, string, base java.lang.Object and base java.lang.Class are now specialized with their required conversion rules.

Path reduction:

  • Removed HostRef and all of its usage. It was a halfway memory management method. To be passed around it was being held as a dynamically allocated pointer type with no static presence for cleanup. This defeats the point of having a smart point wrapper if the smart pointer is being used as a pointer itself. Thus it was only as safe as the user applied conventions rather than safe by design.
  • Replaced all the HostRef methods and JPy* Python object wrappers with a new smart pointer concept (namespace JPPy). This removes the redundant host and JPy* wrapper layers.
  • Removed multiple optimization paths such as bypassing between jchar and unicode if the size matched. These paths were for speed reasons, but they could only be tested on particular machines. Thus it was difficult to tell if something was broken. It is better to have one tested code path that is slight slower, then a faster path that is busted.
  • Removed dead class JPCharString.
  • (bug) Replaced all string handling with conversion through UTF8. Java and python use different UTF8 encodings and thus those paths that were trying to short cut directly through from one system to another were badly flawed. By forcing a conversion to and from each time a java string or python string are passed eliminates conversion problems. This should resolve user issues having to do with truncating extended unicode characters.
  • Combined all code paths in canConvertToJava and convertToJava to use the JPValue
  • Combined code paths from check and get for JPValue, JPClass and JPProxy get patterns when fetching from python. Almost always we want to use the object immediately and just check if we can.
  • Removed the entirely redundant Primitive type setRange and getRange. That code was entirely dead because it could not be reached. Renamed the direct methods as they now have the same function.
  • Removed JPTypeName. This concept will be phased out to support lambdas. TypeManager now used getCanonicalName(). Transferred responsibility for conversion to native names to python module interface.
  • Introduced named classes for all specialized instances of classes to be held in TypeManager namespace. Thus converted most of the "is this type" to comparison of JPClass* pointers in place of string level comparisons.
  • Removed near duplicate methods. JProxy was requesting slightly altered copies of many conversions to support its usage. These operations could be supported by just splitting to two existing methods. Thus we could eliminate a lot of stray methods that served this specialized purpose.
  • JPArray is now a method holder rather than the primary object like JPBoundMethod. All array objects in python now hold both a __javaarray__ and a __javavalue__. This eliminates need for special paths for arrays.
  • _getClassFor is now overloaded to work with array classes. Thus asking for a JClass('[java.lang.Object;') will now correctly return a JavaArrayClass.
  • Constructing a string now shortcuts to avoid methodoverload on new instance if given a Python string.
  • Reworked the GIL handling. The previous model was doing all the release locks on the JPJni calls automatically for almost all jni transactions. This would be fine, except that many utility functions were using those same calls regardless of whether is was a good time to release the lock. This ultra fine grain locking was effectively allowing any call to JPJni methods to become a break point, including those calls in critical sections such as ensureTypeCache and TypeManager::findClass. Any time it loaded a class or looked up a name it could be interrupted and thus end up in a corrupt state. Thus I moved all of the GIL calls to those places where we call user code on the type returns and the object constructors. Thus cuts the number of GIL transactions greatly and eliminates the need to deal with trampling global resources. The refactor exposed this a bit more because the removal of TypeName meant that we did a lot more transactions to get the class name. But that does not mean the flaw was not there before. If our tests cases had been any more aggressive about creating class instances during execution it would have overrun the TypeManager table and all would have failed.
  • Removed the previous default option to automatically convert java.lang.String to either a python string or a unicode when returning from java. This does mean some string operations now require calling the java string method rather than the python one. Having strings not convert but rather remain on the jvm until needed cuts the conversion costs when working with java heavy code. I added a caching mech so that if we need to convert the string multiple times, we don't pay additional over the previous option.
  • A special toString method was added to PyJPValue to convert java strings to python strings. This can convert java string resources to python ones on request.

Proxy changes:

  • Proxy as implemented previously held only a pointer to the proxy object and from this proxy object it lookup up the callable using either a dictionary or an instance. The majority of the resources were held by the jpype.Proxy. This was replaced with a more general function in which the PyJPProxy proxy holds two resources. One is an object instance and the other is a lookup function that turns the name to a function definition. This supports the same use cases but eliminates the need for finding resources by convention. There is no need for the proxy in Python to have any specific layout other than holding a PyJPProxy as __javaproxy__. Thus allowing alternive structures such as Proxy by inheritance to work.
  • Memory handling was changes slightly as a result so that the reference queue is now responsible for cleaning up the proxy. Proxy handle instances are generated whenever the proxy is passed to java. Thus we form no counting loops as the proxy has no reference to the handles and the handles hold a reference to the proxy.

Exception changes:

  • Changed all exception paths to use JPypeException exclusively. The prior system did way to much in the Exception constructors and would themselves crash if anything unusual happened making changing of the system nearly prohibitive to debug. Everything bubbles down to toJava and toPython where we perform all the logging and pass the exception off. This also centralizes all the handling to one place.
  • This pulls all the logic from JPProxy so that we can now reuse that when returning to any java jni native implemented function.
  • Same thing for Python, but that was already centralized on rethrow.
  • Reworked exception macros to include more info and introduced JPStackInfo. It may be possible to connect all the stack info into the Python traceback (via a proxy class) to present a more unified error reporting. But this work is currently incomplete without a python layer support class.
  • Integrated JPStackInfo into tracer to give more complete logs when debugging.

Code quality:

  • Applied a source formatter in netbeans. It is not perfect as it tends to add some extra spaces, but it does make faster work of the refactor. Custom spacing rules were applied to netbeans to try to minimize the total changes in the source.
  • Improved error handling where possible.
  • Rework JPTracer so that reporting from places that do not have a formal frame or could not properly throw (such as destructors) and still appear in the trace log. All TRACE macros were moved to JP_ so that were less likely to hit conflicts. Removed guards that complete disabled Tracer from compiling when TRACE was not enabled so that unconditional logging for serious failure such as suppressed exceptions in destructors can report.
  • Defensively added TRACE statements whenever entering the module for a nontrivial action so that errors could be located more quickly.
  • Removed MTRACE layer as Java local frame handles all cleaning tasks for that now.
  • Replaced TRACE1, TRACE2, TRACE3 with a variodic argument macro JP_TRACE because I am too lazy to remember to count.
  • Renamed functions to best match the documented corresponding function in the language it was taken from. Thus making it easier to find the needed documentation. (Ie JPyString::isString() becomes JPPyString::check() if the corresponding language concept is PyString_Check()). This does mean that naming is mixed for the Java/Python layers but it is better to be able to get the documentation than be a naming idealist.
  • Used javadoc comments on header of base clases. These strings are picked up by netbeans for document critical usage.
  • Moved method implementations and destructors out of headers except in the case of a truly trivial accessor. This has a small performance loss because of removal of inline option. This reduces the number of redundant implementation copies at link time and ensures the virtual destructor is fixed in a specific object. We can push those back to the header if there is a compelling need.

Documentation changes:

  • Documentation of major class methods have been added as well as marker whereever the underlying assumptions are not reasonably transparent.
  • Action items for further work have been marked as FIXME for now.

Module jpype changes:

Because these do affect the end user, we have marked them as enhance, change, remove, bug fix, or internal.

General:

  • (enhance) Static methods and fields are now accessible from an object instance. Appropriate exceptions are issued if attempting to operate on a static member without an object instance.
  • (enhance) __all__ added to all modules so that we have a well defined export rather that leaking symbols everywhere. Eliminated stray imports in the jpype namespace.
  • (enhance) Add @deprecated to _core and marked all functions that are no longer used appropriately. Use -Wd to see deprecated function warnings.
  • (enhance) Exposed JavaInterface, JavaObject, JavaClass so that they can be used in issubclass and isinstance statement. JavaClass.__new__ method was pushed to factory to make it safe for external use.
  • (enhance) mro for Java Classes removes JavaInterface so that issubclass(cls, JavaInterface) is only true if the class not derived from JavaObject.
  • (enhance) All classes derived from java.lang.Throwable are now usable as thrown exceptions. No requirement to access special inner classes with exception types. Exceptions can be raised directly from within a python context to be passed to java when in proxy. Throwables now use a standard customizer to set their base class to the python Exception tree. Deprecated JException
  • (enhance) args is a property of java.lang.Throwable containing the message and the cause if specified.
  • (enhance) JChar array now converts to a string and compares with string properly. Conversion uses range so that it does not try to convert character by character.
  • (remove) JByte array is not a string type. It is not a string in java and should not be treated as a string without explicit conversion. Conversion path was horribly inefficient converting each byte as a python object. Test marked as skip.
  • (change) Array conversion errors produce TypeError rather than RunTimeError.
  • (enhance) JArray now supports using raw python types as the specifier for array types. It will convert to the most appropraite type or return an error.
  • (remove) property conversion customizer is deactivated by default. This one proved very problematic. It overrided certain customizers, hid intentionally exposed fields, bloated the dictionary tables, and interferred with the unwrapping of exception types. We can try to make it an optional system with import jpype.properties or some such but it will still have all those problems. Best to kill this misfeature now.
  • (enhance) JArray classes now have class_. We can access the component type. This makes them more consistent with JClass. (required for testing)
  • (enhance) Use of constructor call pattern eliminated the need for use of a separate factory and type. Thus we are back to the original design in which we only need to expose a small number of "types". This was applied to JArray, JClass, JException, and JObject. Use of isinstance() and issubclass now supported. The only challenge was keeping box types working.
  • (remove) Functions that return a string now return a java.lang.String rather than converting to Python. Thus when chaining elements together in java will get the full benefit matching types. The previous auto convert has been removed.
  • (enhance) java.lang.String now has much more complete set of python operations. String conversions are now cached, so the penalty of converting is kept to a minimum.
  • Tried to be more consistent about returning errors that are valid in python.
    • Too many or two few arguments to a function will throw a TypeError
    • Value conversion out of range will throw OverFlowError
    • Value conversions that are the right type but invalid value will
      give ValueError (char from string too long)
    • Type conversions that cannot be completed should give TypeError.
    • Errors setting attributes should give AttributeError such as trying to set a final field or trying to get an instance field from a static object.
    • Arrays access should produce IndexError on bad range.
      (it would be nice if these also mapped to java errors and the corresponding errors in java were derived from the python error so that we can properly look for ArrayIndexOutOfBoundsException (derived from IndexException). But that is too heavy to attempt now.)

Wrappers:

  • (internal) Rewrote the JWrapper module from scratch to reflect the use of JPValue. Renamed _jwrapper to _jtypes. The concept of wrappers has now been lost internally. All objects and primitives are just values.
  • (enhance) Created import module containing all of the symbols needed for creating types in jpype so that we can support a limited import statement from jpype.types import *
  • (enhance) JString contructor now returns a java.lang.String object. Removed JStringWrapper as java.lang.String serves its purpose.
  • (enhance) JObject now returns an object with the java type as a functional object rather than a dead end wrapper. This does allow some redundant things such as converting a python class wrapper into a class JObject(java.lang.String) == java.lang.String.class_ but otherwise seems good.
  • (enhance) 'JObject' and 'JString' accept 0 arguments to generate a generic object and empty string.
  • (enhance) JArray, JException and JObject report as JavaClass when using issubclass.

Internal:

  • (internal) Changes corresponding to the __init__ rework to match revised PyJP* classes.
  • (internal) Changes corresponding to the capsule removal.
  • (internal) Remove SPECIAL_CONSTRUCTOR_KEY as everything that uses it can recognize a PyJPValue as indicating they are receiving an existing java resource as input. All special handling required to construct objects from within C++ layer were thus eliminated.
  • (internal) Removed almost all required resources from python needing to be register in _jpype with the exception of getClassMethod.
  • (internal) Java class customizers did not need to be deferred until after the JVM is initialized. Pushing them into the dictionary immediately fixes issues in which a customizer was not applied to classes during early bootstrapping. This eliminates a large number of the need for calling initialize on each jpype module in _core.
  • (internal) JArrayClass and JClass are the same for purposes of Customizers and class tree.
  • (internal) Customizer code and dictionary moved to _jcustomizer so that it can be shared between Object and Array classes.
  • (internal) Converted JavaClass to more python like "try first, eat an exception if it fails" philosophy to increase robustness to failure. This eliminates the problems when a new base class is introduced with a customizer without setting up a meta class.
  • (internal/enhance) Broke connections between boxed types and wrappers. User supplied wrappers can implements specified "Value" method. Wrapper types now have similar methods to boxed types with appropriate range checks.
  • (internal) All $Static meta classes have been eliminated. There is now only one tree of classes. A single meta class JClass serves as the type for all classes.
  • (intenal) Short cut for just adding a base class as a customizer.

Bugs:

  • (bug fix) Fixed bug in jpype.imports in which it would not install its hooks if loaded afer the jvm was started.
  • (bug fix) Fixed bug in JBoxed type wrappers in python which would lead
    java.lang.Double and java.lang.Float to have an integer value when boxed was corrected.
  • (bug fix) Fixed bug in JObject that was preventing classes from being wrapped as objects. Verified a number of test cases in the test suite.
  • (bug fix) Reenabled the throw from java test during proxy. The issue was that jpype was releasing resources before it could transfer control a PyErr_Clear removed the reference and thus our throwable was invalid. It was dastardly to find, but the fix was moving a statement one line up.

TODO:

  • Finish specialization of JPArray classes for byte[] and char[]
  • Read the user manual and revise accordingly.
  • Deal with fast array conversions misuse of types. int[]<=>float[]
  • Direct bridge methods for char[] are currently bypassing the unicode
    translation layer. It is unclear what Java does with extended unicode
    when dealing with char[].
  • Add a system to register a translation customizer so that we do not need to
    modify C++ code to add new simple translations like python date to java
    Instant. These would be installed into the PyJPClass during class
    wrapper customization. We will need to make sure each class has a Python
    type wrapper cached in ensureTypeCache so we are guaranteed to find
    the conversion.
  • Use translation customizer to merge numpy basic data types into
    primitive conversions.
  • Revise proxy to use implements. (Assuming someone ever responds to the
    issue posting.)
  • Add tests for Exception.args
  • Reenable lost "synchronized" command
@marscher

This comment has been minimized.

Copy link
Collaborator

commented Jul 1, 2018

wow, very impressive! I'm kind of underwater right now, so the review of this will take some time - sorry.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 1, 2018

Not to worry. I still have to get it working on the CI. Oddly none of the 4 that I test on are displaying that segfault. It seems like it is a shutdown bug so I will start there. Once I get done with that I will start on phase 2 of the refactor which is gutting the JNI, moving to a class loader, etc.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 4, 2018

Progress thus far. Finished Linux 3.x build, 2.7 linux, cygwin 3.6, and both flavors of windows compiler issues. I still have to finish the unicode to string method for 2.7 (there was no test case for this), fix the int length issue, and investigate pypy issues.

After this I will go fix numpy issues.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 9, 2018

I made some progress on PyPy. It is much closer to working than previous. All problems with crashing due to mishandling of tuples were fixed with the refactor. Unfortunately, it is failing checks regarding memory leaks. I am not sure if this is a problem with the test code or with our functionality on PyPy. It is not a high priority to track down for me as I do not use PyPy, but perhaps it is close enough for someone who is interested to run to ground.

@Thrameos Thrameos force-pushed the Thrameos:devel branch from 6a70e73 to 4275107 Jul 9, 2018

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 9, 2018

@marscher This massive patch is complete.

There are still a half dozen test cases that I need to add and work through before it is ready to use in a production sense. Most of the issues have to do with untested code on unicode conversion of jchar types. I didn't have much to work with other than the python docs and I may have messed up a pattern. It is not so much that I am sure that it is wrong, but simply that I less confident than with the rest of the code.

I did manage to keep Python 2.6 working in this patch, but it is getting a bit burdensome. Our test cases for the memory view stuff is pretty thin. I suspect that some stuff may not be quite right on raw io buffers. But that code was just as suspect before as it is now. The jpype_memoryview stuff was actually disabled in master due to a header issue and my refactor reactivated some of that. Given that 2.6 docs are getting scarce I am not sure how much longer we can support it.

I know that you are currently occupied, but I do plan to make further progress in the meantime. Rather than piling those other changes into this massive pull request I am going to split out those clean up activities into separate branches off of my devel head. Thus I won't be able to submit them until this current pull is reviewed. Most of them are single issue pulls such as getting synchronized working, improving proxy, auto generation of proxy for functors, more test cases, revising customizers, etc. But once those are complete I will be cutting into the jni transactions at the back end. With this reorg that should be much less disruptive but will still generate another very large pull request.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 9, 2018

Synchronized branch now has a working test case for synchronized using pyjp_monitor.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 10, 2018

Lambdas branch now has working test case for returning an anonymous class or lambda.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 14, 2018

I am working on the next patch for duck typing of primitives that will allow numpy types to get converted. It is a pain because it is hard to determine if something is actually an int type or a float type given they all have both __int__ and __float__. I have settled on checking for __and__ as the tie breaker. Does this seem reasonable?

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 14, 2018

Nevermind. I found the call I needed for the duck typing.

https://www.python.org/dev/peps/pep-0357/

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 14, 2018

primitive_duck branch now has support for duck typing of primitives to support numpy types.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 16, 2018

customizer branch has mostly complete rework of class customizers. Using @JImplementationFor we can declare any class to hold the methods for the finished JClass instance. This simplified adding new customizers. The revised customizers are applied with O(1) so there is not performance cost. By setting a __jclass_init__ method in customizer class, it can apply customizations to all derived classes.

It fails with a segfault in one test. So I need to run it to ground before it is ready.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 21, 2018

devel_utf8 branch has a working test case for UTF8 with surrogate codes for Python3. I will need to test Python2 before it is complete. The patch is a bit of a mess as it pulled the devel branch in twice. I will get it cleaned up when the devel is branch up to date.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 22, 2018

devel_utf8 branch now has full support for utf translation for python 2 and python 3 thanks to test cases provided by rene-bakker-it.

@marscher I have about two to three more tasks that I can complete before maintaining separate branches for each modification will start to become difficult due to conflicts on the C++ backend.

I think I can complete the customizer rework debugging, fix numpy array encoding, and improve proxies with decorators. After that I will start needing code from the multiple branches together so that I can proceed to add the automatic type conversion (hits all classes in C++ derived from jp_class) and the class loader code (hits all C++ code using jp_jniutil and typemanager) . Pulling char[] and byte[] from jp_arrayclass is currently on hold as it will conflict with utf-8 encoding changes. Auto proxy on functional interface is contingent on type conversion code. Enhanced tracing may be possible without conflicts, but as the only person likely to benefit from integrating java, c++ and python stacktraces is me I am leaving that as a low priority. Automatic docstring will depend on me being about to override the slot designation to produce a dynamic string, so that will just depend on how lucky I get with cpython fallback paths on slot lookup. And all it can do is state the method signatures unless I find a portable way to fetch javadoc from a class file.

I could start pushing this other branches into the devel, as the massive patch is already a reviewing nightmare I don't think that is a good route. Thus I am going to run out the list of independent tasks, update the project plan, then go on break until you have time to catch up.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Jul 25, 2018

customizer branch contains a completed rework of class customizers. Customizers now simply require using a decorator on an ordinary class to define new methods. Late customizers (post class construction) are possible. One issue resulting in a segfault was identified and verified to be an issue in master. The branch is ready for a pull request once devel is reviewed.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Aug 2, 2018

@marscher any hope of starting this review? My lead employee just quit and I am going to be snowed under for the next few months while I try to find a replacement. I should still be able to get the branched copied merge in once the main review is complete, but otherwise I will have to put the rest on hold until the situation is corrected.

@marscher

This comment has been minimized.

Copy link
Collaborator

commented Aug 3, 2018

The changes are looking good to me. I have one little change request. Could you please run the Python code through autopep8 to have a standard formatting?

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Aug 3, 2018

Applied the autopep8. It changed a lot of stuff and not necessarily in the places that I had been working. Do you have specific settings that we should be applying or is the default settings fine?

I ran it as

python3 -m autopep8 --in-place jpype/*.py setup.py setupext/*.py test/jpypetest/*.py

I can't flatten this pull though because I have 7 branches hung off it right now.

@marscher

This comment has been minimized.

Copy link
Collaborator

commented Aug 3, 2018

Defaults should be fine! Thanks a lot for this massive change!

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Aug 3, 2018

Okay I rebased customizer, primitive_duck and synchronized and applied autopep8 to each of them. Once you apply this pull request to devel I will submit those. I can then move forward the utf8.

We won't quite be to a releasable once all the patches go in. We should consider doing the following before we release 0.7.0:

  • go over the docs
  • merge the user relevant part of my change logs into the official change log.
  • fix the np.array bug
  • decide the severity of the base class method bug. It is pretty nasty because it is a hard crash. But it is on an undocumented function so I could go either way.
@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Aug 4, 2018

Hmm it appears that the appveyor check is not up yet.

@Thrameos

This comment has been minimized.

Copy link
Contributor Author

commented Aug 5, 2018

@marscher Do we want to merge this now or do we need to wait for an appveyor check?

@Thrameos Thrameos merged commit a36f892 into jpype-project:devel Aug 8, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.