Sequentia is a Bitcoin sidechain dedicated to asset tokenization - like stablecoins and stock tokens - and DEX transactions, including direct atomic swaps and lightning swaps between BTC and any token issued on the Sequentia sidechain.

Sequentia

sequentia

This article discusses the scaling limitations for the widely used smart contract platforms Ethereum, Cardano and EOS. We compare the processing of smart contracts at layer one to RChain’s powerful concurrent computation model and describe how RChain achieves scalability. A smart contract platform is a virtual machine whose state evolves as transactions are executed over time. A platform is decentralized, with each computer within a network maintaining a replica of the virtual machine (VM). A decentralized network, running multiple VM copies, provides the necessary security in the event one or more program instances fail or become malicious. Ethereum was the first smart contract platform followed by Cardano and EOS. Each new platform promised to outperform the one before. Ethereum uses Solidity language for smart contracts, while Cardano uses Haskell and EOS, C++. Unfortunately, they all work similarly, following the same paradigm. Ethereum, EOS and Cardano will or already encounter problems, due to the limited work a single processor can perform and to the fact that many nodes have to reach consensus rapidly every x seconds. The maximum number of transactions that can be executed in one second is around 20 in the case of Ethereum. One might think that upgrading the computers to ultra-fast 128 cores processor machines would resolve the first cause of limited transactions throughput, . it does not Limitations of Traditional Programming Languages Smart contracts are just code. Solidity and C++ are object oriented programming languages while Haskell is a functional programming language. The disadvantage of using Solidity, C++ or Haskell for smart contract platforms is easy to understand. There is no way to know if two transactions interact with the same resources, the node cannot know if A then B (sequential execution), B then A (sequential execution), or A and B (concurrent execution) will end up changing the virtual machine state the same way. Before you execute them, transactions are essentially black boxes. For EOS, ethereum and cardano, the ordering of transactions inside a block is therefore part of the protocol. In order to be sure to reach the same state after execution, all nodes have to run transactions in the same order, one after another. Strict ordering and sequential execution of transactions is the main reason for slow transactional throughput speeds. Smart contract platforms right now cannot scale as the hardware scales. Rholang to the Rescue RChain is the only smart contract platform that allows for safe concurrent execution of transactions at layer one. It does so by relying on a new programming language called which follows pi-calculus principles developed by Robin Milner, Joachim Parrow and David Walker in the 90's. rholang RChain nodes that receive smart contracts in the form of rholang terms (code) are able to determine that transactions A, B, C and D are independent, do not interact with the same resources and can therefore be dispatched into multiple processing units (e.g. executed concurrently). statically Ethereum, Cardano and EOS platforms have no choice but to limit transaction flow. They are dependent on centralized and adventurous layer two solutions for scaling. RChain, however, achieves vertical scalability. As nodes add computer core processors they gain additional compute power to process transactions faster. Thanks to its unique approach and concurrency model, RChain platform should outperform Ethereum by one or more orders of magnitude, even with keeping the same level of decentralization. Dappy is building its whole ecosystem on RChain platform, this article was writtent by myself as the guy building dappy, and as a member of the RChain coop. If you would like to learn more about RChain please visit the website and join the pub-RChain Discord community. rchain.coop https://rchain.coop

RChain concurrency model compared to Ethereum, Cardano and EOS sequential model

