I just added a "TEST ONLY" exe to the github repository. This one will use the new pchmessage code and will fork on 11-12-2018 and 11-13-2018. Everything mined on this exe will not be part of the main network, its for testing only. If you try the new pchmessage version of 15.1 it may see this wallet but it will not be compatible since the hard fork coding will occur at a different block and will not be accepted by any other exe's other than this particular one.
https://github.com/number435398/Noodlyappendagecoin-project/blob/master/noodlyappendagecoin-qt%20TEST%20ONLY.exe
Topic: [ANN] NDL - The coin for Pastafarians - Flying Spaghetti Monster Cryptocurrency! - page 14. (Read 125333 times)
November 12, 2018, 07:55:32 AM
November 10, 2018, 05:17:42 PM
I'd really like to get some functionality feedback on the wallet. I think it may be ready for prime-time but I need a consensus before I make such a declaration. I need to make sure you guys accept the fork times and such. Once we all agree and it works, that's when DaveF may be able to update the explorer with the new wallet and the new pchmessagestart code and then we're pretty much set.
No, I haven't updated it for gitian yet though I am starting to look into it.
No, I haven't updated it for gitian yet though I am starting to look into it.
November 08, 2018, 05:35:06 PM
Alright guys, I reverted to fork litecoin v 15.1 as opposed to 16.3 and everything appears to work perfectly! It still contains all the updates we need to be listed on an exchange as well.
https://github.com/number435398/Noodlyappendagecoin-project
The code is there as well as a compiled windows exe file! Now comes time for the good testing!
https://github.com/number435398/Noodlyappendagecoin-project
The code is there as well as a compiled windows exe file! Now comes time for the good testing!
November 05, 2018, 03:19:13 PM
Use the Gitian build system, it is there for a reason.
That's something you say to someone when there's power tool on the table right in front of them and they're not using it in spite of being in a situation where they are in need of it; "it's there for a reason" or "I put it there for you for a reason". I don't even know what the "gitian build system" is, nor am I aware of its presence or location.
I was hoping you might ask, "WTF is Gitian" so that I could teach you.
Here are some links: Gitian building, release-process.
With the information there you should be able to get an idea of why it is a super powerful tool.
Imagine being able to build the binaries and come out with the exact same result as some other guy who built from the same sources -- while at the same time getting builds made for Windows, Linux, macOS and Raspberry Pi in just a couple of hours. That is Gitian.
Best Regards,
-Chicago
Thank you for that information. I may not fully understand the rest of it; I thought "the exact same result" is what other people would get too w my current repository with mingw in Linux.
I don't mind altering the code for your specified purposes and goals, but for now I'm going to be focusing on getting the wallet to read the addresses it creates. I want to get it fully working first and foremost.
November 05, 2018, 03:09:44 PM
Use the Gitian build system, it is there for a reason.
That's something you say to someone when there's power tool on the table right in front of them and they're not using it in spite of being in a situation where they are in need of it; "it's there for a reason" or "I put it there for you for a reason". I don't even know what the "gitian build system" is, nor am I aware of its presence or location.
I was hoping you might ask, "WTF is Gitian" so that I could teach you.
Here are some links: Gitian building, release-process.
With the information there you should be able to get an idea of why it is a super powerful tool.
Imagine being able to build the binaries and come out with the exact same result as some other guy who built from the same sources -- while at the same time getting builds made for Windows, Linux, macOS and Raspberry Pi in just a couple of hours. That is Gitian.
Best Regards,
-Chicago
November 05, 2018, 01:44:36 PM
Use the Gitian build system, it is there for a reason.
That's something you say to someone when there's power tool on the table right in front of them and they're not using it in spite of being in a situation where they are in need of it; "it's there for a reason" or "I put it there for you for a reason". I don't even know what the "gitian build system" is, nor am I aware of its presence or location.
November 05, 2018, 02:46:51 AM
Use the Gitian build system, it is there for a reason.
With it, producing all of the builds for Linux, Windows, macOS and Raspberry Pi become much less prone to human error.
Getting up to speed with Gitian is as easily as looking for the release-process document and following the Gitian guide.
All of the steps can be done inside of VirtualBox.
With it, producing all of the builds for Linux, Windows, macOS and Raspberry Pi become much less prone to human error.
Getting up to speed with Gitian is as easily as looking for the release-process document and following the Gitian guide.
All of the steps can be done inside of VirtualBox.
November 05, 2018, 01:19:34 AM
Yes, I do see the word mingw, but didn't see it in the same context as mingw for windows. Perhaps I should clarify; the only formal training I have in programming is for QBasic. You know...for DOS...that was used in the 90's. No one else took up the mantle to update the wallet, so I did. No, I obviously don't know what you know.
My code works with the instructions provided by the Litecoin developers. Their instructions obviously include Mingw. It works in that context; I can't speak to other contexts.
okay then, 'trust me'
I'm not distrusting you at all. I am just very inexperienced in this kind of thing and, at the very least, can only confirm it will work in the same environment I have setup. I will definitely consider updating that uint thing.
With those variables aside were you able to compile it?
yes, but wont be able to run and play with it for some unknown time this week, my usual couple free hours per week is basically weekends.
Fair enough.
I just updated the validation.cpp on github to reflect your suggestion to convert u_int64 to uint64_t.
November 05, 2018, 01:17:44 AM
Yes, I do see the word mingw, but didn't see it in the same context as mingw for windows. Perhaps I should clarify; the only formal training I have in programming is for QBasic. You know...for DOS...that was used in the 90's. No one else took up the mantle to update the wallet, so I did. No, I obviously don't know what you know.
My code works with the instructions provided by the Litecoin developers. Their instructions obviously include Mingw. It works in that context; I can't speak to other contexts.
okay then, 'trust me'
I'm not distrusting you at all. I am just very inexperienced in this kind of thing and, at the very least, can only confirm it will work in the same environment I have setup. I will definitely consider updating that uint thing.
With those variables aside were you able to compile it?
yes, but wont be able to run and play with it for some unknown time this week, my usual couple free hours per week is basically weekends. i go to bed now, up in 5.5 hours for work.
November 05, 2018, 01:15:59 AM
Yes, I do see the word mingw, but didn't see it in the same context as mingw for windows. Perhaps I should clarify; the only formal training I have in programming is for QBasic. You know...for DOS...that was used in the 90's. No one else took up the mantle to update the wallet, so I did. No, I obviously don't know what you know.
My code works with the instructions provided by the Litecoin developers. Their instructions obviously include Mingw. It works in that context; I can't speak to other contexts.
okay then, 'trust me'
I'm not distrusting you at all. I am just very inexperienced in this kind of thing and, at the very least, can only confirm it will work in the same environment I have setup. I will definitely consider updating that uint thing.
With those variables aside were you able to compile it?
November 05, 2018, 01:14:00 AM
Yes, I do see the word mingw, but didn't see it in the same context as mingw for windows. Perhaps I should clarify; the only formal training I have in programming is for QBasic. You know...for DOS...that was used in the 90's. No one else took up the mantle to update the wallet, so I did. No, I obviously don't know what you know.
My code works with the instructions provided by the Litecoin developers. Their instructions obviously include Mingw. It works in that context; I can't speak to other contexts.
okay then, 'trust me'
November 05, 2018, 01:09:35 AM
Quote
yes, use uint64_t, do not use u_int64.
it will NOT compile in a non-Mingw environment (both linux and Mac)
the cd in the copy of trythis i got from github occurs AFTER the call to 'sudo make -j4 HOST=x86_64-w64-mingw32'. (ie: make is line 7, cd is line 8, another make without args on line 11
I don't use Mingw.
There must be a number of crazy variations on Linux then. Because it compiles for me in Linux just fine (with regards to the u_int64).
the text for my "trythis" is as follows:
Code:
cd depends
PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g')
sudo apt get libevent
sudo chmod +x config.guess
sudo chmod +x config.site.in
sudo chmod +x config.sub
sudo make -j4 HOST=x86_64-w64-mingw32
cd ..
./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
make
There are two "make"'s. The purpose of the first "make" is...well...I don't really know for sure. Its what the Litecoin devs required and its worked so far for me. Perhaps my trythis file won't work for everyone.
I have compiled this code countless times in "Ubuntu 18.04.1 LTS".
you are cross-building for windows, arent you? and dont you even seen the word mingw in that scripot you just posted above?
Mingw exists on linux and on windows systems. it's basially GCC trying to use the microsoft libraries in a native sort of fashion. and every coin wallet i've seen chooses this path. personally i prefer the Cygwin gcc environmnet on windows -- it attempts valiantly to hide the perverse quirks of microsoft Visual C code and library implementations by putting a posix compliant layer on top of the microsoft mess.
Yes, I do see the word mingw, but didn't see it in the same context as mingw for windows. Perhaps I should clarify; the only formal training I have in programming is for QBasic. You know...for DOS...that was used in the 90's. No one else took up the mantle to update the wallet, so I did. No, I obviously don't know what you know.
My code works with the instructions provided by the Litecoin developers. Their instructions obviously include Mingw. It works in that context; I can't speak to other contexts.
November 05, 2018, 01:05:13 AM
Quote
yes, use uint64_t, do not use u_int64.
it will NOT compile in a non-Mingw environment (both linux and Mac)
the cd in the copy of trythis i got from github occurs AFTER the call to 'sudo make -j4 HOST=x86_64-w64-mingw32'. (ie: make is line 7, cd is line 8, another make without args on line 11
I don't use Mingw.
There must be a number of crazy variations on Linux then. Because it compiles for me in Linux just fine (with regards to the u_int64).
the text for my "trythis" is as follows:
Code:
cd depends
PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g')
sudo apt get libevent
sudo chmod +x config.guess
sudo chmod +x config.site.in
sudo chmod +x config.sub
sudo make -j4 HOST=x86_64-w64-mingw32
cd ..
./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
make
There are two "make"'s. The purpose of the first "make" is...well...I don't really know for sure. Its what the Litecoin devs required and its worked so far for me. Perhaps my trythis file won't work for everyone.
I have compiled this code countless times in "Ubuntu 18.04.1 LTS".
you are cross-building for windows, arent you? and dont you even see the word mingw in that script you just posted above?
Mingw exists on linux and on windows systems. it's basially GCC trying to use the microsoft runtime API in a native sort of fashion. and every coin wallet i've seen chooses this path. personally i prefer the Cygwin gcc environmnet on windows -- it attempts valiantly to hide the perverse quirks of microsoft Visual C code and library implementations by putting a posix compliant layer on top of the microsoft mess.
if for on other reason, be consistent with what the rest of the litecoin package uses, even within the same validation.cpp file they use uint64_t
consistency is important for group projects.
November 05, 2018, 12:59:36 AM
Quote
yes, use uint64_t, do not use u_int64.
it will NOT compile in a non-Mingw environment (both linux and Mac)
the cd in the copy of trythis i got from github occurs AFTER the call to 'sudo make -j4 HOST=x86_64-w64-mingw32'. (ie: make is line 7, cd is line 8, another make without args on line 11
I don't use Mingw.
There must be a number of crazy variations on Linux then. Because it compiles for me in Linux just fine (with regards to the u_int64).
the text for my "trythis" is as follows:
Code:
cd depends
PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g')
sudo apt get libevent
sudo chmod +x config.guess
sudo chmod +x config.site.in
sudo chmod +x config.sub
sudo make -j4 HOST=x86_64-w64-mingw32
cd ..
./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
make
There are two "make"'s. The purpose of the first "make" is...well...I don't really know for sure. Its what the Litecoin devs required and its worked so far for me. Perhaps my trythis file won't work for everyone.
I have compiled this code countless times in "Ubuntu 18.04.1 LTS".
November 05, 2018, 12:53:32 AM
I have had no problems with the source I uploaded with regards to the validation.cpp. Are you suggesting I establish that as a "uint64_t" as a general rule or are you having problems? Block 1 will not validate if that is not accepted, and I have experienced no problems therewith.
To confirm, you are concerned about the following code:
Code:
static const u_int64 TOTAL_GENERATION = MAX_MONEY;
static const double FSM_FUNDS = 0.03;
u_int64 nSubsidy = 10000 * COIN;
Yes, you're right on the 'apt get', I meant to remove that.
Line 8 is "cd .." which takes one out of the depends folder for "make".
yes, use uint64_t, do not use u_int64.
it will NOT compile in a non-Mingw environment (both linux and Mac)
the cd in the copy of trythis i got from github occurs AFTER the call to 'sudo make -j4 HOST=x86_64-w64-mingw32'. (ie: make is line 7, cd is line 8, another make without args on line 11
November 05, 2018, 12:42:38 AM
I am still learning how the GitHub desktop works. For months it wouldn't even run for me, so I'm a bit behind on that.
I have uploaded my source code:
https://github.com/number435398/Noodlyappendagecoin-project
I have uploaded my source code:
https://github.com/number435398/Noodlyappendagecoin-project
in src/validation.cpp you added a type reference "u_int64"
this is not a standard type.
this particular source package uses uint64_t everywhere else,
and if you do need to reference a non-basic type for a new variable, make sure the configure script
has a recipe to test for its existence, and if not exists, unleash a sutiable definition in a .h
file somewhere.
your 'trythis' script mentions doing a make while in the 'depends' folder. there is no Makefile in that folder.
it also does an 'apt' get. not all versions of linux or bsd support apt as a package manager (mine does not), if you want to make sure a certain package is installed the configure script is the appropriate place to put a test recipe and a message to the user to fetch the damn thing themselves if the library and/or headers are missing. (or perhaps simply state the package is missing -- with less colourful language than i am prone to.)
I have had no problems with the source I uploaded with regards to the validation.cpp. Are you suggesting I establish that as a "uint64_t" as a general rule or are you having problems? Block 1 will not validate if that is not accepted, and I have experienced no problems therewith.
To confirm, you are concerned about the following code:
Code:
static const u_int64 TOTAL_GENERATION = MAX_MONEY;
static const double FSM_FUNDS = 0.03;
u_int64 nSubsidy = 10000 * COIN;
Yes, you're right on the 'apt get', I meant to remove that.
Line 8 is "cd .." which takes one out of the depends folder for "make".
November 05, 2018, 12:15:59 AM
I am still learning how the GitHub desktop works. For months it wouldn't even run for me, so I'm a bit behind on that.
I have uploaded my source code:
https://github.com/number435398/Noodlyappendagecoin-project
I have uploaded my source code:
https://github.com/number435398/Noodlyappendagecoin-project
in src/validation.cpp you added a type reference "u_int64" in a couple places
this is not a standard type.
this particular source package uses uint64_t everywhere else, even within validation.cpp
and if you do need to reference a non-basic type for a new variable, make sure the configure script
has a recipe to test for its existence, and if not exists, unleash a sutiable definition in a .h
file somewhere.
your 'trythis' script mentions doing a make while in the 'depends' folder. there is no Makefile in that folder.
it also does an 'apt' get. not all versions of linux or bsd support apt as a package manager (mine does not), if you want to make sure a certain package is installed the configure script is the appropriate place to put a test recipe and a message to the user to fetch the damn thing themselves if the library and/or headers are missing. (or perhaps simply state the package is missing -- with less colourful language than i am prone to.)
by the way, i was not doing a Mingw type build but a native linux non-gui daemon build. i find debugging is much easier without GUI api stuff getting in the way.
i'm guessing u_int64 is a Mingw-ism ? (aka Micorsoft-ism?)
November 04, 2018, 01:26:18 PM
I am still learning how the GitHub desktop works. For months it wouldn't even run for me, so I'm a bit behind on that.
I have uploaded my source code:
https://github.com/number435398/Noodlyappendagecoin-project
To build it, if you have all the dependencies type ./trythis; or edit the trythis file and you'll see the necessary commands, whichever you prefer. Just make sure trythis, autogen.sh, configure.ac and /share/genbuild.sh are set to "Allow executing file as program". For some reason I have to continually change that.
As is the wallet creates valid addresses, but will not track the addresses it creates on the balance sheet (I don't know why that is). It will track, however, any existing addresses on a wallet.dat file.
I have uploaded my source code:
https://github.com/number435398/Noodlyappendagecoin-project
To build it, if you have all the dependencies type ./trythis; or edit the trythis file and you'll see the necessary commands, whichever you prefer. Just make sure trythis, autogen.sh, configure.ac and /share/genbuild.sh are set to "Allow executing file as program". For some reason I have to continually change that.
As is the wallet creates valid addresses, but will not track the addresses it creates on the balance sheet (I don't know why that is). It will track, however, any existing addresses on a wallet.dat file.
November 04, 2018, 11:52:02 AM
Quote
I only hope the programming efforts by you brave ones here won't destroy or split the coin over the next weeks. I am not sure if I should further mine it, because I am not sure, if the chain of our block explorer still is the only one, or if another one is actually being prepared in the background.
Even with my wallet, there is no such fork. The wallet, as currently programmed (where it has some address problems) will not fork the network for several weeks from now, but its just a beta anyhow. The current block explorer will not accept that fork anyhow. Once I finish it, I will hardcode another checkpoint to ensure the explorer is correct. This does mean, however, that if someone is on some other fork, that fork will be ignored.
I am following the explorer for the main network. If you think you are on a fork that does not correlate with the explorer, then I would advise taking steps to connect it to the explorer so that whichever fork is strongest will take hold. Even if that means running my old one that I called "0.0.3". Or even running my beta wallet right now; it connects to the explorer too. Just be weary of any addresses my new wallet makes; still working on that.
November 04, 2018, 09:54:27 AM
for future use, here is the graviex.com listing request form:
https://docs.google.com/forms/d/e/1FAIpQLSeFC98OclfkdMKcmwntfTOayung5CgykG_SBxbedCm8NLprWw/formResponse
https://docs.google.com/forms/d/e/1FAIpQLSeFC98OclfkdMKcmwntfTOayung5CgykG_SBxbedCm8NLprWw/formResponse
If I have seen it right, their 3000000 GIO Coins requested for listing would cost abt. 1300 USD at the moment of writing (depending also on the btc spot - if it falls through the side-range during the next days or few weeks - which is what I believe - it could be less).
The graviex team is from russia and acting from Malta. Hm. How perfect this is for a fun Coin! ;-)
____
I only hope the programming efforts by you brave ones here won't destroy or split the coin over the next weeks. I am not sure if I should further mine it, because I am not sure, if the chain of our block explorer still is the only one, or if another one is actually being prepared in the background.
Anyway, I am ready to support the guys in that thread by noodly touches where ever I can. By the way: That DOESN'T mean that we should keep up the illusion of a pressure in time - there's enough time, while we still are in a rough bear market outside! So, why that hard pace? So:
30.000.000 NDL coins for a well tested NDL wallet Version (and yes, - a testnet is indeed helpful, everyone acting proffessional uses one, to ensure his coins survival, instead of any unwanted headless acting). And - if two or three persons work on it together - each of them will get that amount.
But, please: Really think and work TOGETHER. So far this has been never a problem in this thread, but it might be one in the future, if anyone feels too much pressure to succeed fast without need.
Greez,
n.
Jump to: