troubles with JNIPort on Pharo 5 / Java 8

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

troubles with JNIPort on Pharo 5 / Java 8

Tudor Girba-2
Hi,

I am having trouble running JNIPort with Pharo 5 and Java 8 on Mac OS X 10.10.4.

The code loads fine:
Gofer new 
smalltalkhubUser: 'JNIPort' project: 'JNIPort';
configuration;
loadVersion: '3.0-alpha'.

However, I do not know where to point "JNIPortJNIInterface libraryFile:" to. In the original instructions for Java 1.6, the code looked like:
JNIPortJNIInterface libraryFile:
'/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib'

With JDK 1.8 (and even 1.7), the file organization seems to be different and the libclient.dylib does not exist.

I tried to point it to libjli.dylib, which looks similar, but that does not seem to work:
JNIPortJNIInterface libraryFile:
'/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/MacOS/libjli.dylib'.

Can anyone point me in the right direction?

Cheers,
Doru

--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Joachim Geidel
Tudor Girba-2 wrote
However, I do not know where to point "JNIPortJNIInterface libraryFile:"
to. In the original instructions for Java 1.6, the code looked like:
JNIPortJNIInterface libraryFile:
'/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib'

With JDK 1.8 (and even 1.7), the file organization seems to be different
and the libclient.dylib does not exist.

I tried to point it to libjli.dylib, which looks similar, but that does not
seem to work:
JNIPortJNIInterface libraryFile:
'/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/MacOS/libjli.dylib'.
Hi Doru,

JLI is the Java Legacy Interface, not the VM.

AFAICT, the JVM library should be at
/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/server/libjvm.dylib

Java 8 for OS X is a 64 bit version, it won't work with a 32 bit Pharo. When I released the latest version of JNIPort, there was no 64 bit NativeBoost, and as as JNIPort for Pharo is based on NativeBoost, I guess that it won't work with Java 8. However, if you have Apple's original Java 6 installed, you can still use that. An alternative JVM might be JamVM, but I can't check right now if there is a 32 bit version as SourceForge is currently offline.

HTH
Joachim
Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Tudor Girba-2
Hi Joachim,

Thanks for the answer.

I did not have Java 1.6 anymore on my Yosemite, but I installed it now. For reference, here is how to get it:

I still have problems in Pharo5.

I am trying the following script:

I tried in Pharo 3, and the script worked fine.

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.

Any idea of what goes wrong?

Cheers,
Tudor




On Fri, Jul 17, 2015 at 11:56 AM, Joachim Geidel <[hidden email]> wrote:
Tudor Girba-2 wrote
> However, I do not know where to point "JNIPortJNIInterface libraryFile:"
> to. In the original instructions for Java 1.6, the code looked like:
> JNIPortJNIInterface libraryFile:
> '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib'
>
> With JDK 1.8 (and even 1.7), the file organization seems to be different
> and the libclient.dylib does not exist.
>
> I tried to point it to libjli.dylib, which looks similar, but that does
> not
> seem to work:
> JNIPortJNIInterface libraryFile:
> '/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/MacOS/libjli.dylib'.

Hi Doru,

JLI is the Java Legacy Interface, not the VM.

AFAICT, the JVM library should be at
/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/server/libjvm.dylib

Java 8 for OS X is a 64 bit version, it won't work with a 32 bit Pharo. When
I released the latest version of JNIPort, there was no 64 bit NativeBoost,
and as as JNIPort for Pharo is based on NativeBoost, I guess that it won't
work with Java 8. However, if you have Apple's original Java 6 installed,
you can still use that. An alternative JVM might be JamVM, but I can't check
right now if there is a 32 bit version as SourceForge is currently offline.

HTH
Joachim



--
View this message in context: http://forum.world.st/troubles-with-JNIPort-on-Pharo-5-Java-8-tp4836922p4837933.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.




--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Joachim Geidel
Hi Tudor,

