Fortran formatted write function triggers "has exited with code 408 (0x198)" on IF Composer 2013 - debugging
When following Fortran code is executed on the Intel Fortran Composer 2013 the compiler triggers a breakpoint at write function and retuns code 408:
character*20 date_char
character*10 LADATE
...
if (date_char(3:3) .EQ. "") date_char(3:3)="0"
if (date_char(7:7) .EQ. "") date_char(7:7)="0"
write(LADATE,"(2A2,A4)")
S date_char(3:4),date_char(7:8),date_char(9:12)
It is a fixed line-length format and the S represents the line continuation.
The date_char has a value of ' 29 012013 ' and the LADATE ' '
As soon as the write statement is reached the debugger triggers a breakpoint and the Call Stack shows following system functions being called:
for_issue_diagnostics()
_for_emit_diagnostics()
Your time is appreciated
The problem was that the LADATE variable was actually a call-by-reference argument (FORTRAN77 default passing convention):
SUBROUTINE MDATE(LADATE)
character*20 date_char
character*10 LADATE
...
write(LADATE,"(2A2,A4)")
S date_char(3:4),date_char(7:8),date_char(9:12)
RETURN
END
and it was passed as an argument several subroutines above as a just an 8-character string. Simply written, the call would be equivalent to:
...
CHARACTER VAR*20
...
CALL MDATE(VAR(10:17))
...
The program started, but after an attempt to access an inaccessible array addresses by the write function the breakpoint was triggered.
Related
Compile Issue under ProCOBOL due to SQLBEX
Have been trying to compile an existing Pro*COBOL program after making few changes, have verified the syntax and Non-Printable character which may cause issue for compilation. But at the end, compilation for Pro*COBOL failing due one of .(dot) appearing under CALL to SQLBEX for the embedded SQL (Line Number 18106 under the listing). See below code for more details, code snippet has been taken from Pro*COBOL code and the listing generated during compilation. For other instances where SQLBEX is being called, the .(dot) doesn't appear. Would really appreciate any help. Code under the listing: 18085 IF SQLCODE IN SQLCA = WS-DEADLOCK-WAIT-FOR-RESRC 26825000 18086 SET DEADLOCK TO TRUE 26826000 18087 18088* EXEC SQL 26827000 18089* COMMIT 26828000 18090* END-EXEC 18091 MOVE 1 TO SQL-ITERS 18092 MOVE 2914 TO SQL-OFFSET * Micro Focus COBOL for UNIX V4.0 revision 004 18-Jan-17 07:31 Page 313 * cmcomc23.cob 18093 MOVE 0 TO SQL-OCCURS 18094 CALL "SQLADR" USING 18095 SQLCUD 18096 SQL-CUD 18097 CALL "SQLADR" USING 18098 SQLCA 18099 SQL-SQLEST 18100 MOVE 256 TO SQL-SQLETY 18101 18102 CALL "SQLBEX" USING 18103 SQLCTX 18104 SQLEXD 18105 SQLFPN 18106 . 18107 26829000 18108 DISPLAY 'DEAD LOCK OCCURED ' 26829100 18109 GO TO 9000-EXIT 26829200 18110 ELSE 26829300 * 562-S****************************************************************( 308)** ** An "ELSE" phrase did not have a matching IF and was discarded. 18111 SET NO-DEADLOCK TO TRUE 26829400 18112 END-IF. 26829500 * 564-S********** ( 313)** ** A scope-delimiter did not have a matching verb and was discarded. Original Code under Program: 268210******************************************************************26821000 268221 9000-SQL-ERROR SECTION. 26822100 268230******************************************************************26823000 268250 EXEC SQL 26824000 268250 WHENEVER SQLERROR CONTINUE 26824000 268250 END-EXEC. 26824000 268240 26824000 268250 IF SQLCODE IN SQLCA = WS-DEADLOCK-WAIT-FOR-RESRC 26825000 268260 SET DEADLOCK TO TRUE 26826000 268270 EXEC SQL 26827000 268280 COMMIT 26828000 268290 END-EXEC 26829000 268291 DISPLAY 'DEAD LOCK OCCURED ' 26829100 268292 GO TO 9000-EXIT 26829200 268293 ELSE 26829300 268294 SET NO-DEADLOCK TO TRUE 26829400 268295 END-IF. 26829500 268296 26829600 268297 MOVE 'E' TO WS-ERR-SEVERITY-CD. 26829700
Using handles to nested function for GUI callbacks in Octave
I am trying to develop a GUI in Octave (4.0.1, using the GUI version) with the code as follows:
Main GUI function
Function to create figure & various uicontrol
Callback function for uicontrol #1
Callback function for uicontrol #2
Callback function for uicontrol #3
etc...
Each function is delimited by function & end. The first callback I tried to write looks like this: the button is defined in the "graphical creation" function as:
gui.select_btn = uicontrol('Style','pushbutton','String','Select log file ...',...
'Units','normalized','Position',[0.01 0.52 0.25 0.47],...
'BackgroundColor',get(gui.Window,'Color'),'Parent',gui.file_panel,...
'Enable','on','Callback',{#browse_log_file,gui});
and the callback for it is defined in the callback function later as:
function browse_log_file(src,data,gui)
% Called when user presses the "Select log file ..." button
[fname, pname] = uigetfile({'*.log'},'Select log file');
set(gui.log_file_edit,'String',[pname,fname]);
end
whi gui being a struct defined in the main GUI function by calling the "graphical creation" function & accessible by all nested functions.
However, when I try to run the code, I get the following error message:
error: handles to nested functions are not yet supported
error: called from
GUI_analyser>create_interface at line 71 column 20
GUI_analyser at line 8 column 7
error: evaluating argument list element number 1
error: called from
GUI_analyser>create_interface at line 71 column 20
GUI_analyser at line 8 column 7
error: evaluating argument list element number 16
error: called from
GUI_analyser>create_interface at line 71 column 20
GUI_analyser at line 8 column 7
pointing to the line with {#browse_log_file,gui}.
Any suggestions on how to work round this problem?
Meaning of yywrap() in flex
What does this instructions mean in flex (lex) :
#define yywrap() 1
and this [ \t]+$
i find it in the code below:
(%%
[ \t]+ putchar('_');
[ \t]+%
%%
input "hello world"
output "hello_world"
)
According to The Lex & Yacc Page : When the scanner receives an end-of-file indication from YY_INPUT, it then checks the yywrap() function. If yywrap() returns false (zero), then it is assumed that the function has gone ahead and set up yyin to point to another input file, and scanning continues. If it returns true (non-zero), then the scanner terminates, returning 0 to its caller. Note that in either case, the start condition remains unchanged; it does not revert to INITIAL. The #define is used to simplify building the program (so that no -ll linkage option is needed). Further reading: What are lex and yacc? Routines to reprocess input 6. How do Lex and YACC work internally (Lex and YACC primer/HOWTO)
Executing SQL Script using OSQL do not return resultcode
I am executing some sql queries using OSQL through inno setup. I am using following code to run OSQL. This is just for example purpose
SQLQuery:= '"EXEC sp_addserver ''PCNAME'';"';
Param:= '-S(local) -Usa -Psa -Q ' + SQLQuery;
Exec('osql.exe', Param, '', SW_HIDE, ewWaitUntilTerminated, ResultCode);
This works fine. The problem is ResultCode value is always 0. Even if the query does not get executed. For example if I try same query like below where I pass in an invalid stored procedure name the ResultCode is still 0.
SQLQuery:= '"EXEC sp_invalidname ''PCNAME'';"';
Param:= '-S(local) -Usa -Psa -Q ' + SQLQuery;
Exec('osql.exe', Param, '', SW_HIDE, ewWaitUntilTerminated, ResultCode);
Why don't this return me a proper code. If I run the second query in management studio I get an error like this
Msg 2812, Level 16, State 62, Line 1
Could not find stored procedure 'sp_invalidname'
Here return code is 2812. Why dont I get this when I run it through inno. What do I need to do to get this error code in inno?
Thanks to TLama, I updated my code as below and its working now. I had to add -b command line parameter and now it returns 1 if the command fails. -b Specifies that osql exits and returns a DOS ERRORLEVEL value when an error occurs. The value returned to the DOS ERRORLEVEL variable is 1 when the SQL Server error message has a severity of 11 or greater; otherwise, the value returned is 0. Microsoft MS-DOS batch files can test the value of DOS ERRORLEVEL and handle the error appropriately. I updated my code as below. Param:= '-S(local) -Usa -Psa -b -Q ' + SQLQuery; Its explained in the documentation.
Forcing a package's function to use user-provided function
I'm running into a problem with the MNP package which I've traced to an unfortunate call to deparse (whose maximum width is limited to 500 characters).
Background (easily skippable if you're bored)
Because mnp uses a somewhat idiosyncratic syntax to allow for varying choice sets (you include cbind(choiceA,choiceB,...) in the formula definition), the left hand side of my formula call is 1700 characters or so when model.matrix.default calls deparse on it. Since deparse supports a maximum width.cutoff of 500 characters, the sapply(attr(t, "variables"), deparse, width.cutoff = 500)[-1L] line in model.matrix.default has as its first element:
[1] "cbind(plan1, plan2, plan3, plan4, plan5, plan6, plan7, plan8, plan9, plan10, plan11, plan12, plan13, plan14, plan15, plan16, plan17, plan18, plan19, plan20, plan21, plan22, plan23, plan24, plan25, plan26, plan27, plan28, plan29, plan30, plan31, plan32, plan33, plan34, plan35, plan36, plan37, plan38, plan39, plan40, plan41, plan42, plan43, plan44, plan45, plan46, plan47, plan48, plan49, plan50, plan51, plan52, plan53, plan54, plan55, plan56, plan57, plan58, plan59, plan60, plan61, plan62, plan63, "
[2] " plan64, plan65, plan66, plan67, plan68, plan69, plan70, plan71, plan72, plan73, plan74, plan75, plan76, plan77, plan78, plan79, plan80, plan81, plan82, plan83, plan84, plan85, plan86, plan87, plan88, plan89, plan90, plan91, plan92, plan93, plan94, plan95, plan96, plan97, plan98, plan99, plan100, plan101, plan102, plan103, plan104, plan105, plan106, plan107, plan108, plan109, plan110, plan111, plan112, plan113, plan114, plan115, plan116, plan117, plan118, plan119, plan120, plan121, plan122, plan123, "
[3] " plan124, plan125, plan126, plan127, plan128, plan129, plan130, plan131, plan132, plan133, plan134, plan135, plan136, plan137, plan138, plan139, plan140, plan141, plan142, plan143, plan144, plan145, plan146, plan147, plan148, plan149, plan150, plan151, plan152, plan153, plan154, plan155, plan156, plan157, plan158, plan159, plan160, plan161, plan162, plan163, plan164, plan165, plan166, plan167, plan168, plan169, plan170, plan171, plan172, plan173, plan174, plan175, plan176, plan177, plan178, plan179, "
[4] " plan180, plan181, plan182, plan183, plan184, plan185, plan186, plan187, plan188, plan189, plan190, plan191, plan192, plan193, plan194, plan195, plan196, plan197, plan198, plan199, plan200, plan201, plan202, plan203, plan204, plan205, plan206, plan207, plan208, plan209, plan210, plan211, plan212, plan213, plan214, plan215, plan216, plan217, plan218, plan219, plan220, plan221, plan222, plan223, plan224, plan225, plan226, plan227, plan228, plan229, plan230, plan231, plan232, plan233, plan234, plan235, "
[5] " plan236, plan237, plan238, plan239, plan240, plan241, plan242, plan243, plan244, plan245, plan246, plan247, plan248, plan249, plan250, plan251, plan252, plan253, plan254, plan255, plan256, plan257, plan258, plan259, plan260, plan261, plan262, plan263, plan264, plan265, plan266, plan267, plan268, plan269, plan270, plan271, plan272, plan273, plan274, plan275, plan276, plan277, plan278, plan279, plan280, plan281, plan282, plan283, plan284, plan285, plan286, plan287, plan288, plan289, plan290, plan291, "
[6] " plan292, plan293, plan294, plan295, plan296, plan297, plan298, plan299, plan300, plan301, plan302, plan303, plan304, plan305, plan306, plan307, plan308, plan309, plan310, plan311, plan312, plan313)"
When model.matrix.default tests this against the variables in the data.frame, it returns an error.
The problem
To get around this, I've written a new deparse function:
deparse <- function (expr, width.cutoff = 60L, backtick = mode(expr) %in%
c("call", "expression", "(", "function"), control = c("keepInteger",
"showAttributes", "keepNA"), nlines = -1L) {
ret <- .Internal(deparse(expr, width.cutoff, backtick, .deparseOpts(control), nlines))
paste0(ret,collapse="")
}
However, when I run mnp again and step through, it returns the same error for the same reason (base::deparse is being run, not my deparse).
This is somewhat surprising to me, as what I expect is more typified by this example, where the user-defined function temporarily over-writes the base function:
> print <- function() {
+ cat("user-defined print ran\n")
+ }
> print()
user-defined print ran
I realize the right way to solve this problem is to rewrite model.matrix.default, but as a tool for debugging I'm curious how to force it to use my deparse and why the anticipated (by me) behavior is not happening here.
The functions fixInNamespace and assignInNamespace are provided to allow editing of existing functions. You could try ... but I will not since mucking with deparse looks too dangerous:
assignInNamespace("deparse",
function (expr, width.cutoff = 60L, backtick = mode(expr) %in%
c("call", "expression", "(", "function"), control = c("keepInteger",
"showAttributes", "keepNA"), nlines = -1L) {
ret <- .Internal(deparse(expr, width.cutoff, backtick, .deparseOpts(control), nlines))
paste0(ret,collapse="")
} , "base")
There is an indication on the help page that the use of such functions has restrictions and I would not be surprised that such core function might have additional layers of protection. Since it works via side-effect, you should not need to assign the result.
This is how packages with namespaces search for functions, as described in Section 1.6, Package Namespaces of Writing R Extensions Namespaces are sealed once they are loaded. Sealing means that imports and exports cannot be changed and that internal variable bindings cannot be changed. Sealing allows a simpler implementation strategy for the namespace mechanism. Sealing also allows code analysis and compilation tools to accurately identify the definition corresponding to a global variable reference in a function body. The namespace controls the search strategy for variables used by functions in the package. If not found locally, R searches the package namespace first, then the imports, then the base namespace and then the normal search path.