librelist archives

Re: [erlar] [Newbie] [wxErlang] Request for comments :-)

From:

Mariano Guerra

Date:

2011-04-13 @ 19:40

2011/4/13 Ale <peralta.alejandro@gmail.com>:
> Hola Erlanguistas,
>
> Estoy trabajando en un pequeño proyecto para aprender Erlang. Es un
> cliente de IRC con una GUI en wxErlang. (Inicialmente comenzó como un
> robot, pero bueno...) Quiero esconder el protocol de IRC detrás de una
> instancia de un behaviour de gen_event.
>
> He notado que el fuerte de Erlang está en otro lado, más de backend
> que de front end, pero no se me ocurrió otra cosa para hacer en el
> momento, además quería jugar con wxErlang. Me gusta mucho como
> lograron abstraer la creación de objetos (como las ventanas, dialogs,
> y demás).
>
> El código: https://github.com/alep/Ditto
>
> Tengo 4 modulos:
>
> - conn.erl: Esconde la lógica de conexión y el socket. Al crear una
> conexión se le pasa al proceso que maneja la conexión una función que
> se llama cuando reciben datos.
> - ircmsg.erl: Conjunto de funciones para parsear los mensajes de IRC,
> por ejemplo para buscar el prefijo, comando y argumentos de una linea
> como la siguiente ":Wiz!@some.host.net PRIVMSG #erlang : hello world!"
> (prefix = Wiz!@some.host.net, command=PRIVMSG, arguments = ["#erlang",
> "hello world"]
> - dittoui.erl: wxErlang GUI, interfaz de usuario muy simple y
> incompleta. Luego de ir a File -> Connect y pasandole host, puerto,
> nick y usuario (ejemplo:  chat.freenode.net, 6667, thewizardoferl,
> JonErlanguista), crea un socket (y un proceso que lo controla con
> conn:open(...))  luego inicia gen_event, y por ultimo lo notifica de
> los siguientes eventos {pass ...}, {nick "thewizardoferl"} and {user
> "JonErlanguista"}.
> - ircclient.erl: gen_event behaviour que intenta esconder el protocolo
> de IRC. Tiene 4 estados disconnected, nick, user, connected
>
> Quizás me pueden dar algunas criticas o comentarios sobre lo que hice,
> para saber si tiro todo o voy en buen camino.
>
> Erlang es divertido,

no soy ningun guru de erlang, pero mire el codigo y esta muy bien :D
una cosa que puedo acotar.

como erlang no tiene paquetes, es costumbre tener un prefijo comun
para todos los modulos de tu aplicacion, por ejemplo podria ser dito

dit_ui, dito_irc, dito_irccli, dito_conn

o quizas separarlo en dirc_* para todo lo relacionado con el protocolo
y dito_ para el frontend, eso queda a decision de cada uno :D

tambien suele ser costumbre usar una estructura de directorio comun
para proyectos erlang

podes usar rebar[1] si te pinta

$ mkdir dito
$ cd dito
$ wget http://bitbucket.org/basho/rebar/downloads/rebar; chmod u+x rebar
$ ./rebar create-app appid=dito
$ ./rebar compile
$ tree
.
├── ebin
│   ├── dito.app
│   ├── dito_app.beam
│   └── dito_sup.beam
├── rebar
└── src
    ├── dito.app.src
    ├── dito_app.erl
    └── dito_sup.erl

esto no tiene mucho que ver con el codigo pero por ahi es util

vi que como state usas una lista y usas keysearch, suele ser comun
usar un record (no necesario), si usas una lista podes pegarle una
mirada a proplists

http://www.erlang.org/doc/man/proplists.html

de wx no se nada asi que no puedo aportar :D

usas mucho -import, personalmente no los uso pero gustos son gustos ;)

esto:

get_conn(State) ->
    Key = conn,
    get_elem_or_error(Key, State).

get_ui(State) ->
    Key = ui,
    get_elem_or_error(Key, State).

pod ahi podria ser

get(conn=Key, State) -> get_element_or_error(Key, State);
get(ui=Key, State) -> get_element_or_error(Key, State).

pero es cuestion de gustos, pasa que me gusta mucho el pattern matching :P

por ahi vi algunos ifs sin considerar todas las posibilidades, si eso
no matchea es un error, se que let it crash es el paradigma de erlang,
pero si sabes que hacer en el caso del else por ahi esta bueno
hacerlo, o al menos tirar un error mas descriptivo (de nuevo son
gustos :P)

