Author Topic: How to learn the bitshares_toolkit framework quickly for a newbie?  (Read 8249 times)

0 Members and 1 Guest are viewing this topic.

Offline Count of La Mancha

  • Newbie
  • *
  • Posts: 15
    • View Profile
Obviously,FC is the fundamental library of bitshare toolkit.  i would like to have an in-depth study, but do not know how/where to start, is there any documentation i can refer to? attached below are some of my questions, appreciated if anyone help to clarify.

1) there is some following code under the data object,what is the purpose? how it work?and when such code will be executed?
Code: [Select]
FC_REFLECT(..)
2)there are many multiple thread program like below in bitshare toolkit, i  don't quit understand how it work.

Code: [Select]
my->....complete = fc::async( [=](){ my->process..(); } );
3)Serialization is also frequently used in the toolkit,what data format are the following functions convert to? and where are the data saved after the serialization?any difference of the data format between the following serialization functions

Code: [Select]
fc::raw::pack( ...); 

pub.serialize();

I am reviewing the code for the community and can shed some light on these questions based upon my observations.

Obviously,FC is the fundamental library of bitshare toolkit.  i would like to have an in-depth study, but do not know how/where to start, is there any documentation i can refer to? attached below are some of my questions, appreciated if anyone help to clarify.
1) there is some following code under the data object,what is the purpose? how it work?and when such code will be executed?
Code: [Select]
FC_REFLECT(..)

FC_REFLECT is a macro that expands into a template specialization that calls a method for each member.  It seems to enable the creation of different kinds of serialization techniques.   The two primary uses seems to be for what he calls 'raw' and 'json'.   raw appears to be just a binary representation and json is self explanatory.

Quote
2)there are many multiple thread program like below in bitshare toolkit, i  don't quit understand how it work.

Code: [Select]
my->....complete = fc::async( [=](){ my->process..(); } );

This code is actually cooperative multi-tasking and the fc library provides a scheduler that will manage the execution of multiple fibers in a single thread.  This is a very useful construct because you do not have to worry about context switching at arbitrary points like you do with multi-threading.   On the other hand if a fiber blocks without yielding the other tasks in the same thread will not get executed.     fc::async() dispatches a task to be run on the current thread the next time it yields.


Offline vikram


Offline crazybit

Obviously,FC is the fundamental library of bitshare toolkit.  i would like to have an in-depth study, but do not know how/where to start, is there any documentation i can refer to? attached below are some of my questions, appreciated if anyone help to clarify.

1) there is some following code under the data object,what is the purpose? how it work?and when such code will be executed?
Code: [Select]
FC_REFLECT(..)
2)there are many multiple thread program like below in bitshare toolkit, i  don't quit understand how it work.

Code: [Select]
my->....complete = fc::async( [=](){ my->process..(); } );
3)Serialization is also frequently used in the toolkit,what data format are the following functions convert to? and where are the data saved after the serialization?any difference of the data format between the following serialization functions

Code: [Select]
fc::raw::pack( ...); 

pub.serialize();
« Last Edit: May 10, 2014, 03:56:06 am by CrazyBit »

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
You *could* but that would be ignoring the philosophy we endorsed after the discussion about the role of TLDs we had in the DNS section. Even if there are multiple TLDs with the same rules vikram's question still has merit because we specifically want to have other blockchains with other rulesets.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline bytemaster

But all non .p2p blockchains will have different rulesets (at least the ones we make)

Sent from my SCH-I535 using Tapatalk

Not true.   You could have many different namespaces each with the same rules.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
But all non .p2p blockchains will have different rulesets (at least the ones we make)

Sent from my SCH-I535 using Tapatalk

Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline bytemaster

How do you envision the codebase being organized to enable easily developing and maintaining multiple DACs per family? Specifically, I am considering whether it is feasible and desirable to separate BTS/DNS/P2P specific code into a BTS::DNS::P2P namespace which overrides the relevant stubs in BTS::DNS (additional DNS family members would then follow the same pattern).

The difference between P2P and .dac etc should be config-file based and not code based. 

The only time I would derive from DNS is if I was going to change the rules from the base DNS system.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline vikram

How do you envision the codebase being organized to enable easily developing and maintaining multiple DACs per family? Specifically, I am considering whether it is feasible and desirable to separate BTS/DNS/P2P specific code into a BTS::DNS::P2P namespace which overrides the relevant stubs in BTS::DNS (additional DNS family members would then follow the same pattern).

Offline bytemaster

Serialized to json and binary, works with exception and logging infrastructure.

Eventually scripting language hooks etc. 


Sent from my iPhone using Tapatalk
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline vikram

What do the FC_REFLECT* macros enable you to do in the rest of the fc library?

Offline bytemaster

Asset is an amount plus unit. 

Precision problems have been resolved by changing verification algo.


Sent from my iPhone using Tapatalk
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster

It accelerates compile times as well because it removes need to include headers in your headers that is only required for private data. 


Sent from my iPhone using Tapatalk
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster


The concept you mention that's used with wallet, is often referred to as the PIMPL pattern (private implementation). 

I first came to appreciate the power of the paradigm when first stumbled on to QT3, and to this day I still point to the QT code base as how to do it right.

Essentially, it allows you to define a class interface that can remain constant while the implementation can be changed without affecting either the binary or the logical interface (dependencies, etc).    Its a beautiful way to encapsulate dependencies and simplify the use of a class library.  And unlike the notion of "private" in a class definition, what you do in the implementation class can be considered truly private.

QT uses this to great effect such that each shared library that implements a class interface, never changes for the life span of a major version release, while the internals, the implementation details can be updated without requiring the users of the libraries to have to recompile and relink.

Even when not building a binary library, I still use this paradigm to provide true isolation between my implementation and the users of a class library.

So nice to see another developer that gets it!!!


Sent from my iPhone using Tapatalk
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline John-S

  • Newbie
  • *
  • Posts: 12
    • View Profile
The concept you mention that's used with wallet, is often referred to as the PIMPL pattern (private implementation). 

I first came to appreciate the power of the paradigm when first stumbled on to QT3, and to this day I still point to the QT code base as how to do it right.

Essentially, it allows you to define a class interface that can remain constant while the implementation can be changed without affecting either the binary or the logical interface (dependencies, etc).    Its a beautiful way to encapsulate dependencies and simplify the use of a class library.  And unlike the notion of "private" in a class definition, what you do in the implementation class can be considered truly private.

QT uses this to great effect such that each shared library that implements a class interface, never changes for the life span of a major version release, while the internals, the implementation details can be updated without requiring the users of the libraries to have to recompile and relink.

Even when not building a binary library, I still use this paradigm to provide true isolation between my implementation and the users of a class library.

Offline vikram

I'm a noob myself, but have learned a lot in the past couple of days.  Message me with your specific questions and I'll see what I can't do to help bootstrap you along.

- John "S"

Post questions here and I can double check understanding and future devs can see the questions/answers as well.

  • What is the purpose of separating some of the class functionality into the *_impl inner classes (e.g. bts::wallet::detail::wallet_impl)?
  • What exactly does the asset class now represent? Won't we run into precision issues now that it is 64 bits again (rather than 128)?