Problems with the name of files (*. hpprgm) and global ids
02-11-2018, 09:18 PM (This post was last modified: 02-13-2018 12:33 PM by compsystems.)
Post: #1
 compsystems Senior Member Posts: 1,329 Joined: Dec 2013
Problems with the name of files (*. hpprgm) and global ids
Hello, Sorry for my bad translation

A good practice of computer programming is divide and conquer (Folders, subfunctions, etc), which is disseminated in most programming books.

The system of the hp-prime allows to call from directory or folder, a identifier or function and works very well =), except that if the file name (pc-name) is renamed it fails =(

Example of the use of the dot operator or double colon, binary files below

Step 1: create a file with the following name
file: dir_pi_main.hpprgm (main file, library)
PHP Code:
export pi_k:=π; // declares a visible global variable pi_k=3.14159265359 path dir_pi_main::pi_kEXPORT main_pi_k()BEGIN  return {pi_k}; // returns the internal variable pi_k, path dir_pi_main::pi_kEND;

step 2: Execute the following instruction.
dir_pi_main.main_pi_k() [ENTER] // recall the variable pi_k of dir_pi_main
returns {3.14159265359} // ok

or

[tools] program functions dir_pi_main main_pi_k [ok]
dir_pi_main.main_pi_k() [ENTER] {3.14159265359}

Step 3: create a file with the following name
file: dir_pi_2.hpprgm
PHP Code:
EXPORT main_pi_k() BEGIN  return { dir_pi_main.pi_k };  // returns a external variable (pi_k of dir_pi_main)END;EXPORT pi_ext1()BEGIN   dir_pi_main.pi_k:=dir_pi_main.pi_k+1; // modify an external variable  (pi_k of dir_pi_main) where pi_k = pi_k+1  return { dir_pi_main.pi_k } ;  // returns an external variableEND;EXPORT pi_ext2()BEGIN  dir_pi_main.pi_k:=dir_pi_main.pi_k+2; // modify an external variable (pi_k of dir_pi_main) where pi_k = pi_k+2  return { dir_pi_main.pi_k } ;  // returns an external variableEND;EXPORT pi_ext3()BEGIN    return { dir_pi_main.pi_k } ; // returns an  external variableEND;

step 4: Execute the following four instructions.
dir_pi_2.main_pi_k() [ENTER] returns {3.14159265359} // ok
pi_ext1() [ENTER] returns {4.14159265359} // ok
pi_ext2 ()[ENTER] returns {6.14159265359} // ok
pi_ext3 ()[ENTER] returns {6.14159265359} // ok

Step 5: create a file with the following name
file: dir_pi_3.hpprgm
PHP Code:
export pi_k=pi-1; // declares a visible  variable pi_k=3.14159265359-1 path dir_pi_3::pi_kEXPORT main_pi_k()BEGIN    return( { pi_k, dir_pi_main.pi_k } );  // returns a internal (path dir_pi_3::pi_k) and external variable (path dir_pi_main::pi_k)END;EXPORT pi_ext4()BEGIN    pi_k:=pi_k-1;   // modify an internal variable (pi_k of dir_pi_3) where pi_k = pi_k-1  dir_pi_main.pi_k:=dir_pi_main.pi_k+3; // modify an external variable (pi_k of dir_pi_main) where pi_k = pi_k+3  return( { pi_k, dir_pi_main.pi_k } ); // returns a internal and external variableEND;EXPORT pi_ext5()BEGIN    return( { pi_k, dir_pi_main.pi_k } );END;

step 6: Execute the following three instructions.
dir_pi_3.main_pi_k() [ENTER] returns {2.14159265359, 6.14159265359} // ok
pi_ext4 ()[ENTER] returns {1.14159265359, 9.14159265359} // ok
pi_ext5() [ENTER] returns {1.14159265359, 9.14159265359} // ok

Problem #1: If you rename the main file, many functions would fail, because they do not find the correct path

One solution is to store in the header a folder name in each file (internal library name), in this way the name of the file is irrelevant (external library name [pc name]), the real path is defined by the header (internal library name)

With the new directive
file: dir_pi_main.hpppl
PHP Code:
#FOLDER dir_pi_main // header for real pathexport pi_k:=pi;EXPORT main_pi_k()BEGIN  return {pi_k};END;
file: dir_pi_2.hpppl
PHP Code:
#FOLDER dir_pi_2 // headerEXPORT main_pi_k()BEGIN  return { dir_pi_main.pi_k }; END;...
file: dir_pi_3.hpppl
PHP Code:
#FOLDER dir_pi_3 // headerexport pi_k=pi-1;...

you can check the problem by downloading the files below twice and sending the second download to the HPCONNECTITYKIT and you will notice that a syntax error is generated because it does not include the path, since a postfix (n) to the file is appended

2: second problem

In the memory manager, the variables can be reset to zero, but this alters the constant value defined within the algorithm, which produces unexpected results, for this reason to avoid this problem, a possible solution is to define a global variable as constant

CONSTANT EXPORT qpiDIGITS

Example for test the second problem, binary files below (QPI_4.4.hpprgm)
You can check it yourself, resetting the variables qpiEXPLN, qpiMAXINT, qpiDIGITS of QPI_4.4.hpprgm

QPI_(1.41421356237) [enter] returns sqrt(2)
[shift]+[tools]: user vars: qpiEXPLN (real), qpiMAXINT (real), qpiDIGITS (real) then reset each
QPI_(1.41421356237) [enter] returns 1 (failure)

PHP Code:
export qpiEXPLN:=100; // max denom for exp(p/q) or ln(p/q)export qpiMAXINT:=2^20; // largest n allowed for sqrt(n)=a*sqrt(b)export qpiDIGITS:=10; // controls accuracy (best results at 9 or 10)

please test the codes and tell me

Thanks

Jaime

Attached File(s)

02-11-2018, 11:29 PM
Post: #2
 Carlos295pz Senior Member Posts: 365 Joined: Sep 2015
RE: problems with functions that call identifiers and others functions
Una característica de HP PPL es que no es recomendable trabajar con programas externos, y cuando se intente hacer eso simplemente asegurarse de usar el prefijo, entendí desde el principio que ese es el costo de crear un lenguaje tan sencillo y útil como lo es actualmente.

Un lenguaje se puede hacer complejo de muchas formas, pero el asunto real es si es necesario, las características actuales del lenguaje cumplen muchas de mis necesidades, una especie de límite con el que me he topado es su carencia de sub-funciones o no poder crear librerías, lo que ocasiona que repita código en varios de mis programas, pero ese código repetido al final representa mucho menos del 1% del código total, así que practicamente pasa desapercibido.

Respecto a las constantes, es algo interesante, actualmente lo que recomiendo para programas que requieran tal complejidad es que creen Apps, con AFiles se puede manipular archivos, y eso brinda muchas características de persistencia de datos y acceso complejo para el usuario común.

Aún creo que HP PPL es un exelente lenguaje para los estudiantes, para el público para el cual esta destinado, lo que esperaría es que HP Prime implemente otro lenguaje más refinado si es que existe la necesidad de crear uno de más características, incluso del tipo OOP, eso requerirá de una gran decisión del equipo HP a cargo.

Viga C | TD | FB
02-12-2018, 12:58 AM (This post was last modified: 02-13-2018 01:32 AM by compsystems.)
Post: #3
 compsystems Senior Member Posts: 1,329 Joined: Dec 2013
RE: Problems with the name of files and global variables
I renamed the title, because the error does not occur with the dot operator (.) or (:: ), it happens when changing the name of the files, I think it is easy to solve the two problems reported.

First, include a new directive #FOLDER, that is the path reference pointer and not the name of the file (pc-name).
Second, an instruction that allows defining constants, so the compiler will detect if the identifier content is being modified.

PS: Currently, if you can create limited libraries in the HP-PRIME, this style or better this good programming practice, is followed by the user PRIMER

02-12-2018, 03:51 PM (This post was last modified: 02-12-2018 03:51 PM by Han.)
Post: #4
 Han Senior Member Posts: 1,878 Joined: Dec 2013
RE: Problems with the name of files (*. hpprgm) and global ids
Since the new firmware, all your problems can be easily resolved by encapsulating all your programs into a single app. You can even go as far as creating files that are packaged with your apps which are then stored into programs. For example, your app may include programs stored as myprogram1.prg, myprogram2.prg, etc. First create your programs and then do:

AFiles("myprogram1.prg"):=Programs("Program1")

Do this for all your "folders" and package these .prg files with your app.

Then you can simply do something like:

Programs("Program1"):=AFiles("myprogram1.prg");

Place this inside the START() function of your app, and your programs will always have highest priority even if someone else happens to create a program and/or variables using the same names as yours. The same goes for any constants you want to create.

The problem you are describing has always been and will always be an issue for many types of platforms -- not just the HP Prime. Even everyday computers have this issue where if you rename their program folders, the programs may either misbehave or stop working entirely.

Graph 3D | QPI | SolveSys
02-12-2018, 05:45 PM
Post: #5
 compsystems Senior Member Posts: 1,329 Joined: Dec 2013
RE: Problems with the name of files (*. hpprgm) and global ids
Thank you very much Han, I will explore the creation of apps, although it can be a bit more complicated.

The group developer of the TI68k, solved the problem, internally assigned in the header the name of the directory, I would like to see this also in the hp-prime

10 (Ah) 8 bytes Default folder name (zero terminated unless 8 characters long).

02-12-2018, 06:14 PM
Post: #6
 Carlos295pz Senior Member Posts: 365 Joined: Sep 2015
RE: Problems with the name of files (*. hpprgm) and global ids
(02-12-2018 05:45 PM)compsystems Wrote:  The group developer of the TI68k, solved the problem, internally assigned in the header the name of the directory, I would like to see this also in the hp-prime

Cuando exista un duplicado por parte de #FOLDER, la calculadora nuevamente tendrá que decidir entre uno de ellos, o si se borra esa línea se llegaría a lo mismo, no estoy muy seguro de la utilidad de esa directiva.

En cuanto a CONSTANT sí que puede ser útil, aunque extrañamente el usuario común modifica los valores al azar, un reenvío de la aplicación extropeada solucionaría el caso.

Viga C | TD | FB
02-12-2018, 06:20 PM
Post: #7
 Tim Wessman Senior Member Posts: 2,270 Joined: Dec 2013
RE: Problems with the name of files (*. hpprgm) and global ids
(02-12-2018 05:45 PM)compsystems Wrote:  The group developer of the TI68k, solved the problem, internally assigned in the header the name of the directory, I would like to see this also in the hp-prime

They didn't actually "solve" it. They just moved the problem somewhere else.

TW

Although I work for the HP calculator group, the views and opinions I post here are my own.
02-12-2018, 06:27 PM
Post: #8
 Carlos295pz Senior Member Posts: 365 Joined: Sep 2015
RE: Problems with the name of files (*. hpprgm) and global ids
(02-12-2018 03:51 PM)Han Wrote:  Since the new firmware, all your problems can be easily resolved by encapsulating all your programs into a single app. You can even go as far as creating files that are packaged with your apps which are then stored into programs. For example, your app may include programs stored as myprogram1.prg, myprogram2.prg, etc. First create your programs and then do:

AFiles("myprogram1.prg"):=Programs("Program1")

Do this for all your "folders" and package these .prg files with your app.

Then you can simply do something like:

Programs("Program1"):=AFiles("myprogram1.prg");

Place this inside the START() function of your app, and your programs will always have highest priority even if someone else happens to create a program and/or variables using the same names as yours. The same goes for any constants you want to create.

The problem you are describing has always been and will always be an issue for many types of platforms -- not just the HP Prime. Even everyday computers have this issue where if you rename their program folders, the programs may either misbehave or stop working entirely.

It is a destructive method, I believe that this has been possible since much earlier, a possibility of lighter executions, so as not to put all the code in the application program.

Viga C | TD | FB
02-13-2018, 12:59 AM (This post was last modified: 02-13-2018 12:31 PM by compsystems.)
Post: #9
 compsystems Senior Member Posts: 1,329 Joined: Dec 2013
RE: Problems with the name of files (*. hpprgm) and global ids
(02-12-2018 06:20 PM)Tim Wessman Wrote:
(02-12-2018 05:45 PM)compsystems Wrote:  The group developer of the TI68k, solved the problem, internally assigned in the header the name of the directory, I would like to see this also in the hp-prime

They didn't actually "solve" it. They just moved the problem somewhere else.

They did not transfer the problem to another place, I think Tim has not tried the files I attached (dir_pi_main.hpprgm, dir_pi_2.hpprgm, hpprgm dir_pi_3.hpprgm ) If you send the three files and follow the steps of the first post, the steps are executed well, but one way to check the problem, please download the files twice ( dir_pi_main(2).hpprgm, hpprgm dir_pi_2(2).hpprgm, hpprgm dir_pi_3(2).hpprgm ) and send the second download, you will see that the program fails

dir_pi_main(2).main_pi_k() [ENTER] "Error: Syntax error"
or [tools] user vars dir_pi_main(2) main_pi_k() [ENTER] "Error: Syntax error"
or simply rename the main file (library) dir_pi_main.hpprgm to abc.hpprgm
dir_pi_main.main_pi_k() [ENTER] "Error: Unmatch control word"

With an internal name (#folder name ; ), no matter what the file is called (external name or pc-name), the program works, currently any change in a char of the program name (pc-name) fails.

An additional advantage of the internal name is to avoid the duplication of variables, simply when you send the same duplicate file but with different names (pc files), it is detected that the folder already exists and the system would ask if you want to overwrite it [yes/no].

Someone to show me that my idea does not solve anything, if so to close this thread, otherwise this problem remains forever unresolved.