eso es todo lo que se me ocurrio

saludos!

[1] https://bitbucket.org/basho/rebar/wiki/Home1

Mariano,

> no soy ningun guru de erlang, pero mire el codigo y esta muy bien :D
> una cosa que puedo acotar.

Muchas gracias por darle una mirada al código, se aprecia. Es difícil
ponerse aprender solo y el feedback ayuda a motivar.

> como erlang no tiene paquetes, es costumbre tener un prefijo comun
> para todos los modulos de tu aplicacion, por ejemplo podria ser dito
[snip]

Lo de rebar lo quería hacer, muchas gracias por la explicación viene bien.

>
> vi que como state usas una lista y usas keysearch, suele ser comun
> usar un record (no necesario), si usas una lista podes pegarle una
> mirada a proplists
>
> http://www.erlang.org/doc/man/proplists.html

Lo voy a ver.


> usas mucho -import, personalmente no los uso pero gustos son gustos ;)
>

No entendí muy bien, si no usas import que haces?

> get(conn=Key, State) -> get_element_or_error(Key, State);
> get(ui=Key, State) -> get_element_or_error(Key, State).

Está bueno lo voy a cambiar.

De nuevo muchas gracias, apenas pueda voy a incorporar tus sugerencias
al código.

Y no está demás decir que el que quiera contribuir código, es más que
bien venido!

Saludos,
-- 
Ale.

2011/4/13 Ale <peralta.alejandro@gmail.com>:
>> usas mucho -import, personalmente no los uso pero gustos son gustos ;)
>>
>
> No entendí muy bien, si no usas import que haces?
>

El -import hay que usarlo a cuentagotas. Hacer -import(module,
[function/0]) te permite llamar a function() directamente en lugar de
tener que poner module:function(), pero 1- leyendo el code no queda
claro a primera vista en qué modulo está definida y 2- al leer
function() uno puede pensar que es una llamada resuelta a tiempo de
compilación (no dinámica), sin embargo el function() al estar
importado se resuelve a tiempo de ejecución igual que al hacer
module:function(), lo que da lugar a confusiones.

Saludos,
Nahuel Greco.

Otra cosa importante y que diferencia a import de las llamadas completas
tipo módulo:función
es que si tu sistema corre ininterrumpidamente y haces una actualización de
algún módulo en caliente,
mediante el import seguirá llamando a la antigua función que cargó en su
momento, y mediante la
llamada completa llamará a la última versión.

Es algo a tener cuenta.

Saludos.

El 14 de abril de 2011 04:30, Nahuel Greco <ngreco@gmail.com> escribió:

> 2011/4/13 Ale <peralta.alejandro@gmail.com>:
> >> usas mucho -import, personalmente no los uso pero gustos son gustos ;)
> >>
> >
> > No entendí muy bien, si no usas import que haces?
> >
>
> El -import hay que usarlo a cuentagotas. Hacer -import(module,
> [function/0]) te permite llamar a function() directamente en lugar de
> tener que poner module:function(), pero 1- leyendo el code no queda
> claro a primera vista en qué modulo está definida y 2- al leer
> function() uno puede pensar que es una llamada resuelta a tiempo de
> compilación (no dinámica), sin embargo el function() al estar
> importado se resuelve a tiempo de ejecución igual que al hacer
> module:function(), lo que da lugar a confusiones.
>
> Saludos,
> Nahuel Greco.
>

Hola Jorge, Nahuel

Muchas gracias por sus explicaciones, las voy a tener en cuenta!

Saludos,
-- 
Ale.

Creo que no ha quedado claro, esto ocurre sólo cuando llamas a funciones
definidas dentro del mismo módulo, cuando llamas a otro módulo siempre
cogerá la última versión.

Saludos.
El 14 de abril de 2011 07:26, Jorge Sanchez <flowcont@gmail.com> escribió:

> Otra cosa importante y que diferencia a import de las llamadas completas
> tipo módulo:función
> es que si tu sistema corre ininterrumpidamente y haces una actualización de
> algún módulo en caliente,
> mediante el import seguirá llamando a la antigua función que cargó en su
> momento, y mediante la
> llamada completa llamará a la última versión.
>
> Es algo a tener cuenta.
>
> Saludos.
>
>