RE: [ql-users] Display_cde GD2 update
There's always one isn't there ! when the line gets too long - and I'm not quite there yet - you simply get a 'buffer full' error when loading a really really long line into S*Basic. So, I suspect the limit on the number of parameters in a PRINT is defined by the length of the actual line of pre-compiled text - 32Kb if I remember correctly. I'll let you know what the limit is - if I ever find it ! Cheers, Norman. - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:[EMAIL PROTECTED] Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - -Original Message- From: Marcel Kilgus [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 06, 2003 1:35 AM To: ql-users Subject: Re: [ql-users] Display_cde GD2 update I hope nobody is trying to actually find that limit in practice, though. Marcel This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
Re: [ql-users] Display_cde GD2 update
Norman Dunbar writes: There's always one isn't there ! when the line gets too long - and I'm not quite there yet - you simply get a 'buffer full' error when loading a really really long line into S*Basic. So, I suspect the limit on the number of parameters in a PRINT is defined by the length of the actual line of pre-compiled text - 32Kb if I remember correctly. I'll let you know what the limit is - if I ever find it ! Theoretically one would expect the maximum possible number of parameters to be max_linelength / 2 - 2 Say you defined a single character machine code procedure (X) and didnt use a line number, eg: X p,p,p,p,p,... youd expect to be allowed up to 16380 parameters. Actually, for Smsq/e 2.99 the answer appears to be that 'only' up to 5459 parameters are allowed (provided the line length is not exceded). But this could be arbitrary. Check it out: 100 p% = 5459 110 OPEN_OVER#3;'ram1_tst_bas' 120 PRINT#3; '1 X '; 130 FOR i% = 1 TO p% - 1: PRINT#3; 'p,'; 140 PRINT#3; 'p' 150 CLOSE#3 LOAD ram1_tst_bas into an SBasic and try to LIST or EDIT it. What are the limits for other systems? (Not terribly important, I suppose, but nice to know all the same ;) Per
Re: [ql-users] Display_cde GD2 update
In article [EMAIL PROTECTED] uk, Norman Dunbar [EMAIL PROTECTED] writes There's always one isn't there ! when the line gets too long - and I'm not quite there yet - you simply get a 'buffer full' error when loading a really really long line into S*Basic. So, I suspect the limit on the number of parameters in a PRINT is defined by the length of the actual line of pre-compiled text - 32Kb if I remember correctly. I'll let you know what the limit is - if I ever find it ! Be careful out there ... remember the outer limits :-) -- Malcolm Cadman
Re: [ql-users] Display_cde GD2 update
Twenty years or so ago, it seemed to be standard practice in the Defence Industry to write Fortran that way. For some reason, Named Common Blocks were thought to be bad practice, so everything was passed by formal parameters. Hundreds of them. Even if they weren't used in that routine;( think of a tree structure; to get info from one twig to another the data has to go all the way up to the trunk and back down again). More than one large simulation that I took over was spending almost all the execution time (overnight runs) pushing data onto the stack and pulling it off again, and was speeded up by orders of magnitude by use of Named Common. Jeremy - Original Message - From: Marcel Kilgus [EMAIL PROTECTED] To: ql-users [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 3:08 PM Subject: Re: [ql-users] Display_cde GD2 update Wolfgang Lenerz wrote: 358 parameters? To a basic procedure? I'd be MOST interested in knowing what that procedure does... Nothing exciting really. Just seems that instead of using global variables everything is passed as parameters (100 alone are for different key codes of the menu selection). Nice also the ~370 REMark lines trailing the procedure that explain all parameters ;-) Which also partly explains the size of over 13300 lines. Marcel
Re: [ql-users] Display_cde GD2 update
On Tue, 04 Feb 2003 07:12:21 +0100, Wolfgang Lenerz [EMAIL PROTECTED] wrote: On 4 Feb 2003 at 0:05, Marcel Kilgus wrote: Nice one regarding programming style: I have just spent several hours tracing through the SBasic compiler to find a bug that caused SBasic to crash. The program causing the crash used PROCedures with up to 358 (sic! three hundred fifty eight!) parameters. This was too much for a poor subq.b within the compiler's second stage. A shiny new subq.w can now handle even that one... 358 parameters? To a basic procedure? I'd be MOST interested in knowing what that procedure does... Wolfgang Hmmm most likely Windows XP emulation ;-) Phoebus -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: [ql-users] Display_cde GD2 update
Marcel Kilgus wrote: Dilwyn Jones wrote: These new functions, written with much appreciated advice from Marcel Kilgus, Glad you didn't mind me lecturing ;-) Lecturing? I wouldn't exactly call that very helpful email being lecturing! Nice one regarding programming style: I have just spent several hours tracing through the SBasic compiler to find a bug that caused SBasic to crash. The program causing the crash used PROCedures with up to 358 (sic! three hundred fifty eight!) parameters. This was too much for a poor subq.b within the compiler's second stage. A shiny new subq.w can now handle even that one... Hmmm, even Launchpad doesn't quite manage 358 parameters. Don't think that's one I'll be complaining about. Liked Phoebus's reply about trying to emulate Winwoes XP though! -- Dilwyn Jones
Re: [ql-users] Display_cde GD2 update
Dilwyn Jones wrote: These new functions, written with much appreciated advice from Marcel Kilgus, Glad you didn't mind me lecturing ;-) Nice one regarding programming style: I have just spent several hours tracing through the SBasic compiler to find a bug that caused SBasic to crash. The program causing the crash used PROCedures with up to 358 (sic! three hundred fifty eight!) parameters. This was too much for a poor subq.b within the compiler's second stage. A shiny new subq.w can now handle even that one... Ah well, and now back to some actually paid work. ;-) Marcel
Re: [ql-users] Display_cde GD2 update
On 4 Feb 2003 at 0:05, Marcel Kilgus wrote: Nice one regarding programming style: I have just spent several hours tracing through the SBasic compiler to find a bug that caused SBasic to crash. The program causing the crash used PROCedures with up to 358 (sic! three hundred fifty eight!) parameters. This was too much for a poor subq.b within the compiler's second stage. A shiny new subq.w can now handle even that one... 358 parameters? To a basic procedure? I'd be MOST interested in knowing what that procedure does... Wolfgang
