[Mark SiblyKeymaster]

Nasty compiler bug!

Will fix, but String( e._instance ) will fail anyway as you can’t convert an object to a string.

 

 

[Mark SiblyKeymaster]

Have a look at this:

http://monkey2.monkey-x.com/2015/09/09/monkey1-to-monkey2/

 

[Mark SiblyKeymaster]

Just added Mouse.PointerVisible:bool property.

 

[Mark SiblyKeymaster]

Negative step should be working now.

I think I will re-add the ‘c’ style ‘for’ that used to be in there though as it’s the most flexible.

 

[Mark SiblyKeymaster]

I did consider an entirely new name, but nah…mojo is fine.

[Mark SiblyKeymaster]

I’ve been at it for a while here and after updating Emscripten I get the error listed below

I can only guess you’ve got it installed/setup wrong – it looks like it’s trying to build for ‘NACL’, the old google ‘native API’ plugin system.

I’ve just updated/activated to ‘latest’ and it’s tricky – you also need to ‘source emsdk_env.sh’ each time you use it which adds a bunch of paths. it didn’t work just adding this to ‘~/.profile’ so I ended up hard-copying the PATHs and other stuff that ‘source emsdk_env.sh’ adds directly to ‘~/.profile’.

Anyway, 1.36 is now going. When I go ’em++ -v’ from the shell I get:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 1.36.0
clang version 3.9.0 (https://github.com/kripken/emscripten-fastcomp-clang/ 271ce598c3d1fe74efadc254f5be1b57edea9f41) (https://github.com/kripken/emscripten-fastcomp/ 61acfb230665464544f2e8db292f8999fc3c628c) (emscripten 1.36.0 : 1.36.0)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/marksibly/emsdk/clang/fastcomp/build_master_64/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.4
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
INFO:root:(Emscripten: Running sanity checks)

[Mark SiblyKeymaster]

Just leave out the ‘End’…

Monkey

Interface I Property P:Int() Setter( p:Int ) End

1 2 3 4 5 6

Interface I   Property P:Int() Setter( p:Int )   End

 

[Mark SiblyKeymaster]

Sure. I wanted to make sure the compiled version of Emscripten I have was still valid.

Did you ‘./emrebuildmods.sh’ first?

When I rebuild this on Linux, I get this error message:

Ignore it. It’s there to remind me I have more docs to do…

[Mark SiblyKeymaster]

Please describe how it failed – error messages etc.

“it doesn’t work” isn’t much use…!

[Mark SiblyKeymaster]

Actually, something like this should work for now:

1С (Запрос)

Local node:=list.Lastnode While node<>list.HeadNode Local value:=node.Value 'do something with value node=node.Pred Wend

1 2 3 4 5 6 7 8 9

Local node:=list.Lastnode While node<>list.HeadNode    Local value:=node.Value      'do something with value      node=node.Pred Wend

It’s a little nasty as it depends on how List is implemented…

Backwards() will still be happening though so you could just wait for that.

Also…don’t use lists if you can avoid it, as they’re much slower to iterate through than a stack.

 

[Mark SiblyKeymaster]

Not yet, but will add it for V1.0.

 

[Mark SiblyKeymaster]

Another thing – you can still use the old syntax for converting built-in types, eg:

Local x:Float=1.0

Local y:Int=Int( x )

(Not actually necessary in this case but you get the idea…)

 

[Mark SiblyKeymaster]

Hi,

You have to use the new ‘cast’ operator, eg:

If Cast<Alpha>( test ) Then Print( “alpha” )

Basically the same idea as the old cast with slightly different syntax:

Cast< SomeType >( expression )

Bye!
Mark

[Mark SiblyKeymaster]

Welcome, and thanks for the kind words!

 

[Mark SiblyKeymaster]

Hopefully!

I haven’t actually tried any experiments yet, but the generated c++ code will be directly accessing the OS opengl libs in mx2, which will hopefully solve some of the weird ‘vertex buffer object’ performance issues that seem to occur on android when using OpenGL from Java.

That said, some of these problems may be in the various drivers – VBO’s in android have never quite worked as efficiently as they should and know one really seems to know why.

So…cross yer fingers I guess!

Bye,
Mark

[Author]

Posts