May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Halo Menu On Spec Tree Node

by Nicolai Hess

2015-05-06 21:23 GMT+02:00 Sergio Fedi <sergio.fedi(a)gmail.com>: > Thanks for making the new case, I may resolve it soon.â > Good luck :) I put a slice into the inbox, but that fix does not work , fo example: RemotesManager new openWithSpec. does not work anymore

May 6, 2015

Re: [Pharo-users] WebSocket and Proxying ...

by itlists＠schrievkrom.de

Good guess - but this does not help .... Marten Am 06.05.2015 um 21:24 schrieb Sven Van Caekenberghe: > Good that it works now, maybe your problem is that /ws-echo comes before and maybe also matches /ws-echo-client ? But I am no nginx expert. > > Maybe you try serving and proxying it as /client-ws-echo ? Or switch the order ? > -- Marten Feldtmann

May 6, 2015

Re: [Pharo-users] WebSocket and Proxying ...

by Sven Van Caekenberghe

Good that it works now, maybe your problem is that /ws-echo comes before and maybe also matches /ws-echo-client ? But I am no nginx expert. Maybe you try serving and proxying it as /client-ws-echo ? Or switch the order ? > On 06 May 2015, at 20:11, itlists(a)schrievkrom.de wrote: > > Ok, I managed to make it work somehow: > > I removed the static file serving from Pharo and put the > "ws-echo-client" code to the file system and it is now handled by nginx. > > Now only WebSocket stuff is done by Pharo and this seems to work without > problems. > > That means: the mixture of static-stuff and websocket handling breaks > the system: browser (Firefox or Chrome or IE11) <-> nginx <-> Pharo > > Not the solution I wanted, but at least a way to make WebSockets working > under Pharo ... > > Marten > > > > Am 06.05.2015 um 16:48 schrieb itlists(a)schrievkrom.de: >> Hmm, at least I managed, that Pharo answered every second request using >> the echo example >> >> Under Windows and nginx I added to the nginx configuration. My local >> Pharo server is running under 127.0.0.1:40000: >> >> extract from nginx.conf: >> >> http:{ >> >> map $http_upgrade $connection_upgrade { >> default upgrade; >> } >> >> server { >> >> location /ws-echo { >> proxy_pass http://127.0.0.1:40000/ws-echo ; >> proxy_http_version 1.1; >> proxy_set_header Upgrade $http_upgrade; >> proxy_set_header Connection $connection_upgrade; >> } >> location /ws-echo-client { >> proxy_pass http://127.0.0.1:40000/ws-echo-client ; >> } >> >> } >> } >> >> >> >> Am 06.05.2015 um 10:20 schrieb Sven Van Caekenberghe: >>> Marten, >>> >>>> On 06 May 2015, at 10:15, itlists(a)schrievkrom.de wrote: >>>> >>>> Hello, >>>> >>>> I'm playing with WebSockets under Pharo4 and this works as expected - >>>> when using Pharo4 alone (using the Zinc packages). >>>> >>>> But I did not get it to work, when e.g. doing a proxying via nginx (I >>>> did not check it with Apache). >>>> >>>> Actually Pharo4 seems to receive some stuff, because the WebSocket of >>>> Pharo4 stuff does not work as expected after first proxying attempts. >>>> >>>> Has anyone experience with that ? >>>> >>>> Marten >>> >>> Proxying the WebSockets protocol is not easy, nor implemented everywhere, like HTTP is. This makes sense if you think about it, a WebSocket connection is a permanent connection, which takes resources, this is not something most servers like. >>> >>> So it is more difficult. >>> >>> Did you see/try http://nginx.org/en/docs/http/websocket.html ? >>> >>> (I did not try it) >>> >>> Sven >>> >>> >> >> > > > -- > Marten Feldtmann >

May 6, 2015

Re: [Pharo-users] Halo Menu On Spec Tree Node

by Sergio Fedi

Thanks for making the new case, I may resolve it soon.â

May 6, 2015

Re: [Pharo-users] Halo Menu On Spec Tree Node

by Nicolai Hess

2015-05-06 13:47 GMT+02:00 Craig Johnson <craig(a)hivemind.net>: > Hi All, > > I had an issue - when I opened a Halo on a Spec tree node in the UI and > select the menu Icon, I got a DNU message. However if I selected a normal > Morph, the menu Icon worked fine. > > I'm using Pharo 4.0 released version. > > Fixed this by changing TreeModel>>iconFor to: > iconFor: aNode > ^ iconBlock value cull: aNode content*s* cull: aNode > > Hi, Thank you for the report (and the fix) I made a bugtracker entry: 15500 <https://pharo.fogbugz.com/default.asp?15500> SpecTreeNodeModel(Object)>>doesNotUnderstand: #content > > > Craig > > >

May 6, 2015

Re: [Pharo-users] WebSocket and Proxying ...

by itlists＠schrievkrom.de

Ok, I managed to make it work somehow: I removed the static file serving from Pharo and put the "ws-echo-client" code to the file system and it is now handled by nginx. Now only WebSocket stuff is done by Pharo and this seems to work without problems. That means: the mixture of static-stuff and websocket handling breaks the system: browser (Firefox or Chrome or IE11) <-> nginx <-> Pharo Not the solution I wanted, but at least a way to make WebSockets working under Pharo ... Marten Am 06.05.2015 um 16:48 schrieb itlists(a)schrievkrom.de: > Hmm, at least I managed, that Pharo answered every second request using > the echo example > > Under Windows and nginx I added to the nginx configuration. My local > Pharo server is running under 127.0.0.1:40000: > > extract from nginx.conf: > > http:{ > > map $http_upgrade $connection_upgrade { > default upgrade; > } > > server { > > location /ws-echo { > proxy_pass http://127.0.0.1:40000/ws-echo ; > proxy_http_version 1.1; > proxy_set_header Upgrade $http_upgrade; > proxy_set_header Connection $connection_upgrade; > } > location /ws-echo-client { > proxy_pass http://127.0.0.1:40000/ws-echo-client ; > } > > } > } > > > > Am 06.05.2015 um 10:20 schrieb Sven Van Caekenberghe: >> Marten, >> >>> On 06 May 2015, at 10:15, itlists(a)schrievkrom.de wrote: >>> >>> Hello, >>> >>> I'm playing with WebSockets under Pharo4 and this works as expected - >>> when using Pharo4 alone (using the Zinc packages). >>> >>> But I did not get it to work, when e.g. doing a proxying via nginx (I >>> did not check it with Apache). >>> >>> Actually Pharo4 seems to receive some stuff, because the WebSocket of >>> Pharo4 stuff does not work as expected after first proxying attempts. >>> >>> Has anyone experience with that ? >>> >>> Marten >> >> Proxying the WebSockets protocol is not easy, nor implemented everywhere, like HTTP is. This makes sense if you think about it, a WebSocket connection is a permanent connection, which takes resources, this is not something most servers like. >> >> So it is more difficult. >> >> Did you see/try http://nginx.org/en/docs/http/websocket.html ? >> >> (I did not try it) >> >> Sven >> >> > > -- Marten Feldtmann

May 6, 2015

Re: [Pharo-users] [ANN] Idea icon pack now in Configuration Browser

by Offray Vladimir Luna CÃ¡rdenas

Hi, El 05/05/15 a las 11:34, Esteban Lorenzano escribiÃ³: > >> On 05 May 2015, at 17:59, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: >> >> Hi, >> >> El 04/05/15 a las 18:05, Esteban Lorenzano escribiÃ³: >>> >>>> On 05 May 2015, at 01:10, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net >>>> <mailto:offray@riseup.net>> wrote: >>>> >>>> May be the small icon of the glasses works better now that the print preview >>>> is not "polluting" the writing of code, but has a tooltip with glasses on it. >>> >>> no, because thatâs the icon for âinspectâ and what you see there is is >>> playground specific: is showing the result and offering you the possibility of >>> inspect it, yet the glasses. >>> >>> Esteban >> >> >> Ok. It was just an idea. Maybe something else will work, a "play" icon with a "page" or "print" icon. What is wise is that slightly different actions have slightly different icons. > > yes, but that means I need to take pixelimator and create an icon. > A painful and not really compensating task. > I can try it, with time (it is in my todo). > but it will happen when it happens :) > > Esteban > Fine :). Surely creating icons by hand is not the proper solution. Idea icons are a nice improvement and when they get better and we have more icons and themes surely we will have a more broad repertory to choose from. Cheers, Offray

May 6, 2015

MouseWheel events

by Matthieu Lacaton

Hello everyone, I have a question about MouseWheel events in Pharo. On Linux, when I use the wheel of my mouse the event I get in return is an instance of MouseWheelEvent : *" [(606@633) mouseWheel Character arrowDown CTRL 33261828 nil] "* When I press "CTRL + ArrowUp" or "CTRL + ArrowDown" on my keyboard I get the same type of MouseWheelEvent. On the other side, on Windows XP, when I press "CTRL + ArrowUp" or "CTRL + ArrowDown" on my keyboard I also get a MouseWheelEvent but when I use the wheel of my mouse I get a Keystroke event : *" [keystroke '<Ctrl->'] "* with a keyValue of 30 for a mousewheel up and 31 for a mousewheel down. I am a bit confused about this : Shouldn't I get a MouseWheel event when i use the wheel and a keystroke when I use CTRL + Arrow ? Why is it different from Linux to Windows ? In both cases I used Pharo4 VM + a fresh pharo 4 image. Thanks, Matthieu

May 6, 2015

Re: [Pharo-users] mac address on windows

by Esteban Lorenzano

> On 06 May 2015, at 17:03, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-05-06 16:40 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > >> On 06 May 2015, at 12:10, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: >> >> I've loaded your package. >> >> A prerequisite is to load OS-Window to make it work. > > why? > in any case, oswindow is already included in pharo4 > > OS-Windows (by TorstenBergmann) > not > OSWindow :) ahhh. Name clash :) > > It is needed for the shared pool WinTypes, > but without OS-Window, he can use NBWinTypes instead. > > > > Esteban > >> >> I've got the DLL call working nicely and the nativeboost with the structure freezing. >> >> Now, we should all have a look at: >> >> https://github.com/ronsaldo/bullet-pharo <https://github.com/ronsaldo/bullet-pharo> >> >> and >> >> https://github.com/ronsaldo/swig <https://github.com/ronsaldo/swig> >> >> because it looks like the way to go to wrap libraries... >> >> Ronie, I know you modified swig for generating Pharo code; >> >> Is cloning your swig repo the way to go ? >> >> >> Phil >> >> >> >> >> On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti <usman.bhatti(a)gmail.com <mailto:usman.bhatti@gmail.com>> wrote: >> Hi Nicolai, >> >> Here is my package that defines the nativeboost call and associated C structs. >> The external C struct is self referencing and hence sometimes I get infinite recursion when trying to change field descriptions. That is the reason why the automatically generated accessors are absent (although I had them in an earlier version). >> >> Attached also the DLL referenced in the code. >> >> >> >> On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> >> 2015-05-06 9:53 GMT+02:00 Usman Bhatti <usman.bhatti(a)gmail.com <mailto:usman.bhatti@gmail.com>>: >> >> >> On Tue, May 5, 2015 at 7:34 PM, phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@highoctane.be>> wrote: >> >> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti <usman.bhatti(a)gmail.com <mailto:usman.bhatti@gmail.com>> wrote: >> I succeeded to do it by encapsulating the C routine as a DLL and doing an FFI call from my image (as suggested by Guille). >> >> At least there was a way! >> >> Exactly :) >> >> >> Looks like this is the most controlled|debuggable way: >> - get it working with C code out of Pharo >> - make a bridge that can be used easily with FFI in a dll >> - use that from Pharo with proven FFI >> >> Would NativeBoost work with your dll? Should. >> >> I have read a few resources about Nativeboost but I am still naive to know the difference between FFI and nativeboost. The FFI call I made to invoke the DLL function looked similar to the nativeboost calls. >> >> >> >> I also tried to perform the nativeboost call by creating my structures in Pharo. The function in Windows that can be used to retrieve mac address in Windows: GetAdaptersInfo <https://msdn.microsoft.com/en-us/library/windows/desktop/aa365917%28v=vs.85…> that accepts a PIP_ADAPTER_INFOÂ <https://msdn.microsoft.com/en-us/library/windows/desktop/aa366062(v=vs.85).…> structure. I subclassed NBExternalStructure to define this struct and the other used by it in the image but my NB call returned with 87 code (Invalid parameter) and it was impossible to debug. However, I would like to make this thing work to understand what went wrong. >> >> Has this something to do with 32|64 bit library complications? >> >> Not exactly. For me, it was more related to the fact that I had to map a complex C struct in Pharo. Here is an excerpt of the definition from MSDN: >> >> typedef struct _IP_ADAPTER_INFO { >> struct _IP_ADAPTER_INFO *Next; >> ... >> PIP_ADDR_STRING CurrentIpAddress; >> IP_ADDR_STRING GatewayList; >> ... >> } >> >> So, I had to define three external structures (all names in capitals) and I did the effort but in the end I got an error code that I could not debug in the image. Hence, I gave up and opted to go in the native environment. But I would like someone knowledgable to have a look at my nativeboost code because the nativeboost approach is more simple (everything's in the image). >> >> I can have a look. >> >> btw. for what do you need the mac address? >> >> >> >> >> >> usman >> >> >> Phil >> >> With ProcessWrapper, I could not load the classes essential for making the plugin work. >> >> HTH, >> >> Usman >> >> >> >> >> On Mon, May 4, 2015 at 2:54 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> As a complete newb to VM building I found this fairly straight forward (on a Mac btw). >> https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm> >> cheers -ben >> >> On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti <usman.bhatti(a)gmail.com <mailto:usman.bhatti@gmail.com>> wrote: >> >> >> On Sun, May 3, 2015 at 4:22 PM, Pierce Ng <pierce(a)samadhiweb.com <mailto:pierce@samadhiweb.com>> wrote: >> On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote: >> > 1/ OSProcess: I tried (PipeableOSProcess command: 'ipconfig /all') output. >> >> I have used http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper <http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper> successfully >> back when I was on Windows using some now-ancient version of Pharo. >> >> I had initially discarded the idea of using this project because it required a plugin and the information of the plugin was outdated on squeaksource. However, having evaluated superficially the complexity of doing it with nativeboost (because too many external c struct involved in the call), I would like to see if I am better off using this wrapper. >> >> I loaded it with: >> >> Gofer it >> url: 'http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main <http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main>'; >> package: 'ProcessWrapper-Core'; >> package: 'ProcessWrapper-Plugin'; >> package: 'ProcessWrapper-Tests'; >> load. >> >> But the plugins wont load because it requires the class SmartSyntaxInterpreterPlugin and apparently this file is a part of the VMMaker. Is there any recent config for VMMaker in Pharo because this one looks outdated: >> http://pharo.gemtalksystems.com/book/Virtual-Machine/Building/VMMakerTool/ <http://pharo.gemtalksystems.com/book/Virtual-Machine/Building/VMMakerTool/> >> >> >> >> >> >> Pierce >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >

May 6, 2015

Some Athens modifications ?

by Matthieu Lacaton

Hello everybody, I was playing arround with Athens lately and I think I encountered a few small bugs along the way (I may be wrong though) : 1) In *LinearGradientPaint class >> from:* aStartPoint *to:* aStopPoint There is a call to the method *"initializeFrom: aStartPoint to: aStopPoint"* but this method does not exist. I think the whole method could probably be replaced by : *LinearGradientPaint class >>* *from:* aStartPoint *to:* aStopPoint ^ self new start: aStartPoint; stop: aStopPoint; yourself. 2) This is not much but in the *GradientPaint* class there is an instance variable named *"stops"* but it seems that it is never used. 3) In AthensCairoMatrix there is a difference in the variable order between *AthensCairoMatrix class >> fieldsDesc* and *AthensCairoMatrix >> initx: y: sx: sy: shx: shy:* In the first one the order is "sx, shx, shy, sy, x, y" whereas in the second one it is "sx, shy, shx, sy, x, y". However, according to the cairoGraphics API documentation, the order should be the same. By the way I have a small question : Why not keep the same variable names than in cairoGraphics here (xx, yx, xy, yy, x0, y0) ? 4) In *AthensCairoMatrix >> primMultiplyBy:* m. The function as defined in C is the following : void cairo_matrix_multiply (*cairo_matrix_t <http://cairographics.org/manual/cairo-cairo-matrix-t.html#cairo-matrix-t> *result*, *const cairo_matrix_t <http://cairographics.org/manual/cairo-cairo-matrix-t.html#cairo-matrix-t> *a*, *const cairo_matrix_t <http://cairographics.org/manual/cairo-cairo-matrix-t.html#cairo-matrix-t> *b*); It is stated that *"The effect of the resulting transformation is to first apply the transformation in a to the coordinates and then apply the transformation in b to the coordinates."* In Pharo it is defined like this : *void cairo_matrix_multiply ( AthensCairoMatrix * self, AthensCairoMatrix * m , AthensCairoMatrix * self )* For me, when writing "self multiplyBy: aRotationTransformation" it seems more logical to first do the self transformation" and then the rotation transformation (especially if we want a cascade of transformations). However, as currently written in Pharo it is actually the rotation transformation that is applied and then the self transformation. For example, if I want a scaling then a rotation then a translation it seems easier to me to do : myTransformation := myTransformation multiplyBy: scalingTransformation. myTransformation := myTransformation multiplyBy: rotationTransformation. myTransformation := myTransformation multiplyBy: translationTransformation. etc. if I want some other transformations. So it could be nice to have a *a method defined like this : void cairo_matrix_multiply ( AthensCairoMatrix * self, AthensCairoMatrix * self , AthensCairoMatrix * m )* What do you think about it ? Thanks, Matthieu

May 6, 2015