Chameleon RC4 is out!

[Smith@@™]

Works for me, thanks

[Flashe]

Hi everybody,

 

I still not understand why this does not work.

I tried the 2 boot files available in this section faire.Si nothing you can enlighten me with these images in the boot because it does not work for me.

 

 

 

Could help to solve this problem please, I already erased everything on the memory in the smbios.plist.

I see that it works for many.

 

Thanks a lot.

[Dr. Hurt]

The reason its not detecting the memory information for the second slot is that its reading the information at the wrong address, because my board has 2 slots only. Somebody told me that before. I don't know why I didn't remember. Reading the EFI-X forums reminded me, and apparently Asere is already working on it.

 

Vielen Dank für Ihre Zeit

[rekursor]

Folks, just to let you know that I'm reviewing Asere modifications

 

Before I start with my obeservations : *Great* work Asere and sincerely : congrats!

 

But here's few examples/points I can't buy right now:

 

- too many undocumended changes that I believe are not always justified: when dealing with collaborative work, we shoud pay extreme attention to commit as few as possible changes to make others folks checking life easier.

- the code is not re-using sometimes existing functions (like the string to hex conversion for UUIDs)

- the code lacks some (re-)factorizing ( I also changed that and the code is more compact now)

 

- Talking about code conventions, after 20+ years of software development, I can testify that brackets add more complexity that ease in your code in many cases, like when securing your code with assertions/preconditions

(i.e: if (wrong_input) return 0; is much clearer to read when fitting on the on the same line to me)

- many static variables could be local (especially in fake_efi.c)

- Many source files and directory structure changes, was it really justified ?

 

Like I said, I'm on it and as soon as I get some more spare time today or tomorrow, I will deliver a version correcting these issues, so that we can hopefully manage more easily the chameleon code as a team.

[THe KiNG]

What happen with FACP replacement feature?

I understand that automate restart fix is n00b proof, but still I'd like to replace FACP and more tables...

[Trauma!]

Hy Asere,

 

I guess i've found a little mistake in your patch. Concerning the gui.c file patch.

 

@lines 1210 & 1211 :

+	initFont( &font_console, &images[iFontSmall]);
+	initFont( &font_small, &images[iFontSmall]);

 

Should it be :

+	initFont( &font_console, &images[iFontConsole]);
+	initFont( &font_small, &images[iFontSmall]);

 

BTW great work done here.

 

Bye.

[rekursor]

I guess i've found a little mistake in your patch. Concerning the gui.c file patch.

 

@lines 1210 & 1211 :

+	initFont( &font_console, &images[iFontSmall]);
+	initFont( &font_small, &images[iFontSmall]);

 

Should it be :

+	initFont( &font_console, &images[iFontConsole]);
+	initFont( &font_small, &images[iFontSmall]);

Yes there is also little problems in fake_efi.c, like the system-id (which is an 16 bytes hex value) not converted to hex when read from ovveridden options (fortunately it is already in hex format when read from bios)

I just corrected that too.

Continuing ...

[Master Chief]

Folks, just to let you know that I'm reviewing Asere modifications

Thanks, but what code / comment style guide are you using?

 

- the code lacks some (re-)factorizing ( I also changed that and the code is more compact now)

What are your objectives? Getting the code more compact? I would like to suggest to keep an eye on readability... far more important to me as open saucer (and required in a collaborative effort like this).

 

- Talking about code conventions, after 20+ years of software development, I can testify that brackets add more complexity that ease in your code in many cases, like when securing your code with assertions/preconditions (i.e: if (wrong_input) return 0; is much clearer to read when fitting on the on the same line to me)

Eh not true. There is research done in this area – it is actually harder for the human brain to cope with this style. Which brings me back to point one again.

 

- many static variables could be local (especially in fake_efi.c)

True. Thanks for cleaning it up. Keep an eye on gLobals please

 

- Many source files and directory structure changes, was it really justified ?

I am eagerly awaiting to see what this is about.

 

BTW: I renamed dsdt_patcher.* into acpi_patcher.* because that's what it is (we're way past DSDT patching there).

[scrax]

BTW: I renamed dsdt_patcher.* into acpi_patcher.* because that's what it is (we're way past DSDT patching there).

Hi,

where can we find this new version of Revolution? Are you thinkinfg in making a fork on github, from the Asere works?

 

@Rekursor Same question for you, after you finish were will be posted your work on the github repo?

[Asere]

