[Mark SiblyKeymaster]

Probably not much more I can do until I can reproduce it.

That’s the bummer about linux – it’s like supporting 10 OS’s at once!

is equivalent to

yep, these are all effectively the same:

Local t:Int[]
Local t:Int[]=New Int[0]
Local t:Int[]=null

[Mark SiblyKeymaster]

Also, can you email me the crashing version of ted2, ie: the ‘bin/ted2_linux/ted2’ file?

Argh, you probably can’t ‘coz I’m on gmail – can you stick it somewhere I can download it?

[Mark SiblyKeymaster]

Can you try rebuilding all using ‘-O2’ optimizations instead of ‘-O3’? If it still fails, try ‘-O1’.

Are your OS, compilers etc up to date?

[Mark SiblyKeymaster]

Can you enter ‘bt’ into gdb after the crash for a backtrace?

[Mark SiblyKeymaster]

is the field declaration sufficient to allocate memory for an empty array?

Yes, a ‘null’ array in mx2 is really just an array of length 0, ditto strings.

Had a quick look at the code and it seems OK, so this may just be a symptom, not the cause. And if code *was* trying to read from an empty array, all hell should break loose on all platforms!

[Mark SiblyKeymaster]

Ok, gave address sanitizer a go, using “-g -fsanitize=address” for compile/link.

Ted2 starts and runs fine with this, but locks up HARD for about a minute at exit before print ing’killed’ and fnally ending.

Should the sanitizer thing be showing some output?

[Mark SiblyKeymaster]

I think monkey2 on Linux uses OpenAL configured

mx2 uses the distro version of openal on linux.

I have no idea what is causing that memory access violation.

Works fine here, but I just tried to valgrind it and it crashed valgrind with an internal error. It did get as far as opening a window and printing SDL_GOT_FOCUS. Is this where it crashes for you?

Next thing I’d suggest trying is adding symbols to release mode via the -g flag  (in bin/env_linux.txt), eg:

Monkey

'LD options MX2_LD_OPTS_LINUX= MX2_LD_OPTS_LINUX_DEBUG= MX2_LD_OPTS_LINUX_RELEASE=-g -O3 'C compiler options MX2_CC_OPTS_LINUX=-std=gnu99 MX2_CC_OPTS_LINUX_DEBUG= MX2_CC_OPTS_LINUX_RELEASE=-g -O3 -DNDEBUG 'C++ compiler options MX2_CPP_OPTS_LINUX=-std=c++11 MX2_CPP_OPTS_LINUX_DEBUG= MX2_CPP_OPTS_LINUX_RELEASE=-g -O3 -DNDEBUG

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

'LD options MX2_LD_OPTS_LINUX= MX2_LD_OPTS_LINUX_DEBUG= MX2_LD_OPTS_LINUX_RELEASE=-g -O3   'C compiler options MX2_CC_OPTS_LINUX=-std=gnu99 MX2_CC_OPTS_LINUX_DEBUG= MX2_CC_OPTS_LINUX_RELEASE=-g -O3 -DNDEBUG   'C++ compiler options MX2_CPP_OPTS_LINUX=-std=c++11 MX2_CPP_OPTS_LINUX_DEBUG= MX2_CPP_OPTS_LINUX_RELEASE=-g -O3 -DNDEBUG

You’ll need to rebuild all modules and ted2 after changing this file.

You should then be able to debug it with gdb:

Monkey

cd bin/ted2_linux gdb ./ted2 [type 'run' in gdb]

1 2 3

cd bin/ted2_linux gdb ./ted2 [type 'run' in gdb]

If that fixes it, you’re boned.

If not and you still can’t see where the problem is, try removing ‘-DNDEBUG’ and/or reducing ‘-O’ level until it’s the same as debug, ie: 0.

[Mark SiblyKeymaster]

That *would* change self’s size though, it’d change it to r’s size!

Monkey

#Import "<std>" Using std.. Function Main() Local r1:=New Recti( 0,0,20,30 ) Print r1.Size Local r2:=New Recti( 100,100,140,160 ) r1=r1.Centered( r2 ) 'center r1 within r2 - only moves it. Print r1.Size 'same size! End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#Import "<std>"   Using std..   Function Main()   Local r1:=New Recti( 0,0,20,30 ) Print r1.Size Local r2:=New Recti( 100,100,140,160 ) r1=r1.Centered( r2 ) 'center r1 within r2 - only moves it. Print r1.Size 'same size! End

[Mark SiblyKeymaster]

I think it’s right – centering a rect doesn’t change its size, just it’s location.

[Mark SiblyKeymaster]

Monkey

canvas.Color=Color.None 'same as 0,0,0,0 canvas.BlendMode=BlendMode.Opaque 'NO blending canvas.DrawPixel(...)

1 2 3

canvas.Color=Color.None 'same as 0,0,0,0 canvas.BlendMode=BlendMode.Opaque  'NO blending canvas.DrawPixel(...)

[Mark SiblyKeymaster]

DrawPixel?

[Mark SiblyKeymaster]

Awesome work!

It starts at 24M of Ram and it grows to 36M but then stops.

Yes, this is the GC at work.

If you want, you can put a GCCollect() at the bottom of OnRender() or somewhere called frequently. This will slow things down a bit, but it gives you a much better idea of how much memory is really required by the app, and whether there are any leaks.

[Mark SiblyKeymaster]

Ok, just had a quick play and this works pretty well for me:

Monkey

Function Yield() Local future:=New Future<Bool> App.Idle+=Lambda() future.Set( True ) End future.Get() App.RequestRender() End Function LoadGraphics:Image( path:String ) Local progress:=New ProgressDialog( "Loading..." ) progress.MinSize=New Vec2i( 320,240 ) progress.Open() Local image:Image For Local i:=0 Until 250 If image image.Discard() progress.Text="Loading image "+i image=Image.Load( path ) Yield() End progress.Close() Return image End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

Function Yield()   Local future:=New Future<Bool>   App.Idle+=Lambda() future.Set( True ) End future.Get() App.RequestRender() End   Function LoadGraphics:Image( path:String )   Local progress:=New ProgressDialog( "Loading..." ) progress.MinSize=New Vec2i( 320,240 )   progress.Open() Local image:Image For Local i:=0 Until 250 If image image.Discard() progress.Text="Loading image "+i image=Image.Load( path ) Yield() End progress.Close() Return image End

Note: this MUST be run on a fiber, or you’ll get a ‘can’t suspend GUI fiber’ error. This means it should also set a ‘loadingFinished’ flag or something similar when it’s done.

All it does is load the same image a bunch of times, but the progress dialog updates and can be dragged around.

It’s not the *ideal* solution – you shouldn’t need to manually ‘Yield’ – but I think it’s acceptable until I get a chance to do more work on this.

[Mark SiblyKeymaster]

C++ allows you to pass a ‘value’ to a ‘value&’ param, although you need to be a bit careful as unless it’s a ‘const value&’ the c++ code can modify the value you pass it.

So if the c++ interface looks like this:

Monkey

void blah( int &r );

1 2	void blah( int &r );

…then it’s possible that after calling this…

Monkey

Local i:=10 blah( i )

1 2 3

Local i:=10 blah( i )

…that i no longer contains 10!

However, with this:

Monkey

void blah( const int &r );

1 2	void blah( const int &r );

You can be sure blah does not change the value of ‘r’, thanks to the ‘const’ prefix.

(Also, you can replace ‘int’ in all these examples with any custom struct name and the same applies).

You can think of  ‘&’ (reference) params as being very similar to pointers, only the compiler does the ‘varptr’ bit for you automatically (which implies arguments must be variables or you can’t varptr them), eg: this…

Monkey

void blah( int *i );

1 2	void blah( int *i );

 

Monkey

Local i:=10 blah( Varptr i )

1 2 3

Local i:=10 blah( Varptr i )

…will actually produce very similar/identical assembly code to the first example above, so you can see how it’s possible for blah to modify ‘i’ as it really has a pointer to ‘i’.

Probably just confused things there…

[Mark SiblyKeymaster]

Quick idea: add an App.RequestRender() to the bottom of Yield().

But what is it, where does it live.

‘On the stack’, really. Fibers are very similar to threads in that each has its own stack and set of CPU registers, only fibers *never* switch ‘behind your back’ the way threads do. A little old, but more info here:

http://monkey2.monkey-x.com/2016/02/01/func-with-fibers/

Does App.Idle resets itself after a loop ?

Yes, anything you add to App.Idle is only called once, so you need to keep ‘re-adding’ idle handlers if you want them to keep being called.

Inside the Yield() function above, I can change every runtime variable, this within a loop or process that is running at the moment ?

Yes, fibers execute in the same address space so they have access to the same globals etc.

 

I think that in the near future you need to make the gui async , on a other thread or something if you want that many people make applications with monkey.

Nope, the fiber based GUI rocks (and is a common ‘modern’ approach). The problem here is that LoadImage etc. ‘block’. Solving that the way I did with processes and tcpstreams should be quite easy for me to do, and would solve your problems here without you having to change anything.

On the other hand, having a progress dialog running on one thread while loaders run on another is a vastly more complex proposition, as suddenly things need to be synched via mutexs, semaphores. Threads are HARD, and I think the GUI does an excellent job of shielding users from having to deal with them, although obviously there are still ‘holes’ in what is fully supported.

IMO, Ted2 achieves a remarkable level of apparent parallezation (eg: you can type in textviews while programs are building etc) thanks to the fiber system, as you don’t have to really think about synchronization at all (almost anyway) the way you do with threads. In fact, far more works ‘in parallel’ in Ted2 than probably should, but I didn’t design that way, it just works!

Which is not to say threads aren’t useful – being able to load data on a thread is useful. But it’ll be considerably tricker as you’ll have to start dealing with mutexs, semaphores etc. I am personally interested in being able to run OnRender ‘on a thread’, or physics etc – which is another reason that it’s nice for the GUI to use as *few* threads as possible, as it saves threads (ie: cores) for rendering, physics etc. But that’s a way of yet…!

[Author]

Posts