|
|
Post by George on May 6, 2017 11:35:04 GMT -5
MUEH: Got your files. No I'm not testing a fix for this (yet) since so far I haven't even been able to duplicate the failure consistently. Without a consistent failure, there's no way to debug and find what's wrong.
Hopefully, I'll get to some testing today.
George
[Update]
OK, tested with your files, and got the problem. But it's still transient, I can't get it to fail in Debug mode. But in trying things out, my latest source level does NOT experience the problem, even though no changes other than fixes for two unrelated bugs are included.
So I've sent you a newer version to try out via email.
George
|
|
|
|
Post by MUEH on May 8, 2017 9:45:11 GMT -5
George: Good News .
All 3 remaining MEDIT Problem's after 7110 (D(etach), =FILE* not done if first file if changed , Termination CAN cmd )
are solved by 7127 .
Thanks for Excelent Support .
|
|
|
|
Post by George on May 8, 2017 10:10:00 GMT -5
MUEH: Great! Now if I could only REMEMBER making those fixes. Darn! Old age is no fun.
George
|
|
|
|
Post by MUEH on May 8, 2017 14:04:28 GMT -5
George: Just if you want to fix this MEDIT D(etach) Problem when all File data is Excluded .
Do following cmd .
;edit "C:\Users\MUEH\Documents\SPFLi85\MACROS\dos.macro";medit cls.macro;medit only.macro;medit xfly.macro;x all
first D(etach) for file 3 works . 2'nd D(etach) now for file 2 deletes only =FILE> line and file 1 gets the data .
If a least one data line is NX the Problem doesn't occure . Assume that this Data is saved but i didn't try it .
I know now that on D(etach) Data must not be excluded .
|
|
|
|
Post by MUEH on May 9, 2017 3:19:47 GMT -5
The sentence
If a least one data line is NX the Problem doesn't occure
is incorrect . It should say that X lines are not deleted on second Detach .
|
|
|
|
Post by George on May 9, 2017 12:19:32 GMT -5
MUEH: Another MEdit bug? You're too good at finding them. I'll have a look.
George
|
|
|
|
Post by MUEH on May 19, 2017 0:41:07 GMT -5
I Wrote following Macro to Count or select Lines from Medit Session .
' MULCT.macro
/*
Function: LineCount the X and NX Lines in [M]EDIT Session and writes NX to file
Syntax: MULCT [X]
Limits: all M can can only process 499 files, 500 Msg Excessive operands for MEDIT command, >500 Crash
Get_Line$(lptr) RC8 Non modifyable line for FILE Line
Author: Johann Muehlhofer
*/
uses "FILE"
dim i, ip1, ip2, finr, fist as number value 0
dim lid as string
ip1 = SPF_Loop_Check("OFF")
' SPF_Cmd("res")
if Get_Arg_Count=1 and Get_Arg$(1)="X" then SPF_Cmd("X all") ' for Line Counting per File
finr = FILE_Open(Get_INI_Path$+"\MULCT.LCT","OUTPUT")
ip1=1:lid=Get_FilePath$+Get_FileName$
for i = 1 to Get_Last_LPtr
if Get_Line_Type$(i) = "FILE" then
' if Is_File(i) <> 0 then ' -1 instead of 1 so i prefer above line
lid = Get_Line$(i) ' will make request to George to return (eventualy 6 byte =FILE* +) FILE Line Data
if Get_RC<>0 then
Set_Msg(lid+" RC="+Get_RC+" MSG="+Get_Msg$+" LPtr="+i+" LNum="+Get_LNum(i+2))
lid=Get_FilePath$+Get_FileName$
endif
endif
if Get_Line_Type$(i) = "DATA" then
if Get_XStatus$(i) = "NX" then
' if Get_Line_Len(i) = 0 then SPF_Cmd("loc "+Get_LNum(i))
fist = FILE_LinePrint(finr,string$(11," ")+Get_Line$(i))
ip1 = ip1 + 1
endif
endif
if Get_Line_Type$(i) = "EXCL" then
ip2=ip1+Get_XLINES(i)-1
if lid="" then
fist = FILE_LinePrint(finr," /"+string$(26," ")+rset$(Get_XLINES(i),7)+rset$(val(ip1),8)+rset$(val(ip2),8))
else
fist = FILE_LinePrint(finr,File_GetDateTime(lid)+rset$(File_Size(lid),10)+rset$(Get_XLINES(i),7)+rset$(val(ip1),8)+rset$(val(ip2),8)+" "+lid)
lid=""
endif
ip1=ip2+1
endif
next
fist = FILE_LinePrint(finr,Get_Session_Type$)
ip1 = SPF_Loop_Check("ON")
fist = FILE_CLOSE(finr)<span style="font-family: Verdana, Arial; font-size: 10pt;">
</span>
|
|
|
|
Post by MUEH on May 19, 2017 0:53:52 GMT -5
Hello George !
Would it be possible to Enhance Get_Line$ when issued to M-Edit FILE Line to Return
6 Byte =FILE> or =FILE* followed by Full Path File Name ? Set_Line$ should fail .
This will allow knowing the File Name we are just processing .
Thanks
|
|
|
|
Post by George on May 19, 2017 13:17:49 GMT -5
MUEH: OK, I checked the Get_Line$ function and ended up removing a check in there for retrieving lines which could not be modified. Reading such lines should not have been restricted. The Set_Line$ function will of course still prevent altering such lines.
Your suggestion for providing the line control data is worthwhile, since the Get_Modified function does not handle the MEdit files individually.
So Get_Line$ will, for FILE lines only, prefix the lines text data (in FILE's case - the file name) with the ==FILE> or ==FILE* line control data. This information will be in an 8 character prefix field, as that is the max length allowed for a line control field.
If you can privately provide me with your email address, I will send you a copy of SPFLite with this new support.
George
|
|
|
|
Post by MUEH on May 20, 2017 13:55:48 GMT -5
Thanks George . Get_Line$ for =FILE Line works perfekt .
But i noticed another Problem .
all medit command to a file list larger than 499 fails .
With exactly 500 files Msg Excessive operands for MEDIT Command is issued .
With more than 500 files it fails with
SPFLite has encountered an execution exception (C0000005)
Last Interactions were:
KB Primitive: ENTER
Line Cmnd:
Primary Cmnd: all m
Module Back Trace:
06 | CMDPARSE
05 | SDOMEDIT
04 | CALLTAB
03 | FMPCMDALL
02 | CMDASSIGN
01 | POSTKEYBOARD
00 | MAINDKEYPROCESS
Note: A copy of this message is in: C:\Users\MUEH\Documents\SPFLi85\SPFLiteCrash.2017052019423228.txt
all BROWSE or EDIT VIEW don't fail however i noticed that only up to 214 TABS where loaded with data .
i experienced problem when file list where 2 different Hercules SPFLite has encountered an execution exception (C0000005)
Last Interactions were:
KB Primitive: ENTER
Line Cmnd:
Primary Cmnd: all m
Module Back Trace:
06 | CMDPARSE
05 | SDOMEDIT
04 | CALLTAB
03 | FMPCMDALL
02 | CMDASSIGN
01 | POSTKEYBOARD
00 | MAINDKEYPROCESS
Note: A copy of this message is in: C:\Users\MUEH\Documents\SPFLi85\SPFLiteCrash.2017052019423228.txt
i found problem when file list where 2 Hercules source paths . (more than 500 files).
all BROWSE VIEW EDIT don't have the Problem but i noticed that only 214 Tabs have Data loaded .
Occures also when selecting the 500 smalest files .
Thanks George
|
|
|
|
Post by MUEH on May 21, 2017 7:28:10 GMT -5
George: Some Lines above are Pasted twice . Sory .
Got 2 new concerns .
If PASTE or COPY is done After =FILE> or Before first data line =FILE* is not set .
If I (Insert) is done =FILE* is set but Inserted Data Line disappears on Enter.
Doc says that Basicaly in Medit the same things can be done as in regular Edit session .
Do i expect too much Functions from MEDIT ?
|
|
|
|
Post by George on May 21, 2017 12:51:18 GMT -5
MUEH: No, you're not expecting too much from MEDIT, but you're certainly the first user to start reporting bugs.
The failing I command sure is weird, a definite bug.
The limit on ALL turns out to be a dumb one. When ALL MEDIT is done, it basically fires up a MEDIT command with all the filenames as operands. This works just fine except it shows a failing in the basic command parser code, which has a limit of 500 operands for a command.
Sure, I know, all table entities should be handled to grow as needed, but I guess when writing the parser, allowing 500 operands seemed like a value that just never could be exceeded. After all, I couldn't conceive of any command needing more than maybe 10-20 operands.
I'll have a look at fixing these up.
BTW - I'm assuming your 500+ files must be fairly small or this could sure show up some performance issues.
George
|
|
|
|
Post by George on May 21, 2017 14:31:45 GMT -5
MUEH: OK, the I command, PASTE and COPY were all basically triggered by the same error. Now corrected.
And I've figured out the 500 limitation for MEdit and removed it. I tested with about 750 small files, and it's certainly not speedy either loading or saving, but it chugs through. I guess if MEdit makes some editing process simpler, I guess the wait becomes worth it. There's not really much I can do for the speed, MEdit basically cobbles together a whole bunch of the normal processes, trying to speed it up means tinkering with all these basic processes, and I'm reluctant to do that because of the potential impact on everything else.
I'll be sending you a revised 'toy' to play with.
George
|
|
|
|
Post by MUEH on May 23, 2017 4:20:16 GMT -5
George: Get_Line$ for =FILE Line, Insert Problem and 500 file limit are perfectly solved .
However when i made a stress test with large nr of Files (900 or 1200 ) from 400k to 50 bytes with a total size of 50 Meg and 1 Million Lines loading gets Execution exception followed by Loop detection msg
Filesize 536 Line 1 of 22 Col 1 of 106 Tabs( 8) CHAR
SPFLite has detected an internal loop
Last Interactions were:
KB Primitive: ENTER
Line Cmnd:
Primary Cmnd: all m
Module Back Trace:
08 | GETINCREMENT
07 | LINSERTEMPTY
06 | COPYAFILE
05 | SDOMEDIT
04 | CALLTAB
03 | FMPCMDALL
02 | CMDASSIGN
01 | POSTKEYBOARD
00 | MAINDKEYPROCESS
Note: A copy of this message is in: C:\Users\MUEH\Documents\SPFLi85\SPFLiteCrash.2017052310072189.txt
Depending on sort order of files ( size ascending descending or name ) GETINCREMENT Module is not in back Trace .
my file list is
C:\spinhawk-release-3.12\*.c|*||
D:\spinhawk-master\*.c|*||
C:\hyperion-master\*.c|*||
C:\hercules-390-master_2012_11_30-with-tk4--patches\*.c|*||
D:\hyperion-4.0.0-rc0\*.c|*||
C:\spinhawk-release-3.12\*.h|*||
D:\spinhawk-master\*.h|*||
C:\hyperion-master\*.h|*||
C:\hercules-390-master_2012_11_30-with-tk4--patches\*.h|*||
D:\hyperion-4.0.0-rc0\*.h|*||
To get that amount of files i think you can download one Hercules source and restore it to 5 Path's .
If you think it's not worth to analyze further i can live by spliting it into less data . ( x *.c or *.h )
Performance 15 min to load Is no problem for me because once loaded it is relative fast to do FIND LOCATE
and access via macro.
Thanks
|
|
|
|
Post by George on May 23, 2017 13:54:38 GMT -5
MUEH: OK, that file size, whether a MEdit session or not, is pushing things. There's nothing coded in which would limit file size, it's simply a resource problem, and some routines REALLY grown as the file size goes up.
Am I reading correctly, you got an exception BEFORE the loop detection? If so, I'm at bit at a loss, trying to debug something that requires such huge test data is basically impossible. Now if the loop message occurred before the exception, then maybe this can be corrected; I'm sure that is just because the whole loading process has taken much longer than ever expected and SPFLite thinks it has gone into a loop. This could be avoided by internally flagging MEdit as a 'loop exempt' process.
Or, as you say, break this down into chunks. Not as convenient however.
George
|
|
