October 2015 - Pharo-dev - lists.pharo.org

Job | Seeking a Smalltalker for a PhD on Multi-Robot Systems
by Noury Bouraqadi Oct. 13, 2015

Oct. 13, 2015

Hi, My team has an opening for a PhD student to work on multi-robot exploration and mapping. We target search and rescue operations with UGVs controlled using PhaROS (Pharo + our client for the Robot Operating System). You'll find the full description below. More info on our team can be found at: http://car.mines-douai.fr <http://car.mines-douai.fr/> Best, Prof. Noury Bouraqadi Ecole des Mines de Douai Lille area France ------------ CONTACT Prof. Noury Bouraqadi, noury.bouraqadi AT mines-douai.fr <http://mines-douai.fr/> Dr. Luc Fabresse, luc.fabresse AT mines-douai.fr <http://mines-douai.fr/> Dr. Guillaume Lozengez, guillaume.lozengez AT mines-douai.fr <http://mines-douai.fr/> DESCRIPTION Robotic exploration and mapping is basic to many robotic applications and more specifically to search and rescue operations. It relies on robots to build a map of the environment as a first step to further mission specific tasks (eg. extracting trapped victims). In scenarios where time is critical such in the aftermath of an earthquake, the use of multiple robots allows to speed up the exploration and to take advantage of distributed sensor to increase the mapping process. Each robot explores a different but connected area. The global map is built by merging local maps built by individual robots. To build a map of an unknown environment, a robot has to perform Simultaneous Localization and Mapping (SLAM). Based on different perceived data (typically odometery and laser scans), metric SLAM algorithms localize the robot while building an occupancy grid. The occupancy grid models the environment as a matrix where each cell denotes the probability of occupancy of a small area. Best metric SLAM algorithms produce precise maps that allow localization with typically centimetric precision. However, an occupancy grid map is materialized as a large matrix. Beside the memory consumption, such a map leads to high CPU consumption for path planning. CPU consumption is also a concern in multi-robot exploration. Indeed, merging metric maps produced by different robots is computationally intensive. The above drawbacks of metrics maps can be mitigated by the use of topological maps. However, topological maps do not allow precise obstacle delimitations needed for autonomous robots exploration. The goal of this PhD is to contribute to our ongoing effort, and propose a solution that gathers the best of both worlds. The expected outcome is a SLAM algorithm that builds a topological map that embeds metric information. The target algorithm should be implemented on top of the ROS (www.ros.org <http://www.ros.org/>) middleware and validated both in simulation and on actual robots. It should also be supported by a set of automated tests that can safely run on an actual robot. BIBLIOGRAPHY - Robotic Mapping and Exploration. C. Stachniss. Springer 2009. - An evaluation of 2D SLAM techniques available in Robot Operating System. J. M. Santos, D. Portugal, and R. Rocha. SSRR 2013. - A Methodology for Testing Mobile Autonomous Robots. Jannik Laval, Luc Fabresse and Noury Bouraqadi. IROS 2013. - Towards Test-Driven Development for Mobile Robots. Luc Fabresse, Jannik Laval and Noury Bouraqadi. ICRA 2013 eigth workshop on Software Development and Integration in Robotics (SDIR VIII). - Team Size Optimization for Multi-robot Exploration, Zhi Yan, Luc Fabresse, Jannik Laval, and Noury Bouraqadi, SIMPAR 2014. - Metrics for Performance Benchmarking of Multi-robot Exploration. Zhi Yan, Luc Fabresse, Jannik Laval, and Noury Bouraqadi. IROS 2015. - Punctual versus continuous auction coordination for multi-robot and multi-task topological navigation, Guillaume Lozenguez, Lounis Adouane, AurÃ©lie Beynier, Abdel-Illah Mouaddib, Philippe Martinet, Autonomous Robot 2015.

1 0

updated Cryptography
by Robert Withers Oct. 13, 2015

Oct. 13, 2015

I am attaching the .mcz as I am unsure where to publish it. I fixed a few issues (hex is lowercase and inputs to SecureRandom) and all tests pass green in the latest Pharo 5.0. Is there a good place for this to live? -- thanks, Robert

