- Pharo-users - lists.pharo.org

Seeking help on morphs : expander and scrolls

by Jigyasa Grover

Hi I am using Expander Morphs to display some search results. I am finding it hard to insert a scroll bar in text displayed after expanding the title of the search result. The corresponding code snippet is as: *dialog newRow: {* *(* * (* * dialog newExpander: r title asString* * forAll: { dialog newText: r content asString . }* * )minWidth:600; minHeight: 10* *)cellInset: 0;* * borderStyle: (BorderStyle inset baseColor: dialog paneColor; width: 1)* * } * I basically need to add a scroll-able content in '*newText*:' portion. The entire code of my application an offline text search application namely searchQuick is available at github (https://github.com/jig08/sQuick_new) . You all are welcome to fork the code , try the infancy application and send in suggestions. Help Appreciated. Regards Jigyasa

July 17, 2015

Re: [Pharo-users] troubles with JNIPort on Pharo 5 / Java 8

by 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 -- View this message in context: http://forum.world.st/troubles-with-JNIPort-on-Pharo-5-Java-8-tp4836922p483… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 17, 2015

Re: [Pharo-users] NativeBoost and OpenMP

by stepharo

I blogged about you :) Le 16/7/15 19:18, Matthieu Lacaton a Ã©crit : > Hello, > > I haven't really seen anything related to this on the Internet and > maybe some people will find it cool so I just wanted to report one > thing I found out today : > > NativeBoost works great with OpenMP ! > > I wrote a C function twice, once with openMP and once without. I made > 32 bits libraries and used them from inside Pharo with NativeBoost. > > When using the non - openMP library, only one core was used but when > using the openMP library, both my cores were used and the time it took > to run was really divided by (a little bit less than) 2 ! > > That's just me but i find it really cool :p > > Cheers, > > Matthieu > > > >

July 17, 2015

Re: [Pharo-users] NativeBoost and OpenMP

by Ben Coman

Very cool. Nice to hear you're having fun. cheers -ben On Fri, Jul 17, 2015 at 1:18 AM, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > Hello, > > I haven't really seen anything related to this on the Internet and maybe > some people will find it cool so I just wanted to report one thing I found > out today : > > NativeBoost works great with OpenMP ! > > I wrote a C function twice, once with openMP and once without. I made 32 > bits libraries and used them from inside Pharo with NativeBoost. > > When using the non - openMP library, only one core was used but when using > the openMP library, both my cores were used and the time it took to run was > really divided by (a little bit less than) 2 ! > > That's just me but i find it really cool :p > > Cheers, > > Matthieu > > > >

July 17, 2015

Re: [Pharo-users] Pharo Success story - MultiCity

by Norbert Hartl

> Am 16.07.2015 um 18:14 schrieb "phil(a)highoctane.be" <phil(a)highoctane.be>: > > > Le 16 juil. 2015 15:07, "Norbert Hartl" <norbert(a)hartl.name> a Ã©crit : > > > > > >> Am 16.07.2015 um 12:59 schrieb phil(a)highoctane.be: > >> > >> One question about Mongo. > >> > >> How do you handle HA (High Availability) in Pharo? > >> > > I don't. > > > >> The current driver (MongoTalk) connects to one single mongod. > >> > >> I haven't seen any support for replicasets and identifying who is the mongod to write to in MongoTalk (this support is built in any Python, Ruby, ... driver they do provide, including sharding support and GridFS). > >> > > As far as I know there is no support for all of these. It would be really good to have them. But if nobody contributes it may be not needed after all. > > Working - slowly - on it. > Great! I'd like to see support for this. If you have anything commit it. Or ask. I'll be happy to assist. Norbert > > > > >> Also, I've been experiencing a couple of protocol errors when working with mongod under some scenarios (unrecognized command coming back in the wire protocol). Looks like MongoTalk and mongod were out of sync on the wire protocol. > >> > > You need to be careful because the mongo connection is a single stream aligned request by request. If another thread writes on the stream at the same time you will experience what you call "out of sync". > > Not such issue in the current code AFAIK but will look closer. > > > > > Norbert > > > >> Thanks and kudos for one more nice application! > >> > >> Phil > >> > >> > >> On Thu, Jul 16, 2015 at 12:36 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >>> > >>> Hi Torsten, > >>> > >>> > Am 15.07.2015 um 22:51 schrieb Torsten Bergmann <astares(a)gmx.de>: > >>> > > >>> > Another story from 2Denker is up: http://pharo.org/success/MultiCity > >>> > > >>> > Client seems to be done using Amber when I check the login page which was > >>> > styled with Bootstrap. Server in Pharo with Nginx. I guess you use Mongo as > >>> > DB (with Voyage or without). > >>> > > >>> > @Norbert/@Marcus: if possible can you share with us a few more technical details about > >>> > the technologies/stack used. Also about size (LOC, users, nr of images) > >>> > and pitfalls ... > >>> > > >>> > There is always something one can learn from the experience of others. > >>> > >>> sure I can give some insight in the project. > >>> > >>> For the admin client we use amber plus bootstrap. The backend for this is a pharo image with voyage. As you can see in the screenshot there is a geo location entered. That can be searched afterwards because mongo provides geo spatial indexes. > >>> > >>> The project is built upon a service we provide at 2denker. The service is a registry for app installations, users and message tokens. We provide libraries for ios, android and windows mobile that registers the app, assigns a user, requests a message token from the user and stores it. The service is used for notifying the user at return of the car. You then get a notification containing the time and price of your car rental. > >>> > >>> The architecture of our infrastructure is event based. Meaning that e.g. the installation registration service sends events to a central event bus like image. This stores the events in elasticsearch and provides the ability to register for events. > >>> > >>> What we had to do for this project? We've built an image that on the one hand serves the request of the client admin interface. On the other hand it registers at the event server for a certain kind of event. This event is triggered by the car return and piggybacks the geo location where the car has been left. When such an event travels through our system the event server sees a match and calls the image. The image extracts the geo information and searches the database for available advertisements. If one is found and conditions are met an additional message is sent. > >>> > >>> That's roughly it. In the whole process there are 8 pharo images involved but 2 are for redundancy so it is 6 different images. The rest is a mongo database and an elasticsearch database. If you want to know anything more don't hesitate to ask. > >>> > >>> Norbert > >>> > >>> > >>> > >> > >

July 17, 2015

Re: [Pharo-users] Pharo Success story - MultiCity

by Norbert Hartl

> Am 16.07.2015 um 21:24 schrieb Paul DeBruicker <pdebruic(a)gmail.com>: > > Are you using SMS at all? > Yes, we do use sms. One of our services is to reduce prices on messaging through message routing. As we know who can receive a push notification and who does not we can reach all users sending smses only for those who cannot. But in this particular project it is notification only. Norbert > > > > NorbertHartl wrote >>> Am 16.07.2015 um 12:36 schrieb Norbert Hartl < > >> norbert@ > >> >: >>> >>> That's roughly it. In the whole process there are 8 pharo images involved >>> but 2 are for redundancy so it is 6 different images. >> >> To clarify on that. There are two images load balanced for the registry >> services. Two load balanced for the event stuff. Each one for sending >> apple push notifications, google cloud messages and windows messages. And >> there is a single image for this project. >> >> Norbert > > > > > > -- > View this message in context: http://forum.world.st/Pharo-Success-story-MultiCity-tp4837716p4837880.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

July 17, 2015

Re: [Pharo-users] Pharo Success story - MultiCity

by Paul DeBruicker

Are you using SMS at all? NorbertHartl wrote >> Am 16.07.2015 um 12:36 schrieb Norbert Hartl < > norbert@ > >: >> >> That's roughly it. In the whole process there are 8 pharo images involved >> but 2 are for redundancy so it is 6 different images. > > To clarify on that. There are two images load balanced for the registry > services. Two load balanced for the event stuff. Each one for sending > apple push notifications, google cloud messages and windows messages. And > there is a single image for this project. > > Norbert -- View this message in context: http://forum.world.st/Pharo-Success-story-MultiCity-tp4837716p4837880.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 16, 2015

Re: [Pharo-users] NativeBoost and variadic functions

by Ben Coman

On Fri, Jul 17, 2015 at 12:23 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 15 July 2015 at 16:35, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Wed, Jul 15, 2015 at 5:16 PM, Matthieu Lacaton >> <matthieu.lacaton(a)gmail.com> wrote: >> > Hello Igor, >> > >> > Thanks for your answer. >> > >> > I implemented something like that for the printf function: >> > Basically, it generates a method with matching arguments and executes >> > it. >> > >> >> printf: stringFormat args: tab >> >> >> >> | argNumber functionArgs functionPrototype methodCorpse >> >> methodSelector >> >> argsArray | >> >> >> >> ((tab size % 2) = 0) ifFalse: [ >> >> Transcript show: 'error'. >> >> ^self. >> >> ]. >> >> >> >> argNumber := 0. >> >> functionPrototype := 'printf: stringFormat'. >> >> functionArgs := ''. >> >> methodCorpse := ''. >> >> argsArray := (Array new: (tab size / 2) + 1). >> >> argsArray at: 1 put: stringFormat. >> >> >> >> 1 to: tab size by: 2 do: [ :i | >> >> functionPrototype := functionPrototype, ' arg', argNumber >> >> asString, ': ', (tab at: i) asString, argNumber asString. >> >> functionArgs := functionArgs, ' ', (tab at: i) asString, ' ', >> >> (tab >> >> at: i) asString, argNumber asString, ','. >> >> argsArray at: argNumber + 2 put: (tab at: i + 1). >> >> argNumber := argNumber + 1. >> >> ]. >> >> functionArgs := functionArgs allButLast. >> >> >> >> methodCorpse := functionPrototype, Character cr asString, ' >> >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin>', >> >> Character cr >> >> asString, Character cr asString, ' ^self nbCall: #( void printf ( >> >> String >> >> stringFormat,', functionArgs asString, ' ) )', Character cr asString, ' >> >> module: NativeBoost CLibrary'. >> >> >> >> methodSelector := self class compile: methodCorpse. >> >> >> >> self perform: methodSelector withArguments: argsArray. >> > >> > >> > >> > Then you can call it like that : >> > >> > MyClass printf: 'Test of printf. String: %s, Int : %d, Long: %ld, Char: >> > %c, >> > Double: %lf' args: { 'String'. 'This is a string'. 'int'. 100. 'long'. >> > 10000000. 'char'. 89. 'double'. 3.14159 }. >> > >> > >> > I also tried it for some other variadic functions and, on my computer (I >> > am >> > running archlinux), it seemed to work for every type of argument except >> > "float". >> >> >> Maybe NativeBoost does not do implicit type conversions that a C >> compiler would do? > > > It does not. > But that's not an issue. The philosophy behind NB was to require from user > explicit information about what types to use and how. > The main reason behind that, is that the more explicit and detailed > information you got at compilation time (in case of NB - code generation) , > the more simple and efficient generated code will be. > In general, you don't want to generate trains of machine code to handle > 1000+ of cases for converting a single argument (and then repeat the same > for next function argument). It makes things slow and inefficient, not > speaking that generated code also takes memory space. > I don't want to make code generation too smart, and this is why i trying to > avoid any implicitness: because else it makes users wonder why something > works and something don't and he have no idea, because of tons and tons of > contradicting implicit rules hidden behind the scenes. > > And let me remind you that despite that NB implements FFI to speak with C, > it is not obliged to implement features of C language itself. It lets you > speak with C programs, but not lets you write programs like in C (see the > difference? :) I wasn't implying that implicit type conversion was a good thing that needed implementing -- but just a bump if it hadn't needed attention to it before when C did it automagically. cheers -ben > >> [1] "Because C will promote floats to doubles for functions that take >> variable arguments" >> >> More info search [2] for: >> * "implicit type conversion" >> * "guess wrongly when the program uses floating-point formats in >> scanf() or printf()" >> >> [1] >> http://stackoverflow.com/questions/210590/why-does-scanf-need-lf-for-double… >> >> [2] http://www.electroons.com/8051/ebooks/expert%20C%20programming.pdf >> >> cheers -ben >> >> >> > It works fine for "double" though. >> > For "char" you need to pass the integer ASCII value directly for it to >> > work. >> > I tried with "Character value: xxx" but it didn't work. >> > >> > I know that this is very hackish and very bad, and I am aware it has >> > some >> > drawbacks. Moreover I am not even sure it will work everytime. >> > But for now it seems to work ... >> > >> > 2015-07-13 19:24 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >> >> >> >> >> >> >> >> On 10 July 2015 at 10:18, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> >> >> >> wrote: >> >>> >> >>> Hello, >> >>> >> >>> Is it possible with NativeBoost to create a binding for a variadic >> >>> function ? >> >>> >> >>> I've seen the printf example in NBCPrinter but this implementation is >> >>> kind of cheating since it always pass just a %s as format and one >> >>> already >> >>> formatted string to the C function. >> >>> >> >>> I've written a simple variadic function which adds every integer it >> >>> receives as argument (first argument is for the number of following >> >>> arguments) : >> >>> >> >>> int add(int number,...); >> >>> >> >>> In Pharo I've tried something like this : >> >>> >> >>>> add: number arg1: first arg2: second >> >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> >>>> >> >>>> ^ self nbCall: #( int add (int number, int first, int second)) >> >>>> module: 'libMyLib.so' >> >>> >> >>> >> >>> and it works fine with two arguments. >> >>> >> >>> Basically, doing so, I would need one method per number of arguments >> >>> so >> >>> it's not very cool. >> >>> >> >>> I thought that maybe I could pass an array as argument to my Pharo >> >>> method >> >>> but I didn't really find a way to figure out how to define the nbCall >> >>> without having a "Generic failure". >> >>> >> >>>> add: number args: anArray >> >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> >>>> >> >>>> ^ self nbCall: #( int add (int number, ??? anArray)) >> >>>> module: 'libMyLib.so' >> >>> >> >>> >> >>> Do you have an idea ? >> >>> >> >> >> >> In short, there's no marshaller for converting an array of items, to >> >> same >> >> number of things on stack. That could solve the problem with your >> >> example: >> >> passing array of objects of *same* type. But in general, it is not what >> >> C >> >> variadic function(s) standing for. Because they stand for any number of >> >> arguments, of any type. >> >> In C, since all program is compiled statically, compiler knows the >> >> number >> >> of passed arguments and their types through compiling each particular >> >> call >> >> site(s) to variadic function. Which means that in fact, you are still >> >> supplying all information needed by compiler *before* run time. >> >> >> >> In variadic functions, you can pass any arguments of any type, >> >> but for converting each of them, you must tell NB what kind of >> >> marshaller >> >> should be used for it , which means, that it is impossible to know >> >> before >> >> run time, since you cannot know how many arguments you may pass, not >> >> speaking about their types.

