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

Re: [Pharo-users] About Box

by stepharo

Welcome! Stef Le 11/4/16 20:40, Alistair Grant a Ã©crit : > Hi Serge, > > On Mon, Apr 11, 2016 at 09:46:02AM +0200, Serge Stinckwich wrote: >> On Mon, Apr 11, 2016 at 8:57 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> Also my first week with Pharo, and first week with Smalltalk in over 20 years. >> Congrats ! >> Tell us what is your experience until now ;-) > I was the technical lead of a team that programmed with VisualWorks 2.5 > for several years in the 90's, porting it to VMS (VAX and Aplha) and > writing a real-time graphical interface for monitoring and controlling > the water distribution in one of the capital cities in Australia > (Brisbane). > > The UI allowed users to build a library of widgets from basic shapes, > e.g. valves, pumps, reservoirs, etc. They could then be built up to > schematics and attached to a real-time database, receiving events > whenever a value changed. E.g. valves would change shape or colour > depending on whether they were open or closed, alarms would flash, a > pump would show its flow rate, etc. > > We tested it receiving up to 1200 events per second (this was in the > days when a 100MHz RISC processor was the best available (from memory)). > All the graphics, event management and query optimisation were in > Smalltalk, the database query execution and event delivery was in C (the > database was in-memory and didn't support any query language, that all > had to be done by the client). > > I left the company a year or so later. I heard that it was replaced > some years after I left, but I'm not sure when that happened. > > Cheers, > Alistair > >

April 12, 2016

Re: [Pharo-users] Dawn Theme on Pharo 4.0

by stepharo

Check the code because it should just be a subclass of the dark theme with different colors. Stef Le 12/4/16 16:22, Siemen Baader a Ã©crit : > Hi all, > > has anybody had luck using Sebastian's Dawn Theme [1] on Pharo 4.0? The > instructions on github are for Pharo 3.0 - what would I do to make it work > on my 4.0 image? > > thanks, > Siemen > > 1: https://github.com/sebastianconcept/Pharo3DawnTheme > > > > -- > View this message in context: http://forum.world.st/Dawn-Theme-on-Pharo-4-0-tp4889541.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 12, 2016

List with Border

by Bruce Peaslee

Hi, This code creates the list and fills it, but it does not show a border. initializeWidgets transactionList := ListModel new. transactionList items: #('one' 'two' 'three'). transactionList borderWidth: 2; borderColor: Color red.

April 12, 2016

Re: [Pharo-users] FFI return by reference

by Esteban Lorenzano

> On 12 Apr 2016, at 09:44, Thibault Raffaillac <thibault.raffaillac(a)inria.fr> wrote: > >> I will not add for the moment that predefined types value holders? We would >> need to add one for each type we support to be consistent, and document it, >> and add tests. >> And btw? you do have a generic holder? is just that you need to refine it to >> what you want :) > > Couldn't we use FFIInt32? To me it would make sense to use the class to refer to the type, and an instance of it for a value holder in memory (this is not asking for a change, only reporting it looks strange). nope. we try to hide the border between âinâ and âoutâ to make the FFI experience simplerâ¦ but it is there. immutable types (like integers in Pharo) cannot be swap (become) and because of that we cannot make the pack/unpack algorithm to work in any efficient way. The benefit to have this functionality does not pay the performance penalty for doing it (it introduces an extra check for any parameter marshalled). So, for nowâ¦ no, we cannotâ¦ you need to stick with the value holder :( Esteban > >> My advise is that you go with what you need, we can consider add predefined >> value holders later. > > Yep, I am sticking to the basic features as much as possible anyway. > > Cheers, > Thibault >

April 12, 2016

Dawn Theme on Pharo 4.0

by Siemen Baader

Hi all, has anybody had luck using Sebastian's Dawn Theme [1] on Pharo 4.0? The instructions on github are for Pharo 3.0 - what would I do to make it work on my 4.0 image? thanks, Siemen 1: https://github.com/sebastianconcept/Pharo3DawnTheme -- View this message in context: http://forum.world.st/Dawn-Theme-on-Pharo-4-0-tp4889541.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 12, 2016

