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 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() 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 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 PHP Code: #FOLDER dir_pi_2 // header PHP Code: #FOLDER dir_pi_3 // header 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) please test the codes and tell me Thanks Jaime |
|||
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 |
|||
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 |
|||
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 |
|||
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). |
|||
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 |
|||
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. |
|||
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: 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
|
|||
|
|||
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 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. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 2 Guest(s)