Mensajes

vertex@Symphony: ¿Leiste el reglamento del foro alguna vez?

Solamente voy a hacer uso de tu última propuesta para no escribirte un libro de Unixes

P.S: Con mucho gusto podés pedir fuente para cualquier cosa que haya dicho en este mensaje ...

1 - Desde 1995, BSD no existe. ¿por qué lo incluis entre tu lista de Unix-Like como si fuera actual?
  2 - ¿De dónde sacaste que AIX, HP-UX y Solaris no usan entorno de escritorio?
  3 - ¿De dónde sacaste que yo no se lo que es Unix?
  4 - ¿De dónde sacaste que alguien le haya hecho fiesta a Gnome?

Gracias por tu enorme aporte,
Saludos

PD: https://secure.wikimedia.org/wikipedia/en/wiki/Unix

However, the term "Unix" is often used informally to denote any operating system that closely resembles the trademarked system.

Lee antes de postear

Estoy usando una union de punteros, no de structs... todos los punteros ocupan lo mismo, no hay ningun desperdicio de espacio (al menos q sean near, far etc, pero eso ya depende mucho del sistema y es raro encontrarlo en la programacion en modo usuario).
Guardo el flag, con la union de punteros pq estan asociados, estan muy relacionados... Como estan tan relacionados, los pongo en el mismo struct...

No había visto lo de los punteros. Pero no quita lo que decía, porque usar un "union" donde siempre se usará un puntero, y acceder luego a sus miembros es a fin de cuentas... un casteo. Y si vamos a hacer un casteo es mejor ser explícitos.

Por otro lado, no están más relacionados de lo que significa pasar por un mismo dispatcher, porque al final serán tratados por funciónes diferentes. Como al fin y al cabo, usas el union para "castear" el puntero contenido en ese espacio de memoria (el union)...

Código (c) [Seleccionar] Expandir

switch(p.flag){
    case f_medico:
         //lo manejo como medico
        handleMedico(m.data.m);
        break;
    case f_paciente:
         //lo manejo como paciente
        handlePaciente(m.data.p);
        break;
}
...entonces resulta más legible ir al grano con un cast. A demás, al usar esta forma tienes dos problemas a tener en cuenta:

1 - Necesitas una variable extra en la pila local de la función... solo a fin de alojar el puntero que te llega por parámetro, y para enviarlo a otra función. Es innecesario.
2 - Si declaras desde el main los datos como instancias de la union para evitar las variables locales innecesarias, pierdes la posibilidad de tener flujos donde se manejen solo pacientes, o solo médicos (en el ejemplo), sin pasar previamente por un dispatcher. Si los dispatchers son siempre necesarios, es porque tienes dos flujos separados. Seguramente perderás más de dos bytes haciendo dispatchers para cada flujo, y es la diferencia entre crear una instancia de cada tipo, y una union.

Si se desea castear un puntero, entonces se usa un cast, solo por mantener el código simple.

Saludos

Obviamente, debes conocer las diferencias de tamaños para decidir si una union es buena idea o no, y saber si realmente necesitas ese almacenamiento. En ESTA situación, cualquier uso de uniones es DISPARATADO 

¿Porqué?
Porque cuando aún no sabes si es un médico o un paciente, usas el flag para tratarlo. Entonces ¿realmente necesitas almacenar las estructuras en un espacio de memoria común? Sin importar el tipo, puedes tener dos funciónes diferentes, con lo que la función que hace de dispatcher, no tiene que hacer más que pasar el puntero a quien le corresponda... que me parece mucho más razonable  , y si quieres probar si es NULL, lo haces al principio, cosa que te quedaría como:

Código (c) [Seleccionar] Expandir

void
funcion_dispatcher(void *puntero, tipo_dispatcher flag) {
    if (!puntero)
        muere("funcion_dispatcher: puntero nulo!");

    switch (flag) {
        case esMedico:
            funcionMedico((struct medico*)puntero);
            break;
        case esPaciente:
            funcionPaciente((struct paciente*)puntero);
            break;
    }
}

O lo que me parece más visible/lindo:

Código (c) [Seleccionar] Expandir

void
funcion_dispatcher(void *puntero, tipo_dispatcher flag) {
    if (!puntero)
        muere("funcion_dispatcher: puntero nulo!");

    if (flag == esMedico)
            funcionMedico((struct medico*)puntero);

    if (flag == esPaciente)
            funcionPaciente((struct paciente*)puntero);
}

siempre leo que se habla de la 2 leo sobre "desarrollo" ...  Es poco profesional liberar algo en desarrollo en el sitio oficial, dejar a un costado el último release "estable" y dejar el QA a los usuarios ...

No se de donde leerás  No solo acerca de la primer parte sino acerca de tus inquietudes por liberar esta versión como release, esta todo entre las últimas entradas del blog:

Wednesday, April 27, 2011
emesene 2.11.4 released!

> is this the first stable release of the 2.x branch?

yes

yes, we know emesene 2.11.4 is a little rough around the edges, but we needed to make a release to reach a wider audience, get more feedback and hopefully more developers (help us!)

emesene 1 won't come back, anyone who wants to keep it alive may fork it but we encourage you to make emesene 2 as good (and better) than emesene 1, after all emesene 1.6.3 was a result of years of polishing, give emesene 2 a go and help us reach that level, I'm sure it will become better than that in the following months. Don't waste energy on two projects when we can focus on the latest version.

Por otro lado, me mencionas esto, que de verdad no entiendo:

No entiendo qué tiene que ver que sea para KDE, este entorno está disponible para cualquier plataforma que me llega a la cabeza ... ¿me perdí de algo ?

Bueno, el hecho no es si KDE está o no disponible, sino que, como KDE no sea la plataforma de escritorio POR DEFECTO para Unix, un messenger para KDE no será el messenger por defecto para Unix. Que es precisamente lo que dije cuando mencioné que:

KMess es para KDE, por eso no perfila para ser el messenger por defecto para Unix.

Y no, no me vengas con que emesene necesita Gnome porque cualquiera tiene GTK instalado nomás por correr GIMP. Precisamente el motivo por el que aMSN era tan grosso en Unix (todos, incluido MAC), era que estaba en TCL/TK. Ningún sistema Unix, sea con Gnome, KDE, fluxbox, o enlightenment puede decir que no corre TCL/TK, y eso era un golazo para aMSN. Pero tampoco hay lo que digamos muchos entornos de escritorio Unix sin GIMP, y por ende, GTK está por todos lados, por eso emesene viene robando tanto.

Y volviendo a la disponibilidad de KDE. Vamos a ser serios. KDE3 era el cielo, KDE4 apesta.

tené en cuenta que el mensajero never, ever, ever lo cierro, y la compu rara vez se apaga

Estás casi como yo, con la excepción de que nunca tuve problemas.

está plagadísimo de bugs

Sin contar las versiónes anteriores, que por algo están abandonadas. La versión 2 está siendo probada, y el autor recluta gente para probar y codificar. Curiosamente habla español así que podrías contactarlo y hacer un bien a todos 

particularmente en un par de plugins

Bueno, los plugins se corrigen por separado 


Finalmente, al principio

En mi experiencia me encontré con que le falta, pero milenios

Seguramente menos milenios que a aMSN 
KMess es para KDE, por eso no perfila para ser el messenger por defecto para Unix. aMSN lleva muchos años de tregua. Los users de Linux, BSDs y MAC esperamos por algo que avance, y es una iniciativa que emesene ha tomado.

No tengo más novedades de las que puedas leer en el blog de emesene = P

Saludos

En vista de tu código, supongo que estás aprendiendo C y no tienes del todo afianzados los conocimientos técnicos del lenguaje. Por eso, permíteme hacerte algunos comentarios que te pueden favorecer el aprendizaje.

Primer Punto: No debería ser un WHILE sino un FOR, puesto que sabes exáctamente cuántos lugares recorrer.

Segundo: En estos casos, mientras uses C, te convendría ser más explícito en la aritmética de punteros, y quizá menos en la lógica. Yo prefiero ese estilo de codificación porque es más explícito en lo que se está haciendo a nivel memoria. Me refiero a que si tu código es más técnico, lo comprenderás mejor. Cuando conozcas lo suficiente, elegirás cuál es tu manera de codificar favorita.

No he probado porque estoy en el trabajo, pero esto es lo que haría yo:

1 - SIEMPRE pasar el puntero, así sabemos exáctamente con qué trabajamos:

Código (c) [Seleccionar] Expandir

int almacenaContacto(struct contactos *f)

2 - Usar la aritmética de punteros. Cada suma de una unidad para un puntero es un desplazamiento equivalente a su tamaño. Es totalmente claro hacer algo así:

Código (c) [Seleccionar] Expandir

int almacenaContacto(struct contactos *f){
    int i;
    struct contactos *punt = f;
    /* punt contiene la misma direccion, por
     * lo tanto es equivalente, pero como es
     * local a la funcion, podemos moverlo
     */
    for(i=0; i<LIMITE; i++) {
        /* en cada vuelta tienes una llamada simple
         */
        leerContacto(punt);
        /* se mueve una vez el tamanno de
         * la estructura
         */
        punt++;
    }
}

Respecto a la notación que LittleHorse te indicaba, lo reescribiría de esta forma:

Código (c) [Seleccionar] Expandir

void probar(struct contacto f[]) {
    int i;
    for(i=0; i<3; i++){
        escribir(&f[i]);
    }
}


Y por favor, no utilices:

Código (c) [Seleccionar] Expandir

i=i+1

Esto no es PASCAL, aquí existe el operador de incremento:

Código (c) [Seleccionar] Expandir

i++


Saludos

Bueno, se puede hacer que acepten una notación algebráica común para las jugadas. Así solo requieren transferir texto, y se pueden guardar las partidas con lujo de detalles.

Y también usa emesene. aMSN no ha avanzado en años, mientras que emesene con su ultima versión se perfila para el messenger por defecto en Unix.

bash también. Mac es un BSD en su núcleo, así que usa herramientas de Unix.

Primero:
¿Son las mismas llamadas? Obviamente el crypter usara llamadas al sistema, aunque pocas (si es bueno, sino tendrás que codificar uno mejor)

Segundo:
Hay otra manera, que seria:

a) Abrir las bibliotecas con funciones del linker (no se si en Windows tendrán lo mismo, pero en Unix hay "dlopen", "dlsym", "dlclose"), y obtener los símbolos. En el caso sería con dlsym, que recibe como parámetro el nombre del símbolo.
b) Guardas los nombres de los simbolos cifrados como te guste (es ASCII) y los usas en una funcion cargar_simbolo_encriptado, el que los descifra, y luego los busca y carga.

El resultado sería que tu programa solo llamaría realmente a las funciones del linker, todo lo demas serían pedazos codificados y sin sentido. Tomarian sentido a la hora de cargarse.