From kazhoyan at cs.uni-bremen.de Mon Mar 3 23:12:31 2014 From: kazhoyan at cs.uni-bremen.de (Gayane Kazhoyan) Date: Mon, 3 Mar 2014 23:12:31 +0100 Subject: [cram-developers] Link: Extract git sub-dir with history In-Reply-To: <52FCBD7D.3000101@cs.uni-bremen.de> References: <52FCBD7D.3000101@cs.uni-bremen.de> Message-ID: Dear CRAM developers, There was a small problem in the method described in the link from the previous message. To describe the problem I have to first outline what's happening in those instructions. So, assume, you want to move *my_dir* from *repo_a* into *repo_b*, such that the file hierarchy stays the same: *repo_a* / *my_dir* -> *repo_b* / *my_dir* So, the major steps are: * you're creating a clone of the original *repo_a*, because you know you're going to delete things from it: git clone https://github.com/cram-code/repo_a.git * you're applying a subdirectory filter to your repo, which extracts all the files from *my_dir* and the commit history that touches those files and puts them into the root of the repo, and removes everything unrelated to *my_dir *that was there git filter-branch --prune-empty --subdirectory-filter my_dir -- --all so the files from *my_dir* end up in the root of *repo_a*: *repo_a* / *my_dir* / *file_1* -> *repo_a* / *file_1*; *repo_a* / *other_dir* / *file_123* -> nil * you're moving the newly generated copy of the files into a subdirectory, because you don't want them to appear straight at the root of *repo_b* mkdir my_dir git mv * my_dir so that you end up with: *repo_a* / *file_1* -> *repo_a* / *my_dir* / *file_1* Now, the problem with the subdirectory filter is that the history is rewritten such that all your commits are related to the newly extracted files that are situated at the root of *repo_a* (*repo_a* / *file_1*). And when you "git mv * my_dir", your files move, you get *repo_a* / *my_dir* / *file_1*, but the history stays associated with the old file from the root, i.e. *repo_a* / *file_1*. So, in order to move the entries in the commit log together with the files, you need to rewrite the history yet again: git filter-branch --force --index-filter 'git ls-files -s | sed "s-\t\"*-&my_dir/-" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ git update-index --index-info && mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD Source: git filter-branch --help Cheers, Gaya On Thu, Feb 13, 2014 at 1:41 PM, Georg Bartels < georg.bartels at cs.uni-bremen.de> wrote: > Hi all, > > in yesterday's meeting I promised to send around a link to guide > explaining how to extract a sub-dir with history from git which I find > very useful. Here it comes: > > > http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/ > > Cheers, > Georg. > _______________________________________________ > cram-developers mailing list > cram-developers at informatik.uni-bremen.de > https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers > -- Gayane Kazhoyan Institute for Artificial Intelligence, Universit?t Bremen https://ai.uni-bremen.de/team/gayane_kazhoyan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazhoyan at cs.uni-bremen.de Fri Mar 14 23:19:10 2014 From: kazhoyan at cs.uni-bremen.de (Gayane Kazhoyan) Date: Fri, 14 Mar 2014 23:19:10 +0100 Subject: [cram-developers] SBCL heap size Message-ID: Dear CRAM developers, Some of us have recently been getting into problems with SBCL heap overflow. The usual way to change the heap size is either to set (slime-lisp-implementations '((sbcl ("sbcl" "--dynamic-space-size" "MY-NEW-HEAP-SIZE")))) before invoking slime, e.g. in the emacs init file, or to pass a command line argument ``--dynamic-heap-size MY-NEW-HEAP-SIZE`` to the sbcl executive. As in our case slime is invoked by rosemacs and the SLIME-ROS function thereof overrides user-defined SLIME-LISP-IMPLEMENTATIONS, the first option of the above will not have any effect. So, what is left is to pass the command line argument. I found no better solution than to change the slime-ros.el itself. It is located in /usr/share/emacs/site-lisp/rosemacs-el. You should end up with (inferior-lisp-program (concat sbcl-binary " --dynamic-space-size 4096" " --load " roslisp-path "/scripts/roslisp-sbcl-init")) for 4 GB of RAM. To check if the change has taken effect, call (sb-ext:dynamic-space-size). My default heap size used to be 1 GB and since the change I haven't been getting into any overflow problems whatsoever. If that doesn't help, the function for explicitly calling the garbage collector was (sb-ext:gc :full t). Cheers, Gaya -- Gayane Kazhoyan Institute for Artificial Intelligence, Universit?t Bremen https://ai.uni-bremen.de/team/gayane_kazhoyan -------------- next part -------------- An HTML attachment was scrubbed... URL: From liscagheorghe at gmail.com Sat Mar 15 00:27:50 2014 From: liscagheorghe at gmail.com (Gheorghe Lisca) Date: Sat, 15 Mar 2014 00:27:50 +0100 Subject: [cram-developers] SBCL heap size In-Reply-To: References: Message-ID: Hi Gaya, thanks for the advice! Just out of curiosity do you have in mind an example when CRAM would eat more than 1GB of RAM? Do you have an idea about which CRAM module would eat so much memory and maybe why? Cheers, Gheorghe On Fri, Mar 14, 2014 at 11:19 PM, Gayane Kazhoyan wrote: > Dear CRAM developers, > > Some of us have recently been getting into problems with SBCL heap > overflow. > The usual way to change the heap size is either to set > > (slime-lisp-implementations > '((sbcl ("sbcl" "--dynamic-space-size" "MY-NEW-HEAP-SIZE")))) > > before invoking slime, e.g. in the emacs init file, or to pass a command > line argument ``--dynamic-heap-size MY-NEW-HEAP-SIZE`` to the sbcl > executive. > > As in our case slime is invoked by rosemacs and the SLIME-ROS function > thereof overrides user-defined SLIME-LISP-IMPLEMENTATIONS, the first option > of the above will not have any effect. > So, what is left is to pass the command line argument. I found no better > solution than to change the slime-ros.el itself. It is located in > /usr/share/emacs/site-lisp/rosemacs-el. > You should end up with > > (inferior-lisp-program (concat sbcl-binary > " --dynamic-space-size 4096" > " --load " roslisp-path > "/scripts/roslisp-sbcl-init")) > > for 4 GB of RAM. > > To check if the change has taken effect, call (sb-ext:dynamic-space-size). > > My default heap size used to be 1 GB and since the change I haven't been > getting into any overflow problems whatsoever. > > If that doesn't help, the function for explicitly calling the garbage > collector was (sb-ext:gc :full t). > > Cheers, > Gaya > > -- > Gayane Kazhoyan > Institute for Artificial Intelligence, Universit?t Bremen > https://ai.uni-bremen.de/team/gayane_kazhoyan > > _______________________________________________ > cram-developers mailing list > cram-developers at informatik.uni-bremen.de > https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazhoyan at cs.uni-bremen.de Sat Mar 15 01:31:51 2014 From: kazhoyan at cs.uni-bremen.de (Gayane Kazhoyan) Date: Sat, 15 Mar 2014 01:31:51 +0100 Subject: [cram-developers] SBCL heap size In-Reply-To: References: Message-ID: Hi Gheorghe, The high-level plans composed of numerous perception, manipulation and navigation actions (that have vague symbolic descriptions of locations, objects, trajectories etc. as parameters) involve computationally intensive reasoning mechanisms in order to ground those vague descriptions to actual entities in the world surrounding the robot at the moment of plan execution. On the one hand we end up with higher requirements on our hardware (which in the modern world is usually not a problem, PR2 has 24 GB of RAM), and on the other hand we acquire highly flexible plans that are not limited to the current state of the environment, the specific robot hardware etc., at least this is the goal towards which we are working. When implementing complex systems there is always the trade off between the computational efficiency and the capabilities of the system on the feature level. I, personally, expect a robot executive that is trying to approach in its reasoning capabilities the way the humans think to be extremely computationally expensive. Coming closer to the point and having finished my philosophical speech, I suspect that there are three bottlenecks in the current implementation. (1) The generative algorithm generating candidates for location designators currently has as its domain the whole environment of the robot, i.e. for the kitchen scenario it's the whole kitchen. This should not be too hard to optimize by using some kind of a quadtree. (2) The randomized sampling algorithm for designator resolution sometimes takes way too much time for finding a good solution. 1.5 years ago I have been working on a priority sampling mechanism, which resulted in a major performance improvement. I haven't had time to clean up that code and merge it in yet. (3) Prolog is basically a depth-first search algorithm, which is always slow. We had a discussion about this in some of the previous emails. Unfortunately, a different story is that Jan also had a problem of heap overflow when simply starting a ROS node from roslisp and nothing else, which has nothing to do with CRAM and also needs to be looked into. If you would like to contribute to optimizing CRAM, in the discussion about Prolog Lorenz pointed out a number of low-hanging fruits for improvement of our Prolog implementation, I guess that could be a starting point. Cheers Gaya On Sat, Mar 15, 2014 at 12:27 AM, Gheorghe Lisca wrote: > Hi Gaya, > > thanks for the advice! > > Just out of curiosity do you have in mind an example when CRAM would eat > more than 1GB of RAM? > > Do you have an idea about which CRAM module would eat so much memory and > maybe why? > > Cheers, > Gheorghe > > > On Fri, Mar 14, 2014 at 11:19 PM, Gayane Kazhoyan < > kazhoyan at cs.uni-bremen.de> wrote: > >> Dear CRAM developers, >> >> Some of us have recently been getting into problems with SBCL heap >> overflow. >> The usual way to change the heap size is either to set >> >> (slime-lisp-implementations >> '((sbcl ("sbcl" "--dynamic-space-size" "MY-NEW-HEAP-SIZE")))) >> >> before invoking slime, e.g. in the emacs init file, or to pass a command >> line argument ``--dynamic-heap-size MY-NEW-HEAP-SIZE`` to the sbcl >> executive. >> >> As in our case slime is invoked by rosemacs and the SLIME-ROS function >> thereof overrides user-defined SLIME-LISP-IMPLEMENTATIONS, the first option >> of the above will not have any effect. >> So, what is left is to pass the command line argument. I found no better >> solution than to change the slime-ros.el itself. It is located in >> /usr/share/emacs/site-lisp/rosemacs-el. >> You should end up with >> >> (inferior-lisp-program (concat sbcl-binary >> " --dynamic-space-size 4096" >> " --load " roslisp-path >> "/scripts/roslisp-sbcl-init")) >> >> for 4 GB of RAM. >> >> To check if the change has taken effect, call (sb-ext:dynamic-space-size). >> >> My default heap size used to be 1 GB and since the change I haven't been >> getting into any overflow problems whatsoever. >> >> If that doesn't help, the function for explicitly calling the garbage >> collector was (sb-ext:gc :full t). >> >> Cheers, >> Gaya >> >> -- >> Gayane Kazhoyan >> Institute for Artificial Intelligence, Universit?t Bremen >> https://ai.uni-bremen.de/team/gayane_kazhoyan >> >> _______________________________________________ >> cram-developers mailing list >> cram-developers at informatik.uni-bremen.de >> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers >> >> > > _______________________________________________ > cram-developers mailing list > cram-developers at informatik.uni-bremen.de > https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers > > -- Gayane Kazhoyan Institute for Artificial Intelligence, Universit?t Bremen https://ai.uni-bremen.de/team/gayane_kazhoyan -------------- next part -------------- An HTML attachment was scrubbed... URL: From winkler at cs.uni-bremen.de Tue Mar 18 09:21:06 2014 From: winkler at cs.uni-bremen.de (Jan Winkler) Date: Tue, 18 Mar 2014 09:21:06 +0100 Subject: [cram-developers] SBCL heap size In-Reply-To: References: Message-ID: <532801F2.4040000@cs.uni-bremen.de> Hey, thanks for the nice summary, Gaya! This really solved the problem at its root. One more slight comment on it, since I mindlessly ran into it: The order of parameters for the sbcl-binary actually matters. (inferior-lisp-program (concat sbcl-binary " --dynamic-space-size 4096" " --load " roslisp-path "/scripts/roslisp-sbcl-init")) works like a charm, while (inferior-lisp-program (concat sbcl-binary " --load " roslisp-path "/scripts/roslisp-sbcl-init" " --dynamic-space-size 4096")) doesn't work. Parameters after "--load " are not accepted by the sbcl-binary. It won't even complain, but you will be stuck with the default heap size of 1024 MB. Cheers, Jan On 03/14/2014 11:19 PM, Gayane Kazhoyan wrote: > Dear CRAM developers, > > Some of us have recently been getting into problems with SBCL heap overflow. > The usual way to change the heap size is either to set > > (slime-lisp-implementations > '((sbcl ("sbcl" "--dynamic-space-size" "MY-NEW-HEAP-SIZE")))) > > before invoking slime, e.g. in the emacs init file, or to pass a command > line argument ``--dynamic-heap-size MY-NEW-HEAP-SIZE`` to the sbcl > executive. > > As in our case slime is invoked by rosemacs and the SLIME-ROS function > thereof overrides user-defined SLIME-LISP-IMPLEMENTATIONS, the first option > of the above will not have any effect. > So, what is left is to pass the command line argument. I found no better > solution than to change the slime-ros.el itself. It is located in > /usr/share/emacs/site-lisp/rosemacs-el. > You should end up with > > (inferior-lisp-program (concat sbcl-binary > " --dynamic-space-size 4096" > " --load " roslisp-path > "/scripts/roslisp-sbcl-init")) > > for 4 GB of RAM. > > To check if the change has taken effect, call (sb-ext:dynamic-space-size). > > My default heap size used to be 1 GB and since the change I haven't been > getting into any overflow problems whatsoever. > > If that doesn't help, the function for explicitly calling the garbage > collector was (sb-ext:gc :full t). > > Cheers, > Gaya > > > > _______________________________________________ > cram-developers mailing list > cram-developers at informatik.uni-bremen.de > https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers > -- Dipl. Ing. Jan Winkler Technologie-Zentrum Informatik und Informationstechnik Raum 1.56 Am Fallturm 1 (TAB Gebaeude) Universitaet Bremen 28359 Bremen, Deutschland E-Mail: winkler at cs.uni-bremen.de Tel: +49 (0)421-218-64019 Fax: +49 (0)421-218-64047 From kazhoyan at cs.uni-bremen.de Wed Mar 19 14:10:40 2014 From: kazhoyan at cs.uni-bremen.de (Gayane Kazhoyan) Date: Wed, 19 Mar 2014 14:10:40 +0100 Subject: [cram-developers] Bullet full screen Message-ID: Hi, A short note for those working with the OpenGL debug-window for Bullet visualization: to have the window go full screen (mainly for videos) call (glut:full-screen) and to turn it back off (glut:reshape-window 1024 768) Works the best when you have two monitors, otherwise your Emacs will get covered by the window and the only way to go back to it would be to ESC. Hopefully we'll switch back to Rviz one day and this will get obsolete, but until then ... Cheers, Gaya -------------- next part -------------- An HTML attachment was scrubbed... URL: