I've read countless articles, including this which sounded almost exactly like my setup/issue:
Xdebug inside Docker on Mac M1 2021 is not working
I'm getting the error message mentioned in the title, still.
Here is how I spin up the container (which ships with PHPUnit and XDebug):
docker run --rm -it -v $(pwd):/app -v $(pwd)/xdebug.ini:/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini jitesoft/phpunit /bin/ash
Here is the debug.ini I use to overwrite the defaults:
;
; NOTE: We want to echo these contents to this file location
;
; PATH: /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
;
zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20220829/xdebug.so
xdebug.mode=debug
xdebug.idekey=PHPSTORM
xdebug.start_with_request=yes
xdebug.discover_client_host=0
xdebug.client_host=host.docker.internal
xdebug.log=/var/log/xdebug.log
Here is the debug config dump:
[1m__ __ _ _
[1m\ \ / / | | | |
[1m \ V / __| | ___| |__ _ _ __ _
[1m > < / _` |/ _ \ '_ \| | | |/ _` |
[1m / . \ (_| | __/ |_) | |_| | (_| |
[1m/_/ \_\__,_|\___|_.__/ \__,_|\__, |
[1m __/ |
[1m |___/
[0mVersion => 3.2.0
Support Xdebug on Patreon, GitHub, or as a business: https://xdebug.org/support
Enabled Features (through 'XDEBUG_MODE' env variable)
Feature => Enabled/Disabled
Development Helpers => ✘ disabled
Coverage => ✔ enabled
GC Stats => ✘ disabled
Profiler => ✘ disabled
Step Debugger => ✘ disabled
Tracing => ✘ disabled
Optional Features
Compressed File Support => no
Clock Source => clock_gettime
'xdebug://gateway' pseudo-host support => yes
'xdebug://nameserver' pseudo-host support => no
Systemd Private Temp Directory => not enabled
Diagnostic Log
No messages
PHP
Build Configuration
Version (Run Time) => 8.2.1
Version (Compile Time) => 8.2.1
Debug Build => no
Thread Safety => disabled
Settings
Configuration File (php.ini) Path => /usr/local/etc/php
Loaded Configuration File => (none)
Scan this dir for additional .ini files => /usr/local/etc/php/conf.d
Additional .ini files parsed => /usr/local/etc/php/conf.d/date_timezone.ini,
/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini,
/usr/local/etc/php/conf.d/memory-limit.ini
Directive => Local Value => Master Value
xdebug.mode (through XDEBUG_MODE) => coverage => debug
xdebug.start_with_request => yes => yes
xdebug.start_upon_error => default => default
xdebug.output_dir => /tmp => /tmp
xdebug.use_compression => 0 => 0
xdebug.trigger_value => no value => no value
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.log => /var/log/xdebug.log => /var/log/xdebug.log
xdebug.log_level => 7 => 7
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 512 => 512
xdebug.var_display_max_depth => 3 => 3
xdebug.max_nesting_level => 256 => 256
xdebug.cli_color => 0 => 0
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.halt_level => 0 => 0
xdebug.max_stack_frames => -1 => -1
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.profiler_append => Off => Off
xdebug.cloud_id => no value => no value
xdebug.client_host => host.docker.internal => host.docker.internal
xdebug.client_port => 9003 => 9003
xdebug.discover_client_host => Off => Off
xdebug.client_discovery_header => HTTP_X_FORWARDED_FOR,REMOTE_ADDR => HTTP_X_FORWARDED_FOR,REMOTE_ADDR
xdebug.idekey => PHPSTORM => PHPSTORM
xdebug.connect_timeout_ms => 200 => 200
xdebug.scream => Off => Off
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.collect_assignments => Off => Off
xdebug.collect_return => Off => Off
Here is the result on the console when I try and run index.php for debugging:
[docker://jitesoft/phpunit:latest/]:php -dxdebug.mode=debug -dxdebug.client_port=9000 -dxdebug.client_host=host.docker.internal -dxdebug.client_host=host.docker.internal /opt/project/index.php
Process finished with exit code 0
Two things jump out at me
The top of the debug configure dump suggests step debugging is still disabled???
The path to the php script I want to execute on the docker side is /app/index.php not /opt/project/index.php
Thoughts?
In my application I need to convert integer to some term; for example:
1 → :red
2 → :green
3 → :blue
The table is static, it is known during compilation time and its indices range from <1, n>. There is around 60 of them.
In which way should the table be represented, so the lookup is the fastest? Dict, HashDict, tuple (with kernel.elem()), ets, function with pattern matching...?
As Julius Beckmann suggested in this case functions with pattern matching should be sufficient as they are according to my measurements over 5 times faster than accessing a map.
Below you can find an implementation of what you are looking for (benchmark code included at the bottom):
defmodule TermLookUpByInteger do
#term_by_integer %{
1 => :aa, 11 => :ba, 21 => :ca, 31 => :da, 41 => :ea, 51 => :fa, 61 => :ga,
2 => :ab, 12 => :bb, 22 => :cb, 32 => :db, 42 => :eb, 52 => :fb, 62 => :gb,
3 => :ac, 13 => :bc, 23 => :cc, 33 => :dc, 43 => :ec, 53 => :fc, 63 => :gc,
4 => :ad, 14 => :bd, 24 => :cd, 34 => :dd, 44 => :ed, 54 => :fd, 64 => :gd,
5 => :ae, 15 => :be, 25 => :ce, 35 => :de, 45 => :ee, 55 => :fe, 65 => :ge,
6 => :af, 16 => :bf, 26 => :cf, 36 => :df, 46 => :ef, 56 => :ff, 66 => :gf,
7 => :ag, 17 => :bg, 27 => :cg, 37 => :dg, 47 => :eg, 57 => :fg, 67 => :gg,
8 => :ah, 18 => :bh, 28 => :ch, 38 => :dh, 48 => :eh, 58 => :fh, 68 => :gh,
9 => :ai, 19 => :bi, 29 => :ci, 39 => :di, 49 => :ei, 59 => :fi, 69 => :gi,
0 => :aj, 10 => :bj, 20 => :cj, 30 => :dj, 40 => :ej, 50 => :fj, 60 => :gj,
}
#doc """
iex> TermLookUpByInteger.lookup_pmf(2)
:ab
"""
def lookup_pmf(int), do: do_lookup(int)
for {int, term} <- #term_by_integer do
defp do_lookup(unquote(int)), do: unquote(term)
end
#doc """
iex> TermLookUpByInteger.lookup_m(3)
:ac
"""
def lookup_m(int), do: #term_by_integer[int]
end
# Benchmark:
n = 1_000_000
range = 1..(n)
measure = fn fun -> :timer.tc(fn -> for _ <- range, do: fun.() end) end
{time_pmf, _result} = measure.(fn -> TermLookUpByInteger.lookup_pmf(:random.uniform(60)) end)
{time_m, _result} = measure.(fn -> TermLookUpByInteger.lookup_m(:random.uniform(60)) end)
IO.puts " Sample size: #{n}"
IO.puts "Pattern matching functions lookup: #{time_pmf/1000} ms"
IO.puts " Map lookup: #{time_m/1000} ms"
IO.puts " Absolute Difference: #{(time_pmf-time_m)/1000} ms"
IO.puts " Relative Difference: #{round((time_pmf-time_m)/time_m*100)}%"
IO.puts " Faster: x #{Float.round(time_m/time_pmf, 2)} times"
Results:
Sample size: 1000000
Pattern matching functions lookup: 447.6 ms
Map lookup: 2423.517 ms
Absolute Difference: -1975.917 ms
Relative Difference: -82%
Faster: x 5.41 times
I hope that will be useful.
If the map is completely static and will not change, you can use generated pattern matching. This will be the fastest way to integrate that lookup in your application.
Some example code, reading these mappings from a external file: https://github.com/h4cc/slugger/blob/master/lib/slugger.ex#L69-72
Instead of using a external file, your source map data can be held in a #attribute.
Even if new mappings will be needed on runtime, these could be handled with a catchall-pattern match doing a lookup in a HashDict.
If you rely on fast access from many processes, then mochiglobal may be the answer. It's tricky constant pool, which keeps keys and values as functions in module. Every time you put/2 something, module is recompiled (it's slow but doesn't matter in your case). With this approach value is not copied into process heap as it is function call. Here is better explanation.
When I try to login from server
[http_code] => 401
[url] => https://api.twitter.com/oauth/request_token
[host] => https://api.twitter.com/1.1/
[timeout] => 30
[connecttimeout] => 30
[ssl_verifypeer] =>
[format] => json
[decode_json] => 1
[http_info] => Array
(.....
When I try to login from my Localhost its working fine
[http_code] => 200
[url] => https://api.twitter.com/oauth/request_token
[host] => https://api.twitter.com/1.1/
[timeout] => 30
[connecttimeout] => 30
[ssl_verifypeer] =>
[format] => json
[decode_json] => 1
[http_info] => Array
(.....
Can anyone help me. My twitter_consumer_token and twitter_consumer_secret are correct
I think your server time has not set properly
I've this situation wherein a singleton class creates object of a model and is used further in my code.
Now, the problem is that occasionally the connection between application and database is broken and all subsequent calls to the singleton fail. While I'm working on fixing the issue, a workaround is required immediately. I believe the solution I'm thinking of, would work but not sure if it will leak memory, cause deadlocks etc.
Here's the original (partial) code:
1 file_path = File.expand_path(File.dirname(__FILE__))
2 require file_path + '/action_factory'
3 require 'erb'
4
5 class Manager
6
7 def initialize(logger)
8 #logger = logger
9 end
10
11 def log_exception(e,method_name)
12 #logger.log :ERROR,"Manager",method_name,'',$$,'',e.backtrace[0] + ": Uncaught Exception " + e.message,DateTime.now,'system',''
13 e.backtrace.shift
14 #logger.log :ERROR,"Manager",method_name,'',$$,''," from " + e.backtrace.join("\n from ") + "(" + e.class.to_s + ")",DateTime.now,'system',''
15 end
16 def execute_action
17 return false if addresses.collect{|a| a if !a.to_s.empty?}.compact.empty?
18 begin
19 action = ActionFactory.instance().get_action(type)
20 return true
21 rescue Exception => e
22 action = nil ####### I'm planning to add this line ####
23 log_exception(e,this_method_name)
24 return false
25 end
26 end
27 end
28 require 'singleton'
29 $file_path=File.expand_path(File.dirname(__FILE__))
30 Dir[$file_path + '/actions/*_action.rb'].each { |filename| require filename }
31
32 class ActionFactory
33 include Singleton
34
35 def get_action(type)
36 action_type_obj = ActionType.find(:first, :select => "action_name", :conditions => ["id=?",type])
37 if(action_type_obj.nil? or action_type_obj.action_name.nil?)
38 raise "Undefined Action Type"
39 else
40 return eval("Actions::#{action_type_obj.action_name}").instance
41 end
42 end
43 end
The problem is that oracle connection is disconnected sometimes and the statement #36 fails returning InvalidStatement exception. All subsequent calls of the statement 19 fail.
I'm planning to add a statement : action = nil in the exception block in line 22. Will that suffice as a workaround or would it bring more issues like memory leakages, deadlocks etc?
If there is a better solution, I'll be glad to hear.
Thanks
I have an application developed on BlackBerry JE 4.6.1 that decrypts an information from WebServer using DES algorythm.
If I send encrypted information to the server, it is decrypted well. But in case if the server sends an encrypted data,
I do not get the correct value after decryption.
Key is supposed to be the same and crypted information is sent base64 encoded.
During debugging I have found out, that after DESKey is created it's inner data differs from the byte array passed to the constructor.
For example if I create the DESKey the next way
String keyStr = "2100000A";
DESKey desKey = new DESKey(keyStr.getBytes()); // pass the byte array {'2','1','0','0','0','0','0','A'}
the method desKey.getData() returns the byte array {'2','1','1','1','1','1','1','#'} that differs from the initial key bytes.
So is it possible for such behavior of the DESKey to be the reason why I can not decrypt data from server?
Thank you.
The desKey.getData() behaviour is expected.
The doc states:
DES operates on 64 bit blocks and has
an effective key length of 56 bits. In
reality, the key is 64 bits but there
are 8 bits of parity used which means
that the effective key length is only
56 bits. Every eighth bit is used for
parity and it is the least significant
bit that is used for parity.
Parity bit definition:
A parity bit, or check bit, is a bit that is added to ensure that the number of bits with the value one in a set of bits is even or odd. Parity bits are used as the simplest form of error detecting code.
So, this is how it happens:
'2' => 0x32 => 00110010 => 0011001 + (parity bit 0) => 00110010 => 0x32 => '2'
'1' => 0x31 => 00110001 => 0011000 + (parity bit 1) => 00110001 => 0x31 => '1'
'0' => 0x30 => 00110000 => 0011000 + (parity bit 1) => 00110001 => 0x31 => '1'
'0' => 0x30 => 00110000 => 0011000 + (parity bit 1) => 00110001 => 0x31 => '1'
'0' => 0x30 => 00110000 => 0011000 + (parity bit 1) => 00110001 => 0x31 => '1'
'0' => 0x30 => 00110000 => 0011000 + (parity bit 1) => 00110001 => 0x31 => '1'
'0' => 0x30 => 00110000 => 0011000 + (parity bit 1) => 00110001 => 0x31 => '1'
'A' => 0x41 => 01000001 => 0100000 + (parity bit 0) => 01000000 => 0x40 => '#'