My simulator (which shall remain nameless) is crashing. I can't find out where. (It just crashes when I single step over a wait statement, so I guess it's jumping somewhere else, but who knows where.)
I have been trying to instrument my code to try to find out where. Ideally, I'd line to report filename and line number. This is easy in System-Verilog:
$display(`__FILE__,, `__LINE__);
or something like that. I had the idea of doing something similar by replacing the 486 occurrences of begin in my code with
constant CCCCCC : boolean := true; begin report CCCCCC'instance_name;
which broke the four architectures, but that was easily fixed. (Most of the stuff is in functions and procedures.) Unfortunately, using the
`instance_name
and
`path_name
attributes inside a subprogram also crashes my simulator. Doh! And
`simple_name
doesn't provide enough information.
I guess I could write a script to do this, but can anyone think of a smart way to do it in pure VHDL?
Related
an assignment operator is expected with the eval operation
a semi colon is not specified at the end of a free format statement
the name or indicator is not defined
the compiler cannot determine how the program can end try this please
hope its clear for issue
#1 & 2 are pretty evident, the error tells the line number in the source with the problem, just fix it. #3 is pretty evident as well, the error will tell you the name of the variable that is not defined.
#4 is the only one that is a bit tricky if you haven't seen it before. The compiler did not find a return from the main procedure, and also no place that *INLR is set on. Either of those things will fix that one.
Odds are that you just included some typos in your code. Please don't paste the entire source and error listing, just read the errors, and go find someone in your company that can tell you where in the source listing to find the errors. Or if you are using RDi, you could just click on the error, and it will take you directly to the problem.
Delphi Seattle (S10). Win32 project.
Yesterday I got wrong result in my old routine.
I found this line:
sPre := Copy(aSQLText, p - 1, 1);
aSQLText was 'CREATE', and p = 1.
The sPre got "C" result.
Hmmm... Then I wrote to watch window:
Copy('ABC', 0, 1)
and the result was "A"...
Ouch... What???
The copy handles the overflow in the end well.
But not at the beginning? Or what?
I hope that I haven't got any codes which points to before the string.
Do you also got this result in your Delphi?
Why?
As I know the strings internally stored as 4 byte length + string; and they
based in 1 (not 0 as any arrays). Is this a bug?
The call to copy in your code is resolved to the internal function _UStrCopy from System.pas. Right in the beginning of its implementation it checks the Index and Count parameters and corrects them when necessary. This includes forcing the Index to point to the first character if it is too low.
I agree that this should be documented, though.
The documentation for Copy doesn't specify what will happen in this instance, so I wouldn't call it a Bug per se.
I can see arguments for both solutions (empty string or as it does, assume 1 as starting position).
Point is, as it is not defined in the documentation what happens in this instance, it is unwise for a program to assume anything one way or another, as it may be implementation dependent and might even change over the course of different versions. If your code can risk having p=1 (or even p=0) and you want the empty string in that case, you should explicitly write code to that effect instead of relying on your (wrong, in this case) expectation on what the compiler might do:
if p<=1 then sPre:='' else sPre := Copy(aSQLText, p - 1, 1);
My program, PKGDAYMONR has the control option:
ctl-opt Main( CheckDailyPackages )
The CheckDailyPackages procedure has the following PI:
dcl-pi *n ExtPgm( 'PGMNAME' );
As you can see the ExtPgm parameter is not the name of the program. In fact, it’s what came over in the template source and I forgot to change it. Despite the wrong name in ExtPgm, the program runs without a problem.
If I remove that parameter and leave the keyword as just ExtPgm, I get the following message:
RNF3573: A parameter is required for the EXTPGM keyword when the
procedure name is longer than 10.
If I drop ExtPgm from the Procedure Interface altogether, it also complains:
RNF3834: EXTPGM must be specified on the prototype for the MAIN()
procedure.
So why is it that I have to specify a parameter if it doesn't matter what value I enter?
O/S level: IBM i 7.2
Probably worth pursuing as a defect with the service provider; presumably for most, that would be IBM rather than a third-party, as they would have to contact IBM anyhow, given the perceived issue is clearly with their compiler. Beyond that, as my "Answer", I offer some thoughts:
IMO, and in apparent agreement with the OP, naming the ExtPgm seems pointless in the given scenario. I think the compiler is confused while trying to enforce some requirements in validations of the implicitly generated Prototype for the linear-main for which only a Procedure Interface is supplied; i.e. enforcing requirements that are appropriate for an explicit Prototype, but requirements that could be overlooked [thus are no longer requirements] in the given scenario.? I am suggesting that while the RNF3573 would seem appropriate for diagnosing EXTPGM specifications of an explicit Prototype, IMO that same effect is inappropriate [i.e. the validation should not be performed] for an implicit prototype that was generated by the compiler.
FWiW: Was the fixed-format equivalent of that free-form code tested, to see if the same or a different error was the effect? The following source code currently includes the EXTPGM specification with 'PGMNAME' as the argument [i.e. supplying any bogus value of 10-byte naming to supplicate the compiler, just as is being done in the scenario of the OP, solely to effect a successful compile], but could be compiled with the other variations with changes to the source, mimicking what was done with free-form variations, to test if the same\consistent validations and errors are the effect:
- just EXTPGM keyword coded (w/out argument); is RNF3573 the effect?
- the EXTPGM keyword could be omitted; is RNF3834 the effect?
- the D-spec removed entirely (if there are no parameters defined); ¿that was not one of the variations noted in the OP as being tried, so... the effect?
H MAIN(CheckDailyPackages)
*--------------------------------------------------
* Program name: CheckDailyPackages (PGMNAME)
*--------------------------------------------------
P CheckDailyPackages...
P B
D PI EXTPGM('PGMNAME')
/free
// Work is done here
/end-free
P CheckDailyPackages...
P E
I got a response from IBM and essentially Biswa was on to something, it simply wasn't clear (in my opinion) about the answer.
Essentially the EXTPGM is required on long Main procedure names in order to support recursive program calls.
This is the response I received from IBM explaining the reason for the scenario:
The incorrect EXTPGM would only matter if there was a call to the main
procedure (the program) within the module.
When the compiler processes the procedure interface, it doesn't know
whether there might be a call that appears later in the module.
EXTPGM keyword is used to define the external name of the program which you want to prototype. If you mention the EXTPGM then the program will be called dynamically.
Let us take an example in order to explain your query.
PGMA
D cmdExc PR ExtPgm('QSYS/QCMDEXC')
D 200A const
D 15P05 const
c callp cmdExc('CLRPFM LIB1/PF1':200)
C Eval *INLR = *ON
In the above example CmdExc used for the dynamic call to QSYS/QCMDEXC.
When we use the same program name as the EXTPGM parameter it acts as an entry point to the program when called from other programs or procedure.
But in any case when we mention any name as the sample parameter the EXTPGM will not give any error in compilation, but it gives the error during run time as it tries to resolve the name during run time.
How can I reference an input twice in a one line code?
Ex:
my_word=input()
print("hey" if my_word==my_word else "bye")
You are only referencing it once right now, so this is easy:
print("hey" if input().isdigit() else "bye")
Though you could argue that this line of code does too much, and may be difficult to maintain. Breaking it into two lines makes maintenance easier, and for example it also allows you to set a breakpoint on the print line and inspect the value in my_word if you wanted to.
For academic reasons, here is one possible solution to evaluating an expression once but using it multiple times in one statement: list comprehension. (This is a terrible, terrible idea, and you shouldn't do this. I mean it.)
[print(i if i.isdigit() else "bye") for i in (input(),)]
I have a really annoying problem.
This function:
fun writeAFile() =
let
val outstream = TextIO.openOut "look_at_me_im_a_file.txt"
in
TextIO.outputSubstr(outstream,Substring.full("I'm so sad right now :("))
end;
Just creates the file look_at_me_im_a_file.txt but it's empty.
I get no errors and it does not work with either SML/NJ or PolyML.
I have no problems reading from files.
First of all, Substring.full isn't needed - it doesn't really do anything other than give you something of the substring type. Instead, you can do:
TextIO.output (outstream, "I'm so sad right now :(");
Now, the reason it doesn't work:
When you tell sml to write something to a file (using TextIO.output or TextIO.outputSubstr) it doesn't actually write it in the file right away. It writes to a buffer. Well, sometimes it writes to the file right away, but not often enough that you can depend on it.
Now, this seems terribly impractical, but it's more efficient - if you tell it to write several small pieces of data after each other, it can just lump it all together in one write operation.
The way to get around it is to tell sml "Hey, I really want that write to happen right now." There's a function just for that, which is called TextIO.flushOut. Alternatively, closing the stream will also cause everything to be written.
Actually, you should always remember to close your streams. Leaving open file handles lying around is messy - how will the filesystem know that you're done with it, and that it can let other programs write to the file?
Being an rookie i didn't check our lecture notes :/
a functioning version of the code is
fun writeAFile() =
let
val outstream = TextIO.openOut "look_at_me_im_a_file.txt"
in
(
TextIO.output(outstream,"I'm so glad right now :)");
TextIO.closeOut(outstream)
)
end;
Although its noteworthy that the online documentation at http://www.standardml.org/Basis/text-io.html only gives a vague reference to the output function.
And looking at the documentation for the IMPERATIVE_IO says val output : outstream * vector -> unit which is confusing since it is non apparent that string is actually of type CharVector.vector and is thus a valid argument for the output function.
I hope this will be of help to some other rookie out there.