Pyyttonillehan tehtiin VB6:t?

Kakkossarjaa tuetaan varmaan, mutta jos kolmosta ei tuettais ja se ei menestys niin siinähän se pyyttonin loppu ois. Eiköhän ois hyvä, että toi uus menestys kuten pistenettikin?

Jepulis Jeep kirjoitti:

Kakkossarjaa tuetaan varmaan, mutta jos kolmosta ei tuettais ja se ei menestys niin siinähän se pyyttonin loppu ois. Eiköhän ois hyvä, että toi uus menestys kuten pistenettikin?

Lue lisää

"Kakkossarjaa tuetaan varmaan, mutta jos kolmosta ei tuettais ja se ei menestys niin siinähän se pyyttonin loppu ois."

En näe syytä miksi ei menestyisi. Python on hyvä kieli ja kolmonen paransi asioita siellä ja täällä. Aikaa toki menee varmaan 5v ennen kuin siihen on kunnolla siirrytty.

VB.NET ei ole erityisen menestynyt. Lähinnä on muutettu jotain legacy VB-ohjelmia sille mutta uusia ei tehdä juuri mitään.

M-Kar kirjoitti:

"Kakkossarjaa tuetaan varmaan, mutta jos kolmosta ei tuettais ja se ei menestys niin siinähän se pyyttonin loppu ois."

En näe syytä miksi ei menestyisi. Python on hyvä kieli ja kolmonen paransi asioita siellä ja täällä. Aikaa toki menee varmaan 5v ennen kuin siihen on kunnolla siirrytty.

VB.NET ei ole erityisen menestynyt. Lähinnä on muutettu jotain legacy VB-ohjelmia sille mutta uusia ei tehdä juuri mitään.

Lue lisää

En nää myöskään syytä miksei menestyis. Ohan toi kiistämäsi .NET:n menestys näyttänyt kivasti tietä samanlaisille mahollisuuksille.

Mukavasti tehään uuttakin.

Oon miettinyt ton homman ihan tarpeeks tarkkaan.

Eka rivis tulostaa ykkösen ja toinen taas ei kelpaa semmosenaan veepeepistenetille. Ikävä homma muuten jos tommosta ilmasua tarttee jossain kielessä yleensäkin käytellä.

Jepulis Jeep kirjoitti:

Oon miettinyt ton homman ihan tarpeeks tarkkaan.

Eka rivis tulostaa ykkösen ja toinen taas ei kelpaa semmosenaan veepeepistenetille. Ikävä homma muuten jos tommosta ilmasua tarttee jossain kielessä yleensäkin käytellä.

Lue lisää

Eka rivi tulostaa VB Scriptillä ajettuna 65537, mikä on selvä bugi.

Jepulis Jeepin raportoima VB.NETin tulostama luku, 1, on se, mitä normaalisti tuosta odottaisi saavansakin. Oho! Onko Microsoft oikeasti korjannut jotain?

Mielenkiinnosta asensin Visual Basic 2008 Expressin virtuaalikoneeseen. VB.NETin IDE (Visual Studio 2009 v. 9.30729.1) halusi välttämättä syödä nollat esim. &H0000FFFF:stä, eli muutti sen editorissa muotoon &HFFFF. Vastaava muunnos on todennäköisesti takana myös aluksi mainitsemassani VB Scriptin bugissa.

IDEn Mouse-over helppi näytti &HFFFF:n kohdalla "Represents a signed 32-bit integer". Ahaa. VB Scriptin bugi ei siis enää esiinny, koska &H0000FFFF:ää ei tulkita virheellisesti 16-bittiseksi etumerkilliseksi luvuksi. No, ohjeen mukaan VB.NETissähän on 64-bittiset kokonaisluvutkin: Long ja ULong. Kokeilin sitten alustaa 64-bittisen muuttujan seuraavasti:

Dim l as ULong = &H0000000080008000

minkä editori tietysti muutti muotoon

Dim l as ULong = &H80008000

ja tuloksenahan on käännösvirhe: "Constant expression not representable in type 'ULong'", eikä ohjelmaa voi ajaa. Eipä siis tarvinnut montaa minuuttia käyttää tätäkään VB:tä, kun siitäkin löytyi jo bugi: 64-bittistä lukua, jonka ensimmäiset 32 bittiä ovat nollia, ei voi sijoittaa etumerkittömään 64-bittiseen muuttujaan. Kaikenlaisia työkaluja sitä jotkut jaksavat mainostaa näillä palstoilla.

Toisen antamani rivin suorittamiseksi piti näköjään kirjoittaa VB.NETissä moduulin alkuun "Imports System.Math". Ja vastaushan varsinaiseen laskutoimitukseen, Round(2.5)-Round(1.5) on tässäkin VB:n versiossa hieman yllättävä: 0.

Vastoin kuin edellä mainitsemani kääntäjän bugi, tämä on itse asiassa dokumentoitu feature. Tällaiset "meidän kielessä tutut jutut toimivat vähän eri tavalla"-henkiset ratkaisut tekevät VB:n käytöstä todella vastenmielistä kenelle tahansa vähänkin kokeneemmalle ohjelmoijalle.

TRRY kirjoitti:

Eka rivi tulostaa VB Scriptillä ajettuna 65537, mikä on selvä bugi.

Jepulis Jeepin raportoima VB.NETin tulostama luku, 1, on se, mitä normaalisti tuosta odottaisi saavansakin. Oho! Onko Microsoft oikeasti korjannut jotain?

Mielenkiinnosta asensin Visual Basic 2008 Expressin virtuaalikoneeseen. VB.NETin IDE (Visual Studio 2009 v. 9.30729.1) halusi välttämättä syödä nollat esim. &H0000FFFF:stä, eli muutti sen editorissa muotoon &HFFFF. Vastaava muunnos on todennäköisesti takana myös aluksi mainitsemassani VB Scriptin bugissa.

IDEn Mouse-over helppi näytti &HFFFF:n kohdalla "Represents a signed 32-bit integer". Ahaa. VB Scriptin bugi ei siis enää esiinny, koska &H0000FFFF:ää ei tulkita virheellisesti 16-bittiseksi etumerkilliseksi luvuksi. No, ohjeen mukaan VB.NETissähän on 64-bittiset kokonaisluvutkin: Long ja ULong. Kokeilin sitten alustaa 64-bittisen muuttujan seuraavasti:

Dim l as ULong = &H0000000080008000

minkä editori tietysti muutti muotoon

Dim l as ULong = &H80008000

ja tuloksenahan on käännösvirhe: "Constant expression not representable in type 'ULong'", eikä ohjelmaa voi ajaa. Eipä siis tarvinnut montaa minuuttia käyttää tätäkään VB:tä, kun siitäkin löytyi jo bugi: 64-bittistä lukua, jonka ensimmäiset 32 bittiä ovat nollia, ei voi sijoittaa etumerkittömään 64-bittiseen muuttujaan. Kaikenlaisia työkaluja sitä jotkut jaksavat mainostaa näillä palstoilla.

Toisen antamani rivin suorittamiseksi piti näköjään kirjoittaa VB.NETissä moduulin alkuun "Imports System.Math". Ja vastaushan varsinaiseen laskutoimitukseen, Round(2.5)-Round(1.5) on tässäkin VB:n versiossa hieman yllättävä: 0.

Vastoin kuin edellä mainitsemani kääntäjän bugi, tämä on itse asiassa dokumentoitu feature. Tällaiset "meidän kielessä tutut jutut toimivat vähän eri tavalla"-henkiset ratkaisut tekevät VB:n käytöstä todella vastenmielistä kenelle tahansa vähänkin kokeneemmalle ohjelmoijalle.

Lue lisää

Pukeja löytyy ja niitä korjataan. Ihan samalla tavalla vpnetissä kun vaikka pyyttonissa.

3985    yesterday     removed string module from distutils [patch]    open    tarek    tarek
2461    yesterday    test_util.py for distutils    open    tarek    tarek
4015    yesterday    [patch] make installed scripts executable on windows    open    techtonik    
4636    yesterday    bdist_wininst installer with install script raises exception    open    theller    tarek
4931    yesterday    distutils does not show any error msg when can't build C module extensions due to a missing C compiler    open    giampaolo.rodola    tarek
2636    2 days ago    Regexp 2.7 (modifications to current re 2.2.2)    open    timehorse    
4111    2 days ago    Add DTrace probes    open    bretthoerner    skip.montanaro
5159    2 days ago    Indicating packages to be loaded when a Tcl interpreter is created in tkinter    open    gpolo    
1693050    2 days ago    \w not helpful for non-Roman scripts    open    nathanlmiles    
1519638    2 days ago    Unmatched Group issue - workaround    open    nneonneo    effbot
763043    2 days ago    unable to specify another compiler    open    doko    tarek
1032    2 days ago    Improve the hackish runtime_library_dirs support for gcc    open    alexandre.vassalotti    loewis
793069    2 days ago    Add --remove-source option    open    davidfraser    tarek
1481347    2 days ago    parse_makefile doesn't handle $$ correctly    open    hanwen    
1371826    2 days ago    distutils is silent about multiple -I/-L/-R    open    montanaro.historic    
5145    2 days ago    struct.calcsize('cd') returns 16 instead of 9    open    bgailer    georg.brandl
901727    2 days ago    extra_path kwarg to setup() undocumented    open    bob.ippolito    tarek
5141    2 days ago    C API for appending to arrays    open    hniksic    
1757126    2 days ago    [PATCH] Fix ptcp154 encoding cyrillic_asian alias    open    pjenvey    
5148    2 days ago    gzip.open breaks with 'U' flag    open    Chris.Barker    
5155    2 days ago    Multiprocessing.Queue created by sub-process fails when used in sub-sub-process ("bad file descriptor" in q.get())    open    bbutler    jnoller
691291    2 days ago    codecs.open(filename, 'U', 'UTF-16') corrupts text    open    jorend    
2236    3 days ago    Distutils' mkpath implementation ignoring the "mode" parameter    open    henrique    gward
5154    3 days ago    OSX broken poll testing doesn't work    open    bbangert    
2942    3 days ago    mingw/cygwin do not accept asm file as extension source    open    shura_zam    
3871    3 days ago    cross and native build of python for mingw32 with distutils    open    rpetrov    
5125    3 days ago    Strange locale problem with Python 3    open    retoo    
1079    3 days ago    decode_header does not follow RFC 2047    open    kael    
3959    3 days ago    Add Google's ipaddr.py to the stdlib    open    gvanrossum    
3783    3 days ago    dbm.sqlite proof of concept    open    skip.montanaro    rhettinger
4124    3 days ago    Patch for adding "default" to itemgetter and attrgetter    open    tebeka    rhettinger
2204    3 days ago    document ConfigParser behaviour when a file has same section multiple times    open    draghuram    georg.brandl
4577    3 days ago    distutils: -3 warnings (apply)    open    srittau    amaury.forgeotdarc
828336    3 days ago    Allow set swig include dirs in setup.py    open    wiget    tarek
809163    3 days ago    Can't add files with spaces    open    antonio    
808129    3 days ago    Change --changelog to accept files    open    tcampbell    
1019715    3 days ago    distutils ignores configure's --includedir    open    josephwinston    tarek
962772    3 days ago    when both maintainer and author provided, author discarded    open    jbelmonte    tarek
3166    3 days ago    Make conversions from long to float correctly rounded.    open    marketdickinson    marketdickinson
5109    3 days ago    array.array constructor very slow when passed an array object.    open    malcolmp    
3976    3 days ago    pprint._safe_repr is not general enough in one instance    open    erickt    
4947    3 days ago    sys.stdout fails to use default encoding as advertised    open    stevenjd    
5128    3 days ago    compileall: consider ctime    open    gagern    brett.cannon
4347    3 days ago    Circular dependency causes SystemError when adding new syntax    open    thomas.lee    brett.cannon
2578    3 days ago    Figure out what to do with unittest's redundant APIs    open    benjamin.peterson    gregory.p.smith
2422    3 days ago    Automatically disable pymalloc when running under valgrind    open    jamesh    
5149    3 days ago    syntactic sugar: type coercion on pointer assignment    open    PeterASilva    theller
2124    3 days ago    xml.sax and xml.dom fetch DTDs by default    open    akuchling    akuchling
5094    3 days ago    datetime lacks concrete tzinfo impl. for UTC    open    brett.cannon    brett.cannon
977470    4 days ago    Deleted files are reinstalled    open    andersjm    

Tossahan ois ollut näiden mallien lisäksi muutama tuhat pyyttonin pukia lisääkin. Ihmettelen vaan kovasti, miten joku pukijuttu voi tulla yllätyksenä tai yhmettelyn aiheena jos oot kerran ollut pitkään alalla.

Varmasti eroavaisuudet aiheuttaa vastenmielisyyttä semmosissa ihmisissä jotka eivät osaa sopeutua muuttuneisiin tilanteisiin. Ite tykkään tosta pistenetistä. Kiva systeemi ja sillä saa aikaan hommansa hyvin ja helposti.

Ihme juttu jos joku oottaa virheettömyyttä kun eihän semmosta voi olla.

Jepulis Jeep kirjoitti:

Pukeja löytyy ja niitä korjataan. Ihan samalla tavalla vpnetissä kun vaikka pyyttonissa.

3985    yesterday     removed string module from distutils [patch]    open    tarek    tarek
2461    yesterday    test_util.py for distutils    open    tarek    tarek
4015    yesterday    [patch] make installed scripts executable on windows    open    techtonik    
4636    yesterday    bdist_wininst installer with install script raises exception    open    theller    tarek
4931    yesterday    distutils does not show any error msg when can't build C module extensions due to a missing C compiler    open    giampaolo.rodola    tarek
2636    2 days ago    Regexp 2.7 (modifications to current re 2.2.2)    open    timehorse    
4111    2 days ago    Add DTrace probes    open    bretthoerner    skip.montanaro
5159    2 days ago    Indicating packages to be loaded when a Tcl interpreter is created in tkinter    open    gpolo    
1693050    2 days ago    \w not helpful for non-Roman scripts    open    nathanlmiles    
1519638    2 days ago    Unmatched Group issue - workaround    open    nneonneo    effbot
763043    2 days ago    unable to specify another compiler    open    doko    tarek
1032    2 days ago    Improve the hackish runtime_library_dirs support for gcc    open    alexandre.vassalotti    loewis
793069    2 days ago    Add --remove-source option    open    davidfraser    tarek
1481347    2 days ago    parse_makefile doesn't handle $$ correctly    open    hanwen    
1371826    2 days ago    distutils is silent about multiple -I/-L/-R    open    montanaro.historic    
5145    2 days ago    struct.calcsize('cd') returns 16 instead of 9    open    bgailer    georg.brandl
901727    2 days ago    extra_path kwarg to setup() undocumented    open    bob.ippolito    tarek
5141    2 days ago    C API for appending to arrays    open    hniksic    
1757126    2 days ago    [PATCH] Fix ptcp154 encoding cyrillic_asian alias    open    pjenvey    
5148    2 days ago    gzip.open breaks with 'U' flag    open    Chris.Barker    
5155    2 days ago    Multiprocessing.Queue created by sub-process fails when used in sub-sub-process ("bad file descriptor" in q.get())    open    bbutler    jnoller
691291    2 days ago    codecs.open(filename, 'U', 'UTF-16') corrupts text    open    jorend    
2236    3 days ago    Distutils' mkpath implementation ignoring the "mode" parameter    open    henrique    gward
5154    3 days ago    OSX broken poll testing doesn't work    open    bbangert    
2942    3 days ago    mingw/cygwin do not accept asm file as extension source    open    shura_zam    
3871    3 days ago    cross and native build of python for mingw32 with distutils    open    rpetrov    
5125    3 days ago    Strange locale problem with Python 3    open    retoo    
1079    3 days ago    decode_header does not follow RFC 2047    open    kael    
3959    3 days ago    Add Google's ipaddr.py to the stdlib    open    gvanrossum    
3783    3 days ago    dbm.sqlite proof of concept    open    skip.montanaro    rhettinger
4124    3 days ago    Patch for adding "default" to itemgetter and attrgetter    open    tebeka    rhettinger
2204    3 days ago    document ConfigParser behaviour when a file has same section multiple times    open    draghuram    georg.brandl
4577    3 days ago    distutils: -3 warnings (apply)    open    srittau    amaury.forgeotdarc
828336    3 days ago    Allow set swig include dirs in setup.py    open    wiget    tarek
809163    3 days ago    Can't add files with spaces    open    antonio    
808129    3 days ago    Change --changelog to accept files    open    tcampbell    
1019715    3 days ago    distutils ignores configure's --includedir    open    josephwinston    tarek
962772    3 days ago    when both maintainer and author provided, author discarded    open    jbelmonte    tarek
3166    3 days ago    Make conversions from long to float correctly rounded.    open    marketdickinson    marketdickinson
5109    3 days ago    array.array constructor very slow when passed an array object.    open    malcolmp    
3976    3 days ago    pprint._safe_repr is not general enough in one instance    open    erickt    
4947    3 days ago    sys.stdout fails to use default encoding as advertised    open    stevenjd    
5128    3 days ago    compileall: consider ctime    open    gagern    brett.cannon
4347    3 days ago    Circular dependency causes SystemError when adding new syntax    open    thomas.lee    brett.cannon
2578    3 days ago    Figure out what to do with unittest's redundant APIs    open    benjamin.peterson    gregory.p.smith
2422    3 days ago    Automatically disable pymalloc when running under valgrind    open    jamesh    
5149    3 days ago    syntactic sugar: type coercion on pointer assignment    open    PeterASilva    theller
2124    3 days ago    xml.sax and xml.dom fetch DTDs by default    open    akuchling    akuchling
5094    3 days ago    datetime lacks concrete tzinfo impl. for UTC    open    brett.cannon    brett.cannon
977470    4 days ago    Deleted files are reinstalled    open    andersjm    

Tossahan ois ollut näiden mallien lisäksi muutama tuhat pyyttonin pukia lisääkin. Ihmettelen vaan kovasti, miten joku pukijuttu voi tulla yllätyksenä tai yhmettelyn aiheena jos oot kerran ollut pitkään alalla.

Varmasti eroavaisuudet aiheuttaa vastenmielisyyttä semmosissa ihmisissä jotka eivät osaa sopeutua muuttuneisiin tilanteisiin. Ite tykkään tosta pistenetistä. Kiva systeemi ja sillä saa aikaan hommansa hyvin ja helposti.

Ihme juttu jos joku oottaa virheettömyyttä kun eihän semmosta voi olla.

Lue lisää

> Pukeja löytyy ja niitä korjataan. Ihan samalla tavalla vpnetissä kun vaikka pyyttonissa.

Kokemusteni mukaan väitteesi "ihan samalla tavalla"-osa on täysin väärin.

Käytin edellistä postausta varten VB.NETtiä alle puoli tuntia heti ensiasennuksen jälkeen, kun löysin ensimmäisen bugin sen *kääntäjästä*. Jos niitä löytyy Pythonista "samalla tavalla", niin kuin väität, niin ole hyvä ja käynnistä nyt Python ja etsi bugi sen *kääntäjästä*.

Olen kauan sitten joutunut tekemään töitä VB:llä. Vaikka tein ihan vain rutiinijuttuja, niin tämän tason kummallisuuksia tuli vastaan muitakin. Myöhemmin olen saanut naureskella kahvipöydässä sellaisten ohjelmoijien jutuille, jotka yrittävät käyttää VB.NETtiä ihan oikeiden ohjelmien tekemiseen. Niiden juttujen perusteella en ole nähnyt VB:n bug^H^H^Hjäävuoresta edes huippua.

Pythonia olen ehtinyt härnätä VB:tä kauemmin ja huomattavan paljon rankemmin (mm. rinnakkaisuutta, hajautusta, ajonaikaista ohjelmarakenteiden muokkausta ja debuggeria). En ole koko aikana törmännyt kuin yhteen rinnakkaisuuteen liittyvään bugiin, joka oli tosin sekin korjattu heti seuraavassa releasessa.


Millään tavalla reilun vertailun sijaan päädyit postaamaan otteen Pythonin bugi/muutostietokannasta. Sehän on kaikille avoin, vastoin kuin VB.NETin bugitietokanta. Mutta mahdoitko yhtään katsoa mitä listassa oikein oli?

Listan ensimmäinen ei ole bugi, vaan distutils-kirjaston modernisointi. Kyseessä on kirjasto, joka mahdollistaa Python-softien äärimmäisen helpon alustariippumattoman asennuksen. Tällaisesta VB.NET-käyttäjät eivät edes ymmärrä uneksia.

Listan toinen kohta lisää Pythonin samaiseen distutils-kirjastoon uuden moduulitestin. Jos näet jossain bugin, niin kerro.

On listalla oikeita bugejakin, mutta ei mitään triviaalia. Ei esimerkiksi täysin laillista sijoituslausetta, jota kääntäjä ei suostu kääntämään. ;)

> Ihme juttu jos joku oottaa virheettömyyttä kun eihän semmosta voi olla.

Jos sinäkin kokeilisit tehdä töitä hyvillä työkaluilla, niin oppisit vaatimaan edes jonkinlaista laatua.

TRRY kirjoitti:

> Pukeja löytyy ja niitä korjataan. Ihan samalla tavalla vpnetissä kun vaikka pyyttonissa.

Kokemusteni mukaan väitteesi "ihan samalla tavalla"-osa on täysin väärin.

Käytin edellistä postausta varten VB.NETtiä alle puoli tuntia heti ensiasennuksen jälkeen, kun löysin ensimmäisen bugin sen *kääntäjästä*. Jos niitä löytyy Pythonista "samalla tavalla", niin kuin väität, niin ole hyvä ja käynnistä nyt Python ja etsi bugi sen *kääntäjästä*.

Olen kauan sitten joutunut tekemään töitä VB:llä. Vaikka tein ihan vain rutiinijuttuja, niin tämän tason kummallisuuksia tuli vastaan muitakin. Myöhemmin olen saanut naureskella kahvipöydässä sellaisten ohjelmoijien jutuille, jotka yrittävät käyttää VB.NETtiä ihan oikeiden ohjelmien tekemiseen. Niiden juttujen perusteella en ole nähnyt VB:n bug^H^H^Hjäävuoresta edes huippua.

Pythonia olen ehtinyt härnätä VB:tä kauemmin ja huomattavan paljon rankemmin (mm. rinnakkaisuutta, hajautusta, ajonaikaista ohjelmarakenteiden muokkausta ja debuggeria). En ole koko aikana törmännyt kuin yhteen rinnakkaisuuteen liittyvään bugiin, joka oli tosin sekin korjattu heti seuraavassa releasessa.


Millään tavalla reilun vertailun sijaan päädyit postaamaan otteen Pythonin bugi/muutostietokannasta. Sehän on kaikille avoin, vastoin kuin VB.NETin bugitietokanta. Mutta mahdoitko yhtään katsoa mitä listassa oikein oli?

Listan ensimmäinen ei ole bugi, vaan distutils-kirjaston modernisointi. Kyseessä on kirjasto, joka mahdollistaa Python-softien äärimmäisen helpon alustariippumattoman asennuksen. Tällaisesta VB.NET-käyttäjät eivät edes ymmärrä uneksia.

Listan toinen kohta lisää Pythonin samaiseen distutils-kirjastoon uuden moduulitestin. Jos näet jossain bugin, niin kerro.

On listalla oikeita bugejakin, mutta ei mitään triviaalia. Ei esimerkiksi täysin laillista sijoituslausetta, jota kääntäjä ei suostu kääntämään. ;)

> Ihme juttu jos joku oottaa virheettömyyttä kun eihän semmosta voi olla.

Jos sinäkin kokeilisit tehdä töitä hyvillä työkaluilla, niin oppisit vaatimaan edes jonkinlaista laatua.

Lue lisää

Meillä on sitten niinkun erilaiset kokemukset.

Mitäs rojektia teit tolla veepeenetillä vai et kai vaan koittanut oiskos siinä puki? Ite uskostan tommosen kaivamisen mielellään muille. Eiköhän siinä listan muutamissa tuhansissa bugeissa ole tosiaan muutama sinullekin kelpaava.

Ihan mielenkiinnosta pitää kysyä, että mihinkäs ihmeeseen kaipaat ajonaikasta koodinmuokkausta?

Alustariippumattomuus on varmaan kiva juttu niille jotka semmosta tarttee. Ite teen pyyttonitkin tiukasti laitteeseen sidottuina. Ei pahemmin maksa vaivaa tehä niitä siirrettäviksi.

Kyllä toi Visual Studio on hyvä työkalu kunhan ei oo ennakkoasenteinen. Itellä ei oo ongelmia sen kanssa.

Jepulis Jeep kirjoitti:

Meillä on sitten niinkun erilaiset kokemukset.

Mitäs rojektia teit tolla veepeenetillä vai et kai vaan koittanut oiskos siinä puki? Ite uskostan tommosen kaivamisen mielellään muille. Eiköhän siinä listan muutamissa tuhansissa bugeissa ole tosiaan muutama sinullekin kelpaava.

Ihan mielenkiinnosta pitää kysyä, että mihinkäs ihmeeseen kaipaat ajonaikasta koodinmuokkausta?

Alustariippumattomuus on varmaan kiva juttu niille jotka semmosta tarttee. Ite teen pyyttonitkin tiukasti laitteeseen sidottuina. Ei pahemmin maksa vaivaa tehä niitä siirrettäviksi.

Kyllä toi Visual Studio on hyvä työkalu kunhan ei oo ennakkoasenteinen. Itellä ei oo ongelmia sen kanssa.

Lue lisää

Tässä vähän lisää kokemusta VB:stä:
Dim foo As UInteger = &HFFFFFFFF
Dim foo As UInteger = 4294967295

Ensimmäinen ei mene kääntäjästä läpi, toinen menee.
Editorissa on viesti "Constant expression not representable in type 'UInteger'". UInteger on etumerkitön 32-bittinen kokonaisluku. Vastaavia 'hassuja' juttuja ilmenee VB-perheessä aina silloin tällöin. Ongelma vissiin on se, että hexa-luvut ovat oletusarvoisesti Integer tyyppiä, joka on vähintäänkin mielenkiintoinen valinta, koska hexa-luvut ovat etumerkittömiä. No joo, kaikkea ei voi saada.

Python pywin32 ja johan istutaan tiukasti Wintoosassa. Ja mikäs siinä jos tekee hommia COM-kikkareilla yms. Toisaalta todellinen
ja läpinäkyvä alustariippumattomuus on vain
markkinointikikka ja sitä voi soveltaa helloworld-tyyppisille ohjelmille.

Visual Studion siis IDEn tuominen tähän keskusteluun on VÄHÄN ohi aiheen. Kyse oli vain VisualBasic.Njet mokkulasta eikä koko IDEstä. Visual Studio on idenä ihan käypä ja sen editori hakkaa Notepadin mennen tullen. Debuggeri ko. IDEssä on ehdottomasti parasta mitä VS:stä löytyy eikä parempaa debuggeria olekaan. Tosin Linux-softan debuggaaminen on vähän haastavampaa. Vaikkakaan gdb ja sen GUI-liitteet eivät pääse ihan samalle tasolle käytettävyydessä, niin se on kuitenkin toiminnoiltaan vastaava ja portattu moneen ei-Windows domainiin.

Minullakaan ei ole Visual Studion kanssa ongelmia, mutta VB:n kanssa aina on ongelmia.

Ogma kirjoitti:

Tässä vähän lisää kokemusta VB:stä:
Dim foo As UInteger = &HFFFFFFFF
Dim foo As UInteger = 4294967295

Ensimmäinen ei mene kääntäjästä läpi, toinen menee.
Editorissa on viesti "Constant expression not representable in type 'UInteger'". UInteger on etumerkitön 32-bittinen kokonaisluku. Vastaavia 'hassuja' juttuja ilmenee VB-perheessä aina silloin tällöin. Ongelma vissiin on se, että hexa-luvut ovat oletusarvoisesti Integer tyyppiä, joka on vähintäänkin mielenkiintoinen valinta, koska hexa-luvut ovat etumerkittömiä. No joo, kaikkea ei voi saada.

Python pywin32 ja johan istutaan tiukasti Wintoosassa. Ja mikäs siinä jos tekee hommia COM-kikkareilla yms. Toisaalta todellinen
ja läpinäkyvä alustariippumattomuus on vain
markkinointikikka ja sitä voi soveltaa helloworld-tyyppisille ohjelmille.

Visual Studion siis IDEn tuominen tähän keskusteluun on VÄHÄN ohi aiheen. Kyse oli vain VisualBasic.Njet mokkulasta eikä koko IDEstä. Visual Studio on idenä ihan käypä ja sen editori hakkaa Notepadin mennen tullen. Debuggeri ko. IDEssä on ehdottomasti parasta mitä VS:stä löytyy eikä parempaa debuggeria olekaan. Tosin Linux-softan debuggaaminen on vähän haastavampaa. Vaikkakaan gdb ja sen GUI-liitteet eivät pääse ihan samalle tasolle käytettävyydessä, niin se on kuitenkin toiminnoiltaan vastaava ja portattu moneen ei-Windows domainiin.

Minullakaan ei ole Visual Studion kanssa ongelmia, mutta VB:n kanssa aina on ongelmia.

Lue lisää

Ihmettelen kyllä, että mitä sovelluksia te tolla vb.net:llä teette kun ootte joutuneet tommosiin ongelmiin noiden kanssa.

Dim foo As UInteger = CUInt("&HFFFFFFFF")

Tollahan saat meneen tota ekaakin ainaskin läpitten.

Itelläni ei oo kyllä ollut ongemia myöskään VB:n kanssa. Ihmettelen vieläkin sitä, minkä mallisia projekteja ootte sillä tehneet jos tämmöstä tulee. Mites muuten, miten on ongelmaa C#:n kanssa?

Jepulis Jeep kirjoitti:

Meillä on sitten niinkun erilaiset kokemukset.

Mitäs rojektia teit tolla veepeenetillä vai et kai vaan koittanut oiskos siinä puki? Ite uskostan tommosen kaivamisen mielellään muille. Eiköhän siinä listan muutamissa tuhansissa bugeissa ole tosiaan muutama sinullekin kelpaava.

Ihan mielenkiinnosta pitää kysyä, että mihinkäs ihmeeseen kaipaat ajonaikasta koodinmuokkausta?

Alustariippumattomuus on varmaan kiva juttu niille jotka semmosta tarttee. Ite teen pyyttonitkin tiukasti laitteeseen sidottuina. Ei pahemmin maksa vaivaa tehä niitä siirrettäviksi.

Kyllä toi Visual Studio on hyvä työkalu kunhan ei oo ennakkoasenteinen. Itellä ei oo ongelmia sen kanssa.

Lue lisää

> Ihan mielenkiinnosta pitää kysyä, että mihinkäs
> ihmeeseen kaipaat ajonaikasta koodinmuokkausta?

Viimeksi taisin käyttää ohjelmarakenteiden (ei suoraan tavu- tai Python-koodin) muokkausta tehdessäni Pythoniin debuggeria monisäikeisille ohjelmille.

Pythoniin voi ohjelmoida debuggerin Pythonilla itsellään sys.settracen avulla. Se saa Pythonin virtuaalikoneen kutsumaan haluamaansa debuggerin funktiota jokaiselle debugattavan ohjelman riville tultaessa. Monisäikeisten ohjelmien kanssa ongelma on vain se, että debuggerin funktio pitää asettaa sys.settracella jokaisessa säikeessä erikseen. Jos ei sitä aseta, säie ajaa pelkästään debugattavaksi tarkoitettua ohjelmaa ilman debuggerin koodia.

Pythonissa uudet säikeet käynnistetään antamalla uuden säikeen ensimmäiseksi suoritettava funktio parametreineen thread.start_new_thread-funktiolle. Esimerkiksi thread.start_new_thread(foo,()) käynnistää uuden säikeen, jonka suoritus alkaa kutsumalla funktiota foo ilman parametreja. Säie, jossa tämä rivi suoritetaan, jatkaa omaa suoritustaan seuraavalta riviltä. Korkean tason (Javamainen) threading-kirjastokin käyttää pellin alla tätä tekniikkaa.

Toteutin debuggeriin monisäikeisyystuen käärimällä ajonaikaisesti omaa koodiani thread.start_new_thread-funktion ympärille. Kun debugattava Python-ohjelma kutsui tuota funktiota (suoraan tai esim. threading-kirjaston kautta), suoritusvuoroon tulikin ensin sen ympärille lisäämäni koodi. Tuo koodi vaihtoi oikealle start_new_threadille annettavia parametreja. Uudessa säikeessä ei suoritetakaan ensimmäisenä mitään debugattavan ohjelman funktiota, vaan lisää minun omaa koodiani. Tämä koodi puolestaan asettaa aluksi sys.settracen oikein ja kutsuu vasta sitten sitä debugattavan ohjelman funktiota, joka alunperin oli tarkoitus suorittaa uuden säikeen alussa.

Tämä on paljon helpompaa kuin esimerkiksi koodin instrumentointi ennen suoritusta.

TRRY kirjoitti:

> Ihan mielenkiinnosta pitää kysyä, että mihinkäs
> ihmeeseen kaipaat ajonaikasta koodinmuokkausta?

Viimeksi taisin käyttää ohjelmarakenteiden (ei suoraan tavu- tai Python-koodin) muokkausta tehdessäni Pythoniin debuggeria monisäikeisille ohjelmille.

Pythoniin voi ohjelmoida debuggerin Pythonilla itsellään sys.settracen avulla. Se saa Pythonin virtuaalikoneen kutsumaan haluamaansa debuggerin funktiota jokaiselle debugattavan ohjelman riville tultaessa. Monisäikeisten ohjelmien kanssa ongelma on vain se, että debuggerin funktio pitää asettaa sys.settracella jokaisessa säikeessä erikseen. Jos ei sitä aseta, säie ajaa pelkästään debugattavaksi tarkoitettua ohjelmaa ilman debuggerin koodia.

Pythonissa uudet säikeet käynnistetään antamalla uuden säikeen ensimmäiseksi suoritettava funktio parametreineen thread.start_new_thread-funktiolle. Esimerkiksi thread.start_new_thread(foo,()) käynnistää uuden säikeen, jonka suoritus alkaa kutsumalla funktiota foo ilman parametreja. Säie, jossa tämä rivi suoritetaan, jatkaa omaa suoritustaan seuraavalta riviltä. Korkean tason (Javamainen) threading-kirjastokin käyttää pellin alla tätä tekniikkaa.

Toteutin debuggeriin monisäikeisyystuen käärimällä ajonaikaisesti omaa koodiani thread.start_new_thread-funktion ympärille. Kun debugattava Python-ohjelma kutsui tuota funktiota (suoraan tai esim. threading-kirjaston kautta), suoritusvuoroon tulikin ensin sen ympärille lisäämäni koodi. Tuo koodi vaihtoi oikealle start_new_threadille annettavia parametreja. Uudessa säikeessä ei suoritetakaan ensimmäisenä mitään debugattavan ohjelman funktiota, vaan lisää minun omaa koodiani. Tämä koodi puolestaan asettaa aluksi sys.settracen oikein ja kutsuu vasta sitten sitä debugattavan ohjelman funktiota, joka alunperin oli tarkoitus suorittaa uuden säikeen alussa.

Tämä on paljon helpompaa kuin esimerkiksi koodin instrumentointi ennen suoritusta.

Lue lisää

Eipä tullu tommonen tarve mieleen kun tossa Visual Studiossa on jo valmiina se depukkeri eikä sitä tarvii viritellä ite kasaan.

Jepulis Jeep kirjoitti:

Eipä tullu tommonen tarve mieleen kun tossa Visual Studiossa on jo valmiina se depukkeri eikä sitä tarvii viritellä ite kasaan.

Toivottavasti pystyit näkemään tämän debuggeriesimerkin takaa ongelman ratkaisuun käytetyn tekniikan (eli funktioiden ja metodien käärimisen) yleiskäyttöisyyden. Sellaiselle löytyy käyttöä paljon muualtakin kuin debuggereista.

Tällä tekniikalla voi siistiä ohjelmakoodia huomattavasti esimerkiksi sellaisissa tilanteissa, joissa monen funktion ympärille halutaan liittää sama toiminnallisuus. Esimerkiksi autentikointi, puskurointi, cache, logitus, tiettyihin virhetilanteisiin varautuminen, poissulkeminen, aikakatkaisu, transaktio, ohjelman tilan tallennus jne. voidaan kaikki toteuttaa omaan siistiin funktioonsa, mikä voidaan kääriä niin monen muun funktion ympärille kuin halutaan.

Omien funktioiden ja metodien lisäksi näin voi kääriä myös olemassa olevia rajapintoja, niin kuin esimerkissäni thread-kirjaston start_new_thread-funktiolle tehtiin. Tällä tavoin on mahdollista viedä omaa koodia olemassa olevan järjestelmän sisään.

Toisena esimerkkinä tämän tekniikan käytöstä mainittakoon eräs projekti, missä tehdään emesene-pikaviestinohjelmasta lapsille turvallisempaa versiota. Asia hoidetaan toteuttamalla tavallinen emesene-plugin, joka käärii joidenkin pikaviestimen funktioiden ympärille omaa koodiaan. Tuo koodi sitten tarkistaa esimerkiksi onko chatin vastapuoli vanhempien sallimien kontaktien listalla. Jos näin ei ole, chat-yhteyden muodostusta ei sallita: alkuperäistä metodia ei kutsuta lainkaan. Jos taas on, alkuperäistä metodia kutsutaan alkuperäisin parametrein, ja yhteys muodostuu aivan kuten ennenkin.

Tämä on jälleen paljon siistimpää kuin muutosten tekeminen suoraan emesenen lähdekoodiin. Pikaviestin on kuitenkin Jonkun Toisen Projekti, ja tässä projektissa halutaan tehdä lapsille turvallista softaa. Etenkin jos muutoksia ei hyväksyttäisi emesene-projektiin, tuloksena olisi kaksi erillistä projektia ja todella kypsää integrointia aina uusien versioiden ilmestyessä.

Ihan mielenkiinnosta, miten Visual Studiossa onnistuu monisäikeisten ohjelmien debuggaus? Pystyykö käyttäjä valitsemaan, mikä säie ottaa milloinkin askeleen eteenpäin?

TRRY kirjoitti:

Toivottavasti pystyit näkemään tämän debuggeriesimerkin takaa ongelman ratkaisuun käytetyn tekniikan (eli funktioiden ja metodien käärimisen) yleiskäyttöisyyden. Sellaiselle löytyy käyttöä paljon muualtakin kuin debuggereista.

Tällä tekniikalla voi siistiä ohjelmakoodia huomattavasti esimerkiksi sellaisissa tilanteissa, joissa monen funktion ympärille halutaan liittää sama toiminnallisuus. Esimerkiksi autentikointi, puskurointi, cache, logitus, tiettyihin virhetilanteisiin varautuminen, poissulkeminen, aikakatkaisu, transaktio, ohjelman tilan tallennus jne. voidaan kaikki toteuttaa omaan siistiin funktioonsa, mikä voidaan kääriä niin monen muun funktion ympärille kuin halutaan.

Omien funktioiden ja metodien lisäksi näin voi kääriä myös olemassa olevia rajapintoja, niin kuin esimerkissäni thread-kirjaston start_new_thread-funktiolle tehtiin. Tällä tavoin on mahdollista viedä omaa koodia olemassa olevan järjestelmän sisään.

Toisena esimerkkinä tämän tekniikan käytöstä mainittakoon eräs projekti, missä tehdään emesene-pikaviestinohjelmasta lapsille turvallisempaa versiota. Asia hoidetaan toteuttamalla tavallinen emesene-plugin, joka käärii joidenkin pikaviestimen funktioiden ympärille omaa koodiaan. Tuo koodi sitten tarkistaa esimerkiksi onko chatin vastapuoli vanhempien sallimien kontaktien listalla. Jos näin ei ole, chat-yhteyden muodostusta ei sallita: alkuperäistä metodia ei kutsuta lainkaan. Jos taas on, alkuperäistä metodia kutsutaan alkuperäisin parametrein, ja yhteys muodostuu aivan kuten ennenkin.

Tämä on jälleen paljon siistimpää kuin muutosten tekeminen suoraan emesenen lähdekoodiin. Pikaviestin on kuitenkin Jonkun Toisen Projekti, ja tässä projektissa halutaan tehdä lapsille turvallista softaa. Etenkin jos muutoksia ei hyväksyttäisi emesene-projektiin, tuloksena olisi kaksi erillistä projektia ja todella kypsää integrointia aina uusien versioiden ilmestyessä.

Ihan mielenkiinnosta, miten Visual Studiossa onnistuu monisäikeisten ohjelmien debuggaus? Pystyykö käyttäjä valitsemaan, mikä säie ottaa milloinkin askeleen eteenpäin?

Lue lisää

En vaan ymmärrä ollenkaan mitä järkeä on muokata koodia lennossa. Helpompi tehä ihan järkevästi koodaten noi jutut ihan siitä lähtien, että suunnittelee sen monen funktion ympärille liitettävän saman toiminnallisuuden suoraan niin, että tommosta kikkailua ei tartte.

Tai jos nyt haluut oikeesti muokata vaikka sorsaa jollain systeemillä niin voihan sitä sorsakoodia kirjottaa koodista ja lisäillä mitä vaan minne vaan. Yleensä ei oo tarpeen kun toi IDE hoitaa triviaalit hommat silleen, ettei kehittäjän tartte keksiä pyörää uusiks.

Joo, kyllä onnistuu ja kyllä voi valita. Lisää kaikkea kivaa just multithreadiin ja sen koodaamiseen tulee kun toi seuraava ilmestyy, meinaan 2010. Kattellaan sitten lähemmin sen kanssa.

Jepulis Jeep kirjoitti:

En vaan ymmärrä ollenkaan mitä järkeä on muokata koodia lennossa. Helpompi tehä ihan järkevästi koodaten noi jutut ihan siitä lähtien, että suunnittelee sen monen funktion ympärille liitettävän saman toiminnallisuuden suoraan niin, että tommosta kikkailua ei tartte.

Tai jos nyt haluut oikeesti muokata vaikka sorsaa jollain systeemillä niin voihan sitä sorsakoodia kirjottaa koodista ja lisäillä mitä vaan minne vaan. Yleensä ei oo tarpeen kun toi IDE hoitaa triviaalit hommat silleen, ettei kehittäjän tartte keksiä pyörää uusiks.

Joo, kyllä onnistuu ja kyllä voi valita. Lisää kaikkea kivaa just multithreadiin ja sen koodaamiseen tulee kun toi seuraava ilmestyy, meinaan 2010. Kattellaan sitten lähemmin sen kanssa.

Lue lisää

> En vaan ymmärrä ollenkaan mitä järkeä on muokata koodia lennossa.
> Helpompi tehä ihan järkevästi koodaten noi jutut ihan siitä lähtien,
> että suunnittelee sen monen funktion ympärille liitettävän saman
> toiminnallisuuden suoraan niin, että tommosta kikkailua ei tartte.

Se ei tosiaan ole helpompaa, vaan

- *mahdotonta* silloin, kun käärittävien funktioiden lähdekoodia ei ole saatavilla

- *mahdotonta* silloin, kun käärittävät funktiot sijaitsevat standardikirjastossa tai muussa yleiskäyttöisessä kirjastossa. (Esim. thread.start_new_thread.)

- *erittäin vaikeaa* silloin, kun käärittävät funktiot on toteutettu eri kielellä kuin oma ohjelma. Monet Python-kirjastot on toteutettu C:llä.

- *vaikeaa ja typerää* silloin, kun käärittävät funktiot ja omaa ohjelmaa kehitetään eri projekteissa.

- *vaikeaa ja typerää* silloin, kun käärittävät funktiot voivat olla yleisesti järjestelmään asennettua koodia ja oma ohjelma käyttäjäkohtaista koodia. (Mitä jos Firefox-plugineiden pitäisi muokata Firefoxin lähdekoodia toimiakseen?)

Lisäksi sellaisten suoranaisesti sovelluslogiikkaan kuulumattomien funktioikutsujen viljely ympäri koodia, kuten mainitsemani autentikointi, puskurointi, cache jne, heikentää koodin luettavuutta ja ylläpidettävyyttä. Jos ne tuotaisiin koodiin käärimällä, niiden kytkeminen päälle ja pois olisi myös helppoa ja todennäköisesti testauksessa js debuggauksessa hyödyllistä.

TRRY kirjoitti:

> En vaan ymmärrä ollenkaan mitä järkeä on muokata koodia lennossa.
> Helpompi tehä ihan järkevästi koodaten noi jutut ihan siitä lähtien,
> että suunnittelee sen monen funktion ympärille liitettävän saman
> toiminnallisuuden suoraan niin, että tommosta kikkailua ei tartte.

Se ei tosiaan ole helpompaa, vaan

- *mahdotonta* silloin, kun käärittävien funktioiden lähdekoodia ei ole saatavilla

- *mahdotonta* silloin, kun käärittävät funktiot sijaitsevat standardikirjastossa tai muussa yleiskäyttöisessä kirjastossa. (Esim. thread.start_new_thread.)

- *erittäin vaikeaa* silloin, kun käärittävät funktiot on toteutettu eri kielellä kuin oma ohjelma. Monet Python-kirjastot on toteutettu C:llä.

- *vaikeaa ja typerää* silloin, kun käärittävät funktiot ja omaa ohjelmaa kehitetään eri projekteissa.

- *vaikeaa ja typerää* silloin, kun käärittävät funktiot voivat olla yleisesti järjestelmään asennettua koodia ja oma ohjelma käyttäjäkohtaista koodia. (Mitä jos Firefox-plugineiden pitäisi muokata Firefoxin lähdekoodia toimiakseen?)

Lisäksi sellaisten suoranaisesti sovelluslogiikkaan kuulumattomien funktioikutsujen viljely ympäri koodia, kuten mainitsemani autentikointi, puskurointi, cache jne, heikentää koodin luettavuutta ja ylläpidettävyyttä. Jos ne tuotaisiin koodiin käärimällä, niiden kytkeminen päälle ja pois olisi myös helppoa ja todennäköisesti testauksessa js debuggauksessa hyödyllistä.

Lue lisää

En lähtis tohon jo siitä syystä, että jos tämä kolmannen osapuolen koodi muuttuu syystä tai toisesta niin vaikutukset oman koodin kanssa ovat vähintäänkin arveluttavia. Tietenkään tätä ongelmaa ei suurelta osin ole olemassa jos kaikki päivityksetkin voi jäädyttää siihen paikkaan.

Yleensä kaikki autentikoinnit, puskuroinnit ja cachet saa pistettyä koodiin ilman luettavuuden heikentymistä. Mitäs ihmeen autentikointia pitää lisätä koodiin jonka lähdekoodia ei ole saatavissa? Kuulostaa aika erikoiselta.

Jepulis Jeep kirjoitti:

En lähtis tohon jo siitä syystä, että jos tämä kolmannen osapuolen koodi muuttuu syystä tai toisesta niin vaikutukset oman koodin kanssa ovat vähintäänkin arveluttavia. Tietenkään tätä ongelmaa ei suurelta osin ole olemassa jos kaikki päivityksetkin voi jäädyttää siihen paikkaan.

Yleensä kaikki autentikoinnit, puskuroinnit ja cachet saa pistettyä koodiin ilman luettavuuden heikentymistä. Mitäs ihmeen autentikointia pitää lisätä koodiin jonka lähdekoodia ei ole saatavissa? Kuulostaa aika erikoiselta.

Lue lisää

> En lähtis tohon jo siitä syystä, että jos tämä kolmannen osapuolen
> koodi muuttuu syystä tai toisesta niin vaikutukset oman
> koodin kanssa ovat vähintäänkin arveluttavia.

Samaan ongelmaan törmäät aina, kun käytät jonkun muun kuin itsesi tekemiä kirjastoja. Jos käärit vain julkisen rajapinnan funktioita ja metodeja läpinäkyvillä kääreillä, riippuvuus muiden koodista on samalla tasolla kuin silloin, jos vain kutsuisit niitä.

TRRY kirjoitti:

> En lähtis tohon jo siitä syystä, että jos tämä kolmannen osapuolen
> koodi muuttuu syystä tai toisesta niin vaikutukset oman
> koodin kanssa ovat vähintäänkin arveluttavia.

Samaan ongelmaan törmäät aina, kun käytät jonkun muun kuin itsesi tekemiä kirjastoja. Jos käärit vain julkisen rajapinnan funktioita ja metodeja läpinäkyvillä kääreillä, riippuvuus muiden koodista on samalla tasolla kuin silloin, jos vain kutsuisit niitä.

Lue lisää

Jos kerran pelkästään kääritään noita julkisia funkkareita joista ei oo sorsaa, niin ei se vastaa samaa kuin jos kutsuisit niitä. Mitäs teet jos rajapintaan tulee uus vastaavan asian tekevä metodi jota et saakkaan käärittyä vanhalla systeemillä? Siinä menee ratkaisu reisille samoin tein.

Jos noita ois vaan käyttänyt, niin ei niitä ois sillon ilmestynyt omaan koodiin käytettynä.

Jepulis Jeep kirjoitti:

En vaan ymmärrä ollenkaan mitä järkeä on muokata koodia lennossa. Helpompi tehä ihan järkevästi koodaten noi jutut ihan siitä lähtien, että suunnittelee sen monen funktion ympärille liitettävän saman toiminnallisuuden suoraan niin, että tommosta kikkailua ei tartte.

Tai jos nyt haluut oikeesti muokata vaikka sorsaa jollain systeemillä niin voihan sitä sorsakoodia kirjottaa koodista ja lisäillä mitä vaan minne vaan. Yleensä ei oo tarpeen kun toi IDE hoitaa triviaalit hommat silleen, ettei kehittäjän tartte keksiä pyörää uusiks.

Joo, kyllä onnistuu ja kyllä voi valita. Lisää kaikkea kivaa just multithreadiin ja sen koodaamiseen tulee kun toi seuraava ilmestyy, meinaan 2010. Kattellaan sitten lähemmin sen kanssa.

Lue lisää

> En vaan ymmärrä ollenkaan mitä järkeä on muokata koodia lennossa.

Debuggerit, profiloijat, resurssivuotojen tarkastajat, tietoturvatuotteet ja jälkikäteen asennettavat sisällöntarkastajat mm. käyttävät ajonaikaista koodin muokkausta. Jos haluat tutustua asiaan tarkemmin, niin poikkea katsomassa Detours-pakettia http://research.microsoft.com/en-us/projects/detours/. Ongelma ei ole siinä, että tarkastellaan omaa koodia, vaan liimaudutaan muiden tekeleisiin kiinni ja väliin, josta ei ole olemassa muuta kuin binääri.

Mietin vain miten VisualStudiolla voidaan toteuttaa helposti hajautettu toiminnaltaan ennalta määrittelemättömien säikeiden jako usealle eri alustalla (siis Wintoosa/Linux) suoritusyksikölle.

