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

Re: [Pharo-users] Using VirtualGPU

by Serge Stinckwich

On Tue, May 19, 2015 at 11:30 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hi all, > > Sorry for answering very late, I am busy in ICSE where tomorrow I have to > defend my poster for the Student Research Competition. The topic is > profiling over the OpenCL bindings. No problem Ronie. Thank you for your reply. Do you have a copy of your poster somewhere ? >> We are looking at the code of OpenCL and VirtualGPU done by Ronnie. >> What we have understand until now : >> - OpenCL package : low-level stuff to be able to interface OpenCL >> kernels with Pharo >> - VirtualGPU: high-level API on top of OpenCL in order to ease the >> task of people who wants to use OpenCL. VirtualGPU provide high-level >> operations on matrix and image at the moment. > > This is correct. > >> @Ronie: What is not clear at the moment in our mind : when you build a >> VirtualGPU program with the DSL, do you have the overhead of >> communications every time you execute a VirtualGPU instruction or all >> the the instructions are sent at the same time and run on the GPU ? > > The DSL, is actually an abstraction over the OpenCL API. Each operation, is > stored in a simple intermediate representation, that is used to call a > single OpenCL kernel. > > There is no overhead in terms of memory transfers between intermediate > operations, because there kept in the GPU the whole. There is an overhead in > terms of kernel dispatching. For example, the expression a + b * 0.5 in the > VGPU DSL is interpreted as the following pseudo code: > > temp := opencl invokeKernel: 'add' a with: b. > temp2 := opencl invokeKernel: 'mulScalar' temp with: 0.5. > > A custom crafted code would do something like this: > > temp := opencl invokeKernel: 'addAndMulScalar' with: a with: b with: 0.5 > > The VGPU does not do the latter for simplicity. Currently, it does not > generate any kind of OpenCL C code. It works by composing simple functions. > Perhaps, in the future I will add a code generation step for optimization. Ok, I understand. What will be the benefit in term of speed if you doing code generation regarding the current version ? > Another problem, is the proliferation of intermediate buffers. There are > some samples that avoid using intermediate buffers by using add:into: > instead of +. The into buffer is just where the result is going to be > placed. Look into VirtualGPUSamples >> #imageChangedForGradient, > VirtualGPUSamples >> #imageChangedForGradientOptimized , VirtualGPUSamples >>> #imageChangedForGradientOptimizedMore . > > >> >> In our context, for building a GSSA algorithm, I guess we just have to >> combine same VGPU instructions (matrix computations) but for doing SPH >> simulations, we will have to provide our own instructions. Is there >> any documentation in order to add own kernel and instructions ? > > > There is not documentation. We should have some tool like doxygen so that I > can write the documentation when I am writing the methods. > > Anyway, I will document here for now. Great ;-) Can we start a Pillar chapter in https://github.com/SquareBracketAssociates/PharoLimbo > First of all, look at the existing kernels. For that, put this in a > playground and do it (you need the GTInspector): > > EmbObjectBrowser openBrowser. > > That will open a browser that I use to edit the OpenCL C code. It does have > some bugs, but it is better than editting a huge string in a smalltalk > method. Lets look in VGPULinearAlgebraSources. There you will see the > 'kernels' category and inside of it two methods: #matrixKernels' and > #vectorKernels . If you look #vectorKernels , you will see just the OpenCL C > code. > > If you now go to Nautilus, and look the VGPULinearAlgebraSources class, you > will see that it is a subclass of EmbObjectContainer. vectorKernels and > matrixKernels are Smalltalk methods. vectorKernels looks like this: > > vectorKernels > <embeddedObject> > ^ ' > // Vector binary operations > __kernel void floatVector_add(__global float *left, __global float *right, > __global float *result) > ... > ' > > For an example, of actually invoking the kernel, you should look at the > following methods: > VGPUFloatMatrix >> #abs > VGPUFloatMatrix >> #absInto > VGPUFloatMatrix >> #discreteGradient > VGPUFloatMatrix >> #discreteGradientInto > > As for the OpenCL package, it just provides bindings for the C OpenCL API. > You can also use it if you want, but your are on your own :) . I already understand part of that. Thank you for help. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

May 19, 2015

Re: [Pharo-users] Displaying pictures using Athens

by Nicolai Hess

2015-05-19 10:46 GMT+02:00 Christopher Coat <christopher.coat(a)inria.fr>: > Hi everybody, > Hi, > > Iâm currently creating a small app to display images and move them on a > screen using Athens. > I have all my image loaded on start and I use a loop to clear the screen > and redraw all the elements (on different place and angle) every frames. > > The problem is that with morph, everything is fine, but as soon as I place > a picture on a morph the FPS drop down. Even if the picture is a small one. > How do you draw the picture? Is it an ImageMorph or do you use directly Athens for drawing the image? nicolai > Does anybody have faced the same issue ? Or is there any better way to do > it ? > > Thanks > Chris > > > > >

May 19, 2015

Re: [Pharo-users] Using VirtualGPU

by Ronie Salgado

Hi all, Sorry for answering very late, I am busy in ICSE where tomorrow I have to defend my poster for the Student Research Competition. The topic is profiling over the OpenCL bindings. We are looking at the code of OpenCL and VirtualGPU done by Ronnie. > What we have understand until now : > - OpenCL package : low-level stuff to be able to interface OpenCL > kernels with Pharo > - VirtualGPU: high-level API on top of OpenCL in order to ease the > task of people who wants to use OpenCL. VirtualGPU provide high-level > operations on matrix and image at the moment. This is correct. @Ronie: What is not clear at the moment in our mind : when you build a > VirtualGPU program with the DSL, do you have the overhead of > communications every time you execute a VirtualGPU instruction or all > the the instructions are sent at the same time and run on the GPU ? > The DSL, is actually an abstraction over the OpenCL API. Each operation, is stored in a simple intermediate representation, that is used to call a single OpenCL kernel. There is no overhead in terms of memory transfers between intermediate operations, because there kept in the GPU the whole. There is an overhead in terms of kernel dispatching. For example, the expression a + b * 0.5 in the VGPU DSL is interpreted as the following pseudo code: temp := opencl invokeKernel: 'add' a with: b. temp2 := opencl invokeKernel: 'mulScalar' temp with: 0.5. A custom crafted code would do something like this: temp := opencl invokeKernel: 'addAndMulScalar' with: a with: b with: 0.5 The VGPU does not do the latter for simplicity. Currently, it does not generate any kind of OpenCL C code. It works by composing simple functions. Perhaps, in the future I will add a code generation step for optimization. Another problem, is the proliferation of intermediate buffers. There are some samples that avoid using intermediate buffers by using add:into: instead of +. The into buffer is just where the result is going to be placed. Look into VirtualGPUSamples >> #imageChangedForGradient, VirtualGPUSamples >> #imageChangedForGradientOptimized , VirtualGPUSamples >> #imageChangedForGradientOptimizedMore . > In our context, for building a GSSA algorithm, I guess we just have to > combine same VGPU instructions (matrix computations) but for doing SPH > simulations, we will have to provide our own instructions. Is there > any documentation in order to add own kernel and instructions ? > There is not documentation. We should have some tool like doxygen so that I can write the documentation when I am writing the methods. Anyway, I will document here for now. First of all, look at the existing kernels. For that, put this in a playground and do it (you need the GTInspector): EmbObjectBrowser openBrowser. That will open a browser that I use to edit the OpenCL C code. It does have some bugs, but it is better than editting a huge string in a smalltalk method. Lets look in VGPULinearAlgebraSources. There you will see the 'kernels' category and inside of it two methods: #matrixKernels' and #vectorKernels . If you look #vectorKernels , you will see just the OpenCL C code. If you now go to Nautilus, and look the VGPULinearAlgebraSources class, you will see that it is a subclass of EmbObjectContainer. vectorKernels and matrixKernels are Smalltalk methods. vectorKernels looks like this: vectorKernels <embeddedObject> ^ ' // Vector binary operations __kernel void floatVector_add(__global float *left, __global float *right, __global float *result) ... ' For an example, of actually invoking the kernel, you should look at the following methods: VGPUFloatMatrix >> #abs VGPUFloatMatrix >> #absInto VGPUFloatMatrix >> #discreteGradient VGPUFloatMatrix >> #discreteGradientInto As for the OpenCL package, it just provides bindings for the C OpenCL API. You can also use it if you want, but your are on your own :) . I made some experiments with GPU computing with JavaScript. I understood > that the computings are made forever inside the GPU, so you just throw data > and programs once and you let the GPU compute for you. Yet the problem is > to read the data once they are computed. With webGL it seems impossible, > with webCL it is possible and not easy. Hence the choice of openCL I guess. > > I relate here how I could compute the powers of a Markov matrix here: > http://revue.sesamath.net/spip.php?article651 (especially click on "webGL > sans three.js"). I also made some experiments here: > http://irem.univ-reunion.fr/spip.php?article797 (but they use three.js if > I remember well) I have been taking a look at those so called HTML5 WebGL technology. It does not convince me, since I am more interested in desktop application. I was thinking on making a 3D level editor in html5, js and webgl to test the technology, it seems to have many problems. The last week with Milton we found an easy way to draw a Morph into a Woden texture, so I am going to be using Pharo for the editor. The main problem that I have with the web technologies, is the one size fit all mentality that surrounds them. Javascript as IR, the ugly asm.js hack, and the lack of support for UDP socket which any reasonable real time online game requires. Best regards, Ronie 2015-05-12 18:36 GMT+02:00 Alain Busser <alain.busser(a)gmail.com>: > Hi Serge, > > I made some experiments with GPU computing with JavaScript. I understood > that the computings are made forever inside the GPU, so you just throw data > and programs once and you let the GPU compute for you. Yet the problem is > to read the data once they are computed. With webGL it seems impossible, > with webCL it is possible and not easy. Hence the choice of openCL I guess. > > I relate here how I could compute the powers of a Markov matrix here: > http://revue.sesamath.net/spip.php?article651 (especially click on "webGL > sans three.js"). I also made some experiments here: > http://irem.univ-reunion.fr/spip.php?article797 (but they use three.js if > I remember well) > > Happy readings, and, yes, I feel interersted in these subjects > > Alain > > On Tue, May 12, 2015 at 7:48 PM, Serge Stinckwich < > serge.stinckwich(a)gmail.com> wrote: > >> Dear all, >> >> just to let you know, Cheikhou (in CC) is starting a student >> internship in my lab. >> He will work on Epidemiology Modelling with KENDRICK: >> http://ummisco.github.io/kendrick/ >> the platform that we are developing in order to analyse and visualise >> diseases models behaviours. >> >> We would like first to implement a GPU version of the Gillespie >> Stochastic Simulation Algorithm (GSSA): >> http://en.wikipedia.org/wiki/Gillespie_algorithm and after that also >> implement SPH simulations: >> https://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamics >> >> We are looking at the code of OpenCL and VirtualGPU done by Ronnie. >> What we have understand until now : >> - OpenCL package : low-level stuff to be able to interface OpenCL >> kernels with Pharo >> - VirtualGPU: high-level API on top of OpenCL in order to ease the >> task of people who wants to use OpenCL. VirtualGPU provide high-level >> operations on matrix and image at the moment. >> >> @Ronie: What is not clear at the moment in our mind : when you build a >> VirtualGPU program with the DSL, do you have the overhead of >> communications every time you execute a VirtualGPU instruction or all >> the the instructions are sent at the same time and run on the GPU ? >> >> In our context, for building a GSSA algorithm, I guess we just have to >> combine same VGPU instructions (matrix computations) but for doing SPH >> simulations, we will have to provide our own instructions. Is there >> any documentation in order to add own kernel and instructions ? >> >> I know that others guys at INRIA (StÃ©phane ?) are interested by GPU. >> Is it possible to join our effort to share what we are doing ? >> >> Regards, >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ >> >> >

May 19, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Sven Van Caekenberghe

> On 19 May 2015, at 10:53, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > > > Did you look in all your package caches ? > I did. Must have been a victim of cleaning ... but maybe TimeMachine has something ... thanks for the reminder. > > > If it is just a small example, like one class, maybe it could be > > added to the image, in which case it should indeed be a slice. > The package was pretty simple. Basically only adding a few convenience methods around Socket>>#setOption:value: . Still I think a usage example in form of a class comment and test case might be appropriate. So unless Multicast should be part of the base image I'll start with a separate package first. Since Socket is a fundamental part, and multicast is a key feature, I think it would logical to move it to the image itself, with a test case. > CU, > > udo > > > On 19/05/15 10:38, Sven Van Caekenberghe wrote: >> >>> On 19 May 2015, at 10:30, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >>> >>> Hi Sven, >>> >>> you got me :-) >>> >>> I had this as a package sometime ago for my own purposes (mDNS). So I knew it does work and how to do it. It's just I can't find that damned package anymore... >> >> Did you look in all your package caches ? >> >>>> I do think making all this cross platform could be a bit harder, we'll see. >>> It's not that hard. The socket API is the same on all supported platforms. No surprises on *nix based OS. The only exception is Windows where the API is the same but where you might run into some packet drops due to strange personal FW products and "value-add" NDIS drivers for NICs. The situation has gotten much better though since Windows Vista/7 are using multicast for some of their services out of the box. >>> >>> I will recreate it though. Should I simply publish a package or add this as a slice? >> >> Thanks a lot, Udo, a good multicast example would be super cool. >> >> If it is just a small example, like one class, maybe it could be added to the image, in which case it should indeed be a slice. >> >> If it is larger and more application/framework oriented, then maybe a standalone package is more interesting. We try to keep the image as modular as possible. This route would be a bit more work for you, but might make more sense if you also see it possibly growing in the future. >> >>> Best Regards, >>> >>> Udo >>> >>> >>> On 19/05/15 10:20, Sven Van Caekenberghe wrote: >>>> Hi Udo, >>>> >>>> It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. >>>> >>>> I do think making all this cross platform could be a bit harder, we'll see. >>>> >>>> Sven >>>> >>>>> On 19 May 2015, at 00:17, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >>>>> >>>>> This should have been 'IP_ADD_MEMBERSHIP' of course: >>>>> >>>>> imrMultiaddr := #[239 255 255 250]. >>>>> imrInterface := #[0 0 0 0]. >>>>> ipMreq := imrMultiaddr , imrInterface. >>>>> socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>>>> >>>>> >>>>> The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: >>>>> >>>>> [ >>>>> | udpSocket | >>>>> udpSocket := Socket newUDP. >>>>> udpSocket setPort: 1900. >>>>> imrMultiaddr := #[239 255 255 251]. >>>>> imrInterface := #[0 0 0 0]. >>>>> ipMreq := imrMultiaddr , imrInterface. >>>>> udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>>>> udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. >>>>> "udpSocket setOption: 'SO_REUSEADDR' value: 1." >>>>> udpSocket waitForData. >>>>> buffer := ByteArray new: 256. >>>>> data := udpSocket receiveUDPDataInto: buffer. >>>>> bytesRead := data at: 1. >>>>> sender := data at: 2. >>>>> senderPort := data at: 3. >>>>> more := data at: 4. >>>>> result := buffer copyFrom: 1 to: bytesRead. >>>>> udpSocket closeAndDestroy. >>>>> result asString inspect. >>>>> ] fork. >>>>> >>>>> >>>>> >>>>> The "client" (execute in different playground): >>>>> | message udpSocket | >>>>> message := String crlf join: #( >>>>> 'M-SEARCH * HTTP/1.1' >>>>> 'HOST:239.255.255.250:1900' >>>>> 'MAN:"ssdp:discover' >>>>> 'ST:ssdp:all' >>>>> 'MX:1' >>>>> ''). >>>>> >>>>> udpSocket := Socket newUDP. >>>>> udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. >>>>> (udpSocket waitForSendDoneFor: 5). >>>>> udpSocket closeAndDestroy. >>>>> >>>>> Hope this helps. >>>>> >>>>> CU, >>>>> >>>>> Udo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 18/05/15 23:29, Udo Schneider wrote: >>>>>> Hi Manfred, >>>>>> >>>>>> I just stumbled over the IP address you are using (239.255.255.250). If >>>>>> I remember correctly this is a IPv4 Class D Multicast address. >>>>>> (224.0.0.0-239.255.255.255). >>>>>> >>>>>> So if you want to transmit datagrams to this IP address or recieve >>>>>> datagrams sent to this multicast groups you have to set appropriate IP >>>>>> Options. >>>>>> >>>>>> You can set this options using Socket>>#setOption:value: and read them >>>>>> using Socket>>#getOption:. Please note that both methods expect the >>>>>> option to set as a name - not as constant. E.g. >>>>>> >>>>>> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >>>>>> >>>>>> If I do remember correctly you have to set the following options for >>>>>> sending/receiving: >>>>>> >>>>>> Sending: >>>>>> IP_MULTICAST_IF >>>>>> (IP_MULTICAST_LOOP) >>>>>> (IP_MULTICAST_TTL) >>>>>> >>>>>> Sending should AFAIK work w/o setting any option - although >>>>>> IP_MULTICAST_IF is highly recommended. >>>>>> >>>>>> Receiving: >>>>>> (SO_REUSEADDR) >>>>>> IP_ADD_MEMBERSHIP >>>>>> (IP_DROP_MEMBERSHIP) >>>>>> >>>>>> Receiving only works if you joined the multicast group previously. So I >>>>>> assume that you need to do something like this (not tested). >>>>>> >>>>>> imrMultiaddr := #[239 255 255 250]. >>>>>> imrInterface := #[0 0 0 0]. >>>>>> ipMreq := imrMultiaddr , imrInterface. >>>>>> socket setOption: 'MEMBERSHIP' value: ipMreq. >>>>>> >>>>>> Hope this helps. >>>>>> >>>>>> CU, >>>>>> >>>>>> Udo >>>>>> >>>>>> >>>>>> >>>>>> On 18/05/15 16:34, Manfred KrÃ¶hnert wrote: >>>>>>> Hi Sven, >>>>>>> >>>>>>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>>>>>> <sven(a)stfx.eu >>>>>>> <mailto:sven@stfx.eu>> wrote: >>>>>>> >>>>>>> >>>>>>> > On 18 May 2015, at 15:47, Manfred KrÃ¶hnert >>>>>>> <mkroehnert42(a)googlemail.com >>>>>>> <mailto:mkroehnert42@googlemail.com>> wrote: >>>>>>> > >>>>>>> > Hi, >>>>>>> > apparently I am missing something else. >>>>>>> > >>>>>>> > I can find devices when connected to a 'regular' LAN. >>>>>>> > >>>>>>> > However, I have a camera that creates a Wifi accesspoint and >>>>>>> makes itself discoverable via SSDP. >>>>>>> > Once I connect to this accesspoint my computer gets a valid IP >>>>>>> address assigned and the NodeJS code is able to discover the device. >>>>>>> > Unfortunately, the Pharo snippet I posted before does not give me >>>>>>> any results and hangs in Socket>>waitForDataIfClosed: . >>>>>>> > >>>>>>> > Any further ideas? >>>>>>> >>>>>>> Are you sure you restarted the image and your code after switching >>>>>>> networks ? >>>>>>> >>>>>>> >>>>>>> I did not check this before. >>>>>>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>>>>>> it after connecting to the camera accesspoint. >>>>>>> The code snippet freezes there as well. >>>>>>> >>>>>>> Manfred >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > >

May 19, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Udo Schneider

> Did you look in all your package caches ? I did. Must have been a victim of cleaning ... but maybe TimeMachine has something ... thanks for the reminder. > If it is just a small example, like one class, maybe it could be > added to the image, in which case it should indeed be a slice. The package was pretty simple. Basically only adding a few convenience methods around Socket>>#setOption:value: . Still I think a usage example in form of a class comment and test case might be appropriate. So unless Multicast should be part of the base image I'll start with a separate package first. CU, udo On 19/05/15 10:38, Sven Van Caekenberghe wrote: > >> On 19 May 2015, at 10:30, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >> >> Hi Sven, >> >> you got me :-) >> >> I had this as a package sometime ago for my own purposes (mDNS). So I knew it does work and how to do it. It's just I can't find that damned package anymore... > > Did you look in all your package caches ? > >>> I do think making all this cross platform could be a bit harder, we'll see. >> It's not that hard. The socket API is the same on all supported platforms. No surprises on *nix based OS. The only exception is Windows where the API is the same but where you might run into some packet drops due to strange personal FW products and "value-add" NDIS drivers for NICs. The situation has gotten much better though since Windows Vista/7 are using multicast for some of their services out of the box. >> >> I will recreate it though. Should I simply publish a package or add this as a slice? > > Thanks a lot, Udo, a good multicast example would be super cool. > > If it is just a small example, like one class, maybe it could be added to the image, in which case it should indeed be a slice. > > If it is larger and more application/framework oriented, then maybe a standalone package is more interesting. We try to keep the image as modular as possible. This route would be a bit more work for you, but might make more sense if you also see it possibly growing in the future. > >> Best Regards, >> >> Udo >> >> >> On 19/05/15 10:20, Sven Van Caekenberghe wrote: >>> Hi Udo, >>> >>> It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. >>> >>> I do think making all this cross platform could be a bit harder, we'll see. >>> >>> Sven >>> >>>> On 19 May 2015, at 00:17, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >>>> >>>> This should have been 'IP_ADD_MEMBERSHIP' of course: >>>> >>>> imrMultiaddr := #[239 255 255 250]. >>>> imrInterface := #[0 0 0 0]. >>>> ipMreq := imrMultiaddr , imrInterface. >>>> socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>>> >>>> >>>> The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: >>>> >>>> [ >>>> | udpSocket | >>>> udpSocket := Socket newUDP. >>>> udpSocket setPort: 1900. >>>> imrMultiaddr := #[239 255 255 251]. >>>> imrInterface := #[0 0 0 0]. >>>> ipMreq := imrMultiaddr , imrInterface. >>>> udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>>> udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. >>>> "udpSocket setOption: 'SO_REUSEADDR' value: 1." >>>> udpSocket waitForData. >>>> buffer := ByteArray new: 256. >>>> data := udpSocket receiveUDPDataInto: buffer. >>>> bytesRead := data at: 1. >>>> sender := data at: 2. >>>> senderPort := data at: 3. >>>> more := data at: 4. >>>> result := buffer copyFrom: 1 to: bytesRead. >>>> udpSocket closeAndDestroy. >>>> result asString inspect. >>>> ] fork. >>>> >>>> >>>> >>>> The "client" (execute in different playground): >>>> | message udpSocket | >>>> message := String crlf join: #( >>>> 'M-SEARCH * HTTP/1.1' >>>> 'HOST:239.255.255.250:1900' >>>> 'MAN:"ssdp:discover' >>>> 'ST:ssdp:all' >>>> 'MX:1' >>>> ''). >>>> >>>> udpSocket := Socket newUDP. >>>> udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. >>>> (udpSocket waitForSendDoneFor: 5). >>>> udpSocket closeAndDestroy. >>>> >>>> Hope this helps. >>>> >>>> CU, >>>> >>>> Udo >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 18/05/15 23:29, Udo Schneider wrote: >>>>> Hi Manfred, >>>>> >>>>> I just stumbled over the IP address you are using (239.255.255.250). If >>>>> I remember correctly this is a IPv4 Class D Multicast address. >>>>> (224.0.0.0-239.255.255.255). >>>>> >>>>> So if you want to transmit datagrams to this IP address or recieve >>>>> datagrams sent to this multicast groups you have to set appropriate IP >>>>> Options. >>>>> >>>>> You can set this options using Socket>>#setOption:value: and read them >>>>> using Socket>>#getOption:. Please note that both methods expect the >>>>> option to set as a name - not as constant. E.g. >>>>> >>>>> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >>>>> >>>>> If I do remember correctly you have to set the following options for >>>>> sending/receiving: >>>>> >>>>> Sending: >>>>> IP_MULTICAST_IF >>>>> (IP_MULTICAST_LOOP) >>>>> (IP_MULTICAST_TTL) >>>>> >>>>> Sending should AFAIK work w/o setting any option - although >>>>> IP_MULTICAST_IF is highly recommended. >>>>> >>>>> Receiving: >>>>> (SO_REUSEADDR) >>>>> IP_ADD_MEMBERSHIP >>>>> (IP_DROP_MEMBERSHIP) >>>>> >>>>> Receiving only works if you joined the multicast group previously. So I >>>>> assume that you need to do something like this (not tested). >>>>> >>>>> imrMultiaddr := #[239 255 255 250]. >>>>> imrInterface := #[0 0 0 0]. >>>>> ipMreq := imrMultiaddr , imrInterface. >>>>> socket setOption: 'MEMBERSHIP' value: ipMreq. >>>>> >>>>> Hope this helps. >>>>> >>>>> CU, >>>>> >>>>> Udo >>>>> >>>>> >>>>> >>>>> On 18/05/15 16:34, Manfred KrÃ¶hnert wrote: >>>>>> Hi Sven, >>>>>> >>>>>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>>>>> <sven(a)stfx.eu >>>>>> <mailto:sven@stfx.eu>> wrote: >>>>>> >>>>>> >>>>>> > On 18 May 2015, at 15:47, Manfred KrÃ¶hnert >>>>>> <mkroehnert42(a)googlemail.com >>>>>> <mailto:mkroehnert42@googlemail.com>> wrote: >>>>>> > >>>>>> > Hi, >>>>>> > apparently I am missing something else. >>>>>> > >>>>>> > I can find devices when connected to a 'regular' LAN. >>>>>> > >>>>>> > However, I have a camera that creates a Wifi accesspoint and >>>>>> makes itself discoverable via SSDP. >>>>>> > Once I connect to this accesspoint my computer gets a valid IP >>>>>> address assigned and the NodeJS code is able to discover the device. >>>>>> > Unfortunately, the Pharo snippet I posted before does not give me >>>>>> any results and hangs in Socket>>waitForDataIfClosed: . >>>>>> > >>>>>> > Any further ideas? >>>>>> >>>>>> Are you sure you restarted the image and your code after switching >>>>>> networks ? >>>>>> >>>>>> >>>>>> I did not check this before. >>>>>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>>>>> it after connecting to the camera accesspoint. >>>>>> The code snippet freezes there as well. >>>>>> >>>>>> Manfred >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > >

May 19, 2015

Displaying pictures using Athens

by Christopher Coat

Hi everybody, Iâm currently creating a small app to display images and move them on a screen using Athens. I have all my image loaded on start and I use a loop to clear the screen and redraw all the elements (on different place and angle) every frames. The problem is that with morph, everything is fine, but as soon as I place a picture on a morph the FPS drop down. Even if the picture is a small one. Does anybody have faced the same issue ? Or is there any better way to do it ? Thanks Chris

May 19, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Sven Van Caekenberghe

> On 19 May 2015, at 10:30, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > > Hi Sven, > > you got me :-) > > I had this as a package sometime ago for my own purposes (mDNS). So I knew it does work and how to do it. It's just I can't find that damned package anymore... Did you look in all your package caches ? > > I do think making all this cross platform could be a bit harder, we'll see. > It's not that hard. The socket API is the same on all supported platforms. No surprises on *nix based OS. The only exception is Windows where the API is the same but where you might run into some packet drops due to strange personal FW products and "value-add" NDIS drivers for NICs. The situation has gotten much better though since Windows Vista/7 are using multicast for some of their services out of the box. > > I will recreate it though. Should I simply publish a package or add this as a slice? Thanks a lot, Udo, a good multicast example would be super cool. If it is just a small example, like one class, maybe it could be added to the image, in which case it should indeed be a slice. If it is larger and more application/framework oriented, then maybe a standalone package is more interesting. We try to keep the image as modular as possible. This route would be a bit more work for you, but might make more sense if you also see it possibly growing in the future. > Best Regards, > > Udo > > > On 19/05/15 10:20, Sven Van Caekenberghe wrote: >> Hi Udo, >> >> It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. >> >> I do think making all this cross platform could be a bit harder, we'll see. >> >> Sven >> >>> On 19 May 2015, at 00:17, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >>> >>> This should have been 'IP_ADD_MEMBERSHIP' of course: >>> >>> imrMultiaddr := #[239 255 255 250]. >>> imrInterface := #[0 0 0 0]. >>> ipMreq := imrMultiaddr , imrInterface. >>> socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>> >>> >>> The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: >>> >>> [ >>> | udpSocket | >>> udpSocket := Socket newUDP. >>> udpSocket setPort: 1900. >>> imrMultiaddr := #[239 255 255 251]. >>> imrInterface := #[0 0 0 0]. >>> ipMreq := imrMultiaddr , imrInterface. >>> udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >>> udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. >>> "udpSocket setOption: 'SO_REUSEADDR' value: 1." >>> udpSocket waitForData. >>> buffer := ByteArray new: 256. >>> data := udpSocket receiveUDPDataInto: buffer. >>> bytesRead := data at: 1. >>> sender := data at: 2. >>> senderPort := data at: 3. >>> more := data at: 4. >>> result := buffer copyFrom: 1 to: bytesRead. >>> udpSocket closeAndDestroy. >>> result asString inspect. >>> ] fork. >>> >>> >>> >>> The "client" (execute in different playground): >>> | message udpSocket | >>> message := String crlf join: #( >>> 'M-SEARCH * HTTP/1.1' >>> 'HOST:239.255.255.250:1900' >>> 'MAN:"ssdp:discover' >>> 'ST:ssdp:all' >>> 'MX:1' >>> ''). >>> >>> udpSocket := Socket newUDP. >>> udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. >>> (udpSocket waitForSendDoneFor: 5). >>> udpSocket closeAndDestroy. >>> >>> Hope this helps. >>> >>> CU, >>> >>> Udo >>> >>> >>> >>> >>> >>> >>> On 18/05/15 23:29, Udo Schneider wrote: >>>> Hi Manfred, >>>> >>>> I just stumbled over the IP address you are using (239.255.255.250). If >>>> I remember correctly this is a IPv4 Class D Multicast address. >>>> (224.0.0.0-239.255.255.255). >>>> >>>> So if you want to transmit datagrams to this IP address or recieve >>>> datagrams sent to this multicast groups you have to set appropriate IP >>>> Options. >>>> >>>> You can set this options using Socket>>#setOption:value: and read them >>>> using Socket>>#getOption:. Please note that both methods expect the >>>> option to set as a name - not as constant. E.g. >>>> >>>> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >>>> >>>> If I do remember correctly you have to set the following options for >>>> sending/receiving: >>>> >>>> Sending: >>>> IP_MULTICAST_IF >>>> (IP_MULTICAST_LOOP) >>>> (IP_MULTICAST_TTL) >>>> >>>> Sending should AFAIK work w/o setting any option - although >>>> IP_MULTICAST_IF is highly recommended. >>>> >>>> Receiving: >>>> (SO_REUSEADDR) >>>> IP_ADD_MEMBERSHIP >>>> (IP_DROP_MEMBERSHIP) >>>> >>>> Receiving only works if you joined the multicast group previously. So I >>>> assume that you need to do something like this (not tested). >>>> >>>> imrMultiaddr := #[239 255 255 250]. >>>> imrInterface := #[0 0 0 0]. >>>> ipMreq := imrMultiaddr , imrInterface. >>>> socket setOption: 'MEMBERSHIP' value: ipMreq. >>>> >>>> Hope this helps. >>>> >>>> CU, >>>> >>>> Udo >>>> >>>> >>>> >>>> On 18/05/15 16:34, Manfred KrÃ¶hnert wrote: >>>>> Hi Sven, >>>>> >>>>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>>>> <sven(a)stfx.eu >>>>> <mailto:sven@stfx.eu>> wrote: >>>>> >>>>> >>>>> > On 18 May 2015, at 15:47, Manfred KrÃ¶hnert >>>>> <mkroehnert42(a)googlemail.com >>>>> <mailto:mkroehnert42@googlemail.com>> wrote: >>>>> > >>>>> > Hi, >>>>> > apparently I am missing something else. >>>>> > >>>>> > I can find devices when connected to a 'regular' LAN. >>>>> > >>>>> > However, I have a camera that creates a Wifi accesspoint and >>>>> makes itself discoverable via SSDP. >>>>> > Once I connect to this accesspoint my computer gets a valid IP >>>>> address assigned and the NodeJS code is able to discover the device. >>>>> > Unfortunately, the Pharo snippet I posted before does not give me >>>>> any results and hangs in Socket>>waitForDataIfClosed: . >>>>> > >>>>> > Any further ideas? >>>>> >>>>> Are you sure you restarted the image and your code after switching >>>>> networks ? >>>>> >>>>> >>>>> I did not check this before. >>>>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>>>> it after connecting to the camera accesspoint. >>>>> The code snippet freezes there as well. >>>>> >>>>> Manfred >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > >

May 19, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Udo Schneider

Hi Sven, you got me :-) I had this as a package sometime ago for my own purposes (mDNS). So I knew it does work and how to do it. It's just I can't find that damned package anymore... > I do think making all this cross platform could be a bit harder, we'll see. It's not that hard. The socket API is the same on all supported platforms. No surprises on *nix based OS. The only exception is Windows where the API is the same but where you might run into some packet drops due to strange personal FW products and "value-add" NDIS drivers for NICs. The situation has gotten much better though since Windows Vista/7 are using multicast for some of their services out of the box. I will recreate it though. Should I simply publish a package or add this as a slice? Best Regards, Udo On 19/05/15 10:20, Sven Van Caekenberghe wrote: > Hi Udo, > > It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. > > I do think making all this cross platform could be a bit harder, we'll see. > > Sven > >> On 19 May 2015, at 00:17, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: >> >> This should have been 'IP_ADD_MEMBERSHIP' of course: >> >> imrMultiaddr := #[239 255 255 250]. >> imrInterface := #[0 0 0 0]. >> ipMreq := imrMultiaddr , imrInterface. >> socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >> >> >> The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: >> >> [ >> | udpSocket | >> udpSocket := Socket newUDP. >> udpSocket setPort: 1900. >> imrMultiaddr := #[239 255 255 251]. >> imrInterface := #[0 0 0 0]. >> ipMreq := imrMultiaddr , imrInterface. >> udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. >> udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. >> "udpSocket setOption: 'SO_REUSEADDR' value: 1." >> udpSocket waitForData. >> buffer := ByteArray new: 256. >> data := udpSocket receiveUDPDataInto: buffer. >> bytesRead := data at: 1. >> sender := data at: 2. >> senderPort := data at: 3. >> more := data at: 4. >> result := buffer copyFrom: 1 to: bytesRead. >> udpSocket closeAndDestroy. >> result asString inspect. >> ] fork. >> >> >> >> The "client" (execute in different playground): >> | message udpSocket | >> message := String crlf join: #( >> 'M-SEARCH * HTTP/1.1' >> 'HOST:239.255.255.250:1900' >> 'MAN:"ssdp:discover' >> 'ST:ssdp:all' >> 'MX:1' >> ''). >> >> udpSocket := Socket newUDP. >> udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. >> (udpSocket waitForSendDoneFor: 5). >> udpSocket closeAndDestroy. >> >> Hope this helps. >> >> CU, >> >> Udo >> >> >> >> >> >> >> On 18/05/15 23:29, Udo Schneider wrote: >>> Hi Manfred, >>> >>> I just stumbled over the IP address you are using (239.255.255.250). If >>> I remember correctly this is a IPv4 Class D Multicast address. >>> (224.0.0.0-239.255.255.255). >>> >>> So if you want to transmit datagrams to this IP address or recieve >>> datagrams sent to this multicast groups you have to set appropriate IP >>> Options. >>> >>> You can set this options using Socket>>#setOption:value: and read them >>> using Socket>>#getOption:. Please note that both methods expect the >>> option to set as a name - not as constant. E.g. >>> >>> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >>> >>> If I do remember correctly you have to set the following options for >>> sending/receiving: >>> >>> Sending: >>> IP_MULTICAST_IF >>> (IP_MULTICAST_LOOP) >>> (IP_MULTICAST_TTL) >>> >>> Sending should AFAIK work w/o setting any option - although >>> IP_MULTICAST_IF is highly recommended. >>> >>> Receiving: >>> (SO_REUSEADDR) >>> IP_ADD_MEMBERSHIP >>> (IP_DROP_MEMBERSHIP) >>> >>> Receiving only works if you joined the multicast group previously. So I >>> assume that you need to do something like this (not tested). >>> >>> imrMultiaddr := #[239 255 255 250]. >>> imrInterface := #[0 0 0 0]. >>> ipMreq := imrMultiaddr , imrInterface. >>> socket setOption: 'MEMBERSHIP' value: ipMreq. >>> >>> Hope this helps. >>> >>> CU, >>> >>> Udo >>> >>> >>> >>> On 18/05/15 16:34, Manfred KrÃ¶hnert wrote: >>>> Hi Sven, >>>> >>>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>>> <sven(a)stfx.eu >>>> <mailto:sven@stfx.eu>> wrote: >>>> >>>> >>>> > On 18 May 2015, at 15:47, Manfred KrÃ¶hnert >>>> <mkroehnert42(a)googlemail.com >>>> <mailto:mkroehnert42@googlemail.com>> wrote: >>>> > >>>> > Hi, >>>> > apparently I am missing something else. >>>> > >>>> > I can find devices when connected to a 'regular' LAN. >>>> > >>>> > However, I have a camera that creates a Wifi accesspoint and >>>> makes itself discoverable via SSDP. >>>> > Once I connect to this accesspoint my computer gets a valid IP >>>> address assigned and the NodeJS code is able to discover the device. >>>> > Unfortunately, the Pharo snippet I posted before does not give me >>>> any results and hangs in Socket>>waitForDataIfClosed: . >>>> > >>>> > Any further ideas? >>>> >>>> Are you sure you restarted the image and your code after switching >>>> networks ? >>>> >>>> >>>> I did not check this before. >>>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>>> it after connecting to the camera accesspoint. >>>> The code snippet freezes there as well. >>>> >>>> Manfred >>> >>> >>> >>> >> >> >> > > >