Re: [Pharo-users] New project: AR.Drone communication API in Pharo

by Johan Fabry

I forgot to ask, will this work with a PS2 joystick? We have one available in the robotics lab that we can use for that. > On Apr 12, 2016, at 02:41, Carolina HernÃ¡ndez <carola.hp(a)gmail.com> wrote: > > Hi Ronnie, that's is really nice! > > I'm talking to you in private > > 2016-04-10 7:05 GMT-03:00 Ronie Salgado <roniesalg(a)gmail.com <mailto:roniesalg@gmail.com>>: > Ok, I made a cleanup on the OSWindow joystick support. I also added the OSWindowGenericRenderer interface which is implemented by a thin wrapper around the SDL2 renderer interface. I have tested this on Linux using a XBox 360 controller (using SDL2 GameController interface) and a PS2 controller via an USB adapter (using SDL2 Joystick interface). Later I will test it on Windows and Mac. > > ============================= > Here is the demo: https://www.youtube.com/watch?v=lABfEmToHLQ&feature=youtu.be <https://www.youtube.com/watch?v=lABfEmToHLQ&feature=youtu.be> > > OSWindowJoystickExample new open. > > Xbox 360/mapped controls > Left stick: move character > X button: shoot > Start: reset > > ============================= > > I also added a simple examples using the OSWindowGenericRenderer: > > OSWindowGenericRendererDrawingExample new open. > > ============================= > > I also modified the OSSDL2Driver >> #isSuitable method to not call the hasPlugin method. The plugin seems to be unnecessary according to several posts, and I am too lazy for fixing it. I guess that this should be eventually integrated into Pharo 5 after some reviewing. Before that, the latest version of OSWindow should be loaded manually. For that, the packages should be loaded in the following order: > > OSWindow-Core > OSWindow-SDL2 > OSWindow-SDL2-Examples > > After that, the following doIt is required in a playground to start receiving events: > > SDL2Constants initialize. > SDL_Event initialize > > Best regards, > Ronie > > 2016-04-10 3:15 GMT-03:00 phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@highoctane.be>>: > There is joystick support in 4.0, but not in Unix (plugin looks pretty empty). > > Smalltalk vm listBuiltinModules select: [ :each | each beginsWith: 'Joystick' ]. > > JoystickTabletPlugin VMMaker-oscog-nice13154.314 > > So, it is all in the InputEventSensor > > Check for senders of primReadJoystick: > > --> joystickXY:, joystickButtons: ... > > Phil > > > On Sun, Apr 10, 2016 at 1:18 AM, Stephan Eggermont <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: > On 09-04-16 15:24, Carolina HernÃ¡ndez wrote: > I couldn't find any direct way to use a joystick in Pharo, if someone knows > about one, I'd like to integrate it to my code. > https://github.com/Geal/Squeak-VM/tree/master/platforms/Mac%20OS/plugins/Jo… <https://github.com/Geal/Squeak-VM/tree/master/platforms/Mac%20OS/plugins/Jo…> > > Refers to a joystick plugin for squeak. I don't know if that is in the current distribution > (it doesn't seem to be), so you might ask on the vm-dev list about it. I haven't looked > at it, so it could be for a RS-232 based joystick instead of something more useful with > a modern pc. > > Can't SDL2 be used with a joystick? > > Stephan > > > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

April 12, 2016

Re: [Pharo-users] New project: AR.Drone communication API in Pharo

by Johan Fabry

> On Apr 12, 2016, at 00:52, Carolina HernÃ¡ndez <carola.hp(a)gmail.com> wrote: > > Hi Krish > Thanks for all your comments. I agree with Krish that the code is well done, plus the documentation is very complete, I like that a lot! > About the #initialize method, I think you are right, and some code refactoring would solve it. Yes, I would move both block definitions to their separate methods, that should make the code more readable. > Also, about the #takeOff method, maybe the comments are not so explicative, but it just sends the take off command until the drone is actually flying. In practice, it sends it twice and then stops. The logic for the land command is very similar. They are designed that way to ensure the drone will take off or land after only one call of the corresponding method. For me at least the comment in takeOff is clear. > Thanks for your advice on avoiding Float and Integer overrides, it would be cleaner to include the methods in the ARDrone package. Indeed, I think it would be better to have these on ARDCommandManager, as it is the only place they are used and furthermore donât rely on private state of Float or Integer. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

April 12, 2016

Re: [Pharo-users] New project: AR.Drone communication API in Pharo

by Johan Fabry

Hola Hernan, Carolina is doing cool work, which is why I pushed her to make this announcement and video :-) I first want to get LRP working with the drone (more on LRP also on http://pleiad.cl/LRP <http://pleiad.cl/LRP> ). The philosophy of LRP is to do as much as possible on real hardware for a fast development cycle, so simulation of the drone is a very low priority right now. Carolina told me there are more features inside the drone, for augmented reality stuff if I remember correctly. So we will first investigate that to see if we can get more features inside LRP, because that sounds really cool. > On Apr 12, 2016, at 00:27, Carolina HernÃ¡ndez <carola.hp(a)gmail.com> wrote: > > Hi HernÃ¡n, not for now, since my main goal is to make possible to program behaviors for the drone using the language LRP (Live Robot Programming). However, since I am using a spiral development method, I may consider it in a further stage. Thanks for the suggestion! > > Caro > > About LRP: > http://pleiad.dcc.uchile.cl/papers/2014/fabryAl-iberamia14.pdf <http://pleiad.dcc.uchile.cl/papers/2014/fabryAl-iberamia14.pdf> > > 2016-04-09 10:58 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>>: > Hi Carolina, > > Thank you for sharing. > Do you plan to support gazebo or tum_simulator in your API? > > HernÃ¡n > > http://gazebosim.org/ <http://gazebosim.org/> > http://wiki.ros.org/tum_simulator <http://wiki.ros.org/tum_simulator> > > > 2016-04-09 10:24 GMT-03:00 Carolina HernÃ¡ndez <carola.hp(a)gmail.com <mailto:carola.hp@gmail.com>>: > Hi, my name is Carolina Hernandez and I'm a Computer Engineering student at the University of Chile. > As part of my final degree project, I'm creating a communication API for controlling the Parrot AR.Drone 2.0 from Pharo. I've just released an early version. The code is hosted in Smalltalkhub: > http://smalltalkhub.com/#!/~CaroHernandez/ArDronePharo <http://smalltalkhub.com/#!/~CaroHernandez/ArDronePharo> > > I also made a video of a test flight, where the AR.Drone is controlled using the API and keyboard: > https://www.youtube.com/watch?v=d8rERiBoD0o <https://www.youtube.com/watch?v=d8rERiBoD0o> > > I couldn't find any direct way to use a joystick in Pharo, if someone knows about one, I'd like to integrate it to my code. > > Development and tests have been done in Pharo 4.0 and ubuntu 12.04 > Comments are welcome! > > Caro > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

April 12, 2016

Re: [Pharo-users] MessageDialogWindow(s)

by Stephan Eggermont

On 12-04-16 14:25, Rob Rothwell wrote: > Thanks, Stephan...I apologize for my slowness... No problem, mailing list is asynchronous. Sometimes you have time, sometimes not Stephan

April 12, 2016

Re: [Pharo-users] FFI return by reference

by Thibault Raffaillac

> I will not add for the moment that predefined types value holders? We would > need to add one for each type we support to be consistent, and document it, > and add tests. > And btw? you do have a generic holder? is just that you need to refine it to > what you want :) Couldn't we use FFIInt32? To me it would make sense to use the class to refer to the type, and an instance of it for a value holder in memory (this is not asking for a change, only reporting it looks strange). > My advise is that you go with what you need, we can consider add predefined > value holders later. Yep, I am sticking to the basic features as much as possible anyway. Cheers, Thibault

April 12, 2016