DeveloperCompanion 1.0 BETA is here!

[Christoph Dorn]

I am pleased to announce the immediate availability of
DeveloperCompanion 1.0 BETA for Firefox 4:

http://www.developercompanion.com/

Status:

* This is the first release candidate. Please report any issues
here.
* You can find a list of features that will be part of 1.0 on the
site.
* Logging to the Firebug Console will be available again with
Firebug 1.8. Until then these messages will go the the Companion
Console.
* This release is intended to replace all previous releases.
* Ideally install companion into a fresh firefox profile for Firefox
4 to avoid any possible issues.

Activating your license:

If you have a companion license, open your existing companion in
Firefox 3, go to the "Companion" tab and click on "Add Client". You
will receive an email with a link that needs to be opened with the new
companion installed in Firefox 4.

To get started:

The setup process for FirePHP has been much streamlined. You can check
out an example by opening companion (click on icon in browser status
bar) and double-clicking the sample workspace. To add a new workspace
click "New Workspace" and follow the instructions.

I have tested everything to the best of my ability on my setups. I do
expect some issues. When an error occurs the companion console
*should* pop up. Feel free to post these errors to this list so we can
fix them.

What's next:

I will be stabilizing the new release by fixing any reported errors
and streamlining the initial user experience. Once this is done I will
continue with the remainder of the features for the 1.0 release and
work on a proper skin. The final 1.0 release is at least 3 months
away, likely longer, but there will be regular releases as features
are completed and bugs are fixed.

It is my hope to reach a featureset that is beneficial on a daily
basis ASAP. Your feedback in terms of what is missing for you to use
Companion more is important to reach this milestone.

I hope things go smoothly with this first release. Enjoy!

Christoph

[Alessandro Curci]

Hello Christoph,
great news for devcomp 1.0, just I can't activate it because I haven't
Firefox 3.x installed on my laptop anymore.
There's any alternative way to get the email with the new activation link?

Best

Alessandro

[DeveloperCompanion Support]

On 11-05-11 1:52 AM, Alessandro Curci wrote:
> great news for devcomp 1.0, just I can't activate it because I haven't
> Firefox 3.x installed on my laptop anymore.
> There's any alternative way to get the email with the new activation link?

I'll push an update today that will allow you to email an activation
code to the address you used to register originally.

Looking forward to your feedback.

Christoph

--
-------------------------------------------
Christoph Dorn - www.developercompanion.com

[cFreed]

Hi,

Great to know we may use DeveloperCompanion anew, so I immediately
went to http://www.developercompanion.com, but:
- at first try, I simply got “502 Bad Gateway” error
- at second try, “PinfError: Cannot determine default PINF database
path as PINF_HOME and HOME environment variables are not set!”,
followed by a plenty of file-path.js:line-no mentions (I can send them
to you if useful)

Any further try currently causes the same!
What happens?

TIA

Fred

On May 11, 2:37 am, Christoph Dorn <christ...@christophdorn.com>
wrote:

[DeveloperCompanion Support]

Oh. What a great first impression ;)

Let me see what is wrong.

Christoph

On 11-05-11 10:56 AM, cFreed wrote:
> Hi,
>
> Great to know we may use DeveloperCompanion anew, so I immediately
> went to http://www.developercompanion.com, but:

> - at first try, I simply got �502 Bad Gateway� error
> - at second try, �PinfError: Cannot determine default PINF database
> path as PINF_HOME and HOME environment variables are not set!�,

[DeveloperCompanion Support]

Ok. That is fixed. Let me know what you think. Feel free to ping me on
skype: christophdorn

Christoph

--

[cFreed]

Not a skype user, so I answer here anew.
Yes, I get the page now, that's right!

Many thanks for your job

Fred

On May 11, 8:22 pm, DeveloperCompanion Support

<supp...@developercompanion.com> wrote:
> Ok. That is fixed. Let me know what you think. Feel free to ping me on
> skype: christophdorn
>
> Christoph
>
> On 11-05-11 11:13 AM, DeveloperCompanion Support wrote:
>
>
>
>
>
>
>
>
>
>
>
> > Oh. What a great first impression ;)
>
> > Let me see what is wrong.
>
> > Christoph
>
> > On 11-05-11 10:56 AM, cFreed wrote:
> >> Hi,
>
> >> Great to know we may use DeveloperCompanion anew, so I immediately

> >> went tohttp://www.developercompanion.com, but:
> >> - at first try, I simply got 502 Bad Gateway error
> >> - at second try, PinfError: Cannot determine default PINF database
> >> path as PINF_HOME and HOME environment variables are not set! ,

[DeveloperCompanion Support]

On 11-05-11 1:52 AM, Alessandro Curci wrote:

> great news for devcomp 1.0, just I can't activate it because I haven't
> Firefox 3.x installed on my laptop anymore.
> There's any alternative way to get the email with the new activation link?

I pushed a new update (rc14) which you can get by updating all add-ons
using the ff4 add-on manager. No need to restart :)

You can now open companion, click on "Account" and then "Activate this
client".

Please let me know if this works for you.

Christoph

[cFreed]

Hi Christoph,

Sorry to come back soon...
I think to have upgraded correctly (now with FirePHP server
0.0.0master1105101636 and DeveloperCompanion 1.0b1rc12).
But I don't get my logs display in the devcomp console, though in
Firebug Net tab I see the expected well known X-Wf-... headings!
For your information, I use the simple upgrade method.

What may be wrong?
TIA

Fred

[DeveloperCompanion Support]

I don't think the simple upgrade method is supported yet as I was
postponing that work until Firebug 1.8 is out. There is no reason why I
cannot bring it back sooner though to log to the companion console
(instead of firebug). I'll get that working ASAP.

I encourage you to try the new configuration. All you should need to do
is create a new workspace, insert your "Homepage URL" and paste the
generated code into your PHP code. Then click "Add Workspace". Once this
is done all logging should work.

Christoph

--

[DeveloperCompanion Support]

On 11-05-11 2:14 PM, DeveloperCompanion Support wrote:
> I don't think the simple upgrade method is supported yet as I was
> postponing that work until Firebug 1.8 is out. There is no reason why I
> cannot bring it back sooner though to log to the companion console
> (instead of firebug). I'll get that working ASAP.

Actually it **is** working with the simple upgrade.

The DeveloperCompanion Console should pop up with a bunch of messages
when you go to http://www.firephp.org/

Could you confirm that please.

If it does not work are there any errors in the error console or
anywhere else?

Christoph

[cFreed]

Thanks a lot for the quick responses: I'm impressed!

For the new configuration, I still hesitate now, since there are times
that I added a supplemental/external layer to call FIrePHP services:
it is deeply integrated to my own framework, and I didn't feel ready
enough yet to go back under the hood :-)
In any case, sure I will do it.

But just now, and for answer to your 2nd message: no, I do NOT see
ANYTHING in the devcomp console when going to http://www.firephp.org/.
With this url, as with my own tests, I only see expected headings in
the Firebug Net tab, and in any case I don't get any error message in
the Firebug console nor elsewhere...

Does this give you an idea?
TIA

Fred


On May 11, 11:25 pm, DeveloperCompanion Support

<supp...@developercompanion.com> wrote:
> On 11-05-11 2:14 PM, DeveloperCompanion Support wrote:
>
> > I don't think the simple upgrade method is supported yet as I was
> > postponing that work until Firebug 1.8 is out. There is no reason why I
> > cannot bring it back sooner though to log to the companion console
> > (instead of firebug). I'll get that working ASAP.
>
> Actually it **is** working with the simple upgrade.
>
> The DeveloperCompanion Console should pop up with a bunch of messages

