mx2cc crash during linkage

About Monkey 2 Forums Monkey 2 Programming Help mx2cc crash during linkage

Tagged: ,

This topic contains 15 replies, has 6 voices, and was last updated by  arpie 5 months, 2 weeks ago.

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #14210

    arpie
    Participant

    I’m stuck tracking down a linkage crash and would like to ask a few quick questions :

    1. Is a linkage crash (mx2cc fatal error) always considered a bug (ie. the thing causing the crash should be caught during semanting)?  If so, I will try to create  a crash test example and put it on github to help get it fixed.
    2. The crash seems to be caused by me calling a Class Function on an Instance of a Derived Class (it is a Virtual Function).  Should I be able to do this or am I abusing the Monkey (ooh-er!)?
    3. Am I being dumb or are Class Functions not mentioned in the online documentation?  If they are missing, can I help put them there?  Who maintains the docs and where should I officially report documentation errors and the like?

    TIA

    #14211

    DruggedBunny
    Participant

    I would at least comment on 1)…

    Report with runnable example and see what Mark makes of it, in that mx2cc fatal errors basically shouldn’t happen.

    #14212

    arpie
    Participant

    Finally pinpointed the problem and boiled it down to this runnable example.  Uncomment the final line to cause a linkage error.

    Should polymorphism work on ‘static method’s / ‘class function’s?

    #14217

    nerobot
    Participant

    You can’t override static methods in java or c#, so I think Mark have to deny it too.

    #14218

    Mark Sibly
    Keymaster

    This looks like a compiler bug to me – you shouldn’t be able to use ‘virtual’, ‘abstract’, ‘override’ or ‘final’ with functions (static methods).

    It doesn’t make any sense to allow it either – without a ‘Self’, an object has no dynamic type.

    #14219

    Qube
    Participant

    The code example works in version 1.1.08

    Attachments:
    #14221

    abakobo
    Participant

    about 3)

    there is a github orgnization
    https://github.com/mx2DocsCommunity/monkey2/issues

    the fact that class funcs are not documented is in the issues.
    You can help improving docs via that fork or with your own github..
    If you want admin rights in mx2DocsCommunity just ask..

    I’ve had been working a bit on the language ref. but have just a few spare time now so focused on my game project.

    #14232

    arpie
    Participant

    @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 🙂

    #14233

    abakobo
    Participant

    @arpie, invited you as owner. If you are used to git cli, it would be great if you could sqash all the “dev up” commits into one commit, so it doesn’t pollute brl’s repo when making a pull request. Can you do that? I’ve been looking a for it a bit but I never used the cli..

    #14235

    arpie
    Participant

    @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.

    #14237

    abakobo
    Participant

    Well I’ve done it all wrong till now and Mark has merged some pull requests full of «dev up». So for the last pull request I actualy made a clean fork on my account and the closed the issues on the mx2docsCommunity fork.
    I must say I’m a bit surprised it is so complicated to keep a branch sync and clean.
    Anyway, do as you think it’s better. My way to do it is completely wrong probably. Nerobot had suggested somewhere how to do it cleanly (in a pull request discussion I think).

    If it is possible to create a new branch that is a clean copy of brl’s dev that would be neat. But how to sync mx2docsCommunity master(or dev) with brl’s dev in a clean way?
    As you can see I’m more using github like a dropbox than like a git ;).

    #14238

    nerobot
    Participant

    My suggestion is good for a short improvements. But if you have long changes then there can be many merges of m2 repo in yours.

    But anyway – the only main repo here is brl/monkey2, and to keep its commits clear Mark have to always use Squash&Merge option (to get single commit of all pulled changes). And I think he does it already. 🙂

    #14244

    arpie
    Participant

    @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.

    #14253

    arpie
    Participant

    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…

    #14254

    nerobot
    Participant

    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?

    ‘Static’ mean that this logic is common for whole class/type, not for every instance.

    To declare common logic for instances which can be overriden you should use virtual methods (not a functions).

    To prevent overriding in derived classed you can mark methods as Final.

    To force user to override method – mark it as Abstract; methods of interfaces are abstract by defaul.

Viewing 15 posts - 1 through 15 (of 16 total)

You must be logged in to reply to this topic.