Contributing Advent 1: Xdebug and hidden properties
Today starts the "contributing advent" with a nice bug from Xdebug. I can't possibly be fixing an issue every day, so I've started a while earlier.
This first contribution is for bug #987: "Hidden property names not shown". In PHP it is possible to convert an array to an object with:
<?php $a = (object) [ "hello", 4 => "mr.", -8 => "elephpant" ]; var_dump( $a ); ?>
Xdebug's standard HTML var_dump() as well as the CLI, the coloured CLI and the debugger interface DBGp all suffered from the same issues that numerical properties were not showing in output. For example the above would show:
class stdClass#1 (3) {
string(5) "hello"
string(3) "mr."
string(9) "elephpant"
}
After the committed fix, it now shows:
class stdClass#1 (3) {
public ${0} =>
string(5) "hello"
public ${4} =>
string(3) "mr."
public ${-8} =>
string(9) "elephpant"
}
As you can see, it uses {…} to show it is a special property.
The debugger interface allows properties to be retrieved through the property_get command. This command returns an XML document that looks like:
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="property_get" transaction_id="4">
<property name="$o" fullname="$o" address="" type="object" classname="stdClass" children="1" numchildren="6" page="0" pagesize="32">
<property name="key" fullname="$o->key" facet="public" address="" type="string" size="5" encoding="base64">
<![CDATA[dmFsdWU=]]>
</property>
<property name="1" fullname="$o->1" facet="public" address="" type="int">
<![CDATA[0]]>
</property>
</property>
</response>
With the fullname property ($o->1) an IDE can then make further requests to dive into the property information, with:
property_get -i 42 -n $o->1
Initially that did not work, and I thought I had to extend the parser with additional rules to differentiate between an associative key and a numerical key. I came up with using $o->{1} as in the var_dump() output from above, and then using a special case to fetch a numerical property with zend_hash_index_find() and the integer value in between { and } instead of the zend_hash_find() that I normally use. An hour later I had implemented this and then came to the conclusion that I could just use zend_symtable_find() — which handles both numerical indexes as strings as well as associate indexes as strings, greatly simplifying the implementation. The change for the debugging interface was not more than: https://github.com/xdebug/xdebug/commit/4d8d5b7092f134e6e5a51a0ea2e6932930a29da9#diff-07a70c2afd727f925169e8b30f1c72dcL455
After adding six test cases, the issues is now resolved.
Life Line
Updated a bus_stop, a waste_basket, and a bench
Created 2 waste_baskets; Updated 2 bus_stops and a crossing; Confirmed a dry_cleaning shop
Merge branch 'v2022'
Update data to 2026a
Sigh, the AI Slop has now come for the PHP project.
I had this little Black-capped Chickadee eating out of my hand earlier on a lovely 8k walk with @dseguy and @DaveLiddament in the snow at the back end of @ConFooCa .
Thanks Canada!
Updated a restaurant
Created a ticket shop, a bench, and a toilet
Created a picnic_table; Updated a viewpoint
Updated a shelter
I hiked 9.3km in 3h12m03s
Updated 3 restaurants
I walked 3.1km in 29m25s
I walked 4.4km in 45m01s
I walked 5.4km in 55m28s
Updated a restaurant; Confirmed a hotel
I walked 6.3km in 1h12m59s
Paraphrasing opening keynote speaker at ConFoo: "Should we go back to the waterfall method of writing massive specs upfront to feed to AI coding agents?"
I walked 1.6km in 17m29s
I walked 2.1km in 17m44s
Updated a pub
I walked 2.6km in 26m41s
Merged pull request #1065
Comparison whether class is userland or internal used the wrong macro



Shortlink
This article has a short URL available: https://drck.me/adv1301-aen