El vie., 5 jun. 2020 a las 22:32, ToddAndMargo via perl6-users (<perl6-users@perl.org <mailto:perl6-users@perl.org>>) escribió:

    On 2020-06-05 13:06, Peter Pentchev wrote:
     > On Fri, Jun 05, 2020 at 11:32:20AM -0700, ToddAndMargo via
    perl6-users wrote:
     >> Hi All,
     >>
     >> Windows 10 Pro
     >>
     >> raku -v
     >> This is Rakudo version 2020.05.1 built on MoarVM version
     >> 2020.05 implementing Raku 6.d.
     >>
     >> I had a weird symptom calling Raku from Cobian Backup.
     >> A black box popped up, delayed about two seconds,
     >> then died.  The only writing was the flashing cursor.
     >>
     >> Running the program directly from a shell showed
     >> that I had a directory in "lib" that did not
     >> exist on the customer's machine:
     >>
     >> use lib 'K:/NtUtil', 'C:/NtUtil', '.';
     >>
     >> Edited out the missing directory and happy camping returned.
     >
     > What is the window title of that "black box"? Is it possible that
    it is
     > a command prompt that is actually your program, and that it took
    longer
     > to run because of something like trying to access a network drive or
     > something? (note: I have not run Windows in about ten years, I
    have no
     > idea how it behaves when you try to access a drive letter that
    does not
     > correspond to a currently mapped device or share).

    Hi Peter,

    It was "Raku".

    And I did check the result of what was suppose to have
    happened and it did not.

    I had a little tiny panic attack as I had spend endless
    hours on that program just to have it not interface
    with Cobian.

    After correcting my "usr lib", all the text that
    was suppose to show (as showed in a shell) did
    show up i the Raku black box.

    Trivia:  this is how Cobian calls my program:

    COMMANDLINE,"C:\rakudo\bin\raku.exe C:\NtUtil\CobianWrapper.pl6
    --rotates 20 --backup_path [BACKUP]\MyDocsBackup\backup1",true

    -T

On 2020-06-06 00:13, JJ Merelo wrote:
Since Raku is running CompUnits besides compiling them, it might be that there was some CompUnit creating a window in the path. Since you've been talking about GTK lately, something doing that might be left over and if it was used by something along the path, it might have been compiled, thus run, and popped up. It's probably not a good idea to open Windows in a CompUnit, as opposed to the main program.

JJ

Hi JJ,

I have no idea what you are talking about.  :'(

I have not implemented an GTK things in Windows yet.

The report here was that an error in the code did not
show in the pop up window, but did show from a shell.
When the error was corrected, all the text that showed
in the shell also showed up in the pop up.  I was
just warning everyone about a "quirk".  I was not
asking for help.

And in the instance, I want to see the pop up.  Other
I do not and I have posted an RFE on that.

-T

Reply via email to