Ps. Oczywiście nie żadnych peerów, tylko na myśli miałem dokładnie: “Query and display bitcoin DNS seeds, for P2P node addresses”.
Przy okazji: Ten spam o którym była mowa kilka postów wyżej, pojawia się też w Tag-ach.
Taadaaam ! Obudziłem Frankenstein-a, ale się cieszę :D. Portfel częściowo działa pod MOS-em – Frankenstein podryguje. Generowanie samego porfela i adresów – śmiga. Zapytanie o peer-ów P2P – śmiga (tu się nakombinowałem bo MOS-owy ixemul-u nie ma getaddrinfo()).
Synchronizacja portfela z siecią na razie leży – czas na przyzwoite “sportowanie” libevent2. Także o sprawdzaniu stanu konta, czy wysyłaniu płatności na razie mowy nie ma.
Aczkolwiek teoretycznie za pomocą dołączonego programu (blkscan albo blkstats) możnaby sprawdzić stan konta. Jednak teoretycznie, bo nie widziałem jeszcze ostatecznego wyniku działania tych narzędzi. Na 32bit Linux sprawdzałem z plikiem bloków 22GB (: i po godzinie coś glib wymięka z alokacją pamięci także w związku z tym pod MorphOS-em ten test sobie na razie odpuszczam – może trzeba podzielić ten plik na mniejszcze części…
A w temacie, jedynym otwartoźródłowym kodem, sprawnym dla Big-endian jest libccoin i chyba całkiem dobrze się składa, że autor jgarzik należy do coreteam-u #itcoin.
Na razie do portfela jeszcze daleko ale sam lib pod ixemulem działa bez problemu (przynajmniej w obecnej fazie testowania).
Libbitcoin requires a C++11 compiler, which means GCC 4.7.0 minimum.
Czyli na razie nici, raczej ?
A mi OWB loguje się bez kombinacji na allegro, ciekawe, że u niektórych jest problem.
Postaram się uporządkować trochę temat aby dokładniej nakreślić o co mi chodzi.
Otóż mam zapisane ustawienie domyślne dla MUICON odpowiadające moim preferencjom. Domyślnie widocznych jest kilka przycisków.
Teraz niezależnie od powyższych ustawień chcę mieć:
1. Możliwość uruchamiania pewnego programu działającego w trybie tekstowym (wykorzystuje on klasę PowerTerm) w oknie MUICON w taki sposób aby były schowane przyciski (NewPage itp.).
2. Dodatkowo okno to ma mieć inne położenie i wymiary niż domyślne dla NewShell (z menu Ambienta).
3. Uruchamiać się w innej kolorystyce niż domyślnie zapisana dla PowerTerm.
Jak mi się wydaje odpowiedzialne za te ustawienia są:
Ad. 1 – ENV:Sys/CON_muiconhandler.prefs
Ad. 2 – NewShell WINDOW="CON://///" FROM=skrypt (w tym skrypcie następuje uruchomienie programu)
AD. 3 – ENV:MUI/MCON.1.prefs – (stąd pytanie o sposób sprawdzenia aktualnej ilości otwartych okien CLI)
Jak tego dokonać ? Nie znalazłem przykładu jak wczytać własną konfigurację w skrypcie.
Mam pomysł na rozwiązanie, przynajmniej częściowe.
Jakby ktoś miał podobny problem to trzeba zaznaczyć, że parametry typu NOCLOSE, NOBORDER itp. dla polecenia NewShell (dla Tooltype IconX również) działają tylko dla konsoli typu RAW: lub SYSCON: nie ma szans aby to zadziałało z CON: czy MUICON: raczej.
Co do uruchamiania okna CLI (CON: lub MUICON:) z uwzględnieniem odrębnej konfiguracji, to można posłużyć się pewnym trick-iem. Mianowicie w skrypcie AmigaDOS przed poleceniem NewShell należy umieścić polecenie które podmieni konfigurację domyślną [ENV:Sys/CON_muiconhandler.prefs] na docelową zapisaną wcześniej pod inną nazwą i ewentualnie lokacją. Z kolei przywrócenie domyślnej konfiguracji można wykonać w pierwszej lini skryptu uruchamianego przez ów NewShell wykorzystującym [FROM].
Albo może inaczej: Jak uruchamiać CLI z uwzględnieniem zapisanych ustawień MUICON innych niż default-owe ?
Piękna kolekcja 🙂
W kwestii wypalania DVD z grubsza sprawa wygląda tak, że ISO nie przechowa pliku powyżej 2GB. Potrzebny jest UDF 2.50 (i chyba konieczna jest płyta DVD RAM). Także zabrnąłem w ślepą uliczkę. Albo rozbebeszę archiwum 2.3 GB na dwa mniejsze i wypalę pod MOS-em, albo w ramach eksperymentu zepsuję drugą płytkę DVD -R na innym systemie .
FryingPan-em tak właśnie robiłem. Jalapeno chyba w ten sposób nie potrafi.
Z IceFS to samo, zarówno w kwestii listowania archiwów jak i Jalapeno.
Generalnie Jalapeno tworząc ISO, dzieli sobie większe pliki i zapisuje ISO w kawałkach maksymalnie po 1GB. W moim przypadku (dwa pliki 2.3 GB + 1.45 GB) z mniejszego pliku robi ISO w dwóch kawałkach – 1 GB i 460 MB, a z większego jeden „kawałek” 0 b. Dla ścisłości dodam, że jadę jeszcze na MOS 3.4, czyli chyba powinienem sprawdzić też na 3.5.
Teraz kolej na sprawdzenie co na to FryingPan, tylko czy on działa prawidłowo na PB ? Na razie mam Drive Unregistered, klucz co prawda mam na Pegazie ale on chyba jest przypisany do napędu jak dobrze pamiętam.
Ps. Pobrałem FP 1.32 full version i to samo. Problem z plikiem 2.3 GB – Item size: 0. Zarówno z partycji IceFS i SFS. Features: large files dla IceFS jest. No to jeszcze MakeCD do kolekcji został.
Archiwum leży sobie na partycji SFS. System plików jak mi się wydaje „daje radę”, gdyż narzędziem tar z SDK można zbudować takowe i spokojnie je rozpakować. Z pamięcią jak zaobserwowałem przed chwilą jest tak, że przy „wkliknięciu” np. w archiwum tar-owe o rozmiarze 512 MB podczas listowania w Ambiencie, dostępna pamięć ram zmniejsza się chwilowo o około 4 MB. Co ciekawe, zrobiłem teraz archiwum tar 1.4 GB i problemu z listowaniem pod Ambientem nie ma 🙂 czyli zdaje się jest gdzieś „magiczna" bariera 2 GB. Tak czy innaczej trzeba będzie raport zrobić. Co do angielskiego to bez rewelacji ale jak się postaram to podobno i zrozumieć można :).
Ps. Ehhhmm, zdaje się jest inny problem jeszcze. Jalapeno jakby nie lubi plików powyżej 2GB. Po zrobieniu ISO z dwóch plików: 2.3 GB + 1.45 GB twierdzi, że ma do wypalenia ISO o rozmiarze 1.45 GB :]
„Co sie naczyścim to sie natrudzim co sie nasprzątam to se nabrudzim" czy jakoś tak to szło. No nic trzeba kombinować – amigowanie :).
Kwestia sprawnego zlib-a i można odpalać zgodnie z procedurą, i instalować gdzie się chce
Sprawdzone z oryginalnymi źródłami libpng-1.6.9.
Copyright 2014 - Wszelkie prawa zastrzeżone MorphOS.pl