env: mac, truffle, ganache
Is there anyone can tell me that why I can't transfer ether from one account to another? below is the test code and debug info.
truffle(develop)> web3.eth.getBalance(web3.eth.accounts[2])
{ [String: '80999999999999440773'] s: 1, e: 19, c: [ 809999, 99999999440773 ] }
truffle(develop)> web3.eth.getBalance(web3.eth.accounts[4])
{ [String: '98999999999999979000'] s: 1, e: 19, c: [ 989999, 99999999979000 ] }
truffle(develop)> web3.eth.sendTransaction({from: web3.eth.accounts[4], to: web3.eth.accounts[2], value: web3.toWei(1, "ether")})
'0xc56c7982006ed5bd9f47523c5f38e3e86185b389a02b7e7c4d23b1e33bd07224'
truffle(develop)> debug 0xc56c7982006ed5bd9f47523c5f38e3e86185b389a02b7e7c4d23b1e33bd07224
Gathering transaction data...
Addresses affected:
0xc5fdf4076b8f3a5357c5e395ab970b5b54098fef(UNKNOWN)
Warning: The source code for one or more contracts could not be found.
Commands:
(enter) last command entered (step next)
(o) step over, (i) step into, (u) step out, (n) step next
(;) step instruction, (p) print instruction, (h) print this help, (q) quit
(b) toggle breakpoint, (c) continue until breakpoint
(+) add watch expression (`+:<expr>`), (-) remove watch expression (-:<expr>)
(?) list existing watch expressions
(v) print variables and values, (:) evaluate expression - see `v`
?:
(node:10530) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 4): TypeError: Cannot read property 'gasCost' of undefined
The debugger is used to step through a smart contract. You're just doing a simple ether transfer between two addresses. If you output the balances of your accounts after doing the transfer, you should see the transfer was successful.
Related
I'm trying to access Redis using Rust with the following:
extern crate redis;
use redis::{Client, Commands, Connection, RedisResult};
fn main() {
let redis_client = Client::open("redis://127.0.0.1/").unwrap();
let redis_conn = redis_client.get_connection().unwrap();
let mut keys_to_get = vec![];
keys_to_get.push("random_key_1".to_string());
keys_to_get.push("random_key_2".to_string());
let redis_result: String = redis_conn.get(keys_to_get).unwrap();
}
When I run cargo run I get:
Running `target/debug/test_resdis`
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: An error was signalled by the server: wrong number of arguments for 'get' command', ../src/libcore/result.rs:746
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: Process didn't exit successfully: `target/debug/test_resdis` (exit code: 101)
Am I doing something wrong, or is it a bug?
Running your program against a netcat server shows the following requests made:
*3
$3
GET
$12
random_key_1
$12
random_key_2
The GET command should be an MGET.
I believe this to be a bug in the implementation:
impl<T: ToRedisArgs> ToRedisArgs for Vec<T> {
fn to_redis_args(&self) -> Vec<Vec<u8>> {
ToRedisArgs::make_arg_vec(self)
}
}
impl<'a, T: ToRedisArgs> ToRedisArgs for &'a [T] {
fn to_redis_args(&self) -> Vec<Vec<u8>> {
ToRedisArgs::make_arg_vec(*self)
}
fn is_single_arg(&self) -> bool {
ToRedisArgs::is_single_vec_arg(*self)
}
}
Under the hood, the library inspects the key type to know if it's multivalued or not, using ToRedisArgs::is_single_arg, which has a default implementation of true.
As you can see, a slice implements ToRedisArgs::is_single_arg, but a Vec does not. This also suggests a workaround: treat the vector like a slice:
redis_conn.get(&*keys_to_get)
This issue has now been filed with the library.
I'm writing a "compiler" of sorts: it reads a description of a game (with rooms, characters, things, etc.) Think of it as a visual version of an Adventure-style game, but with much simpler problems.
When I run my "compiler" I'm getting a syntax error on my input, and I can't figure out why. Here's the relevant section of my yacc input:
character
: char-head general-text character-insides { PopChoices(); }
;
character-insides
: LEFTBRACKET options RIGHTBRACKET
;
char-head
: char-namesWT opt-imgsWT char-desc opt-cond
;
char-desc
: general-text { SetText($1); }
;
char-namesWT
: DOTC ID WORD { AddCharacter($3, $2); expect(EXP_TEXT); }
;
opt-cond
: %empty
| condition
;
condition
: condition-reason condition-main general-text
{ AddCondition($1, $2, $3); }
;
condition-reason
: DOTU { $$ = 'u'; }
| DOTV { $$ = 'v'; }
;
condition-main
: money-conditionWT
| have-conditionWT
| moves-conditionWT
| flag-conditionWT
;
have-conditionWT
: PERCENT_SLASH opt-bang ID
{ $$ = MkCondID($1, $2, $3) ; expect(EXP_TEXT); }
;
opt-bang
: %empty { $$ = TRUE; }
| BANG { $$ = FALSE; }
;
ID: WORD
;
Things in all caps are terminal symbols, things in lower or mixed case are non-terminals. If a non-terminal ends in WT, then it "wants text". That is, it expects that what comes after it may be arbitrary text.
Background: I have written my own token recognizer in C++ because(*) I want the syntax to be able to change the way the lexer's behavior. Two types of tokens should be matched only when the syntax expects them: FILENAME (with slashes and other non-alphameric characters) and TEXT, which means "all the text from here to the end of the line" (but not starting with certain keywords).
The function "expect" tells the lexer when to look for these two symbols. The expectation is reset to EXP_NORMAL after each token is returned.
I have added code to yylex that prints out the tokens as it recognizes them, and it looks to me like the tokenizer is working properly -- returning the tokens I expect.
(*) Also because I want to be able to ask the tokenizer for the column where the error occurred, and get the contents of the line being scanned at the time so I can print out a more useful error message.
Here is the relevant part of the input:
.c Wendy wendy
OK, now you caught me, what do you want to do with me?
.u %/lasso You won't catch me like that.
[
Here is the last part of the debugging output from yylex:
token: 262: DOTC/
token: 289: WORD/Wendy
token: 289: WORD/wendy
token: 292: TEXT/OK, now you caught me, what do you want to do with me?
token: 286: DOTU/
token: 274: PERCENT_SLASH/%/
token: 289: WORD/lasso
token: 292: TEXT/You won't catch me like that.
token: 269: LEFTBRACKET/
here's my error message:
: line 124, columns 3-4: syntax error, unexpected LEFTBRACKET, expecting TEXT
[
To help you understand the equations above, here is the relevant part of the description of the input syntax that I wrote the yacc code from.
// Character:
// .c id charactername,[imagename,[animationname]]
// description-text
// .u condition on the character being usable [optional]
// .v condition on the character being visible [optional]
// [
// (options)
// ]
// Conditions:
// %$[-]n Must [not] have at least n dollars
// %/[-]name Must [not] have named thing
// %t-nnn At/before specified number of moves
// %t+nnn At/after specified number of moves
// %#[-]name named flag must [not] be set
// Condition-char: $, /, t, or #, as described above
//
// Condition:
// % condition-char (identifier/int) ['/' text-if-fail ]
// description-text: Can be either on-line text or multi-line text
// On-line text is the rest of the line
brackets mark optional non-terminals, but a bracket standing alone (represented by LEFTBRACKET and RIGHTBRACKET in the yacc) is an actual token, e.g.
// [
// (options)
// ]
above.
What am I doing wrong?
To debug parsing problems in your grammar, you need to understand the shift/reduce machine that yacc/bison produces (described in the .output file produced with the -v option), and you need to look at the trail of states that the parser goes through to reach the problem you see.
To enable debugging code in the parser (which can print the states and the shift and reduce actions as they occur), you need to compile with -DYYDEBUG or put #define YYDEBUG 1 in the top of your grammar file. The debugging code is controlled by the global variable yydebug -- set to non-zero to turn on the trace and zero to turn it off. I often use the following in main:
#ifdef YYDEBUG
extern int yydebug;
if (char *p = getenv("YYDEBUG"))
yydebug = atoi(p);
#endif
Then you can include -DYYDEBUG in your compiler flags for debug builds and turn on the debugging code by something like setenv YYDEBUG 1 to set the envvar prior to running your program.
I suppose your syntax error message was generated by bison. What is striking is that it claims to have found a LEFTBRACKET when it expects a [. Naively, you might expect it to be satisfied with the LEFTBRACKET it found, but of course bison knows nothing about LEFTBRACKET except its numeric value, which will be some integer larger than 256.
The only reason bison might expect [ is if your grammar includes the terminal '['. But since your scanner seems to return LEFTBRACKET when it sees a [, the parser will never see '['.
I'm running spin in validation mode with the code like below. Got a problem with function called 'never'. While execution it gives me an error that functions inc(), dec() and reset() have never been accomplished. But if i add a cycle, it works great. By documentation, 'never' checks the variables on every step. So, why it does not work without a cycle?
int x=0
proctype Inc(){
do
::true ->
if
::x<10->x=x+1
fi
od
}
proctype Dec(){
do
::true ->
if
::x>0->x=x-1
fi
od
}
proctype Reset(){
do
::true ->
if
::x==10->x=0
fi
od
}
never { // if I need this to work, i have to add
To_Init: // this line
if
:: (x<0) || (10<x) -> goto accept
:: else -> goto To_Init // and that line
fi;
accept:
}
init{
run Inc();
run Dec();
run Reset();
}
'Never' block, that gives me a warning
never {
if
:: (x<0) || (10<x) -> goto accept
fi;
accept:
}
actually, thats not an error, that's kind of warning, shows unreached in proctype Inc, Dec, Reset, Init. Full warning log is below.
warning: for p.o. reduction to be valid the never claim must be stutter-invariant
(never claims generated from LTL formulae are stutter-invariant)
(Spin Version 6.2.7 — 2 March 2014)
+ Partial Order Reduction
Full statespace search for:
never claim + (never_0)
assertion violations + (if within scope of claim)
acceptance cycles + (fairness disabled)
invalid end states - (disabled by never claim)
State-vector 28 byte, depth reached 0, errors: 0
1 states, stored
0 states, matched
1 transitions (= stored+matched)
0 atomic steps
hash conflicts: 0 (resolved)
Stats on memory usage (in Megabytes):
0.000 equivalent memory usage for states (stored*(State-vector + overhead))
0.289 actual memory usage for states
128.000 memory used for hash table (-w24)
0.534 memory used for DFS stack (-m10000)
128.730 total actual memory usage
unreached in proctype Inc
l31never-no-cycle:6, state 3, "x = (x+1)"
l31never-no-cycle:6, state 4, "((x<10))"
l31never-no-cycle:4, state 6, "(1)"
l31never-no-cycle:9, state 9, "-end-"
(4 of 9 states)
unreached in proctype Dec
l31never-no-cycle:15, state 3, "x = (x-1)"
l31never-no-cycle:15, state 4, "((x>0))"
l31never-no-cycle:13, state 6, "(1)"
l31never-no-cycle:18, state 9, "-end-"
(4 of 9 states)
unreached in proctype Reset
l31never-no-cycle:24, state 3, "x = 0"
l31never-no-cycle:24, state 4, "((x==10))"
l31never-no-cycle:22, state 6, "(1)"
l31never-no-cycle:27, state 9, "-end-"
(4 of 9 states)
unreached in claim never_0
l31never-no-cycle:35, state 6, "-end-"
(1 of 6 states)
unreached in init
l31never-no-cycle:39, state 2, "(run Dec())"
l31never-no-cycle:40, state 3, "(run Reset())"
l31never-no-cycle:41, state 4, "-end-"
(3 of 4 states)
A never claim reports an error in two case: 1) an 'accept' cycle is detected, or 2) the never claim completes. A third possibility is if the never claim cannot take a step; this third possibility is the one your code is producing
When your claim was:
never {
if
:: (x<0) || (10<x) -> goto accept
fi;
accept:
}
the initial state has no possible step. That is, the never claim start state is just before the if; from that state where x==0 there is no possible next step.
When there is no possible step in a never claim, the verifier backtracks to a state where a step can be taken. In your case, there is no place to back up to and your verification ends because there is nothing more to do. The verifier then notes that lots of code didn't execute (because, in fact, nothing executed in your model).
You can tell that this is not what you anticipated because of all the unexecuted code. But is it not reported as an error.
For your subsequent case, you added an else. In this case the verifier can take a step in the never claim and thus your verification proceeds.
Here my function that execute cmd as a Rebol instructions :
exec-cmd: func [
cmd [ block! ] "Rebol instructions"
/local err
] [
if error? err: try [
do cmd
] [ print mold disarm err ]
]
When I launch the function, I've encountered the following error message :
** Script Error: err needs a value
** Where: exec-cmd
** Near: if error? err: try [
do cmd
]
How can I avoid this message and manage the error ?
When the Rebol default evaluator sees a sequence of a SET-WORD! followed by a "complete" expression, it will assign the result of that expression to the named word.
However, Rebol has the ability to return a special kind of "nothing" from a function called an UNSET!. For instance:
>> type? print {What "value" does a print return?}
What "value" does a print return?
== unset!
This is different from returning a NONE! value...because if you continue the chain of evaluation, the evaluator will not allow them in assignments.
>> foo: print {This isn't legal}
This isn't legal
** Script Error: foo needs a value
** Near: foo: print "This isn't legal"
Variables cannot actually "hold a value" of type UNSET!. UNSET! is just the "value type" that you will get if you try and access a variable that is not set. Regardless of the philosophical equivalence of whether there is a none value or not, the mechanical consequence is that if you want to allow an unset! value to effectively be "assigned" you have to do that "assignment" using the set function and the /any refinement:
>> set/any 'foo (print {This works...})
This works...
== unset!
But to be able to read from the value, you can't just reference it as the variable is now undefined. You need to use the corresponding get:
>> type? get/any 'foo
== unset!
Anyway, that's the background on why you're seeing this. Your cmd presumably ended with a function that returned an UNSET!, like maybe print?
Here's an example that may be illustrative:
exec-cmd: func [
cmd [block!] "Rebol instructions"
/local err
] [
set/any 'result (try [do cmd])
case [
unset? get/any 'result [
print "Cmd returned no result"
]
function? :result [
print ["Cmd returned a function:" newline (mold :result)]
]
;-- Rebol3 only --
;
; closure? :result [
; print ["Cmd returned a closure:" newline (mold :result)]
; ]
;-- Rebol3 should be changed to match Red and not require this --
;
lit-word? :result [
print ["Cmd returned a literal word:" newline (mold :result)]
]
error? result [
print mold disarm result
]
true [
print ["Cmd returned result of type" (mold type? result)]
print ["The value was:" newline (mold result)]
]
]
]
Notice that once you've already handled the case where result might be unset, you don't have to use get/any and can just do normal access.
There is a foundational issue in the way the interpreter works, that if a word is bound to a FUNCTION! value (also the CLOSURE! values in Rebol3) then referencing that word invokes the related code. To work around this, if you know you're in a situation where a word may hold a such a value you can use GET or the analogue of a SET-WORD! known as a GET-WORD!. These are generally considered "ugly" so it's best if you can isolate the part of the code that needs to test for such an edge case and not wind up putting colons in front of things you don't need to!
What has been deemed a design flaw is something called "lit-word decay". This necessitates the use of a GET-WORD! in Rebol2 if you have an actual literal word in your hand. In that case, your program won't crash, it just won't give you what you expect. It's explained here...it has already been changed in Red so it's certain to change for Rebol3.
Also, the concept of errors being "armed" and needing to be "disarmed" to be inspected has been eliminated in Rebol3. That doesn't affect the error? test in Rebol2 such that you'd need to use a GET-WORD!, but affected just about everything else you could do with them.
All right. I think I've covered all the cases here, but someone will correct me if I haven't!
(Note: if you're curious how to make your own function that returns an UNSET! like print does, just use exit instead of return)
>> nothing: func [value] [exit]
>> type? nothing 1020
== unset!
Use set/any and get/any to handle values that regular assignment and evaluation can't.
if error? set/any 'err try [
do cmd
] [ print mold disarm get/any 'err ]
Once the error is disarmed you can handle it normally.
rebol []
secretAgent: do func[ /local person firstName lastName][
firstName: "James"
lastName: "Bond"
person: make object! [
whoAreYou: func[][
print rejoin ["My name is " lastName ", " firstName " " lastName]
]
]
]
secretAgent/whoAreYou
if (error? (error: try [secretAgent/firstName])) [
probe disarm error
]
input
returns
My name is Bond, James Bond
** Script Error: Invalid path value: firstName
** Near: secretAgent/firstName
whereas I would expect same result as for
probe disarm try [secretAgent/firstName]
input
which returns:
My name is Bond, James Bond
make object! [
code: 311
type: 'script
id: 'invalid-path
arg1: 'firstName
arg2: none
arg3: none
near: [secretAgent/firstName]
where: none
]
Ah, that's a good example of why R3 tones down the way errors get triggered.
In R2, when an ERROR! values is evaluated (processed by the interpreter) it will activate the error handling mechanism. So, if you're not really careful, as you pass around the error value (like passing it to a function, returning it as a result, or in your case, evaluating it within a paren expression), it's going to trigger the error exception handler again.
In retrospect, this hair trigger was a poor evaluation rule. So, that's why R3 no longer handles errors that way. But, we cannot change it in R2.
Try without the extra (parentheses)
if error? error: try [secretAgent/firstName] [
probe disarm error
]
REBOL 2 errors are hair trigger. Your error was triggered in bubbling up one set of parentheses, rather than trapped.
See the difference here:
if error? error: try [0 / 0] [print ['bad mold disarm error]]
if error? (error: try [0 / 0]) [print ['bad mold disarm error]]
REBOL 3 error handling is slightly different -- disarm is not longer necessary, for example.