Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - BoneFlute

Stran: 1 ... 57 58 [59] 60 61 ... 133
871
Ahoj.

Mám Fedoru 27, a aplikaci Gnome Soubory (Nautilus). Kde je defaultní chování, že když dám začnu psát, tak mi to začne vyhledávat a filtrovat. Celkově spokojenost, ale chtěl bych trochu jiné chování.

Aby to hledalo jen v aktuálním adresáři a nikoliv v podadresářích.
Případně, aby mě to hodilo na patřičný soubor či adresář.

Zkoušel jsem volby a klávesové zkratky ale na nic jsem nearazil. Snad jsem jen něco přehlédl.

Díky za pomoc.

872
O serveru Root.cz / Re:Zrizeni nemoderovane sekce na Root.cz
« kdy: 04. 02. 2019, 00:09:09 »
Diskuse na Rootu nebyly zrušeny, jen teď budeme striktně vyžadovat, aby byly vedeny slušně, s úctou a k tématu.

Pokud chcete diskutovat o čemkoliv volně, máte spoustu možností. Můžete třeba založit skupinu na Redditu nebo kdekoliv jinde. Sem ale volné povídání na libovolné téma nepatří, chceme se v diskusích držet tématu.

A proc to zde nepatri? Proc by zde nemohla byt sekce na volne povidani? Jake je oduvodneni?

A proc na Redditu, kdyz to neni ani cesky server. To prece neni reseni.

Už tu několikrát bylo vlákno na celkem zajímavé téma. Mělo 60, i 80 stránek. A našel jsem tam dvě užitečné informace. Nejen, že mě to naučilo nereagovat na trolly, ale dokonce už omezuju návštěvu.

873
Vývoj / Re:Co si myslíte o OOP?
« kdy: 25. 01. 2019, 07:59:29 »
V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)
Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.
Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.

pouziva to chtej nechtej kazdy:
Zas nepřeháněj. Možná někdo někdy.

874
Odkladiště / Re:Trestné činnosti s IS
« kdy: 24. 01. 2019, 23:39:56 »
Obávám se, že vaši teorii o domácím úkolu musím vyvrátit.
Jedná se o okruhy ke zkoušce, kterým úplně také nerozumím...
Takže to zkusím jinak...
Mohou být trestné činy související s IS následující: CSRF (například poslání transakce útočníkovi), MITB, phising, různé zneužití chyby u serveru, což způsobí škodu? Lze toto požadovat za trestné činy souvísející s IS nebo ne?

Já teda nejsem právník, takže to co píšu jsou pouhopouhé spekulace.

Právo se od IT liší tím, že v právu je definováno zákonem, co je trestný čin, čistě z autority zákonodárce.

Takže zda je CSRF či MITB či Phising trestným činem záleží na tom, zda o tom ten zákon hovoří. (Což netuším.) Ale mám pocit, že jsem někde četl, že odsoudily nějakého člověka za nějaký ten útok na základě toho, že vyčíslili škodu, která oběti vznikla.

Takže, kolega si nechal odemčený počítač a šel na oběd. Já k tomu sedl, zkouknul, co tam má, a následně mě dotyčný kolega zažaloval za morální ublížení, že jsem se mu bez dovolení koukal na soukromé fotky. Blbost, ale pro ilustraci.

875
Vývoj / Re:Co si myslíte o OOP?
« kdy: 24. 01. 2019, 20:54:20 »
Pokud mas teda jazyk postavenej na neuplny implementaci tridy pak je ten jazyk deravej v abstrakcich. Zapomen na to jestli jsem neco tvrdil o deravych tridach protoze jsme se nikdy neshodli na tom jestli se bavime o implementaci nebo koncepci. Tridu jako abstrakci muzu implementovat pouhym dictem metod a seznamem jak jsem zminil. Tvrdim akorat ze cukr je deravy a tvrdim ze vzdy.
O tridach a objektech tvrdim ze existuje jednodussi mechanismus na kterym zalozit bazi jazyka - napr. prototypy. Clovek pak v implementaci nemusi resit rozdil mezi objektem a tridou, pouze mezi built-in a derivovanym objektem.

Hele, a ono to v tom Pythonu vadí? V čem vadí, že ten cukr je děravý? Někdo ti brání vytvořit si vlastní řešení nějakého vzoru pro Python? Třeba takové Mixiny můžeš udělat celkem v pohodě, a nepotřebuješ žádnou dědičnost. Ale možná mi unikla ta tvá pointa.

Taky bych rozlišoval věci, kdy Python ti nabízí jen základní konstrukce pro vytvoření programu (+ ten tebou zavrhovaný cukr). Úplně něco jiného jsou pak vlastnosti jazyka, které schválně omezují vývojáře. Protože takové omezení může být z různých důvodů přidaná hodnota. Myslíš si, že skutečnost, že Python má syntaktický cukr pro vytvoření objektu (přestože je to jen zabalenej dict) nějak škodí? V čem?

876
Vývoj / Re:Co si myslíte o OOP?
« kdy: 24. 01. 2019, 20:46:37 »
Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.
Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:

(T2) zadaní se vždycky změní, nejpozději do půl roku

a třetím:

(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí

čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):

(OTOOOP) Cokoliv může [v čase analýzy]  dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.

:)
Ještě je třeba myslet na další pravidlo :
(T4) Změna zadání rozbordelí jakýkoliv návrh provedený podle jakéhokoliv paradigmatu.

Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit. Když to bude nepřehledé už od začátku, tak už to žádná změna nemůže zhoršit. 8)
Mě teda přijde, ale možná z toho ještě vyrostu, že na něco takového je dobrej kompromis funkcionální programování. Napsat funkci umí každej. Nejde to moc zvrtat. Kruhový závislosti jsem tam taky nějak moc neviděl. A když vznikne nějaký patvar, nebo se posune zadání, tak se prostě staré funkce nechají vyhnít. Zatím my přišlo, že se to dá snáz ukočírovat.

877
Vývoj / Re:Co si myslíte o OOP?
« kdy: 24. 01. 2019, 20:43:36 »
Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.
A proto je to nejčastější způsob! ;)

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.
A úplně ideálně ani třídy ne :)
Třída je typ.
V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)

878
Vývoj / Re:Co si myslíte o OOP?
« kdy: 24. 01. 2019, 00:53:26 »
Metoda se staticky typovanym atributen tedy NEMUZE dostat nekorektni data ve smyslu, ze to neni objekt HttpRequest.

Je rozdíl mezi tím, když se s dotyčným objektem domluvíš na určitých podmínkách, a mezi tím, když se domluvíš na všech (Haskell) a na ničem (Python).

Aktory jsou mezi sebou (často fyzicky) nezávislí. Ty můžeš tomu objektu poslat zprávu, která bude zcela korektní, ale v tom danném okamžiku (0:52hodin) prostě ten aktor tu zprávu nezná. Ale třeba od od 4:00 už jo.

Je pak otázka, co znamená to "nezná". Proč, a jak se to projevuje.

879
Vývoj / Re:Co si myslíte o OOP?
« kdy: 23. 01. 2019, 20:58:57 »
Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.
Plus započítej implementaci, která se prostě nepovedla. A díky tomu máme objektově orientované programování (místo objektového programování) :-)

880
Vývoj / Re:Co si myslíte o OOP?
« kdy: 23. 01. 2019, 15:29:20 »
proto chapu, ze nekteri Haskell opevuji, kdyz maji pracovat treba s Indy.

Kdyby jen s Indy.

881
Vývoj / Re:Co si myslíte o OOP?
« kdy: 23. 01. 2019, 13:33:51 »
v mém scénáři začnu se strukturovaným AST (podmínky + cykly, fakt strom) a přeložím ho na seznam příkazů se skokama (tohle jsem měl původně na mysli, když jsem psal AST) a tady už jsou cykly kdy se příkaz skoku odkazuje na jiný příkaz ve stejném seznamu

To bude ono. Já tam žádné skoky ani cykly neměl.
Díky.

882
Vývoj / Re:Co si myslíte o OOP?
« kdy: 23. 01. 2019, 03:39:36 »
S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

to v Pythonu nejde. To si asi pleteš s Javascriptem.
Ty jo, zaváhal jsem, ale:
Kód: [Vybrat]

class A:
pass

class B (A):
def boo(self):
return 'B'

def goo(self):
return 'C'

b = B()
print(dir(b))
A.goo = goo
print(dir(b))
print b.goo
print b.goo()

883
Vývoj / Re:Co si myslíte o OOP?
« kdy: 22. 01. 2019, 16:17:46 »
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?

Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.

Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.

[dict1, dict2, dict3]

ekvivalentni

class C: pass
class B(C): pass
class A(B): pass

kde A odpovida dict1, B dict2, C dict3

Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.

javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník. S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

884
Vývoj / Re:Co si myslíte o OOP?
« kdy: 21. 01. 2019, 18:54:16 »
já se s nima potkávám u AST (tam právě zkouším alga a jinde zase "závislostní vektor" - k vynucení konzistence) a interpretrech (knot tying, vážně velká sranda, vemu seznam instrukcí a složím je do jedné IO akce, v místě skoku na jiné místo programu uvážu uzlík)

Mohl by si se více rozepsat. Shodou okolností jsem zrovna nějaké to ASTčko nedávno dělal. A na žádný cyklický graf jsem nenarazil. Vždy jsem si vystačil se stromem. Buď jsem tak šikovnej (nepravděpodobné), nebo jsem se jen náhodou vyhnul nějakému scénáři... Předem dík.

885
Vývoj / Re:Co si myslíte o OOP?
« kdy: 21. 01. 2019, 18:19:43 »
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Mohl by si sem hodit nějaký scénář, kdy se cyklická datová struktura hodí? Pro představu.

Stran: 1 ... 57 58 [59] 60 61 ... 133