Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - wackou

Pages: 1 ... 10 11 12 13 14 15 16 [17] 18 19 20 21 22 23 24 ... 33
241
Stakeholder Proposals / Re: Tutorial about running a delegate
« on: February 02, 2015, 07:50:10 pm »
Quote from: Thom on February 02, 2015, 07:27:47 pm
In my case the .bashrc file is simple, small and clean so that is unlikely the issue.

maybe that was the issue, debian provides you with a default .bashrc that contains this towards the end.

Code: [Select]
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi

If you overwrote it with yours and it doesn't have this, then yes, you need to call the virtualenvwrapper yourself there

Quote from: Thom on February 02, 2015, 07:27:47 pm
Probably not the correct way to resolve whatever the actual problem is but it works and I have no time to dig into it anymore.

If it works, it works :)

Quote from: Thom on February 02, 2015, 07:27:47 pm
However it is still necessary to use the -p parameter to get the correct python version:

Code: [Select]
mkvirtualenv -p`which python3` bts_tools

This is the correct way to do it, it has been like that in the tutorial from the beginning if I recall correctly (not in the install section of the reference doc, though)

Sorry for all the mess with python and the virtualenv, I realize now it's maybe not that easy to setup correctly if you don't know how to, but be glad because a working virtualenvwrapper will save you many headaches in the future, I can guarantee that. Don't hesitate to pm me if you have any more problems.

242
Stakeholder Proposals / Re: Tutorial about running a delegate
« on: February 02, 2015, 06:32:46 pm »
Quote from: Thom on February 02, 2015, 05:24:49 pm
The last thing I did before going to bed last night was kick off a build which failed. I think I have the tools & virtualenv installed and working correctly now, but obviously I need to track down the failure.

what is the error you get? Probably it should be something easy to fix now that you've made it this far...

(will reply to your other comments in a while, no time right now)

243
Stakeholder Proposals / Re: Delegate btstools.digitalgaia: proposal and updates
« on: February 02, 2015, 03:19:03 pm »
Last week's time was spent mainly on writing more documentation, both reference documentation for the tools and making the tutorial clearer. This can be found here:

http://bts-tools.readthedocs.org
(announcement for the tutorial is at: https://bitsharestalk.org/index.php?topic=13627)

I also fixed running the GUI client in linux (bts run_gui). This week I will continue to polish the documentation, as it starts looking nice but has still a few rough edges.

244
Stakeholder Proposals / Re: Tutorial about running a delegate
« on: February 02, 2015, 03:09:12 pm »
Quote from: Thom on February 01, 2015, 04:37:18 pm
Looking forward to enhancements that provide for more robust remote management and monitoring using ssh and secure email notification.

Not sure what you mean by secure email notification... The tools can already send an email to you using a provider you configured, using TLS. Did you have something else in mind?

245
Stakeholder Proposals / Re: Tutorial about running a delegate
« on: February 02, 2015, 03:07:25 pm »
Quote from: Thom on February 01, 2015, 09:28:53 pm
I'm having trouble due to the mixture of python 2.7 & python 3. Your instructions need to take this into account. For example, the mkvirtualenv cmd is not in the path, and pip will reference the default version for python 2.7 not python 3.

I had to add python3-pip to the long list of packages you cite as dependencies. Also, to use the virtualenvwrapper script it must be sourced, such as in the ~/.bashrc profile. The location of the wrapper script can be found with something like:

Code: [Select]
pushd /; find . | grep virtualenvwrapper.sh; popd

Then add that path to the end of the ~/.bashrc file or your favorite shell:

Code: [Select]
source <path to virtualenvwrapper.sh>

Even still that may not produce the correct results, but I finally found a definitive solution for using the virtualenvwrapper so that it utilizes the correct python interpreter. You must use the -p parameter to mkvirtualenv to be certain the target virtual environment is using python3, otherwise it's going to be the system default which is probably python2.x.

All this should be unnecessary, once you install the virtualenvwrapper package, (apt-get install virtualenvwrapper), next time you open a shell (but you need to open a new one, you probably stayed in the same one and that's why you had to do everything manually) you will have virtualenvwrapper functions in your shell, no need to activate anything manually (this is done through the /etc/bash_completion.d/virtualenvwrapper file)

Quote from: Thom on February 01, 2015, 09:28:53 pm
You might consider adding a version arg to your bts tool which will make it easy for users to report the version people may have issues with.
definitely needed, will do (https://github.com/wackou/bts_tools/issues/19)

246
Stakeholder Proposals / Re: Tutorial about running a delegate
« on: February 02, 2015, 02:51:32 pm »
Thanks Thom for your comments. I have already integrated some of those comments, still need to make the python3 issue clearer.

Updated doc can be found at: http://bts-tools.readthedocs.org/

There are 2 main parts written now: reference doc and the tutorial. Reference doc should be more complete, while the tutorial is more step-by-step. For instance, ref doc doesn't mention (yet) the use of virtualenv, as it is not absolutely required for the tools, but the tutorial still shows how to do it. I will keep updating both until there is very little room for confusion left.

247
Stakeholder Proposals / Re: Tutorial about running a delegate
« on: February 01, 2015, 09:01:27 am »
Quote from: Thom on February 01, 2015, 01:03:52 am
It's been a few years since I've installed a Debian distro. It only required 1 DVD before, but it's up to 3 now! It took almost 14 hours to download the ISOs with BitTorrent.

Actually, the recommended way to install Debian is not to download the DVDs (which contain all the packages in their repos), but the single CD (if you have a slow connection and want to install it multiple times) or the Netinst (highly recommended) which contain only the base system, and then from there you complete the installation by downloading updated packages directly.

See here to get the netinst ISO (and others): https://www.debian.org/devel/debian-installer/

Quote from: Thom on February 01, 2015, 01:03:52 am
I began to follow your tut to upgrade Wheezy to Jessie and found out your repository link doesn't work. The link you provided to mirrors.gandi.net resolves to 215.70.184.233 but apt can't connect to it(I can ping that address just fine).

Oops sorry, yeah that was a copy-paste oversight (because I'm on gandi, those mirrors are blazing fast, but not available outside), you should definitely use the official debian repos. Actually, if you install directly from the Jessie installer, you don't have to do anything with our apt sources, they already point to the correct ones. I did the Wheezy -> Jessie upgrade way as Gandi doesn't offer Jessie images yet, but installing from the Jessie installer is the better solution.

Quote from: Thom on February 01, 2015, 01:03:52 am
I'm curious why you decided to go with Jessie rather than Wheezy.

I did it mainly for 2 reasons:
 - Jessie is already frozen (ie: they only accept bugfixes until the final release, no new packages or updates), so it's very similar to what will be the stable release (from experience, only minor packages are still waiting for bug fixes, and I never had a problem with a RC in Debian in 10 years)
 - In Wheezy, gcc, cmake and boost are all outdated versions that cannot be used to compile the BitShares client. So you would have to update those anyway by taking them from testing, which ends up making your distro look more like Jessie than Wheezy anyway.
So Jessie it is :)

Thanks for all the proofreading ;)

248
General Discussion / Re: Please Consider Voting for fuzzy.beyondbitcoin
« on: January 31, 2015, 08:43:33 am »
After upgrading your client, you also need to remember to publish the new version on the blockchain, you can do that with:

Code: [Select]
>> wallet_publish_version fuzzy.beyondbitcoin

Given that this is something that I have forgotten to do so many times, the bts_tools now have an option to do this automatically for you when they detect that the client has been upgraded. I will try to have this clearly explained in the docs in a couple of days, but I don't have a link readily available yet. There's a small section in the tutorial that quickly goes over it, though: http://bts-tools.readthedocs.org/en/latest/howto_monitor.html

249
Stakeholder Proposals / Re: Tutorial about running a delegate
« on: January 30, 2015, 10:24:07 am »
Quote from: Thom on January 30, 2015, 12:30:19 am
I can't quite see the full picture about the virtualenv however. I understand the sandbox concept, but unless I'm mistaken doesn't the client need to run within the virtualenv context (i.e. directory created by the virtualenv cmd), or is it only a sandbox for python includes/libs/imports?

it is only for the python libs/imports, nothing else is changed (basically what it does it to set the $PYTHONPATH environment variable so that libs in the virtualenv are imported first). This has absolutely no effect whatsoever on running the BitShares client, or anything that doesn't use python.


Quote from: Thom on January 30, 2015, 12:30:19 am
When you create the virtualenv & source it, does that extend the sandbox outside of the virtualenv folder?

Yes, the sandbox is either active or inactive, regardless of which directory you are in. That's also one reason I like virtualenvwrapper a lot, is that it "hides" the location of the virtualenv directory, and the only thing you ever have to think of is to activate it ("workon myvirtualenv") or deactivate it ("deactivate"), and you can call this from any folder you are in. Makes it so much simpler to interiorize

Quote from: Thom on January 30, 2015, 12:30:19 am
Also, been trying to find info on "seed nodes"; what are they? What is their function? There's no info in the wiki.bitshares.org about them.

seed nodes are just normal nodes, but they have an IP address that is publicly known, and are used by people connecting to the network when they launch the client: they need an entry point to the network, and that is the function provided by seed nodes. This places a few desired properties on them: high uptime, lots of connections, etc. To sum up, they are like full nodes in bitcoin + public IP.

250
General Discussion / Re: Robot avatars changed, why is that?
« on: January 29, 2015, 08:58:11 pm »
Quote from: gamey on January 29, 2015, 08:53:32 pm
Quote from: wackou on January 29, 2015, 08:50:42 pm
Quote from: kokojie on January 29, 2015, 08:35:47 pm
What's the point of robot avatar anyway, the account name is already unique enough. Also this avatar apparently haven't stopped people from sending money to scam accounts such as "bter". I think it makes the client look childish and amateur tbh. It doesn't fit the overall theme of the client as a serious professional exchange.

This gave me an idea: it would be nice if the accounts could publish their own avatars on the blockchain, as part of the public info for the account (using wallet_account_update_registration). The client could then show this instead of the robohash. This wouldn't prevent scams, but at least it would allow people to choose their own avatar.

Then you have porn and questionable images.

And you have just helped people with scamming since they can just duplicate the images of others.

Then what we probably need to solve this is a reputation system as what was envisioned by Keyhotee originally :)

251
General Discussion / Re: Robot avatars changed, why is that?
« on: January 29, 2015, 08:50:42 pm »
Quote from: kokojie on January 29, 2015, 08:35:47 pm
What's the point of robot avatar anyway, the account name is already unique enough. Also this avatar apparently haven't stopped people from sending money to scam accounts such as "bter". I think it makes the client look childish and amateur tbh. It doesn't fit the overall theme of the client as a serious professional exchange.

This gave me an idea: it would be nice if the accounts could publish their own avatars on the blockchain, as part of the public info for the account (using wallet_account_update_registration). The client could then show this instead of the robohash. This wouldn't prevent scams, but at least it would allow people to choose their own avatar.

252
General Discussion / Re: Wackou, the 30% Delegate.
« on: January 29, 2015, 08:27:11 pm »
Thanks for the vote of confidence, Fuzz!

There is also this thread: https://bitsharestalk.org/index.php?topic=12534
that people can follow, where I post my weekly/bi-weekly updates (depending on progress made)

Another idea that occurred to me that I'd like to implement, if there's a demand for it, is to add a "smart" caching functionality to the bts_proxy RPC server (https://bitsharestalk.org/index.php?topic=13143)

As the blockchain grows bigger, there are some queries to the BitShares client that start taking a non-negligible amount of time, and some of those expensive queries could effectively be cached as the result they return does not change very often. For instance, the blocks produced by a delegate only change when the delegate effectively produces a block, which happens at determined time, roughly every 15 mins. Using the caching server, you'd pay for the call only once every 15 mins, and all other calls would basically be free.

I believe this could potentially be useful to sites like bitsharesblocks.com, or even the GUI client, if properly implemented.

253
Stakeholder Proposals / Re: Tutorial about running a delegate
« on: January 29, 2015, 08:01:05 pm »
btw, I plan to integrate some of the comments I already received on the tutorial, hopefully over this weekend. This will fix some missing parts in the docs and rough edges about the installation. Stay tuned!

254
Stakeholder Proposals / Re: Tutorial about running a delegate
« on: January 29, 2015, 07:58:14 pm »
Quote from: ripplexiaoshan on January 28, 2015, 07:53:08 pm
So are you going to compete with him? :P

I consider that I have a profile very similar to Riverhead, that's true, but I wouldn't call it competition :)

As far as I can tell, Riverhead is more active on the forums, and I spend most of my time developing the bts_tools instead, but we have the same mission: ensuring that the network is as robust as possible. In any case, I think that in the first stages of development of a project, it is better to let creative initiatives grow organically and freely, and then take the better ideas between them and merge them into something useful and stable.

You could compare this to writing code as fast as possible to make it work first, and only then refactor it to make it clean. I like this way better because when you refactor and do a proper design, you already have the experience of making it work, which avoids overlooking some aspects that you could have missed had you started thinking about the problem beforehand.

I do foresee a future where Riverhead and myself, but also Xeroc, Emski, etc get together to shape some common tools / docs / etc. which represent the consensus about what is the absolute best way to manage the network infrastructure (ie: delegate nodes, seed nodes, backup solutions, DDoS prevention, etc). For instance, I can see a not so distant future where we take Xeroc's, Alt's and my python code to create a standard python BitShares wrapper API too (like this: https://bitsharestalk.org/index.php?topic=13685, but more complete)
However, before reaching a consensus, I believe we first need to come up with ideas and code as freely as possible. Friendly competition, if you will ;)

255
DevShares / Re: DevShares 0.6.2 Feedback
« on: January 29, 2015, 03:26:32 pm »
well, shouldn't a 0.6.2 with a checkpoints.json file go on the "main" chain anyway with all the init delegates? unless the fork was caused by a block that is now considered invalid by 0.6.2 but not by 0.6.1-89, I guess...

Pages: 1 ... 10 11 12 13 14 15 16 [17] 18 19 20 21 22 23 24 ... 33

Page created in 0.027 seconds with 23 queries.