I am trying to uninstall the commerce modules.
I had purchased a template with the commerce modules and using the files with demo data from them. I have contacted the template provider and he has clarified the issue is not with the template and it is with the module.
I am uninstalling the modules one by one and I also flushed all cache in between each uninstall.
I have also deleted all views, blocks and data under commerce such as orders, products before uninstalling the modules.
I can uninstall all commerce modules except Commerce, Commerce Price, Commerce Store and Commerce Product.
Whenever I try uninstalling Commerce Product, it does not complete for some reason. I only get
The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The "commerce_product" entity type does not exist. in <em class="placeholder">Drupal\Core\Entity\EntityTypeManager->getDefinition()</em> (line <em class="placeholder">133</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/EntityTypeManager.php</em>). <pre class="backtrace">flag_views_data_alter(Array, NULL, NULL) (Line: 501)
Drupal\Core\Extension\ModuleHandler->alter('views_data', Array) (Line: 254)
Drupal\views\ViewsData->getData() (Line: 162)
Drupal\views\ViewsData->get('block_content') (Line: 91)
Drupal\views\Plugin\Derivative\ViewsEntityRow->getDerivativeDefinitions(Array) (Line: 101)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array) (Line: 87)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() (Line: 283)
Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() (Line: 174)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 22)
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('entity:node') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('entity:node', Array) (Line: 84)
Drupal\Component\Plugin\PluginManagerBase->createInstance('entity:node') (Line: 818)
Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin('row') (Line: 122)
Drupal\views\Plugin\views\style\StylePluginBase->init(Object, Object, Array) (Line: 821)
Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin('style') (Line: 883)
Drupal\views\ViewExecutable->initStyle() (Line: 1840)
Drupal\views\ViewExecutable->getTitle() (Line: 132)
Drupal\views\Plugin\views\display\PathPluginBase->getRoute('blog', 'page') (Line: 220)
Drupal\views\Plugin\views\display\PathPluginBase->collectRoutes(Object) (Line: 120)
Drupal\views\EventSubscriber\RouteSubscriber->routes()
call_user_func(Array) (Line: 146)
Drupal\Core\Routing\RouteBuilder->rebuild() (Line: 83)
Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild() (Line: 477)
Drupal\Core\Extension\ModuleInstaller->uninstall(Array, 1) (Line: 91)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->uninstall(Array) (Line: 160)
Drupal\system\Form\ModulesUninstallConfirmForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 585)
Drupal\Core\Form\FormBuilder->processForm('system_modules_uninstall_confirm_form', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm('system_modules_uninstall_confirm_form', Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 576)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 153)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 657)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
</pre>
and I can no longer access the website.
Can some one explain the cause of the error to me?
It seems like the theme is dependent on the commerce module, so you have to check theme, there might be some views that rendered directly in the theme and now you have deleted the module so that view does not getting the product entity. you have to enable it.
Related
I'd like to prove the correctness of this function from libsecp256k1:
static int secp256k1_ctz64_var_debruijn(uint64_t x) {
static const uint8_t debruijn[64] = {
0, 1, 2, 53, 3, 7, 54, 27, 4, 38, 41, 8, 34, 55, 48, 28,
62, 5, 39, 46, 44, 42, 22, 9, 24, 35, 59, 56, 49, 18, 29, 11,
63, 52, 6, 26, 37, 40, 33, 47, 61, 45, 43, 21, 23, 58, 17, 10,
51, 25, 36, 32, 60, 20, 57, 16, 50, 31, 19, 15, 30, 14, 13, 12
};
return debruijn[((x & -x) * 0x022FDD63CC95386D) >> 58];
}
My specification is
Definition secp256k1_ctz64_var_debruijn_spec : ident * funspec :=
DECLARE _secp256k1_ctz64_var_debruijn
WITH a : Z
PRE [ tulong ]
PROP(0 <= a < Int64.modulus)
PARAMS(Vlong (Int64.repr a))
SEP()
POST [ tint ]
PROP()
RETURN(Vint (Int.repr (Z.of_nat (ctz a))))
SEP().
for my own custom implementation of ctz : Z -> nat.
However when I go to prove the associated correctness lemma:
Lemma body_secp256k1_umul128: semax_body Vprog Gprog f_secp256k1_ctz64_var_debruijn secp256k1_ctz64_var_debruijn_spec.
Proof.
start_function.
forward.
I get an error:
Tactic failure: Cannot evaluate right-hand-side expression (sometimes this is caused by missing LOCALs in your precondition) (level 995).
My goal context is
1 goal
Espec : OracleKind
a : Z
Delta_specs : Maps.PTree.t funspec
Delta := abbreviate : tycontext
H : and (Z.le 0 a) (Z.lt a Int64.modulus)
POSTCONDITION := abbreviate : ret_assert
MORE_COMMANDS := abbreviate : statement
______________________________________(1/1)
semax Delta
(PROPx nil
(LOCALx (cons (temp _x (Vlong (Int64.repr a))) nil) (SEPx nil)))
(Ssequence
(Sset _t'1
(Ederef
(Ebinop Oadd (Evar _debruijn (tarray tuchar 64))
(Ebinop Oshr
(Ebinop Omul
(Ebinop Oand (Etempvar _x tulong)
(Eunop Oneg (Etempvar _x tulong) tulong) tulong)
(Econst_long (Int64.repr 157587932685088877) tlong)
tulong) (Econst_int (Int.repr 58) tint) tulong)
(tptr tuchar)) tuchar)) MORE_COMMANDS) POSTCONDITION
Notably the debruijn array and its content are absent from the context. Am I supposed to be adding v_debruijn to my specification in some manner when a function has a local static variable like this?
Though it's defined locally, debruijn is treated as a global variable in the clightgen generated Coq file.
So it seems like modifying your specification in the following way should at least get you started:
Definition secp256k1_ctz64_var_debruijn_spec : ident * funspec :=
DECLARE _secp256k1_ctz64_var_debruijn
WITH a : Z, gv : globals
PRE [ tulong ]
PROP(0 <= a < Int64.modulus)
PARAMS(Vlong (Int64.repr a))
GLOBALS(gv)
SEP(data_at Ers (tarray tuchar 64) (map (fun x => Vint (Int.repr x)) debruijn) (gv _debruijn))
POST [ tint ]
PROP()
RETURN(Vint (Int.repr (Z.of_nat (ctz a))))
SEP(data_at Ers (tarray tuchar 64) (map (fun x => Vint (Int.repr x)) debruijn) (gv _debruijn)).
where debruijn in the above definition is the appropriate list Z associated with your array.
Supplementary to TJ Machado's answer, the data for the debruijn array is stored in gvar_init v_debruijn in a somewhat unusual data structure specialized for static initialization. I haven't found a good canonical way to turn this into a suitable data_at expression, but I did manage to hack something together for my purposes:
Definition debruijn64_array (sh: share) (gv: globals) : mpred :=
Eval cbn in
let
is_all_init_int8 := fix is_all_init_int8 (l : list init_data) :=
match l with
| [] => True
| Init_int8 _ :: l' => is_all_init_int8 l'
| _ => False
end
in let
uninit_int8s := fix uninit_int8s (l: list init_data) :
is_all_init_int8 l -> list int :=
match l with
| [] => fun _ => []
| x :: l' =>
match x with
| Init_int8 i => fun pf => i :: uninit_int8s l' pf
| _ => False_rec (list int)
end
end
in data_at sh (gvar_info v_debruijn)
(map Vint (uninit_int8s (gvar_init v_debruijn) I)) (gv _debruijn).
My final specification is:
Definition secp256k1_ctz64_var_debruijn_spec : ident * funspec :=
DECLARE _secp256k1_ctz64_var_debruijn
WITH a : Z, sh_debruijn : share, gv : globals
PRE [ tulong ]
PROP(0 <= a < Int64.modulus; readable_share sh_debruijn)
PARAMS(Vlong (Int64.repr a))
GLOBALS(gv)
SEP(debruijn64_array sh_debruijn gv)
POST [ tint ]
PROP()
RETURN(Vint (Int.repr (Z.of_nat (ctz a))))
SEP(debruijn64_array sh_debruijn gv).
I'm trying to translate an Arduino example project for the M5 Thermal HAT (using MLX90640) (on an M5StickC) which works for me to MicroPython (1.18).
While trying to read data via I2C strange things happen.
Creating the I2C object and scanning the bus with the HAT attached works as expected:
>>> from machine import Pin, I2C
>>> i2c = I2C(0, sda=Pin(0), scl=Pin(26), freq=800000)
>>> i2c.scan()
[51]
Reading the status register at 0x8000 as described in the MLX90680 documentation also returns data which seems plausible to me:
>>> list(i2c.readfrom_mem(0x33, 0x8000, 2))
[0, 8]
>>> list(i2c.readfrom_mem(0x33, 0x8000, 2))
[0, 9]
Bit 3 indicates available data and bit 0 seems to toggle pages.
But now the magic begins.
As I try to read the "control register" at 0x800D as demonstrated in an Adafruit example (and all other examples) it seems to behave exactly like the status register (with a toggling first bit, which should not happen on a control register):
>>> list(i2c.readfrom_mem(0x33, 0x800D, 2))
[0, 9]
>>> list(i2c.readfrom_mem(0x33, 0x800D, 2))
[0, 8]
After a bit of experimenting and playing with different addresses and sizes I had to realize that the address provided with I2C.readfrom_mem() seems to be totally ignored:
>>> list(i2c.readfrom_mem(0x33, 0x0000, 16))
[0, 9, 0, 191, 121, 159, 0, 0, 32, 97, 0, 4, 3, 32, 3, 224]
>>> list(i2c.readfrom_mem(0x33, 0x1000, 16))
[0, 9, 0, 191, 121, 159, 0, 0, 32, 97, 0, 4, 3, 32, 3, 224]
>>> list(i2c.readfrom_mem(0x33, 0x2400, 16))
[0, 9, 0, 191, 121, 159, 0, 0, 32, 97, 0, 4, 3, 32, 3, 224]
>>> list(i2c.readfrom_mem(0x33, 0x2800, 16))
[0, 8, 0, 191, 121, 159, 0, 0, 32, 97, 0, 4, 3, 32, 3, 224]
I tried turning all devices off and on again, played with different values for addrsize and clock speeds and tried a different HAT attached to the stick (to make sure I2C is working fine in principal) but all with no insights.
Since most code examples (e.g. this or that) demonstrating how to use the MLX90640 sensor via I2C use low level access to I2C (rather than MicroPythons readfrom_mem implementation) I also tried a discrete write/read approach:
>>> i2c.writeto(0x33, bytes([0x80, 0x0D]))
2
>>> list(i2c.readfrom(0x33, 2))
[0, 9]
>>> i2c.writeto(0x33, bytes([0x0D, 0x80])) # try swapped byte order
2
>>> list(i2c.readfrom(0x33, 2))
[0, 9]
With all the same effect.
What do I do wrong here? Since I can read data from the I2C bus I guess I don't have a problem of electrical nature.. (also the native Arduino example is fully working on the same device).
Is there some basic I2C knowledge I missed until now?
Why do all I2C read operations on this device issued by MicroPython seem to disregard the address while others are working totally fine?
It looks like you are missing the stop parameter.
micropython I2C writeto
Try this:
i2c.writeto(0x33, bytes([mem_address>>8, mem_address&0xFF]), False)
i2c.readfrom(0x33, 2)
Accordingly to write data you'd write:
i2c.writeto(0x33, bytes([mem_address>>8, mem_address&0xFF] + [d,a,t,a]))
I know that Javascript Date() function can handle date entry overflows. But in Julia I get Error.
Is there any way to handle overflows automatically?
DateTime(2020, 4, 22, 15, 43, 67) # ----> 2020-4-22T15:44:07
DateTime(2020, 12, 31, 23, 59, 60) # ----> 2021-1-1T00:00:00
I find the default behavior of throwing an error useful. If you want to allow overflows you can define your own function for this eg. like this:
julia> MyDateTime(y, m, d, h, mi, s) =
+(DateTime(0), Year(y), Month(m-1), Day(d-1),
Hour(h), Minute(mi), Second(s))
MyDateTime (generic function with 1 method)
julia> MyDateTime(2020, 4, 22, 15, 43, 67) # ----> 2020-4-22T15:44:07
2020-04-22T15:44:07
julia> MyDateTime(2020, 12, 31, 23, 59, 60) # ----> 2021-1-1T00:00:00
2021-01-01T00:00:00
Note that the order of operations matters there - we first advance year, then month, etc. (as e.g. the effect of advancing time by one second may depend on the month, year and day):
julia> MyDateTime(2020, 2, 28, 23, 59, 60)
2020-02-29T00:00:00
julia> MyDateTime(2021, 2, 28, 23, 59, 60)
2021-03-01T00:00:00
(this can get especially tricky if you have very large and invalid values of month, day etc.)
I am having an issue in Asterisk 14.6.1 getting my custom CDR fields populated using ODBC to a MySQL database, basically I am making simultaneous outbound calls using Dial and I need to know in the CDRs which phone actually answered the call, so I am using a macro.
So here’s my simple extensions.conf
exten => 12345,1,Dial(PJSIP/071XXXXXXXX#EP&PJSIP/072XXXXXXXX#EP,180,M(test),r)
And my Macro:
[macro-test]
exten => s,1,Verbose(Call Answered from ${CALLERID(num)} to ${DIALEDPEERNUMBER})
exten => s,2,Set(CDR(outboundddi)=${DIALEDPEERNUMBER})
exten => s,3,Set(CDR(userfield)=${DIALEDPEERNUMBER})
So all this works fine, calls are ringing, being answered and macro running!
Output from Asterisk:
PJSIP/PrimaryEP-00000001 answered PJSIP/EP-00000000
– Executing [s#macro-test:1] Verbose(“PJSIP/EP-00000001”, “Call Answered from 12345 to 071XXXXXXXX#EP”) in new stack
Call Answered from 12345 to 071XXXXXXXX#EP
– Executing [s#macro-test:2] Set(“PJSIP/EP-00000001”, “CDR(outboundddi)= 071XXXXXXXX#EP”) in new stack
– Executing [s#macro-test:3] Set(“PJSIP/EP-00000001”, “CDR(userfield)= 071XXXXXXXX#EP”) in new stack
So I know all this works. The Set(CDR(userfield)=${DIALEDPEERNUMBER}) works fine, the Set(CDR(outboundddi)=${DIALEDPEERNUMBER}) does not, it appears to be ignored, and I do not get an error. So the value is getting populated in the userfield of the database, but nothing gets populated in the outboundddi field of the database.
I think it gets ignored because cdr_odbc is registered in the backend as well as cdr_adaptive_odbc - but if I noload cdr_odbc.so then I do not get any CDRs logged in the ODBC database, and if I take out the config in cdr_odbc.conf then again I get nothing on the ODBC database.
Here is some further detail:
cdr show status
Call Detail Record (CDR) settings
Logging: Enabled
Mode: Simple
Log unanswered calls: Yes
Log congestion: Yes
Registered Backends
cdr-custom
cdr_manager (suspended)
radius
Adaptive ODBC
ODBC
res_config_sqlite
odbc show
ODBC DSN Settings
Name: asterisk
DSN: Asterisk
Number of active connections: 1 (out of 1)
module reload cdr_adaptive_odbc.so
Module ‘cdr_adaptive_odbc.so’ reloaded successfully.
– Reloading module ‘cdr_adaptive_odbc.so’ (Adaptive ODBC CDR backend)
== Parsing ‘/etc/asterisk/cdr_adaptive_odbc.conf’: Found
– Found adaptive CDR table cdrs#asterisk.
> Found calldate column with type 93 with len 19, octetlen 19, and numlen (0,10)
> Found clid column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found src column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found dst column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found dcontext column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found channel column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found dstchannel column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found lastapp column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found lastdata column with type 12 with len 80, octetlen 80, and numlen (0,0)
> Found duration column with type 4 with len 10, octetlen 10, and numlen (0,10)
> Found billsec column with type 4 with len 10, octetlen 10, and numlen (0,10)
> Found disposition column with type 12 with len 45, octetlen 45, and numlen (0,0)
> Found amaflags column with type 4 with len 10, octetlen 10, and numlen (0,10)
> Found accountcode column with type 12 with len 20, octetlen 20, and numlen (0,0)
> Found userfield column with type 12 with len 255, octetlen 255, and numlen (0,0)
> Found uniqueid column with type 12 with len 32, octetlen 32, and numlen (0,0)
> Found linkedid column with type 12 with len 32, octetlen 32, and numlen (0,0)
> Found sequence column with type 12 with len 32, octetlen 32, and numlen (0,0)
> Found peeraccount column with type 12 with len 32, octetlen 32, and numlen (0,0)
> Found outboundddi column with type 12 with len 50, octetlen 50, and numlen (0,0)
cdr_adaptive_cdr.conf
[adaptive_connection]
connection=asterisk
table=cdrs
usegmtime=yes
cdr_odbc.conf
[global]
dsn=asterisk
loguniqueid=yes
dispositionstring=yes
table=cdrs ;“cdr” is default table name
usegmtime=yes ; set to “yes” to log in GMT
hrtime=yes ;Enables microsecond accuracy with the billsec and duration fields
newcdrcolumns=yes ; Enable logging of post-1.8 CDR columns (peeraccount, linkedid, sequence)
I guess I could just forget it and use the userfield that is working, but I’d rather it be stored in a custom CDR field and I’d like to know what is incorrect for my own sanity, so if anyone can point me into what I have configured incorrectly I would be most grateful.
Thanks
David
You have put aliases lines in cdr_adaptive_odbc.conf
alias start => calldate
No, it not scan table itself.
The following go code doesn't compile, because (I believe) there is a mistake around the way pointers are being referenced.
In particular, The error message is
prog.go:13: cannot use append((*x)[:remove], (*x)[remove + 1:]...) (type []int) as type *[]int in assignment
Here is an abstracted and simplified version of the code which results in this error message.
package main
import "fmt"
func main() {
x := &[]int{11, 22, 33, 44, 55, 66, 77, 88, 99}
for i, addr := range *x {
if addr == 22 {
for len(*x) > 5 {
remove := (i + 1) % len(*x)
x = append((*x)[:remove], (*x)[remove+1:]...)
}
break
}
}
fmt.Println(x)
}
You're not using an array here, you're using a slice. Generally, you don't want to handle a pointer to a slice since it can get awkward, and the pointer is needed in very few cases.
To fix your error, dereference x:
*x = append((*x)[:remove], (*x)[remove+1:]...)
But you should probably be using the slice value directly, so that no dereferences are required:
x := []int{11, 22, 33, 44, 55, 66, 77, 88, 99}