PHP 5.4 removes Pass by Reference

[Amy Stephen]

What are the plans for Joomla now that php removed pass by reference in v 5.4? I checked the roadmap, but didn't recognize an entry that addressed this.

http://php.net/manual/en/migration54.incompatible.php

http://www.php.net/manual/en/language.references.pass.php

Thanks!

[Emerson da Rocha Luiz]

Just out of curiosity, how often and how dependent we are of it?

We need remember that this should not only be a concern of JPlaform, but also classes in the CMS. Maybe not for a 3.0.0, but for something at least like 3.0.2 or 3.0.3 and at some point on 2.5. In a few months the forums can be filled with users having problems with it that also affects the 2.5 core.

Important to remember: nothing on JPlatform coding standards tell about this. http://developer.joomla.org/standards/ch03s03s07.html just says about do not use reference on variables (functions are not mentioned) and http://developer.joomla.org/standards/ch02s05.html still empty. Ok that a Joomla developer must be also a good PHP programmer, but does not hurt add at least one note about this and a warning of incompatibility on PHP 5.4 just to be sure.

emerson

--

Emerson Rocha Luiz
+55 51 9881-9146 | Skype: fititnt | GTalk: fititnt | Twitter: @fititnt | http://www.fititnt.org

Membro do JUGRS

[Rouven Weßling]

Do you know of any examples where we're using call time pass by reference? (pass by reference itself is not deprecated nor removed)

I did go trough the platform and removed a lot of explicit references where PHP would always do pass by reference (since we're passing objects) and where we simply don't need it. However there's still a few left.

Best regards

Rouven

[Mark Dexter]

I'm not sure I understand. Are we talking about something like this:

function stick(&$pks, $value = 1)

or something else?

We have many places where we pass function args by reference. But I
don't think this is what is changing.

Can someone please give a specific code example of what no longer
works? That would help me a lot. Thanks.

Mark

[Michael Babker]

It looks like this is what is removed from PHP 5.4:
http://www.php.net/manual/en/language.references.pass.php

On the page, it references it being deprecated in PHP 5.3.

[Amy Stephen]

This type of call will be a problem:

call_user_func_array('function', array(&$a));


Looks like just a small handful: application/router.php has a couple, legacy/error/error.php, legacy/toolbar/button.php

I need to change my call to the filesystem. Looks like the events in Joomla are cleaned up already.

Probably more of an impact for developers since it appears someone has gone through the core (with the exception of those few, if I understand correctly.)

[Rouven Weßling]

Just to clarify, call time pass by reference is this:

function a($x) {
return $x;
}

$foo = "Joomla";
a(&$foo);

This is deprecated in 5.3 and removed in 5.4.

Call by reference itself looks likes this:

function b(&$x) {
return $x;
}

$foo = "Joomla";
a($foo);

This still works fine in 5.4.


What I'm not quite sure is whether this still works:
b(&$foo);

But we should just make sure we never use call time pass by reference.

Best regards
Rouven

[Niels Braczek]

Am 28.06.2012 17:46, schrieb Rouven Weßling:

> Call by reference itself looks likes this:
>
> function b(&$x) {
> return $x;
> }

This should be avoided, if $x is an object, since objects *always* are
passed as a reference.

Regards,
Niels

--
| http://barcamp-wk.de · 2. Barcamp Westküste Frühjahr 2013 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Emerson da Rocha Luiz]

Just to point a few lines of important core plugins

https://github.com/joomla/joomla-cms/blob/master/plugins/authentication/joomla/joomla.php#L29

https://github.com/joomla/joomla-cms/blob/master/plugins/content/joomla/joomla.php#L28

https://github.com/joomla/joomla-cms/blob/master/plugins/system/cache/cache.php#L29

All these use &$varname. 

So, these call does not are deprecated but must be avoided? If we just remove "&" still work fine on all PHP versions 5.2~5.4? Or, if for it works, need changes core of CMS and JPlatform, can it break 3rd plugins that at some point can depend of these "&"?

Ok that for new triggers we could avoid pass by reference, but any change on how plugins works now really must be tested a lot or before release a change call 3rd developers and be clear that this specific point must be tested if have any change of break.

We need keep in mind that a lot of plugins on JED still just updated from old versions and have some people just make it work on Joomla 1.6+, but not really refactored for be standart. Even new plugins at some point have copy & paste from old plugins way of work.

emerson

--

Emerson Rocha Luiz
+55 51 9881-9146 | Skype: fititnt | GTalk: fititnt | Twitter: @fititnt | http://www.fititnt.org

Membro do JUGRS

[Rouven Weßling]

On Jun 28, 2012, at 6:18 PM, Emerson da Rocha Luiz wrote:

Just to point a few lines of important core plugins

https://github.com/joomla/joomla-cms/blob/master/plugins/authentication/joomla/joomla.php#L29

https://github.com/joomla/joomla-cms/blob/master/plugins/content/joomla/joomla.php#L28

These two can easily be removed since there are objects passed.

https://github.com/joomla/joomla-cms/blob/master/plugins/system/cache/cache.php#L29

This one too. If mary event work goes in in time, and if I don't find a better solution, that one may even be a fatal error.

All these use &$varname. 

So, these call does not are deprecated but must be avoided? If we just remove "&" still work fine on all PHP versions 5.2~5.4? Or, if for it works, need changes core of CMS and JPlatform, can it break 3rd plugins that at some point can depend of these "&"?

I wouldn't say must, more should. There are some valid use cases for pass by reference.

We need keep in mind that a lot of plugins on JED still just updated from old versions and have some people just make it work on Joomla 1.6+, but not really refactored for be standart. Even new plugins at some point have copy & paste from old plugins way of work.

In general that shouldn't be a problem. They'll just get an E_STRICT error.

Rouven

[Sam Moffatt]

You're reading it wrong.

> https://github.com/joomla/joomla-cms/blob/master/plugins/authentication/joomla/joomla.php#L29

That's a function definition not a function call so it won't be a
problem anyway.

> https://github.com/joomla/joomla-cms/blob/master/plugins/content/joomla/joomla.php#L28

This is also a function definition, so it still fine and not deprecated.

> https://github.com/joomla/joomla-cms/blob/master/plugins/system/cache/cache.php#L29

This is again a function definition and not what is being deprecated.

What is being deprecated is when you do something like this:

<code>
function processString($string)
{
// string ops or something that manipulates the original value of string.
return $processedString;
}

$result = processString(&$myReallyBigString);
</code>

The reason is obvious, to prevent functions that modify their input
thinking it's a copy from unintentionally having side effects that the
author of the function didn't intend. The final line is what is being
deprecated and will generate the warning.

Defining references in a function declaration isn't a problem, only
when you want to 'force' a function to take a reference (which in
itself was a curious concept unique to PHP) - or using it in the
function call. All of these examples are perfectly safe because they
are function definitions.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Amy Stephen]

On Thu, Jun 28, 2012 at 12:16 PM, Sam Moffatt <pas...@gmail.com> wrote:

You're reading it wrong.

> https://github.com/joomla/joomla-cms/blob/master/plugins/authentication/joomla/joomla.php#L29

That's a function definition not a function call so it won't be a
problem anyway.

https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/event/event.php#L52

Judging from the comment on line 52 (which probably should be updated) - it looks like the Event system used to call these by reference but it's been changed to:

return call_user_func_array(array($this, $event), $args);

At minimum, shouldn't that give a strict error since the definitions are different? How will it (or will it?) impact operation? And should the plugins be defined in the manner that they are? Or, should it be changed if for no other reason than to avoid confusion?

[Rouven Weßling]

On Jun 28, 2012, at 7:24 PM, Amy Stephen wrote:

On Thu, Jun 28, 2012 at 12:16 PM, Sam Moffatt <pas...@gmail.com> wrote:

You're reading it wrong.

> https://github.com/joomla/joomla-cms/blob/master/plugins/authentication/joomla/joomla.php#L29

That's a function definition not a function call so it won't be a
problem anyway.

https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/event/event.php#L52

Judging from the comment on line 52 (which probably should be updated) - it looks like the Event system used to call these by reference but it's been changed to:

return call_user_func_array(array($this, $event), $args);

You'll have to look at the code that actually triggers the event for sure. JEvent::update() can still pass things by reference.

Rouven

[Amy Stephen]

The update method does, but the actual call to the plugin method does not.

