Hi, I had a backup of a file in a different folder, accidentally I dragged this file to the HPP-CK that previously exists, HPP-CK should display a replacement confirmation pop-up window, currently rewrites without confirmation.
Files with extension (1) or (2) They become
[b]unusable. /b] if another file calls internal functions of the same,
I do not know what solution there could be, outside of what I propose in
http://www.hpmuseum.org/forum/thread-8025.html
When two users create a file with the same name
With a new INTERNAL CMD (KEYWORD) HPP-CK would no longer have to replace, else added an extension to differentiate n files with the same name
file1: linearAlgebra.hpprgm
PHP Code:
#INTERNAL vectors
EXPORT main()
...
END;
vectors.main() // exe main of vectors
This would not affect old programs, if the compiler can not find the keyword
INTERNAL, takes the name of the file
file: linearAlgebra.hpprgm
linearAlgebra.main // exe main of linearAlgebra
/////////
Another user could create a file of the same name and HPP-CK would differentiate it by the internal name
file1: linearAlgebra.hpprgm
PHP Code:
#INTERNAL vectors
EXPORT main()
...
END;
file2: linearAlgebra.hpprgm
PHP Code:
#INTERNAL abcd
EXPORT main()
...
END;
The #INTERNAL proposal does not actually solve the issue -- what if another user also happens to use the same internal name? We would still have the same issue. I do agree that the conn. kit should ask the user whether they want to overwrite an existing program. In fact, it will prompt the user when dragging files from the calculator/emulator into the Content section. Hopefully the next update will ensure that it works in both directions.
(03-27-2017 07:08 AM)Han Wrote: [ -> ]The #INTERNAL proposal does not actually solve the issue -- what if another user also happens to use the same internal name? We would still have the same issue. I do agree that the conn. kit should ask the user whether they want to overwrite an existing program. In fact, it will prompt the user when dragging files from the calculator/emulator into the Content section. Hopefully the next update will ensure that it works in both directions.
Resolves at least one problem, that if the file is renamed this remains functional. Currently if you rename a file that is used by another program, this is unusable.
I think #INTERNAL is a very good idea, I do not know what the development group thinks.
(03-27-2017 04:59 PM)compsystems Wrote: [ -> ]Resolves at least one problem, that if the file is renamed this remains functional.
Does it? If I wrote my own program and used the same internal name as you did, and also used the same function names like main()... there is no way to distinguish my program from yours since (in this example) we have two instances of internalname.main(). The filename.programname() scheme eliminates this issue since 1) you cannot use duplicate file names and 2) any exported programs/variables that share the same name can be distinguished using the fully qualified name: filename.variable or filename.programname(). I do not see how it would be possible to enforce unique internal names except for programs created on the calculator. But if a user downloads a program that uses the same internal name as an existing program, what do you propose the calculator do in this case?
Quote:Currently if you rename a file that is used by another program, this is unusable.
As for renaming files causing programs to break, this should be expected. It would be no different from HP renaming the SOLVE command to HPSOLVE and causing compatibility issues with existing programs that use the SOLVE command. Those programs would have to be manually updated. Similarly, on the HP48, if you write a program that calls another program named MYPROG that was stored in another directory, you would have to use the full path to MYPROG. Renaming the directory would cause your program (that needed MYPROG) to break.
EDIT: I recommend using a naming scheme that makes your program(s) more likely to be unique. Avoid using generic names like main(), for example. Instead, if your file is called LinearAlgebra, then consider using laMain() for the main function (note the 'la' -- short for
linear
algebra). Or perhaps linalgMain(). Other related programs could be called linalgProg1(), etc. This way, you may not even need to use the fully qualified names and the naming scheme is even quite similar to the one currently being used by the firmware.
The .hpprgm files are truly the source code, the executable file is also internal, The file name should only serve as PC storage and transfer, not as internal storage reference
tstLibM.hpprgm fails if your rename
LibMenu.hpprgm for example to LibMenu
1.hpprgm
http://www.hpmuseum.org/forum/thread-722...l#pid64739
with INTERNAL
LibMenu1.hpprgm
The program tstLibM.hpprgm still works
Many times when downloading the same file for example LibMenu.hpprgm windows rename it to (n) LibMenu(1).hpprgm
And if you send it to the HPP-CK would fail the execution of tstLibM.hpprgm, with INTERNAL this problem is avoided, for example the files of the TI68K calcs, internally stores the name, I never had problems with the TI68K while with the HP48/50, I had to search and rename directories
The TI-89 variable file format, Link
http://merthsoft.com/linkguide/ti89/fformat.html
Says:
8 bytes for Default
folder name (INTERNAL NAME)