En VS tenes varias formas de definir un metodo api,
con un mecanismo incluso extensible.
Fijate en los implementors de #apiPrimitiveMap
Cada forma se corresponde con una manera de
realizar la llamada nativa; si usas una que no corresponde,
ocurre lo que siempre ocurre con el lenguaje
de máquina :-)
suerte,
Ale.



---- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Tuesday, May 30, 2006 11:06 PM
Subject: [objetos] API: _fastcall


> Hola
>
>   Tengo problemas para invocar una funcion exportada como _fastcall desde
MT.
>
>   Desde VS no hay dramas ya que vasta con usar la palabra reservada API y
listo.
>   Lo que me llama la atencion es que en la ayuda no hace diferencias entre
las distintas convenciones, incluso no nombra a _fastcall la cual es
diferente de las demas por que los parametros son pasados en los registros y
no en la pila.
>
>   Por que en VS funcionan igual, sin hacer diferencias entre
convenciones.??
>   Todo esto esta derivado del uso de genesis3d.
>
>   saludos kiko
>
>
>
> ---------------------------------
>  1GB gratis, Antivirus y Antispam
>  Correo Yahoo!, el mejor correo web del mundo
>  Abrí tu cuenta aquí

En VS tenes varias formas de definir un metodo api,
  con un mecanismo incluso extensible.
Fijate en los implementors de #apiPrimitiveMap
Cada forma se corresponde con una manera de
  realizar la llamada nativa; si usas una que no corresponde,
  ocurre lo que siempre ocurre con el lenguaje
  de máquina :-)
suerte,
Ale.



---- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Tuesday, May 30, 2006 11:06 PM
Subject: [objetos] API: _fastcall


> Hola
>
>   Tengo problemas para invocar una funcion exportada como _fastcall desde
MT.
>
>   Desde VS no hay dramas ya que vasta con usar la palabra reservada API y
listo.
>   Lo que me llama la atencion es que en la ayuda no hace diferencias entre
las distintas convenciones, incluso no nombra a _fastcall la cual es
diferente de las demas por que los parametros son pasados en los registros y
no en la pila.
>
>   Por que en VS funcionan igual, sin hacer diferencias entre
convenciones.??
>   Todo esto esta derivado del uso de genesis3d.
>
>   saludos kiko
>
>
>
> ---------------------------------
>  1GB gratis, Antivirus y Antispam
>  Correo Yahoo!, el mejor correo web del mundo
>  Abrí tu cuenta aquí

Hola,
Recuerdo que hemos hablado de este tema en la lista,
  fijate en los mails históricos, pues en ese entonces comenté
  varios detalles.

>   Además, queria saber como saber cuales son los objetos
> interesados en algun evento.
>   Ya que no encuentro el mensaje apropiado para seber esto,
> si puedo saber que eventos dispara un objeto pero no los
> registrados para cuando dicho evento suceda.

Buscá los sendes de ese evento; es decir, senders del selector.

hasta pronto,
Ale.


----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Tuesday, May 30, 2006 10:07 AM
Subject: [objetos] Eventos Vs.


> Hola
>
>
>   Queria saber si el mecanismo de eventos de Vs, tiene que ver con los
eventos que las ventanas de windows resiven.
>
>   En principio me pareseria que esta mecanismo es nativo de VS y que su
uso se extendio a las ventanas y pane de VS.
>
>   Lo pregunto porque en MT existen eventos pero estos estan intimamente
ligados a los mensajes que window envia a las ventanas.
>   Además, queria saber como saber cuales son los objetos interesados en
algun evento.
>   Ya que no encuentro el mensaje apropiado para seber esto, si puedo saber
que eventos dispara un objeto pero no los registrados para cuando dicho
evento suceda.
>
>   saludos kiko
>
>
> ---------------------------------
>  Horóscopos, Salud y belleza, Chistes, Consejos de amor.
>  El contenido más divertido para tu celular está en
> Yahoo! Móvil

Hola,

El image (v.exe) es el ejecutable que deberías distribuir
  como runtime; junto a los archivos de runtime y librerías (SLLs)
  que use tu aplicación. Esto está explicado claramente
  en los manuales, con un buen detalle de para que sirve
  cada archivo (y que contiene).

Hay varias formas de hacer que al arrancar el image
  una aplicación tome control y presente una interfaz
  de "arranque"... considerá que la aplicación puede
  ser muy pequeña y cargar dinámicamente lo que
  necesite para ejecutar.
Lo más acostumbrado es usar el image de base (v.exe
  de 24kb) renombrado a cómo desees que se llame tu
  aplicación. Es decir, distribuís es v.exe renombrado como
     MiApp.exe
Además distribuís:
1.- MiApp.BMP que será la imagen de presentación
  de tu aplicación (si existe el archivo dónde se arranca
  la aplicación).
2.- miApp.BND que es el archivo de bindings.
(para saber que colocar en el archivo de bindings
  fijate en el manual y en los .bnd que tenes en
  el directorio donde lo tenes instalado; editalos con
  Notepad o abrilos en Smalltalk con File/Open...)

Al final de la lista de bindings (MiApp.bnd)
  colocas una SLL que es la de booteo de tu aplicación...
Esa SLL dispara el mensaje de arranque de la GUI
  de tu aplicación (o lo que necesites,
  x ejm. dar servicios HTTP, etc, etc..)
Considerá que cuando se carga esa SLL deberás tener
  ya cargado lo que esta necesite para arrancar.
Para armar al SLL con le mensaje de booteo de tu
  aplicación hacelo con una expresión como la
  siguiente:
