mboost-dp1
unknown
Ja pisse god..
Nu er det blevet lettere at finde fejl, og når de så frigiver koden, så kan jeg håbe på jeg er den eneste som fandt det..
Spøg til side, det er et godt initiativ!
Nu er det blevet lettere at finde fejl, og når de så frigiver koden, så kan jeg håbe på jeg er den eneste som fandt det..
Spøg til side, det er et godt initiativ!
Det kunne jo tænkes at en ikke så godsindet person fandt en fejl og ikke rapporterede denne, men i stedet udnyttede den til sin egen fordel når den nye version blev udgivet. Det er jo set før at det er de "onde" der finder fejlene før de "gode".
Burde næsten være en fast standart for folk ... Give crackere og andre med samme "samfundsstandart" muligheden for at finde fejl inden det bliver sendt ud - men hva, mon ikke endten Sun tager patent på denne måde at gøre det på, eller bliver sagsøgt langt ind i helvede fordi andre har taget patent på det? :)
edit: Sandt nok der er mulighed for det - løsningen kunne vel være at der kun kan arbejdes på den online og så bliver ALT logget? ...
edit: Sandt nok der er mulighed for det - løsningen kunne vel være at der kun kan arbejdes på den online og så bliver ALT logget? ...
Java's største hastighedsproblem synes jeg er den store VM. Den tager en krig at loade, og den fylder hele hukommelsen, bare fordi man skal køre et par kB.
Tjeah jeg synes da Azureus og cgoban2 er udemærkede java programmer, som responderer helt som man kunne forvente.
Omvendt har jeg ikke været synderligt imponeret over gui hastigheden på de .net programmer jeg har prøvet.
Når det så er sagt, så er det helt korrekt at man kan lave tilfælde hvor java gui er meget langsomt, og det tager som regel længere tid at loade end det ville gøre som binært program, men det giver jo næsten sig selv.
Jeg synes klart det er en fordel at de jave programmer jeg bruger kan bruges på alle de platforme jeg benytter.
Omvendt har jeg ikke været synderligt imponeret over gui hastigheden på de .net programmer jeg har prøvet.
Når det så er sagt, så er det helt korrekt at man kan lave tilfælde hvor java gui er meget langsomt, og det tager som regel længere tid at loade end det ville gøre som binært program, men det giver jo næsten sig selv.
Jeg synes klart det er en fordel at de jave programmer jeg bruger kan bruges på alle de platforme jeg benytter.
#7 Teknikken er jo grundigt afprøvet i Linux og resten af free software verdenen. Det 'problem' du nævner er tit brugt som argument mod open source software, men jeg kan ikke nævne et eneste eksempel hvor sådan et problem er opstået i den virkelige verden. Tværtimod er det min klare opfattelse at producenterne af open source software er bedre til at lukke hullerne end de fleste andre.
#8 Det kan man sku da ikke tage patent på. Sun er meget inspireret af den måde fri software udvikles på og de nærmer sig denne model på alle de måder de kan (tænk på Open Solaris og Open Office eksempelvis).
#8 Det kan man sku da ikke tage patent på. Sun er meget inspireret af den måde fri software udvikles på og de nærmer sig denne model på alle de måder de kan (tænk på Open Solaris og Open Office eksempelvis).
#4 naturligvis er java langsomt, det er fortolket kode. Der er endnu ikke nogen der har fundet på en metode til at fortolke kode i O(1), altså konstant tid. Om det betyder noget er så en hel anden sag. Hvad mener du med at det er nemmere at kode java der performer dårligt end det er at kode f.eks. C++ der performer dårligt? Jeg ville mene at det er omvendt, da du har nogle "farlige" muligheder i c++ som er fjernet i java. Altså ting du simpelthen ikke kan.
#10: Well C# (eller .NET ville måske være lidt mere præcist) anvender jo Windows API til at lave windows forms, det kan java af gode grunde ikke da det ville gøre de fortolkere der fines til mobiltelefoner mm. afhængige af at der er windows API på f.eks. din telefon. Det er selvfølgeligt fair nok at sammenligne, men java kommer aldrig op på siden af .NET i GUI. På den anden side, så kan .NET ikke køre på andet end windows, hvis det bruger windows forms, for det er ikke implementeret i mono endnu :)
#10: Well C# (eller .NET ville måske være lidt mere præcist) anvender jo Windows API til at lave windows forms, det kan java af gode grunde ikke da det ville gøre de fortolkere der fines til mobiltelefoner mm. afhængige af at der er windows API på f.eks. din telefon. Det er selvfølgeligt fair nok at sammenligne, men java kommer aldrig op på siden af .NET i GUI. På den anden side, så kan .NET ikke køre på andet end windows, hvis det bruger windows forms, for det er ikke implementeret i mono endnu :)
#11 everything comes at a price... VM er javas styrke og svaghed. Hvis hastigheden i dine 3kb er vigtigere end at kunne afvikle dem på din kaffemaskine og mobiltelefon må du jo vælge et andet sprog. På den anden side... det er da ret behageligt at kunne kode til windows, linux og opvaskemaskinen samtidig :)
#6 & #7 Nu er det jo ligesom ikke nyt at java source koden bliver frigivet. Det har den faktisk været siden 1.1. Muligvis tidligere.
Ide'en er som med alt open source at hvis flere øjne kigger på det er der større sansynlighed for at finde fejlene og få dem rettet. Windows har jo med al ønskelig tydelighed vist os at crackerne nok skal finde fejlene alligevel, selv om source koden ikke er tilgængelig.
Ide'en er som med alt open source at hvis flere øjne kigger på det er der større sansynlighed for at finde fejlene og få dem rettet. Windows har jo med al ønskelig tydelighed vist os at crackerne nok skal finde fejlene alligevel, selv om source koden ikke er tilgængelig.
#19
Du kunne jo om ikke andet tage et kig på siden der linkes til..
http://download.java.net/jdk6/
Sourcekoden har været tilgængeligt i meget lang tid.
Du kunne jo om ikke andet tage et kig på siden der linkes til..
http://download.java.net/jdk6/
Sourcekoden har været tilgængeligt i meget lang tid.
#16
"...naturligvis er java langsomt, det er fortolket kode. Der er endnu ikke nogen der har fundet på en metode til at fortolke kode i O(1), altså konstant tid..."
Heh, nej hvis man kunne fortolke kode i konstant tid ville der delme ikke være meget grund til at opgradere sin spand EVER.
Jeg er rimelig sikker på at fortolket kode og compilet kode følger hinanden linært i udførselstid. Det eneste der skulle være til forskel i det her tilfælde med Java i modsætning til f.eks. c er at der ikke eksisterer en garbage collection algoritme der kører i O(n). Hvis du vil vise at fortolket kode ikke kører så hurtigt som compilet kode er det vist ikke lige O-notationen du skal bruge.
"...naturligvis er java langsomt, det er fortolket kode. Der er endnu ikke nogen der har fundet på en metode til at fortolke kode i O(1), altså konstant tid..."
Heh, nej hvis man kunne fortolke kode i konstant tid ville der delme ikke være meget grund til at opgradere sin spand EVER.
Jeg er rimelig sikker på at fortolket kode og compilet kode følger hinanden linært i udførselstid. Det eneste der skulle være til forskel i det her tilfælde med Java i modsætning til f.eks. c er at der ikke eksisterer en garbage collection algoritme der kører i O(n). Hvis du vil vise at fortolket kode ikke kører så hurtigt som compilet kode er det vist ikke lige O-notationen du skal bruge.
#21 så hvis man har 100 instruktioner tager hver instruktionsfortolkning 100 gang en eller anden konstant og hvis der er 100000 instruktioner tager der 100000 gange samme konstant? Så fortolkningen skulle blive langsommere efterhånden som programmet blev større? Well det er jeg ikke helt enig med dig i.
Naturligvis tager det længere tid at fortolke hele programmet, men det sker jo ikke! Modsat .NET som pre-compiler hele programmet, så ligger det i fortolkningens natur at instruktionerne bliver fortolket en af gangen, hvilket hveken tager O(n) eller O(1), men et eller andet sted imellem.
Naturligvis tager det længere tid at fortolke hele programmet, men det sker jo ikke! Modsat .NET som pre-compiler hele programmet, så ligger det i fortolkningens natur at instruktionerne bliver fortolket en af gangen, hvilket hveken tager O(n) eller O(1), men et eller andet sted imellem.
#16, #21
Java er ikke fortolket kode. I årevis har man anvendt hotspot VM. Dvs. en indbygget compiler, der kompilerer bytecode til OS'ets maskinkode.
Se fx J2SE Platform at a Glance og The Java HotSpot Virtual Machine
Det er en myte at java ikke kan køre hurtigt.
Java er ikke fortolket kode. I årevis har man anvendt hotspot VM. Dvs. en indbygget compiler, der kompilerer bytecode til OS'ets maskinkode.
Se fx J2SE Platform at a Glance og The Java HotSpot Virtual Machine
Det er en myte at java ikke kan køre hurtigt.
#24
hmm ja nu skal du passe på ikke at lægge ord i folks munde.. Jeg er ganske godt klar over at suns VM compiler til native code men faktum er nu altså at programmet skal køre et godt stykke tid før det bliver compilet. Mener en metode skal kaldes 100 gange per default, før den bliver compilet.. så snakken omkring fortolket kode er skam stadig relevant.
Desuden er jeg af den overbevisning at java kører ganske hurtigt men det vil næsten altid være tilfældet at fortolket kode vil køre langsommere end precompiled native code.. også selvom det bare er et par brøkdele. Grunden til at jeg skriver precompiled er selfølgelig at én VM kan optimere bedre på runtime end en compiler kan på compile time. I hvert fald teoretisk set.
hmm ja nu skal du passe på ikke at lægge ord i folks munde.. Jeg er ganske godt klar over at suns VM compiler til native code men faktum er nu altså at programmet skal køre et godt stykke tid før det bliver compilet. Mener en metode skal kaldes 100 gange per default, før den bliver compilet.. så snakken omkring fortolket kode er skam stadig relevant.
Desuden er jeg af den overbevisning at java kører ganske hurtigt men det vil næsten altid være tilfældet at fortolket kode vil køre langsommere end precompiled native code.. også selvom det bare er et par brøkdele. Grunden til at jeg skriver precompiled er selfølgelig at én VM kan optimere bedre på runtime end en compiler kan på compile time. I hvert fald teoretisk set.
#23
Kom til at skifte side så jeg mistede det svar jeg lige havde skrevet så du får en kort version.
Store o notationen bruges til at vise hvordan afviklingstiden vokser i forhold til størelsen på input. O(1) betyder derfor at afviklingstiden ikke ændres ved forøgning af input. O(n) betyder fordobling af input betyder fordobling i afviklings tid, O(n*n) fire gange så lang tid osv.
Det jeg siger er at hvis man afvikler et program enten på jernet og på en VM vil de altså udføres på samme tid med en konstant faktor til forskel.
Af samme grund kan jeg ikke helt se hvad du prøver at komme frem til når du snakker om 100 instruktioner og at noget ligger imellem O(n) eller O(1). Enten vokser afviklingstiden i forhold til input eller også gør det ikke.
Kom til at skifte side så jeg mistede det svar jeg lige havde skrevet så du får en kort version.
Store o notationen bruges til at vise hvordan afviklingstiden vokser i forhold til størelsen på input. O(1) betyder derfor at afviklingstiden ikke ændres ved forøgning af input. O(n) betyder fordobling af input betyder fordobling i afviklings tid, O(n*n) fire gange så lang tid osv.
Det jeg siger er at hvis man afvikler et program enten på jernet og på en VM vil de altså udføres på samme tid med en konstant faktor til forskel.
Af samme grund kan jeg ikke helt se hvad du prøver at komme frem til når du snakker om 100 instruktioner og at noget ligger imellem O(n) eller O(1). Enten vokser afviklingstiden i forhold til input eller også gør det ikke.
#26 ja du har forstået hvordan store o virker :) Men det jeg taler om er hvordan fortolkning virker. Fortolkning betyder at hver instruktion "oversættes" til maskininstruktioner på den platform der køres på efterhånden som programmet afvikles. Ud af mit første indlæg kan du læse at jeg taler om fortolkningsprocessen, ikke om køretiden for java eller javaprogrammet. At tale om programmets køretid som en funktion af antallet af instruktioner er jo nonsence, da der som bekendt findes loops mm. i programmer.
Fra dit første indlæg (du har enda forstået det :)
Ja de følger hinanden liniært, men ikke i forhold 1:1, fordi FORTOLKNINGSPROCESSEN ikke tager O(1), men noget mere. Så kan man rent stringent sige at den tager O(1*k) og man typisk fjerner konstanten fordi køretidsberegninger skal være uafhænging af hvilken maskine man kører på.
Sidst men ikke mindst et godt råd: Brug opera, den husker naturligvis hvad man skriver i forms selv om man skifter side :)
#24 Det var jeg ikke klar over... My bad! Foregår det også på mindre enheder som mobiltelefoner mm? Gemmes asspemply eller oversættes der før hver kørse? Hehe mange spørgsmål, men jeg er nysgærrig :)
Det efterlader de hastighedsmæsse problemer der findes med GUI i java til den manglende integration med operativsystemets API, hvilket nok ikke bliver "rettet" :)
Fra dit første indlæg (du har enda forstået det :)
Jeg er rimelig sikker på at fortolket kode og compilet kode følger hinanden linært i udførselstid.
Ja de følger hinanden liniært, men ikke i forhold 1:1, fordi FORTOLKNINGSPROCESSEN ikke tager O(1), men noget mere. Så kan man rent stringent sige at den tager O(1*k) og man typisk fjerner konstanten fordi køretidsberegninger skal være uafhænging af hvilken maskine man kører på.
Sidst men ikke mindst et godt råd: Brug opera, den husker naturligvis hvad man skriver i forms selv om man skifter side :)
#24 Det var jeg ikke klar over... My bad! Foregår det også på mindre enheder som mobiltelefoner mm? Gemmes asspemply eller oversættes der før hver kørse? Hehe mange spørgsmål, men jeg er nysgærrig :)
Det efterlader de hastighedsmæsse problemer der findes med GUI i java til den manglende integration med operativsystemets API, hvilket nok ikke bliver "rettet" :)
#27
Jeg kan se at vi har set lidt forskelligt på sagen. Men at noget køres fortolket betyder bare at det ikke kan køres direkte på jernet. At det kører på en VM betyder ikke at det oversættes. Det er ganske vist muligt at oversætte denne bytecode men det har intet med fortolkning at gøre.
Dette er så ikke rigtigt. Java, eller rettere Swing, kan sagtens køre så hurtigt som winforms eller hvad det nu kaldes. Det eneste problem ved swing er bare at du har mulighed for at bruge den thread, som bruges til at tegne, til at lave andre tidskrævende operationer hvilket medfører at gui'en hænger. Dette er såmænd det eneste problem Swing har, og kan man ikke lide det kan man bare bruge SWT eller lign. der vil medføre samme "fordel" som du har ved winforms.
Jeg kan se at vi har set lidt forskelligt på sagen. Men at noget køres fortolket betyder bare at det ikke kan køres direkte på jernet. At det kører på en VM betyder ikke at det oversættes. Det er ganske vist muligt at oversætte denne bytecode men det har intet med fortolkning at gøre.
Det efterlader de hastighedsmæsse problemer der findes med GUI i java til den manglende integration med operativsystemets API, hvilket nok ikke bliver "rettet" :)
Dette er så ikke rigtigt. Java, eller rettere Swing, kan sagtens køre så hurtigt som winforms eller hvad det nu kaldes. Det eneste problem ved swing er bare at du har mulighed for at bruge den thread, som bruges til at tegne, til at lave andre tidskrævende operationer hvilket medfører at gui'en hænger. Dette er såmænd det eneste problem Swing har, og kan man ikke lide det kan man bare bruge SWT eller lign. der vil medføre samme "fordel" som du har ved winforms.
#29
Her tager du så fejl. Måske du bliver forvirret fordi man på dansk (lidt misvisende) bruger ordet 'oversætter' om en compiler.
Både en 'compiler' og en fortolker oversætter koden til maskinkode. Maskinen kan nu engang kun forstå maskinkode, hvodan end du vender og drejer det.
Forskellen ligger i som iluka så rigtigt siger, at en compiler evaluere(oversætter) hele programmet compile-time. Hvor en fortolker kun evaluere(oversætter) ét 'expression' ad gangen run-time.
Jeg kan se at vi har set lidt forskelligt på sagen. Men at noget køres fortolket betyder bare at det ikke kan køres direkte på jernet. At det kører på en VM betyder ikke at det oversættes. Det er ganske vist muligt at oversætte denne bytecode men det har intet med fortolkning at gøre.
Her tager du så fejl. Måske du bliver forvirret fordi man på dansk (lidt misvisende) bruger ordet 'oversætter' om en compiler.
Både en 'compiler' og en fortolker oversætter koden til maskinkode. Maskinen kan nu engang kun forstå maskinkode, hvodan end du vender og drejer det.
Forskellen ligger i som iluka så rigtigt siger, at en compiler evaluere(oversætter) hele programmet compile-time. Hvor en fortolker kun evaluere(oversætter) ét 'expression' ad gangen run-time.
#30
Hvem snakker om fortolkere og compilere? Jeg snakker om at køre noget fortolket i en VM og at køre noget direkte på cpuen, og derfor bruger jeg ordene fortolket kode (interpreted code) og native code. Jeg prøver at forklare at man godt kan køre noget på en VM uden at den skal oversætte det til native code, hvilket jeg har forstået han mener.
Hvem snakker om fortolkere og compilere? Jeg snakker om at køre noget fortolket i en VM og at køre noget direkte på cpuen, og derfor bruger jeg ordene fortolket kode (interpreted code) og native code. Jeg prøver at forklare at man godt kan køre noget på en VM uden at den skal oversætte det til native code, hvilket jeg har forstået han mener.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund