Bug in os.Args?

Hi!

I wanted to try Gold and made some very basic command line apps. When i tried to access os.Args i ran into troubles: it seems to allways return an empty array on island widows (while working fine for .net).

Is this a known bug?

Thanks

Not a known bug, But certainly looks like a bug; I’ll have this looked at ASAP.

Thanks, logged as bugs://84090

Thanks a lot, Marc.

1 Like

Of course!

BTW it seems there is also a problem with “time” on island windows. This code :

start := time.Now()
time.Sleep(200 * time.Millisecond)
t := time.Now()
fmt.Printf("Elapsed: %v mcs.\n", t.Sub(start).Microseconds())
fmt.Printf("Elapsed: %v ms.\n", t.Sub(start).Milliseconds())
fmt.Printf("Elapsed: %v ms.\n", t.Sub(start).Seconds()*1000)

displays :

Elapsed: 20 mcs.
Elapsed: 0 ms.
Elapsed: 0.0203 ms.

While compiled for .net it prints the correct :

Elapsed: 201246 mcs.
Elapsed: 201 ms.
Elapsed: 201.2467 ms.

From an external timer it looks like both apps sleeps for about 200ms.

So Sleep works correctly, “just” either t.Sub() seems to be broken? Logging.

Thanks, logged as bugs://84092

I’ll make sure both pf these get looked at tomorrow.

Yes, Sleep seems to work corectly. Changing the value is correctly reflected in the total run time measured externaly.

No emergency here, but thanks again! :clap: :+1:

1 Like

Guess this explains it somewhat:

var Args: go.builtin.Slice<go.builtin.string> := {$IF ISLAND}new go.builtin.Slice<go.builtin.string>(''){raise new NotImplementedException}{$ELSEIF ECHOES}go.builtin.string.PlatformStringArrayToGoSlice(Environment.GetCommandLineArgs){$ENDIF};

:joy:

workaround for now: if you define your main() menthod to accept a string array, you should get the arguments there, ok.

1 Like

bugs://84090 got closed with status fixed.

1 Like

This was fixed, but I’m afraid we neglected to run a new full release build of GBL (which takes a long time :wink: prior to starting todays build, so 2497 will not have this fix. I can sen you a copy of the fixed GBL tomorrow (or you can build it yourself from github of course; I recommend only building the target you need, then, to seep it up ;).

1 Like

Again, thanks a lot Marc. Nothing blocking here for me, I’m just playing and learning so I will explore other parts of Element during the next week (if time permits). :slightly_smiling_face:

1 Like

bugs://84092 got closed with status fixed.

Back to the game after a pause, and purchasing a (personal) licence. The numbers are now good on Windows, but the last attempt to display makes the program block (using 10.0.0.2509).

func main() {
    start := time.Now()
    time.Sleep(200 * time.Millisecond)
    t := time.Now()

    // OK
    fmt.Printf("Elapsed: %d mcs.\n", t.Sub(start).Microseconds())
    fmt.Printf("Elapsed: %d ms.\n", t.Sub(start).Milliseconds())

    // Possible hint at the bug cause
    fmt.Printf("%T \n", t.Sub(start).Milliseconds()) // -> go.builtin.int64
    fmt.Printf("%T \n", t.Sub(start).Seconds())      // -> RemObjects.Elements.System.Double

    // Program hangs !
    fmt.Printf("Elapsed: %f ms.\n", 1000*t.Sub(start).Seconds())
}

Tested it with 2517 and the behavior is the same.

Renaud,

My apologies; it seems I missed rour last reply, and that issue was never logged. doing now.

1 Like

Thanks, logged as bugs://84358

bugs://E24152 was closed as fixed.