I'm dealing with a list of errors while trying to open a *.w file in the appBuilder. I managed to find a previous version of that file, which opens fine, and I see following differences between both files:
Per procedure segment information
---------------------------------
File Segment #Segments Total-Size
---- ------- --------- ----------
Good_version.w
...
Int-Proc: 19 1 26232
...
Bad_version.w
...
Int-Proc: 19 1 32712
As you can see, "Int-Proc" number 19 seems to be the one, exceeding the segment size (above 32K) and hence is the one causing the problem.
Now the obvious question: how can I know the meaning of "Int-Proc" number 19? I have some procedures inside my code but the number does not correspond with the total number of "Int-Proc" (very naïvely: I have 38 "Int-Proc" entries in client.mon but only 21 End procedure. entries in my source code).
Edit
The action to take in case of exceeding 32K limit is splitting the procedure, which grows too large, into smaller pieces. However, between Bad_version.w and Good_version.w, it seems that in total 5 procedures have been expanded, and I'd like to know which one I need to split.
Disclaimer: I have never used the AppBuilder.
client.mon is for r-code statistics, so I think that instead of .w there should be a .r there. The AppBuilder has a 32000 byte (= maximum size of a character variable) limit for internal procedures. 32000 new lines will also break the AppBuilder view, but compile to 0 bytes (or so).
I /thought/ the AppBuilder would complain about an internal procedure being too large upon selecting the procedure that is too large. If not you will need to get the /text/ content size of block of your .w between procedure and end procedure and you know which are your problem.
Something like:
def var lcw as longchar no-undo.
def var iprocs as integer no-undo.
def var lcproc as longchar no-undo.
def var cc as character no-undo.
def var ic as integer no-undo.
cc = chr(1).
copy-lob from file "my.w" to lcw.
assign
lcw = replace( lcw, 'procedure ', cc )
lcw = replace( lcw, 'end procedure', cc )
iprocs = num-entries( lcw, cc )
.
do ic = 1 to iprocs:
lcproc = entry( ic, lcw, cc ).
if length( lcproc ) > 31000 then
message substring( lcproc, 1, 100 ) view-as alert-box.
end.
Intrigued by how the AppBuilder really complains:
started the AppBuilder
created a Smart Window
opened the first procedure section (it was a trigger)
added // some comment
saved the .w
opened the .w with Notepad++ and blew up // some comment to be larger than 32000 bytes
Opened .w with AppBuilder, endless errors.
Quit.
-> Added -debugalert to my shortcut.
On first error started debugger.
Debugger tries to start, but does not (remember the hidden procedures post)
-> Added -zn to my shortcut.
On first error started debugger.
It starts. While I cannot see any source code since I have not extracted the source code pls, I can see and view all variable and buffers.
Since I had blown up a trigger, the error reported _trg. Viewing _trg:
And:
Related
I wrote a query which contains multiple for each statements. The query is taking more than 20 minutes to fetch the data. Is there a way to check what time each loop started and ended. (How much time does each loop takes to execute and also the total time taken to complete the program).
You could do as you ask (just follow JensD's suggestsions) but you would likely be better served to use the profiler. You can easily add profiling for a code snippet:
assign
profiler:enabled = yes
profiler:description = "description of this test"
profiler:profiling = yes
profiler:file-name = "filename.prf"
.
/* this is deliberately awful code that should take a long time to run */
for each orderline no-lock:
for each order no-lock:
for each customer no-lock:
if customer.custNum = order.custNum and orderLine.orderNum = orderLine.orderNum then
. /* do something */
end.
end.
end.
/* end of test snippet */
assign
profiler:enabled = no
profiler:profiling = no
.
profiler:write-data().
You can then load that prf file into an analysis tool. The specifics depend on your development environment - if you are using an up to date version of PSDOE there is a Profiler analyzer included, if not you might want to download ProTop
https://demo.wss.com/download.php and use the simple report included in lib/zprof_topx.p.
Ultimately what you are going to discover is that one or more of your FOR EACH statements is almost certainly using a WHERE clause that is a poor match for your available indexes.
To fix that you will need to determine which indexes are actually being selected and review the index selection rules. Some excellent material on that topic can be found here: http://pugchallenge.org/downloads2019/303_FindingData.pdf
If you don't want to go to the trouble of reading that then you should at least take a look at the actual index selection as shown by:
compile program.p xref program.xref
Do the selected indexes match your expectation? Did WHOLE-INDEX (aka "table scan") show up?
Using ETIME you can initiate a counter of milliseconds. It could be called once or several times to tell how much time has passed since reset.
ETIME(TRUE).
/*
Loop is here but instead I'll insert a small pause.
*/
PAUSE 0.5.
MESSAGE "This took" ETIME "milliseconds" VIEW-AS ALERT-BOX.
Milliseconds might not be useful when dealing with several minutes. Then you can use TIME to keep track of seconds but you need to handle start time yourself then.
DEFINE VARIABLE iStart AS INTEGER NO-UNDO.
iStart = TIME.
/*
Loop is here but instead I'll insert a slightly longer pause.
*/
PAUSE 2.
MESSAGE "This took" TIME - iStart "seconds" VIEW-AS ALERT-BOX.
If you want to keep track of several times then it might be better to output to a log file instead of using a MESSAGE-box that will stop execution until it's clicked.
DEFINE VARIABLE i AS INTEGER NO-UNDO.
DEFINE STREAM str.
OUTPUT STREAM str TO c:\temp\timing.txt.
ETIME(TRUE).
/*
Fake loop
*/
DO i = 1 TO 20:
PAUSE 0.1.
PUT STREAM str UNFORMATTED "Timing no " i " " ETIME "ms" SKIP.
END.
OUTPUT CLOSE.
The source code of UNIX V6 is available and there is a book on it by J.Lions. From the book I know that " . " symbol means current location. I do not understand the next:
"*An assignment statement of the form
identifier = expression
associates a value and type with the identifier. In the example
. = 60^.
the operator ’^’ delivers the value of the first
operand and the type of the second operand
(in this case, “location”);*"
The statement can be found in file low.s (0526). What does it mean? Does it actually change PC register value and behaves as a jump instruction? I know it is old code, but I want to understand it. Thank you.
In the 6th edition assembler, . is the location counter, an offset from the beginning of a segment (text, data, or bss). When the assembler starts processing a file, . in each segment is 0, and is incremented either by assignment to . or by the presence of data or instruction statements.
The statement . = 60^. means to take the value 60 (in octal), cast it to the type of the location counter (in this case, type data), and assign it to the location counter. You'll see several statements like this in low.s in the area where interrupt vectors are set up.
When the link editor combines multiple object files together, their text, data, and bss sections are concatenated (except for COMMON data, which gets allocated just once) and any references (such as labels) to instructions or data will be relocated appropriately.
Building the Unix kernel requires an extra step to make sure data meant to be in low memory get loaded at the proper address. After low.s and the rest of the Unix kernel object files have been linked together, sysfix is run to make the data section have a load address of 0, and to relocate all data references appropriately. So that . = 60^. statement has effectively set the location counter to physical address 60.
I have a fill-in with the following code, made using the AppBuilder
DEFINE VARIABLE fichNoBuktiTransfer AS CHARACTER FORMAT "N(18)":U
LABEL "No.Bukti Transfer"
VIEW-AS FILL-IN NATIVE
SIZE 37.2 BY 1 NO-UNDO.
Since the format is N, it blocks the user from entering non-alphanumeric entries. However, it does not prevent the user from copypasting such entries into the fill-in. I have an error checking like thusly to prevent such entries using the on leave trigger:
IF LENGTH(SELF:Screen-value) > 18 THEN DO:
SELF:SCREEN-VALUE = ''.
RETURN NO-APPLY.
END.
vch-list = "!,*, ,#,#,$,%,^,&,*,(,),-,+,_,=".
REPEAT vinl-entry = 1 TO NUM-ENTRIES(vch-list):
IF INDEX(SELF:SCREEN-VALUE,ENTRY(vinl-entry,vch-list) ) > 0 THEN DO:
SELF:SCREEN-VALUE = ''.
RETURN NO-APPLY.
END.
END.
However, after the error handling kicked in, when the user inputs any string and triggers on leave, error 632 occurs:
error 632 occurs
Is there any way to disable the error message? Or should I approach the error handling in a different way?
EDIT: Forgot to mention, I am running on Openedge version 10.2B
You didn't mention the version, but I'll assume you have a version in which the CLIPBOARD system handle already exists.
I've simulated your program and I believe it shouldn't behave that way. It seems to me the error flag is raised anyway. My guess is even though those symbols can't be displayed, they are assigned to the screen value somehow.
Conjectures put aside, I've managed to suppress it by adding the following code:
ON CTRL-V OF FILL-IN-1 IN FRAME DEFAULT-FRAME
DO:
if index(clipboard:value, vch-list) > 0 then
return no-apply.
END.
Of course this means vch-list can't be scoped to your trigger anymore, in case it is, because you'll need the value before the leave. So I assigned the special characters list as an INIT value to the variable.
After doing this, I didn't get the error anymore. Hope it helps.
To track changes in a fill-in I always use at first this code:
ON VALUE-CHANGED OF FILL-IN-1 IN FRAME DEFAULT-FRAME
DO:
/* proofing part */
if ( index( clipboard:value, vch-list ) > 0 ) then do:
return no-apply.
end.
END.
You could add some mouse or developer events via AppBuilder to track changes in a fill-in.
I'm having issues when trying to read in a binary file I've previously written into another program. I have been able to open it and read it to an array with out compilation errors, however, the array is not populated (all 0's). Any suggestions or thoughts would be great. Here is the open/read statement I'm using:
allocate(dummy(imax,jmax))
open(unit=io, file=trim(input), form='binary', access='stream', &
iostat=ioer, status='old', action='READWRITE')
if(ioer/=0) then
print*, 'Cannot open file'
else
print*,'success opening file'
end if
read(unit=io, fmt=*, iostat=ioer) dummy
j=0
k=0
size: do j=1, imax
do k=1, jmax
if(dummy(j,k) > 0.) print*,dummy(j,k)
end do
end do size
Please let me know if you need more info.
Here is how the file is originally written:
out_file = trim(output_dir)//'SEVIRI_FRP_.08deg_'//trim(season)//'.bin'
print*, out_file
print*, i_max,' i_max,',j_max,' j_max'
open (io, file = out_file, access = 'direct', status = 'replace', recl = i_max*j_max*4)
write(io, rec = 1) sev_frp
write(io, rec = 2) count_sev_frp
write(io, rec = 3) sum_sev_frp
check: do n=1, i_max
inna: do m=1, j_max
!if (sev_frp(n,m) > 0) print*, count_sev_frp(n,m)
end do inna
end do check
print*,'n-',n,'m-',m
close(io)
First of all the form takes two possible values as far as I know: "FORMATTED" or "UNFORMATTED".
Second, to read, you should use a open that is symmetric to the open statement that you used to write the file, Unless you know exactely what you are doing. I suggest that for reading, you open with:
open(unit=io, file=trim(input), access='direct', &
iostat=ioer, status='old', action='READ', recl = i_max*j_max*4)
That corresponds to the open statement that you used to save the file.
As innoSPG says, you have a mismatch in the way the file is written and how it is read.
An external file may be connected with one of three access methods: sequential; direct; stream. Further, a connection may be formatted or unformatted.
When the file is opened for writing it uses the direct access method with unformatted records. The records are unformatted because this is the default (in the abscence of the form= specifier).
When you open the file for reading you use the non-standard extension of form="binary" and stream access. There is possibly nothing wrong with this, but it does require care.
However, with the read statements you are using formatted (list-directed) input. This will not be allowed.
The way suggested in the previous answer, of using a similar access method and record length will require a further change to the code. [You'll also need to set the value of the record length somehow.]
Not only will you need to remove the format, to match the unformatted records written, but you'll want to use the rec= specifier to access the records of the file.
Finally, if you are using the iostat= specifier you really should check the resulting value.
In standard Pascal (ISO7185), there was no procedure Assign that would've let a programmer to assign some kind of file name to a file variable. It only appeared in Turbo Pascal and other derivates.
So... how am I supposed to open a handle to a specific file if I comply with the standard?
Closest I've found is this Irie Pascal example:
program vowels(f, output);
var
f : file of char;
tot, vow : integer;
c : char;
begin
reset(f);
tot := 0;
vow := 0;
while not eof(f) do
begin
read(f, c);
case c of
'a', 'e', 'i', 'o', 'u',
'A', 'E', 'I', 'O', 'U'
: vow := vow + 1;
otherwise
end;
tot := tot + 1;
end;
writeln('Total characters read = ', tot);
writeln('Vowels read = ', vow)
end.
which suggests I might be able to give the file name as a startup parameter. This works using Irie Pascal. However, if I try to use that with P5, which should be closest to standard-compiliant Pascal compiler for modern computers I've found, I get (after replacing 'otherwise') **** Error: external file unknown 'f '. So, what'd be the standard way? Or is this actually the standard way and P5 is doing something wrong?
Edit: standard also gives a sample
program copy (f, g);
var f,g : file of real;
begin
reset(f) ; rewrite(g);
while not eof(f) do
begin
g^ := f^ ; get(f) ; put(g)
end
end.
but I haven't been able to get that to work with any compiler.
Edit2:
Doing it like this:
program copy (f, g);
var f,g : file of char;
begin
reset(f) ; rewrite(g);
while not eof(f) do
begin
g^ := f^ ; get(f) ; put(g)
end
end.
works just fine in Irie and is compliant with the standard. Using that, file name can be given as a startup parameter.
However, as explained by Marco van de Voort,
ISO 7185 does not have any standard way for a program to specify
file names at all, so any such way is already beyond 7185 (Bind
is ISO 10206, Assign is UCSD/BP, the 2nd parameter to Reset is
an extension of GPC and I think some other compilers).
(source)
IIRC this was for VMS support where the OS bound files before starting the program.
Unbound files were automatically tempfile iirc. Search the GNU Pascal maillists (old archives, say 2005 or so), they had quite some discussions about ISO file implementation.
It was Scope on the CDC 6000 series machines. However, the rest is correct. You basically assigned external files to logical header file names in the Scope command language.
Of course this seems very tedious now, but these were the days of the batch mode computer, where everything was submitted as a "deck" of cards to be run as input, then collected as a series of output "cards". Tape reels got rid of the actual cards, but tapes were treated as a collection of cards on a tape.
In normal use, Wirth's original compilers were actually limited to just an input and an output file. If you wanted more than one input file, you concatenated them. This was easier than it sounds, since most input and output files were text, and every file had distinct end tolkens in it.
This paradigm fit well with the idea that you mounted an input tape and an output tape for a job on a batch system. The job of the batch computer was to linearly process the input tape and produce the output tape. A large and fast machine would have several jobs concatenated onto a single tape and run sequentially.
The option of a high speed printer typically rounded out the system. Thus, a college kid in the 1960s learning computer science would punch a deck on what looked like a typewriter (or get it typed by a keypunch operator), then that deck would be collected and transcribed to a tape deck and scheduled to run. An hour or more later, you were handed a section of greenbar from the printer that represented the output from your program.
Anyways, its always a good debate question as to why Wirth put that limitation in the language. Probabaly it was for the simple reason that the CDC 6000 machines could not have dealt with a feature that randomly opened a file by name. Also remember that the predecessor to Pascal, Algol, had no I/O statements whatever! They considered I/O to be inherently machine specific.
Scott Moore