Native DSDT/AML IDE & Compiler: MaciASL Open Beta

[philip_petev]

I have been asked before, but one of the major reasons for making MaciASL in the first place was to lower the DSDT-edit barriers for most users. The packagers/maintainers who would generate lots of DSDTs, or automate an opaque process should (in my opinion), focus on creating and maintaining patch repositories users can access with the app. Patches are not only more flexible regarding BIOS updates, but also let users see what is going on and allows easy modification. Using repositories makes it clear who is responsible for the patch, and roughly what each will do. The paternalism of an automated command line process keeps users ignorant of what is necessary to get their systems working. I would prefer it if hackintoshers needing heavily-edited DSDTs were at least aware of that fact.
As always, anyone can create a prepared-DSDT repository using the AppleScript bindings for batch-processing.

From the packager's point of view (my point of view in this case), such command line tool will allow all DSDT-related operations (mostly the extraction and patching, the disassembling and assembling can be handled by the iasl compiler, which is command line tool as well) to be made from a package, which will contain only the patches, this tool and the iasl compiler. The main reason I'm asking about such tool is this initiative. The idea is to be made a postinstall tool for all these board, containing all you need to run OS X (DSDT patching, SSDT generation, patched AppleHDA.kext and probably other kexts, Chimera and FakeSMC) on them. I know how to make the installer to assemble and disassemble the DSDT, but I don't know how to extract and patch the DSDT from the command line (yet).

 

[SJ_UnderWater]

this is exactly what I was talking about, but you didn't address my concerns. Just because something can be automated and packaged doesn't mean it should. What happens when the patch needs changing (because the BIOS, OSX, or best-practices have changed), or someone wants to know what will be / has already been done? Where is the documentation, the "open"ness? This is essentially a text-editing process made opaque and brittle (what happens when a patch fails, or a DSL doesn't compile; there is no user-interaction allowed in pkgs without Installer plugins) in the name of "ease".
Part of the genius of patches is how flexible they can be when done correctly compared to readymade DSDTs, and I would rather use something explicit, where I could see what was going on, and have some opportunity to learn. I don't think the answer here is more, specific Installer pkgs, storing important information in XAR silos. Granted I have an interest in seeing more repos created, but I wouldn't have spent so much time on that feature if I didn't think it was a good idea.
Of course the source is up on SourceForge now (and fairly well-factorized i think), so anyone could take the Patch classes and create their own Foundation binary.

 

[xsmile]

I would like to report that scrolling is quite an obstacle in the current build.
The syntax highlighting is applied to visible code regions only but when this happens, the whole app freezes for approximately one second.
I believe it went somehow smoother in earlier versions.

EDIT:
One more small thing: If the DefinitionBlock declaration is in the first line of the document, it loses its highlighting.

EDIT2:
Pasting a very large data snippet crashes the app. I can reproduce it with 0x20000 bytes.

 

[PikeRAlpha]

I don't like Java, due to the many security bugs, and thus being able to use native (OSS) apps is a plus for me. However. I am convinced that DSDT edits are, or soon should be, a thing of the past. To me it is time to start doing things differently. And we can do that because the modern BIOS versions are less broken.

About stuff changing and requiring future updates; That is the same kind of story for both patches in a (your) repo and patches DSDT's. Someone will have to fix broken stuff. No matter where you put it.

About educating people. I concur. And I am glad to have a rich heritage, because my father did a tremendous amount of work back in the day, and as a result, you can find his work in every ACPI table these days. That was when people started to do heavy DSDT coding, because he taught people what to do, but using LEGO like patches won't teach people what to do. It's just a different kind of way of patching the ACPI tables. But to be honest. That doesn't bother me. I mean. Whatever suits your needs.... that is fine by me.

 

[SJ_UnderWater]

I would like to report that scrolling is quite an obstacle in the current build.
The syntax highlighting is applied to visible code regions only but when this happens, the whole app freezes for approximately one second.
I believe it went somehow smoother in earlier versions.

I have not been able to reproduce this on my i3-530. Certainly it's possible to scroll slowly enough that you're fighting with the code coloring, but the coalescing delay is 0.15sec, and my Mighty Mouse is able to scroll much faster than that. I noticed during my test that the scroll isn't considered complete if you hold the scrubber yourself. Once you release the scrubber, the coloring will trigger.

EDIT:
One more small thing: If the DefinitionBlock declaration is in the first line of the document, it loses its highlighting.

This has been fixed with a small regex edit, it will appear in the next version.

EDIT2:
Pasting a very large data snippet crashes the app. I can reproduce it with 0x20000 bytes.

I wasn't able to reproduce this either. To test, I took one of the ProBook DSDT's, and pasted the entire tree into a new untitled document. I experienced no issues. If you experience a crash, please post the crash report, otherwise I'm left trying to reproduce it myself

 

[SJ_UnderWater]

I don't like Java, due to the many security bugs, and thus being able to use native (OSS) apps is a plus for me. However. I am convinced that DSDT edits are, or soon should be, a thing of the past. To me it is time to start doing things differently. And we can do that because the modern BIOS versions are less broken.

I don't think any manufacturer will add _DSM methods, ever.

About stuff changing and requiring future updates; That is the same kind of story for both patches in a (your) repo and patches DSDT's. Someone will have to fix broken stuff. No matter where you put it.

You misunderstood. When you package a solution as an Installer pkg (for example), all a user will ever be working with is an "instance", a time-dependent copy. When you choose a patch from a repository, you're always fetching the newest version of that patch. My point wasn't that repository patches are somehow always magically correct, my point was you're always downloading it right before you apply. Any changes the repo maintainer makes to the files will be reflected immediately in the app.

About educating people. I concur. And I am glad to have a rich heritage, because my father did a tremendous amount of work back in the day, and as a result, you can find his work in every ACPI table these days. That was when people started to do heavy DSDT coding, because he taught people what to do, but using LEGO like patches won't teach people what to do. It's just a different kind of way of patching the ACPI tables. But to be honest. That doesn't bother me. I mean. Whatever suits your needs.... that is fine by me.

People can learn what you make available to them. When you patch behind the scenes and hide the complexity, I can guarantee a user will learn nothing. When you tell users to click on a patch entry from your repository, I can guarantee they will see the patch text in the patcher and realize that the text is not only what they've fetched by clicking, but also that it is the important part of the process, the text is the critical piece. Some may even be intrepid enough to scroll through the whole thing, and even edit a word or two how they want. The point is it's right there in front of them, no barriers.

 

[xsmile]

It crashes when the data is single line.

Report:
http://pastebin.com/raw.php?i=YE16ri5a

 

[osxfr33k]

It crashes in Lion 10.7:

Process: MaciASL [509]
Path: /Users/USER/Downloads/MaciASL.app/Contents/MacOS/MaciASL
Identifier: net.sourceforge.MaciASL
Version: 1.1 (227)
Code Type: X86-64 (Native)
Parent Process: launchd [140]

Date/Time: 2013-02-19 10:38:11.888 -0600
OS Version: Mac OS X 10.7 (11A511)
Report Version: 9

Interval Since Last Report: 48544 sec
Crashes Since Last Report: 6
Per-App Interval Since Last Report: 5 sec
Per-App Crashes Since Last Report: 5
Anonymous UUID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000038

VM Regions Near 0x38:
-->
__TEXT 000000010a8dd000-000000010a906000 [ 164K] r-x/rwx SM=COW /Users/USER/Downloads/MaciASL.app/Contents/MacOS/MaciASL

Application Specific Information:
objc[509]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.AppKit 0x00007fff85242466 _NSAtomicGetObjectRetained + 10
1 com.apple.AppKit 0x00007fff852d06ec -[NSImage _usingCacheRepPerformBlock:] + 33
2 com.apple.AppKit 0x00007fff8567a2f7 -[NSImage co

 

[SJ_UnderWater]

It crashes when the data is single line.
Report:
http://pastebin.com/raw.php?i=YE16ri5a

I can see it's crashing in Colorize, an offset which is probably OpNoArg, but could you provide an example of text which can reproduce the problem? I didn't understand "data is single line"

It crashes in Lion 10.7:

Please provide a full report, otherwise I can't see the stack trace.

 

[xsmile]

I copied the hexadecimal content in the form of of an approximately 130kb sized file with Hex Fiend and pasted it.
It results in the data being placed as a sequence of <character><character><whitespace> in a very long single line. That's when the crash occurs. The content of the file shouldn't matter I guess.