According to sources, Apple earlier today declared build 8A428 of Tiger 'gold master,' the final development stage. Companies typically release the 'GM' candidate to manfuacturing for duplication and packaging.

Earlier this week, Apple release a "FC" (final candidate) build to developers and other partners to test the operating system for any last minute "showstoppers." The build reportedly still had a few outstanding issues, but those were not expected to delay Tiger's release. They are expected to be fixed in the next free (downloadable) update to the operating system.

Sources expect Apple to announce the completion of Mac OS X 10.4 Tiger as early as tomorrow, April 1st. Some retailers, including Amazon, which is offering a $35 mail-in rebate, have already begun taking pre-orders of Mac OS X Tiger, indicating that they expect to thip the product within 30 days.

Mac OS X Tiger is expected to hit retail stores in the second half of April. In the past, Apple has held special launch events at its retail stores and other retailers have also joined with special events and festivities of their own.

Apple is also holding its Worldwide Developer Conference 2005 in San Francisco in June, where it will focus on the new features and development tools available with Mac OS X Tiger.

Apple has refused to comment about Mac OS X Tiger's release to manufacturing and the estimated date of shipment--except to say that it is due in the first half of 2005.

http://www.appleinsider.com/article.php?id=976

Ainda não saiu, mas com os pre-orders, já está em 1º lugar da lista de "Top sellers" de software na amazon.

http://www.amazon.com/exec/obidos/tg/new-for-you/top-sellers/-/software/102-6221357-8178535

(Rant)
Assim que todos os users de Apple tiverem comprado este update, em cinco ou seis dias, portanto, já o Windows XP x64 vendeu 6 ou 7 vezes mais. Outra coisa que se vê nesta descrição da amazon é como eles dão grande ênfase ao novo look de uma nova aplicação ou novos filtros e efeitos acelerados... realmente, para ter um rip-off do windowsblinds (n me venham com a skin do Aqua, pois há mtas mais e bem melhores) não era preciso tanto alarido.
A vossa mui odiada (e, ao mesmo tempo, estimada) MS não mudou nada no interface e adicionou características que aumentam a estabilidade e a segurança (pelo menos não está pior, mas como user das versões alpha e beta há mtos meses, acho-o mto melhor) do novo OS, cuja base é a do Win2003 Server x64. Está a apple assim tão desesperada ? Não era melhor mudar certos elementos irritantes do interface em vez de adicionar mais bling-bling ? Já estou farto de ter de aturar esses quirks sempre q tenho de usar os G5's (BTW, a alcunha deles, dada pelos próprios users de flash e freehand em mac's é os "Jacintos", vá-se lá saber pq) lá da Fac..
Pronto, é Unix (FreeBSD), tudo bem, mas eles só fazem mesmo o interface, não têm desculpa.
Come on, Steve, get a grip.
(/Rant)

Ficam aqui links com informação sobre o Tiger:

Tour e features -> http://www.apple.com/macosx/
Developer Overview -> http://developer.apple.com/macosx/tiger/index.html
Tiger Server Preview -> http://www.apple.com/server/macosx/tiger/

Não encontrei nenhuma preview/review de sites "independentes" sobre o Tiger. Se alguem tiver um link, que meta aqui.

A nivel da versão server e sem conhecer as versões antigas, pela descrição do site, nao me parece que tenha grandes novidades. Pelo menos em comparação com a versão consumidor.

Quanto às features do Tiger, o que me chama mais à atenção é o "Dashboard". Parece-me uma excelente ideia.
O Automator é outra das coisas que me parece muito util, apesar de pouco falada.

Em relação ao Core image, continua a não ver no site da Apple os requisitos minimos.
Era bom que houvesse suporte para o Mac mini, nem que fosse parcial.

Eu vou estar atento ao Xcode 2.0.

O gcc 4.0 trás ganhos bastante interessantes em desempenho e aproximam-no do XLC da IBM, e o debuger gráfico tb é interessante.
Ahh, isto faz parte do Tiger.

Another new feature in Xcode 2.0 is graphical remote debugging. For many applications, the best way to debug a problem is to run the application on the same machine on which the developer is working in Xcode. But when working on full-screen applications, such as games, or debugging event handling, remote debugging gives you the ability to run an application on another machine and have access to most of the same debugging features you are used to having.

Along with improvements to the GUI, Xcode 2.0 will ship with GCC 4.0 which features a new C++ Parser and several code generation improvements including auto-vectorization. While hand-tuning Velocity Engine code can get you the maximum performance from the G4 and G5 processors, now you can have GCC do the heavy lifting for you. You'll benefit from this without any extra effort, with auto-vectorization in GCC bringing anywhere between a 4X and 14X performance improvement to code that works with arrays of data.

Wow... ja agora, será k o 10.4 corre no G4 ainda? (n li a noticia toda n tenho tempo talvez se houver alguma alma caridosa que me diga kuais sao os req. minimos)

Wow... ja agora, será k o 10.4 corre no G4 ainda? (n li a noticia toda n tenho tempo talvez se houver alguma alma caridosa que me diga kuais sao os req. minimos)

Claro que corre. Aliás, ele ainda não foi lançado pq havia um problema qq com os ibook's 12' e o superdrive ou coisa parecida. Acho que nem bootavam. Se andam a testar o Tiger em ibooks é pq corre no G4. Agora, sem um placa suportada que suporte o CoreImage e afins por hardware todas as novas mariquices ficam mais lentas.

Nota: o Mac OS X 10.3.9 tb está prestes a ser lançado. Provavelmente este fim de semana ou no início da próxima semana se tudo correr bem.

O Dashboard é tão inovador que é um autêntico ripoff ao Konfabulator!! É um daqueles ripoffs brutais! Agora todos os MacUsers (pelo menos os menos informados) vão dizer que é excelente e muito original e tal... Mas eu tenho o mesmo no meu PC com o Konfabulator.

O Konfabulator só existia originalmente para Mac, só que quando a Apple anunciou o Dashboard que claramente tirou muita "inspiração" ao Konfabulator os develps do programa viraram-se mais para windows e lançam sempre as versões windows primeiro.

Para saberem mais sobre o programa:

http://www.konfabulator.com/

Isso é uma mariquice. Ainda bem que há o port para windows. Assim posso ter algo parecido ao que vou ter no Tiger no Windows. Esses gajos deviam era estarem contentes por a Apple incluir isso no Mac OS X. Podem agora desenvolver montanhas de widgets para o Tiger e até vendê-los. É que com a inclusão disto no Tiger toda a gente com Mac e Tiger fica a saber o que é.

O Dashboard é tão inovador que é um autêntico ripoff ao Konfabulator!! É um daqueles ripoffs brutais! Agora todos os MacUsers (pelo menos os menos informados) vão dizer que é excelente e muito original e tal... Mas eu tenho o mesmo no meu PC com o Konfabulator.

LIES!!! Não estou a ver nenhuma semelhança.....:D

Agora a sério, tens ideia se o Dashboard é este software licensiado ou é mesmo rip off?

É pena, pensava que era ideia da Apple. Mas parece-me ser algo bastante util. Confirmas?

Eu vou estar atento ao Xcode 2.0.

O gcc 4.0 trás ganhos bastante interessantes em desempenho e aproximam-no do XLC da IBM, e o debuger gráfico tb é interessante.
Ahh, isto faz parte do Tiger.


Tenho algumas dúvidas que o GCC 4.0 faça parte do Tiger... pela razão mais óbvia do mundo...

Lá está. É a tal história das patentes de software. O que é que a Apple copiou? É que o Konfabulator baseia-se em coisas conhecidas e do domínio público. O Active Desktop da Microsoft não é muito diferente, certo?

afinal o que é o dashboard? é que tou mesmo lazy para ir pesquisar.. :P sorry :P

_zZz_

afinal o que é o dashboard? é que tou mesmo lazy para ir pesquisar.. :P sorry :P

_zZz_

http://www.apple.com/macosx/tiger/dashboard.html

Tenho algumas dúvidas que o GCC 4.0 faça parte do Tiger... pela razão mais óbvia do mundo...

Do que li, nas betas trazia o 3.3 e o 4, com o 4 em default.
Mas não vi nada sobre a final, por isso pode mudar.

LIES!!! Não estou a ver nenhuma semelhança.....:D

Agora a sério, tens ideia se o Dashboard é este software licensiado ou é mesmo rip off?

É pena, pensava que era ideia da Apple. Mas parece-me ser algo bastante util. Confirmas?

Do site (Journal deles):

It seems that Apple thinks Konfabulator is pretty cool! Just to clear the air, Apple has not bought Konfabulator, it hasn't hired the developers, it hasn't even talked to us. They just seem to like our product. A lot!

We already knew that many individuals at the company liked Konfabulator (for various reasons but mostly because it was something that differentiated the platform in a very Mac-like way). Now we know that the corporation likes it ... or something that looks just like it.

So what does this mean for Konfabulator? Well, for starters, Dashboard wont be available for at least 9 months (perhaps 12) so your options are limited to the original for quite a while. Secondly, people seem a little unsure that they only want to see or interact with their Widgets in a special Exposé mode. Some Widgets (iTunes controllers spring to mind) should be on the screen all the time. Personally, I would have liked to see an enhancement to Exposé that would let me nominate apps (like Address book or System Preferences) that were only visible in a special mode. That would have been a logical evolution of the functionality.

Konfabulator is already way ahead of Dashboard in terms of functionality (from what I've seen in the demo) and over the next year it'll get a whole lot better. Make sure to tell us what you want to see.

For Widget users things are looking pretty rosy. They can have something that's better than Dashboard now and they can rest assured that Widgets will be around for some time to come.

Remember, Konfabulator is Whatever you want it to be, anything else is just a sincere imitation.


Já conhecia o Konfabulator há bastante tempo e até fiquei agradado por este passo da Apple é que assim eles mudaram-se para windows.

Podem ler o resto do journal deles no site.



Nemesis, tens cenas muito loucas. As primeiras versões para windows tinham um bug de memória que aquilo comia recursos como se não houvesse amanhã, mas as novas versões já estão boas. Eu utilizo alguns widgets bastantes uteis do Konfabulator. Existem MUITOS por essa net fora. Prefiro o Konfabulator ao Samurize por exemplo.


Xpirit, acho que dizes isso porque foi a Apple a copiar se tivesse sido a Microsoft a tua posição teria sido a mesma?

A mim não me afecta em nada eles terem copiado a ideia, até é melhor porque agora tenho o Konfabulator no windows.

E é verdade o próprio Konfabulator baseia-se em muita coisa que anda pela net... o próprio DesktopX da Stardock. Mas o look das widgets do Dashboard é muito à la Konfabulator se me faço entender! Só não vê quem não quer!

Mas eu não tenho nada contra a Apple ter feito o "port" ripoff coff coff do Konfabulator para o seu sitema Operativo... Mas e quanto à Dock da Apple? Porque é ameaçaram o autor da Y'z Dock a desistir da mesma porque eram um ripoff da dock da Apple? Hmm...

Já agora o criador do Konfabulator trabalhou na Apple...

Olha desconhecia esse Konfabulator e agora vou investigar.
Porreiro

Do que li, nas betas trazia o 3.3 e o 4, com o 4 em default.
Mas não vi nada sobre a final, por isso pode mudar.

Epá, o 4.0 ainda não saiu. Não está previsto antes de dia 14 de Abril, mas se a Apple gosta de futurologia...

Epá, o 4.0 ainda não saiu. Não está previsto antes de dia 14 de Abril, mas se a Apple gosta de futurologia...

o desenvolvimento gcc 4.0 para PPC é coordenado pela Apple.

o desenvolvimento gcc 4.0 para PPC é coordenado pela Apple.~

Apenas o Assembler.
O front-end é comum, como é óbvio.

~

Apenas o Assembler.
O front-end é comum, como é óbvio.

qual front-end? o parser? Como as instruções PPC são diferentes o parser de assembler é diferente. Bom, mas confesso que estrutura interna de compiladores não é *ainda* :D o meu forte.

Mas eu não tenho nada contra a Apple ter feito o "port" ripoff coff coff do Konfabulator para o seu sitema Operativo... Mas e quanto à Dock da Apple? Porque é ameaçaram o autor da Y'z Dock a desistir da mesma porque eram um ripoff da dock da Apple? Hmm...


Lá está, a lei não protege as pessoas que desenvolvem. Mas... quando dizem rip-off estão a referir-se a quê? à ideia, ao aspecto gráfico? Mas em que ficamos? Isto pode ser copiado ou não? É que as pessoas que estão contra as patentes de software tem uma ideia contrária.

Lá está, a lei não protege as pessoas que desenvolvem. Mas... quando dizem rip-off estão a referir-se a quê? à ideia, ao aspecto gráfico? Mas em que ficamos? Isto pode ser copiado ou não? É que as pessoas que estão contra as patentes de software tem uma ideia contrária.

Repara... Eu quando digo ripoff falo da funcionalidade, aspecto... é em tudo semelhante! Ainda para mais já existindo anteriormente o Konfabulator para Mac.

Agora... estou contra? Bem em certa parte sim por ser tão parecido, mas não me afecta. Pelos vistos tirando o facto de ter ficado um bocado chateado com a Apple e ter passado para segundo plano os releases (e de se ter movido para windows) parece não chatear muito o autor do Konfabulator.

Se realmente é válido "copiar" o konfabulator e penso que sim, não vejo problema nisso porque razão se insurge a Apple contra quem faz uma dock parecida com a da Apple para windows, a Y'z Dock caso não saibam. Emula muito bem a dock da Apple e a Apple obrigou o autor de desistir de distribuir o pequeno software (grátis) se não levava com um processo em cima.

Mas por exemplo não faz o mesmo à ObjectDock que é da StarDock...

Enfim, grandes empresas, grandes interesses...

qual front-end? o parser? Como as instruções PPC são diferentes o parser de assembler é diferente. Bom, mas confesso que estrutura interna de compiladores não é *ainda* :D o meu forte.

Não existe parser de assembly. Existe assembler.
O front end é o que faz o parsing da linguagem, e a converte em E3C. Aqui podem ser feitas as primeiras optimizações óbvias.

Só depois é que vai para o back-end que trata da gestão de memória, e mais tarde dos registos, e só finalmente são feitas as optimizações específicas da plataforma e no fim o assembler.

(Rant)
Assim que todos os users de Apple tiverem comprado este update, em cinco ou seis dias, portanto, já o Windows XP x64 vendeu 6 ou 7 vezes mais. Outra coisa que se vê nesta descrição da amazon é como eles dão grande ênfase ao novo look de uma nova aplicação ou novos filtros e efeitos acelerados... realmente, para ter um rip-off do windowsblinds (n me venham com a skin do Aqua, pois há mtas mais e bem melhores) não era preciso tanto alarido.
A vossa mui odiada (e, ao mesmo tempo, estimada) MS não mudou nada no interface e adicionou características que aumentam a estabilidade e a segurança (pelo menos não está pior, mas como user das versões alpha e beta há mtos meses, acho-o mto melhor) do novo OS, cuja base é a do Win2003 Server x64. Está a apple assim tão desesperada ? Não era melhor mudar certos elementos irritantes do interface em vez de adicionar mais bling-bling ? Já estou farto de ter de aturar esses quirks sempre q tenho de usar os G5's (BTW, a alcunha deles, dada pelos próprios users de flash e freehand em mac's é os "Jacintos", vá-se lá saber pq) lá da Fac..
Pronto, é Unix (FreeBSD), tudo bem, mas eles só fazem mesmo o interface, não têm desculpa.
Come on, Steve, get a grip.
(/Rant)


Pronto... lá tinha q vir o "do contra".

Mais uma vez... o Tiger NÃO É UM UPDATE!

Falas, falas, falas, falas... e n te vejo a fazer nada :P

Curiosamente o Longhorn tb vai ter efeitos "apaneleirados". Q giro, né? Assim vai haver mais pessoal com pcs "amaricados".

Rip-off do Windowblinds??... oh meu amigo, informa-te primeiro e diz os disparates depois, sim?

E se há "certos elementos pormenores" q te irritam, n quer dizer q irritem os restantes users.

Sempre ouvi dizer... "quem desdenha quer comprar".

Mais uma vez... o Tiger NÃO É UM UPDATE!

Também lhe podes chamar "actualização", "minor version" e afins... embora essa história não leva a lado nenhum...

Não existe parser de assembly. Existe assembler..

Então como é que passas do Assembler em Ascii para código assembler binário sem o parser?

Repara... Eu quando digo ripoff falo da funcionalidade, aspecto... é em tudo semelhante! Ainda para mais já existindo anteriormente o Konfabulator para Mac.

Bom, nesse caso tanto o konfabulator e o Dashboard são rip-offs de uma coisa muito mais antiga que surgiu nos Mac's faz 20 anos. O Desk Ornaments.
A ideia é a mesma. A diferença é na tecnologia usada (javascripts, e afins) e aspecto (para melhor). Atenção!!! Os Widgets são coisas à parte. Qualquer pessoa pode desenvolvê-los. A estrutura que os suporta é que está em discussão. ATENçÃO, estou a falar de VINTE ANOS! Sabem como eram os PC's nesta altura? Eu lembro-me. Desenvolvia para um IBM PC com ecran verdinho em modo texto. Para fazer gráficos dava trabalho.

http://www.folklore.org/StoryView.py?project=Macintosh&story=Desk_Ornaments.txt

Também lhe podes chamar "actualização", "minor version" e afins... embora essa história não leva a lado nenhum...

Pois... tal como no windows. E então assim tinhamos: o 98 é update do 95; o Xp é update do 2000, and so on.

Update à maneira foi quando o Word passou da versão 2.0 pra 6.0
Aquilo é que foram melhorias que nunca mais acabavam

Então como é que passas do Assembler em Ascii para código assembler binário sem o parser?

Não passas. Esse passo não existe.
Passas do E2C para assembly.

DeepSnoozer: já te começavas era a moderar um bocadinho, tanto com as ofenças como o facto de abrires agora uma nova thread de 5 em 5 minutos.

pelo que li, sei que recebeste um novo powerbook, eu gosto bastante de mac tb, acredito que estejas entusiasmado, mas têm lá um bocadinho de calma.

fica bem
[]

Não passas. Esse passo não existe.
Passas do E2C para assembly.

O que é que é para tí assembly? O código binário final ou o assembler *escrito* ?

olha, passa lá isto para código final sem usar um parser.

void __declspec(naked) main()
{
// Naked functions must provide their own prolog...
__asm {
push ebp
mov esp, ebp
sub esp, __LOCAL_SIZE
}

// ... and epilog
__asm {
pop ebp
ret
}
}

PS. No IST não obrigam as pessoas a programar em assembler? Bolas, só de pensar que até à unha tive que programar assembler. Convertia com lápis e papel Z80 em código binário e introduzia-o à pata. Enfim!

Obrigam sim senhora...
Mas é x86
Fiz um jogo das cobras e mais umas merdas que já não me lembro bem.
O meu irmão é que anda com isso agora :P
E ele até deve ter aprendido mais Assembler que eu.
Mas isso tu sabes melhor que eu ou não?
Essa do lápis já não é do meu tempo. Mas podia ser pior. O meu tio ainda andou com cartões dum lado pro outro e quando o programa pifava nunca sabiam bem se os furos estavam bem feitos ou se era do código.

olha, passa lá isto para código final sem usar um parser.

void __declspec(naked) main()
{
// Naked functions must provide their own prolog...
__asm {
push ebp
mov esp, ebp
sub esp, __LOCAL_SIZE
}

// ... and epilog
__asm {
pop ebp
ret
}
}

PS. No IST não obrigam as pessoas a programar em assembler? Bolas, só de pensar que até à unha tive que programar assembler. Convertia com lápis e papel Z80 em código binário e introduzia-o à pata. Enfim!

1º isso é inline asm, o meu conhecimento de architectura de compiladores é algo limitado por enquanto, mas assim são coisas diferentes, o compilador usa o parser, descobre um bloco asm, chama o assembler, executa-o (neste caso o masm de certeza, ou variante visto tratar-se de vc++ specific), o parser continua o resto e no final o linker liga tudo (tanto o codigo c/c++ como o que já tinha sido criado com o assembler).

2º um gajo que passa a vida a defender apple e gcc e depois mostra um exemplo que cuja sintaxe não segue o sintaxe at&t do gcc, e ainda usa keywords MS specific como o __declspec.. :P

3º no IST por enquanto só usamos asm especifico para um cpu "virtual" que eles lá têm (com instruções genericas, como push, pop, add, sub, etc, sem uso de qq extenção como mmx, sse's, etc), mas sim, mais lá para a frente (arch compiladores provavelmente) usa-se asm x86 specific.

O que é que é para tí assembly? O código binário final ou o assembler *escrito* ?

olha, passa lá isto para código final sem usar um parser.


É enfiado a martelo no código. Para isso não precisas de um compilador para nada. Basta um assembler.

É enfiado a martelo no código. Para isso não precisas de um compilador para nada. Basta um assembler.

não basta não! Quase toda a gente hoje em dia programa assembler com inlines em c. Este assembler passa por um parser. Se achas que não, bom, tens direito à tua opinião.

1º isso é inline asm, o meu conhecimento de architectura de compiladores é algo limitado por enquanto, mas assim são coisas diferentes, o compilador usa o parser, descobre um bloco asm, chama o assembler, executa-o (neste caso o masm de certeza, ou variante visto tratar-se de vc++ specific), o parser continua o resto e no final o linker liga tudo (tanto o codigo c/c++ como o que já tinha sido criado com o assembler).

2º um gajo que passa a vida a defender apple e gcc e depois mostra um exemplo que cuja sintaxe não segue o sintaxe at&t do gcc, e ainda usa keywords MS specific como o __declspec.. :P

3º no IST por enquanto só usamos asm especifico para um cpu "virtual" que eles lá têm (com instruções genericas, como push, pop, add, sub, etc, sem uso de qq extenção como mmx, sse's, etc), mas sim, mais lá para a frente (arch compiladores provavelmente) usa-se asm x86 specific.



Foi o primeiro que encontrei via google. Deves estar a achar que eu tenho muito tempo. Já acho a minha participação bastante acima da média. Mesmo o inline assembler pode ter referências a variáveis declaradas no c/c++. Portanto a hipótese de passagem directa para o assembler não está totalmente correcta. Há que passar as referências a variáveis. Mas lá está. Depois o assembler tem um parser. Ainda outra coisa. O gcc actual não processa inline de assembler directamente? É que já lá vai o tempo que fazia isso.

É enfiado a martelo no código. Para isso não precisas de um compilador para nada. Basta um assembler.

estamos a falar de parser e não de compiladores como tu o entendes. Por outro lado o Assembler (masm, asm,etc) são compiladores também.

não basta não! Quase toda a gente hoje em dia programa assembler com inlines em c. Este assembler passa por um parser. Se achas que não, bom, tens direito à tua opinião.

O uso de ASM é do pior que se pode fazer em 99% dos casos.
Em qualquer software que não dependa da plataforma não pode usar ASM, e com isso torna o ASM quase completamente inútil.

O assembler não passa por um parser. Na melhor das hipóteses esse assembler tem um parser, e converte directamente ASCII para bytecode.


estamos a falar de parser e não de compiladores como tu o entendes. Por outro lado o Assembler (masm, asm,etc) são compiladores também.

Acho que ainda não percebeste.
O códido asm que meteres em qualquer código não é mexido, não é alterado, não é optimizado. É espetado no resto do bytecode juntamente com o resto do programa.

Um compilador é sempre a mesma coisa. Assemblers não são, nunca foram e nunca serão compiladores. Não fazem gestão de registos, não fazem gestão de memória, não alinham os acessos, não fazem optmizações, etc etc etc.

Um assembler limita-se a converter ASCII para bytecode.