[Cuis] Paquetes en Cuis

> Hola Juan y demás gente de SqueakRos (llueve y refrescó!!):
>
> Estoy probando algunos esquemas de persistencia simples que sirven para muchas aplicaciones que no tienen que guardar gran volumen de datos, como dice Ramón Leon, hay una gran cantidad de app tipo oficina (que de otra manera se resuelven con documentos u hojas de cálculo) para lo cual no hacen falta grandes bases de datos.
>
> Pense en hacer algún driver para alguna embebida por ejemplo tipo Berkeley pero me gustó más esto todo Smalltalk. El tema es que tengo que seguir ensuciando el Cuis.....digo, tengo que portar cosas que en cuis no están tipo los UUID's por ejemplo.
>
> Eso no pasa nada no? Digo, mientras lo deje a nivel de paquetes no jode en nada creo.
>
> La duda que me surge es como coordinar después la instalación de todo lo necesario para que funcione cada cosa y, además, como hacer con los paquetes que se repiten, es decir que se necesitan en más de uno de los demás. Para todo eso se hizo Monticello/Metacello (versiones, prereq, etc).
>
> ¿Pensás que algo así puede llegar a ser necesario en Cuis? ¿Tenés alguna idea al respecto? (A mi lo primero que se me ocurre es hacer algunos scripts simples que hagan la carga secuencial de lo que se necesita).
>
> Saludos y gracias!
>
> --
> ============================================
> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
> Arduino Software  http://www.arduinosoftware.com
> PasswordsPro  http://www.passwordspro.com
> greensecure.blogspot.com germanarduino.blogspot.com
> ============================================
>

> Hola Juan y demás gente de SqueakRos (llueve y refrescó!!):
>
> Estoy probando algunos esquemas de persistencia simples que sirven para muchas
> aplicaciones que no tienen que guardar gran volumen de datos, como dice Ramón
> Leon, hay una gran cantidad de app tipo oficina (que de otra manera se
> resuelven con documentos u hojas de cálculo) para lo cual no hacen falta
> grandes bases de datos.
>
> Pense en hacer algún driver para alguna embebida por ejemplo tipo Berkeley
> pero me gustó más esto todo Smalltalk. El tema es que tengo que seguir
> ensuciando el Cuis.....digo, tengo que portar cosas que en cuis no están tipo
> los UUID's por ejemplo.
>
> Eso no pasa nada no? Digo, mientras lo deje a nivel de paquetes no jode en
> nada creo.
>
> La duda que me surge es como coordinar después la instalación de todo lo
> necesario para que funcione cada cosa y, además, como hacer con los paquetes
> que se repiten, es decir que se necesitan en más de uno de los demás. Para
> todo eso se hizo Monticello/Metacello (versiones, prereq, etc).
>
> ¿Pensás que algo así puede llegar a ser necesario en Cuis? ¿Tenés alguna idea
> al respecto? (A mi lo primero que se me ocurre es hacer algunos scripts
> simples que hagan la carga secuencial de lo que se necesita).
>
> Saludos y gracias!

> **
>
>
> > Hola Juan y demás gente de SqueakRos (llueve y refrescó!!):
> >
> > Estoy probando algunos esquemas de persistencia simples que sirven para
> muchas
> > aplicaciones que no tienen que guardar gran volumen de datos, como dice
> Ramón
> > Leon, hay una gran cantidad de app tipo oficina (que de otra manera se
> > resuelven con documentos u hojas de cálculo) para lo cual no hacen falta
> > grandes bases de datos.
> >
> > Pense en hacer algún driver para alguna embebida por ejemplo tipo
> Berkeley
> > pero me gustó más esto todo Smalltalk. El tema es que tengo que seguir
> > ensuciando el Cuis.....digo, tengo que portar cosas que en cuis no están
> tipo
> > los UUID's por ejemplo.
> >
> > Eso no pasa nada no? Digo, mientras lo deje a nivel de paquetes no jode
> en
> > nada creo.
> >
> > La duda que me surge es como coordinar después la instalación de todo lo
> > necesario para que funcione cada cosa y, además, como hacer con los
> paquetes
> > que se repiten, es decir que se necesitan en más de uno de los demás.
> Para
> > todo eso se hizo Monticello/Metacello (versiones, prereq, etc).
> >
> > ¿Pensás que algo así puede llegar a ser necesario en Cuis? ¿Tenés alguna
> idea
> > al respecto? (A mi lo primero que se me ocurre es hacer algunos scripts
> > simples que hagan la carga secuencial de lo que se necesita).
> >
> > Saludos y gracias!
>
> No se si te sirve, pero comparto mi experiencia con Cuis.
> Antes que nada, no tengo ninguna duda que la implementacion de Juan es
> superior, pero lamentablemente incompatible con Squeak / Pharo.
>
> No creo que puedas cargar nada sin muuuuuuuuchoooo esfuerzo.
>
> Mi ultima derivacion minima limpia esta ahi en el servidor, junto con la de
> SqueakRos4dot 4
>
> Hoy quise incluir el DependencyBrowser de Squeak que hizo Andreas Raab
>
> Ahi te vas a enterar que te hacen falta StringHolder y CodeHolder ( si no
> lo
> tendras que re escribir)
>
> Cuando incorpores esas dos clases, te va a quedar la siguiente lista
> haciendo
>
> Undeclared removeUnreferencedKeys; inspect.
>
> #BorderedSubpaneDividerMorph
> #BrowserRequestor
> #ChangesOrganizer
> #CompiledM
> ethodTrailer
> #LayoutFrame
> #MorphicTextEditor
> #PluggableTextMorph
> #Project
> #S
> malltalkImage
> #SyntaxMorph
> #TextRequestor
> #ToolBuilder
> #UIManager
> #WindowCol
> orSpec
>
> Como hoy esta fresquito, viendo las referencias intentare limpiar.
>
> Y queda el tema de la implementación de String en Cuis , que no se puede
> cambiar
>
> Edgar
>
>  
>

> **
>
>
> Hola Germán,
>
> Quoting Germán Arduino <[hidden email]>:
>
>    Hola Juan y demás gente de SqueakRos (llueve y refrescó!!):
>
> Estoy probando algunos esquemas de persistencia simples que sirven para
> muchas aplicaciones que no tienen que guardar gran volumen de datos, como
> dice Ramón Leon, hay una gran cantidad de app tipo oficina (que de otra
> manera se resuelven con documentos u hojas de cálculo) para lo cual no
> hacen falta grandes bases de datos.
>
>
> Buenísimo!
>
>
>
> Pense en hacer algún driver para alguna embebida por ejemplo tipo Berkeley
> pero me gustó más esto todo Smalltalk. El tema es que tengo que seguir
> ensuciando el Cuis.....digo, tengo que portar cosas que en cuis no están
> tipo los UUID's por ejemplo.
>
> Eso no pasa nada no? Digo, mientras lo deje a nivel de paquetes no jode en
> nada creo.
>
>
> Seguro. Después vamos viendo si parte de esas cosas es mejor integrar en
> Cuis o no... No hay nada escrito en piedra.
>
>
>     La duda que me surge es como coordinar después la instalación de todo
> lo necesario para que funcione cada cosa y, además, como hacer con los
> paquetes que se repiten, es decir que se necesitan en más de uno de los
> demás. Para todo eso se hizo Monticello/Metacello (versiones, prereq, etc).
>
> ¿Pensás que algo así puede llegar a ser necesario en Cuis? ¿Tenés alguna
> idea al respecto? (A mi lo primero que se me ocurre es hacer algunos
> scripts simples que hagan la carga secuencial de lo que se necesita).
>
>
> Los paquetes de Cuis (por ahora) no manejan prerequisitos. Tampoco
> versiones. Pero hay que pensar, e ir viendo. Me parece que agregar un
> número de versión a cada paquete no estaría mal. Se podría hacer que cada
> vez que salvás un paquete se actualice automáticamente. El problema sería
> que si dos personas bajan el mismo paquete y hacen cambios distintos, y
> graban, habría dos versiones con igual número y distinto contenido... Mi
> idea es que el manejo de paquetes se lleve lo mejor posible con Git /
> GitHub. Alguien sabe cómo se suele hacer esto con sistemas basados en
> archivos de texto? O sea, en GitHub, usualmente, la gente que usa C,
> Phyton, lo que sea, le suele poner número de versión a los archivos? O usan
> exclusivamente los ids de versiones de Git? Si lo usual es esto último,
> entonces la dependencia de paquetes de Cuis debería usar ésto también. Pero
> no es parte de los archivos, así que no veo cómo se podría validar al
> cargar paquetes...
>
> Ideas, discusión, correcciones, se agradecen!
>
>  Cheers,
> Juan Vuletich
>
>  
>

> Hola gente!
>
> Algo puedo aportar sobre Git/GitHub (no tanto sobre bajar un archivo de Git (digamos cuis.zip), sino sobre las versiones del codigo que esta en un repo Git)
>
>
> Git tiene el concepto de branch y de tag
>
>
> Un branch es una rama de desarrollo, por ejemplo master, la mas comun, la "actual", y por otro lado podria tener "dev" ver por ejemplo
> https://github.com/hugoruscitti/pilas/branches 
>
>
> un engine de juegos en Python.
>
>
> Pero creo que lo que importa para esta discusion, es que cada branch (p.ej., en general el master) tiene tag, que es un simple string, por ejemplo v0.0.1
> ver:
> https://github.com/hugoruscitti/pilas/tags 
>
>
> El que nos lo muestre como .zip, es una facilidad de GitHub (no creo que de Git). Para Git, es un punto, un mojon, en el branch X (en este ejemplo de arriba, en el branch master)
>
>
> No hay DOS personas que pongan el mismo tag. Lo que hay es
>
>
> - Una o varias personas tienen acceso al repo principal
> - Una persona cualquier puede forkear el repo principal (fork es una utilidad de GitHub, sino en Git puro yo tendria que clonearme el repo original,  luego manejarlo localmente, y probablemente guardarlo en un proyecto de una cuenta mia en alguna parte, sin tener acceso de escritura al repo original)
> - Esa persona nueva, cambia lo que quiera en su repo, clonado del original
> - Luego hace un pull request al repo original, donde alguien acepta o no el cambio
>
>
> https://help.github.com/articles/using-pull-requests 
>
>
> Otra variante: el nuevo contributor hace fork del repo original. Y crea un branch ahi por cada nueva idea/fix/feature. Y hace pull request por cada uno de esos branch, al repo original. Esto pasa cuando el contributor tiene varias cosas para arreglar o fixear, o sugerir mejoras.
>
>
> Para los strings de tags, se puede usar cualquier cosa. Pero muchos usan Semantic Versioning
> http://semver.org/ 
>
>
> Se entendio?
>
>
> Comentarios, correcciones?
>
>
> Nos leemos!
>
>
> Angel "Java" Lopez
> @ajlopez
> gh:ajlopez

> 2012/11/23 Juan Vuletich (mail lists) <[hidden email]>
>
>
> > Hola Germán,
> >
> > Quoting Germán Arduino <[hidden email]>:
> >
> > > Hola Juan y demás gente de SqueakRos (llueve y refrescó!!):
> > >
> > > Estoy probando algunos esquemas de persistencia simples que sirven para muchas aplicaciones que no tienen que guardar gran volumen de datos, como dice Ramón Leon, hay una gran cantidad de app tipo oficina (que de otra manera se resuelven con documentos u hojas de cálculo) para lo cual no hacen falta grandes bases de datos.
> >
> > Buenísimo!
> >
> > > Pense en hacer algún driver para alguna embebida por ejemplo tipo Berkeley pero me gustó más esto todo Smalltalk. El tema es que tengo que seguir ensuciando el Cuis.....digo, tengo que portar cosas que en cuis no están tipo los UUID's por ejemplo.
> > >
> > > Eso no pasa nada no? Digo, mientras lo deje a nivel de paquetes no jode en nada creo.
> >
> > Seguro. Después vamos viendo si parte de esas cosas es mejor integrar en Cuis o no... No hay nada escrito en piedra.
> >
> > > La duda que me surge es como coordinar después la instalación de todo lo necesario para que funcione cada cosa y, además, como hacer con los paquetes que se repiten, es decir que se necesitan en más de uno de los demás. Para todo eso se hizo Monticello/Metacello (versiones, prereq, etc).
> > >
> > > ¿Pensás que algo así puede llegar a ser necesario en Cuis? ¿Tenés alguna idea al respecto? (A mi lo primero que se me ocurre es hacer algunos scripts simples que hagan la carga secuencial de lo que se necesita).
> >
> > Los paquetes de Cuis (por ahora) no manejan prerequisitos. Tampoco versiones. Pero hay que pensar, e ir viendo. Me parece que agregar un número de versión a cada paquete no estaría mal. Se podría hacer que cada vez que salvás un paquete se actualice automáticamente. El problema sería que si dos personas bajan el mismo paquete y hacen cambios distintos, y graban, habría dos versiones con igual número y distinto contenido... Mi idea es que el manejo de paquetes se lleve lo mejor posible con Git / GitHub. Alguien sabe cómo se suele hacer esto con sistemas basados en archivos de texto? O sea, en GitHub, usualmente, la gente que usa C, Phyton, lo que sea, le suele poner número de versión a los archivos? O usan exclusivamente los ids de versiones de Git? Si lo usual es esto último, entonces la dependencia de paquetes de Cuis debería usar ésto también. Pero no es parte de los archivos, así que no veo cómo se podría validar al cargar paquetes...
> >
> > Ideas, discusión, correcciones, se agradecen!
> >
> >
> > >
> >
> > Cheers,
> > Juan Vuletich

> Hola Angel,
>
> Quoting Angel Java Lopez <[hidden email]>:
>
>    Hola gente!
>
> Algo puedo aportar sobre Git/GitHub (no tanto sobre bajar un archivo de
> Git (digamos cuis.zip), sino sobre las versiones del codigo que esta en un
> repo Git)
>
> Git tiene el concepto de branch y de tag
>
> Un branch es una rama de desarrollo, por ejemplo master, la mas comun, la
> "actual", y por otro lado podria tener "dev" ver por ejemplo
> https://github.com/hugoruscitti/pilas/branches
>
> un engine de juegos en Python.
>
> Pero creo que lo que importa para esta discusion, es que cada branch
> (p.ej., en general el master) tiene tag, que es un simple string, por
> ejemplo v0.0.1
> ver:
> https://github.com/hugoruscitti/pilas/tags
>
> El que nos lo muestre como .zip, es una facilidad de GitHub (no creo que
> de Git). Para Git, es un punto, un mojon, en el branch X (en este ejemplo
> de arriba, en el branch master)
>
> No hay DOS personas que pongan el mismo tag. Lo que hay es
>
> - Una o varias personas tienen acceso al repo principal
> - Una persona cualquier puede forkear el repo principal (fork es una
> utilidad de GitHub, sino en Git puro yo tendria que clonearme el repo
> original,  luego manejarlo localmente, y probablemente guardarlo en un
> proyecto de una cuenta mia en alguna parte, sin tener acceso de escritura
> al repo original)
> - Esa persona nueva, cambia lo que quiera en su repo, clonado del original
> - Luego hace un pull request al repo original, donde alguien acepta o no
> el cambio
>
> https://help.github.com/articles/using-pull-requests
>
> Otra variante: el nuevo contributor hace fork del repo original. Y crea un
> branch ahi por cada nueva idea/fix/feature. Y hace pull request por cada
> uno de esos branch, al repo original. Esto pasa cuando el contributor tiene
> varias cosas para arreglar o fixear, o sugerir mejoras.
>
> Para los strings de tags, se puede usar cualquier cosa. Pero muchos usan
> Semantic Versioning
> http://semver.org/
>
> Se entendio?
>
> Comentarios, correcciones?
>
> Nos leemos!
>
> Angel "Java" Lopez
> @ajlopez
> gh:ajlopez
>
>
>   Está bien, pero la pregunta que hago es cómo hacer que Cuis pueda
> validar la versión del paquete. Cuando se crea un nuevo tag en Git, eso no
> forma parte de ninguno de los archivos que estás commiteando. Yo quiero
> dejar el manejo de versiones en Git (no quiero hacer lo que hace
> Monticello). Así que el problema es que Cuis no tiene acceso al tag, y no
> puede validar dependencias.
>
> Cómo se maneja ésto en un ambiente convencional (basado en files)? Se deja
> la validación de versiones de las dependencias en manos del programador?
>
>     2012/11/23 Juan Vuletich (mail lists) <[hidden email]>
>
>> **
>>
>>
>>
>> Hola Germán,
>>
>> Quoting Germán Arduino <[hidden email]>:
>>
>>    Hola Juan y demás gente de SqueakRos (llueve y refrescó!!):
>>
>> Estoy probando algunos esquemas de persistencia simples que sirven para
>> muchas aplicaciones que no tienen que guardar gran volumen de datos, como
>> dice Ramón Leon, hay una gran cantidad de app tipo oficina (que de otra
>> manera se resuelven con documentos u hojas de cálculo) para lo cual no
>> hacen falta grandes bases de datos.
>>
>>
>> Buenísimo!
>>
>>
>>
>> Pense en hacer algún driver para alguna embebida por ejemplo tipo
>> Berkeley pero me gustó más esto todo Smalltalk. El tema es que tengo que
>> seguir ensuciando el Cuis.....digo, tengo que portar cosas que en cuis no
>> están tipo los UUID's por ejemplo.
>>
>> Eso no pasa nada no? Digo, mientras lo deje a nivel de paquetes no jode
>> en nada creo.
>>
>>
>> Seguro. Después vamos viendo si parte de esas cosas es mejor integrar en
>> Cuis o no... No hay nada escrito en piedra.
>>
>>
>>     La duda que me surge es como coordinar después la instalación de
>> todo lo necesario para que funcione cada cosa y, además, como hacer con los
>> paquetes que se repiten, es decir que se necesitan en más de uno de los
>> demás. Para todo eso se hizo Monticello/Metacello (versiones, prereq, etc).
>>
>> ¿Pensás que algo así puede llegar a ser necesario en Cuis? ¿Tenés alguna
>> idea al respecto? (A mi lo primero que se me ocurre es hacer algunos
>> scripts simples que hagan la carga secuencial de lo que se necesita).
>>
>>
>> Los paquetes de Cuis (por ahora) no manejan prerequisitos. Tampoco
>> versiones. Pero hay que pensar, e ir viendo. Me parece que agregar un
>> número de versión a cada paquete no estaría mal. Se podría hacer que cada
>> vez que salvás un paquete se actualice automáticamente. El problema sería
>> que si dos personas bajan el mismo paquete y hacen cambios distintos, y
>> graban, habría dos versiones con igual número y distinto contenido... Mi
>> idea es que el manejo de paquetes se lleve lo mejor posible con Git /
>> GitHub. Alguien sabe cómo se suele hacer esto con sistemas basados en
>> archivos de texto? O sea, en GitHub, usualmente, la gente que usa C,
>> Phyton, lo que sea, le suele poner número de versión a los archivos? O usan
>> exclusivamente los ids de versiones de Git? Si lo usual es esto último,
>> entonces la dependencia de paquetes de Cuis debería usar ésto también. Pero
>> no es parte de los archivos, así que no veo cómo se podría validar al
>> cargar paquetes...
>>
>> Ideas, discusión, correcciones, se agradecen!
>>
>>  Cheers,
>> Juan Vuletich
>>
>>
>>
>
>     Cheers,
> Juan Vuletich
>

> Hola gente!
>
>
> Ah, Juan... voy entendiendo... A ver, por lo que vi, el validar un paquete (llamemos a esto un conjunto de archivos que me baje de Git, puede ser todo el repo, o un directorio donde esta el paquete que quiero), se deja en manos del manejador de paquetes que se use. Por ejemplo, en Node.js/Javascript se usa npm, y este pide que haya un package.json que describa el paquete que me acabo de bajar. Ahi ve la version y tambien ahi ve las dependencias que tenga. Un ejemplo mio:
>
>
> https://github.com/ajlopez/SimpleRemote/blob/master/package.json 
>
>
> Un ejemplo mio en un tag v0.0.1:
> https://github.com/ajlopez/SimpleMessages/blob/v0.0.1/package.json 
>
>
> Un ejemplo de nuget (manejador de paquetes de .NET):
>
> <?xml version="1.0"?>
> <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
>   <metadata>
>     <id>jQuery</id>
>     <version>1.8.2</version>
>     <title>jQuery</title>
>     <authors>John Resig</authors>
>     <owners>John Resig</owners>
>     <licenseUrl>http://jquery.org/license</licenseUrl>
>     <projectUrl>http://jquery.com/</projectUrl>
>     <requireLicenseAcceptance>false</requireLicenseAcceptance>
>     <description>jQuery is a new kind of JavaScript Library.
>         jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.</description>
>     <summary>jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development.</summary>
>     <language>en-US</language>
>     <tags>jQuery</tags>
>   </metadata>
> </package>  
>
>
> y asi. El de arriba, es de jQuery.1.8.2. El autor preparo este archivo, para cuando empaqueto la libreria PARA NUGET. Para otros manejadores, seguramente habra armado otros archivos.
>
>
> Espero haber entendido tu pregunta. En resumen:
>
>
> - Hay un archivo en lo que uno se baja, que describe la version y las dependencias que tiene
> - El formato de ese archivo depende del manejador de paquetes

> 2012/11/23 Juan Vuletich (mail lists) <[hidden email]>
>
>
> > Hola Angel,
> >
> > Quoting Angel Java Lopez <[hidden email]>:
> >
> > > Hola gente!
> > >
> > > Algo puedo aportar sobre Git/GitHub (no tanto sobre bajar un archivo de Git (digamos cuis.zip), sino sobre las versiones del codigo que esta en un repo Git)
> > >
> > >
> > > Git tiene el concepto de branch y de tag
> > >
> > >
> > > Un branch es una rama de desarrollo, por ejemplo master, la mas comun, la "actual", y por otro lado podria tener "dev" ver por ejemplo
> > > https://github.com/hugoruscitti/pilas/branches 
> > >
> > >
> > > un engine de juegos en Python.
> > >
> > >
> > > Pero creo que lo que importa para esta discusion, es que cada branch (p.ej., en general el master) tiene tag, que es un simple string, por ejemplo v0.0.1
> > > ver:
> > > https://github.com/hugoruscitti/pilas/tags 
> > >
> > >
> > > El que nos lo muestre como .zip, es una facilidad de GitHub (no creo que de Git). Para Git, es un punto, un mojon, en el branch X (en este ejemplo de arriba, en el branch master)
> > >
> > >
> > > No hay DOS personas que pongan el mismo tag. Lo que hay es
> > >
> > >
> > > - Una o varias personas tienen acceso al repo principal
> > > - Una persona cualquier puede forkear el repo principal (fork es una utilidad de GitHub, sino en Git puro yo tendria que clonearme el repo original,  luego manejarlo localmente, y probablemente guardarlo en un proyecto de una cuenta mia en alguna parte, sin tener acceso de escritura al repo original)
> > > - Esa persona nueva, cambia lo que quiera en su repo, clonado del original
> > > - Luego hace un pull request al repo original, donde alguien acepta o no el cambio
> > >
> > >
> > > https://help.github.com/articles/using-pull-requests 
> > >
> > >
> > > Otra variante: el nuevo contributor hace fork del repo original. Y crea un branch ahi por cada nueva idea/fix/feature. Y hace pull request por cada uno de esos branch, al repo original. Esto pasa cuando el contributor tiene varias cosas para arreglar o fixear, o sugerir mejoras.
> > >
> > >
> > > Para los strings de tags, se puede usar cualquier cosa. Pero muchos usan Semantic Versioning
> > > http://semver.org/ 
> > >
> > >
> > > Se entendio?
> > >
> > >
> > > Comentarios, correcciones?
> > >
> > >
> > > Nos leemos!
> > >
> > >
> > > Angel "Java" Lopez
> > > @ajlopez
> > > gh:ajlopez
> >
> > Está bien, pero la pregunta que hago es cómo hacer que Cuis pueda validar la versión del paquete. Cuando se crea un nuevo tag en Git, eso no forma parte de ninguno de los archivos que estás commiteando. Yo quiero dejar el manejo de versiones en Git (no quiero hacer lo que hace Monticello). Así que el problema es que Cuis no tiene acceso al tag, y no puede validar dependencias.
> >
> > Cómo se maneja ésto en un ambiente convencional (basado en files)? Se deja la validación de versiones de las dependencias en manos del programador?
> >
> > > 2012/11/23 Juan Vuletich (mail lists) <[hidden email]>
> > >
> > >
> > > > Hola Germán,
> > > >
> > > > Quoting Germán Arduino <[hidden email]>:
> > > >
> > > > > Hola Juan y demás gente de SqueakRos (llueve y refrescó!!):
> > > > >
> > > > > Estoy probando algunos esquemas de persistencia simples que sirven para muchas aplicaciones que no tienen que guardar gran volumen de datos, como dice Ramón Leon, hay una gran cantidad de app tipo oficina (que de otra manera se resuelven con documentos u hojas de cálculo) para lo cual no hacen falta grandes bases de datos.
> > > >
> > > > Buenísimo!
> > > >
> > > > > Pense en hacer algún driver para alguna embebida por ejemplo tipo Berkeley pero me gustó más esto todo Smalltalk. El tema es que tengo que seguir ensuciando el Cuis.....digo, tengo que portar cosas que en cuis no están tipo los UUID's por ejemplo.
> > > > >
> > > > > Eso no pasa nada no? Digo, mientras lo deje a nivel de paquetes no jode en nada creo.
> > > >
> > > > Seguro. Después vamos viendo si parte de esas cosas es mejor integrar en Cuis o no... No hay nada escrito en piedra.
> > > >
> > > > > La duda que me surge es como coordinar después la instalación de todo lo necesario para que funcione cada cosa y, además, como hacer con los paquetes que se repiten, es decir que se necesitan en más de uno de los demás. Para todo eso se hizo Monticello/Metacello (versiones, prereq, etc).
> > > > >
> > > > > ¿Pensás que algo así puede llegar a ser necesario en Cuis? ¿Tenés alguna idea al respecto? (A mi lo primero que se me ocurre es hacer algunos scripts simples que hagan la carga secuencial de lo que se necesita).
> > > >
> > > > Los paquetes de Cuis (por ahora) no manejan prerequisitos. Tampoco versiones. Pero hay que pensar, e ir viendo. Me parece que agregar un número de versión a cada paquete no estaría mal. Se podría hacer que cada vez que salvás un paquete se actualice automáticamente. El problema sería que si dos personas bajan el mismo paquete y hacen cambios distintos, y graban, habría dos versiones con igual número y distinto contenido... Mi idea es que el manejo de paquetes se lleve lo mejor posible con Git / GitHub. Alguien sabe cómo se suele hacer esto con sistemas basados en archivos de texto? O sea, en GitHub, usualmente, la gente que usa C, Phyton, lo que sea, le suele poner número de versión a los archivos? O usan exclusivamente los ids de versiones de Git? Si lo usual es esto último, entonces la dependencia de paquetes de Cuis debería usar ésto también. Pero no es parte de los archivos, así que no veo cómo se podría validar al cargar paquetes...
> > > >
> > > > Ideas, discusión, correcciones, se agradecen!
> > > >
> > > >
> > > > >
> > > >
> > > > Cheers,
> > > > Juan Vuletich
> >
> > Cheers,
> > Juan Vuletich
>
>