Hi Tudor,
it should be
jvmSettings runtimeSettings addOption: '-Xmx4000m'.
The options are added with exactly the same string which is used in command
lines.
You can check the value of an option by using java.lang.System.getProperty()
if it is a "-Dname=value" option. For -X options, it is no
Hi Tudor,
It is not possible to start a Java VM again in the same operating system
process after shutting it down. You have to restart Pharo to do this. This
is a restriction of the Java VM itself, not a restriction of JNIPort. The
JVM specification also says that it should be possible to start mo
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
> Am 09.08.2015 um 14:36 schrieb Tudor Girba-2 [via Smalltalk]
> :
> 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
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
Hi Tudor,
some progress in Pharo 5:
> Am 28.07.2015 um 16:10 schrieb Tudor Girba-2 [via Smalltalk]
> :
>
> 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
>
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 NativeB
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'
>
> Wit
.
Best regards
Joachim Geidel
My OpenPGP Key: 29F88108 available from hkp://keys.gnupg.net
Hi all,
Am 30.05.2014 um 10:30 schrieb kilon alios :
> he has not provided documentation for Nativeboost that's true, but he never
> left a question unanswered either ;)
just to make sure that my message isn’t misunderstood: I am not blaming Igor
for not having written a book about NativeBoost
with
simple things like de-referencing a pointer to a pointer to a struct etc. - I
didn’t find documentation for this, and this is a basic feature in my opinion.
Best regards,
Joachim Geidel
> Additional examples can be found in the class NBBasicExamples in the package
>
ws, this is the „real“ registry),
and there are menu items in the system browser for generating Smalltalk wrapper
classes for Java classes. None of this exists for Pharo yet.
Best regards,
Joachim Geidel
BTW, I have published an updated version of JNIPort which partly resolves the
performance issue caused by using #become:.
Joachim
--
My OpenPGP Key: 29F88108 available from hkp://wwwkeys.de.pgp.net
Hi Igor,
thanks a lot, your analysis is correct, and it helped.
Am 05.04.2014 um 17:05 schrieb Igor Stasenko:
> so, without going deep into implementation details, just by reading comment
> i can already see potential bottleneck - using #become: operation which is
> veery slow.
Yes, #become: i
Am 31.03.2014 um 21:25 schrieb Tudor Girba :
> Now, the next question. I saw that it is possible to enable callbacks, but I
> could not find an example of how it works.
>
> For example, could we model this:
>
> - in a JavaClassOriginator class we have a method like
> execute(JavaClassTargetInter
Hi Doru,
Am 27.03.2014 um 13:07 schrieb Tudor Girba:
> Just a question: is there a way to communicate with an already running VM
> that was started independently from Pharo?
JNIPort uses the Java VM as a DLL / shared library, using the Java Invocation
Interface which is part of the Java Native
it seems that calling
a JNI method with NativeBoost is extremely slow, but I don't trust those
profiles too much.
So, give it a try, and if you find something useful concerning the bad
performance, please send me a message.
Best regards,
Joachim Geidel
--
View this message in context:
http://forum.world.st/ANN-JNIPort-for-Pharo-3-0-alpha-tp4750750.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
y Pharo code is equivalent to "Pharo become: nil". :-)
Best regards,
Joachim Geidel
--
View this message in context:
http://forum.world.st/NativeBoost-callbacks-from-different-threads-tp4740997.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
18 matches
Mail list logo