Since the patch does not apply to MaciASL, it has been moved to
http://www.tonymacx86.com/mavericks...-7x37-clover-install-guide-26.html#post832916 Please keep this thread on-topic, that includes issues which only affect MaciASL as-shipped.
It was clearly directly related to the use of MaciASL with newer iasl, but whatever, this is your thread.
The development branch has been pushed, from work completed last weekend. Any new issues should be tracked against that branch, and reported here. development will eventually merge on to master as v1.4
I had issues with this version, in particular the isInjected code, which crashed when opening standalone files. I replaced it with:
Code:
+(NSString *)isInjected:(NSURL *)url {
//return [[self.tableset allKeysForObject:[NSData dataWithContentsOfURL:url]] objectAtIndex:0];
if (!self.tableset)
return nil;
NSArray* allkeys = [self.tableset allKeysForObject:[NSData dataWithContentsOfURL:url]];
if (!allkeys || ![allkeys count])
return nil;
return [allkeys objectAtIndex:0];
}
I'm sure the above can be "simplified" somewhat by taking advantage of the fact that you can send messages to nil, but I'm no Obj-C expert so I didn't attempt any such "optimization."
BTW, is there anything in particular you'd like testing to focus on with this new version in the 'development' branch?
If you're talking about your mention ~20 days ago, that's not what I mean, considering you were unaware of external resolution in MaciASL until I pointed it out, instead running iASL directly.
You said I never notified you of the deficiency with regard to external resolution with SSDTs. I was just pointing out that, in fact, I had notified you and therefore your characterization that I'm not reporting issues as discovered is incorrect.
I'm still running iasl directly and have no plans to start using MaciASL tablesets instead.
There is a huge gap developing whereby you're maintaining a diverging downstream product while not contributing upstream or notifying me proactively of issues, sending users my way without explanation.
There is no "huge gap." Look at a diffmerge of the projects and you'll see the differences are almost entirely a result of PATCHMATIC ifdef.
I do not feel it is my responsibility to report bugs to you that other users experience while using MaciASL. That responsibility falls squarely on them and becomes an issue between you and that user, including whether they provide adequate explanation of the problem.
When I report issues to you, I usually spend considerable time investigating and reducing the repro case. Evidently you do not appreciate this. I do not have the time to do that for every issue each user might discover. It is unreasonable for you to expect me to serve as conduit for all bugs discovered by users that I might come in contact with during the process of helping them.
If you're counseling users against my advice to use DSLs, generated with a version of iASL I don't ship (and therefore don't support, at least implicitly), on a downstream product (which I certainly don't support), but still apply my commits to your source, you have a responsibility to keep track of those changes. If you identify an issue which exists in MaciASL, then post it here.
Since MaciASL provides a file association for .DSL, it should be able to open and manipulate any DSL file regardless of how the file was generated. This includes new versions of iasl, as you can't be certain users of MaciASL are not using the tool in ways not according to your personal preferences/practices.
I regularly update my fork of the Intel iasl repo, as there are useful fixes there.
I noticed you didn't answer my question. Why is this happening, why are you re-patching a patched file?
Your question was not relevant to the issue being discussed. As I tried to explain, it is common to apply one patch during the development of a "patch set" for a given computer, only to discover additional patches to the same file are later required. It is for this reason that I use a "source code" strategy where such patches are applied only DSL files and built into AML for testing. This avoids later secondary disassembly, which as you know, is not reliable without the other files in the table set as reference.
If you're using a "source code" strategy, that strongly implies exactly what I was saying: the tableset and patches are the "source", the patched AML is the "binary".
Using the tableset requires all patches to be applied at once. This is cumbersome, time consuming, and error prone. It is why I use patchmatic and make to automate the process. I would never consider using MaciASL tablesets during the the development process.
Developers use IDEs, consumers use automated solutions.
I'm a developer. I use a combination of IDEs *and* automated solutions such as make or shell scripts. IDEs are not the best tools for all development tasks. I use the most appropriate tools to accomplish the given task. I suspect you do too.
MaciASL is a great tool but I don't find it adequate, by itself, for end-to-end development of complex ACPI patches and prefer to use a mix-n-match approach as it fits my needs.