Debian : ficheros temporales mejor en RAM o en disco ?

En este link podeis leer un interesante artículo resumiendo el hilo de debate que comenzó Sergue acerca de si es buena idea meter el directorio /tmp ( directorio para albergar los ficheros temporales en un sistema Unix/Linux ) en memoria. Para la nueva versión de Debian: Wheezy 7.0 se está valorando si sería recomendable montar /tmp en un sistema de ficheros tmpfs. No todo el mundo está conforme y ha creado una rama de debate bastante interesante.

El resumen es que hay gente que defiende que meter /tmp en tmpfs aumenta la velocidad del sistema ya que no hay accesos al disco para ficheros temporales. Parace que el ejemplo de Solaris que lo lleva haciendo desde hace mucho tiempo ha estado muy presente en el debate. En un entorno ideal en el que el sistema sólo use ficheros pequeños es ideal, pero si usamos un sistema en el que los ficheros temporales sean de gran tamaño, como cuando se descomprime un fichero .iso o ficheros temporales de streamming unidos junto con un uso de memoria de elevando, provocaría que el sistema tenga que usar swap para proporcionar memoria emulada al tmpfs y ofrecer espacio suficiente a /tmp.

En general es una lectura bastante interesante y recomendable:

Temporary files: RAM or disk?

javascript checker standalone spidermonkey + jslint

Construyendo nuestra caja de herramientas nos encontramos con que necesitamos una herramienta de linea de comandos que nos chequee la sintaxis de los ficheros javascript antes de subirlo a subversion. He encontrado jslint que según sus propios autores es una herramienta para calidad el código javascript y efectivamente eso es, sólo que a nosotors sólo nos interesa el chequeo de la sintaxis.

En la documentación que he encontrado hay varios blogs en los que hablan de usar rhino que es un interprete de javascript de la fundación mozilla y funciona con java ( clooooooonk ) y por otro lado y mi opción preferida es spidermonkey de la fundación mozilla también pero sin usar java con lo que la velocidad de procesamiento evidentemente aumenta.

Actualmente existen dos problemas, uno que la versión de jslint no soporta el modo stand-alone por lo que Andy hizo unas pequeñas modificaciones y las publicó aquí http://whereisandy.com/code/jslint/.

Existe un segundo problema que es, que spidermonkey al parecer no soporta la gestión de ficheros, por que según leo, el standard ECMAScript no especifica ningúna librería standard de I/O. También estan las jslibs pero no están en el repositorio de linux con lo que no me interesa andar compilando teniendo ya una alternativa como spidermonkey

El tal Andy, ha hecho este bloque de código :
[shell](function(a) {

    var input=””;
    var line=””;
    var blankcount=”0″;
    while (blankcount < 10){
        line=readline();

        if (line==””)
            blankcount++;
        else
            blankcount=0;
        if (line==”END”) break;
        input += line;
        input += “\n”;
    }
    input = input.substring(0, input.length-blankcount);

    if (!input) {
        print(“No input!”);
        quit(1);
    }
    if (!JSLINT(input, {
        rhino: true,
        passfail: false
    })) {
        for (var i = 0; i < JSLINT.errors.length; i += 1) {
            var e = JSLINT.errors[i];
            if (e) {
                print(‘Lint at line ‘ + (e.line + 1) + ‘ character ‘ + (e.character + 1) + ‘: ‘ + e.reason);
                print((e.evidence || ”).replace(/^\s*(\S*(\s+\S+)*)\s*$/, “$1″));
                print(”);
            }
        }
    } else {
        print(“jslint: No problems found.”);
        quit();
    }
})(arguments);[/shell]
Lo que consigue es capturar el código con la funcion readline() hasta que encuentra una linea con END o diez líneas vacías.

 

De forma que si yo tengo este script tonto llamado dummy.js :
[shell]function stupid(x) {
  y = x

  if(y == 0){
    return 5
    }
}

print(‘Hello World’ + stupid(0) );[/shell]
Lo ejecutaría así:
[shell]cat dummy.js | js jslint.sh[/shell]
El problema es que en mi caso se ejecuta y se queda ahí muerto hasta que falla con el error:
[shell]jslint:4246: InternalError: allocation size overflow[/shell]
El problema es que no está detectando las lineas vacías como ‘\n’ sino como ‘null’ lo que nos lleva a mi pequeña modificación para que funcione el script :
[shell](function(a) {

    var input=””;
    var line=””;
    var blankcount=”0″;
    while (blankcount < 10){
        line=readline();

        if (line==”” || line==null ){             blankcount++;     }
        else
            blankcount=0;
        if (line==”END”) break;

        if ( line!=null)         input += line;
        input += “\n”;
    }
    input = input.substring(0, input.length-blankcount);

    if (!input) {
        print(“No input!”);
        quit(1);
    }
    if (!JSLINT(input, {
        rhino: true,
        passfail: false
    })) {
        for (var i = 0; i < JSLINT.errors.length; i += 1) {
            var e = JSLINT.errors[i];
            if (e) {
                print(‘Lint at line ‘ + (e.line + 1) + ‘ character ‘ + (e.character + 1) + ‘: ‘ + e.reason);
                print((e.evidence || ”).replace(/^\s*(\S*(\s+\S+)*)\s*$/, “$1″));
                print(”);
            }
        }
    } else {
        print(“jslint: No problems found.”);
        quit();
    }
})(arguments);[/shell]
y si ahora lo ejecutamos ya lo chequea correctamente:
[shell]cat dummy.js | js jslint.sh[/shell]
[shell]Lint at line 2 character 7: Line breaking error ‘x’.
y = x

Lint at line 2 character 8: Missing semicolon.
y = x

Lint at line 4 character 8: Use ‘===’ to compare with ‘0’.
if(y == 0){

Lint at line 5 character 13: Missing semicolon.
return 5[/shell]
Como nota indicar que se cogen 10 lineas en blanco como fin del fichero ya que con el metodo readline() no tenemos forma de sabe dónde está el final del fichero.

 

Espero que os sea de utilidad. Descargar jslint

 

prestashop upgrade to 1.4x Coremanager fails with ‘unknown method ‘clear_compiled_tpl’

Estoy haciendo pruebas de actualización de una tienda de prestashop de 1.3 a 1.4.
Funciona todo bien menos esta parte que pertenece al módulo coremanager :

Fatal error: Uncaught exception ‘SmartyException’ with message ‘unknown method ‘clearcompiledtpl’

[shell]Fatal error: Uncaught exception ‘SmartyException’ with message ‘unknown method ‘clear_compiled_tpl” in /home/jorge/Proyectos/prestashop/tools/smarty/sysplugins/smarty_internal_wrapper.php:117
Stack trace:
#0 /home/jorge/Proyectos/prestashop/tools/smarty/Smarty.class.php(766): Smarty_Internal_Wrapper->convert(‘clear_compiled_…’, Array)
#1 /home/jorge/Proyectos/prestashop/modules/coremanager/coremanager.php(42): Smarty->__call(‘clear_compiled_…’, Array)
#2 /home/jorge/Proyectos/prestashop/modules/coremanager/coremanager.php(42): Smarty->clear_compiled_tpl()
#3 /home/jorge/Proyectos/prestashop/classes/Module.php(595): CoreManager->CoreManager()
#4 /home/jorge/Proyectos/prestashop/admin-dev/tabs/AdminModules.php(526): ModuleCore::getModulesOnDisk(true)
#5 /home/jorge/Proyectos/prestashop/admin-dev/tabs/AdminModules.php(371): AdminModules->displayList()
#6 /home/jorge/Proyectos/prestashop/admin-dev/index in /home/jorge/Proyectos/prestashop/tools/smarty/sysplugins/smarty_internal_wrapper.php on line 117
[/shell]

Llevo un rato dándole vueltas, se puede solucionar, cambiando la configuración de la tienda y marcando :’ ‘. Esto lo soluciona temporalmente, pero como no me quedé tranquilo, estuve revisando de dónde sale este módulo y resulta que no es de prestashop si no, de una empresa de terceros… así que fuera modulo 😀

coremanager es un plugin de la empresa http://filtersearchpro.co.uk/en/