Forum Replies Created
-
Posts
-
It should look something like this :
My phone is upright, tilted 45 degrees to the right. If the spinner is much bigger or much smaller, then there is a calibration issue, or if it lies on its side, there is an axis inversion.
It seems I’m a bit late to this party but just solved this issue here. On linux there doesn’t seem to be a standard place to install the ndk bundle. Your distro package will probably put it under /opt/android or some such, but Android Studio will manage the ndk bundle updates somewhere else (in my case ~/Android/Sdk/ndk-bundle). I told monkey where to find it by adding these lines to the end of <monkey>/bin/env_linux.txt (based on similar lines in env_macos.txt) :
12345'***** ANDROID TARGET *****'Add path to android NDK'PATH=${HOME}/Android/Sdk/ndk-bundle:${PATH}It’s lengthy, but did you read it? The clue is in there – there is a bug in one of the shaders and it is failing to compile (logcat line 773, which in turn references line 309 of the shader listing above).
As far as I can make out you’re not actually using the latest git code. It looks like Mark fixed this bug in the very latest commit on the 6th May. Try git pulling and rebuild everything…
Or if you want a quick fix, edit line 384 of ../modules/mojo3d/assets/shaders/imports/std.glsl and change “lod==0” to “lod==0.0”.
Looking good! But slow here aswell. Using Arch Linux on an i5 laptop, I get 10-13fps on Firefox (59.0.2), same on Chrome (66.0.3359.139) and also the same if I rebuild natively from the source. So it’s not a browser issue.
My gfx card isn’t the greatest (built-in Intel) but I get over 50fps when running toy-plane (with the window resized to 640×480 resolution). The CPU reports about 13% usage when running either of these.
If I run Toyplane and Bust in separate windows simultaneously I get 13fps for both. As soon as I close Bust, Toyplane jumps up to 50fps.
Does that help track down what is slowing things down? Happy to tinker with some code if it could be helpful – just point me to any likely culprits. It would be nice to see this running smoothly.
Like you, I will have flurries of activity punctuated by periods of absence, depending on how my day job is going – I’m self-employed so my timetable tends to be erratic. It would seem sensible to assign yourself an issue on github if you start writing on a particular topic. That way we have a record of who is doing what. I will probably try to tackle the issues I have reported on github before anything else. And perhaps class functions. But I leave for an 8 day holiday tomorrow so won’t be doing anything for a little while!
Well, that makes it easy – there are currently no changes in the docs repo for you to pull in!
Don’t worry, rebasing occasionally will make absolutely no noticable difference to what you are currently doing. It is simply to tidy up the docs repo. You can totally absolutely completely trust me to make it work. Besides, you have no idea who I am, no idea whether I actually know what I’m talking about or whether I am going to break a system that you are currently quite happy with. And I have no relevant credentials to put your mind at ease. What could possibly go wrong!?
Yes, you are right that rebasing can happen at any time but it’s nice to feel like I have a reason to justify otherwise arbitrary timing.
I’m already looking forward to the ‘ton of new stuff’…
@abakobo Yes, a rebase is exactly what is needed for a clean pull request, and it will also keep the docs repo in sync with the main repo. The downside is that anybody editing the files in the docs repo will have to pull a new branch after each rebase. This is why I think it is important to limit the rebases to only be done once for each monkey release.
PS: Did you see my posts and questions here : http://monkeycoder.co.nz/forums/topic/integrated-docs-github-community-organisation/page/3/
@mark, I totally understand where you’re coming from but I promise a rebase will actually make it simpler. The docs repo was running slowly out of sync with your main repo… not a major catastrophe but getting worse with each merge.
All I really want know is how you currently manage the timing of the pull requests. If you give us a heads-up that a release is imminent we can rebase the docs on the latest develop branch just before sending you a pull request. You won’t notice any difference but the commit history will be cleaner and the docs repo will stay in sync.
According to the github page, on the wipdocs branch :
This branch is 27 commits ahead, 7 commits behind blitz-research:develop.
Those 27 commits are the ‘dev up’ merges and shouldn’t really show up here. I don’t understand why github doesn’t understand that they have been remerged back into blitz-research:develop.
Anyway, I have rebased the wipdocs branch onto the latest blitz-research:develop (on my machine), and published the result to a new branch on m2docsCommunity repo called ‘rebased’. It currently says :
This branch is even with blitz-research:develop
I think that if we now use this ‘rebased’ branch for pushing all doc updates, I will then be able to rebase it again before sending Mark a pull request. As I’ve said before though rebasing is dangerous as it rewrites history and we should only do it once in a while, probably just before mark releases each new version. One other advantage of us rebasing before Mark pulls is that if there are any conflicts, we can fix them before sending the pull request instead of dumping them on Mark!
‘Static’ mean that this logic is common for whole class/type, not for every instance.
Yes, absolutely. But they can be invoked on a class OR on an instance.
I am suggesting marking a Class Function as Abstract as a style of Contractual Programming. Clearly it cannot be used to define common logic.
This currently works in Monkey if you declare a Function in an Interface, and this makes total sense. However, calling the Function() by doing Interface.Function() currently causes a compiler crash. This also makes total sense but would be better caught during semanting with a sensible error message (“Illegal call to abstract function”?).
My above logic should also be applicable to Abstract Classes, which are basically just Interfaces with some predefined methods. Allowing Abstract Functions within Class declarations is the same as using them in Interfaces. Indeed, this works as I described above in Monkey. If an Abstract Function is not defined in a Derived Class, the semanter says “Class <class> is abstract due to unimplemented method(s)”.
Can I get back to my original question about static methods?
@qube thanks for that but I think if you uncomment the final line of code it will crash.
@Mark I’m using the ‘latest’ gcc on linux so I would be surprised if this is a compiler bug? but you never know!
@Mark @nerobot surely it is not quite as simple as banning override/abstract/etc. It is useful to be able to declare an abstract Class Function in order to enforce any derived classes to define the function (a style of contractual programming, I guess?). Certainly they make sense within an interface, don’t they?
The only OO concept that breaks with static methods is polymorphism. The only thing that needs to be made illegal (caught by the semanter?) is calling an abstract function. This is what caused my crash… and in any case a crash is Not A Good Thing.
I intend to add class functions to the docs so want to fully understand what they can/can’t be used for…
@abakobo Hello! Just found this thread. I can’t believe I’d missed/forgotten about it!
I’m wondering how the docs get from the m2docsCommunity repo onto the turdus.be website? I presume that requires some sort of manual operation by you to upload it?
BTW are you one of the turdus band members?
@abakobo don’t be so hard on yourself! git is extremely complex, has many possible ways of doing the same thing. Multi-user version management is inherently incredibly complicated. If your method is working then you are not doing it wrong! As far as I know, the method you are using is actually quite common. It seems messy because Mark is a coding god and produces a huge number of commits.
When you mention brl/monkey2, do you really mean blitz-research/monkey2? I presume Mark changed the name at some point in the past?
Nerobot has hit the nail on the head : the only main repo is blitz-research/monkey2. Commits should only be squashed in one direction -> towards the main repo. If we squash the merge from upstream to docs, it will be very difficult for Mark to then merge back to pull in the doc commits.
On the other hand, I don’t think Mark should be squashing your pull requests. He should be rebasing them! That way he wouldn’t have the merges from brl->docs showing up in the brl repo. Or perhaps I’ve misunderstood something?
@Mark, have you tried doing a ‘rebase and merge’ instead of just a merge on the docs pull requests? Will you even notice this question?
I think we could rebase locally in the docs repo before issuing a pull request to Mark but that may get difficult to maintain due to having to rewrite history in the docs repo. I will have a play tomorrow.
@abakobo I am no expert but afaik it is generally considered a bad idea to squash commits once they have been pushed to a shared repo – it means ‘rewriting history’ and causes a headache for anybody with local copies of the repo.
A better approach would be to have two branches – one where all the commits happen, as they do now (wipdocs), and a master branch to which those commits are merged in batches, before being then pulled back into brl’s repo. There are other approaches but at a first glance, this one makes the most sense to me for this project.
Maybe you are already doing something like this? I will take a closer look later and get back to you.
@abakobo Thanks for the heads-up. I had no idea that docs repo existed.
I’d be very happy to help sort some of those issues listed on github. I dont use github much (I prefer the git cli) but can’t seem to find a way to request admin rights… am I being dumb or is there no way to do so on github? Can you add me as an admin – IMO it is a much tidier way to work than adding more and more forks! I’m arpie42 on github.
I know what you mean about spare time! But many hands make light work, apparently
