English | Magyar
JS ki | CSS ki | Ékezetek ki | HiContrast
Lapozó:  (0 - 1424) 
<== | ==>
Ugrás a végére | Összes megjelenítése | Utolsó oldal
OpenOpera patches | Opera-SSL patches | Opera 12.15 source (Git repository) | Opera 12.15 source (Torrent) | Opera internal pages | Otter Browser Linux x64 - Qt5.15.2/QtWebKit5.602.1 (2024.04.27. 20:05)
OS for MC680x0 | OS for PPC | OS for Sparc64 | besztofbégéaefcé | CSÉNDZSLOG | WebToolz | DDG Shit Filter | Google Shit Filter | Progz | Fast CSS Box | Browser | OS | Agent | Statisztika | BBCode
Monospace font-family: Courier New | Browser default monospace
Email értesítő / Email notification ===> 
Keresés
Σ: 16 post

TCH  (statz) Főfasz
#1, Főfasz (10443)
186 | #2f10 | ^ | Idézet | Sat, 22 Nov 2014 01:29:30 +01
46.139.*.* Linux x86 Opera Classic Hungary *.catv.pool.telekom.hu
http://index.hu/belfold/2014/11/21/senki_sem_nyer_a_fidesz_zsugorodasabol/

Én mondtam.

Bocsánat a politikáért, lehúzom magam a vécén magamtól is.


TCH  (statz) Főfasz
#1, Főfasz (10443)
9061 | #2f11 | ^ | Idézet | Sun, 23 Nov 2014 20:41:53 +01
46.139.*.* Linux x86 Opera Classic Hungary *.catv.pool.telekom.hu
Boldog május elsejét minden kecskekúrógépnek.
Mai témánk az RGB komponensek kiterjesztése, illetve összezsugorítása.

Széleskörben elterjedt téveszme az, hogy az RGB komponensek kiterjesztése, ill zsugorítása pofonegyszerűen megoldható egyetlen sima shifteléssel: ha 4 bitről 8-ra terjesztünk ki, vagy 8-ról 4-re zsugorítunk, akkor az 4 bit eltolás balra vagy jobbra, ha 8-ról bővítünk 16-ra, vagy 16-ról 8-ra, akkor az 8 bit eltolás egyik vagy másik irányba.
Ez egyébként valóban működik így...csak épp szarul. Ez a probléma jelen volt már Amigán is (amikor megjelent az AGA és az addig 12-bites RGB kódokat 24-bitesre kellett kiterjeszteni), de jelen van még ma is, amikor pl. olyan PNG-vel dolgozik az ember, amiben a komponensek nem 8-bitesek, hanem 16.
Mi is ezzel módszerrel a baj? Az, hogy nem pontos. Minden sötétebb lesz, mint kéne, hogy legyen. Nézzük csak végig, hogy miért. Először a 4/8-as párt.

Ha egy 4-bites komponenst kiterjesztünk sima 16-os szorzással (4-bites eltolás), akkor valami ilyesmi fog történni: 0x5 => 0x50
Miért nem jó ez? Azért, mert a 4-bites skálán az 0x5 az baromira nem ugyanaz a fényerő, mint a 8-bitesen az 0x50. Ezzel az értékkel annyira nem egyértelmű, de nézzük meg egy másikkal! 0xf => 0xf0
Ugye, hogy baromira nem stimmel valami? 4 biten az 0xf a maximum fényerőt jelenti, míg 8-biten az 0xf0 közel sincs hozzá, ami azt illeti, 4 bitre visszavezetve, arányaiban közelebb áll az 0xe-hez, mint az 0xf-hez!
A miértje egyszerű ennek a dolognak: a konvertálás lépésköze nem stimmel, mert az nem 16. Az arányos lépésközt pedig úgy lehet kiszámítani, hogy a két skála lépéseinek számát elosztjuk egymással. Ha a 4-bites komponenst nézzük, akkor ott a nulla után 15 db lépés van 0xf-ig. Ha a 8-bitest, akkor 255 lépés van 0xff-ig. 255 / 15 = 17. Ergo a 4/8-bites konverzióknál 17 az arányos lépésköz és nem 16. Tehát 0x5-ből nem 0x50 lesz, hanem 0x55 és 0xf-ből sem 0xf0, hanem 0xff. 17-tel kell szorozni vagy osztani, nem 16-tal. És ugyanez a szabály vonatkozik a 8/16-bites konverzióra. 65535 / 255 = 257, tehát ott pedig 257 a lépésköz.