--------------------------------------
  aBuilder bindAction: (Message
   receiver: (Smalltalk at: #MiAppGUI)
   selector: #openInRunTime)
--------------------------------------
dónde MiAppGUI es la clase que implementa
  tu interfaz inicial e implementa el mensaje (de clase)
  #openInRuntime  (u #open si no es sensible a que se
  está arrancando en runtime)

Si trabajas de manera monolítica (grabando todo
  en un solo image), el archivo v.exe
  tendrá todo tu sistema y podrás cambiar en ese
  image el método
    SessionModel>>#startUpSampleGuiApplication

  o colgarte del evento #startup

Fijate en el método
    SessionModel>>#startupSession
  para entender que sucede al arrancar un image.

Estas últimas formas de hacerlo no te las recomiendo,
  si buscas realizar un trabajo bien terminado;
  aunque son formas válidas (y en algunos smalltalks
  la única forma :-).

Mas detalles encontrarás en los manuales y creo que
  en el help.
Recuerdo que hace tiempo hablamos de este tema,
  así que en esta lista debería haber mas información.

hasta pronto,
Ale.


----- Original Message -----
From: "Juan Manuel Duran" <juan_manuel_duran@...>
To: <smalltalking@...>
Sent: Friday, May 26, 2006 2:07 PM
Subject: [objetos] Como ejecutar directamente una aplicacion


Hola gente, les cuento que estoy jugando un poco con Visual Smalltalk y
tengo una duda, quiero saber como hacer para que la aplicación se ejecute
directamente sin tener que entrar al workspace y tener que ejecutar Do It.

Muchas gracias y saludos.

Hola,

>Me pregunto, cual es la forma de resolver este método, con #do: o #to:do: .
>   Digamos que lo que me interesa es cuando debería usar uno u otro
> y cual es el significado de ambos, ya que supongo que los 2 responden
> a necesidades diferentes dentro del ambiente.

Envías el mensaje #do: (con un bloque) a un objeto que puede
  evaluarlo en su contenido. Es aplicable a las colecciones (u
  otros objetos compuestos de dominios específicos) sin importar
  que sean indexables o no; el orden en que se evalúa el bloque
  para cada elemento del contenido no está fijado y el receptor
  puede determinarlo según lo desee.

El mensaje #to:do: es un mensaje mas específico, que
  se aplica a colecciones iterables (es decir, indexables
  numéricamente -en realidad indexables por números
  naturales- ), presupone un orden de "iteración".
Por lo general es un mensaje optimizado por el
  compilador, en dónde se generan bytecodes mas
  eficientes que el escribir la iteración + indexación
  a mano.
No es frecuente el uso de este mensaje en objetos
  de dominios específicos.

hasta pronto,
Ale.


----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Friday, May 26, 2006 10:43 AM
Subject: Re: [objetos] #detect:


> Hola
>
>   Ok, dejemos de lado el tema de eficiencia.
>   Me pregunto, cual es la forma de resolver este metodo, con #do: o
#to:do: .
>   Digamos que lo que me interesa es cuando deveria usar uno u otro y cual
es el significado de ambos, ya que supongo que los 2 responden a necesidades
diferentes dentro del ambiente.
>
>   saludos kiko
>
> "Alejandro F. Reimondo" <aleReimondo@...> escribió:
>   Hola kiko,
>
> En los mensajes que no se recibe un bloque para atender
> la falta de un elemento, es "normal" en las colecciones
> el generar un error.
> A modo de ejemplo, podes ver:
>     #at:ifAbsent:    vs.     #at:
>     #select:ifNone: vs.     #select:
>     #detect:ifNone: vs.     #detect:
>     #reject:ifNone: ... etc...
>
> Se usa #at:ifAbsent: cuando uno desea manejar
> la contingencia que representa que el elemento buscado
> no este en la coleccion...
> Los mensajes de la derecha deben disparar
> un error al no estar el elemento...
>
> En mi opinión, no debería devolverse nil
> pues sería ambiguo y además un factor
> que denotaría incompatibilidad;
> pues en otros smalltalks se espera que nunca se
> siguiera ejecutando a continuación del envío
> del #detect: y en cambio en MT además lo haría
> con un objeto potencialmente no polimorfico con
> lo que podría devolver el #detect: en caso de
> funcionar correctamente.
>
> Ejemplo:
>     aCollection detect: [:one| one notNil ]
> Al devolver "nil" estaría aseverando que en la
> coleccion existe nil , no siendo nil (como si hubiera enviado
> el mensaje #notNil a nil y éste hubiera devuelto true).
>
> >    Por que en MT se implementa con el mensaje #to:do:
> > y en Vs con #do:.
>
> Porque muy posiblemente es la forma mas eficiente de
> implementarlo en cada plataforma.
>
> >   Cual es la mejor????,si es  que la hay.
>
> La mejor es la que funcione mejor en dónde está escrita.
> En otras palabras, no hay una "mejor forma" o un mejor
> algoritmo; siempre importa más la plataforma dónde
> se evalúa una expresión (1) y las condiciones de evaluación (2).
>
> (1) un sistema de objetos es muy complejo como para
> predecir (salvo en casos muy simples) la eficiencia en función
> de la lectura de las expresiones. Porque hay en juego muchos
> elementos, entre (seguramente) muchos otros:
> - generación de basura. (podes pagarlo a la corta o a la larga
> al precio de liberarla; cosa que muchas veces ocurre muuuucho
> después de terminar de evaluar el test :-)
> - optimizaciones subyacentes, especialmente en maquinas
> generadoras de código nativo (como la de VS)
> - eficiencia de mensajes usados y alocacion de contextos (y
> argumentos)
> - etc...
>
> (2) ocurre (a menudo con las colecciones) que un algoritmo
> es eficiente o no dependiendo del numero de elementos que
> maneja (por ejemplo, las formas de resolver las colecciones
> que usan hashing son sensibles a la cantidad de elementos
> que manejan; pues la función de hash tiene un dominio de
> salida reducido).
>
> En resumen, comparar entre un ambiente y otro en forma
> absoluta (o viendo la implementacion "de base") es tan valido
> como comparar la forma de las piedras en la tierra vs. la luna...
> Tomando de muestra un ladrillo :-)
>
> hasta pronto,
> Ale.
>
>
>
>
> ----- Original Message -----
> From: "kikote gregoris" <kikogregoris@...>
> To: <smalltalking@...>
> Sent: Friday, May 19, 2006 11:36 AM
> Subject: [objetos] #detect:
>
>
> > Hola
> >
> >   Queria saber cual es la diferencia de la implementación de  el método
> #detect:ifNone en VS y la implementación de #detect: en MT.
> >   Paso los metodos:
> >
> >   VS:
> >
> >   >>detect: aBlock ifNone: exceptionBlock
> >           "Answer the first element of the receiver that
> >            causes aBlock to evaluate to true (with that
> >            element as the argument).  If no such element is
> >            found, evaluate exceptionBlock (with no arguments)."
> >       self do: [ :element |
> >           (aBlock value: element)
> >               ifTrue: [^element]].
> >       ^exceptionBlock value
> >
> >   MT:
> >
> >   >>detect: aBlock
> >               "
> >               Evaluates aBlock with each element of the receiver
> >               until the result is true or all elements have been
> processed.
> >               In the first case, the method returns the element for
which
> aBlock evaluated to   true,
> >               otherwise it returns nil.
> >               Parameters:
> >                           aBlock A one-argument block that iterates over
> the receiver.
> >               Return Value:
> >                           The first element for which aBlock evaluates
to
> true, or nil if none is found.
> >               "
> >               |element|
> >               1 to: self size do: [:i|
> >                           (aBlock value: (element := self at: i))
ifTrue:
> [^element]
> >               ].
> >               ^nil
> >
> >    Por que en MT se implementa con el mensaje #to:do: y en Vs con #do:.
> >   Cual es la mejor????,si es  que la hay.
> >
> >   Saludos kiko
> >
> >
> > ---------------------------------
> >  1GB gratis, Antivirus y Antispam
> >  Correo Yahoo!, el mejor correo web del mundo
> >  Abrí tu cuenta aquí
>
>
>
> Para más información sobre la Asociación escribir a info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
desarrollo en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm
>
>
>
>
> ---------------------------------
>   Enlaces de Yahoo! Grupos
>
>    Para visitar el sitio web del grupo, andá a:
> http://ar.groups.yahoo.com/group/smalltalking/
>
>    Para cancelar tu suscripción a este grupo, enviá un mensaje a:
> smalltalking-unsubscribe@...
>
>    El uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de
Yahoo!.
>
>
>
>
> ---------------------------------
>  Esa persona especial te espera en Yahoo! Encuentros
> ¡Dejate encontrar!
> Descubrilo aquí

Hola kiko,

>   OK, la categoría es del método.

En algunos lugares (no recuerdo dónde como para dar mas info)
  he visto propuestas de categorización de mensajes; y a mi me
  h aparecido siempre muy interesante el tratar de asistir mejor
  en la tarea de implementa mensajes; por ejemplo,
  si un mensaje se implementa en distintas clases DEBE tener
  el mismo Comment (cosa que no siempre se respeta, el comment
  a menudo está infectado de detalles pertinentes al contexto
  de resolución, es decir, al receptor; incorrectamente).
No he visto asistentes en este sentido en los smalltalks
  que se usan y si he observado a personas confundirse
  respecto del significado de un mensaje (al leer los comments)
  o el usar el mismo mensaje para semánticas distintas
  (generando un falso polimorfismo que no se detecta hasta
  que ya es tarde para evitarlo/repararlo).

>   Se podría decir que un método puede pertenecer a una
> categoría más general y además pertenecer a una categoría
> mas especifica.

Las categorías son administradas por una herramienta que es
  un asistente para las personas (un asistente humano) pero
  NO tiene relación ni compromisoCon/comprometeA
  el sistema
Es simple mejorar las herramientas (esto es realizado por lo
  general como trabajos prácticos en materias dónde se
  introduce a trabajar en un ambiente).
Hay herramientas dónde un método puede categorizarse
  en mas de una categoría, etc. Permitiendo que uno tenga
  por ejemplo "initialize" y "release" como do scategorías
  y no tenga que reducirlas a "init/release"...

>   Por ejemplo: #initialize podría ser de init/release pero a su vez
private.
>   Esto no se puede hacer con el sistema de categorías
> como esta planteado, pero se podría agregar en el commet
> un "private"  o lo que sea.

En el comment o en otra parte, si tenes un framework
  asistente "de código" es simple extenderlo/reducirlo
  en estos aspectos hasta alograr la forma en la que el
  equipo se siente cómodo (y no perdiendo tiempo
  en cosas que quizás desean no usar).
Estos asistentes "de código" o "asistentes humanos"
  o asistentes para la interpretación de comportamiento
  pueden relacionarse con herramientas de testing (si el
  equipo valora el trabajo con test unit u otros tests,
  pueden incorporarse al framework).

Por lo general los proveedores de los smalltalks comerciales
  no se han preocupado mucho a la hora de dar valor en
  estos aspectos de la producción; y cuando lo han hecho
  (en mi opinión) lo han hecho forzando formas de trabajo
  (las que determinan un costo en su implementación práctica).
Los equipos de trabajo son los que determinan entonces
  que soporte se procuran para la producción; resolviéndose
  en muchos casos informalmente.

>   Con respecto a "Private", al releer tu mail,
> sospecho que quizás pensas que es conveniente
> el no poderle enviar un mensaje "private" a un objeto...

Pienso que si existe un mensaje e spara ser enviado.
No importa quien lo envíe.
Y si importa, el receptor debe ser sensible a esto (y no
  un fantasma invisible el que "se da cuenta").
El sabe quien envió el mensaje es simple, la reflexión en
  el proceso(o el stack) es suficiente para que el receptor
  pueda saberlo y actuar como desee.

hasta pronto,
Ale.


----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Friday, May 26, 2006 10:37 AM
Subject: Re: [objetos] Categoria de mensajes


> Hola
>
>
>   OK, la categoría es del método.
>
>   Se podría decir que un método puede pertenecer a una categoría más
general y además pertenecer a una categoría mas especifica.
>   Por ejemplo: #initialize podría ser de init/release pero a su vez
private.
>   Esto no se puede hacer con el sistema de categorías como esta planteado,
pero se podría agregar en el commet un "private"  o lo que sea.
>   Lo pregunto, por que encontré cosas de esta naturaleza en el MT y no me
parece mal aunque la categoría private quedaría un poco pelada desde este
punto de vista.
>
>
>   Con respecto a "Private", al releer tu mail,
> sospecho que quizás pensas que es conveniente
> el no poderle enviar un mensaje "private" a un objeto...
>
>   Con respecto a esto, la verdad no me lo había planteado
>
>
> saludos kiko
>
> "Alejandro F. Reimondo" <aleReimondo@...> escribió:  Hola
kiko,
>
> >   Estoy un poco confundido con el sistema de categorías
> > del MT, ya que un mensaje que en ciertas circunstancias
> > es private en otras es de init/release.
>
> Muchas veces pasa que los METODOS son categorizados
> distinto por diferentes personas.
> (observá que lo que se categoriza es el método, no el mensaje!)
>
> En los sistemas multicategorias (que permiten mas de una
> categoría para un método) ocurre que a menudo las personas
> olvidan categorizarlo según todas las categorías aplicables,
> dándose entonces la situación de que otra persona
> encuentra la categorización de uno o mas métodos
> incompleta (o completa bajo perfiles irrelevantes ante
> su punto de vista).
>
> A veces se usa también la categorización como un
> indicador técnico (por ejemplo: refine este método
> en subclases).
> El "private" es un indicador técnico que comúnmente
> se usaba colocar en el Comment de un mensaje (método),
> y en los sistemas con categorización se ha empezado a
> mover a las categorías. Esto, creo yo, ocurre como
> consecuencia de la producción de sistemas por personas
> que no distinguen entre el sistema y su documentación
> (un caso, son aquellos que piensan que es "responsabilidad"
> del sistema el documentarse; aunque es variado el espectro
> de situaciones y "recetas" que se generan en función de una
> discriminación insuficiente entre que es un sistema y que
> es su definición).
>
> >   Mirando en el ST no advierto la diferencia entre las 2 situaciones.
> >   Como ejemplo puedo nombrar el mensaje #initialize.
> >   Yo me pregunto, cuando un mensaje se considera de
> > carácter privado para el objeto que lo implementa.
>
> La categoría es del método (no del mensaje).
> Un mensaje puede ser implementado en clases
> distintas y en ellas clasificarse sus métodos según
> las variadas ópticas. :-)
>
> No se si esto contesta de alguna forma tus inquietudes,
> pero estoy casi seguro que permitirá analizar la categorización
> (de mensajes y/o métodos) con más detenimiento.
>
> Con respecto a "Private", al releer tu mail,
> sospecho que quizás pensas que es conveniente
> el no poderle enviar un mensaje "private" a un objeto...
>
> De ser así sería muy incómodo, por ejemplo, desde
> un inspector... no poder mandar el mensaje...
> y si el inspector puede... porque anObject no :-)
>
> Además de ser incómodo, va en contra de uno de
> los principios importantes en la producción (de software,
> y otras cosas).
> El principio lo podríamos enunciar así:
>    "Nunca es positivo trabajar para tener menos"
> En otras palabras:
>   Nunca hagas algo hoy para no poder
>     hacer/extender mañana.
>
> hasta pronto,
> Ale.
> Pdta.: creo que hay mails históricos sobre este tema,
> quizás en lo dicho en ese entonces hay información útil.
>
>
> ----- Original Message -----
> From: "kikote gregoris" <kikogregoris@...>
> To: <smalltalking@...>
> Sent: Tuesday, May 23, 2006 11:15 AM
> Subject: [objetos] Categoria de mensajes
>
>
> > Hola
> >
> >   Estoy un poco confundido con el sistema de categorias del MT, ya que
un
> mensaje que en ciertas circunstancias es private en otras es de
> init/release.
> >   Mirando en el ST no advierto la diferencia entre las 2 situaciones.
> >
> >   Como ejemplo puedo nombrar el mensaje #initialize.
> >   Yo me pregunto, cuando un mensaje se considera de caracter privado
para
> el objeto que lo implementa.
> >
> >   saludos kiko
> >
> >
> >
> >
> >
> > ---------------------------------
> >  1GB gratis, Antivirus y Antispam
> >  Correo Yahoo!, el mejor correo web del mundo
> >  Abrí tu cuenta aquí
>
>
>
> Para más información sobre la Asociación escribir a info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
desarrollo en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm
>
>
>
>
> ---------------------------------
>   Enlaces de Yahoo! Grupos
>
>    Para visitar el sitio web del grupo, andá a:
> http://ar.groups.yahoo.com/group/smalltalking/
>
>    Para cancelar tu suscripción a este grupo, enviá un mensaje a:
> smalltalking-unsubscribe@...
>
>    El uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de
Yahoo!.
>
>
>
>
> ---------------------------------
>  Horóscopos, Salud y belleza, Chistes, Consejos de amor.
>  El contenido más divertido para tu celular está en
> Yahoo! Móvil

Hola kiko,

En los mensajes que no se recibe un bloque para atender
la falta de un elemento, es "normal" en las colecciones
el generar un error.
A modo de ejemplo, podes ver:
    #at:ifAbsent:    vs.     #at:
    #select:ifNone: vs.     #select:
    #detect:ifNone: vs.     #detect:
    #reject:ifNone: ... etc...

Se usa #at:ifAbsent: cuando uno desea manejar
la contingencia que representa que el elemento buscado
no este en la coleccion...
Los mensajes de la derecha deben disparar
un error al no estar el elemento...

En mi opinión, no debería devolverse nil
pues sería ambiguo y además un factor
que denotaría incompatibilidad;
pues en otros smalltalks se espera que nunca se
siguiera ejecutando a continuación del envío
del #detect: y en cambio en MT además lo haría
con un objeto potencialmente no polimorfico con
lo que podría devolver el #detect: en caso de
funcionar correctamente.

Ejemplo:
    aCollection detect: [:one| one notNil ]
Al devolver "nil" estaría aseverando que en la
coleccion existe nil , no siendo nil (como si hubiera enviado
el mensaje #notNil a nil y éste hubiera devuelto true).

>    Por que en MT se implementa con el mensaje #to:do:
> y en Vs con #do:.

Porque muy posiblemente es la forma mas eficiente de
implementarlo en cada plataforma.

>   Cual es la mejor????,si es  que la hay.

La mejor es la que funcione mejor en dónde está escrita.
En otras palabras, no hay una "mejor forma" o un mejor
algoritmo; siempre importa más la plataforma dónde
se evalúa una expresión (1) y las condiciones de evaluación (2).

(1) un sistema de objetos es muy complejo como para
predecir (salvo en casos muy simples) la eficiencia en función
de la lectura de las expresiones. Porque hay en juego muchos
elementos, entre (seguramente) muchos otros:
- generación de basura. (podes pagarlo a la corta o a la larga
al precio de liberarla; cosa que muchas veces ocurre muuuucho
después de terminar de evaluar el test :-)
- optimizaciones subyacentes, especialmente en maquinas
generadoras de código nativo (como la de VS)
- eficiencia de mensajes usados y alocacion de contextos (y
argumentos)
- etc...

(2) ocurre (a menudo con las colecciones) que un algoritmo
es eficiente o no dependiendo del numero de elementos que
maneja (por ejemplo, las formas de resolver las colecciones
que usan hashing son sensibles a la cantidad de elementos
que manejan; pues la función de hash tiene un dominio de
salida reducido).

En resumen, comparar entre un ambiente y otro en forma
absoluta (o viendo la implementacion "de base") es tan valido
como comparar la forma de las piedras en la tierra vs. la luna...
Tomando de muestra un ladrillo :-)

hasta pronto,
Ale.




----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Friday, May 19, 2006 11:36 AM
Subject: [objetos] #detect:


> Hola
>
>   Queria saber cual es la diferencia de la implementación de  el método
#detect:ifNone en VS y la implementación de #detect: en MT.
>   Paso los metodos:
>
>   VS:
>
>   >>detect: aBlock ifNone: exceptionBlock
>           "Answer the first element of the receiver that
>            causes aBlock to evaluate to true (with that
>            element as the argument).  If no such element is
>            found, evaluate exceptionBlock (with no arguments)."
>       self do: [ :element |
>           (aBlock value: element)
>               ifTrue: [^element]].
>       ^exceptionBlock value
>
>   MT:
>
>   >>detect: aBlock
>               "
>               Evaluates aBlock with each element of the receiver
>               until the result is true or all elements have been
processed.
>               In the first case, the method returns the element for which
aBlock evaluated to   true,
>               otherwise it returns nil.
>               Parameters:
>                           aBlock A one-argument block that iterates over
the receiver.
>               Return Value:
>                           The first element for which aBlock evaluates to
true, or nil if none is found.
>               "
>               |element|
>               1 to: self size do: [:i|
>                           (aBlock value: (element := self at: i)) ifTrue:
[^element]
>               ].
>               ^nil
>
>    Por que en MT se implementa con el mensaje #to:do: y en Vs con #do:.
>   Cual es la mejor????,si es  que la hay.
>
>   Saludos kiko
>
>
> ---------------------------------
>  1GB gratis, Antivirus y Antispam
>  Correo Yahoo!, el mejor correo web del mundo
>  Abrí tu cuenta aquí

Hola kiko,

>   Estoy un poco confundido con el sistema de categorías
> del MT, ya que un mensaje que en ciertas circunstancias
> es private en otras es de init/release.

Muchas veces pasa que los METODOS son categorizados
distinto por diferentes personas.
(observá que lo que se categoriza es el método, no el mensaje!)

En los sistemas multicategorias (que permiten mas de una
categoría para un método) ocurre que a menudo las personas
olvidan categorizarlo según todas las categorías aplicables,
dándose entonces la situación de que otra persona
encuentra la categorización de uno o mas métodos
incompleta (o completa bajo perfiles irrelevantes ante
su punto de vista).

A veces se usa también la categorización como un
indicador técnico (por ejemplo: refine este método
en subclases).
El "private" es un indicador técnico que comúnmente
se usaba colocar en el Comment de un mensaje (método),
y en los sistemas con categorización se ha empezado a
mover a las categorías. Esto, creo yo, ocurre como
consecuencia de la producción de sistemas por personas
que no distinguen entre el sistema y su documentación
(un caso, son aquellos que piensan que es "responsabilidad"
del sistema el documentarse; aunque es variado el espectro
de situaciones y "recetas" que se generan en función de una
discriminación insuficiente entre que es un sistema y que
es su definición).

>   Mirando en el ST no advierto la diferencia entre las 2 situaciones.
>   Como ejemplo puedo nombrar el mensaje #initialize.
>   Yo me pregunto, cuando un mensaje se considera de
> carácter privado para el objeto que lo implementa.

La categoría es del método (no del mensaje).
Un mensaje puede ser implementado en clases
distintas y en ellas clasificarse sus métodos según
las variadas ópticas. :-)

No se si esto contesta de alguna forma tus inquietudes,
pero estoy casi seguro que permitirá analizar la categorización
(de mensajes y/o métodos) con más detenimiento.

Con respecto a "Private", al releer tu mail,
sospecho que quizás pensas que es conveniente
el no poderle enviar un mensaje "private" a un objeto...

De ser así sería muy incómodo, por ejemplo, desde
un inspector... no poder mandar el mensaje...
y si el inspector puede... porque anObject no :-)

Además de ser incómodo, va en contra de uno de
los principios importantes en la producción (de software,
y otras cosas).
El principio lo podríamos enunciar así:
   "Nunca es positivo trabajar para tener menos"
En otras palabras:
  Nunca hagas algo hoy para no poder
    hacer/extender mañana.

hasta pronto,
Ale.
Pdta.: creo que hay mails históricos sobre este tema,
quizás en lo dicho en ese entonces hay información útil.


----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Tuesday, May 23, 2006 11:15 AM
Subject: [objetos] Categoria de mensajes


> Hola
>
>   Estoy un poco confundido con el sistema de categorias del MT, ya que un
mensaje que en ciertas circunstancias es private en otras es de
init/release.
>   Mirando en el ST no advierto la diferencia entre las 2 situaciones.
>
>   Como ejemplo puedo nombrar el mensaje #initialize.
>   Yo me pregunto, cuando un mensaje se considera de caracter privado para
el objeto que lo implementa.
>
>   saludos kiko
>
>
>
>
>
> ---------------------------------
>  1GB gratis, Antivirus y Antispam
>  Correo Yahoo!, el mejor correo web del mundo
>  Abrí tu cuenta aquí

---

Enlaces de Yahoo! Grupos

• Para visitar el sitio web del grupo, andá a:
  http://ar.groups.yahoo.com/group/smalltalking/
   
• Para cancelar tu suscripción a este grupo, enviá un mensaje a:
  smalltalking-unsubscribe@...
   
• El uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de Yahoo!.

Hola kiko,

>   Estoy un poco confundido con el sistema de categorías
> del MT, ya que un mensaje que en ciertas circunstancias
> es private en otras es de init/release.

Muchas veces pasa que los METODOS son categorizados
  distinto por diferentes personas.
  (observá que lo que se categoriza es el método, no el mensaje!)

En los sistemas multicategorias (que permiten mas de una
  categoría para un método) ocurre que a menudo las personas
  olvidan categorizarlo según todas las categorías aplicables,
  dándose entonces la situación de que otra persona
  encuentra la categorización de uno o mas métodos
  incompleta (o completa bajo perfiles irrelevantes ante
  su punto de vista).

A veces se usa también la categorización como un
  indicador técnico (por ejemplo: refine este método
  en subclases).
El "private" es un indicador técnico que comúnmente
  se usaba colocar en el Comment de un mensaje (método),
  y en los sistemas con categorización se ha empezado a
  mover a las categorías. Esto, creo yo, ocurre como
  consecuencia de la producción de sistemas por personas
  que no distinguen entre el sistema y su documentación
  (un caso, son aquellos que piensan que es "responsabilidad"
  del sistema el documentarse; aunque es variado el espectro
  de situaciones y "recetas" que se generan en función de una
  discriminación insuficiente entre que es un sistema y que
  es su definición).

>   Mirando en el ST no advierto la diferencia entre las 2 situaciones.
>   Como ejemplo puedo nombrar el mensaje #initialize.
>   Yo me pregunto, cuando un mensaje se considera de
> carácter privado para el objeto que lo implementa.

La categoría es del método (no del mensaje).
Un mensaje puede ser implementado en clases
  distintas y en ellas clasificarse sus métodos según
  las variadas ópticas. :-)

No se si esto contesta de alguna forma tus inquietudes,
  pero estoy casi seguro que permitirá analizar la categorización
  (de mensajes y/o métodos) con más detenimiento.

Con respecto a "Private", al releer tu mail,
  sospecho que quizás pensas que es conveniente
  el no poderle enviar un mensaje "private" a un objeto...

De ser así sería muy incómodo, por ejemplo, desde
  un inspector... no poder mandar el mensaje...
  y si el inspector puede... porque anObject no :-)

Además de ser incómodo, va en contra de uno de
  los principios importantes en la producción (de software,
  y otras cosas).
El principio lo podríamos enunciar así:
    "Nunca es positivo trabajar para tener menos"
En otras palabras:
   Nunca hagas algo hoy para no poder
     hacer/extender mañana.

hasta pronto,
Ale.
Pdta.: creo que hay mails históricos sobre este tema,
  quizás en lo dicho en ese entonces hay información útil.


----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Tuesday, May 23, 2006 11:15 AM
Subject: [objetos] Categoria de mensajes


> Hola
>
>   Estoy un poco confundido con el sistema de categorias del MT, ya que un
mensaje que en ciertas circunstancias es private en otras es de
init/release.
>   Mirando en el ST no advierto la diferencia entre las 2 situaciones.
>
>   Como ejemplo puedo nombrar el mensaje #initialize.
>   Yo me pregunto, cuando un mensaje se considera de caracter privado para
el objeto que lo implementa.
>
>   saludos kiko
>
>
>
>
>
> ---------------------------------
>  1GB gratis, Antivirus y Antispam
>  Correo Yahoo!, el mejor correo web del mundo
>  Abrí tu cuenta aquí

Hola gente

  Ademas el metodo privado es eso privado de ese objeto
eso significa que solo el objeto debe llamarlo porque
tambien significa que puede cambiar ,no debes usarlo
porque no es protocolo del objeto sino parte de su
implmentacion interna, puede cambiar y no es seguro
como por eso mejor no llamrlo.
salu2

  MDC
  --- Facundo <facundov79@...> escribió:

> Hola Kiko,
>
> Sí el mensaje no se debería enviar al Objeto desde
> otros objetos es
> Privado, en mi opinión.
> Por ej.: no envias #initialize desde otros objetos
> sino que los haces
> desde el mismo Objeto con otro mensaje, generalmente
> #new.
> En Dolphin para hacer un método private lo
> categorizas dentro Private
> pero eso no quita que no pueda estar en otra
> categoría (además) el
> método, pero obvio que no en Public.
>
> Saludos, Facundo
>
> kikote gregoris escribió:
> > Hola
> >
> > Estoy un poco confundido con el sistema de
> categorias del MT, ya que
> > un mensaje que en ciertas circunstancias es
> private en otras es de
> > init/release.
> > Mirando en el ST no advierto la diferencia entre
> las 2 situaciones.
> >
> > Como ejemplo puedo nombrar el mensaje #initialize.
> > Yo me pregunto, cuando un mensaje se considera de
> caracter privado
> > para el objeto que lo implementa.
> >
> > saludos kiko
> >
> >
> >
> >
> >
>
------------------------------------------------------------------------
> > *1GB gratis*, Antivirus y Antispam
> > Correo Yahoo!, el mejor correo web del mundo
> > Abrí tu cuenta aquí
> <http://login.yahoo.com/config/mail?.intl=ar>
> >
> > Para más información sobre la Asociación escribir
> a info@...
> >
> > Smalltalking es un espacio colaborativo creado
> para el estudio y
> > desarrollo en Ambientes de Objetos.
> > Se sustenta gracias a la participación de sus
> socios.
> >
> > Las reglas de etiqueta sobre la lista están en
> > http://www.smalltalking.net/join/netiquete.htm
> >
> >
> >
> >
>
------------------------------------------------------------------------
> > *Enlaces de Yahoo! Grupos*
> >
> >     * Para visitar el sitio web del grupo, andá a:
> >
> http://ar.groups.yahoo.com/group/smalltalking/
> >
> >     * Para cancelar tu suscripción a este grupo,
> enviá un mensaje a:
> >       smalltalking-unsubscribe@...
> >
>
<mailto:smalltalking-unsubscribe@...?subject=Unsubscribe>
> >
> >     * El uso de Yahoo! Grupos está sujeto a las
> Condiciones del
> >       servicio de Yahoo!
> <http://ar.docs.yahoo.com/info/utos.html>.
> >
> >
>
>
>
>
>
>
___________________________________________________________
>
> 1GB gratis, Antivirus y Antispam
> Correo Yahoo!, el mejor correo web del mundo
> http://correo.yahoo.com.ar
>
>




_________________________________________________
Yahoo! Autos. Más de 12.000 vehículos publicados.
¿Qué esperás para vender el tuyo?
Hacelo ahora y ganate un premio de Yahoo!
http://autos.yahoo.com.ar/vender/

Hola Kiko,

Sí el mensaje no se debería enviar al Objeto desde otros objetos es
Privado, en mi opinión.
Por ej.: no envias #initialize desde otros objetos sino que los haces
desde el mismo Objeto con otro mensaje, generalmente #new.
En Dolphin para hacer un método private lo categorizas dentro Private
pero eso no quita que no pueda estar en otra categoría (además) el
método, pero obvio que no en Public.

Saludos, Facundo

kikote gregoris escribió:
> Hola
>
> Estoy un poco confundido con el sistema de categorias del MT, ya que
> un mensaje que en ciertas circunstancias es private en otras es de
> init/release.
> Mirando en el ST no advierto la diferencia entre las 2 situaciones.
>
> Como ejemplo puedo nombrar el mensaje #initialize.
> Yo me pregunto, cuando un mensaje se considera de caracter privado
> para el objeto que lo implementa.
>
> saludos kiko
>
>
>
>
> ------------------------------------------------------------------------
> *1GB gratis*, Antivirus y Antispam
> Correo Yahoo!, el mejor correo web del mundo
> Abrí tu cuenta aquí <http://login.yahoo.com/config/mail?.intl=ar>
>
> Para más información sobre la Asociación escribir a info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
> desarrollo en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
> http://www.smalltalking.net/join/netiquete.htm
>
>
>
> ------------------------------------------------------------------------
> *Enlaces de Yahoo! Grupos*
>
>     * Para visitar el sitio web del grupo, andá a:
>       http://ar.groups.yahoo.com/group/smalltalking/
>
>     * Para cancelar tu suscripción a este grupo, enviá un mensaje a:
>       smalltalking-unsubscribe@...
>       <mailto:smalltalking-unsubscribe@...?subject=Unsubscribe>
>
>     * El uso de Yahoo! Grupos está sujeto a las Condiciones del
>       servicio de Yahoo! <http://ar.docs.yahoo.com/info/utos.html>.
>
>





___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar

Hola Gustavo,

>> Concuerdo que es muy difícil hoy en día enseñar con
>>  Smalltalk en las universidades;
>Yo no lo veo tan difícil, diría todo lo contrario.
> Es el lugar.Que otro si no ?.

Siempre existió y existe la posibilidad de enseñar
  vinculado a la producción (de proyectos comerciales).
De esta forma, además se resuelve la sustentabilidad
  de la actividad en forma independiente (cosa que creo
  ya no se enseña/alienta en los colegios secundarios :-( ).

> Es el lugar.Que otro si no ?.
El lugar podría ser también en una universidad
  (no es un problema geográfico :-)
  pero en el caso de hacerlo allí
  creo que uno (y los aprendices) está expuesto
  a distracciones comunes hoy en día del contexto
  académico, intereses no alineados con
  el aprendizaje e incluso políticas que requieren
  de gente que se esfuerce en aprender cosas
  con alto grado de obsolescencia.

Pensandolo dos veces, creo que además habría
  que sumarle distracciones que tienen que ver
  con la curiosidad de quien esta aprendiendo
  (en edades post adolescentes -adultos
  cronológicamente, pero no para la sociedad- )
  las que hacen mas difícil aún la realización de
  actividades productivas por un largo tiempo (mas
  de seis meses). Esto, creo, también se observa
  en personas que se tratan de capacitar en foros
  globales; es decir, no es una característica de
  las universidades (los universitarios) de hoy en día,
  pero si se observa en esos ámbitos.

>> e imposible
>>  es enseñar a trabajar con objetos.
>Por ?.
>Supongo que todo lo imposible es por por la
> posibilidad de enseñar incorrectamente.no ?

No creo que se enseñe incorrectamente
  (y creo que hay muy buena voluntad de
  enseñar).
Se enseña menos u otras cosas.

No hay docentes con experiencia real
  intentando enseñar a trabajar en un AO.
Al punto que estos docentes no conocen aún
  como defenderse de los ataques de otros docentes
  o personajes que no saben/entienden como
  trabajar con objetos (incluso confundiendo los
  términos como si todo fuera lo mismo).

En algunos casos se intenta enseñar diseño OO
  y la enseñanza se remite a la explicación de
  modelos y patrones de uso común,
  sin ningún tipo de análisis estadístico de los resultados
  por períodos mayores al año. Es decir, se evalúa el
  éxito por medio de resultados inmediatos (casi
  instantáneos) y se alienta a "investigar innovando"
  cuando aun no se conoce del tema ni se ha trabajado
  lo suficiente como para entender.

hasta pronto,
Ale.





----- Original Message -----
From: "Gustavo Ibarra" <ibarrags@...>
To: <smalltalking@...>
Sent: Saturday, May 20, 2006 4:15 PM
Subject: Re: [objetos] Re: [squeakRos] RV: Whither Squeak?


Hola.

> Concuerdo que es muy difícil hoy en día enseñar con
>  Smalltalk en las universidades;

Yo no lo veo tan dificil, diria todo lo contrario.
  Es el lugar.Que otro si no ?.

> e imposible
>  es enseñar a trabajar con objetos.

Por ?.

Supongo que todo lo imposible es por por la posibilidad de enseñar
incorrectamente.no ?

> hasta pronto,
> Ale.

Idem,Gustavo.-


Para más información sobre la Asociación escribir a info@...

Smalltalking es un espacio colaborativo creado para el estudio y desarrollo
en Ambientes de Objetos.
Se sustenta gracias a la participación de sus socios.

Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm

Enlaces de Yahoo! Grupos

Hola.

> Concuerdo que es muy difícil hoy en día enseñar con
>  Smalltalk en las universidades;

Yo no lo veo tan dificil, diria todo lo contrario.
  Es el lugar.Que otro si no ?.

> e imposible
>  es enseñar a trabajar con objetos.

Por ?.

Supongo que todo lo imposible es por por la posibilidad de enseñar
incorrectamente.no ?

> hasta pronto,
> Ale.

Idem,Gustavo.-

oops. Pensé que no estaría de más enviar el correo también a smalltalking.

Perdón si fué una metedura de pata. Pido disculpas.

El 20/05/06, Alejandro F. Reimondo<aleReimondo@...> escribió:
>
>  Hola Edgar,
>
>  Opino también que las palabras de Lord ZealoN
>  serían de más utilidad en un grupo con interés
>  particular en Squeak.
>  Aquí estamos intentando focalizar el diálogo a temas
>  acordes a nuestros objetivos.
>
>  Concuerdo que es muy difícil hoy en día enseñar con
>  Smalltalk en las universidades; e imposible
>  es enseñar a trabajar con objetos.
>
>  hasta pronto,
>  Ale.
>
>
>
>
>
>  ----- Original Message -----
>  From: "Lic. Edgar J. De Cleene" <edgardec2001@...>
>  To: <smalltalking@...>
>  Sent: Saturday, May 20, 2006 9:59 AM
>  Subject: Re: [objetos] Re: [squeakRos] RV: Whither Squeak?
>
>
>  Bueno, no siendo miembro de este foro, pido permiso y disculpas para
> aclarar
>  algunas cosas.
>
>  Smalltalking es en mi conocimiento algo muchísimo mas amplio e importante
>  que nuestro modesto intento de aprender algo y contribuir con Squeak.
>
>  Existen otros foros que leo y de los cuales me nutro.
>
>  Aquí en Rosario, como se ve, nos reunimos en el bar e intentamos que nos
>  faciliten los laboratorios, cosa que cualquiera que haya transitado la
>  universidad pública sabe no es fácil.
>
>  De la privada me echaron por oponerme a enseñar Visual Basic en lugar de
>  Squeak :=)
>
>  Squeak no es ni el mejor Smalltalk , ni el único, y ciertamente esta muy
>  lejos de ser algo perfecto.
>
>  Lo que vengo pregonando en el desierto es que es una divertida forma de
>  empezar a trabajar con objetos, porque no es sencillo empezar con los
>  Smalltalk "serios"
>
>  Siendo libre y abierto, cualquiera puede hacer lo que se le ocurra con el.
>
>  Incluso mejorarlo y darle otro aspecto visual, les aseguro que no tendran
>  problemas legales con Apple :=)
>
>  Edgar (por SqueakRos, iniciativa Rosarina para investigar y desarrollar
>  squeak)
>
>
>
>
>  ____________________________________________________
>  Esa persona especial te espera en Yahoo! Encuentros.
>  ¡Dejate encontrar!
>  http://ar.encuentros.yahoo.com/
>
>
>
>  Para más información sobre la Asociación escribir a info@...
>
>  Smalltalking es un espacio colaborativo creado para el estudio y desarrollo
>  en Ambientes de Objetos.
>  Se sustenta gracias a la participación de sus socios.
>
>  Las reglas de etiqueta sobre la lista están en
>  http://www.smalltalking.net/join/netiquete.htm
>
>  Enlaces de Yahoo! Grupos
>
>
>
>
>
>
>
>
>  Para más información sobre la Asociación escribir a info@...
>
>  Smalltalking es un espacio colaborativo creado para el estudio y desarrollo
> en Ambientes de Objetos.
>  Se sustenta gracias a la participación de sus socios.
>
>  Las reglas de etiqueta sobre la lista están en
> http://www.smalltalking.net/join/netiquete.htm
>
>
>
>  ________________________________
>  Enlaces de Yahoo! Grupos
>
>
> Para visitar el sitio web del grupo, andá a:
> http://ar.groups.yahoo.com/group/smalltalking/
>
> Para cancelar tu suscripción a este grupo, enviá un mensaje a:
> smalltalking-unsubscribe@...
>
> El uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de
> Yahoo!.
>


--

::Mi blog::
http://blog.lordzealon.com

Hola Edgar,

Opino también que las palabras de Lord ZealoN
  serían de más utilidad en un grupo con interés
  particular en Squeak.
Aquí estamos intentando focalizar el diálogo a temas
  acordes a nuestros objetivos.

Concuerdo que es muy difícil hoy en día enseñar con
  Smalltalk en las universidades; e imposible
  es enseñar a trabajar con objetos.

hasta pronto,
Ale.




----- Original Message -----
From: "Lic. Edgar J. De Cleene" <edgardec2001@...>
To: <smalltalking@...>
Sent: Saturday, May 20, 2006 9:59 AM
Subject: Re: [objetos] Re: [squeakRos] RV: Whither Squeak?


Bueno, no siendo miembro de este foro, pido permiso y disculpas para aclarar
algunas cosas.

Smalltalking es en mi conocimiento algo muchísimo mas amplio e importante
que nuestro modesto intento de aprender algo y contribuir con Squeak.

Existen otros foros que leo y de los cuales me nutro.

Aquí en Rosario, como se ve, nos reunimos en el bar e intentamos que nos
faciliten los laboratorios, cosa que cualquiera que haya transitado la
universidad pública sabe no es fácil.

De la privada me echaron por oponerme a enseñar Visual Basic en lugar de
Squeak :=)

Squeak no es ni el mejor Smalltalk , ni el único, y ciertamente esta muy
lejos de ser algo perfecto.

Lo que vengo pregonando en el desierto es que es una divertida forma de
empezar a trabajar con objetos, porque no es sencillo empezar con los
Smalltalk "serios"

Siendo libre y abierto, cualquiera puede hacer lo que se le ocurra con el.

Incluso mejorarlo y darle otro aspecto visual, les aseguro que no tendran
problemas legales con Apple :=)

Edgar (por SqueakRos, iniciativa Rosarina para investigar y desarrollar
squeak)




____________________________________________________
Esa persona especial te espera en Yahoo! Encuentros.
¡Dejate encontrar!
http://ar.encuentros.yahoo.com/



Para más información sobre la Asociación escribir a info@...

Smalltalking es un espacio colaborativo creado para el estudio y desarrollo
en Ambientes de Objetos.
Se sustenta gracias a la participación de sus socios.

Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm

Enlaces de Yahoo! Grupos

Bueno, no siendo miembro de este foro, pido permiso y disculpas para aclarar
algunas cosas.

Smalltalking es en mi conocimiento algo muchísimo mas amplio e importante
que nuestro modesto intento de aprender algo y contribuir con Squeak.

Existen otros foros que leo y de los cuales me nutro.

Aquí en Rosario, como se ve, nos reunimos en el bar e intentamos que nos
faciliten los laboratorios, cosa que cualquiera que haya transitado la
universidad pública sabe no es fácil.

De la privada me echaron por oponerme a enseñar Visual Basic en lugar de
Squeak :=)

Squeak no es ni el mejor Smalltalk , ni el único, y ciertamente esta muy
lejos de ser algo perfecto.

Lo que vengo pregonando en el desierto es que es una divertida forma de
empezar a trabajar con objetos, porque no es sencillo empezar con los
Smalltalk "serios"

Siendo libre y abierto, cualquiera puede hacer lo que se le ocurra con el.

Incluso mejorarlo y darle otro aspecto visual, les aseguro que no tendran
problemas legales con Apple :=)

Edgar (por SqueakRos, iniciativa Rosarina para investigar y desarrollar
squeak)




____________________________________________________
Esa persona especial te espera en Yahoo! Encuentros.
¡Dejate encontrar!
http://ar.encuentros.yahoo.com/

La verdad es que quería comentar más o menos sobre qué iba ese correo.

Mi inglés es un poco cochambroso y no lo he llegado a entender. Ese
correo yo lo entendí como a mal.

Me explico. Lo que me ha parecido entender, es que squeak necesita un
camino a tomar puesto cada vez va a peor. Teniendo demasiados módulos
por defecto que hay que mantener, y la compatibilidad que debe guardar
para Croquet por ejemplo. Sobre este tema yo opino que los que tienen
que mantener la compatibilidad es el equipo de croquet no los
desarrolladores principales de Squeak.

Más o menos, no se si es lo que me ha parecido leer. Agradecería que
me lo explicaseis.

Mis pequeña aportación sobre esto, teniendo en cuenta las escasas 3
horas que he podido dedicar a smalltalk a día de hoy, es que deberían
existir dos tipos de release.

Squeak debería tener sólo una imágen oficial. Una imágen con lo justo
y tomado como integrado en la oficial. (Shout etc...) con una interfaz
"seria" (o corporativa, como querais llamarlo) a partir de ahí, a
partir de esa imágen, los distintos grupos son los que deberían
preocuparse de tener sus "forks" listos y funcionando. Una rama de
squeak para la educación? Pues ahí entran small-land con sus
changesets. Una rama para croquet? Pues más de lo mismo. Pero todos
intentando usar un repositorio de librerías estandar para todos
(porque si no podría ser una locura)

Quizás, sería interesante también una resolución automática de
dependencias al estilo de apt de Debian para el caso de la release
minimal.

Trabajar sobre una imágen de 25MB + 25MB de cs es algo pesado bajo mi
punto de vista. Mi humilde opinión es que estoy seguro que hay mucho
código que sobra, que ya no hace falta. Y que en caso de necesitarlo,
la persona que lo requiera, que lo cargue a través de monticello o
squeakmap.

Han comentado algo sobre compatibilidades. Una posible solución sería
que pudiesen convivir distintas versiones de una misma librería, al
igual que hace linux.

Yo creo que hay que mirar hacia adelante. No hacia atrás. No podemos
pensar en aplicaciones de hace 8 años y que sigan siendo compatibles.
Lo que hay que pensar es, que las personas que hicierons esas
aplicaciones, deben migrarlas al nuevo sistema, porque si no, estamos
frenando el crecimiento de squeak.

Bajo mi humilde opinión. Una carencia muy importante que tiene squeak,
es, que como entorno de desarrollo para aplicaciones finales, carece
de un punto importantísimo. Un GUI builder. Cuando desarrollo, al
igual que hacía en Delphi, a la hora de la interfaz, quiero
preocuparme sólamente que el botón esté ahí mismo, donde estaba
apuntando con el ratón. y preocuparme sólamente del código. Construir
GUI's a partir de código, hoy en día, es un atraso. Quizás todo esto
se solucione con Tweak, pero hasta donde pude verlo, no me llamó
demasiado la atención.

Un proyecto con muchos usuarios detrás, es un proyecto vivo. Y un
proyecto vivo, es un proyecto que crece. Yo creo que mucha gente no
cree en squeak como alternativa a las opciones de pago como VS o
Dolphin, por su estética. Sigo opinando que tanto el logo de squeak,
como su interfaz, son demasiado infantiles, y no atraen a las posibles
empresas que quieran usarlo para sus proyectos. Y a Squeak le faltan
las empresas detrás de él usándolo. El logo de squeakfoundation sería
un reemplazo? Yo creo que sí. Un nuevo logo? supongo que también.

