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.)
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 have a set of data (cumulative precipitation) that when the instrument resets, the starting level of the precipitation recorded changes. To correct this, I need to add the amount by which the the value dropped to the new recording so that the values are continuously increasing as they should.
i.e. the range of numbers below would be changed from:
26, 27, 28, 18, 19, 20
to:
26, 27, 28, 28, 29, 30
By adding the drop (10) to all values after the drop.
I think I need to loop the action through a range of cells (12746 to 17567)
You could do something like this:
# An example like yours, but with multiple drops.
vals = c(26, 27, 28, 18, 19, 20, 15, 17, 19);
correct_drops = function(vals)
{
n = length(vals);
# which() will get you indices where the condition holds true.
# Here it will get you the sites where 2 consecutive values
# have that the first value is greater than the second, meaning a drop.
indices_before_drop = which(vals[1:(n-1)] - vals[2:n] > 0);
# Looping through all drops, correcting each individually.
vals_corrected = vals;
for (ibd in indices_before_drop)
{
iad = ibd + 1;
drop = vals_corrected[ibd] - vals_corrected[iad];
vals_corrected = c(vals_corrected[1:ibd], (vals_corrected[iad:n] + drop));
}
return (vals_corrected);
}
vals_corrected = correct_drops(vals);
Of course there are special cases to be considered.
In any case I believe that which(..) and c(..) and subvector ranges v[a:b] are your friends here.
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.
Is there a way to make bootstrap datetime picker to show me only options that represent intervals of half hour? (8:00; 8:30; 9:00; 9:30; ...)
Also I would like to know if there are ways to limit time intervals (say start from 8:00 AM until 18:00 PM).
You can set interval with the stepping parameter, while you can use enabledHours to limit valid hours of day. Assuming that "datetimepicker" is the id of your component, you can initialize it as follows:
$('#datetimepicker').datetimepicker({
stepping: 30,
enabledHours: [8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18]
});
You can find further information in the official documentation of the library
For me it works:-
$('.datetimepicker').datetimepicker({
autoclose:true,
minuteStep: 30,
hoursDisabled: [19, 20, 21, 22, 23, 00, 1, 2, 3, 4, 5, 6, 7]
});
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}