Pre-processor output file.

roho

Member
Hello all,

I've been generating this output file when compiling for a long time now, and it has been working without any problems. Until today. The compiling still works fine, that's no problem, but now WordPad just opens an empty window and a separate error window telling that it cannot locate the file. The path given has my username converted to upper case letters, whereas it should be all lower case. When I navigate to where the file should be (\Users\<username>\AppData\Local\Temp\) then there are no .bas files there, suggesting that the problem lies on the file generation side.

As far as I'm aware, I haven't altered any settings in PE6, and neither have I downloaded any SW from RevEd recently. I've been through all the options set up and can't find anything that could affect the path name. Something somewhere must have changed, but I cannot find what or where. Can anybody help, please, I need the pre-processed file in order to run simulations.
 

premelec

Senior Member
At various times I've used a program called Agent Ransack to find lost files - worked better than MS finder... since there are several hundreds of thousands of files on my machine it can take a while... ;-0 good luck...
 

hippy

Technical Support
Staff member
I am not sure what the issue would be, why it has stopped working. PE6 takes the on-screen program, saves it to a temporary file, runs the pre-processor on it, which generates another temporary file, runs the compiler on that. Those temporary files should be placed where Windows tells PE6 to place temporary files; presumably "\Users\<username>\AppData\Local\Temp" which would seem to be correct.

Windows will tell PE6 what temporary filename to use and there's no reason to believe PE6 won't be using the directory and filename which Windows says to use and it is reasonable to expect they would be there when PE6 then tries to show the preprocessor output file.

Windows does clear out temporary files but should not be doing that so aggressively that they are gone immediately.

Can you provide details of which Windows version and version of PE6 you are using, what PICAXE is selected, what your PICAXE program is, what the filename is which WordPad is trying to show and the full text and filename which is given in the error message pop-up.
 

roho

Member
Thanks premelec, but with the information that hippy's provided, I don't think that I'll be needing it. If the compilation is successful, and it is, then the files must be being generated and in the correct location. I opened the explorer(?) window at the relevant directory, started compiling, and then watched the contents of the temp\ directory to see what happened. Although I didn't see it every time, there were times when I very clearly saw that a number of files were being created, four I think. However, they existed only fleetingly, and by the time the WordPad window opened, then had all already disappeared. If that rapid disappearance is Windows tidying up, then it is certainly aggressive in doing so. This happens every time.

To answer the questions, I'm running PE6.0.8.6 under Windows 10. The chip in question is a 28X2, the code I will attach below, though I'm not sure it's of much value in this instant, as well as the error message. The file that is trying to be opened obviously changes with every compilation, but for the error message below, I clearly saw that the name given for the file matched that shown fleetingly in the directory listing. However, the user name part of the path is the wrong case. Whether this last bit is of any significance I have no idea, but the file had already been removed by the time the WordPad window opened.

Here's the code:
[No sorry, here's not the code -- it's way too long to fit the 10000 character length of message limit. If you really need it, I'll post it in sections later on.]

Finally, the error message:
WordPadError.png
 

hippy

Technical Support
Staff member
It does sound like this is Windows 'stealing your files'. It may be worth updating to the latest version of PE6 but the problem seems to be outside PE6.

The username shown in the error pop-up appears to be the Windows 8-dot-3 truncated version of what your username actually is, which one would presume is longer than 8 characters or contains spaces or other non A-Z characters.

That shouldn't be the issue, which does seem to be the files disappearing or being placed somewhere else as soon as they are created.

Given that it is not really necessary to post your full code. It would be worth checking with some other test programs to see if behaviour is the same or just with that code.
 

hippy

Technical Support
Staff member
I perused Google to see if I could find any reports on temporary files disappearing on Windows 10 as soon as created but I couldn't find any. Plenty of other cases; the folder filling up, unable to delete files.

It would be worth checking how much disk space is used or free, performing a disk clean-up, flushing temporary internet files, and of course performing a full anti-virus scan.

And, talking anti-virus, it would be worth checking that's not deleting them or quarantining them.
 

roho

Member
I've now tried compiling a number of different programmes, and while all are successful, the pre-processing output file never gets generated for long enough that WordPad can capture it. Target devices have been 14M2, 20M2, 28X2 and 40X2, and the code length has varied from many hundreds of lines down to about a dozen. We can rule out the problem being device or code related.

I've got oceans of free disk space, more than 330GB, I've cleaned it anyway of collected detritus, and I can't yet find anything from the anti-virus SW that would lead me to suspect that it is intervening. I do recall that I received a SW push from MS a few weeks ago, and this could be the first time that I've been compiling files since then. I'll try contacting MS help desk and see if that helps.
 

PhilHornby

Senior Member
I opened the explorer(?) window at the relevant directory, started compiling, and then watched the contents of the temp\ directory to see what happened. Although I didn't see it every time, there were times when I very clearly saw that a number of files were being created, four I think. However, they existed only fleetingly, and by the time the WordPad window opened, then had all already disappeared. If that rapid disappearance is Windows tidying up, then it is certainly aggressive in doing so.
What happens if you run the Preprocessor manually (in a "command Prompt") ?

Code:
Usage:        picaxepp -p18M2 input_file.bas output_file.bas
Optional switches:
        -h      Display help
        -q      Quiet mode
        -z"myname.bas"  Pseudo for ppp_filename
        -s      Simulation mode (adds '#define simulating')
Code:
c:\>[B][COLOR=#0000ff]cd "\Program Files (x86)\Revolution Education\PICAXE Editor\Compilers"[/COLOR][/B]


c:\Program Files (x86)\Revolution Education\PICAXE Editor\Compilers>[B][COLOR=#0000ff]picaxepp  -p08m2 c:\temp\temp.bas [/COLOR][COLOR=#800080]temp.out[/COLOR]
[/B]

PICAXE Preprocessor
Version 1.0.5
Copyright (c) 2011-2015
Revolution Education Ltd


Preprocessing files...
   c:\temp\temp.bas


PASS, preprocessing successful.


c:\Program Files (x86)\Revolution Education\PICAXE Editor\Compilers>[B][COLOR=#0000ff]type [/COLOR][COLOR=#800080]temp.out[/COLOR][/B]
[B][COLOR=#ff0000]REM #PICAXE 08m2


do
loop[/COLOR][/B]
c:\Program Files (x86)\Revolution Education\PICAXE Editor\Compilers>
(In your case, using -p28x2 and the name of your .bas file)

This must? work, because that's the file that PicaxeEditor.exe feeds into the compiler (picaxe08m2.exe in my example) and then wordpad.exe. There should be a.ppp flavour of the specified output file as well.

Perhaps you'll find that the problem is with wordpad.exe and it can't read it (for some reason).

UPDATE

It appears to be PicaxeEditor.exe that ultimately clears these files away - i.e. they're not marked for automatic deletion when closed. There's potential for a race condition, where PicaxeEditor marks them for delete, before Wordpad has got started. (Guessing at this point :-; )
 
Last edited:

roho

Member
Yes, that works exactly as you describe. Thanks a ton, Phil, that's a really big help to me.
 

hippy

Technical Support
Staff member
The files are at least briefly appearing in the temporary directory even when the pre-processor is run from within PE6 so I would say the pre-processor is already proven to work, and that the compilers using those temporary files also work is confirmation they are there for long enough for the compilers to do their thing.

An exact manual test of the pre-processor will require taking input from a file in the temporary directory, putting the pre-processed output there.

As to the ultimate deletion of those files; I believe PE6, the pre-processor and compilers, don't much care; it is create and forget, leaving it up to Windows to delete them knowing Windows will do that as it knows the directory is a temporary directory.

Windows is usually rather laid-back about deletion, rarely performing such deletions, the usual complaint being that files are not deleted, the directory is filling up.

Deletion would not normally be instant or within a few seconds of creation, because that defeats the object of temporary files which will be placed there, intended to be used later, just as PE6 is doing.

This is what makes the behaviour we are seeing here rather bizarre. One thought was that Windows was moving files from the temporary directory to somewhere else it has decided they should be, but it seems odd Windows would allow them to appear and then move them. Such relocation would normally be done within Windows; you ask for C:\Temp it decides 'that's should be C:\SomewhereElse' and would change that on-the-fly so the relocation was completely transparent; files would instantly appear where they should be, are there, no matter how referred to. It's aliasing rather than moving. That's how Windows does it with other directories and has done for a while.

That leads to the possibility that it is anti-virus or something which is scanning directories and folders, clearing up only after something has been created and it has re-scanned directories.

This behaviour appears to be recent and we haven't had any other reports of it. Nothing will have changed with PE6 and it was previously working.

One thing worth trying is creating a file with NotePad or WordPad and saving it in the temporary directory with a .bas extension, seeing if that persists or is cleared out.
 

PhilHornby

Senior Member
Yes, that works exactly as you describe.
OK, so you have a workaround, at least.

There are some other things you can try, that might debug it further - by simulating more closely what PicaxeEditor does:-

1) Rather than letting the PicaxEpp output file default to the current directory - try forcing it into your 'Temp' directory. By this I mean prefix "temp.out" in my example, with "C:\users\ROGGH_~1\AppData\Local\Temp\" (This in itself is a curiosity - because it's the 8.3 version of the actual directory name). [I expect this to work]

2) Prove your copy of Wordpad can find and open this file, when specified on the command line. So: "c:\Program Files\windows nt\accessories\wordpad" "C:\users\ROGGH_~1\AppData\Local\Temp\temp.out" [I expect this to work too...]

3) Get a feel for how long Wordpad takes to open - it should be pretty instantaneous.

4) Prove you can delete the file that Wordpad still has open, without complaints from either Wordpad or the command doing the deleting. [I'm still wondering about a race-condition, where PicaxeEditor deletes the file before Wordpad has had a chance to open it.]

My next step would be to substitute Wordpad.exe with another program, in order to print out some debugging info - but it would be much easy for Rev. Ed. to have a look at their source code. They could confirm how/when PicaxeEditor.exe deletes the file ... and how it synchronises that activity with Wordpad.exe ...
 
Last edited:

PhilHornby

Senior Member
As to the ultimate deletion of those files; I believe PE6, the pre-processor and compilers, don't much care; it is create and forget, leaving it up to Windows to delete them knowing Windows will do that as it knows the directory is a temporary directory.
No - PicaxeEditor deletes the file.

BTW - I'm not just guessing at this - I was using Sysinternals Process Monitor to observe what happens. I saved the output from my investigations here, if you want to see them - (invoke Process Monitor and "File | Open" that file). (This is a highly filtered version of what you actually observe in real-time).

him as well said:
That leads to the possibility that it is anti-virus or something which is scanning directories and folders, clearing up only after something has been created and it has re-scanned directories.
I could find no evidence of any other programs accessing these files (but I don't think a Virus Checker would necessarily show up as a discrete program).

Another thought...

If a Virus Checker detected a problem when the file was created, the file wouldn't be available for the compiler to read and the compiler would fail before Wordpad. Ditto, if a Virus Checker detected a problem when the file was opened for read. It would seem quite a coincidence , if a scheduled Virus Check always happened in between the compiler and Wordpad running.
 
Last edited:

roho

Member
Indeed, compilation has never been affected, so the temporary file generation and usage must be good. The problem seems to be limited to the files being in existence long enough for WordPad to see them.

When I initially ran the pre-processor command manually, I put the output file directly where I would use it. I've now done a trial as you suggested and saved it in the Temp directory: after several hours it's still there, as is the .ppp file created at the same time.
 

PhilHornby

Senior Member
I've just noticed that Wordpad.exe exists in two flavours on my system...32 and 64 bit.

Code:
c:\>dir "\Program Files\windows nt\accessories\wordpad.exe" "c:\Program Files (x86)\windows nt\accessories\wordpad.exe"


 Volume in drive C is SSD
 Volume Serial Number is EEE9-05F3


 Directory of c:\Program Files\windows nt\accessories


29/09/2017  13:41         4,490,240 wordpad.exe
               1 File(s)      4,490,240 bytes


 Directory of c:\Program Files (x86)\windows nt\accessories


29/09/2017  13:42         4,289,024 wordpad.exe
               1 File(s)      4,289,024 bytes
               0 Dir(s)  21,997,137,920 bytes free


c:\>
PicaxeEditor invokes the 32bit version.

It might be interesting to see what happens if you replace the 32bit version with the 64bit one (keeping a copy of the original of course). It's a bit of a pain to do - you have to take ownership of the two files (.exe and .dll) and then add yourself to the ACL, with full permissions.

Simpler might be to specifically invoke the 32bit version and see if it can successfully open the Precompiler output file. (Any manual tests you've done up now, will have used the 64bit version - assuming, of course, that you have a 64 bit PC!)

(Personally, I've always invoked Wordpad as Write.exe -- I'd never noticed that Write.exe is now just a stub to keep the old-timers happy!)
 

hippy

Technical Support
Staff member
PicaxeEditor deletes the file.

BTW - I'm not just guessing at this - I was using Sysinternals Process Monitor to observe what happens.
You may well be right, my recollection or imagining of what it does may well be incorrect. One would have to look at the source code of PE6 to see exactly what is intended. But if that's what SysInternals shows then I imagine your analysis is correct.

PE6 won't be deleting the file before it has launched WordPad to open that file, and I wouldn't have expected it to continue until it had been acknowledged that WordPad had launched and opened the file.

Perhaps something has changed such that PE6 is being led to continue and delete the file. We will have to investigate that.
 

hippy

Technical Support
Staff member
Within PE6, if you go into Options, select the File page, there's a Default Temp Path option. Might be worth trying some other path to see if that improves things.
 

roho

Member
I'm afraid that changing the temporary path doesn't alter things. I've taken a more careful look at the timing as the WordPad window is being opened, and the sequence of events is:
  1. Four temporary files are created in the temporary directory,
  2. The outline of the WordPad window appears,
  3. All four files are deleted from the directory,
  4. The WordPad window fills in properly,
  5. The error message appears.
 

PhilHornby

Senior Member
...and I wouldn't have expected it to continue until it had been acknowledged that WordPad had launched and opened the file.
As you say, a look at the source code will reveal all...

On my PC (where it works OK), PicaxeEditor definitely deletes the file (or rather marks it for delete), while Wordpad is still running - it doesn't wait for it to exit.

Code:
c:\TEMP>[B][COLOR=#008000]dir *.bas /s[/COLOR] [/B]
Volume in drive C is SSD
 Volume Serial Number is EEE9-05F3


 Directory of c:\TEMP\system

03/02/2018  21:41            88,313 vybibbhf.bas
               1 File(s)         88,313 bytes

     Total Files Listed:
               1 File(s)         88,313 bytes
               0 Dir(s)  21,726,232,576 bytes free

c:\TEMP>[B][COLOR=#008000]dir *.bas /s[/COLOR][/B]
 Volume in drive C is SSD
 Volume Serial Number is EEE9-05F3
[B][COLOR=#0000ff]File Not Found[/COLOR][/B]

c:\TEMP>[B][COLOR=#008000]taskkill /im wordpad.exe[/COLOR][/B]  ; wordpad is still running, with "[COLOR=#0000ff]vybibbhf.bas[/COLOR]" open :-
SUCCESS: Sent termination signal to the process "[COLOR=#0000ff]wordpad.exe" with PID 12000.
[/COLOR]
c:\TEMP>
 

PhilHornby

Senior Member
Windows 10 Pro (64bit). [10.0.16299.214]

I think I've got the latest release - but in this "Software-as-a-service world", you can never really tell!
 

PhilHornby

Senior Member
Problem reproduced ...

I can reproduce this error - or one that is similar...

I created a directory called "c:\temp\Long Directory Name"

In PicaxeEditor Options | File, I selected this as the Default Temp Path (by browsing to it).

In PicaxeEditor Options | Diagnostics (Pre-processor), I enabled "Display Pre-processor Output"

I then hit the "Syntax Check" button.

I briefly saw files appear in my new "Temporary Directory" :-

Code:
 Directory of c:\temp\Long directory name


04/02/2018  19:16    <DIR>          .
04/02/2018  19:16    <DIR>          ..
04/02/2018  19:16            88,313 k5n2njqo.bas
04/02/2018  19:16                 0 k5n2njqo.err
04/02/2018  19:16           571,957 k5n2njqo.ppp
04/02/2018  19:16            32,544 k5n2njqo.sim
               4 File(s)        692,814 bytes
               2 Dir(s)  21,035,347,968 bytes free
But Wordpad failed to open the specified file :-

noteightdotthree.jpg

This looks like some kind of parsing error related to the spaces in the name. The OP's error seems slightly different, in that PicaxeEditor appears to have used the 8.3 version of the directory name instead. (8.3 filename creation is enabled on my PC)
 

roho

Member
I've downloaded the latest revision of PE6 but still the problem persists. I've also created a temporary directory called AAAA directly under C:\ to remove the usage of 8.3 directory path names, and still the same behaviour. This one is defying logic at the moment.

WordPadErrorAAAA.png
 

roho

Member
Ah, just read your previous post properly. You saw the files in the directory listing briefly. Had they disappeared by the time WordPad opened?
 

hippy

Technical Support
Staff member
I can reproduce this error - or one that is similar...
Yes, there does seem to be an issue when specifying a path with embedded spaces when it comes to WordPad, but oddly enough seems to works for viewing the pre-processor output which launches NotePad. I will file that as something to look at though I think we would generally say "don't use paths with spaces, etc".

For the OP's case; the path would be what Windows is providing for PE6 to use and it may well provide the 8-dot-3 names to avoid embedded space issues or when dealing with long filenames.

I would say the two are different; the OP's case that it can't open the file because it's seemingly not there, the embedded space issue because it isn't being given the correct path and filename so will not find the file even if it is there.
 

PhilHornby

Senior Member
Had they disappeared by the time WordPad opened?
No, I don't believe so - but hard to prove one way or the other. Certainly, I can't reproduce a "no such file" error, except when it's looking for the wrong file (ie truncated directory name).
 

PhilHornby

Senior Member
I just looked back through my "Process Monitor" logfile.

PicaxeEditor.exe deletes the Pre-processor .BAS file, almost exactly two seconds after invoking Wordpad (on my PC). I know that PicaxeEditor checks for the existence of Wordpad.exe and checks that the process fires up correctly. It doesn't know what that Process is actually doing though - if you swap Wordpad.exe for CMD.EXE, it doesn't give an error.

Can Wordpad (the 32bit version) open a file specified on the command line on your PC, in less than two seconds?

I decided that that's not something you can easily measure - if you ask it to open a large file, it gives no indication that it has started the process, only that it has completed :(
 
Last edited:

PhilHornby

Senior Member
Test script to prove Wordpad can open a file in two seconds.

Creates a file containing the string "Hello there!" and asynchronously invokes the 32bit version of Wordpad to view it. Two seconds later, it deletes the file.

Note: When invoked using the "Start" command, Windows seems to need the 8.3 version of the path to Wordpad.exe - enclosing it in quotes doesn't appear to do the same job. I cheated by creating a new file assocation ;-)

I can't get this to fail on my PC, with the Timeout set to 2 seconds. I have had occasional failures with it set to 1.

(Copy to TIMER.BAT and invoke from Command Prompt)

Code:
@echo off

:: Test time required by wordpad to open file

echo Hello there!>%TEMP%TESTFILE.PHIL
type %TEMP%TESTFILE.PHIL

::
::start "c:\Program Files (x86)\windows nt\accessories\wordpad" %TEMP%TESTFILE.PHIL
::Sadly, this doesn't work - it just follows the file association instead :-(
::You have to use the 8.3 version of the file, rather than enclosing it in quotes.
::start c:\progra~1\window~4\access~1\wordpad.exe would probably work.
::

::Create a file association instead!

ftype PhilFile="c:\Program Files (x86)\windows nt\accessories\wordpad.exe" "%%1"
assoc .Phil=PhilFile

::Invoke 32bit wordpad

start %TEMP%TESTFILE.PHIL

:: WAIT 2 Seconds
Timeout /t 2

del /q /f %TEMP%TESTFILE.PHIL

ftype PhilFile=
assoc .Phil=
 

Technical

Technical Support
Staff member
1) PE6 uses the getTempPath API which always returns the short filename version for Windows legacy reasons. Therefore PE6 is not doing anything clever, it's just using whatever Windows tells it to use withe regards to the path to the Temp folder. Unless you use (force) the path address via Options, in which case it uses exactly what you type instead. This option is only really useful for school network use.
2) We guess the error seen is most likely because Wordpad is trying to open the file too early (not too late) ie before PE6 has finished writing out the temporary file to disk.
 

roho

Member
For absolutely no explicable reason, it's started working again. It was failing earlier this morning and now it's working: precisely the same file, same target device (40X2), same session (no shutting down of PE and re-starting it), same everything. Let's see how long this lasts...
 

roho

Member
Yes, but it doesn't run as it should on my machine. I've been lumbered with a Power shell, which seems to be distinctly user unfriendly. I can't get commands, that work perfectly fine on the command line, to run from a script. It even gives an error that a certain command is not known, although I enter the alias instead of the command, and it can identify it as such.

However, all of that aside, I can run commands from the command line, and WordPad opened (earlier in the week, when the problem was persisting) near instantaneously. I've just checked it again and it's behaving the same. I've just re-booted my laptop and WordPad continues to capture the pre-processed file correctly.
 

PhilHornby

Senior Member
Ah ... some recent update replaced "Command Prompt" with Powershell and it's not the same beast at all.

You can set the default back in "Settings >> Personalisation >> Taskbar" ... or hit "WIN+R", then "cmd.exe", as a one-off.
 
Top