[Amy Stephen]

In reality, these are all probably "okay" because objects are likely always (or almost always) passed through.

I guess the question is - do the plugins serve as a good example of how you want devs to code? Most will just copy and paste. If the parameters don't hurt -- but also don't help -- maybe clean up is in order?

Anyway, it does look more like a CMS issue and I have my problem fixed now. Appreciate the feedback.

[Rouven Weßling]

On Jun 28, 2012, at 7:42 PM, Amy Stephen wrote:

> The update method does, but the actual call to the plugin method does not.

I gotta say one of the bests things about PHP is its documentation. Straight from the horses mouth:

Before PHP 5.4, referenced variables in param_arr are passed to the function by reference, regardless of whether the function expects the respective parameter to be passed by reference. This form of call-time pass by reference does not emit a deprecation notice, but it is nonetheless deprecated, and has been removed in PHP 5.4. Furthermore, this does not apply to internal functions, for which the function signature is honored. Passing by value when the function expects a parameter by reference results in a warning and having call_user_func() return FALSE (there is, however, an exception for passed values with reference count = 1, such as in literals, as these can be turned into references without ill effects — but also without writes to that value having any effect —; do not rely in this behavior, though, as the reference count is an implementation detail and the soundness of this behavior is questionable).

(http://php.net/manual/de/function.call-user-func-array.php)

So from my understanding it still works when the function declaration declares a variable as static.

Rouven

[Ofer Cohen]

There is a post in the forum about this:
http://forum.joomla.org/viewtopic.php?f=622&t=726130

Ofer Cohen

[Sam Moffatt]

I'm not sure I see how this is related. Line 760 looks like this for me:
$retval = $this->$doTask();

From the tag:
https://github.com/joomla/joomla-cms/blob/2ab73ee2441027c99ca3bb44dcc593d9e42247df/libraries/joomla/application/component/controller.php#L760

This isn't an example of pass by reference…

Cheers,

Sam Moffatt
http://pasamio.id.au

[Beat]

On Thursday, June 28, 2012 5:09:31 PM UTC+2, Rouven Weßling wrote:

Do you know of any examples where we're using call time pass by reference? (pass by reference itself is not deprecated nor removed)

I did go trough the platform and removed a lot of explicit references where PHP would always do pass by reference (since we're passing objects) and where we simply don't need it. However there's still a few left.

Best regards

Rouven

Hi Rouven,

Hi all,

This is a false alarm and a wrong reaction imho. PHP 5.4 only removes a feature which is *already deprecated* and generates *strict notices* in PHP 5.3:

calling so: a( &$b ); instead of a( $b )  (with function a( &$b ) implemented ) is removed. That's all.

However, by removing the & references to objects you are changing the API of Joomla without notice, and this will break quite a few extensions.

If there are such API changes, they should only affect Joomla 3.0 and not 2.5.

Please consider reversing those changes as &$object is still not same as $object in a call reference at all, if that object is passed to somewhere where it is assigned.

Simple example showing why passing an object by reference to a function is not at all the same as passing it by "value".

Also an array( &$object ) is not at all same as array( $object ). And both are perfectly valid in PHP 5.4.

Best Regards,

Beat

TEST-CODE SHOWING WHY Joomla API should keep &$object in function arguments and in array() :

<?php

class test {

public $oStore;

public function setRef( &$o ) {

$this->oStore = &$o;

}

public function setObj( $o ) {

$this->oStore = $o;

}

}

// A: Test without reference:

$t = new test();

$testobj1 = new stdClass();

$testobj1->a = 1;

$testobj2 = new stdClass();

$testobj2->a = 2;

$t->setObj( $testobj1 );

echo $t->oStore->a;

// outputs 1

$testobj1 = $testobj2;

echo $t->oStore->a;

// outputs 1 because it's not a reference

// Test with reference:

$t = new test();

$testobj1 = new stdClass();

$testobj1->a = 1;

$testobj2 = new stdClass();

$testobj2->a = 2;

$t->setRef( $testobj1 );

$testobj1 = $testobj2;

echo $t->oStore->a;

exit;

// outputs 2 because it's a reference

[Amy Stephen]

Beat -

First, thanks for that code example. Good reminder of the basics of what "by reference" means. That, Sam's explanation, and Rouven's post that begins "Just to clarify" are all very good and helped me clear up my misunderstanding.

Now, to be honest, I am doubtful a problem exists simply on the basis that we aren't seeing these surface. But, even so, before suggesting a change be reverted on the basis of a general comment, it would be important to point to the lines of code that are an issue, or at least apply a generic testing approach to an actual broken extension. Due diligence is needed, right? Let's not jump to conclusions though since that certainly does have potential to create false alarm.

The one conclusion I have drawn from this thread is that the topic is confusing to most of us and that we aren't all talking about the same thing. Clear example - the title of the topic I selected. That alone was incorrect as Rouven correctly (and gently) pointed out.  So, I am sorry for creating confusion and unnecessary concern by initiating this topic based on my incorrect understanding.

Thanks.
Amy

[Beat]

Hi Amy,
Fully agree with your approach, "isn't broken, don't fix", but think
that should apply to the changes made, and not to reverting them for
due diligence.

Breaking the API compatibility has a huge impact on Joomla users when
their extensions stop working because of API changes - most extensions-
developers and Joomla users just went through the 2.5.5-nightmare, and
this kind of changes are exactly the best way to break again Joomla's
API, so should be done only if really needed.

So fully agree with you on the principle, but not on the timing and
acceptance of "fait accompli".

Best Regards,
Beat

[Emerson da Rocha Luiz]

Break compatibility is one think that needs more attention, but start to blow up a few E_STRICT warnings on extensions should be fine on a update from 2.5 to 3.0, if necessary. For me, even for a 2.5 to 2.5 should not be a problem if is just a E_STRICT.

If Joomla, the cms or the platform, are with unnecessary code that was only necessary on PHP4, is a bit strange we continue with this for years. In last case, at least give one different way to do it if developer is just using JPlatform and no Joomla-CMS. The problem is that *every time* that we come close to one problem with legacy code, instead of at least make a public call to extensions developer weeks before one relase to test changes, and also make some compreensive guide of update, just "well, I will just copy this class to from /libraries/joomla to /libraries/cms and is not more my problem". Since Joomla 3.0 is too close, be prepared for do it on 4.0 is a good idea.

Well, what I said on this email is not my opinion specific to this topic about pass by reference, but for everything.

emerson

--

Emerson Rocha Luiz
+55 51 9881-9146 | Skype: fititnt | GTalk: fititnt | Twitter: @fititnt | http://www.fititnt.org

Membro do JUGRS

[Amy Stephen]

500 lashes with a wet noodle to those who keep the core fires going for making a change (that we cannot specifically identify) and, in doing so, harming users by breaking their extensions (that have not been reported as broken so we cannot name.)

Don't. Do. It. Again. (whatever it was that you did.)

I'm sorry to be so cross, but I am old and I am frustrated with the general lack of engagement of the developer community unless there is beer to drink or something to bitch about and the apparent inability of the leadership of this project to pull their developers in. This community is in a rut and destined to continue the same cycle of failure until people start to see themselves in the problem and do something about it. Will that ever happen? I have given up hope.  The patterns are too deep.

Now that both of us have jumped up on soapboxes and shared our negative views of the state of Joomla, as it were, maybe we can return this discussion to it's intended topic? If the 2.5.5 "nightmare" is something that requires further "discussion", please open a new thread.

[Beat]

Amy -

Thank you for your constructive, positive, engagement-encouraging and
enlightening reply (it was a bit off-topic to say the least, isn't
it? ;-) ).
I'm really sad to read the way you think generally about the Joomla
Community and its leadership. :-(
Fortunately, very positive changes are happening in Community,
Leadership and Joomla code. :-)

Neither my post nor my opinions are negative. Removing an unneeded
change that will break API compatibility in 2.5.x CMS versions (and
keeping it for 3.0) is not negative by any metric. ;-)

back to thread subject: :-)

All -

I stand with my general statements, and those can be found in Joomla's
roadmap in more general terms):
- Joomla CMS 2.5.x -> 2.5.x+1 (and corresponding Platform) should NOT
change APIs where not absolutely required (isn't proven broken, don't
fix it).
- Joomla CMS 2.x -> 3.x: API (and corresponding Platform) changes and
modernizations are welcome (with backward, forward, or sideward
compatibility at choice preferably as it is a in-CMS update and not a
migration).

Several people, including Rouven, Michael, and me, have explained what
the subject of this thread "PHP 5.4 removes Pass by Reference" means,
and that it is NOT a reference to an object in an array nor a
reference to an object in the parameter of a function definition, but
only a reference at function-caller side, and which were already
issuing warnings in PHP 5.3 already and have all been already fixed in
Joomla 1.5 and 2.5.

My only comment was that: As it wasn't what was thought initially, the
corresponding changes are not needed nor good for Joomla CMS 2.5, and
I have shown with a simple example why they have an adverse effect on
compatibility for minor releases, and should be removed from 2.5 and
kept for 3.0.

I have in additon replied to the common misunderstanding that $object
and &$object would be same (THEY ARE NOT), and have shown a simple
example of why they are different, and of why it makes sense to keep &
$object where they were for Joomla CMS 2.5.