unfortunately I haven’t had much time to work on JNIPort for a while. I have started to simplify some of the code, but this isn’t finished yet, and I have not yet looked into Pharo 4 and 5. The latest Pharo version I have worked with was 3, because I was waiting for the VM and NativeBoost changes which were announced but not finished the last time I looked (which is a long time ago). So currently, I can’t tell what is wrong. Obviously, something has changed in the class building mechanism since Pharo 3. The other problem might be related to NativeBoost or the VM, but of course I am speculating for now.

Cheers,
Joachim

Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>:

Hi Joachim,

Thanks for the answer.

I did not have Java 1.6 anymore on my Yosemite, but I installed it now. For reference, here is how to get it:

I still have problems in Pharo5.

I am trying the following script:

I tried in Pharo 3, and the script worked fine.

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.

Any idea of what goes wrong?

Cheers,
Tudor

Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Tudor Girba-2
Hi Joachim,

Thanks for the answer.

Unfortunately, I am stuck at the moment too, and I have no idea how to proceed. I would really benefit from your, or someone else's, help :).

Cheers,
Doru


On Tue, Jul 28, 2015 at 9:57 PM, Joachim Geidel <[hidden email]> wrote:
Hi Tudor,

unfortunately I haven’t had much time to work on JNIPort for a while. I have started to simplify some of the code, but this isn’t finished yet, and I have not yet looked into Pharo 4 and 5. The latest Pharo version I have worked with was 3, because I was waiting for the VM and NativeBoost changes which were announced but not finished the last time I looked (which is a long time ago). So currently, I can’t tell what is wrong. Obviously, something has changed in the class building mechanism since Pharo 3. The other problem might be related to NativeBoost or the VM, but of course I am speculating for now.

Cheers,
Joachim

Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>:

Hi Joachim,

Thanks for the answer.

I did not have Java 1.6 anymore on my Yosemite, but I installed it now. For reference, here is how to get it:

I still have problems in Pharo5.

I am trying the following script:

I tried in Pharo 3, and the script worked fine.

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.

Any idea of what goes wrong?

Cheers,
Tudor



View this message in context: Re: troubles with JNIPort on Pharo 5 / Java 8
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.



--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Tudor Girba-2
Hi again,

I continued with experimentation in Pharo 3. Specifically, I would like to get a callback working, but something does not work out.

Could you take a look below? Perhaps you can spot what I am doing wrong.

Here is what I did:

1. I downloaded:

2. I created the following Java class:

package com.tudorgirba.jniport.callback;

import jniport.RequestNotHandedException;

import jniport.SmalltalkNotification;

public class SimpleNotifier {

private static final Object   notifyTag = new String("sendNotification()");

public static Object notifyTag () { return notifyTag; }

public void sendNotification() throws RequestNotHandedException

{

new SmalltalkNotification(notifyTag, this).send();

}

}


3. Then I ran this code in a Pharo 3.0 image:

"---"
Gofer new 
smalltalkhubUser: 'JNIPort' project: 'JNIPort';
configuration;
loadVersion: '3.0-baseline'.

JNIPortJNIInterface libraryFile:
'/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib'.
jvmSettings := JVMSettings new.
jvmSettings usesGhosts: true.
jvmSettings supportsCallbacks: true.
jvmSettings jniPortSettings  useJNIHelperLibrary: false.
jvmSettings ghostClassSettings retainMethodSource: true.
jvmSettings runtimeSettings classpath:
'.:/Users/girba/Work/Code/moose/JNIPort30.jar:/Users/girba/Work/Code/moose/JNIPort30-Tests.jar:/Users/girba/Work/Code/moose/jniport/jniport-callbacks/bin/'.
Cursor execute showWhile: [JVM newWithSettings: jvmSettings].
notifierClass := JVM current findClass: #'com.tudorgirba.jniport.callback.SimpleNotifier'.
JVM current callbackRegistry
        setCallback: notifierClass notifyTag
        handler: [:this :param | self halt].
notifier := notifierClass new.
notifier sendNotification.
"---"

Everything executes without error, but the self halt part is not reached.
I would expect that when the #sendNotification is executed, the corresponding handler gets executed and the debugger appears.
(I thought that perhaps something is wrong with the classpath, but the notifierClass and the notifier objects look just fine)

Any idea of what is wrong?

Cheers,
Doru




On Wed, Jul 29, 2015 at 10:47 AM, Tudor Girba <[hidden email]> wrote:
Hi Joachim,

Thanks for the answer.

Unfortunately, I am stuck at the moment too, and I have no idea how to proceed. I would really benefit from your, or someone else's, help :).

Cheers,
Doru


On Tue, Jul 28, 2015 at 9:57 PM, Joachim Geidel <[hidden email]> wrote:
Hi Tudor,

unfortunately I haven’t had much time to work on JNIPort for a while. I have started to simplify some of the code, but this isn’t finished yet, and I have not yet looked into Pharo 4 and 5. The latest Pharo version I have worked with was 3, because I was waiting for the VM and NativeBoost changes which were announced but not finished the last time I looked (which is a long time ago). So currently, I can’t tell what is wrong. Obviously, something has changed in the class building mechanism since Pharo 3. The other problem might be related to NativeBoost or the VM, but of course I am speculating for now.

Cheers,
Joachim

Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>:

Hi Joachim,

Thanks for the answer.

I did not have Java 1.6 anymore on my Yosemite, but I installed it now. For reference, here is how to get it:

I still have problems in Pharo5.

I am trying the following script:

I tried in Pharo 3, and the script worked fine.

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.

Any idea of what goes wrong?

Cheers,
Tudor



View this message in context: Re: troubles with JNIPort on Pharo 5 / Java 8
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.



--

"Every thing has its own flow"



--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Tudor Girba-2
Hi again,

In the meantime I found the problem: if I replace self halt with a concrete execution, it works :).

I also tested the passing of arguments back and forth between Pharo3 and Java 1.6 and that works fine, as well.

Now, the only thing left is to get this running on Pharo5.

Cheers,
Doru





On Thu, Jul 30, 2015 at 10:44 PM, Tudor Girba <[hidden email]> wrote:
Hi again,

I continued with experimentation in Pharo 3. Specifically, I would like to get a callback working, but something does not work out.

Could you take a look below? Perhaps you can spot what I am doing wrong.

Here is what I did:

1. I downloaded:

2. I created the following Java class:

package com.tudorgirba.jniport.callback;

import jniport.RequestNotHandedException;

import jniport.SmalltalkNotification;

public class SimpleNotifier {

private static final Object   notifyTag = new String("sendNotification()");

public static Object notifyTag () { return notifyTag; }

public void sendNotification() throws RequestNotHandedException

{

new SmalltalkNotification(notifyTag, this).send();

}

}


3. Then I ran this code in a Pharo 3.0 image:

"---"
Gofer new 
smalltalkhubUser: 'JNIPort' project: 'JNIPort';
configuration;
loadVersion: '3.0-baseline'.

JNIPortJNIInterface libraryFile:
'/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib'.
jvmSettings := JVMSettings new.
jvmSettings usesGhosts: true.
jvmSettings supportsCallbacks: true.
jvmSettings jniPortSettings  useJNIHelperLibrary: false.
jvmSettings ghostClassSettings retainMethodSource: true.
jvmSettings runtimeSettings classpath:
'.:/Users/girba/Work/Code/moose/JNIPort30.jar:/Users/girba/Work/Code/moose/JNIPort30-Tests.jar:/Users/girba/Work/Code/moose/jniport/jniport-callbacks/bin/'.
Cursor execute showWhile: [JVM newWithSettings: jvmSettings].
notifierClass := JVM current findClass: #'com.tudorgirba.jniport.callback.SimpleNotifier'.
JVM current callbackRegistry
        setCallback: notifierClass notifyTag
        handler: [:this :param | self halt].
notifier := notifierClass new.
notifier sendNotification.
"---"

Everything executes without error, but the self halt part is not reached.
I would expect that when the #sendNotification is executed, the corresponding handler gets executed and the debugger appears.
(I thought that perhaps something is wrong with the classpath, but the notifierClass and the notifier objects look just fine)

Any idea of what is wrong?

Cheers,
Doru




On Wed, Jul 29, 2015 at 10:47 AM, Tudor Girba <[hidden email]> wrote:
Hi Joachim,

Thanks for the answer.

Unfortunately, I am stuck at the moment too, and I have no idea how to proceed. I would really benefit from your, or someone else's, help :).

Cheers,
Doru


On Tue, Jul 28, 2015 at 9:57 PM, Joachim Geidel <[hidden email]> wrote:
Hi Tudor,

unfortunately I haven’t had much time to work on JNIPort for a while. I have started to simplify some of the code, but this isn’t finished yet, and I have not yet looked into Pharo 4 and 5. The latest Pharo version I have worked with was 3, because I was waiting for the VM and NativeBoost changes which were announced but not finished the last time I looked (which is a long time ago). So currently, I can’t tell what is wrong. Obviously, something has changed in the class building mechanism since Pharo 3. The other problem might be related to NativeBoost or the VM, but of course I am speculating for now.

Cheers,
Joachim

Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>:

Hi Joachim,

Thanks for the answer.

I did not have Java 1.6 anymore on my Yosemite, but I installed it now. For reference, here is how to get it:

I still have problems in Pharo5.

I am trying the following script:

I tried in Pharo 3, and the script worked fine.

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.

Any idea of what goes wrong?

Cheers,
Tudor



View this message in context: Re: troubles with JNIPort on Pharo 5 / Java 8
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.



--

"Every thing has its own flow"



--

"Every thing has its own flow"



--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Joachim Geidel
In reply to this post by Tudor Girba-2
Hi Tudor,

some progress in Pharo 5:

> Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Tudor Girba-2
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 <[hidden email]> wrote:
Hi Tudor,

some progress in Pharo 5:

> Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>:
>
> 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
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.



--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Tudor Girba-2
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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Tudor,

some progress in Pharo 5:

> Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>:
>
> 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
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.



--

"Every thing has its own flow"



--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Joachim Geidel
Hi Tudor,

Am 09.08.2015 um 13:27 schrieb Tudor Girba:
I tested your changes, and I confirm that the code works fine in Pharo 5. Now, we just need to get them published :).

I tend to avoid words like „just“, „simply“ etc. when talking about software. ;-)  The ConfigurationOfJNIPort should be updated in a way which lets one load the current package versions when using Pharo 3, and new ones when using Pharo 4 or 5. I haven’t used this stuff for a while, and will have to read the documentation again before being able to publish something useable.

I have just added you as a contributor to the JNIPort project and as a member to the JNIPort team at SmalltalkHub, so you can publish changes.

Cheers,
Joachim

Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Tudor Girba-2
Hi,

Great.

However, I notice that you have some distinct version names, and this seems to throw MC off. For example, when trying to load the latest version of ConfigurationOfJNIPort:
- we get: ConfigurationOfJNIPort-JoachimGeidel.3.0a3
- instead of: ConfigurationOfJNIPort-JoachimGeidel.3.0a4

This problem would be fixed if we would change the numbering a bit. For example, when I try to commit a new version of the configuration, Monticello offers:
ConfigurationOfJNIPort-TudorGirba.3.5

Is it Ok if I commit it like this?

Cheers,
Doru



On Sun, Aug 9, 2015 at 1:44 PM, Joachim Geidel <[hidden email]> wrote:
Hi Tudor,

Am 09.08.2015 um 13:27 schrieb Tudor Girba:
I tested your changes, and I confirm that the code works fine in Pharo 5. Now, we just need to get them published :).

I tend to avoid words like „just“, „simply“ etc. when talking about software. ;-)  The ConfigurationOfJNIPort should be updated in a way which lets one load the current package versions when using Pharo 3, and new ones when using Pharo 4 or 5. I haven’t used this stuff for a while, and will have to read the documentation again before being able to publish something useable.

I have just added you as a contributor to the JNIPort project and as a member to the JNIPort team at SmalltalkHub, so you can publish changes.

Cheers,
Joachim



View this message in context: Re: troubles with JNIPort on Pharo 5 / Java 8
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.



--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Joachim Geidel

> Am 09.08.2015 um 14:36 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>:
> However, I notice that you have some distinct version names, and this seems to throw MC off. For example, when trying to load the latest version of ConfigurationOfJNIPort:
> - we get: ConfigurationOfJNIPort-JoachimGeidel.3.0a3
> - instead of: ConfigurationOfJNIPort-JoachimGeidel.3.0a4
>
> This problem would be fixed if we would change the numbering a bit. For example, when I try to commit a new version of the configuration, Monticello offers:
> ConfigurationOfJNIPort-TudorGirba.3.5
>
> Is it Ok if I commit it like this?

Yes, of course, do whatever it takes. I used the „aN“ suffer because I considered that version as an alpha release, and wanted to do a lot more before publishing a „real“ release.

Cheers,
Joachim

Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Tudor Girba-2
Ok. I added now:
- 3.1-alpha with packages for pharo 5
- development and stable symbolic versions for pharo 3 and pharo 5.

The tests problem should still be solved. Do you still want to look at that?

Once that is done, the tests packages should be added to the version. I can do that.

Cheers,
Doru



On Sun, Aug 9, 2015 at 2:51 PM, Joachim Geidel <[hidden email]> wrote:

> Am 09.08.2015 um 14:36 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>:
> However, I notice that you have some distinct version names, and this seems to throw MC off. For example, when trying to load the latest version of ConfigurationOfJNIPort:
> - we get: ConfigurationOfJNIPort-JoachimGeidel.3.0a3
> - instead of: ConfigurationOfJNIPort-JoachimGeidel.3.0a4
>
> This problem would be fixed if we would change the numbering a bit. For example, when I try to commit a new version of the configuration, Monticello offers:
> ConfigurationOfJNIPort-TudorGirba.3.5
>
> Is it Ok if I commit it like this?

Yes, of course, do whatever it takes. I used the „aN“ suffer because I considered that version as an alpha release, and wanted to do a lot more before publishing a „real“ release.

Cheers,
Joachim



View this message in context: Re: troubles with JNIPort on Pharo 5 / Java 8
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.



--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: troubles with JNIPort on Pharo 5 / Java 8

Joachim Geidel
Thanks a lot!

I will look into the problem with the test package as soon as possible.

Joachim

Am 9. August 2015 17:29:42 MESZ, schrieb "Tudor Girba-2 [via Smalltalk]" <[hidden email]>:
Ok. I added now:
- 3.1-alpha with packages for pharo 5
- development and stable symbolic versions for pharo 3 and pharo 5.

The tests problem should still be solved. Do you still want to look at that?

Once that is done, the tests packages should be added to the version. I can do that.

Cheers,
Doru



On Sun, Aug 9, 2015 at 2:51 PM, Joachim Geidel <[hidden email]> wrote:

> Am 09.08.2015 um 14:36 schrieb Tudor Girba-2 [via Smalltalk] <[hidden email]>:
> However, I notice that you have some distinct version names, and this seems to throw MC off. For example, when trying to load the latest version of ConfigurationOfJNIPort:
> - we get: ConfigurationOfJNIPort-JoachimGeidel.3.0a3
> - instead of: ConfigurationOfJNIPort-JoachimGeidel.3.0a4
>
> This problem would be fixed if we would change the numbering a bit. For example, when I try to commit a new version of the configuration, Monticello offers:
> ConfigurationOfJNIPort-TudorGirba.3.5
>
> Is it Ok if I commit it like this?

Yes, of course, do whatever it takes. I used the „aN“ suffer because I considered that version as an alpha release, and wanted to do a lot more before publishing a „real“ release.

Cheers,
Joachim



View this message in context: Re: troubles with JNIPort on Pharo 5 / Java 8
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.



--

"Every thing has its own flow"



If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/troubles-with-JNIPort-on-Pharo-5-Java-8-tp4836922p4841826.html
To unsubscribe from troubles with JNIPort on Pharo 5 / Java 8, click here.
NAML

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.