tomsi42 Skrevet 3. september 2011 Del Skrevet 3. september 2011 Jeg ser Lisp-innflytelse Det stemmer nok bra. Og ut ifra det jeg har sett av LISP-kode, så er Tcl klart mer leselig. Lenke til kommentar
torbjørn marø Skrevet 4. september 2011 Del Skrevet 4. september 2011 Jeg ser Lisp-innflytelse Det stemmer nok bra. Og ut ifra det jeg har sett av LISP-kode, så er Tcl klart mer leselig. Ja, slik det også er enklere å lese Donald Duck enn det er å lese Dostojevskij. Fikk lyst til å dele et lite sitat: "Programming in Lisp is like playing with the primordial forces of the universe. It feels like lightning between your fingertips. No other language even feels close." -- Glenn Ehrlich 2 Lenke til kommentar
tomsi42 Skrevet 4. september 2011 Del Skrevet 4. september 2011 Ja, slik det også er enklere å lese Donald Duck enn det er å lese Dostojevskij. Hehe. Personlig foretrekker jeg Pondus ... Lenke til kommentar
Matsemann Skrevet 4. september 2011 Del Skrevet 4. september 2011 Litt artig å leke seg med Android. Så mye å tenke på når man programmerer til noe håndholdt, og leker meg uten rammeverk o.l. (jobber med å lage mitt eget rammeverk for tiden). Blant annet har man FloatMath, en egen java-klasse som bruker floats og dermed er litt raskere. Den virtuelle maskinen (Dalvik) er ikke så glad i getters. Tre ganger raskere å hente ut noe direkte. Altså isteden for private int x; public int getX { return x; } så har man bare public x; og så henter man alt med objektnavn.x. Er jo "bad design" på en måte, men såpass mye raskere at det må gjøres slik. Java sin garbage collector kan være døden for et spill, da den bruker noen hundre ms på å fullføre. Derfor må man bruke masse Pools for å unngå og lage masse objekter som så blir ubrukt og tatt. Og jeg skriver i Java (som man må på Android), mens selve OpenGL på android kjører i C. Så må jobbe med direct NIO buffers. Siden all opengl-data lagres i native heap memory, mens jeg i Java jobber mot den virtuelle maskinens minne. Her sender jeg to arrays til OpenGL. En med posisjon og teksturdata, og en med hvordan disse 4 punktene skal tolkes som 2 trekanter. ByteBuffer byteBuffer = ByteBuffer.allocateDirect(4 * VERTEX_SIZE); byteBuffer.order(ByteOrder.nativeOrder()); vertices = byteBuffer.asFloatBuffer(); vertices.put(new float[] { 20.0f, 20.0f, 0.0f, 1.0f, 228.0f, 20.0f, 1.0f, 1.0f, 228.0f, 228.0f, 1.0f, 0.0f, 20.0f, 228.0f, 0.0f, 0.0f }); vertices.flip(); byteBuffer = ByteBuffer.allocateDirect(6 * 2); byteBuffer.order(ByteOrder.nativeOrder()); indices = byteBuffer.asShortBuffer(); indices.put(new short[] { 0, 1, 2, 2, 3, 0 }); indices.flip(); Rabling fra min side om hva jeg driver med for tiden. Lenke til kommentar
worseisworser Skrevet 4. september 2011 Del Skrevet 4. september 2011 Og jeg skriver i Java (som man må på Android), SDK'en er Java/Dalvik, men NDK'en er native/C. Lenke til kommentar
GeirGrusom Skrevet 4. september 2011 Del Skrevet 4. september 2011 Herregud så mye diggere OpenGL er i C# hvor du har unsafe, og ingen type erasure. Lenke til kommentar
Matsemann Skrevet 4. september 2011 Del Skrevet 4. september 2011 Hva er unsafe og type erasure? Lenke til kommentar
TheMaister Skrevet 4. september 2011 Del Skrevet 4. september 2011 (endret) Med nyere NDK er det vel mulig å gjøre 99.9% av all koden i C/C++ på Android? Endret 4. september 2011 av TheMaister Lenke til kommentar
GeirGrusom Skrevet 5. september 2011 Del Skrevet 5. september 2011 Hva er unsafe og type erasure? Unsafe gjør at du for eksempel kan pinne et vertex array for grabage collectoren og sende pekeren til dette arrayet til OpenGL. Fordi C# ikke har type erasure på generics, så kan du ta en ArrayList<Vertex>, pinne den og sende innholdet til OpenGL uten å trenge wrappers eller noe som helst. Eksempelvis skriver du slik: public struct MyVertex { public static readonly int SizeOf = Marsha.SizeOf(typeof(MyVertex)); public Vector3 Position; public Vector4 Color; } unsafe void SomeFunction() { var buffer = new List<MyVertex>(); /* ... */ fixed(MyVertex* ptr = buffer) { GL.glVertexPointer(3, GL.GL_FLOAT, MyVertex.SizeOf, (void*)ptr); GL.glColorPointer(4, GL.GL_FLOAT, MyVertex.SizeOf, (void*)((byte*)ptr + 12)); gl.DrawArrays(GL.GL_POINTS, 0, buffer.Length); } } Lenke til kommentar
tomsi42 Skrevet 5. september 2011 Del Skrevet 5. september 2011 Veldig interessert i å høre om du finner noen spesielle styrker ved tcl som du kan dele med oss. En par ting som er behagelig i tcl kontra perl og andre - regexp og switch på strenger: foreach line $data { if {[string match {[A-Za-z]*} $line]} { regexp {([A-Za-z]+)([0-9]*)=(.*)} $line all label index value if {$index >= 0} { if {$index > $album(tracks)} { set album(tracks) $index } } switch $label { DISCID { set album(discid) $value } DTITLE { regexp {(.*) / (.*)} $value all artist title set album(artist) $title set album(title) $title } DYEAR { set album(year) $value } DGENRE { set album(genre) $value } TTITLE { set titles($index) $value } EXTD { append album(info) $value } EXTT { if {[info exist titleinfo($index)]} { append titleinfo($index) $value } { set titleinfo($index) $value } } PLAYORDER { # we don't do playorder } default { puts "unknown label: $label" } } } } Lenke til kommentar
asicman Skrevet 7. september 2011 Del Skrevet 7. september 2011 Syntax er noe sært da språket kun skjønner en ting: kommandoer - if og løkker er også implementert som kommandoer ... beregninger gjøres med kommandoen expr: set var [expr 2 * 3] istedet for var = 2 * 3 ... Tcl har ingen syntax Det er bare som mange andre skall: kommando forfulgt av argumenter. Så har man mange former for quoting/substituering, f.eks. er { og } bare en måte å quote argumentene på slik at de ikke blir evaluert. [ og ] vil medfører at argumentene blir evaluert først. Hvis man forsøker å forstå {} o.l. som syntax på samme måte som i f.eks. C så får man raskt problemer med Tcl. Etter min mening så gir det ikke en så mye å lære seg Tcl i dag. Jeg bruker en del verktøy som bruker Tcl som kommandotolker. Til slik bruk kan det være nyttig. Det er også veldig enkelt å pakke inn programmet ditt med Tcl framfor å skrive en egen kommandotolker. Lenke til kommentar
tomsi42 Skrevet 7. september 2011 Del Skrevet 7. september 2011 Etter min mening så gir det ikke en så mye å lære seg Tcl i dag. Jeg bruker en del verktøy som bruker Tcl som kommandotolker. Til slik bruk kan det være nyttig. Det er også veldig enkelt å pakke inn programmet ditt med Tcl framfor å skrive en egen kommandotolker. Jeg er ikke uenig i at dette. Tcl kan ofte være nyttig som lim. For min del, så må jeg lære meg Tcl da vi bruker i jobben (på et system som man startet på utvikling av for rundt 20 år siden ...) Lenke til kommentar
gerri28 Skrevet 7. september 2011 Del Skrevet 7. september 2011 Ser faktisk ut som at Delphi er på sporet av noe med XE2. Støtter 64bit, Mac OSX og iOS. Står på enkelte forum at Linux/Android støtte kommer etter hvert. http://edn.embarcadero.com/article/41593 Lenke til kommentar
tomsi42 Skrevet 7. september 2011 Del Skrevet 7. september 2011 Ser faktisk ut som at Delphi er på sporet av noe med XE2. Støtter 64bit, Mac OSX og iOS. Står på enkelte forum at Linux/Android støtte kommer etter hvert. http://edn.embarcadero.com/article/41593 Det ser jo interessant ut - men koster vel skjorta ... Lenke til kommentar
Blåbær Skrevet 7. september 2011 Del Skrevet 7. september 2011 Dyrere enn VS2010 ser det ut som, men man kan ihvertfall utvikle til flere plattformer. http://store.embarcadero.com/store?Action=DisplayCategoryProductListPage&SiteID=borlande&Locale=en_IE&categoryID=656300 http://www.microsoftstore.no/shop/nb-NO/Microsoft/Design-+-Developer Lenke til kommentar
GeirGrusom Skrevet 8. september 2011 Del Skrevet 8. september 2011 Interessant at de har flyttet til kryssplattform. Synd at det er Delphi. Lenke til kommentar
asicman Skrevet 8. september 2011 Del Skrevet 8. september 2011 (endret) Ser faktisk ut som at Delphi er på sporet av noe med XE2. Støtter 64bit, Mac OSX og iOS. Står på enkelte forum at Linux/Android støtte kommer etter hvert. http://edn.embarcadero.com/article/41593 I Apple's iOS SDK stod det: Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited). Kilde: http://www.engadget.com/2010/04/08/apples-iphone-lockdown-apps-must-be-written-in-one-of-three-la/ Er det slutt på dette eller tilbyr XE2 et eget SDK? At man med XE2 kan lage Android og iOS applikasjoner virker som om det strider i mot den siste setningen om "compatibility layer" Videre 3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Har XE2 blitt blessed av Apple? Jeg jobbet som Apple utvikler på 80-tallet, da Apple og APDA (Apple Programmers and Developers Association) var åpne og visionære. Nå er det like godt å la være. EDIT: Ser ut som det er slutt på noen av restriksjonene, men 3.3.1 står fortsatt slik jeg har forstått det. Fint hvis noen kan gi en oppdatering på Apple's SDK lisensiering. Endret 8. september 2011 av asicman Lenke til kommentar
Blåbær Skrevet 8. september 2011 Del Skrevet 8. september 2011 Det er gammelt, ble endret i september 2010. http://www.adobe.com/devnet/logged_in/abansod_iphone.html Andre språk som c# fungerer fint med ios. http://xamarin.com/ Lenke til kommentar
GeirGrusom Skrevet 8. september 2011 Del Skrevet 8. september 2011 Unity er også tilgjengelig på iOS og brukerne var lenge i usikkerhet om Unity kom til å bli blokkert fra App Store (ettersom Unity benytter Mono). Men Unity fikk tillatelse av Apple til å fortsette med iOS plattformen. Tror hensikten egentlig er å stenge spesifikt Adobe Flash ute uten å skrive det rett ut. Ettersom de unntar JavaScript så virker de som hyklere. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå