I'm trying to upgrade my code for FE in solid mechanics and wave-propagation. Because metis/5.1.0 is not properly compiling with my code (whereas metis/4.0.3 was linking perfectly), I want to switch to ParMETIS.
What ParMETIS function can I substitute for the METIS function metis_PartMeshDual?
Related
I'm using Julia to autograde students' work. I have all of their files Student1.jl, Student2.jl, etc. as separate modules Student1, Student2, etc in a directory that is part of LOAD_PATH. What I want to be able to do works completely fine in the REPL, but fails in a file.
macro Student(number)
return Meta.parse("Main.Student$number")
end
using Student1
#Student(1).call_function(inputs)
works completely fine in the REPL. However, since I'm running this in a script, I need to be able to include the modules with more metaprogramming that is currently not working. I would have thought that the exact same script above would have worked in a file Autograder.jl by calling
#eval(using Student1)
#Student(1).call_function(inputs)
in a module Autograder. But I get either an UndefVarError: Student1 not defined or LoadError: cannot replace module Student1 during compilation depending on how I tweak things.
Is there something small in Julia metaprogramming I'm missing here to make this autograding system work out? Thanks for any advice.
The code just as you have written works for me on julia versions 1.1.0, 1.3.1, 1.5.1, 1.6.0 and 1.7.0. By that I mean, if I add an inputs variable and put your first code block in a file Autograder.jl and run JULIA_LOAD_PATH="modules:$JULIA_LOAD_PATH" julia Autograder.jl with the student modules in the modules directory I get the output of the call_function function in the Student1 module.
However if Autograder.jl actually contains a module then the Student$number module is not required into Main and your macro needs to be modified accordingly:
module Autograder
macro Student(number)
return Meta.parse("Student$number") # or "Autograder.Student$number"
end
inputs = []
#eval(using Student1)
#Student(1).call_function(inputs)
end
Personally I wouldn't use a macro to accomplish this, here is one possible alternative:
student(id) = Base.require(Main, Symbol("Student$(id)"))
let student_module = student(1)
student_module.call_function(inputs)
end
or without modifying the LOAD_PATH:
student(id) = include("modules/Student$(id).jl")
let student_module = student(1)
student_module.call_function(inputs)
end
What are the differences between runghc and ghc?
I ran a short program that seemed to compile fine with both, except that I got the following with runghc, but not plain ghc:
error:
Variable not in scope: main :: IO a0
Perhaps you meant `min' (imported from Prelude)
It seems that compiling things in runghc, those things need Main function, while plain ghc, doesn't?
Is that all?
runghc is used to run programs directly, not compiling them. A file without a main IO action can't be run as, by definition, there is nothing to run.
What ghc does with a file not containing a main is compile it as a module, to be imported by other haskell programs/modules - these are, of course, not runnable.
I got the following error wich is common with generated sources:
spec of this package does not allow a body
I would like to know if it exist a rule to put in the gpr file to ignore this error.
Like a ignore flag.
As I mentionned this files are generated so i have no right on them (not alowed to suppress them neither rewrite them).
More over it would be nice to have a rule that work for every generation.
If you were to compile
package Guillaume is
end Guillaume;
package body Guillaume is
end Guillaume;
in Ada 1983 mode, you would get e.g.
gnatmake -gnat83 guillaume.ads
gcc -c -gnat83 guillaume.ads
guillaume.ada:1:09: warning: package "Guillaume" does not require a body
guillaume.ada:1:09: warning: body in file "guillaume.adb" will be ignored
Having a body that isn’t required by the spec was made illegal with Ada 95 (it would be possible to change a body and for the compilation process not to notice that it needed to be recompiled, leading to confusion). If your code generator was designed to produce Ada 83, then I guess you may have to face compiling in Ada 83 mode - but GNAT doesn’t, as far as I know, guarantee to be 100% compatible, particularly as far as the run time system is concerned.
Are the offending package bodies all actually empty? If so, you might be able to list them and use the Excluded_Source_List_File attribute in your project. If not, you are in trouble, because there’s no way (without changing package sources) to get the code in them to execute.
(Later): actually, Excluded_Source_List_File doesn’t help; it stops gprbuild looking at the file, but not the compiler; and it’s the compiler that rejects the body. Sorry. But if you could make such a list you could use it to delete the bad bodies.
You can exclude the body from the list of source files:
for Excluded_Source_Files use ("my_body.adb");
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.
I want to use R's mathematical functions as provided in libRmath from Ocaml. I successfully installed the library via brew tap homebrew science && brew install --with-librmath-only r. I end up with a .dylib in /usr/local/lib and a .h in /usr/local/include. Following the Ocaml ctypes tutorial, i do this in utop
#require "ctypes.foreign";;
open Ctypes;;
open Foreign;;
let test_pow = foreign "pow_di" (float #-> int #-> returning float);;
this complains that it can't find the symbol. What am I doing wrong? Do I need to open the dynamic library first? Set some environment variables? After googling, I also did this:
nm -gU /usr/local/lib/libRmath.dylib
which gives a bunch of symbols all with a leading underscore including 00000000000013ff T _R_pow_di. In the header file, pow_di is defined via some #define directive from _R_pow_di. I did try variations of the name like "R_pow_di" etc.
Edit: I tried compiling a simple C program using Rmath using Xcode. After setting the include path manually to include /usr/local/include, Xcode can find the header file Rmath.h. However, inside the header file, there is an include of R_ext/Boolean.h which does not seem to exist. This error is flagged by Xcode and compilation stops.
Noob alert: this may be totally obvious to a C programmer...
In order to use external library you still need to link. There're at least two different ways, either link using compiler, or link even more dynamically using dlopen.
For the first method use the following command (as an initial approximation):
ocamlbuild -pkg ctypes.foreign -lflags -cclib,-lRmath yourapp.native
under premise that your code is put into yourapp.ml file.
The second method is to use ctypes interface to dlopen to open the library. Using the correct types and name for the C function call, this goes like this:
let library = Dl.dlopen ~filename:"libRmath.dylib" ~flags:[]
let test_pow = foreign ~from:library "R_pow_di" (double #-> int #-> returning double)