- Pharo-users - lists.pharo.org

Re: [Pharo-users] PharoJS

by Noury Bouraqadi

> On 17 Jul 2015, at 17:21, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Noury Bouraqadi-2 wrote >> The main difference is that with PharoJS we develop and test in Pharo, >> with the confort of all cool tools such as the GT inspector, spotter :-) > > Wow!!! That is my main pain point with Amber. Unless one is very disciplined > with TDD, the linkage between the app loaded in the browser, and Helios > loaded in a separate window, introduces a run-compile-like cycle where after > every change, one has to reload the app which reloads the IDE, and you lose > all current state e.g. workspaces, etc. > > How mature is PharoJS? Is anyone using it in production? Who are the core > developers? What are the intentions e.g. toy? experiment? > production-quality? next big thing? > PharoJS is a side project I started early May this year as an experiment. But, after few weeks I noticed that it can cover a significant subset of Pharo. As I showed at ESUG (we missed you BTW), it allows building a simple form app for smartphones using PhoneGap. So, I shifted my goal, and decided to make it clean and usable for production-quality app. Fortunately, I won't be alone. Torsten Bergmann and Dave Mason kindly offered their help and joined the project since few days. Regarding the status, PharoJS is usable, but I don't recommend to use it for production right now. It is not polished and parts are likely to dramatically change in the forthcoming weeks. We also need to expand the documentation. Lot of stuff to do, but I'm very excited about it :-) Still, you can give it a try. There is a first tutorial that gives a quick overview. More to come. Noury

July 18, 2015

Re: [Pharo-users] Fwd: Phratch: System/World Menu instead of phratch menu

by Offray Vladimir Luna CÃ¡rdenas

Hi, No, I can't reproduce the bug, but our workshop already ended with very good results by the way. We use some mixture of Phratch and Scratch. Phratch worked fine almost all the time (except for the bug with Spanish and Operators, but the almost "real time" support was a convencing feature for the software). Scratch has the advantage of a web gallery, video integration, and more demos, but I think that some kind of gallery preview and sharing mode inside Phratch will reduce this advantage. It was a very possitive experience and I plan to repeat it in the future and make more documentation. Cheers, Offray On 15/07/15 10:58, jannik laval wrote: > Hi Offray, > > Could you reproduce the bug ? > Or when does it appear ? > > Best regards, > Jannik > > 2015-07-15 17:39 GMT+02:00 Offray Vladimir Luna CÃ¡rdenas > <offray(a)riseup.net <mailto:offray@riseup.net>>: > > He he, sorry sending from the wrong mail address, here comes again. > > > -------- Forwarded Message -------- > Subject: Phratch: System/World Menu instead of phratch menu > Date: Wed, 15 Jul 2015 10:35:37 -0500 > From: Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> > <mailto:offray.luna@mutabit.com> > To: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > > > > Hi, > > Some of my students are having a problem. For some reason the pharo > world/system menu appears and we don't know how to disable it and go > back to the phratch menu, so we can't use "Save as" and other options to > save/export projects. > > How to get back the default behaviour for Phratch menus? > > Thanks, > > Offray > > > > > > > -- > > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info > http://car.mines-douai.fr/ >

July 18, 2015

Re: [Pharo-users] Pharo-users Digest, Vol 27, Issue 62

by Noury Bouraqadi

> On 17 Jul 2015, at 18:26, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: > > The main thing I am wondering about is how to build portable interfaces. > > My ideal situation would be to use something like Spec to prototype within Pharo, and then generate something similar in JS. > > Alternatively, perhaps we could create mock objects for something like jquery-ui. > > Noury, have you done any experiments with this? > I like the idea. But, so far PharoJS does not have support for widgets. Roassal might be a cool solution. It does not have all widgets, but the cool zoomable visualisation can be exported to javascipt. Noury

July 17, 2015

Re: [Pharo-users] Pharo-users Digest, Vol 27, Issue 62

by Andy Burnett

The main thing I am wondering about is how to build portable interfaces. My ideal situation would be to use something like Spec to prototype within Pharo, and then generate something similar in JS. Alternatively, perhaps we could create mock objects for something like jquery-ui. Noury, have you done any experiments with this? Cheers Andy

July 17, 2015

Rectangle center rounding

by Jan BlizniÄenko

Hello I came to problem with Roassal which originates in Rectangle class. Although rectangle holds its points (origin and corner) in float (not rounded) numbers, the Rectangle>>#center method rounds it down to integers. It causes wierd behavior in Roassal where moving elements in some ocasions are "jumping" to all directions like a jelly. I understand it is for performance reasons, but I think this optimisation is not on the right place. Rectangle origin: 0.9(a)0.9 corner: 3@3 just does not have center 1@1, it is way too far from the real center. Shouldn't the rounded method be separated as for example roundedCenter or something like that to eliminate the confusion? Jan -- View this message in context: http://forum.world.st/Rectangle-center-rounding-tp4837980.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 17, 2015