A zsugorítás már egy picit trükkösebb. Ott ugyanis nem elég a lépésközzel leosztani az értéket, mert pl. 0xed / 17 = 13 azaz 0xc lesz, holott az 0xed-ből ugyanúgy 0xe kéne, hogy legyen, mint az 0xee-ből. A trükk persze nem agysebészet: kerekíteni kell. Persze egy komponens zsugorításánál orbitális baromság lenne lebegőpontos műveleteket végezni; erre való a maradékos osztás: ha a maradék nagyobb, mint a lépésköz fele, akkor inkrementálni kell a normál osztás végeredményét.

Ennek megfelelően:
4=>8: c * 17
8=>16: c * 257
8=>4: (c / 17) + (c % 17 > 8)
16=>8: (c / 257) + (c % 257 > 128)

Ez persze nem kicsit lassabb, mint a 16-al/256-al való szorzás-osztás, ami gyakorlatilag 4/8 bittel való tologatás. Nade, lehet optimalizálni.

A szorzást gyerekjáték. x * (2n + 1) = (x << n) + x

Az osztást már szopatósabb, főleg, mivel kétféle osztás is van benne. Ami azt illeti, modern procin nincs is értelme lebontani más, egyszerűbb műveletekre, mert lassabb lesz, mint maga az osztás lenne. (A szorzásra ez nem vonatkozik, az egy shift és egy összeadás modern gépen is gyorsabb lesz, mint az egy szorzás.) Régi procin (pl. 68000-esen) viszont már van értelme.
Egyik optim. módszer a táblás verzió. (Az egyébként még a szorzáson is gyorsítana, a tábla gyorsabb, mint a shift + összeadás.) Viszont a táblával a 16-bites komponens zsugorításánál lesz egy "kis" gond. Az, hogy rohadtul 64 kB hosszú lesz. A másik három tábla nem olyan nagy (4=>8: 16 byte, 8=>16: 512 byte, 8=>4: 256 byte), együttesen sem foglalnak le 1 kB-t, de a negyedik az bazinagy lenne. A helytöbblet sokszorosa a sebességtöbbletnek. (Modern gépen, ahol egy osztás már 3-4 ciklus, ott többezerszerese, régi gépen, ahol az osztás még több mint 100 ciklus volt, ott többtízszerese.) Modern gépen kurwára értelmetlen, régi gépen meg kurwára nem fér el.

Viszont valami beugrott, ahogy keresgettem, hogy hogy lehet kiegyszerűsíteni a 257-el való osztást. (Egyébként semmit nem találtam rá.) A 255-el való osztásra egyszer már találtam valami (félig-meddig) megfelelő megoldást. Az a képlet úgy szólt, hogy x / 255 = (x * 257) / 65536 (kivéve ha a maradék nulla). Ami nem volt teljesen igaz, mert 10 milliomodos nagyságrendű eltérés van a két képlet között. Na, az 16 bitre még bőven jó. 8-ra meg főleg. Na, most mivel a 255 meg a 257 pont ugyanakkora távra vannak a 256-tól, így gondoltam fel lehet őket cserélni, amúgy ugyanaz a megoldás (modulóstul):
(((x << 8) - x) >> 16) + (x % 257 == 0 && x != 0)
Írtam egy rövid C programot, ami az x / 257-et 0-tól 65535-ig összehasonlította ezzel a képlettel. 100%-os találat volt, vagyis az elgondolásom a 255<->257 cserélhetőségről jó volt.
A modulótól persze még nem szabadultunk meg, de közben ki akartam próbálni, hogy működik-e eggyel lejjebb is, 15<->17 felállásban:
(((x << 4) - x) >> 8) + (x % 17 == 0 && x != 0)
Ez is egyezett az x / 17 összes lehetséges eredményével. Na persze, még korai az öröm, a moduló még mindig ott kolbászol, rohaggyonmeg és úgy meg nem sok értelme van kiegyszerűsíteni egy osztást, ha lesz benne helyette egy másik.
Poénból kipróbáltam, hogy mi lesz, ha a % 17-et kicserélem bitmaszkra (& 15, ez tkp. a % 15 megfelelője). Nem vártam tőle semmit, de az eredményen néztem egyet, mert 256-ból 241 így is helyes eredményt adott ki, viszont ami igazán széppé tette az egészet az az, hogy csak ott nem stimmelt, ahol x alsó és fölső 4 bitje megegyezett (értsd: 0x11, 0x22, 0x33, ...). Sz*rk: Közben leesett, hogy ennek magyarázata abban rejlik, amit fentebb vezettem le, hogy x * 17 = (x << 4) + x, azaz a 17 szorzatainál az alsó és a felső 4 bit mindig ugyanaz. Magyarán az x % 17 == 0 felírható így is:
(x >> 4) == (x & 15)
Úgyhogy ebből már gyerekjáték volt kirakni a képlet végét:
(((x << 4) - x) >> 8) + (uint8_t)(((x >> 4) == (x & 15)) && (x != 0))
Tehát így lehet felírni a 17-el való osztást. És ennek megfelelően a 257-el való osztást meg így:
(((x << 8) - x) >> 16) + (uint16_t)(((x >> 8) == (x & 255)) && (x != 0))
És egyben akkor általános képlet gyanánt is leírható, hogy (16 biten!!!)
x / (2n + 1) = (((x << (n / 2)) - x) >> n) + (((x >> (n / 2)) == (x & (2n - 1))) && (x != 0))

No, eddig igazán kurwa jók vagyunk, csak az a baj, hogy a felezős moduló még mindig ott rohad. :P Viszont fel és alá kísérletezgetés közben leesett, hogy bazzeg a moduló, az maradék, hát ha az egész osztás eredményét visszaszorozzuk, akkor annak az eredménye és az eredeti szám különbsége az a maradék! (Ne röhögjetek, kurwa szar vagyok matekból!)
Azaz érthetőbben x % y == x - ((x / y) * y) Ebben ugyan megint van egy szorzás, de azt mint fentebb már kitrágyaltuk, x * 2n+1 esetén azt picsafasz kiegyszerűsíteni. Tehát (c / 17) + (c % 17 > 8) helyett:
tmp = (((x << 4) - x) >> 8) + (uint8_t)(((x >> 4) == (x & 15)) && (x != 0));
result = tmp + (x - (uint8_t)(((tmp << 4) + tmp) > 8));
És (c / 257) + (c % 257 > 128) helyett:
tmp = (((x << 8) - x) >> 16) + (uint16_t)(((x >> 8) == (x & 255)) && (x != 0));
result = tmp + (uint16_t)(x - (uint16_t)(((tmp << 8) + tmp) > 128));
Ennek megfelelően valahogy így lehet felírni a dolgokat:
#define component4_extend(c, r) (r) = ((c) << 4) + (c)
#define component8_extend(c, r) (r) = ((c) << 8) + (c)

#ifdef EZ_EGY_REGI_PROCI
#define component8_shrink(c, r, tmp) tmp = ((((c) << 4) - (c)) >> 8) + (uint8_t)((((c) >> 4) == ((c) & 15)) && ((c) != 0)); r = tmp + ((c) - (uint8_t)(((tmp << 4) + tmp) > 8))
#define component16_shrink(c, r, tmp) tmp = ((((c) << 8) - (c)) >> 16) + (uint16_t)((((c) >> 8) == ((c) & 255)) && ((c) != 0)); r = tmp + ((c) - (uint16_t)(((tmp << 8) + tmp) > 128))
#else
#define component8_shrink(c, r, tmp) r = ((c) / 17) + (uint8_t)((c) % 17 > 8)
#define component16_shrink(c, r, tmp) r = ((c) / 257) + (uint16_t)((c) % 257 > 128)
#endif
Huh, bazdmeg. Az elején nem gondoltam volna, hogy sikerül a 17-el és 257-el való osztásokat kiegyszerűsíteni. Ezért nem szabad soha feladni. :P
Viszont mégegyszer mondom, hogy modern procin nincs értelme kiegyszerűsíteni az zsugorítóst, ergo ott nem kell definiálni az EZ_EGY_REGI_PROCI makrót.

