Contribute
Register

Native DSDT/AML IDE & Compiler: MaciASL Open Beta

Status
Not open for further replies.
Your changes _for_new_versions_of_MaciASL_, yes. The reason for bundling the binaries was users could swap them out themselves whenever they wanted, in fact some continue to do this. So long as newer versions of iasl use my suggestion, they will continue to work in _any_ MaciASL, this is the point.
 
SJ_UnderWater said:
Your changes _for_new_versions_of_MaciASL_, yes. The reason for bundling the binaries was users could swap them out themselves whenever they wanted, in fact some continue to do this. So long as newer versions of iasl use my suggestion, they will continue to work in _any_ MaciASL, this is the point.
Click to expand...

Thanks. I'm not concerned with older versions of MaciASL (they would already have a patched iasl present). Looking forward not back...
 
Part of releasing an app is making sure all users are ok, you can't just abandon them. Maybe you're not concerned, but I have to be. If someone still using an older version (for whatever reason) used the updater then they would lose the compiler Summary if the iasl wasn't corrected, that's important.
 
SJ_UnderWater said:
Part of releasing an app is making sure all users are ok, you can't just abandon them. Maybe you're not concerned, but I have to be. If someone still using an older version (for whatever reason) used the updater then they would lose the compiler Summary if the iasl wasn't corrected, that's important.
Click to expand...

Yes, this is why you must continue to publish a patched iasl at the location where MaciASL downloads updates.

But certainly, the code could be changed as I have outlined to allow a user to replace the iasl5 in Contents/MacOS with one they've built themselves from official Intel sources (or a fork of the same) without the patch present.

Either way, I've already changed it in my version, and with the information you provided here it is "mystery solved." Let's move on.

Thanks again!
 
The problem with handling both is becoming overly reliant on the regular expression to filter out the necessary lines. The previous versions which sent different messages to stderr and stdout maintained this separation clearly, and make less of it into guesswork. String parsing is never an exact science, and combining two streams of different information (which were once separate) makes it that much harder. It's no longer explicit and the iASL functions could fail in unpredictable ways later on.
I post how I build iasl in the wiki, and that fulfills my obligation to users who go their own way.
 
SJ_UnderWater said:
The problem with handling both is becoming overly reliant on the regular expression to filter out the necessary lines. The previous versions which sent different messages to stderr and stdout maintained this separation clearly, and make less of it into guesswork. String parsing is never an exact science, and combining two streams of different information (which were once separate) makes it that much harder. It's no longer explicit and the iASL functions could fail in unpredictable ways later on.
I post how I build iasl in the wiki, and that fulfills my obligation to users who go their own way.
Click to expand...

I believe the design of the -vi option (created for use with Visual Studio or other IDEs) is done in such a way that only single line error/warning/etc output goes to stdout. It isn't "mixed" with anything else. I suppose it is possible for there to be a bug in the code which doesn't respect the intended design, where some unintended output could go to stdout that could confuse MaciASL regex based parser. But the same could be true of output going exclusively to stderr (in the case of patched iasl). So far, I haven't seen any issues... In fact, in the case of patched iasl (-vi), I find that stdout is always empty.
 
you're still talking about _less_ information than it had before. Up until now the output was split and it seemed to be fine for IDE integration, it's been three years since "iasl4" was released. But the larger point is _any_ previous behavior could change and would have to be fixed for MaciASL; the problem with incorporating outside projects is that they may change at any time, and historical compatibility means not having a good way of breaking with previous versions of the product. The old stderr output is fully characterized, there is no chance of a false negative/positive.
Even if I added this change (which I won't), there would never be a point at which it would be safe to transition to the newer output form. I've made my objections clear in this case, that though it's not strictly exclusive, that it makes the app less explicit and safe overall. Changes may/will come later which are exclusive and will require source fixes, and that is how development will go. Only at the point of a "new" iasl, like iasl51 or iasl6, etc would it be "safe" to characterize new behavior.
It is the responsibility of users who compile their own copy to determine what the app's requirements are, and they're publicly available.
 
SJ_UnderWater said:
you're still talking about _less_ information than it had before. Up until now the output was split and it seemed to be fine for IDE integration, it's been three years since "iasl4" was released. But the larger point is _any_ previous behavior could change and would have to be fixed for MaciASL; the problem with incorporating outside projects is that they may change at any time, and historical compatibility means not having a good way of breaking with previous versions of the product. The old stderr output is fully characterized, there is no chance of a false negative/positive.
Even if I added this change (which I won't), there would never be a point at which it would be safe to transition to the newer output form. I've made my objections clear in this case, that though it's not strictly exclusive, that it makes the app less explicit and safe overall. Changes may/will come later which are exclusive and will require source fixes, and that is how development will go. Only at the point of a "new" iasl, like iasl51 or iasl6, etc would it be "safe" to characterize new behavior.
It is the responsibility of users who compile their own copy to determine what the app's requirements are, and they're publicly available.
Click to expand...

We agree to disagree. Not surprising... Thanks for the input.
 
GPUs don't have DSDTs
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top