Chameleon RC4 is out!

[rekursor]

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?

 

Ok, let's start by easy things where we can get a chance to agree rapidly:

 

1. Indentation

having seen most indentation styles going from 2 to 8 spaces, I would suggest a indentation of 4 spaces.

No tabs for indentation, only spaces.

2. Comments

I see here two main different cases:

function description comments and one-line code quick comments

 

For functions documentation, I suggest to use this syntax

/**
* My comment here, one line comment can also be tolerated but following the /** */ notation
*/

Note the use of /** that will make future html auto-documentation easier (i.e: Doxygen at least recognize this marker), (proportional fonts make the space before the asterisk invisible but all asterisks are aligned).

 

for punctual, short code comment, let's use:

// my quick comment

[zef]

1. Indentation

having seen most indentation styles going from 2 to 8 spaces, I would suggest a indentation of 4 spaces.

4 spaces looks fine, but the big question is, are we going to use 4x spaces, or use 1 tab rendered as 4 spaces?

I would go with 4x spaces, this way you get the same opticals regardless of tab configuration.

 

2. Comments

I see here two main different cases:

function description comments and one-line code quick comments

 

For functions documentation, I suggest to use this syntax

/**
*
*/

Note the use of /** that will make future html auto-documentation easier (i.e: Doxygen at least recognize this marker), (proportional fonts make the space before the asterisk invisible but all asterisks are aligned).

 

for punctual, short code comment, let's use:

// my quick comment

 

I buy it

[rekursor]

4 spaces looks fine, but the big questions is are we going to use 4x spaces, or use 1 tab rendered as 4 spaces?

I would go with 4x spaces, this way you get the same opticals regardless of tab configuration.

...

I buy it

Very good point, in most of my recent projects, we ONLY use spaces for indentation,

so +1 on that one too.

[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.

 

So it's ok for me.

 

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.

 

I know your MALLOC is better than the malloc of Chameleon, but like i said i revert this because it will be hard to merge from chameleon original sources. If zef it's okay to change all the chameleon malloc to MALLOC we'll can keep your change.

 

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

Likewise MALLOC

 

Regards

 

EDIT:

 

So okay for me, change BOOL to bool and use a modified version of malloc.

 

I will give you my last fadt patch with system-type include as soon as possible.

[Master Chief]

1) Check.

2) Check.

 

3) #define at top of document (below #include)?

 

4) Global vars right below #include / #define (notation: gLobal)?

 

5) No curly brackets for single lines?

 

6) else

{

....

}

 

instead of:

 

else {

....

} ?

 

7) if

{

....

}

instead of:

 

if {

....

}

 

8) fall through code (using indention) or bail out early (using returns)?

 

9) Spaces/readability i.e. not: if (fd<0)

but: if (fd < 0)

[quinielascom]

Asere, there are a strange bug with all your patched versions: at boot stage if I select Help in the menu some lines appear corrupted or fuzzy.

 

I´m not sure if this bug is present in others graphics cards and/or chipsets.

[blackosx]

Asere, there are a estrange bug with all your patched versions: at boot stage if I select Help in the menu some lines appear corrupted or fuzzy.

 

I´m not sure if this bug is present in others graphics cards and/or chipsets.

It's because the font_small.png is being used instead of the font_console.png.

[JrCs]

Hi,

 

in attachement all the patchs to change the FADT table (Patch fadt table, RestartFix, System-type).

The patchs must be apply in order: 00-xxxxx, 01-xxxxx, etc.

 

Regards,

JrCs

fadt_patchs.zip

[rekursor]

Asere, there are a strange bug with all your patched versions: at boot stage if I select Help in the menu some lines appear corrupted or fuzzy.

 

I´m not sure if this bug is present in others graphics cards and/or chipsets.

It's a font problem bug, little regression from asere's patch that I fixed in my branch on our public chameleon svn repos.

 

3) #define at top of document (below #include)?

4) Global vars right below #include / #define (notation: gLobal)?

5) No curly brackets for single lines?

 

6) else

{

....

}

 

instead of:

 

else {

....

} ?

 

7) if

{

....

}

instead of:

 

if {

....

}

 

8) fall through code (using indention) or bail out early (using returns)?

 

9) Spaces/readability i.e. not: if (fd<0)

but: if (fd < 0)

3. Yes but with the reserve that I like to keep local what should stay local, even defines, but I would add

ALWAYS prefer:

const int MY_VAL=123;

to

#define MY_VAL 123

(type checking is always better than macros when possible)

4. No Global vars please as much as possible:)

global vars limited to a file (static) are tolerable but often, we can get rid of them

5. +1

6 & 7. +1

When we use brackets, lets make the effort to have them at the same indent level indeed, I could'nt care less about using one more line because I agree the code is much more readable.

8. Definitly bail it early: there was 20 years ago a consensus talking about using one exit point, and this was corrolary to the thinking that goto should be banned (indeed in most situations we should ban goto except for exception-like handling where they are imho justified)

I believe modern programming techniques will favor the use of return especially for preconditions handling.

9. +1, but as a recommendation, with a bit of tolerance.

 

I will add :

10a. variable, functions, types naming

non const variables should follow the (currently mostly used) following convention:

int myVariableIsFine;

instead of :

int my_variable_is_ok;

10.b the function naming should follow the same convention (and both starts with a lower case letter)

10.c type naming share the same conventions except they start with a Capital letter:

typedef ... MyType;

 

11. Please ALWAYS make sur you initialize variables:

avoid as much as possible:

int myVar

...

myVar = 10;

 

but use instead:

int myVar = 10;

(I don't count how many bugs I corrected due to lack of initialization)

 

12. const values should start by a capital like:

const int MyConstVariable = 42;

or

const int MY_CONST_VARIABLE=42; is also ok for me, depending on the context of use.

 

13. macro definitions should follow this convention:

#define MY_HANDY_MACROS_PSEUDO_FUNC() ...

 

14. Macros use should be limited to really special cases where they bring real value (like special optimization cases)

Most of the time inlining a function is much better than the use of macros

 

15. Don't optimize your code blindly, always favor readability when in doubt.

Very often, optimization is not necessary where you think it is, think about the bubble sort algorithm,

where people would code it in assembly, where a heap or quick sort algorithm would be much more efficient (n log(n) instead of quadratic), as an example when values count to be sorted get high.

[JrCs]

Hi,

 

about the options in com.apple.boot.plist, i use for exemple System-type for the name (instead of system-type like Asere).

 

We must defined how to name the options.

I think we can start the option with an uppercase letter (like options from apple, and most of chameleon).

After that, do we use the - or not, so for exemple is it better to define System-type or SystemType ?

 

What are your opinions ?

[rekursor]

about the options in com.apple.boot.plist, i use for exemple System-type for the name (instead of system-type like Asere).

 

We must defined how to name the options.

I think we can start the option with an uppercase letter (like options from apple, and most of chameleon).

After that, do we use the - or not, so for exemple is it better to define System-type or SystemType ?

 

What are your opinions ?

I am not keen on naming these options this way because it is not homogen with all other current options following the convention:

MyOptionIsFineWithNothingButLetters

so -1 on that one for me.

[JrCs]

Ok for me, i prefer option like SystemType too.

[rekursor]

Ok for me, i prefer option like SystemType too.

We currently use SystemID for system-id and this is exactly what it is,

EDIT: Sorry, yes for system-type, if it is in the boot config, then SystemType is fine.

But shouldn't it be in smbios, so here the convention would be SMsystemtype instead ?

[blackosx]

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

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

I have just used your new Rename Partition boot option from the new Chameleon SVN repo and I can report it works great. Thanks

 

I think it's now great to be able to go to one place to see what developments are taking place and have the opportunity to test things out. Well done to everybody involved.

[rekursor]

I have just used your new Rename Partition boot option from the new Chameleon SVN repo and I can report it works great. Thanks

 

I think it's now great to be able to go to one place to see what developments are taking place and have the opportunity to test things out. Well done to everybody involved.

Thanks for testing that !

I also find handy and complementary this feature, when combined with 'Hide Partition', there is no boot partitions ambiguities anymore

 

EDIT: Added a first draft of our coding standards (coding_standards.txt) in the root of the distrib in my branch.

Please participate to it and getting it more complete, while keeping in mind that this paper should retain only the essentials of it, so that it can easily be applied by all potential contributors.

We want the standard to be helpful for everyone, not a burden.

[zef]

Thanks for testing that !

I also find handy and complementary this feature, when combined with 'Hide Partition', there is no boot partitions ambiguities anymore

 

EDIT: Added a first draft of our coding standards (coding_standards.txt) in the root of the distrib in my branch.

Please participate to it and getting it more complete, while keeping in mind that this paper should retain only the essentials of it, so that it can easily be applied by all potential contributors.

We want the standard to be helpful for everyone, not a burden.

 

Very great progress! I think we can also add such documents for the forgery pages.

[rekursor]

Very great progress! I think we can also add such documents for the forgery pages.

Thanks, I see you also populated the documentation thumbnail on the repos site, it's a good start !

[zef]

Thanks, I see you also populated the documentation thumbnail on the repos site, it's a good start !

 

Rekursor,

 

Thanks for boosting up the progress.

 

Need to investigate the Markdown Extra syntax for getting nicely formatted pages:

 

http://michelf.com/projects/php-markdown/extra/

 

I'm also thinking about to add an extra Trac fronted for this repo as well. I love Trac's built-in revision compare facilities.

 

Any more ideas are welcome

[rekursor]

I'm also thinking about to add an extra Trac fronted for this repo as well. I love Trac's built-in revision compare facilities.

+1, great initiatives.

 

I'm not finished yet for this WE,

I'm developing another little surprise for chameleon,

just need to spend some time for my fantastic kids as well,

so I can't rush too much right now, but it's coming soon hopefully

[rocksteady]

rekursor, if I were moderating this forum I'd have given you a special "pacifist of the month" badge under your username, thinking twice about it, I'll do it for you on the Chameleon forum when we're done with the upgrades

 

Apologies pm'ed, misunderstandings trashed,

 

Now let's produce some 1st-class stuff and have future discussions like this one @ the upcoming dedicated place.

[Onixs]

"RestartFix=Yes" in com.apple.boot.plist is alternative for OpenHaltRestart or OSXRestart ?

[WinstonAce]

Neither the kexts nor the "RestartFix=Yes" is required when using the modified versions from this thread

[scrax]

I think it's now great to be able to go to one place to see what developments are taking place and have the opportunity to test things out. Well done to everybody involved.

 

+1

[rocksteady]

Hold on tight Gents,

 

We're getting together, laying out the basics to rock + roll out some 1st-class stuff

[rekursor]

Folks,

 

I'm glad to introduces a new Chameleon dedicated os x application (probably the first ?) :

 

A System Preference Pane permitting to select the boot partition of your choice and automatically updates it to the boot config:

 

This is an early beta, but it worked for me so I am curious to know if it works for you ...

Also, I need to polish it a bit before I put that on svn, so the sources will come this week probably.

 

There's a lot of room for new functionalities, so be kind folks, it's the only first (still useful) PoC.

 

PS: I programmed this toy today and I did not know anything about cocoa before, that was a really fun first experience !

 

Beta 5 is available for OSX 10.5 and OSX10.6 here: