error trying to update

========== Graphics-tpr.225 ==========

An attempt to improve the comment for BitBlt; it was very out of date (no Patterns or MAskedForms in image now) and more than a bit confusing in places. Hopefully this is less so.

========== Monticello-nice.571 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Monticello-nice.570 <<<
Now that the SyntaxError restarts the existing Compiler process rather than substitute to it, it is possible to edit method with incorrect syntax in the SyntaxError and continue MC Loading/Merging.

Though, we should log the corrected code, not the syntaxically incorrect one, and for that we let MethodAddition intercept the SyntaxErrorNotification so as to retrieve its corrected newSource.

========== Kernel-nice.808 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Kernel-nice.807 <<<
If you just need the parameter names, then just ask for the parameter names.
Asking for parameter and temp names, then throwing the temps away sounds like not using the right API in the right place...

========== Graphics-tpr.225 ==========

An attempt to improve the comment for BitBlt; it was very out of date (no Patterns or MAskedForms in image now) and more than a bit confusing in places. Hopefully this is less so.

========== Monticello-nice.571 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Monticello-nice.570 <<<
Now that the SyntaxError restarts the existing Compiler process rather than substitute to it, it is possible to edit method with incorrect syntax in the SyntaxError and continue MC Loading/Merging.

Though, we should log the corrected code, not the syntaxically incorrect one, and for that we let MethodAddition intercept the SyntaxErrorNotification so as to retrieve its corrected newSource.

========== Kernel-nice.808 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Kernel-nice.807 <<<
If you just need the parameter names, then just ask for the parameter names.
Asking for parameter and temp names, then throwing the temps away sounds like not using the right API in the right place...

......then a walkback (attached)..........

Cheers,
Bob

Ah, probably a problem with load order.

I will check that.

2013/9/21 Bob Arning <[hidden email]>

========== Graphics-tpr.225 ==========

An attempt to improve the comment for BitBlt; it was very out of date (no Patterns or MAskedForms in image now) and more than a bit confusing in places. Hopefully this is less so.

========== Monticello-nice.571 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Monticello-nice.570 <<<
Now that the SyntaxError restarts the existing Compiler process rather than substitute to it, it is possible to edit method with incorrect syntax in the SyntaxError and continue MC Loading/Merging.

Though, we should log the corrected code, not the syntaxically incorrect one, and for that we let MethodAddition intercept the SyntaxErrorNotification so as to retrieve its corrected newSource.

========== Kernel-nice.808 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Kernel-nice.807 <<<
If you just need the parameter names, then just ask for the parameter names.
Asking for parameter and temp names, then throwing the temps away sounds like not using the right API in the right place...

========== Graphics-tpr.225 ==========

An attempt to improve the comment for BitBlt; it was very out of date (no Patterns or MAskedForms in image now) and more than a bit confusing in places. Hopefully this is less so.

========== Monticello-nice.571 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Monticello-nice.570 <<<
Now that the SyntaxError restarts the existing Compiler process rather than substitute to it, it is possible to edit method with incorrect syntax in the SyntaxError and continue MC Loading/Merging.

Though, we should log the corrected code, not the syntaxically incorrect one, and for that we let MethodAddition intercept the SyntaxErrorNotification so as to retrieve its corrected newSource.

========== Kernel-nice.808 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Kernel-nice.807 <<<
If you just need the parameter names, then just ask for the parameter names.
Asking for parameter and temp names, then throwing the temps away sounds like not using the right API in the right place...

......then a walkback (attached)..........

Cheers,
Bob

So Monticello-nice.571 is using a message added in Compiler-nice.270
So does Kernel-nice.808

That means that I should have placed Compiler-nice.270 in an intermediate update or higher in the package order...

I just republished update-nice.246.mcm with Compiler raised two places abaove (above Monticello and Kernel).

Could you retry?

2013/9/21 Nicolas Cellier <[hidden email]>

Ah, probably a problem with load order.

I will check that.

2013/9/21 Bob Arning <[hidden email]>

========== Graphics-tpr.225 ==========

An attempt to improve the comment for BitBlt; it was very out of date (no Patterns or MAskedForms in image now) and more than a bit confusing in places. Hopefully this is less so.

========== Monticello-nice.571 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Monticello-nice.570 <<<
Now that the SyntaxError restarts the existing Compiler process rather than substitute to it, it is possible to edit method with incorrect syntax in the SyntaxError and continue MC Loading/Merging.

Though, we should log the corrected code, not the syntaxically incorrect one, and for that we let MethodAddition intercept the SyntaxErrorNotification so as to retrieve its corrected newSource.

========== Kernel-nice.808 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Kernel-nice.807 <<<
If you just need the parameter names, then just ask for the parameter names.
Asking for parameter and temp names, then throwing the temps away sounds like not using the right API in the right place...

========== Graphics-tpr.225 ==========

An attempt to improve the comment for BitBlt; it was very out of date (no Patterns or MAskedForms in image now) and more than a bit confusing in places. Hopefully this is less so.

========== Monticello-nice.571 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Monticello-nice.570 <<<
Now that the SyntaxError restarts the existing Compiler process rather than substitute to it, it is possible to edit method with incorrect syntax in the SyntaxError and continue MC Loading/Merging.

Though, we should log the corrected code, not the syntaxically incorrect one, and for that we let MethodAddition intercept the SyntaxErrorNotification so as to retrieve its corrected newSource.

========== Kernel-nice.808 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Kernel-nice.807 <<<
If you just need the parameter names, then just ask for the parameter names.
Asking for parameter and temp names, then throwing the temps away sounds like not using the right API in the right place...

......then a walkback (attached)..........

Cheers,
Bob

Ran mostly without problem. Got one of those monticello merge-whatever windows complaining about TheWorldMenu>>soundEnablingString. I clicked keep and merge and it went away. Whatever that means.

Cheers,
Bob

On 9/21/13 5:38 PM, Nicolas Cellier wrote:

So Monticello-nice.571 is using a message added in Compiler-nice.270
So does Kernel-nice.808

That means that I should have placed Compiler-nice.270 in an intermediate update or higher in the package order...

I just republished update-nice.246.mcm with Compiler raised two places abaove (above Monticello and Kernel).

Could you retry?

2013/9/21 Nicolas Cellier <[hidden email]>

Ah, probably a problem with load order.

I will check that.

2013/9/21 Bob Arning <[hidden email]>

========== Graphics-tpr.225 ==========

An attempt to improve the comment for BitBlt; it was very out of date (no Patterns or MAskedForms in image now) and more than a bit confusing in places. Hopefully this is less so.

========== Monticello-nice.571 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Monticello-nice.570 <<<
Now that the SyntaxError restarts the existing Compiler process rather than substitute to it, it is possible to edit method with incorrect syntax in the SyntaxError and continue MC Loading/Merging.

Though, we should log the corrected code, not the syntaxically incorrect one, and for that we let MethodAddition intercept the SyntaxErrorNotification so as to retrieve its corrected newSource.

========== Kernel-nice.808 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Kernel-nice.807 <<<
If you just need the parameter names, then just ask for the parameter names.
Asking for parameter and temp names, then throwing the temps away sounds like not using the right API in the right place...

========== Graphics-tpr.225 ==========

An attempt to improve the comment for BitBlt; it was very out of date (no Patterns or MAskedForms in image now) and more than a bit confusing in places. Hopefully this is less so.

========== Monticello-nice.571 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Monticello-nice.570 <<<
Now that the SyntaxError restarts the existing Compiler process rather than substitute to it, it is possible to edit method with incorrect syntax in the SyntaxError and continue MC Loading/Merging.

Though, we should log the corrected code, not the syntaxically incorrect one, and for that we let MethodAddition intercept the SyntaxErrorNotification so as to retrieve its corrected newSource.

========== Kernel-nice.808 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Kernel-nice.807 <<<
If you just need the parameter names, then just ask for the parameter names.
Asking for parameter and temp names, then throwing the temps away sounds like not using the right API in the right place...

......then a walkback (attached)..........

Cheers,
Bob

Nothing really needs to be done - it was the same change. I needed to make it first to get the help menu in order to update to your version.

On 9/21/13 6:00 PM, Nicolas Cellier wrote:

It means that we both changed the same method, so there is a merge conflict.

Right now, the method for resolving is binary:

If you say keep, then you accept the incoming version to replace your version.

If you say reject, then refuse the incoming version and prefer to keep your own version.

I guess that you'll want to manually merge our both changes once the load is complete.

2013/9/21 Bob Arning <[hidden email]>

Ran mostly without problem. Got one of those monticello merge-whatever windows complaining about TheWorldMenu>>soundEnablingString. I clicked keep and merge and it went away. Whatever that means.

Cheers,
Bob

On 9/21/13 5:38 PM, Nicolas Cellier wrote:

So Monticello-nice.571 is using a message added in Compiler-nice.270
So does Kernel-nice.808

That means that I should have placed Compiler-nice.270 in an intermediate update or higher in the package order...

I just republished update-nice.246.mcm with Compiler raised two places abaove (above Monticello and Kernel).

Could you retry?

2013/9/21 Nicolas Cellier <[hidden email]>

Ah, probably a problem with load order.

I will check that.

2013/9/21 Bob Arning <[hidden email]>

========== Graphics-tpr.225 ==========

An attempt to improve the comment for BitBlt; it was very out of date (no Patterns or MAskedForms in image now) and more than a bit confusing in places. Hopefully this is less so.

========== Monticello-nice.571 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Monticello-nice.570 <<<
Now that the SyntaxError restarts the existing Compiler process rather than substitute to it, it is possible to edit method with incorrect syntax in the SyntaxError and continue MC Loading/Merging.

Though, we should log the corrected code, not the syntaxically incorrect one, and for that we let MethodAddition intercept the SyntaxErrorNotification so as to retrieve its corrected newSource.

========== Kernel-nice.808 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Kernel-nice.807 <<<
If you just need the parameter names, then just ask for the parameter names.
Asking for parameter and temp names, then throwing the temps away sounds like not using the right API in the right place...

========== Graphics-tpr.225 ==========

An attempt to improve the comment for BitBlt; it was very out of date (no Patterns or MAskedForms in image now) and more than a bit confusing in places. Hopefully this is less so.

========== Monticello-nice.571 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Monticello-nice.570 <<<
Now that the SyntaxError restarts the existing Compiler process rather than substitute to it, it is possible to edit method with incorrect syntax in the SyntaxError and continue MC Loading/Merging.

Though, we should log the corrected code, not the syntaxically incorrect one, and for that we let MethodAddition intercept the SyntaxErrorNotification so as to retrieve its corrected newSource.

========== Kernel-nice.808 ==========

Don't pass a category to a Compiler, classifying is not its job.

>>> Kernel-nice.807 <<<
If you just need the parameter names, then just ask for the parameter names.
Asking for parameter and temp names, then throwing the temps away sounds like not using the right API in the right place...

......then a walkback (attached)..........

Cheers,
Bob