I am trying to use an external library from Pascal that I have successfully used from C before. In order to use this library I have been provided a .h file, a .dll file and a .lib file.
I converted the .h file using the h2pas utility but I am getting the following errors (which I suspect are linker-related):
Error: (5009) Forward type not resolved "XPRSbranchobject"
This appears to be the offending line:
type
...
XPRSbranchobject = ^xo_user_branch_entity_s ;
How do I let Lazarus know that xo_user_branch_entity_s is part of the external library?
You could simply write:
type
xo_user_branch_entity_s = record
a: integer; // <-- probably redundant
end;
XPRSbranchobject = ^xo_user_branch_entity_s;
You must be sure you never (de)allocate such object (the record, either directly or via pointer); if the sources tries to access internal members, the compiler will complain.
This implies that allocation/deallocation is done by the DLL.
It should (could?) work...
This is meant to be a FAQ question, so please be as complete as possible. The answer is a community answer, so feel free to edit if you think something is missing.
This question was discussed and approved on meta.
I am using R and tried some.function but I got following error message:
Error: could not find function "some.function"
This question comes up very regularly. When you get this type of error in R, how can you solve it?
There are a few things you should check :
Did you write the name of your function correctly? Names are case sensitive.
Did you install the package that contains the function? install.packages("thePackage") (this only needs to be done once)
Did you attach that package to the workspace ?
require(thePackage) (and check its return value) or library(thePackage) (this should be done every time you start a new R session)
Are you using an older R version where this function didn't exist yet?
Are you using a different version of the specific package? This could be in either direction: functions are added and removed over time, and it's possible the code you're referencing is expecting a newer or older version of the package than what you have installed.
If you're not sure in which package that function is situated, you can do a few things.
If you're sure you installed and attached/loaded the right package, type help.search("some.function") or ??some.function to get an information box that can tell you in which package it is contained.
find and getAnywhere can also be used to locate functions.
If you have no clue about the package, you can use findFn in the sos package as explained in this answer.
RSiteSearch("some.function") or searching with rdocumentation or rseek are alternative ways to find the function.
Sometimes you need to use an older version of R, but run code created for a newer version. Newly added functions (eg hasName in R 3.4.0) won't be found then. If you use an older R version and want to use a newer function, you can use the package backports to make such functions available. You also find a list of functions that need to be backported on the git repo of backports. Keep in mind that R versions older than R3.0.0 are incompatible with packages built for R3.0.0 and later versions.
Another problem, in the presence of a NAMESPACE, is that you are trying to run an unexported function from package foo.
For example (contrived, I know, but):
> mod <- prcomp(USArrests, scale = TRUE)
> plot.prcomp(mod)
Error: could not find function "plot.prcomp"
Firstly, you shouldn't be calling S3 methods directly, but lets assume plot.prcomp was actually some useful internal function in package foo. To call such function if you know what you are doing requires the use of :::. You also need to know the namespace in which the function is found. Using getAnywhere() we find that the function is in package stats:
> getAnywhere(plot.prcomp)
A single object matching ‘plot.prcomp’ was found
It was found in the following places
registered S3 method for plot from namespace stats
namespace:stats
with value
function (x, main = deparse(substitute(x)), ...)
screeplot.default(x, main = main, ...)
<environment: namespace:stats>
So we can now call it directly using:
> stats:::plot.prcomp(mod)
I've used plot.prcomp just as an example to illustrate the purpose. In normal use you shouldn't be calling S3 methods like this. But as I said, if the function you want to call exists (it might be a hidden utility function for example), but is in a namespace, R will report that it can't find the function unless you tell it which namespace to look in.
Compare this to the following:
stats::plot.prcomp
The above fails because while stats uses plot.prcomp, it is not exported from stats as the error rightly tells us:
Error: 'plot.prcomp' is not an exported object from 'namespace:stats'
This is documented as follows:
pkg::name returns the value of the exported variable name in namespace pkg, whereas pkg:::name returns the value of the internal variable name.
I can usually resolve this problem when a computer is under my control, but it's more of a nuisance when working with a grid. When a grid is not homogenous, not all libraries may be installed, and my experience has often been that a package wasn't installed because a dependency wasn't installed. To address this, I check the following:
Is Fortran installed? (Look for 'gfortran'.) This affects several major packages in R.
Is Java installed? Are the Java class paths correct?
Check that the package was installed by the admin and available for use by the appropriate user. Sometimes users will install packages in the wrong places or run without appropriate access to the right libraries. .libPaths() is a good check.
Check ldd results for R, to be sure about shared libraries
It's good to periodically run a script that just loads every package needed and does some little test. This catches the package issue as early as possible in the workflow. This is akin to build testing or unit testing, except it's more like a smoke test to make sure that the very basic stuff works.
If packages can be stored in a network-accessible location, are they? If they cannot, is there a way to ensure consistent versions across the machines? (This may seem OT, but correct package installation includes availability of the right version.)
Is the package available for the given OS? Unfortunately, not all packages are available across platforms. This goes back to step 5. If possible, try to find a way to handle a different OS by switching to an appropriate flavor of a package or switch off the dependency in certain cases.
Having encountered this quite a bit, some of these steps become fairly routine. Although #7 might seem like a good starting point, these are listed in approximate order of the frequency that I use them.
If this occurs while you check your package (R CMD check), take a look at your NAMESPACE.
You can solve this by adding the following statement to the NAMESPACE:
exportPattern("^[^\\\\.]")
This exports everything that doesn't start with a dot ("."). This allows you to have your hidden functions, starting with a dot:
.myHiddenFunction <- function(x) cat("my hidden function")
I had the error
Error: could not find function some.function
happen when doing R CMD check of a package I was making with RStudio. I found adding
exportPattern(".")
to the NAMESPACE file did the trick. As a sidenote, I had initially configured RStudio to use ROxygen to make the documentation -- and selected the configuration where ROxygen would write my NAMESPACE file for me, which kept erasing my edits. So, in my instance I unchecked NAMESPACE from the Roxygen configuration and added exportPattern(".") to NAMESPACE to solve this error.
This error can occur even if the name of the function is valid if some mandatory arguments are missing (i.e you did not provide enough arguments).
I got this in an Rcpp context, where I wrote a C++ function with optionnal arguments, and did not provided those arguments in R. It appeared that optionnal arguments from the C++ were seen as mandatory by R. As a result, R could not find a matching function for the correct name but an incorrect number of arguments.
Rcpp Function : SEXP RcppFunction(arg1, arg2=0) {}
R Calls :
RcppFunction(0) raises the error
RcppFunction(0, 0) does not
Rdocumentation.org has a very handy search function that - among other things - lets you find functions - from all the packages on CRAN, as well as from packages from Bioconductor and GitHub.
If you are using parallelMap you'll need to export custom functions to the slave jobs, otherwise you get an error "could not find function ".
If you set a non-missing level on parallelStart the same argument should be passed to parallelExport, else you get the same error. So this should be strictly followed:
parallelStart(mode = "<your mode here>", N, level = "<task.level>")
parallelExport("<myfun>", level = "<task.level>")
You may be able to fix this error by name spacing :: the function call
comparison.cloud(colors = c("red", "green"), max.words = 100)
to
wordcloud::comparison.cloud(colors = c("red", "green"), max.words = 100)
I got the same, error, I was running version .99xxx, I checked for updates from help menu and updated My RStudio to 1.0x, then the error did not come
So simple solution, just update your R Studio
I have two Omnet++ projects A and B. A currently needs B. Is it possible to declare B as a feature of A somehow, so I can turn it on and off? I want to have the separate projects as B can be reused in other projects. I added a feature using a new .oppfeatures file in A and I added corresponding ifdef statements in the C++ code. Currently I struggle with the ned file:
import namespaceB.B;
network Network
{
parameters:
[...]
bool bDisabled = default(false);
submodules:
[...]
b: B if !bDisabled;
}
How can I conditionally import the ned file of B? If I use a wildcard for importing Omnet complains about "no such module type" in the submodule declaration. Is my idea to have an external project as feature possible at all? Any other idea how I can accomplish this (maybe a git submodule or something)?
Thanks!
Try to follow the pattern what INET is using with regards to the TCP implementations. INET has it's own TCP module (in the TCP_INET feature) and also two alternative implementation defined by the TCP_lwIP and TCP_NSC features. Take a look at the src/makefrags file to check the wizardry how to add compiler and linker flags based on the enablement of a particular feature. e.g.:
WITH_TCP_LWIP := $(shell (cd .. && ./bin/inet_featuretool -q isenabled TCP_lwIP && echo enabled) )
ifeq ($(WITH_TCP_LWIP), enabled)
INCLUDE_PATH += -Iinet/transportlayer/tcp_lwip/lwip/include -Iinet/transportlayer/tcp_lwip/lwip/include/ipv4 -Iinet/transportlayer/tcp_lw
endif
This code checks whether the TCP_lwIP feature is enabled and adds the necessary include paths. You can add also linker flags if you have to link with the external project. (you can add compiler and linker flags also in the oppfeatures file if you don't need anything complicated )
Now, how to deal with the optional NED types? Also take a look at how the TCP module is defined in the StandardHost:
tcp: <default(firstAvailable("Tcp", "TcpLwip", "TcpNsc"))> like ITcp
As the given module is optional, you always have to have "something" that could be used instead of it. At least a dummy module. Now the there is an ITcp interface module (that is always present) and all the different TCP implementations "implement" it. What you see here is that tcp is a module which looks like the ITcp module and during the build up, the actual implementation will be either Tcp, TcpLwip or TcpNsc in this particular order. Whichever is present actually in the ned type tree. By disabling a feature, we actually remove the given ned type from the ned path too (the feature excludes the given NED package that contains the implememtation).
from the OMNeT++ API (NED functions):
string firstAvailable(...)
Accepts any number of strings, interprets them as NED type names (qualified or unqualified), and returns the first one that exists and its C++ implementation class is also available. Throws an error if none of the types are available.
This NED function was specifically invented and added to OMNeT++ for these purposes (to scan for the presence of a given NED type)
I'm generating a Go file (to include constants such as build version etc) so that the constants can be used in other packages. I have a created a small tool that will create the file with go generate but am trying to think of an appropriate name so that
It is obvious that it is generated, so if it is missing (on build) the user then knows to run go generate
And I can then add the file to the .gitignore
My first guess is something like version_GENERATED.go
Any conventions I should be aware of or better suggestions?
Having a suffix like _GENERATED added to the file name does not hold any information until the file is generated, as the compiler will just give you "unrelated" errors like "undefined: xxx" (the compiler won't guess that if the identifier would exists, it would be in version_GENERATED.go).
For example the stringer generator generates files with name type_string.go where type is replaced with the name of the type it is generated for.
So I think simply following the general guidelines for file names is enough, except maybe use _gen or _generated suffix. Or if your tool is public and used by others too, then use the name of the tool as the suffix (like stringer does).
If you do want the user to get a talkative error message in case your generator is yet to be run, your generator may generate an exported constant whose name is talkative if included in an error message, like:
const MustRunStringerGenerator = 0
And in your program refer to it like:
var _ = MustRunStringerGenerator // Test if stringer has been run
If stringer has not yet been run, you'll see an error message:
undefined: MustRunStringerGenerator
So I have the following files
/src/baseService.thrift
/baseTypes.thrift
/baseSecurity.thrift
I want all of these thrift definitions to be created into one library. The top of each file is thus:
baseService.thrift
==================
namespace java foo.bar
namespace cpp foo.bar
namespace js foo.bar
namespace go foo.bar
import "baseTypes.thrift"
baseTypes.thrift
================
namespace java foo.bar
namespace cpp foo.bar
namespace js foo.bar
namespace go foo.bar
baseSecurity.thrift
===================
namespace java foo.bar
namespace cpp foo.bar
namespace js foo.bar
namespace go foo.bar
import "baseTypes.thrift"
The problem is, how to I create all of these into one lib package? It works fine for java/cpp/js but when I try to build for go it's a no go.
With thrift, you can't do a thrift gen:baz *.thrift, you have to do the files one at a time. For the other languages, we just do a:
for f in `find *.thrift`; do
thrift -o myGenDir --gen go $f"
done
(substitute appropriate gen command for each lang)
For Python this is fine because it puts every gen'd file in it's own dir based on the filename [ i.e. foo/bar/{filename}/ttypes.py]. For Java it dumps all of the files in foo/bar/ but every class name is unique. For cpp, it dumps it all into the gen dir, but uniquely named per thrift file [so {filename.h}, {filename.cpp}]. For Go, however, it dumps everything into foo/bar like so:
/foo/bar/constants.go
/foo/bar/service.go
/foo/bar/service-remote/
/foo/bar/baz/ [for anything that has a namespace of foo.bar.baz]
/foo/bar/ttypes.go
The problem is, the ttypes.go and (presumably) constants.go are getting overwritten by whatever is gen'd last in the for loop. Is there a way around this? It works for the other languages - seems like it's an oversight for Go. What am I missing. We've got lots of Thrift files with lots of stuff in them - I'd rather not have to combine everything that's at the same package level into one thrift file.
The problem is, the ttypes.go and (presumably) constants.go are getting overwritten by whatever is gen'd last in the for loop.
Yes, that's true.
Is there a way around this?
The most (cross-language) portable recommendation is to not do this. Instead:
put different IDL files into different namespaces
put everything belonging to one namespace into exactly one IDL file
The Thrift compiler offers a few compiler switches for Go that may help you at least partially, (you get all available options for all languages by typing thrift --help on the command prompt)
go (Go):
package_prefix= Package prefix for generated files.
thrift_import= Override thrift package import path (default:git.apache.org/thrift.git/lib/go/thrift)
package= Package name (default: inferred from thrift file name)
These options are used like in
thrift -gen go:package=mypack,package_prefix=myprefix
It works for the other languages - seems like it's an oversight for Go.
It might be your impression but I'd recommend not to try it, if you are interested in cross-language compatibility. The behaviour is the same with other languages. Just as an example: I recently fixed (or better: worked around) a problem with the Erlang tests, where I had to fight exactly this very same issue.
Had the same problem recently. Every IDL in different namespaces just doesn't work. Code looks bad, different namespaces everywhere that you have to remember, annoying to add/remove namespaces for every little thing.
I only define a single namespace so I come with this. Basically, objects are in different files but they're written as they're in a single file. So no imports, no cross-file references, no namespaces in every file. I put namespaces in a separate file. Then my script joins everything into one big thirft file and compiles it. It does require you to put everything in the right order but it works for languages I need - Go, C# and Java worked fine.
For me it too looks like an oversight. There is no reason for it to be like that just for Go. Maybe some day I will send a merge request with behaviour that better matches other languages.