|
Bugzilla – Full Text Bug Listing |
| Summary: | extension: Specialized version of GetObject in MobilityModel to allow python bindings use MobilityModels through basic interface (doesn't require bindings for the specific mobility model) | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Alex Afanasyev <alexander.afanasyev> |
| Component: | python bindings | Assignee: | Gustavo J. A. M. Carneiro <gjcarneiro> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | ns-bugs |
| Priority: | P5 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | Patch | ||
Can you help me understand better this is needed? What error do you get when getting a mobility model that is not known to the Python bindings? Maybe there's a way to make pybindgen smarter about this and avoid this workaround... Here is what I have encountered. When in Python we needed to get hold of an aggregated object, we use something like this (copied from visualizer): mob = ns3_node.GetObject(ns.mobility.MobilityModel.GetTypeId()) Somehow, when a specific mobility model does not have corresponding bindings, this results in mob to have only Object interface and nothing from Mobility interface. Right. I think understand what happens. What does your waf configure say about "Checking for internal GCC cxxabi" ? |
Created attachment 1577 [details] Patch The attached patch implements a specialized version of GetObject method (MobilityModel::GetMobilityModel) in MobilityModel class. This method is now used by the visualizer to obtain mobility interface. This trick is necessary in order to use in python mobility models that are not explicitly exported (or impossible to export) to python bindings generation.