Re: [Pharo-users] PharoJS

by Sean P. DeNigris

Noury Bouraqadi-2 wrote > The main difference is that with PharoJS we develop and test in Pharo, > with the confort of all cool tools such as the GT inspector, spotter :-) Wow!!! That is my main pain point with Amber. Unless one is very disciplined with TDD, the linkage between the app loaded in the browser, and Helios loaded in a separate window, introduces a run-compile-like cycle where after every change, one has to reload the app which reloads the IDE, and you lose all current state e.g. workspaces, etc. How mature is PharoJS? Is anyone using it in production? Who are the core developers? What are the intentions e.g. toy? experiment? production-quality? next big thing? ----- Cheers, Sean -- View this message in context: http://forum.world.st/PharoJS-tp4837593p4837974.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 17, 2015

Re: [Pharo-users] [Pharo-dev] Seeking help on morphs : expander and scrolls

by Jigyasa Grover

Nicolai, that was indeed a help. Thanks :) -- View this message in context: http://forum.world.st/Seeking-help-on-morphs-expander-and-scrolls-tp4837934… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 17, 2015

Re: [Pharo-users] [Pharo-dev] Seeking help on morphs : expander and scrolls

by Nicolai Hess

what about "newTextEditorFor:" *dialog newRow: {* *(* * (* * dialog newExpander: r title asString* * forAll: { dialog newTextEditorFor: yourTextModel getText:#getTextSelector setText:#setTextSelector. }* * )minWidth:600; minHeight: 10* *)cellInset: 0;* * borderStyle: (BorderStyle inset baseColor: dialog paneColor; width: 1)* 2015-07-17 11:59 GMT+02:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: > 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

The Esug videos have started arriving

by Stephan Eggermont

https://www.youtube.com/user/esugboard/videos

July 17, 2015

How to correctly boost performances with Nativeboost ?

by Matthieu Lacaton

Hello everyone, I know, I come up with another question involving NativeBoost ... Sorry ! Anyway, I am currently trying to improve the performance of a Pharo application by trying to rewrite some parts in C and use them with NativeBoost. In the application, there is a need to compute a lot of 2D projections of points so basically I need to compute a lot of cosinuses and sinuses on different points. Ultimately I'd like to do it with openMP to use all the processor cores but for now I just wanted to do some tests to find the best way to combine Pharo and C. The first test consisted in writing a very simple C function and use it from inside Pharo : void project (Point *p) { p->x = cos(p->x); p->y = sin(p->y); } with typedef struct { double x; double y; } Point; In Pharo I created a NBExternalStructure to match Point and everything worked as expected. Now I ran some performance tests and there are some results I don't really understand :( 1) First test was : test | t1 t2 tC tPharo | tC := 0. tPharo := 0. 1 to: 1000000 do: [ :i | | p1 | p1 := Point x: i + (1.0 / i ) y: i - (1.0 / i). t1 := Time microsecondsToRun: [ p1 setX: p1 x cos setY: p1 y sin. ] tPharo := tPharo + t1. ] 1 to: 1000000 do: [ :i | | p2 | p2 := MyPoint x: i + (1.0 / i ) y: i - (1.0 / i). t2 := Time microsecondsToRun: [ self primProject: p2. ] tC := tC + t2. ] Results here are arround 185 ms for tC and 210 ms for tPharo. Nothing really bothered me with this test as results seemed coherent (are they ?). 2) Second test was : test2 | tC tPharo array1 array2 size | size := 1000000. array1 := Array new: size. array2 := Array new: size. 1 to: size do: [ :i | array1 at: i put: (Point x: i + (1.0 / i ) y: i - (1.0 / i)). array2 at: i put: (MyPoint x: i + (1.0 / i ) y: i - (1.0 / i)). ]. tPharo := Time millisecondsToRun: [ array1 do: [ :each | each setX: each x cos setY: each y sin. ]. ]. tC := Time millisecondsToRun: [ array2 do: [ :each | self primProject: each. ]. ]. Results here are arround 3 500 ms for tPharo and 150ms for tC. And I don't really understand why such a difference. I've tried doing tC first but it changed nothing. I've checked the results and the contents of array2 are all updated correctly. Is there a problem with tC or tPharo ? What am I doing wrong ? On another hand, I also noticed that it is faster to allocate the array with Pharo Points than the array with MyPoint C-ish struct. I did some more testing and it seemed that on a general basis it is faster to manipulate Pharo objects than C-ish structs or pointers. For example, it is faster to read in a Pharo array than to read in a NativeBoost_to_C array. Knowing so, what kind of C types should I use to avoid losing too much time manipulating them with NativeBoost ? Is it preferable, for example, to use two separate double instead of a struct with two doubles inside ? Thank you very much, Matthieu

July 17, 2015