Thus, Joomla 2.5 does fine on that regard on "PHP 5.4 removed feature
Pass by Reference" (the subject of this thread), and thus any function
definition fixes made for this are of not fixing anything for Joomla
CMS 2.5 (and its underlying Joomla Platform), but will be breaking the
Joomla API compatibility, specially for system plugins extending
Joomla's functionality, and needing the references to function
properly.

Sorry, can't explain it better without starting to repeat myself.

Positively,
Best Regards,
Beat

On Jun 29, 11:44 pm, Amy Stephen <amystep...@gmail.com> wrote:
> 500 lashes with a wet noodle to those who keep the core fires going for

> making a change* (that we cannot specifically identify)* and, in doing so,
> harming users by breaking their extensions *(that have not been reported as
> broken so we cannot name.)*
>
> Don't. Do. It. Again. (*whatever it was that you did*.)

>
> I'm sorry to be so cross, but I am old and I am frustrated with the general
> lack of engagement of the developer community unless there is beer to drink
> or something to bitch about and the apparent inability of the leadership of
> this project to pull their developers in. This community is in a rut and

> destined to continue the same cycle of failure until people start to see *
> themselves* in the problem and do something about it. Will that ever

[Amy Stephen]

On Fri, Jun 29, 2012 at 6:33 PM, Beat <bea...@gmail.com> wrote:

Neither my post nor my opinions are negative. Removing an unneeded
change that will break API compatibility in 2.5.x CMS versions (and
keeping it for 3.0) is not negative by any metric. ;-)

I agree!

So, specifically, what code changed that you want reverted? Link to it.

You said that extensions were broken. Name them.

You said the API of the CMS was changed. So, once you have linked to the code you want reverted, then, explain specifically how the API changed.

That's constructive. With those facts in hand, solutions can be found.

I'll await your response and I promise you, if you can substantiate your claims, I will help you champion a solution.

[Beat]

Amy -
Thank you for your "challenges to prove myself" and your proposal to
"help me champion solution", but my 3 posts above are already very
clear and easily understandable by the Joomla core devs and all
professional PHP developers.
Wishing you a great week-end, :-)
Beat


On Jun 30, 2:37 am, Amy Stephen <amystep...@gmail.com> wrote:

> On Fri, Jun 29, 2012 at 6:33 PM, Beat <beat...@gmail.com> wrote:
> > Neither my post nor my opinions are negative. Removing an unneeded
> > change that will break API compatibility in 2.5.x CMS versions (and
> > keeping it for 3.0) is not negative by any metric. ;-)
>
> > I agree!
>

> So, specifically, what code changed that you want reverted? *Link to it. *
>
> You said that extensions were broken. *Name them.*

>
> You said the API of the CMS was changed. So, once you have linked to the

> code you want reverted, *then, explain specifically how the API changed.*

[Amy Stephen]

Ok, thanks Beat. The last thing to add, then, is very specific statements of clarity so that folks understand what might be expected of them in case there is confusion. Correct me if I am wrong, but I think it's fair to say the following are true:

- No specific code changes were identified as a problem so there is nothing to revert, at this time.

- To the best of our knowledge, users have no reason to be concerned as we do not know of any extensions experiencing problems or failing as a result of anything discussed in this thread.

