Since there's nothing about this on google, I opened this issue.
I'm trying to compile this code:
module Random: Mirage_random.S = struct
include Mirage_random_stdlib
end
module Ipv4: Static_ipv4.Make(Random, Clock, Ethernet, Arp) = struct
include Static_ipv4
end
but I get this:
root#66f08fd7c55b:/workspaces/ocaml_env/mirage-tcpip/examples/raw_ip_tcp_example# dune build raw_ip_tcp_example.exe
Entering directory '/workspaces/ocaml_env/mirage-tcpip'
File "examples/raw_ip_tcp_example/raw_ip_tcp_example.ml", line 44, characters 36-37:
44 | module Ipv4: Static_ipv4.Make(Random, Clock, Ethern
^
Error: Syntax error: module path expected.
You can see the static_ipv4 file here https://github.com/mirage/mirage-tcpip/blob/master/src/ipv4/static_ipv4.mli#L17
I don't have any idea of why this error happens. I didn't include Clock, Ethernet, Arp because the error is already on Random. You can see the random signature here: https://github.com/mirage/mirage-random/blob/master/src/mirage_random.ml and the implementation I'm including here https://github.com/mirage/mirage-random-stdlib
I don't know about Mirage at all, but conventionally Make is a functor. I.e., it maps modules to modules. But you have the call in the syntactic position of a module type.
I would expect something more like this:
module Ipv4 = Static_ipv4.Make(. . .)
My apologies if this isn't helpful.
First, you have a syntax error, functor application should be written:
Static_ipv4.Make(Random)(Clock)(Ethernet)(Arp)
Then you have a kind error: Static_ipv4.Make(Random)(Clock)(Ethernet)(Arp) is a module expression, not a module type. Moreover, it is not clear if you even need a signature constraint. Simply writing
module Ipv4 = struct
include Static_ipv4
let more = 0
end
works if you wanted to make an extended version of the Static_ipv4 module.
But maybe, you wanted to add few functions to the functor result?
In this case, you can use:
module Ipv4 = struct
include Static_ipv4.Make(Random)(Clock)(Ethernet)(Arp)
let an_new_and_shiny_function = ()
end
If you really want to enforce that the type is the same, you need to reuse the signature of the functor result:
module Ipv4: sig
include Mirage_protocols.IP with type ipaddr = Ipaddr.V4.t
val connect : ip:(Ipaddr.V4.Prefix.t * Ipaddr.V4.t) -> ?gateway:Ipaddr.V4.t ->
end
= struct
include Static_ipv4.Make(Random)(Clock)(Ethernet)(Arp)
let an_new_and_shiny_function.
end
Related
dear
i wrote this code to calculate wind speed from anemometer
below the error message
windspeedcode2:15: error: 'FreqCount' is not a class, namespace, or
enumeration
FreqCount::f_comp= 8; // Set compensation to 12
^
windspeedcode2:16: error: 'FreqCount' is not a class, namespace, or
enumeration
FreqCount::start(100); // Start counting with gatetime of
100ms
^
windspeedcode2:17: error: 'FreqCounter' has not been declared
while (FreqCounter::f_ready == 0) // wait until counter
ready
^
windspeedcode2:19: error: 'FreqCount' is not a class, namespace, or
enumeration
freq=FreqCount::f_freq;//read frequency value
^
exit status 1 'FreqCount' is not a class, namespace, or enumeration
This report would have more information with "Show verbose output
during compilation" option enabled in File -> Preferences.
:: is the scope resolution operator for defining the same function outside the class
. is the dot operator used to call a member function (or member variable) on a object.
An example would be (assuming a instance named FreqCount exist in you library header): FreqCount.f_comp= 8;
Only if f_comp is a static class member variable can it be accessed is you called it: FreqCount::f_comp= 8; But that is unlikely for a library.
So what is in your header and where does the library come from?
thank you for your help the problem has been solved by downloading another library
as shown in picture
I am currently using the Map functor to create a string map: module StringMap = Map.Make(String).
I then am trying to insert a set of mappings of strings to a list of 'a objects into the StringMap. to check if the key already exists, I am doing the following:
match StringMap.find_opt key my_map with
| None -> StringMap.add key [child] my_map
| Some l -> StringMap.add key (child::l) my_map
However, when I compile, I get an error saying the binding for find_opt has an unbound value, even though it is defined in the signature: https://ocaml.org/learn/tutorials/map.html.
I have also tried using StringMap.mem key my_map, but get the following error:
Error: This expression has type string but an expression was expected of type
'a StringMap.t =
(StringMap.Key.t, 'a, StringMap.Key.comparator_witness)
Base__Map.t
I've looked around to see if there is a typing error or something but have been unable to find anything. Any ideas as to why I am getting either of these errors?
According to the error message you're using Base (or Core) library, which are substitutions for the OCaml standard library and have the different interface. In particular, the find function in the Map interface already returns an option type, and thus there is no find_opt function.
Perhaps, you've used some example from the jbuilder tutorial that enables this library automatically.
You can either switch to the standard library or enable the compatibility with the vanilla OCaml standard library by opening the compatibility module Caml, e.g.,
open Caml
(* your code goes below *)
I define an outer syntax command, imake to write some code to a file and do some other things. The intended usage is as follows:
theory Scratch
imports Complex_Main "~/Is0/IsS"
begin
imake ‹myfile›
end
The above example will write some contents to the file myfile. myfile should be a path relative to the location of the Scratch theory.
ML ‹val this_path = File.platform_path(Resources.master_directory #{theory})
I would like to be able to use the value this_path in specifying myfile. The imake command is defined in the import ~/Is0/IsS and currently looks as follows:
ML‹(*imake*)
val _ = Outer_Syntax.improper_command #{command_spec "imake"} ""
(Parse.text >>
(fn path => Toplevel.keep
(fn _ => Gc.imake path)))›
The argument is pased using Parse.text, but I need feed it the path based on the ML value this_path, which is defined later (in the Scratch theory). I searched around a lot, trying to figure out how to use something like Parse.const, but I won't be able to figure anything out any time soon.
So: It's important that I use, in some way, Resources.master_directory #{theory} in Scratch.thy, so that imake gets the folder Scratch is in, which will come from the use of #{theory} in Scratch.
If I'm belaboring the last point, it's because in the past, I wasted a lot of time getting the wrong folder, because I didn't understand how to use the command above correctly.
How can I achieve this?
Your minimal examples uses Resource.master_directory with the parameter #{theory} to define your path. #{theory} refers (statically) to the theory at the point where you write down the antiquotation. This is mostly for interactive use, when you explore stuff. For code which is used in other places, you must use the dynamically passed context and extract the theory from it.
The function Toplevel.keep you use takes a function Toplevel.state -> unit as an argument. The Toplevel.state contains a context (see chapter 1 of the Isabelle Implementation Manual), which again contains the current theory; with Toplevel.theory_of you can extract the theory from the state. For example, you could use
Toplevel.keep (fn state => writeln
(File.platform_path (Resources.master_directory (Toplevel.theory_of state))))
to define a command that prints the master_directory for your current theory.
Except in simple cases, it is very likely that you do not only need the theory, but the whole context (which you can get with Toplevel.context_of).
Use setup from preceding (parts of the) theory
In the previous section, I assumed that you always want to use the master directory. For the case where the path should be configurable, Isabelle knows the concept of configuration options.
In your case, you would need to define an configuration option before you declare your imake command
ML ‹
val imake_path = Attrib.setup_config_string #{binding imake_path}
(K path)
› (* declares an option imake_path with the value `path` as default value *)
Then, the imake command can refer to this attribute to retrieve the path via Config.get:
Toplevel.keep (fn state =>
let val path = Config.get (Toplevel.context_of state) imake_path
in ... end)
The value of imake_path can then be set in Isar (only as a string):
declare [[imake_path="/tmp"]]
or in ML, via Config.map (for updating proof contexts) or Config.map_global (for updating theories). Note that you need to feed the updated context back to the system. Isar has the command setup (takes an ML expression of type theory -> theory) for that:
setup ‹Config.map_global imake_path (K "/tmp")›
Configuration options are described in detail in the Isar Implementation Manual, section 1.1.5.
Note: This mechanism does not allow you to automatically set imake_path to the master directory for each new theory. You need to set it manually, e.g. by adding
setup ‹
Config.map imake_path
(K (File.platform_path (Resources.master_directory #{theory})))
›
at the beginning of each theory.
The more general mechanism behind configuration options is context data. For details, see section 1.1 and in particular section 1.1.4 of the Isabelle Implementation Manual). This mechanism is used in a lot of places in Isabelle; the simpset, the configuration of the simplifier, is one example for this.
I'm trying to debug some code in which members of a user defined object mysteriously change addresses, and while doing that I realized user defined objects do that as well. Here's a small example of querying object address from function that created it and then from its member function:
module foo_module
type foo_type
contains
procedure :: foo
end type foo_type
contains
subroutine foo(this)
class(foo_type) :: this
print *, 'Inside foo this is', loc(this)
end subroutine foo
end module foo_module
program trial
use foo_module
type(foo_type) :: object
print *, 'Object address', loc(object)
call object%foo()
end program trial
A sample output I get is:
Object address 4452052800
Inside foo this is 140734643354880
Why am I getting two different addresses for the same object? Am I doing something wrong? Or is there something with LOC that comes into play I don't understand?
I'm using ifort under osx.
LOC is an extension. Its behaviour is as specified by the compiler vendor.
What the behaviour intended by the vendor here isn't clear, but the difference that you are seeing is that in the main program you get the integer equivalent of the memory address of the non-polymorphic object (what you probably expect), while in the subroutine you get the integer equivalent of the memory address of the polymorphic descriptor for the object (maybe what you want, maybe not).
Using TRANSFER(C_LOC(xxx), 0_C_INTPTR_T) is a more portable way of getting the integer representation of the address of an object (where the C_* things are from the ISO_C_BINDING intrinsic module). C_LOC requires that its argument have the TARGET attribute and be non-polymorphic (use SELECT TYPE).
I'd recommend asking on the relevant Intel Forum if you want further clarification on the intended behaviour of the LOC extension.
I reported the bug to the developers our internal issue ID is DPD200253159. I found that the C_LOC function from ISO_C_BINDING works. For example:
subroutine foo(this)
use, intrinsic :: iso_c_binding
class(foo_type) :: this
print *, 'Inside foo this is', transfer(c_loc(this),0_C_INTPTR_T)
end subroutine foo
Let's say I have a Foo.fsx script that contains this code:
module Bar =
let foobar = "foo"+"bar"
open Bar
let a = System.Reflection.Assembly.GetExecutingAssembly()
let ty = a.GetType("Foo.Bar") // but it returns null here
How can I achieve that? Thanks!
This is a tricky question, because F# interactive compiles all types into types with some mangled names (and the executing assembly can contain multiple versions of the same type).
I managed to do it using a simple trick - you'd add an additional type to the module - then you can use typeof<..> to get information about this type. The type inside a module is compiled as a nested type, so you can get the name of the type representing the module from this (nested) type:
module Bar =
let foobar = "foo"+"bar"
type A = A
// Get type of 'Bar.A', the name will be something like "FSI_0001+Bar+A",
// so we remove the "+A" from the name and get "FSI_0001+Bar"
let aty = typeof<Bar.A>
let barName = aty.FullName.Substring(0, aty.FullName.Length - "+A".Length)
let barTy = aty.Assembly.GetType(barName)
// Get value of the 'foobar' property - this works!
barTy.GetProperty("foobar").GetValue(null, [| |])
You could probably simply search all types in the assembly looking for +Bar. That would work as well. The benefit of the trick above is that you get a reference to the specific version of the type (if you interactively run the code multiple times, you'll get a reference to the module corresponding to the current Bar.A type)
As a side-note, there were some discussions about supporting moduleof<Bar> (or something like that) in future versions of F# - this is a bit inelegant as it is not a real function/value like typeof, but it would very useful!