Why module using .A has to be prefixed with dot? It doesn't work if you omit the dot.
File ./A.jl
module A
export sayHi
function sayHi()
println("hi")
end
end
File ./Main.jl
include("./A.jl")
using .A # <= Why it has to be prefixed with dot?
sayHi()
Running, start REPL and type
include("./Main.jl")
Part 2
And if you move file A.jl to different location, like ../some-dir/A.jl it has to be prefixed to two dots using ..A. Why?
Because you define module A inside your current module. The dot means "look inside the current module for this". https://docs.julialang.org/en/v1/manual/modules/#Relative-and-absolute-module-paths-1
After digging it deeper - it seems like the answer is - don't use modules.
The documentation is wrong, it says
When in reality, the module usage is heavily tied to the location of files, it could be using Foo, using .Foo, using ..Foo or using Main.Foo - depending on the location of the Foo module relative to the file that imports it. In my personal opinion - something is very wrong with that design.
No support in the VSCode Editor, it doesn't understand using ..Foo. There are other ways to use modules, including altering startup.jl or JULIA_LOAD_PATHS - none of it works either. I assume nobody noticing these problems because nobody actually using modules.
Top answer on YCombinator - gives the same answer - the best way to use modules in Julia - is to not use it at all https://news.ycombinator.com/item?id=19232824
Related
For Python there is an option to add custom CSS to a Dash app. The method seems quite straightforward, it says
Just create a folder named assets in the root of your app directory
and include your CSS and JavaScript files in that folder. Dash will
automatically serve all of the files that are included in this folder.
By default the url to request the assets will be /assets but you can
customize this with the assets_url_path argument to dash.Dash
source: https://dash.plotly.com/external-resources
However when I try to do so in Julia, nothing happens.
Is this feature a thing in Julia? If not, how can I do so?
Found a hack, have no idea if this is the correct way though...
Essentially tried to find the inputs to app = dash() by going methods(dash)
julia> methods(dash)
# 1 method for generic function "dash":
[1] dash(; external_stylesheets, external_scripts, url_base_pathname, requests_pathname_prefix, routes_pathname_prefix, assets_folder, assets_url_path, assets_ignore, serve_locally, suppress_callback_exceptions, prevent_initial_callbacks, eager_loading, meta_tags, index_string, assets_external_path, include_assets_files, show_undo_redo, compress, update_title) in Dash at C:\Users\<User>\.julia\packages\Dash\Weukk\src\app\dashapp.jl:291
where I noticed a arg assets_folder. Putting in the absolute path seems to work so the full code looks something like this
using Dash
app = dash(assets_folder="/absolute/path/to/assets")
I'm having problem understanding how to correctly set the COMPILE_DEFINITIONS target properti in CMake.
my target is add_library(modelutilities STATIC ${modelutilities_SRCS})
I if use
set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} ${Qt5Widgets_COMPILE_DEFINITIONS})
set_target_properties(modelutilities PROPERTIES
VERSION "0.0.1"
SOVERSION 0
EXPORT_NAME "ModelUtilities"
ARCHIVE_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/lib"
LIBRARY_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/lib"
RUNTIME_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/bin"
COMPILE_DEFINITIONS ${modelutilities_COMPILE_DEFINE}
)
everything works fine, but if I add another line between them with set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} MODELUTILITIES_LIB) it stops working complaining that set_target_properties was called with the wrong number of arguments.
Anyone can spot what I'm doing wrong?
P.S.
I already tried using doublequotes: set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} "MODELUTILITIES_LIB"). It did not change anything
P.P.S.
If I message(STATUS ${modelutilities_COMPILE_DEFINE}) QT_WIDGETS_LIB;QT_GUI_LIB;QT_CORE_LIB in the first case and QT_WIDGETS_LIB;QT_GUI_LIB;QT_CORE_LIB;MODELUTILITIES_LIB in the second
With newer version of CMake, what is being preached is the idea of targets. So, for example, instead of include_directories() it's now preferred to use target_include_directories().
That being the case I think you'd be better served using the preferred target_compile_definitions() to set compile definitions for your utilities library.
One advantage you get is that your can scope your compile definitions using the PUBLIC or PRIVATE keywords.
I am trying to use a tree based map in Coq, specifically Coq.FSets.FMapAVL.
I found this 4 year old question: Finite map example
Looking at the standard lib documentation referenced in the comments, I see this note:
NB: This file is here only for compatibility with earlier version of FSets and FMap. Please use Structures/Orders.v directly now.
What does this mean? When I google "Structures.v" or "Orders.v" I always end up at other documentation pages with related deprecation warnings.
What is the proper, non-deprecated way to use an FMap in Coq 8.6?
Since the OrderedTypeEx module is deprecated, we won't use Nat_as_OT defined in it.
There is Nat_as_OT in OrdersEx (just a synonym for PeanoNat.Nat), which is useful for our purposes.
Unfortunately, the following code
Require Import Coq.Structures.OrdersEx.
Module M := FMapAVL.Make Nat_as_OT.
won't work, because signatures OrderedType.OrderedType (currently used by FMapAVL) and Orders.OrderedType are not compatible.
However, the OrdersAlt module contains functors, which allow to build a module of one type from another. In this case, we are interested in Backport_OT. The following code shows how to use FMapAVL.Make, the rest of the code can be copied from the linked question:
From Coq Require Import
FSets.FMapAVL Structures.OrdersEx Structures.OrdersAlt.
Module backNat_as_OT := Backport_OT Nat_as_OT.
Module M := FMapAVL.Make backNat_as_OT.
The situation with FMapAVL was explained by Pierre Letouzey in this Coq-Club post:
the transition between old-style OrderedType and the new one isn't
finished yet (some work remain to be done on FMaps for instance),
and we cannot simply remove the old-style OrderedType.
Ada is still new to me, so I am trying to find my way around the GPS IDE. I asked another question earlier, but I think this problem has precedence over that one, and may be at the root of my trouble.
When I compile, I am getting a long list of *warning: source file ... not found"
In my .gpr file, I have listed all of the spec and body source files and use the following naming scheme:
package Naming is
for Casing use "mixedcase";
for Dot_Replacement use ".";
for Spec_Suffix ("ada") use "_s.ada";
for Body_Suffix ("ada") use "_b.ada";
end Naming;
What is odd it the error messages all look either like this:
warning: source file "xxx_b.adb" not found
or this
warning: source file "xxx.adb" not found
Note that neither of these (xxxb.adb or xxx.adb) conform to the file specs, which should end with .ada.
Can someone explain what is going on here?
I'm 99% sure that the problem is one of the ones I mentioned in answer to your other question: GNAT does not normally support more than one compilation unit in a file. I got exactly the behaviour you describe with GPS and these files:
james_s.ada:
with Jane;
package James is
end James;
jim_s.ada:
package Jim is
end Jim;
package Jane is
end Jane;
The error message on compiling james_s.ada says it can't find Jane_s.ada, but when I ask GPS to go to the declaration of Jane it takes me to the "correct" line in jim_s.ada.
You could use gnatchop to split jim_s.ada, but it doesn't understand project files or naming conventions; you probably want to keep the existing names for the code that works, so you'd rename gnatchop's output as required.
However! to my great surprise, it turns out that GNAT does support having more than one compilation unit in a file, provided package Naming in the project file tells it about each unit in the file:
package Naming is
for Casing use "mixedcase";
for Dot_Replacement use ".";
for Spec_Suffix ("ada") use "_s.ada";
for Body_Suffix ("ada") use "_b.ada";
for Spec ("Jim") use "jim_s.ada" at 1;
for Spec ("Jane") use "jim_s.ada" at 2;
end Naming;
It's up to you whether to do this or to bite the bullet and use gnatchop, either on the multi-unit files or on the whole source tree.
First off, this isn't an Ada problem, its a Gnat problem. Other Ada compilers have no problem with the file names you are using.
However, Gnat is rather unique in that it expects there to be only one program unit (package body, package spec, stand-alone routine, etc) per source file. This is because it is also rather unique in that it expects to be able to find the source code for any program unit just by knowing that unit's Ada intentifier. Most other Ada compilers maintain some kind of library file that maps file names to program units, and you have to register all your files into it. (Whereas your typcial C compiler just leaves the problem of finding files for all your code up to the user entirely).
Generally the easiest thing to do with Gnat, the way that will cause you the least trouble, is to just use its default file naming convention (and of course don't put multiple program units in a single file.
If you already have some existing Ada code (perhaps developed for another compiler), the easiest way to import it into Gnat is typically to run the gnatchop tool on it all. So that's what I'd suggest you try.
From GPRbuild User's Guide:
Strings are used for values of attributes or as indexes for these attributes. They are in general case sensitive, except when noted otherwise [...]
Based on this, I believe you have to use "Ada" instead of "ada" as index for Spec_Suffix and Body_Suffix. I currently do not have access to the tools for testing this, so I suggest to just try it out.
Is there a way to create separate executables within one CMakeLists.txt file for the same classes, but for a different intention? This is somewhat like the DEBUG/RELEASE switch, but I need to do a decision at source code level.
Pseudo-CMakeLists.txt:
SET_INTENTION(app1 1)
ADD_EXECUTABLE(app1 main.cxx)
SET_INTENTION(app2 2)
ADD_EXECUTABLE(app2 main.cxx)
Pseudo-Code main.cxx:
if (intention == 1)
//do something different to intention == 2
I tried ADD_DEFINITIONS as preprocessor definitions and #ifdef in source, but CMake seems to interpret the whole file and got all definitions, no matter at what position the definition was added. Splitting the ADD_EXECUTABLES() into two CMakeLists.txt (in subfolders) is not really straight forward and leads to problems when using QT4_WRAP_CPP and QT4_WRAP_UI. I appreciate any ideas / workarounds.
The COMPILE_DEFINTIONS property looks promising:
add_executable(app1 main1.cxx)
get_target_property(APP1_COMPILE_DEFS app1 COMPILE_DEFINITIONS)
set_target_property(app1 PROPERTIES COMPILE_DEFINITIONS "${APP1_COMPILE_DEFS};INTENTION=1")
add_executable(app2 main2.cxx)
get_target_property(APP2_COMPILE_DEFS app2 COMPILE_DEFINITIONS)
set_target_property(app2 PROPERTIES COMPILE_DEFINITIONS "${APP2_COMPILE_DEFS};INTENTION=2")
Then use preprocessor #if INTENTION=1 and so forth in your source files. If you're not using a recent CMake, you may need to mess with the COMPILE_FLAGS property instead.