Forum Replies Created
-
AuthorPosts
-
Ok, it turns out you can’t currently write to a struct via an extension method.
I’ll have a look into possibly allowing this later, but for now I’ve added an error message when you attempt to do this.
This works here with latest mx2cc (was fixed pre v1.0.5 I think):
Monkey12345678910111213#import "<std>"Using std..Function Main()Local _stack:=New IntStackLocal _scope:Int_scope = (_stack.Length > 0) ? _stack.Pop() Else NullEndYou should be fixed on github too.
Holy crap, can reproduce it!
I usually have my file browser in ‘column view’, but if I change to ‘grid view’ (ie: like yours) I get the same problem!
I can fix it by changing back to column view (or list view) after which it happens again but is fixed the next time I start Ted2.
Will look into this – very strange though!
What’s that funky mouse circle thing – is it an addon? Can you disable it?
Weird, using exactly the same setup and it doesn’t happen here.
I did find one minor thing but it’s very unlikely to be the problem – have committed the fix anway, you’ll need to rebuild ted2.
Also, it does take quite a while to open the first time – but that’s true of pretty much everything on my Mac until it ‘warms up’.
Does it never show at all? Never close? What are the symptoms exactly?
What versions of macos/monkey2 are you using?
> any chance of allowing extension overload methods?
This should be possible eventually. Will be returning to operator to: and extensions soon-ish.
The mangled output is what Ted2 uses to produce the debugview, so I’m guessing you’re not using Ted2?
I can clean this up, but I need a way for apps to tell if they’re running in Ted2 or not.
The debugger itself is pretty primitive right now, generally only useful for ‘post mortem’ debugging (which is all I’ve ever used debuggers for anyway). More features will come, but some will likely have to wait until reflection and other features are added.
Quick demo:
Monkey12345678910111213141516171819Function Main()Local w:=20,h:=10Local t:=New Int[][w]For Local x:=0 Until wt[x]=New Int[h]NextFor Local y:=0 Until hFor Local x:=0 Until wPrint t[x][y]NextNextEndNote that the ‘new’ is sort of back to front, ie: in the ‘New Int[][w]’ bit, w comes last, but when you’re indexing with ‘x’ it comes first!
This actually makes sense to me as a compiler coder, ie: ‘New Int[][w]’ is w new int arrays, which is what we want, but I think java/c# parse things kind of differently so you end up with ‘New Int[w][]’ instead, which or may not make more sense to others.
I’m pretty relaxed about changing this if enough people prefer the Java way.
Yes, that’s a no.
I was initially planning on supporting ‘looser’ eol rules, but that wasn’t as easy as I thought it’d be.
In the end, I sorted of just embraced the whole strict eol approach instead, thinking I might revisit it later. But now, I just don’t see a compelling reason to any more – I like it the way it is.
Will it work on Android and iOS?
I’m not sure about iOS but, somewhat to my surprise, it does work on Android! Both the sdl-mixer and openal drivers too (had to increase the ‘polling’ rate of the openal one though).
I haven’t got bluetooth keyboard working on iOS yet so I haven’t really tested it there.
Can you try and put together a runnable example for me to play with?
Sounds interesting!
September 7, 2016 at 7:58 am in reply to: external abstract won't compile in debug mode (w7 and elcapitan) #3732It’s working here – did you rebuild all?
-
AuthorPosts