Hi guys,
I was respecting the power save mode in the US not posting anything here but, on the other hand, maybe a light subject can you help you spend the time thinking while your computers are turned off.

I don't know if anyone will find this useful considering it is directly related with my solitary development platform, with the lack of rules and bad method but, if not, maybe some good idea come up.

I deliver new releases to my customers on the fly; the customer asks, I change the program, publish and install it as fast as possible, this is the perfect scenario.
The not perfect one, and frequent, is when, during that change, another customer ask for an urgent help, or change to another program, and I interrupt what I was doing.
That interruption can take, hours or days.

I try to keep my running changes opened in the Editor but, for many reasons, at some point I have to close it and, I don't know why, APN doesn't keep the opened files on the next session.
Anyway that's not the point because, probably, it would not save me from the real problem, which is:

A customer asks for another change in a program that is under development, I do it and send a release that has unfinished changes.

To avoid this to happen, I thought if it would be possible to compile/execute to a different extension, like XRUN because I just publish SBX and RUN files.

Maybe ++pragma XRUN, like we have already for ++pragma SBX could inform the compiler to create the result with the XRUN extension and keep the original RUN/SBX file untouched.
At runtime, if an XRUN is found it would take precedence over existing RUN/SBX files.
To save time on searching for XRUN files on each program execution, maybe a MIAME setting could inform A-Shell to do it, because that should only be set on in-house development scenarios.

So, too much craziness?

Good day Jorge!

Still working here but with limited resources

You hit our problem on the HEAD!

We have programs in "Quarantine" for one customer, then another customer has an emergency request or we need to perform a bug fix. Sounds like your issue as well?

Sometimes I will make it to the standard release (Archived) version and add them to the version in Quarantine as well. OR i will make it to the quarantine version and notify the customer they are getting a beta version of the program. I am sure there are programs to manage these things but since we are working on a shoestring budget doing the best we can

Looking forward to replies...

Hi Frank,

Let me know if you need more candles, I'm sure US and Brazil now think on the same wave so, there will be no problem to deliver there survival goods. :p

I was about to add this request to your post under a similar topic but I was afraid to mix different things besides possibly related.

My unique goal here is to guarantee that, because I forgot, not send "under work" programs to my customers.
It's still up to me check what I was doing before.

Precisely this morning, a customer sent an email asking for a new simple feature, those that I can do in half an hour, I opened the program, add a few traces to check a couple of things, compiled it and was testing the program. Since then, I wasn't able to get back to that due a lot of things, including have to feed Violeta and change her diapers so, easily, I will forget about that running test which besides harmless will not be elegant to publish.
With my request, the first thing I would do is to add ++pragma xrun to the top line and guarantee that program will not go by mistake to any customer.

For what I understood from your previous post, you want more control about what kind of changes are running and the possible impact on the field, no?

Have a nice weekend and take the chance to fill the storeroom with extra supplies

This doesn't address the compiled application directly, but it seems like you'd greatly benefit from adopting some form of revision control.

Either git or mercurial as they're the to two most popular DVCS. With git being significantly in the lead now days, and having much better Windows support. Beside MicroSoft buying github.com, they also undertook a multi-year project of converting all of the development teams to using git internally. It would seem MicroSoft has a vested interest to ensure git continues to support Windows.

There are also a multitude of git GUI's to make it easier to use, but TortoisHg is still the de facto/premiere mercurial GUI.

From a code perspective you'd commit your changes prior to releasing the application to the customer, so you'd see you had prior changes in the source of any files in your repository.

I know Jorge works alone, but this making working with other developers drastically simpler, and less error prone.

I have the same problem. (Probably everyone does.)

Stephen is definitely right on revision control, although I can appreciate that when you've already got too many things on your plate, adding another complicated tool to learn may not seem like a step in the right direction. But there's no question that the "right" way to deal with the problem of needing a quick fix for one customer while you're in the midst of a more complicated update is to create a branch, or shelve the in-progress work and make your quick fix to the prior version, then merge them later.

But, as noted, that doesn't address the question of how to keep the various RUN versions separate, and especially how to do that in a way that doesn't get so complicated it introduces more problems than it solves.

To consider another variation of the problem, sometimes I'd like to introduce a new version of a program into a production environment (on the theory that the changes are minor enough that it's not worth constructing a full scale parallel test). In other words, the human guinea pig scenario. What I'd like is a really simple mechanism to roll that change back to the prior version at the first indication of trouble. Ideally, simple enough that a standard menu option could take care of it. So I'd tell the customer that I installed an update, but if they had any problem with it, just use the roll back option.

Perhaps Jorge's idea of an alternate extension for 'beta' executables (e.g. .RUNX, .SBXX, .LITX) would fit into that, provided there was a simple way to toggle the runtime option to use or ignore the 'beta' versions.

Inserting a ++PRAGMA at the start to tell the compiler to generate the 'beta' version might be a pain (compared perhaps to a switch), but it would probably address the problem of getting distracted and forgetting that the program wasn't really ready for prime time (assuming you had the sense to insert it immediately when you started working the updates in question.)

Definitely an idea to ponder.

Must have been another "bar-level" conference topic...

I seem to recall something regarding software control. As a wise man once said, sometimes the cure overwhelms the problem. It might be cool to see somehow the programs in beta. Not sure what to recommend. Certainly easily distracted with other projects, life, diapers, to forget where u leave off.. We just tend to use the old fashioned PPn system to hold onto revisions until the program is cleared for now...

Thanks for the offer Jorge, candles still holding out! You might just need to keep a supply handy as well ;

Thank you guys for the discussion.
I definitely agree with Stephen that Tortoise should be the tool in place but, as Jack mentioned, there is a learning curve to implement and adjust to the development platform, shame on me, even for APN, which is implemented and is just a matter of using it, I did it at the beginning but, since a long time that I gave up when it started to not update correctly and I wasn't able to figure out how to fix.
So, on Frank's wave, what would really help me is a simple solution just to minimize the risk to not publish a beta program and I'm still convinced that changing the running extension would be the most adequate.
Obviously it's not a fail proof solution once it's manually controlled but, I'm sure, the benefit of the method would be enough good to encourage me to not forget to add, or maybe uncomment, the ++pragma xrun line and follow it with comments about the running changes.

Related to this, I take the chance to ask if APN has the ability to remember the opened files from the last session.

On the issue of APN remembering open files, it does if you establish a workspace. To do that, first start with a fresh session and open several files. Then use File..Save Workspace to give the workspace a name (e.g. foo.pnws). I suggest saving all of your workspaces in the APN\settings directory.

Once the workspace is associated with the session, then when you close out of APN, it will prompt you to save the workspace, which saves the list of open files and other session details.

Then, the next time you open APN, use File..Open Workspace to open it back up again.

As for the original idea of a special extension for beta programs, we don't really need any new features in the compiler, since there is already a ++PRAGMA FORCE_EXT "ext" . (Note that the extension is limited to 3 characters, so you can't have "xrun" or "runx" but you can have "rnx".)

So that part is easy. It's the other part where we have to be careful so the "solution doesn't overwhelm the problem".

Maybe the simplest thing is for you to just manually copy the .RNX files to .RUN after transferring them to the target system?

Another possibility is for the runtime system to just automatically look for these alternate extensions (e.g. rnx, sxx, ...?) and use them in favor of the corresponding standard versions if they exist. That wouldn't be very difficult to implement, but has the two potential downsides of:

1) Slight extra overhead for every program load;

2) Possibility that the A-Shell update will inadvertently start using some forgotten old backup copies of programs that have been left on customer systems, causing havoc.

(1) doesn't bother me much, but (2) is a potential killer.

The next option is to allow you to activate this feature, either via a MIAME.INI switch, XCALL MIAMEX function, or ...? But then you have to manage the process of activating/deactivating that switch, which could lead to some confusion in the field.

An even more flexible option would be to implement a PATH capability like we are used to in every other environment. (That has been a wish-list item for years, but it also risks the solution overwhelming the problem.)

Caution: considering the options and arriving at the best solution may require more than one caipirinha on the beach! So pace yourself.

You were right!!!
After the second caipirinha the solution came instantly

Note that, I don't intend to use the beta RUN files in customers, this is only to use in my development platform and, precisely, to avoid publishing beta programs in my updatecenter (from where I deliver to my customers).
On my initial post, I mentioned the need to add a MIAME option to inform A-Shell to look for Beta run files that would be set only on my platform, precisely, to avoid the overhead in customers.


But, unknown for me until now, your little treasure ++PRAGMA FORCE_EXT "RNX" does the trick, it's enough for what I need because I can control the RUN from my Menu instead of expect that A-Shell does.
If I mention the extension in the RUN statement, it does run that file so, I've adjusted my Menu program to lookup for RNX and, if found, asks if I want to run the beta program (.RNX) or the normal one (.RUN) or even if I want to delete the .RNX.

This was about to be perfect but, first, I tried "RUN test.RNX" with a small program and it worked, when I tried it with several "real" programs, I'm receiving "out of memory" running .RNX that are copies of .RUN files

Any tip?

I'm sorry to say, but this may take another couple of caipirinhas. :rolleyes:

It turns out that the loader cares about the file extensions, because it needs to know whether a file being loaded is a "program" (currently RUN, SBX or LIT), or data (anything else). The reason why it matters is that programs get converted from the format on disk to the executable format in memory during the load operation. (This is an unfortunate hangover from AMOS compatibility - RUN files under AMOS contain 32 bit integers in the peculiar AMOS word-swapped format, like I4 variables. To avoid having to worry about whether the byte swapping has been done at runtime, it is done at load time. But obviously we don't want to do any massaging of non-program files that get loaded.)

Note that although most loads are for programs, there are several exceptions, e.g. COMMON modules, INIX modules, message files, and anything loaded with MX_USRLOD, etc.

So I think it is going to require a change of some kind to A-Shell, along with a decision of what specifically to allow. One option would be to add a few more special extensions to the list recognized as programs (RNX, SXX). That would be the easiest, but leaves the door open to forgetting this detail and encountering it again later. Maybe an INI parameter like RUNEXT=RUN,LIT,RNX,SXX, would help make it more explicit

Another idea would be to define a special ersatz which would always be checked first when loading programs. (One problem here is how to know that the chosen ersatz isn't already in use somewhere.)

Or ...?

Well it seems I processed my caipirinhas faster than you... :p

... and decided to add an option to the miame.ini to define a list of additional file extensions that represent compiled run-able programs. For example:

RUNEXT=RNX

Currently the only effect of adding an extension to the list is that it can be loaded properly into memory and therefore executed with the RUN command. This should address the immediate problem (at least in Jorge's case).

The more general cases (XCALL, CHAIN, etc.), may require another round or two of cold drinks. Possible refinements include updating the program search logic to take into account the additional extensions. It may also be necessary segment the list into alternate RUN extensions and alternate SBX extensions.

ash65notes.txt
ash-6.5.1653.0-w32c-upd.zip

Good morning,

First, thank you for remember me about the Workspace in APN, I forgot to mention it on my previous reply, it's precious and, unbelievably, I forgot about it somewhere in the past.

And, also, thank you for the solution, it's exactly what I was about to suggest if I didn't lose my internet connection last night together with a back pain that move me to bed earlier.

I've updated and adjusted the MIAME.INI but I'm still getting the out of memory error.
I've copied the setting from this post so, no chance for a typo error, does it need to be positioned in any specific position of the MIAME.INI or it's just the normal case when a change is so easy that you didn't even test it and failed the obvious basic?

Thank you very much

Maybe all these caipirinhas aren't so good for us - I've been crawling around the house with a bad back too!

But releasing a fix without testing???

Ok, I'll admit I might have done that once or twice for a truly trivial fix, but this one was complicated enough to require testing, which it definitely got. Although perhaps not enough...

Here's my test scenario. I used the program ADDSVUE[908,81] (introduced at the Conference), but probably any program of a reasonable size will work.

Using a version prior to 6.5.1653, or without the RUNEXT=RNX in the miame.ini ...

With 6.5.1653.0+, and with RUNEXT=RNX in the miame.ini ...

It shouldn't make any difference where the RUNEXT=RNX statement is in the miame.ini (except not above the SERIAL line), and I've tried it with additional extensions in the list, e.g.

And both work. I've also tried re-extracting the ashw32.exe from the zip, and it is the same.

So it isn't clear to me what the discrepancy is, but could it have something to do with the way you're laying on your back while having Violeta do the typing and reading the responses back to you? :rolleyes:

(Note that the extensions are limited to 3 characters, so XRUN or RUNX probably won't work.)

So, only one caipirinha prepared before this test and I'm still drinking it.

this is the content on the ashlog.log

14-Jan-19 19:43:21 [ACERUZ:02-2] Out of memory while loading C:\USERS\JT\ONEDRIVE\DESENVOLVIMENTO\SOFT\DSK0\007006\MAIN.RNX, avail=51111584, need=-1512046587


Should I keep drinking?

Yes! (In the hopes it will buy me some time trying to figure out what is going on here.)

I think I'm going to have to add a special trace to dig deeper into this.

But in the meantime, if you could get your assistant to email me a copy of your MAIN.RNX file, maybe that will provide some insight (beyond what I was able to get from the the Cachaça.)

Ok, you can stop drinking now - I found the problem. It was a safety test to make sure that the RUNEXT= line didn't overrun the space allocated for the stored list. The idea was good, but the execution was poor. (I was comparing against the wrong value, causing the comparison to either succeed or fail based on the physical relationship between two unrelated buffers. So about half of the time it worked as advertised, and the rest of the time it didn't. I guess you could say I got it half right. :rolleyes: )

Anyway have your assistant try this version...

ash65notes.txt
ash-6.5.1653.1-w32c-upd.zip

Thank you very much Jack, it's in place, working as expected and already helping me to control running changes.

I don't know if it's humanly possible, but in theory you should now be even more productive than before!

So Frank: does this minor refinement work for you?

Hint: It would only really work if you were able to test your beta program by running them from the dot prompt, where you could specify the RNX extension, or had a mechanism like Jorge's where the complete program name and extension was a parameter to some kind of generic launcher.

Otherwise, you want to be able to drop a beta RNX file into a directory with a bunch of fully testing RUN files, we would need to implement a means of having A-Shell detect the presence of the RNX and load it in preference to the RUN.

Or, maybe the other way around is better for testing at a customer site: rename the original RUN to SAV or something like that, and then drop in your RNX. A-Shell, when failing to find the RUN file, could then trigger the alternate search. (That would avoid the need to always look for alternate files on every program load.)

Thanks for all the effort here, though i still couldn't find my Caipirinha! (in all honesty I had to look it up but seems like a good programming companion!)

Not to muddle the discussion any further, (see, got that from the recipe), we do keep older versions of the program on the customer site renamed to the edit number, i.e. post.500. We send the new run for beta testing. I can see some possible usage here, but will have to wait until we move to 6.5...

Just to reinforce that, at least for me and my development platform, this is absolutely precious because:

1. compiling to RNX prevents RUN files to be produced with beta code
REMARK: it depends on me to add that pragma before any change but, believe me, the benefit is so huge that I'm impelled to do it naturally and, once I've defined it in the APN text clips adding three comment lines after the pragma statement, it's even easier.

2. I've adjusted my menu to visually inform me about all running BETA programs, and it updates dynamically according the existing RNX found while loading the menu, take a look ...
All the red-light lines with the **BETA** label will run the RNX file and it's a duplicate of the previous line that will run the RUN file.
I can also delete the RNX file from the menu using the context menu once I finish the beta test and decide to publish the program.

I'm very happy with this little tweak

Ooops! :rolleyes:

I forgot the programs/sbx called from the inside of other programs :p

My preference would be to:
Once defined RUNEXT=RNX,XSB in MIAME.INI those extensions should have precedence over RUN and SBX files respectively when the extension is not specified on the RUN/XCALL statements.

But I don't want to convert this in a "project" neither introduce complexity that can compromise performance in A-Shell so, Jack, if you decide to not go deeper on this, I'll be fine to assume that BETA modules must be called directly or follow any directive you accept to implement.

I'm still very happy to have this.

I figured that at some point we were going to need to tinker with the preferences on the file searching/loading, so this isn't actually a shock.

But while it made sense to allow for several extensions in the RUNEXT list (easy for the program loader to check the file being loaded against a list of several extensions), I'm not sure it makes as much sense to have to search the directory for every possible alternate extension every time we run a program or load a subroutine. Nor does it make sense to combine the RNX and XSB in the same category if it's going to determine the search path, since either we might end up XCALLing a RNX by accident, or we have to depend on A-Shell guessing that "RNX" is an alternate RUN extension, while "XSB" is an alternate subroutine extension. (Although I suppose we could resolve that confusion by just declaring that the RUNEXT list can have only 2 entries: one alternate for RUN and one alternate for SBX. But in that case we should probably rename it to RUNSBXEXT=. Alternately, we need a RUNEXT= and a SBXEXT=.)

One other detail I should note: the XCALL statement does not allow for an explicit extension - it will generate a compiler error. However, VXCALL does allow extensions. So, if you used VXCALL instead of XCALL, and had some centralized table for subroutines like you do for programs, where you could specify the extension, then the exiting RUNEXT feature would be sufficient.

But I suspect that in general, what would be required is an enhancement to the search logic for programs and subroutines which would allow you to tell it to look for XSB in preference to SBX, and RNX in preference to RUN, etc.

It seems a bit out-of-proportion though to add such a feature without at the same time addressing the possibility of a more generalized search path, i.e. changing the file locations, not just the extensions. Then again, maybe those are two completely separate birds that just happen to nest in the same "search" tree?

Give a Jorge a cookie... :rolleyes: :p

Hi,

Again, apologize for the overhead on this.

I like the idea to separate RUN and SBX definitions so RUNEXT= would be the alternate extension for RUN files and SBXEXT= for SBX files.
I'm using single in the sentence above because I don't see any valid reason to have more than one alternative but, if so, a possible option would be to allow more than one entry for RUNEXT= and SBXEXT= in MIAME.INI?

Regarding the possibility to add alternative locations for the alternative extensions, I'm not seeing it useful in my case but, one possibility could be something like this:
RUNEXTPATH=RNX,BETA:
SBXEXTPATH=XSB,DSV:[700,0]

In the above examples, the BETA: and the DSV:[700,0] should be added to the end of the standard search sequence.

Just one remark, my preference would be for RNX and XSB taking precedence over RUN and SBX respectively if the RUN/SBX exists, not only if those are not present.

Thank you very much.

One thing to consider is that not every ashell environment has a single customer. In some cases we have 100 databases inside a single PPn. Database 1 lives in [50,1], 2 lives in [50,2], etc.

When we send a beta program to a customer, we need to send it to the actual ppn of the customer, or the entire environment sees the version. We could not use any semantics that would override the entire system to a beta area. Not saying it couldn't be of some use for other vendors, just not in our environment.

To reiterate, we would sent the beta version of the run and even sbx to the specific ppn so it would only be seen by that customer. It would already override the current amos system of hierarchy since the live programs reside in BAS:

This addresses the complication that I was about to address separately, which is that given a search path containing multiple directories (e.g, for [p,pn] then BAS:, or [p,pn], [p,0], then BAS: ), which takes precedence, the directory search or the extension search?

Obviously, from Frank's perspective it would need to search for each extension in each directory before moving on to the next directory in the search. I suppose it would be possible that from some other perspective, it would make more sense to search all of the directories for the primary extension before repeating that search for the beta extension. But supporting both options would significantly complicate the logic, and Frank's preference (search for all extensions in the current directory before moving on to the next directory) would almost certainly be more efficient.

With that in mind, the idea of further complicating it by adding another search directory is less enticing than it might have otherwise been. (And note that we already have the -mntsys mechanism allowing you to add another layer to the search, so perhaps that can take the urgency off of needing further customization of the search path?)

Agreed. Not taking other options off the table that you and Jorge were considering, it certainly makes sense that whatever path search is in use it follows the normal amos/ashell directive. In other words, follow the normal ashell path structure by default unless some sort of override is provided that will look in a specific beta repository (Jorge's prefererence?)

There's certainly no argument there. I was just pointing out that if one was going to load RNX files in preference to RUN, there are still two ways to go about it:

1) Scan the search path ([P,PN], [P,0], etc) to see if there are any RNX files anywhere in the path. If none, then repeat the search for RUN files.

or

2) For each directory in the search path, search first for RNX, and if not found, then RUN, before proceeding to the next directory in the search path.

Contrary to what I suggested in my previous post, either approach would work for you if you put the RNX in the [p,pn] directory. But I think the 2nd approach is preferable, because in the standard case (no RNX files anywhere), the search is more likely to terminate sooner (unless all of your RUN files are in the last directory searched, i.e. the BAS: directory, in which case the amount of searching will be the same for either method.)

Muddling though all of the above, here's my new proposal:

1. Rename the existing RUNEXT= option to COMPRGEXT= (for compiled program extension), but otherwise leave the functionality the same. The option only serves to identify filetypes by extension to the loader that should be treated as compiled programs; it does not have any effect on searching.

2. Add two new miame.ini options: ALTRUNEXT= and ALTSBXEXT=, each of which allows a single alternate extension to be registered for RUN programs and XCALL routines, respectively. Specifying an extension in this way automatically adds it to the internal COMPRGEXT list (along with RUN, SBX, and LIT), so you probably wouldn't explicitly use COMPRGEXT, but the structure would still be used internally.

The RUN and XCALL search paths would be altered as described under point (2) at the top of this message, i.e. for each directory searched, we first look for the alternate extension (if defined), and if not found, then the standard extension. Note that the rule also applies to modules loaded into user memory.

This would double the number of program lookups, but only when the alternate extensions were defined. But probably the overhead will be insignificant. Note that the one case where you might have thousands of repetitive lookups would be for XCALLs, but in that case, they would normally be cached in user memory. (As an aside, note that the XCALL operation does check if the version on disk is more current than the one in memory, but no more frequently than once per 15 seconds. But the check/comparison would be further complicated by the fact that we could have the SBX loaded, but in the last 15 seconds, an XBS has appeared in the directory, or the XBS was loaded but has now disappeared from the disk.)

Hi,
I'm happy with the adoption of 2) on the searching logic and agree on the naming change to ALTRUNEXT and ALTSBXEXT but must confess that didn't got the need for COMPRGEXT.
For what I understood it should have the full list of alternate extensions defined individually in all ALTRUNEXT and ALTSBXEXT but it's not mandatory, is this correct?

Just one remark, if the extension is explicit in the run command, like RUN test.RUN or RUN test.RNX, in my opinion, the search on the folders sequence should be exclusive to the declared extension.
This doesn't apply to SBX once we can't specify extensions in the XCALL statements.

Working backwards:

a) Right. If you specify an explicit extension (RUN TEST.RNX) then the search is limited to that extension.

b) Partially right. (Explicit extension not possible with XCALL, but is possible with VXCALL.)

