Gente,
Estoy armando un SubPane en VS con capacidades de scroll pero usando la
estructura provista por Win llamada ScrollInfo ->
http://msdn.microsoft.com/en-us/library/bb787537(VS.85).aspx

Eso me da la posibilidad de usar los llamados scrollbar dinamicos (ver
imagen) que hace que el llamado "thumb" del scrollbar se achique/agrande
proporcionalmente al tamaño de la pagina que uno esta scrolleando.

Actualmente ya tengo implementado los llamados api y tengo una imple que me
funciona a medias; por algun motivo estoy haciendo mal alguna cuenta o algo
que hace que no pueda scrollear la pagina entera.

Tengo mas detalles para dar, pero no quisiera ahondar en el problema si
alguien tiene algun ejemplo hecho para VS y me lo puede pasar o alguna punta
que me indique que tengo que tener en cuenta al usar este tipo de scroll le
agradeceria.

Muchas Gracias,
Leo

Buenas a todos,
Tengo una oportunidad de negocio para el desarrollo de un website con
capacidades de e-commerce & content managment (entre otras particularidades,
pero eso es lo basico):

Back End
o   Gestión de usuarios y perfiles
o   Modulo de avisos y novedades
o   Modulo de archivos de descarga
o   Modulo de links sugeridos
o   Modulo de eventos
o   Modulo de páginas de contenidos
o   Edición de ítems de menú

Front End:
o   Página principal con novedades y contenidos eventuales.
o   Banners con novedades  y destacadas.
o   Acceso restringido mediante usuario y password.
o   Catalogo de Productos.
o   Listado y búsqueda de documentos digitales en formatos de Word, PDF, JPG
y Power Point.
o   Formulario de contacto y registro en base de datos.

Es condicion necesaria que se le pueda aplicar un diseño dado (a traves de
archivo .css seria ideal).
Si alguien tiene ya un producto con estas capacidades o similares si me
puede contactar en privado asi le cuento en detalle de que se trata; o si
aun no teniendo algo ya desarrollado esta en condiciones de desarrollar este
tipo de emprendimiento.

Saludos,
Leo

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

From: kikoGregoris

To: smalltalking@...

Sent: Friday, February 27, 2009 2:19 PM

Subject: Re: [objetos] Manejo de proyecto en Vs ?

Hola Ale   Gracias por responder. No me queda muy claro el asunto. Como le decía a Carlos, creo que el orden en que se salven las clases es importante, pues a la hora de levantar el proyecto se tendran que cargar las clases en el orden correcto. Para que no te diga ST algo como:   XXX se encuentra desea definir como global ?..     Ale wrote: Solo tenes que declarar las clases de las que heredan todas  las de tu proyecto, las que pueden ser mas de una; por lo  general es suficiente con una clase para el modelo,  otra para GUI, y una por cada facilidad adicional (que puede  ser conveniente a veces definirlas como proyectos).   Ok, aquí esta lo que decía. Para poner el ejemplo de Genesis, vos tenes: GenesisObject y GenesisDLL. GenesisObject tiene refencia a GenesisDLL en   GenesisPointer>>dll  " Private - Returns the current library in use.  We can't use #library as the name of this message because #library express SLL support.  "  ^GenesisDLL library   Sin embargo GenesisObject esta antes que GenesisDLL en:   Genesis3DBaseProject(class)>>classNames  "Private - Returns the names of Project dependent classes."  ^#(  GenesisObject "Model objects"  GenesisDLL "Low level interface"  GenesisMainWindow "MainWindow enhacements"  GenesisCoordinator "GUI Tests"  ) Por otro lado GenesisMainWindow esta antes que GenesisCoordinator . Pero GenesisCoordinator  tiene refencia a GenesisMainWindow en:   GenesisCoordinator>>windowClass  " Private - Answer the class of windows for the receiver."  ^GenesisMainWindow   Se entiende ?     No me queda claro si esto lo queres saber para  tu proyecto o si es algo que estan queriendo conocer,  como para hacer un lindo cuadro descriptivo, u otra cosa...   No, no quiero hacer cuadritos jajaj.   Saludos kiko --- El jue 26-feb-09, Alejandro F. Reimondo <aleReimondo@...> escribió: De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: [objetos] Manejo de proyecto en Vs ? Para: smalltalking@... Fecha: jueves, 26 de febrero de 2009, 9:45 pm Hola kiko,   >Estoy usando el manejador de proyecto de Ale. >Lo que no me queda claro es como hacer para > determinar las clases que dependen entre sí.   Solo tenes que declarar las clases de las que heredan todas  las de tu proyecto, las que pueden ser mas de una; por lo  general es suficiente con una clase para el modelo,  otra para GUI, y una por cada facilidad adicional (que puede  ser conveniente a veces definirlas como proyectos). No es necesario declarar dependencias. En caso de no querer que las subclases de una clase de  tu proyecto formen parte de éste, podes definirlo,  ya que todo mensaje e implementació n de cómo se  conforma un proyecto esta en la superclase y puede  refinarse para cada proyecto. >Puedo usar References, pero en un sistema con > muchas clases se empieza a complicar. O no ?.   No me queda claro si esto lo queres saber para  tu proyecto o si es algo que estan queriendo conocer,  como para hacer un lindo cuadro descriptivo, u otra cosa...   >Otra cosa, tengo por un lado la clase JetObject, > desde donde cuelgan todas las clases que refieren a Jet. >Por otra parte tengo los objetos que pertenecen al Editor de mapas. >Yo puse la clase JetEditorObject colgada de JetObject, pero > no sé si JetEditorObject debería colgar de Object.   Depende de que tengas en JetObject... Por lo general uno arranca con una clase vacía arriba de todo,  y es muy frecuente (dependiendo de cómo uno trabaja) que  allí coloque mensajes de comodidad para el proyecto mismo. Otras veces se usa el extender y modificar métodos de clases  externas al proyecto. En ambos casos el framework de proyectos te va a servir,  no solo por lo que ya está escrito, sino tambien porque  es muy cómodo subclasificar cuando un proyecto lo requiere,  por ejemplo, es muy facil hacer una extension para que  se bajen otros proyectos dependientes de uno troncal, etc. Sobre la lista de clases... >Deben estar en orden inverso ? o no importa No importa, fijate en cómo se baja un proyecto (en cómo  quedan dispuestos los fuentes)  y te vas a dar cuenta que no es necesario un orden.   suerte, Ale.       ----- Original Message ----- From: kikoGregoris To: smalltalking@ gruposyahoo. com.ar Sent: Thursday, February 26, 2009 4:28 PM Subject: [objetos] Manejo de proyecto en Vs ? Hola Gente   Estoy usando el manejador de proyecto de Ale. Lo que no me queda claro es como hacer para determinar las clases que dependen entre sí. Puedo usar References, pero en un sistema con muchas clases se empieza a complicar. O no ?.   Otra cosa, tengo por un lado la clase JetObject, desde donde cuelgan todas las clases que refieren a Jet. Por otra parte tengo los objetos que pertenecen al Editor de mapas. Yo puse la clase JetEditorObject colgada de JetObject, pero no sé si JetEditorObject debería colgar de Object. ESto es para tratar de diferenciar lo que corresponde puramente al manejo del Engine y el otro para el manejo del editor de mapas. Se entiendo ?. Además para facilitar la creación y separación  de los proyectos   Por último   classNames  "Private - Returns the names of Project dependent classes."  ^#(  GenesisObject "Model objects"  GenesisDLL "Low level interface"  GenesisMainWindow "MainWindow enhacements"  GenesisCoordinator "GUI Tests"  )   Deben estar en orden inverso ? o no importa saludos kiko Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/

---

Yahoo! Cocina
Recetas prácticas y comida saludable
Visitá http://ar.mujer.yahoo.com/cocina/

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

From: kikoGregoris

To: smalltalking@...

Sent: Friday, February 27, 2009 2:06 PM

Subject: Re: [objetos] Manejo de proyecto en Vs ?

Hola Carlos   Gracias por tus comentarios. Carlos wrote: La idea al trabajar con proyectos es que en un proyecto tenés un grupo cohesivo y coherente de clases, que se referencian entre sí en sus métodos. Debe(ría) haber pocas referencias a clases de fuera del proyecto. Por supuesto, siempre hay.   Si comprendo.   Carlos wrote: De todos modos, en el manejo primitivo de proyectos de VS, no se puede cargar una SLL si tiene referencias externas. Eso es relativamente fácil de arreglar y lo sugiero fuertemente, ya que es una limitación bastante incómoda.   A que te referis con esto, podrías ampliar el concepto ?   > classNames > "Private - Returns the names of Project dependent classes." > ^#( > GenesisObject "Model objects" > GenesisDLL "Low level interface" > GenesisMainWindow "MainWindow enhacements" > GenesisCoordinator "GUI Tests" > ) > > Deben estar en orden inverso ? o no importa > No entiendo. Si estuvieran en orden inverso, quedarían los tests antes de las clases de base, según lo que dicen los comentarios. Esto parece indicar una especie de orden de dependencias.   El caso es que GenesisObject, tiene referencias a GenesisDLL. Y GenesisDLL no tiene referencias a ningun GenesisObject o deribados. Es por eso que me confunde.   Por lo que entiendo un proyecto no es mas que una forma de organizar un conjunto de clases con sus respectivos comportamientos, de tal forma que al cargarlas desde ST esten en el orden correcto y no reviente por no conozer alguna clase que se hace referencía y que no fue instalada aun. Estoy muy  lejos ?. ES solo por esto que creo que lo mas dificultoso es decirle al proyecto que clase va antes o despues de las demas. Es esto a lo que quiero llegar   Saludos kiko     --- El jue 26-feb-09, Carlos E. Ferro <ceferro@...> escribió: De: Carlos E. Ferro <ceferro@...> Asunto: Re: [objetos] Manejo de proyecto en Vs ? Para: smalltalking@... Fecha: jueves, 26 de febrero de 2009, 9:23 pm kikoGregoris wrote: > Hola Gente > > Estoy usando el manejador de proyecto de Ale. > Lo que no me queda claro es como hacer para determinar las clases que > dependen entre sí. > Puedo usar References, pero en un sistema con muchas clases se empieza > a complicar. O no ?. > Sí, se puede complicar. Pero entonces es que el proyecto no está bien definido. La idea al trabajar con proyectos es que en un proyecto tenés un grupo cohesivo y coherente de clases, que se referencian entre sí en sus métodos. Debe(ría) haber pocas referencias a clases de fuera del proyecto. Por supuesto, siempre hay. De todos modos, en el manejo primitivo de proyectos de VS, no se puede cargar una SLL si tiene referencias externas. Eso es relativamente fácil de arreglar y lo sugiero fuertemente, ya que es una limitación bastante incómoda. > > Otra cosa, tengo por un lado la clase JetObject, desde donde cuelgan > todas las clases que refieren a Jet. > Por otra parte tengo los objetos que pertenecen al Editor de mapas. > Yo puse la clase JetEditorObject colgada de JetObject, pero no sé si > JetEditorObject debería colgar de Object. > Si no heredás nada de comportamiento de JetObject (y supongo que no), sería mejor que "cuelgue" de Object. Si tenés proyectos, no hay necesidad de "inventar" clases sólo para agrupar cosas debajo de ellas. > > classNames > "Private - Returns the names of Project dependent classes." > ^#( > GenesisObject "Model objects" > GenesisDLL "Low level interface" > GenesisMainWindow "MainWindow enhacements" > GenesisCoordinator "GUI Tests" > ) > > Deben estar en orden inverso ? o no importa > No entiendo. Si estuvieran en orden inverso, quedarían los tests antes de las clases de base, según lo que dicen los comentarios. Esto parece indicar una especie de orden de dependencias. Saludos -- Carlos E. Ferro* * ceferro@ciudad. com.ar <mailto:ceferro@ciudad. com.ar> carloseferrob@ yahoo.com <mailto:carloseferrob@ yahoo.com>

---

Yahoo! Cocina
Recetas prácticas y comida saludable
Visitá http://ar.mujer.yahoo.com/cocina/

Carlos wrote:

De todos modos, en el manejo primitivo de proyectos de VS, no se puede
cargar una SLL si tiene referencias externas. Eso es relativamente fácil
de arreglar y lo sugiero fuertemente, ya que es una limitación bastante
incómoda.

 

A que te referis con esto, podrías ampliar el concepto ?

El caso es que GenesisObject, tiene referencias a GenesisDLL.

Y GenesisDLL no tiene referencias a ningun GenesisObject o deribados.

Es por eso que me confunde.

 

Por lo que entiendo un proyecto no es mas que una forma de organizar un conjunto de clases con sus respectivos comportamientos, de tal forma que al cargarlas desde ST esten en el orden correcto y no reviente por no conozer alguna clase que se hace referencía y que no fue instalada aun.

Estoy muy  lejos ?.

ES solo por esto que creo que lo mas dificultoso es decirle al proyecto que clase va antes o despues de las demas.

Es esto a lo que quiero llegar

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

From: kikoGregoris

To: smalltalking@...

Sent: Thursday, February 26, 2009 4:28 PM

Subject: [objetos] Manejo de proyecto en Vs ?

Hola Gente   Estoy usando el manejador de proyecto de Ale. Lo que no me queda claro es como hacer para determinar las clases que dependen entre sí. Puedo usar References, pero en un sistema con muchas clases se empieza a complicar. O no ?.   Otra cosa, tengo por un lado la clase JetObject, desde donde cuelgan todas las clases que refieren a Jet. Por otra parte tengo los objetos que pertenecen al Editor de mapas. Yo puse la clase JetEditorObject colgada de JetObject, pero no sé si JetEditorObject debería colgar de Object. ESto es para tratar de diferenciar lo que corresponde puramente al manejo del Engine y el otro para el manejo del editor de mapas. Se entiendo ?. Además para facilitar la creación y separación  de los proyectos   Por último   classNames  "Private - Returns the names of Project dependent classes."  ^#(  GenesisObject "Model objects"  GenesisDLL "Low level interface"  GenesisMainWindow "MainWindow enhacements"  GenesisCoordinator "GUI Tests"  )   Deben estar en orden inverso ? o no importa saludos kiko

---

Yahoo! Cocina
Recetas prácticas y comida saludable
Visitá http://ar.mujer.yahoo.com/cocina/

kikoGregoris wrote:
> Hola Gente
>
> Estoy usando el manejador de proyecto de Ale.
> Lo que no me queda claro es como hacer para determinar las clases que
> dependen entre sí.
> Puedo usar References, pero en un sistema con muchas clases se empieza
> a complicar. O no ?.
>
Sí, se puede complicar.
Pero entonces es que el proyecto no está bien definido.
La idea al trabajar con proyectos es que en un proyecto tenés un grupo
cohesivo y coherente de clases, que se referencian entre sí en sus métodos.
Debe(ría) haber pocas referencias a clases de fuera del proyecto. Por
supuesto, siempre hay.
De todos modos, en el manejo primitivo de proyectos de VS, no se puede
cargar una SLL si tiene referencias externas. Eso es relativamente fácil
de arreglar y lo sugiero fuertemente, ya que es una limitación bastante
incómoda.
>
> Otra cosa, tengo por un lado la clase JetObject, desde donde cuelgan
> todas las clases que refieren a Jet.
> Por otra parte tengo los objetos que pertenecen al Editor de mapas.
> Yo puse la clase JetEditorObject colgada de JetObject, pero no sé si
> JetEditorObject debería colgar de Object.
>
Si no heredás nada de comportamiento de JetObject (y supongo que no),
sería mejor que "cuelgue" de Object. Si tenés proyectos, no hay
necesidad de "inventar" clases sólo para agrupar cosas debajo de ellas.
>
> classNames
>  "Private - Returns the names of Project dependent classes."
>  ^#(
>  GenesisObject "Model objects"
>  GenesisDLL "Low level interface"
>  GenesisMainWindow "MainWindow enhacements"
>  GenesisCoordinator "GUI Tests"
>  )
>
> Deben estar en orden inverso ? o no importa
>
No entiendo. Si estuvieran en orden inverso, quedarían los tests antes
de las clases de base, según lo que dicen los comentarios. Esto parece
indicar una especie de orden de dependencias.

Saludos

--

Carlos E. Ferro* *
ceferro@... <mailto:ceferro@...>
carloseferrob@... <mailto:carloseferrob@...>

elvio, el viernes paso a eso de las 16 mas o menos, si le parece bien

Hola, disculpe la demora en escribir, pasa que ultimamente estoy mas
apurado que rengo en tiroteo jajaja

Estoy preparando un par de finales y estoy trabajando en un gym mañana
y un poco a la tarde, pero no tengo problema para arreglar un día, por
ejemplo el viernes a la tarde para que nos juntemos a charlar sobre
las charlas (valga la redundancia).

Usted dirá a que hora en particular...

Miguel.

Hola,

Estaré en Argentina esta semana y daré una charla en Buenos Aires con
el objetivo de Desmistificar Agile & Scrum, que son un nuevo paradigma
para gestion de proyectos mucho mas alineados a los trabajadores del
conocimiento.

Lo interesante es que este tipo de procesos surgieron en la comunidad
de Objetos, muchos de las mismas personas de Smalltalk.

La charla es gratuita, la inscripcion hay que hacerla en
http://tinyurl.com/dfkfhc

Abrazos,
Juan Bernabó

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

From: kikoGregoris

To: smalltalking@...

Sent: Monday, February 23, 2009 10:20 AM

Subject: Re: Profile /V (Era Re: [objetos] RE: Vs GUI ???)

Hola Ale   Con el #erase, me refiero a que cuando borra el GraphPane se nota . El efecto es visible y es muy feo. Nosé como se llama tecnicamente este efecto, pero creo que tiene un nombre. Parese como cuando filmas la pantalla del televisor que se ve el barrido de la pantalla.     Otra cosa, las conversiones de precision doble a simple son muy costosas ?. Segun el profile si. Yo uso OleStructure para las conversiones   JetStruct(class)>>singleFloatAtOffset: offset  "Answer a Float that represents the single-precision float value at offset <offset>."    ^ OLEStructure internalFloatFromExternalFloat: ( self bytesAtOffset: offset count: 4 )   Esto es de alta performance ?   Pregunte en el foro de Jet3D si puedo declarar jeFloat como double. Creo que sería lo mas conveniente. No ?     saludos kiko --- El lun 23-feb-09, Alejandro F. Reimondo <aleReimondo@...> escribió: De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: Profile /V (Era Re: [objetos] RE: Vs GUI ???) Para: smalltalking@... Fecha: lunes, 23 de febrero de 2009, 9:54 am Hola,   >Lo tengo implementado y igual que vos en Genesis, usando > SelfDefinedStructur e y el Profile me dice que se gasta el > 60% del tiemp en la recorrida y accesos a las estructuras.   Es posible, el jitter de la VM de VisualSmalltalk no optimiza  a ese nivel; es una VM ya viejita y si bien anda muy bien  en muchos casos ya se le ven los achaques del tiempo :-) No ocurre lo mismo aún con las aplicaciones hechas con VS.   >Implemente una version de Vector heredada de ExternalBuffer > y la velocidad se incremento muchisimo.   Eso es lo correcto, optimizar solo dónde vale la pena.   >Tambien me dice que el #collect: es vastante costoso.   Toda copia tiene costo a corti y largo plazo (creo que el profiler  te indicará el costo inmediato, de cómputo, pero note dá una idea  de que impacto tiene a mediano plazo, debido a la intoxicación  que impone en el sistema y lo que le cuesta "limpiarla") .   >De todas formas, aunque ahora el movimiento del mapa es > muy suave se nota el #erase. >Y es muy molesto. >Porque razon puede ser ?. >Alguna forma de evitar esto ?.   No me doy cuenta a quete referís.   Ale.         ----- Original Message -----

__

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

From: Alejandro F. Reimondo

To: smalltalking@...

Sent: Monday, February 23, 2009 9:54 AM

Subject: Re: Profile /V (Era Re: [objetos] RE: Vs GUI ???)

Hola,

 

>Lo tengo implementado y igual que vos en Genesis, usando

> SelfDefinedStructure y el Profile me dice que se gasta el

> 60% del tiemp en la recorrida y accesos a las estructuras.

 

Es posible, el jitter de la VM de VisualSmalltalk no optimiza

 a ese nivel; es una VM ya viejita y si bien anda muy bien

 en muchos casos ya se le ven los achaques del tiempo :-)

No ocurre lo mismo aún con las aplicaciones hechas con VS.

 

>Implemente una version de Vector heredada de ExternalBuffer

> y la velocidad se incremento muchisimo.

 

Eso es lo correcto, optimizar solo dónde vale la pena.

 

>Tambien me dice que el #collect: es vastante costoso.

 

Toda copia tiene costo a corti y largo plazo (creo que el profiler

 te indicará el costo inmediato, de cómputo, pero note dá una idea

 de que impacto tiene a mediano plazo, debido a la intoxicación

 que impone en el sistema y lo que le cuesta "limpiarla").

 

>De todas formas, aunque ahora el movimiento del mapa es

> muy suave se nota el #erase.

>Y es muy molesto.

>Porque razon puede ser ?.

>Alguna forma de evitar esto ?.

 

No me doy cuenta a quete referís.

 

Ale.

 

 

 

 

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

From: kikoGregoris

To: smalltalking@...

Sent: Sunday, February 22, 2009 9:29 PM

Subject: Re: Profile /V (Era Re: [objetos] RE: Vs GUI ???)

Hola Ale   Gracias, ya me pasaron el Profile/V. Es muy simple de usar y te da info muy precisa. En mi caso el problema principal es la forma en que estoy usando las estructuras y punteros de Jet.   Lo tengo implementado y igual que vos en Genesis, usando SelfDefinedStructure y el Profile me dice que se gasta el 60% del tiemp en la recorrida y accesos a las estructuras. Implemente una version de Vector heredada de ExternalBuffer y la velocidad se incremento muchisimo.     Tambien me dice que el #collect: es vastante costoso.   De todas formas, aunque ahora el movimiento del mapa es muy suave se nota el #erase. Y es muy molesto. Porque razon puede ser ?. Alguna forma de evitar esto ?.   saludos kiko       --- El mié 18-feb-09, Alejandro F. Reimondo <aleReimondo@...> escribió: De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: Profile /V (Era Re: [objetos] RE: Vs GUI ???) Para: smalltalking@... Fecha: miércoles, 18 de febrero de 2009, 8:24 pm En Help abri el VDoc31W.hlp y luego     - Language Reference     -- Perfomance Profiler     ------[LRSubtopics] No es una maravilla... ,  pero creo que te puede ser de utilidad. Ale. ----- Original Message ----- From: kikoGregoris To: smalltalking@ gruposyahoo. com.ar Sent: Wednesday, February 18, 2009 5:23 PM Subject: Profile /V (Era Re: [objetos] RE: Vs GUI ???) Hola Ale, gente   Estube buscando el Profile/V, pero no hay rastros de el. Alguien lo tiene disponible ?. Instale un clase que se llama Profile que estaba el las Lib, pero nosé si es el Profile/V o no. Además de que no tengo idea de como usarlo.   Alguna ayudita .   saludos kiko --- El mié 18-feb-09, Alejandro F. Reimondo <aleReimondo@ smalltalking. net> escribió: De: Alejandro F. Reimondo <aleReimondo@ smalltalking. net> Asunto: Re: [objetos] RE: Vs GUI ??? Para: smalltalking@ gruposyahoo. com.ar Fecha: miércoles, 18 de febrero de 2009, 4:31 pm Hola kiko,   Es muy raro que el mayor tiempo se consuma en recorrerlos y en recalcularlos. ..  fijate si te es de utilidad analizar con el profiler dónde y porqué estas perdiendolo;  si efectivamente se te va en computo, te sugiero que analices minusiosamente  que cuentas estan implicadas, tratando de eliminar las conversiones (por ejemplo,  el uso de fraciones, LongIntegers intermedios, etc). Si eso tampoco elimina  del todo el tiempo, o no es satisfactorio, en ese punto, tendrás usa idea clara  de qué computo es intensivo, y tenes la alterntiva de colocar ese computo  a ser realizado con optimizaciones (como por ejm. usando OpenC u otra  librería que pueda realizar computo masivo de forma optima).   Sobre lo significativo de los "16ms"... no puedo decirte si es importante  o no reducirlos.. . fijate con el profiler. Por otro lado, siempre es bueno no dibujar cuando no es necesario :-)  e incluso, a veces, saltar cuadros de la animación.   >PD: Nadie a tenido algun problema similar > para dibujar en un GraphPane ?   jajaja todo el que hace algo con un minimo de manejo gráfico  ha tenido inconvenientes.   suerte, (dale masa) Ale.         ----- Original Message ----- From: kikoGregoris To: smalltalking@ gruposyahoo. com.ar Sent: Tuesday, February 17, 2009 10:26 AM Subject: Re: [objetos] RE: Vs GUI ??? Hola Gente   Tome el tiempo con #millisencodnsToRun : y el tiempo se va en el recalculo de los vertices, sobre todo en recorrerlos Por el contrario de lo que yo pensaba, que era en dibujar. Esto solo toma entre 0 y 16 millisegudos, para un total de 38 brush. Creo que es poco significativo este tiempo. No ?.   Lo que intento es: En vez de recorrer todas las caras de los Brush cada vez que muevo o hago zoom, me quedo con una colección vertices del  lado de ST y trabajo con ella. Con esto mejoró bastante.   El otro problema que veo es que se nota cuando se hace el #erase y queda horrible.   Alguna idea ?   saludos kiko   PD: Nadie a tenido algun problema similar para dibujar en un GraphPane ?       --- El lun 16-feb-09, kikoGregoris <kikogregoris@ yahoo.com. ar> escribió: De: kikoGregoris <kikogregoris@ yahoo.com. ar> Asunto: [objetos] RE: Vs GUI ??? Para: smalltalking@ gruposyahoo. com.ar Fecha: lunes, 16 de febrero de 2009, 9:28 am Hola Gente   Tengo un problema con la utilización de un GraphPane. El tema es que debo dibujar un Brush, por ejemplo un cuadrado y luego poder moverlo con el mouse.   Tengo definido el evento #display y un mensaje #displayWindow asociado a dicho evento.   La implementació n de #displayWindow manda a dibujar el o los brush de esta manera:   OrthoViewCompositeP ane>>displayWindow   "Callback for the #display event in OrthoViewPane [GraphPane]. (Generated by WindowBuilder Pro)"   self brushes isNil ifFalse:[ self brushes do:[:brush | brush drawOrthoViewFacesW ith: camera in: self ]].   drawOrthoViewFacesW ith: aJetEditorCamera in: aPane   "Draw all faces of the receiver in aPane with aJetEditorCamera"     self firstTime ifTrue:[ aPane graphPane pen deleteAllSegments. self allFaces do:[:face | vertexs removeAll. 0 to:(face vertexCount- 1) do:[:index | vertexs add: (aJetEditorCamera worldToView: (self worldSpaceVertexAt: index from:face) )]. aPane graphPane pen drawRetainPicture: [ aPane graphPane pen polygon: vertexs]. self firstTime: false. ]. ] ifFalse:[ aPane graphPane pen drawChain].   Tengo 2 problemas.   El primer problema es la actualización del GraphPane, luego de mover el Brush.   En este momento lo manejo asi:   OrthoViewCompositeP ane>>button1Moved: aPane   "Callback for the #button1Moved event in OrthoViewPane [GraphPane]. (Generated by WindowBuilder Pro)"     Notifier isControlKeyDown ifTrue:[   self camera updatePosition: ( aPane mouseLocation ). self graphPane erase; redraw. ].   Esto funciona OK. La pregunta es: Es el momento de hacer el update del GraphPane ?. Si solo envio #redraw dibuja sin limpiar el cuadro anterior, con lo cual queda un garabato !!.       Por otra parte el problema mas grande es la caída de la performance con geometrías grandes y complejas.   Esto se debe a que cada vez que muevo la camara, se debe recalcular los puntos de cada polígono de cada Brush que se van a dibujar y luego dibujarlos de a uno.         Nosé si se entiende bien, tratare de sintetizar el problema.   Cada vez que dibujo un Brush, debo tomar los vertices de cada cara y transformarlos desde las coordenadas locales en el mapa a las coordenadas del Screen. Luego los dibujo.   Para moverlos o hacer un zoom, solo cambio la posición de la cámara y recalculo cada polígono, luego los dibujo. Así lo hacen en C++:   void Brush_RenderOrthoFa ces( Brush *pBrush, const Ortho * pOrtho, int32 hDC, jeBoolean bDrawVertex, jeBoolean bDrawSelFaces, jeBoolean bColorOveride ) { int i, j ; jeBrush_Face * pFace ; Point points[BRUSH_ MAXPOINTSPERFACE ]; jeVec3d Vert ; int nVertices ; jeBoolean bFaceSelected ; HDC hVertexBitmap; jwePen * pPen = NULL; assert( pOrtho != NULL ) ; assert( SIGNATURE == pBrush->nSignature ) ; assert( pBrush != NULL ) ; if (!pBrush->bShow) return; // Jeff: Load vertex bitmap from resources - 8/18/2005 if( bDrawVertex ) { hVertexBitmap = CreateCompatibleDC( (HDC)hDC) ; SelectObject( hVertexBitmap, (HBITMAP)AppData_ GetVertex( )); } if( ! bColorOveride ) { if( Brush_IsCutBrush( pBrush ) ) { pPen = Pen_SelectSubtractB rushColor( hDC ) ; } else { pPen = Pen_SelectAddBrushC olor( hDC ) ; } } i = 0; pFace = Brush_GetNextFace( pBrush, NULL ) ; do { bFaceSelected = Brush_IsFaceSelecte d( pBrush, pFace ) ; if( !(bDrawSelFaces && bFaceSelected) ) { nVertices = Brush_FaceGetVertCo unt( pFace ) ; assert( nVertices < BRUSH_MAXPOINTSPERF ACE ) ; for( i=0; i<nVertices; i++ ) { Vert = Brush_FaceGetWorldS paceVertByIndex( pBrush, pFace, i ) ; Ortho_WorldToView( pOrtho, &Vert, &points[i] ) ; } points[i++] = points[0] ; // It would appear we just let GDI clip... Pen_Polyline( hDC, points, i ) ; // hDC==hDrawDC } if( bDrawVertex ) { i = Brush_FaceGetVertCo unt( pFace ) ; for( j=0; j<i; j++ ) BitBlt((HDC) hDC, points[j].X- 3, points[j].Y- 3, 6, 6, hVertexBitmap, 0, 0, SRCCOPY ); } pFace = Brush_GetNextFace( pBrush, pFace ) ; } while( pFace != NULL ) ; if( ! bColorOveride && pPen ) Pen_Release( pPen, hDC ); if( bDrawVertex ) DeleteDC(hVertexBit map ); // 2nd pass for selected faces? if( bDrawSelFaces ) { FaceIterator fI; pPen = Pen_SelectSelectedF aceColor( hDC ); pFace = FaceList_GetFirstFa ce(pBrush->pSelFaces, &fI ) ; while (pFace) { if( Brush_IsFaceSelecte d( pBrush, pFace ) ) { nVertices = Brush_FaceGetVertCo unt( pFace ) ; assert( nVertices < BRUSH_MAXPOINTSPERF ACE ) ; for( i=0; i<nVertices; i++ ) { Vert = Brush_FaceGetWorldS paceVertByIndex( pBrush, pFace, i ) ; Ortho_WorldToView( pOrtho, &Vert, &points[i] ) ; } points[i++] = points[0] ; // It would appear we just let GDI clip... Pen_Polyline( hDC, points, i ) ; // hDC==hDrawDC } pFace = FaceList_GetNextFac e( pBrush->pSelFaces, &fI ) ; }; Pen_Release( pPen, hDC ); } // Draw Sel Faces if( bDrawVertex ) { VertDrawInfo vdi ; VertList * pVerts ; // If any verts are selected, draw the verts pVerts = Brush_GetSelVert( pBrush ) ; if( VertList_GetNumVert ( pVerts ) ) { vdi.hDC = hDC ; vdi.pBrush = pBrush ; vdi.pOrtho = pOrtho ; VertList_Enum( pVerts, &vdi, Brush_DrawSelectedV ertsCB ) ; } } } // Brush_RenderOrthoFa ces   Como se ve, ellos recalculan todo cada vez que se mueve o se hace un zoom y no hay caida de performance.   El usar la capasidad del RecordingPen, me trae el problema de que no puedo mover o hacer zoom con los StorePicture guardados y por lo tanto no me queda otra que recalcular todo.   Podría quedarme con los vertices ya convertidos y trabajar con ellos, pero no me ha dado mucho resultado.   Alguna sugerencía ?   Saludos kiko Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/ Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/ Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/

---

