How to compile ocaml graphics windows cygwin - graphics

I use cygwin 64 terminal on Windows and want to compile this ocaml graphics code.
It's saved as a .ml type:
let etat x y c=draw_circle x y 10 ;let a=(x-5) and b=(y-5) in moveto a b ;let s=string_of_int c in draw_string s;;
etat 100 100 1;;
etat 200 200 3;;
I'm confused between : load graphics.cma open Graphics Graphics.open_graph
And should I use ocamlc -o g graphics.cma g.ml
to compile?

i'm confued between : load graphics.cma open Graphics Graphics.open_graph
load is a directive of the interactive toplevel. It is not part of the OCaml language. You are using directives to command the interactive toplevel. And it is used to load code to the toplevel.
open Graphics is a language construct that will bring names of definitions in module Graph to the current scope. This allows you to write open_graph instead of Graphics.open_graph. It is better not to open too many modules (if any) as it may pollute your namespace, and make your code less understandable.
Graphics.open_graph is a function, that, when invoked, will open a graphics window in your machine.
and should i use ocamlc -o g graphics.cma g.ml to compile.
Yep, you can use ocamlc to compile your code. The OCaml compiler toolchain is rather difficult to use. However, there is a compilation manager, called ocamlbuild, that should work like magic, e.g.,
ocamlbuild -pkg graphics g.byte
You will get a g.byte executable that you can run.

Related

FreeBSD - how do I compile PolyML including XWindows module

On freebsd 12 the xwindows module in PolyML is not implemented so I am trying to compile its source outside the ports tree. It does compile, but I cannot open the XWindows module in poly.
What I did is:
copied libX11 to /usr/lib to be sure, and made symbolic links in
/usr/include for Xm and X11 to /usr/local/include.
inserted one space in xwindows.cpp because of a clang error
added these options to configure :
--x-includes=/usr/local/include/X11 --x-libraries=/usr/local/lib/ --with-x --with-system-libffi
set the environment : LDFLAGS=-L/usr/local/lib/gcc7 , where libstdc++
is located
tried with clang and gcc7
The code compiles without further errors. There is a file xwindows.o, 375160 bytes for cc and 291184 for gcc7.
The log contains
Created structure XWindows
Created structure Motif
I run poly from where it was compiled, and get
open XWindows
poly: : error: Structure (XWindows) has not been declared Found near open XWindows.
The non-graphics modules open normally
What am i doing wrong here ?? thanks for pointers
I
added CONFIGURE_ENV= LDFLAGS=-L/usr/local/lib to the port's Makefile, and
inserted a space before ZERO_X in xwindows.cpp
after which the ports code compiled, including the 2 modules in poly
My error has been to omit a make rmconfig before new compilation, and I had originally compiled poly without motif, so that kept coming back

Compiling simple programs on Haskell on Windows using the command line

This is a follow-up to this question, which is about whether it is possible to compile simple programs on Haskell in Windows, without recourse to Cygwin: Compiling Haskell programs in Windows: is it possible without downloading something such as Cygwin?
For background, I asked this question, since if there were some other way of compiling the program it would be very useful to know, since I am on a university computer and cannot download things like Cygwin without permission. (and even with permission it might not be possible, depending on what Cygwin requires)
Someone responded to my question, suggesting I open the command line and put ghc --make helloworld and hit Enter. However, when I put in ghc --make helloworld and hit Enter this comes up:
ghc: unrecognised flag: --
did you mean one of:
-D
-F
-H
Usage: For basic infomration, try the '--help' option
The person answering the question suggested I made another question, asking why I received the above message. How can I deal with this problem?
Yes, it is possible to use Windows to compile Haskell programs. In fact, I use Windows for all my Haskell programming! To compile a Haskell program, use ghc --make <program>; for instance, here it would be ghc --make helloworld.hs. Note that there is no space between -- and make; including this space gives the error you describe. After running this command, an executable helloworld.exe file is produced.

Call Matlab from Intel Fortran (Linux)

I am trying to integrate a Matlab program I wrote into some Fortran code. I tried to follow the example Mathworks provides. But I can't get it to compile because I can't find the header files it requests.
Does anyone know of an example of someone getting it to work on Linux using an Intel compiler. I think that might be part of the problem because Matlab only supports GNU Fortran on Linux.
And I realize this is a simple question, I just don't understand how to do anything in compiling more complicated than including multiple files with defined paths.
Disclaimer: I'm currently using OS X so I can only provide output from OS X but everything should transfer easily over to Linux due to the Unix base. I also don't have the Intel Fortran compiler on OS X (only the C/C++ compiler).
Note: You will need to substitute the paths I use for the correct paths on your system depending on your MATLAB installation directory.
This issue isn't specific to the Intel Compiler, I also receive errors with the GCC Fortran compiler.
$ gfortran fengdemo.F
fengdemo.F:1:0:
#include "fintrf.h"
^
Fatal Error: fintrf.h: No such file or directory
compilation terminated.
You can use the Unix locate command to find files.
$ locate fintrf.h
/Applications/Matlab R2014a.app/extern/include/fintrf.h
In the directory where fengdemo.F is we can then pass the correct directory in using the -I option
-I../../include/
However, this produces linking errors as we haven't specified where the libraries for fintrf.h can be found. We can do this with the -L option (you will need to replace maci64 with the correct option for Linux - I can't remember it off the top of my head but you should be able to see it in the bin directory)
-L../../../bin/maci64/
Now we need to tell it what libraries to use with -leng -lmx and so the completed command is
$ ifort fengdemo.F -I../../include/ -L../../../bin/maci64/ -leng -lmx
and it should compile correctly.
We aren't finished yet though as it won't execute. We need to set up our PATH and DYLD_LIBRARY_PATH environment variables correctly. Specifically we need to add the bin and bin/maci64 directories of our MATLAB installation to PATH
$ export PATH=$PATH:/Applications/Matlab\ R2014a.app/bin/maci64:/Applications/Matlab\ R2014a.app/bin
and the bin/maci64/ and sys/os/maci64/ to DYLD_LIBRARY_PATH
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Applications/Matlab\ R2014a.app/bin/maci64/:/Applications/Matlab\ R2014a.app/sys/os/maci64/
Note: On Linux DYLD_LIBRARY_PATH should be LD_LIBRARY_PATH. Thanks to Vladimir F for correcting me.
Now you can execute the program using
$ ./a.out

cygwin does not create a.out file when I compile for ocaml

I'm currently trying to start learning ocaml with cygwin, but when I try to compile an ml file, nothing happens - no error messages and no files created.
The command I used on cygwin was,
$ ocamlc hello.ml
According to my Prof., there should be a file called, a.out created on my working folder, but there was nothing.
But when I tried with this command,
$ ocamlc -o a.out hello.ml
a.out file was created properly, and I could run the compiled program using
$ ./a.out
as pointed out by the Prof.
For some experiment, I typed in the following,
$ ocamlc -o a hello.ml
This created a file named 'a' without any file extension.
So my question is,
1. Why doesn't it create the a.out file in the first place? - it should have been done according to the Prof.
2. What does the .out file do?
Any new file created when you type ocamlc hello.ml? Maybe camlprog.exe around? If it is, you are using MinGW OCaml over Cygwin. MinGW OCaml is a windows app therefore its default executable file name is not a.out, which is the default name for Unix and Cygwin.
I never recommend ppl to learn OCaml with Windows or Cygwin. Since there are 3 flavors: Cygwin OCaml, MinGW OCaml and MSVC OCaml and they behave slightly different like this. And newcomers are never sure which flavor they are actually using.

Compiling Haskell code in Cygwin, and some other bugs in Haskell Platform on Windows

I am trying to compile a simple hello world program in Haskell, with Haskell Platform 2011.2.0.1. If I load the code in WinGHCi, and use the GUI to compile, the .exe is created. Then I can run the .exe from Cygwin.
But if I try to compile the code in Cygwin (using ghc --make), linker fails. But again, if I compile from the Windows cmd prompt, then the compile+linker works fine.
Are there any other environment variables I need to import into Cygwin, to make the compile+linker work in it? I have put the following dirs in my Cygwin PATH: 2011.2.0.1/lib/extralibs/bin, 2011.2.0.1/bin (these are the only two valid Haskell related entries that I could see in the Windows environment variables).
I also noticed a couple of invalid items in the Windows environment variables (this looks like a bug in the Haskell installation):
(system var) C/ProgramFiles/Haskell/bin - this dir does not exist because I have installed Haskell in D disk.
(user var) userxxx/ApplicationData/cabal/bin - this dir does not exist.
I tried to file a bug report in HaskellPlatform, but I dont have permission to do it.
Without access to your development environment or a listing of the errors that you're getting, I can only assume that the issue is related to the way that you've set up your PATH.
GHC on Windows comes bundled with its own gcc compiler (for C code) and ld linker. If you've installed Cygwin, you've probably also installed the MinGW toolchain, which comes with its own version of gcc and ld. Then, you've probably made your PATH variable list /usr/bin before the path to the Haskell Platform binary directories, which makes ghc find the MinGW linker and C compiler before it finds the versions that were bundled with GHC.
You need to make sure that the HP directories are listed before the Cygwin directories. It should not be like this:
$ echo $PATH
/bin:/usr/bin:.../2011.2.0.1/bin
Instead, it should be like this:
$ echo $PATH
.../2011.2.0.1/bin:/bin:/usr/bin
This is only a guess at what the issue might be, and you should provide more details for a better diagnosis.

Resources