> when you go tohttp://www.firephp.org/

[DeveloperCompanion Support]

> For the new configuration, I still hesitate now, since there are times
> that I added a supplemental/external layer to call FIrePHP services:
> it is deeply integrated to my own framework, and I didn't feel ready
> enough yet to go back under the hood :-)
> In any case, sure I will do it.

No rush, whenever you are ready. As you can see there are still some
kinks to iron out.

> But just now, and for answer to your 2nd message: no, I do NOT see
> ANYTHING in the devcomp console when going to http://www.firephp.org/.
> With this url, as with my own tests, I only see expected headings in
> the Firebug Net tab, and in any case I don't get any error message in
> the Firebug console nor elsewhere...
>
> Does this give you an idea?

Not, not yet. So you are testing this with FF 4.0.1 and Devcomp 1.0b1rc14?

Which OS are you on? Do you have other extensions installed? Could you
try with a fresh profile for ff4?

Christoph

[Alessandro Curci]

It worked perfectly and without complications, I've disabled and looks
like Narwhal for XULRunner isn't needed anymore, can you confirm that?

I'll check it against what used to work with pre 1.0 versions in the
next days and let you know if something pop ups.

Thank you for the speedy and great support Christoph.

Best

Alessandro

[Jeff]

There appears to be an issue with the display of groups.

With the logging code:
$group = $console->group('QUERY','QUERY')->open();
$console->label('WHERE')->log($where);
$console->label('SORT')->log($sort);
$console->label('SQL')->log($sql);
$group->close();

I'm getting the following in the console window:
http://dl.dropbox.com/u/23648271/group_broken.png

[DeveloperCompanion Support]

On 11-05-12 1:00 AM, Alessandro Curci wrote:
> It worked perfectly and without complications,

Ok. Good. Thanks for confirming.

> I've disabled and looks
> like Narwhal for XULRunner isn't needed anymore, can you confirm that?

That is correct. Only the single new extension is needed.

> I'll check it against what used to work with pre 1.0 versions in the
> next days and let you know if something pop ups.

Great!

> Thank you for the speedy and great support Christoph.

Thanks for the feedback.

Christoph

[DeveloperCompanion Support]

Taking a look today. Thanks for pointing this out.

Christoph

--

[cFreed]

> So you are testing this with FF 4.0.1 and Devcomp 1.0b1rc14?
>
> Which OS are you on? Do you have other extensions installed? Could you
> try with a fresh profile for ff4?

