April 2014 - Pharo-users - lists.pharo.org

free learnig book

by Roelof Wobben

Hello, I wonder if there is a free book with a lot of exercises so I can practice and learn a lot about Smalltalk. Roelof

April 7, 2014

Re: [Pharo-users] changes and sources file availability

by Pharo4Stef

You should send a fix so that we can control the message to show up or not. Damien did a lot of clean to make sure that we can run Pharo in a readyonly folder but there are more cases probably to handle. Stef On 06 Apr 2014, at 14:16, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > You can remove the .source file as well, but you will have a warning > message as in this screenshot. It is pretty easy to hack the system to > prevent it however. > > > Hilaire > > Le 06/04/2014 12:34, Usman Bhatti a Ã©crit : >> My use case is to prevent access to the source code in the image as much >> as possible. >> >> For changes file, I found this: >> PharoFilesOpener >>shouldInformAboutReadOnlyChanges. >> >> For sources, no idea. But it would be good to remove the Pharo sources >> as well because that's not really needed. >> > > -- > Dr. Geo http://drgeo.eu > <WarningNoSource.jpg>

April 6, 2014

Re: [Pharo-users] changes and sources file availability

by Hilaire Fernandes

You can remove the .source file as well, but you will have a warning message as in this screenshot. It is pretty easy to hack the system to prevent it however. Hilaire Le 06/04/2014 12:34, Usman Bhatti a Ã©crit : > My use case is to prevent access to the source code in the image as much > as possible. > > For changes file, I found this: > PharoFilesOpener >>shouldInformAboutReadOnlyChanges. > > For sources, no idea. But it would be good to remove the Pharo sources > as well because that's not really needed. > -- Dr. Geo http://drgeo.eu

April 6, 2014

Re: [Pharo-users] changes and sources file availability

by Usman Bhatti

Hi, Tx for your replies. On Fri, Apr 4, 2014 at 10:09 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 03 Apr 2014, at 19:05, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> > wrote: > > > Hi, > > > > It is gone. And for me it is a very annoying. > > > > Now if you want the system to prevent looking I am afraid you have to > > modify some system class method as there is no more hook to do it > > properly (see the mailing list archive for discussion about that a few > > weeks ago). Then I don't know the consequence of Pharo3 running without > > the source files. Some feedback will be nice on that specific point. > > > > So... yes, right now there are no Preferences. But we can add them back. > (I can do that). > The only thin that will (right now) not work is decompiling, but just > running > a program is fine. If you want to debug you need sources+changes. > > My use case is to prevent access to the source code in the image as much as possible. For changes file, I found this: PharoFilesOpener >>shouldInformAboutReadOnlyChanges. For sources, no idea. But it would be good to remove the Pharo sources as well because that's not really needed. regards, Usman This is not nice and we will fix that with Pharo4. > > > I guess this situation can evolve in future. > > > Yes! > > Marcus >

April 6, 2014

Re: [Pharo-users] [ANN] JNIPort for Pharo 3.0 alpha

by Pharo4Stef

On 05 Apr 2014, at 23:35, Joachim Geidel <joachim.geidel(a)onlinehome.de> wrote: > 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: is *very* slow in Pharo. No problem at all in VisualWorks or Dolphin Smalltalk or Pharo 1.2, though! > > Time millisecondsToRun: [1000 timesRepeat: [String new become: String new ]] > > Pharo 3.0 (and also in 2.0 and 1.4): > 3948 3495 2891 2532 3162 > > Pharo 1.2 with the Squeak 4.2.5beta1U VM: > 90 89 82 90 72 these numbers are strange. Because mariano used a lot become: and he did not report a factor like that. Thanks for reporting them. > > VisualWorks 7.9.1: note that this is measured in microseconds: > Time microsecondsToRun: [1000 timesRepeat: [String new become: String new ]] > 211 208 222 212 208 this will be fixed with spur and body. > > Thatâs a factor of more than 10.000! IMHO, someone should have a look at the primitives involved. > >> also, by tracking senders of #knownJavaSubclasses , i see there's also uses of #become operation.. >> >> So, my first verdict is: >> - excessive use of #become ==> slow performance >> :) >> >> (sure, i have no idea if you can avoid using become or not, but my bet this is main reason of low performance) > > Well, given the measurements above, I wouldnât say that the reason is excessive use of #become:, but the extremely slow implementation of #become: in Pharo since 1.4. However, I managed to remove the need for sending #become: in #findClassFor:, but not in the second place. This reduces the time to start a Java VM to 5-6 seconds on my aged machine (2.4 GHz Intel Core 2 Duo from early 2008). The benchmark which I mentioned in my announcement and which took 12 seconds came down to less than 0.2 seconds. That's a little more than the 0.11 seconds in VisualWorks, but at least in the same order of magnitude. > > Thanks again! > Joachim > >

April 6, 2014

Re: [Pharo-users] [ANN] JNIPort for Pharo 3.0 alpha

by Joachim Geidel

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: is *very* slow in Pharo. No problem at all in VisualWorks or Dolphin Smalltalk or Pharo 1.2, though! Time millisecondsToRun: [1000 timesRepeat: [String new become: String new ]] Pharo 3.0 (and also in 2.0 and 1.4): 3948 3495 2891 2532 3162 Pharo 1.2 with the Squeak 4.2.5beta1U VM: 90 89 82 90 72 VisualWorks 7.9.1: note that this is measured in microseconds: Time microsecondsToRun: [1000 timesRepeat: [String new become: String new ]] 211 208 222 212 208 Thatâs a factor of more than 10.000! IMHO, someone should have a look at the primitives involved. > also, by tracking senders of #knownJavaSubclasses , i see there's also uses of #become operation.. > > So, my first verdict is: > - excessive use of #become ==> slow performance > :) > > (sure, i have no idea if you can avoid using become or not, but my bet this is main reason of low performance) Well, given the measurements above, I wouldnât say that the reason is excessive use of #become:, but the extremely slow implementation of #become: in Pharo since 1.4. However, I managed to remove the need for sending #become: in #findClassFor:, but not in the second place. This reduces the time to start a Java VM to 5-6 seconds on my aged machine (2.4 GHz Intel Core 2 Duo from early 2008). The benchmark which I mentioned in my announcement and which took 12 seconds came down to less than 0.2 seconds. That's a little more than the 0.11 seconds in VisualWorks, but at least in the same order of magnitude. Thanks again! Joachim

April 5, 2014

Re: [Pharo-users] [ANN] JNIPort for Pharo 3.0 alpha

by Pharo4Stef

Joachim would you be interested to write a little Chpater for the Pharo for the entreprise book? I can help. Ste On 05 Apr 2014, at 14:32, Joachim Geidel <joachim.geidel(a)onlinehome.de> wrote: > Am 31.03.2014 um 21:25 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >> 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(JavaClassTargetInterface target) { target.m() } >> - In Pharo we create PharoClassTargetImplementation as an implementation of JavaClassTargetInterface >> - passing an instance of PharoClassTargetImplementation to JavaClassOriginator results in calling PharoClassTargetImplementation>>m >> >> ? >> >> >> Cheers, >> Doru > > Hi Doru, > > itâs not completely straightforward, but also not really complicated. Chris Uppalâs JNIPort documentation contains examples, and you can also get some information from the test cases for callbacks. You will need the jniport.jar file which can be downloaded from http://jniport.wikispaces.com/Downloads (it is contained in JNIPort_Extras.zip). The Java classes needed for callback support have names starting with âDolphinâ - they come directly from Chrisâ implementation for Dolphin Smalltalk. > > A simple example: To set up sending a simple notification without parameters to a Smalltalk object, you need a Java class similar to the following: > > ----------------- > package my.package; > import org.metagnostic.jniport.*; > public class MyClass > { > private static final Object notifyTag = new String("MyClass.sendNotification()â); > public static Object notifyTag () { return notifyTag; } > public void sendNotification() > throws RequestNotHandedException > { > new DolphinNotification(notifyTag, this).send(); > } > } > ----------------- > > You have to install the callback in Smalltalk: > > ----------------- > NotificationHandler := â¦ "the object which receives the notifications" > classStatic := jvm findClass: 'my.package.MyClass'. > jvm callbackRegistry > setCallback: classStatic notifyTag "the tag can be an arbitrary String" > handler: [:this :param | NotificationHandler handleNotificationFor: this]. > ----------------- > > When you send sendNotification() to an instance of MyClass, NotificationHandler should receive the message #handleNotificationFor:. > > In the example code, the tag is a static variable in MyClass. Of course, you can also give every instance of MyClass its own tag. In this case, you have to set up a callback in Smalltalk for every tag which is used. > > The example is a short version of the test code for handling notifications in JNIPortCallbackNotificationsTest and the corresponding Java class org.metagnostic.jniport.test.regression.Notifications. The source code of this Java class is in the archive JNIPort-Tests.zip which is contained in JNIPort_Extras.zip. > > If you need an example for a notification which has parameters and where the Smalltalk code returns a result, have a look at JNIPortCallbackRequestsTest>>testCallbackWithOneParameterAndReturn and the corresponding Java class org.metagnostic.jniport.test.regression.Callbacks. > > In the Java class, you need something like this (copied from Callbacks and simplified) which enables a callback taking an int parameter and returning an instance of the Java class Integer: > > private static final Object callbackTag = new String(âcallback with parameters"), > > // callback with return value > public int callbackAndReturn(int i) > throws Throwable > { > Object returnValue = new DolphinRequest(callbackTag, this, i).value(); > return ((Integer) returnValue).intValue(); > } > > A DolphinRequest is created with the tag which identifies the callback in Smalltalk, the object sending the callback (this), and an arbitrary number of parameters. For example, the following creates a DolphinRequest with two parameters: > > DolphinRequest dr = new DolphinRequest( > s_callbackTag, > this, > new Integer(i), > new Double(d)); > > Calling the value() method of the DolphinRequest sends the request to VisualWorks and returns the result of the Smalltalk callback block. > > In Smalltalk, you can create callbacks accepting parameters like this (see JNIPortCallbackRequestsTest): > > "No parameters" > jvm callbackRegistry setCallback: classStatic callbackTag > handler: [:this :param | self handleCallbackFor: this]. > > "One parameter" > jvm callbackRegistry setCallback: classStatic callbackTag > handler: [:this :param | self handleCallbackFor: this with: param]. > > "Arbitrary number of parameters" > jvm callbackRegistry setCallback: classStatic callbackTag > handler: [:this :params | self handleCallbackFor: this withArguments: params asArray]. > > If the callback has a result which should be passed from Smalltalk to Java, it must be a Java object. Here is an example from the test class (callbacksStatus is just an instance variable of JNIPortCallbackRequestsTest): > > handleCallbackFor: aJavaObject with: anotherJavaObject > > | jliClass | > > jliClass := jvm findClass: #'java.lang.Integer'. > > callbacksStatus addLast: (aJavaObject = instance). "identity test on the Java object" > callbacksStatus addLast: ((anotherJavaObject static = jliClass) and: [anotherJavaObject intValue = 1]). > > ^ jliClass new_int: 15. "Do not return a Smalltalk Integer. It must be a Java Integerâ > > Johan Brichauâs JavaConnect had a more direct way of creating callbacks, using Javaâs dynamic proxies. However, it had an open issue, as it relied on different Java objects having different identity hashes, which is not true in all cases. JNIPortâs implementation is relatively complicated because it had to take into account that the callbacks can be triggered from a different thread than the Smalltalk thread. In VisualWorks, thatâs not a problem, as the VM handles this, and Pharo simply does not support callbacks from foreign threads. So, it could be simplified in JNIPort as well. > > Does this help? > Joachim > >

April 5, 2014

[ANN] WIP iStoa

by Hilaire Fernandes

Hello, For those who want to give a try to work in progress iStoa on Linux, an Interactive math exercises book. https://launchpad.net/istoa/alpha/14.04/+download/iStoa.app-14.04a.zip Hilaire -- Dr. Geo http://drgeo.eu

April 5, 2014

Re: [Pharo-users] [ANN] JNIPort for Pharo 3.0 alpha

by Igor Stasenko

On 25 March 2014 19:59, Joachim Geidel <joachim.geidel(a)onlinehome.de> wrote: > Hi everybody, > > JNIPort for Pharo 3.0 alpha is now available at SmalltalkHub. > > JNIPort is a Smalltalk library which allows Java code to be invoked from > Smalltalk. It acts as a bridge between the world of Smalltalk objects and a > Java Virtual Machine (JVM) where Java code is executing. > > When I first ported JNIPort to Squeak and Pharo 1.x, I used Alien as the > FFI > library. As NativeBoost has superseded Alien, the interface to the Java > Native Interface library had to be rewritten. There are still some > undocumented and obscure parts in NativeBoost, so this has taken some time. > > If you want to try it, load it via the ConfigurationOfJNIPort. I hope this > works. If it does not, load the packages individually in the order in which > they appear in the ConfigurationOfJNIPort. > http://www.smalltalkhub.com/#!/~JNIPort/JNIPort > The next step is to read the documentation at > http://jniport.wikispaces.com/ > Otherwise, you won't know what to do next. ;-) > Download the extra files from the download page at Wikispaces, you will > need > two jar files from there. > > Start a Java VM attached to Pharo by adapting and executing the following > code snippet: > > ---- > | jvmSettings | > "You can set the path to the Java VM library by editing the path as > needed." > JNIPortJNIInterface libraryFile: > > '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib' > . > "JNIPortJNIInterface libraryFile: > 'C:\Programme\Java\jre7\bin\client\jvm.dll' ." > > jvmSettings := JVMSettings new. > jvmSettings usesGhosts: true. > jvmSettings supportsCallbacks: true. > jvmSettings jniPortSettings useJNIHelperLibrary: false. > jvmSettings ghostClassSettings retainMethodSource: true. > > "On Mac OS X and Linux, class path entries are separated by colons." > "On Windows, you have to use semicolons instead. Edit the following line > as > needed." > jvmSettings runtimeSettings classpath: > '.:/Users/myname/JNIPort.jar:/Users/myname/JNIPort-Tests.jar'. > " jvmSettings runtimeSettings classpath: > '.;.\JNIPort.jar;.\JNIPort-Tests.jar'." > > "Uncomment the following if you want the Java VM to emit verbose messages. > How to access these messages depends on your platform. > On Mac OS X, they are visible in the Console application." > "jvmSettings runtimeSettings addOption: '-verbose:jni'; addOption: > '-verbose:gc'; addOption: '-verbose:class'." > Cursor execute showWhile: [JVM newWithSettings: jvmSettings]. > ---- > > Then the fun starts: > > ---- > | zfClass zipfile entries | > zfClass := JVM current findClass: #'java.util.zip.ZipFile'. > zipfile := zfClass new_String: 'JNIPort.jar'. > zipfile size. "--> answers an Integer" > entries := zipfile entries. > entries asAnEnumeration do: [:each | Transcript cr; print: each]. > ---- > > And now to the ugly little secret reason why I call it an alpha version: > > While everything seems to work, it is *much* slower than it used to be in > Pharo 1.2 with Alien. And when I compare it with VisualWorks, I wonder if > the Pharo version secretly does some additional work for SETI: > - Starting the JVM: > VisualWorks 0.7 seconds > Pharo 7 to 8 seconds > - A benchmark using some methods of java.io.BufferedReader and > java.util.StringTokenizer: > VisualWorks 114 milliseconds > Pharo 12 to 13 seconds > > profiled a bit.. this: =================== | jvmSettings | "You can set the path to the Java VM library by editing the path as needed." JNIPortJNIInterface libraryFile: '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Libraries/libclient.dylib' . "JNIPortJNIInterface libraryFile: 'C:\Programme\Java\jre7\bin\client\jvm.dll' ." jvmSettings := JVMSettings new. jvmSettings usesGhosts: true. jvmSettings supportsCallbacks: true. jvmSettings jniPortSettings useJNIHelperLibrary: false. jvmSettings ghostClassSettings retainMethodSource: true. JVM newWithSettings: jvmSettings ============== and got this: **Leaves** 22.8% {925ms} StaticJavaLangClassLoader(JavaStatic)>>knownJavaSubclasses 19.9% {804ms} JVMWithCallbacks(JVM)>>findClassFor: 5.9% {240ms} OrderedCollection>>do: 5.1% {206ms} Metaclass(Behavior)>>registerLocalSelector: 3.0% {120ms} JNIPortJNIEnv>>return:onException: 2.2% {91ms} CompiledMethod>>methodClass: 2.2% {88ms} OrderedCollection>>add: 2.1% {84ms} Array(SequenceableCollection)>>do: 2.0% {81ms} WordArray class(Behavior)>>new: 2.0% {79ms} WeakArray class>>finalizationProcess 1.3% {52ms} JNIPortJNIInterfaceForMacOSX(JNIPortJNIInterface)>>checkReturnCode: 1.1% {46ms} Heap>>updateObjectIndex: ------------- findClassFor: aJNIObject "private -- find/make the JavaStatic that will wrap aJNIObject" "we have to ensure that the ref is converted to global if necessary *before* the class lookup, since that might take considerable time during which callbacks might happen (especially if new ghost classes have to be constructed). Hence we convert it now, even though we will 'convert' again later (in #own:)" "NB: this will #become: the JNIObject into a global ref if necessary" self convertToGlobal: aJNIObject. ^ super findClassFor: aJNIObject. ---------- so, without going deep into implementation details, just by reading comment i can already see potential bottleneck - using #become: operation which is veery slow. also, by tracking senders of #knownJavaSubclasses , i see there's also uses of #become operation.. So, my first verdict is: - excessive use of #become ==> slow performance :) (sure, i have no idea if you can avoid using become or not, but my bet this is main reason of low performance) -- Best regards, Igor Stasenko.

April 5, 2014

Re: [Pharo-users] [ANN] JNIPort for Pharo 3.0 alpha

by Joachim Geidel

Am 31.03.2014 um 21:25 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > 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(JavaClassTargetInterface target) { target.m() } > - In Pharo we create PharoClassTargetImplementation as an implementation of JavaClassTargetInterface > - passing an instance of PharoClassTargetImplementation to JavaClassOriginator results in calling PharoClassTargetImplementation>>m > > ? > > > Cheers, > Doru Hi Doru, itâs not completely straightforward, but also not really complicated. Chris Uppalâs JNIPort documentation contains examples, and you can also get some information from the test cases for callbacks. You will need the jniport.jar file which can be downloaded from http://jniport.wikispaces.com/Downloads (it is contained in JNIPort_Extras.zip). The Java classes needed for callback support have names starting with âDolphinâ - they come directly from Chrisâ implementation for Dolphin Smalltalk. A simple example: To set up sending a simple notification without parameters to a Smalltalk object, you need a Java class similar to the following: ----------------- package my.package; import org.metagnostic.jniport.*; public class MyClass { private static final Object notifyTag = new String("MyClass.sendNotification()â); public static Object notifyTag () { return notifyTag; } public void sendNotification() throws RequestNotHandedException { new DolphinNotification(notifyTag, this).send(); } } ----------------- You have to install the callback in Smalltalk: ----------------- NotificationHandler := â¦ "the object which receives the notifications" classStatic := jvm findClass: 'my.package.MyClass'. jvm callbackRegistry setCallback: classStatic notifyTag "the tag can be an arbitrary String" handler: [:this :param | NotificationHandler handleNotificationFor: this]. ----------------- When you send sendNotification() to an instance of MyClass, NotificationHandler should receive the message #handleNotificationFor:. In the example code, the tag is a static variable in MyClass. Of course, you can also give every instance of MyClass its own tag. In this case, you have to set up a callback in Smalltalk for every tag which is used. The example is a short version of the test code for handling notifications in JNIPortCallbackNotificationsTest and the corresponding Java class org.metagnostic.jniport.test.regression.Notifications. The source code of this Java class is in the archive JNIPort-Tests.zip which is contained in JNIPort_Extras.zip. If you need an example for a notification which has parameters and where the Smalltalk code returns a result, have a look at JNIPortCallbackRequestsTest>>testCallbackWithOneParameterAndReturn and the corresponding Java class org.metagnostic.jniport.test.regression.Callbacks. In the Java class, you need something like this (copied from Callbacks and simplified) which enables a callback taking an int parameter and returning an instance of the Java class Integer: private static final Object callbackTag = new String(âcallback with parameters"), // callback with return value public int callbackAndReturn(int i) throws Throwable { Object returnValue = new DolphinRequest(callbackTag, this, i).value(); return ((Integer) returnValue).intValue(); } A DolphinRequest is created with the tag which identifies the callback in Smalltalk, the object sending the callback (this), and an arbitrary number of parameters. For example, the following creates a DolphinRequest with two parameters: DolphinRequest dr = new DolphinRequest( s_callbackTag, this, new Integer(i), new Double(d)); Calling the value() method of the DolphinRequest sends the request to VisualWorks and returns the result of the Smalltalk callback block. In Smalltalk, you can create callbacks accepting parameters like this (see JNIPortCallbackRequestsTest): "No parameters" jvm callbackRegistry setCallback: classStatic callbackTag handler: [:this :param | self handleCallbackFor: this]. "One parameter" jvm callbackRegistry setCallback: classStatic callbackTag handler: [:this :param | self handleCallbackFor: this with: param]. "Arbitrary number of parameters" jvm callbackRegistry setCallback: classStatic callbackTag handler: [:this :params | self handleCallbackFor: this withArguments: params asArray]. If the callback has a result which should be passed from Smalltalk to Java, it must be a Java object. Here is an example from the test class (callbacksStatus is just an instance variable of JNIPortCallbackRequestsTest): handleCallbackFor: aJavaObject with: anotherJavaObject | jliClass | jliClass := jvm findClass: #'java.lang.Integer'. callbacksStatus addLast: (aJavaObject = instance). "identity test on the Java object" callbacksStatus addLast: ((anotherJavaObject static = jliClass) and: [anotherJavaObject intValue = 1]). ^ jliClass new_int: 15. "Do not return a Smalltalk Integer. It must be a Java Integerâ Johan Brichauâs JavaConnect had a more direct way of creating callbacks, using Javaâs dynamic proxies. However, it had an open issue, as it relied on different Java objects having different identity hashes, which is not true in all cases. JNIPortâs implementation is relatively complicated because it had to take into account that the callbacks can be triggered from a different thread than the Smalltalk thread. In VisualWorks, thatâs not a problem, as the VM handles this, and Pharo simply does not support callbacks from foreign threads. So, it could be simplified in JNIPort as well. Does this help? Joachim

April 5, 2014