3 4

issue with large file path on windows
by Nicolai Hess Oct. 13, 2015

Oct. 13, 2015

For those who had problems with pharo on windows and github based repositories, I built a windows vm with support for long paths: https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… For browsing directories with large paths (FileList or Inspect), you may need one additional change in the image (But I am not really sure about that) : DiskStore>>initialize super initialize. maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ]. please test and give feedback. This wasn't as easy as I thought, and I had to make some more changes for the file permissions (the stat-functions don't work for files with long paths). Please test other file/folder operations. nicolai

8 21

really
by Robert Withers Oct. 13, 2015

Oct. 13, 2015

This is what I want to build. What do you suggest I do? Thanks, Robert

2 2

[ANN] New SqueakSSL binaries (v0.2.0b) for Linux
by Tobias Pape Oct. 12, 2015

Oct. 12, 2015

Hi all, I've created a new version of the SqueakSSL binaries: https://github.com/itsmeront/squeakssl/releases/tag/v0.2.0b Only changes: â¢ Linked the Linux binary statically against LibreSSL 2.2.3 (was 2.2.1) â¢ Produce SqueakSSL and so.SqueakSSL with the correct sonames â¢ Explicitly link the Linux binaries with librt (was omitted by default) The OSX and Windows versions stayed. The actual C code did not change. Best regards -Tobias

1 0

Re: [Pharo-dev] Problems with a large block
by Nicolai Hess Oct. 12, 2015

Oct. 12, 2015

2015-10-08 23:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Thu, Oct 8, 2015 at 2:27 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Hello Eliot, and thanks for your time. >> >> >> In our (pharo) implementation for sourceNodeForPC, we start at the >> AST-Node of >> the compiled method, get the IR (IntermediateRepresentation) and scan >> this sequence of IRNodes >> until we finally find that one, that maps to the bytecode of the closure >> creation code (this should be a IRPushClosureCopy). >> The problem is now, we don't find (always) the right IRNode, and it >> depens on the number of local temps, if this is > 3 we don't hit the right >> one. >> > > That's very strange. Can you construct a synthetic example of two simple > blocks, one with three temps and and one with four temps and show me the > difference in the byte code? > [ :x | | a b c | a:=b:=c:=x ] "calling #sourceNode gives a RBBlockNode - ok" Bytecode 13 <8F 01 00 0B> closureNumCopied: 0 numArgs: 1 bytes 17 to 27 17 <73> pushConstant: nil 18 <73> pushConstant: nil 19 <73> pushConstant: nil 20 <10> pushTemp: 0 21 <81 43> storeIntoTemp: 3 23 <81 42> storeIntoTemp: 2 25 <81 41> storeIntoTemp: 1 27 <7D> blockReturn 28 <7C> returnTop [ :x | | a b c d | a:=b:=c:=d:=x ] "calling #sourceNode gives a RBMethodNode - not ok" Bytecode 13 <8F 01 00 0E> closureNumCopied: 0 numArgs: 1 bytes 17 to 30 17 <73> pushConstant: nil 18 <73> pushConstant: nil 19 <73> pushConstant: nil 20 <73> pushConstant: nil 21 <10> pushTemp: 0 22 <81 44> storeIntoTemp: 4 24 <81 43> storeIntoTemp: 3 26 <81 42> storeIntoTemp: 2 28 <81 41> storeIntoTemp: 1 30 <7D> blockReturn 31 <7C> returnTop As I wrote above, in Pharo, to get the sourceNode we try to find the push closure bytecode from "startpc - 1" by traversing the IR and try to get the IRNode with matching "bytecodeOffset". The bytecodeOffsets for the above blocks: [ :x | | a b c | a:=b:=c:=x ] "bytecodeOffset -> IR" 19->pushClosureCopyCopiedValues: #() args: #(#x) 28->returnTop 20->pushTemp: #x 22->storeTemp: #c 24->storeTemp: #b 26->storeTemp: #a 27->blockReturnTop [ :x | | a b c d | a:=b:=c:=d:=x ] "bytecodeOffset -> IR" 20->pushClosureCopyCopiedValues: #() args: #(#x) 31->returnTop 21->pushTemp: #x 23->storeTemp: #d 25->storeTemp: #c 27->storeTemp: #b 29->storeTemp: #a 30->blockReturnTop Both blocks don't have a bytecodeOffset matching the bytecode of the pushclosure (13), but we start the search from "startpc - 1" (= 16) and do a loop from 0 to -3 (because bytecodes can have a length of 1,2 or 4) For the first block, this works bytecodeOffset 19 = 16 - (-3) For the second block this does not work, somehow the bytecodeoffset value depends on the number of local temps. And for the second block this is one greater. > And my interpretation was, the IRPushClosureCopy node has the wrong >> "bytecode offset" (whatever this is). The bytecodeOffset value (somehow) >> depends on the number of local temps, but maybe this is right (for >> whatever this is used) and we are just using it wrong for in this situation. >> > > So you need to ask Marcus how to interpret bytecodeOffset. The thing is, > it should be simple. One has: > > BlockCreationBytecode > any number of pushConstant: nil's (0 to N) > first byte code in block > last bytecode in block (always a blockReturnTop) > > and a block's startup is always that of the byte immediately following the > BlockCreationBytecode. So if the byte code offset is somehow the span of > the "any number of pushConstant: nil's (0 to N)" then there's a bug in the > IR somewhere when the number of temps is > 3. But if that's not what it > means then, well, I don't know what the problem is. > >

3 3

Relation between Garage PG and PGv2
by Esteban A. Maringolo Oct. 12, 2015

Oct. 12, 2015

Hi all, and Guille Polito in particular, I'm loading the Garage classes into Pharo 4, and I see the Garage-Postgres package "duplicates" the classes of the PostgresV2 package, but instead of using the PG prefix, it uses the GA prefix. This is in particular with the case of Garage-Postgres-Protocol package. Why is it so? Because even GAConnection>>#buildDefaultConnectionArgs (which is a replica of PGConnection) references PGConnectionArgs instead of GAConnectionArgs, which is the replica of the first. QUESTION: Isn't Garage a "common API" for the *existing* drivers? (like a common wrapper), and if so it delegates the protocol handling to the real driver? In the PostgresV2 package in this case, to PG prefixed classes. Regards! Esteban A. Maringolo

2 2

[ANN] Pharo Sprint October 23
by marcus.denker＠inria.fr Oct. 12, 2015

Oct. 12, 2015

We will organize a Pharo sprint / Moose dojo Friday, 23th October, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on the official IRC channel #pharo on irc.freenode.net <http://irc.freenode.net/> server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come.

1 0

hello
by SebastiÃ¡n Krynski Oct. 12, 2015

Oct. 12, 2015

Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. Just writing to let you know that I'm starting to work on adding an atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. The operator will be used this way: a :=: b meaning 'swap variable a with variable b'. In order to do this I will be modifying the VM and the Compiler . I'm working under the direction of INRIA and Gabriela ArÃ©valo.

5 7

Another pass on catalog web-site (Styling)
by Esteban Lorenzano Oct. 12, 2015

Oct. 12, 2015

Hi, I made another pass on catalog web-site. This time I just enhanced a bit the stylingâ¦ still a lot to do but is looking better and better: http://catalog.pharo.org (you might need a force refresh) But in fact, this announce is just an excuse to remember you to enhance your configurations with catalog information as described here: http://catalog.pharo.org/catalog/note-for-developers Also, if your configuration is proved to work on Pharo 3, 4 or 5, please copy your configuration into that repository, to avoid it to appear under âUnstableâ tag. The Catalog is just as good as the information it provides: there is A LOT of very good packages no one will ever notice (like Aconcagua, for example), that does not provide *any* information and therefore they will never be used :( PLEASE PLEASE PLEASE UPDATE YOUR CONFIGURATIONS! cheers, Esteban

2 1