Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.
Fredrik Olsson
  • Registrerad 2002-09-11
  • Senast aktiv 2010-01-16
  • Antal inlägg 66

Foruminlägg

De senaste inläggen Fredrik Olsson har skrivit i forumet.

Hej alla.

Snart dags för Res i Skåne v2.0, många nyheter och ofantligt mycket snabbare sökningar för alla som åker buss och tåg i södra Sverige.

En nyhet är stöd för en drös språk, men en del vanliga språk saknas fortfarande. Så jag söker någon som har 20 minuter över, och talar något av följande språk:
* Arabiska
* Polska
* Ryska

Skicka meddelande till mig direkt om du är sugen.

Det rätta svaret är nog snarare att du alltid ska ha med engelska. Ett par exempel på personer som kommer att se din app men inte förstår svenska:
* Stackarna på Apple som ska granska appen till App Store.
* Ett helt gäng folk som skulle vilja ge dig gratisreklam med en recension eller två.

Sedan har vi de som förstår, men föredrar engelska:
* Många svenskar som inte har Svenska som modersmål.
* Folk som vill ha alla sina appar på engelska pga. "konsekvens".

Att inte stödja engelska är att anse som fattigt, det kan vara det som skiljer en konkurrerade app från din app.

Vi är några eldsjälar som har startat CocoaHeads Øresund.

Kort intro till CocoaHeads; den är en internationell sammanslutning av loger, som samlas varje månad i olika städer världen runt för att prata om utveckling med Cocoa för Mac OS X, och Cocoa Touch för iPhone OS, och eller sina egna projekt. CocoaHeads drivs ideellt med enda syfte att låta Cocoa-utvecklare träffas och utbyta erfarenheter.
Webbsida: CocoaHeads: International Cocoa Club

Kort intro till CocoaHeads Øresund; det är en sammanslagning av CocoaHeads Copenhagen och CocoaHeads Malmö, vi träffas varannan månad i Köpenhamn, respektive Malmö. Vi kommer att bjuda in lokala utvecklare som presenterar sina projekt och erfarenheter, varefter vi kallpratar allt som rör Cocoa och Cocoa Touch över en bit mat och öl.
Första mötet är den 11:e augusti i Malmö i Cocoways lokaler, som också sponsrar dricka och tilltugg till mötet. Nästkommande möte är den 8:e september i Köpenhamn i Jayway Danmarks lokaler.
Webbsida: CocoaHeads Øresund | Google Groups

Alla Mac OS X- och iPhone OS-utvecklare i Öresundstrakten är välkomna att ansluta sig till Googlegruppen, och att komma till våra möten. Föranmälda medlemmar har alltid förtur till möten om de blir fulla. Nästkommande mötes tid och plats kan ni lätt hålla koll på genom att prenumera på får iCal-kalender:
URL: webcal://www.cocoaheads.org//se/Malmö/events.ics

Hej.

Jag skulle vilja ta video in från en extern Component AV-kabel, eller Composite AV-kabel och visa i Keynote. Det vill säga i praktiken video ut från en iPhone.

Finns det någon som vet vad jag ska köpa? TV-kort, extra mjukvara, och så vidare?

Ursprungligen av Ingemar Ragnemalm:

Det är inte alls svårt att skriva Carbon-program. En massa folk har gnällt över inlärningströskeln, och gjort en massa klassbibliotek ovanpå Toolboxen (dvs Carbon) bara för att de inte förstår sig på en enkel eventloop som egentligen bara kan skrivas på ett sätt. Numera har man valet att få callbacks i stället, men det gör ingen större skillnad.

Jo jag kan inte tänka mig att det skulle vara svårare än att hantera meddelandekön när man programmerar rakt på Win32. Inte svårare, men garanterat inte identiskt.

Så länkar till exempel, böcker eller vad som helst som kan sparka igång mig fort vore uppskattat.

Sedan några månader är mitt favoritprogrammeringsspråk helt klart och utan ens ett uns tvekan D. Funktionellt, konsekvent, enkelt och snyggt. Som C++ borde varit, och som Mac-programmerare borde ha det :).

Xcode integrationen finns redan där, färgkodning, använda debuggerna, mallar för projekt och filer, det enda som saknas där är "code-completion". Men att skriva GUI-program till Mac är lite värre, Hello World för Carbon finns ju som exempel för att visa att det går. Men där tar det lite stop.

Ett väldigt minimalistiskt ramverk för att skriva platformsoberoende GUI finns i form av MinWin, en liten samling D-klasser för Win32, GTK och Motif. Att också ge stöd för Carbon borde inte vara så svårt.

Själv har jag ingen erfarenhet av Carbon, så jag vet inte riktigt vart jag ska börja. Finns det någon som skulle ha intresse av att ge mig en hjälpande hand där?

D:s hemsida hittar du här: http://www.digitalmars.com/d/
D för OSX här: http://gdcmac.sourceforge.net/
Xcode integration här: http://www.alanz.com/d/xcode/
MinWin hittar du här: http://home.comcast.net/~benhinkle/minwin/

Ursprungligen av Samuel K:

Så det fungerar bra under OS X nu alltså? Tittade lite på D för drygt ett år sedan och blev otroligt imponerad faktiskt, fick nästan lite Ruby-vibbar av all elegans och genomtänkthet, men då var enda kompileringsalternativet för OS X en synnerligen experimentell patch till GCC så jag tappade intresset. Men då kanske jag måste återuppta det igen

Funkar alldeles utmärkt, gcc varianten har mognat till mycket mer än en patch. Ännu är det gcc 3.3 som bakstycke men det går att leva med. Med Xcode patchen så måste jag säga att D blir ett språk med samma dignitet som C eller C++ (code-completion saknas, men men). Det går ju alldeles utmärkt att skriva delar av sina program i D, andra i C, C++ eller ObjC för den delen och bara länka ihop, rätt verktyg för rätt uppgift! Gladast blir den ju om main-funktionen är D, men det finns dokumentation för hur man sparkar igång skräpsamlaren och så i andra fall med, news-grupperna är guldgruvor.

Det saknas bra kit för GUI, men det är generellt för D i allmänhet inte för D till OSX. Men det går ju bra att använda gamla hederliga C-gränssnitt, så det finns de som helt enkelt kodar mot Carbon.

Ursprungligen av elwiz:

För mig är det nog mono + java som gäller i applikationsutveckling. Jag är lat och gillar garbage collection

Då skulle du gilla D. Ingen runtime, för OSX används gcc som "back-end" för kompilatorn. Full tillgång till alla bibliotek i C. Och hör och häpna; en konsekvent syntax!

http://www.digitalmars.com/d/

Integrationskit för Xcode med, så du får bra syntaxfärgning, kan använda debuggern och all annan lull lull.

Denna sida:
http://shootout.alioth.debian.org/
Ett stort antal programmeringsspråk "tävlar". De har ett dussintal programuppgifter, som "räkna alla ord i en text", mandelbrotsfraktaler och mycket annat.
Varje uppgift är löst i en uppsjö av programmeringsspråk, C, C++, PHP, Java, C#. Ja totalt 41 olika kompilatorer/interpretatorer för en hel drös olika språk.

Varje uppgift kollas sedan i tre hänseenden;
1. Hur snabbt programmet körs.
2. Hur mycket minne programmet tar.
3. Hur många rader kod programmet är.

Självklart är det fritt fram att optimera vilken uppgift som hellst, för vilket språk som helst, av vilken programmerare som hellst.

Och nu det roliga: D spöar skiten ur C++ på det mesta :).

Kan bara bifalla föregående talare. Om det är någon som vet hur man får upp konsollen på ett svenskt tangentbord så tas en beskrivning emot mycket tacksamt.

Hur 17 får jag upp konsollen? Kör på en PowerBook. ~ säger alla webbsidor, knappen under esc således. Kvittar om jag använder amerikansk tangentbordslayout.

Tittade lite i konfigurationsfilerna som finns i pk4-filerna om man packar upp dem. johnc.cfg lät bra i den står det:
bind ~ "toggleConsole"
Snyggt tänkte jag, bara att binda till någon annan tangent då. Icke sa nicke. Man ska visst hålla ned alt och ctrl med, men med:
seta com_allowConsole "1"
Så ska det räck med bara tilde, så då borde ju "bara" vilken annan tangent som helst kunna användas med?
Men icke!

Nu är mina googlekrafter slut, hjälp!?!

För alla mina spelinköp till Playstation 2 så använder jag http://www.spelbutiken.se/. De har bra priser och beställer man innan klockan 17.00 levererar de till nästa dag.

Så självklart mejlade jag dem och frågade om de inte kunde tänka sig att sälja mac spel till mig också. De svarade vänligen att de kunde de visst tänka sig om det bara var fler som visade sitt intresse eftersom de av förklarliga själ inte kan gå runt på en kund :).

Så varför inte ta och visa dem ert intresse?

Citat:

Skrevs ursprungligen av amigoz
Hmmm...jag skulle vilja se ett test i tex photoshop där man först använder en ikke 64-bitars version och sedan gämförde testen med en 64-bitars version av programmet så man kunde se hur mycket extra fart det blir med sådan optimering.

Det skriver jag under på. 32- vs 64-bit kod på samma G5 är mycket intressant.

Och flyter iCals gränssnitt äntligen på?

Komprimering och uppackning av gigantiska filer.

Citat:

Skrevs ursprungligen av iBjorn
Jag håller med! Den absolut största knasgrejen i OSX är att "skrivbordet" ligger fjorton nivåer ned! Skrivbordet ska ligga absolut högst i filstrukturen, det är ju först då som användaren kommer i centrum. Så länge man inte fixar det så kan man planka windows hur mycket som helst utan att det blir bra!

Och det är ju detta som "XP stölden" ordnar. Skrivbordet är ett klick ned. Ett tydligt klick alltid tillgängligt från alla Finder-fönster, inte ens moster Agda eller du kan missa det ens om ni ger er fan på att göra det på pin kiv.

Snabbvalslistan till vänster i nya Finder är ett briljant drag. Jag håller med om att favoriter och verktygsfältsobjekt tillsammans gjorde precis samma sak förut, så det är inget nytt. Det är bara omgjort så att ingen kan missa att använda det.
De ligger alltid synliga med namn, namn som kan vara långa utan att störa, vilket inte kan sägas om verktygsfältsobjekt.
De ligger på Finder-fönstrets arbetsyta vilket talar om för alla användare att de kan ändra i dem precis som en vanlig Finder-vy.

Kort och gott de skriker på ett diskret sätt åt användaren vad de kan användas till. Min sambo klurade inte själv ut att hon kunde dra och släppa mappar till Finders verktygsfält för att få enkla genvägar. Jag är dock beredd att satsa en hundring på att väldigt få personer kommer att missta sig på Panthers snabbvalslista ens vid första anblicken.

Så jag har översatt den i en sittning så det kryllar av fel det är jag säker på.

Därför vore jag tacksam om folk ville tanka ner den och lusläsa lite. Skicka sedan alla kommentarer på fel, inkonsekvens eller synpunkter till mig.

Om det går fort så hinner översättningen med till 3.0.1 uppdateringen.

Här är filen:
http://aio.nocrew.org:31001/~peylow/download.php?file=proteus3.sv.dmg

Och hit skickar du kommentarer
peylow@atari.org

Tack på förhand.

Citat:

Skrevs ursprungligen av el gringo
okey - så det finns plats för 64 gäster i den nya G5an...

om jag kör ett gammalt 32-bitars program och ett nytt 64-bitars program...vad händer då? äter hälften av 64bitarsprogrammet själv medan den andra hälften får dela sin måltid med 32-bitarsprogrammet? och vad innebär det i praktiken på "hastigheten"?

Nej, en grupp gäster kan bara äta i taget. Så när ett 32 bits program körs så används hälften av platserna (Eller endast 32 bits funktioner), när ett 64 bits program körs så används alla platser.

Endast ett program kan köras i taget. Vad Mac OS X gör är att den låter varje program köras ett litet kort tag och byter sedan till nästa. Så håller den på och byter mellan alla programmen som är igång flera gånger per sekund. Så ofta att du som användare upplever det som att alla programmen körs hela tiden.

Det är upp till OS X att se till att ett 64 bits program får tillgång till alla 64 bits funktioner och att ett 32 bits program håller sig till 32 bits. Det är därför Apple måste uppdatera OS X. Programmen i sig behöver inte uppdateras (Men det är ju bra om så görs).

Hastighetsmässigt betyder det inte speciellt mycket. PPC har 32 st GPR register och dessa (Tillsammans med FPU och lite annat smått och gott) använder programmen för att utföra sitt arbete, vilket betyder att de måste sparas av OS X när ett program byts så att programmet inte helt plötsligt får helt annan data att arbeta med än vad det ska vara. Dessa register är 32 bit eller 4 bytes nu. Dessa komer att bli 64bit eller 8 bytes. Så i praktiken betyder det att OS X måste spara 128 bytes mer till minnet varje gång ett program byts.
Detta är dock inte mycket att jämnföra med de 512 bytes som krävs för att spara alla AltiVec register. Så min gissning är att prestandan inte kommer att lida alls av detta.