I’m using: SWI-Prolog version 8.1.9 on Windows 8.1
Whenever I try to open the Edit Spy predicates with with 8.1.9 I get the error dump below in the console window. This did not happen with 8.0.3. Note, 8.1.9 is the version I reported the problems with the Navigator window freezing, which Jan said in another thread is fixed in one of the dev builds:
ERROR: [Thread pce] Unhandled exception: Domain error: `predicate_property' expected, found `trace_any'
ERROR: [Thread pce] In:
ERROR: [Thread pce] [20] '$get_predicate_attribute'(gui_tracer:noguitracer,trace_any,1)
ERROR: [Thread pce] [18] prolog_debug_status:debugging(trace,gui_tracer:noguitracer) at c:/program files/swipl/xpce/prolog/lib/trace/status.pl:172
ERROR: [Thread pce] [17] Send-method on @51711037957/prolog_debug_status_dialog: prolog_debug_status_dialog->update at c:/program files/swipl/xpce/prolog/lib/trace/status.pl:143
ERROR: [Thread pce] [16] <meta call>
ERROR: [Thread pce] [15] pce_principal:send(@51711037957/prolog_debug_status_dialog,update) <foreign>
ERROR: [Thread pce] [14] Send-method on @51711037957/prolog_debug_status_dialog: prolog_debug_status_dialog->initialise at c:/program files/swipl/xpce/prolog/lib/trace/status.pl:80
ERROR: [Thread pce] [13] <meta call>
ERROR: [Thread pce] [12] pce_principal:send(@51711037924/prolog_debug_status,append(new(prolog_debug_status_dialog))) <foreign>
ERROR: [Thread pce] [11] Send-method on @51711037924/prolog_debug_status: prolog_debug_status->initialise(@prolog_ide/prolog_ide) at c:/program files/swipl/xpce/prolog/lib/trace/status.pl:65
ERROR: [Thread pce] [10] <meta call>
ERROR: [Thread pce] [9] pce_principal:send(prolog_debug_status(@prolog_ide/prolog_ide),open) <foreign>
ERROR: [Thread pce] [7] <meta call>
ERROR: [Thread pce] [6] pce_principal:send(@prolog_ide/prolog_ide,open_debug_status) <foreign>
ERROR: [Thread pce] [5] call(swi_ide:send(...,open_debug_status)) at c:/program files/swipl/boot/init.pl:324
ERROR: [Thread pce] [4] <meta call>
ERROR: [Thread pce] [3] pce_principal:pce_dispatch <foreign>
ERROR: [Thread pce] [2] catch(pce_dispatch:pce_dispatch,_710,pce_dispatch:true) at c:/program files/swipl/boot/init.pl:386
ERROR: [Thread pce] [1] pce_dispatch:pce_dispatcher(main) at c:/program files/swipl/xpce/prolog/lib/pce_dispatch.pl:98
ERROR: [Thread pce] [0] <meta call>
ERROR: [Thread pce]
ERROR: [Thread pce] Note: some frames are missing due to last-call optimization.
ERROR: [Thread pce] Re-run your program in debug mode (:- debug.) to get more detail.
ERROR: [Thread pce] Unhandled exception: frame ->append: Argument 1 (subwindow): `window' expected, found `new(prolog_debug_status_dialog)'
Also, I’ve been getting this error a lot lately when I try to consult a module:
ᙕ[debug] 16 ?- make.
Warning: 'c:/program files/swipl/xpce/prolog/lib/pce_manual': can not recompile "c:/program files/swipl/xpce/prolog/lib/pce_manual.qlf" (access denied)
Warning: Loading from source
Not likely anytime soon. There has just been one and there are by far too few serious bug fixes. If you want to keep up, use the devel versions (as you seem to do). They sometimes break, but are generally fixed quickly.
So the current development branch has all the fixes you mentioned for the graphical debugger? Also, is there a Windows binary for that branch, or is the only way to get it to build from source?
I just upgraded to the latest dev build, running on Windows 8.1:
Welcome to SWI-Prolog (threaded, 64 bits, version 8.1.9-19-gdf7c7a26a)
The Navigator now works again (thanks!). However, I’m still getting the access denied error when I do a make operation. It doesn’t seem to be hurting anything, at least not yet.
Warning: 'c:/program files/swipl/xpce/prolog/lib/pce_manual': can not recompile "c:/program files/swipl/xpce/prolog/lib/pce_manual.qlf" (access denied)
Warning: Loading from source
I see. So the SWI-Prolog process can’t access the initial files because they are in a directory that requires administrator rights, but once it creates new copies in a directory it does have access privileges to, the problem goes a way?
The likely cause is that although the qlf file is created from the same source and thus up-to-date, after the install process one of the .pl input files has a later time stamp then the .qlf file. This makes make/0 think the qlf file is out of date. There are (I guess) three ways out:
Run make/0 as admin to create a new (identical) version of the .qlf file
Make sure make/0 keeps its mouth shut about .qlf files it cannot write, possibly limited to the system.
Fix the installer somehow that the .qlf files are more recent than the .pl files. No clue how.
In versions of Window starting with Vista, C:\Program files is not owned by a user but by NT Service\Trusted Installer which does not allow a regular user on Windows to modify the directory or any file in it.
Use
C:\>dir /Q
and you should see a line like
06/18/2019 11:43 AM <DIR> NT SERVICE\TrustedInstaProgram Files
If you even try and create an empty file in the directory as a user you will get
C:\Program Files>copy nul > file.txt
Access is denied.
This was done many years ago as a security measure to protect the directory from hackers.
So the problem you have is not specific to SWI-Prolog it is with any user updates to those protected directories.
Now if you do it as an administrator it works.
Microsoft Windows [Version 10.0.17134.885]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>cd C:\Program Files
C:\Program Files>copy null > file.txt
C:\Program Files>dir file.txt
Volume in drive C is OS
Volume Serial Number is F6C0-475E
Directory of C:\Program Files
07/17/2019 12:43 PM 44 file.txt
1 File(s) 44 bytes
0 Dir(s) 75,268,648,960 bytes free
C:\Program Files>
Notice the dialog title Administrator: Command Prompt
Since I have not done full blow Windows applications in a while I am quite rusty on this so take this with a grain of salt.
They can be updated but the work should not be done in the C:\Program Files directory or any directory that is owned by NT Service\Trusted Installer AFAIK.
Typically how this is done is in a directory that is owned by the user and that the user doesn’t need to know the details about because only the application needs to know about it.
Most application create a directory following this pattern C:\Users\Eric\.<application> e.g. C:\Users\Eric\.docker. They start the directory name with a period (.).
Another place to do it might be C:\Users\Eric\AppData\Roaming\<application> but that typically only contains data. I don’t know if installers are also using that for temporary builds and cleaning up afterwards.
Another part I don’t know is if the user wants the app to work with all users that have an account on the computer, then where does that take place?
And another part I haven’t worked with in a long time is the fact that the location of user accounts is not to be hardcoded, e.g. C:\Users\Eric but looked up in the registry.
They have official documents that detail all of this, but I haven’t looked at them in years and the details typically change with every other release of Windows.
I will try and find the manuals but no promises.
EDIT
The maze to the Windows developer documents start here.
The most robust technique on Windows is to get the user’s application data folder from the environment. Here’s how it’s done with C#:
If you prefer to execute a shell command and then capture and parse the shell’s stdout PIPE, you can use this command from a command window (cmd.exe):
echo %appdata%
That will cause the user’s appdata folder to print to the console. That folder gives read/write permissions to all user level apps. As @EricGT says, create a folder underneath directory for SWIPL (e.g. c:\users\robert\AppData\Roaming\swi-prolog), and use that as your top level directory for all storage.
Note, c:\users\robert\AppData\Roaming\ is my appdata folder on my system but you can’t use it blindly. The directory “moves around” on different systems so you have to ask the operating system for it as I specified above.
The application data that is specific to a user should go in the directory (%appdata%) with a subdirectory created for that application, but the executables, DLLs, etc, should still go in Program Files
If you put the executables and DLLs in ‘appdata’ then you have defeated the purpose of protecting Program Files by giving access to anyone with access to the user account, think hacker, and they can modify those executables. Again not exactly sure of the details without checking, but that is in the ball park.
Thanks Eric. I meant application data storage for the user, not the program installation itself as you rightly point out. I should have made that more clear.
Hi Jan. That gives the user’s documents folder, not the application data storage folder. Usually that folder has a sub-directory named \roaming or \local in its path, as my reply to Eric shows.