May 19, 2015

Re: [Pharo-users] Issue with UDP Sockets

by Sven Van Caekenberghe

Hi Udo, It would be good if some of this knowledge could be added inside the image, as class comment or methods comments. Even better would be an example combined with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test would then actively ensure this functionality is protected. I do think making all this cross platform could be a bit harder, we'll see. Sven > On 19 May 2015, at 00:17, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > > This should have been 'IP_ADD_MEMBERSHIP' of course: > > imrMultiaddr := #[239 255 255 250]. > imrInterface := #[0 0 0 0]. > ipMreq := imrMultiaddr , imrInterface. > socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. > > > The "server" could be something like this (execute in first playground). I used another IP address (#[239 255 255 251]) because #[239 255 255 250] might already be part of the multicast group because of other processes and this shows the "whole" process of subscribing to a multicast group: > > [ > | udpSocket | > udpSocket := Socket newUDP. > udpSocket setPort: 1900. > imrMultiaddr := #[239 255 255 251]. > imrInterface := #[0 0 0 0]. > ipMreq := imrMultiaddr , imrInterface. > udpSocket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq. > udpSocket setOption: 'IP_MULTICAST_LOOP' value: 1. > "udpSocket setOption: 'SO_REUSEADDR' value: 1." > udpSocket waitForData. > buffer := ByteArray new: 256. > data := udpSocket receiveUDPDataInto: buffer. > bytesRead := data at: 1. > sender := data at: 2. > senderPort := data at: 3. > more := data at: 4. > result := buffer copyFrom: 1 to: bytesRead. > udpSocket closeAndDestroy. > result asString inspect. > ] fork. > > > > The "client" (execute in different playground): > | message udpSocket | > message := String crlf join: #( > 'M-SEARCH * HTTP/1.1' > 'HOST:239.255.255.250:1900' > 'MAN:"ssdp:discover' > 'ST:ssdp:all' > 'MX:1' > ''). > > udpSocket := Socket newUDP. > udpSocket sendData: message toHost: #[239 255 255 251] port: 1900. > (udpSocket waitForSendDoneFor: 5). > udpSocket closeAndDestroy. > > Hope this helps. > > CU, > > Udo > > > > > > > On 18/05/15 23:29, Udo Schneider wrote: >> Hi Manfred, >> >> I just stumbled over the IP address you are using (239.255.255.250). If >> I remember correctly this is a IPv4 Class D Multicast address. >> (224.0.0.0-239.255.255.255). >> >> So if you want to transmit datagrams to this IP address or recieve >> datagrams sent to this multicast groups you have to set appropriate IP >> Options. >> >> You can set this options using Socket>>#setOption:value: and read them >> using Socket>>#getOption:. Please note that both methods expect the >> option to set as a name - not as constant. E.g. >> >> socket setOption: 'IP_MULTICAST_IF' value: multicastInterface. >> >> If I do remember correctly you have to set the following options for >> sending/receiving: >> >> Sending: >> IP_MULTICAST_IF >> (IP_MULTICAST_LOOP) >> (IP_MULTICAST_TTL) >> >> Sending should AFAIK work w/o setting any option - although >> IP_MULTICAST_IF is highly recommended. >> >> Receiving: >> (SO_REUSEADDR) >> IP_ADD_MEMBERSHIP >> (IP_DROP_MEMBERSHIP) >> >> Receiving only works if you joined the multicast group previously. So I >> assume that you need to do something like this (not tested). >> >> imrMultiaddr := #[239 255 255 250]. >> imrInterface := #[0 0 0 0]. >> ipMreq := imrMultiaddr , imrInterface. >> socket setOption: 'MEMBERSHIP' value: ipMreq. >> >> Hope this helps. >> >> CU, >> >> Udo >> >> >> >> On 18/05/15 16:34, Manfred KrÃ¶hnert wrote: >>> Hi Sven, >>> >>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe >>> <sven(a)stfx.eu >>> <mailto:sven@stfx.eu>> wrote: >>> >>> >>> > On 18 May 2015, at 15:47, Manfred KrÃ¶hnert >>> <mkroehnert42(a)googlemail.com >>> <mailto:mkroehnert42@googlemail.com>> wrote: >>> > >>> > Hi, >>> > apparently I am missing something else. >>> > >>> > I can find devices when connected to a 'regular' LAN. >>> > >>> > However, I have a camera that creates a Wifi accesspoint and >>> makes itself discoverable via SSDP. >>> > Once I connect to this accesspoint my computer gets a valid IP >>> address assigned and the NodeJS code is able to discover the device. >>> > Unfortunately, the Pharo snippet I posted before does not give me >>> any results and hangs in Socket>>waitForDataIfClosed: . >>> > >>> > Any further ideas? >>> >>> Are you sure you restarted the image and your code after switching >>> networks ? >>> >>> >>> I did not check this before. >>> But I just downloaded a fresh 40613 image with PharoLauncher and started >>> it after connecting to the camera accesspoint. >>> The code snippet freezes there as well. >>> >>> Manfred >> >> >> >> > > >

