Post Reply 
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
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_k

EXPORT main_pi_k()
BEGIN
  
return {pi_k}; // returns the internal variable pi_k, path dir_pi_main::pi_k
END

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 variable
END;

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 variable
END;

EXPORT pi_ext3()
BEGIN  
  
return { dir_pi_main.pi_k } ; // returns an  external variable
END

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_k

EXPORT main_pi_k()
BEGIN  
  
return( { pi_kdir_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_kdir_pi_main.pi_k } ); // returns a internal and external variable
END;

EXPORT pi_ext5()
BEGIN  
  
return( { pi_kdir_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 path
export pi_k:=pi;

EXPORT main_pi_k()
BEGIN
  
return {pi_k};
END
file: dir_pi_2.hpppl
PHP Code:
#FOLDER dir_pi_2 // header
EXPORT main_pi_k()
BEGIN
  
return { dir_pi_main.pi_k }; 
END;
... 
file: dir_pi_3.hpppl
PHP Code:
#FOLDER dir_pi_3 // header
export 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)
.hpprgm  dir_pi_main.hpprgm (Size: 1.67 KB / Downloads: 2)
.hpprgm  dir_pi_2.hpprgm (Size: 2.63 KB / Downloads: 1)
.hpprgm  dir_pi_3.hpprgm (Size: 2.7 KB / Downloads: 1)
.hpprgm  QPI_4.4.hpprgm (Size: 13.3 KB / Downloads: 1)
Find all posts by this user
Quote this message in a reply
02-11-2018, 11:29 PM
Post: #2
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
Visit this user's website Find all posts by this user
Quote this message in a reply
02-12-2018, 12:58 AM (This post was last modified: 02-13-2018 01:32 AM by compsystems.)
Post: #3
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

http://www.hpmuseum.org/forum/thread-7001.html
http://www.hpmuseum.org/forum/thread-9097.html
Find all posts by this user
Quote this message in a reply
02-12-2018, 03:51 PM (This post was last modified: 02-12-2018 03:51 PM by Han.)
Post: #4
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
Find all posts by this user
Quote this message in a reply
02-12-2018, 05:45 PM
Post: #5
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

please, look the following link
http://merthsoft.com/linkguide/ti89/fformat.html

10 (Ah) 8 bytes Default folder name (zero terminated unless 8 characters long).
Find all posts by this user
Quote this message in a reply
02-12-2018, 06:14 PM
Post: #6
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
Visit this user's website Find all posts by this user
Quote this message in a reply
02-12-2018, 06:20 PM
Post: #7
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 HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
02-12-2018, 06:27 PM
Post: #8
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
Visit this user's website Find all posts by this user
Quote this message in a reply
02-13-2018, 12:59 AM (This post was last modified: 02-13-2018 12:31 PM by compsystems.)
Post: #9
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.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: