Error 2278 - Retain Release Conflict

Exciting new Business Rules announcements!
(Outgoing messages only)

Moderators: Susan Smith, admin, Gabriel

Gabriel
Posts: 399
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Postby Gabriel » Mon Jul 19, 2010 3:41 pm

I think he's calling the library from itself with release.

So there's no Program A and Program B. There's only Program A.

It would be like

Code: Select all

10 library, release : fnx
20 let fnx
30 stop
40 !
50 def library fnx
60    print "Hello World"
70 fnend

Gabriel
Posts: 399
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Postby Gabriel » Mon Jul 19, 2010 3:44 pm

To be more specific, he's using a named library statement to call its self. Correct me if I'm wrong, Pete.

Code: Select all

 (self.br)
10 library release "self.br" : fnx
20 let fnx
30 stop
40 !
50 def library fnx
60    print "Hello World"
70 fnend

gordon
Posts: 331
Joined: Fri Apr 24, 2009 6:02 pm

Postby gordon » Mon Jul 19, 2010 4:05 pm

This would violate the rule that a libaray cannot be called with RELEASE while it is still in memory from a non-RELEASE call. When you load a program to run it, it is invoked by the RUN process. The dictionary could have received any number of assignments prior to calling the embedded function. Once the dictionary is in use, it cannot legitimately be called with release because it would clear ALL of the variables in it's dictionary.

That is something to remember when grouping functions into libraries as well. Each call to a function with RELEASE clears ALL of it's variables. Actually the variables are cleared upon exiting a RELEASE call but the same restrictions are applicable.

gordon
Posts: 331
Joined: Fri Apr 24, 2009 6:02 pm

Postby gordon » Mon Jul 19, 2010 4:12 pm

Having said the above, I am tempted to provide an OPTION in the current release of BR ( 4.2 ) to allow a program to call an embedded function with RELEASE for the specific purpose of clearing all of it's own variables.

Susan Smith
Posts: 715
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Postby Susan Smith » Mon Jul 19, 2010 4:49 pm

Gordon, Are you suggesting the use of an OPTION for backwards compatibility so that old programs that used this convention can continue using the syntax as before? Because of you aren't, I'd think that it would be much more clear to use a different ( new) switch for the clearing of variables only, such as ,CLEARVAR

Then there wouldn't be confusing about what's happening - especially if the library calls are nested deeply, making it hard to trace it all back to find out of a library is in fact being released while in memory. Personally, I like ,RELEASE to clear the LIBRARY & its vars as it's always been, and ,CLEARVAR (or something like it) to indicate that only the variables are being cleared and not the library.

Just my thoughts.

-- Susan

PJKLUG
Posts: 27
Joined: Tue Jun 09, 2009 9:29 am

Postby PJKLUG » Mon Jul 19, 2010 11:35 pm

This is the "stand alone" code that can be loaded and RUN...
This will RUN in 3.91f with or without the RELEASE on line 10
This will only RUN in 4.18i without the RELEASE on line 10

0010 LIBRARY RELEASE,"LIB_PROG" : FNLIBCALL
0020 LET FNLIBCALL
0030 DEF LIBRARY FNLIBCALL
0040 PRINT NEWPAGE !:
PRINT FIELDS "5,1,C 20,N": "GOT HERE...." !:
INPUT FIELDS "5,25,C 1,UA,N": Y$ !:
PRINT NEWPAGE
0050 FNEND

The same function "called" from other code that is loaded and RUN...
This will RUN in both 3.91f and 4.18i with or without the RELEASE on line 10 of the above code

0020 PRINT NEWPAGE !:
PRINT FIELDS "4,1,C 20,R,N": "NOW CALLING..." !:
INPUT FIELDS "4,25,C 1,UA,N": Y$
0030 OPEN #2: "SROW=1,SCOL=1,EROW=24,ECOL=80",DISPLAY,OUTIN
0040 LIBRARY RELEASE, "LIB_PROG" : FNLIBCALL
0050 LET FNLIBCALL
0060 CLOSE #2:
0070 PRINT FIELDS "6,1,C 20,R,N": "DONE CALLING..."

