... just to get a feel how fast we are proceeding. A few months ago, our editor looked like this fella here:
Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 193. (Read 450523 times)
December 15, 2016, 03:15:20 PM
Our SDK Editor just got one tad sexier ;-)
... just to get a feel how fast we are proceeding. A few months ago, our editor looked like this fella here:
... just to get a feel how fast we are proceeding. A few months ago, our editor looked like this fella here:
December 14, 2016, 09:02:32 PM
Specifically Poloniex is known to refuse to list unproven/early stages coins, unless thorough testing has been done.
I completely agree with you. Let's do a lot of Testing and not to hurry to release it.The worst part is, if they don't feel confident in a product at launch, then it's virtually impossible to have them list it later.
Waves and Raiblocks to name a few never got listed on Polo.
I agree with you to not rush it
What they (or anyone else) are "developing" doesn't have anything to do do with exchange listing. The Waves team had already got their money so as Elastic did. I think the project should be launched when the developers think it's ready and exchanges should list as soon as they want to. This could be completely different timeframes. One should not affect the other.
December 14, 2016, 06:22:21 PM
Specifically Poloniex is known to refuse to list unproven/early stages coins, unless thorough testing has been done.
I completely agree with you. Let's do a lot of Testing and not to hurry to release it.The worst part is, if they don't feel confident in a product at launch, then it's virtually impossible to have them list it later.
Waves and Raiblocks to name a few never got listed on Polo.
I agree with you to not rush it
December 14, 2016, 03:51:35 PM
Because my eyeballs do not see github wiki, I can only guess what an elastic grammar is as well as what language that is, that u posted a part of in a quote above ur last post with a snapshot of development environment. The coding environment utilizes the color scheme analogous to firefox devedition dark theme, obviously this and firefox dev tools are very much alike. Will it run on windows? Im eager to compile something in ur environment.
December 14, 2016, 03:44:07 PM
Fuck yeah, that's beautiful! Which language does ElasticPL resemble the most, by the way?
It is basically C but without any variables, data types, switch-cases, gotos, pointers, and all other evil stuff ;-)
Instead it comes with all sorts of built in functions (crypto, big numbers arithmetic, mathematical functions, ...) as well as a "repeat()" function to create loops with strictly bounded iteration count.
I guess we need a "Language Tutorial and Specification" ;-)
So, instead of variables, what do you use exactly? The "m" thing looks like a variable to me…? I mean, sure, in a distributed computer, it would be pretty hard to assign an address to it?
Well, to avoid "shooting down nodes" my exceeding their memory, we have this comcept.
Every program has a fixed memory, and only there it can either write values to or read values from.
A program coded in Elastic PL can use
64000 integers in the m[] array
1000 floats in the f[] array
and 100 big integers in the b[] array.
Those arrays are just there, magically, and no new variable can be declared programatically.
December 14, 2016, 03:33:56 PM
Fuck yeah, that's beautiful! Which language does ElasticPL resemble the most, by the way?
It is basically C but without any variables, data types, switch-cases, gotos, pointers, and all other evil stuff ;-)
Instead it comes with all sorts of built in functions (crypto, big numbers arithmetic, mathematical functions, ...) as well as a "repeat()" function to create loops with strictly bounded iteration count.
I guess we need a "Language Tutorial and Specification" ;-)
So, instead of variables, what do you use exactly? The "m" thing looks like a variable to me…? I mean, sure, in a distributed computer, it would be pretty hard to assign an address to it?
December 14, 2016, 03:31:07 PM
Fuck yeah, that's beautiful! Which language does ElasticPL resemble the most, by the way?
It is basically C (i guess in its form its also similar to javascript) but without any variables, data types, switch-cases, functions, gotos, pointers, and all other evil stuff ;-)
Instead it comes with all sorts of built in functions (crypto, big numbers arithmetic, mathematical functions, ...) as well as a "repeat()" function to create loops with strictly bounded iteration count.
I guess we need a "Language Tutorial and Specification" ;-)
December 14, 2016, 03:23:24 PM
Please don't push to get listed on exchanges. I'd rather see the project mature before approaching exchanges.
Specifically Poloniex is known to refuse to list unproven/early stages coins, unless thorough testing has been done.
Look at how long Ethereum guys tested before they launched. I know it would be great gift for Xmas for it to go live, but I think you're better off in the long run if the launch is solid.
Specifically Poloniex is known to refuse to list unproven/early stages coins, unless thorough testing has been done.
Look at how long Ethereum guys tested before they launched. I know it would be great gift for Xmas for it to go live, but I think you're better off in the long run if the launch is solid.
I completely agree with you. Let's do a lot of Testing and not to hurry to release it.
While I agree in principle, I think it would be important to have some kind of "in-house" OTC market for XEL. Without buying XEL, you can't use the Elastic network. Without the possibility to sell XEL, miners won't be so keen on providing their computing power.
XEL lives and dies with the possibility to be bought and sold.
Good news for those of you, who want to experiment with Elastic PL soon!
You always wanted a nice looking Development Environment for Elastic?
You always wanted real syntax highlighting for the Elastic PL language?
You always wanted to get compiler errors to exactly know the line where your syntax error is?
You always wanted to debug the VM memory of your elastic program?
Then just enjoy the following ...
(pictures)
You always wanted a nice looking Development Environment for Elastic?
You always wanted real syntax highlighting for the Elastic PL language?
You always wanted to get compiler errors to exactly know the line where your syntax error is?
You always wanted to debug the VM memory of your elastic program?
Then just enjoy the following ...
(pictures)
Fuck yeah, that's beautiful! Which language does ElasticPL resemble the most, by the way?
December 14, 2016, 03:21:09 PM
Good news for those of you, who want to experiment with Elastic PL soon!
You always wanted a nice looking Development Environment for Elastic?
You always wanted real syntax highlighting for the Elastic PL language?
You always wanted to get compiler errors to exactly know the line where your syntax error is?
You always wanted to debug the VM memory of your elastic program?
Then just enjoy the following ...
You always wanted a nice looking Development Environment for Elastic?
You always wanted real syntax highlighting for the Elastic PL language?
You always wanted to get compiler errors to exactly know the line where your syntax error is?
You always wanted to debug the VM memory of your elastic program?
Then just enjoy the following ...
December 14, 2016, 01:40:32 PM
Specifically Poloniex is known to refuse to list unproven/early stages coins, unless thorough testing has been done.
I completely agree with you. Let's do a lot of Testing and not to hurry to release it.The worst part is, if they don't feel confident in a product at launch, then it's virtually impossible to have them list it later.
Waves and Raiblocks to name a few never got listed on Polo.
December 14, 2016, 12:01:28 PM
Please don't push to get listed on exchanges. I'd rather see the project mature before approaching exchanges.
Specifically Poloniex is known to refuse to list unproven/early stages coins, unless thorough testing has been done.
Look at how long Ethereum guys tested before they launched. I know it would be great gift for Xmas for it to go live, but I think you're better off in the long run if the launch is solid.
Specifically Poloniex is known to refuse to list unproven/early stages coins, unless thorough testing has been done.
Look at how long Ethereum guys tested before they launched. I know it would be great gift for Xmas for it to go live, but I think you're better off in the long run if the launch is solid.
I completely agree with you. Let's do a lot of Testing and not to hurry to release it.
December 14, 2016, 11:18:13 AM
Step 1:
The Mainnet is locked and offline. In order to launch it, 25% of all tokens must be redeemed. This essentially means that the users (to recall, I code this for you guys) decide thenselves when to launch or not to launch. If the whales think the code sucks, they just delay!
when step one start?
The Mainnet is locked and offline. In order to launch it, 25% of all tokens must be redeemed. This essentially means that the users (to recall, I code this for you guys) decide thenselves when to launch or not to launch. If the whales think the code sucks, they just delay!
when step one start?
December 14, 2016, 10:55:28 AM
Please don't push to get listed on exchanges. I'd rather see the project mature before approaching exchanges.
Specifically Poloniex is known to refuse to list unproven/early stages coins, unless thorough testing has been done.
Look at how long Ethereum guys tested before they launched. I know it would be great gift for Xmas for it to go live, but I think you're better off in the long run if the launch is solid.
Specifically Poloniex is known to refuse to list unproven/early stages coins, unless thorough testing has been done.
Look at how long Ethereum guys tested before they launched. I know it would be great gift for Xmas for it to go live, but I think you're better off in the long run if the launch is solid.
December 13, 2016, 05:11:37 PM
I am sure there could be a mechanism to make trades from one block experiment to the next stably bound and deterministic right? great plan EK
December 13, 2016, 02:00:00 PM
What about this "Mainnet Release Plan"?
Disclaimer: I am just a coder so I am not launching anything. I am just coding an open source product as best as my knowledge allows me to. So I will not be launching anything. So this is what I thought.
Step 1:
The Mainnet is locked and offline. In order to launch it, 25% of all tokens must be redeemed. This essentially means that the users (to recall, I code this for you guys) decide thenselves when to launch or not to launch. If the whales think the code sucks, they just delay!
Step 2:
We have a 5 stage launch. This means, that the first version, let's say 1.0, will only run from Block 1 to Block 5000 and then stop.
Then, version 1.1 will rum from Block 5001-10000, and so on. So we have five "hard forks" basically between blocks 1 and 25000 in which we can embed potential fixes or changes to the protocol without crippling the network, since old clients will just stop syncing at block X.
Since the bounds are known, I don't see a problem here.
We explicitly say that the blockchain may be reverted partially or totally during this time span.
Step 3:
After some more excessive testing we roll out 1.5 which begins at block 25001 (so basically after 17,5 days approx.) and goes on forever ;-)
I think this would give us some real field testing and not just on the test net, and give us five chances to fix any future bugs.
What do you think about this? Do you have any suggestions?
Of course, we have to make the GPU miner happen first, and rethink the missing parts about the ElasticPL language.
Disclaimer: I am just a coder so I am not launching anything. I am just coding an open source product as best as my knowledge allows me to. So I will not be launching anything. So this is what I thought.
Step 1:
The Mainnet is locked and offline. In order to launch it, 25% of all tokens must be redeemed. This essentially means that the users (to recall, I code this for you guys) decide thenselves when to launch or not to launch. If the whales think the code sucks, they just delay!
Step 2:
We have a 5 stage launch. This means, that the first version, let's say 1.0, will only run from Block 1 to Block 5000 and then stop.
Then, version 1.1 will rum from Block 5001-10000, and so on. So we have five "hard forks" basically between blocks 1 and 25000 in which we can embed potential fixes or changes to the protocol without crippling the network, since old clients will just stop syncing at block X.
Since the bounds are known, I don't see a problem here.
We explicitly say that the blockchain may be reverted partially or totally during this time span.
Step 3:
After some more excessive testing we roll out 1.5 which begins at block 25001 (so basically after 17,5 days approx.) and goes on forever ;-)
I think this would give us some real field testing and not just on the test net, and give us five chances to fix any future bugs.
What do you think about this? Do you have any suggestions?
Of course, we have to make the GPU miner happen first, and rethink the missing parts about the ElasticPL language.
Great plan EK,but as above guys says,during step 2 times,there are none exchanges will list a 'keep test forking' xel coin,isnot it? That will be a big price hurting for xel,pls thinking more.
How about launch a 'stable alpha' mainet for instead?
I can undestand EK seeing things from a "perfectionist" point of view . There is no reason for exchanges to list XEL from the very beggining . IOTA is launched and it isn't listed still in exchanges although people trade it in high prices compared to ICO . And i believe that price will not be negative affected for a product that is heavily tested , i think the opposite is most certain .
My apologies for my poor English , i hope you get my point .
PS . EK , you are my hero , keep up the fantastic work . Also a great thank you to all the members that helped this project come true .
December 13, 2016, 08:40:32 AM
What about this "Mainnet Release Plan"?
Disclaimer: I am just a coder so I am not launching anything. I am just coding an open source product as best as my knowledge allows me to. So I will not be launching anything. So this is what I thought.
Step 1:
The Mainnet is locked and offline. In order to launch it, 25% of all tokens must be redeemed. This essentially means that the users (to recall, I code this for you guys) decide thenselves when to launch or not to launch. If the whales think the code sucks, they just delay!
Step 2:
We have a 5 stage launch. This means, that the first version, let's say 1.0, will only run from Block 1 to Block 5000 and then stop.
Then, version 1.1 will rum from Block 5001-10000, and so on. So we have five "hard forks" basically between blocks 1 and 25000 in which we can embed potential fixes or changes to the protocol without crippling the network, since old clients will just stop syncing at block X.
Since the bounds are known, I don't see a problem here.
We explicitly say that the blockchain may be reverted partially or totally during this time span.
Step 3:
After some more excessive testing we roll out 1.5 which begins at block 25001 (so basically after 17,5 days approx.) and goes on forever ;-)
I think this would give us some real field testing and not just on the test net, and give us five chances to fix any future bugs.
What do you think about this? Do you have any suggestions?
Of course, we have to make the GPU miner happen first, and rethink the missing parts about the ElasticPL language.
Disclaimer: I am just a coder so I am not launching anything. I am just coding an open source product as best as my knowledge allows me to. So I will not be launching anything. So this is what I thought.
Step 1:
The Mainnet is locked and offline. In order to launch it, 25% of all tokens must be redeemed. This essentially means that the users (to recall, I code this for you guys) decide thenselves when to launch or not to launch. If the whales think the code sucks, they just delay!
Step 2:
We have a 5 stage launch. This means, that the first version, let's say 1.0, will only run from Block 1 to Block 5000 and then stop.
Then, version 1.1 will rum from Block 5001-10000, and so on. So we have five "hard forks" basically between blocks 1 and 25000 in which we can embed potential fixes or changes to the protocol without crippling the network, since old clients will just stop syncing at block X.
Since the bounds are known, I don't see a problem here.
We explicitly say that the blockchain may be reverted partially or totally during this time span.
Step 3:
After some more excessive testing we roll out 1.5 which begins at block 25001 (so basically after 17,5 days approx.) and goes on forever ;-)
I think this would give us some real field testing and not just on the test net, and give us five chances to fix any future bugs.
What do you think about this? Do you have any suggestions?
Of course, we have to make the GPU miner happen first, and rethink the missing parts about the ElasticPL language.
Great plan EK,but as above guys says,during step 2 times,there are none exchanges will list a 'keep test forking' xel coin,isnot it? That will be a big price hurting for xel,pls thinking more.
How about launch a 'stable alpha' mainet for instead?
December 12, 2016, 07:01:58 AM
I think the new progamming language is working, better than ever (math and crypto functions yet to come)!
Now testing testing testing ;-)
Get it Running:
Example Elastic PL Program (in file "prog.pl"):
Example Output:
Running:
assign: variable=m[2], float=false, index=2, opr=[=], operand = 3, raw text = m[2]=3
assign: variable=m[1], float=false, index=1, opr=[=], operand = 4, raw text = m[1]=++m[2]
assign: variable=m[1], float=false, index=1, opr=[=], operand = 4, raw text = m[1]=m[2]++
assign: variable=m[1], float=false, index=1, opr=[=], operand = 20.0, raw text = m[1]=(4*m[2])
assign: variable=m[1], float=false, index=1, opr=[=], operand = 6.0, raw text = m[1]=1*(1+(m[1]>>2))
assign: variable=m[1], float=false, index=1, opr=[=], operand = 0, raw text = m[1]=0
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1, raw text = m[1]=1
assign: variable=m[1], float=false, index=1, opr=[=], operand = 22, raw text = m[1]=(m[1]<1)?2:22
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1000, raw text = m[1]=1000
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1001.0, raw text = m[1]=m[1]+1
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1002.0, raw text = m[1]=m[1]+1
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1003.0, raw text = m[1]=m[1]+1
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1004.0, raw text = m[1]=m[1]+1
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99.1234, raw text = m[2]=99.1234
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99, raw text = m[2]=m[2]
assign: variable=f[2], float=true, index=2, opr=[=], operand = 99.1234, raw text = f[2]=99.1234
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99.1234, raw text = m[2]=99.1234
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99, raw text = m[2]=m[2]
assign: variable=f[2], float=true, index=2, opr=[=], operand = 99.1234, raw text = f[2]=99.1234
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99.1234, raw text = m[2]=99.1234
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99, raw text = m[2]=m[2]
assign: variable=f[2], float=true, index=2, opr=[=], operand = 99.1234, raw text = f[2]=99.1234
assign: variable=m[1], float=false, index=1, opr=[=], operand = 4, raw text = m[1]=4&5
assign: variable=m[1], float=false, index=1, opr=[=], operand = 5, raw text = m[1]=4|0x00001
assign: variable=m[1], float=false, index=1, opr=[=], operand = true, raw text = m[1]=(2<5)
assign: variable=m[1], float=false, index=1, opr=[=], operand = 2, raw text = m[1]=++m[1]
assign: variable=f[1], float=true, index=1, opr=[=], operand = 1.1, raw text = f[1]=1.1
assign: variable=f[1], float=true, index=1, opr=[=], operand = 3, raw text = f[1]=f[1]|2
assign: variable=m[9], float=false, index=9, opr=[=], operand = 22, raw text = m[9]=(((((22)))))
Debug Dump State:
m[1]: 2
m[2]: 99
m[9]: 22
f[1]: 3.0
f[2]: 99.1234
Verified Bounty: true
Now testing testing testing ;-)
Get it Running:
Code:
git clone https://github.com/OrdinaryDude/elastic-grammar.git
cd elastic-grammar
mvn compile
mvn exec:java
Example Elastic PL Program (in file "prog.pl"):
Code:
// Elastic PL Test Class
m[2]=3;
m[1] = ++m[2];
m[1] = m[2]++;
m[1] = (4*m[2]);
m[1] = 1*(1+(m[1]>>2));
if(m[1]==6){
m[1]=0;
}else{
m[1]=1;
}
if(m[1]==7){
m[1]=0;
}else{
m[1]=1;
}
m[1]=(m[1]<1)?2:22;
if(m[1]==22 || m[1]==99){
m[1]=1000;
}
if(m[1]==22 && m[1]==99){
m[1]=1001;
}
repeat(3){
// stupid loop
m[1]=m[1]+1;
break ; // should exit right away
m[2]=99;
}
repeat(3){
// stupid loop
m[1]=m[1]+1;
if((1+1-1)==1){
continue; // should run the above line 3 times
}
m[2]=99;
}
repeat(3){
// stupid loop
if((1+1-1)==8988){
continue; // should never be executed and just fall through to second line below this one
}
m[2]=99.1234;
m[2]=m[2];
f[2]=99.1234;
if((1+1-1)!=8988){
continue; // should exit here
}
f[2]=f[2]+1; // never called
}
m[1]=4&5;
m[1]=4|0x00001;
m[1]=(2<5);
m[1]=++m[1];
f[1]=1.1;
f[1]=f[1]|2; // will be 3 due to float/int cast
if(!(2>1)){
m[9]=2;
}
if(!(!(2>1))){
m[9]=(((((22)))));
}
verify(m[9]==22);
Example Output:
Running:
assign: variable=m[2], float=false, index=2, opr=[=], operand = 3, raw text = m[2]=3
assign: variable=m[1], float=false, index=1, opr=[=], operand = 4, raw text = m[1]=++m[2]
assign: variable=m[1], float=false, index=1, opr=[=], operand = 4, raw text = m[1]=m[2]++
assign: variable=m[1], float=false, index=1, opr=[=], operand = 20.0, raw text = m[1]=(4*m[2])
assign: variable=m[1], float=false, index=1, opr=[=], operand = 6.0, raw text = m[1]=1*(1+(m[1]>>2))
assign: variable=m[1], float=false, index=1, opr=[=], operand = 0, raw text = m[1]=0
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1, raw text = m[1]=1
assign: variable=m[1], float=false, index=1, opr=[=], operand = 22, raw text = m[1]=(m[1]<1)?2:22
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1000, raw text = m[1]=1000
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1001.0, raw text = m[1]=m[1]+1
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1002.0, raw text = m[1]=m[1]+1
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1003.0, raw text = m[1]=m[1]+1
assign: variable=m[1], float=false, index=1, opr=[=], operand = 1004.0, raw text = m[1]=m[1]+1
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99.1234, raw text = m[2]=99.1234
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99, raw text = m[2]=m[2]
assign: variable=f[2], float=true, index=2, opr=[=], operand = 99.1234, raw text = f[2]=99.1234
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99.1234, raw text = m[2]=99.1234
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99, raw text = m[2]=m[2]
assign: variable=f[2], float=true, index=2, opr=[=], operand = 99.1234, raw text = f[2]=99.1234
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99.1234, raw text = m[2]=99.1234
assign: variable=m[2], float=false, index=2, opr=[=], operand = 99, raw text = m[2]=m[2]
assign: variable=f[2], float=true, index=2, opr=[=], operand = 99.1234, raw text = f[2]=99.1234
assign: variable=m[1], float=false, index=1, opr=[=], operand = 4, raw text = m[1]=4&5
assign: variable=m[1], float=false, index=1, opr=[=], operand = 5, raw text = m[1]=4|0x00001
assign: variable=m[1], float=false, index=1, opr=[=], operand = true, raw text = m[1]=(2<5)
assign: variable=m[1], float=false, index=1, opr=[=], operand = 2, raw text = m[1]=++m[1]
assign: variable=f[1], float=true, index=1, opr=[=], operand = 1.1, raw text = f[1]=1.1
assign: variable=f[1], float=true, index=1, opr=[=], operand = 3, raw text = f[1]=f[1]|2
assign: variable=m[9], float=false, index=9, opr=[=], operand = 22, raw text = m[9]=(((((22)))))
Debug Dump State:
m[1]: 2
m[2]: 99
m[9]: 22
f[1]: 3.0
f[2]: 99.1234
Verified Bounty: true
December 12, 2016, 03:14:16 AM
But you do not need to as I am soon going to start the learning process of working with Elastic development as soon as it stabilizes to what it's going to be permanently.
December 12, 2016, 03:10:50 AM
Maybe implementing trading before project is fully developed would be a good thing and maybe producing markets running on the completed project itself should be considered. Lets see there is margin trading futures market and p2p collateralize'd lending among endless new options. EK after wrapping the minimal viable project up you could quickly implement this oh and online wallet running itself
December 12, 2016, 02:57:51 AM
nice to see some progress!
hopefully project can release before the end of this year.
I hope we could hear from Lannister , hope he's well. The entire workload is on EK . Not an easy job !hopefully project can release before the end of this year.
I think Lannister would probably not be able to reduce EK's workload by himsef as he's not developer.
He could eventually attract more people with his BTC, but I'm pretty sure he's gone for good, and we won't hear from him anymore.
Jump to: