Administrator
|
Hei,
Huomaan olevani pahasti/hyvästi addiktoitunut käyttämään useita Survoja yhtaikaa! Se on tehokas työtapa, kun pitää hoitaa erilaisia töitä/projekteja/toimia/tehtäviä/..., ja yhden napin (alt-Tab) takana on kokoajan aktiiviset näkymät kaikkien näiden toimituskenttiin, joissa on kesken milloin mitäkin. Olennaista on, että väliaikaisten tiedostojen hakemisto eli tempdisk on eri joka instanssilla (session_tmp=1 APU-eli Auxiliary Parameter Updates -tiedostossa). Tyypillinen määrä yhtaikaisia Survoja on minulla 2-3, jos käytän SURVO MM:ää. Sen sijaan SURVO R:ää olen vain harvoin kahdentanut, koska siinä jokainen uusi instanssi vaatii alleen oman R:n, mikä valitettavasti hankaloittaa tällaista toimintaa. Olisiko ideaa, että tämä(kin) toiminto toteutettaisiin voimallisemmin Survon sisällä? Tuli vain yhtäkkiä äsken mieleen (ja siksi kirjoitin heti tänne), että toiminnon voisi kenties toteuttaa välilehtinä (engl. tab), vrt. esim. nettiselaimet ym. Siis niin, että Survo-näkymien (ts. auki olevien toimituskenttien) välillä voisikin vaihdella napilla ctrl-Tab. Nettiselaimessa minulla on tälläkin hetkellä auki 8 välilehteä. Voisi olla aika vinhaa saada vastaava moniajomaisema Survon sisään. SURVO R:ssä olisi tyrkyllä headline:lta tyhjäksi jäänyt ylärivi... :) Tämähän ei ole ainoa analogia Survon ja nettiselaimen välillä. Toinen on viitelista, jonka Seppo keksi aika samoihin aikoihin kuin nettiselaimet alkoivat yleistyä. Sehän on ihan vastaava tekniikka kuin selainten suosikkilistat/kirjanmerkit. Käytän viitelistoja erittäin paljon, minulla on useita satoja linkkejä eri puolille hakemistojani. Periaatteessa (ja käytännössäkin!) ne mahdollistavat kätevän töiden välillä hyppimisen, mutta eivät ne sille pärjää, että ajelee parilla kolmella Survolla yhtaikaa. Olennaisinta viitelistoissa on se, että niiden avulla löytää työkohteensa ilman että tarvitsee turvautua käyttöjärjestelmän tarjoamiin hakutoimintoihin. Mitä ajatuksia tämä teissä herättää? - Kimmo |
Mä pidän tuota tosi hyvänä ajatuksena. Itsellänikin on "paha" tapa pitää useita istuntoja (parhaimmillaan/pahimmillaan jopa 6-8) auki, kun on erilaisia juttuja. Osa saattaa olla vain esim. R-skriptien ajamista varten. Etenkin kun ei käytä R:n toimintoja, niin tuo R:n konsoli-ikkunan on melko turha olla näkyvillä.
|
Administrator
|
In reply to this post by Kimmo Vehkalahti
Välilehtiajattelu ei ole uutta vaan sellainen on kytenyt minulla mielessä jo ennen SURVO R:n tai edes Musteen ensimmäisiä versioita. Valitettavasti kunnon toteutus on kaikkea muuta kuin helppo. Aito moniajo yhden R:n alaisuudessa on sula mahdottomuus. Oma temppihakemisto on triviaali juttu siihen nähden, että kaikki ei-paikalliset muuttujat niin R- kuin C-koodissa pääsevät sotkeutumaan tai siihen, että Tcl/Tk:n eventtien pitäisi ohjautua oikeisiin paikkoihin. Uuden R:n avaaminen ratkaisee kaikki nämä ongelmat, joten pieni ylimääräisistä R-kuvakkeista aiheutuva "kömpelyys" alt-tab vaihdoissa on oikeasti minimaalinen haitta, jos mietitään minkämoisista fundamentaalisista asioista puhutaan. Toisin sanoen moniajo ilman uuden R:n käynnistämistä ei tule toteutumaan. Täysin toinen asia on ajatella välilehtiä samaan aikaan avoimina olevina toimituskenttinä, joista kuitenkin vain yksi kerrallaan voi olla aktiivinen. Kyseessähän ei siis silloin ole mistään aidosta usean Survon käytöstä vaan tarpeesta poukkoilla "projektista toiseen". Sehän itse asiassa vastaa pitkälti sitä, että välilehdeltä toiselle siirryttäessä viitelistamaisesti siirryttäisiin paikasta toiseen ja samalla vaihdettaisiin "sessiomuuttujia" ja rajallista määrää globaaleja kontrolliparametreja niin, että näkymä päivittyy automaattisesti toivotunlaiseksi ja väliaikaistiedostot ohjautuvat oikeaan paikkaan. Ilmeisesti tällainen riittäisi suurimpaan osaan "monen Survon" käyttötarpeista?!? Tällaisen toiminnan implementointi voisi olla realistinen vaihtoehto ja ehkäpä sitä voisi lähteä jopa kokeilemaan. Vähän kypsyttelyä kuitenkin vaatii.. |
Administrator
|
Hauska kuulla, että olen puhaltanut kytevään liekkiin. Kirjoitin tosiaan samantien, kun ajatus pälkähti päähäni. Vasta pari tuntia ennen Reijon vastausta tajusin, että olin hivenen huolimattomasti käyttänyt käsitettä "moniajo", vieläpä kirjoitukseni otsikossa. On todella syytä tehdä selvä ero kahden erilaisen käyttötavan välillä: (1) moniajo, jossa kaikki työt edistyvät (käyttäjän näkökulmasta) yhtaikaa (2) "vuoroajo", jossa etualalla oleva työ edistyy ja taustalla olevat odottavat Yhteistä tavoille (1) ja (2) on oman ympäristön (mm. temppihakemisto) määrittely kullekin työlle, mutta kuten Reijo toteaa, varsinaiset tekniset haasteet etenkin (1):n osalta vasta alkavat siitä. No jos nyt mikään meille milloinkaan riittää... :) Käyttötarpeet vaihtelevat varmaankin käyttäjästä toiseen, mutta minulle tuo kyllä riittäisi päivittäiseen työskentelyyn oikein hyvin. Sen sijaan automatisoitujen prosessien ajamiseen (jota mm. Petrillä taitaa aika paljon esiintyä?) se ei sovi, mutta niihin sopisikin paremmin "eräajo" omassa "työjonossaan" (käyttääkseni 1980-luvun suurkoneympäristön käsitteitä; idea kuitenkin se, että omatoimisten prosessien ajamiseen ei tarvitse "tuhlata" interaktiivista "tietokoneaikaa"). Kannatan kypsyttelyä ja kokeilua! - Kimmo |
Näistä R-skriptien ajoista oli ainakin yksi malli täällä:
http://forum.survo.fi/R-skriptien-aktivointi-td116.html Minulla on tosiaan aika paljon pitkiä datanjalostusputkia (jotka liittyvät päivittyviin datoihin). Yleensä ne ovat sellaisia, jotka käynnistetään /ACTIVATE:lla (sisällä voi sitten olla mitä tahansa esim. R-skriptejä). Yksittäiset kokonaisuudet on pääasiassa eriytetty erillisiin .EDT kenttiin. Ajastukset on yksi juttu, jota olen miettinyt. Olisi paljon helpompaa, kun tietyt /ACTIVATE:t ja R-ajot voisi toteuttaa silla tavalla omatoimisesti "koneen" puolelta, että jonnekin on speksattu, miten usein mitkäkin prosessit ajetaan läpi (ja mahdollisesti missä järjestyksessä, jos prosessien välillä on riippuvaisuuksia, kuten toisinaan on). Vaikka koneet tekevät kaiken todella likaisen työn, niin nyt menee "aika paljon aikaa" siihen, että availee paljon erilaisia .EDT kenttiä, joista sitten vain käy painamassa /ACTIVATEa (no ei se nyt aina ihan niin yksinkertaista ole, kyllähän sitä koko ajan pienempiä ja isompiakin "puukotuksia" tulee tehtyä). Joo mut tää ehkä meni vähän otsikon sivuun... huomaan vaan että yksittäisten prosessien määrä on kasvanut sellaiseksi, että niiden hallintaan olisi alettava panostamaan :) |
***Ajastukset on yksi juttu, jota olen miettinyt. Vaikka vähän voi otsikosta sivussa ollakin, niin kyllä noi ajastukset pitäisi onnistua. Sonera-aikoinani jotain sellaisia tein. Survo-keskustelun arkistossa on siitä pieni juttukin: http://www.survo.fi/arkisto/000278.html Task Schedulen pitäisi nyt mielestäni Survo R:llä toimia vastaavasti, kun alotuksessa voi antaa käynnistettävä sukron :JVa |
Administrator
|
Tuolla näemmä olin myös muistutellut noista kasariaikaisista eräajoista, joita submitattiin erilaisiin työjonoihin. Sieltä ne sitten käynnistyivät aikaherätteellä ja raportoivat prosessin kulusta ja tuloksista. Kai nyt kaikkea tuota voi harrastaa nykysysteemeilläkin.
Olipa muuten Pentillä värikkäät kommentit mun ja Juhan viesteihin! :D Kaikkea tuolla arkistossa onkin... |
In reply to this post by Juha Valtonen
R-skriptejä olen ajastellut meidän palvelinkoneella, lähinnä rekisteriajoihin liittyen. Homma on yksinkertaista, on tehty batch tiedosto, jonne on listattu ajettavat R-skriptit, jotka taas voi ajaa vaikka windows command promptissa. En ole vielä ihan ymmärtänyt miten Survo R:llä voisi käynnistää (jonkun task schedulen avulla) Muste siten, että voitaisiin esim. aktivoida tietyssä kohtaa .EDT -kenttää oleva /ACTIVATE (ja sitten mieluusti sulkea ko. .EDT-istunto kun homma bueno, no joo F8+R nappula voitaneen liittää prosessiin?)... Survossahan oli virityksiä, jossa tietty .EDT voitiin avata työpöydällä olevasta pikakuvakkeesta (eli periaatteessa olisi ajastettavissa). |
Täällä
http://www.survo.fi/arkisto/000278.html missä vähän puhuttiin isosta datasta, niin tuli mieleen, et voitaisiinko jossain (esim. seminaarissa) ottaa aiheeksi tämän ns. big data. Miten Survo R pystyy tulevaisuudessa taklaamaan siihen liittyviä ongelmia. Esim. tekstimuotoisen (esim. web-sivustot, keskustelut, dokumentit) rooli tulee luultavasti kasvamaan. Osa dokumenttien analyysista tapahtuu tekoälyn toimesta jne. Datamäärät voivat olla valtavia. Esim. miten tekstidataa kannattaisi kuljettaa osana .SVOa jne. Olisiko ajateltavissa jokin datatyypin laajennus, joka mahdollistaisi paremmin vaikka kokonaisen kirjan sisältämän merkkijonon säilyttämistä datakentässä... oma lukunsa ovat sitten kuvat, videot ym, jotka ymmärtääkseni voi tallentaa tietokantoihin "bittimössönä". No taas livuttiin otsikosta aika lailla... |
In reply to this post by Kimmo Vehkalahti
... en sitten selkeästi tajunnut, että tässä R:n paketin nimikin muuttunut (Muste -> Survo R)? Mutta hyvä nimi! |
Administrator
|
Jep! Risteilyraportti kertoo kaiken kauniimmin: http://www.survo.fi/yhdistys/risteilyt.html |
Administrator
|
In reply to this post by Petri Palmu
Erittäin hyvä sivupolku. Voisi ajatella useampaakin tilaisuutta syksyllä? Big Data tulee nyt vastaan joka puolella. Tiedoksi juuri ilmestynyt teos: http://www.otteitaverkosta.fi/ |
In reply to this post by Kimmo Vehkalahti
Kun tuosta tulee R:n "virallinen" paketti, niin onko nimi RSurvo vai SurvoR? RSurvo lienee enemmän tyyli, jota paketeissa käytetty... Esim. RODBC. Vai jotain muuta? Täytyy alkaa totutella pois Musteesta ;) |
Administrator
|
Näillä näkymin Survo R:n (perus)paketin nimi tulee olemaan yksinkertaisesti survo. Survo R on kuitenkin sen verran laaja kokonaisuus, että CRAN-julkaisua varten se täytyy mahdollisesti jakaa useampaan pakettiin. Toistaiseksi työversion paketin nimenä pysyy muste, mutta jo nyt paketin lataamisen jälkeen Survo R:n editorin käynnistäminen onnistuu komennolla survo(). |
Free forum by Nabble | Edit this page |