This is a strange one. I feel that I should use the Esperanto language for creating the terms in Dust. The reasons are the following.
Internationalization
Information systems are theoretically global. A person is a person, a chair is a chair, a calendar is a calendar everywhere on the Earth, at least on declaration level. Of course, we put different holidays into the calendar in Hungary and China, we write texts in different languages, and we want to see the user interface or the notification messages from our calendar in our chosen language - but the types and the business logic is the same.
However, in general we use English language to write source codes and comments - that is: we declare the elements in a natural language that we assume the other programmers will understand. So, in fact our systems are English by default, and then translated to other natural languages. However, the terms of our task domain should not be English, that is another "implementation", not the abstract definition. Luckily enough, we have an artificial language with the simplest possible (artificial) grammar, and a full word set for daily and scientific use. Luckily enough: I myself don't know Esperanto! so I will have an immediate need of anything I do to be translated to English, which I, and my fellow programmers can understand. It is a fundamental design decision of mine to separate identifiers from text information, where identifiers are hidden, programmatic information that can never get out of the system to the user, only through a translator - but now this will be an inevitable requirement because I (and my colleagues) would not understand the user interface or logs, if it is not translated to a language we know.
Esoteric
The esoteric reason behind the decision is that with Dust I start to create a parallel world. For the first time of course, I create the meta-meta layer: the definitions of "Type", "Aspect", "Entity", etc.; instances of these types will contain "themselves": the Type, Aspect, Entity, ... type definitions. Then other type definitions come which describe a Person, a Chair, etc. and then instances of persons, chairs, etc. So finally I will have an information system that can represent entities and relations in the external world. So far there is nothing new, all software does the same, yet the programmers don't think about it, and uses the constructs of the programming language for the meta layers and start with practical types. But here I talk about a system where for declarations I don't use a programming language construct, but an independent, external utility.
The structure of that knowledge, the meaning of the terms are the "words", the types: a "Person" is a structure of information that we have described in the Person type. Not a human perception of a Person, but an informatic representation of a person. A natural language word represents a human understanding - the artificial language word represents a type definition. A human knowledge can, and has to be simplified and organized to what the actual type definition can hold; and a human perception can be built by a human brain after browsing complex information networks available in the information system. I also think that all system knowledge can be translated to syntactically valid sentences; but to understand (parse) sentences, it is a fundamental need that the generation rules are clean, simple and obvious.
I accept Noam Chomsky's sentence that Esperanto is not a language. A natural language expresses and also affects the unique structure and complexity of the human brain, with all parallelism, analogies, different meanings, the very nature of human existence. This must be transformed when dealing with mathematics, natural sciences or computers to an environment that is locked to strict rules and only one, perfectly defined meaning. This can only be done on the human side, and I think all the attempts for automatic translation and machine understanding are doomed. The machine understanding will always fail on this in a certain percentage, and the more important it is that the machine does exactly what I want, the less likely that I will ever trust a speech-to-text engine and would want a button to press instead. Or: I have to learn how the machine will understand my sentences, and talk to it using an ultimately simplified "Language-for-my-coffee-maker"... But why?
We do have Esperanto, an artificial generic language. If we have the type definitions (the exact "technical meaning") of each word in a transparent form (again in Esperanto), we have a perfectly clean interface to the system: we can know what attributes, commands, relations we can refer to when talking to the coffee machine. We can use a simple but generic (and so globally available) language that is easy to learn, and so enter a world where we can actually talk to any entity in an unambiguous way, and we don't have to learn a locally crippled natural language for each new type we meet (as we do today for each new software, forget the text-to-speech part, any user interface does just this... not to mention the famous example of the new Office package).
I think it is possible that with Esperanto we can actually do anything in this information system. We can take a totally new component, understand its features, query its state and use its function, all without any additional user interface, just by using the fact that we know Esperanto (the "human script language of Dust"). The essential simplification and clarification between our thoughts and the machine understandable, unambiguous commands - and back: building ideas from the received unambiguous information is done in our brain, using our own, internal natural/artificial language translation. In this scenario, all parties do what they are the best at.
The last sentence: the business logic is now implemented in a programming language - but as I have already mentioned: a source code is nothing else but a more human readable form of a forest (mathematical graph term) of construct nodes of that language (declaration, value transfer, decision, call, repeat, ...). This is to what the compiler/interpreter transforms the text files, and then executes it (interpreter) or further transforms it to machine instruction code arrays. Thinking in this way, the source code itself is equivalent to an entity hierarchy, and any entity hierarchy can be transformed to Esperanto sentences, so perhaps this is the end of programming languages as well: we only need the declaration of the construct nodes to express just any action using them. (Of course this is not among the first targets, just a strange idea.)
2012. november 11., vasárnap
2012. november 10., szombat
Az ezeregyedik kiáltvány :-)
2012.november.8th. at 21:00
A jelenség természetességével is tisztában vagyok, ez egyben frappáns válasz is ejha (66) felvetésére ("Lehet, hogy likvidálni kéne"). A gond csak az, hogy egy kis (falu méretű) közösségben ezt a viselkedésmódot a sarki kocsmában néhány nyolc napon túl gyógyuló mozdulattal kigyógyítják bárkiből – egy “modern” “demokráciában” viszont öltönyös szakértők és bloggerek járják körbe-körbe a végtelenségig, mi meg bambán hagyjuk kiteljesedni.
Felvetésedre a válaszom röviden: a “civilizált ember” mai, nyugati közfelfogás szerinti definíciója természetesen tarthatatlan. Viszont szerintem HA képesek leszünk a valódi szükségleteink kielégítésére koncentrálni az idióta álomkergetés helyett, HA hajlandóak leszünk újra DOLGOZNI, közösségként gondolni önmagunkra és hinni a bennünk rejlő lehetőségben, AKKOR nyerhetünk elég időt az “újratervezéshez”. Ha nem, akkor bizony pofára esünk, és NEM lesz “csendesen eléldegélés a romokon”, meg felemelkedés.
Hosszabb választ a Hajnalvilág könyv 97. oldalától olvashatsz.
[... persze erre "hubab" már nem válaszolt.]
2012.november.9th. at 07:34
1: NEM vagy objektív, ahogy a világon egyetlen ember sem az, semmilyen szempontból nem vagyunk alkalmasak rá. Ezzel a megállapítással mindaddig egyet is értesz, amíg nem rád vonatkozik (a saját objektivitásodra mint abszolút jellemzőre, és nem mint szándékra hivatkozol).
2: Az objektivitás MÉRTÉKE valóban meghatározza azt, hogy mennyire pontosan látjuk a világot, és ettől függ az, hogy mire vagyunk KÉPESEK a jelen pillanatban. Például: az álmodozókat megvezetik, mert direkt ezt kívánják, és minél nagyobb a homogén álmodozók köre, annál hatalmasabb (és idiótább) vezért emelnek maguk fölé. Szimpla MATEK. Egyébként a tréfa kedvéért: a “fides” jelentése hit, latinul.
3: Viszont UGYANILYEN fontos az, hogy milyennek akarod látni a világot, milyennek hiszed a jelenségek látszata mögött. Ennek alapján hozol döntéseket, és (képességeid mértékében) ebbe az irányba MOZGATOD a világot.
—
Te “csak” krónikás vagy. De ezzel mindenkit, aki a blogodat olvassa, elriasztod a nagy közösségi, konstruktív gondolkodástól, az ember jövőjébe vetett hittől; és egyéni túlélős barkácsolásra biztatod, táplálod bennük azt az illúziót, hogy ennek bármi értelme lenne. Pedig te is leírod, hogy az ebben gondolkodók szépen állítsák sorba a szeretteiket, húzzanak ki kilenc “eldobhatót” minden egyes olyan emberért, akit szeretnének megtartani. VAGY: próbáljanak más megoldást keresni, még ha lehetetlennek látszik is.
Továbbá: HA Orbán Viktor olvasná a blogodat, és a benne leírt jövőképet, a párbeszédek tartalmát és színvonalát, szerinted elgondolkodna azon, hogy mit is csinál? Szerintem éppen ellenkezőleg: ebben is csak visszaigazolást látna. Nem is alaptalanul.
Na ezért vitáztam veled eddig – de már minden fontosat elmondtam.
2012.november.10th. at 04:35
Például ahelyett, hogy “birkanépezik”, meg túlélő tanfolyamokat szervez (mert “nem szeretném, de úgyis minden összeomlik”), meg “mozgalmat indít a korrupció ellen (HAHAHA…) mondhat olyat, hogy
Hölgyeim és Uraim, ébresztő!
Magyarországon IGENIS VANNAK olyan emberek, akiket a felelősségtudat és személyes felelősségvállalás, a szaktudás és a jó szándék tesz vezetővé, NEM a “modern” “demokrácia” amúgy is fejre állított, majd lassan kézi távvezérlővé barkácsolt szabályai. Például:
A sor folytatható, alternatívák kereshetők. De ahelyett, hogy a zsibbadt tömeget ekézném nyafogva, meg százalékokon töprengenék, kijelentem, hogy ÉN személyesen őket akarom vezető szerepben látni, és kérlek téged, kedves olvasó:
Még akár idézhetnél is tőlem, mondjuk ilyet:
A fásultság, végtelen unalom és kiábrándultság nem kellemes érzés, de alapvetően jó. Azokról az eszközökről, amelyek igyekeznek egységes, százalékokkal és mutatókkal mérhető tömeggé formálni bennünket, egyenként kiderül, hogy mennyit érnek, ugyanakkor mibe kerülnek nekünk és a bolygónak. A király meztelen, hiába a kikiáltók hangos üvöltése, a fizetett hangulatcsinálók suttogása a tömegben – az ember újra keresni kezdi szomszédja kezét.
Tudjuk már, hogy a bennünket pirosra, narancsra, kékre vagy zöldre festő, százalékokért bármit kimondó „teamek” folyamatosan lesnek, méregetnek minket; minden óhajt és az ellenkezőjét is felírják zászlajukra – csak sajnos oly kevés már ott a hely a korábbi elvek, ígéretek mellett.
Így aztán egyre erősebben vágyunk arra, hogy valaki végre mondjon igazat, ha fáj is – és ne hagyja abba csak emiatt. Igenis szúrja a tűt, vágja a húst, fájjon, ha kell; de szeretet, felelősségtudat és hit legyen a szemében, ne tartson poharat a véremnek, és ne koccintson vele a műtőasztal alatt.
Ma mindez vágyálom csupán, és nem a szereplők miatt, mert bár ők egyénileg természetesen felelősek az általuk okozott kárért, de ha lecseréljük őket, ugyanolyanok állnak a helyükre. De talán éppen ez tesz minket elég erőssé, elhatározottá ahhoz, hogy felvállaljuk és kimondjuk: igen, én magam vagyok ez a rendszer.
Magam vágytam arra, hogy szebb világot hazudjanak nekem, én kívántam, hogy elvakítsanak, elkábítsanak, és magam is részt veszek mások becsapásában. Most viszont látni akarok, színről színre úgy, ahogy a dolgok vannak, és igazat akarok mondani akkor is, ha ez sokba kerül nekem, mert megcsömörlöttem már ettől a kusza, önmagának folyamatosan ellentmondó rendszertől, amelynek része vagyok. Leesni az ágyról nagyon kellemetlen, de ha ez szükséges ahhoz, hogy végre felébredjünk egy lázálomból, akkor megéri.
—
TE mondhatnál ilyet, mert EZ valóban “inspirálhat” embereket a nagyobb közösségi összefogásra – az általad elővett témák és hangulat NEM.
Én nem mondhatok ilyet, mert szerintem a jelen helyzet következmény, az okok feltárásáért ennél jóval messzebbre kell menni.
Az objektivitásos téma:
Igen, ha sarokba szorítalak és éppen jó hangulatod van, akkor egyáltalán válaszolsz, nem küldesz elmeorvoshoz (mint korábban néhányszor) és képes vagy elismerni – de csak olvasd el ezt az egyetlen bekezdésedet. Azonnal visszatámadsz, és már azonnal elfelejted, hogy KIVEL beszélsz.
ÉN vagyok az, aki állandóan a saját szubjektivitását tekinti alapnak, ÉN vagyok az, aki csak a szóismétlés miatt nem írja bele minden mondatába, hogy “szerintem”. ÉN vagyok az, aki az egész életét azzal tölti, hogy magukat objektívnak és alaposnak képzelő emberek kósza ötleteiből egy valóban objektív világban (számítógép) működő rendszert faragjon.
Igen, képes vagyok lemenni arra a szintre, amit te szeretsz, de ott a jelen problémákra NINCS MEGOLDÁS, mert ahhoz igen távoli rendszerek közötti összefüggési hálózat ismerete és feltárása szükséges alapkövetelmény! EZT próbálom elmesélni a “kitérőktől hemzsegő” szövegeimben. És igen: baromi kemény agymunkát igényel a követése is, nem is várhatom el senkitől – tőled sem, nem hogy az “istenadta néptől”. De akkor minek és kinek beszélek?
No azt hiszem, itt volt elég, megint az ellenállhatatlan ágyúgolyó és az áttörhetetlen fal konfliktusánál járunk.
65, Tibor bá: Ez annyira szép, és elegáns párhuzam, hogy kifélkövérítettem. Csak azt kellene belátnod, hogy a Viktorok is mind benne vannak az “emberi természetben”. Vágj le egyet, nő helyette három.Köszi, gondoltam, hogy jól passzol ide.
A jelenség természetességével is tisztában vagyok, ez egyben frappáns válasz is ejha (66) felvetésére ("Lehet, hogy likvidálni kéne"). A gond csak az, hogy egy kis (falu méretű) közösségben ezt a viselkedésmódot a sarki kocsmában néhány nyolc napon túl gyógyuló mozdulattal kigyógyítják bárkiből – egy “modern” “demokráciában” viszont öltönyös szakértők és bloggerek járják körbe-körbe a végtelenségig, mi meg bambán hagyjuk kiteljesedni.
67, hubab: Amit eddig elolvastam tőled, abból azt veszem ki, hogy nem vagy hajlandó figyelembe venni annak a puszta lehetőségét sem, hogy az emberiség már túlnyújtózott a maga takaróján, és a jelen népesség puszta életben tartása is csak a föld egyre csökkenő tartalékainak teljes felélése árán lehetséges, míg azok léteznek. ... Mitől vagy olyan biztos abban, hogy a hajó még nem ment el? Hogy egyáltalán létezik még elvi megoldás a pozitív kimenetre?Biztos nem vagyok semmiben. Viszont jogomban áll ELDÖNTENI, hogy miért tartom érdemesnek élni és dolgozni – és mire nem pazarolok időt.
Felvetésedre a válaszom röviden: a “civilizált ember” mai, nyugati közfelfogás szerinti definíciója természetesen tarthatatlan. Viszont szerintem HA képesek leszünk a valódi szükségleteink kielégítésére koncentrálni az idióta álomkergetés helyett, HA hajlandóak leszünk újra DOLGOZNI, közösségként gondolni önmagunkra és hinni a bennünk rejlő lehetőségben, AKKOR nyerhetünk elég időt az “újratervezéshez”. Ha nem, akkor bizony pofára esünk, és NEM lesz “csendesen eléldegélés a romokon”, meg felemelkedés.
Hosszabb választ a Hajnalvilág könyv 97. oldalától olvashatsz.
[... persze erre "hubab" már nem válaszolt.]
2012.november.9th. at 07:34
65, Tibor bá: Én csak krónikás vagyok. Én nem okozom az eseményeket, csak észlelem és közzé teszem. Ha lenne hatalmam azon lennék, hogy minden magyar a 10 százalékban legyen.Azért lefutom ezt az “én csak krónikás vagyok” kört is újra.
1: NEM vagy objektív, ahogy a világon egyetlen ember sem az, semmilyen szempontból nem vagyunk alkalmasak rá. Ezzel a megállapítással mindaddig egyet is értesz, amíg nem rád vonatkozik (a saját objektivitásodra mint abszolút jellemzőre, és nem mint szándékra hivatkozol).
2: Az objektivitás MÉRTÉKE valóban meghatározza azt, hogy mennyire pontosan látjuk a világot, és ettől függ az, hogy mire vagyunk KÉPESEK a jelen pillanatban. Például: az álmodozókat megvezetik, mert direkt ezt kívánják, és minél nagyobb a homogén álmodozók köre, annál hatalmasabb (és idiótább) vezért emelnek maguk fölé. Szimpla MATEK. Egyébként a tréfa kedvéért: a “fides” jelentése hit, latinul.
3: Viszont UGYANILYEN fontos az, hogy milyennek akarod látni a világot, milyennek hiszed a jelenségek látszata mögött. Ennek alapján hozol döntéseket, és (képességeid mértékében) ebbe az irányba MOZGATOD a világot.
—
Te “csak” krónikás vagy. De ezzel mindenkit, aki a blogodat olvassa, elriasztod a nagy közösségi, konstruktív gondolkodástól, az ember jövőjébe vetett hittől; és egyéni túlélős barkácsolásra biztatod, táplálod bennük azt az illúziót, hogy ennek bármi értelme lenne. Pedig te is leírod, hogy az ebben gondolkodók szépen állítsák sorba a szeretteiket, húzzanak ki kilenc “eldobhatót” minden egyes olyan emberért, akit szeretnének megtartani. VAGY: próbáljanak más megoldást keresni, még ha lehetetlennek látszik is.
Továbbá: HA Orbán Viktor olvasná a blogodat, és a benne leírt jövőképet, a párbeszédek tartalmát és színvonalát, szerinted elgondolkodna azon, hogy mit is csinál? Szerintem éppen ellenkezőleg: ebben is csak visszaigazolást látna. Nem is alaptalanul.
Na ezért vitáztam veled eddig – de már minden fontosat elmondtam.
2012.november.10th. at 04:35
77 Tibor bá Ez az a kitérőktől hemzsegő szöveg elkerülésének üdítő példája, amit nálad még nem volt alkalmam tapasztalni. Inspiráló!Hátulról előre: “mit csinálhat máshogy egy krónikás”?
Az objektivitásról írottakkal egyetértek. Az ember legfeljebb törekszik rá, de tökéletesen nem tudja elérni. Na de, tudsz ennél jobbat? Ráadásul ez mindenkire, tehát rád is vonatkozik. Az a tudat, hogy abszolút objektív neme lehetsz, nem béníthat le. Különben is döntéseidnél egyéni dolgokkal súlyozod a tényezőket, ami máris a szubjektivitás felé tol. Például: Túlélési stratégia esetén nekem jó, ha van hátra egy évtized, esetleg másfél. Nyilván a felkészülésnél ez egy objektív tényező számomra, de más nézete szerint szubjektív.
Krónikás ügy: Juliánusz barát időben jelezte, hogy a mongol horda nyugatra tart. Kérdésem: Ezzel elriasztotta a nagy közösségi, konstruktív gondolkodástól a magyarokat? Ellenkezőleg, inspirálhatta volna őket, ha hallgatnak rá. – persze ezt te másképp látod. Jogod van hozzá.
Például ahelyett, hogy “birkanépezik”, meg túlélő tanfolyamokat szervez (mert “nem szeretném, de úgyis minden összeomlik”), meg “mozgalmat indít a korrupció ellen (HAHAHA…) mondhat olyat, hogy
Hölgyeim és Uraim, ébresztő!
Magyarországon IGENIS VANNAK olyan emberek, akiket a felelősségtudat és személyes felelősségvállalás, a szaktudás és a jó szándék tesz vezetővé, NEM a “modern” “demokrácia” amúgy is fejre állított, majd lassan kézi távvezérlővé barkácsolt szabályai. Például:
- Államfő / miniszterelnök: Róna Péter
- Földművelésügy: Ángyán József
- Gazdaság: Demján Sándor
- Oktatás: Molnár Lajos
- Média, kisebbség: Pikó András
A sor folytatható, alternatívák kereshetők. De ahelyett, hogy a zsibbadt tömeget ekézném nyafogva, meg százalékokon töprengenék, kijelentem, hogy ÉN személyesen őket akarom vezető szerepben látni, és kérlek téged, kedves olvasó:
- gondolkodj el azon, hogy ilyen emberi minőséget akarsz-e az ország vezetésében látni – vagy azt, akik most ücsörögnek ott!
- keress további jelölteket, vitázzunk EZEN nagy szavak, zsidózás meg turulos-koronás maszlag helyett – és nézzük végre LEVEGŐNEK azokat a balfékeket, egyetlen gondolatot, egyetlen másodpercet ne pazaroljunk rájuk!
- ha van kedved, csinálhatunk akár mozgalmat is, de NEM azért, hogy MI mondjuk meg a tutit, hanem azért, hogy végre ŐK mondhassák meg!
- és végül: ÉN követni fogom őket akkor is, ha éppen kényelmetlen, amit mondanak, mert BENNÜK én személyesen megbízom!
Még akár idézhetnél is tőlem, mondjuk ilyet:
A fásultság, végtelen unalom és kiábrándultság nem kellemes érzés, de alapvetően jó. Azokról az eszközökről, amelyek igyekeznek egységes, százalékokkal és mutatókkal mérhető tömeggé formálni bennünket, egyenként kiderül, hogy mennyit érnek, ugyanakkor mibe kerülnek nekünk és a bolygónak. A király meztelen, hiába a kikiáltók hangos üvöltése, a fizetett hangulatcsinálók suttogása a tömegben – az ember újra keresni kezdi szomszédja kezét.
Tudjuk már, hogy a bennünket pirosra, narancsra, kékre vagy zöldre festő, százalékokért bármit kimondó „teamek” folyamatosan lesnek, méregetnek minket; minden óhajt és az ellenkezőjét is felírják zászlajukra – csak sajnos oly kevés már ott a hely a korábbi elvek, ígéretek mellett.
Így aztán egyre erősebben vágyunk arra, hogy valaki végre mondjon igazat, ha fáj is – és ne hagyja abba csak emiatt. Igenis szúrja a tűt, vágja a húst, fájjon, ha kell; de szeretet, felelősségtudat és hit legyen a szemében, ne tartson poharat a véremnek, és ne koccintson vele a műtőasztal alatt.
Ma mindez vágyálom csupán, és nem a szereplők miatt, mert bár ők egyénileg természetesen felelősek az általuk okozott kárért, de ha lecseréljük őket, ugyanolyanok állnak a helyükre. De talán éppen ez tesz minket elég erőssé, elhatározottá ahhoz, hogy felvállaljuk és kimondjuk: igen, én magam vagyok ez a rendszer.
Magam vágytam arra, hogy szebb világot hazudjanak nekem, én kívántam, hogy elvakítsanak, elkábítsanak, és magam is részt veszek mások becsapásában. Most viszont látni akarok, színről színre úgy, ahogy a dolgok vannak, és igazat akarok mondani akkor is, ha ez sokba kerül nekem, mert megcsömörlöttem már ettől a kusza, önmagának folyamatosan ellentmondó rendszertől, amelynek része vagyok. Leesni az ágyról nagyon kellemetlen, de ha ez szükséges ahhoz, hogy végre felébredjünk egy lázálomból, akkor megéri.
(Hajnalvilág, 2008 - 86. oldal)
—
TE mondhatnál ilyet, mert EZ valóban “inspirálhat” embereket a nagyobb közösségi összefogásra – az általad elővett témák és hangulat NEM.
Én nem mondhatok ilyet, mert szerintem a jelen helyzet következmény, az okok feltárásáért ennél jóval messzebbre kell menni.
Az objektivitásos téma:
Igen, ha sarokba szorítalak és éppen jó hangulatod van, akkor egyáltalán válaszolsz, nem küldesz elmeorvoshoz (mint korábban néhányszor) és képes vagy elismerni – de csak olvasd el ezt az egyetlen bekezdésedet. Azonnal visszatámadsz, és már azonnal elfelejted, hogy KIVEL beszélsz.
ÉN vagyok az, aki állandóan a saját szubjektivitását tekinti alapnak, ÉN vagyok az, aki csak a szóismétlés miatt nem írja bele minden mondatába, hogy “szerintem”. ÉN vagyok az, aki az egész életét azzal tölti, hogy magukat objektívnak és alaposnak képzelő emberek kósza ötleteiből egy valóban objektív világban (számítógép) működő rendszert faragjon.
Igen, képes vagyok lemenni arra a szintre, amit te szeretsz, de ott a jelen problémákra NINCS MEGOLDÁS, mert ahhoz igen távoli rendszerek közötti összefüggési hálózat ismerete és feltárása szükséges alapkövetelmény! EZT próbálom elmesélni a “kitérőktől hemzsegő” szövegeimben. És igen: baromi kemény agymunkát igényel a követése is, nem is várhatom el senkitől – tőled sem, nem hogy az “istenadta néptől”. De akkor minek és kinek beszélek?
No azt hiszem, itt volt elég, megint az ellenállhatatlan ágyúgolyó és az áttörhetetlen fal konfliktusánál járunk.
2012. november 8., csütörtök
Entity containers and locks
Entity containers targets the problem of transactions: changing multiple entity instances and attributes within a single action. The change must be "atomic", all updates must be done or discarded to keep the components in valid, consistent state - but the modification process requires time, and the operation may be interrupted by a failure (hardware, system, connection - this is the traditional transaction management) or another concurrent modification (programming language lock and synchronization constructs).
Moving the state representation to Dust means that the code should never meet this situation - it can control the "commit" / "rollback" operations, but it does not have to actively protect anything from transaction errors: it should work as configured. The encapsulation gives a way to support this, using a hierarchy of entity containers.
The Dust runtime is merely an entity instance container, with an API to get references to them, access their content and send messages. Its actual operation: the ability of handling the types, entities, messages, and that it can go for other entities upon requests are actually the functions of some required (and later time: properly protected) kernel "meta" entities.
As long as an operation accesses entities and reads their content, we have no problem, this operation can run in parallel with many components accessing the same instance. Writing causes the trouble. Of course, parallel write requests should not be allowed - but we also should not let a write operation complete while another code is actually reading the same entity, because it is nonsense to get different results to the same question (like: I make a decision because of the state of an item, and do other actions, yet the item state gets modified at the same time).
The solution (at least seems to be) quite simple, using the restrictions above. When a code uses a reference, it gets connected to its local usage pool, and also linked into the using contexts list of the aspect. When the message processing ends (the code returns), the references are released and removed from the list. When a code request a write operation, the Aspect gets locked to that code, and all concurrent write requests are suspended until this lock lives. However, the code does not change that aspect instance: it is shallow-cloned into a secondary Entity container. Whenever this code, or any other that it calls refers to this Aspect, they receive this temporal instance; but it is linked to the original container, and any instance missing from the current container will be resolved from (or by) its parent.
So, the update code collects duplicates into the local container, but does not break other processes by the parallel modification as long as it runs. When it ends, the temporary context is released and the updates are committed. This is the point when readers could be broken, so the commit process waits for all current references to be released to the item, and also blocks opening new read references to the target objects. In the root level, commit means updating the instance in its persistent storage as well.
Deadlocks
Of course, this "generic approach" has inevitable problems because of its simplicity. It can naturally result in deadlocks: parallel processes both waiting for an instance blocked by the other. However, this information is not hidden somewhere in the runtime, behind the language constructs, but clearly visible in the Dust runtime thread manager - and can be resolved there. On the other hand, the approach of atomizing the business logic and moving all state representation to Dust means that the message responding codes will be short and simple, so the synchronization problems "should" become more visible and manageable.
Releasing and listening
In longer operations the coder should take care of the consequences of having some entities locked for a longer period of time, consider the side effects and implement the behavior wisely. For example: one entity contains information that has effects on other entities. When this entity changes, many others also has to be updated. If it runs in cycle, it would gradually lock all the touched entities, which is not good - so, it can commit changes for each item thus releasing them from the local context. Of course, with the messaging architecture this is not the case: the update request can be broadcast to all members, the message processor does the update, so the change is done in the local context of the called message processor, and the local commit is done when the processor exits.
However, what should happen to the originating object? It depends. It may remain locked all along the update process to block concurrent modification. Or the relevant data can be extracted for creating the update message, and then the code can release the entity, so even if it gets updated during the child processes, the actual modification will be coherent (though obsolete). Or, the source object can be released, but the process can listen to its change, and if it gets updated while the process is running, it can stop the operation and restart it with the updated information again.
Operation contexts
Another typical situation is when the modification process is of "unknown length": the system enters a state of updating some entities, but has to wait for external events to happen. This is the generic scenario behind all user interfaces, server communication, interaction with a hardware component, etc. I would say that reading data from the hard drive is also the same situation.
The current programming methodology uses wait calls, spins in cycles, etc, in this case, which is again a situation when the code represents the application state, and which considered evil in Dust. The command is sent to the hardware, the information is presented to the user, so this task is done, the activated message processor code must return. The event will appear some time later, dispatched to the component again, resulting in a data change (mouse movement and click -> user interface component state change -> data modification), the relevant message processors are called, and then again the system stops and waits for the next event.
The state between these operations are stored in an operation context, a temporal persistent entity container. This is independent from Dust kernel container (which represents the "actual global state of the things"), and floats above it, containing "one required new state under construction". Such contexts can be created by some system level components - like one that can display a GUI window, open a network channel or start a stream deserialization process. When the context is closed, it can rollback the operation: throw the container, or, by default, commit it: update all entities of the parent container. Yes, this is a tree, and a window called modally from another window can update the parent window's context, and NOT the root under it (and for exchange, it can see the actual modifications made on the parent window).
This again relates to locking. The GUI displays many entities, and updates some. The update locking can break through the context depending on the configuration. The definition should contain if it
- locks the target item globally, blocking others to modify it, but ensure that no concurrent modification takes place - better for atomic components,
- or let others do parallel modification and merge the modifications on commit if needed - better for big components like source codes.
The displayed entities are another problem: they would block updates because of the read registration. An alternative is that the GUI elements listen to the displayed entity, but release it. So, the updates are allowed, but the controls get notification about it and so they can reflect to parallel changes. This is a recipe both for parallel displaying and editing the same data instances, and for screen sharing, depending on if the listening is registered to the target or the GUI element entity.
Esti mese: Viktor és a léghajó
Ennek úgy tűnik sosem lesz vége... Újra karattyolok Antalffy Tibor blogján.
2012.november.7th. at 20:07
... amit Orbán tesz, az ő szempontjából szerintem teljesen racionális, csak addig tűnik bénázásnak, amíg nem akarjuk elfogadni, hogy egyszerűen a saját kapunkra támad. A hülye ötletek tárháza a nekünk szóló “pávatánc”, rágni való gumicsont – a lényeg viszont az, hogy ne maradjon egyéni mozgástered, anyagi függetlenséged, szorulj rá a nemzeti tőgyre. És ne is reméld, hogy lehet máshogy is, mert a “hazán kívül” csak a “gonoszok” vannak.
2012.november.8th. at 04:14
60, Ábel: Én látok bizonyos lépéseket, amik éppen abban az irányba hatnak, hogy minél kevésbé szoruljanak rá az egyes alrendszerek az állami tőgyre, ami nemsokára úgyis teljesen elapad/levágják stb.
Pl. mindenhol szabad már állatot tartani. Vagy az, hogy fokozatosan kivonják az állami pénzt a felsőoktatásból, egészségügyből: ettől ezek részben sorvadnak, de részben meg fogják találni azokat a forrásokat, amikből mégis fennmaradhatnak. Persze nem mindenki számára, csak annak, aki meg tudja fizetni. Ez a társadalmi mobilitás vége lesz, de a geddon után úgysincs más.
Ne haragudj, ez ostobaság. Elég közelről látom, ahogy a szó szoros értelmében kivéreztetik a magyar civil társadalmat, például a környezetvédelmi szervezeteket, amelyek a közfelfogással ellentétben NEM a szemétszedésről meg az atomos láncolgatásról szólnak, hanem a fenntartható élet-minták feltárásáról és népszerűsítéséről (lásd itt például Géza tudását). Most már egyre inkább múlt időben.
A társadalmi rendszerek fenntartása NEM “rentábilis”, ezek nem teremtenek pénzre váltható értéket, nincs “nettó bevétel”; elvileg a gazdaság termelő részének kellene finanszíroznia (erről szólnak az adók). Ha ez nem történik meg, akkor a kiváltságos kevesek számára marad elérhető, a “többiek” mennek a levesbe, ami NEM a megoldás, hanem a totális összeomlás receptje, lásd Görögországot (de ha jobban figyelsz, az egész “fejlett nyugatot” élen Amerikával) a lejtőn lefelé – és Argentínát, ahogy jóvátehetetlen következmények mellett kifelé próbál araszolni. Engedelmeddel Tibor bá, egy régi(!!!) írásom: újsütetű messiásunkat ekéztem ezzel áprilisban.
59, Tibor bá: Az egészet megette a fene, de miért kell siettetni? legalább én szeretnék “békebeli” módon elhunyni.De nem ezért firkálok itt megint, hanem azért, mert megint egy ide szánt szösszenettel ébredtem (fél négykor, rohadt dolog ez a prófétaság). Figyelj csak:
Viktorunk olyan, mint a süllyedő léghajó kapitánya, aki kidobja az égőt (mert veszélyes), aztán a gázpalackokat (mert égő nélkül minek), lebontja a kosár oldalát és a köteleket nyiszálgatja. Minden ilyen lépés után megtapsoltatja magát, hogy na, megint emelkedünk, akárki láthatja! És miért? Mert a ballaszt homokból szép várat épít Kennek és Barbie-nak (a “benne hívő igaz magyaroknak”), és ahhoz semmiképpen nem akar hozzányúlni.
Ezzel az a bajom, Tibor bá, hogy például ebből lehet plakátot nyomni, meg pólóra felrajzolni, meg hőbörögni – de a léghajó felemelése, amelyért való erőfeszítés az EGYETLEN erkölcsileg, emberileg elfogadható megoldás (azért, hogy nem csak TE, hanem mindannyian tisztességben addig élhessünk, amíg adatik, és békében nyugodjunk el, amikor eljön az ideje) nem ezen múlik.
—
Ahogy egyébként az “apostoli magyar királyságon”, okoskodáson vagy a lezuhanásra való felkészülésen sem. Azt a vitát meg nem nyitom újra, hogy aki MA, a kényelmes székecskéjéből és életkéjéből a “geddon után” szöveggel jön, az az én szótáramban nem felel meg az “ember” fogalom definíciójának. Mindegy, ezzel ébredtem, leírtam, szép napot. Dolgozni is kéne még, mielőtt munkába mennék.
2012.november.8th. at 05:05
Ó basszus… hát most kellett leessen a lényeg! Tibor bá! Orbán Viktor TE VAGY!
Pontosan ugyanazt a forgatókönyvet látja, mint te, ugyanazt a logikát követi – csak neki hatalma is van a túlélésre érdemes tíz százalék kiválasztására és támogatására “a többi” rovására (szerk: és ő az, aki a tanácsomnak megfelelően szektát csinál belőlük). De milyen rohadt dolog már ezt a turulos csónakot kívülről nézni…
Bocs… :-D
2012. november 7., szerda
Entities 2
References
The fundamental difference of Dust is that it considers the software (all of them without exceptions) a state machine. The software is built up from components having many attributes and connections to each other, but both the attributes and the connections are managed and kept inside the framework runtime environment, can be accessed and managed by framework API calls. The software code on the other hand is responsible only for handling events, and not for representing the system state. That is: no "main" function, no waiting cycles and polling, and no final and static variables, local buffers for storing system state information.
Whenever a code (an internal event handler of a component instance) wants to access another component, it can do so only through dust API calls, and only by a component (Aspect) reference that it has received from the incoming message, its own existing component links or by searching for entities using API calls. The code has a very short life: runs only to respond a message (and not to represent a "listening state" for example), and has no need to "remember" any component or state (except for storing such information in its own or other components' attributes).
This means that the Dust runtime is free to handle the actual entity instances behind the API wall as it wants. It is totally irrelevant if the instance is purged from memory and reloaded, replaced with another instance ("dll hell"), exists or temporarily moved to another computer - as long as its attributes are reachable and messages can be sent to it using their references.
The fundamental difference of Dust is that it considers the software (all of them without exceptions) a state machine. The software is built up from components having many attributes and connections to each other, but both the attributes and the connections are managed and kept inside the framework runtime environment, can be accessed and managed by framework API calls. The software code on the other hand is responsible only for handling events, and not for representing the system state. That is: no "main" function, no waiting cycles and polling, and no final and static variables, local buffers for storing system state information.
Whenever a code (an internal event handler of a component instance) wants to access another component, it can do so only through dust API calls, and only by a component (Aspect) reference that it has received from the incoming message, its own existing component links or by searching for entities using API calls. The code has a very short life: runs only to respond a message (and not to represent a "listening state" for example), and has no need to "remember" any component or state (except for storing such information in its own or other components' attributes).
This means that the Dust runtime is free to handle the actual entity instances behind the API wall as it wants. It is totally irrelevant if the instance is purged from memory and reloaded, replaced with another instance ("dll hell"), exists or temporarily moved to another computer - as long as its attributes are reachable and messages can be sent to it using their references.
2012. november 5., hétfő
Entities 1
Entity versus Aspect
Separation of these terms is fundamental in Dust. The Entity represents the "existence", be it a message, a software component, a real life object or person. The Entity has a life cycle independent from the computer environment, and its computer representation must be synchronized to reflect those changes - this is why we have "information systems". Behind all operations Dust manages entity instances in the background; all information packages come and go in Dust in Entity instances.
Aspects are "objects" of declared and managed types having attributes and implementing business logic (that is: processing and responding to incoming messages). An Entity instance has a collection of Aspects, which collection may change along the life of the Entity - so the Entity itself has a history of changing Aspects, while the Aspects have history of changing Variants, receiving and sending messages.
In any business logic (software code) we can only see Aspects. We use and communicate with these feature collections, not the Entities themselves. Every Aspect instance, where my business logic is integrated, have the list of required service components, with which I have to communicate to do my job. These links are defined in my type, declared when the application configuration is created (deployed to the actual running environment), and resolved when my entity is loaded. In fact, most business logic does not have to get and store entities dynamically, variable content come with the messages that it has to process.
Knowing this, I assume that the business logic code should never access entities, nor aspects directly, through a memory reference or object instance. The Dust kernel API therefore can totally separate the "user" business logic from internal memory and data management, and this is a fundamental step towards security and reliability.
On the other hand, there are special components that have to see through this layer: the generic services like expressions; automatic GUIs that are generated to an Entity by listing its Aspects; or serialization. The idea: i should create Entity, Aspect, Field aspect instances! The component can request them from an incoming Entity instance, and through them it can manage those generic operations. With this trick, there is no programmatic or API difference between kernel and user level code, no new "protected" kernel functions. Of course, the operations must be protected, but again with the same tools as all other Dust security features will be implemented, with the same declaration features.
Separation of these terms is fundamental in Dust. The Entity represents the "existence", be it a message, a software component, a real life object or person. The Entity has a life cycle independent from the computer environment, and its computer representation must be synchronized to reflect those changes - this is why we have "information systems". Behind all operations Dust manages entity instances in the background; all information packages come and go in Dust in Entity instances.
Aspects are "objects" of declared and managed types having attributes and implementing business logic (that is: processing and responding to incoming messages). An Entity instance has a collection of Aspects, which collection may change along the life of the Entity - so the Entity itself has a history of changing Aspects, while the Aspects have history of changing Variants, receiving and sending messages.
In any business logic (software code) we can only see Aspects. We use and communicate with these feature collections, not the Entities themselves. Every Aspect instance, where my business logic is integrated, have the list of required service components, with which I have to communicate to do my job. These links are defined in my type, declared when the application configuration is created (deployed to the actual running environment), and resolved when my entity is loaded. In fact, most business logic does not have to get and store entities dynamically, variable content come with the messages that it has to process.
Knowing this, I assume that the business logic code should never access entities, nor aspects directly, through a memory reference or object instance. The Dust kernel API therefore can totally separate the "user" business logic from internal memory and data management, and this is a fundamental step towards security and reliability.
On the other hand, there are special components that have to see through this layer: the generic services like expressions; automatic GUIs that are generated to an Entity by listing its Aspects; or serialization. The idea: i should create Entity, Aspect, Field aspect instances! The component can request them from an incoming Entity instance, and through them it can manage those generic operations. With this trick, there is no programmatic or API difference between kernel and user level code, no new "protected" kernel functions. Of course, the operations must be protected, but again with the same tools as all other Dust security features will be implemented, with the same declaration features.
2012. november 3., szombat
Working with data 3
Collections again
It is very hard to get rid of old habits and choose a more complex-looking solution (which is complex only until we peek under the hood of the programming language where the problems are hidden).
I thought (and programmed in this way many times) that collections are generic part of data management. Again: they are not. Collections are aspects themselves, they either are part of the owner entity (like: subpanels of a window, scheduled commands of the scheduler, etc.) or referred internal entity members. Yes, the last time I have said that I did not need a collection directly, but only the iteration/search function - but forgot to mention the term "temporary". It is true that I don't need temporary collections, but the object themselves do contain many collections. If they are hidden under the "variant" layer, I have returned to the same problem of temporary collections, but under the hood with expressions for example.
So: Variants do not have multi-value content. If there is a need of it, it is a reference to a Collection aspect or entity. When expression evaluation encounters such a reference, that is again an accumulate / broadcast / search action (and reintroduce the parallel execution on this very low level).
Serialization
When different nodes communicate, they need to serialize their content. This component is responsible for working with references (independent of the actual implementation or the syntax of the stream). The generic solution is that each serialization action contains an ID map, where the unique id of the entity instance and a local, action-unique id is connected. The local id is used all the time, while the content is pushed into the stream only on the first call, when the item is registered into the map. In this way both sides have the simplest way to write and read the self referring structures properly.
Very important: the mapping must be set when starting the serialization: the referred entities may contain back references to the entity being serialized. They must receive the local id only, not start a recursive serialization process. On the other hand: anytime a local id based reference is resolved, the instance itself should be considered "final", but may be incomplete, and its content should not be used at this time. The read process should end with an independent initialization action after all referred components are read.
Content in serialization
From the content point of view, we have static and dynamic serialization.
Static is when I want to store and "remember" something as it is, like a configuration file: I want to keep some settings... NO! The config files are actually the primary source of the stored instances! Hmm... This means that for persistent entities, I have to serialize the content only if that serialization is actually the primary storage for those instances. All the others must only be stored by their unique identifiers (global type Id plus the identifier there). Of course, static serialization cannot contain temporal instances? NO: in some cases, like logging, anything, including temporal instances, must be stored persistently.
Dynamic serialization occurs when I send some content to another active node, which can ask back for additional information as well. In this case, the content of the stream should be optimized by the number of other request that the target has to make when processing the stream content. Some of the referred entities it may already have; others it can miss and ask back for. To cut it short: the sender may add the content of any entity instances to a dynamic serialization, even though the target is not the primary source of that information. This happens if the aim of the communication is in fact to get that instance (like requesting a Person record from a node that owns them), or that they are required to understand the response (sending Address, or Medical records as well with the Person).
It is possible that the sender keeps a sort of log about which objects is had sent to the requester, because it is responsible for keeping them in sync with the actual state, or even add event communication to them (later, this is screen sharing and active teamwork), or at least to optimize the serialization content: send only if the information is not available on the requester side. Of course, this is just an optimization: the requester is allowed to reload all content again (the client may be restarted or lose any content independently from what the server knows about it).
When thinking about connecting to other nodes, we have to keep in mind that the endpoints may have different feature set. The most important is when the client is limited, like it has static type management, so it is simply unable to load a new type to understand the content of the serialization stream.
Level zero is to be able to build a stream connection and be able to transfer bytes through that line reliably. This is a lower level requirement that has to be solved with implementing the proper connector components; as long as I work with Java or other higher level languages, this should be a no issue. However, it also means that I must pack the stream operations into units as well, otherwise I might surprise myself when moving to a more limited environment.
The first level is that both ends must be able to parse and write the stream, that is: be able to handle the actual syntax. This means having Serializer component implementation, and the language elements for that syntax. This is a reference to an existing declarative information package, the EBNF-like declaration of the JSON language, which is actually used to parse and generate JSON streams (and in the hand of the Serializer, a valid JSON serialization) works just like the type declaration themselves. They are persistent entity instances, can be referred to, etc.
So, the limited client has the JSON language definition compiled into its codebase, and the client introduction contains the reference to that instance along with the statement that it is a static client, and cannot handle additional stream formats. When a stream connection is made, this information is used, and the more dynamic node can adapt to this requirement, optionally download the required language definition.
The second level is the content type set. Again, a static client may have final set of types, perhaps encoded again. This is a more generic limitation affecting any environment that is unable to load codes and object dynamically. For example the GWT environment can adapt to additional stream syntax, because if it has the generic EBNF code set, a new syntax is just another structure made from them. However, the GUI declaration types are final, a "Table" type is mapped to one specific code; it is not able to understand new, derived Table types. On a really static client this is also not a question: it is not even able to download and integrate new Type definitions.
So, a limited client introduction can also contain that it has a final type set, and the identifiers of the accepted types. The dynamic sender must "downcast" its content to the required types, and skip aspects that are of types unknown to the client. Naturally, this may result errors because of the lack of required references - the sender must handle these situations. But at least, they are visible...
It is very hard to get rid of old habits and choose a more complex-looking solution (which is complex only until we peek under the hood of the programming language where the problems are hidden).
I thought (and programmed in this way many times) that collections are generic part of data management. Again: they are not. Collections are aspects themselves, they either are part of the owner entity (like: subpanels of a window, scheduled commands of the scheduler, etc.) or referred internal entity members. Yes, the last time I have said that I did not need a collection directly, but only the iteration/search function - but forgot to mention the term "temporary". It is true that I don't need temporary collections, but the object themselves do contain many collections. If they are hidden under the "variant" layer, I have returned to the same problem of temporary collections, but under the hood with expressions for example.
So: Variants do not have multi-value content. If there is a need of it, it is a reference to a Collection aspect or entity. When expression evaluation encounters such a reference, that is again an accumulate / broadcast / search action (and reintroduce the parallel execution on this very low level).
Serialization
When different nodes communicate, they need to serialize their content. This component is responsible for working with references (independent of the actual implementation or the syntax of the stream). The generic solution is that each serialization action contains an ID map, where the unique id of the entity instance and a local, action-unique id is connected. The local id is used all the time, while the content is pushed into the stream only on the first call, when the item is registered into the map. In this way both sides have the simplest way to write and read the self referring structures properly.
Very important: the mapping must be set when starting the serialization: the referred entities may contain back references to the entity being serialized. They must receive the local id only, not start a recursive serialization process. On the other hand: anytime a local id based reference is resolved, the instance itself should be considered "final", but may be incomplete, and its content should not be used at this time. The read process should end with an independent initialization action after all referred components are read.
Content in serialization
From the content point of view, we have static and dynamic serialization.
Static is when I want to store and "remember" something as it is, like a configuration file: I want to keep some settings... NO! The config files are actually the primary source of the stored instances! Hmm... This means that for persistent entities, I have to serialize the content only if that serialization is actually the primary storage for those instances. All the others must only be stored by their unique identifiers (global type Id plus the identifier there). Of course, static serialization cannot contain temporal instances? NO: in some cases, like logging, anything, including temporal instances, must be stored persistently.
Dynamic serialization occurs when I send some content to another active node, which can ask back for additional information as well. In this case, the content of the stream should be optimized by the number of other request that the target has to make when processing the stream content. Some of the referred entities it may already have; others it can miss and ask back for. To cut it short: the sender may add the content of any entity instances to a dynamic serialization, even though the target is not the primary source of that information. This happens if the aim of the communication is in fact to get that instance (like requesting a Person record from a node that owns them), or that they are required to understand the response (sending Address, or Medical records as well with the Person).
It is possible that the sender keeps a sort of log about which objects is had sent to the requester, because it is responsible for keeping them in sync with the actual state, or even add event communication to them (later, this is screen sharing and active teamwork), or at least to optimize the serialization content: send only if the information is not available on the requester side. Of course, this is just an optimization: the requester is allowed to reload all content again (the client may be restarted or lose any content independently from what the server knows about it).
Format and type negotiation
Level zero is to be able to build a stream connection and be able to transfer bytes through that line reliably. This is a lower level requirement that has to be solved with implementing the proper connector components; as long as I work with Java or other higher level languages, this should be a no issue. However, it also means that I must pack the stream operations into units as well, otherwise I might surprise myself when moving to a more limited environment.
The first level is that both ends must be able to parse and write the stream, that is: be able to handle the actual syntax. This means having Serializer component implementation, and the language elements for that syntax. This is a reference to an existing declarative information package, the EBNF-like declaration of the JSON language, which is actually used to parse and generate JSON streams (and in the hand of the Serializer, a valid JSON serialization) works just like the type declaration themselves. They are persistent entity instances, can be referred to, etc.
So, the limited client has the JSON language definition compiled into its codebase, and the client introduction contains the reference to that instance along with the statement that it is a static client, and cannot handle additional stream formats. When a stream connection is made, this information is used, and the more dynamic node can adapt to this requirement, optionally download the required language definition.
The second level is the content type set. Again, a static client may have final set of types, perhaps encoded again. This is a more generic limitation affecting any environment that is unable to load codes and object dynamically. For example the GWT environment can adapt to additional stream syntax, because if it has the generic EBNF code set, a new syntax is just another structure made from them. However, the GUI declaration types are final, a "Table" type is mapped to one specific code; it is not able to understand new, derived Table types. On a really static client this is also not a question: it is not even able to download and integrate new Type definitions.
So, a limited client introduction can also contain that it has a final type set, and the identifiers of the accepted types. The dynamic sender must "downcast" its content to the required types, and skip aspects that are of types unknown to the client. Naturally, this may result errors because of the lack of required references - the sender must handle these situations. But at least, they are visible...
Feliratkozás:
Bejegyzések (Atom)