Ping... In the easiest case, simply don't use that view anymore, but the default Project Explorer instead. It looks good enough to me.
"Perl Auto Builder" doesn't work anymore with Eclipse 2020-09
The Navigator View is scheduled for removal by Eclipse after August 2021.
I'm somewhat sure to have installed EPIC from the marketplace some months ago and there's a page available: https://marketplace.eclipse.org/content/epic-eclipse-perl-integration#group-details But now, the marketplace client within Eclipse can't find it anymore. Any idea about the problem?
I'm somewhat sure to have installed EPIC from the marketplace some months ago, but now I can't find it there anymore. Has it ever been published there? If so, any idea what could be the problem now?
I added this fix - binmode($DB::OUT, ':encoding(UTF-8)') rather than binmode($DB::OUT, ':utf-8') to EPIC 0.7.6 now. Please have a look at the original bug ticket and patches again, in my opinion it makes very clear that using ":encoding(...)" is deprecated as well: +(W deprecated) The sysread(), recv(), syswrite() and send() operators +are deprecated on handles that have the C<:utf8> layer, either +explicitly, or implicitly, eg., with the C<:encoding(UTF-16LE)> layer. https://rt.perl.org/Public/Ticket/Attachment/1360169/728149/0001-perl-125760-deprecate-sys-read-write-send-recv-on-ut.patch...
I added this fix - binmode($DB::OUT, ':encoding(UTF-8)') rather than binmode($DB::OUT, ':utf-8') to EPIC 0.7.6 now. Please have a look at the original bug ticket and patches again, in my opinion it makes very clear that using ":encoding(...)" is deprecated as well: +(W deprecated) The sysread(), recv(), syswrite() and send() operators +are deprecated on handles that have the C<:utf8> layer, either +explicitly, or implicitly, eg., with the C<:encoding(UTF-16LE)> layer. https://rt.perl.org/Public/Ticket/Attachment/1360169/728149/0001-perl-125760-deprecate-sys-read-write-send-recv-on-ut.patch...
I added this fix - binmode($DB::OUT, ':encoding(UTF-8)') rather than binmode($DB::OUT, ':utf-8') to EPIC 0.7.6 now. Please have a look at the original bug ticket and patches again, it makes very clear that using ":encoding(...)" is deprecated as well: +(W deprecated) The sysread(), recv(), syswrite() and send() operators +are deprecated on handles that have the C<:utf8> layer, either +explicitly, or implicitly, eg., with the C<:encoding(UTF-16LE)> layer. https://rt.perl.org/Public/Ticket/Attachment/1360169/728149/0001-perl-125760-deprecate-sys-read-write-send-recv-on-ut.patch...
EPIC seems to not suggest methods named completely in upper case or starting with _ in Content Assist. Is there some way to at least change the behaviour for upper case? I use that naming convention for public constants and don't have the feeling that it's that uncommon in Perl or other languages. Not having Content Assist available for those constants is a bit annoying. Thanks!
As for your fix, I'll test it, but I suspect that changing from :utf8 to :raw might have unwanted side effects of not being able to see UTF-8 characters[...] +1, changing to ":raw" alone doesn't make much sense if one explicitly worked with UTF-8 characters before. Using ":raw" in combination with explicitly encoding/decoding to/from UTF-8 before writing/after reading OTOH should be the proper solution. I often prefer "Encode::Ecode|decode" instead of "utf8::encode|decode", because it croaks on invalid...
As for your fix, I'll test it, but I suspect that changing from :utf8 to :raw might have unwanted side effects of not being able to see UTF-8 characters[...] +1, changing to ":raw" alone doesn't make much sense if one explicitly worked with UTF-8 characters before. Using ":raw" in combination with explicitly encoding/decoding to/from UTF-8 before writing/after reading OTOH should be the proper solution. I often prefer "Encode::Ecode|decode" instead of "utf8::encode|decode", because it croaks on invalid...
As for your fix, I'll test it, but I suspect that changing from :utf8 to :raw might have unwanted side effects of not being able to see UTF-8 characters[...] +1, changing to ":raw" alone doesn't make much sense if one explicitly requested UTF-8 characters before. Changing either to "read" while keeping the ":utf8"-layer or changing to ":raw" followed by "Encode::decode('UTF-8', $buffer, Encode::FB_CROAK()[ | Encode::LEAVE_SRC()])" on all read bytes seems to be the proper solution. "utf8::decode"...
Check GitHub for a more detailed explanation what is going on and an easy fix to apply: https://github.com/phpvirtualbox/phpvirtualbox/issues/53#issuecomment-326043790
There's a workaround: Get the missing class from the former Eclipse version, it''s placed in org.eclipse.jface_*.jar. Afterwards find your local installation of org.epic.perleditor_0.7.3.jar and add the missing class into that jar, using the correct dir structure for the class like the EPIC classes itself. It just needs to be present and seems to be the only missing class. Afterwards this concrete editor problem was gone for me. Placing the class in some other class path outside that jar didn't work...
I've manually created an issiue in GitHub as wlel, not sure of there's any kind of automatic integration. https://github.com/phpvirtualbox/phpvirtualbox/issues/54
I've manually created an issiue in GitHub as wlel, not sure of there's any kind of integration. https://github.com/phpvirtualbox/phpvirtualbox/issues/54
Exception Object ( [message:protected] => The password and password identifier must be empty if the output should be unencrypted [string:Exception:private] => [code:protected] => 0 [file:protected] => /home/someHost/public_html/phpvirtualbox-5.0-5/endpoints/lib/vboxconnector.php [line:protected] => 2429 [trace:Exception:private] => Array ( [0] => Array ( [file] => /home/someHost/public_html/phpvirtualbox-5.0-5/endpoints/lib/vboxconnector.php [line] => 951 [function] => remote_progressGet [class]...
Exception Object ( [message:protected] => The password and password identifier must be empty if the output should be unencrypted [string:Exception:private] => [code:protected] => 0 [file:protected] => /home/someHost/public_html/phpvirtualbox-5.0-5/endpoints/lib/vboxconnector.php [line:protected] => 2429 [trace:Exception:private] => Array ( [0] => Array ( [file] => /home/someHost/public_html/phpvirtualbox-5.0-5/endpoints/lib/vboxconnector.php [line] => 951 [function] => remote_progressGet [class]...
Error on decrypting encrypted VMs
This is the same file like in the comment before, but compressed directly under XP....
I have another instance of this issue: Compressed with settings working under Win...
I attached the files in different versions: A newly created one under Win 7, the...
Win 8.1 x64 compressed files don't work with Win 7 x64 or XP x86