What are these comment-like lines in ocamllex generated .ml? - ocamllex

When I generate an .ml file with ocamllex it has a bunch of lines like:
# 21 "lib/myproj/example.ml"
These look like comments, except AFAIK comments in OCaml are like (* this is a comment *)
VS Code doesn't seem to treat them as comments either.
What syntax is this? What do they do?

These are "line number directives":
https://ocaml.org/manual/lex.html#sss:lex-linedir
Preprocessors that generate OCaml source code can insert line number directives in their output so that error messages produced by the compiler contain line numbers and file names referring to the source file before preprocessing, instead of after preprocessing.

Related

How to strip binary characters from a file?

I've got a file that contains lines that look like this in vim:
^[[0;32msalt-2016.3.2-1.el6.noarch^[[0;0m^M
which look like this in more:
salt-2016.3.2-1.el6.noarch
I would like to produce a copy of this file that only contains the displayed characters as more shows them. I tried piping it through dos2unix but it refuses to do anything, complaining that "dos2unix: Binary symbol 0x1B found at line 2".
Probably I could achieve what I want with some sed statements, but I'm wondering whether there is a linux/unix utility that will take output from more or cat and produce a file that contains only the whitespace and text as displayed?
There's something called ansifilter which does exactly this. I tested it out on my file and it works.

Is it possible to change the way Maxima generates LaTeX code?

I would like to be able to change the way Maxima generates the LaTeX code (in general). For example, I have the following code in Maxima:
I then exported the code to LaTeX, and I immediately get an error saying:
! Package inputenc Error: Unicode char \u8:− not set up for use with LaTeX.
See the inputenc package documentation for explanation.
Type H <return> for immediate help.
You can check out the LaTeX code generated through this gist on GitHub.
I would like at least not only to not get any errors, but also to change a little bit the style of the LaTeX code generation to adapt it to certain circumstances. For example, I would like to be able to insert a break line (or more) after the outputs...
Is it possible to do? Are there any alternatives?
You can put the following line in the preamble of the LaTeX output:
\DeclareUnicodeCharacter{2212}{-}
which tells LaTeX what to do with the Unicode hyphen (character 2212 according to this table).
WxMaxima should generate this declaration itself -- it is a bug that it does not.
Most likely something happened when you exported the code. To fix the existing file you can follow the accepted answer to this question.
https://tex.stackexchange.com/questions/83440/inputenc-error-unicode-char-u8-not-set-up-for-use-with-latex
But try exporting again and see if the error was accidental.
Update:
Add
\DeclareUnicodeCharacter{00A0}{ }
to your preamble.
Well, the gistfile1.txt at line 54 contains − characters instead of -. I wonder how those characters were generated. What commands did you enter in wxMaxima to generate gistfile1.txt?
Anyway, I find that if I replace those characters with ordinary hyphens, it avoids the error you reported. So perhaps the problem is to avoid generating those characters in the first place.
EDIT: This answer is off the mark. See my other answer for a real solution.

parse program with tokens at fixed positions in a line

I am new to Antlr and need to write a parser for a legacy assembly code that may have line numbers in fixed columns. Also, certain columns have significance - whether its a comment, continuation, etc. How can I detect these?
To give some examples:
000001 proc proc1
000002* comment
* comment without line numbers
continuation marker set ==> X
Arbitrary text as continuation
Thanks
xAn
I've faced something like this when programming an Antlr grammar to parse Cobol sources. Cobol have some characteristics like yours (fixed columns, column is significant, etc).
The only solution I've found for this problem: "pre-process" the input and turned it into some that Antlr could parse without problems!
Ex: In Cobol, an asterisk in column 7 indicates that the line is a comment line; I changed it (the asterisk itself) to ">>" and specified in my grammar that ">>" means that this line is a comment line.

Vim syntax highlighting for multiline fortran openmp directives

I'm using modern fortran for doing parallel programming. I'm using vim and it's been really annoying me that the fortran.vim syntax files don't seem to handle compiler directives like !$omp or !dir$. These just get rendered as comments in vim so they don't stand out. In c/c++ these compiler directives are done using #pragma's so everything stands out like it were preprocessor code rather than comment code. So I want similar treatment in my fortran syntax.
Here's an example of a multiline directive that I want to colour:
!$omp parallel do reduction(+: sum0) reduction(+: sum1) &
private( nn, S1, S2, Y1, Y2, rvec0, rvec1, iThreadNum)
What I have so far is a new fortran.vim file located in $HOME/.vim/after/syntax.
I've got it to recognise the '!$omp' at the start of a line and to colour that line and also to colour the multilines properly. My syntax file contains this:
syn region fortranDirective start=/!$omp.*/ end=/[^\&]$/
hi def link fortranDirective PreProc
My problem is that it now can't handle the simple case of just a single line. I.e:
!$omp parallel do blah blah
call foobar <-- this is coloured the same as the line above
I need some kind of regex rule in my syntax file to be able to correctly match both single line and continued line. Can anybody help please?
As far as I can tell, the problem is that your start regex is too greedy.
This should work:
syn region fortranDirective start=/!$omp.\{-}/ end=/[^\&]$/

Using variables to open output files in Fortran

I have a piece of Fortran code:
C --------------------------------------------
CALL READIN_HYD
CALL READIN_CONFIG
CALL READIN_FORCE
CALL READIN_STEPPER
C --------------------------------------------
OPEN(11,FILE='EVO_0wall.dat')
and I'm attempting to replace the hardcoded file name (EVO_0wall.dat) with something I can input from my input parameters (which are all read by the subroutines readin_hyd, etc).
I'm trying to do something like this:
CHARACTER*30 OUTFILE
WRITE(*,*) 'OUTPUT FILE'
READ(*,*) OUTFILE
WRITE(*,*) 'OUTPUT FILE: ',OUTFILE
which I have added into the READIN_CONFIG subroutine. Coming back, I replace with
OPEN(11,FILE=OUTFILE,STATUS='NEW')
in the main routine in the hope that it will say the same thing as before if the input file I pipe in contains 'EVO_0wall.dat' (with the apostrophes) in the appropriate place.
If I run the code, all other input variables are read correctly, and the data is output correctly - however, it creates and places the output in an odd file with no extension and broken characters for a name (for example, degree, "{a}, and 0 ). Renaming the file with a .dat extension lets me open it, and the data within is correct. (edit: actually, the variable OUTFILE changes to the odd characters when its in the main function, if I try to simply print its value, so I guess its not just wrong syntax in the OPEN statement)
Is there some way that Fortran handles strings that I'm missing between these? I'm afraid I'm a novice to Fortran (this is someone else's code that I'm adapting), and am not quite sure what I'm missing. Any help would be much appreciated!
Thanks!
As an alternative to the suggestion of #M.S.B., you may use trim and adjustl, like this:
implicit none
character*99 :: outf
outf='outf.outf'
open(1,file=trim(adjustl(outf)))
write(1,*)'foobar',42
close(1)
end
Here adjustl ensures that there's no leading whitespace, and trim trims the trailing whitespace. This should work as long as the outf variable only contains legal characters [I'd suggest using basic ASCII only].
On a side note, if I add status='new' to the open statement, it fails at runtime (with gfortran 4.4.3 at least) if the file already exists. If you really want to make sure that the existing file is not overwritten, you need to inquire first.
That seems OK. The following read statement should allow you to omit the apostrophes:
read (*, '(A)' ) outfile
What does the "echo" write statement of the value of outfile output?
My FORTRAN is rusty, but I think the {a} may represent hex A, or decimal 10, which is a newline. That's what you would get when you read in the OUTFILE name.
You may need to TRIM the OUTFILE of all whitespace

Resources