After some experimentation, I managed to get a URL similar to the one you show (starting with "?response_type=..."), which isn't a valid URL. It should look more like this (i.e. starting with "https://...") ...
.

I'm not sure yet why the bad URL response isn't accompanied by a status code; apparently the back end is taking a "you asked for it, you got it" approach.

In my case, I was playing with the GMAIL authentication and the OAUTH2.BP sample program. The issue (for me) came down to the fact that my client credentials did not include the necessary name:value pairs that the sample program was looking to extract from the json file. (The issue was that the Google API console had changed the names used in their json file.) But ultimately it's a matter of making sure you actually have values for all of the OAUTH2 parameters required for that API (client id, secret, port, authorization endpoint, token endpoint, challenge and scope).

That's probably not enough to solve your issue, but hopefully helps you focus on adjusting those parameters until you get a URL response that looks like an actual URL. But if that's not getting you anywhere, feel free to send me the details needed so I can try to access the API from here.

Hi,

I'm trying to autjenticate to Microsoft Power Platform in A-Shell using SOSLIB[908,77]OAUTH and would appreciate advice for the settings to use and where.
I've connected to this platform using POSTMAN so, I believe it's just a matter of put the right values on the right places to achieve the same here.
The settings to get the token in Postman are those in the image and I found correspondences in clients.jso for "client_id" and "auth_endpoint" settings but didn't found an option to "NOT authorize using browser".
Running OAUTH seems to connect fine but asks to open the browser to confirm but nothing happens.

Any tip?

PS: If necessary, I can provide my clientID and all other settings to test

Thanks in advance

Oh well. I thought maybe I was in line for a kickback, or perhaps some kind of bidirectional pop-up ad promotion? (It's easy to imagine A-Shell developers starting at our HH topic in the AshRef and clicking on the HH Madeira pop-up ad; it might be a bit more challenging to lure wine shoppers over to XTREE. But they'll be glad they did!)

No, no marketing rep, I just knew already the HH Madeira wine and found the HH-Estates while searching the link to put here as a joke by analogy to the new HH cformat option :-)

Thanks for the tip. But are you by any chance moonlighting as an HH marketing rep?

Just wonderful, easy and with a very nice result.
After such an easy and elegant solution, you should go find a complex HH Madeira wine to enjoy the success or, if you prefer something local you can try HH-Estates

Thank you very much

I haven't had to resort to that (yet), but here's a first pass at it:

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

As you'll see from the notes, I went with HH as it somehow seemed cleaner to me as I was looking at the code.

Note that unlike Advance Coldef Options, the cformat codes cannot be defaulted (at least not currently) using column 0, so you'd have to add the HH code to potentially every column.

Now maybe I'll go for that Red...

Excelent!
And maybe a glass of good Red will help...later

I like it. In fact I can think of a program I use a lot (the generic file viewer ADDSVUE) where this might be a very nice option, since a lot of files have a lot of unused fields which just clutter up the grid with unnecessary columns.

But it's early on Monday and I'm not yet stressed enough to need the relaxation, so I'll work on it later...

Hi,

Here is a soft one, just to relax

Sometimes there are columns in the XTREE to display complementary data that exists only in a few rows but most of the times those columns are empty.
When those columns are positioned to the right, fine, I just leave them there but, even though, sometimes those columns trigger unnecessary horizontal scroll bars.
When these columns bother, I use an hide'col_X$="H" which is cleared while loading the array on the first non-empty value for the column.

Would it be reasonable to consider a cformat "He" to hide empty columns?
Where empty could be all rows "" for string columns and all rows 0 for numeric columns.

Thanks

Here's a beta release of the update that fixes this problem:

ash-7.0.1757.5-el7-upd.tz
ash70notes.txt

And although it's not related to the compiler issue and not specific to this version, this update of the ashnet library is recommended:

libashnet.so.1.14.194-el7.tz

