Hola. No conozco la tecnología con la que trabajas así que toma lo que te digo
con pinzas, pero así a simple vista tengo entendido que el tipo de imágen bmp no
soporta transparencia por lo cual es natural que el alpha te devuelva 255 (100%
opaco). Te recomiendo probar lo mismo pero con el tipo png. suerte

On Mon, 26 Oct 2009 06:44:44 -0700 (PDT)
kikoGregoris <kikogregoris@...> wrote:

> Hola gente
>
> Tengo que obtener el valor del canal alpha de un bitmap en grayscale, y no veo
forma de hacer esto en Dolphin.
>
> Miro la clase Bitmap , Image y  GdiPlusImage.
> Traté de hacer algo como esto:
>
> GdiplusBitmap fromBitmap: (  Bitmap fromFile: 'C:\Documents and
Settings\Gregoris\Mis documentos\Dolphin Smalltalk
X6\TerrainEditor\assets\Textures\test.bmp')
>
> Luego miro el canal alpha así:
> 1 to: 255 do:[: x | 1 to: 255 do:[:i | (self pixelAt: x@i ) alpha  < 255
ifTrue:[^x@i]]].
>
> Para ver si hay algo, pero todos los alpha son 255.
>
>
> Incluso en el ejemplo:
>
> GdiplusGraphics>>exampleGdipGAlphaBlending
>     "Using GDI+ .... Alpha Blending Lines and Fills ... Using Compositing Mode
to Control Alpha Blending
>
>         self exampleGdipGAlphaBlending showExample
>     "
>
>     "Create a blank bitmap."
>
>     | bitmap graphics redBrush greenBrush bitmap2 graphics2 |
>     bitmap := GdiplusBitmap width: 180 height: 100.
>     "Create a Graphics object that we can use to draw on the bitmap."
>     graphics := bitmap graphics.
>     "Create a red brush and a green brush, each with an alpha value of 160."
>     redBrush := GdiplusSolidBrush color: (ARGB fromArray: #(210 255 0 0)).
>     greenBrush := GdiplusSolidBrush color: (ARGB fromArray: #(210 0 255 0)).
>     "Set the compositing mode so that when we draw overlapping ellipses,
>     the colors of the ellipses are not blended."
>     graphics compositingMode: CompositingModeSourceCopy.
>     "Fill an ellipse using a red brush that has an alpha value of 160."
>     graphics fillEllipse: (0 @ 0 extent: 150 @ 70) brush: redBrush.
>     "Fill a second ellipse using green brush that has an alpha value of 160.
>     The green ellipse overlaps the red ellipse, but the green is not blended
with the red."
>     graphics fillEllipse: (30 @ 30 extent: 150 @ 70) brush: greenBrush.
>     "Prepare to draw on the screen."
>     bitmap2 := GdiplusBitmap extent: 400 @ 200.
>     graphics2 := bitmap2 graphics clear: ARGB white.
>     graphics2 compositingQuality: CompositingQualityGammaCorrected.
>     "Draw a multicolored background."
>     graphics2 fillRectangle: (200 @ 0 extent: 60 @ 100)
>         brush: (GdiplusSolidBrush color: (ARGB stdColor: #aqua)).
>     graphics2 fillRectangle: (260 @ 0 extent: 60 @ 100)
>         brush: (GdiplusSolidBrush color: (ARGB stdColor: #yellow)).
>     graphics2 fillRectangle: (320 @ 0 extent: 60 @ 100)
>         brush: (GdiplusSolidBrush color: (ARGB stdColor: #fuchsia)).
>     "Display the bitmap on a white background."
>     graphics2 drawImage: bitmap at: 0 @ 0.
>     "Display the bitmap on a multicolored background."
>     graphics2 drawImage: bitmap at: 200 @ 0.
>     ^bitmap2
>
>
> Todos los alpha de la imagen son 255 !!.
>
>
> Algo me estoy perdiendo y no  veo que es.
> Alguna idea de como  hacer esto ?
>
> saludos kiko
>
>
>
>
>
>
>       Yahoo! Cocina
>
> Encontra las mejores recetas con Yahoo! Cocina.
>
>
> http://ar.mujer.yahoo.com/cocina/


--
Sebastian Gurin <sgurin@...>

Buenas tardes,
Mis disculpas si posteo algo demasiado básico para los mensajes que veo en el
grupo por estos días, pero este link que pego aquí me ayudó mucho para mostrar
información en listas multicolumna:

http://www.mindspring.com/~lsumberg/Dolphin/PersonalMoney/index.htm

El autor Louis Sumberg retoma aquí el tutorial "Personal Money" y le incorpora
ésta y otras mejoras.

A mí me gustaría agregar en la sección de "Enlaces" del foro una carpeta con
direcciones para orientar a principiantes, y así evitar, como yo, realizar
preguntas innecesarias. Pero lo dejo a criterio de ustedes.

Saludos
Gerardo

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.14.20/2444 - Release Date: 10/18/09 09:04:00

On Mon, 19 Oct 2009 09:53:47 -0300
"Carlos E. Ferro" <ceferro@...> wrote:


alejandro decía:

> > 2.- sobre que "todo en smalltalk es un
> > objeto", te lo creiste solo al comienzo no? Sabes que no es asi...
> > no? (si aun crees que en smalltalk todo es un objeto, no dejes de ir
> > a una de nuestras presentaciones de ambientes de objetos :-) lo digo
> > en serio... te estas perdiendo de "algo importante" si pensas que esa
> > muletilla introductoria es correcta.
>

Me gustaría oir ejemplos de entidades que en smalltalk no son objetos...

carlos decía:

> Esto es otra cosa fundamental y que sólo encontré en Smalltalk.
> Para un programador COBOL, "desarrollarse" como programador era poder escribir
más rápido y pensar menos... Adquirir mejores templates de programas y el mejor
editor de textos.
> Para el programador Java, desarrollarse ¿es tener la mejor biblioteca de
frameworks y funcionalidades?
>

pregunta interesante, sobretodo para un programador (mucha parte del tiempo) en
java. Es obvio que la tecnología escogida modela nuestra forma de producción.
Una tecnología basada o que alienta un modelo modular va a hacer que la
respuesta a la pregunta de carlos sea Si. (De hecho, basta mirar las ofertas
laborales en java: "se valora experiencia en los frameworks X, Y y conocimiento
de los estándares A, B")

Ahora, bien yo creo que aunque la tecnología nos empuje hacia un lado, también
nos empujan el tipo de proyecto y nuestras propias decisiones. Por ejemplo,
estoy seguro que hay programadores smalltalk con más tendencia a utilizar
módulos que algunos programadores java. O sea la creatividad, las ganas de
aprender, las ganas de enriquecerse resolviendo un problema, van a ser distintas
segun la tecnología que utilicemos, pero también según las ganas ( o los
objetivos) de cada uno.

Lamentablemente concuerdo, muchos colegas javaleros encuentran mucho más
gratificante ver el problema resuelto por unos frameworks que ellos se
encargaron de anudar, que resolver por ellos mismos el problema. Bueno no se si
"lamentablemente"; sigo sosteniendo que hay diferentes clases de
programadores...

Esto lo dijo alejandro:

> > Si uno
> > busca desarrollar capacidades (el producto son los modelos del grupo
> > de trabajo) el exito es mas dificil de medir y se requiere a menudo
> > de varios proyectos (en estos casos son valiosos algunos conceptos
> > que nombró Carlos cuando uno se encuenra dentro de un dominio
> > estricto/estructurado/adulto )

Pregunta de novato, relacionada con lo anterior ,¿cuando hablamos de
programadores, hablamos de alguien que busca desarrollar capacidades? ¿
"desarrollar capacidades" es "programar" ?  ¿ desarrollar es desarrollarnos ?
Por ejemplo, me viene a la cabeza un peón de construcción que pasa por el
edificio terminado: el tipo siente gratificación por el edificio, en gral él no
se dearrolló, se desarrolló la construcción. Lo mismo la gratificación de un
jardinero veterano al sentarse a oler el cesped recién cortado: lo gratificante
es el acto de contemplar la "obra"... No se si se entiende el punto...

>
> Acá ya entramos en el dominio del desarrollo de software y de la ingeniería de
conocimiento.
>
> > En los casos poco frecuentes donde a
> > uno le toca gravitar por diferentes contextos (distintas áreas
> > sociales y productivas) se requiere de un poco más, y allí es muy
> > util el entender y usar un AO; y en esos casos, creo que uno puede
> > percibir de forma mas peculiar que utilidad tiene un ambiente.
>
> Acá se me acabaron las analogías :-)) Esto es único de los ambientes de
objetos, creo.
>

me parece una buena (otra) definición o punto de vista que separa a los
ambientes de objetos de las tecnologías corrientes.


> Saludos
> --
>
> carlos e. ferro* *| senior developer* *|  *caesar systems *| *see clearly.
decide smarter.*
>
> ceferro@... <mailto:ceferro@...> | t:
+1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com
<http://www.caesarsystems.com/>
>
> **This message and any attached documents contain information from Caesar
Systems LLC that may be confidential/trade secret and/or privileged. If you are
not the intended recipient, you may not read, copy, distribute or use this
information. If you have received this transmission in error, please notify the
sender immediately by telephone or by reply e-mail and then delete this message.
>
>
>


--
Sebastian Gurin <sgurin@...>

----- Original Message -----

From: Carlos E. Ferro

To: smalltalking@...

Sent: Sunday, October 18, 2009 11:32 AM

Subject: [objetos] Arrancamos, se larga la ronda de clasificación

El día de la madre no es el mejor para hacer este anuncio, pero aunque quise terminar ayer, no pude.

Declaro oficialmente iniciada la ronda de clasificación/eliminatoria del concurso de programación de Smalltalks 2009.

Ya subí en la sección de archivos del grupo (http://groups.google.com.ar/group/smalltalks-2009-coding-contest) el smalltalks2009ccQua2WindowsExe.rar y el smalltalks2009ccQua2Image.rar, que son el ejecutable y una imagen VW cerrada (para los que no usan Windows) del servidor. Contra este servidor deberán jugar.

No hubo cambios en los comandos, así que las herramientas siguen sirviendo. El jugador de ejemplo también. Hubo ajustes diversos y hay varios mundos nuevos. Ahora encontrarán, además de los aleatorios, personajes con distintos temperamentos e inclinaciones.

El jugador provisto con la estrategia de sólo trabajar hace entre 25 y 40 mil puntos, así que en principio, voy a poner un límite de 64 mil puntos para considerar que pasan la eliminatoria. Tendrán tiempo hasta el domingo antes de la conferencia (inclusive) para mandar los certificados a la cuenta codingContest2009@....
El certificado es un archivo codificado con extensión .cc que genera el servidor cuando terminan de correr todos los mundos.

Bueno, ya falta menos de un mes, así que manos a la obra. Buena suerte y diviértanse.

--

carlos e. ferro | senior developer |  caesar systems | see clearly. decide smarter.

ceferro@... | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com 

This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Hola,

Sebastián decia...
>>Probablemente me
>> ahorre tiempo globalmente, pero gastar el tiempo en algo no
>> relacionado al problema es feo.

Carlos luego decía...
>Me recuerda algo que siempre dice Paenza, un divulgador científico,
> en su programa de televisión y sus libros. El cierra cada programa
> proponiendo un problemita matemático, y siempre repite que lo
> interesante NO es la solución, porque la semana siguiente él te
> da una solución. Lo interesante es pensar el problema, vivir con
> el problema y ejercitar la cabeza, pensar alternativas... Es lindo
> tener problemas; la satisfacción de resolverlos dura un segundo
> pero el disfrute del proceso de resolución es mucho más largo.

Esa en la forma mas acostumbrada de pensar y actuar,
  en el caso de los científicos (la palabra que se me vino
  a la mente fue "matemáticos", pero me contuve y...).
Eso me quedó gravado desde cuatro año en la secundaria
  y luego se reforzó más aún al ser alumno de Paenza en
  Análisis Matemático (cosa que no podía evitar en mi
  recorrido por la carrera de ciencias Químicas).

La actitud de buscar un problema para ser resuelto
  parece noble y parece hacer un gran aporte quien la promueve
  (a veces a quienes no tienen un sustento de conocimiento
  suficientemente maduro como para ver sus concecuencias);
  pero desde entonces siempre me pregunté porqué casi nadie
  veía que concecuencias tiene.

Otra forma de decir lo mismo sería por medio de una
  pregunta simple y directa:
     "Puede no plantearse un problema ?"

Sabemos los efectos de modelar/aplicar la solución a un problema.
Podemos pensar en producir (software) sin atacar un problema?

Muchas veces vemos (ejemplos sobran en programas
  donde se promueven los abordajes cientificos) que el planteo
  del problema requiere de un maestro, requiere del experto
  que nos lo plantea... nos subyuga a sus objetivos.

En el abordaje de sistemas espesificos o ineditos (soluciones
  primeras/unicas) ocurre que no existe el maestro, ni la guía,
  y dibujar/definir un problema es sumar un problema.
En esos casos el avance es "mirando hacia atras", es mirandose
  lo que nos queda en las manos luego de trabajar sobre algo
  que no necesariamente entendíamos al empezar.
En esos casos no sabemos si nos perdemos de soluciones mejores,
  y ocurre como decía Carlos que uno no puede equivocarse,
  simplemente no puede ocurrir que no nos salga lo que queremos...
Pues lo que se ve (el producido), se ve cuando ya salió; cuando está ahí.
Ese producto es para ser observado y retroalimentar el proceso
  de avance, de tallado del sistema.
A veces (como obra tallada) ocurre que otros lo alaban
  antes que nosotros nos dimos cuenta que "lo hicimos".

Este proceso en ciclos es radicalmente diferente al proceso
  guiado por un tutor en base al planteo de problemas;
  pues no esta viciado por la voluntad subyugante del superior;
  del que dicta además "el standard", la forma correcta... la forma única,
  la forma limpia que permite la definición del problema!
  (aquel que esconde en la definición del problema lo que
  quiere que descubramos, y reduce en su definición limpia
  toda posibilida de de escapar con decoro a esa solución
  que parece única/pura una vez que caímos en ella)

Si piensan que uno no puede evitar el plantear(se) problemas...
Piensan que es la única forma de avance?
O puede ser complementada con otras formas de "desarrollo"?

Que valor tiene un ambiente de objetos virtuales para:
- el escenario de "todo esUn: Problema" ?
     (esta condenado a ser una caja de herramientas?)
- el uso de ciclos de experiencia ?
     (que tiene que ya no esté ahí? [*] )

>Hmmm... Es el típico ejemplo de decisión que no se puede
> tomar a la ligera. En Smalltalk, para la GUI, CADA DIALECTO
> inventó una forma distinta de representar y trabajar con los
> widgets, y es la peor pesadilla a la hora de migrar código de
> un ST a otro. Al punto que casi nadie lo intenta, se migra
> ligeramente el código "de modelo" y la GUI se programa de
> nuevo, porque es más fácil que migrarla.

Eso depende de cuan profesional sea el diseño de la GUI.
Hay algunos smalltalks en los que:
- la GUI es experimental y no llego nunca a ser madura.
- la GUI esta construida de una forma tan gótica que de
    esa forma se asegura elproveedor que nadie podrá
    sacar nada de valor de ahi adentro :-)

En DNG tenemos soporte para evitar pagar esos costos
  que muchas veces hacen imposible mover aplicaciones
  de un smalltalk a otro, esto no lo digo con intensión de
  dar mas detalles al respecto, sino para sugerir que
  hay formas de avanzar sin complicar.

Y que cuando vemos complicaciones en Smalltalks de hoy,
  analicemos quién ha sacado provecho de estas complicaciones
  (asi quizás podamos entender porque siguen luego de años
  algunas cosas mas complicadas de lo necesario en Smalltalk).

hasta pronto,
Ale.

[*] ¿como es posible que yo, que existo
no haya sido antes de existir y que alguna vez yo,
que existo ya no seré quien soy?
Tomado de la pelicula "Der Himmel Über Berlin" (El cielo sobre Berlín)
Wim Wenders (1987)

On Tue, 13 Oct 2009 06:34:33 -0700 (PDT)
kikoGregoris <kikogregoris@...> wrote:

> Como lo modelarían ustedes ?.
>
> Que relación hay entre un objetos virtual y uno real que estoy modelando
(Formón/Brush)?.
>
> Trato de pensar en todas las pautas que aquí se han dicho para poder modelar
> correctamente, pero no me cierra.
>
> El desacoplar la forma fuera del Brush, me permite tener un modelo  más
flexible. El tema es que como no logro que
> esto me quede bien modelado    pensé
> en preguntar
>


Hola. Segun lo que te entendí, tu dilema me parece que es el clásico Herencia vs
Delegación. ¿A quien le doy la responsabilidad, a una subclase o a otro objeto?
IMHO no hay una forma correcta de modelar. Probablemente utilizando herencia el
modelo parezca más elegante, pero acordate que estás atado al significado de
herencia (herencia simple). Que la clase Brush delegue la responsabilidad de
pintar a otro objeto puede ser más flexible y en algunos contextos más
eficiente... No creo que exista una forma de modelar "más natural" que otras,
creo que el modelo es siempre algo artificial... La elección depende del
contexto.. un saludo

>
>
>
> saludos
>
>  
>
> PD: Debo volver a Delphi ? jajjaja
>
>
>
>
>
>
>
>       Yahoo! Cocina
>
> Encontra las mejores recetas con Yahoo! Cocina.
>
>
> http://ar.mujer.yahoo.com/cocina/


--
Sebastian Gurin <sgurin@...>

Hola carlos, esta frase te quedó genial.

> Te entiendo y como dije en otros emails, también lo hemos hecho y lo hacemos.
> Lo que quiero remarcar es que no es una decisión para tomar a la ligera, como
que voy paseando por el supermercado y veo una nueva marca de salsa de tomate y
decido llevar una lata para probarla.
> Esa lata pasó por muchas instancias de control y sé que puedo llevarla sin
(gran) temor a intoxicarme.
> Tomar un framework es más bien como ir por un bosque desconocido y agarrar un
hongo que te parece comestible.

Creo que hiciste una ilustración de un framework la cual debería ser mejor
recordada por muchos y me incluyo, que a la hora de un problema, salen al
supermercado de google a ver qué framework consiguen en lugar de considerar que
la elección de un framework debería ser la última opción. Más aún cuando, 
existen supermercados enormes y gratuitos como www.apache.org, sourceforge.net,
etc. Repito, en este contexto es muy tentador salir de compras antes de pensar,
y es muy fácil acostumbrarse. Este thread en lo personal, me sirvió para
recordar eso, que considerar la utilización d eun framework debe ser la última
opción y que "beneficio / productividad" no es igual a "hacer algo que funcione
en poco tiempo"

un saludo!

On Thu, 15 Oct 2009 09:03:21 -0300
"Carlos E. Ferro" <ceferro@...> wrote:

>
>
> Sebastian Gurin wrote: (01/10/2009, comento con bastante retraso)
>
> > Yo no dije que evitaba construir ruedas, aunque no niego que es muy
> > fácil acostumbrarse... es cierto que todas las situaciones son
> > distintas, la solución propuesta por el framework es solo una y
> > seguramente mi situación hubiera sido resuelta mejor con la solución
> > personalizada. Soy consciente que al usar un framework pierdo en
> > flexibilidad, conocimiento y el tiempo que gasto lo gasto en aprender
> > el framework, no el problema que es lo interesante. Probablemente me
> > ahorre tiempo globalmente, pero gastar el tiempo en algo no
> > relacionado al problema es feo.
>
> Creo que no es que no está relacionado al problema; si el framework ataca ese
problema, está relacionado.
> Creo que el problema es que al aceptar el framework, aceptaste la visión de
otros, el modelo de otros. Y lo que es peor, al ponerlo en tu software, te
comprometiste con ese modelo y lo estás apoyando. Esto suena (deliberadamente)
muy ideológico, pero quiero decir que estás renunciando parcialmente a tu
libertad de opinión, para encogerte de hombros y decir "ese tipo debe tener
razón... yo le hago caso". Y eso, lo sabemos todos, casi siempre es peligroso.
> Me recuerda algo que siempre dice Paenza, un divulgador científico, en su
programa de televisión y sus libros. El cierra cada programa proponiendo un
problemita matemático, y siempre repite que lo interesante NO es la solución,
porque la semana siguiente él te da una solución. Lo interesante es pensar el
problema, vivir con el problema y ejercitar la cabeza, pensar alternativas... Es
lindo tener problemas; la satisfacción de resolverlos dura un segundo pero el
disfrute del proceso de resolución es mucho más largo.
>
> >> Lo digo con onda.. para sugerir reflexion sobre las distintas
> >> formas de entender que implica construir sistemas.
> >>
> >> Decia que me resulta extraño porque siempre he encontrado que la
> >> experiencia de construir algo propio es de un ariqueza que excede
> >> por mucho lo que uno intentó obtener de él o ahorrar al no hacerlo.
>
> Esto que decía Alejandro va también en la misma línea.
>
> > Yo parto de la base de que "desarrollar algo" implica "ponerse un
> > objetivo". "Quiero algo que haga esto y esto..." (se que se irá
> > refinando con el tiempo, pero nace un objetivo. Yo en lo personal (o
> > en esta etapa), trato de no colgarme con cosas que me aparten (en
> > tiempo, todo es tiempo) de mi objetivo personal. Cada vez que creo
> > algo nuevo, soy muy crítico de si en realidad es necesario, porque
> > lamentablemente me acostumbré a MI triste verdad: cuanto más código
> > más dificil y vulnerable el software.
>
> Por supuesto. Pero el proceso muchas veces es escribir código, tal vez gran
cantidad, y con eso entender algo. Esa comprensión nos permite ahora pulir la
solución anterior y reducir la cantidad de código.
> Creo que esa es la forma de tener poco código, no privarse de escribirlo desde
el principio.
> Estoy totalmente de acuerdo en no apartarse de los objetivos. Hay una etapa
del que programa con objetos en que cada problema intenta llevarte a modelar el
universo completo (en escala 1:1 de objetos virtuales con reales), y hay que
combatir esa tendencia fuertemente. Pero adoptar cosas de otros sin terminar de
entenderlas no es poner menos código, sino poner más código que encima no
controlás (bueno, es el optimismo de pensar que el tuyo SI lo controlás :-)
>
> > Para llegar a ese objetivo primero necesito solucionar varios
> > problemas que se me presentaran. Para mi, muchas veces, llegar a ese
> > objetivo primero es mucho más valioso que lo que me pueda enriquecer
> > "la experiencia de construir algo propio". Esto me pasa con muchos
> > "algos" que suelen interponerse entre yo y mi objetivo. En esa
> > situación, ya sea porque ese "algo" no me interesa. o porque me
> > interesa pero sé que me va a llevar mucho tiempo, o simplemente
> > porque quiero algo robusto que sé que existe, en esa situación
> > utilizo el framework. Yo se que es una solución que hizo otro para
> > otro problema, pero al menos garantiza ser buena en ciertos aspectos
> > y me permite a mi no estar obligado a comprender las internas. En
> > general, trato de perder con los frameworks lo que quiero perder.
>
> Te entiendo y como dije en otros emails, también lo hemos hecho y lo hacemos.
> Lo que quiero remarcar es que no es una decisión para tomar a la ligera, como
que voy paseando por el supermercado y veo una nueva marca de salsa de tomate y
decido llevar una lata para probarla.
> Esa lata pasó por muchas instancias de control y sé que puedo llevarla sin
(gran) temor a intoxicarme.
> Tomar un framework es más bien como ir por un bosque desconocido y agarrar un
hongo que te parece comestible.
>
> >> Por otro lado la energia y tiempo invertido en hacer "las cosas"
> >> (podemos llamarlo los objetos si quieren :) no es nunca tan grande
> >> como lo sugiere una proyección lineal. En cambio el pensar en no
> >> hacerlo, nos alienta a pensar en un costo oculto o una relacion
> >> alta de costo/beneficio; fundada en la utopia del beneficio sin
> >> realización.
> >
> > A mi se me ocurren aquí ejemplos de situaciones en las que el
> > beneficio sin realización en ciertas actividades, no es una utopía.
>
> Esto depende de qué consideres "beneficio". Por supuesto, se puede ganar
dinero sin realizarse. ¿Eso es un beneficio? ¿Para quién?
>
> > Quiero crear una gui, no me interesa saber cómo pintar en pantalla,
> > manejar eventos a bajo nivel, ni representar widgets de diferentes
> > tipos gráficamente.
>
> Hmmm... Es el típico ejemplo de decisión que no se puede tomar a la ligera. En
Smalltalk, para la GUI, CADA DIALECTO inventó una forma distinta de representar
y trabajar con los widgets, y es la peor pesadilla a la hora de migrar código de
un ST a otro. Al punto que casi nadie lo intenta, se migra ligeramente el código
"de modelo" y la GUI se programa de nuevo, porque es más fácil que migrarla.
> Entiendo lo que decís, yo uso Window Builder en VS y rara vez bajo a ver los
internals, rara vez mapeo una API Windows para un control no soportado... pero
"rara vez" implica que alguna vez lo hacemos y sé cómo hacerlo.
>
> > No me interesa porque mi programa es un super
> > compresor de archivos, y lo único que necesito de la gui es que el
> > usuario ingrese un archivo, no tiene nada que ver con el objetivo
> > principal. Utilizo Morphic, gtk o la winapi porque si tengo que
> > aprender y hacer esto yo solo, no lo haría nunca en mi vida (iría en
> > contra de mi objetivo que es terminar).
>
> OK, pero primero harás un mínimo análisis de cuál de esos usás y por qué. Y la
siguiente vez,el análisis se repite, incorporando tu experiencia previa de uso.
Eso ya es medir consecuencias del uso y es un paso más en la dirección de
entender la problemática de la GUI.
>
> > Necesito un reproductor de películas visual que me permita poner y
> > sincronizar subtítulos visualmente y otras características que no he
> > encontrado en ningún reproductor visual. Me encantaría aprender sobre
> > temas como formatos multimedia, reproducción de video, etc y poder
> > hacer el reproductor desde cero, pero nuevamente gastar 10 años de mi
> > tiempo no está dentro de mis posibilidades. Sé que existe un
> > reproductor de videos que hace todo esto y que puedo reutilizar pero
> > su interface es por líneas de comandos, no visual. ¿Por qué es una
> > utopía entonces beneficiarme de cumplir con mi objetivo principal sin
> > "haberme realizado" ? Algo es algo...
>
> Porque tenés un beneficio a corto plazo, te quedás contento un rato y
compraste problemas a mediano plazo.
> Vos creés que te realizaste y a las dos cuadras te pegás un porrazo porque a
la patineta que compraste se le salió un rulemán... Es como creer que te van a
regalar algo cuando te hacen escuchar la propaganda de un tiempo compartido.
>
> Saludos
> --
> carlos e. ferro* *| senior developer* *|  *caesar systems *| *see clearly.
decide smarter.*
>
> ceferro@... <mailto:ceferro@...> | t:
+1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com
<http://www.caesarsystems.com/>
>
> **This message and any attached documents contain information from Caesar
Systems LLC that may be confidential/trade secret and/or privileged. If you are
not the intended recipient, you may not read, copy, distribute or use this
information. If you have received this transmission in error, please notify the
sender immediately by telephone or by reply e-mail and then delete this message.
>
>
>


--
Sebastian Gurin <sgurin@...>

----- Original Message -----

From: kikoGregoris

To: smalltalking@...

Sent: Tuesday, October 13, 2009 10:34 AM

Subject: [objetos] Pensando en objetos ?

Hola gente Tengo un problema para modelar un objetos que llamo Brush, el cual se encarga de modelar un terreno. Como si fuera un formón de un carpintero. Este Brush  puede ser de dos formas( por el momento), circular o cuadrado, pero podría ser de infinitas formas. En un modelado rápido puse: Brush     SquaredBrush      CircleBrush. Yo creo que esta muy mal y que Brush solo debería conocer de que forma es y actuar en consecuencia. El tema es que no puedo lograr que funcione de esta forma y por eso entre a dudar. Si pienso en el ejemplo del formón, en la realidad este es de una forma u otra, no tiene una punta intercambiable. Lo cual me confunde, porque hace parecer que mi modelo esta bien y que Formón/Brush tiene subclases Pero aquí los objetos son virtuales.jajaj Como lo modelarían ustedes ?. Que relación hay entre un objetos virtual y uno real que estoy modelando (Formón/Brush)?. Trato de pensar en todas las pautas que aquí se han dicho para poder modelar correctamente, pero no me cierra. El desacoplar la forma fuera del Brush, me permite tener un modelo  más flexible. El tema es que como no logro que esto me quede bien modelado    pensé en preguntar saludos PD: Debo volver a Delphi ? jajjaja

---

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Hola a todos! me parece muy interesante comparar los diferentes objetivos o
prioridades de quien realiza la tarea de "programar". Yo de esta charla saco mi
primer conclusión "personal" (algo nuevo para mi), es que "ser productivo" es
muchísimo ma´s que "que cantidad de software / tiempo". Al utilizar
tecnologías que promocionan la modularidad nos olvidamos de cuánto valor hay
en enriquecernos nosotros con el problema.

Ahora bien sigo opinando que hay situaciones en las cuales "la modularidad se
impone". Si tenemos suerte podremos safar, pero si se trata de trabajo muchas
veces no. Hay clientes que quieren y piden "un plugin para firefox"! Haciendo el
mismo razonamiento que hoy yo supongo que si nos dedicamos a nuestras rueditas
siempre, corremos el riezgo de perder la agilidad para integrar módulos. Yo
voto por tener presente ambas cosas al momento de elegir, voto por elegir....

También sostengo la postura de que algunas situaciones es justificable querer
evitar entender / implementar cierta problematica. Hay problematicas que muchas
veces nada tienen que ver con el "modelo de dominio" de nuestra app (sobre lo
que nos interesa enfocarnos y aprender) y ¿ por qué tenemos que desear
entenderlas y resolverlas sin ayuda ? Es cierto, no podemos evitar entenderla,
pero sin un framework tenemos que entenderla por completo...

Bueno no se, quería comparar el caso de la rueda de carlos, . Yo también tengo
proyectos que son así, desde cero, resolviendo las problematicas y descubriendo
mis formas de resolverlas. El placer es más grande cuando se logra algo en ese
contexto que cuando se logra "hacer andar un framework". Me parece interesante
comparar este tipo de desarrollo con lo que sucede hoy en día tecnologías como
java. Ya no existen los frameworks; lo que existe ahora son los estándares.

Sun o quien sea, hace un estándar para portales web, otros para persistencia de
objetos, otros para tecnologías de presentación web, otro para transmisión de
mensajes, etc. Para "cualquier" actividad o problematica que se le plantee al
desarrollador java existe un estándar, que más o menos converje con la
problematica personal. Si existe el estándar existen 1 o más implementaciones
(aunque, juas, muchas veces ocurre que 1) hacen un estándar y demoran tiempo en
surgir implementaciones 2) estándares que solo tienen y tuvieron 1
implementación)

Antes, los autores de los frameworks "obligaban" a uno a adaptarse al framework.
Ahora, además, los autores de los estándares "obligan" al autor del framework.
Ahora tenemos entonces muchos frameworks que implementan el mismo estándar. El
estándar define el problema y la solución, los frameworks lo implementan. Ojo,
no todos los frameworks tienen un estándar atrás, pero la tendencia de todos
es a estandarizar :( Que veo entonces:

* todos programamos en lo mismo y de la misma forma. Actualmente la jvm soporta
otros lenguajes de scripting, pero se programa en el mismo
framework-estándar-lenguaje. Más aún, muchos toolkits/frameworks hoy en día
ya no son distribuidos como las clasicas librerías (modulos) sino que el
usuario se baja la sdk (el entorno de desarrollo para programar con eso)...

Me interesa comparar este contexto con un smalltalk, en dónde como decía
carlos, uno tiene tanta libertad para escojer el nivel en el cual trabajar, no
hay limites entre mis objetos y el resto del sistema, las pocas leyes que hay
son suceptibles de ser cambiadas por el usr, como el concepto de herencia,
mensaje, etc. Son como dos extremos en lo que respecta al insentivo que tienen,
como tecnologías, sobre el desarrollador...

un saludo a todos!


On Fri, 09 Oct 2009 08:57:21 -0300
"Carlos E. Ferro" <ceferro@...> wrote:

>
>
> [ Me pasé a un texto más plano porque el HTML me queda horrible... No sé si
son las propagandas de Yahoo o qué ]
>
> Alejandro F. Reimondo wrote:
>
> > Hola Sebastian,
> >
> > Mas abajo decias...
> >> Esta forma de trabajar, de no reinventar la rueda en cada
> >> funcionalidad nueva, me permite deribar responsabilidades a los
> >> módulos.
> > ...luego...
> >> A mi me sigue resultando extraño que un desarrollador de software
> >> diga que la modularización es una quimera.
> >
> > A mi me resulta extraño que un desarrollador de software trate de
> > evitar el construir ruedas. Y sonreir diciendo que usa la que otro
> > hizo para otra cosa.
>
> Exacto. Siempre estuve más sastisfecho con mi rueda de piedra labrada a
cascotazos, pero a la medida de mis ejes, que con las llantas de aleación
brillante hechas por otro, que después tenía que martillar para que encajaran.
Es increíble la cantidad de frameworks que hay, resolviendo problemas que yo
jamás he tenido.
>
> > Decia que me resulta extraño porque siempre he encontrado que la
> > experiencia de construir algo propio es de un ariqueza que excede por
> > mucho lo que uno intentó obtener de él o ahorrar al no hacerlo.
>
> Ese es otro factor, que hace que esté más satisfecho con mi rueda. No sólo
hice la rueda, mejoré mis cascotes, aprendí un montón sobre los ángulos de
incidencia y el tallado ¡y hasta descubrí que salen chispas cuando golpeás
dos piedras de determinada manera! Todavía no sé si eso podré usarlo para
algo, pero es muy lindo de ver...
> Más allá de la metáfora picapiedras, estoy totalmente de acuerdo. Uno
programa (a veces) porque le pagan para hacerlo, pero sobre todo el programador
Smalltalk programa muchas veces para aprender, para entender usando Smalltalk
como herramienta.
>
> > Por otro lado la energia y tiempo invertido en hacer "las cosas"
> > (podemos llamarlo los objetos si quieren :) no es nunca tan grande
> > como lo sugiere una proyección lineal. En cambio el pensar en no
> > hacerlo, nos alienta a pensar en un costo oculto o una relacion alta
> > de costo/beneficio; fundada en la utopia del beneficio sin realización.
>
> Otra gran verdad. La sombra en la pared asusta más que el objeto.
>
> > Creo que un ejemplo puede servir... El DNG (Next Generation
> > Smalltalk) es un smalltalk de alta tecnología, de muy alta
> > perfomance, posee una VM muy pequeña... Como puede lograrse esto?
> > solo si no se usan componentes y se minimiza el uso de
> > encapsulamiento. Smalltalk, como lenguaje de bajo nivel, posee los
> > atributos necesarios para permitir lo mismo. Y la flexibilidad y
> > extensibilidad para también soportear el uso modular. Como plataforma
> > de desarrollo, es mas conveniente por no forzar a la modularidad.
>
> Sí. Lo bueno es que si quisiéramos módulos al estilo de Pascal, podríamos
implementarlos, pero no estamos obligados a usarlos. Podemos trabajar con un
nivel tan alto o tan bajo (hasta los bytes del assembler) como queramos. Podemos
usar sólo la interfaz pública de un objeto o inspeccionar sus variables de
instancia. Y siempre tenemos la libertad de elegir.
>
> Saludos
>


--
Sebastian Gurin <sgurin@...>

signatureHola Carlos,

>>>Hay una métrica muy sencilla, que enunció hace mucho Dan Ingalls
>>> y a la que no le pudimos encontrar la vuelta:
>>>Todo sistema cuya complejidad exceda lo que una (sola) persona
>>> puede entender, está condenado al fracaso.
>>Aqui debemos prestar atención al momento en que lo dijo...
>>no solo a que se consideraba "industria de software" en esa época,
>>sino tambien a la edad que tenía Dan Ingalls y que estaba
>>haciendo cuando lo dijo :-)
>Me da la impresión de que él sigue pensando (y haciendo)
> lo mismo, al menos lo que leí de sus proyectos hace un
> par de años iba en esa dirección: construir un sistema computacional
> asequible para una persona.
>Igual, podremos preguntárselo en Smalltalks 2009, en noviembre.

Que bueno si presenta algo que haya hecho en Smalltalk!
Algo que aporte a Smalltalk y no a lenguajes de scripting,
  lo digo con onda, a mi no me va eso de usar a Smalltalk
  solo para "inspirarse".

Si en sus palabras se escucha la intención (los argumentos),
  aunque en mi opinión, su forma de entender Smalltalk ha
  cambiado radicalmente. Esto lo digo en base a su presentación
  del año pasado en S3 y a pocas charlas que he tenido en forma privada,
  sobre otros temas, pero que en el fondo tienen centro en lo que
  Smalltalk es hoy para Dan Ingalls y otros (dentro de los que
  no puedo excluirme por mas que lo intente).
Pero me resulta incómodo hablar de lo que él dice/hace; no se
  porque... me siento como hablando mal de un cura :-(

La intensión de mi párrafo era poner el punto en lo que han
  cambiado las personas de la industria de software en este
  tiempo; y la gente "de smalltalk" desde entonces.

>>En ese mismo documento histórico y recomendable para
>>cualquiera que se inicia en Smalltalk, hay otras ideas
>>que no se han realizado y que incluso las cosas devinieron
>>en el sentido inverso (como el caso del sistema operativo).
>Sobre el sistema operativo, ellos querían controlar (o mejor,
> que el usuario controlara) la máquina directamente desde
> Smalltalk.

Lo que se quiere logar con un articulo como ese me parece
  que no es facil de conocer si no se analiza en el contexto
  en que fue escrito (recordá que en esos años la fuerza
  de HP era inmensa, sirve por ejemplo partes del green
  book como para tener idea de qué querian lograr -con
  el proyecto smalltalk, claro, no con los S.O...- ).

Lo mismo ocurre si uno lee solo "las ideas" escritas en
  un articulo como "Back to the future" que fue escrito para
  llamar la atención y motivar en la gestación de Squeak.

He preguntado varias opiniones sobre lo que ellos
  "querían" al escribir el articulo... y con el tiempo me es facil
  encontrar una respuesta (que me satisface); pero
  creo que es porque (con)viví (con)el proceso que
  se llamó Squeak mientras quienes escribiron el articulo
  hicieron lo necesario para lograr lo que querían.

> En esa época fue posible. Luego, los sistemas operativos
> se volvieron monstruos muy grandes y difíciles de manejar
> y esto quedó como un sueño imposible.

Si, para la mayoría de la gente de sistemas; pero todo aquel que
  conoce Smalltalk hace la suya y se da cuenta que el S.O. no es
  necesario en la práctica, basta un año de Smalltalk, o ir a reuniones
  donde se habla sobre eso (como las que siempre hicimos)
  y cómo aprovechamos esas características.

> Hoy, nuevamente con SqueakNOS, Richarte y compañía
> volvieron a bootear una PC con Smalltalk y unas pocas
> líneas de assembler. Así que esto con respecto a los
> SO, va y viene.

Oops! creo que estas omitiendo muchos proyectos similares,
  incluso incluyendo hardware, que fueron descritos en papers
  (al menos dos proyectos asi por cada decada desde el 83);
  y de varios proyectos privados que sustentaros desarrollos
  en la industria aeronautica, automovilistica, etc.

En mi opinión el trabajo de SqueakNOS siempre ha tenido
  el atractivo de estar basado en Squeak, pero no tengo
  información respecto de cuanto soporte(uso) práctico
  ha tenido.
Me refiero a uso en la práctica, pues lo bueno que sea
  Squeak todos lo conocemos, pero eso implica, creo yo,
  también una VM muy rudimentaria, tanto que considero
  que lo deja fuera del uso práctico en dónde ameriataría
  no tener OS.

>Esto que dice Dan es muy piola, pero hasta donde una sola
> persona puede bancar la complejidad de un sistema ¿?

>>Curiosamente, en la práctica, un plato de fideos no es
>>dificil de entender, si no tienen mucho condimento... :-)
>Siempre podés agarrar un solo fideo e ir "sorbiendo".

Si exacto!
El punto importante es usar el tiempo... no lo que uno sorba.
  (lo instantáneo solo produce sensaciones/ideales)
La cinética es muy improtante en el proceso informático.
La reducción de los tiempos no debe guiar la producción
  de software. (esto es posible usando un AO, pero es
  considerado casi siempre una perdida de tiempo
  el demorar mas de lo necesario al producir software
  con LOOs)

>>La oferta de un smalltalk único esta en mi opinión
>>relacionada con la obesidad, no solo la de ese smallltalk,
>>sino de los sistemas que generes con ese smalltalk...
>Es como decía Tolkien, "Un Smalltalk para gobernarlos a todos".

Si.
Y pensar en Smalltalk como un contenido es gran parte del problema.
Por eso nuestros esfuerzos (que siempre son poco
  recompensado por los resultados) en promover el conocimiento
  de Smalltalk mas allá de lo que "tiene dentro".
En nuestra charla con los años hemos incorporado
  un detalle de "las distintas formas de entender Smalltalk"
  que me parece muy positivo para quien tiene espíritu crítico
  o desea explorar mas allá de lo que parece a primera vista.

Estoy casi seguro que nuestra charla no se dará en Smalltalks 2009
  por la misma razón que no se ha dado en las anteriores,
  por los contenidos, siempre se ha requerido de mi presencia
  y en este último año creo que por estar ocupados en nuestras
  labores remuneradas no pudimos permitirnos atender como se debe
  nuestras actividades en este contexto no lucrativo (efecto de
  la crisis :).
Fue uno de nuestros objetivos el lograr que otras personas
  puedan exponer nuestras ideas; pero vamos leeennntttooo :-)
  (en los avances tecnológicos 50 años no son nada)

Igualmente estoy seguro que encontraremos espacios
  dónde nuestra asociacion sin fines lucrativos sea respetada
  como se merece.

> Es muy malo que haya un Smalltalk único, monopólico.
> Por suerte todavía no sucede, aunque pareciera que
> en la familia de Smalltalk comerciales, de uso industrial,
> así fuera.

No nunca fue así.
Ojalá la producción de software no caiga tan bajo
  como para que no exista variedad de plataformas Smalltalk.
En mi opinión sería al extinsión de Smalltalk (cada alternativa
  smalltalk entendida como una especie... que es otra forma
  de entenderlo :-)

Lo que si me alerta es ver que no hay innovación real en Smalltalk.
Veo que incluso algunos "referentes" de otras épocas
  parecen no ver mas allá de las "oportunidades" que dá el
  aprovecharse de la fama de Smalltalk.
Pero al momento de nombrar algún avance, salen con que
  Smalltalk e sun lenguaje dinámico (con el que se puede
  escribir scripts en un browser...).
Estoy deacuerdo que eso satisface al aficionado o a quien no
  es de la industria de software, pero ciego sería uno si
  no reflexionara sobre cuando ayudó a Smalltalk la "oportunidades
  que nos dió Java" (entre tantas otras alternativas que fueron
  planteadas como cosas positivas y con el tiempo vimos como
  afectaron a smalltalk y a la gente de sistemas en general).

hasta pronto,
Ale.