Obtendo executáveis de programas escritos em Lua
Luciano de Souza
Tenho a distribuição de Lua 5.1 para windows. Na pasta raiz do
interpretador, encontrei o executável bin2c e fiquei curioso em saber
o que exatamente ele faz.
Consultando documentação na Internet, entendi que ele transforma em
código C arquivos binários gerados com Luac. Então, para experimentar,
fiz exatamente isso. Peguei um arquivo ".lua" da pasta de exemplos e
converti-o: "luac sample.wlua'. Obtive um arquivo binário que chamei
'sample.luac'. Então, fiz: 'bin2c sample.luac > sample.c'.
De fato, obtive um arquivo C bastante grande com definições de Lua.
Minha pergunta é: Este arquivo sample.c, gerado deste modo, contém
tudo o que é necessário para que seja gerado um executável?
Observei que em sample.c, há chamadas à lua_loadfile, então, é claro
que lua.h deve ser declarada e, portanto, deve estar acessível no
momento da compilação. Mas o que pergunto é. Se o arquivo sample.wlua,
utilizava funções de IUP, Luaxml, luasql, etc, quando bin2c converteu
o seu respectivo binário, todas estas definições foram levadas
juntamente?
Presumo que a resposta seja sim para todos os módulos Lua e não para
todas as DLLs. Assim, o executável gerado continuaria a necessitar das
DLLs de IUP, de Luaxml, etc.
Gosto da idéia de ter um só executável sem depender do interpretador.
Então, pensei que este poderia ser um caminho para:
1. Programar o código inteiro em Lua;
2. Gerar o binário luac;
3. Gerar o código-fonte C;
4. Compilar com GCC o código fonte com tudo quanto é necessário para
gerar um executável único que rode sem o interpretador.
Este é o caminho? Se sim, então, apesar de ter de utilizar um
compilador C, não teria de ter praticamente nenhum conhecimento de C.
Estarei correto?
Luciano de Souza
Alex Queiroz
2010/7/6 Luciano de Souza <luch...@gmail.com>:
(...)
> momento da compilação. Mas o que pergunto é. Se o arquivo sample.wlua,
> utilizava funções de IUP, Luaxml, luasql, etc, quando bin2c converteu
> o seu respectivo binário, todas estas definições foram levadas
> juntamente?
Não. O programa bin2c apenas converte qualquer arquivo que você
passar para ele (bytecode Lua, MP3, AVI) para código C. O mesmo
processo deve ser repetido para todos os módulos Lua usados no
projeto.
--
-alex
http://www.artisancoder.com/
Antonio Scuri
A combinação luac+bin2c apenas gera um arquivo que usamos na prática como
um código C gerado automaticamente que substitui a chamada a dofile em algum
ponto do seu programa em C já existente.
Usamos muito essa combinação internamente no IUP. Chamamos esses arquivos
gerados de LOH, e eles são literalmente incluidos nas funções de
inicialização do IupLua e seus módulos secundários usando #include.
[]s
scuri
> --
> Lua BR - http://groups.google.com/group/lua-br
Luciano de Souza
desagradável é responder a quem não parece ter-se esforçado para
procurar e, por isso, em cada mensagem tento demonstrar que li algo
sobre o assunto. Mas em meio a tantas palavras, a objetividade sofre.
O que desejaria objetivamente? Programar em Lua e ter um único
executável sem dependências externas.
Se tudo quanto desejasse estivesse tão-somente nas DLLs de Lua, então,
a questão pareceria mais simples, pois as mesmas funções das DLLs
podem ser obtidas nas bibliotecas estáticas de Lua. Com ligação
estática, poderia incluir quase tudo em um único executável. Digamos
que o programa fosse constituído de 50 módulos ".lua". Poderia combiná-
los com Luac, convertê-los para C com Bin2c, quando compilasse o
executável teria realmente tudo. O Bin2c converte tão-somente o
arquivo dado, mas se este já for a combinação de todos os outros,
então, ele fará o trabalho que dele se espera.
Então, decido utilizar IUP. Creio que o caso é o mesmo. IUP possui
DLLs, mas também possui uma biblioteca estática. Se desejo manter tudo
em um único executável. poderia construir as telas com Led e convertê-
las para C com Ledc e utilizando a API de C para IUP, poderia incluir
tudo no mesmo executável.
Pronto, está resolvido o problema tanto se utilizar Lua quanto IUP.
mas se utilizar Luasql, Luaxml, Loop, Md5 ou qualquer outra
biblioteca, não creio que sempre terei a possibilidade de ligá-la
estáticamente por meio de um ".h".
Se no interior de um ".lua", depois convertido para ".luac" e, por
fim, convertido para ".c", fizer um "require('luaxml'", o que o
require espera é pela DLL de Luaxml. Com Luac consigo combinar módulos
Lua. Com Luac consigo apenas combinar módulos ".lua" e, portanto, as
dependências de DLLs parecem continuar a existir.
O que me incomoda é que, por vezes, estou a fazer um programa
pequenino que, mesmo com interface gráfica, ocupasse não mais que 500
KB incluindo todo o código necessário à sua execução, sem dependências
além do próprio sistema operacional. E porque teria de enviar todas as
DLLs os instaladores teriam de ficar sempre extraordinariamente
grandes e, ainda verificar se tais DLLs já foram gravadas no
computador do usuário. Afinal, como há dependências em DLLs tenho
sempre de garantir que todas estejam presentes e, se mais de um
programa for instalado, é melhor que verifique para que não estejam em
duplicidade.
De fato, não é imprescindível que tudo seja reunido em um único
executável. mas que gostaria, lá isso gostaria! Isto é possível e
razoavelmente prático?
Antonio Scuri
simplesmente o interpretador Lua que carrega justamente um LOH que
inicializa um dialogo simples para execução de programas Lua.
Se voce tiver dificuldades de achar isso no código fonte do IUP me avise
que eu te mando diretamente. Fica na pasta iup/srcconsole.
[]s
scuri
> -----Original Message-----
> From: lua...@googlegroups.com [mailto:lua...@googlegroups.com] On
Luciano de Souza
conjunto completo de IUP possui mais de 13MB. Se o que bin2c gera é
algo que substitui o dofile, então, exceto no que diz respeito a IUP,
cujas bibliotecas serão carregadas com #include <iup.h>, luaxml.dll,
luasql/core.dll continuarão a ser necessárias e, portanto, há que
fazer-se a ligação dinâmica. Se considerar que o peso maior da
aplicação é IUP, de fato, ter as outras dependências não é
propriamente um problema. E se, em algum momento, eu fosse
fundamentalista ao ponto de querer mesmo tudo em um só executável,
então, utilizaria uma bilbioteca XML de C e não de Lua.
Se corretamente entendi, iupview.exe pode ser armazenado em um único
executável porque as duas dependências Lua e IUP podem ser ligadas
estaticamente o que nem sempre será verdadeiro.
O único requisito que ora não preencho é que não domino C. mas segundo
o que tenho observado por aqui, é realmente importante aprender C e,
afinal, para quem sabe Pascal, C não é muito diferente. C parece ter
praticamente o mesmo nível de dificuldade de Pascal. Apenas os
compiladores parecem ser mais temperamentais.
Não estou com os fontes de IUP nesta máquina, mas creio que não terei
problemas em localizar o código a que se refere.
Igor
É só usar o L-Bia. Página do projeto: http://l-bia.luaforge.net/
Igor Ferreira Cemim
Stephen Eilert
> pequenino que, mesmo com interface gráfica, ocupasse não mais que 500
> KB incluindo todo o código necessário à sua execução, sem dependências
> além do próprio sistema operacional. E porque teria de enviar todas as
> DLLs os instaladores teriam de ficar sempre extraordinariamente
> grandes e, ainda verificar se tais DLLs já foram gravadas no
> computador do usuário. Afinal, como há dependências em DLLs tenho
> sempre de garantir que todas estejam presentes e, se mais de um
> programa for instalado, é melhor que verifique para que não estejam em
> duplicidade.
> De fato, não é imprescindível que tudo seja reunido em um único
> executável. mas que gostaria, lá isso gostaria! Isto é possível e
> razoavelmente prático?
Deixe-me ver se eu entendi. Você quer um executável pequeno e, ao
mesmo tempo, quer link estático para não usar DLLs? Estes dois
objetivos são opostos - somem as DLLs e o executável infla.
Qual o problema em usar DLL?
--Stephen
Sent from my Emacs
Luciano de Souza
conseguiria algo assim se todo o c�digo da interface gr�fica estivesse
pr�-instalado em uma DLL. O que gostaria � que o instalador contivesse tudo.
Nesta hip�tese, se utilizasse liga��o din�mica, para IUP, teria de enviar
todas as DLLs e isso soma 13MB. Ent�o, para IUP, penso que a liga��o
est�tica, se a id�ia � que o instalador fique menor, em torno de 4,5MB..
bem, neste caso, penso que para IUP a liga��o est�tica seja melhor. Mas o
restante pesar� muito pouco e, portanto, no instalador posso empacotar as
DLLs.
Mas voc� tem raz�o. Embora 4,5MB seja menos que 13MB, o c�digo seria
inclu�do toda vez que um programa fosse compilado. Ent�o, ao inv�s de
economizar espa�o, estaria aumentando. Bom, mas a id�ia n�o � a economia de
espa�o; � a facilidade de instala��o (execut�vel �nico). Ao fim, talvez seja
esta tradicional preocupa��o com o modo de instala��o dos programas que
tenha feito com que desenvolvedores busquem sempre incluir tudo em seus
programas, consumindo mais recursos das m�quinas. Com os discos e as
mem�rias de hoje, � pouco relevante que um programa ocupe mais espa�o; mas
se todos os desenvolvedores est�o a fazer o mesmo, o sistema rodar� mais
lentamente.
Se n�o ligasse IUP estaticamente, se fizesse dois programas, ficaria
incomodado de gravar duas vezes os 13MB, por isso, teria que:
1. Ter dois instaladores: um para a interface gr�fica e outro para o
programa.
2. Incluir todas as DLLs de IUP no instalador. Durante o processo de
instala��o teria de varrer o computador do usu�rio para ver se l� j� n�o se
encontram. Ao fim, poderia mandar um execut�vel de 14MB e instalar
efetivamente apenas 1.
Com a liga��o est�tica, para IUP, penso que tal n�o ocorra.
----- Original Message -----
From: "Stephen Eilert" <sped...@gmail.com>
To: <lua...@googlegroups.com>
Sent: Wednesday, July 07, 2010 12:31 AM
Subject: Re: [lua-br] Re: Obtendo execut�veis de programas escritos em Lua
2010/7/6 Luciano de Souza <luch...@gmail.com>:
> O que me incomoda � que, por vezes, estou a fazer um programa
> pequenino que, mesmo com interface gr�fica, ocupasse n�o mais que 500
> KB incluindo todo o c�digo necess�rio � sua execu��o, sem depend�ncias
> al�m do pr�prio sistema operacional. E porque teria de enviar todas as
> DLLs os instaladores teriam de ficar sempre extraordinariamente
> grandes e, ainda verificar se tais DLLs j� foram gravadas no
> computador do usu�rio. Afinal, como h� depend�ncias em DLLs tenho
> sempre de garantir que todas estejam presentes e, se mais de um
> programa for instalado, � melhor que verifique para que n�o estejam em
> duplicidade.
> De fato, n�o � imprescind�vel que tudo seja reunido em um �nico
> execut�vel. mas que gostaria, l� isso gostaria! Isto � poss�vel e
> razoavelmente pr�tico?
Deixe-me ver se eu entendi. Voc� quer um execut�vel pequeno e, ao
mesmo tempo, quer link est�tico para n�o usar DLLs? Estes dois
objetivos s�o opostos - somem as DLLs e o execut�vel infla.
Qual o problema em usar DLL?
--Stephen
Sent from my Emacs
--
Luciano de Souza
melhor forma de obter este execut�vel, ent�o, testei-o.
A praticidade � extraordin�ria e a ferramenta parece realmente �ltil. Mal se
cr� que esteja na vers�o 0.2!
Peguei um m�dulo cuja �nica dpened�ncia fosse Lua51.dll. Fiz:
l-bia test.lua
Um execut�vel pequenino foi gerado. Muito bom. Se corretamente entendi,
poderia incluir neste execut�vel inclusive o conte�do de DLL, quase como se
fosse liga��o est�tica. Ent�o, fiz um teste com um arquivo de exemplo de
IUP: submenu.lua. Inicialmente, tentei:
l-bia sumenu.wlua
Como neste arquivo, havia a declara��o "require('iuplua')", informou-me que
este m�dulo n�o existia e, portanto, n�o era poss�vel inclu�-lo. Pudera,
iuplua n�o � um m�dulo, mas uma DLL. A solu��o parecia estar no par�metro
"-l":
l-bia sumenu.wlua -l iuplua.dll
Ent�o, ele reclamou que a DLL n�o existia. Claro! "iuplua" n�o � o nome da
DLL, mas sim o nome exportado para a tabela _G, quando na DLL iuplua51.dll
invocou-se a fun��o lua_openiuplua. Penso que seja isso, ent�o:
l-bia submenu.wlua -l iuplua51.dll
Bom, meu amigo, isso tamb�m n�o funcionou. Continua a dizer-me que a DLL n�o
existe. Mas desta vez, para que n�o houvesse qualquer problema de n�o
encontrar, executei tudo dentro da pasta lua\5.1\clibs, onde est� a referida
DLL. Por isso, pergunto-lhe: nos execut�veis gerados por L-bia, j� conseguiu
incluir DLLs?
----- Original Message -----
From: "Igor" <igor.ferr...@gmail.com>
To: "Lua BR" <lua...@googlegroups.com>
Sent: Tuesday, July 06, 2010 5:17 PM
Subject: [lua-br] Re: Obtendo execut�veis de programas escritos em Lua
Resposta r�pida, sim. � poss�vel criar execut�veis Windows para Lua.
� s� usar o L-Bia. P�gina do projeto: http://l-bia.luaforge.net/
Igor Ferreira Cemim
--
Igor
Eu compilei um executável que utilizava a extensão LuaPacket com
sucesso.
Recomendo que você coloque o L-Bia, código e arquivos da extensão
(estrutura de diretórios)
tudo no mesmo diretório antes de tentar compilar.
Para mim funcionou Ok. O L-Bia é muito últil. Estou conseguindo
utilizar
ele com sucesso no Windows 7. :)
Igor Ferreira Cemim
On 7 jul, 05:12, "Luciano de Souza" <luchya...@predialnet.com.br>
wrote:
Igor
C:\Users\Igor\Desktop\Lua\l-bia.exe
C:\Users\Igor\Desktop\Lua\lua
C:\Users\Igor\Desktop\Lua\lua.exe
C:\Users\Igor\Desktop\Lua\lua5.1.dll
C:\Users\Igor\Desktop\Lua\socket
C:\Users\Igor\Desktop\Lua\Unused
C:\Users\Igor\Desktop\Lua\lua\ltn12.lua
C:\Users\Igor\Desktop\Lua\lua\mime.lua
C:\Users\Igor\Desktop\Lua\lua\socket
C:\Users\Igor\Desktop\Lua\lua\socket.lua
C:\Users\Igor\Desktop\Lua\lua\socket\ftp.lua
C:\Users\Igor\Desktop\Lua\lua\socket\http.lua
C:\Users\Igor\Desktop\Lua\lua\socket\smtp.lua
C:\Users\Igor\Desktop\Lua\lua\socket\tp.lua
C:\Users\Igor\Desktop\Lua\lua\socket\url.lua
C:\Users\Igor\Desktop\Lua\socket\core.dll
C:\Users\Igor\Desktop\Lua\socket\mime
C:\Users\Igor\Desktop\Lua\socket\mime\core.dll
Tente fazer algo semelhanate. :)
Luciano de Souza
'iuplua51.dll'. Bastou que renomeasse a DLL para iuplua.dll que a compila��o
funcionou.
NO entanto, l-bia tem dentro de si lua.exe e n�o wlua.exe. Como resultado,
n�o � poss�vel esconder o console o que, neste caso, � incoveniente.
quando observei o par�metro "-l" imaginei que se referisse a uma dll, mas
consegui compilar com a linha de comando: "l-bia submenu.wlua". Mas agora
come�o a imaginar que "-l" se refira a uma biblioteca C. Ent�o, ser� um
".h"?
O execut�vel resultante, incluiu todo o c�digo de todos os m�dulos, mas n�o
o das DLLs. � um execut�vel pequenino que continua a depender da presen�a
das DLLs. � tamb�m poss�vel p�-las para dentro do execut�vel?
O que consegui funciona bem para programas console e certamente o utilizarei
para este prop�sito. Mas o que obtive n�o � muito bom para GUI. Embora tenha
de deparar-me com os tem�veis compiladores C, para as GUIs, n�o poderei
fugir quando o objetivo for este.
----- Original Message -----
From: "Igor" <igor.ferr...@gmail.com>
To: "Lua BR" <lua...@googlegroups.com>
Sent: Wednesday, July 07, 2010 11:01 PM
Subject: [lua-br] Re: Obtendo execut�veis de programas escritos em Lua
Se com DLLs voc� se refere a extens�o sim.
Eu compilei um execut�vel que utilizava a extens�o LuaPacket com
sucesso.
Recomendo que voc� coloque o L-Bia, c�digo e arquivos da extens�o
(estrutura de diret�rios)
tudo no mesmo diret�rio antes de tentar compilar.
Para mim funcionou Ok. O L-Bia � muito �ltil. Estou conseguindo
Igor Ferreira Cemim
--
Stephen Eilert
> Note que 500KB foi um tremendo exagero. De fato, tem razão. Somente
> conseguiria algo assim se todo o código da interface gráfica estivesse
> pré-instalado em uma DLL. O que gostaria é que o instalador contivesse tudo.
> Nesta hipótese, se utilizasse ligação dinâmica, para IUP, teria de enviar
> todas as DLLs e isso soma 13MB. Então, para IUP, penso que a ligação
> estática, se a idéia é que o instalador fique menor, em torno de 4,5MB..
> bem, neste caso, penso que para IUP a ligação estática seja melhor. Mas o
> restante pesará muito pouco e, portanto, no instalador posso empacotar as
> DLLs.
Alguém aí pode explicar como isso ocorre? Porque eu não faço a mínima
idéia. Para mim, ligação estática apenas copia o código da biblioteca
para o executável - então pouco importa se o código está no executável
ou na dll, ele vai estar em algum canto e o tamanho é o mesmo. Slack
space, talvez?
>
> Mas você tem razão. Embora 4,5MB seja menos que 13MB, o código seria
> incluído toda vez que um programa fosse compilado. Então, ao invés de
> economizar espaço, estaria aumentando. Bom, mas a idéia não é a economia de
> espaço; é a facilidade de instalação (executável único). Ao fim, talvez seja
> esta tradicional preocupação com o modo de instalação dos programas que
> tenha feito com que desenvolvedores busquem sempre incluir tudo em seus
> programas, consumindo mais recursos das máquinas.
Bem, ao meu ver facilidade de instalação é o caso apenas se *não
houver* um programa de instalação. Aí você teria apenas um executável.
Mas como normalmente programas Win32 vêm com um instalador, não faz
tanta diferença se é um arquivo só ou 1000 arquivos.
> Com os discos e as
> memórias de hoje, é pouco relevante que um programa ocupe mais espaço; mas
> se todos os desenvolvedores estão a fazer o mesmo, o sistema rodará mais
> lentamente.
Hein? Contanto que o disco não esteja praticamente lotado, o espaço em
disco ocupado é irrelevante para o desempenho. O espaço em memória
sim, mas hoje em dia isso também não é muito relevante: o espaço
ocupado por código é muito menor do que o ocupado pelos dados. E não
dá pra prever o "memory footprint" com base no "disk footprint".
>
> Se não ligasse IUP estaticamente, se fizesse dois programas, ficaria
> incomodado de gravar duas vezes os 13MB, por isso, teria que:
>
> 1. Ter dois instaladores: um para a interface gráfica e outro para o
> programa.
>
> 2. Incluir todas as DLLs de IUP no instalador. Durante o processo de
> instalação teria de varrer o computador do usuário para ver se lá já não se
> encontram. Ao fim, poderia mandar um executável de 14MB e instalar
> efetivamente apenas 1.
Depende. Hoje em dia, a Microsoft recomanda o que ela chama de "xcopy
deployment". Isso quer dizer que, para instalar uma aplicação, o
usuário efetivamente precisa fazer apenas uma cópia. Para viabilizar
isso, as DLLs vão no diretório do programa, não em System(32). Nesse
caso não é necessário verificar coisa alguma: copie as DLLs para o
diretório de destino e pronto. Caso seja estritamente necessária a
instalação de DLLs em System(32), aí sim vc teria que "varrer" o
computador - mas isso é trabalho para o instalador fazer, não é seu
trabalho. Use um instalador decente ao invés de escrever o seu.
Existe outro ponto: com DLLs, seus dois programas compartilham o mesmo
código em memória, se eles usarem as mesmas DLLs. Cada DLL é carregada
apenas uma vez em memória. E você ainda tem a flexibilidade de fazer
coisas como, por exemplo, carregar a DLL apenas quando o programa
precisar e não na inicialização.
Distribuição de patches também é mais fácil: se só uma DLL precisar de
correção, você pode distribuir só ela.
Não vejo muitos motivos para usar ligação estática hoje em dia. A não
ser que você queira esconder o fato de estar usando Lua, dos olhos de
pessoas leigas.
Antonio Scuri
também. Programas nessa linha em geral funcionam bem para arquivos Lua.
Quando ao problema de não usar o wlua.exe, acho que pode ser contornado
copiando o arquivo wlua.exe que vem no Lua for Windows para lua.exe na pasta
onde o l-bia vai acessa-lo.
O problema de renomear a DLL do IupLua é que os módulos secundários do
IupLua, tal como "iupluacontrols" não vão funcionar. Aproveite para copiar a
DLL de Lua do Lua for Windows para o l-bia, esse pode ser o problema de ele
não estar encontrando o IupLua.
[]s
scuri
> -----Original Message-----
> From: lua...@googlegroups.com [mailto:lua...@googlegroups.com] On
> Behalf Of Luciano de Souza
> Sent: quinta-feira, 8 de julho de 2010 00:39
> To: lua...@googlegroups.com
> Subject: Re: [lua-br] Re: Obtendo executáveis de programas escritos em
> Lua
>
> Encontrei o problema. No require, declarei "iuplua', mas a DLL chama-se
> 'iuplua51.dll'. Bastou que renomeasse a DLL para iuplua.dll que a
> compilação
> funcionou.
>
> NO entanto, l-bia tem dentro de si lua.exe e não wlua.exe. Como
> resultado,
> não é possível esconder o console o que, neste caso, é incoveniente.
>
> quando observei o parâmetro "-l" imaginei que se referisse a uma dll,
> mas
> consegui compilar com a linha de comando: "l-bia submenu.wlua". Mas
> agora
> começo a imaginar que "-l" se refira a uma biblioteca C. Então, será um
> ".h"?
>
> O executável resultante, incluiu todo o código de todos os módulos, mas
> não
> o das DLLs. É um executável pequenino que continua a depender da
> presença
> das DLLs. É também possível pô-las para dentro do executável?
>
> O que consegui funciona bem para programas console e certamente o
> utilizarei
> para este propósito. Mas o que obtive não é muito bom para GUI. Embora
> tenha
> de deparar-me com os temíveis compiladores C, para as GUIs, não poderei
> fugir quando o objetivo for este.
>
>
>
> ----- Original Message -----
> From: "Igor" <igor.ferr...@gmail.com>
> To: "Lua BR" <lua...@googlegroups.com>
> Sent: Wednesday, July 07, 2010 11:01 PM
> Subject: [lua-br] Re: Obtendo executáveis de programas escritos em Lua
>
>
> Se com DLLs você se refere a extensão sim.
> Eu compilei um executável que utilizava a extensão LuaPacket com
> sucesso.
> Recomendo que você coloque o L-Bia, código e arquivos da extensão
> (estrutura de diretórios)
> tudo no mesmo diretório antes de tentar compilar.
>
> Para mim funcionou Ok. O L-Bia é muito últil. Estou conseguindo
Luciano de Souza
quem pense assim. Em um grupo de Python, certa vez, ouvi um indivíduo
a dizer que linguagem boa mesmo era C, que Python era fraquinha, que C
é que tinha construído o windows e que Python somente era valorizada
porque tinha uma biblioteca muito estensa. Mal sabia ele que este é o
maior de todos os elogios. Se o difícil se faz fácil pelos recursos de
uma linguagem, então, mais tempo se tem para pensar no que realmente
interessa. Penso que, para ele, o interessante era haver muitos
ponteiros complicados porque isso ressaltava notavelmente os dotes
intelectuais dos desenvolvedores. Quando li sua mensagem, achei
curiosa a hipótese, mas pensando melhor, há gente para tudo.
Minha preocupação foi mesmo com a distribuição. Se faço um programinha
bem simples, digamos, um listador de diretórios que permita a cópia de
nomes em uma GUI. Bom, neste caso, para mim, que venho do compilado
Pascal, soa estranho que um programinha assim tenha 13MB, tamanho
mínimo para as DLLs de IUP. Mas pensando melhor, o programinha Pascal
também tem um tamanho razoável porque necessita das DLLs da API do
Windows e, neste caso, há a notória desvantagem do código não ser
multiplataforma. E se eventualmente pode haver vantagem na ligação
estática, você bem mostrou que a também desvantagens no que concerne
ao gerenciamento de memória.
Olhe, Stephen, se há mesmo algo que não faria, é deixar de dar os
créditos à Lua. Bom, Lua é decididamente grandinha e não necessita de
mim, mas tenho enorme gratidão pelo que me deu. Sou cego e, por isso,
não podia programar GUIs. Com IUPLua, consegui o que não havia
conseguido em nenhuma outra parte. Então, o que tenho por IUP e Lua é
bem mais do que simples respeito, é afeição de verdade e se empacotar
códigos em um executável ofuscasse esse crédito, sem dúvida, daria um
jeito de mencioná-lo de outro modo. O que sou é realmente muito
curioso e gosto sempre de examinar mais de uma forma de fazer algo sem
que haja um problema de fato.
Antônio, a DLL voltou para o seu nome de batismo. Como vê, estou
virando IUP ao avesso!
Stephen Eilert escreveu:
Antonio Scuri
> bem simples, digamos, um listador de diretórios que permita a cópia de
> nomes em uma GUI. Bom, neste caso, para mim, que venho do compilado
> Pascal, soa estranho que um programinha assim tenha 13MB, tamanho
> mínimo para as DLLs de IUP.
Isso não é verdade. O tamanho mínimo de uma aplicação Lua que use IUP é:
wlua5.1.exe -> 35Kb
lua5.1.dll - > 164Kb
iup.dll - > 365Kb
iuplua51.dll - > 116Kb
Total: 680Kb
Contando com Lua junto. Ou seja bem abaixo dos tais 13Mb. E não estamos
falando de uma aplicação reduzida, apenas de uma versão do IUP sem desenho
gráfico, nem suporte a arquivos de imagem, nem controles estendidos tipo
IupMatrix, mas que inclui todos os controles principais de uma interface com
o usuário tradicional.
Imagino que na sua conta voce tenha incluido tudo relacionado com IUP,
assimo como CD e IM.
[]s
Scuri
Luciano de Souza
resultado é que considerei que todas eram necessárias. Não utilizarei
nenhuma biblioteca de desenho ou manipulação de imagens e, por isso,
creio que tudo referente a CD e a IN não seja importante para mim.
Acho que o único controle estendido que já utilizei foi IupTabs. Se
peguei o espírito da coisa, nesta hipótese, teria de incluir
iuptabs.dll e, creio, iupcontrols51.dll que julgo ser responsável pelo
gerenciamento dos controles estendidos.
Com este tamanho, não há mesmo porque falar em ligação estática. Tenho
que me acostumar a colocar no programa aquilo que ele realmente
utiliza. Adotarei o seguinte procedimento. Se necessitar de um
controle estendido, busco a DLL referente a ele. Executo o programa.
Se funcionar, tudo bem, se não funcionar, então, o programa me dirá
qual foi a DLL faltante e, neste caso, vou adicionando o que faltou.
Muito obrigado! O raciocínio não estava mal, mas a premissa...
Antonio Scuri
padrões.
[]s
scuri
> -----Original Message-----
> From: lua...@googlegroups.com [mailto:lua...@googlegroups.com] On
> Behalf Of Luciano de Souza
> Sent: quinta-feira, 8 de julho de 2010 14:39
> To: Lua BR
> Subject: [lua-br] Re: Obtendo executáveis de programas escritos em Lua
>
Stephen Eilert
> Minha preocupação foi mesmo com a distribuição. Se faço um programinha
> bem simples, digamos, um listador de diretórios que permita a cópia de
> nomes em uma GUI. Bom, neste caso, para mim, que venho do compilado
> Pascal, soa estranho que um programinha assim tenha 13MB, tamanho
> mínimo para as DLLs de IUP. Mas pensando melhor, o programinha Pascal
> também tem um tamanho razoável porque necessita das DLLs da API do
> Windows e, neste caso, há a notória desvantagem do código não ser
> multiplataforma. E se eventualmente pode haver vantagem na ligação
> estática, você bem mostrou que a também desvantagens no que concerne
> ao gerenciamento de memória.
As DLLs da API do Windows não entram nessa contabilidade, a não ser
que elas sejam parte de algum "redistributable" - msvcrt, directx,
msxml ou coisas do tipo.
Hoje em dia as pessoas não têm o menor pudor em distribuir aplicações
em Java (que precisam da JRE inteira e é bem maior do que 13MB) mais
diversos .jars de dependências ou em .NET (que precisa do .net
framework inteiro também).
Em contraste, minha última aplicação em Python com wxWidgets
(wxPython) tinha aproximadamente 4MB. E a distribuição Python é muito,
mas muito maior do que Lua. Só a DLL do interpretador era coisa de
1,5MB.
Lua tem um dos menores runtimes que eu conheço. Portanto, o meu
conselho final é: tente gastar um tempo para descobrir quais são, de
fato, as dependências. Tenho certeza que você vai ter uma boa
surpresa.
-- Stephen
Sent from my Emacs
Igor
embora não muitplataforma, recomendo também a você dar
uma olhada na linguagem AutoIt.