You probably have heard of the idea of out-of-order execution, and that it breaks some common-sense assumptions about writing programs, and software has to insert barriers to make things right. That was a baffling concept to me at least when I heard of it. At the very least, What's the point? why would the hardware want to execute out of order only to have the software correct the behavior back? Is the software taking care of all the quirks for me?  And if not, where's the catch? Well,  all this conundrum comes from the evolution of processor design to create parallelism and the software efforts to harness the power while reining in the unwanted impact. Let's start with a tiny bit of history. Sequential consistency on uniprocessor Going back to the good old days when your CPU was just single-issue (meaning executing one instruction at a time), and there's no multi-threading programming to speak of, the programming model is straight forward -- there's memory and a stream of instructions executing in program order, doing reading/writing to the memory. For as long as the program lives, memory will reliably hold results written to it, and  reproduce the same values when read afterwards. That is, a read after a write to the same memory location will faithfully return the value written. A write after a write to the same memory location will overwrite the old value with the new. To illustrate, look at this simplistic : example1 { i = ; :: << i << ; j = ; :: << i << ; :: << j << ; i = ; :: << i << ; :: << j << ; ; } 1 # include <iostream> 2 3 int main () 4 int 1 5 std cout ' ' 6 int 5 7 std cout ' ' 8 std cout ' ' 9 2 10 std cout ' ' 11 std cout '\n' 12 return 0 13 Easy to predict, the result will be . At first variable assumes the value . Up until , where the value's updated, no matter how many times it's read the location will always return the same value. Right after 2 is written to it, reading that variable will invariably return . 1 1 5 2 5 i 1 line 9 2 There's also the variable . Since it's a different location, what value is written to it doesn't concern the output of whatsoever. j i Now let's look at a 2-threaded example to add a bit of nondeterminism. Keep in mind we're still executing on a single CPU. Imagine we have two functions and executed by two separate threads, in the following : func0 func1 example2 i = ; j = ; output[ ]; {
  i = ;
  output[ ] = j;
} {
  j = ;
  output[ ] = i;
} int 0 int 0 int 2 void func0 () 1 1 void func1 () 1 0 After the program finishes what are the valid outputs? There are roughly four instructions here. Two reads and two writes. Depending on how they are mixed, and are both likely -- if one function happens to execute before another then these will ensue. is possible too, so long as the reads are both performed after the writes are done. 01 10 11 You probably have noticed is not possible. No matter how you execute, the first instruction will be writing a to either of the output elements. 00 1 When you make this conclusion, you are of course intuitively making assumptions that the programming model is . To summarize, this means that even though the instructions from different threads may be interleaved in a nondeterministic way, each thread's execution is in program order. Also the operations are not overlapped. One memory access is done before another begins. sequential consistency Over the years, processor design has improved drastically, and computer architects play all kinds of tricks to extract parallelism from executions. For example, here in our example you may notice that in , the two operations can be performed in parallel, so long as they both execute before . Given a possible instruction sequence, we'll be free to reorder the instructions to maintain the impression that the program still runs with sequential consistency, as long as we maintain the order of memory operations to the same variable! func0 func1 Computer architects actually went ahead and took advantage of this to implement that can execute multiple instructions at a time. They tracked the operation dependencies using algorithms like and . In the history of processor you will see the architects playing nasty and nastier tricks, such as speculative execution, which caused a ton of now in the cloud business. superscalar processors Scoreboarding Tomasulo trouble But I have digressed here. The point is no matter how the system evolves, has been the contract between programmers and system builders. sequential consistency de facto Consistency model on multi-processors In the early to mid 2000's, the idea of SMP (symmetric multiprocessing) really caught on. The reason was that computer architects found it more and more difficult to dissipate the amount of heat generated by a single powerful processor. Using the same die area, they'd rather build multiple smaller "cores". However, like the uniprocessor days, in each core, instructions may still be executed out-of-order. The read-write dependencies are still tracked by the same algorithms so as to maintain the illusion that it's as if the program was still executed in-order. However, this dependency tracking won't be available across cores. Now looking back on our : example2 i = ; j = ; output[ ]; {
  i = ;
  output[ ] = j;
} {
  j = ;
  output[ ] = i;
} int 0 int 0 int 2 void func0 () 1 1 void func1 () 1 0 Suppose the two functions are executed on two separate processors, processor-0 will be free to think is all it's executing. So it's possible for this processor to read the and write the output first. Processor-1 is in the same boat! So under this paradigm, the output is actually possible! func0 j 00 To illustrate this, let's write a full-fledged program that can reproduce this: i; j; output[ ]; ::atomic< > ready; { (!ready.load()) {
  }

  i = ;
  output[ ] = j;
} { (!ready.load()) {
  }

  j = ;
  output[ ] = i;
} {
  i = ;
  j = ;
  ready.store( ); :: ; :: ; ::this_thread::sleep_for( ::chrono::milliseconds( ));
  ready.store( );

  t0.join();
  t1.join(); :: << output[ ] << output[ ] << :: ;
} { (;;)
    run_test();
} # include <atomic> # include <iostream> # include <thread> int int int 2 std bool void func0 () while 1 1 void func1 () while 1 0 void run_test () 0 0 false std thread t0 (func0) std thread t1 (func1) std std 5 true std cout 0 1 std endl int main () for Don't mind the boiler plates for now. The sleep in and the atomic are to make the two threads start roughly at the same time. run_test ready On my x86 processor, is not only possible, it's the dominant output (perhaps because reading is cheaper than writing with cache coherency protocols, which we will cover in later posts). In fact and combined only account for about 25% of the output. 00 01 10 For some reason is really rare, next to nonexistent, but that is just because of the timing of the execution. If you tell both threads to yield between the read and the write, then you will see most of the time. 11 11 Also, to illustrate this won't be a problem on uniprocessors, we can pin the two threads onto the same core by adding the following snippet right after you create the threads. Afterwards you will see output completely disappear. 00 cpuset;
  CPU_ZERO(&cpuset);
  CPU_SET( , &cpuset);
  pthread_setaffinity_np(t0.native_handle(), ( ), &cpuset);
  pthread_setaffinity_np(t1.native_handle(), ( ), &cpuset); cpu_set_t 0 sizeof cpu_set_t sizeof cpu_set_t How do we fix the broken consistency I don't know about you, but when I first saw this result my mind was blown. I knew some RISC processors can go aggressive on relaxing memory models, but I had always thought my old buddy x86 is a dependable fellow. X86 in fact, implements a memory model called TSO, or total store ordering. As the name suggests, the stores (writes) to all locations are globally ordered. More on the relaxed memory model later, but the tl;dr here is that you can imagine TSO places write results in a buffer called LSQ, or load-store-queue, before they go out to the cache. Each read afterwards will in turn check this queue for an early hit, before they themselves go out to the cache. The reason is that cache access takes much longer than register access, and it's valuable to keep a buffering structure on-core. But of course the consequence is that your read may bypass previous writes to different locations, as long as you can find a result in the LSQ, sometimes breaking sequential consistency. The fix is to enforce sequential consistency by removing the reordering. C++ gives you a standard way of doing this. Instead of declaring and as plain integers, we'll wrap them around a type, and the reads and writes will be through the and methods. i j std::atomic load() store() By default these methods will , even when these variables are accessed across different processors. So our new program will look like this: enforce sequential consistency ::atomic< > i; ::atomic< > j; output[ ]; ::atomic< > ready; { (!ready.load()) {
  }

  i.store( );
  output[ ] = j.load();
} { (!ready.load()) {
  }

  j.store( );
  output[ ] = i.load();
} {
  i.store( );
  j.store( );
  ready.store( ); :: ; :: ; ::this_thread::sleep_for( ::chrono::milliseconds( ));
  ready.store( );

  t0.join();
  t1.join(); :: << output[ ] << output[ ] << :: ;
} { (;;)
    run_test();
} # include <atomic> # include <iostream> # include <thread> std int std int int 2 std bool void func0 () while 1 1 void func1 () while 1 0 void run_test () 0 0 false std thread t0 (func0) std thread t1 (func1) std std 5 true std cout 0 1 std endl int main () for As promised before, we have now converted and into atomics. And voilà, the pattern is eliminated even if we're running on 2 cores, fully bringing us to the sequential consistency land! i j 00 Underlying the hood, the compiler inserts memory barriers so that the processors will coordinate to observe a global order on memory operations. Later on we'll get a chance to look at how the barriers are actually inserted at the assembly level. This enforcement is quite slow. If all variables are protected by memory barriers, it kind of defeats the purpose of having multiple cores. But for now, we see it solves the problem of correctness. Recapitulation and what's to come Here we have covered: Sequential consistency is the programming model computer systems strive to deliver. It's always been maintained on uniprocessor programming. When programming on multiple processors, at times programmers need to explicitly enforce sequential consistency on their own. There are language constructs programmers can take advantage of. In the next episode, we'll dig deeper into some of the more relaxed memory models and how they are supposed to be used to maintain the illusion of sequential consistency and at the same time produce as much parallelism between multiple cores as possible. Disclaimer : Compilation in this article is done with clang++ 10, with compiler flags "-O2 -std=c++20 -lpthread". YMMV as to the execution results.

