Topic: Devcoin - page 156. (Read 412998 times)

They don't say if they are for 32bit or 64 bit?

-MarkM-

if anyone needs an i686 Linux binary

http://pool.devcoin.org/files/daemons/

that devcoind is the latest: knotwork-old-devcoind-266adc4

Ok, thanks. I've upgraded my node at bitparking.com with the new code.

Yup, 25,000 is the official time. Because coding and testing went faster than I expected the switch will be at around block 25,000 instead of the 25,500 I originally said.

Everyone using the daemon must upgrade to Mark's latest devcoind release before block 25,000:
https://github.com/knotwork/old-devcoind

Block 25,000 will probably be around Jan 7, but don't wait, upgrade as soon as possible.

Is the 25,000 switch on time 'official' now? Will there be an announcement for people to update nodes? We're at 23,770 as I'm writing this so it's not far off. I'd like to upgrade my node but don't want to do it if it's going to change. Are you going to add a checkpoint in the release?

I copied my wxWidgets source code from the hard disk that had been in my old 32 bit Fedora 14 box to the /usr/src area on my currency 64 bit Fedora 15 bix and compiled it successfully first time.

In the process I saw names going by like cairo and pango that reminded me what the pain had been: dependencies. It had been really hard to find out exactly what that long list of things had been that it actually needed to get those components to work; the original list had not been right for Fedora.

Since you mention binaries, I won't bother deleting the .o files, on the probably not likely but maybe hypothetically possible chance they could work on Ubunto; and will .tgz the directory and put it on the sunsite downloads site. Hpoefully if nothing else seeing the exact dependencies that worked on both Fedora 14 and Fedora 15 might help get it working on Ubunto.

I think it is possible that I never even tried to get the bitcoin wxWidgets GUI to work on my 64bit, Fedora 15 boxes, so maybe there isn't even anything weird and special installed on this box that made this compile work. (Other than it already has everything the -qt needed.)

Wow wxWidgets is huge:

-rw-r--r--.  1 root root 335759774 Dec 30 01:10 wxWidgets-2.9.0.Fedora15.tgz

I'll have to use sftp to put it on sunsite, web uploads don't seem to work for anything over a meg or few. It'll take a while to get there.

-MarkM-

From looking at the trading on vircurex:
https://vircurex.com/

There is a 28 BTC trading volume on i0coin, but only 1 BTC on iXcoin. So you could run the pool with devcoin as the parent, namecoin and i0coin as the auxilaries, and sell all the i0coins as your fee for the extra work in running a merged mining pool.

I was thinking Ubuntu would be enough, as a majority of the people using the devcoin-qt client are doing so on Ubuntu.  I was not able to install wxWidgets in June, but installing under Ubuntu is supposed to be doable:
http://wiki.wxwidgets.org/Installing_and_configuring_under_Ubuntu


I don't understand what the patches are doing, but I speculate that indeed the patches must be setting up threads themselves.  I would speculate that there should be a way to just check without setting up more threads, but I don't know how to do that. If there are no objections, they'll be an twelve generation share bounty to check in some way that doesn't crash a Qt client, divided by everyone who codes it. I know that won't magically fix the problem and I don't know if the problem can be fixed, but if it can it'll give the developers who fix it some of what they deserve.


I believe our previous problem was that the Qt threads were incompatible with threads made by other programs. When we tried calling a python script from within Qt it crashed; when we tried running a python script and then reading the result from a file, that worked fine.


I suspect that bitcoin-qt wraps tightly with the network code. If someone does make a thin GUI client which communicates securely with the daemon, that would be good too.


I tried it under Ubuntu, and I could not get it to compile.  I'm hoping that either the wxWidgets package has improved, or that someone else could make a devcoin-wxWidgets binary and I could run that.

I'm not sure I see the value in i0 and iX merged mining , they are basically dead , broken coins with no purpose or future

Rock On!

this was on a private testpool.

Pool.devcoin.org is exclusively mining devcoins on mainnet until we get to the magic number block then I will shut down and reboot with new config and will be live on Bitcoin, Namecoin and Devcoin Network.

Although it will take me a day or two to get the stats and web pages upgraded for users we will be effectively merged as soon as that magic number hits and I reboot the pool software.

Who is "most people"? Windows?

We should nail down exactly what is causing the crash. We already got rid of what was causing it before, which was mining.

So what the heck is causing it now?

What was mining doing that caused it? Was it just that mining uses threads?

This error looks as if threads are happening even without mining. Maybe the patches explicitly set up threads themselves?

I am not really clear as to whether our previous solution (simply not trying to mine) worked due to eliminating the use of threads or due to eliminating of whatever it was that was not thread-safe.

Are there still threads? What for? Why aren't there threads in the daemon?

Is the GUI simply trying to pretend to be both a front end GUI and a back end daemon by running a GUI thread and a daemon thread? If so maybe we could/should rip out the GUI from the deamon and have the GUI totally separate, like any normal unix application that provides a GUI front end to interact with a daemon?

That might be approaching close toward being a thin client, maybe we can look around and find a thin client people who want a GUI can use to talk to the daemon?

OH WAIT! Open Transactions' java client includes a tab in which you talk to your bitcoin daemon.

I don't recall exactly what problems I had to solve to get the wxWidgets bitcoin to compile, I do recall it was a pain, and took a while. I was given the impression that on normal systems, which maybe meant Windows, Mac and some kind of Linux, maybe Ubuntu or Debian or both, it "just works", that it didn't work on Fedora was my fault for using Fedora instead of the target platform. What platform did you try it on?

-MarkM-

The reason I started with bitcoin-qt is that I was not able to compile bitcoin-wxWidgets. If someone can make a binary of bitcoin-wxWidgets that most people could install then that would be good enough.

Another possibility is that the offending process call could be changed to a file write by a script and then a read by bitcoin-qt. What I mean is that just before we ported over the remaining python stuff in the really old devcoin to boost C++, we did manage to get python working safely from qt by calling the script, having the script write to a file, then reading that file. Since this was awkward we dropped it when the remaining python code was ported to C++. However, if in this case there is no other way to solve the problem, then CheckBlock could use that same technique.

Qt comes from repositories as packages for your system. wxWidgets not so much. At least not the version bitcoin needed/used.

I did get it to actually work on Fedora 14, and I see I still have that machine's hard drive mountable in this machine so I can grab it over and see if it still compiles in Fedora Core 15.

Some folk apparently actually like that old GUI better than the qt one.

It is right there in the old-devcoind repo, you "just" need the dependencies...

-MarkM-

Namecoin doesn't have a gui and i0coin uses the older wxwidgets based GUI.

What client GUI do i0coin and namecoin use?

I missed this, sorry. This means you're not actually mining devcoins at the moment. Your blocks will be created but then orphaned by the network as all the other nodes should reject them. You'll basically be mining your own fork of devcoin. What is the current hashrate of the entire devcoin network? Someone should ask allchains to support it, or provide an equivalent if possible.

My boost libs all seem to be indicating they are boost 1.46.0

-MarkM-

I searched for the error and found this:
https://svn.boost.org/trac/boost/ticket/3951

It seems that the problem occurred when -O2 or -O3 gcc optimizations were used:
"I now also observed that the code works with templates if I compile it with -O1. If -O2 or -O3 is used, the assertion occurs. "

along with boost 1.40, 1.41 or 1.42.  It did not occur in boost 1.36, and was fixed in boost 1.45.

I'll probably add it to mmpool to see how it goes. That'll give it 30-40 Ghash/s.