But checking, I noticed a bug that was probably causing your problem. Fixed now.
Incidentally, there is a [data at input slot ___] and also a [data at input byte ___].
From your calculation looks like you might be working with bytes, so you should use the second form. "slots" are 32-byte chunks. Those are more friendly to work with in (most) contracts which expect inputs in that form.
I'd love to eradicate bytes from the UI. POC-5 will make that more practical since that client accepts 32-byte inputs by default (unlike POC-4).
EDIT: I'm discovering some deep-running mismatches arising from different expectations for bytes or slots. I'll have to invest further time to reconcile this but might have to abandon the idea of hiding bytes from user for memory access.
@mode80 RE:tooltips. My first reaction is that the font size is too small. Secondly, the response from mousing over takes a wee bit too long to display. Having said that if it responds too quickly, it can be quite irritating.
I suggest the compromise is to do the right click on the block and click on help. Then display a larger font description. After all, it is during the initial learning curve that someone will want to read it. Once you are adept at it, you won't want to be bothered with the help.
Mouseover should be reserved for comments made on the block. That is much neater and will be more frequently used by the adept user.
@Bluefin, further to up above, I've rolled back that "fix" because it's really not a complete solution.
Etherescripter 0.4.0 tries to abstract away the concept of bytes by presenting things in terms of "slots" (which are 32-byte chunks) and then doing needed calculation "behind the scenes". Unfortunately it was never able to do this completely because other contracts might expect inputs in some form other than 32-byte chunks, so the concept of bytes was still partially exposed.
Then you discovered that the "behind-the-scenes" calculation breaks down when supplied anything other than a simple number. (Supplying a label or expressions for the slot number doesn't work). My quickfix above would just blur the distinction between slots and bytes without fixing everything it needs to.
The real solution is for me to overhaul this broken leaky abstraction or abandon it. I will do that but I will save it for 0.5.0. In the meantime supplying an expression to [data at input slot __] won't work, but you can work around this by using [data at input byte ___] instead.
Agreed there's too much info crammed into the tooltips. A one-liner for each block combined with a link to a more detailed Help page would be better long term.
@mode80 me and my colleague's are using etherscripter on several occasions already. nice for teaching, really productive tool. one thing which is bogging down the user exp is scrolling. I.e., you have the (long) tool list on the left and the canvas on the right. Now, scrolling would be much more convenient if the two panes are separate scrolling areas.
Yes, I've noticed that gets annoying on long contracts. The library I'm using for rendering the canvas has limited options for scrolling, but I'll look for some way to make this possible.
In the meantime, one thing that helps a little is zooming out on your browser (e.g. View->ZoomOut menuitem in Chrome).
@mode80 alright. i reckon that bugs go in here as well? we (me + ralph) spotted a simple but nasty one LLL code generation relevant to PoC 4 and 5 as well: tx.input_slot_count converts to LLL code item: 'calldatasize' which is translated to PUSH1 0x36 in AlethZero. Correct LLL output would be '(calldatasize)' which then translates to the right CALLDATASIZE byte code.
Ouch. Fixed that for you. The old code was intended to "round up" if there was leftover input after dividing it into 32-byte chunks. I changed it to "round down" which is consistent with how Serpent does it. In general it shouldn't matter when input is given supplied in even 32-byte chunks, as will be more standard with POC-5.
If you think your bug report might help others, you can always post it here. Otherwise, can just send a forum private message, and I'll still get it.
I would like to test. I am not technical but I have been learning python to try and get to where I could write contracts. Maybe this could speed up my progress.
@mode80 - cool work. Thanks for your work... Though it works fully client side why not to do it opensource? I think a big part of community will look for tooling to build better contracts faster...
Honestly, no. I made and maintained EtherScripter in my spare time up through POC-5. Given the pace of change, it was way too early. A lot of wasted effort would have gone into maintaining compatibility. That, and it wasn’t especially welcomed by (some) core devs.
I do think the world needs a system of private law that Ethereum enables. I wanted that within reach of everyone, not just programmers.
Maybe EtherScripter will inspire someone to take another crack once the tech settles.
@mode80 Thanks for the reply. EtherScripter is/was very impressive. I am curious as to how easily non-programmers will get the hang of creating dapps, once as you said, things settle down tech wise.
You working on anything else with 1.0 coming up next month?
Would be great if contacts can be registered to a name and owned. So that developers can upgrade them (based on some upgrade authorization, voting, etc.)
Comments
But checking, I noticed a bug that was probably causing your problem. Fixed now.
Incidentally, there is a [data at input slot ___] and also a [data at input byte ___].
From your calculation looks like you might be working with bytes, so you should use the second form. "slots" are 32-byte chunks. Those are more friendly to work with in (most) contracts which expect inputs in that form.
I'd love to eradicate bytes from the UI. POC-5 will make that more practical since that client accepts 32-byte inputs by default (unlike POC-4).
EDIT: I'm discovering some deep-running mismatches arising from different expectations for bytes or slots. I'll have to invest further time to reconcile this but might have to abandon the idea of hiding bytes from user for memory access.
I suggest the compromise is to do the right click on the block and click on help. Then display a larger font description. After all, it is during the initial learning curve that someone will want to read it. Once you are adept at it, you won't want to be bothered with the help.
Mouseover should be reserved for comments made on the block. That is much neater and will be more frequently used by the adept user.
complete solution.
Etherescripter 0.4.0 tries to abstract away the concept of bytes by presenting things in terms of "slots" (which are 32-byte chunks) and then doing needed calculation "behind the scenes". Unfortunately it was never able to do this completely because other contracts might expect inputs in some form other than 32-byte chunks, so the concept of bytes was still partially exposed.
Then you discovered that the "behind-the-scenes" calculation breaks down when supplied anything other than a simple number. (Supplying a label or expressions for the slot number doesn't work). My quickfix above would just blur the distinction between slots and bytes without fixing everything it needs to.
The real solution is for me to overhaul this broken leaky abstraction or abandon it. I will do that but I will save it for 0.5.0. In the meantime supplying an expression to [data at input slot __] won't work, but you can work around this by using [data at input byte ___] instead.
Agreed there's too much info crammed into the tooltips. A one-liner for each block combined with a link to a more detailed Help page would be better long term.
I.e., you have the (long) tool list on the left and the canvas on the right. Now, scrolling would be much more convenient if the two panes are separate scrolling areas.
In the meantime, one thing that helps a little is zooming out on your browser (e.g. View->ZoomOut menuitem in Chrome).
LLL code generation relevant to PoC 4 and 5 as well:
tx.input_slot_count converts to LLL code item: 'calldatasize' which is translated to PUSH1 0x36 in AlethZero. Correct LLL output would be '(calldatasize)' which then translates to the right CALLDATASIZE byte code.
If you think your bug report might help others, you can always post it here. Otherwise, can just send a forum private message, and I'll still get it.
Honestly, no. I made and maintained EtherScripter in my spare time up through POC-5. Given the pace of change, it was way too early. A lot of wasted effort would have gone into maintaining compatibility. That, and it wasn’t especially welcomed by (some) core devs.
I do think the world needs a system of private law that Ethereum enables. I wanted that within reach of everyone, not just programmers.
Maybe EtherScripter will inspire someone to take another crack once the tech settles.
You working on anything else with 1.0 coming up next month?
Thanks