Previously, GHC would inform me when I tried to import a module from an installed, but hidden, package:
Could not find module 'Foo'
It is a member of the hidden package 'foo-0.1.0.0'.
Perhaps you need to add 'foo' to the build-depends in your .cabal file.
Now1, it doesn't:
Could not find module 'Foo'
Perhaps you meant Bar (from bar-0.1.0.0)
Use -v to see a list of the files searched for.
Has this feature been removed, or is it simply off by default (and if so, how can I enable it)?
1 I suspect this came with the version bump to 8.0.0, though I'm not positive.
Related
I'm developing a package in RStudio with usethis, trying to make use of best practices. Previously, I had run usethis::use_tidy_eval(). Now, I'm using data.table, and set this up by running usethis::use_data_table(). I get a warning,
Warning message:
replacing previous import ‘data.table:::=’ by ‘rlang:::=’ when loading ‘breakdown’
because the NAMESPACE contains the the two lines:
importFrom(rlang,":=")
importFrom(data.table,":=")
It turns out I no longer need usethis::use_tidy_eval(), so I'd like to revert it and in doing so get rid of the warning.
How can I undo whatever usethis helper functions do? Must I edit the NAMESPACE myself? How do I know what else was modified by usethis::use_tidy_eval()? What about undoing usethis::use_pipe()?
Unless you made a Git commit before and after running that code, there's probably not an extremely easy way. The two options I'd consider would be:
Read the source code of the function. This can require some hopping around to find definitions of helper functions, but use_tidy_eval looks like it:
adds roxygen to Suggests in DESCRIPTION
adds rlang to Imports in DESCRIPTION
adds the template R file tidy-eval.R
asks you to run document() which is what actually updates the NAMESPACE. You can find the lines added by looking for the importFrom roxygen tags in the template file.
To undo this, you should just be able to delete all of the above. However, you need to be a bit careful - e.g. if you import functions from rlang outside of tidy-eval.R, removing it from DESCRIPTION might prevent installation. Hopefully any such issues would be revealed by devtools::check() if they do happen.
The other option would be to get an older version of your package, run use_tidy_eval() and document() and then compare the changes. That will be more comprehensive and might catch things I missed above, but the same caveats about not being able to necessarily just reverse everything still apply.
Same strategy for use_pipe().
Sidenote: there are probably ways to adequately qualify different uses of := so that both can coexist in your package, in case that would be preferable.
I've got this section in my project's root's meson.build:
if get_option('gen_py_bindings')
message('told to build py bindings')
custom_target('py_bindings',
command: ['env', '_MESON_MODULE_NAME=' + meson.project_name(), ',_MESON_MODULE_VERSION=' + meson.project_version(), './py3_bindings/setup.py', 'build'],
depends: [mainlib],
depend_files: files(['py3_bindings/module.c', 'py3_bindings/setup.py']),
input: ['py3_bindings/setup.py'],
install: false, output: 'sharedextension.so')
endif
It's a custom target that runs a setup.py script to build python bindings for my project's library.
The problem is that it is always seemingly up-to-date. I've used the depends keyword argument to specify that it depends on another build target in the project, and the depend_files keyword argument to specify that it depends on the C source file that the script uses to build the extension, as well the actual script that is being ran as the command. I've also used the input keyword argument even though I don't understand the difference between it and depend_files.
I can only get the custom target to regenerate if I make a change to meson.build (the message() call is displayed successfully).
No other change will do. I've tried updating all files listed in the custom target but it always results in: ninja: no work to do.. Even if other out-of-date targets get rebuilt/relinked/etc...
I'm using ninja 1.9.0 and meson 0.52.1 on linux.
I am also well aware of the build_always_stale keyword argument but I don't want to use it unless necessary. (update: setting it to true still doesn't result in the target rebuilding, looks like there's something more at play here but I can't figure it out).
By default, custom targets don't get built when running plain ninja and thus the build_by_default keyword argument needs to be passed and set to true, e.g.
custom_target('target', build_by_default: true)
In the package inferred system, you can specify a dependency on a package of the form "a/b/c" where a is the package name and there is a lisp file at "b/c.lisp" that defines the "a/b/c" package.
Is there a way to specify a different path for the file for the package inferred system? For example say the file is at "src/b/c.lisp" instead of "b/c.lisp".
It's probably a bug that package-inferred-system uses system-source-directory instead of component-pathname. If you think it is, please file a bug against https://bugs.launchpad.net/asdf
Unhappily, bug or not, any fix isn't going to be released then made universal for a while. So at least for the next two years, you can't rely on it unless you provide your own fixed ASDF.
As for a workaround — why not place your .asd file in src/ if you want all source under there???
You can use register-system-packages to specify which packages a system provides. You can read more here
Since in http://julia.readthedocs.org/en/latest/manual/modules/ there's no much info about modules, I would like to ask the following.
I want to try two modules via ijulia. Both modules are in my working directory as
name-of-files.jul. I will call them generically module_1.jul and module_2.jul.
module_1.jul uses module_2.jul and I load it with
using module_2
On ijulia session, if I try
using module_1
gives an error. I also tried
include("module_1.jul")
This last sentence, when executed, rises an error because the module_1.jul cannot find
variable "x" that I know is contained in module_1.jul (in this case I "loaded" the module
using include("module2.jul") inside module_1.jul
Julias module system assumes some things that aren't necessarily obvious from the documenation at first.
Julia files should end with .jl extensions.
Julia looks for module files in directories defined in the LOAD_PATH variable.
Julia looks for files in those directories in the form ModuleName/src/file.jl
If using module_1 fails then I'm guessing it's because it's source files fail one of the above criteria.
Some time has passed since this question. Recently, Noah_S wrote the solution in the comments of the previous answer; this means that it is a recurrent doubt for people starting to learn the language. For their sake, I will re-write it here Noah_S' answer along with my most novel solution.
I am a mess with the julia versions and which commands work with the specific ones, so for older julia versions we have to look for the \path and then include in the julia module
push!(LOAD_PATH, "/path")
In newer versions this can be improved. Forget about looking by hand the path and just do
path = readstring(`pwd`)
push!(LOAD_PATH, chomp(path))
I hope this can be useful to many julians newcomers.
I'm trying to get package references resolved during a build, using GNAT Programming Suite (hosted on Win XP). In the Builder Results, I get errors like this one:
file "ac_configuration_s.ada" not found
Clicking on the error takes me to a line like this:
with
Ac_Configuration,
Dispense_Timer,
...
The first item (Ac_Configuration) isn't resolved, but the second item (Dispense_Time) is resolved. I have several others that do or don't resolve. All of the files in question (spec and body) are identified as source files.
When I hover my mouse over the line with the error, a popup shows up that offers this:
(Cross-references info not up to date. This is a guess.)
Ac_Configuration
local package declared at D_Ac_Config_S.Ada:85
The guess is correct, but I don't know how to use this. How do I get this to correctly build?
Update
Here is teh call to gcc
gcc -c "-gnatec=C:\Source\build\GNAT-TEMP-000001.TMP" -I- -gnatA
-x ada "-gnatem=C:\Source\build\GNAT-TEMP-000002.TMP" "C:\Source\C_Cbt_Main_B.Ada"
I don't see a reference to teh "miimal" switch.
In this case, there is no corresponding body file file D_Ac_Config_S.Ada. So the is no body file to compile separately.
When I right click on the package reference inside the with, I can goto the declaration of Ac_Configuration and every other package name that is the source of an error. So these lreferences are being resolved somehow.
By the way, I have not used ADA before, so I'm still trying to understand everything.
It looks as though you're using _s.ada as the suffix for specs, and I'm guessing _b.ada for bodies?
GNAT may have difficulty with this naming convention. It's possible, using a GNAT Project file (.gpr), to alter GNAT's default convention ({unit-name}.ads for specs, {unit-name}.adb for bodies) but the rules (see "Spec_Suffix") say "It cannot start with an underscore followed by an alphanumeric character" (I haven't tried this, but you can see that it would confuse the issue if you had a package Foo_S, for example).
LATER: It turns out that GNAT (GPL, 4.7, 4.8) is quite happy with your suffixes!
If the package Ac_Configuration is really a local package declared at line 85 of D_Ac_Config_S.Ada, then there's your problem; you can only with a library unit, which in this case would be D_Ac_Config.
with D_Ac_Config;
...
package Foo is
...
Bar : D_Ac_Config.Ac_Configuration.Baz;
I wonder whether D_Ac_Config_S.Ada (for example) actually contains multiple Ada units? (if so, compiling that file should result in a compilation error such as end of file expected, file can have only one compilation unit). GNAT doesn't support this at compile time, providing instead a utility gnatchop.
Would it be possible to just gnatchop all the source and be done with it?
Hm, I think it sounds like the compiler's got a bad set of objects/ALIs it's working with, hence the cross-reference not up to date error. (Usually the compiler's good about keeping things up to date; but you may want to check to see if the "minimal recompilation" switch is set for the project.)
Have you tried compiling just the ["owning"] file D_Ac_Config_S.Ada? (i.e. if it were a spec, go to the corresponding body and compile that.) That should force its ALI/object files to be updated.
Then try building as normal.
-- PS: you might have to clean first.