July 16, 2015

NativeBoost and OpenMP

by Matthieu Lacaton

Hello, I haven't really seen anything related to this on the Internet and maybe some people will find it cool so I just wanted to report one thing I found out today : NativeBoost works great with OpenMP ! I wrote a C function twice, once with openMP and once without. I made 32 bits libraries and used them from inside Pharo with NativeBoost. When using the non - openMP library, only one core was used but when using the openMP library, both my cores were used and the time it took to run was really divided by (a little bit less than) 2 ! That's just me but i find it really cool :p Cheers, Matthieu

July 16, 2015

Re: [Pharo-users] NativeBoost and variadic functions

by Matthieu Lacaton

> > Oh man... > and why would anyone may want to use this? :) > > Sure you can do whatever it takes to implement a feature you want so badly, > but hey.. > If something that takes so much effort and so inefficient as result, would > you consider abandon the idea and use something else instead? :) > Because it is straightly against the philosophy of NB: be fast and > explicit. > And you seem to be in favor of implicitness. > Well, nevertheless, it is a honorable goal, so good luck :) You are right. Actually it was just a workaround to see if I could bypass some of the "limitations" but it is definitely too ugly and inefficient to be useful. The C code will be changed to fit Pharo and that will do the trick. And let me remind you that despite that NB implements FFI to speak with C, > it is not obliged to implement features of C language itself. It lets you > speak with C programs, but not lets you write programs like in C (see the > difference? :) > You are definitely right once again. I noticed today that lately I was writing more C-ish code in Pharo than Smalltalk-ish code... But I really like NativeBoost :( 2015-07-16 18:33 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > > > On 15 July 2015 at 11:16, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> > wrote: > >> Hello Igor, >> >> Thanks for your answer. >> >> I implemented something like that for the printf function: >> Basically, it generates a method with matching arguments and executes it. >> >> *printf:* stringFormat *args:* tab >>> >>> | argNumber functionArgs functionPrototype methodCorpse >>> methodSelector argsArray | >>> >>> ((tab size % 2) = 0) ifFalse: [ >>> Transcript show: 'error'. >>> ^self. >>> ]. >>> >>> argNumber := 0. >>> functionPrototype := 'printf: stringFormat'. >>> functionArgs := ''. >>> methodCorpse := ''. >>> argsArray := (Array new: (tab size / 2) + 1). >>> argsArray at: 1 put: stringFormat. >>> >>> 1 to: tab size by: 2 do: [ :i | >>> functionPrototype := functionPrototype, ' arg', argNumber >>> asString, ': ', (tab at: i) asString, argNumber asString. >>> functionArgs := functionArgs, ' ', (tab at: i) asString, ' ', >>> (tab at: i) asString, argNumber asString, ','. >>> argsArray at: argNumber + 2 put: (tab at: i + 1). >>> argNumber := argNumber + 1. >>> ]. >>> functionArgs := functionArgs allButLast. >>> >>> methodCorpse := functionPrototype, Character cr asString, ' >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin>', Character cr >>> asString, Character cr asString, ' ^self nbCall: #( void printf ( String >>> stringFormat,', functionArgs asString, ' ) )', Character cr asString, ' >>> module: NativeBoost CLibrary'. >>> >>> methodSelector := self class compile: methodCorpse. >>> >>> self perform: methodSelector withArguments: argsArray. >>> >> >> >> Then you can call it like that : >> >> MyClass printf: 'Test of printf. String: %s, Int : %d, Long: %ld, Char: >> %c, Double: %lf' args: { 'String'. 'This is a string'. 'int'. 100. 'long'. >> 10000000. 'char'. 89. 'double'. 3.14159 }. >> >> >> I also tried it for some other variadic functions and, on my computer (I >> am running archlinux), it seemed to work for every type of argument except >> "float". It works fine for "double" though. >> For "char" you need to pass the integer ASCII value directly for it to >> work. I tried with "Character value: xxx" but it didn't work. >> >> I know that this is very hackish and very bad, and I am aware it has some >> drawbacks. Moreover I am not even sure it will work everytime. >> But for now it seems to work ... >> >> Oh man... > and why would anyone may want to use this? :) > > Sure you can do whatever it takes to implement a feature you want so badly, > but hey.. > If something that takes so much effort and so inefficient as result, would > you consider abandon the idea and use something else instead? :) > Because it is straightly against the philosophy of NB: be fast and > explicit. > And you seem to be in favor of implicitness. > Well, nevertheless, it is a honorable goal, so good luck :) > > >> 2015-07-13 19:24 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >> >>> >>> >>> On 10 July 2015 at 10:18, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> >>> wrote: >>> >>>> Hello, >>>> >>>> Is it possible with NativeBoost to create a binding for a variadic >>>> function ? >>>> >>>> I've seen the printf example in NBCPrinter but this implementation is >>>> kind of cheating since it always pass just a %s as format and one already >>>> formatted string to the C function. >>>> >>>> I've written a simple variadic function which adds every integer it >>>> receives as argument (first argument is for the number of following >>>> arguments) : >>>> >>>> int add(int number,...); >>>> >>>> In Pharo I've tried something like this : >>>> >>>> *add: *number *arg1: *first *arg2: *second >>>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >>>>> >>>>> ^ self nbCall: #( int add (int number, int first, int second)) >>>>> module: 'libMyLib.so' >>>>> >>>> >>>> and it works fine with two arguments. >>>> >>>> Basically, doing so, I would need one method per number of arguments so >>>> it's not very cool. >>>> >>>> I thought that maybe I could pass an array as argument to my Pharo >>>> method but I didn't really find a way to figure out how to define the >>>> nbCall without having a "Generic failure". >>>> >>>> *add: *number *args: *anArray >>>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >>>>> >>>>> ^ self nbCall: #( int add (int number, ??? anArray)) >>>>> module: 'libMyLib.so' >>>>> >>>> >>>> Do you have an idea ? >>>> >>>> >>> In short, there's no marshaller for converting an array of items, to >>> same number of things on stack. That could solve the problem with your >>> example: passing array of objects of *same* type. But in general, it is not >>> what C variadic function(s) standing for. Because they stand for any number >>> of arguments, of any type. >>> In C, since all program is compiled statically, compiler knows the >>> number of passed arguments and their types through compiling each >>> particular call site(s) to variadic function. Which means that in fact, you >>> are still supplying all information needed by compiler *before* run time. >>> >>> In variadic functions, you can pass any arguments of any type, >>> but for converting each of them, you must tell NB what kind of >>> marshaller should be used for it , which means, that it is impossible to >>> know before run time, since you cannot know how many arguments you may >>> pass, not speaking about their types. >>> >>> >>> >>> >>>> Thanks, >>>> >>>> Matthieu >>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

July 16, 2015