You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
roslisp fasls are compiled to ~/.ros/roslisp/packagename. This means when switching e.g. between diamondback and electric, that the wrong fasls can get loaded. Instead, fasls should go and be fetched from specialized locations, like ~/.ros/roslisp/path/to/file
Current workaround: delete fasls in ~/.ros/roslisp on each switch
The text was updated successfully, but these errors were encountered:
I see the problem but don't understand your solution. Can you give an example of the specific paths that would be used?
Changed 15 months ago by kruset
Fasls for ROS package /opt/ros/electric/stacks/common_msgs/geometry_msgs would go into ~/.ros/roslisp/opt/ros/electric/stacks/common_msgs/geometry_msgs
/opt/ros/diamondback/stacks/common_msgs/geometry_msgs would go into ~/.ros/roslisp/opt/ros/diamondback/stacks/common_msgs/geometry_msgs
/home/username/work/ros/sandbox/common_msgs/geometry_msgs would go into ~/.ros/roslisp/home/username/work/ros/sandbox/common_msgs/geometry_msgs
Changed 15 months ago by kruset
Hm, actually this still does not quite help. When switching between electric and diamondback the fasls at
could still conflict. So it would be even better to combine ROS_ROOT and path/to/file. That still leaves ambiguity for manually switching sbcl versions, so if we can also encode sbcl version, even better. Like: ~/.ros/roslisp/geometry_msgs/opt/ros/electric/sbcl-1.0.50/home/username/work/ros/sandbox/common_msgs/geometry_msgs The path could be somewhat reduced without too much risk by replacing "/opt/ros/electric" with just "electric" and starting at ~ for local files.
e.g. ~/.ros/roslisp/geometry_msgs/electric/sbcl-1.0.50/work/ros/sandbox/common_msgs/geometry_msgs
better ideas?
Changed 15 months ago by moesenle
Actually, I don't see that as an issue. Using the same package with different ROS distros at the same time is always a bad idea and you can run into all different kinds of inconsistencies not only with roslisp. Normally, I think users have one checkout per distro and not one checkout for all distros.
I think we shouldn't complicate this too much and try to find the minimal working solution. Just using $ROS_HOME/roslisp/ is fine and the corresponding patch should be pretty straight forward. Also, encoding the sbcl version shouldn't really be necessary since we catch the 'incompatible fasl' error and trigger recompilation in that case anyway.
To summarize, the only case where I see problems are lisp packages that lie in /opt/ros, mostly messages. When the user uses multiple distros at the same time, we either need to have the fasls at distinct locations or make sure that they are recompiled whenever the distro is switched. Currently, we (I guess) sort of implement the latter case. This might lead to lot's of unnecessary compilations and depending on asdf might even cause problems when the file dates don't indicate that recompilation is necessary. That means we actually want the former case implemented.
I will have a look at the source code and see if I can provide a quick patch as soon as I find some time.
Changed 11 months ago by kruset
Given similar issues with rosjava, I suggested a solution of either making rosinstall set a different ROS_HOME for each distro/rosinstall location, or a new ros env variable for binaries that rosinstall would set, leaving ROS_HOME fixed for non-conflicting data.
Migrated from https://code.ros.org/trac/ros/ticket/3716
Reported by: kruset Owned by: bhaskara
Priority: minor
Last modified ago: Mar 2012
roslisp fasls are compiled to ~/.ros/roslisp/packagename. This means when switching e.g. between diamondback and electric, that the wrong fasls can get loaded. Instead, fasls should go and be fetched from specialized locations, like ~/.ros/roslisp/path/to/file
Current workaround: delete fasls in ~/.ros/roslisp on each switch
The text was updated successfully, but these errors were encountered: