OS X 10.4 Tiger goes Gold

[Xpirit]

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.

 

[greven]

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...

 

[Tafinho]

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* 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.

 

[johncool]

(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

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".

 

[Tafinho]

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...

 

[Xpirit]

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?

 

[Xpirit]

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

 

[johncool]

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.

 

[timber]

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

 

[Tafinho]

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.

 

[sapropel]

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
[]

 

[Xpirit]

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!

 

[timber]

Obrigam sim senhora...
Mas é x86
Fiz um jogo das cobras e mais umas maravilhas que já não me lembro bem.
O meu irmão é que anda com isso agora
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.

 

[sapropel]

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..

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.

 

[Tafinho]

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.

 

[Xpirit]

É 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.

 

[Xpirit]

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..

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.

 

[Xpirit]

É 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.

 

[Tafinho]

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.