programerska paradigma - WTF?

asynchronous and event driven programming paradigm - kaj za vraga je paradigma pri programiranju, v kontekstu AMPS frameworka?
AMPS = Asynchronous Middleware for Protocol Servers

Ne vem, kako naj si to razlagam, moram pa vedeti zaradi diplomske naloge.

AMPS...
...Provides extensive support for asynchronous and event driven programming
paradigm specifically tailored for writing protocol servers for networking and
telecommunication domains.

Če pomaga - AMPS je programersko okolje (ogrodje), namenjeno pisanju sintakse delovanja HSS (Home Subscriber Server).

Hvala, bo kar prava beseda za nadaljevanje. (Prevajam iz strokovnega PDF-ja.)

asinhron gotov ni slovnesk če si purist, mogoče "časovno nusklajen" al pa podomače nenataknje. dej probi andeja bauerja nadlegvat on se mal stemi sferami že encajt ukvarja pri nas pa bi znu bit brihtn.

aja pol pa ni panike sej ti bo mentor navrgu

druzga ni kt brskanje po narejenih diplomah. strokovnjak za prevode pa tudi nisi. tako , da se ne sekiraj. dej omejit iskanje na googletu po pdfjih pa ključne besede not matrej pol pa če najdeš kaj podobnega kul , čene pa pusti. ker včasih marketing nabluzi svoje , mi svoje teoretiki tretje. predstavlej si cilno publiko tudi v končni fazi.

slitkx je 21. feb 2011 ob 21:20 izjavil:

Pa še tole... => 'asynchronous and event driven programming paradigm'

Glede na to, da je pojem 'paradigm' zgoraj že pojasnjen, je pravilen prevod 'asinhrono in dogodkovno obravnavan programerski pristop'?

Neusklajen in dogodkovno naravnan programerski pristop

Ok, neusklajen je mogoče iskanje dlake v jajcu (v raznih slo knjigah se synchronizing prevaja kot usklajevanje), ampak 'driven' pomeni gnan, kar se sliši čudno itak - je pa naravnan boljši nadomestek za gnan kot obravnavan.

morbo je 21. feb 2011 ob 22:25 izjavil:

slitkx je 21. feb 2011 ob 21:20 izjavil:

Pa še tole... => 'asynchronous and event driven programming paradigm'

Glede na to, da je pojem 'paradigm' zgoraj že pojasnjen, je pravilen prevod 'asinhrono in dogodkovno obravnavan programerski pristop'?

Neusklajen in dogodkovno naravnan programerski pristop

Ok, neusklajen je mogoče iskanje dlake v jajcu (v raznih slo knjigah se synchronizing prevaja kot usklajevanje), ampak 'driven' pomeni gnan, kar se sliši čudno itak - je pa naravnan boljši nadomestek za gnan kot obravnavan.

dobr sem pijan sam tisto kar je on napisal razumem tole pa ne.

Diameter Base Protocol Stack => Je ok prevod 'na DIAMETRU baziran protokolni sklad'? (DIAMETER je protokol v IMS arhitekturi.)

Hja, samo 'base' je tudi 'baza', iz česar sem izhajal. Bom vseeno pogledal, če se da tvoj predlog spraviti v tekst.

Če uporabim 'osnovni', potlej bi bil prevod 'osnovni protokolni sklad DIAMETRA' oz. 'osnovni protokolni sklad protokola DIAMETER', kar je pa nesmiselno, saj je sklad samo en.

Ne, je pravilno prepisano. Link: http://advancedims.com/Docomentation/HS...

3. poglavje, stran 1.

AMPS framework is implemented as a shared library, and lies at the bottom of the architecture.
The diameter base protocol stack has been implemented as a shared library, and lies on top of
AMPS. The communication between Diameter Base Protocol stack and AMPS is through direct
function calls and through callback functions.

stack je lahko tudi nabor ali skupek v tem primeru , ko gre za skupek protokolov. sklad namiguje bolj na hierarhično zaporedje nabor ali skupek pa ne nenujno odvisne protokole. ampak tukaj gre že za lingo kulinariko.

Protocol stack je sklad (nabor) protokolov in ne protokolni sklad.

Torej je potlej 'Diameter Base Protocol Stack' = 'osnovni nabor Diameter protokolov'? (Kar mi ne zveni logično, ker je Diameter sam po sebi hkrati protokol in sklad (prebral v drugi literaturi).

Stack = sklad

Menim, da sem našel dober prevod. => 'sklad osrednjega protokola DIAMETER'
Izhajam iz tega, da je v IMS okolju DIAMETER najpomembnejši ('base') protokol, brez katerega bi bil IMS mrtva platforma.
Bom pa vseeno pri navedbah kratic (poglavje posebej) navedel tudi originalni angleški izraz.

DIAMETER je protokol. Glede na http://www.javvin.com/protocol/rfc3588.... pa je bolj videti, da je Diameter Base Protocol polno ime, DIAMETER/Diameter pa njegovo krajše poimenovanje.

Saj zdajle z Diametrom nimam prvič opravka, v diplomi sem o njem že pisal, pa tudi zanj še pride posebej poglavje (primerjava s predhodnikom Radiusom).

Kar se pa tiče sklada, pa dejansko obstaja tudi protokolu istoimenski sklad. Pač poimenovan po protokolu.

X preda Y v upravljanje AMPS framework-u (?), ki s programsko logiko na osnovi dogodkov nadzoruje nadaljno izvajanje kode .

Asinhronost lahko pomeni marsikaj. Pri clock generatorju pomeni to, da vodila ne rabijo biti časovno 'usklajena' med seboj.
Včasih se je to reševalo z delilniki in množilniki.

Počasi, počasi... Vidim, da moramo začeti na začetku. Pred dnevi sem se namenoma izognil komentiranju vpisov iz začetka te teme, ker se mi niti ni dalo pametovat, niti se mi ni dalo tipkat...

asynchronous and event driven programming paradigm
asynchronous = HSS je software (oz. vsaj ta dokument, katerega prevaja pixel, je specifikacija HSS-jevega softwera). Kot programer point besede asynchronous vidim v tem, da se nekaj izvaja ločeno oz. "neblokirajoče". Pri računalniškem programiranju namreč asynchronous pomeni, da glavna nit programa teče naprej in ne čaka, da bo tisti del programske kode, ki je bil izveden asinhrono, zaključil svoje delovanje in vrnil kontrolo nad izvajanjem nazaj glavni niti. Asihrona koda ustvari "vzporeden tir" in se izvaja ločeno na njem.
Normalno se vrstice programske kode in ukazi izvajajo zaporedno. Najprej prvi, ko ta konča, se začne izvajati drugi, nato tretji... Če eden od njih za svoje izvajanje porabi velko časa, program vmes stoji zamrznjen (ne dela nič) vse dokler počasnež ne konča in mu "vrne kontrolo". Šele nato se izvede nov ukaz. Pri asinhroni kodi pa glavna nit samo ukaže, naj se koda izvede, in takoj nadaljuje z naslednjim svojim ukazom. Torej se v naslednjem trenutku izvajata nova vrstica iz glavne niti, ter hkrati prva iz asinhrone.
Prevod "časovno neusklajen" morda drži za signal in komunikacije, no res pa je, da če zzeeellllooo nategnemo pomen te fraze, bi lahko rekli, da bi bil to ustrezen izraz tudi za software. Namreč, ker se asinhrona koda izvaja ločeno, ne vemo, kdaj je pri svojem izvajanju prišla do vrstice, v kateri se nastavi npr. i = 0. Zato se v glavni kodi nikoli ne smemo zanašati, da je i res 0, ker mogoče asinhrona koda do tam še ni prišla... V tem pogledu sta (tudi) časovno neusklajeni. Vendar je to zgolj stranski efekt, ne pa glavni namen.

event driven programming = Programska koda, sama od sebe, ne dela nič. Ko se zgodi nek dogodek programska koda odreagira. Npr. uporabnik se prijavi v HSS sistem in takrat se sproži funkcija onUserLogin().
Koda, katera ni event driven, dela po zaporedju, kot ga je napisal programer: A -> B -> C -> D... Če pa je event driven, je njeno zaporedje odvisno od dogodkov. Če najprej pride dogodek C se bo najprej izvedlo onC, potem spet nič, pride dogodek A in se izvede onA, itn.

event based logic = programska koda (ponavadi procedura/funkcija), katera je odvisna od dogodka... Če se je sprožil dogodek login, se izvede onLogin(); Če bi se sprožil hočemFilm, bi se izvedla showMovie()...

drive subsequent code execution = čeprav je subsequent v bistvu naslednji, beri to kot sledečo. Torej kodo, ki sledi (izhaja iz) iz dogodka.

slitkx je 24. feb 2011 ob 19:46 izjavil:

Zaključek: Diameter Base Protocol Stack = osnovni sklad protokola DIAMETER (osnovni zato, ker ga je možno razširiti; extensions...)

Ne! Tvoj prevod in njegova razlaga (osnovni sklad... osnovni zato, ker ga je možno razširiti) pomen ravno obrneta. Diameter Base Protocol Stack je vedno enak in to je njegova najlepša in najbolj uporabna lastnost. Nadgradijo se objekti (v našem primeru protokoli, izpeljanke iz Diameter Base Protocol), katere ta stack sprejema. Vsi od njih MORAJO imeti isto osnovo, na enak dogodek pa lahko različne nadgradnje odreagirajo drugače (glej zgoraj moj izmišljen primer s plačljivimi in brezplačnimi filmi). Prav to, da je stack vedno enak in da je delovanje nadgradenj lahko poljubno, je osnova za to, da je (ugibam) možno HSS zelo preprosto nadgraditi in prilagoditi željam uporabnika/ponudnika.

"Diameter Base Protocol Stack" nimaš kej prevajat. Če je Boeing naredil letalo Dreamliner, je to pač Dreamliner in ne nek "Sanjski linijec". Tako se pač imenuje in pika. Huh, primer... "Windows GDI" (Graphics Device Interface) je knjižnjica, katera skrbi za izris grafike na zaslon in so jo tako poimenovali v MS. Tekst "Za izris teksta na zaslon poskrbi Windows GDI" prevajaš v "Za izris teksta na zaslon poskrbi vmestnik okenske grafične naprave".

Če mene vprašaš (dokumenta še vedno nisem bral), je "Diameter Base Protocol Stack" ena navadna knjižnjica. Če HSS teče na Windowsih, potem gre verjetno za kak *.dll file. Verjetno "DiameterBaseProtocolStack.dll" ali "dbps.dll". Ima neko standardizirano osnovo, potem pa se mu definira/dodaja dogodke in funkcije, katere vsebujejo "reakcijo" na definiran dogodek: DiameterBaseProtocolStack.register('login', 'simobilovOnLogin()'), DiameterBaseProtocolStack.register('tegadogodkanivspecifikaciji', 'simobilNašaNovaFunkcija()'); Tako si to jaz predstavljam.

Kar se tiče prevodov, ti svetujem, da preštudiraš svoj PDF in potem napišeš obnovo, prosti spis :), v slovenščini. Upam stavit, da boš naredil manj napak in ob tem še izgubil manj živcev...

Ok, še eno pripombo moram dati (preden kdo skoči v zrak)... Razlago asinhrone kode sem poenostavil do te mere, da sem mogoče že malce zavajajoč. Boljši primer asinhronosti je spodaj, čeprav sem prepričan, da se funkcija onUserLogin() v resnici izvede tudi v svoji niti (da omogoča hkratno komunikacijo z velikim številom uporabnikov):

dogodek: nov user
	-> funkcija onUserLogin() {
		izriše okno za vnos gesla
	   }  (zaključi svoje izvajanje)

... HSS teče naprej...

dogodek: user je vnesel password
	-> funkcija onUserPasswordRecieved() {
		preveri, če je password ok
		...
	   }
...

Če pa koda ne bi bila asinhrona, bi izgledalo takole:

dogodek: nov user
	-> funkcija onUserLogin() {
		izriše okno za vnos gesla
		... HSS je "zamrznjen" ...
		... čakamo, da uporabnik vnese geslo...
		... HSS še vedno ne dela nič ...
		... uporabnik vnese geslo ...
		preveri, če je password ok
		...
	   }  (zaključi svoje izvajanje)

... HSS teče naprej...

Ok, lej... Tole ne leti nate osebno in je čist moje osebno mnenje. Ampak jaz enostavno že kako desetletje ali še več ne berem več nobenih tehničnih dokumentov, ker so (večinoma) vsi po vrsti nerazumljivi. Jaz mislim, da varuhi slovenskega jezika delajo ogromno škodo našemu narodu, ker silijo slovenske prevode v vsak drek. Ti prevodi so včasih ne samo leseni, ampak tudi napačni (najin primer stacka, ko si s prevodom obrnil njegov pomen, je dober primer; enako moj vzorčni prevod GDI-ja) je enostavno preprosteje, da uporabljam angleške dokumente. In potem nam, tudi zaradi tega, raste generacija (imam doma primer 13-letnika), ki praktično ne zna več govoriti slovensko. TV menu je v EN, na novem računalniku je bilo po treh dneh treba namestiti EN winse, pri kosilu pa se pogovor neprestano "seka" z vprašanji "Kaj pomeni to-pa-to?"

Če se bo tvoj mentor poglobil v tvoje prevode, jih bo zavrnil. Jaz bi ti diplomsko raztrgal in začni znova. :) To je meni naredil profesor še v srednji šoli in ti povem, da sem mu 25 let kasneje zato hvaležen. :) Šlo je za seminarsko o našem sončnem sistema (planeti in ti) in sem jo prevajal iz ene tuje knjige, besedo za besedo. Od takrat naprej vedno delam tako, da stvar preberem/razumem in napišem prosti prevod (v bistvu povzetek).

Npr., tudi angleške kratice mooram raztolmačiti in jih v besedilu omeniti v slovenščini, angleško kratico za slovenski prevod pa navesti v oklepaju. (Le prvič, ko se kratica pojavi, kasneje uporabljam samo kratico.)

Tako da, če bi imel namesto 'Diameter Base Protocol Stack' že v izvoru kratico 'DBPS', bi jo moral raztolmačiti in prevesti v slovenščino. Takle pač imam...

Ne vem, žal ni v moji pristojnosti, da bi o tem odločal.
V ločenem poglavju, kjer bodo še enkrat navedene vse uporabljene kratice, bodo zraven njihovi slovenski prevodi. Na srečo obstajata slovar informatike ter LTFE slovar, ki mi zelo olajšata delo. A tale DBPS je pa primer (zelo)redko uporabljene sestavljene fraze, zaradi česar je pravilen prevod v kontekstu težji.

asynchronous = HSS je software (oz. vsaj ta dokument, katerega prevaja pixel, je specifikacija HSS-jevega softwera). Kot programer point besede asynchronous vidim v tem, da se nekaj izvaja ločeno oz. "neblokirajoče". Pri računalniškem programiranju namreč asynchronous pomeni, da glavna nit programa teče naprej in ne čaka, da bo tisti del programske kode, ki je bil izveden asinhrono, zaključil svoje delovanje in vrnil kontrolo nad izvajanjem nazaj glavni niti. Asihrona koda ustvari "vzporeden tir" in se izvaja ločeno na njem.
Normalno se vrstice programske kode in ukazi izvajajo zaporedno. Najprej prvi, ko ta konča, se začne izvajati drugi, nato tretji... Če eden od njih za svoje izvajanje porabi velko časa, program vmes stoji zamrznjen (ne dela nič) vse dokler počasnež ne konča in mu "vrne kontrolo". Šele nato se izvede nov ukaz. Pri asinhroni kodi pa glavna nit samo ukaže, naj se koda izvede, in takoj nadaljuje z naslednjim svojim ukazom. Torej se v naslednjem trenutku izvajata nova vrstica iz glavne niti, ter hkrati prva iz asinhrone.
Prevod "časovno neusklajen" morda drži za signal in komunikacije, no res pa je, da če zzeeellllooo nategnemo pomen te fraze, bi lahko rekli, da bi bil to ustrezen izraz tudi za software. Namreč, ker se asinhrona koda izvaja ločeno, ne vemo, kdaj je pri svojem izvajanju prišla do vrstice, v kateri se nastavi npr. i = 0. Zato se v glavni kodi nikoli ne smemo zanašati, da je i res 0, ker mogoče asinhrona koda do tam še ni prišla... V tem pogledu sta (tudi) časovno neusklajeni. Vendar je to zgolj stranski efekt, ne pa glavni namen.

lahko bi bilo tudi časovno neodvisen.
mislim , pa da gre za message passing , kjer ni potrebe po časovni soslednosti. o tehničnih izvedbah asinhronega izvajanje kode pa tu nebi, sploh pa vglavnem opisuješ paralelizem.