For what it's worth, along with the fix for the ++IFDEF <structname> issue (discussed here), I've added the following stats to the end of the LSX file in the hopes of perhaps making it easier to identify compiler performance issues, or at least quantify them. (This is from your prccstdsp program compiled under Windows) ...

As the asterisked note indicates, unfortunately, measuring the time used in routines that take almost no time per call, but which get called tens of thousands of times, potentially adding up to real time, is not very reliable when the time for a single call isn't significantly longer than the clock resolution. The Windows CPU clocks use 100-nanosecond units, but it's not clear whether the actual resolution is that fine, or whether, for example, each search for a structure name in the structure definition index takes significantly less than that, thus making it look like the 15041 searches took no time at all. Also, the total CPU time for the 4 search routines itemized is very close to the total CPU time for the entire compilation, which is ridiculous, because there's a lot of other code in the compilation that wasn't being separately itemized. So that strongly implies that whether or not a routine gets properly measured is a bit like Russian Roulette (either it gets off for free because the clock didn't change, or it gets hit with a big charge, most of which should have gone against prior routines.

Another detail which stands out is that the initial pre-scan (Phase 0) actually took longer than the main compilation (Phase 1), which surprised me. Partly that may be because the pre-scan had to look at 3 times as many routines as the main scan. And partly it may be because the pre-scan is having to build these various index trees, offloading some of the work from the main scan (which mostly then was doing a lot of searches of those trees). Or maybe there is some inefficiency there which needs to be squeezed out. But here we can't blame the clock resolution because it's measuring once at the start and once at the end of each phase (which are plenty long enough to make the clock resolution a non issue).

Another surprising result is that the total elapsed time is so much more than the CPU time. That suggests that the OS devoted almost 2/3 of its time to other background processes. (Not entirely out of the question, especially with Windows, but still a bit surprising.)

Anyway, I'll probably post the update later tonight or tomorrow, but now that you have your workaround, and considering how apparently rare it is for the original problem to actually be triggered, it's not clear there's any urgency.

I forgot about the /IGOO switch. I was hoping for an easy performance win. Compilation for PRCCTDSP program recently went from 8-9 seconds to 20+. We thought it was related to moving to a 64-bit A-Shell, but it is still that slow back on 6.5. Must have been a change we made.

Problem for another day I suppose. Thanks for the through response.

You got that right -- I'm not sure I would ever have figured it out otherwise!

Interesting question. Actually pair of questions. On the first one, there's no known limit on the use of ++include'once. But since you're compiling with the /igoo (Include Global Only Once) switch, you're effectively already using ++include'once everywhere. So I don't think removing your ++IFNDEF statements bracketing each include will make any difference.

As an aside, I've settled on the pattern of always using ++include'once (in fact, it's an APN shortcut triggered by "inc"), but I still add the ++IFNDEF directives inside most include files anyway -- partly out of habit, but also on the theory that it provides additional flexibility. For example, in cases where I may want to test multiple versions of a function, I can use the /C:symbol=value compiler switch to explicitly DEFINE the symbol associated with a the relevant include file to prevent it from being processed even once.

But setting all of that to the side to address the second question about how much overhead there is in scanning a file during the first compiler pass (necessary to process the conditional directives), it's definitely "something", but probably not "a lot". I'm guessing that on average, the first pass is about 3-4 times faster than the second pass, since it only needs to pay attention to ++ directives, DEFINES, function/procedure declarations and calls, and now perhaps DEFSTRUCTs. And it doesn't actually have to 'compile' any of it. It's mainly just building the matrix of called functions so that we shake out those that aren't called, and can know in advance the named parameters for those that are. But perhaps I should add some timing statistics to the compiler output to actually measure that.

While on the subject of minor refinements/optimizations, I noticed that you tend to use LOOKUP as a way to conditionally include a file depending on whether it exists, e.g.

There's nothing wrong with that, and doesn't add more than a few extra picoseconds of overhead to parse the statement, but just from a syntax simplification perspective, my preference would be for:

or

It just seems a little cleaner.

About 15 years ago we were using ++include'once, but the nested limit kept being us. To remove that as an issue we stopped all use of ++include'once, and now use ++IFDEF inside the includes. I think this is causing unnecessary slowness in the compiler because it must scan every file regardless of it already being included.

I think the ++include'once nest limit no longer exists, is this correct? If so, I'll be interested to see how much faster we can compile wtth ++include'once.

Does anyone have any experience with the difference?

That's an interesting issue. Couldn't have found that without the code I imagine.

I've modified the ++IFDEF to use a DEFINE, and it's compiling now.

I've identified the problem, but haven't yet decided on the solution. It came into being when ++IFDEF was enhanced to treat DEFSTRUCTs like DEFINEd symbols. But while DEFINEs are processed during the initial compiler pass, DEFSTRUCTs are not. Unlike DEFINEs which can easily be cleared at the start of the second pass, or not (since they don't take up any space in the RUN), DEFSTRUCTs are a lot more complex and lead to variables being defined, which do take up space in the RUN. So we don't want to handle them until we're sure which functions are actually going to be included in the RUN, which we don't know until we shake out all the uncalled functions at the end of the first pass.

In your case, the function that was causing the undefined function error was only being called by another function that was dependent on an ++IFDEF INVPRCHIST_CMDHDR where INVPRCHIST_CMDHDR was a DEFSTRUCT. Because the DEFSTRUCT wasn't processed in the first phase, the function calling the one in question wasn't included, causing both the called function and the caller to be shaken out. But in the second pass, the caller got included because the DEFSTRUCT by then had been processed, leaving the call to the missing function, but not the missing function; hence the compiler error. The error doesn't show up in the LSX, because it gets created during the second pass, and because even for functions that are shaken out, the function definition still appears in the LSX. So the LSX compilation completes without error. (The RUN still would be missing the body of the function in question, but in another coincidence, that function was empty of any code anyway, since all of its contents were dependent on ++IF clauses that weren't triggered.)

You could work around the issue by replacing your ++IFDEF <defstruct name> with ++IFDEF <symbol> and add the DEFINE <symbol> next to the DEFSTRUCT. It wouldn't be that easy to find all the potential occurrences of the problem since your DEFSTRUCT names don't look any different than other symbol names. (This is one reason why I prefer to use a common prefix like ST_ in front of DEFSTRUCT names, making them easily distinguishable from other symbols.) On the other hand, it takes a lot of parts to line up in order for the problem to surface, so maybe this one routine is all you need to manually adjust to take the pressure off updating.

In any case, I expect to work out a solution within the next 24 hours or so.

Ok, I got it all set up and am able to reproduce the error here. Now the fun begins. But first, lunch!

OK, that is great. Thank you Jack

No rush on my part. But I'm also willing to pull the code over myself to save you the trouble. It looks like there's about a dozen unique include directories and I could just wildcard transfer them to a VM here.

I can get you a copy of the code. Going to be after lunch.

I thought I had simulated that operation but apparently didn't do it right. I would like to get back on again, although I'm not yet sure what my plan of attack is going to be. Given that there is no obvious connection between the code that gets commented out and the actual error, and the enormous size of the program (over 2000 ++includes, 380+ of which are unique, 11000+ individual functions...) I definitely need a strategy! Either some kind of customized traces (which will probably involve many cycles of uploading test versions of the compiler), or maybe come up with a way to copy the entire source tree over to my environment where I can more easily work with it.

I was saying that commenting those three lines in our code (not the LSX) allows the program to compile. There is a conditional feature that is enabled if that file is included; which, is needed for one customer, but not another.

I shutdown ngrok on the computer you connected to yesterday. Let me know if you need access again.

I found another FTP2 bug related to the XFTPF_RENAME, XFTPF_DEL and XFTPF_RMVEXT opcodes; the fix is in 1757.4 ...

ash-7.0.1757.4-el7-upd.tz
ash70notes.txt