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

Re: [Pharo-dev] building the pharo-vm failed

by Max Leske

> On 13 Oct 2015, at 11:17, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > > On 10/13/2015 02:25 AM, Max Leske wrote: >> >>> On 13 Oct 2015, at 00:29, Robert Withers <robert.w.withers(a)gmail.com> wrote: >>> >>> I am trying to build the vm and I got an error during make, listed at the bottom is one item that had error, but there were many conflicting types errors. >>> >>> I started with the latest bz2 from here: http://files.pharo.org/vm/src/vm-unix-sources/blessed/. I setup my tool environment (Ubuntu). The README.md says do a make in the platforms dir but that failed. >>> >>> >>> Recommended to me was the git repo: https://github.com/pharo-project/pharo-vm/blob/master/README.md >>> >>> So, I ran: >>> git clone --depth=1 https://github.com/pharo-project/pharo-vm.git >>> >>> cd build >>> >>> ./build.sh >>> >>> It pulled the image, generated sources then started to make the results when I got this error. >>> >>> What should I do now? >> >> Hi Robert, >> >> errors like that are often a consequence of differing gcc / clang versions (yes, weâre using a somewhat outdated version). What version do you have installed on your system? > > It took me some time to get back to this issue. I checked versions and gcc 4.9.2 and cmake 3.0.2. I don't have clang installed. Should I have? No, I donât think so, sorry. I mixed up CMake and clang in my head. > > thanks, > Robert > >> >> Cheers, >> Max >> >>> >>> -- >>> thanks, >>> Robert >>> >>> >>> >>> >>> /home/robert/.local/share/Pharo/pharo-vm/src/vm/cogit.c:3418:1: error: conflicting types for âconcretizeMoveAwRâ >>> concretizeMoveAwR(AbstractInstruction * self_in_concretizeMoveAwR) >>> ^ >>> /home/robert/.local/share/Pharo/pharo-vm/src/vm/cogit.c:457:14: note: previous declaration of âconcretizeMoveAwRâ was here >>> static sqInt concretizeMoveAwR(AbstractInstruction * self_in_concretizeMoveAwR) NoDbgRegParms; >>> ^

Oct. 13, 2015

Re: [Pharo-dev] building the pharo-vm failed

by Robert Withers

On 10/13/2015 02:25 AM, Max Leske wrote: > >> On 13 Oct 2015, at 00:29, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> I am trying to build the vm and I got an error during make, listed at the bottom is one item that had error, but there were many conflicting types errors. >> >> I started with the latest bz2 from here: http://files.pharo.org/vm/src/vm-unix-sources/blessed/. I setup my tool environment (Ubuntu). The README.md says do a make in the platforms dir but that failed. >> >> >> Recommended to me was the git repo: https://github.com/pharo-project/pharo-vm/blob/master/README.md >> >> So, I ran: >> git clone --depth=1 https://github.com/pharo-project/pharo-vm.git >> >> cd build >> >> ./build.sh >> >> It pulled the image, generated sources then started to make the results when I got this error. >> >> What should I do now? > > Hi Robert, > > errors like that are often a consequence of differing gcc / clang versions (yes, weâre using a somewhat outdated version). What version do you have installed on your system? It took me some time to get back to this issue. I checked versions and gcc 4.9.2 and cmake 3.0.2. I don't have clang installed. Should I have? thanks, Robert > > Cheers, > Max > >> >> -- >> thanks, >> Robert >> >> >> >> >> /home/robert/.local/share/Pharo/pharo-vm/src/vm/cogit.c:3418:1: error: conflicting types for âconcretizeMoveAwRâ >> concretizeMoveAwR(AbstractInstruction * self_in_concretizeMoveAwR) >> ^ >> /home/robert/.local/share/Pharo/pharo-vm/src/vm/cogit.c:457:14: note: previous declaration of âconcretizeMoveAwRâ was here >> static sqInt concretizeMoveAwR(AbstractInstruction * self_in_concretizeMoveAwR) NoDbgRegParms; >> ^ >> > >

Oct. 13, 2015

Re: [Pharo-dev] binary serialization

by Torsten Bergmann

Hi Robert, Also checkout the chapter on Fuel in Pharo Enterprise book: https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l… Bye Torsten > Gesendet: Dienstag, 13. Oktober 2015 um 09:44 Uhr > Von: "Robert Withers" <robert.w.withers(a)gmail.com> > An: pharo-dev(a)lists.pharo.org > Betreff: Re: [Pharo-dev] binary serialization > > Yes, I have to do object substitutions. Thanks for the link! > > thanks, > Robert > > On 10/13/2015 03:43 AM, Max Leske wrote: > > > >> On 13 Oct 2015, at 09:40, Robert Withers <robert.w.withers(a)gmail.com> wrote: > >> > >> Sven and Torsten, that's a binary serialization library! It will take time to learn it and how to use mappers. > >> > >> What is the format; is it language neutral? > > > > For quick serialization you donât need to do anything. It works for (almost) all objects. Only if you want to exclude things or treat some objects in a special way, you will need to do some stuff. > > > > Documentation: http://rmod.inria.fr/web/software/Fuel. > > > > > >> > >> thanks, > >> Robert > >> > >> On 10/13/2015 01:21 AM, Sven Van Caekenberghe wrote: > >>> Yes, it is called FUEL and it is a standard part of the image. See FLSerializer and FLMaterializer. > >>> > >>>> On 13 Oct 2015, at 06:59, Robert Withers <robert.w.withers(a)gmail.com> wrote: > >>>> > >>>> Does Pharo have stream classes to binary de/serialize an object, such that the protocol accepts an object as an argument and converts it to a byteArray? > >>>> > >>>> -- > >>>> thanks, > >>>> Robert > >>>> > >>> > >>> > >> > > > > > >

Oct. 13, 2015

Job | Seeking a Smalltalker for a PhD on Multi-Robot Systems

by Noury Bouraqadi

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.

Oct. 13, 2015

Re: [Pharo-dev] Alien and FFI in Pharo

by Robert Withers

On 10/13/2015 04:00 AM, Robert Withers wrote: > I'm sorry for not asking, Craig. Do you have a compelling use case? I > would think that the whole system would be much more agile and lean, > especially on the Pi. Callbacks would mean threaded plugins could run. > > I'd like to see dual 32-bit stacks running in 64-bits . Or not, depending on a bit. Then interleave 32-bit dualframes and 64-bit frames. I think that would be cool. > > thanks, > Robert > > On 10/13/2015 03:00 AM, Craig Latta wrote: >> >>> I want to get NIO sockets working using FFI, which I understand means >>> Alien. I can't seem to load Alien from the Catalog. >>> >>> What do you suggest I do? >> >> If NIO sockets involve callbacks from threads forked by the >> library, don't bother. Cog's scheduler deadlocks. >> >> >> -C >> >> -- >> Craig Latta >> netjam.org >> +31 6 2757 7177 (SMS ok) >> + 1 415 287 3547 (no SMS) >> >>

Oct. 13, 2015

Re: [Pharo-dev] Alien and FFI in Pharo

by Robert Withers

I'm sorry for not asking, Craig. Do you have a compelling use case? I would think that the whole system would be much more agile and lean, especially on the Pi. Callbacks would mean threaded plugins could run. I'd like to see dual 32-bit stacks running in 64-bits . thanks, Robert On 10/13/2015 03:00 AM, Craig Latta wrote: > >> I want to get NIO sockets working using FFI, which I understand means >> Alien. I can't seem to load Alien from the Catalog. >> >> What do you suggest I do? > > If NIO sockets involve callbacks from threads forked by the > library, don't bother. Cog's scheduler deadlocks. > > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > >

Oct. 13, 2015

Re: [Pharo-dev] binary serialization

by Robert Withers

Yes, I have to do object substitutions. Thanks for the link! thanks, Robert On 10/13/2015 03:43 AM, Max Leske wrote: > >> On 13 Oct 2015, at 09:40, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> Sven and Torsten, that's a binary serialization library! It will take time to learn it and how to use mappers. >> >> What is the format; is it language neutral? > > For quick serialization you donât need to do anything. It works for (almost) all objects. Only if you want to exclude things or treat some objects in a special way, you will need to do some stuff. > > Documentation: http://rmod.inria.fr/web/software/Fuel. > > >> >> thanks, >> Robert >> >> On 10/13/2015 01:21 AM, Sven Van Caekenberghe wrote: >>> Yes, it is called FUEL and it is a standard part of the image. See FLSerializer and FLMaterializer. >>> >>>> On 13 Oct 2015, at 06:59, Robert Withers <robert.w.withers(a)gmail.com> wrote: >>>> >>>> Does Pharo have stream classes to binary de/serialize an object, such that the protocol accepts an object as an argument and converts it to a byteArray? >>>> >>>> -- >>>> thanks, >>>> Robert >>>> >>> >>> >> > >

Oct. 13, 2015

Re: [Pharo-dev] binary serialization

by Max Leske

> On 13 Oct 2015, at 09:40, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > Sven and Torsten, that's a binary serialization library! It will take time to learn it and how to use mappers. > > What is the format; is it language neutral? For quick serialization you donât need to do anything. It works for (almost) all objects. Only if you want to exclude things or treat some objects in a special way, you will need to do some stuff. Documentation: http://rmod.inria.fr/web/software/Fuel. > > thanks, > Robert > > On 10/13/2015 01:21 AM, Sven Van Caekenberghe wrote: >> Yes, it is called FUEL and it is a standard part of the image. See FLSerializer and FLMaterializer. >> >>> On 13 Oct 2015, at 06:59, Robert Withers <robert.w.withers(a)gmail.com> wrote: >>> >>> Does Pharo have stream classes to binary de/serialize an object, such that the protocol accepts an object as an argument and converts it to a byteArray? >>> >>> -- >>> thanks, >>> Robert >>> >> >> >

Oct. 13, 2015

Re: [Pharo-dev] binary serialization

by Robert Withers

Sven and Torsten, that's a binary serialization library! It will take time to learn it and how to use mappers. What is the format; is it language neutral? thanks, Robert On 10/13/2015 01:21 AM, Sven Van Caekenberghe wrote: > Yes, it is called FUEL and it is a standard part of the image. See FLSerializer and FLMaterializer. > >> On 13 Oct 2015, at 06:59, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> Does Pharo have stream classes to binary de/serialize an object, such that the protocol accepts an object as an argument and converts it to a byteArray? >> >> -- >> thanks, >> Robert >> > >

Oct. 13, 2015

Re: [Pharo-dev] Alien and FFI in Pharo

by Robert Withers

Hi Craig, I saw your thread on that. Luckily NIO is a blocking call-out when you call select, so no callbacks. Callbacks would be nice to have available. It sounds like it is potentially big in impact to the image environment...pure events. I don't wish to see conversation completely stop on it, but I do not have a compelling use for it yet. I'd rather see 64bit Cog/Spur on PI. thanks, Robert On 10/13/2015 03:00 AM, Craig Latta wrote: > >> I want to get NIO sockets working using FFI, which I understand means >> Alien. I can't seem to load Alien from the Catalog. >> >> What do you suggest I do? > > If NIO sockets involve callbacks from threads forked by the > library, don't bother. Cog's scheduler deadlocks. > > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > >

Oct. 13, 2015