Everything You Need to Know About Multithreading: Sequential Consistency Concept [Part 1]

Semi-Abstract This novel concept is a creative overview of existing concepts, Sequential Content and Content Intelligence have both been moderately addressed in the web literature. However, the synthesis of the two had yet to be examined until now. Intelligent Content Content Intelligence (CI) elevates business semantics, research, production, and distribution. CI employs AI and raw data to optimize content strategy and performance. CI systems tend to operate in the following sequential order : – mine for relative data trends, patterns, and relationships Data collection – identify and analyze CMS, web, and social media data Data analysis – predict future data trends and strategic impact Data Insights A four-tiered CI sequence model ensures that each step is maximally executed: Intelligent Engineering According to [ ], content engineers organize the shape, structure, and application of content…(they) define and facilitate the during the entire content strategy, production and distribution cycle from beginning to end. A content structure Content engineers bridge content strategy and development. The engineer does not view content as a static or final asset. Instead, s/he reduces content down to a recyclable . This omniversal content requires intricate architecture and extensive planning. The engineer further integrates, encrypts, and routes content toward : quantum state multiple endpoints Drive Media Mobile Engine Intelligent engineering is not designed to unnecessarily disrupt existing content pathways. In fact, it refines and expands content elements to maximize their processes over time. Intelligent Advantage Sequential Content Intelligence™ (SCI) tends to follow the (i.e. roughly 80% of results stem from 20% of content). In other words, 20% of produced content tends to yield an 80% increase in online visibility and engagement. Factors involved in this process include the application of "creative spend" toward: Pareto Law of the vital few for usable content concepts and components web research of relative digital assets preparation and presentation to enhance branding and attract visitors blog redesign to captivate visitors and provoke engagement blog post creation recommends the following Pareto content intelligence pathway: Triberr - When creating website/blog content, utilize analytics for data (e.g., create UTM or trackable backlinks). Track traffic sources to determine visitor locality. Track Data - Pinpoint activity patterns that maximize results (e.g., posting content w/certain hashtags at a particular time of day). Identify the 20% - Strategize on how to maximize platform operationality. Enhance web presence via peak hour engagement, repurposing content, and investing in digital ads. Amplify the 20% - the outcome, the process via data analysis, with different content EIR Evaluate Improve Repeat In spite of Pareto's Law, "create less, promote more" should not be the de facto approach to successful sequential content development. Instead, identifying and leveraging the 20% of SCI within the marketing stack that garners 80% of results ought to be the proper objective.

WTF is Sequential Content Intelligence™?

is a library for Node.js, a simple sequential and parallel task list runner for terminal. Taskz Getting Started Install it via . Create your task sequence in any script file then run it. npm i taskz taskz = ( );

taskz([
  { : , : () => ( setTimeout(resolve, ));
  },
  { : , : () => { ( );
    }
  }
]).run(); const require "taskz" text "first task - sleeps for 200ms" task async await new Promise => resolve 200 text "this task will fail" task async throw new Error "this task failed" So in other word, you have to create a array of tasks: myTasks = [
  { : , : { } },
  { : , : { } }
]; const text "task 1" task => () /* ... */ text "task 2" task => () /* ... */ Then pass it to the function and call to start the process: taskz run taskz(myTasks).run(); You can also run tasks in parallel: taskz(myTasks, { : }).run(); parallel true Other features: , , subtasks stop on fail , . pass context from task to task change text within a task during execution Have fun with it: link to github repository

A Simple Sequential and Parallel Task List Runner for Terminal

Disclaimer: I am not a financial advisor. Please do your own due diligence when it comes to crypto-investing . Never put in money that you cannot afford to lose . Cryptocurrency markets are extremely volatile. Invest at your own risk . “In the business world, the rearview mirror is always clearer than the windshield.” ~Warren Buffett~ I’ve figured this indicator is an easy way to indicate where to sell or buy. What is TD sequential indicator? Number indicator used to identify a price point where an uptrend or a downtrend exhausts itself and reverses. . It gives you a recommendation where to buy and where to sell What are we looking at? A series of nine candles where each close higher/lower than its 4th predecessor candle’s close value. When is there a buy recommendation? When you see 9 consecutive closes “ ” than the close 4 bars prior. lower An ideal buy is when the low of bars 6 and 7 in the count are exceeded by the low of bars 8 or 9. See the example below of a buy recommendation In the following example, we have a TD 9 Buy, Let’s see what happens next When is there a sell recommendation? When you see 9 consecutive closes “ ” than the close 4 candles prior. higher An ideal sell is when the the high of bars 6 and 7 in the count are exceeded by the high of bars 8 or 9. See the example below of a sell recommendation. Sell by TD Sequential Another Example of a sell recommendation when the low of the red 1 count is broken. it’s a short play. Number Indicator / TD Sequential indicator sell Here is the Result after the TD indicator sell recommendation. Tone Vays is very famous for using this indicator although Tone modified TD Sequential a little bit. To try this TD indicator on TradingView, copy-paste this implementation study("Number Indicator / Thomas DeMark Sequential",overlay=true)transp=input(0)Numbers=input(true)SR=input(true)Barcolor=input(true)TD = close > close[4] ?nz(TD[1])+1:0TS = close < close[4] ?nz(TS[1])+1:0 TDUp = TD - valuewhen(TD < TD[1], TD , 1 )TDDn = TS - valuewhen(TS < TS[1], TS , 1 )plotshape(Numbers?(TDUp 2?true:na):na,style=shape.triangledown,text="2",color=green,location=location.abovebar,transp=transp)plotshape(Numbers?(TDUp 4?true:na):na,style=shape.triangledown,text="4",color=green,location=location.abovebar,transp=transp)plotshape(Numbers?(TDUp 6?true:na):na,style=shape.triangledown,text="6",color=green,location=location.abovebar,transp=transp)plotshape(Numbers?(TDUp 8?true:na):na,style=shape.triangledown,text="8",color=green,location=location.abovebar,transp=transp)plotshape(Numbers?(TDUp==9?true:na):na,style=shape.triangledown,text="9",color=green,location=location.abovebar,transp=transp) 1?true:na):na,style=shape.triangledown,text="1",color=green,location=location.abovebar,transp=transp)plotshape(Numbers?(TDUp 3?true:na):na,style=shape.triangledown,text="3",color=green,location=location.abovebar,transp=transp)plotshape(Numbers?(TDUp 5?true:na):na,style=shape.triangledown,text="5",color=green,location=location.abovebar,transp=transp)plotshape(Numbers?(TDUp 7?true:na):na,style=shape.triangledown,text="7",color=green,location=location.abovebar,transp=transp)plotshape(Numbers?(TDUp plotshape(Numbers?(TDDn 2?true:na):na,style=shape.triangleup,text="2",color=red,location=location.belowbar,transp=transp)plotshape(Numbers?(TDDn 4?true:na):na,style=shape.triangleup,text="4",color=red,location=location.belowbar,transp=transp)plotshape(Numbers?(TDDn 6?true:na):na,style=shape.triangleup,text="6",color=red,location=location.belowbar,transp=transp)plotshape(Numbers?(TDDn 8?true:na):na,style=shape.triangleup,text="8",color=red,location=location.belowbar,transp=transp)plotshape(Numbers?(TDDn==9?true:na):na,style=shape.triangleup,text="9",color=red,location=location.belowbar,transp=transp) 1?true:na):na,style=shape.triangleup,text="1",color=red,location=location.belowbar,transp=transp)plotshape(Numbers?(TDDn 3?true:na):na,style=shape.triangleup,text="3",color=red,location=location.belowbar,transp=transp)plotshape(Numbers?(TDDn 5?true:na):na,style=shape.triangleup,text="5",color=red,location=location.belowbar,transp=transp)plotshape(Numbers?(TDDn 7?true:na):na,style=shape.triangleup,text="7",color=red,location=location.belowbar,transp=transp)plotshape(Numbers?(TDDn //------------//// Sell Setup ////------------//priceflip = barssince(close<close[4])sellsetup = close>close[4] and priceflipsell = sellsetup and barssince(priceflip!=9)sellovershoot = sellsetup and barssince(priceflip!=13)sellovershoot1 = sellsetup and barssince(priceflip!=14)sellovershoot2 = sellsetup and barssince(priceflip!=15)sellovershoot3 = sellsetup and barssince(priceflip!=16) //----------//// Buy setup////----------//priceflip1 = barssince(close>close[4])buysetup = close<close[4] and priceflip1buy = buysetup and barssince(priceflip1!=9)buyovershoot = barssince(priceflip1!=13) and buysetupbuyovershoot1 = barssince(priceflip1!=14) and buysetupbuyovershoot2 = barssince(priceflip1!=15) and buysetupbuyovershoot3 = barssince(priceflip1!=16) and buysetup //----------//// TD lines ////----------//TDbuyh = valuewhen(buy,high,0)TDbuyl = valuewhen(buy,low,0)TDsellh = valuewhen(sell,high,0)TDselll = valuewhen(sell,low,0) //----------////   Plots  ////----------// plot(SR?(TDbuyh ? TDbuyl: na):na,style=circles, linewidth=1, color=red)plot(SR?(TDselll ? TDsellh : na):na,style=circles, linewidth=1, color=lime)barcolor(Barcolor?(sell? #FF0000 : buy? #00FF00 : sellovershoot? #FF66A3 : sellovershoot1? #FF3385 : sellovershoot2? #FF0066 : sellovershoot3? #CC0052 : buyovershoot? #D6FF5C : buyovershoot1? #D1FF47 : buyovershoot2? #B8E62E : buyovershoot3? #8FB224 : na):na) An ideal setup tends to be a better indicator, as regular setups often are perfected at a later date. And you should understand that a setup does guarantee a reaction in the opposite direction. If the momentum is too strong in the trend direction, a reversal could very well be cancelled. not

How to Buy/Sell Cryptocurrency with TD Sequential indicator

I love the new library that ships with ES6, though one thing has been left out, a function to sequentially execute multiple promises. Promise We can use a library like , , , , etc., or we can make our own. I really only need a single function and it seemed kind of heavy to import a whole library for one function which is why I created this. Q Bluebird RSVP.js Async One trait of the Promise is that it executes immediately. This actually works against us, we’ll need the Promises to execute when we are ready for it to execute. The way I did this was to convert each Promise into a factory function. The factory function will be a simple function that will return a Promise. Now our Promises will execute when decide. we For this *cough* contrived example, I’ve decided to use jQuery’s ajax method as my promise. // some dummy urls to resolveconst urls = ['/url1', '/url2', '/url3']// convert each url to a function that returns an ajax callconst funcs = urls.map(url => () => $.ajax(url)) Solving this problem is a little complex, and I find it helps me to think ahead a little bit about what our function should output. Probably something like this: Promise.resolve().then(x => funcs[0]()) // resolve func[0].then(x => funcs[1]()) // resolve func[1].then(x => funcs[2]()) // resolve func[2] I also want the final promise to return an array that contains the results of each promise. This was the most complex part. I needed to start each promise with an empty array and then concatenate the results of each promise to that array. Stick with me, I’ll try my best to break it down. [] I’m gonna start off this Promise with an initial value of an empty array like this . Then execute each factory function using the Promise’s function. Promise.resolve([]) then For simplicity sake, this example just resolve index of func. We’ll do the rest later. 0 // start our promise off with an empty array. this becomes all.Promise.resolve([])// all is the array we will append each result to..then(all => {return funcs[0]().then(result => {// concat the resolved promise result to allreturn all.concat(result)})}) This block of code can be expressed this in a more compact way by removing all the , , and from our code. { } return Promise.resolve([]).then(all => funcs[0]().then(result => all.concat(result))) A neat trick to get rid of that arrow function is directly call like this: concat Promise.resolve([]).then(all => funcs[0]().then(Array.prototype.concat.bind(all))) And finally, this will be the output of our function: Promise.resolve([]).then(x => funcs[0]().then(Array.prototype.concat.bind(x))).then(x => funcs[1]().then(Array.prototype.concat.bind(x))).then(x => funcs[2]().then(Array.prototype.concat.bind(x))) That wasn’t so bad was it? Now that we know our input and output, let’s make! We could use a loop (but that’s not very functional), we could also use recursion, but what I really like for this problem is . for reduce Whenever you need to transform a list into a single object, consider using reduce. Our function should take an array of factory functions (that each return a Promise) and reduce them into the single Promise chain expressed above. promiseSerial Our initial value of is passed into our reduce method like this: Promise.resolve([]) const promiseSerial = funcs =>funcs.reduce((promise, func) => ???, Promise.resolve([])) The last piece is to generalize one of our Promise 's from above and update some argument names. (the new part is in bold) then const promiseSerial = funcs =>funcs.reduce((promise, func) =>promise.then(result => ,Promise.resolve([])) func().then(Array.prototype.concat.bind(result))) That’s it! A pretty simple… scratch that… short function that will resolve Promises sequentially. Lastly, let’s slap it all together. Now we have eliminated the need to install a 3rd party library with our shiny new function. promiseSerial Hey! You actually made it to the end of this article! What is your use case for resolving promises sequentially? How did you solve this? Please share your experiences. I know it’s a small thing, but it makes my day when I get those follow notifications on Medium and Twitter ( ). Or if you think I’m full of shit, tell me in the comments below. @joelnet Cheers! Related Articles _In my last article, Death of the for Loop, I tried to convince you to abandon the for loop for a more functional…_medium.com Rethinking JavaScript: Break is the GOTO of loops _JavaScript’s for loop has served us well, but it is now obsolete and should be retired in favor of newer functional…_hackernoon.com Rethinking JavaScript: Death of the For Loop _Thinking functionally has opened my mind about programming._medium.com Rethinking JavaScript: The if statement

Functional JavaScript: Resolving Promises Sequentially

Before ES5, JavaScripters were living in a Callback Hell. Debugging was a crazy console.log-ing inside thousand of callback functions. Then Promises came to rescue JavaScripters. The Magic of Promises turned that Hell into a flat structure, and it was the light at the end of the tunnel. Async Await was the incarnation of the Promise. ES7. 8 must know Examples : AsyncFunction Object Promise function Async function Await Sequentially Await Parallelly Await Nest Await Dynamically Error Handle Note e — This story only focuses on Asynchronies issue. — To Nodejs developer, to run ES7 please read: BBB, Babel Burger Boilerplat Chronological Picture 1- Constructor of async: asyncFunction The AsyncFunction constructor creates a new Async function object. In JavaScript every Async function is actually a AsyncFunction object. From : Mozilla console.log(async function () {}); Who has known that AsyncFunction and Promise siblings? If no you can are not permitted to skip, because this is the reason why await is supported by ES6's Promise functions and how the characteristic of Promise is applied by Async await, such as and : Resolving Parallel Error Handling function(){...return new (function(resolve, reject) {...})...} Promise 2- Constructing Promise function Why are we talking about Promise functions here? Because people may have missed that the foundation of Async await are promises, every Async function we create and every thing that we Await will naturally become a promise. Example (Thanks for ’s suggestion): Jyotman Sing (async function() { var sleep = function(para) {return new Promise(function(resolve, reject) {setTimeout(function() {resolve(para * para)}, 1000)})} var result = await sleep(2)// result is 4 })(); 3- Constructing Async function The declaration defines an , which returns a object (also a promise). When the async function returns a value, the promise will be resolved with the returned value. When the async function throws an exception or some value, the promise will be rejected with the thrown value ( ). **async function** async function [AsyncFunction](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncFunction "The AsyncFunction constructor creates a new async function object. In JavaScript every async function is actually a AsyncFunction object.") Mozilla Example: async function asyncSleep (para){return await sleep(para)} var result = await asyncSleep(2)//result is 4 asyncSleep(3).then(function(result2){//result2 is 9}) 4- Await Sequentially Example: var result1 = await sleep(2);var result2 = await sleep(result1);var result3 = await sleep(result2); //result1 is 4//result2 is 16//result3 is 256 5- Await Parallelly Example: var results = await Promise.all([sleep(1), sleep(2)]);//results is [1,4] 6- Nest Example: for(var i =0 ; i<3; i++){var result = await sleep(i); for(var j =0 ; j<result; j++){  
    console.log('   i:'+i+', j:'+j+': ', await sleep(j));  
} } // i:1, j:0:  0// i:2, j:0:  0// i:2, j:1:  1// i:2, j:2:  4// i:2, j:3:  9 7- Dynamic Async functions Fellow JavaScripters, it’s time to admit it: we have a problem with promises ( ). Nolan Lawson I really agree with quote_._ Dynamical Promise Array is demanded when dealing with unknown process, dynamical problem. To the issue, my instinct was to push all the Promise functions into an Array, then await each of them sequentially. But it was proved incorrect when I discovered that the Promise functions executed while they were being declared. My conclusion is, don’t trust human instinct when solving problems with Promises. Nolan Lawson ’s The walk-around is to store parameters and promises separately (map object is used here) Example: var sleep = function(para1,para2) {var _para1 = para1, _para2 = para2 || para1 ;return new Promise(function(resolve, reject) {setTimeout(function() {resolve(_para1 * _para2)}, 1000)})} var proMap = new Map();proMap.set([1], sleep);proMap.set([2, 3], sleep);proMap.set([3], sleep); for (var [para, fun] of proMap.entries()) {var result = await fun.apply(this, para);console.log(para, result)} //[ 1 ] 1//[ 2, 3 ] 6//[ 3 ] 9 8- Error handle within an function Errors are swallowed “silently” async – just like inside normal Promises ( Nicolas Bevacqua ). Error handling in both and were born from the same mother, they both needed try/catch, so that errors are captured and handled in awaited promises from within the async function. Async Promises Example: var errorSleep = function(para) {return new Promise(function(resolve, reject) {setTimeout(function() {reject(' ErrorSleep')}, 1000)})} var result1 = await sleep(1);var result2 = await errorSleep(4);var result3 = await sleep(1); _try {_ console.log('result1: ', result1)  
console.log('result2: ', result2)  
console.log('result3: ', result3) console.log('err: ', err)console.log('result1: ', result1)console.log('result2: ', result2)console.log('result3: ', result3) _} catch (err) {_ } //err:   ErrorSleep//result1:  1//result2:  undefined//result3:  undefined : Summary Good, async/await is a great syntactic improvement for both nodejs and browser programer. Comparing to Promises, it is a shortcut to reach the same destination. It helps developer to implement functional programming in JavaScript, and increases the code readability, making JavaScript more enjoyable. Bad, as mentioned in part 7 and 8, Promise has problem in generating instance dynamically and resolving the instance, also await should have given Javascripter a louder shout when an accident exception is found. Like this story? It is helpful to others? It helps me know if you’d like to see write more about his topic and helps people see the story, . when tap the heart below Reference: Source: https://medium.com/@peterchang_82818/javascript-es7-async-await-bible-tutorial-example-32294f6133ab#.m33vwg1yx Mozilla: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncFunction Nicolás Bevacqua https://ponyfoo.com/articles/understanding-javascript-async-await Nolan Lawson https://pouchdb.com/2015/05/18/we-have-a-problem-with-promises.html

Asycn Await BIBLE: Sequential, Parallel, Nest, Dynamic and Error Handle in Javascript

The pain of javascript is fighting with async functions, specially the big boss “CALLBACK HELL”, when you putting thousand console.log to make the code dirty to kill one CALLBACK bug. It lasted for long until I found Promises, which follows simple logical, organized resolve-reject structure and it solves most of the async problems, so thank you to Promises. However, a use case that chain N unknown number of promises with parameters and resolving them sequentially, it seem like impossible to accomplish by either native ES6 Promises or by third party libraries: q, bluebird, deferred.js etc. Failed example: Defining function which will be used many times in this article: genPromist var genPromist = function(para) {return new Promise(function(resolve, reject) {setTimeout(function() {console.log('para: ', para)resolve(para * para)}, 1000)})} Chain 4 promises and resolve it recursively: var promises = [];promises.push(genPromist(1));promises.push(genPromist(2));promises.push(genPromist(3)); var recursiveFunction = function(promisesList) {return new Promise(function(resolve, reject) {if (promisesList.length <= 0) {resolve()} else {return promisesList[0].then(function() {promisesList.shift();return recursiveFunction(promisesList);});}});} recursiveFunction(promises) Sadly, the program did not run as expected, and the array was resolved parallelly. And most of the libraries works well when promise function has no parameter, which means that a CLASS in javascript. promises Solution: The ways Javascript handling and are different ( issue of anonymous function with parameters ). functions of promises functions of promises with parameters So that handling this issue needed to push to an array list promise function (not a promise) PACU is a tool to solve the problem of chaining promises functions with parameters and resolving each continuously. Installation: $ npm install --save pacu Usage: var pacu require("pacu") = pacu.series(promisesList).then(function(result) { console.log("Result series: ", result) },function(err){ console.log("Error series: ", result) });

[ Javascript ] Killer of Sequential Promises

DIY Fake News Detector: Unmask misinformation with Recurrent Neural Networks

Lifelong Intelligence Beyond the Edge using Hyperdimensional Computing: Conclusion, and References

Authors:
(1) Xiaofan Yu, University of California San Diego, La Jolla, California, USA (x1yu@ucsd.edu);
(2) Anthony Thomas, University of California San Diego, La Jolla, California, USA (ahthomas@ucsd.edu);
(3) Ivannia Gomez Moreno, CETYS University, Campus Tijuana, Tijuana, Mexico (ivannia.gomez@cetys.edu.mx);
(4) Louis Gutierrez, University of California San Diego, La Jolla, California, USA (l8gutierrez@ucsd.edu);
(5) Tajana Šimunić Rosing, University of California San Diego, La Jolla, USA (tajana@ucsd.edu). Table of Links Abstract and 1. Introduction 2 Related Work 3 Background on HDC 4 Problem Definition 5 LifeDH 6 Variants of LifeHD 7 Evaluation of LifeHD 8 Evaluation of LifeHD semi and LifeHDa 9 Discussions and Future Works 10 Conclusion, Acknowledgments, and References 4 PROBLEM DEFINITION Before diving into our method, we first rigorously formulate the unsupervised lifelong learning problem using streaming sources, driven by real-world IoT applications. Streaming Data. To represent continuously changing environment, we assume a well-known class-incremental model in lifelong learning, in which new classes emerge in a sequential manner [46]. We also allow data distribution shift within one class. This setting models a scenario in which a device is continuously sampling data while the surrounding environment may change implicitly over time, e.g., the self-driving vehicle as shown in Fig. 1. We require that all samples appear only once (i.e., single-pass streams). Learning Protocol. Our goal is to build a classification algorithm that maps X → Y. For evaluation, we use the common evaluation protocol in state-of-the-art lifelong learning works [13, 14, 54], in which we construct an iid dataset E = {(𝑋𝑘 , 𝑦𝑘 )} for periodic testing, by sampling labeled examples from each class in a manner that preserves the overall (im)balance between the classes. Note, that even when one class has not appeared in the training data stream, it is always included in E. Hence E is a global view of all classes that can potentially exist in the environment. Unsupervised Clustering Accuracy. Since we do not give class labels or the total number of classes during training, the predicted label can be different from the ground-truth label. Therefore, for evaluation metric, we cannot adopt the simple prediction accuracy that requires exact label matching. Instead, we employ a widely used clustering metric known as unsupervised clustering accuracy (ACC) [63], which mirrors the conventional accuracy evaluation but within an unsupervised context. This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. Authors: (1) Xiaofan Yu, University of California San Diego, La Jolla, California, USA (x1yu@ucsd.edu); (2) Anthony Thomas, University of California San Diego, La Jolla, California, USA (ahthomas@ucsd.edu); (3) Ivannia Gomez Moreno, CETYS University, Campus Tijuana, Tijuana, Mexico (ivannia.gomez@cetys.edu.mx); (4) Louis Gutierrez, University of California San Diego, La Jolla, California, USA (l8gutierrez@ucsd.edu); (5) Tajana Šimunić Rosing, University of California San Diego, La Jolla, USA (tajana@ucsd.edu). Authors: Authors: (1) Xiaofan Yu, University of California San Diego, La Jolla, California, USA (x1yu@ucsd.edu); (2) Anthony Thomas, University of California San Diego, La Jolla, California, USA (ahthomas@ucsd.edu); (3) Ivannia Gomez Moreno, CETYS University, Campus Tijuana, Tijuana, Mexico (ivannia.gomez@cetys.edu.mx); (4) Louis Gutierrez, University of California San Diego, La Jolla, California, USA (l8gutierrez@ucsd.edu); (5) Tajana Šimunić Rosing, University of California San Diego, La Jolla, USA (tajana@ucsd.edu). Table of Links Abstract and 1. Introduction Abstract and 1. Introduction 2 Related Work 2 Related Work 3 Background on HDC 3 Background on HDC 4 Problem Definition 4 Problem Definition 5 LifeDH 5 LifeDH 6 Variants of LifeHD 6 Variants of LifeHD 7 Evaluation of LifeHD 7 Evaluation of LifeHD 8 Evaluation of LifeHD semi and LifeHDa 8 Evaluation of LifeHD semi and LifeHDa 9 Discussions and Future Works 9 Discussions and Future Works 10 Conclusion, Acknowledgments, and References 10 Conclusion, Acknowledgments, and References 4 PROBLEM DEFINITION Before diving into our method, we first rigorously formulate the unsupervised lifelong learning problem using streaming sources, driven by real-world IoT applications. Streaming Data. To represent continuously changing environment, we assume a well-known class-incremental model in lifelong learning, in which new classes emerge in a sequential manner [46]. We also allow data distribution shift within one class. This setting models a scenario in which a device is continuously sampling data while the surrounding environment may change implicitly over time, e.g., the self-driving vehicle as shown in Fig. 1. We require that all samples appear only once (i.e., single-pass streams). Streaming Data. Learning Protocol. Our goal is to build a classification algorithm that maps X → Y. For evaluation, we use the common evaluation protocol in state-of-the-art lifelong learning works [13, 14, 54], in which we construct an iid dataset E = {(𝑋𝑘 , 𝑦𝑘 )} for periodic testing, by sampling labeled examples from each class in a manner that preserves the overall (im)balance between the classes. Note, that even when one class has not appeared in the training data stream, it is always included in E. Hence E is a global view of all classes that can potentially exist in the environment. Learning Protocol. Unsupervised Clustering Accuracy. Since we do not give class labels or the total number of classes during training, the predicted label can be different from the ground-truth label. Therefore, for evaluation metric, we cannot adopt the simple prediction accuracy that requires exact label matching. Instead, we employ a widely used clustering metric known as unsupervised clustering accuracy (ACC) [63], which mirrors the conventional accuracy evaluation but within an unsupervised context. Unsupervised Clustering Accuracy. This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. available on arxiv

Stories, News & Mentions about SEQUENTIA

Sequentia’s Stories on HackerNoon