I suppose it is redundant to RELEASE the variables twice in the second set of code with the RELEASE in both the calling code and the called code but at least the variables get cleared. By not allowing the RELEASE in the stand alone code we don't have the option. I was always taught to clean up after myself when I was done with something.

Pete

PJKLUG
Posts: 27
Joined: Tue Jun 09, 2009 9:29 am

Postby PJKLUG » Mon Jul 19, 2010 11:44 pm

This isn't violating the rule that a libaray cannot be called with RELEASE while it is still in memory from a non-RELEASE call because there NEVER was a non-RELEASE call. ALL my library calls have RELEASE. That's been my point in this entire discussion so why the error? Even 3.91f gives me that error and that's not a problem but in this case it shouldn't be an error in any version.

Pete

GomezL
Posts: 238
Joined: Wed Apr 29, 2009 5:51 am
Contact:

Postby GomezL » Tue Jul 20, 2010 5:02 am

Just for fun, I tried this in BR 4.03jf.

IN BR. 4.03jf, it did "Get here".

I also noticed that the library was released (Not Active).

I made a few changes to see what happens:

00010 LIBRARY RELEASE, "LIB_PROG" : FNLIBCALL
00015 ! EXECUTE "STAT MEM" : PAUSE
00020 LET FNLIBCALL
00025 EXECUTE "STAT MEM" : PRINT VAR$: PAUSE
00030 DEF LIBRARY FNLIBCALL
00035 LET VAR$="Still in memory"
00040 PRINT NEWPAGE !:
PRINT FIELDS "5,1,C 20,N": "GOT HERE...." !:
INPUT FIELDS "5,25,C 1,UA,N": Y$ !:
PRINT NEWPAGE
00050 FNEND

VAR$ does get cleared in 4.03jx, but memory doesn't really seem to be affected one way or another.

Another interesting thing


00010 LIBRARY RELEASE, "" : FNLIBCALL

This doesn't produce an error, but VAR$ still retains it's values.

gordon
Posts: 331
Joined: Fri Apr 24, 2009 6:02 pm

Postby gordon » Tue Jul 20, 2010 9:15 am

I now realize that the OPTION I described earlier is superfluous because every program that is run gets initialized by clearing it's variables. So by removing the RELEASE in line 10, the program already has it's variables cleared when it is run, and the program goes away when it chains to another program such as a menu. At the same time, the function can be called with RELEASE to assure that the variables are cleared between calls by other programs.

In one case it is run as a program. In the other case it is called as a library function.

By not allowing the RELEASE in the stand alone code we don't have the option.


As I indicated above, in stand alone mode the program is freshly initialized anyway and it goes away when the program ends, so clearing the dictionary is a natural consequence of running the program instead of calling it.

Please let me know if this does not meet all of your needs for running programs and calling them.

PJKLUG
Posts: 27
Joined: Tue Jun 09, 2009 9:29 am

Postby PJKLUG » Tue Jul 20, 2010 9:47 am

That works for me. I will make the changes in all my programs that are both stand alone and called as libraries. Someone should be sure to document this INCOMPATIBILITY between versions 3.9x and prior and the 4.xx versions. Fortunately I only have to worry about myself as my only customer.

Is the fact that F7 start copy F7 end copy are no longer highlighted in 4.xx when not in GUI mode a bug or just no longer supported because everyone is using MyEdit? I don't know what happens in GUI mode.

Pete

John
Posts: 550
Joined: Sun Apr 26, 2009 8:27 am
Location: West Orange, NJ
Contact:

Postby John » Tue Jul 20, 2010 9:52 am


gordon
Posts: 331
Joined: Fri Apr 24, 2009 6:02 pm

Postby gordon » Tue Jul 20, 2010 10:34 am

I was not aware the F7 highlight had gone away. That will be restored.

However, now you can use Windows keys for highlighting, cutting, copying and pasting.

NOTE: This provides two scratch pads - Windows and the original BR F7/F8 save area.

PJKLUG
Posts: 27
Joined: Tue Jun 09, 2009 9:29 am

Postby PJKLUG » Tue Jul 20, 2010 11:51 am

Thanks... I have been using the windows highlighting in 3.9x and the F7 too. The F7 still works in 4.xx but it's less "visual".

Pete


Return to “Announcements”

Who is online

Users browsing this forum: No registered users and 1 guest

cron