May 19, 2015

Re: [Pharo-users] Alt-tab between windows

by Dimitris Chloupis

As you linked in your blog post there are my video tutorials , one of them are about window groups https://www.youtube.com/watch?v=GGJZeajjWGU About general GUI and UI designs its not any less nightmarish to open multiple windows in Pharo than it is to open multiple buffers in emacs. The diffirence between the two is that with emacs you have the nightmare of lack of any GUI while in pharo you have the lack of sophisticated editing. My personal opinion on UIs is that I look around and all I see is a huge mess. The modern effort to turn to minimalism and try to minimise this phenomenon , fails miserably. Web is even messier because of fragmentation and lack of cohesion you ending up with a billion different UIs that fail the same way. What the modern world needs is not minimalism but rather I high complex system that can deal with complexity and extremely varied demands. That would require a large body of developers to sit down and do thorough research to solve the problem of ever increasingly complex software. I work with 3d graphics that are notorious for their inherit complexity, the situation has been getting so bad lately , that age of "one software to rule them all" has come to pass and we see more and more fragmentation that makes life even more difficult. Pharo is doing some good work on this area but realistically , the community is too small to solve such a huge problem even with pharo ease of use. On Tue, May 19, 2015 at 6:46 AM Avdi Grimm <avdi(a)avdi.org> wrote: > > On Mon, May 18, 2015 at 11:06 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> As a step in this direction, the Window Menu (small arrow in title >> bar) item "Create window group" may provide part of the behaviour you are >> looking for. > > > Interesting! How does one add more than one window to the group? Is there > more info on this somewhere? > > > -- > Avdi Grimm > http://avdi.org > >

May 19, 2015