Proyecto CloudLang

[Irwin Rodriguez]

Saludos comunidad,

Estoy creando un pequeño servicio llamado CloudLang y su función es hacer de librería en la nube para tareas comunes como validaciones de formatos (DNI, Cédula, etc), envío de emails, analizadores de texto con o sin formato (JSON, YAML, TOML, XML, etc).

En fin, todo lo que vaya necesitando lo iré publicando y de manera agnóstica para que cada quien pueda usarla según su localidad.

De momento solo he creado un transpilador JSON a Visual FoxPro, para los que no lo conozcan, un transpilador es un tipo de compilador que en lugar de generar código de bajo nivel (generalmente ensamblador o lenguaje máquina), genera un código de alto nivel y equivalente en el lenguaje objetivo, en nuestro caso Visual FoxPro.

Lo he creado porque tengo una pantalla de auditoría de datos que ataca una bitácora que contiene cientos de miles de registros en formato JSON que analizo con JSONFox y convierto a cursor (no todos a la vez pero si bajo demanda).

La solución funciona pero no estoy del todo contento así que la puse a pruebas contra el transpilador de cloudlang y la diferencia es ridícula de verdad, un JSON de poco más de 17 mil líneas lo pude convertir a objeto fox equivalente en tan solo 2 segundos y medio, comparado con JSONFox que me tardaba 6 minutos. 

Todo está en desarrollo alfa así que solo los invito a probarla, no la usen en entornos de producción porque puedo cambiar cosas sin previo aviso.

Los que quieran probar solo tienen que descargar o clonar este PRG: https://github.com/Irwin1985/cloudlang

El uso de las 2 únicas funciones disponibles está aquí: https://github.com/Irwin1985/cloudlang/blob/main/README.md

El servicio está alojado en Heroku con el plan gratuito.

El transpilador JSON todavía necesita varios ajustes para llegar al mismo nivel de análisis que JSONFox pero de momento funciona para todos los tipos.

Saludos y espero les sea de utilidad.

[Octavio Rodriguez]

Excelente Irwin!

--
Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CABooBBmCWcdpXrMYqOO1CD7WRahG1PZTfQn6eFrmebvFUHFZPw%40mail.gmail.com.

[Carton Jeston]

Para ya un poco Irwin, tardas menos en desarrollar un proyecto que yo en asimilar para que sirve :-)

[Marco Plaza]

Hola Irwin... muy buena idea.. yo estuve también con ganas de usar Phyton pero el tiempo no da...

Probando tu servicio examiné la respuesta y veo que usas un key/value .. así que ya lo tienes casi listo para 

 usar una colección.. !  así se facilita recorrer el objeto y muchas cosas mas.. 

puedes probar cambiar el parser para que el constructor quede algo así como esto:

<vfp>

PUBLIC beatle1

beatle1 = respuesta()

? 'beatle1:'
? 'name',beatle1('name')
? 'last name',beatle1('last_name')
? 'dob',beatle1('dob')
? 'songs:'

for each song in beatle1('songs').items

? '-',m.song

endfor

* o:
? ':',beatle1('songs').items(1)
? ':', beatle1('songs').items(2)
? ':', beatle1('songs').items(3)

***************************************************************************

FUNCTION respuesta()

***************************************************************************

* respuesta del servicio cloudlib  de  Irwin Rodriguez 

