JMP desaparece cuando ejecuta un programa Python en JMP 18He estado intentando familiarizarme con la nueva interfaz Python en JMP 18. Una de las preguntas que estoy explorando es: "¿Es posible escribir un programa Python en el entorno JMP que ejecute módulos r? El programa muy simple que estoy usando es
# Import the necessary libraries
import numpy as np
from rpy2.robjects.packages import importr
import rpy2.robjects as ro
# Create a numpy array
data = np.array([1, 2, 3, 4, 5])
# Convert the numpy array to an R vector
r_vector = ro.FloatVector(data)
# Import the base package in R
base = importr('base')
# Calculate the mean of the vector in R
mean = base.mean(r_vector)
# Convert the mean back to a Python float
mean_py = np.array(mean)[0]
print(f"The mean of the data is {mean_py}")
Instalé el paquete RPY2 usando el JSL
Python Install Packages( "rpy2");
Se instaló sin problemas. También lo instalé en mi versión nativa 3.8 de Python y en la versión nativa de Python 3.11.
El código Python se ejecuta sin errores en Python 3.8 y en el 3.11 instalado de JMP.
Sin embargo, al ejecutar el código en Python bajo JMP 18, tan pronto como se ejecuta la línea 3, JMP desaparece inmediatamente.
from rpy2.robjects.packages import importr
¿Alguien tiene alguna idea de por qué sucede esto?
Automatización y secuencias de comandosRe: JMP desaparece al ejecutar un programa Python en JMP 18No pude instalar ese paquete usando
Python Install Packages( "rpy2");
o
import jmp
import jmputils
# update to latest version of pip and setuptools then install numpy & pandas
jmputils.jpip('install --upgrade', 'pip setuptools')
jmputils.jpip('install', 'rpy2')
y tuve que pasar por la línea de comandos. Después de instalarlo, me enfrento al mismo problema, JMP simplemente se cerrará cuando importe rpy2.robjects (la importación de rpy2 parece funcionar). ¿Quizás esto esté relacionado con algo como aquí https://github.com/jupyterlab/jupyterlab/issues/4817 ?
Re: JMP desaparece al ejecutar un programa Python en JMP 18Creo que probablemente sea parte de los problemas mencionados en el problema 4871 de jupyterlab. Específicamente, la mención en una de las respuestas.
Por defecto, rpy2 buscará la primera R que se encuentre en la RUTA. Lo que puede suceder es que la R en la RUTA no coincida con la biblioteca compartida de R seleccionada al cargarla dinámicamente.
JMP carga Python como una biblioteca compartida, por lo que cualquier ruta de carga de biblioteca compartida deberá estar en las ubicaciones que JMP espera. El Python integrado en JMP carga el módulo rpy2, y sus bibliotecas compartidas estarían en el directorio site-packages/ correspondiente. Luego, rpy2 intenta cargar las bibliotecas compartidas de R en el espacio de proceso. Si no se puede encontrar una biblioteca o no se carga debido a un conflicto, el proceso se terminará en un lugar que JMP no puede detectar. Este fue el problema que tuvimos hace mucho tiempo al intentar utilizar una instalación Conda de Python en Windows. Conda movió las ubicaciones predeterminadas y no configuró la rpath, por lo que JMP no pudo encontrar archivos Dll de los que dependía Python y salía rápidamente al intentar ejecutar cualquier cosa de Python con una instalación basada en Anaconda. Además, ninguno de los archivos Dll cargados se liberará ni se descargará hasta que JMP se cierre.
No recomiendo usar rpy2. Mi preferencia/sugerencia personal es utilizar pyRserve. El paquete pyRserve es un cliente ligero Python que se comunica con un servidor Rserve a través de TCP/IP. Hay un ejemplo en $SAMPLE_SCRIPTS/Python/Rserve.py que tiene comentarios extensos sobre la configuración y el uso.
Esto aísla los procesos mucho mejor y no está cargando R en el espacio de direcciones de Python que luego está dentro de JMP. Con Rserv, un fallo o problema dentro de R no tendrá ningún efecto en JMP. Además, su instancia de Rserv se puede ejecutar en cualquier lugar. Localmente en Windows o en macOS, dentro de WSL (Subsistema de Windows para Linux) en Windows, en una máquina remota (Linux, macOS, ...). Un servidor R remoto puede requerir soporte de administración de red adicional, como firewall y puertos permitidos. Al ejecutarse localmente, eso no debería ser un problema.
Este es uno de los peligros de permitir que se carguen archivos DLL en JMP. Ya sea desde los módulos de Python o de nuestras propias capacidades JSL de DLL de carga. Un fallo o error en la DLL cargada puede provocar un error irrecuperable y no controlado en JMP.