Por supuesto, estoy hablando con un desconocimiento total y absoluto
del tema, pero como he comentado al principio, no si es que he
entendido mal los más de 40 correos sobre este tema en la lista, o
qué, pero parecían desesperanzadores.

Espero que me equivoque y no pierda la pequeña ilusión que tengo con
squeak/smalltalk, y no tenga que pensar por enésima vez, en buscar
otro entorno de desarrollo como Lazarus+FPC o C/C++ etc.. para mis
proyectos en los que pueda encontrarme cómodo.


2006/5/19, Lic. Edgar J. De Cleene <edgardec2001@...>:
>
>  Anoche en la vereda del bar estuvimos charlando algo sobre Squeak y sobre
> el
>  futuro (4.0 ?)
>
>  Reenvio esto que es importante.
>
>  Estan soplando buenos vientos en la comunidad , despues de algunas
>  tormentas.
>
>  Gente importantísima como Alan Kay, Dan Ingalls, Ralph Johnson y otros han
>  reaparecido para que podamos aprender de ellos
>
>  Cees De Groot fue mi jefe en el primer Morphic Splitters, es uno de los
>  pilares y buena gente.
>
>  Su único defecto es ser holandes y recordarme que antes de jugar con Suecia
>  tenemos que pasar a Holanda :=)
>
>  Estaría bueno que los nuevos miembros que son alumnos de la UTN nos envien
>  mensajes, contando quienes son, que les gusta , que esperan de nosotros.
>
>  Para muestra pueden ver el blog
> http://201-212-99-13.cab.prima.net.ar:9000/seaside/blog/SummerTeam/
>
>  Ahí pueden inspirarse para las presentaciones.
>
>  Podemos empezar un nuevo blog "comunitario" o un swiki.
>
>  Podriamos llamarlo "LibroDeQuejas" y ahí poner cada uno lo que no nos gusta
>  , lo que nos gustaría que Squeak tenga y no tiene, mensajitos cariñosos
> para
>  la novia o novio del tenor "Cuchi cuchi te amo - XYZ", etc.
>
>  ------ Mensaje reenviado
>  De: Cees De Groot <cdegroot@...>
>  Responder a: The general-purpose Squeak developers list
>  <squeak-dev@...>
>  Fecha: Fri, 19 May 2006 09:43:55 +0200
>  Para: The general-purpose Squeak developers list
>  <squeak-dev@...>
>  Asunto: Whither Squeak?
>
>  Us board folks have been discussing where to go from here and I
>  personally would like to see a lot of discussion on this on
>  squeak-dev, so I am going to completely unofficially kick off this
>  discussion :-).
>
>  I'll present this as a set of bullets, I think it would be nice if we
>  could have a round of brainstorming first to complete these lists
>  before becoming opiniative.
>
>  Pressures:
>  - Squeak 3.x is so far quite succesful in resisting us applying
>  software engineering efforts to it. The reasons are manifold, but two
>  major reasons are manpower and available tools, neither is going to
>  change any time soon;
>  - It looks like squeak-dev is on its own, with the two main projects
>  that are using it (SqueakLand and Croquet, of course) effectively
>  having forked. There always has been a perceived need to be stable to
>  support these projects, but in howfar that is necessary at present is
>  open for debate;
>  - There is an awful amount of ideas, and an awful amount of talk about
>  what hasn't been done to Smalltalk since Smalltalk-80. Some of these
>  ideas were bad, a lot were good but haven't been implemented, and some
>  have been implemented. I think the number one reason for not
>  implementing good ideas is inertia due to having to support a large
>  codebase (see the point about SqueakLand and Croquet).
>
>  Possible solutions (given in "who is General Failure and what is he
>  doing on my drive?" style):
>  - Abort. Go back to the SqC model and live with a monolithic image (do
>  not scale);
>  - Retry. Declare Spoon to be Squeak 4.0, declare that that is all that
>  is going to be "officially" supported for the time being, and refuse
>  to support anything additional that doesn't have a proven team backing
>  it (scale up).
>  - Ignore. Keep on following the (distributed) software engineering
>  trail, but realize that it may take 5 years before we have a
>  modularized, manageable Squeak (scale down).
>
>  I have a clear preference, but I am not giving it until after a bit of
>  brainstorming here on the list. I hope that the rest of you will be
>  able to show the same restraint :)
>
>
>  ------ Fin del mensaje reenviado
>
>
>
>
>  ____________________________________________________
>  Esa persona especial te espera en Yahoo! Encuentros.
>  ¡Dejate encontrar!
>  http://ar.encuentros.yahoo.com/
>
>
>
>
>  correo electrónico a:
> squeakRos-unsubscribe@...
>
>
>  correo electrónico a:
> squeakRos-unsubscribe@...
>
>
>
>
>  ________________________________
>  Enlaces de Yahoo! Grupos
>
>
> Para visitar el sitio web del grupo, andá a:
> http://ar.groups.yahoo.com/group/squeakRos/
>
> Para cancelar tu suscripción a este grupo, enviá un mensaje a:
> squeakRos-unsubscribe@...
>
> El uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de
> Yahoo!.


--

::Mi blog::
http://blog.lordzealon.com

Hola kiko,

Entre 1991 y 1992 en Object Style hicimos una aplicación que "servía"
  para determinar la forma mas eficiente de cortar chapas metálicas bajo
  pedidos dinámicos.
Es decir, uno tiene chapas inmensas de metal a las que puede cortar en
  forma horizontal o vertical, pero de cualquier tamaño y en cualquier
  orden (podes cortar una chapa ya cortada).
Dicho así el problema parece parecido al tuyo... un problema difícil.
Para resolverlo formulamos un framework bidimensional de recorte,
  que uno o dos años después usamos en parte (como guías iniciales)
  en sistemas de mapas.
Recuerdo que nos llevó una o dos semanas darnos cuenta en que
  problema nos habíamos metido :-)
Y recuerdo que, entre 3 y 6 meses lograr resolver el problema
  "decorosamente" (eramos tres personas ocupadas intermitentemente
  en ese tema).

El problema mas importante al comienzo parecía ser el "cómo cortar ?".
Luego del primer prototipo comprobamos que era un problema :-P
  pero además nos dimos cuenta de un problema mayor aún.

Al cortar chapas, se generan retazos que se desean usar para cortar
  otras chapas!
Y además un pedido que esta aprobado puede ser revocado justo
  antes de cortar... invalidando el análisis que habías hecho e invalidando
  otros pedidos!

Es decir, el problema no solo era complejo de resolver por única vez,
  sino que además, en nuestro caso, el problema se replantea dinámicamente...
Lo mismo ocurriría si, alguien empieza a sacar cajas en dónde vos
  estas poniéndolas... (en tu caso espero que esto no pueda ocurrir :-)

Al analizar esta problemática y encontrar que el sistema era un sistema
  que no tenía un "tiempo cero" ni un fin; intentamos no resolverlo.
Es decir, dejamos de intentar la "vía fácil" y empezamos a buscar
  cómo resolver el problema, sin importar que sea la mas eficiente.
Pues así no parábamos la línea de corte... esperando la mejor forma de
  cortar para ahorrar, por ejemplo, un 1% de material y dejar (en muchos
  casos) recortes inusables/invendibles (es decir, mas basura).

Poco recuerdo de los detalles de la implementacion (fue en Smalltalk/V)
  y no se si tendré aún un backup (en diskettes).
Si recuerdo que:
     - la solución funcionaba con una cinética apropiada para
          satisfacer los pedidos.
     - el software se usó por poco tiempo (creo, no mas de un año)
         y en modo de asistente; con "metidas de mano" periódicas
         (es decir, priorizar pedidos a mano para que corte mejor, etc;
          las personas no dejaban hacer al sistema, sino que lo usaban
          como si fuera el mas bobo del equipo... creo que eso es lógico,
          ya que el sistema no puede defenderse :-) ).
     - el hacer ese sistema nos reforzó como equipo (a Leo, Xavi y a mi)
      y reforzó la "fe" en que hay cosas que cuesta formular en términos
      de objetivos (el objetivo para el cliente era cortar de la mejor
      forma, pero en realidad lo que mas importaba era no afectar a la
      cinética del proceso)

Espero sirvan de algo los comentarios y te animen en tus
  ensayos sobre la problemática.

hasta pronto,
Ale.




----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Friday, May 19, 2006 11:34 AM
Subject: Re: [objetos] Backtraking


> Hola segio
>
>   Que es un problema NP ??.
>
>   Lo voy a replantear, en principio lo queria hacer en 3d , ahora lo voy a
plantear en 2d que creo es un poco mas simple , si es que lo es .
>   Luego pienso que hacerlo en 3d puede resultar mas simple.
>
>   Debo aclarar que el problema en 2d es llenar un área rectangular con la
maxima cantidad de formas rectangulares.
>
>   saludos kiko
>
> Sergio Fedi <sergio.fedi@...> escribió:
>             La solución va por el lado del backtracking, tengo la idea
general de cómo hacer esto pero quisiera saber si alguien realizo algo de
este tipo.
>   Tengan en cuenta que necesito que puedan ingresar la mayor cantidad de
paquetes dentro de la caja.
>
>
>
>   Si mal no recuerdo, eso es un problema NP.
>
>   Y backtracking es una posible solucion, y dudo que sea la mejor.
>
>   Fijate papers sobre el tema.
>
>   Es probable que una heuristica apropiada sea mejor.
>
>
>
>
> Para más información sobre la Asociación escribir a info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
desarrollo en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm
>
>
>
>
> ---------------------------------
>   Enlaces de Yahoo! Grupos
>
>    Para visitar el sitio web del grupo, andá a:
> http://ar.groups.yahoo.com/group/smalltalking/
>
>    Para cancelar tu suscripción a este grupo, enviá un mensaje a:
> smalltalking-unsubscribe@...
>
>    El uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de
Yahoo!.
>
>
>
>
> ---------------------------------
>  1GB gratis, Antivirus y Antispam
>  Correo Yahoo!, el mejor correo web del mundo
>  Abrí tu cuenta aquí

Hola kiko,

En los mensajes que no se recibe un bloque para atender
  la falta de un elemento, es "normal" en las colecciones
  el generar un error.
A modo de ejemplo, podes ver:
     #at:ifAbsent:    vs.     #at:
     #select:ifNone: vs.     #select:
     #detect:ifNone: vs.     #detect:
     #reject:ifNone: ... etc...

Se usa #at:ifAbsent: cuando uno desea manejar
  la contingencia que representa que el elemento buscado
  no este en la coleccion...
Los mensajes de la derecha deben disparar
  un error al no estar el elemento...

En mi opinión, no debería devolverse nil
  pues sería ambiguo y además un factor
  que denotaría incompatibilidad;
  pues en otros smalltalks se espera que nunca se
  siguiera ejecutando a continuación del envío
  del #detect: y en cambio en MT además lo haría
  con un objeto potencialmente no polimorfico con
  lo que podría devolver el #detect: en caso de
  funcionar correctamente.

Ejemplo:
     aCollection detect: [:one| one notNil ]
Al devolver "nil" estaría aseverando que en la
  coleccion existe nil , no siendo nil (como si hubiera enviado
  el mensaje #notNil a nil y éste hubiera devuelto true).

>    Por que en MT se implementa con el mensaje #to:do:
> y en Vs con #do:.

Porque muy posiblemente es la forma mas eficiente de
  implementarlo en cada plataforma.

>   Cual es la mejor????,si es  que la hay.

La mejor es la que funcione mejor en dónde está escrita.
En otras palabras, no hay una "mejor forma" o un mejor
  algoritmo; siempre importa más la plataforma dónde
  se evalúa una expresión (1) y las condiciones de evaluación (2).

(1) un sistema de objetos es muy complejo como para
  predecir (salvo en casos muy simples) la eficiencia en función
  de la lectura de las expresiones. Porque hay en juego muchos
  elementos, entre (seguramente) muchos otros:
- generación de basura. (podes pagarlo a la corta o a la larga
  al precio de liberarla; cosa que muchas veces ocurre muuuucho
  después de terminar de evaluar el test :-)
- optimizaciones subyacentes, especialmente en maquinas
  generadoras de código nativo (como la de VS)
- eficiencia de mensajes usados y alocacion de contextos (y
  argumentos)
- etc...

(2) ocurre (a menudo con las colecciones) que un algoritmo
  es eficiente o no dependiendo del numero de elementos que
  maneja (por ejemplo, las formas de resolver las colecciones
  que usan hashing son sensibles a la cantidad de elementos
  que manejan; pues la función de hash tiene un dominio de
  salida reducido).

En resumen, comparar entre un ambiente y otro en forma
  absoluta (o viendo la implementacion "de base") es tan valido
  como comparar la forma de las piedras en la tierra vs. la luna...
  Tomando de muestra un ladrillo :-)

hasta pronto,
Ale.




----- Original Message -----
From: "kikote gregoris" <kikogregoris@...>
To: <smalltalking@...>
Sent: Friday, May 19, 2006 11:36 AM
Subject: [objetos] #detect:


> Hola
>
>   Queria saber cual es la diferencia de la implementación de  el método
#detect:ifNone en VS y la implementación de #detect: en MT.
>   Paso los metodos:
>
>   VS:
>
>   >>detect: aBlock ifNone: exceptionBlock
>           "Answer the first element of the receiver that
>            causes aBlock to evaluate to true (with that
>            element as the argument).  If no such element is
>            found, evaluate exceptionBlock (with no arguments)."
>       self do: [ :element |
>           (aBlock value: element)
>               ifTrue: [^element]].
>       ^exceptionBlock value
>
>   MT:
>
>   >>detect: aBlock
>               "
>               Evaluates aBlock with each element of the receiver
>               until the result is true or all elements have been
processed.
>               In the first case, the method returns the element for which
aBlock evaluated to   true,
>               otherwise it returns nil.
>               Parameters:
>                           aBlock A one-argument block that iterates over
the receiver.
>               Return Value:
>                           The first element for which aBlock evaluates to
true, or nil if none is found.
>               "
>               |element|
>               1 to: self size do: [:i|
>                           (aBlock value: (element := self at: i)) ifTrue:
[^element]
>               ].
>               ^nil
>
>    Por que en MT se implementa con el mensaje #to:do: y en Vs con #do:.
>   Cual es la mejor????,si es  que la hay.
>
>   Saludos kiko
>
>
> ---------------------------------
>  1GB gratis, Antivirus y Antispam
>  Correo Yahoo!, el mejor correo web del mundo
>  Abrí tu cuenta aquí

Fijate acá:

http://en.wikipedia.org/wiki/NP_%28complexity%29

Saludos,

German

Mensaje citado por: kikote gregoris <kikogregoris@...>:

> Hola segio
>
>   Que es un problema NP ??.
>
>   Lo voy a replantear, en principio lo queria hacer en 3d , ahora lo voy
> a plantear en 2d que creo es un poco mas simple , si es que lo es .
>   Luego pienso que hacerlo en 3d puede resultar mas simple.
>
>   Debo aclarar que el problema en 2d es llenar un área rectangular con
> la maxima cantidad de formas rectangulares.
>
>   saludos kiko
>
> Sergio Fedi <sergio.fedi@...> escribió:
>             La solución va por el lado del backtracking, tengo la idea
> general de cómo hacer esto pero quisiera saber si alguien realizo algo
> de este tipo.
>   Tengan en cuenta que necesito que puedan ingresar la mayor cantidad de
> paquetes dentro de la caja.
>
>
>
>   Si mal no recuerdo, eso es un problema NP.
>
>   Y backtracking es una posible solucion, y dudo que sea la mejor.
>
>   Fijate papers sobre el tema.
>
>   Es probable que una heuristica apropiada sea mejor.
>
>
>
>
> Para más información sobre la Asociación escribir a
> info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
> desarrollo en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
> http://www.smalltalking.net/join/netiquete.htm
>
>
>
>
> ---------------------------------
>   Enlaces de Yahoo! Grupos
>
>    Para visitar el sitio web del grupo, andá a:
> http://ar.groups.yahoo.com/group/smalltalking/
>
>    Para cancelar tu suscripción a este grupo, enviá un mensaje a:
> smalltalking-unsubscribe@...
>
>    El uso de Yahoo! Grupos está sujeto a las Condiciones del servicio de
> Yahoo!.
>
>
>
>
> ---------------------------------
>  1GB gratis, Antivirus y Antispam
>  Correo Yahoo!, el mejor correo web del mundo
>  Abrí tu cuenta aquí

La solución va por el lado del backtracking, tengo la idea general de cómo hacer esto pero quisiera saber si alguien realizo algo de este tipo.

Tengan en cuenta que necesito que puedan ingresar la mayor cantidad de paquetes dentro de la caja.

 

Si mal no recuerdo, eso es un problema NP.

 

Y backtracking es una posible solucion, y dudo que sea la mejor.

 

Fijate papers sobre el tema.

 

Es probable que una heuristica apropiada sea mejor.
 

Probá en Google:

\"constraint satisfaction problem\" implementation

Saludos,

German

Mensaje citado por: kikote gregoris <kikogregoris@...>:

> Hola
>
>   Tengo el problema de, tener que ubicar  una cantidad de paquetes de
> diferentes volúmenes dentro de una caja.
>
>   La solución va por el lado del backtracking, tengo la idea general de
> cómo hacer esto pero quisiera saber si alguien realizo algo de este
> tipo.
>   Tengan en cuenta que necesito que puedan ingresar la mayor cantidad de
> paquetes dentro de la caja.
>
>   Saludos kiko
>
>
> ---------------------------------
>  Horóscopos, Salud y belleza, Chistes, Consejos de amor.
>  El contenido más divertido para tu celular está en
> Yahoo! Móvil