* ( https://github.com/Irwin1985/cloudlang/blob/main/cloudlib.prg )

* modificada para retornar una colección

***************************************************************************

* Global Regular Expression object.
If Type('_SCREEN.oRegEx') != 'U'
    =Removeproperty(_Screen, 'oRegEx')
Endif
=AddProperty(_Screen, 'oRegEx', Createobject("VBScript.RegExp"))
_Screen.oRegEx.Global = .T.

*--- modificación sugerida: -------------*

    local mainObject as collection
    mainObject = CreateObject('collection')
       
    mainObject.Add( checkString("John"),"name")
    mainobject.Add( checkString("Lennon"),"last_name")
    mainObject.Add( checkString("1940-10-09 Liverpool"),"dob")
   
    ob1 = CREATEOBJECT('empty')
    addproperty(ob1,'items(1)',null)
    mainObject.Add( m.ob1,"songs")
   
    DIMENSION ob1.items(1)
    ob1.items(1) = checkString("Bless you")

    DIMENSION ob1.items(2)
    ob1.items(2) = checkString("My Life")
   
    DIMENSION ob1.items(3)
    ob1.items(3) = checkString("Stand by Me")

*---- fin modificación    
       
return mainObject
* ================================================= *
* Helper function
* ================================================= *
function addKeyValuePair(obj, entry, key, value)
    local loKeyValuePair as Object
    loKeyValuePair = CreateObject('Empty')
    =AddProperty(loKeyValuePair, 'key', key)
    =AddProperty(loKeyValuePair, 'value', value)
    * Bind loKeyValuePair to target object.
    =AddProperty(obj, entry, loKeyValuePair)        
endfunc
* ================================================= *
* Function FormatDate
* return a valid date or datetime date type.
* ================================================= *
function formatDate as variant
    lparameters tcDate as string, tlUseDMY as Boolean
    local lDate
    lDate = .null.
    do case
    case 'T' $ tcDate && JavaScript or ISO 8601 format.
        do case
        case '+' $ tcDate
            tcDate = getwordnum(tcDate, 1, '+')
        case at('-', tcDate, 3) > 0
            tcDate = substr(tcDate, 1, at('-', tcDate, 3)-1)
        otherwise
        endcase
        try
            setDateAct = set('Date')
            set date ymd
            lDate = ctot('^'+tcDate)
        catch
            lDate = {//::}
        finally
            set date &setDateAct
        endtry
    case occurs(':', tcDate) >= 2 && VFP Date Time Format. 'YYYY-mm-dd HH:mm:ss'
        try
            setDateAct = set('Date')
            set date ymd
            lDate = ctot(tcDate)
        catch
            lDate = {//::}
        finally
            set date &setDateAct
        endtry
    otherwise
        try
            setDateAct = set('Date')
            if !tlUseDMY
                set date ymd
            else
                set date dmy
            endif
            lDate = ctod(tcDate)
        catch
            lDate = {//}
        finally
            set date &setDateAct
        endtry
    endcase
    return lDate
endfunc
* ================================================= *
* Check string.
* ================================================= *
Procedure checkString(tcString)
    escapeCharacters(@tcString)
    checkUnicodeFormat(@tcString)
    return tcString
endproc
* ================================================= *
* Parse all special characters in a string.
* ================================================= *
Procedure escapeCharacters(tcString)
    * Convert all escape sequences
    tcString = Strtran(tcString, '\\', '\')
    tcString = Strtran(tcString, '\/', '/')
    tcString = Strtran(tcString, '\n', Chr(10))
    tcString = Strtran(tcString, '\r', Chr(13))
    tcString = Strtran(tcString, '\t', Chr(9))
    tcString = Strtran(tcString, '\"', '"')
    tcString = Strtran(tcString, "\'", "'")    
EndProc
* ================================================= *
* Check for unicode special format in a string.
* ================================================= *
procedure checkUnicodeFormat(tcString)        
    * Look for unicode format
    _Screen.oRegEx.Pattern = "\u([a-fA-F0-9]{4})"
    Local loResult, lcValue
    _Screen.oRegEx.IgnoreCase = .t.
    _Screen.oRegEx.global = .t.
    loResult = _Screen.oRegEx.Execute(tcString)
    If Type('loResult') == 'O'
        For i = 0 to loResult.Count-1
            lcValue = loResult.Item[i].Value
            Try
                tcString = Strtran(tcString, lcValue, Strconv(lcValue, 16))
            Catch
            EndTry
        EndFor
    EndIf
EndProc
        

</vfp>

[James Suárez]

Hola Irwin gracias por tus aportes. Siempre me gusta ver otros proyectos,  para aprender diferentes estilos y técnicas de programación. 

Hablando de cloudlang La idea en principio parece buena, pero realmente no lo veo como algo viable.  Usar Internet añade una latencia alta a cada función. Tal vez convertir un JSON de tantas líneas demora mucho menos que JsonFox, porque a la final estás procesando el JSON en un lenguaje más rápido, pero también implica que sí conviertes un JSON muy pequeño demorará más por la latencia que añade el request web (y el execscript).

Por un lado te comento que he revisado el código, y creo que sería más rápido usar macro sustitución que usar execscript. Podrías probarlo y ver resultados. Es decir Dividir el código línea por línea y ejecutarlo con &. Sinceramente estoy un 80% seguro que sería más rápido, ya que  execscript lo que hace es guardar el código a un archivo temporal, compilar y ejecutar. Solo el hecho de que execscript tenga que escribir en disco, añade una latencia indeseada, e innecesaria, y poco predecible (la velocidad de escritura depende obviamente más del estado y tipo de disco, que del procesador) que creo no pasaría con macro sustitución. Puede que me equivoque, pero no se pierde nada con probar. 

Por otro lado, depender de una librería que necesite siempre de Internet puede ser bueno en pruebas, pero no estoy seguro si en producción lo sea. Yo te recomiendo, o te exhorto porque no mejor, en lugar de depender de Internet y un servidor, crear todas esas funciones basadas en kodnet (recuerden que kodnet permite usar cualquier librería/clase .NET y .NET Core directamente en VFP sin registrar, sin permisos de administrador). Así se crearían un montón de funciones sobre 1 única librería.

Y es que creo que en cierto sentido, kodnet está infravalorada. Incluso veo que algunas personas crean librerías  usando C# que necesitan de registro y de PERMISOS de administrador, cosas que se pueden abolir usando kodnet. No sé si aquí alguno la ha usado a detalle (sobre todo la última versión) pero si lo hacen más a profundidad, notarán que crear objetos, obtener/asignar propiedades en ellos, o incluso llamar métodos, es mucho más rápido con kodnet, que con objetos o funciones escritas directamente en VFP. 

Para probar mi punto, y a lo mejor motivar, ya sea a ti mismo Irwin o a cualquier otra persona a crear librerías usando kodnet les comento el benchmark que hice. 

La prueba la hice en un servidor Intel Xeon E5-2630. Cómo es un VPS, los resultados, pueden variar un poco de un equipo real, pero igual sirve para comparar tiempos entre cada librería (además que ejecute varias veces las pruebas).

JSONFox usando el Lexer nativo VFPA 32 bits.  

Unos 1511 segundos, es decir más de 25 minutos. La memoria subió hasta más de 160MB aproxidamente.

JSONFox usando el Lexer nativo VFPA 64 bits.  

Unos 299 segundos, es decir 5 minutos. Sorprendentemente para mi, en 64 bits, el parser es 5 veces más rápido. ¿Ha hecho CHEN un buen trabajo con VFPA64 o es simplemente porque es 64 bits?

JSONFox Lexer C# VFPA 32 bits

NO FINALIZÓ. Bueno espere más de 15 minutos, y seguía sin acabar, además que la memoria subió de manera desproporcionada. Decidí probarlo en mi laptop que tiene un mejor procesador, y en 15 minutos ya iba por unos 600MB de memoria y aún no acababa. Desistí de esperar que terminara. Teniendo en cuenta lo que dice el repo, pensé que iba a tardar muy poco, pero en realidad  parecía que no iba a terminar nunca. ¿A lo mejor es un problema con el archivo que probé? 

JSONFox Lexer C# VFPA 64 bits

NO COMPATIBLE CON 64 BITS (al parecer, porque con el regasm de Framework64 no se registra la clase)

Cloudlang VFPA 32 bits y VFPA 64 bit

No finalizó. Sale Syntax Error

Kodnet VFPA 32 bits y VFPA 64 bits

(el código de ejemplo de kodnet no necesita tener nada más instalado a parte de kodnet y el .NET Framework que ya viene por defecto en Windows. kodnet técnicamente se puede usar sin instalar, pero por facilidad de mantenimiento, y para dar un debido soporte a VFPA64 bits, ahora está disponible en forma de instalador. kodnet se puede y se recomienda instalar sin permisos de administrador) 

Alrededor 0.3 segundos la primera vez, entre 0.05 - 0.15 segundos en posteriores ejecuciones.

Tanto en 32 bits como en 64 bits, los tiempos de ejecución son iguales

* NOTA: Este ejemplo usa la librería JSON.NET que ya está incluida en kodnet, pero naturalmente también es posible crear código que depende de otras librerías diferentes.

Cómo se puede ver, el rendimiento de kodnet es bastante notable. La forma de obtener los valores del objeto analizado, sería por ejemplo: m.result.item["txs"].item[0].item["ver"] y que como ya comenté antes,  leer los valores de un objeto generado con kodnet, es mucho más rápido que si fueran objetos VFP nativos.

Decidí probar también con un archivo mucho más pequeño, para ver cómo  iba la cosa, un archivo de unos 139KB y unas 5000 lineas.

JSONFox lexer nativo VFPA64 = promedio 12 segundos

JSONFox lexer nativo VFPA32 = también unos 12 segundos. ¿Por qué con el archivo grande demora muchísimo más? NO lo sé, pero  con el archivo grande sí probé como unas 3 veces y en todas demoró unas 5 veces más en comparación a VFPA64.

JSONFox lexer C# VFPA32 = Creo que Definitivamente hay algo mal con el lexer, c# espere unos minutos, no terminaba, y la memoria seguía subiendo desproporcionadamente.

CloudLang VFPA32 y VFPA64 = esta vez si finalizó. Promedio 11-12 segundos. Pensé que iba a ser menor el tiempo, lo ejecuté varias veces para comprobar. No sé exactamente que uses en el server, no dudo que el parser sea rápido, solo que creo que los tiempos de respuesta en VFP dependerán muchísimo de la latencia de la red, y de la sobrecarga del servidor, y en este caso el tiempo no presenta mejoras con respecto a JSONFox. De hecho si el JSON fuera aún más pequeño, creo que claramente JSONFox sería superior.

Kodnet VFPA32 y VFPA64 = Primera vez 0.15, posteriores, 0.04 segundos promedio

(Imagen de referencia de la segunda prueba de cloudlib)

Conclusiones

En los archivos más grandes, JSON parse en kodnet puede ser hasta unas  19000 veces más rápido que JsonFox en 32 bits, y unas 3700 veces más rápido que JsonFox en 64 bits.

En los archivos más pequeños, kodnet puede ser hasta unas 1000 veces más rápido que JsonFox y Cloudlib. 

Cloudlib depende más de la latencia de la red, disco, y otros factores externos que realmente del código.

Programar un parser enfocado en rendimiento es una idea genial, pero creo que el enfoque de hacerlo depender de internet no es viable. En cambio si lo haces con kodnet, tendrás un rendimiento superior sin dudarlo. Sería muy bueno verte crear funciones que trabajen con Kodnet.

Saludos a todos. 

Los archivos de código de las pruebas los dejo en este link (tanto los PRG como JSON): https://drive.google.com/drive/folders/1QCH5StSIVi0eyDLYK-_nfI_D7x53HZuA?usp=share_link

--
Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/0a919dc1-100d-4c53-bd84-8cfe7d6b46f8n%40googlegroups.com.

[Irwin Rodriguez]

Hola Marco, 

Que buena idea la de usar el objeto collection, además desconocía que se podía acceder a sus valores usando la notación objeto('propiedad') la cual me resulta súper cómoda!

Ya he adaptado los cambios y he realizado un par de pruebas con objetos y arrays anidados y de momento todo parece marchar bien.

Un saludo.

[Irwin Rodriguez]

Hola James,

Gracias por tus comentarios y conclusiones con respecto al performance de Kodnet vs JSONFox, sin duda hay un error en el Lexer C# que no he atendido tras la última modificación.

Yo hice el intento de incorporar la librería para la empresa donde trabajo pero desafortunadamente tras la incorporación de Kodnet apareció el famoso error C0000005 que causó mucho caos en ese entonces y tuve que 

quitarla del proyecto porque le adjudicaron el error el cual demostré que era falso pero ya era tarde porque ya le tenían animadversión. 

Personalmente he explorado el multithreading y los events handlers y me ha gustado mucho, he fantaseado con un wrapper o un interprete que abstraiga un poco el uso de la librería porque en mi opinión la librería

no tiene el reconocimiento que se merece por el desconocimiento por parte de muchos tanto en esta como en otras comunidades, sobre todo para aquellos que ya tienen soluciones creadas con wwDotNetBridge resulta

difícil cambiarse y adaptar a lo nuevo. 

Cloudlang lo veo como un puente donde puedo pasar o ejecutar cosas, el tema JSON fue el primero que salió porque justo necesitaba lidiar con ficheros en ese formato y pasarlos de un lugar a otro y

cloudlang me sirvió de mucho, con lo cual coincido en usar un parser no dependiente de internet para la mayoría de los casos.

Con respecto a EXECSCRIPT() no recuerdo guardar en disco y ejecutar (salvo que la propia función lo haga) pero en todo caso no está de más hacer las pruebas con macros.

un saludo.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAFiS3qUV9VQBYi5RnO3R_-h9VhbW4mcCOTUXA0Dqu%2Bs8N6TZ7w%40mail.gmail.com.

[Victor Espina]

Lo que yo no entiendo es cuál es la ventaja que me da estar consumiendo funciones en la nube,  mas allá de estar usando siempre la ultima version de la libreria??  Es decir seria imposible, por ejemplo, usar esta librería en una aplicación que va a correr en un equipo sin acceso a internet, o tendría que apelar a complicaciones tales como tener el server de CloudLang instalado localmente.   Como funciona esto en otras plataformas es que yo tengo un programa CLI que me permite instalar, actualizar o desinstalar librerías desde un repositorio en la nube... pero una vez instalada, la librería esta LOCAL, por ejemplo:

npm install cloud_lib@latest

Esto me descargaría la ultima version de la librería cloud_lib.   Si luego resulta que se publica una nueva version, entonces yo podría hacer:

npm update cloud_lib

y eso me actualizaría la librería a la ultima version,  pero SIEMPRE estaría trabajando LOCAL.   Este programa CLI (NPM en el ejemplo) mantiene un registro de todos los paquetes instalados en un proyecto y su version, dentro de un archivo de control (packages.json en el caso de NPM), por lo que nos da la ventaja adicional de no tener que guardar esas librerías en nuestro propio repo, ya que podemos descargar todas las librerías automáticamente a partir de la informacion contenida en el archivo control, por ejemplo:

npm install

Ese comando leería el contenido del archivo de control y descargaría todas las librerías que usamos en nuestro proyecto (con las versiones originales, que no necesariamente son las ultimas).

Entonces, lo que yo rescato de esta idea es la de tener un repositorio en la nube con multiples librerías de Fox y entonces desarrollara un programa CLI que nos permite descargar y actualizar esas librerías localmente.  Eso si seria tremenda idea y algo con lo que me encantaría colaborar!!.


Victor Espina

[Victor Espina]

De hecho, revisé la documentación de NPM y sirve perfectamente para publicar librerías de VFP usando su plataforma, que es gratuita y opensource.   Voy a hacer algunas pruebas  y luego les cuento que tal me fue.

Victor Espina

[Marco Plaza]

Hola Victor.. yo hace unos meses trabajando con node casualmente puse en mi "to-do" lo que tu dices..

y encontré quienes lo usan para phyton.. pero lo único que no me gusta mucho es que para publicar 

paquetes en npm es algo tedioso; github es mucho mas accesible porque puedes descargar el código 'raw' con url directas.

Terminé concluyendo que sería muy fácil crear un package manager "FoxPack" que simplemente necesita que cada prg 

tenga una funcion llamada '_dependencies' que retorne un array con las url de los prg o cualquier otro 

archivo necesario que puede residir en github o donde uno quiera.

Así al construir el proyecto simplemente al igual que el project manager de vfp comienzas por el main y al ir

descargando, se resuelve la funcion, obtenemos la lista y las descargamos, luego se repite para cada nuevo prg 

creando así un arbol de dependencias.

FoxPack podría también crear el paquete npm si encontramos algún tipo de utilidad en ello.

[Marco Plaza]

Hola James descargué tus pruebas pero no dejaste los enlaces para instalar kodnet...

Estoy de acuerdo contigo..usar go / phyton / c# es infinitamente mas rápido que vfp, y de utilidad 

para parsear grandes archivos..imposible que vfp compita con phyton/c#/go por eso quise ver 

lo que propone Irwin ( recuerda que json y el prg se comprimen bastante aunque no tiene habilitada la compresión  )

Sin embargo te dejo unas pruebas usando nfJsonRead (  https://raw.githubusercontent.com/VFPX/nfJson/master/nfJson/nfjsonread.PRG   )

 en mi pc ... 

el json1 termina en 3.052 y el json2 en 0.545 .

Otra versión que no he liberado es un poco más rápida ( _o2json  ) que termina en 2.919 y 0.421.

Se trata de que necesitas... conveniencia vs velocidad - archivos grandes o pequeños.. 

( un solo prg que te devuelve un objeto fácilmente explorable ) vs un puente a c# que requiere algo más 

para la instalación y mas verboso para usar el objeto..

[HernanCano]

Amigos: Marco, Víctor, Irwin:

Es interesante sus propuestas-comentarios-participaciones.

Irwin: Conozco JSONFox, lo uso con archivos "normales" (no gigantes") con netscanner=.f. y objetos fácilmente explorables.

Evidentemente para archivos "grandes", uno (en este escenario) necesita acomodarse a la velocidad.

Marco: La idea que se comenta de FoxPack es super-interesante. Conozco NodeJs (someramente, por que no me queda fácil salirme de VFP), y si avanzan con FoxPack, puedo apoyar y aportar.

James: qué grato es ver cómo Kodnet no aporta; si Kodnet es posible ser usado "sin instalar", quisiera saber cómo.

Seguimos en contacto.

[Victor Espina]

Gracias por compartir tu experiencia Marco.  Yo he usado mucho npm al trabajar con Angular e Ionic, y justamente la ventaja que le veo es que tu agregas la libreria y luego simplemente la usas, sin preocuparte ni de donde la bajo ni que la compone... solo plug & play.   Quizás, como dices, sea mas rápido y eficiente trabajar en una utilidad que simplifique el upload de un paquete a npm mas que trabajar en un CLI completo desde cero... pero, al mismo tiempo, lanzarse a crear nuestra propia plataforma de colaboración con un CLI propio y siguiendo las directivas que planteas suena como algo SUPER interesante de abordar y hacer, solo por diversion :)

Lo podríamos llamar FPM (Fox Package Manager) !!

Saludos

Victor Espina

[Marco Plaza]

Ciertamente Victor.. algo así como vfpx pero donde cualquiera pueda subir sus paquetes.

[Victor Espina]

Podríamos usar ActiveVFP o tu REST server para manejar el backend con el catalogo de paquetes públicos, y hacer un CLI en VFP que ejecute desde la ventana de comandos de fox y que siga las directrices que mencionas.   Entonces, si quisieras instalar FoxJSON en un proyecto, haríamos:

DO fpm WITH "install foxjson@latest"

o incluso podríamos tener una UI simple para buscar un paquete e instalarlo, asi como mostrar los paquetes instalados localmente y desinstalar alguno.

Definitivamente suena a algo super interesante como "pet project" :)

Victor Espina

[Victor Espina]

Claro. De hecho, la primer tarea seria indexar dentro del catalogo todos los proyectos que estan actualmente en VFPx.  

Victor Espina

[Marco Plaza]

Bueno Irwin compartió hace tiempo como usar un proyecto que está en win32api 

para crear aplicaciones de consola ( el codigo original tenía un pequeño bug  )

que te permiten hacer ejecutables tipo npm o vue cli.

se podría hacer un fpm con compatibilidad de comandos con npm,

y heredar la arquitectura ( paquetes globales / locales ) check.. install etc.

[Irwin Rodriguez]

Hola Victor, 

Entiendo lo que quieres decir, de hecho la forma en que lo hace Thor nunca me ha gustado y pienso que un CLI para fox con funcionalidades similares a las de NodeJS sería lo mejor. En el caso de CloudLib no es solo el PRG sino que detrás hay un servicio REST que escucha las peticiones de este para hacer cualquier cosa que le vaya agregando. Volviendo al tema CLI, hace unos días antes de caer en cama por COVID (aún me sigo recuperando) estuve trabajando con algo muy muy similar (pantallazo adjunto) para gestionar mis proyectos, se trata de un pequeño CLI que se ejecuta dentro del IDE de fox y me sirve para crear y compilar mis proyectos no visuales, la ventana adopta los colores configurados por el IDE tanto para backcolor como forecolor y así quedar lo más nativa posible.

No tengo en proyecto en github aún pero seguro lo subo esta noche o mañana.

PD. si se animan a crear el proyecto CLI cuenten conmigo.

Un saludo.

--
Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/30488312-f488-4e21-80ad-6a1a68a184ban%40googlegroups.com.

[James Suárez]

Hola Irwin. EXECSCRIPT "(salvo que la propia función lo haga)" : Sí, la propia función lo hace, guarda en un archivo temporal el código que tú le mandas como parámetro, compila y ejecuta. Por eso yo creo que sería más rápido con macrosustitución, claro que tendrías que mandar el código de una manera que se pueda dividir en línea por línea. Estaría de probarlo. Yo recuerdo que una vez hice algo que hacía así, generaba código al vuelo, y con & era más rápido que con execscript

Y creo que sería bueno igual que pruebes con cloudlang que pasa con el archivo JSON1 que nunca lo analizó. 

Saludos. 

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CABooBBnCtfjUVbJzr2LHis3M0uStqO0Bf-vLSmVOGMZ3fWYtRA%40mail.gmail.com.

[James Suárez]

Hola Marco.

El link de kodnet es: https://github.com/foxshell/kodnet   

Me olvidé de probar con nfjsonRead, pero efectivamente tiene tiempos muy buenos para ser solución 100%VFP 

Probé en el mismo server, para tener una referencia.

Con el JSON grande: 3.422, lo ejecuté varias veces con un promedio de unos 3 segundos.

Con el JSON pequeño, 0.750

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/27bd0ce6-c42c-4fc8-bc0a-5d04c50a89dan%40googlegroups.com.

[James Suárez]

Marco acerca de:

Se trata de que necesitas... conveniencia vs velocidad - archivos grandes o pequeños.. 

( un solo prg que te devuelve un objeto fácilmente explorable ) vs un puente a c# que requiere algo más 

para la instalación y mas verboso para usar el objeto..

- Lo último que es más verboso de hecho se puede solucionar. El ejemplo que hice con kodnet es básico. La nueva versión de kodnet permite crear objetos con propiedades dinámicas. Así que con un código más trabajado se podría acceder a cada propiedad directamente en lugar de usar la función/indexador ítem. De todas maneras tener una función item es vital en casos por ejemplo donde hay propiedades iguales donde solo cambian mayúsculas/minúsculas.

En fin creo que kodnet sería la solución donde se requiera el máximo rendimiento, porque de hecho Otro punto que favorece kodnet es que por alguna razón, obtener los varlores del objeto kodnet es más rápido que sí fuera un objeto vfp nativo. Yo lo he probado y realmente es mejor.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/27bd0ce6-c42c-4fc8-bc0a-5d04c50a89dan%40googlegroups.com.

[Marco Plaza]

Lo último que mencionas ( case sensitive ) y propiedades que en vfp no son válidas 

son las razones para usar un puente o implementar el parser usando una colección.. 

pero se pierde la capacidad de depurar fácilmente el objeto...

Igual probaré kodnet de nuevo a ver que tal.

Saludos.

[Irwin Rodriguez]

James, del JSON1.json hice la prueba y ciertamente después de un largo rato javascript arroja un error "Heap out of memory" con lo cual es un camino sin salida.

Por otro lado, he instalado kodnet en su nueva versión y cuando trato de ejecutar el program3.prg me sale este error:

Un saludo.

[James Suárez]

Irwin si usa el instalador en modo usuario, solo puede usarlo en VFP abierto en modo de usuario. Es decir si necesita abrir VFP en modo administrador y usar kodnet, tiene que instalar kodnet en modo administrador (usando una ventana cmd en modo administrador)

También le comento que actualmente el instalador tiene que ejecutarse en todos los usuarios  de la máquina donde se vaya a usar kodnet.

Yo creo que algo de eso debe ser el problema, o a lo mejor el comando (punto 2) falló, en ese caso, pon el contenido que salió al ejecutar el comando.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/ebbb605f-5cc2-45c9-a1dc-7b889478be2fn%40googlegroups.com.

[James Suárez]

Solo por diversión, me puse a ver si podía hacer el JSON.Parse menos verboso con kodnet, y haciendo un pequeño cambio se puede. Lo subí en la misma carpeta de drive como program5.

Necesita de kodnet 3.0.7 (ya que había un pequeño error en las clases que manejan propiedades dinámicas)

Se puede acceder al objeto analizado, tal y como cualquier objeto, directamente con la propiedad, o también con el método/indexador item. Para los array, se puede acceder usando cualquiera de las formas: array[0], array(0), array.item[0]

y se puede saber la longitud del array con la propiedad array.count (tener en cuenta los arrays en .NET inician en 0)

Lo único que faltaría es poder hacer un "preview" a la variable (o depurar el objeto como decía Marco), pero si lo importante es el rendimiento, queda como muy buena opción.

[Victor Espina]

Podrían facilitarme el archivo JSON que estan usando para esas pruebas?  quiero ver si mi libreria JSON es capaz de procesarlo y en cuanto tiempo.

Saludos

Victor Espina

[James Suárez]

Aquí están los archivos prg y JSON que he probado.

El más grande JSON 1 con ese pruebe.

0.97MB y más de 20000 líneas 

https://drive.google.com/drive/folders/1QCH5StSIVi0eyDLYK-_nfI_D7x53HZuA?usp=share_link

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/dc4c8796-04bd-4d45-b34d-6dab125b5955n%40googlegroups.com.

[Victor Espina]

No, salí reprobado :(  Me tomo 6.479s procesar el archivo JSON2.JSON y con el JSON1.JSON tuve que tumbarlo despues de 5min..... inicialmente pensé que era la creación de objetos y propiedades lo que podia estar consumiendo la mayor parte del tiempo, pero resulto que esa parte solo le suma 2s al tiempo total... por alguna razon solo el analizar secuencialmente el string me esta llevando el 75% del tiempo.... así que hay mucho espacio para mejorar, en mi caso.

Dicho eso, honestamente el formato JSON se pensó para transferir pequeños conjuntos de datos... intentar parsear un JSON de  1 MB me parece una falla de diseño, independientemente de lo rápido que se pueda parsear.

Saludos

Victor Espina

[HernanCano]

Sí, Victor.

Por éso es que Irwin puso la DLL ("adicional", el Helper, el NetScanner): para archivos grandes: para poder mejorar en velocidad. Recordemos que la JSONFoxHelper.dll debe ser registrada con RegAsm.

Notemos además que la propuesta de James pasa también por el consumo de la DLL, la cual también se considera que es de .Net, y que (1) debe ser registrada igualmente con RegAsm, o --si no-- (2) ser usada con Kodnet (que sí se registra por su propio el instalador --o procedimiento instalador--).

Te cuento que efectivamente el Colombia los JSON no son "grandes" (en los términos que indican las pruebas que se están compartiendo aquí): si un XML de respuesta de la DIAN (firmado) no llega a los 50 Kb (cincuenta kilobytes), entonces un JSON tampoco (veo un JSON de respuesta de mi PT, que tiene 42 Kb --cuarenta y dos kilobytes--, incluyendo el XML de respuesta de la DIAN. Así que mi interés es la eficiencia con los JSON "normales". Ojalá pueda hacer las pruebas.

Uso adecuadamente JSONFox, por que sólo requiero poner el .APP junto a mi aplicación. Y me ha ido bien.

A tu JSON.PRG le he notado que produce una variable pública q no es mi forma de programar, tiene muchas dependencias "legacy" (para versiones anteriores de VFP, que no me permite "leer" adecuadamente el contenido (el PRG) de la solución).

Y la propuesta del Kodnet me queda difícil implementarla, por que no veo cómo pueda estar instalando Kodnet en todos y cada uno de los computadores de un cliente para poder usarlo. La solución de poder usar DLL "externas" (hechas en .Net, dentro de VFP) "sin registrar" me parece magnífica, pero debo darle cabida en mi forma de desarrollar.

[James Suárez]

Hola. Solo por aclarar, kodnet fue escrita en c# sí, de hecho el proyecto en c# está también publicado en github, pero no necesita de regasm, (ni de regsvr32). He ahí la ventaja de kodnet: No necesita permisos de administrador.

"Y la propuesta del Kodnet me queda difícil implementarla, por que no veo cómo pueda estar instalando Kodnet en todos y cada uno de los computadores de un cliente para poder usarlo" = Aprecio cualquier comentario que ayude a mejorar. Pienso que de la misma manera que instalas tu app en cada uno de los clientes. Lo haces manual o con instalador? Si es de manera manual no veo porque no instalar manualmente kodnet si los pasos son sencillos y rápidos. Si es con instalador, entonces habría que buscar la forma que desde el instalador de su app se ejecute de una vez el proceso de instalación de kodnet. Realmente creo que no hay complique. Incluso me viene la idea de modificar y hacer un solo exe y así evitar el comando que actualmente se ejecuta desde cmd. Un solo exe y desde VFP se ejecute y listo. En ese caso el usuario podría ponerlo junto a sus archivos ejecutables y ejecutarlo al iniciar la aplicación si detecta que no están disponible las clases COM. El instalador no requiere permisos de administrador, ni tampoco requiere intervención del usuario. Por lo tanto creo que sería viable. Habría que probarlo. 

Saludos. 

--

Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/6e12f276-4c36-4138-af04-7e2c22240911n%40googlegroups.com.

[Victor Espina]

Hernan, la variable publica JSON se crea solo si ejecutas el "loader", pero nada te impide crear instancias locales simplemente haciendo:

SET PROCEDURE TO JSON

LOCAL oJson

oJson = CREATE("JSON")

En cuanto a las dependencias, la verdad debería ser transparente y no debería causarte problemas al generar el proyecto. De todas formas estoy pensando probar a publicar mis librerías a través de la plataforma NPM, y ahi si creo que van a ser exclusivamente compatibles con VFP9.

Saludos

Victor Espina

[Daniel Sánchez]

Si es como comentas un json no debería ser muy grande, pero en mi caso tengo unos datos que subo a una base de datos en la nube y paso la info en un json y en este caso paso el objeto oportal con los campos indicados

hay dos campos filepdf, y filexml en los cuales van dos archivos en formato comprimido uno tiene 94kb y el otro 5kb y al convertir el objeto oPortal con json.stringify(oPortal) toma 77.252 segundos y par enviar el json al portal 12.134 segundos y estos datos variará según el tamaño del los archivos que adjunto, como ves la conversión del objeto a json demora un monton, seria excelente que el proceso no tome casi nada como están indicando los compañeros.

Saludos

--

Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/dbf6054c-fa2d-4aa3-8bba-1850c311cbd8n%40googlegroups.com.

--

Daniel Sánchez Escobar
Investigación y Desarrollo
Reset Software SAC
Móvil y WhatsApp +051-949398047 / Móvil 948615385
Trujillo - Perú

P  Sugerimos no imprimir este e-mail a menos que sea absolutamente necesario. Protejamos el medio ambiente.

[Victor Espina]

Puedes enviarme un ejemplo de ese JSON para probar con mi libreria?

Victor Espina

[Daniel Sánchez]

Aquí te adjunto el txt del json que indique en el ejemplo, otro dato que no indique es el equipo que use es una Laptop Dell Intel Core i7 Gen 11 2.8Ghz con 16GB de RAM

Saludos

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/03d2dade-da2c-4967-bfe7-b344e3ec4e1en%40googlegroups.com.

[HernanCano]

Hola, Daniel.

¿Tienes la librería que la puedas compartir, o un link de ella?

Gracias por todo lo q nos compartes.

[HernanCano]

Buenas tardes, amigos.

En el adjunto les muestro un laboratorio de pruebas que hice para estas utilidades JSON que estamos comentando.

Les pido me ayuden a configurar adecuadamente Cloudlang para poder ejecutar, pues me está mostrando un error que describo en el adjunto, y de esta forma completar adecuadamente la comparativa.

Espero que esta info a todos les sea de utilidad.

[James Suárez]

Hernán creo que la prueba con JSONFox con .netscanner = .t. está errada. Es imposible que sea más rápido que kodnet, porque según lo que vi en el código de JSONFox, aún con netscanner habilitado, los objetos se crean del lado de VFP. Además que confirmado ya con Irwin la librería con .netscanner habilitado está fallando. Así que creo que la prueba está generando error y en realidad no se completa por lo que el tiempo no sería real. Lo digo porque además, en JSONFox me fijé que si la librería no es capaz de completar el análisis no sale error, sino que muestra un WAIT WINDOW, así que a lo mejor en tus pruebas está haciendo eso, mostrando un WAIT WINDOW y no está completando el proceso realmente. 

Te lo comento para que revises.

--
Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/efba3270-ef58-49ef-ad9a-7b541556e03bn%40googlegroups.com.

[James Suárez]

Hernán creo que no se entendió lo que dije en el mensaje anterior, así que aquí lo explico mejor. Si revisas los mensajes anteriores en las pruebas que yo hice con .netscanner = .T. con JSONFox las pruebas nunca finalizaron,  y la memoria se subió. Irwin comentó que efectivamente había un bug actualmente con el LEXER C#. Si en tus pruebas terminó inmediatamente creo que es porque en realidad nunca procesó el JSON. Para explicarme mejor, paso dos imágenes de lo que me pasó la primera vez que quise probar con netscanner = .T.

(Pareciera que el proceso se completó en 0.271 segundos pero en realidad hubo un error y el proceso nunca se completó)

(la variable result es .NULL.)

Yo creo que en tus pruebas te está pasando lo mismo, sea el mismo mensaje de error u algún otro similar. PIenso que podrías revisar y subir los resultados actualizados.

Por otro lado, la versión PROGRAM5.PRG con kodnet, permite leer el objeto con propiedas directas, haciéndolo menos verboso (como se ve en la imagen). PROGRAM3.PRG permite leer las propiedades del objeto solo usando el método/indexador item.

PROGAM5  hace que sea más fácil usar el objeto analizado (parseado), pero a cambio usa dos clases .NET más, por lo que es unos milisegundos más lento que PROGRAM3.PRG (notorio sobre todo en la primera ejecución), por lo cuál es correcta tu apreciación: PROGRAM3 es ligeramente más rápido que PROGRAM5.

La optimización que yo hice a  PROGRAM5 fue para usabilidad, pero no de rendimiento. De todas maneras la diferencia no es mucha, por lo que yo personalmente, preferiría usar la opción de PROGRAM5.

 

Saludos. 

[James Suárez]

ACTUALIZACIÓN: Yo dije que en mis pruebas JSONFox con el lexer C# el proceso nunca finalizó (y fue verdad), pero parece que Irwin ya corrigió el código, o al menos corrigió el archivo .app (que subió al repo hace 2 días). El proceso ahora sí finaliza, pero igual tarda mucho más que nfjsonread y kodnet 

(tardó 125.119 segundos en procesar el JSON1 de más de 20000 líneas)

[HernanCano]

Las pruebas q he hecho las he hecho ejecutando los PROGRAM#.PRG tal cual los ven.

Te adjunto la .APP que estoy usando.

[HernanCano]

>>> ...  Si en tus pruebas terminó inmediatamente creo que es porque en realidad nunca procesó el JSON....

Lamento profundamente con todos los colegas de la Comunidad VFP.

Pero no sabía que había un problema JSONFox con .netscanner = .T. .

Eso se debe a que no uso JSONFox con .netscanner = .T. . Sólo lo uso con .netscanner = .F., efectivamente por que mis archivos no son grandes.

También admito que lo he preferido a varios otros que he probado, por su facilidad de uso.

Veo que la detección de errores sólo está en el PROGRAM7.PRG (JSON-VEspina).

Pero evidentemente no se sabía que la DLL de JSNFox tenía error (me descompensa....--me saca la piedra!!--)

Pero mi intención es --y será-- aportar.

>>>... La optimización que yo hice a  PROGRAM5 fue para usabilidad, pero no de rendimiento. De todas maneras la diferencia no es mucha, por lo que yo personalmente, preferiría usar la opción de PROGRAM5.....

Esta es la apreciación que necesitábamos. Indiscutiblemente versiones mayores/posteriores son "mejores" que las anteriores.

[James Suárez]

Sí Hernán, tu PRG de prueba está bien, lo que yo sospecho es que la librería de FoxHelper de JSONFox no está correctamente registrada. Recuerda registrar usando el parámetro /codebase

Así registré yo y funciona:

regasm foxhelper.dll /tlb /codebase

En la computadora que yo pruebo dura 125 segundos con JSONFox y el lexer C#, con el .app actualizado. Sería bueno que le registres nuevamente la clase, a ver si puedes probar, y así actualizar el PDF para ver cómo son los tiempos bajo una misma máquina y poder ver correctamente el comparativo.

Saludos.

--

Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/7abf1580-4e94-4d9d-8617-8b55371708b5n%40googlegroups.com.

[HernanCano]

Ahhhhh......

Ya vamos peor....

La registré hace varios meses cuando empecé con ella................................

Y si hay que registrar cada que es cambiada...................... en la forma en que hay q registrarla.................

Con mayor razón no la uso con .netscanner=.t.

>>> ....  Sería bueno que le registres nuevamente la clase, a ver si puedes probar....

Claro que sí...............

[HernanCano]

Buen día, amigos.

Este hilo es sobre Cloudlang.

¿Alguien me puede dar una luz sobre qué puede estar pasando cuando ejecuto, pues me aparece el error adjunto?

[Irwin Rodriguez]

Buenas chicos, me estuve poniendo al día con los comentarios y quiero darte las gracias Hernán por las pruebas detalladas que estás haciendo. Ciertamente hace unos días actualice JSONFox.app por el fallo que reportó James, solo hay que actualizar el .APP ya que el assembly no sufrió cambio alguno.

El core de Kodnet reposa en NET así que incluirla en las pruebas contra las demás librerías nativas le da mucha ventaja con lo cual tal y como lo dijo James "es imposible que sean más rápidas que kodnet" y lleva razón así que las pruebas en mi opinión tienen que estar en 2 grupos.

El grupo 1 para librerías nativas:

1. JSONFox con NetScanner = .F.

2. JSON de Victor

3. nfJson

El grupo 2 para librerías que utilicen a terceros:

1. JSONFox con NetScanner = .T.

2. KodNet

3. wwDotNetBridge

Sin embargo en este último grupo JSONFox de seguro quedará en el tercer lugar y con mucho tiempo de diferencia pues tanto kodNet como wwDotNetBridge delegan el trabajo duro a NET con lo cual sigue quedando en desventaja pero creo que las pruebas serían más justas y equilibradas.

****************** CLOUDLANG *************************

Hernán, con respecto al error de sintaxis es muy posible que sea algún salto de línea representado en el JSON como "\n" eso hace que el traspilador genere un salto de línea equivalente en Fox con lo cual tras ejecutarse el código resulta en error. Creo que voy a dejar los saltos de línea para que los haga el PRG en lugar del servicio y así evitar este fallo. 

Para descartar haz pruebas con JSON pequeño sin salto de línea y con salto de línea entre un string me refiero, ejemplo:

{

  "mensaje": "Saludos cordiales.\nSirva la presente para..."

}

Ya comentaré algo luego...

Un saludo.

--
Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---

Has recibido este mensaje porque estás suscrito a un tema del grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/publicesvfoxpro/yGo604O4VeE/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/456a620d-8ba0-4a9a-b9bb-cf9beaa53598n%40googlegroups.com.

[HernanCano]

Todo bien, Irwin.

Estoy haciendo las pruebas con los JSON mostrados/adjuntados, que fueron compartidos en los comentarios. Sinceramente me queda difícil buscar si hay un salto de línea. Trataré de investigar más.

[HernanCano]

Las pruebas mías con el "JSONFox corregido" ya fueron compartidas en otro hilo.

Con wwDotNetBridge no hemos compartido algo --en cuanto a este tema-- (ojalá supiera cómo usarlo). De todas formas el objetivo aquí es Cloudlang.

Estoy analizando tu comentario sobre mi error con Cloudlang.

El sábado, 26 de noviembre de 2022 a la(s) 05:24:10 UTC-5, rodrigu... escribió:

[HernanCano]

Hola, Irwin.

Estoy ejecutando el PROGRAMA2.PRG para testear Cloudlang (se adjunta).

Pero ahora (ya actualicé JSONFox) me aparece este otro error (ver imagen adjunta).

Recordemos que he tomado la decisión se suprimir el JSON1.JSON de los análisis, pues JSONFox tarda mucho.

Cuando analiza el JSON2.JSON, ejecuta bien.

Pero cuando analiza el tercer archivo oPortal.JSON, sale el error. Le doy Ignorar, y sigue con el sgte archivo.

Cuando analiza el sgte archivo RESPUESTA_F.....JSON, sale el mismo error. Le doy Ignorar, y sigue con el sgte archivo.

Cuando analiza el sgte archivo RESPUESTA_N.....JSON, sale el mismo error. Le doy Ignorar, y termina.

Los archivos cuatro y cinco son personales, no los adjunto, pero son similares al tres.

Podríamos decir que el archivo #3 oPortal.JSON --que de hecho en estructura es pequeño-- la única característica preponderante que tiene es que tiene dos campos base64: uno cuya longitud es de 128,156 bytes (128 Kb), y el otro es de 5,833 bytes (5.8 Kb).

El sábado, 26 de noviembre de 2022 a la(s) 05:24:10 UTC-5, rodrigu... escribió:

[HernanCano]

[Irwin Rodriguez]

Perdona Hernan, no había actualizado el README y la forma de acceder a los miembros del objeto JSON ha cambiado a la siguiente:

text to lcJsonStr noshow
{
  "name": "John",
  "last_name": "Lennon",
  "dob": "1940-10-09 Liverpool",  
  "songs": ["Bless you", "My Life", "Stand by Me"]
}
endtext

myJson = cloudlib_parseJSON(lcJsonStr)

?myJson('name')
?myJson('last_name')
?myJson('dob')

* IMPRIMIR EL ARRAY SONGS

FOR EACH lcSong IN myJson('songs').Items
  ?lcSong
ENDFOR

El dom, 27 nov 2022 a las 21:51, HernanCano (<jherna...@gmail.com>) escribió:

--
Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---

Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/32be06f4-adb3-4710-9aa5-d3a689d54d46n%40googlegroups.com.

[HernanCano]

Ok.

Y de todas formas con el oPortal.json sigue fallando.