Yahoo! Cocina
Recetas prácticas y comida saludable
Visitá http://ar.mujer.yahoo.com/cocina/

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

From: kikoGregoris

To: smalltalking@...

Sent: Sunday, February 22, 2009 9:29 PM

Subject: Re: Profile /V (Era Re: [objetos] RE: Vs GUI ???)

Hola Ale   Gracias, ya me pasaron el Profile/V. Es muy simple de usar y te da info muy precisa. En mi caso el problema principal es la forma en que estoy usando las estructuras y punteros de Jet.   Lo tengo implementado y igual que vos en Genesis, usando SelfDefinedStructure y el Profile me dice que se gasta el 60% del tiemp en la recorrida y accesos a las estructuras. Implemente una version de Vector heredada de ExternalBuffer y la velocidad se incremento muchisimo.     Tambien me dice que el #collect: es vastante costoso.   De todas formas, aunque ahora el movimiento del mapa es muy suave se nota el #erase. Y es muy molesto. Porque razon puede ser ?. Alguna forma de evitar esto ?.   saludos kiko       --- El mié 18-feb-09, Alejandro F. Reimondo <aleReimondo@...> escribió: De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: Profile /V (Era Re: [objetos] RE: Vs GUI ???) Para: smalltalking@... Fecha: miércoles, 18 de febrero de 2009, 8:24 pm En Help abri el VDoc31W.hlp y luego     - Language Reference     -- Perfomance Profiler     ------[LRSubtopics] No es una maravilla... ,  pero creo que te puede ser de utilidad. Ale. ----- Original Message ----- From: kikoGregoris To: smalltalking@ gruposyahoo. com.ar Sent: Wednesday, February 18, 2009 5:23 PM Subject: Profile /V (Era Re: [objetos] RE: Vs GUI ???) Hola Ale, gente   Estube buscando el Profile/V, pero no hay rastros de el. Alguien lo tiene disponible ?. Instale un clase que se llama Profile que estaba el las Lib, pero nosé si es el Profile/V o no. Además de que no tengo idea de como usarlo.   Alguna ayudita .   saludos kiko --- El mié 18-feb-09, Alejandro F. Reimondo <aleReimondo@ smalltalking. net> escribió: De: Alejandro F. Reimondo <aleReimondo@ smalltalking. net> Asunto: Re: [objetos] RE: Vs GUI ??? Para: smalltalking@ gruposyahoo. com.ar Fecha: miércoles, 18 de febrero de 2009, 4:31 pm Hola kiko,   Es muy raro que el mayor tiempo se consuma en recorrerlos y en recalcularlos. ..  fijate si te es de utilidad analizar con el profiler dónde y porqué estas perdiendolo;  si efectivamente se te va en computo, te sugiero que analices minusiosamente  que cuentas estan implicadas, tratando de eliminar las conversiones (por ejemplo,  el uso de fraciones, LongIntegers intermedios, etc). Si eso tampoco elimina  del todo el tiempo, o no es satisfactorio, en ese punto, tendrás usa idea clara  de qué computo es intensivo, y tenes la alterntiva de colocar ese computo  a ser realizado con optimizaciones (como por ejm. usando OpenC u otra  librería que pueda realizar computo masivo de forma optima).   Sobre lo significativo de los "16ms"... no puedo decirte si es importante  o no reducirlos.. . fijate con el profiler. Por otro lado, siempre es bueno no dibujar cuando no es necesario :-)  e incluso, a veces, saltar cuadros de la animación.   >PD: Nadie a tenido algun problema similar > para dibujar en un GraphPane ?   jajaja todo el que hace algo con un minimo de manejo gráfico  ha tenido inconvenientes.   suerte, (dale masa) Ale.         ----- Original Message ----- From: kikoGregoris To: smalltalking@ gruposyahoo. com.ar Sent: Tuesday, February 17, 2009 10:26 AM Subject: Re: [objetos] RE: Vs GUI ??? Hola Gente   Tome el tiempo con #millisencodnsToRun : y el tiempo se va en el recalculo de los vertices, sobre todo en recorrerlos Por el contrario de lo que yo pensaba, que era en dibujar. Esto solo toma entre 0 y 16 millisegudos, para un total de 38 brush. Creo que es poco significativo este tiempo. No ?.   Lo que intento es: En vez de recorrer todas las caras de los Brush cada vez que muevo o hago zoom, me quedo con una colección vertices del  lado de ST y trabajo con ella. Con esto mejoró bastante.   El otro problema que veo es que se nota cuando se hace el #erase y queda horrible.   Alguna idea ?   saludos kiko   PD: Nadie a tenido algun problema similar para dibujar en un GraphPane ?       --- El lun 16-feb-09, kikoGregoris <kikogregoris@ yahoo.com. ar> escribió: De: kikoGregoris <kikogregoris@ yahoo.com. ar> Asunto: [objetos] RE: Vs GUI ??? Para: smalltalking@ gruposyahoo. com.ar Fecha: lunes, 16 de febrero de 2009, 9:28 am Hola Gente   Tengo un problema con la utilización de un GraphPane. El tema es que debo dibujar un Brush, por ejemplo un cuadrado y luego poder moverlo con el mouse.   Tengo definido el evento #display y un mensaje #displayWindow asociado a dicho evento.   La implementació n de #displayWindow manda a dibujar el o los brush de esta manera:   OrthoViewCompositeP ane>>displayWindow   "Callback for the #display event in OrthoViewPane [GraphPane]. (Generated by WindowBuilder Pro)"   self brushes isNil ifFalse:[ self brushes do:[:brush | brush drawOrthoViewFacesW ith: camera in: self ]].   drawOrthoViewFacesW ith: aJetEditorCamera in: aPane   "Draw all faces of the receiver in aPane with aJetEditorCamera"     self firstTime ifTrue:[ aPane graphPane pen deleteAllSegments. self allFaces do:[:face | vertexs removeAll. 0 to:(face vertexCount- 1) do:[:index | vertexs add: (aJetEditorCamera worldToView: (self worldSpaceVertexAt: index from:face) )]. aPane graphPane pen drawRetainPicture: [ aPane graphPane pen polygon: vertexs]. self firstTime: false. ]. ] ifFalse:[ aPane graphPane pen drawChain].   Tengo 2 problemas.   El primer problema es la actualización del GraphPane, luego de mover el Brush.   En este momento lo manejo asi:   OrthoViewCompositeP ane>>button1Moved: aPane   "Callback for the #button1Moved event in OrthoViewPane [GraphPane]. (Generated by WindowBuilder Pro)"     Notifier isControlKeyDown ifTrue:[   self camera updatePosition: ( aPane mouseLocation ). self graphPane erase; redraw. ].   Esto funciona OK. La pregunta es: Es el momento de hacer el update del GraphPane ?. Si solo envio #redraw dibuja sin limpiar el cuadro anterior, con lo cual queda un garabato !!.       Por otra parte el problema mas grande es la caída de la performance con geometrías grandes y complejas.   Esto se debe a que cada vez que muevo la camara, se debe recalcular los puntos de cada polígono de cada Brush que se van a dibujar y luego dibujarlos de a uno.         Nosé si se entiende bien, tratare de sintetizar el problema.   Cada vez que dibujo un Brush, debo tomar los vertices de cada cara y transformarlos desde las coordenadas locales en el mapa a las coordenadas del Screen. Luego los dibujo.   Para moverlos o hacer un zoom, solo cambio la posición de la cámara y recalculo cada polígono, luego los dibujo. Así lo hacen en C++:   void Brush_RenderOrthoFa ces( Brush *pBrush, const Ortho * pOrtho, int32 hDC, jeBoolean bDrawVertex, jeBoolean bDrawSelFaces, jeBoolean bColorOveride ) { int i, j ; jeBrush_Face * pFace ; Point points[BRUSH_ MAXPOINTSPERFACE ]; jeVec3d Vert ; int nVertices ; jeBoolean bFaceSelected ; HDC hVertexBitmap; jwePen * pPen = NULL; assert( pOrtho != NULL ) ; assert( SIGNATURE == pBrush->nSignature ) ; assert( pBrush != NULL ) ; if (!pBrush->bShow) return; // Jeff: Load vertex bitmap from resources - 8/18/2005 if( bDrawVertex ) { hVertexBitmap = CreateCompatibleDC( (HDC)hDC) ; SelectObject( hVertexBitmap, (HBITMAP)AppData_ GetVertex( )); } if( ! bColorOveride ) { if( Brush_IsCutBrush( pBrush ) ) { pPen = Pen_SelectSubtractB rushColor( hDC ) ; } else { pPen = Pen_SelectAddBrushC olor( hDC ) ; } } i = 0; pFace = Brush_GetNextFace( pBrush, NULL ) ; do { bFaceSelected = Brush_IsFaceSelecte d( pBrush, pFace ) ; if( !(bDrawSelFaces && bFaceSelected) ) { nVertices = Brush_FaceGetVertCo unt( pFace ) ; assert( nVertices < BRUSH_MAXPOINTSPERF ACE ) ; for( i=0; i<nVertices; i++ ) { Vert = Brush_FaceGetWorldS paceVertByIndex( pBrush, pFace, i ) ; Ortho_WorldToView( pOrtho, &Vert, &points[i] ) ; } points[i++] = points[0] ; // It would appear we just let GDI clip... Pen_Polyline( hDC, points, i ) ; // hDC==hDrawDC } if( bDrawVertex ) { i = Brush_FaceGetVertCo unt( pFace ) ; for( j=0; j<i; j++ ) BitBlt((HDC) hDC, points[j].X- 3, points[j].Y- 3, 6, 6, hVertexBitmap, 0, 0, SRCCOPY ); } pFace = Brush_GetNextFace( pBrush, pFace ) ; } while( pFace != NULL ) ; if( ! bColorOveride && pPen ) Pen_Release( pPen, hDC ); if( bDrawVertex ) DeleteDC(hVertexBit map ); // 2nd pass for selected faces? if( bDrawSelFaces ) { FaceIterator fI; pPen = Pen_SelectSelectedF aceColor( hDC ); pFace = FaceList_GetFirstFa ce(pBrush->pSelFaces, &fI ) ; while (pFace) { if( Brush_IsFaceSelecte d( pBrush, pFace ) ) { nVertices = Brush_FaceGetVertCo unt( pFace ) ; assert( nVertices < BRUSH_MAXPOINTSPERF ACE ) ; for( i=0; i<nVertices; i++ ) { Vert = Brush_FaceGetWorldS paceVertByIndex( pBrush, pFace, i ) ; Ortho_WorldToView( pOrtho, &Vert, &points[i] ) ; } points[i++] = points[0] ; // It would appear we just let GDI clip... Pen_Polyline( hDC, points, i ) ; // hDC==hDrawDC } pFace = FaceList_GetNextFac e( pBrush->pSelFaces, &fI ) ; }; Pen_Release( pPen, hDC ); } // Draw Sel Faces if( bDrawVertex ) { VertDrawInfo vdi ; VertList * pVerts ; // If any verts are selected, draw the verts pVerts = Brush_GetSelVert( pBrush ) ; if( VertList_GetNumVert ( pVerts ) ) { vdi.hDC = hDC ; vdi.pBrush = pBrush ; vdi.pOrtho = pOrtho ; VertList_Enum( pVerts, &vdi, Brush_DrawSelectedV ertsCB ) ; } } } // Brush_RenderOrthoFa ces   Como se ve, ellos recalculan todo cada vez que se mueve o se hace un zoom y no hay caida de performance.   El usar la capasidad del RecordingPen, me trae el problema de que no puedo mover o hacer zoom con los StorePicture guardados y por lo tanto no me queda otra que recalcular todo.   Podría quedarme con los vertices ya convertidos y trabajar con ellos, pero no me ha dado mucho resultado.   Alguna sugerencía ?   Saludos kiko Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/ Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/ Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/

---

Yahoo! Cocina
Recetas prácticas y comida saludable
Visitá http://ar.mujer.yahoo.com/cocina/

Hola, disculpen que la demora en responder, pasa que me estaba fijando las fechas para rendir finales...

En fin, si la hacen el 8 o 15 de marzo puedo ir sin problemas.

Saludos

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

From: Elvio Fernandez

To: smalltalking@...

Sent: Friday, February 20, 2009 9:50 AM

Subject: [objetos] Re: Reunion en La Plata

Como nadie respondio nada, vuelvo a enunciar:
pospongamos la reunion de mañana 21, para una o dos semanas adelante. No todos pueden concurrir

Posibles dias:
 1 de marzo,
8 de marzo,
15 de marzo,

Saludos

Elvio

El 19 de febrero de 2009 11:27, Elvio Fernandez <elvio.fernandez@gmail.com> escribió:

Muchachos, mejor pospongamos la reunion para una o dos semanas adelante. No todos pueden concurrir

Posibles dias:
 1 de marzo,
8 de marzo,
15 de marzo,

Elijan gente.

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

From: kikoGregoris

To: smalltalking@...

Sent: Wednesday, February 18, 2009 7:38 AM

Subject: Re: [objetos] Recuperar imagen VS ????

Hola Ale   Gracias, es graticante saber que uno lo puede hacer. Estaba viendo tu manejador de proyectos y no me queda claro como funciona. Me das un pantallazo de por donde debo ir ?.   Porqué hay *.ssl y *.st que contienen lo mismo ?. Que son los *.sml y *.prj ?   saludos kiko --- El lun 16-feb-09, Alejandro F. Reimondo <aleReimondo@...> escribió: De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: [objetos] Recuperar imagen VS ???? Para: smalltalking@... Fecha: lunes, 16 de febrero de 2009, 3:09 pm  kiko, Mis recomendacione serían: 1.- hace backups periodicos (es frecuente en la etapa  de aprendizaje romper algo valioso). 2.- no uses un image de desarrollo para hacer ensayos  (a veces se advierten muy tarde los efectos de una innovación). 3.- no es necesario que trabajes grabando el image. El que hayas sufrido un problema como el que comentaste  y que hayas podido recuperarte de él habla de que  superaste una etapa. Felicitaciones! suerte! Ale.     ----- Original Message ----- From: kikoGregoris To: smalltalking@ gruposyahoo. com.ar Sent: Monday, February 16, 2009 7:05 AM Subject: Re: [objetos] Recuperar imagen VS ???? Hola Ale, carlos   Gracias, ya recupere lo que necesitaba.   Sería conveniente que arrancara con una imagen nueva ?. O no hay problemas de que se vuelva a romper ?.   saludos kiko --- El vie 13-feb-09, Alejandro F. Reimondo <aleReimondo@ smalltalking. net> escribió: De: Alejandro F. Reimondo <aleReimondo@ smalltalking. net> Asunto: Re: [objetos] Recuperar imagen VS ???? Para: smalltalking@ gruposyahoo. com.ar Fecha: viernes, 13 de febrero de 2009, 6:37 pm  Kiko, Es simple parsear el mensaje, fijate en el mensaje de clase   Message class >> numberOfArgumentsFo r:  para saber que selectores son los que no tienen dos puntos. Los demás mensajes no tienen arguments (no tienen $:)  o estan formados por unidades de dos partes (en el fuente),  una hasta los dos puntos y la siguiente (#nextWord)  que es sin dos puntos y determina el nombre del argumento. suerte! Ale. pdta: Para ver algo menos simple, podes ver el goodie de  smalltalking de Scripting que tiene un parser de metodos  completos.     ----- Original Message ----- From: kikoGregoris To: smalltalking@ gruposyahoo. com.ar Sent: Tuesday, February 10, 2009 1:43 PM Subject: Re: [objetos] Recuperar imagen VS ???? Hola   Creo que no es el mejor ejemplo el que mostré , pues es un caso simple.   este es el bueno:   >>addDependent: anObject interestIn: anAspect     "Add a dependent <anObject> that receives an update event when the event named <anAspect> is triggered."     self         when: anAspect         send: #update         to: anObject   Si en mensaje esta bien formado, es decir tiene comment no hay drama. Pero cuando no tiene ? Es posible que sea muy fácil,pero no me doy cuenta.   saludos kiko - El lun 9-feb-09, kikoGregoris <kikogregoris@ yahoo.com. ar> escribió: De: kikoGregoris <kikogregoris@ yahoo.com. ar> Asunto: Re: [objetos] Recuperar imagen VS ???? Para: smalltalking@ gruposyahoo. com.ar Fecha: lunes, 9 de febrero de 2009, 4:15 pm Hola Ale, carlos, gente   Pude implementar una rudimentaria rutina, que retorna y compila todos los sourceString para una clase dada. A excepción de los mensajes que tienen argumentos. !!!   El tema esta en que no puedo parsear correctamente desde el string. Por la sensilla razón de que nosé cual es la condición de corte correcto dentro del string.   Pongamos un ejemplo:   >>activate: aBoolean     "Activates the receiver."     ^self dll         jeEngineActivate: self asParameter         active: aBoolean asParameter   En este caso podria usar el primer ( " ) para saber que hay termina el selector.   El tema es, que pasa si no tiene comment ?.   Se entiende ?.   saludos kiko       - El sáb 7-feb-09, Alejandro F. Reimondo <aleReimondo@ smalltalking. net> escribió: De: Alejandro F. Reimondo <aleReimondo@ smalltalking. net> Asunto: Re: [objetos] Recuperar imagen VS ???? Para: smalltalking@ gruposyahoo. com.ar Fecha: sábado, 7 de febrero de 2009, 9:29 pm  Hola kiko,   >Yo de todas maneras empece de atras para adelante > y me voy quedando con las ultimas versiones.   Es mejor ir en orden cronológico.. . leyendo (no con  los ojos - fijate como se hace el fileIn...) y evaluando  los chunks de importancia (definiciones de clases,  vas a ver que es facil parsear el chunk para darte  cuenta si tiene un subclass:... ;  y los aClass removeSelector: xxx)  descartando en casi todos los casos los otros chunks (que  por lo gral son evaluaciones en un inspector,  inútiles en lo que estas haciendo) Los chunks que tiene la forma     ! aClass [class] methods ! es decir, parsea si hay tres palabras...  y la ultima es #methods     determinan que los chunks siguientes  hasta un chunk vacio (que solo tiene blancos)  son metodos de esa clase (si tiene tres palabras la  segunda será "class" e implica que el método  es "de clase", es decir unmetodo dela clase  "aClass class")   Sobre estos ultimos chunks podes ir parseando para  quedarte con el selector (el nombre del mensaje)  y gurdar la ultima version, para luego hacer fileIn  de todos los leidos... o podes irlos compilando  directamente. ..   >Igual es un trabajo durisimo.   No es duro si podes automatizarlo.   Se que estoy tarde leyendo estos mails y seguramente  ya invertiste mucho tiempo y casi seguramente ya te  han dado indicaciones como esta (no es algo dificil  de hacer, es dificil la primera vez :)   Si pensas que te serviría de algo tener una ayuda  sobre esta tarea, decime y busco en mis cosas  una SLL que hace un trabajito como este. Yo la uso cuando quiero conocer diferencias  entre trabajos similares, o versiones de paquetes  en formato fuente.   suerte, Ale.       ----- Original Message ----- From: kikoGregoris To: smalltalking@ gruposyahoo. com.ar Sent: Tuesday, February 03, 2009 9:43 PM Subject: Re: [objetos] Recuperar imagen VS ???? Hola Carlos, guillermo   Si tengo el change.log. Por lo que dice carlos, no queda otra que meter mano al change.   Es un trabajo durisimo, el tema es que esta todo. Lo bueno y lo malo, es decir metodos y clases  que fui modificando con el tiempo.   Yo de todas maneras empece de atras para adelante y me voy quedando con las ultimas versiones. Igual es un trabajo durisimo. En la lista de Vs me tiraron algo voy a ver que dicen antes de hacer mas. No es que  menosprecie sus ayudas, pero por hay se puede hacer algo mas   gracias a ambos   kiko De: Carlos E. Ferro <ceferro@ciudad. com.ar> Asunto: Re: [objetos] Recuperar imagen VS ???? Para: smalltalking@ gruposyahoo. com.ar Fecha: martes, 3 de febrero de 2009, 9:12 pm kikoGregoris wrote: > Hola Gente > > > El tema del código sigue igual, el sourceString de los CompiledMethod > es un entero bien grande. > Eso es normal. El contenido de la variable sourceString es un entero que tiene codificado en qué archivo y en qué offset de ese archivo empieza el chunk con el source del método. > Cuando intentas acceder via el mensaje #source, se tarda una vida para > mostra el contenido que es una collecion de *$.* > Esto indica que tenés corrupto el archivo de fuentes. Si trabajás con la imagen, sin usar SLLs para tus proyectos (y supongo que sí, porque si no, tendrías más fácil el backup y los fuentes), el único archivo de fuentes de tus cambios es el CHANGE.LOG. Algunas cosas viejas y originales del VS se pueden encontrar en otro archivo que se llama SOURCES. Pero lo tuyo debe estar en el change.log. No hay mucho arreglo. Si tenés suerte, se choteó un caracter y lo podés arreglar a mano; dale una hojeada alrededor del punto de ruptura. Pero con ese tema de la codificación, hacer arreglos a mano en los sources es muy difícil. Normalmente es más fácil editar el change.log y re-hacer los cambios a mano. > > Lo que guarda un fileOut de una clase o metodo es precisamente el > método que estaba cambiando. > > Lo curisos es que la aplicacion que estoy haciendo anda perfecto, si > ocurre un error abre el debug, pero no se puede ver el codigo. > No es curioso, indica que lo único que se te estropeó es el archivo de fuentes, o mejor dicho, los links al archivo de código fuente. Los métodos compilados ya tienen sus propios bytecodes guardados y sí, van a andar bien. Otra "salida" es ~~decompilar~ ~ los bytecodes de cada método compilado. Tenemos un ByteCodeReader en el trabajo que hace esas cosas. Creéme que (a menos que tengas mucha cancha) es más fácil leer las cosas del change.log que leer los bytecodes sin nombres simbólicos que te ayuden. El formato chunk es human-readable en serio... > > Alguna idea de como puedo restaurar esto ? > Como te dije arriba, no creo que puedas. Tal vez alguien sepa más que esto o tenga alguna herramienta que te ayude, yo llego hasta ahí. -- Carlos E. Ferro* * ceferro@ciudad. com.ar <mailto:ceferro@ciudad. com.ar> carloseferrob@ yahoo.com <mailto:carloseferrob@ yahoo.com> Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/ Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/ Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/ Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/

---

Yahoo! Cocina
Recetas prácticas y comida saludable
Visitá http://ar.mujer.yahoo.com/cocina/

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

From: kikoGregoris

To: smalltalking@...

Sent: Wednesday, February 18, 2009 5:23 PM

Subject: Profile /V (Era Re: [objetos] RE: Vs GUI ???)

Hola Ale, gente   Estube buscando el Profile/V, pero no hay rastros de el. Alguien lo tiene disponible ?. Instale un clase que se llama Profile que estaba el las Lib, pero nosé si es el Profile/V o no. Además de que no tengo idea de como usarlo.   Alguna ayudita .   saludos kiko --- El mié 18-feb-09, Alejandro F. Reimondo <aleReimondo@...> escribió: De: Alejandro F. Reimondo <aleReimondo@...> Asunto: Re: [objetos] RE: Vs GUI ??? Para: smalltalking@... Fecha: miércoles, 18 de febrero de 2009, 4:31 pm Hola kiko,   Es muy raro que el mayor tiempo se consuma en recorrerlos y en recalcularlos. ..  fijate si te es de utilidad analizar con el profiler dónde y porqué estas perdiendolo;  si efectivamente se te va en computo, te sugiero que analices minusiosamente  que cuentas estan implicadas, tratando de eliminar las conversiones (por ejemplo,  el uso de fraciones, LongIntegers intermedios, etc). Si eso tampoco elimina  del todo el tiempo, o no es satisfactorio, en ese punto, tendrás usa idea clara  de qué computo es intensivo, y tenes la alterntiva de colocar ese computo  a ser realizado con optimizaciones (como por ejm. usando OpenC u otra  librería que pueda realizar computo masivo de forma optima).   Sobre lo significativo de los "16ms"... no puedo decirte si es importante  o no reducirlos.. . fijate con el profiler. Por otro lado, siempre es bueno no dibujar cuando no es necesario :-)  e incluso, a veces, saltar cuadros de la animación.   >PD: Nadie a tenido algun problema similar > para dibujar en un GraphPane ?   jajaja todo el que hace algo con un minimo de manejo gráfico  ha tenido inconvenientes.   suerte, (dale masa) Ale.         ----- Original Message ----- From: kikoGregoris To: smalltalking@ gruposyahoo. com.ar Sent: Tuesday, February 17, 2009 10:26 AM Subject: Re: [objetos] RE: Vs GUI ??? Hola Gente   Tome el tiempo con #millisencodnsToRun : y el tiempo se va en el recalculo de los vertices, sobre todo en recorrerlos Por el contrario de lo que yo pensaba, que era en dibujar. Esto solo toma entre 0 y 16 millisegudos, para un total de 38 brush. Creo que es poco significativo este tiempo. No ?.   Lo que intento es: En vez de recorrer todas las caras de los Brush cada vez que muevo o hago zoom, me quedo con una colección vertices del  lado de ST y trabajo con ella. Con esto mejoró bastante.   El otro problema que veo es que se nota cuando se hace el #erase y queda horrible.   Alguna idea ?   saludos kiko   PD: Nadie a tenido algun problema similar para dibujar en un GraphPane ?       --- El lun 16-feb-09, kikoGregoris <kikogregoris@ yahoo.com. ar> escribió: De: kikoGregoris <kikogregoris@ yahoo.com. ar> Asunto: [objetos] RE: Vs GUI ??? Para: smalltalking@ gruposyahoo. com.ar Fecha: lunes, 16 de febrero de 2009, 9:28 am Hola Gente   Tengo un problema con la utilización de un GraphPane. El tema es que debo dibujar un Brush, por ejemplo un cuadrado y luego poder moverlo con el mouse.   Tengo definido el evento #display y un mensaje #displayWindow asociado a dicho evento.   La implementació n de #displayWindow manda a dibujar el o los brush de esta manera:   OrthoViewCompositeP ane>>displayWindow   "Callback for the #display event in OrthoViewPane [GraphPane]. (Generated by WindowBuilder Pro)"   self brushes isNil ifFalse:[ self brushes do:[:brush | brush drawOrthoViewFacesW ith: camera in: self ]].   drawOrthoViewFacesW ith: aJetEditorCamera in: aPane   "Draw all faces of the receiver in aPane with aJetEditorCamera"     self firstTime ifTrue:[ aPane graphPane pen deleteAllSegments. self allFaces do:[:face | vertexs removeAll. 0 to:(face vertexCount- 1) do:[:index | vertexs add: (aJetEditorCamera worldToView: (self worldSpaceVertexAt: index from:face) )]. aPane graphPane pen drawRetainPicture: [ aPane graphPane pen polygon: vertexs]. self firstTime: false. ]. ] ifFalse:[ aPane graphPane pen drawChain].   Tengo 2 problemas.   El primer problema es la actualización del GraphPane, luego de mover el Brush.   En este momento lo manejo asi:   OrthoViewCompositeP ane>>button1Moved: aPane   "Callback for the #button1Moved event in OrthoViewPane [GraphPane]. (Generated by WindowBuilder Pro)"     Notifier isControlKeyDown ifTrue:[   self camera updatePosition: ( aPane mouseLocation ). self graphPane erase; redraw. ].   Esto funciona OK. La pregunta es: Es el momento de hacer el update del GraphPane ?. Si solo envio #redraw dibuja sin limpiar el cuadro anterior, con lo cual queda un garabato !!.       Por otra parte el problema mas grande es la caída de la performance con geometrías grandes y complejas.   Esto se debe a que cada vez que muevo la camara, se debe recalcular los puntos de cada polígono de cada Brush que se van a dibujar y luego dibujarlos de a uno.         Nosé si se entiende bien, tratare de sintetizar el problema.   Cada vez que dibujo un Brush, debo tomar los vertices de cada cara y transformarlos desde las coordenadas locales en el mapa a las coordenadas del Screen. Luego los dibujo.   Para moverlos o hacer un zoom, solo cambio la posición de la cámara y recalculo cada polígono, luego los dibujo. Así lo hacen en C++:   void Brush_RenderOrthoFa ces( Brush *pBrush, const Ortho * pOrtho, int32 hDC, jeBoolean bDrawVertex, jeBoolean bDrawSelFaces, jeBoolean bColorOveride ) { int i, j ; jeBrush_Face * pFace ; Point points[BRUSH_ MAXPOINTSPERFACE ]; jeVec3d Vert ; int nVertices ; jeBoolean bFaceSelected ; HDC hVertexBitmap; jwePen * pPen = NULL; assert( pOrtho != NULL ) ; assert( SIGNATURE == pBrush->nSignature ) ; assert( pBrush != NULL ) ; if (!pBrush->bShow) return; // Jeff: Load vertex bitmap from resources - 8/18/2005 if( bDrawVertex ) { hVertexBitmap = CreateCompatibleDC( (HDC)hDC) ; SelectObject( hVertexBitmap, (HBITMAP)AppData_ GetVertex( )); } if( ! bColorOveride ) { if( Brush_IsCutBrush( pBrush ) ) { pPen = Pen_SelectSubtractB rushColor( hDC ) ; } else { pPen = Pen_SelectAddBrushC olor( hDC ) ; } } i = 0; pFace = Brush_GetNextFace( pBrush, NULL ) ; do { bFaceSelected = Brush_IsFaceSelecte d( pBrush, pFace ) ; if( !(bDrawSelFaces && bFaceSelected) ) { nVertices = Brush_FaceGetVertCo unt( pFace ) ; assert( nVertices < BRUSH_MAXPOINTSPERF ACE ) ; for( i=0; i<nVertices; i++ ) { Vert = Brush_FaceGetWorldS paceVertByIndex( pBrush, pFace, i ) ; Ortho_WorldToView( pOrtho, &Vert, &points[i] ) ; } points[i++] = points[0] ; // It would appear we just let GDI clip... Pen_Polyline( hDC, points, i ) ; // hDC==hDrawDC } if( bDrawVertex ) { i = Brush_FaceGetVertCo unt( pFace ) ; for( j=0; j<i; j++ ) BitBlt((HDC) hDC, points[j].X- 3, points[j].Y- 3, 6, 6, hVertexBitmap, 0, 0, SRCCOPY ); } pFace = Brush_GetNextFace( pBrush, pFace ) ; } while( pFace != NULL ) ; if( ! bColorOveride && pPen ) Pen_Release( pPen, hDC ); if( bDrawVertex ) DeleteDC(hVertexBit map ); // 2nd pass for selected faces? if( bDrawSelFaces ) { FaceIterator fI; pPen = Pen_SelectSelectedF aceColor( hDC ); pFace = FaceList_GetFirstFa ce(pBrush->pSelFaces, &fI ) ; while (pFace) { if( Brush_IsFaceSelecte d( pBrush, pFace ) ) { nVertices = Brush_FaceGetVertCo unt( pFace ) ; assert( nVertices < BRUSH_MAXPOINTSPERF ACE ) ; for( i=0; i<nVertices; i++ ) { Vert = Brush_FaceGetWorldS paceVertByIndex( pBrush, pFace, i ) ; Ortho_WorldToView( pOrtho, &Vert, &points[i] ) ; } points[i++] = points[0] ; // It would appear we just let GDI clip... Pen_Polyline( hDC, points, i ) ; // hDC==hDrawDC } pFace = FaceList_GetNextFac e( pBrush->pSelFaces, &fI ) ; }; Pen_Release( pPen, hDC ); } // Draw Sel Faces if( bDrawVertex ) { VertDrawInfo vdi ; VertList * pVerts ; // If any verts are selected, draw the verts pVerts = Brush_GetSelVert( pBrush ) ; if( VertList_GetNumVert ( pVerts ) ) { vdi.hDC = hDC ; vdi.pBrush = pBrush ; vdi.pOrtho = pOrtho ; VertList_Enum( pVerts, &vdi, Brush_DrawSelectedV ertsCB ) ; } } } // Brush_RenderOrthoFa ces   Como se ve, ellos recalculan todo cada vez que se mueve o se hace un zoom y no hay caida de performance.   El usar la capasidad del RecordingPen, me trae el problema de que no puedo mover o hacer zoom con los StorePicture guardados y por lo tanto no me queda otra que recalcular todo.   Podría quedarme con los vertices ya convertidos y trabajar con ellos, pero no me ha dado mucho resultado.   Alguna sugerencía ?   Saludos kiko Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/ Yahoo! Cocina Recetas prácticas y comida saludable Visitá http://ar.mujer. yahoo.com/ cocina/

---

Yahoo! Cocina
Recetas prácticas y comida saludable
Visitá http://ar.mujer.yahoo.com/cocina/