[Modelinterpreter] source lookup

[Boldizsár Németh]

Sziasztok!

Akkor valószínűleg az én ismereteim túl hiányosak ebben a debug 
témakörben, vagy lemaradtam (akár címzettként, akár csak figyelmen kívül 
hagyva) némi levelezésről.

Amiből kiindultam:
  - Maga a java delegate nem befolyásolja közvetlenül a UI 
megjelenítést. (Tehát nincs benne olyan hívás, hogy most regisztráld be 
ezt, mint java debug alanyt.)
  - A jdt launcher egy rakás dolgot csinál, amit nem lenne jó copy-zni.
  - Ahhoz, hogy normálisan tudjuk kezelni például a class betöltési 
eseményeket, szükségünk van egy (beregisztrált, normális kontextusban 
létező) JavaDebugTarget-re.

Próbáljuk akkor kitalálni, hogy merre is lehet itt haladni, mit kéne 
lecserélni és mire, mert úgy érzem információhiány van.

Boldi


On 2015.05.03. 16:01, kmate at caesar.elte.hu wrote:
> Sziasztok!
>
> Idézet (Boldizsár Németh <nboldi at caesar.elte.hu>):
>
>> Volt szó arról, hogy a user-nek nagy problémát okoz az, hogy a source 
>> lookup ellhalgatása nem megy, meg mindenféle daemon thread-ek 
>> indulnak, amikre resume-ot nyomva nem fut tovább a model.
>>
>> Ezzel kapcsolatban arra kaptam kérést, hogy jdt launch-ot valahogy 
>> váltsuk ki. Azonban alaposabban utánajárva a témába elég valószínűnek 
>> tűnik, hogy a jdt launch-nak ehhez nincs sok köze, mivel ez egy 
>> launch szintű tool, az meg egy ui viselkedés, amin változtatni 
>> akarunk. Valójában itt az a bibi, hogy a futó launch egy jdt launch, 
>> és ennek megfelelően működnek az ui komponensek is.
>> Azonban ennek megvalátoztatását én nem tartom reálisnak. Abból, amit 
>> láttam belőle, mélyen át kellene írnunk az eclipse működését. Persze 
>> lehet, hogy éppen van rá valami rövid, nem olyan csúnya megoldás, de 
>> nagy esélyt erre nem látok.
>
> Boldi, olvastad a korábbi levelem, de komolyan? :)
>
>> Két út marad amit követni lehet.
>>
>> Az első egy rövid távú megoldás. A source lookup-ot várhatóan át 
>> tudom úgy alakítani, hogy valami olyasmit nyisson meg, ami értelmes, 
>> például a modellt, amit végre akarunk hajtani. Sajnos, ha azt mondom, 
>> hogy semmit, az ui rész akkor is megnyit egy tab-ot, amiben az lesz, 
>> hogy error, mert a source lookup semmit mondott az adott stack 
>> frame-hez, szóval ez nem nyerő. Amúgy kb ez is lenne az elvárt 
>> viselkedés. A deamon thread-eket meg talán ki lehet küszöbölni, mert 
>> elvileg ilyeneknek nem kellene futni.
>
> Most is két debug modellünk van, és ez az egyik legnagyobb baj, ami az 
> összes többit okozza.
> A lényeg az lenne, hogy egyet (moka-sat) használjunk megfelelően;
> az általad említett első opciót pedig elvileg elvetettük.
>
> Ha nem így van szóljatok, de redundánsnak tűnnek a dolgok itt.
>
>> A második, komolyabb erőfeszítésekkel járó út (ami valószínűleg még 
>> az előbbihez adódik hozzá) az, hogy saját debug modellünk legyen. Ez 
>> egy ui szintű komponens, ami meghatározná a debug környezetet. Ezzel 
>> kapcsolatban azonban még sok a kérdőjel, és szerintem legjobb esetben 
>> is csak május végére lehet belőle valami.
>
> Én végig azt hittem, hogy ezt fejlesztjük ki ebben a hónapban. Nem 
> kell csodákat tennie, két része van:
> 1) debug target: a vm és a user interface minimális eseményeire kell 
> válaszolni, nem mindre, sokat le lehet tiltani és ignorálni (step 
> over, step in, stb...)
> 2) debug model: semmi nem kell bele, esetleg a state-et meg lehet 
> mutatni, amin állunk, egy nagyjából 2 perces meló, de még ez sem kéne.
>
> Az elsőt megírtuk, más formában. A másodikkal meg kb. semmi dolgunk 
> nincs. A launch kiváltása nagyjából copy-paste, ezen lehetne dolgozni 
> (saját debug vm indítás valamilyen módon: attach/listen/launch). 
> Kedden délután tudok vele foglalkozni, addig még írogassunk, csak 
> feleslegesen rossz irányba ne menjetek, mert az kidobott idő.
>
> Várom az egyéb reflexiókat a témában.
>
> Üdv,
>  Máté
>
>
> _______________________________________________
> Modelinterpreter mailing list
> Modelinterpreter at plc.inf.elte.hu
> https://plc.inf.elte.hu/mailman/listinfo/modelinterpreter