Aika lailla googlatuilta näiden kavereiden ongelmat vaikuttavat kun eivät ole yhtään vinkanneet millasia projekteja ovat tehneet kun tommosiin törmäsivät.

Vai kestiköhän se puoli tuntia ettiä se puki netistä?

Kuten kirjoitin, tuo bitwise-and-ongelma tuli minulle vastaan VB Scriptissä. Ihan tarkkaan sanottuna html:n sekaan upotetussa, luonnollisesti http-serverin päässä suoritettavassa sellaisessa.

Nimestään huolimatta VB Script taas on ihan eri kieli kuin VB6. Vaikka esimerkiksi molemmissa voi määritellä luokkia, vain VB6:ssa niille voi määritellä rakentajat (constructor) tai niitä voi periä.

Törmäsin tähän ongelmaan toteutettuani rutiinit, joilla voi pakata pienen määrän tietoja samaan 32-bittiseen kokonaislukuun. Kyse ei siis ole mistään rakettitieteestä.

Enää en muista, missä yhteydessä törmäsin tuohon pyöristyskäytäntöön. Kuten kirjoitin, kyseessä ei ole pyöristysvirhe, vaan seuraus siitä, että kieleen on menty valitsemaan poikkeuksellinen pyöristystapa (round-to-even¹). Kumpaakaan ongelmaa minun ei valitettavasti tarvinnut Googlata.

Oikeassa elämässä ei aina pääse valitsemaan tehtävään sopivinta ohjelmointikieltä. Ei esimerkiksi silloin, kun jatkokehitetään olemassa olevaa softaa. Jos valitsemaan aina pääsisi, en olisi varmasti törmännyt näihin enkä muihinkaan VB:n ongelmiin.

Pythonilla voi ohjelmoida OpenGL:ää, joten 3D-pelin tekemistä ei tarvitsisi aloittaa ihan pohjilta... ;)


¹ http://en.wikipedia.org/wiki/Rounding#Round-to-even_method

TRRY kirjoitti:

Kuten kirjoitin, tuo bitwise-and-ongelma tuli minulle vastaan VB Scriptissä. Ihan tarkkaan sanottuna html:n sekaan upotetussa, luonnollisesti http-serverin päässä suoritettavassa sellaisessa.

Nimestään huolimatta VB Script taas on ihan eri kieli kuin VB6. Vaikka esimerkiksi molemmissa voi määritellä luokkia, vain VB6:ssa niille voi määritellä rakentajat (constructor) tai niitä voi periä.

Törmäsin tähän ongelmaan toteutettuani rutiinit, joilla voi pakata pienen määrän tietoja samaan 32-bittiseen kokonaislukuun. Kyse ei siis ole mistään rakettitieteestä.

Enää en muista, missä yhteydessä törmäsin tuohon pyöristyskäytäntöön. Kuten kirjoitin, kyseessä ei ole pyöristysvirhe, vaan seuraus siitä, että kieleen on menty valitsemaan poikkeuksellinen pyöristystapa (round-to-even¹). Kumpaakaan ongelmaa minun ei valitettavasti tarvinnut Googlata.

Oikeassa elämässä ei aina pääse valitsemaan tehtävään sopivinta ohjelmointikieltä. Ei esimerkiksi silloin, kun jatkokehitetään olemassa olevaa softaa. Jos valitsemaan aina pääsisi, en olisi varmasti törmännyt näihin enkä muihinkaan VB:n ongelmiin.

Pythonilla voi ohjelmoida OpenGL:ää, joten 3D-pelin tekemistä ei tarvitsisi aloittaa ihan pohjilta... ;)


¹ http://en.wikipedia.org/wiki/Rounding#Round-to-even_method

Lue lisää

Nykypeleissä tommonen taitaa vaan olla ainoostaan pieni osa juttuja. Fysiikkatietojen laskenta vie aika kivasti tehoa. No, ohan siihenkin juttunsa.

Jepulis Jeep kirjoitti:

Nykypeleissä tommonen taitaa vaan olla ainoostaan pieni osa juttuja. Fysiikkatietojen laskenta vie aika kivasti tehoa. No, ohan siihenkin juttunsa.

kyllä fysiikkalaskuja voi tehdä ihan skriptakielellä jos objekteja ei ole montaa. Tai jos ei tarvitse välittää tarkasti eri objektien vuorovaikutuksesta.

Ja suurimpaan osaan peleistä niitä ei välttämättä tarvita lähes ollenkaan. Ei kaikki pelit ole Doomia ja Quakea, vain tylsimmät!

.......... kirjoitti:

kyllä fysiikkalaskuja voi tehdä ihan skriptakielellä jos objekteja ei ole montaa. Tai jos ei tarvitse välittää tarkasti eri objektien vuorovaikutuksesta.

Ja suurimpaan osaan peleistä niitä ei välttämättä tarvita lähes ollenkaan. Ei kaikki pelit ole Doomia ja Quakea, vain tylsimmät!

Lue lisää

Eikös Doomista ja Quakesta, siitä ekasta kun et veivannut numeroa, ole reilusti yli 10 vuotta.

Nykypelejä, poika, nykypelejä.

Opjekteja on paljon ja vuorovaikutus on aika tärkeetä nykyään. Pieni osa semmosia tarttevista on räiskintöjä.

Jepulis Jeep kirjoitti:

Aika lailla googlatuilta näiden kavereiden ongelmat vaikuttavat kun eivät ole yhtään vinkanneet millasia projekteja ovat tehneet kun tommosiin törmäsivät.

Vai kestiköhän se puoli tuntia ettiä se puki netistä?

Lue lisää

Varmasti nuo virheet ovat löydettävissä ovat löydettävissä googlella, mutta joku voi joskus törmätä oikeessa elämässä bitin maskaukseen. Sellaisia tarpeita syntyy kun pitää pakata tai kryptata tietoa tai pelata epästandardin kommunikaatioprotokollan kanssa. VisualBasicilla ei noita oikeastaan kannata tehdä, mutta jos asiakas sitä haluaa, niin se sitten tehdään. Ja kuitenkin GUIn tekeminen syntyy VB:llä näppärästi tosin C# ja Java taitavat antaa siihenkin paremman kokonaisuuden. Pitääpä koittaa tuo hex-luku C#:lla.

Toinen huomio, johon esimerkilläni koitin keskustelua ohjata, oli se, että Microsoftin mielestä hex-luku, jossa on lukualueen ylin bitti '1' tulkitaan implisiittisesti etumerkilliseksi on virheellinen. Miksi? Siksi, että hex-luvut ovat etumerkittömiä, koska ne edustavat vastaavia nibblen kokoisia binäärilukuja. Siten tässä yhdeyssä koko etumerkin käsite on merkityksetön. Negatiivinen luku on vain sovittu kahden komplementiksi binääriluvuksi, koska sen kanssa on helpompi laskea kuin yhden komplementin eli pelkän negaation kanssa pelaaminen.

Löysin tuossa vanhan vuodelta -83 olevan Basic-listauksen, joka oli tehty Microsoftin Basic tulkille. Sieltä löysin tuskaisen tappelun jälkiä vastaavien konversioiden kanssa. Vaikka basicilla on joskus hauska leikkiä esim. Excelin ja Wordin yhteydessä (tiedän VBA on typistetty VB), niin kyllä siellä aina tulee jotain omituisuuksia vastaan, jotka on toteutettu muissa valtakielissä intuitiivisemmin.