Köszönöm a figyelmetlenséget, belétek is bazdmeg. Továbbá bikacsököt bilgécnek és a kurwa anyját a mikrofosnak.


Prometheus  (statz) Főfasz
#3, Főfasz (1824)
208 | #2f12 | ^ | Idézet | Tue, 25 Nov 2014 15:37:08 +01
78.139.*.* winhate Mozilla Firefox Hungary *.business.broadband.hu
https://www.resistsurveillance.org/emergency

Kíváncsi vagyok, hogy erről mi a véleményetek. Az Amnesty International meg pár szervezet adta ki ezt a programot. Megnézi, hogy kémkednek-e nálad kormányszervek.


TCH  (statz) Főfasz
#1, Főfasz (10443)
1755 | #2f13 | ^ | Idézet | Tue, 25 Nov 2014 16:59:04 +01
46.139.*.* Linux x86 Opera Classic Hungary *.catv.pool.telekom.hu

XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
Hát perszeeee! Megnézi, hogy kémkednek-e nálam a kormányszervek! XDDDDDDDDDDDDDDDDDDDDDDDDDDD
Mégis honnan a fárasból tudná ez a program azt?!

Ez egy fasság. Három eset lehetséges:
 •  Ez egy szelep. Felrakod és kiírja, hogy tiszta vagy. Azért adják, hogy lecsillapítsák a tömeget, hogy megnyugodjon a hülyéje, hogy neeem, utánam asztán nem kémkednek, a Detekt (sic!) is megmonta!
 •  Ez tényleg arra való, amit írnak róla, viszont akkor szart se ér! Ahogy fentebb is kérdeztem, honnan a fárasból tudná ez a szar program, hogy van-e a gépeden valami?! Ezt két módon tudhatja: vagy ismeri az összes titkosszolgálat/kormány/mittudomén ilyen jellegű szoftvereit - ami lássuk be, bebaszna - vagy ez csak egy túljhájpolt backdoorkiller, azaz hátsóajtókat keres a gépeden, amit vagy megtalál, vagy nem, de leginkább nem, mert ő csak azt találja meg, amit ismer és csak azt ismerheti, ami már lebukott. Egyébként is, nem csak a kormányok/ügynökségek kémkedhetnek utánad, hanem a multik, meg a feketekalapos hackerek, meg a szkriptkiddie-k, meg még aki csak akar. Hatszáz tonna szekus cucc van ugyanezeknek a kiszűrésére-felszámolására, miféle létjogosultsága lenne ennek, miben lenne jobb?
 •  Ez maga a kémprogram. Nem ismerős valahonnan a szitu? Egy cseppet sem? Pedig tökig van a net olyan bannerekkel, hogy Scan your PC for free és társai, ahol a szerencsétlen júzer balfasz módon, sajátkezűleg feltelepíti a hátsóajtót/kémprogramot/botot/vírust/reklámgépet a gépére, mert elhitették vele, hogy ez majd jól megmongya, hogyaszongya, hogy nincse' vájrúszöe a gépömön!

Vagyis 2/3-ad esélye van annak, hogy kitörölheted vele és 1/3-ad esélye van annak, hogy ez maga egy kibaszott kémprogram.
Kerülje el mindenki, aki csak látja.


TCH  (statz) Főfasz
#1, Főfasz (10443)
86 | #2f14 | ^ | Idézet | Tue, 25 Nov 2014 23:40:37 +01
46.139.*.* Linux x86 Opera Classic Hungary *.catv.pool.telekom.hu
http://m.cdn.blog.hu/na/napigeek/image/11_10/rendszer_tuntetes.png

