Re^4: Debugger Bug?

Sure, turning on AUTOFLUSH helps!

  DB<1> $| = 1
 
  DB<2> x print "horst"
horst0  1
  DB<3> p print "horst"
horst1
  DB<4>  print "horst"
horst
[download]

But it's strange that only x doesn't flush automatically while other commands do ...

  DB<5> $| = 0
 
  DB<6> x print "horst"
0  1
  DB<7>  print "horst"
horsthorst
  DB<8> p print "horst"
1horst
[download]

Cheers Rolf

Comment on Re^4: Debugger Bug? Select or Download Code

Replies are listed 'Best First'.
Re^5: Debugger Bug? (who cares?) by tye (Sage) on Sep 03, 2009 at 02:08 UTC
But it's strange that only x doesn't flush automatically Not any stranger than using `x` and print together. I'm not terribly surprised that this particular combination was not "expected". In any case, the code in question is: `# Turn off the one-time-dump stuff now. if ($onetimeDump) { $onetimeDump = undef; $onetimedumpDepth = undef; } elsif ( $term_pid == $$ ) { eval { # May run under miniperl, when not ava +ilable... STDOUT->flush(); STDERR->flush(); }; # XXX If this is the master pid, print a newline. print $OUT "\n"; }` [download] - tye	[reply] [d/l] [select]
Re^6: Debugger Bug? (who cares?) by LanX (Saint) on Sep 03, 2009 at 08:42 UTC
Not any stranger than using x and print together. Maybe this example is easier for you to "accept" as a use case? `DB<1> sub doit { print "test"; return 1..3} DB<2> x doit() 0 1 1 2 2 3 DB<3> test DB<3> p doit() 123test` [download] As I updated in the OP, when you are using the debugger as a REPL, these inconsistencies are strange enough to care for. Cheers Rolf	[reply] [d/l]