Hi Jack,

As Frank suggested, the change of the channel number was one of the first attempts we tried.

I confirm that we changed the SUBMIT to another command and it didn't work.

We'll give it a try using a different server and the program you attached.

We're running A-Shell 7.0.1760.0 under Red Hat Enterprise Linux Release 9.4 (Plow)

Thank you very much and best regards.

That seems like the logical explanation. I just can't see how commenting out the XCALL SUBMIT would affect it, given that it is executing an external command, in another process, unrelated to A-Shell. Surely the external command cannot be stepping on an A-Shell file channel. Possibly the XCALL SUBMIT itself could be the culprit, but in that case, it should have shown up in my test program. I thought it might be that the input file (lisemp.dat) was somehow being referenced by one of the XCALL SUBMIT parameters, but I don't see any evidence of that in the ashlog FOPENS traces.

I had something similar happen and in my case something was stepping on the fcn (888 in this case) status. Just for fun have you changed the channel # you are using?

For what it's worth, I created a test program for this (using /usr/bin/md5sum rather than pdflatex). And I've been unable to reproduce the problem, at least with 7.0.1764.1-el9. I suggest you download it and try it on the target system to see whether the issue is specific to pdflatex (hard to believe!) or else is related to some other detail of the way you are XCALLing SUBMIT. You could easily modify the program to use your input file and execute pdflatex to see whether the problem relates to some other difference between our two programs.

Rename SUBEOFTST.TXT to .BAS, VUE it, save it, compile it and then RUN it (in any directory). It uses the files SUB*.* as inputs to md5sum executed through XCALL SUBMIT, generating a .OUT file for each one. (You'll have at least 3 to start with -- the RUN, BAS and BAK -- and if you want a more extensive test, just create some additional SUB*.* files by COPYing from other any files of any type.) It also allows you to switch the SBR=SUBMIT2 option on and off to see whether that affects the behavior.

That's truly mysterious! I don't see anything weird in the trace, and can't think of any connection between the SUBMIT operation (which isn't even invoking A-Shell) and the current input file pointer.

I may have to investigate it more thoroughly here. Can you please clarify the environment (A-Shell and OS version)?

As a workaround, here's a suggestion (shouldn't be necessary, but easy to implement): Make a call to MX_FLINES to count the lines in the file before you enter the loop, and then change the loop control to use FOR COUNT = 1 TO TOTLINES...

Here's the update which adds support for the mouse wheel synchronized scrolling...

ash-7.0.1765.5-w32c-upd.zip
ash70notes.txt

Hi Jack,

Attached you will find the screen with the requested output.

What I can see is that the loop starts again from the very beginning, i.e. the first record appears again. EOF(888) is always zero.

The other file is an excerpt from ashlog.log (temp.txt) with the requested traces activated.

Thank you in advance and best regards.

Yes, regarding the wheel, I forgot that it doesn't act as a front-end to the regular scroll messages that I trapped. I'll add a hook and post an update.

But as for SBXMSG, I'm not that familiar with it, although it appears to be a wrapper for AG_MESSAGEBOXSTD.

The source I have is dated in 2018 and has no version, so I'm not sure if it's current. I didn't see any obvious test programs but created this simple one which seems to work ok.

If you'd like, I'd be happy to modernize it to act as a wrapper to XCALL MSGBOX. That routine is a bit simpler in that it doesn't require a round-trip communication with between the application and UI sides of the client, as well as way more sophisticated with additional options, but perhaps most important, it gets a LOT of use, so any problems would become quickly apparent.

Hi Jack,
Apologize for my silence on this, too much pressure to implement other features more important than scroll two xtrees together.
Anyway, I've installed this new release and, undoubtly, the synch is much better.
I noticed that using the mouse wheel to scroll doesn't trigger the synch, I don't know if it's not possible or you just forgot that, but if you find it too much complicated, it's great the way it is now.

But while playing with this new release, maybe I've found the problem and it's not related with exiting the XTREE, in fact, not related to XTREE, something broke the call of my SBXMSG.
Today I was getting crazy trying to understand why "if a>1" was not working because a message should pop up using "xcall sbxmsg ....", but the problem was in the sbxmsg not working and, I guess, the problem previously described as "xtree hangs on exit" was precisely due to the SBXMSG problem that should be called on the xtree exit.
Can you check if sbxmsg.sbx is working on your side?

thank you very much

Strange...

From what I can see, you've got an input file with 34 lines, each containing information to be turned into a pdflatex command executed through SUBMIT. The loop looks something like this...

The IF EOF(888) never gets triggered. But if you comment out the XCALL SUBMIT, it works fine. Since the #888 file is not referenced by the SUBMIT command, it's hard to see what the connection is. To get more information, I would suggest adding another couple of lines after the IF EOF(888) ...

I'm not sure what you're going to see, but perhaps it will be a clue. One possibility is that you see the last line repeated over and over again. Or maybe the line is blank but the eof doesn't get triggered. Or ....?

Another debug which might help pin this down would be to use SET TRACE FOPENS ON and SET TRACE RW ON and SET TRACE XCALL ON prior to running your test, so we obtain a log of the open and input operations, and can see the actual XCALL SUBMIT parameters, in case something unexpected shows up.

Hi Jack,

Using SUBMIT makes the speed execution is much better, but something strange is happening:

We're using a loop to submit several files to pdflatex but the EOF of this file is never being detected.

If we comment out the submit statement, then the EOF is detected properly.

I'm sending to your email a couple of videos to show how 34 files are being sent to pdflatex through SUBMIT. We had to put a hard-coded counter to 50 to stop de loop, otherwise it enters in a never ending cycle. Commenting the SUBMIT stops when the EOF is detected.

If someone else is interested in the subject I can share the videos. Please let me know.

Thank you in advance and best regards.

After some further testing, I decided to recall the original implementation of this feature, as it wasn't working reliably. The replacement version, in 7.0.1765.3, seems to work much more reliably. And as an added bonus, works automatically in both directions. (The first scroll operation on the first tree will set up the second tree to forward its scroll operations back to the first tree.)

ash-7.0.1765.3-w32c-upd.zip
ash70notes.txt

Well, if it's obvious, I'm as blind as you are!

The one thing that makes sense is that the HOST version performs the same as your XCALL SYSTEM (which I'm assuming is an alias to XCALL HOSTEX), since that's exactly what HOST uses.

The one big difference between how bash executes the command, and how A-Shell HOSTEX does, is that bash uses the system commands fork() and exec(), whereas A-Shell uses the command system(), which acts as a convenience wrapper for fork() and exec(). It does add overhead (mainly for the setup, not for the execution) but there are apparently some subtle differences in the way the environment is shared that might have an effect on a command as complex as pdflatex. Normally that difference is virtually un-measurable.

As an example, I tried md5sum on a 1.5GB file (multiple times to eliminate cache differences) and the execution time was identical whether executed from bash or from A-Shell using HOST.

Since pdflatex is so complicated, with lots of sub-processes and intermediate files, maybe there is some operation that gets repeated in the midst of all that which is less efficient due to the slight difference in environment.

The one way to get A-Shell to use the fork() / exec() technique is with XCALL SUBMIT, which you could use instead of HOSTEX to see if it was faster. Your command would look something like:

Note that if the SBR=SUBMIT2 option is set in the miame.ini, this command should return immediately, so you would have to wait for the output to appear in the pdflatex.out file to measure how long it actually took to run. (Or maybe it doesn't matter, if the only goal is to get response back to your app as fast as possible.)

Hi Jack,

I attach to your email a file with three videos due to the 5MB limit (I think this number is pretty low for current standards!)

The one called "sga host command" shows the conversion to PDF from the A-Shell prompt using "host pdflatex [filename]".

The one called "sga system command" is the one used by xcall hostex.

You can easily see that although it is a single file, the process takes a long time.

The video called "linux terminal" is the execution from the Linux prompt of the same command: pdflatex [file name] and you can see that it executes much more quickly.

This same video includes the execution for many files and the process takes less time than executing just one by the other mechanisms.

Probably there is something obvious that I'm not seeing at the moment!

If anyone else is interested in the videos I can send them to your email. Please let me know.

Thank you in advance and best regards.

Hmmm.... that seems mysterious. Are you capturing the output (by passing the stdout parameter to HOSTEX)? If so, you might want to try removing it and just letting the output come to the screen, as the capture method is much more complex and may be somehow slowing it down. Otherwise, XCALL HOSTEX uses the standard Linux system() call, which is essentially what the bash shell uses to execute commands, so it's hard to see why it would run any slower.

Hi Stephen, I've email you a password its fine just using the email address refocus-much-uncle@duck.com and login HERE

Once logged in the menu is the round orange burger 'thing' in the top-left of the screen, once you selected a menu option you just click the grey individual panels to open them up for different data-grid/charts/graphs/stats etc etc etc

(Let me know if you dont receive it or any any questions etc etc etc )

Hello!

We have a case where we are using the Linux tool called LATEX to create PDF files locally.

This is something that has been used for years and they haven't had any details.

Currently the cliente is using a new server and what happens is that to process a group of files to convert to PDF, from the Linux prompt it takes a few seconds, while with XCALL HOSTEX it takes much longer.

Is there a reason for this change in execution speed?

Thanks in advance and greetings.

Looks Cool Steve!

Here's an email refocus-much-uncle@duck.com if you could give me demo access that would be great. I can send my primary email via email later if you need that for the demo.

I look forward to checking it out.

There was an issue where A-Shell was not checking for libashtls.so in the directory where the ashell executable was loaded from. This is resolve with 7.0.1765.1.

sure , why not

Very slick! (Now when you get some free time, can you add ATE functionality to it so we can run text and AUI applications on a phone?)

Actually here is another example im working on at the moment (Warehouse Stock Relocate) and closer to Jacks A-Shell CGI mode suggestion, Its a Web Portal written in Net/C#/Blazor but ALL its data is coming from our Ashell Linux Server (hosted in the Cloud) its just passing JSON data back and forth via an API/A-Shell CGI. (I think similar to what OmniLedger is doing)

Idea is a nice front end for the user using a web browser and all the back-end processing is STILL running the the good old very solid 1980s ashell stock adjustment code (well 1987 to be be precise) just the RUN program data comes from JSON rather than ATE and a keyboard.

Idea here being web based allows it to run on any device (with a web browser) and users can to walk around a large Warehouse picking and relocating stock, aim is for Android handhelds (with built in bar code scanners) - It keeps the Ashell clients we have out there seeing update development but still running ashell/Madics.

But the theory is much the same if you want to show a nice Chart, Graph or something where the Ashell program launches the browser passing all the data needed in a JSON.

My Test development is here Test Stock Locate and the PIN to login is 2324 and its talking to our Ashell Server for all the data and processing.
* Once logged in click the RELOCATE button
* Enter ZGILO for a BIN
* WHEELS for the item.
* Enter a Qty and click Pick
(The stock is now in your hand, well cart) to put it else where...
* Enter ABC123 for a BIN
* WHEELS for the item.
* Enter Qty you got and click LOCATE.

(Take me a while to get this screen layout to work well for a small Android screen, but works just as well for a Windows PC browser too)

Really a year has gone by already??

I think we here at Caliq have gone around in circles several times over god know how many years with different type of dashboards, charts, data integration etc etc.. from calling external charts from with in Ashell to just supplying meaningful SQL Tables for customers to use and do themselves in something like PowerBI...

As Jack says we end up with using the DevExpress components and writing an external Data Analytics web portal that we squirt data too (not via SQL but mostly simple CSV files) this also allowed us to open it up a bit to other systems like Sage, Microsoft Dynamics , Caliq, good old Madics/Ashell and other bespoke systems

John there at Diversified Data Solutions had a little play back at the conference.

We have gotten on well with the DevExpress stuff , nice Charts, Grids and at the moment im playing with the new C# Devexpress Blazor but it is all outside Ashell.

The portal is currently mostly aimed at Sales Analytics, seeing Company Orders, Invoices and helping Sales Rep gain business and leads.but have dozens of customers using it with great feed back.

Your welcome to explore it here at Toucan Sales Analytics just drop me an email for a login (if everyone uses the same it just get confused)

It fed by the following CSV Struture Here

I think both Steve and Matt were using DevExpress, although Steve had bundled his version along with support for other common back-end ERPs into a package they call Toucan. Your timing is interesting because I was just thinking about looking into this again yesterday. After the Conference I got distracted by other things and didn't really have a chance to investigate it. And now a year has gone by. But it's not clear that there's anything new needed on the A-Shell side. My understanding is that the client uses RESTful HTTP requests to communicate with the back end, so you could use the A-Shell CGI mode to service the requests. Everything else is essentially independent front-end development, mostly likely in Visual Studio.

Hi Jack,

I'm just following up on a topic the '23 conference. I can't recall the name of the chart package. Just curious if this has gained any research time, or thought on actual implementation.

TIA,
Stephen