[Mark SiblyKeymaster]

Forgot to also mention, you cannot modify ‘captured’ variables inside a lambda, ie: this should give an error:

 

Monkey

Function Test() Local t:=0 Local f:=Lambda() t=1 'Error! 't' cannot be modified here. End End

1 2 3 4 5 6

Function Test()    Local t:=0    Local f:=Lambda()       t=1   'Error! 't' cannot be modified here.    End End

A lambda effectively gets a ‘copy’ of outer locals at the time the lambda is evaluated. So this..

Monkey

Function Test() Local t:=0 Local f:=Lambda() Print t End t=1 f() End

1 2 3 4 5 6 7 8

Function Test()    Local t:=0    Local f:=Lambda()       Print t    End    t=1    f() End

…will print ‘0’.

[Mark SiblyKeymaster]

Mark, have you thought about a page system and designer?

I think it’s a great idea, but probably a bit much for me to take on right now.

[Mark SiblyKeymaster]

Nope.

[Mark SiblyKeymaster]

You need to declare ‘str’ before the lamba, not after.

[Mark SiblyKeymaster]

Strings are allocated from the heap, but are reference counted instead of GC’d.

[Mark SiblyKeymaster]

I don’t know how they work under the hood but I think of structs as primitive types.

This is probably the best way to think of them, and they do in fact work very much like primitive types under the hood, eg:

Monkey

Struct MyInt Field value:Int End Local t1:Int Local t2:MyInt

1 2 3 4 5 6

Struct MyInt    Field value:Int End   Local t1:Int Local t2:MyInt

Here, both t1 and t2 will both take 4-ish bytes of stack memory (the size of the ‘int’ struct might end up being aligned) and both will ‘disappear’ when the statement block ends (so using Varptr with either is dangerous!).

Both are also ‘copied’ when assigned to variables or passed to or returned from functions.

Where things get perhaps a little confusing is with…

Monkey

Local t3:=New MyInt

1	Local t3:=New MyInt

Since MyInt is a struct not a class, the ‘new MyInt’ bit doesn’t actually allocate ‘heap’ memory – it creates a new temporary MyInt (on the stack) that is then copied to t3. Which is actually quite similar to what this does…

Monkey

Local t4:=5+10

1	Local t4:=5+10

This also creates a temporary int to store the result of 5+10 in (ie: 5+10 is a ‘new Int’), which is then copied to t4.

But really, apart from this wrinkle there’s nothing really that magical about structs – it’s pointers that are the tricky ones!

(Note also that when I say ‘on the stack’, this really just means logically on the stack. Compilers generally try to store as much as possible in cpu registers (which are really another form of stack storage) and this applies to structs as much as ints etc. So code like “Local t3:=New MyInt” may well reduce down to a single move instruction to a cpu register).

Structs and primitives also act the same way when it comes to arrays:

Monkey

Local a1:=New Int[100] Local a2:=New MyInt[100]

1 2	Local a1:=New Int[100] Local a2:=New MyInt[100]

Both of these will allocate about 400 bytes of heap memory (all arrays are stored on the heap regardless of whether the elements are primitives, structs or classes).

And in both cases, Varptr a[i+1]-Varptr a[i] will be 4, ie: the values are stored consecutively in memory.

So structs and primitive types are actually very very similar concepts.

As for…

Monkey

Struct Vector3 Field data:= New Float[3] End

1 2 3 4

Struct Vector3 Field data:= New Float[3] End

This should in fact be causing a compile time error – something along the lines of ‘struct field initializers must be constant’ (another related story…) – if not, there’s a bug or you’re not using the latest version of mx2cc.

[Mark SiblyKeymaster]

Just use libc.exit_( whatever ) directly.

[Mark SiblyKeymaster]

I had a quick look through but I don’t I’ll be able to use any of the mojox stuff.

The problem is (as far as I can tell anyway) too much of it is hard coded in. For example, buttonx uses literal rects/colors etc everywhere.

On of the goals with the gui is to create something people can use for their own games, which means they need to be able to tweak as much as possible.

This means padding rects, colors, icons etc need to be variables of some sort, and preferably collected together so they are easier to tweak. The mojox/theme.monkey2 file was my temporary solution to this but has been superceded by a much nicer ‘theme.json’ config file in the new mojox.

I’m a bit curious why you duplicated the code for ‘TreeView’ in codetreeview – was there some reason you couldn’t just extend TreeView.Node? This is what I’ve done in debugview/helpview and it turned out to work surprisingly well. Or is it just another case of ‘no docs’?

DrawImageIcon is possibly a useful addition to mojo, although it can also be achieved with DrawRect( x,y,w,h,image,sx,sy,sw,sh ). In future, when mx2 gets the ability to add methods to classes, you’d be able to implement DrawImageIcon without having to add more stuff to canvas.

Everyone’s likely to have their own ‘must have’ version of DrawImage etc. If there’s enough demand for one in paticular I’d consider adding it, but it’s a ‘one off’ request and can be implemented without disturbing canvas it probably wont happen.

I like the new Color consts and think they would make a nice addition – although ‘Phlox’?!?

I don’t think the Key.Command addition is necessary – the ‘Gui’ key basically means ‘the key between Control and Shift’ and I’m fine with that. My Ps2 keyboard (still going!) has a ‘PS’ key for the Gui key – should I add another enum for that? I don’t think so…

What is probably sorely needed though is something like:

Monkey

#If __TARGET__="macos" MenuCmd=Gui #Else MenuCmd=Control #Endif

1 2 3 4 5

#If __TARGET__="macos"    MenuCmd=Gui #Else    MenuCmd=Control #Endif

…to make setting hotkeys for menus easier.

Nice work in general though! I’m amazed anyone has been able to do anything useful with mojox considering it is completely undocced and fairly underdeveloped so I understand it can’t have been easy to do what you’ve done.

The new mojox will have SOME docs at least so hopefully my apparently ‘weird’ approaches to some stuff will make more sense.

[Mark SiblyKeymaster]

No ETA at the moment sorry.

Get back to work on diddy in the meantime!

[Mark SiblyKeymaster]

I agree that String could do with some more methods, though I’m not too keen on the ‘L’ ‘R” names – how about…?

Dup:String( num:Int )

TrimStart:String()

TrimEnd:String()

Pad:String( len:Int,padding:String=” ” )   ‘centers string…? Symmetry with Trim()…

PadStart:String( len:Int,padding:String=” ” )

PadEnd:String( len:Int,padding:String=” ” )

I’m thinking ‘Start’ ‘End’ instead of ‘Left’ ‘Right’ here to go with StartsWith and EndsWith, but ‘Left’ and ‘Right’ would also work.

Not quite sure how padding:String works – Duped as much as necessary? – but it’d be nice to allow for more than just padding with spaces.

I did consider allowing String * Int for Dup, but with the relaxed type conversions was a bit worried it could too easily trip people up. Still an option though…?

[Mark SiblyKeymaster]

How does it use emscripten when emscripten requires LLVM bytecode and Monkey2 compiles using gcc?

Emscripten provides a full clang c++ toolchain for translating c++ -> llvm.

1. Does Ted2 use OpenGL for rendering?

Sort of. Mx2 uses the gles20 api for all rendering at the moment, but on Windows this is converted to d3d9/d3d11 via the ‘angle’ library.

1. Performance wise… a blank canvas gives about half FPS that a blank canvas in BlitzMax would create.  Is that something to be concerned about?  Will the performance ratio be similar compared to BlitzMax (0.5x)?

Hopefully not!

[Mark SiblyKeymaster]

Local blendMode:=BlendMode.Alpha *should* work – definitely a bug.

Can you post this in ‘issues’ at github Richard? Just copy and paste of the original post is fine.

[Mark SiblyKeymaster]

Sure – are they up at github yet?

[Mark SiblyKeymaster]

@mark, any idea when the zip module might be ready to use?

Very soon!

I have a simple std.zipfile module already going, but all it can really do is ExtractZip( zipFile,dstDir ).

I’ll be adding support for extracting individual files and subdirs too, but if all you need is ExtractZip I can commit ASAP.

[Mark SiblyKeymaster]

I’m actually in the process of cleaning up mojox and turning it into a ‘real’ module – results should be out within a week or so.

[Author]

Posts