- Pharo-users - lists.pharo.org

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

by Carolina HernÃ¡ndez

Hi Krish Thanks for all your comments. About the #initialize method, I think you are right, and some code refactoring would solve it. 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. Thanks for your advice on avoiding Float and Integer overrides, it would be cleaner to include the methods in the ARDrone package. Cheers Caro 2016-04-09 13:56 GMT-03:00 S Krish <krishnamachari.sudhakar(a)gmail.com>: > > Very interesting and well done. > > *Observations: from a 15 min review. beyond the basics .. which really is > well done. Hope I can play with it sometime when I get time.. * > > Love the commandQueue and UDP handling and this block: > > senderProcess := [[ | nextCommand | > "dequeue the next command, enumerate it and send it" > nextCommand := commandsQueue next . > arDrone commandAdapter send: nextCommand > ] repeat ] fork. > > I like the comments in #*sendMoveCommandLeftRightTilt*: lrTilt > *frontBackTilt*: fbTilt *verticalSpeed*: verticalSpeed *angularSpeed*: > angularSpeed > > > But the #initialize method is doing too much in one long method.. check > other methods too.. > > > *Comments: * > > takeOff > "Every 1 second sends the take off command to the drone, until it's state > goes from Landed to Flying (ARDState flyMask from 0 to 1)" > > Either the naming can be keepFlying .. not sure if I want > to takeOff every second. > > > Advice avoiding overrides on Integer and Float given its not really needed > and you can do that in your own class in the package. > > viz: #*from32BitArrayWithOnesAt*: > > > > > > On Sat, Apr 9, 2016 at 8:24 AM, Carolina HernÃ¡ndez <carola.hp(a)gmail.com> > wrote: > >> 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 >> >> 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 >> >> 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 >> > >

April 12, 2016

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

by Carolina HernÃ¡ndez

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 2016-04-09 10:58 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)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://wiki.ros.org/tum_simulator > > > 2016-04-09 10:24 GMT-03:00 Carolina HernÃ¡ndez <carola.hp(a)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 >> >> 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 >> >> 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 >> > >

April 12, 2016

Re: [Pharo-users] MessageDialogWindow(s)

by Stephan Eggermont

On 11/04/16 18:53, Rob Rothwell wrote: > Where can I learn how to open a bug entry and/or how to submit a fix? http://pharo.org/contribute Create an account at pharo.fogbugz.com, log in and add a new issue. Select the image version the bug should be fixed against and the priority. Describe it by copying the relevant information from these posts. A fix is created by taking the latest version of the pharo image (of the right version), making the change there, ideally adding a a test that fails in the buggy situation and succeeds with the fix. In Monticello, create a slice containing only the packages that you needed to change. If you type the issue number in the slice field, its description will be automatically downloaded. Commit the slice to the pharo inbox for the right version, copy the commit text to the clipboard. (that assumes that you signed the contributors license agreement and have commit rights to the inbox). In the issue tracker, click on resolve, paste the commit text and select Resolved (Fix Review Needed). That will trigger the Monkey to run system tests. Once it passes, someone else should review the fix so it can be Resolved (Fix To Include). (Sometimes, the monkey times out, and you need to tell it to run again). Stephan

April 11, 2016

Re: [Pharo-users] About Box

by Serge Stinckwich

Thank you. I was talking about your experience with Pharo :-) But your description is nice also. Regards, On Mon, Apr 11, 2016 at 8:40 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > 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 > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 11, 2016

Re: [Pharo-users] About Box

by Alistair Grant

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 11, 2016

Re: [Pharo-users] MessageDialogWindow(s)

by Rob Rothwell

On Mon, Apr 11, 2016 at 2:52 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-04-11 8:29 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > >> On 11-04-16 02:00, Robert J Rothwell wrote: >> >>> Should >>> >>> (MessageDialogWindow new text: 'Hello') open >>> >>> work? >>> >>> I get a stack trace on CompositionScanner if I try to set the text. >>> >> >> Yes. Please open a bug entry. (If you want to help, try with a few older >> versions >> of pharo to find out when the bug was introduced) > > Where can I learn how to open a bug entry and/or how to submit a fix? > >> > Yes, maybe MessageDialogWindow should init the font with a default font. > You are correct; adding: MessageDialogWindow>>initialize ^super initialize textFont: (Smalltalk ui theme textFont) Corrects the problem in Pharo 4.0 and Pharo 5.0 > > >> Also, is there a way to display the dialog modally (relative to your >>> application)? >>> >>> Take a look at Morph>openModal: >> > Thank you! > >> Stephan >> >> > And this DialogWindow classes are used by UITheme, for example > > Smalltalk ui theme messageIn:World text:'Some MessageText' title:'The > Title'. > or for long messages: > Smalltalk ui theme longMessageIn:World text: ProfStef > pharoZenValuesContents title:'Pharo Zen'. > > The "World" argument specifies to which Window this Dialog should be modal. > This seems like what I should have done in the first place! Rob

April 11, 2016

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

by Sean P. DeNigris

stepharo wrote > this is cool +1! ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-project-AR-Drone-communication-API-in-Pharo-tp488… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 11, 2016

Re: [Pharo-users] About Box

by Sean P. DeNigris

Alistair Grant wrote > Also my first week with Pharo, and first week with Smalltalk in over 20 > years. How exciting! Three oldtime Smalltalkers discovering Pharo in a week... and, letting us know :) Welcome. ----- Cheers, Sean -- View this message in context: http://forum.world.st/About-Box-tp4889296p4889383.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 11, 2016

Re: [Pharo-users] finding Pharo Launcher

by Damien Cassou

Mark Bestley <st(a)bestley.co.uk> writes: > On 11/04/2016 12:56, Damien Cassou wrote: >> several persons believe the launcher is not ready to be the default >> download for everyone. Unfortunately, nobody has time to work on it. >> > Is there a list ot things that need to be fixed for this to happen https://github.com/pharo-project/pharo-launcher/issues I think some people have had a hard time understanding the GUI. That's why I designed a prototype: https://github.com/pharo-rocker/rocker-brick/tree/master/mockups -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 11, 2016

Re: [Pharo-users] FFI return by reference

by Esteban Lorenzano

> On 11 Apr 2016, at 06:24, Thibault Raffaillac <thibault.raffaillac(a)inria.fr> wrote: > >>> 1) Declare a class variable >>> >>> MyClass class>>initialize >>> INT_PTR := FFIExternalValueHolder ofType: ?int?. >> >> as a larger explanation, this will create an anonymous subclass to keep ?int? >> values, than later you can use as a type in your function call. Some people >> would call this obscure, but is a good way of solving this problem (I >> adopted it from old NB). >> If you want to have a named class instead an anonymous class, you can just >> subclass FFIExternalValueHolder: >> >> FFIExternalValueHolder subclass: #MyIntPtr >> >> and then implement typeDecl class method >> >> MyIntPtr class>>typeDecl >> ^ ?int' >> >> and this will work as the anonymous class > > The second option is definitely what I want. Personally my option would be to put my types in a class pool and use them, not to extendâ¦ but option is there so you can choose what you want :) > I am trying to expose a function returning several ints, as in SDL2>>mouseStateX: y: (excluding the possibility to return a Point). > However I would rather not define my own int holder, can't we have generic holders to rely on? 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 :) You could always use a ByteArray and took values later (some functions in Athens do it like that). The advantage of this approach (using plain ByteArrays) is that you do not need to change function signature at the cost of needing to do manually what the value holder does for you. My advise is that you go with what you need, we can consider add predefined value holders later. Esteban > > Thibault >

April 11, 2016