As of now, PHP version 8.0.3 is available, as well as 7.4.16 as the latest in the 7 series. For those of us who have upgraded to Komodo 12.0.1, what is the most recent version in the PHP 7 series that we could upgrade our PHP to? Or, to use some wording from a related bug ticket, does Komodo 12.0.1 now incorporate binaries built for PHP 7.2, or 7.3, or even 7.4?
The latest binaries we built are for 7.2. I think you’re best bet for getting the latest and greatest will be to do as you did in that linked ticket and use the Xdebug binary for debugging.
Thanks for the info, @careyh. In that case, I will stick with PHP 7.2 and hold off on upgrading to PHP 7.3 or 7.4.
Hello, fellow Komodo IDE enthusiasts! I hope everyone is well.
For a couple years now I’ve been using PHP 7.2 instead of 7.3, only to avoid a problem of Komodo IDE skipping over assert() statements in my unit testing code (an issue detailed at https://github.com/Komodo/KomodoEdit/issues/3745). But now, to get Drupal 9 running on a local web server, it requires PHP 7.3 as a bare minimum. So I was wondering, with the current version of Komodo IDE, what the latest version of PHP that I could use without again bumping into the assert() problem.
As an experiment, I tried PHP 7.4 in conjunction with the Xdebug recommended by https://xdebug.org/wizard, which was php_xdebug-3.1.2-7.4-vc15.dll. The result is that Komodo IDE can run assert() statements, but it now won’t let me step through any statements, and instead just runs the entire script without stopping on the first statement. Anyone have any ideas why? As a test, I pointed Komodo IDE back to my old PHP 7.2, and the stepping capability returned.
Hey @mjross! Long time no read. Hope you’re well.
That’s odd that 7.3 or 7.4 even worked. Can you clarify if you’re doing remote or local debugging? Starting the debugger from the browser or from Komodo, respectively?
If local, you’ll need to follow these steps to support PHP > v. 7.2.:
If remote, I’ve not heard of an issue with debugging not stopping in the code though that is definitely possible if not properly configured.
So if you could confirm what kind of debugging you’re doing I’ll have more questions.
Hi, Carey, and happy new year! Everything is good here, in Puerto Vallarta. I won’t mention what the current weather is like.
The debugging is local and starting from inside Komodo IDE.
I didn’t entirely understand the procedures from that support article, but they sound similar to the steps I followed (from my PHP installation notes):
- Go to https://xdebug.org/wizard
- Paste the output of php.exe -i.
- Download the recommended php_xdebug.dll version. PHP 7.4.27 uses 3.1.2-7.4. PHP 7.3.33 uses 3.1.2-7.3. PHP 7.2.18 uses 2.7.2-7.2.
- Copy it to C:_a\PHP\ext as php_xdebug.dll
- In C:_a\PHP\php.ini, add “zend_extension = xdebug”.
Today I did further testing, and now have PHP versions 7.2, 7.3, and 7.4 installed, as well as the appropriate Xdebug DLL files. The testing confirmed that the debug stepping works with 7.2, but not either 7.3 or 7.4.
Oddly enough, even with 7.2, when I start the debugging process (Debug > Step In), Komodo always pops up the Debugging Options dialog, even though in my preferences I have “Skip debugging options dialog when launching” enabled. I think this misbehavior started after I installed Microsoft Visual C++ Redistributable for Visual Studio 2019, which is required by PHP 7.4.x and which presumably supersedes Microsoft Visual C++ Redistributable for Visual Studio 2012 x86, which I was using for PHP 7.2.x. How that could affect the debugging options dialog, is beyond me.
Because I make extensive use of step debugging, and it’s annoying for that debugging options dialog to be popping up each time, I’m contemplating rolling back my laptop to an image of the boot partition to one saved a month or so ago, prior to any of this misbehavior.
To solve- er… avoid the issue of the Debugging Options dialog, I rolled back my laptop to an earlier image. But that means I’m stuck on PHP 7.2 (and can’t run Drupal 9 on a local web server). This rollback reduces the number of tests I can do, but that dialog box was too annoying. Will Komodo be compiled for PHP 7.4?
Don’t worry, I’m a winter boy. The snow up here is what I like to see
I tried to mimic your setup but I guess I hit the same issue you did, Komodo doesn’t know what to do with a PHP compiled with Visual C++ 2017. From the logs:
[2022-01-05 12:14:57,739] [ERROR] koPHPConfigurator: Unexpected compiler: Visual C++ 2017
There are currently no plans for updates to Komodo so I can’t say when or if that would get fixed.
I’m not sure I udnerstand why you’re not able to use F5 to start your debug session instead of Step in though. Wouldn’t that resolve your dialog issue?
Good to hear that you like it up there in the Great White North. An old Rush fan here…
Sorry to hear about the dearth of update plans for Komodo.
I tried F5 just now, while viewing a PHP file, and nothing happened. Is that the default key command for Debug > Step In? (I have that command and the other debug commands assigned to different keystrokes, so perhaps that’s why nothing happens.) Or is it a different way of starting debugging without seeing the dialog box?
Yeah, F5 is the default keybinding. From that screenshot it looks like you haven’t assigned a keybinding to Debugger: Go/Continue
I have respect for RUSH but I went through high school as a skate punk snob then only branched into metal after high school haha.
Yep. No hotkey, because I never use Debugger > Go/Continue because it just runs everything, while I want to step into or over each statement. Also, it pops up the Debugging Options dialog, which I want to avoid.
IMO, Rush’s first six albums were phenomenal, but then they degenerated into radio-ready synth prog rock. Skate + metal? Surely you have been welcomed to The Church of Suicidal?! “We’ll have a sermon and a wonderful recital!”
Ahh, this sounds familiar now. I can’t reproduce this. I feel like we’ve had this conversation before though. I just meant use Go/Continue to START the debugger. I use step in after that as well.
There’s no way that installing a VS compiler effected that preference. I’d check your prefs file with Komodo closed to confirm that the pref you think is set is actually set, and to what you expect. You’d look for
I can’t use Go/Continue to only start the debugger and then step in after that, because it pops up the Debugging Options dialog, and when I click “OK”, it just runs the entire script, without stopping on the first statement, and at that point the debugger is done.
I think you’re right about a VS compiler not effecting any preference. I may have found the source of the problem: Up to this point I have been enabling in my preferences the checkbox for Debug > “Skip debugging options dialog when launching”, naturally assuming that that would skip over the options dialog when starting debugging. But the opposite happens: it always pops up a dialog. Just now I unchecked that box, and tested it again, and now it skips the dialog box! So that setting seems to be doing the opposite of how I’m interpreting the label of that setting.
Ahh, yes you have to set a breakpoint using Go.
OHhhhh you know what I think it is? I’m not 100% sure what the codes doing and I don’t have time at the moment to dig BUT the way to COUNTER that option is to press
Ctrl then the key to start debugging/step in/whatever. The keybindings you chose use
Ctrl. My guess is the code is seeing the
Ctrl in the keybinding and doing the opposite of what you set for the pref. I bet, as a test, if you change step-in back to F6 (or whatever the default is) you’ll find that the pref is respected and the dialog won’t appear. Then try Ctrl+F6 and it will do the opposite of the preference.
I tested and verified your hypothesis by using the menu commands each time and no keybindings. You were right.
This is the first I’ve heard of
Ctrl countering the setting for the dialog! And to think all these years I was using that and didn’t know it.
Thanks. That clears up a lot of the mystery.
Well at least we got THAT.
Sorry we couldn’t get the other things working for you.
One thing I’ll drop here. I saw you’re manually managing PHP installs. I was doing some PHP stuff for a friend last year and worked with a Laravel dev who pointed me at using Laragon for managing PHP installs and my dev env for Laravel. It’s a full dev server like XAMPP and family but I liked it better than XAMPP. I highly recommend checking it out. PHP has some weird gotchas on Windows when you’re manually installing.
We certainly did, and I appreciate your insight into Ctrl having such- er… control.
Thank you for the tip on Laragon. I’ll check that out. Ages ago I got into the habit of manually installing each component of my web dev environment partly because I wanted to learn as much as possible about the technologies, but also because I was able to turn my notes into plenty of article$. This was in ancient times when publishers paid actual money to writers for articles to appear in magazines printed on papyrus or something like that.
Hello, Carey. I hope you’re doing well! You’re probably tired of this particular topic, but this might be my last addition to it… I promise.
You’re undoubtedly aware of the date limitation of 32-bit PHP (e.g., https://www.drupal.org/docs/system-requirements/limitations-of-32-bit-php). As an experiment, I tried switching from 32-bit PHP to 64-bit, but it turns out that the assert() problem- er, reasserts itself (sorry) when switching to 64-bit PHP. Perhaps Komodo IDE is compiled only for 32-bit PHP 7.2?
I’m not actually. We don’t do much of any PHP at ActiveState and I’ve only done a little outside of the day job.
That doesn’t sound right. Checking the Komodo folders I see that we ship with 32 and 64 bit versions (as well as thread safe and non-thread safe for each of those).
I don’t mind you digging and asking questions at all @mjross. If we can figure something out that works around it without having to make a new Komodo release then that is fine. I just wouldn’t get your hopes up that a fix will be coming from ActiveState.