|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
Russian Federation4235 Posts
On November 17 2017 00:21 Manit0u wrote:Show nested quote +On November 16 2017 23:21 Deckard.666 wrote:On November 16 2017 18:59 Manit0u wrote:
Is there a way to make JavaScript print 1.0 into JSON? It's super dumb considering that every number in JS is a float, but you can't display them as floats if they only have 0's in decimal places (and I need it to do so). Like this, maybe?
let encoded = JSON.stringify({num: 1.0}).replace(/(?!\.)\d+(?!\.)/,"$&.0")
console.log(encoded) // {"num":1.0}
Kinda ugly using regex to modify the JSON, but I don't think you can make JSON.stringify output it like that directly. Unfortunately this won't fly. The problem is that we have to pass user input from the front-end form (many values are being passed, strings, floats, integers, booleans to the API as JSON, it is then passed on to external tools which require that all float values have decimal notation. The input is validated for type and it would be stupid to convert some values to float since technically the user could input invalid float (passed as string and cast to float) and casting it could skew the validation. JavaScript is so awful at times  Would it be so hard for them to implement simple functions like toFloat() (kinda stupid for JS since every number is a float by default, they just show it as int) or toInt()?
How bout adding 0.0000001 to every number in your JSON?
|
On November 18 2017 17:27 bo1b wrote:Show nested quote +On November 18 2017 15:56 phar wrote:On November 16 2017 15:40 bo1b wrote:On November 16 2017 06:45 Silvanel wrote:On November 15 2017 22:40 bo1b wrote:
That letter looks like it's from Victoria, Australia - most likely in melbourne. I didn't know we had any companies in this area which used erlang. Out of curiosity, You based it on what? The letter referenced something called vcat. More than possible theres another tribunal somewhere around the world called vcat, but im fairly certain it's located in Australia, Victoria, Melbourne. Jesus $55/hr is the going rate for "lead developer" in Melbourne? Actually nvm if the owner is still interviewing people that place has gotta be tiny as shit 55 an hour is no where near the going rate for lead dev in Melbourne. Having a forklift license qualifies you for ~50 an hour here, a lead dev is on > 180k a year before stock generally.
Ok that sounds much more realistic
|
manitou how about passing "x.0" floats as a string with some sort of identifer in front that the user would never type? Then have the external tools cast any strings starting with the identifier back to float? that's assume you can actually edit the "external tools"
there's probably other options but we'd need to know what these tools are doing!
|
Worst case you'd have to write our own json serializer along with a custom object.toString equivalent that converts floats the way you want, right? You obviously never want to do that, but it shouldn't be all that hard to create a good enough serializer if you control the input.
|
On November 19 2017 17:30 spinesheath wrote:
Worst case you'd have to write our own json serializer along with a custom object.toString equivalent that converts floats the way you want, right? You obviously never want to do that, but it shouldn't be all that hard to create a good enough serializer if you control the input.
I'll guess I'll have to create custom validations for this (to make sure that the passed string is indeed a float) and cast it in the back-end before sending it off.
JavaScript has seriously disappointed me.
|
Not sure if this is the right thread to whine about this stuff: Holy shit Microsoft/Windows get your act together! I just spent an hour trying to set up QTCreator with msvc compiler because absolutely everything is changed around for no apparent reason. Back with msvc 2015 it was literally just download, install and run and everything in QT would be set up pretty automatically (Except for windows debugger, which has ALSO changed location for absolutely no reason). Now you have to waddle around within 20 bullshit folders to find the stuff you need, and of course absolutely nothing is documented anywhere. /rant
|
On November 19 2017 23:13 Manit0u wrote:Show nested quote +On November 19 2017 17:30 spinesheath wrote:
Worst case you'd have to write our own json serializer along with a custom object.toString equivalent that converts floats the way you want, right? You obviously never want to do that, but it shouldn't be all that hard to create a good enough serializer if you control the input. I'll guess I'll have to create custom validations for this (to make sure that the passed string is indeed a float) and cast it in the back-end before sending it off. JavaScript has seriously disappointed me.
Sounds like you just need your backend to deserialize / cast to float / serialize / send out.
|
I have been trying to send funds from one ethereum account to another using web3j to test that it works on Android. I am using an Infura cloud instance.
First, it appears I need to send it async because Android requires that you do so. In the code down below I have tried to do so - but it fails on the last step, when I try to get from the Future. If I do not try to get the value then there is no exception, but I obviously cannot do anything with the value that I want to do.
final String FROM_ADDRESS = "0x6861B070f43842FC16eAD07854eE5D91B9D27C13";
final String TO_ADDRESS = "0x31B98D14007bDEe637298086988A0bBd31184523";
//Credentials credentials = obtainCredentials(WALLET_DIRECTORY);
Callable<TransactionReceipt> task = new Callable<TransactionReceipt>() {
@Override
public TransactionReceipt call() throws Exception {
Web3j web3 = Web3jFactory.build(
new HttpService("https://rinkeby.infura.io/SxLC8uFzMPfzwnlXHqx9")
);
Log.d(TAG, web3.ethGasPrice().getJsonrpc());
ClientTransactionManager clientTransactionManager =
new ClientTransactionManager(web3, FROM_ADDRESS);
Log.d(TAG, clientTransactionManager.getFromAddress());
org.web3j.tx.Transfer tran = new org.web3j.tx.Transfer(web3, clientTransactionManager);
Log.d(TAG, String.valueOf(tran.getSyncThreshold()));
RemoteCall<TransactionReceipt> rc = tran.sendFunds(
TO_ADDRESS,
BigDecimal.valueOf(1.0),
Convert.Unit.ETHER
);
Log.d(TAG, String.valueOf(rc.toString()));
return rc.send();
}
};
Future<TransactionReceipt> future = Async.run(task);
return future.get();
It comes with this exception:
11-19 12:49:03.418 32442-32442/com.example.graeme.beamitup W/System.err: java.util.concurrent.ExecutionException: org.web3j.protocol.exceptions.ClientConnectionException: Invalid response received: okhttp3.internal.http.RealResponseBody@3c286ab
11-19 12:49:03.418 32442-32442/com.example.graeme.beamitup W/System.err: at java.util.concurrent.FutureTask.report(FutureTask.java:94)
11-19 12:49:03.419 32442-32442/com.example.graeme.beamitup W/System.err: at java.util.concurrent.FutureTask.get(FutureTask.java:164)
11-19 12:49:03.419 32442-32442/com.example.graeme.beamitup W/System.err: at com.example.graeme.beamitup.Transfer.sendTransfer(Transfer.java:183)
11-19 12:49:03.419 32442-32442/com.example.graeme.beamitup W/System.err: at com.example.graeme.beamitup.MainActivity.onCreate(MainActivity.java:26)
11-19 12:49:03.419 32442-32442/com.example.graeme.beamitup W/System.err: at android.app.Activity.performCreate(Activity.java:6272)
It points out an invalid response from the HTTP transfer - but shouldn't this be happening even without trying the Future.get? The code executes either way, correct? What have I done wrong to create this error?
|
Sorry on a phone so can't look much, but a future in Java doesn't necessarily execute anything until you try to get the value (either directly or via some util library like guava futures). So when you call
Future<Foo> x = ...;
Nothing actually happens. Then when you call
x.get()
You get actual stuff happening (namely, a blocking wait on the value returning). You should read into Java async more, since I'm obviously glossing over a lot of things.
Also note this doesn't explain at all why you're getting the error at all, which I can't really look into now because phone, sorry.
Can you confirm that some existing command line http util (like wget or something) works fine? It might be your server that's at fault? (Or is it not your server, I wasn't super clear on that)
|
On November 20 2017 11:43 phar wrote:
Sorry on a phone so can't look much, but a future in Java doesn't necessarily execute anything until you try to get the value (either directly or via some util library like guava futures). So when you call
Future<Foo> x = ...;
Nothing actually happens. Then when you call
x.get()
You get actual stuff happening (namely, a blocking wait on the value returning). You should read into Java async more, since I'm obviously glossing over a lot of things.
Also note this doesn't explain at all why you're getting the error at all, which I can't really look into now because phone, sorry.
Can you confirm that some existing command line http util (like wget or something) works fine? It might be your server that's at fault? (Or is it not your server, I wasn't super clear on that)
Aw frick, that is not what I was hoping to hear.  Thanks for the info! I read Future.get() and they made it sound like it only retrieved the value(and waited if need be), but I must have misread/misunderstood.
I'll look into the command line stuff. It's not my server - it's an Infura ethereum client in the cloud, which means you don't have to DL the client to, for example, a phone(though it goes against the point of ETH by using a centralized server).
|
On November 20 2017 11:43 phar wrote:
Sorry on a phone so can't look much, but a future in Java doesn't necessarily execute anything until you try to get the value (either directly or via some util library like guava futures). So when you call
Future<Foo> x = ...;
Nothing actually happens. Then when you call
x.get()
You get actual stuff happening (namely, a blocking wait on the value returning). You should read into Java async more, since I'm obviously glossing over a lot of things.
Are you sure about that? I believe the work starts when you run the task but on a different thread than the current one.
|
On November 20 2017 15:02 Hanh wrote:Show nested quote +On November 20 2017 11:43 phar wrote:
Sorry on a phone so can't look much, but a future in Java doesn't necessarily execute anything until you try to get the value (either directly or via some util library like guava futures). So when you call
Future<Foo> x = ...;
Nothing actually happens. Then when you call
x.get()
You get actual stuff happening (namely, a blocking wait on the value returning). You should read into Java async more, since I'm obviously glossing over a lot of things.
Are you sure about that? I believe the work starts when you run the task but on a different thread than the current one.
Yes it can start immediately, depends on how things are constructed. That's what I meant by glossing over things... I wasn't being super precise.
However from warsame's perspective, it's as though nothing happens until he calls .get because he's not waiting at all between the two statements. The time it takes his cpu to move from the future = statement to the future.get statement is on the order of a nanosecond. The time it takes for your network to issue a http request and get a response is on the order of a millisecond, to possibly tens or hundreds of ms depending on distance and how shitty your network is. So from the CPUs perspective, fucking nothing happened before calling .get
Same deal if you issue a disk read. Your cpu can execute something on the order of 60 million instructions (possibly more or less depending on what you're doing) before getting *a single byte* back from a disk read. Thus for most things you do async in Java, you won't stumble across exception like warsame is seeing until you actually do a blocking wait (e.g. future.get or something similar).
|
On November 20 2017 12:44 WarSame wrote:Show nested quote +On November 20 2017 11:43 phar wrote:
Sorry on a phone so can't look much, but a future in Java doesn't necessarily execute anything until you try to get the value (either directly or via some util library like guava futures). So when you call
Future<Foo> x = ...;
Nothing actually happens. Then when you call
x.get()
You get actual stuff happening (namely, a blocking wait on the value returning). You should read into Java async more, since I'm obviously glossing over a lot of things.
Also note this doesn't explain at all why you're getting the error at all, which I can't really look into now because phone, sorry.
Can you confirm that some existing command line http util (like wget or something) works fine? It might be your server that's at fault? (Or is it not your server, I wasn't super clear on that) Aw frick, that is not what I was hoping to hear. Thanks for the info! I read Future.get() and they made it sound like it only retrieved the value(and waited if need be), but I must have misread/misunderstood. I'll look into the command line stuff. It's not my server - it's an Infura ethereum client in the cloud, which means you don't have to DL the client to, for example, a phone(though it goes against the point of ETH by using a centralized server).
Ok get the http request working without writing any code first to isolate that as a problem. E.g. with wget or some such tool. There also exist browser plugins that will work.
Generally speaking when writing software, only do one new thing at a time until you verify that it works. Ideally write a test for each new step/thing you get working. Once you get better or more confident you can try skipping and doing a bunch of things at once, but if it fails then you go back to looking at things one at a time.
In this case isolate the http request first, *then* write some new code to issue that http request.
|
On November 19 2017 23:13 Manit0u wrote:
JavaScript has seriously disappointed me.
It never disappointed me. I never had any positive expectations about js to begin with.
|
On November 14 2017 20:08 Manit0u wrote:![[image loading]](https://i.imgur.com/7Q9S0Qp.jpg) It seems that "We'll contact you soon" takes on a completely new meaning in this day and age...
Why do people block out the company name? Why not name and shame so prospective interviewees and employees know what they are in for.
|
On November 21 2017 03:04 Piledriver wrote:Show nested quote +On November 14 2017 20:08 Manit0u wrote:It seems that "We'll contact you soon" takes on a completely new meaning in this day and age... Why do people block out the company name? Why not name and shame so prospective interviewees and employees know what they are in for.
They would probably sue them.
|
On November 20 2017 15:02 Hanh wrote:Show nested quote +On November 20 2017 11:43 phar wrote:
Sorry on a phone so can't look much, but a future in Java doesn't necessarily execute anything until you try to get the value (either directly or via some util library like guava futures). So when you call
Future<Foo> x = ...;
Nothing actually happens. Then when you call
x.get()
You get actual stuff happening (namely, a blocking wait on the value returning). You should read into Java async more, since I'm obviously glossing over a lot of things.
Are you sure about that? I believe the work starts when you run the task but on a different thread than the current one.
Ah, that clears up my misunderstanding. I needed to do a Future because Android prohibits you from doing networking on the main thread.
On November 21 2017 02:16 phar wrote:Show nested quote +On November 20 2017 12:44 WarSame wrote:On November 20 2017 11:43 phar wrote:
Sorry on a phone so can't look much, but a future in Java doesn't necessarily execute anything until you try to get the value (either directly or via some util library like guava futures). So when you call
Future<Foo> x = ...;
Nothing actually happens. Then when you call
x.get()
You get actual stuff happening (namely, a blocking wait on the value returning). You should read into Java async more, since I'm obviously glossing over a lot of things.
Also note this doesn't explain at all why you're getting the error at all, which I can't really look into now because phone, sorry.
Can you confirm that some existing command line http util (like wget or something) works fine? It might be your server that's at fault? (Or is it not your server, I wasn't super clear on that) Aw frick, that is not what I was hoping to hear. Thanks for the info! I read Future.get() and they made it sound like it only retrieved the value(and waited if need be), but I must have misread/misunderstood. I'll look into the command line stuff. It's not my server - it's an Infura ethereum client in the cloud, which means you don't have to DL the client to, for example, a phone(though it goes against the point of ETH by using a centralized server). Ok get the http request working without writing any code first to isolate that as a problem. E.g. with wget or some such tool. There also exist browser plugins that will work. Generally speaking when writing software, only do one new thing at a time until you verify that it works. Ideally write a test for each new step/thing you get working. Once you get better or more confident you can try skipping and doing a bunch of things at once, but if it fails then you go back to looking at things one at a time. In this case isolate the http request first, *then* write some new code to issue that http request.
My machine is on Windows and it's surprisingly hard to do HTTP req/res but luckily I found out about Postman.
I also apparently fixed the issue, but now am struggling because web3j is weird/doesn't do what their documentation says. I'm reading through their actual code and it's not nice either. Such is life! Thanks for the help!
|
You should really use RxJava and Retrofit warsame
|
I got the code I was working on to finally work muthafuckas!!!
@Blisse, is that because it slots into Java really nicely? I glanced through their pages and didn't see anything that made it a must-have, but then again I also don't know much.
|
Nice! Was it because the credentials were not passed to the transaction 'send funds'?
|
|
|
|
|
|
EPT