- Unless more information arises, at this time, we have no advise to offer developers as to changes they must make to their code because we have not identified any API changes in this thread.

Unless someone has specific concerns or advise for the project, users, or developers, I think we can set that discussion aside now.

++++

In this case, the PHP 5.4 changes could cause extensions to fail and harm user sites. Does anyone have "easy-to-understand, specific" answers to these questions:

- What should the project do?

- What should developers do?

- Is there advise that should be shared with users on the Wiki (?) related to PHP 5.4?

The more specific these instructions are, the more likely we can help protect users simply by raising awareness in the developer community.

Any takers on answers to those three questions?

Thanks.

[Andrew Eddie]

Reminder. This is a platform list not a CMS list. We keep going over "what happens in the cms" and it's completely unnecessary and distracting. If there's a significant compatibility problem, use the legacy tree to your advantage. That's what it's there for. 

On the issue at hand, we, I thought, dealt with pass by reference many years ago and any remaining instances should be considered a bug and should be fixed. The change in PHP 5.4 in not a problem in the platform and should really not be considered a problem for the cms as a downstream user, in my opinion.

Regards

Andrew Eddie 

--
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[Elin Waring]

There is a reason that projects like PHP give long deprecation notices and that is so that there are no problems when the removal happens. In this case, both CMS and what was then called the Joomla Framework removed many instances prior to the release of Joomla 1.6 and then when most hosts finally upgraded to PHP 5 and CentOS, WAMP and MAMP all did it with E_STRICT reporting turned on we found all the others very very quickly thanks to the screams in the forums. It is possible that somewhere deep inside some bit of code that is never used by anyone with error reporting turned on there could be some stray instance, but highly unlikely. We have said all along that we strive for E_ALL|E_STRICT.  Andrew, Louis and Ian were driven crazy by being asked questions by me while doing the doc blocks about every single place I saw an & in a method signature.  Not that I couldn't have missed some but I did scan all of the files in the platform at that time. 

The previous edition of our code standards said this:

E_STRICT-compatible code
As of version 1.6, all new code that is suggested for inclusion into Joomla must be E_STRICT-compatible. This means that it must not produce any warnings or errors when PHP's error reporting level is set to E_ALL | E_STRICT.

E_STRICT is of course a moving standard. Currently we have deprecation warnings that are mainly around array_diff_assoc Array to String Conversion.  These are present in the platform as well as in well known downstream applications.  What would be great is if some people would proactively hunt those down. By doing it now, when deprecation ends we will not have any problems. 

Although annoying when it leaks out to site visitors, the PHP deprecation model of taking the time to ensure that php developers know well in advance about deprecations and removals is very successful as we can tell by the ease of transition to PHP 5.4 that both the platform and well known down stream applications have made. That, among other things, is why we are able to have  a non emergency discussion of the process or removing the mysql driver among other things. It is certainly a model worth emulating.

Elin

[Rouven Weßling]

On 30.06.2012, at 20:29, Elin Waring wrote:

E_STRICT is of course a moving standard. Currently we have deprecation warnings that are mainly around array_diff_assoc Array to String Conversion.  These are present in the platform as well as in well known downstream applications.  What would be great is if some people would proactively hunt those down. By doing it now, when deprecation ends we will not have any problems. 

It has already ended with PHP 5.4. A solution for the occurrence in JCache is an open pull request. If there are others (or any strict, warning or notice from the platform) please add them to the issues. We should hunt all of them down.

Rouven

[Amy Stephen]

Andrew - thanks for that response. My problem was related to how I invoked Joomla's File system, which I modeled after an old way things were done in Joomla and just assumed that the problem I had was also in Joomla. I should have known, and its good to know, that you guys have been on that for awhile.

Kudo's to all of you who have tackled what seemed to be an insurmountable number of strict errors over the past year. It's that kind of work, and the unit testing, and the class cleanups, that pave a way for Joomla longevity. It's always a delicate balance between stability and staying up to date, but when PHP removes a function, there is no choice.

All in all, given all the changes going on in technology, there have been remarkably few problems and smooth transitions. (Not to diminish the impact of the problems that have occurred and I have yet to meet a core contributor who isn't personally "ashamed" and frustrated when problems happen.) But, stepping back and looking at the overall progress, it's going pretty well.