Hi, I tested your changes, and I confirm that the code works fine in Pharo 5. Now, we just need to get them published :).
Cheers, Doru On Sun, Aug 9, 2015 at 12:50 PM, Tudor Girba <tu...@tudorgirba.com> wrote: > Hi Joachim, > > This is great news! Thanks a lot for looking into this. > > Could you commit your changes? Or could you grant me access to the JNIPort > project? > > Cheers, > Doru > > > > On Sun, Aug 9, 2015 at 12:25 PM, Joachim Geidel < > joachim.gei...@onlinehome.de> wrote: > >> Hi Tudor, >> >> some progress in Pharo 5: >> >> > Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk] <[hidden >> email] <http:///user/SendEmail.jtp?type=node&node=4841798&i=0>>: >> > >> > I also tried with Pharo4 and Pharo5, but it does not work because I get >> a MNU for GhostClassBuilder>>#client:. >> > >> > I fixed it in a Pharo5 image by using #installer: instead, but the >> computation of "JVM newWithSettings: jvmSettings" does not seem to finish >> and it blocks the VM. >> >> Changing the call of #client: to #installer: in >> GhostClassInstaller>>#initialize: was correct. >> >> > Any idea of what goes wrong? >> >> Someone declared String>>subStrings: as deprecated in Pharo 4 or 5. When >> I ran „JVM newWithSettings: jvmSettings“, a notifier opened which warned >> about the deprecated method. I changed the method which used it in the >> debugger, then proceeded. The image blocked until I hit <cmd-.>. A debugger >> opened, it was in the middle of writing to the Pharo error log file. I >> proceeded, the image blocked again, I hit <cmd-.> again. A debugger opened >> which contained a very large stack of contexts with the method >> handleSignal: calling itself endlessly. There seems to be something wrong >> with handling/logging deprecation warnings in Pharo 5. Why do they have to >> be written to the error log in the first place? I don’t think that they >> belong there. >> >> There are four methods sending subStrings: in the package >> JNIPort-Java-Base. I changed them to use substrings: instead. >> >> There are two methods in JNIPort-StringEncoding which send "Smalltalk >> isLittleEndian“, String>>#asJavaLangStringEncodedByteArray and >> String>>#fromJavaLangStringEncodedByteArray:. This does not work anymore. I >> replaced this with "EndianDetector isLittleEndian“. >> >> After these changes, starting a JVM and executing the example script >> which you posted just worked fine. >> >> Unfortunately, loading the test package JNIPort-Tests-Java-Base fails >> with an exception: >> >> UTF8InvalidText(Object)>>subclassResponsibility >> UTF8InvalidText(Exception)>>defaultAction >> UndefinedObject>>handleSignal: >> Context>>handleSignal: >> >> AFAIK, there was no problem when loading the package in Pharo 3. There >> seem to be two problems: The UTF8TextConverter seems to think that there is >> an invalid character in the source code file, and UTF8InvalidText has no >> #defaultAction method. Looks like a bug in Pharo 5 to me. >> >> HTH >> Joachim >> >> >> ------------------------------ >> View this message in context: Re: troubles with JNIPort on Pharo 5 / >> Java 8 >> <http://forum.world.st/troubles-with-JNIPort-on-Pharo-5-Java-8-tp4836922p4841798.html> >> Sent from the Pharo Smalltalk Users mailing list archive >> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at >> Nabble.com. >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"