Folks, just to let you know that I'm reviewing Asere modifications

 

Before I start with my obeservations : *Great* work Asere and sincerely : congrats!

Thank you.

 

 

But here's few examples/points I can't buy right now:

- too many undocumended changes that I believe are not always justified: when dealing with collaborative work, we shoud pay extreme attention to commit as few as possible changes to make others folks checking life easier.

Please do not forget, there was/is no public, not even viewable, code repository for Chameleon. I've started to cleanup and change things and because of the missing repository all ends in one big patch. The biggest change of all was the cleanup of the boolean mess.

 

- the code is not re-using sometimes existing functions (like the string to hex conversion for UUIDs)

- the code lacks some (re-)factorizing ( I also changed that and the code is more compact now)

- many static variables could be local (especially in fake_efi.c)

I've started with the cleanup... and of course this job is not done

 

- Talking about code conventions, after 20+ years of software development, I can testify that brackets add more complexity that ease in your code in many cases, like when securing your code with assertions/preconditions

(i.e: if (wrong_input) return 0; is much clearer to read when fitting on the on the same line to me)

Disagree. I'm not talking about one-liners. But I've seen already this:

if (!param)
  return 0;

if (!param)
	printf("Error: !param);
	return 0;

 

The easiest expample. Now think about much more complex situations with mixed for, switch, if , else, braces no braces... you will get lost easily! In the case of Chameleon there are also mixed and even wrong indentions. Another thing: I'm a vi guy and to read/understand code I'm using the % operator (jumps the braces) to skip, find... code blocks. Very handy if you have to understand other peoples code. But without the braces it's much harder to read and understand the code. And much, much harder to make changes!

 

- Many source files and directory structure changes, was it really justified ?

Most source files changes due the boolean cleanup.

Many directory structure changes... where???

 

 

I opened a public repository at github as suggested here. Since then all commits are atomic and related to one issue.

 

 

What happen with FACP replacement feature?

I understand that automate restart fix is n00b proof, but still I'd like to replace FACP and more tables...

 

Is there already some patch available?

 

Hy Asere,

 

I guess i've found a little mistake in your patch. Concerning the gui.c file patch.

 

@lines 1210 & 1211 :

+	initFont( &font_console, &images[iFontSmall]);
+	initFont( &font_small, &images[iFontSmall]);

 

Should it be :

+	initFont( &font_console, &images[iFontConsole]);
+	initFont( &font_small, &images[iFontSmall]);

 

BTW great work done here.

 

Bye.

 

This is already fixed. Please do not use the "old" patch files. Find the actual code here: http://github.com/aserebln/Chameleon

 

 

 

What are your objectives? Getting the code more compact? I would like to suggest to keep an eye on readability... far more important to me as open saucer (and required in a collaborative effort like this).

 

+1

[rekursor]

@Asere+MC

When I talk about more compact code, I should say more factorized code.

I revamp sometimes code so that it is more readable not because of brackets use,

The brackets considerations are for me no big deal, I'm more focused on a higher level of 'black-box' type architecture,

meaning that I care much more about how functions are decomposed into manageable primitives,

and if the code internals in a function programmed in a defensive style programming following the preconditions/invariant/post-conditions model.

 

@Asere, when I talk about renaming, I thing more about the files that have been deleted or renamed, more than the 'Booter' subdir where you can finally get the root of the chameleon distrib, btw why changing the root of the chameleon distrib ?

There is one public repository that Zef created recently with possibility of submitting patches, code reviews

and so on.

 

I think Zef should talk about it asap otherwise I'll do it !

 

Now what also matters to me is to be capable to review any change that has been made and understand it as quickly as possible, this is why one should try his best to make as less changes as possible for a new feature, so that the team that works within a same repository gets no headaches considering the changes, especially when working in your own branch and merging to trunk only after review. Of course, this has to be balanced (changes that could make the architecture better and more maintainable versus changes that could lead to too many regression bugs).

 

 

Finally, it is clear to me that there is always something to say about what we code, especially with the time we can afford to it, the last thing I am is an evangelist, so I'm always open to discussions and I am also capable of changing my mind if I believe your arguments makes sense, in our context.

[rocksteady]

I think Zef should talk about it asap otherwise I'll do it !

He will

 

Just a tad bit of more patience Gents

 

We're busy upgrading the kitchen

[Master Chief]

Hi,

where can we find this new version of Revolution? Are you thinkinfg in making a fork on github, from the Asere works?

Not yet. Still working on fixing bugs. It does load from BIOS now, but only for my MB.

 

@Asere+MC

When I talk about more compact code, I should say more factorized code.

I revamp sometimes code so that it is more readable not because of brackets use,

The brackets considerations are for me no big deal, I'm more focused on a higher level of 'black-box' type architecture,

meaning that I care much more about how functions are decomposed into manageable primitives,

and if the code internals in a function programmed in a defensive style programming following the preconditions/invariant/post-conditions model.

No worries. I wasn't blaming you for anything. Just a friendly reminder that documentation about the preferred code style is missing. Which of course makes it impossible for people to contribute in the desired style. In fact; I could have helped you if I only knew what to do

 

p.s. I am still wondering why github was denied by zef, especially after he said that everything was in place. Well. Signing up for a github account is not only easy, free but could also have saved a lot of time and energy.

[rekursor]

No worries. I wasn't blaming you for anything. Just a friendly reminder that documentation about the preferred code style is missing. Which of course makes it impossible for people to contribute in the desired style. In fact; I could have helped you if I only knew what to do

 

p.s. I am still wondering why github was denied by zef, especially after he said that everything was in place. Well. Signing up for a github account is not only easy, free but could also have saved a lot of time and energy.

+1 on documentation about the preferred code

 

While waiting for a public announcement, I decided to start from asere patch, because after diffing all the files from chameleon r687, I really like most of it

 

I did this so that whatever which repos we decide to all start from, the code would be very similar (at least between my branch and current github asere branch).

 

I would really like asere to add a document including an exhaustive list of changes (i.e: I discovered while diffing that boot0.s now disable the verbose mode by default, why?), I will help on such a (vital) document if necessary.

 

I believe Zef tries to satisfy our need while keeping some compatibility with their team process and tools (i.e svn),

let's see what he will say about this...

[zef]

Sorry guys for the delay.

 

This is the public Chameleon repo page:

 

http://forge.voodooprojects.org/p/chameleon/

[rekursor]

Sorry guys for the delay.

 

This is the public Chameleon repo page:

 

http://forge.voodooprojects.org/p/chameleon/

Thanks Zef, I fixed another font bug (different from the one reported by Trauma) and now I get my console font working great again.

Available in my branch in the public svn opened by Zef.

Continuing ...

 

EDIT:

 

While waiting I added a new feature: 'Rename Partition'=hd(x,y) <name>[; ...]

works fine here say goodbye to 'System Reserved' partition names !

 

@Asere: Where is the memory detection source code ? Did I miss something or it is simply not in the source (i.e: mem.c, spd.c). RC4 spd code has been removed, you seem to have put new placeholders (like scan_smbus_controller() from RC4 replaced by an empty scan_spd() placeholder).

Why is that ?

Thanks

[Master Chief]

While waiting for a public announcement, I decided to start from asere patch, because after diffing all the files from chameleon r687, I really like most of it

Me too, except for the use of MALLOC

 

I would really like asere to add a document including an exhaustive list of changes (i.e: I discovered while diffing that boot0.s now disable the verbose mode by default, why?), I will help on such a (vital) document if necessary.

Most people seem to want a silent boot process. Which BTW is also slightly faster.

 

My tree does not show anything but the boot logo (and earlier in the boot process) i.e. I also changed boot1x. Give it a try

 

I believe Zef tries to satisfy our need while keeping some compatibility with their team process and tools (i.e svn), let's see what he will say about this...

I only hope that the Chameleon team is going to use it, so that this repository (zefs') won't become another second class citizen.

 

Sorry guys for the delay.

 

This is the public Chameleon repo page:

 

http://forge.voodooprojects.org/p/chameleon/

Thank you zef, but I get this error:

PlufErrorHandlerException making GET request to /p/chameleon/timeline/
8 : Trying to get property of non-object
PHP 	/var/www/sites/voodooprojects/forge/indefero/src/IDF/Review/Patch.php, line 144
URI 	GET /p/chameleon/timeline/

When I click on Latest Updates

[JrCs]

Hi all,

 

I started a new branch from the Asere patchs.

I have revert some patchs so it will be more easier to apply the futurs patchs to Chameleon original sources.

 

The reverts are:

• style coding
  
• MALLOC function to malloc
  
• bool type to BOOL
  

I have also rewrite a little the restart fix to be full ACPI compliant.

 

I will push my branch to my github account as soon as possible.

 

About the PM-Profile patch, i think it's better to have a non misleading option in com.apple.boot.plist. So i think it's better to name the option PM-profile instead of system-type because it's only modify the Power Management Profile in the FADT table.

 

In attachment:

• the "revert patch" to apply to the latest asere's chameleon version
  
• my patch_fadt function and restart fix to be applied on original chameleon RC4 sources
  

Regards JrCs.

revert_style_and_function.zip

patch_fadt_and_restartfix.zip

[Dr. Hurt]

Does Asere's source code on github contain the memory detection?

I got the source and compiled but I don't get RAM information detected.

Asere's bin version detects RAM information.

 

Am I doing something wrong?

[Asere]

Hi all,

 

I started a new branch from the Asere patchs.

I have revert some patchs so it will be more easier to apply the futurs patchs to Chameleon original sources.

 

The reverts are:

• style coding
  
• MALLOC function to malloc
  
• bool type to BOOL
  

I have also rewrite a little the restart fix to be full ACPI compliant.

 

I will push my branch to my github account as soon as possible.

 

About the PM-Profile patch, i think it's better to have a non misleading option in com.apple.boot.plist. So i think it's better to name the option PM-profile instead of system-type because it's only modify the Power Management Profile in the FADT table.

 

In attachment:

• the "revert patch" to apply to the latest asere's chameleon version
  
• my patch_fadt function and restart fix to be applied on original chameleon RC4 sources
  

Regards JrCs.

 

Have only little time at the moment. So a quick response:

 

I suggest to stay with system-type. It's straightforward, like system-id, devices-properties... it's the destination name... how it appears in the ioreg. Another thing. My GA-EP45-DS3 only have ACPI V1. I don't even have a PM_Profile. OS X uses FACP:PM_Profile to set system-type.

 

Why to remove the MALLOC (a macro to malloc(__FILE__, __LINE__))? Look at the code. Chameleon is written to not check whether malloc fails or not. Malloc must work, if not Chameleon stops and give an error message like: malloc error address=x size=y, which is completely useless. How to narrow down which malloc failed??? Impossible! I had 2 times malloc errors and to find out which malloc failed, I rewrote the malloc calls to hand over the filename and linenumber too. Now, then malloc fails you will exactly see, which one is failing.

 

Asere

 

 

Yes there is also little problems in fake_efi.c, like the system-id (which is an 16 bytes hex value) not converted to hex when read from ovveridden options (fortunately it is already in hex format when read from bios)

I just corrected that too.

Continuing ...

 

Can you explain this? I've checked it again. It's working (SMUUID, UUID from SMBIOS, system-id). There was only an error with getBootForKey("system-id), which I have fixed.

 

bool type to BOOL

 

Ahh... why back to BOOL??? Why not to use not to Iso C99 "stdbool.h", which is bool and true, false.

[rocksteady]

I only hope that the Chameleon team is going to use it, so that this repository (zefs') won't become another second class citizen.

Pardon?

 

We've had enough of a FUDFest already, don't you think? And how come mature educated persons drop racial slurs?

 

I do not understand what you're after. If it's anything personal you can level straight+easy with that specific person(s), no? Want your own name on your own lollipop? Why don't you open your own dedicated thread/blog/forum? We'll come back, read you and congratulate you. Want to join our efforts? You're welcome to do so.

 

What's so cool about trying to divide a project into "camps"?

[zef]

Thank you zef, but I get this error:

PlufErrorHandlerException making GET request to /p/chameleon/timeline/
8 : Trying to get property of non-object
PHP 	/var/www/sites/voodooprojects/forge/indefero/src/IDF/Review/Patch.php, line 144
URI 	GET /p/chameleon/timeline/

When I click on Latest Updates

 

I had to delete some entries from the forge DB manually but i forgot to remove a leftover row from the timeline table, that caused the issue. Fixed already.

[Master Chief]

Pardon?

 

We've had enough of a FUDFest already, don't you think? And how come mature educated persons drop racial slurs?

What racial slurs? Have I missed anything?

 

Edit: In case you mean my: "...won't become another second class citizen". Which is pretty normal talk when you disuse a new repository (I wasn't talking about zef).

 

I do not understand what you're after. If it's anything personal you can level straight+easy with that specific person(s), no? Want your own name on your own lollipop? Why don't you open your own dedicated thread/blog/forum? We'll come back, read you and congratulate you. Want to join our efforts? You're welcome to do so.

 

What's so cool about trying to divide a project into "camps"?

Sorry, but I do not have any kind of personal grievance. Not with anyone (here).

 

Yes I could use my own name for "my lollipop" but like I said, and a couple of times before already... this is not my goal and thus I wonder, seriously, why you keep mentioning it. I mean scroll up. Go back a few pages and read what I wrote. Thank you.

 

About me asking about the code style, which has absolutely nothing to do with "camps" or anything, since it is just a normal question. Yet, you make it sound worse than it is, and start blaming me for something that isn't there. Thanks again.

 

Now. Before people can join, don't you agree that they need to know things like the preferred code / comment style? Is that really that difficult to understand?

 

Can we please go back to some level of educated communication, without the almost usual low-level posts here? And when you, zef, or anyone else has issues with me, then I challenge you to communicate with me on a fair level. Not by twisting my words, stretching them so that they fit you better. Thanks again.

 

FTR: Want I want is a name change [clearly] because Chameleon is a registered trademark (don't talk about dis-respect without being respectful to others yourself) and that people forget the past, continue their great work, but by following the generally accepted OSS guidelines. And please without adding any restrictions. Or blaming people when they want things to go slightly different. After all; all I do is to follow the previously mentioned guidelines, yet I get "strange" comments/replies. And time after time. So who is blaming who here? Who is being disrespectful here?

 

I had to delete some entries from the forge DB manually but i forgot to remove a leftover row from the timeline table, that caused the issue. Fixed already.

Confirmed. Thanks!

 

 

...

Can you explain this? I've checked it again. It's working (SMUUID, UUID from SMBIOS, system-id). There was only an error with getBootForKey("system-id), which I have fixed.

Probably because of the fixed length... shorter/longer strings in com.apple.Boot.plist make it fail? Not to mention that longer strings will do bad things

 

Ahh... why back to BOOL??? Why not to use not to Iso C99 "stdbool.h", which is bool and true, false.

+1

 

p.s. I understand the use of MALLOC but you could use malloc instead. Just a different change.

[rekursor]

Pardon?

...

What's so cool about trying to divide a project into "camps"?

 

Gentlemen,

 

I believe that sometimes we see the evil where there is nothing (intended to be) wrong, really. Especially when we work hard in the meantime and most of us do.

 

This new Chameleon site is really a great thing, I have no worry about the fact that the Chameleon team will be the first to use it, because if you think about it, it is also a great time saving feature for us to have new features/fixes gathered at one main place.

 

Please people join this great initiative and be positive and thankful about what it can bring to us.

 

Nothing is more important in this community project that gathering all our talents and work together, even if it is the most difficult task in most open source projects.

 

Like I said in previous a post, I really have great esteem for all of you folks that contribute to make our common project better.

 

We all have qualities and specificities that make us individuals, that's fine and I can easily cope with it, because my motivation for collaborative work goes far beyond other individual considerations.

 

I hope I'm not the only one to think that way,

 

--Rek

 

+1 for keeping the bool changes and

+1 for renaming MALLOC to malloc while keeping this great debug feature

 

I can rapidly do the changes if it is ok for you folks,

 

btw did anyone tried my new Rename Partition feature ?

[Master Chief]

Gentlemen,

 

I believe that sometimes we see the evil where there is nothing (intended to be) wrong, really. Especially when we work hard in the meantime and most of us do.

 

This new Chameleon site is really a great thing, I have no worry about the fact that the Chameleon team will be the first to use it, because if you think about it, it is also a great time saving feature for us to have new features/fixes gathered at one main place.

 

Please people join this great initiative and be positive and thankful about what it can bring to us.

 

Nothing is more important in this community project that gathering all our talents and work together, even if it is the most difficult task in most open source projects.

 

Like I said in previous a post, I really have great esteem for all of you folks that contribute to make our common project better.

 

We all have qualities and specificities that make us individuals, that's fine and I can easily cope with it, because my motivation for collaborative work goes far beyond other individual considerations.

 

I hope I'm not the only one to think that way,

 

--Rek

I agree. This is a win-win situation for everyone. I mean having a public repository is another step forward. Can we please continue and put a next point on the agenda, being: Code and Comment Style?

 

+1 for keeping the bool changes and

+1 for renaming MALLOC to malloc while keeping this great debug feature

 

I can rapidly do the changes if it is ok for you folks,

Yes, please! Thanks!