Mostrando entradas con la etiqueta referencia. Mostrar todas las entradas
Mostrando entradas con la etiqueta referencia. Mostrar todas las entradas

8 de julio de 2013

FTP desde batch en windows

Supongamos que el archivo file.txt, se quiere bajar desde el servidor ftp://direccion_ftp.com

Para eso se puede guardar una lista de los comandos ftp necesarios en un archivo, por ejemplo:

creamos cmd.ftp conteniendo
open direccion_ftp.com
userFtp
passFtp
get file.txt
quit
Obviamente reemplazando la dirección, usuario, password y archivo por los que correspondan.
(Notar que la URL se escribe directamente, sin especificar el protocolo ftp)

Ahora creamos un archivo .bat para ejecutar esos comandos desde el cliente ftp, por ejemplo :

creamos download.bat conteniendo
ftp -s:cmd.ftp
Listo, probar!
C:\path>download.bat
Salida

C:\path>ftp -s:cmd.ftp
ftp> open direccion_ftp.com
Conectado a direccion_ftp.com.
220 "Bienvenido al servidor de FTP"
Usuario (direccion_ftp.com:(none)):
331 Please specify the password.

230 Login successful.
ftp> get file.txt
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for file.txt (1024 bytes).
226 Transfer complete.
ftp: 1024 bytes recibidos en 0,02 segundos 77,31 a KB/s.
ftp> quit
221 Goodbye.

Cuidado: el archvo cmd.ftp va a contener usuario y password del ftp, y lo podría ver cualquiera, cosa que no suele ser buena idea.



10 de noviembre de 2012

git init

Git es un conocido Sistema de Control de Revisiones Distribuido (DRCS) que permite hacer seguimiento de cambios a los archivos de un proyecto, facilitando además el trabajo en equipo.

Estas son notas preliminares para iniciarse en la terminología git , un panorama para facilitar el camino al que recién se inicia.

Para ejecutar los comandos citados de ejemplo se debe tener git instalado.


Conceptos Básicos

  • Repositorio (alias 'repo')
    Lugar donde se almacena el registro de los cambios en archivos, ¿Todos los cambios? no, sólo se registrarán las modificaciones que ocurrieron entre comandos commit, git almacena todo este registro en una carpeta llamada .git
    Para crear un repositorio local se hace con el comando
    git init
    en la misma carpeta que están los archivos que queremos hacer seguimiento.
    Durante el desarrollo y las pruebas se suele trabajar con esos respositorios locales, que están en la misma carpeta de cada proyecto, pero usualmente hay también algún respositorio remoto para mantener las revisiones en un servidor, lo cual es muy útil para trabajar en equipo y tener backup, ahí se suben los cambios y se puede mantener actualizada la copia local con la del server.

    Todo esto requiere alguna metodología de trabajo para evitar perder datos, por ejemplo sobreescribir el trabajo de otro, tomar una revisión vieja por error, etc.

  • Working Directory / Working Tree
    Es la carpeta donde están todos los archivos de nuestro proyecto. Respecto a git ve básicamente dos tipos de archivos: los que figuran en el repo y se les hace un seguimiento de cambios (tracked) y los que no (untracked) que no se registran. De todas formas esto es dinámico, además hay una instancia intermedia antes de estar registrados en el repo pasan por la "Index/Staging Area".

  • The Index/The Staging Area
    Se refiere a la lista de archivos cuyos cambios se registrarán en el repo durante el próximo commit (independientemente de si previamente figuraban o no en el repo) por ejemplo el comando
    git add archivo.txt
    agrega el archivo.txt a la "Staging Area" es decir lo deja 'preparado', y con el comando
    git commit
    se registra en el repo, ya sea su primer registro o almacenando una nueva revisión de sus cambios.
    git add .  (agrega al Index los archivos en carpeta, modificados y nuevos, sin actualizar los borrados)
    git add -u . (agrega al Index modificados y actualiza borrados, sin agregar los nuevos)
    git add --all . ( agrega todos los cambios al Index, es decir ambas anteriores)
    

  • Commit
    Este es el comando (y concepto) de registrar en el repositorio local la revisión actual de los archivos que estén preparados, es decir, los que están en el Index/Staging Area.
    Para saber qué cambios hubo en la carpeta de trabajo desde el último commit, puede usarse
    git status
    esto informa de los cambios, no sólo en los archivos tracked(que ya figuraban en el repo y tenemos un registro, o de los que estén en el Index listos para commit), sino que justamente nos avisa si por ejemplo aparecieron archivos nuevos en el Working Tree cuyos cambios no están siendo seguidos, para que nos demos cuenta de agregarlos si es necesario.
    Cada commit debe incluir un mensaje que indique el motivo del mismo, por ejemplo "reparado tal problema", "agregada tal función", etc.. además este mensaje queda almacenado en el commit junto al nombre de quien lo hizo. Para listar la historia de commits se usa
    git log
    (y para ver sólo el último commit se puede usar git log -1 ). El nombre de "autor" para los commits se puede especificar globalmente, así no tenemos que escribirlo cada vez en nuestra computadora
    git config --global user.name  "nombre"
    git config --global user.email "nombre@mail.com"
    
    También puede abrirse el archivo de configuración con el editor por defecto
    git config --global --edit
  • y editarlo directamente
    [user]
             name=nombre
             email=nombre@mail.com

  • Staging
    Es la acción de agregar archivos al Index/Staging Area, en otros sistemas la palabra commit suele significar "guardar las diferencias de todos los archivos seguidos" pero en git está la opción/obligación de agregar primero los archivos al Index antes de hacer commit, esto permite commits separados y diferentes para un mismo conjunto de archivos, por ejemplo si se hicieron un par de cambios que no tienen nada que ver entre sí en diferentes archivos, y no se desea hacer un commit general, se pueden hacer varios commit independientes por archivo (e incluso para partes de un mismo archivo).
    Al momento de almacenar los cambios git commit a secas no actualiza todos los archivos del repo, sino sólo los que están en el Index, por lo tanto antes de un commit se deben agregar, por ejemplo, git commit archivo, y si se quieren registrar los cambios de todos los archivos que figuran en el repo, se puede usar el comando git commit -a que primero agrega al Index todos los archivos que ya figuraban en el repositorio (tracked) y después hace el commit. Finalmente si se agregan nuevos archivos al proyecto, y se los desea incluir en el commit, no alcanza con hacer commit -a ya que los que nunca estuvieron en el repositorio se deben agregar mediante add.

  • Branch
    En un proyecto suele haber varias ramas de trabajo, se suelen hacer muchas revisiones hasta que queda funcionando(o alguna parte) de una manera más o menos "estable", en esos momentos se libera una Versión, la cual no debe mezclarse con otras revisiones que se puedan ir haciendo ya sea para agregar funciones, reparar errores, probar nuevas características, etc.. cada una de estas posibles ramificaciones de revisiones sucesivas se llama branch, usualmente hay una rama principal a la que se llama master, que es la que contiene sólo las versiones liberadas "estables" y ninguna revisión en la que se estan haciendo cambios "inestable" (pero todo esto ya depende de la metodología de trabajo adoptada)
    Para crear una rama de trabajo, por ejemplo llamada "ramaTrabajo", se usan los comandos:
    git branch ramaTrabajo
    git checkout ramaTrabajo
    El primer comando crea el nuevo branch, el segundo lo selecciona. Seleccionar el branch con checkout no es una simple cuestión de nombres, detrás cambia todo, por ejemplo si hicimos modificaciones y commits en la ramaTrabajo, y luego volvemos al branch master, todos los archivos cambian al modo que estaban en master, esto permite cambiar el marco de trabajo sin mezclar revisiones. Si intencionalmente deseo mezclar las revisiones lo voy a hacer a través de git de una forma ordenada, por ejemplo si hay un branch "fix" hecho para corregir un problema, cuando ya está listo para ser parte del master puedo escribir.
    git merge fix

  • HEAD
    Es una forma de referir el branch actual, con el que se está trabajando, cuando se hace un commit por defecto se guardan las diferencias respecto a la anterior revisión que corresponda a ese branch.
    Por ejemplo el HEAD de un repositorio local podría apuntar a un branch llamado "develop", mientras el HEAD de otro repositorio podría apuntar a un branch llamado "bug_fix", etc..
    Para ver donde está apuntando el branch actual basta ver el contenido del archivo HEAD, esto se puede hacer, estando en la carpeta de trabajo.

    En Linux:
    cat .git/HEAD
    En Windows:
    type .git\HEAD

  • origin
    Es la forma de referir al repo del servidor remoto desde el cual se actualizado el repo local (pull) o hacia el cual se guardan los cambios (push).
    git remote add origin direccion_web_del_repo
    Ejemplo:
    git remote add origin https://github.com/nombreUsuario/proyecto.git

  • SHA1
    Esto está relacionado a git sólo de manera indirecta, SHA (Secure Hash Algorithm) es la forma que usa git para calcular una "firma" del archivo, identificarlo y detectar así si hubo modificaciones

  • Para finalizar diagrama simplificado de estos conceptos (fuente:Wikipedia)



26 de junio de 2012

Python primera prensada


En cualquier orden, esta es una primera impresión

Voy a tomar como referencia el lenguaje C por conocerlo, pero no es una comparativa. Dejando de lado que usualmente Python se ejecuta bajo un intérprete, lo primero que me llamó la atención es que las funciones en lugar de definirse entre llaves {}, requieren indentación, (sí, requieren ), supongo esto es para que la legibilidad del código no quede del todo librada al programador y sea parte de la sintaxis, otro detalle inmediato es que no se usa punto y coma al final de las líneas, y que los comentarios de código se escriben anteponiendo #. Aunque incompatibles con C, son lindas cosas, hasta ahí particularidades que no aportan mayor ventaja, veamos algo más, un hola mundo.

Hello World
  • En C
    // Comentario
     int main(void)  
     {  
         printf("hola mundo" );  
         return 0;  
     }   
    
  • En Python
    # Comentario  
    print ("hola mundo") 
    
En ese ejemplo Python luce más simple, pero para ser justos debería compararse con un hola mundo definido en una función main, que esto revelar más detalles del lenguaje, y hecho así ya no parece simple.

Python main
  • #Definiendo main como función
    def main():
        print ('hola mundo')      #1
    if __name__ == '__main__':    #2
        main() 
    
    #1: Notar la indentación (viene a ser equivalente a las llaves de C)
    #2: Aquí el hecho de no tener indentación da por terminada la def anterior
Repetir Strings
  • #Aprovecho a mencionar una singular forma de repetir strings
    print("hola mundo " * 5)
    
    hola mundo hola mundo hola mundo hola mundo hola mundo
Dicho sea de paso, estos ejemplos son para Python 3.x, aclaro esto porque a partir de la versión 3.x print usa paréntesis, es una función, por lo tanto el "hola mundo" de la versión 2.x (sin paréntesis) tan simple que parece, es incompatible.

Python 2.x
  • print "hola mundo"
Python 3.x
  • print ("hola mundo")

Esto evidentemente puede ocacionar problemas con código 'viejo', pero como salvedad digamos que "no es tan importante de donde viene, sino adonde va", y creo que es una mejora uniformizar el llamado a funciones.
Otra cosa, para poder usar ciertos caracteres (por ejemplo tildes) en los comentarios se debe aclarar primero la codificación que se va a usar en el archivo, por ejemplo:
  • #coding: latin-1

Entorno de Desarrollo Integrado (IDE)

Por suerte conseguir una IDE funcional fue relativamente rápido: pyDev.org  (basada en eclipse  que además tiene una versión stand-alone Aptana  y por lo visto funcionan ok).
Hay también un plugin para Netbeans para los que nos gusta esa IDE.

List Comprehension

Esto me gusta, al menos es algo útil, varios lenguajes traen esta característica o alguna similar, las "listas por comprensión" son una forma de procesar y generar listas. A la lista se ingresan, filtran y extraen datos de una forma directa, especificando el qué y sin los detalles de cómo.
Esto podría pensarse en términos más generales como el avance de la abstracción en los lenguajes, (pensemos que hay microcontroladores que ni siquiera tienen una instrucción de multiplicar, y las multiplicaciones se hacen mediante desplazamientos de bits y/o sumas sucesivas), pero todo eso es invisible para el lenguaje, y es solucionado por el compilador, por lo tanto en ese caso básico ya se puede ver cómo un "algoritmo oculto" (lenguaje abstracto) resuelve el cómo especificando sólamente el qué.
Como siempre toda abstracción exige que se pierdan ciertos detalles, y el control sobre esos detalles, y aunque esto aparentemente limita ciertas posibilidades a bajo nivel permitite facilitar otras de mayor nivel que en definitiva son más complejas y tienen un mayor alcance.
Aquí algunos ejemplos que se explican a sí mismos con los resultados
  • #Imprime el elemento 3 
    #Va a imprimir la D (ya que empieza en indice=0 tal como los array de C)
    
    lista = ['A', 'B', 'C', 'D', 'E']
    print( lista[3] )
    
    D
  • #coding: latin-1
    #Ahora vamos a usar 'comprehension' para extraer datos
    #Se obtienen, modifican e imprimen todos los elementos de la lista
    #multiplicando cada valor por 2
    #Observar que la palabra elemento sólo se usa para referenciar el item
    #puede usarse cualquier nombre de variable
    #(abajo está la misma operación mediante for (sin comprehension) )
    listaNumeros = [100, 200, 300, 400, 500] 
    listaCompre= [2*elemento for elemento in listaNumeros]
    print(listaCompre)
    
    listaClasic = []
    for valor in listaNumeros:
        listaClasic.append(2*valor)
        
    print(listaClasic)
    
    [200, 400, 600, 800, 1000]
  • #coding: latin-1
    #Hacemos un poco más complejo el comprehension agregando unos if's
    #Para modificar y seleccionar algunos items de la lista
    #(Notar que la condición la chequea antes de hacer la operación)
    listaNumeros = [1, 2, 3, 4, 5] 
    listaSelecta =[10*valor for valor in listaNumeros if valor>=3]
    print(listaSelecta)
    
    listaDos=['hola', 'cómo', 'va']
    listaFiltrada = [valor for valor in listaDos if valor!='hola']
    print(listaFiltrada)
    
    [30, 40, 50]
    ['cómo', 'va']
Suficiente para una primera impresión

18 de mayo de 2012

Configuration Words en PIC18F26J50


Las Flash Configuration Words (FCW) son cuatro (de 16 bits cada una), y están almacenadas al final de la memoria FLASH de programa, ocupando las últimas 8 direcciones de la FLASH (hay dos direcciones asignadas para cada Configuration Word). Si el micro tiene 64Kbytes de FLASH (desde la dirección 0x0000 hasta 0xFFFF) entonces las Configuration Words van a ocupar desde la dirección 0xFFF8 hasta la 0xFFFF.
En RESET estas Words se copian automáticamente en RAM, en registros para configuración, mapeados desde la dirección 0x300000 hasta la 0x300007, se los puede leer pero no escribir, incluso son esos (los de RAM) los valores que usa el micro para su configuración (si los valores en FLASH fueran cambiados en Runtime por ejemplo en una self-write, ese cambio no tendría efecto hasta que no suceda un RESET y la consiguiente copia en RAM)
  • CONFIG1 0x300000 CONFIG1L 0x300001 CONFIG1H
  • CONFIG2 0x300002 CONFIG2L 0x300003 CONFIG2H
  • CONFIG3 0x300004 CONFIG3L 0x300005 CONFIG3H
  • CONFIG4 0x300006 CONFIG4L 0x300007 CONFIG4H

El seteo de FCW conviene que figure en el source del proyecto para que contenga la configuración de acuerdo a su hardware y no sea necesario almacenar esa información aparte.

Para especificar esta información de configuración en el source se utilizan directivas que son diferentes (según el compilador)

    Para el C18 luce de esta manera
       #pragma config CPUDIV = NOCLKDIV
       #pragma config USBDIV = OFF
       #pragma config FOSC = HS
       #pragma config PLLEN = ON
       ...

    Para el CCS es algo así
    (No me gusta este compilador porque se sale mucho del estándar de C, pero es una opinión personal)
       #FUSES NOWDT  
       #FUSES WDT128 
       #FUSES HS  
       #FUSES NODEBUG 
       ...

    Para el HI-TECH PICC18 se parece a esto
    __CONFIG(1, DEBUG_OFF & XINST_OFF & STVREN_ON & PLLDIV_1 );
    __CONFIG(2, IESO_OFF & FCMEN_OFF & LPT1OSC_ON );
    __CONFIG(3, DSWDTPS_8192 & DSWDTEN_OFF & DSBOREN_OFF);
    __CONFIG(4, WPDIS_OFF);

¿Dónde encuentro los nombres de esas constantes?
 
En el compilador HI-TECH los valores de la constantes están en :

C:\Archivos de programa\HI-TECH Software\PICC-18\9.80\docs\18f26j50.html

(para windows en español y versión 9.80)

Se usan con la directiva

#pragma config

(Que es compatible con C18 pero también con la nueva versión de HI-TECH)

Esto es porque Microchip compró la empresa HI-TECH, los compiladores HI-TECH y C18 se fusionaron en un nuevo compilador llamado XC. Por lo que vi de momento el "nuevo" compilador no es más que el HI-TECH con compatibilidad agregada para C18, para nuevos proyectos (hoy 2012) aconsejan usar HI-TECH, ya que los XC van a ser backward compatibles con ese compilador.


11 de agosto de 2011

\r\nHerencia de máquinas de escribir mecánicas

Hasta en los formatos de texto más simples* aunque no tengan colores y chiches, es necesario poder codificar no sólo letras, símbolos y números visibles, también necesita codificar una mínima cantidad de cosas invisibles que son parte del formato, metadatos, que por ejemplo corresponden al espaciado y saltos de línea, lo que permite dar claridad al texto. Por otro lado en las comunicaciones usuario-máquina, si son mediante comandos (también minimalistas) tienen metadatos por ejemplo para permitir borrar caracteres, mover el cursor, o para avisar al otro lado de la red cuando se presiona ENTER mediante algún contrato, es otro hecho indispensable.

*(formatos simples, en el sentido de minimizar los pasos necesarios en el procesamiento de los datos por software al momento de alistarlos para la lectura humana del texto como tal)

Obviamente hay complejos formatos y protocolos de alto nivel, comprimidos, no comprimidos, encriptados, human-readable o no, etc.. muchísimos para elegir, HTML, JSON y XML podrían ser ejemplos, y pueden listarse miles, pero aún debajo de algunos de ellos suelen seguir subsistiendo aquellos simples y viejos códigos de metadatos, cuyos nombres se remontan en el tiempo hasta las máquinas de escribir mecánicas y quien sabe cuanto tiempo más van a estar entre nosotros!

Este post está dedicado al dúo Retorno de Carro y Salto de Línea (CRLF) o ("\r\n")
  • Retorno de carro (CR, carriage return).
    Es '\r' en  lenguaje C, es 0x0D (13 en decimal) en ASCII
    Retorna al comienzo de la hoja (izquierda) el "carro mecánico" o el cursor
  • Saltar a siguiente linea (LF, line feed).
    Es '\n' en  lenguaje C, es 0x0A (10 en decimal) en ASCII
    "Alimentar" Linea, o sea alimentar la máquina de escribir con una línea más de papel
    o "bajar" a la linea siguiente en una pantalla.
El mismo símbolo de la tecla ENTER ya nos recuerda ese significado de dos acciones (bajar y volver al comienzo)


El uso depende de la plataforma, por ejemplo:

En Linux se utiliza simplificado sólo el LF, o sea '\n', sólo el 0x0A (el 10) de ASCII
 
En Windows normalmente se utiliza CRLF (consola y archivos) es decir la conjunción  "\r\n"

Aunque esta información está repetida en muchos lugares por internet (como ven incluso está repetida en este mismo texto), el objetivo era hacer una nota para mi mismo, y tener un lugar confiable de donde leerlo, aprovechando que los verifiqué personalmente, los anoto con redundancia para recordarlos.