Ikszdé.


OrkenWhite  alias  "OrkenWhite az idióta" Főfasz
#5, Főfasz (1004)
876 | #2f15 | ^ | Idézet | Wed, 26 Nov 2014 14:26:08 +01
84.2.*.* Linux x86 Google Chrome Hungary *.dsl.pool.telekom.hu


@TCH:
Ez maga a kémprogram. Nem ismerős valahonnan a szitu? Egy cseppet sem? Pedig tökig van a net olyan bannerekkel, hogy "Scan your PC for free" és társai, ahol a szerencsétlen júzer balfasz módon, sajátkezűleg feltelepíti a hátsóajtót/kémprogramot/botot/vírust/reklámgépet a gépére, mert elhitették vele, hogy "ez majd jól megmongya, hogyaszongya, hogy nincse' vájrúszöe a gépömön!"

Csakhogy az egész program nyílt forráskódú, mellesleg egy elismert(offline) szervezet készítette.
De mivel a kormányok ismerni fogják a programot(nyílt forráskódú), ezért felkészíthetik rá a kémprogramjukat. A közösség viszont építhet új dolgokat a programba, amivel ismét megtalálja a kártevőt.


@TCH:
http://m.cdn.blog.hu/na/napigeek/image/11_10/rendszer_tuntetes.png
Ikszdé.



XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD






djpety  alias  "Pety" Lófasz
#6, Lófasz (953)
68 | #2f16 | ^ | Idézet | Thu, 27 Nov 2014 01:08:33 +01
81.182.*.* winnyogsz Google Chrome Hungary *.dsl.pool.telekom.hu
Napi fail: http://capture.pety.me/IMG_20141126_151832.jpg


Prometheus  (statz) Főfasz
#3, Főfasz (1824)
136 | #2f17 | ^ | Idézet | Thu, 27 Nov 2014 13:41:49 +01
78.139.*.* winhate Mozilla Firefox Hungary *.business.broadband.hu
Srácok, megtaláltam az Anti-TCH-t!:
http://444.hu/2014/11/26/a-skizofren-programozo-aki-10-even-at-irt-egy-operacios-rendszert-istennek/


TCH  (statz) Főfasz
#1, Főfasz (10443)
664 | #2f18 | ^ | Idézet | Thu, 27 Nov 2014 17:56:10 +01
46.139.*.* Linux x86 Opera Classic Hungary *.catv.pool.telekom.hu
@OrkenWhite:
Csakhogy az egész program nyílt forráskódú, mellesleg egy elismert(offline) szervezet készítette.
De mivel a kormányok ismerni fogják a programot(nyílt forráskódú), ezért felkészíthetik rá a kémprogramjukat. A közösség viszont építhet új dolgokat a programba, amivel ismét megtalálja a kártevőt.
Három lehetőséget vázoltam fel. Amit leírtál, nem zárja ki a kettes számú lehetőséget: a hasznavehetetlenséget, a létjogosulatlanságot.
@djpety:
Napi fail
Hát ez kurwa jó, felrakjuk! XDDDD
@Prometheus:
Srácok, megtaláltam az Anti-TCH-t!:
Ez mitől anti-én?


TCH  (statz) Főfasz
#1, Főfasz (10443)
750 | #2f19 | ^ | Idézet | Sat, 29 Nov 2014 13:44:42 +01
46.139.*.* Linux x86 Opera Classic Hungary *.catv.pool.telekom.hu
Újabb bizonyíték arra, hogy a gúgel a következő mikrofos.
Circa egy évtizeddel korábban a mikrofossal próbálta eljátszani ugyanezt a műsort az amcsi kúrmány, sikertelenül. És tartok tőle, hogy ez a kísérlet is sikertelnül fog végződni; hiába van igaza az EU-nak, az összes adu a kibaszott kugli kezében van, dettó mint tíz éve az USA igazságügyi minisztériuma és a mikrofos perében. Ha mégis tyúkszarba fulladna a kugli manővere, akkor még mindig lekenhetik a gyenge láncszemeket.

Én mindettől függetlenül drukkolok az EU-nak, hogy kétvállra fektesse ezt a tetves mammutot, mint ahogy tette korábban egyéb mammutok digitális diktatúrája (ACTA) esetében.


Prometheus  (statz) Főfasz
#3, Főfasz (1824)
161 | #2f1a | ^ | Idézet | Sat, 29 Nov 2014 16:30:36 +01
46.107.*.* winhate Mozilla Firefox Hungary *.catv.pool.telekom.hu
A Google és az Apple hatalommal rendelkezik.
A probléma ott kezdődik, ha a hatalom és a felelősség nem esik egybe.
Arról tudok, hogy pl. az Apple nem fizet adót.


TCH  (statz) Főfasz
#1, Főfasz (10443)
102 | #2f1b | ^ | Idézet | Sat, 29 Nov 2014 18:00:38 +01
46.139.*.* Linux x86 Opera Classic Hungary *.catv.pool.telekom.hu
Gaygle se.


TCH  (statz) Főfasz
#1, Főfasz (10443)
1937 | #2f1c | ^ | Idézet | Sat, 29 Nov 2014 21:08:13 +01
46.139.*.* Linux x86 Opera Classic Hungary *.catv.pool.telekom.hu
Tegyük fel, hogy be kell szúrnunk egy stream közepébe adatot. Beszúrás alatt azt értem, hogy nem felülírom ami útban van, hanem a beszúrt terület mögé mozgatom. Hogy lehet ezt csinálni? A memcpy() nem feltétlen jó, hiszen, ha a beszúrt terület vége nem lóg túl a stream eredeti végén, akkor a beszúrandó méret kisebb lesz, mint az a terület ami mögötte van, ennek megfelelően a copynál akkora overlap lesz, mint ide Irak és saját magára fog másolni, felülírván a hátralévő adatokat. A memmove() már jobb lenne, mert annek nem baj az overlap...csak éppen ez úgy működik, hogy előbb átmásolja egy átmeneti bufferbe, aztán copyzza be a végső helyére. Pazarlás Safranek. Hogyan lehetne ezt egyszeri memóriamásolással megoldani? Kurwa egyszerű, ha a sima memcpy() azért nem jó ide, mert overlap esetén felülírja a hátralévő adatokat, akkor fordított irányban kell copyzni! Viszont olyan memóriamásoló függvény, ami ezt csinálná, egyszerűen nincs! (Stringmásolóra vannak implementációk, de az nem jó, az byte-onként másol.)
Úgyhogy összedobtam egyet. Használlyátok egész seggel:
#ifndef _MEMCPY_BKW_C
#define _MEMCPY_BKW_C 1

#include <stdint.h>
#include <stdlib.h>

#if __WORDSIZE == 64
#define mask 7
#define shift 3
#define copytype int64_t
#endif

#if __WORDSIZE == 32
#define mask 3
#define shift 2
#define copytype int32_t
#endif

#if __WORDSIZE == 16
#define mask 1
#define shift 1
#define copytype int16_t
#endif

void memcpy_bkw(char *dst, char *src, size_t size)
{
	size_t mod;
	copytype *dstb;
	copytype *srcb;

	dstb = (copytype *)((copytype)dst + size);
	srcb = (copytype *)((copytype)src + size);
	mod = size & mask;
	size >>= shift;
	while (size--)
	{
		*dstb-- = *srcb--;
	}
	while (mod--)
	{
		*dst-- = *src--;
	}
}

#endif


kemi  (statz) Főfasz
#2, Főfasz (2970)
302 | #2f1d | ^ | Idézet | Sun, 30 Nov 2014 09:48:44 +01
78.131.*.* Ubuntu x86 Mozilla Firefox Hungary *.pool.digikabel.hu
Használt már valaki Bluetooth fülest pécén? Egy darabig működik, aztán elkezd szakadozni a hang, és tuti, hogy nem az akkuval van a baj, mert most töltöttem. Az adatátviteli sebességről meg annyi, hogy USB 3.0-s portba van dugva, Bluetooth 4.0-t támogató adapter, a füles meg elvileg 2.0-s. Driver baj?


TCH  (statz) Főfasz
#1, Főfasz (10443)
1152 | #2f1e | ^ | Idézet | Sun, 30 Nov 2014 12:03:29 +01
46.139.*.* Linux x86 Opera Classic Hungary *.catv.pool.telekom.hu
@kemi:
Driver baj?
Az is lehet, de inkább PulseAudio-nak tűnik. Következő lépéseket kéne megnézni:
 •  Kipróbálod winfos alatt. Ha semmi baja sincs, akkor a probléma a Linuxban keresendő, ha van, akkor a hardware-ben.
 •  Ha van nálad PulseAudio, akkor töröld le a fárasba, úgysem jó semmire, használd natívan az ALSA-t, a PA csak egy felesleges réteg az ALSA felett.
 •  Ha PulseAudio nélkül sem megy, akkor próbáld meg azt, hogy amikor elkezd rakoncátlankodni, akkor lelövöd az alkalmazást és utána újra elkezdesz lejátszatni vele. Ha működik, akkor válts lejátszót és keress egy olyat, ami nem szarja össze a buffert.
 •  Ha nem megy, akkor próbáld meg kihúzni és visszadugni, amikor szarakodni kezd. Ha működik, akkor driverhiba lesz, mert újrainicializáláskor jó. Cserélj drivert újabbra vagy épp régibbre.
 •  Ha nem megy, akkor vagy ALSA bug, vagy a jóég tudja, hogy mi...esetleg a probléma nem is nálad van, hanem van valakinek a környéken valami cucca, ami időnként bezavar az adatforgalmadba. Esetleg nincs is softwarebaj, csak configbaj, rosszul van beállítva a buffermértet, vagy valami egyéb... Tuggya a tököm.


TCH  (statz) Főfasz
#1, Főfasz (10443)
3542 | #2f1f | ^ | Idézet | Sun, 30 Nov 2014 18:57:40 +01
46.139.*.* Linux x86 Opera Classic Hungary *.catv.pool.telekom.hu
Most húztam le a slozin a GCC-t egyszer s mindenkor! Én ilyet még életemben nem basztam, amit ma ez a hulladék lószar produkált! Most dolgozom egy PNG => IFF konverteren és van nekem egy struct-om, ami így néz ki:
struct png_struct
{
	s32 width;
	s32 height;
	u8 bit_depth;
	u8 color_type;
	u8 compression_method;
	u8 filter_method;
	u8 interlace_method;
	u32 palette[256];
	size_t image_size;
	char *image;
};
És tartozik hozzá egy függvény:
open_png(char *src, png p, bool calc_crc)
Működött is a beolvasás, dekódolás, kitömörítés... Viszont ma eszembe jutott, hogy mi van, ha csak a header-t akarom parse-lni? Módosult a két cucc:
struct png_struct
{
	s32 width;
	s32 height;
	u8 bit_depth;
	u8 color_type;
	u8 compression_method;
	u8 filter_method;
	u8 interlace_method;
	u32 palette[256];
	bool data_loaded;
	size_t image_size;
	char *image;
};
open_png(char *src, png p, bool calc_crc, bool only_parse_header)
Eredmény? Segmentation fault. WTF?! És utána rájöttem, hogy akármit változtatok a struct-on, segfault az eredmény! Kishíján összeszartam magam, hát ilyet még az életben nem pipáltam! Utána kidebuggoltam, hogy a segfaultot ez a sor okozza:
p->image = realloc(p->image, new_size);
Mégpedig azért, mert az image valahogy nem NULL értékkel bírt, holott annál a sornál annak kéne lennie! Elkezdtem kidebuggolni, hogy hol változik meg és végül rájöttem, hogy ennél a sornál:
data = realloc(data, chunk_length + 4);
Előtte NULL a p->image, utána pedig 1024! DAFUQ?! Senki nem nyúl hozzá, se közel, se távol! Mi a fasz?! Mi az eres, retkes faszom ez?! Valami GCC bug?! CLANG fel. Compile. És működik bazdmeg. ÉS MŰKÖDIK BAZDMEG!!! IGEN, EZ EGY KIBASZOTT GCC BUG!!! Hát én ilyet még életemben nem pipáltam, hogy egy realloc egy totál másik pointert szétcsesszen és mindezt egy a kód által nem érintett struct megváltoztatása miatt! 4.6-os és 4.7-es GCC is dettó ugyanezt produkálja, 4.8-at meg nem lehet feltenni Debian 7-re csak úgy, hiába kerestem, mindenütt azt válaszolták a hogy lehet 4.8-at rakni Wheezy-re jellegű kérdésekre, hogy az nem jó ötlet, meg minek neked az. Minek nekem az?! Annak, hogy az előzőek bugosak! (Bár ki tudja, lehet, hogy az utána lévők is!) Nem lehet felrakni?! Ok! Akkor GCC => slozi!
root@Csabi:~# cd /usr/bin
root@Csabi:/usr/bin# unlink gcc
root@Csabi:/usr/bin# unlink g++
root@Csabi:/usr/bin# unlink cpp
root@Csabi:/usr/bin# ln -s clang gcc
root@Csabi:/usr/bin# ln -s clang g++
root@Csabi:/usr/bin# ln -s clang cpp
Good riddance!

Ne használjatok GCC-t, mert SZAR!

Sz*rk: A CLANG-gal bezzeg nincs olyan baj, hogy hogy rakom fel a legújabbat Debian 7-re! http://llvm.org/apt/

Sz*rk #2: Közben egyébként rájöttem, hogy mi okozta (a data változó nem volt NULL), de hogy ez MIÉRT okozta, amit okozott, miért baszik el egy teljesen másik pointert, egy a kód által nem érintett struct-ban és hogy akkor miért ment ez CLANG-ban...
Egyébként -O2 vagy -O3 kapcsolónál a CLANG is elszállt, de az ott és azért szállt el, ahol és amiért elbasztam, nem baszott szét teljesen véletlenszerűen valami egészen mást! Ezért is bírtam rájönni, hogy mi a franc van. Most már megy GCC-ben is, de most már akkor is a CLANG mellett maradok; ha elbaszok valamit, akkor az legyen elbaszva, amit elbasztam és ne totál más!


English | Magyar
JS ki | CSS ki | Ékezetek ki | HiContrast
Lapozó:  (0 - 1424) 
<== | ==>
Ugrás a végére | Összes megjelenítése | Utolsó oldal
OpenOpera patches | Opera-SSL patches | Opera 12.15 source (Git repository) | Opera 12.15 source (Torrent) | Opera internal pages | Otter Browser Linux x64 - Qt5.15.2/QtWebKit5.602.1 (2024.04.27. 20:05)
OS for MC680x0 | OS for PPC | OS for Sparc64 | besztofbégéaefcé | CSÉNDZSLOG | WebToolz | DDG Shit Filter | Google Shit Filter | Progz | Fast CSS Box | Browser | OS | Agent | Statisztika | BBCode
Monospace font-family: Courier New | Browser default monospace
Email értesítő / Email notification ===> 
Keresés

Név: (max 255 byte)

Email: (max 255 byte) Nem kötelező!

Üzenet: (max 65536 kar.) 65536-0=65536




crap_vkn v4.34.0 by TCH
Thx to saxus for the escaped string decoder function (PHP), the realIP function (PHP) & the SQL handle layer (PHP), to thookerov for the int_divide function (PHP), to Jeff Anderson for the getSelText function (JS), to Alex King for the insertAtCursor function (JS), Flood3r for the new CSS styles, Pety for the spamprotection idea and some design and comfort ideas, MaxMind for the IP2Country database, famfamfam for the flags of countries and an unknown PHP programmer for the removeAccents function.



Kecskebaszók ide!