My OS is Win7 x64, and yes I'm using FF 4.0.1, and I did'nt try yet
with a fresh profile.
But I was remained at DevComp 1.0b1rc12, and things have changed since
I got rc14 in the DevComp console:
1. (don't know if significant) only the Clear button appears now
(previously I also had a Reload button)
2. like with rc12, none of my logs appear, but I always get the same
error message (once at each new page load)

Message is:
array(
map(
message=>Already parsing!,
fileName=>/__PWD__/resource:/jid1-devcomp-extension-ff4-devcomp-data/
packages.jar!/p3fab0ff862fc3b180e59de090c1a7ca6@/lib/channel,
lineNumber=>9,
stack=>([object Proxy],[object Proxy])@/__PWD__/resource:/jid1-devcomp-
extension-ff4-devcomp-data/packages.jar!/
p3fab0ff862fc3b180e59de090c1a7ca6@/lib/channel:9
@:0
,
name=>Error
)
)

May be this will bring more information?
TIA

Fred

[DeveloperCompanion Support]

On 11-05-12 11:50 AM, cFreed wrote:
> My OS is Win7 x64, and yes I'm using FF 4.0.1, and I did'nt try yet
> with a fresh profile.
> But I was remained at DevComp 1.0b1rc12, and things have changed since
> I got rc14 in the DevComp console:
> 1. (don't know if significant) only the Clear button appears now
> (previously I also had a Reload button)

I removed that as it is only relevant when working on companion.

> 2. like with rc12, none of my logs appear, but I always get the same
> error message (once at each new page load)
>
> Message is:
> array(
> map(
> message=>Already parsing!,
> fileName=>/__PWD__/resource:/jid1-devcomp-extension-ff4-devcomp-data/
> packages.jar!/p3fab0ff862fc3b180e59de090c1a7ca6@/lib/channel,
> lineNumber=>9,
> stack=>([object Proxy],[object Proxy])@/__PWD__/resource:/jid1-devcomp-
> extension-ff4-devcomp-data/packages.jar!/
> p3fab0ff862fc3b180e59de090c1a7ca6@/lib/channel:9
> @:0

Ah, I did not realize you were getting this error. I'll have a fix for
this with the next release.

Thanks!

Christoph

[DeveloperCompanion Support]

Just pushed an update: 1.0b1rc15

Use the Firefox add-ons manager to update the extension without restarting!

Changelog:

* Bugfix: Recover from parsing incorrectly formatted wildfire messages
* Enhancement: Server library upgrade message if incorrect 1.0
version used
* Enhancement: Method and status for requests in companion console
* Bugfix: Group display in companion console
* Enhancement: Better error messages to troubleshoot server requests

Any issues? Let me know.

Christoph

--

[DeveloperCompanion Support]

On 11-05-11 7:37 PM, Jeff wrote:

Should be fixed now. Let me know.

Thanks!
Christoph

[DeveloperCompanion Support]

There is a fox for this in 1.0b1rc15 now.

You may still get an error but it should not break all of companion any
more. Please let me know if it now works or what error you are getting.

Thanks!
Christoph

[cFreed]

Thanks for the quick reaction!
I got rc15 but infortunately, it doesn't work yet.

With rc14, I said I was getting one error message for each page loaded
(if I correctly observed...?).
But with rc15:
1. I get twice the [almost (see precision below)] same message. And it
is not exactly for each page loaded, but for each page which contains
headings for the DevComp console.
2. I continue not to get my logs.

The message is:
array(
Error parsing raw data, <<<< this line for the 1st message only
map(
message=>JSON.parse,
fileName=>/__PWD__/resource:/jid1-devcomp-extension-ff4-devcomp-data/
packages.jar!/p3fab0ff862fc3b180e59de090c1a7ca6@/lib/protocol,
lineNumber=>9,
stack=>@:0
,
name=>SyntaxError
)
)

TIA

Fred

[DeveloperCompanion Support]

Getting closer. I'll make that error more verbose so we can see what the
incoming JSON is that seems to be breaking things.

Thanks for continuing to troubleshoot this.

Christoph

--

[DeveloperCompanion Support]

Just pushed an update: 1.0b1rc16

Use the Firefox add-ons manager to update the extension without restarting!

Changelog:

* Bugfix: Don't show '@' in console for file/line if line is not
available
* Bugfix: Don't trim group titles
* Enhancement: Better error messages when parsing FirePHP <1.0 messages
* Bugfix: Renderer lookup logic for table cell values

Any issues? Let me know.

Christoph

--

[DeveloperCompanion Support]

Ok, let's try: 1.0b1rc16

Please send *all* errors you get for one request.

Do you have a simple test case I can try on my system?

Thanks!
Christoph

--

[Jeff]

Appears to be working now, thanks.

On May 12, 1:16 pm, DeveloperCompanion Support

[cFreed]

Hi Christoph,

Not "exactly" working yet, but good news.

With rc16, before the 2 error messages already mentioned, I get a
supplemental first error message, followed by a copy of the X-
Wf-1-1-1-1 heading:
array(
Error parsing JsonStream message,

map(
message=>JSON.parse,
fileName=>/__PWD__/resource:/jid1-devcomp-extension-ff4-devcomp-data/
packages.jar!/p3fab0ff862fc3b180e59de090c1a7ca6@/lib/protocol,
lineNumber=>9,
stack=>@:0
,
name=>SyntaxError

),
[{"Type":"LOG","Label":"mocs","File":"W:\\dispatcher.php(37) :
eval()'d code","Line":1},{null:null,"k&#257;te":"k&#257;te","k&#299;
\u009aaparte &#7779;ab&#257;tu ak&#257;lu ":"k&#299; \u009aaparte
&#7779;ab&#257;tu ak&#257;lu ","k&#299; \u009aaparte
\u009aak&#257;nu":"k&#299; \u009aaparte
\u009aak&#257;nu",null:null,"SAG-DU":"SAG-DU","\u008aU--TI":"\u008aU--
TI","\u009aulm&#257;nu":"\u009aulm&#257;nu"}]
)

As you can see, it contains a lot of special characters: normal, since
the involved project (I naturally selected it for test, because it is
my current work) handles texts from Sumerian, Babylonian and other
Assyrian eras.
Then I realized it could be the reason of the problem, and I tested
with another project: yes, when no special character happens, it works
fine!
Sorry not to have payed sufficient attention to this particularity,
till now.

BTW, now that I can look at DevComp normally working, I alert you on a
little inconvenience, in case of error reporting (from my own code).
When message is not open yet, title displays only the type and nature
of the error; alternatively, when open, it displays only the file-path
and line-no.
In my opinion, both are of first interest simultaneously.

In any case, many thanks.
Fred

On May 13, 2:41 am, DeveloperCompanion Support

[cFreed]

Sorry, I omitted to answer this:

> Do you have a simple test case I can try on my system?

No, not exactly

But I imagine you should take advantage of directly executing the
project where these %ù*$=)^:! characters happen :-)
So I updated an on-line version of this project with FirePHP 1.0.
If you find it useful, simply claim: I will give you the guidelines to
simply have a bunch of logs with these special characters.

Fred

[DeveloperCompanion Support]

Just pushed an update: 1.0b1rc17

Use the Firefox add-ons manager to update the extension without restarting!

Changelog:

* Enhancement: Show error message if reload status not 2xx or 'Parser
error' found in response
* Bugfix: Keep message title showing when expanding traces and exceptions
* Bugfix: Exception titles not showing with broken UI and traces
* Enhancement: Show included files for request

Any issues? Let me know.

Christoph

On 11-05-10 5:37 PM, Christoph Dorn wrote:

--

[DeveloperCompanion Support]

On 11-05-13 3:40 PM, cFreed wrote:
> With rc16, before the 2 error messages already mentioned, I get a
> supplemental first error message, followed by a copy of the X-
> Wf-1-1-1-1 heading:
> array(
> Error parsing JsonStream message,
> map(
> message=>JSON.parse,
> fileName=>/__PWD__/resource:/jid1-devcomp-extension-ff4-devcomp-data/
> packages.jar!/p3fab0ff862fc3b180e59de090c1a7ca6@/lib/protocol,
> lineNumber=>9,
> stack=>@:0
> ,
> name=>SyntaxError
> ),
> [{"Type":"LOG","Label":"mocs","File":"W:\\dispatcher.php(37) :
> eval()'d code","Line":1},{null:null,"k&#257;te":"k&#257;te","k&#299;

> \u009aaparte&#7779;ab&#257;tu ak&#257;lu ":"k&#299; \u009aaparte

> &#7779;ab&#257;tu ak&#257;lu ","k&#299; \u009aaparte
> \u009aak&#257;nu":"k&#299; \u009aaparte
> \u009aak&#257;nu",null:null,"SAG-DU":"SAG-DU","\u008aU--TI":"\u008aU--
> TI","\u009aulm&#257;nu":"\u009aulm&#257;nu"}]
> )
>
> As you can see, it contains a lot of special characters: normal, since
> the involved project (I naturally selected it for test, because it is
> my current work) handles texts from Sumerian, Babylonian and other
> Assyrian eras.
> Then I realized it could be the reason of the problem, and I tested
> with another project: yes, when no special character happens, it works
> fine!
> Sorry not to have payed sufficient attention to this particularity,
> till now.

Ah. That would be it. Should be no problem to fix. Great catch!

> BTW, now that I can look at DevComp normally working, I alert you on a
> little inconvenience, in case of error reporting (from my own code).
> When message is not open yet, title displays only the type and nature
> of the error; alternatively, when open, it displays only the file-path
> and line-no.

This was a bug. Fixes in rc17.

> In my opinion, both are of first interest simultaneously.

I have the file/line hidden by default at the moment. You can see it in
the table when expanding. Let's see how that goes first.

Christoph

[cFreed]

> Ah. That would be it. Should be no problem to fix. Great catch!

Hope so!

> > When message is not open yet, title displays only the type and nature
> > of the error; alternatively, when open, it displays only the file-path
> > and line-no.
> This was a bug. Fixes in rc17.

Ok, now the error keeps displayed with rc17.

> I have the file/line hidden by default at the moment. You can see it in
> the table when expanding. Let's see how that goes first.

Don't understand.
Unless I already forgot (aah... Alzheimer... :-) what I previously
saw:
. expanded table didn't change between rc16 and rc17: follows the
stack from bottom to top, and 1st line is only N-1 level
. file/line which appeared in title with rc16 was the exact point
(deepest N level) where the error occurs; this information is now
totally omitted, no?

In the other hand, I also noticed a strange behaviour when just
upgraded to rc17.
I upgraded without restarting FF, so DevComp console was already open
and I directly refreshed the tabs which contained my test projects.
Then:
1. all worked as if no upgrade had happen yet: displayed information
was in rc16 style, and DevComp window title displayed "rc16"
2. I closed DevComp window and refreshed my tabs anew: DevComp window
never re-opened
3. I had to close and restart FF to have DevComp window come back,
with rc17 title and contents

Fred

[DeveloperCompanion Support]

On 11-05-13 6:08 PM, DeveloperCompanion Support wrote:
> On 11-05-13 3:40 PM, cFreed wrote:
>> With rc16, before the 2 error messages already mentioned, I get a
>> supplemental first error message, followed by a copy of the X-
>> Wf-1-1-1-1 heading:
>> array(
>> Error parsing JsonStream message,
>> map(
>> message=>JSON.parse,
>> fileName=>/__PWD__/resource:/jid1-devcomp-extension-ff4-devcomp-data/
>> packages.jar!/p3fab0ff862fc3b180e59de090c1a7ca6@/lib/protocol,
>> lineNumber=>9,
>> stack=>@:0
>> ,
>> name=>SyntaxError
>> ),
>> [{"Type":"LOG","Label":"mocs","File":"W:\\dispatcher.php(37) :
>> eval()'d code","Line":1},{null:null,"k&#257;te":"k&#257;te","k&#299;
>> \u009aaparte&#7779;ab&#257;tu ak&#257;lu ":"k&#299; \u009aaparte
>> &#7779;ab&#257;tu ak&#257;lu ","k&#299; \u009aaparte
>> \u009aak&#257;nu":"k&#299; \u009aaparte
>> \u009aak&#257;nu",null:null,"SAG-DU":"SAG-DU","\u008aU--TI":"\u008aU--
>> TI","\u009aulm&#257;nu":"\u009aulm&#257;nu"}]
>> )

Looks like we have two issues here.

The JSON is not parsing because there are 'null:null' pairs in the data
object. This needs to be fixed in the PHP lib. Could you send me a
logging line that generates the above? I need to figure out where the
'null' is coming from for the key as I want to have a fix for that in
the library.

When I adjust the JSON to make it parse the characters are not displayed
properly in the console. I get:

http://screencast.com/t/Ka9zTApz2i4C

What do I need to do to have these display properly? What does the HTML
code have to be?

FYI, as you can see in the screenshot, %�*$=)^:! seems to work fine.

Christoph

[DeveloperCompanion Support]

On 11-05-13 7:14 PM, cFreed wrote:
>>> When message is not open yet, title displays only the type and nature
>>> of the error; alternatively, when open, it displays only the file-path
>>> and line-no.
>> This was a bug. Fixes in rc17.
> Ok, now the error keeps displayed with rc17.
>
>> I have the file/line hidden by default at the moment. You can see it in
>> the table when expanding. Let's see how that goes first.
> Don't understand.
> Unless I already forgot (aah... Alzheimer... :-) what I previously
> saw:
> . expanded table didn't change between rc16 and rc17: follows the
> stack from bottom to top, and 1st line is only N-1 level
> . file/line which appeared in title with rc16 was the exact point
> (deepest N level) where the error occurs; this information is now
> totally omitted, no?

Hmm. The top row in the table should be N, not N-1. That is the case for
me. If you find one where that is not the case, could you send me the
response headers.

> In the other hand, I also noticed a strange behaviour when just
> upgraded to rc17.
> I upgraded without restarting FF, so DevComp console was already open
> and I directly refreshed the tabs which contained my test projects.
> Then:
> 1. all worked as if no upgrade had happen yet: displayed information
> was in rc16 style, and DevComp window title displayed "rc16"
> 2. I closed DevComp window and refreshed my tabs anew: DevComp window
> never re-opened
> 3. I had to close and restart FF to have DevComp window come back,
> with rc17 title and contents

Ok. Will fix so all windows close during update for now.

Christoph

[cFreed]

> The JSON is not parsing because there are 'null:null' pairs in the data
> object. This needs to be fixed in the PHP lib. Could you send me a
> logging line that generates the above? I need to figure out where the
> 'null' is coming from for the key as I want to have a fix for that in
> the library.

Not sure to clearly understand what you need.
May be the best explanation is to show you the involved part of PHP
code:

# get words which are either independant or canonic stems:
# (in any case, they are NOT "childs" of a canonic stem)
$base_mocs=
sql_get_list('&moc','vernaculaire',null,'`&moc_row` IS NULL');
fp($base_mocs,'base_mocs');##
foreach($base_mocs as $moc) {
# build an equivalent array where key=value on each item, so it
may be
# furtherly replaced without changing its key when canonic
stems:
@$mocs[$moc]=$moc;
}
fp($mocs,'mocs');##

The log we are currently examining commes from the last line above,
where fp() is my own function to log through FirePHP; it is equivalent
to (FirePHPinstance)->log($mocs,'mocs');
Then you see that $mocs is an associated array, built from another
(simple) array, where each item takes its key form its own value.
So when an item is null in the source array, it leads to a null=>null
item in the target array, which itself begins a "null:null" pair when
JSON'ed.
Don't know if sufficiently clear?

> When I adjust the JSON to make it parse the characters are not displayed
> properly in the console. I get:
>
>    http://screencast.com/t/Ka9zTApz2i4C
>
> What do I need to do to have these display properly? What does the HTML
> code have to be?

IMO, this is not important, just for now.
I experienced several problems with this, since those characters come
from:
. user input (and then, depends on its own OS current configuration)
and/or
. already recorded data, which comes back from DB
For you to have an idea of what it should look like, here is the HTML
code when $mocs (see above) has been processed to finally generate a
<select> element:
http://www.screencast.com/users/cFreed/folders/Default/media/d8ebd415-f1a8-4c11-ba25-7598dd40314d
(part of the involved heading may be recognized beginning just under
the highlighted line)

> FYI, as you can see in the screenshot, % *$=)^:! seems to work fine.

Yes, I realize that I was wrong: the heading where the error lies is
not absolutely the 1st one, but the 1st one where null:null happens
(and special chars are present in precedent headings).

Fred

[cFreed]

> >> I have the file/line hidden by default at the moment. You can see it in
> >> the table when expanding. Let's see how that goes first.
> > Don't understand.
> > Unless I already forgot (aah... Alzheimer... :-) what I previously
> > saw:
> > . expanded table didn't change between rc16 and rc17: follows the
> > stack from bottom to top, and 1st line is only N-1 level
> > . file/line which appeared in title with rc16 was the exact point
> > (deepest N level) where the error occurs; this information is now
> > totally omitted, no?
>
> Hmm. The top row in the table should be N, not N-1. That is the case for
> me. If you find one where that is not the case, could you send me the
> response headers.

For me, it is always limited to N-1, with N visible only in the title,
as in the example showed here:
http://www.screencast.com/t/ciPMSIgqoO

In this case, the N level line should look like:
File: W:\objects\Url.php | Line: 38 (where the involved parse_url()
function locates)

Like already with FireConsole, this line logically doesn't appear in
the expanded table, because the "Instruction" field cannot be obtained
from (I suppose) debug_backtrace() or something equivalent: so for me
this is normal.
But the file/line info of this N level remains a important
information.

That is how I see that issue.

Fred

[DeveloperCompanion Support]

It should always show N in the table. Not N-1. Could you send me the
response headers for this request. If you have some PHP code that can
show the problem that would be good too.

Thanks!
Christoph

[cFreed]

> It should always show N in the table. Not N-1. Could you send me the
> response headers for this request.

For the exemple showed by my previous example (http://
www.screencast.com/t/ciPMSIgqoO), here are the headings:

X-Wf-Protocol-1 http://meta.wildfirehq.org/Protocol/JsonStream/0.2
X-Wf-1-Plugin-1 http://meta.firephp.org/Wildfire/Plugin/FirePHP/Library-FirePHPCore/0.0.0master1105101636
X-Wf-1-Structure-1 http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1
X-Wf-1-1-1-1 785|[{"Type":"EXCEPTION","File":"W:\\objects\
\Url.php","Line":38},{"Class":"ErrorException","Message":"E_WARNING:
parse_url(http:\/\/\/www.reseau-quetelet.cnrs.fr\/spip\/styles\/
spip_style_site.css) [<a href='function.parse-url'>function.parse-url<
\/a>]: Unable to parse URL","File":"W:\\objects\\Url.php","Line":
38,"Type":"trigger","Trace":[{"file":"W:\\objects\\Html.php","line":
981,"function":"build_url","class":"Url","type":"::","args":["http:\/\/
\/www.reseau-quetelet.cnrs.fr\/spip\/styles\/spip_style_site.css"]},
{"file":"Q:\\html_begin.php","line":
25,"function":"add_link","class":"Html","type":"->","args":["http:\/\/
\/www.reseau-quetelet.cnrs.fr\/spip\/styles\/spip_style_site.css"]},
{"file":"Q:\\quetelet.php","line":6,"args":["Q:\
\html_begin.php"],"function":"require_once"}]}]|
X-Wf-1-Index 3
X-Wf-1-1-1-2 782|[{"Type":"EXCEPTION","File":"W:\\objects\
\Url.php","Line":38},{"Class":"ErrorException","Message":"E_WARNING:
parse_url(http:\/\/\/www.reseau-quetelet.cnrs.fr\/spip\/styles\/
styleaffichage.css) [<a href='function.parse-url'>function.parse-url<\/
a>]: Unable to parse URL","File":"W:\\objects\\Url.php","Line":
38,"Type":"trigger","Trace":[{"file":"W:\\objects\\Html.php","line":
981,"function":"build_url","class":"Url","type":"::","args":["http:\/\/
\/www.reseau-quetelet.cnrs.fr\/spip\/styles\/styleaffichage.css"]},
{"file":"Q:\\html_begin.php","line":
26,"function":"add_link","class":"Html","type":"->","args":["http:\/\/
\/www.reseau-quetelet.cnrs.fr\/spip\/styles\/styleaffichage.css"]},
{"file":"Q:\\quetelet.php","line":6,"args":["Q:\
\html_begin.php"],"function":"require_once"}]}]|
X-Wf-1-1-1-3 752|[{"Type":"EXCEPTION","File":"W:\\objects\
\Url.php","Line":38},{"Class":"ErrorException","Message":"E_WARNING:
parse_url(http:\/\/\/www.reseau-quetelet.cnrs.fr\/spip\/styles\/
menu.css) [<a href='function.parse-url'>function.parse-url<\/a>]:
Unable to parse URL","File":"W:\\objects\\Url.php","Line":
38,"Type":"trigger","Trace":[{"file":"W:\\objects\\Html.php","line":
981,"function":"build_url","class":"Url","type":"::","args":["http:\/\/
\/www.reseau-quetelet.cnrs.fr\/spip\/styles\/menu.css"]},{"file":"Q:\
\html_begin.php","line":
27,"function":"add_link","class":"Html","type":"->","args":["http:\/\/
\/www.reseau-quetelet.cnrs.fr\/spip\/styles\/menu.css"]},{"file":"Q:\
\quetelet.php","line":6,"args":["Q:\
\html_begin.php"],"function":"require_once"}]}]|

The image shows only the first DevComp displayed block, corresponding
to the first heading above: you see that it's 3 times the same.

> If you have some PHP code that can
> show the problem that would be good too.

I don't see how to better illustrate this case: the only significant
thing is the malformed url transmitted to parse_url(), which causes
the error to happen.
How deep is the function calls stack doesn't matter, no? And I seem
that passing to you some hundreds of PHP lines which compose this
stack context has no sense.

But may be I'm wrong: don't hesitate to correct me.

Fred

[cFreed]

Two little issues I noticed...

When closing the main FF window, the DevComp window remains open: if I
omit to close it first, it is the one FF remembers.
So next time FF is launched, it uses its postion and size... and you
guess they are not the ones I wish for my main FF window :-)

In the other hand, when both main FF and DevComp windows are open, if
I close the DevComp one, it is not re-opened when loading a page with
FirePHP logs.
Like already reported about the upgrade process, only closing and re-
opening FF makes DevComp window appear anew.

Thanks for your attention.

Fred

[cFreed]

> In the other hand, when both main FF and DevComp windows are open, if
> I close the DevComp one, it is not re-opened when loading a page with
> FirePHP logs.
> Like already reported about the upgrade process, only closing and re-
> opening FF makes DevComp window appear anew.

Just tried anew, and now DevComp window does NOT omit to re-open!
So, sure that what I reported doesn't happen systematically.
Sorry for the false alert.
I will try to identify where and how it may happen...

Fred

[DeveloperCompanion Support]

Just pushed an update: 1.0b1rc18

Use the Firefox add-ons manager to update the extension without restarting!

Changelog:

* Enhancement: Editable request URL that sends "GET" request on enter
* Enhancement: Remember companion window and console position and size
* Change: Increased padding of table cells
* Change: Always close Companion window and console when last firefox
window is closed
* Bugfix: HTTPS support
* Bugfix: Always show parser errors when reloading request (even if
insight did not respond in headers)
* Bugfix: Close all windows when unloading/updating
* Bugfix: Workspace detection from some URLs
* Bugfix: Resize tab bars when window is being resized

[DeveloperCompanion Support]

On 11-05-15 12:26 PM, cFreed wrote:
> When closing the main FF window, the DevComp window remains open: if I
> omit to close it first, it is the one FF remembers.
> So next time FF is launched, it uses its postion and size... and you
> guess they are not the ones I wish for my main FF window :-)

In rc18 I now keep the dimensions of the companion window and console. I
also close the companion window and console when the last ff window closes.

For me this now has the desired effect most of the time where the
dimensions of the last FF window are remembered. I have made a note to
make this more reliable and should have a solution soon.

Christoph

[DeveloperCompanion Support]

On 11-05-14 11:18 AM, cFreed wrote:
>> The JSON is not parsing because there are 'null:null' pairs in the data
>> object. This needs to be fixed in the PHP lib. Could you send me a
>> logging line that generates the above? I need to figure out where the
>> 'null' is coming from for the key as I want to have a fix for that in
>> the library.
> Not sure to clearly understand what you need.
> May be the best explanation is to show you the involved part of PHP
> code:
>
> # get words which are either independant or canonic stems:
> # (in any case, they are NOT "childs" of a canonic stem)
> $base_mocs=
> sql_get_list('&moc','vernaculaire',null,'`&moc_row` IS NULL');
> fp($base_mocs,'base_mocs');##
> foreach($base_mocs as $moc) {
> # build an equivalent array where key=value on each item, so it
> may be
> # furtherly replaced without changing its key when canonic
> stems:
> @$mocs[$moc]=$moc;
> }
> fp($mocs,'mocs');##

Please send me a var_dump() and var_export() of $mocs;

Also please confirm that the same issue exists if you call:

fp(var_export($mocs),'mocs');

If not, I need to know which line in FirePHP.class.php is writing "null"
as the key in the JSON. (I also need the server library version).

Thanks!
Christoph

[cFreed]

> Please send me a var_dump() and var_export() of $mocs;

var_dump():
array(8) { ["ana MÁŠ DU"]=> string(10) "ana MÁŠ DU" ["kāte"]=>
string(9) "kāte" ["kī šaparte ṣabātu akālu "]=> string(45) "kī šaparte
ṣabātu akālu " ["kī šaparte šakānu"]=> string(27) "kī šaparte
šakānu" ["leqû"]=> string(4) "leqû" ["SAG-DU"]=> string(6) "SAG-
DU" ["ŠU--TI"]=> string(6) "ŠU--TI" ["šulmānu"]=> string(12)
"šulmānu" } bool(true)

var_export():
array ( 'ana MÁŠ DU' => 'ana MÁŠ DU', 'kāte' => 'kāte', 'kī šaparte
ṣabātu akālu ' => 'kī šaparte ṣabātu akālu ', 'kī šaparte šakānu' =>
'kī šaparte šakānu', 'leqû' => 'leqû', 'SAG-DU' => 'SAG-DU', 'ŠU--TI'
=> 'ŠU--TI', 'šulmānu' => 'šulmānu', )

Wow: you catch something more here.
Beyond what I explained on how $mocs is built, it appears that in this
case its first item does NOT contain a null=>null pair!
Then I'm puzzled: how could it be substituted to the original value?
...

Well, at this point, I had an idea and tested deeper.

I noticed that in fact even $base_mocs (the original simple array) had
its first item null too.
And I realized that the null value already appeared in the headings:
so the original issue is in FirePHP server, not in the companion.

Finally I found that the problem comes from certain item contents: for
the current case, "ana MÁŠ DU" is replaced by null, due to the "Á"
character (&#193, or &Aacute;). When replacing it by "ana MŠ DU", its
content is well rendered.
I also found that the "û" character (&#251;, or &ucirc;) does the
same. Sure there are other ones... can't figure out why some special
chars cause the problem and other ones no...

This image illustrate all of that: http://www.screencast.com/t/TehhhUES

Fred

[rgoula]

Things weren't working for me at first, but I didn't have much time to
see what was going on. I was extremely happy to see that this morning
when I updated the addon, it is now usable for me, and working well.
My only gripe with it is the new Companion Console that I am getting
instead of the integration I previously had with FireBug's console. I
mostly dump information to tabs, but some things I was still putting
in the main console. I'm assuming this was done for a deeper reason
and I will just have to get used to it.

On a side note though, the request history doesn't always seem to
update on switch. Most of the time it did, but a simple reload
corrected the tabs when it stuck. Not a big deal, but I figured it
was worth mentioning. Great job, things are moving along very nicely
(rc18).

Robert

On May 12, 8:39 pm, DeveloperCompanion Support

[DeveloperCompanion Support]

On 11-05-16 7:06 AM, rgoula wrote:
> Things weren't working for me at first, but I didn't have much time to
> see what was going on. I was extremely happy to see that this morning
> when I updated the addon, it is now usable for me, and working well.

Good to hear.

> My only gripe with it is the new Companion Console that I am getting
> instead of the integration I previously had with FireBug's console. I
> mostly dump information to tabs, but some things I was still putting
> in the main console. I'm assuming this was done for a deeper reason
> and I will just have to get used to it.

There is a reason. DeveloperCompanion is now built on top of jetpack,
mozilla's new add-on SDK, [1] which allows restartless extensions.

The problem is Firebug 1.7 does not allow for restartless registering of
extensions which should work again with Firebug 1.8. So I will bring
logging to the Firebug Console back again as soon as Firebug supports
what I need (I am working with the Firebug folks on that).

Having it log to the Companion Console is an iterim solution although I
am starting to like it better than the Firebug Console. I'll likely add
a preference that will allow you to select where you want the 'page'
context messages to appear.

> On a side note though, the request history doesn't always seem to
> update on switch. Most of the time it did, but a simple reload
> corrected the tabs when it stuck. Not a big deal, but I figured it
> was worth mentioning.

Thanks for pointing this out. I'll take a look. If you notice any
pattern let me know.

> Great job, things are moving along very nicely (rc18).

Now that the core stuff is working I'll be bringing the 'on'
functionality back, then continue with the other features for 1.0 [2].

Christoph

[1] - https://jetpack.mozillalabs.com/
[2] - http://developercompanion.com/

[DeveloperCompanion Support]

Good catch. Unfortunately I cannot reproduce the issue as I cannot get a
null key for the array no matter what I do.

That does not matter though as you can obviously reproduce the error and
test a fix. I am going to add a check to ensure all keys are always
strings. Could you please change the following in your copy and test to
make sure that a null key is now properly sent and displayed.

Insert:

if ($key === null) {
$key = "null";
}

At:

https://github.com/cadorn/firephp-libs/blob/master/packages/core/lib/FirePHPCore/FirePHP.class.php#L1401

Thanks!
Christoph

> character (&#193, or&Aacute;). When replacing it by "ana MŠ DU", its
> content is well rendered.
> I also found that the "û" character (&#251;, or&ucirc;) does the

> same. Sure there are other ones... can't figure out why some special
> chars cause the problem and other ones no...
>
> This image illustrate all of that: http://www.screencast.com/t/TehhhUES
>
> Fred
>

--

[DeveloperCompanion Support]

Just pushed an update: 1.0b1rc19

Use the Firefox add-ons manager to update the extension without restarting!

Changelog:

* Change: Launch Companion window with first browser window if it was
open with last browser window
* Change: Add '/' at beginning of paths in application requests table
* Change: Expand request in companion console if error present
* Bugfix: Save dimensions of last browser window and apply to first
browser window
* Bugfix: Show file and line of exception/error source when logging
via FirePHPCore

You will need to update your FirePHP lib as well.

Christoph

--

[DeveloperCompanion Support]

This should be fixed now (rc19). You should see an extra line at the top
of the table with the file and line info of where the error was triggered.

Thanks!
Christoph

--

[cFreed]

> Good catch. Unfortunately I cannot reproduce the issue as I cannot get a
> null key for the array no matter what I do.

I'm surprised: if you write $FP->log(array('ana MÀŠ DU'=>'ana MÀŠ
DU')), do you get "ana MÀŠ DU":"ana MÀŠ DU" in your heading rather
than null:null?
For me, any key containing a "À" turns my headings to null.

> That does not matter though as you can obviously reproduce the error and
> test a fix. I am going to add a check to ensure all keys are always
> strings. Could you please change the following in your copy and test to
> make sure that a null key is now properly sent and displayed.
>
> Insert:
>
>    if ($key === null) {
>      $key = "null";
>    }
>

I inserted the above code at line 1401, and the involved headings
didn't change! continues to contain null rather than "null".
So I first imagined that the null key I got in the heading were
substituted to the original key in a further step of the process.
Seems to be true, since I tried with a *really* null original key,
like fp(null=>'ana MÀŠ DU'), and the heading is "":null!

In other words:
1. a *really* null key appears as '' (empty string) in the heading,
rather than "null" as it should with the above patch!
2. a null key, when generated by the problem (in place of the original
'ana MÀŠ DU' key), appears as null (the word null without quotes)
3. the presence of the special character "À" leads to different
results, depending on where it lies:
3-1. fp('ana MÀŠ DU'') --> all correct
3-2. fp(array(null=>'ana MÀŠ DU') --> "":null in heading -->
DevComp renders it conforming to the heading: array(''=>NULL)
3-3. fp(array('ana MÀŠ DU'=>'ana MÀŠ DU') -->null:null in heading
--> DevComp fires the well known triple error message

No more hair on my head, now... and what about you? :-)

Fred

[cFreed]

> This should be fixed now (rc19). You should see an extra line at the top
> of the table with the file and line info of where the error was triggered.

Yes, it works fine!

BTW, with last FirePHP version and rc19, nothing changed for the null-
key issue :-(

Fred

[DeveloperCompanion Support]

So we have established that some special characters in the key cause the
key to become null. Based on what we know I now suspect the UTF8
encoding function or the JSON encoding.

Please take a look at:

https://github.com/cadorn/firephp-libs/blob/master/packages/core/lib/FirePHPCore/FirePHP.class.php#L1413

And

https://github.com/cadorn/firephp-libs/blob/master/packages/core/lib/FirePHPCore/FirePHP.class.php#L1241

Now I don't know if you are using the native encoding function or the
bundled one. I suspect one or both have a bug.

Let me know which one causes the null key.

FYI. I do not think this issue exists with the Insight API (and improved
variable encoder) as keys are handled differently, but if it is the UTF8
encoding step then it will have the same issue.

Thanks
Christoph

--

[cFreed]

> So we have established that some special characters in the key cause the
> key to become null. Based on what we know I now suspect the UTF8
> encoding function or the JSON encoding.
>
> Please take a look at:
>

> https://github.com/cadorn/firephp-libs/blob/master/packages/core/lib/...
>
> And
>
> https://github.com/cadorn/firephp-libs/blob/master/packages/core/lib/...

BTW, I don't understand: my onw version of FirePHP
(0.0.0master1105161440-firephp) is not the same as the online one you
pointed above; for me, at line 1401 are the lines you proposed to
insert into the previous version, 3 days ago:

if ($key === null) {
$key = "null";
}

(and I insist: it is not my own addition but what I downloaded as is)

> Now I don't know if you are using the native encoding function or the
> bundled one. I suspect one or both have a bug.
>
> Let me know which one causes the null key.

I verified and noticed I use the native JSON encoding function.
Based on this, you may observe the results of some of my supplemental
tests: http://www.screencast.com/t/BLK6YfZPRZp.
Left part is from my own test console:
. the upper block under "Code" gives results showed under "Results"
below
. the lower blokc under "Code" invokes FirePHP
In the right part are the DevComp corresponding results.

We observe that, directly invoked after utf8_encode() of the involved
data, json-encode() gives a correct result.
In the other hand, when data is already converted to utf8, DevComp
also gives a correct result, while receiving iso data, it shows null.
(I didn't include the case of an array(iso,iso), since we know that it
causes DevComp to ONLY fire its errors)

So it seems to mean that utf8 encoding should be the guilty. But I see
that FirePHP uses the native utf8_encode() function, like in the above
reported tests!
So what? Again, at this point, I feel stuck...

> FYI. I do not think this issue exists with the Insight API (and improved
> variable encoder) as keys are handled differently, but if it is the UTF8
> encoding step then it will have the same issue.

As already said, I temporarily differ toggling to full integration.
But I want to thank you for the license I received today: it's very
nice!
Thanks anew!

Fred

[DeveloperCompanion Support]

Just pushed an update: 1.0b1rc20

Use the Firefox add-ons manager to update the extension without restarting!

Changelog:

* Enhancement: Terms in compare editions dialog
* Enhancement: Terms before purchasing dialog
* Change: New 7 day trial for everyone
* Bugfix: Premature trial expire
* Bugfix: Launch arrow not hiding on multiple windows
* Bugfix: Window height creep every time window is opened

Christoph

--

[DeveloperCompanion Support]

On 11-05-17 5:36 PM, cFreed wrote:
>> Please take a look at:
>> https://github.com/cadorn/firephp-libs/blob/master/packages/core/lib/...
>> And
>> https://github.com/cadorn/firephp-libs/blob/master/packages/core/lib/...
>
> BTW, I don't understand: my onw version of FirePHP
> (0.0.0master1105161440-firephp) is not the same as the online one you
> pointed above; for me, at line 1401 are the lines you proposed to
> insert into the previous version, 3 days ago:
> if ($key === null) {
> $key = "null";
> }
> (and I insist: it is not my own addition but what I downloaded as is)

I forgot to push the latest changes. Sorry. They are there now (I
removed those 3 lines again).

> So it seems to mean that utf8 encoding should be the guilty. But I see
> that FirePHP uses the native utf8_encode() function, like in the above
> reported tests!
> So what? Again, at this point, I feel stuck...

Me too. I cannot even reproduce the issue you are seeing.

The only other idea I have is to try:

mb_convert_encoding($key, 'UTF-8')

instead of utf8_encode().

As for a hack solution we have two options:

1) Check for null after the encoding and encode the key differently
(maybe via json_encode() if that output is UTF-8) if null. That way we
still get something to the client other than null.
2) Repair the JSON on the client before parsing

I would prefer (1).

Could you see if mb_convert_encoding() resolves the issue and if not or
if you do not have it installed could you try and get option (1) working?

>> FYI. I do not think this issue exists with the Insight API (and improved
>> variable encoder) as keys are handled differently, but if it is the UTF8
>> encoding step then it will have the same issue.
>
> As already said, I temporarily differ toggling to full integration.

Right. I am keeping you informed about the differences.

> But I want to thank you for the license I received today: it's very
> nice!
> Thanks anew!

You are welcome. Thanks for your assistance in troubleshooting this.

Christoph

[cFreed]

Hi Christoph,

Sorry for the silence: I w

On May 19, 5:47 pm, DeveloperCompanion Support

[cFreed]

Uh! Sorry for the previous post: sent by itself :-)

So, I said: sorry for the silence, I was totally occupied by a little
but urgent problem.

Now I tested anew, and I'm getting a different conclusion than the
previous one, but at least it seems to be a certitude: the guilty is
not utf8_encode(), but is_utf8()!
More precisely, mb_detect_encoding() as well as the alternative test
you propose both consider the given data *is* utf8!

But they are not *really* guilty, and it's where things turn puzzling
anew: examining detail of ISO-8859-1 charset (the one used in the
involved project), I realized that it SHOULD NOT handle some of the
characters which create the problem!
But sure they do, since the project itself works fine.
In any case, it seems logic that the pointed characters make the
entire string considered as utf8: then no utf8_encode() happens, and
json_encode() cannot work properly.

This was only to give you news, since : for now, I will continue to
investigate...

Fred

[DeveloperCompanion Support]

I don't think we will ever detect encodings accurately 100% of the time.
The is_utf8() method has gotten significant attention and
troubleshooting in the past and the current implementation is the result
of that.

For FirePHP < 1.0 I could add a flag to force UTF-8 encoding for all
strings and for FirePHP 1.0+ I could add an encoding method to the
Insight API so strings can be selectively force encoded.

These could be workarounds until maybe a reliable detection solution
comes around.

What do you think?

Christoph

--

[cFreed]

> I don't think we will ever detect encodings accurately 100% of the time.

I agree. Sigh!

> These could be workarounds until maybe a reliable detection solution
> comes around.

I seem it will not be necessary, since I finally found a solution.
May be you'll think it is a strange one: feel free to criticize it.
Its main disadvantage is that it causes json_encode to be executed
twice for each involved element.
For the rest, as far as I could investigate, it seems to always work
fine.

It's based on the fact that, when no error happens, json-encode
returns "null" only for a null string.
So the method I propose (also designed to be as little invasive as
possible against the existing code) is only modify the is_utf8()
function as follows:

- line 1441, replace:
return (mb_detect_encoding($str, 'UTF-8', true) == 'UTF-8');
by
return
(mb_detect_encoding($str, 'UTF-8', true) == 'UTF-8')
and
($str===null or $this->jsonEncode($str,true)!=='null')
;

- (old) line 1466, replace:
return true;
by
return ($str===null or $this->jsonEncode($str,true)!=='null');

In addition, since the function now calls $this->jsonEncode(), it
cannot be static any longer (line 1438), and so it must be now called
as $this->is_tuf8() rather than self::is_utf8() (lines 1416 and 1423).

With these changes, I now get all working without any error, as
illustrated by the logs sequence where I originally encountered the
error: http://www.screencast.com/t/fMczTsIfGE.

Let me know what you think!

BTW, I noticed two little things:
1. I'm pleased to have logs displayed into the Firebug console anew
(for me, more convenient since I prefer to toggle between tabs rather
than between windows); but the DevComp window keeps opening at first
FP->log() call (and remains empty, of course) even when FB console tab
is enabled.
2. currently, when expanding a log result, its label (if any) doesn't
appear in title

Fred

[DeveloperCompanion Support]

On 11-05-25 4:59 PM, cFreed wrote:
> - line 1441, replace:
> return (mb_detect_encoding($str, 'UTF-8', true) == 'UTF-8');
> by
> return
> (mb_detect_encoding($str, 'UTF-8', true) == 'UTF-8')
> and
> ($str===null or $this->jsonEncode($str,true)!=='null')
> ;
>
> - (old) line 1466, replace:
> return true;
> by
> return ($str===null or $this->jsonEncode($str,true)!=='null');
>
> In addition, since the function now calls $this->jsonEncode(), it
> cannot be static any longer (line 1438), and so it must be now called
> as $this->is_tuf8() rather than self::is_utf8() (lines 1416 and 1423).
>
> With these changes, I now get all working without any error, as
> illustrated by the logs sequence where I originally encountered the
> error: http://www.screencast.com/t/fMczTsIfGE.
>
> Let me know what you think!

Looks good enough. Can you send me the whole modified FirePHP file? It
will make it much easier for me to merge the changes.

> BTW, I noticed two little things:
> 1. I'm pleased to have logs displayed into the Firebug console anew
> (for me, more convenient since I prefer to toggle between tabs rather
> than between windows); but the DevComp window keeps opening at first
> FP->log() call (and remains empty, of course) even when FB console tab
> is enabled.

Can you send me the response headers for a request that opens the
console. If the messages are going to the firebug console the companion
console should not open.

> 2. currently, when expanding a log result, its label (if any) doesn't
> appear in title

Can you be more specific. Which label?

When a message is expanded the summary line is removed (and expanded
below) and replaced with the file and line info. What do you expect?

Christoph

[cFreed]

> Looks good enough. Can you send me the whole modified FirePHP file? It
> will make it much easier for me to merge the changes.

Here it is: http://www.screencast.com/t/CeVpxLUrXd.

> Can you send me the response headers for a request that opens the
> console. If the messages are going to the firebug console the companion
> console should not open.

Sorry, you're right: seems that now it doesn't open any longer.
I had it opened only at first log() just after upgrading to rc29.

> > 2. currently, when expanding a log result, its label (if any) doesn't
> > appear in title
>
> Can you be more specific. Which label?

The 2nd argument in log($data,$label).

> When a message is expanded the summary line is removed (and expanded
> below) and replaced with the file and line info. What do you expect?

It's illustrated by the image at http://www.screencast.com/t/CeVpxLUrXd

Fred

[DeveloperCompanion Support]

On 11-05-26 12:10 PM, cFreed wrote:
>> Looks good enough. Can you send me the whole modified FirePHP file? It
>> will make it much easier for me to merge the changes.
>
> Here it is: http://www.screencast.com/t/CeVpxLUrXd.

Thanks! Will be in next release.

>>> 2. currently, when expanding a log result, its label (if any) doesn't
>>> appear in title
>>
>> Can you be more specific. Which label?
>
> The 2nd argument in log($data,$label).
>
>> When a message is expanded the summary line is removed (and expanded
>> below) and replaced with the file and line info. What do you expect?
>
> It's illustrated by the image at http://www.screencast.com/t/CeVpxLUrXd

Ah, of course. Will have a fix in next release.

Thanks!
Christoph

[cFreed]

> > Here it is:http://www.screencast.com/t/CeVpxLUrXd.
>
> Thanks! Will be in next release.

Glad to help.

> > It's illustrated by the image athttp://www.screencast.com/t/CeVpxLUrXd

>
> Ah, of course. Will have a fix in next release.

Right, not a big issue.

On the other hand, unfortunately, I get a new strange behaviour with
0.0.0master1105261453-firephp and DevComp rc31.
Expanding a message doesn't show its contents, which seem empty.
Note that only a simple array shows the presence of differents items
(even if each item appears empty too), while associated ones show
nothing.
This is illustrated here: http://www.screencast.com/t/Tfei1J9QFdj.

Fred

[DeveloperCompanion Support]

On 11-05-27 8:36 AM, cFreed wrote:
> On the other hand, unfortunately, I get a new strange behaviour with
> 0.0.0master1105261453-firephp and DevComp rc31.
> Expanding a message doesn't show its contents, which seem empty.
> Note that only a simple array shows the presence of differents items
> (even if each item appears empty too), while associated ones show
> nothing.
> This is illustrated here: http://www.screencast.com/t/Tfei1J9QFdj.

I cannot reproduce this. Have you tried restarting firefox / computer
just in case?

The Companion Console opening is a good thing as it is trying to log an
error, but the error not showing up in the console is not a good thing :(

Please send me the response headers for the request.

Also, please use the FirePHP.class.php code you sent me to see if the
problem goes away. If it does send me the response headers for this
request as well.

Is anyone else having an issue where the variables do not show when
expanding?

Thanks!
Christoph

[cFreed]

Very much puzzling...

First, the good news: it now works! And no need to restart FF nor the
computer.

Then, some points of interest about what happened previously:
1. the test occured JUST AFTER upgrading to rc31
2. now that it works, I see that label is well displayed when
expanding message; but on my previous screenshot http://www.screencast.com/t/Tfei1J9QFdj,
you may observe that the label was not displayed: looks like if rc31
was not used yet (but its window title cites "rc31")
3. looking for the headers as you claimed, I saw that also the
previous FirePHPCore version (1105161440 with my own adds) was cited
on "X-Wf-1-Plugin-1" line
4. and when I tried *really* using this previous version of FirePHP,
of course the headers didn't change, but also I didn't get the
previous error
5. returning to the latest FirePHP version, I got all working fine,
with only the "X-Wf-1-Plugin-1" citation changed in headers

From that, I suspect 2 things:
1. I seem the DevComp version might be guilty, rather than the FirePHP
one
2. and something might turn wrong yet in the upgrade process (look at
my previous post May 14, 4:14 am above)

BTW, what should be useful is the ability to go back to an older
DevComp version: in the current case, using rc29. But I have no idea
how it would be possible?

Ha, may be another interesting point, if the ugrade process is really
involved: I passed directly from rc29 to rc31.

Ha (2 :-), in extremis, by chance I just observed another thing.
Having my Firebug window accidently closed I reopened it, WITHOUT any
web page update, and the messages in Firebug console have changed!
Now labels are displayed the same way when message is expanded or
collapsed (sure it's what you expected :-)
But before ithe window was closed and reopened, the label appeared
right-justified in light font-weight without background-color, exactly
the same as the file/line!

So, to be more clear, the same logs sequence did successively render:
. just after upgrading from rv29 to rc31 -> no label displayed
. after updating the web page -> label displayed in right/light mode
. after closing/opening the Firebug window -> label displayed in left/
background mode

Pfff :-)

Hope this helps!

Fred

[DeveloperCompanion Support]

On 11-05-27 11:47 AM, cFreed wrote:
> First, the good news: it now works! And no need to restart FF nor the
> computer.

Great!

> 2. and something might turn wrong yet in the upgrade process (look at
> my previous post May 14, 4:14 am above)

I have made a few improvements to the upgrade process but there are
still some caching issues. What you are observing is the various caches
flushing. I hope to review this again soon.

> BTW, what should be useful is the ability to go back to an older
> DevComp version: in the current case, using rc29. But I have no idea
> how it would be possible?

I have made a note to add a section on the support page in the companion
window to display the changelog with links to download the various versions.

For now you can go to http://developercompanion.com/ and modify the
install link for the button to the version you want.

> Ha, may be another interesting point, if the ugrade process is really
> involved: I passed directly from rc29 to rc31.

That is fine. It will always grab the latest and sometimes I make a few
releases in short succession.

Thanks!
Christoph