Unbounded Value OCAML [closed] - makefile

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I am trying to compile Orange as part of OTAWA
However I get the below Error in file wcee.ml
Error: Unbound value IMap.print_ordered
The reason for the error is the below snippet.
let glb = common
(** Least upper bound. *)
let lub = IMap.combine max
(** Pretty printer. *)
let print = IMap.print CostItem.print Format.pp_print_int
(** Full printing. *)
let print_complete = IMap.print_ordered ~first:"" ~firstbind:">> " ~last:"" ~sep:"#\n" CostItem.print CostItem.known Format.pp_print_int
end
What is the reason for that ?

TL,DR: at first sight, it might be possible that the project currently just FTBFS (fails to build from source)? Anyway, I didn't attempt to compile it myself, but you may want to get in touch with the TRACES research team that maintains OTAWA to ask? (e.g., emailing Pr. CASSÉ…)
Further details:
the latest version of the source code seems to be online at this URL: wcee.ml,
which depends on tMap.ml,
the function you mention is defined via module IMap = TMap.Make(CostItem), which depends on the Make functor in the tMap compilation unit, which indeed does not seem to provide the print_ordered function,
hence the Unbound value error (which just means "this function is undefined!")

Related

Is commenting every right brace good/bad style? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am teaching an upper-division software engineering course and am reviewing every student's code. Some of my students have picked up the habit elsewhere of adding a comment to the right of every closing brace identifying the statement type, such as:
if (x > 3) {
y = 10;
} //if
I have told the students to follow the Android code style guidelines, which says nothing about this practice. On what grounds should I tell them not to do this (besides personally not liking it), or should I permit it?
Comments are for clarifying code and increasing readability. It's clear enough to most reasonable software developers that the statement is an "if." Furthermore, many IDEs and editors automatically highlight brackets such as these, so the comment isn't necessary. Generally, you should save comments for describing what methods, classes and variables do (e.g. in Javadoc), or what subroutines within a method will do. This is based on the general guideline of making sure everything you add improves the code.
Tell them that they should assume that person who review code knows language syntax and how to program. Comments should be rare, indicate and explain some weird and not obvious code section (for instance the api provided by some library is bugged and some workarounds/hacks are needed). We've got documentation (and unit tests) to explain how to use and how code should behave. For educational purpose you can write small class/module filled with such "comment-documentation", give it to students and ask them what did they learn about code from these comments.
Well, most likely this will end up in a discussion based on personal preference - which is not within the scope of stackoverflow. But aI'll answer anyway:
In my opinion, that's a bad thing to do - for multiple reasons.
It messes up the code. the more comments are in there, the less readable it is. A single } in a line tells me, instantly, that the last block ends here. with the comment behind, there is more to read - and no additional info (but people will read anyway, cause they don't know that the comment doesn't include any info... and because people tend to read everything automatically)
It leads to sloppy indentation. After all, that may even be the reasons people started that in the first place.
it's unnecessary - if I indet the code in a consistent manner, it shouldn't be necessary to note what was closed, it should be easily visible by just going up to where the last statement with the same indentation level was. In most cases (unbless you're reverse-indenting (or whatever that is called), which I don't like at all) this should be very easy, as there is nothing in between...
it leads to bigger file sizes. may be invalid on modern systems, but still.
Every time is overkill. It depends on the level of indentation and the length of your function, but these are usually signs that you need to step back and refactor. The only time I explicitly do it is for namespaces in C++

How to comment code that has a complicated explanation [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a if (a > b) { .. in my code, which I would like to explain why is there to someone looking at the code.
The reason for it being there is quite complicated and cannot be explained well without the use of images.
The question is, how to best document this to a programmer looking at the code? Is there a generally accepted way?
Should I create a comment in the code saying "See explanation XX", and then create a document somewhere containing XX?
Much of this will depend on what you are coding and the size of your project, but generally I would say that you should comment this particular conditional with an explanation only for what if (a > b) { .. is checking for, and why.
When you get to the content inside the if condition, explain that. Broader explanations as to the purpose of the function itself and its objectives should generally be in the declaration, although you can also add descriptions to the definition (I prefer to avoid this generally, although I sometimes describe the method in further detail on top of the definition, where it would simply clutter the declaration of the class).
For example,
class A
{
// this method performs operations on x or y as appropriate, given the input conditions of
// a and b. Its purpose is ... and in order to achieve this it does ...
void Method(int a, int b);
};
// elsewhere in a .cpp file
// Note that this method uses method abc rather than method cde in order to achieve
// such and such more efficiently (description here is more technical than in the
// declaration, and might focus on more specific issues while still remaining
// applicable to the function as a whole, and should therefore not be in the body)
void A::Method(int a, int b)
{
// check to see whether or not a > b in order to decide whether to operate on x or on y
if (a > b)
{
// a is greater than b, and therefore we need to operate on x because...
}
else
{
// a is not greater than b, therefore we need to operate on y because...
}
}
I find that by structuring my comments to address the reason why specific sections of code are the way they are, the reader is able to "follow the story" that the code is telling as she reads through it.
If it is absolutely impossible to describe what the if section is doing without a broader explanation, then by all means add a paragraph or two. There is nothing wrong with long comments as long as they are well placed and address the specific purpose of the following lines of code. You shouldn't need to add for more information, see function header because that should already be implied.
You can add broader descriptions to the enclosing function, method, or scope, but comments should always address the piece of code they are referring to as succinctly as possible. After all, if the reader wanted to know what the whole function was doing, she'd look at the declaration. The reason she's looking at the definition of the function is because she wants to know what the components of the function are doing, and so the comments should address just that.

How do I make sense of Ruby documentation? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have seen code such as:
Net::HTTP::Post.new(url)
If I then use ri as follows:
$ ri Net::HTTP::Post
I get almost no documentation, and:
$ ri Net::HTTP::Post.new
results in
Nothing known about Net::HTTP::Post.new
When reading the documentation for Net::HTTP, I get the suspicion that the code should be using Net::HTTP#request_post instead. I still find the correct way to use this module confusing. Why does Net::HTTP::Post.net seem to work? Even with the Net::HTTP.request_post, I get:
undefined method `request_post' for Net::HTTP:Class.
To clarify my question, what I want is to know how to:
Find the best documentation for ruby.
Given the example provided, obtain the best way to achieve the aim (which is, to make an HTTP POST request, I'll add that I need to use provide authentication, cookie, and data in the body).
Make sense of what it means when the methods have been annotated with 'R' (does that mean 'read-only'? That doesn't make sense because I need to set the request body, which implies write...
As a contrast, this is equivalent documentation for Python, which I understand (being a python dev myself): http://docs.python.org/2/library/httplib.html
Here is the answer I will ultimately accept unless someone else has a better answer:
In order to understand Ruby's documentation, do the following, in sequential order:
Read the documentation for the module in the latest version of Ruby that is out there. Use ruby-doc.org, even if this version is for Ruby 2.0 and you're using Ruby 1.8, it is still likely to be significantly clearer and more complete.
Use google to find code examples.
Use irb to check if examples actually work.
Use ri to check if documentation for your version of ruby exists. If it exists, take a look for any insight as to what might differ in your version.
Use reflection/introspection in order to attempt to discover any exposed methods that may be useful.

uncalled variables [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am trying to get started with Lisp and I have some (messy) code that i want to be able to ask the user for a title and url.
Save them in a variable, and then print them out when called. I am running into troubles though. First of all i don't know how to compile my program to run it. Also, the one time when i did run it i got an error about the variable title being uncalled. Can anyone help me with either of these things? Sorry i can't give you more information about the error.
;;Define a function called make-cd that takes four parameters
(defun make-url( title url ))
(list :title title :url url)
;;In the make-url function create a plist that takes the passed values
;; Define global variable db and set its value to nil
(defvar *db* nil)
;; Define a function that takes one paramter and pushes it to the make-url func.
;;(defun add-url (url) (push url *db*))
;; Define a function that takes the *db* variable and makes the output pretty
(defun dump-db ()
(dolist (url *db*)
(format t "~{~a:~10t~a~%~}~%" url)))
(defun prompt-read (prompt)
(format *query-io* "~a: " prompt)
(force-output *query-io*)
(read-line *query-io*))
Perhaps this will help.
Lisp programs aren't always distributed in compiled form. Having your program as just the source code is even better then only having the FASL (that's how Lisp binaries are called) because it makes it easier to fix problems if they are found later.
Traditionally, more complex programs, are arranged by means of ASDF package asdf:defsystem macro. You can read more about it here: http://common-lisp.net/~mmommer/asdf-howto.shtml . You can find examples on the internet, of how this is usually done through using Quicklisp and looking into its ~/quicklisp/dists/quicklisp/software/<name of the program>/ directory to see how other programs are arranged.
Once system is defined by asdf:defsystem, you would use asdf:oos to "operate" on it, that is load it. However, Quicklisp has become a very popular and easy to use utility for working with Lisp systems (it uses ASDF package underneath too). So, considering you have it, you would then (ql:quickload "your-system").
In order to make your system available locally through Quicklisp, I'd recommend doing it this way: In your $HOME directory (on Linux it is usually aliased with tilde ~) in the file: ~/.config/common-lisp/source-registry.conf (you may need to create one, if it's not there already), add something like:
(:source-registry
(:tree (:home "quicklisp/quicklisp/"))
(:tree (:home "Projects/my-project/"))
:inherit-configuration)
The above would imply that ~/Projects/my-project/ directory contains a system definition file (*.asd), where you have described what files belong to the system and instructed on how to load them etc.
For other options for adding local projects, read the Quicklisp FAQ
For more information about source-registry.conf file format read ASDF manual.
This is a bit involved at the beginning, so I'd advise you to just install one project using Quicklisp and study how it is made. Alexandria could be a good start - besides being a generally useful package, it isn't very large and illustrates the matter very well, IMO.
The code you have provided contains errors and will not compile. The error is in your definition of make-url. The proper definition should be:
(defun make-url( title url )
(list :title title :url url))
Notice the difference in parenthesis placements.
In your code you had an additional parenthesis following the parameter list. This closed the defun, causing make-url to be evaluated as a function with no body. The next line was then evaluated as a call to the built-in function list. The arguments were evaluated, and an error was encountered when it attempted to find a value for title. There is no binding in the global environment, a binding for title only exists within the body of make-url.
Also, your definition of add-url is commented out. A semi-colon begins a comment in Lisp.
How to compile and run your program depends on what compiler you are using. If you are using SBCL the function is sb-ext:save-lisp-and-die. A simple program like this would usually be run in a Read-Eval-Print-Loop(REPL), and most compilers will enter one when started. If you have SBCL installed you can start a repl by entering the command 'SBCL' to the command prompt. If your code is in an external file you can then load that using Load.

How do I track down where a R package function fails? [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
General suggestions for debugging R?
I've encountered an error when calling a function from an R package. Briefly,
> library(treemap)
> ...
> tmPlot(X,index=c("r1","r2","r3","r4"),vSize="size")
Error in if (maxI == 1) { : missing value where TRUE/FALSE needed
This SO question gives more details.
I examined the source code of tmPlot by typing tmPlot at the R prompt, but the line that fails doesn't appear in the function. Which means, I assume, that it's failing in some function called by tmPlot.
What's the best way to track this down? For example, can I generate a stack trace somehow? Is there an interactive debugger that will allow me to step through and see where the error happens?
traceback will print the call stack.
traceback()
Also, have a look at the on-line help for the debug function. Although I have seen better interactive debuggers, there is some basic functionality provided by debug(), debugonce() and undebug()
?base::debug

Resources