c) In 99% of the cases, there will be no need for an explicit COMPRGEXT statement, since it will be assembled automatically from the built-in default (RUN,SBX,LIT) and the ALTRUNEXT/ALTSBXEXT statements.

So maybe I should just eliminate it from the documentation? The only reason for keeping it would be for the hypothetical case where you wanted to create a set of programs, perhaps archived historical copies, with some non-standard extensions (e.g. R65 for version 6.5, etc.), but you didn't ever want them included in the runtime search. Adding COMPRGEXT=R65 in this case would allow you to RUN FOO.R65 for ad-hoc testing.

One other detail on the ALTSBXEXT which is obscure but needs to be noted. In order for the feature that automatically detects when the version of an SBX on disk is newer than the one in memory to work with the alternate SBX extension, the routine has to be loaded into memory from the standard search path. The only case where that might not always be true would be if you used an explicit LOAD statement to load the routine from some nonstandard location. For example, assuming you have ALTSBXEXT=SXX, consider:

If TESTFOO does an XCALL FOO, the subroutine search routine will find FOO.SXX in user memory. But, in order to determine if it has been superseded by an updated version on disk, the search will try to locate the disk copy to compare them. But since we loaded FOO.SXX from some non-standard location, it won't be found. That will result in deciding that the SXX is no longer valid, and the search will start over looking for FOO.SBX.

That would be an unusual case, and the need for such a technique (sometimes used for testing purposes) perhaps goes away with the new ALTSBXEXT capability.

A more typical scenario, where this behavior is exactly what you want, would be if you put the beta FOO.SXX out on disk, and then later decided that you don't like that version and want to revert to the standard FOO.SBX. So you delete FOO.SXX from disk. But without this feature that automatically verifies that the version in memory is the latest, some users might continue running with the beta version in memory, which would be bad.

Note that this memory-vs-disk checking doesn't happen any more frequently than once per 15 seconds, so while it's pretty quick to notice changes, it doesn't create much overhead for routines that are called thousands of times in sequence.

One other point about performance: defining an ALTSBXEXT is definitely going to increase the overhead of XCALL statements, due to the need for the addition directory lookups. (The same is true for ALTRUNEXT, but it's less of a concern since you would never execute hundreds of RUN statements per second, whereas you might execute hundreds of XCALLs per second.) The automatic caching of XCALLs in memory does a good job of minimizing the disk overhead on each XCALL, but only for XCALLs that have been recently called. In that case, it will be cached in user memory, and the search will find it there before looking in the disk directory. And as long as 15 seconds haven't elapsed since the last call to that routine, it won't need to do any further checking on disk. So overall, I don't expect it to be very noticeable, although I haven't yet tried quantify it empirically. My main point as that unless you're actually intending to use the feature, I wouldn't activate it.

All clear now, in particular the value of COMPRGEXT so, keep it and documented

Thanks

Ok, here's a new beta version to test...

ash65notes.txt
ash-6.5.1654.0-w32c-upd.zip

(Note, it would have been appropriate to release this with the alternate executable extension, i.e. ashw32.exx, but unfortunately Windows hasn't yet caught up with the latest A-Shell technology. :rolleyes: )

Just give them a few more time to confirm that we have a final release and you'll see their first announcements about a fantastic option to release in 2020.
Remember that you have launched since the beginning the 4 characters extension on companies naming with Micros.abio while they still stand on 3 with Micros.oft :p

On my first test, regarding the RUN/CALL I think everything is working like planned but there are two things to review regarding SBX:
1. To compile with a different extension I have to add the ++pragma force_ext "XBX" and remove the ++pragma sbx.
I'm fine if it must be that way.
2. REMARK: I think this is exactly what you explained that will happen but I have to read again your topic (after change diapers) anyway here is the point:
When I delete the XBX from disk it doesn't load the corresponding SBX.
Anyway this is not a big problem because when I delete the XBX that means the test finished and it would be normal to enter with a fresh A-Shell session.

Many thanks Jack, at least for me, this will be of great help.

On point 1, it might be nice if there was a pragma or switch to declare that you were creating a beta version, which, if an ALT???EXT was defined corresponding to the program being compiled, would result in the compiled extension using the alternate rather than the standard extension. (i.e. RUN -> ALTRUNEXT, SBX -> ALTSBXEXT)

But, that's a little bit convoluted and seems like an invitation to further confusion. Maybe if it was simply ++pragma beta, that would be more clear, but although you are thinking of this feature in terms of beta updates, I deliberately used ALT???EXT= rather than BETA???EXT= to allow for it to be used in a different way, i.e. where calling it 'beta' might itself add to the confusion. So I'm not thrilled with ++pragma beta.

Another way to look at it is that ++pragma sbx is really unnecessary/redundant, since there is nothing special about an SBX that the compiler needs to know about or do anything about. The only difference between an SBX and a RUN is the extension, the way you call it, and the fact that an SBX can retrieve parameters using XGETARG{S}.

So, maybe it would be cleaner for you to just eliminate your usage of ++pragma sbx and always use ++pragma force_ext "sbx" instead. In that case, at least the process would be the same for both RUN and SBX modules.

As for point 2, I'm not sure we are on the same page. My intent was that if you delete the XBX from disk, the next XCALL should load the SBX instead (unless fewer than 15 seconds have passed since the prior XCALL).

Here's my simple test (I used SXX for the alternate extension):

The TSTSBX routine displays its name and version and argument, so the above shows that it loaded the alternate SXX version as expected. Now I'll delete the SXX from disk and repeat the test:

The MAP command shows that deleting the TSTSBX.SXX from disk did not automatically delete it from memory. But when I ran the test program, it called the regular TSTSBX.SBX version because it couldn't find the SXX on disk. And then 2nd MAP command confirms that now we have the SBX in memory.

However, if I had been a little quicker on the keyboard, it might have used the alternate SXX version that was still in user memory, due to the performance safeguard that limits the cross-checking of memory-vs-disk to every 15 seconds. But the objective is that removing the alternate/beta versions from disk should result in any cached copies of them being removed within 15 seconds.