User login
Login with your MaplePrimes or Maplesoft.com account
Poll
How to perform immediate output from a procedure?
20Categories:
f:=proc ()
local s;
s := time();
FileTools[Text][WriteString]('default', "a");
FileTools[Flush]('default');
while time() < s+20 do end do
end proc;
f();
In the codes aboveFileTools[Text][WriteString] is called. But in execution, the output does not appear until 20 seconds elapse.
How can I force the output appear immediately?
In fact
, I have a long program from which I expect fast progress reports, but due to the phenomenon above, the reporting cycles are not satisfactory (too long).
Announcements
Recent blog posts
- Job offer / Stellenangebot: Technischer Support Maple
- Table from procedure
- Maple Mentor Awards: The Big Kahuna
- The actual architecture
- new package adoption
- Conjectures ripe for Maple experimentation
- overloaded operators
- poll: change in Maple that you want most?
- The future of FourierTrigSeries package
- Maple 12.01 is now Available
Recent comments
- to Robert Israel:
yes,
51 min 11 sec ago - to acer:
Yes, it is
1 hour 5 min ago - I agree
1 hour 13 min ago - simpler
1 hour 26 min ago - Not that way
1 hour 45 min ago - Eigenvectors
1 hour 55 min ago - Thanks, acer,
I find another
3 hours 3 min ago - interesting idea
6 hours 5 min ago - interesting
6 hours 8 min ago - The answers
9 hours 16 min ago
print
It works with a simple print statement.
Your version will also work in command-line Maple.
Thank you! But print
Thank you! But print inserts line-break after each call. Therefore, it cannot generate a compact output.
For example:
A: 1 2 3
B: 1 2 3 4
The numbers are expect to be outputed gradually and immediately after the number is processed. Namely, it is expected as if the following three strings appear in a single line at different time.
A: 1
A: 1 2
A: 1 2 3
fprintf
Can you use fprintf or printf? Those won't insert a line break unless you explicitly include it ("\n").
acer
I tried all them. But they
I tried all them. But they do not appear in time.
try closing the file
You may need to close the file before the wait loop in order to read the contents right away. The flush that you are using, may not be doing it's job.
In a windows application, even if the buffers are flushed, I've had the flush fail on occassion.
Since you are appending, you should be able to open and close as often as you want. You can also just add a several writes with waits between, with time-stamps. Then rather than look at the file during the long loop, just wait until it's all done and then look at the time-stamps to comfirm operation.
Well, the default file
Well, the default file cannot be closed, because it is the screen.
The loop in practice takes several hours (may be 10 or more) to run. Therefore I have to make sure that it is working in a desired way. I do not expect to find some thing wrong only after 10 hours. Therefore, immediate output is expected. I have more than 700 input files to process, and they will generate more than 80,000 output files in total. I have to monitor the process. Also I expect to do monitoring in a compact format.
afante - possible solution
This kinda bothered me, so I tried a few things. Below is something that works - even though it's a little weird. You will need to be in document mode where you create a TextArea from the available components. The default name for the first TextArea is TextArea0. Then:
f := proc () local s;
use DocumentTools in
s := time();
while time() < s+10 do
t2 := time():
while time() < t2+1 do end do;
SetProperty('TextArea0', 'value', cat(GetProperty('TextArea0', 'value'), "a "))
end do:
end use
end proc; f();
I gave it a try just to make sure it works.
Didn't work for me
Hmmm. this didn't work for me: the TextArea stayed blank until the very end, then suddenly filled with a's. I tried it under both Windows Vista and Ubuntu Linux.
maple 11
I'm using maple 11 on WinXP. The a's appeared in the box at 1 second interval for 10 seconds. I wonder why it would be different in your version or in another OS.
11 vs 12
I can confirm: it works in Maple 11.02, not in 12.0 (in this case both under Windows XP).
I suspect the change is due to efforts to address the performance issues that have plagued the Standard GUI ever since its introduction. One way to improve performance is to prevent unnecessary redrawing. Only in this case the redrawing was necessary.
now I'm confused
Unless I'm misinterpretting something, Doug has mentioned further down that the TextArea0 does indeed update prior to the function returning, with Maple 12 in WinXP and you are saying it doesn't.
My interpretation of all this is:
1.) The original poster of this thread, wanted to have a procedure with a loop that he could call once, and let it run for up to ten hours or so. Within that loop would be some processing, as well as a visible update somewhere (preferably the screen) to indicate the processing was occurring.
2.) The sample I showed, could do that, but only by writing to a TextArea.
3.) My example would run forever, all the while being able to update a textarea at particular intervals. However, it worked for me in Maple 11 within WinXP, but not for you in WinXP with version 12. But a similar loop scenario worked for Doug with Maple 12 in WinXP. I'm confused about all this.
Please try my worksheet: 2timv.com/math/maple/loopTest/loopTest.zip using Maple 12 in WinXP and let me know if BEFORE the function call returns, the TextArea updates with a's every second or so. This might help clear up some of the confusion in my mind.
updated - I just made the file above a .zip file because it was being changed from a .mw to a .xml by this forum's formatting.
No confusion: see same result with Maple 12
No. I see the same behavior as the others. With Maple 12, under WinXP, all output appears at the end. With Maple 11, one letter appears every second.
Doug
thanks Doug
I really appreciate you giving that a try. That information with what Robert had mentioned about the reason for changes to the functionality in Maple 12 makes sense now. I'm not crazy about the change, but it does explain the change.
The only problem now, is that it puts us (or me at least) back at square-one concerning trying to visibly show activity while within the loop and prior to returning from the function - if I were to use Maple 12.
I suppose something else rather unusual could be done, such as writing the information to a disk file as previously suggested, and then adding to that, the spawning of a second process to read and display the contents of that file periodically while the loop within maple was running. Do you have any ideas?
try using a maplet
Have you thought about using a maplet?
In the maplets I have written I know I have seen delays in when certain updates are made. I always thought this was due to the processing that was being done between the times when the GUI updates were done. I know I've seen this in Maple 12.
If this is correct, I'm guessing that you could achieve your desired goal by implementing it within a maplet.
Unfortunately, right now I do not have the time to create such a maplet. If I get some time later, and before someone else does it, I'll see if I can't put together a quick demo that can be used to test this functionality.
Doug
display the contents of that file
That can be done continuously from the console using the 'tail' command like:
tail -f filename
It can be done also on Windows as there win32 implementations of 'tail'.
I do not see this way of logging to be unusual but quite standard, faster, easier, and more reliable.
error boxes
Executing these lines I get a lot of error boxes with messages like:
Attempted to set property of unknown component 'TextArea0'
or with retrieve instead of set. This is Maple 12 on Win XP
need textarea
That would happen if you didn't create the TextArea prior to executing that code.
More evidence, in Maple 12 and worksheet mode
I am using Maple 12, in worksheet mode. You can add an embedded component to a worksheet just as easily as to a document.
For me the output appears only at the end of the loop. I've done some more testing, and it appears to me that updates are done once for each execution group. It's not the end of the function call, as the following shows (it matters not whether f3 is local to f2 or global):
f2 := proc (T) local f3, s; f3 := proc(TT) local t; use DocumentTools in t := time(): while time() < t+TT do end do; SetProperty('TextArea0', 'value', cat(GetProperty('TextArea0', 'value'), "a ")) end use end proc; s := time(); while time() < s+T do f3(1) end do; end proc:Remember to clear the contents of the TextArea before calling f2 to make it easier to see the new output.
Now, in a single execution group, try executing (hitting enter once):
and compare this to what you get if you execute the same sequence of commands in separate execution groups (hit enter twice):
You might want to clear the contents of the TextArea from time to time to make it easier to see the results.
I'll have to give this some more thought. But, first, I have a couple of classes to teach.
Doug
nice example Doug
That was a nice example Doug - thanks. I was aware of the components in worksheet mode. What I was implying by the document mode, was to not use the classic worksheet, which is what I think of when I think "worksheet", and which I use a lot when I'm not in document mode of the standard maple GUI.
I got the same results as you did, with each update being done at the end of a loop, but before the function returning. What OS are you running?
Maple 12, Windows XP
And, here is the worksheet that I developed to test this.
View 178_TextAreaOutputTest.mw on MapleNet or Download 178_TextAreaOutputTest.mw
View file details
Doug
worked fine
The worksheet worked fine for me. However, having f2(1) in the example instead of something like f2(5) seemed to somewhat obscure the fact that the TextArea0 was updating after each loop rather than waiting until the function returned. I think this is the behavior the original poster was looking for. I wonder why it doesn't work correctly in Maple 12 within WinVista as indicated by Robert Israel.
my worksheet
Not sure how to put it here, so below is a link. I guess you need to right-click and do "save target as":
2timv.com/math/maple/loopTest/loopTest.zip
I just updated the link from a .mw to .zip, because the forum code was changing my file linked to from .mw to .xml. It seems like I'm really adding confusion to this thread - sorry.
Maplet
Try it with a Maplet, like this:
G:= proc() local s,t; s:= time(); Maplets:-Tools:-Set(TB1(value)=""); while time() < s + 10 do t:= time(); while time() < t+1 do end do: Maplets:-Tools:-Set(TB1(append)="a"); end do; Maplets:-Tools:-Set(TB1(value)="Finished"); end proc; with(Maplets[Elements]): maplet := Maplet([[ TextBox['TB1'](""), Button("Go", Action(Evaluate('function'='G()'))), Button("Done", Shutdown()) ]]): Maplets[Display](maplet);Exactly!
Thanks Robert. This is exactly what I had in mind. And, it works as requested - even in Maple 12.
It should now be possible to replace the procedure G with your 10-hour job. Of course, you could also use the maplet to set other parameters for the problem or to display other intermediate results. Robert's contribution shows that this is possible.
Doug
Slider
Instead of a TextArea, you could also use a Slider, something like this:
G2:= proc() local s,t; s:= time(); while time() < s + 20 do t:= time(); while time() < t+1 do end do: Maplets:-Tools:-Set(SL1(value)=round(t+1-s)); end do; end; with(Maplets[Elements]): maplet2 := Maplet([[ Slider['SL1'](0..20,showticks,'majorticks'=10, 'minorticks'=1), Button("Go", Action(Evaluate('function'='G2()'))), Button("Done", Shutdown()) ]]): Maplets[Display](maplet2);Unfortunately, the new components introduced in Maple 12, such as Volume Gauge and Rotary Gauge, are not in the Maplets package.
maplets and embedded components
The development of maplets appears to have slowed considerably. More efforts have been directed towards embedded components. Unfortunately, there are still many things that cannot be done with embedded components. Personally, I think I'd make more use of embedded components if I could do most of the things I can do in a maplet.
This particular example is one where there is a performance difference between maplets and embedded components - and the maplet is more powerful in the hand of a knowledgeable user.
But, I'm getting off topic and I still have too many other things that I should be doing right now.
Doug
more with maplets
With this discussion in mind, I'm going to become better acquanted with maplets - something I've worked with very little. I agree with you about a preference for embedded components over the maplets, but am now quite skeptical about their continued functionality. Thanks for sticking with this thread - helping to bring about this final resolution
Were bug reports filed?
There clearly seem to have been multiple important bugs identified in this thread -- have they been filed?
at least two
As far as the central issue discussed here goes, I'll do that now. I've already discussed it in person with the people who should know about it. It's better to have a duplicate SCR than to miss it altogether.
I'm talking about the loss of functionality between Maple 11 and 12, for updating a embedded component TextArea using either FileTools:-Text:-Write's default handle or printf and friends. That is a regression.
Sure, one could use `print` or `lprint` or even userinfo and get staggered intermediate output from a running procedure as described in this thread. But those all insert a line break.
It could be nice if the worksheet itself (not an embedded component or Maplet) could also gain this functionality.
I'll enter these two separately.
Dave Linder
Mathematical Software, Maplesoft
my preference
In reference to the possibility of a worksheet gaining the functionality, that may be a fine addition to the embedded component fix. However, my preference is the embedded component. If it was output to the worksheet, and if there were much output, I think a constant redraw of the worksheet as may occur with this sort of thing, would be very distracting. The really nice thing about the embedded text component, is that it can be sized, the output sent to it, and then it can be scrolled to view the output. A "floating" component, in my opinion would be even nicer. That way it could be placed conveniently anywhere on the screen.
I wonder if anyone else has a preference?
An independent window
would be much more useful. For logging, context information, etc.