You Got A Question? Ask    GNOME Community!


Gnome Calculator port to Vala | A massive re-write!

This post was made with an older stylesheet


Gnome Calculator Rename

Robert Ancell made the commit that changes the name from gcalctool to gnome-calculator (Oct 15).


Porting to Vala

Ok that is a bit old (Oct 14) but I just noticed. Robert Ancell committed a huge patch that changes 74 files, removes 18179 lines of C code and adds 13318 lines of Vala. ~1/3 of the code is gone!

In the bug report (bug #640685) Robert says:

It would be nice to drop C for good and move to Vala…

Advantages:
- Modern syntax will attract new developers
- No manual management of reference counting
- Less code means easier maintenance

We’ve converted most of the legacy code to GObject code so this shouldn’t be too hard now. What’s blocking this right now is:
- The parser/lexer (a big chunk of work, see 589569)
- The MP math library (probably not too hard to fix)

And of course the question is why the new Gnome modules aren’t written in Vala? Vala was created to make Gnome a more rapid development and hacker-friendly platform, ..anyway.


Gnome Calculator 3.7.0+git

Vala port works fine, at least as far as I’ve tried it and it will come with Gnome 3.8.


 
  We can't watch comments unless G+ provides an API or if you send a notification, e.g +World Of Gnome
     Sometimes is better to place your questions on GNOME Community
  • Philip Witte

    I really wish Vala had operator and method overloading… very poor decision on the designers part, IMO. Albeit, even with those limitation, Vala is still a much nicer, hacker-friendly language than C.

    • alex285

      Wow! I don’t do Vala, but that sounds weird to me, because I thought it was similar to C# and Java. Function Overloading is so common practice to any OO language.

    • foobar

      There are very simple reasons why we are not supporting method overloading:
      – How should the c-name be called?
      – How would it be possible to create a nice C API when we have to derive names of types?
      – In case we are not appending parameter types to names for the first method written, how should we maintain API and ABI stability?
      – It would mess up gir-based bindings
      – Bindings wouldn’t use it. => different API styles
      – Method overloading sucks as much as the programmer who is overloading a method.
      – etc

      About Operator Overloading:
      – We actually support it for [] (.get (), .set (val)) and foreach.
      – Operator Overloading is ambiguous very often. Just think at a matrix*matrix. Not doing it results in more-readable code in most cases.

      Juergs decisions are perfectly fine in both cases.

      • Philip Witte

        A couple of your points seem to repeat, so I’ll only address the ones I found relevant

        “How should the c-name be called?” – The same way other languages handle this. D/C#/etc mangle their names however they see fit, but have special ways of marking functions to be readable in C

        “How would it be possible to create a nice C API when we have to derive names of types?” – I don’t follow, I thought the goal of Vala was to get away from C. I understand it’s important to play nice with C, but other languages have already managed this nicely without placing limits on how they functions internally. Even other languages which compile to C, like Nimrod, support Method Overloading, and for good reason. No one wants to have to constantly choose between: add_with_int() or add_with_float() to add a simple number.

        “It would mess up gir-based bindings” – I don’t know what GIR-Based bindings are, but a quick google makes me think it’s a GObject specific issue. No comment.

        “Method overloading sucks as much as the programmer who is overloading a method.” – I’m sure this was intended as a joke, or at least I hope it was.

        “We actually support it for [] (.get (), .set (val)) and foreach.” – Good to know. What I really want it for though, is Vectors, Matrices, and Quaternions.

        “Operator Overloading is ambiguous very often.” – No more or less than any regular function. It’s just as easy to misname those. I’ve always heard this argument, but I’ve never once come across a library with an overly ambiguous custom operators… can you provide a real-world example? I’m generally interested.

        “Not doing it results in more-readable code in most cases.” – Yes, but no one wants operator overloading for “most cases” we want it for math-heavy situations, like Game Engine/Script code. In these situations, operators make code much easier to read.

        • http://twitter.com/Aleksandar_93 Aleksandar Jovanov

          * This is a quote from vala site : ”
          Vala is a new programming language that aims to bring modern programming language
          features to GNOME developers without imposing any additional runtime
          requirements and without using a different ABI compared to applications
          and libraries written in C. ”

          * There are generics in vala so you do add <int> or add <float> for your use case.

          * Vala is based solely on GObject and such it has very nice support for GIR. They droped Posix and Dova profiles in 0.18 development cycle.

        • foobar

          D, C# and friends can’t be compared with vala when it comes about C compatibility. Only D provides C compatibility, but using a D library in C is a mess. Even Nimrod has a different purpose.

          You are wrong about a very basic point: We do not try to “get away from C”. Just take a look at libfolks, our contact manager. It’s written in vala and is used from C as well. The whole purpose of our language is to play nicely with the gnome platform. Desinging a language with this idea in mind simply can’t support operator or method overloading, when our gir files needs distinct names. Providing custom names as you suggested is not even a good workaround and far away from beeing a solution. Just imagine you would have to provide two up to three names for every overloaded method! Writing a library would force you to design your API at least on three levels: Vala, Gir and C.

          I already tried to explain why we’d have to append type names to every function in that case: When you write a function, publish your code with API stability, and add a new one with the same name, the programer has to make sure he adds an attribute to the first one to freeze the name. What is when the programmer wants to add a alternative version without any parameter?

          Operator overloading doesn’t make much sense when you can’t use types to choose between implementations. There is not a lot to add here.

          I hacked on more cpp as you can imagine in my live. Closed source, most time. The problem of wrong used operator and method overloading is common. Showing a real live example is quite hard: Most known platforms are well designed. (They wouldn’t be well known otherwise.) It’s less about libraries but about application code. People don’t put much thought about their internals on small levels.

          However, here is one:

          foo << "asfasf" << 10 < but no one wants operator overloading for “most cases” we want it
          for math-heavy situations, like Game
          > Engine/Script code. In these
          situations, operators make code much easier to read.
          Vala is a DSL for a desktop environment. Your examples are hardly fitting the purpose of the language.

          • Philip Witte

            Okay, well I admit it sounds like, with the stated goal of Vala and the technical reasons you give, it makes sense to take the simplest path. I am glad to hear Vala’s limitations are for technical reasons, and not just some guys opinion.

            > “foo << "asfasf" << 10 < “Vala is a DSL for a desktop environment. Your examples are hardly fitting the purpose of the language.”

            I think this is the root of my disappointment with Vala. It could be a language useful for my stated purpose, but it doesn’t aspire to be. It’s just annoying, because it is a language with easy-to-read syntax, acceptable memory management, good performance, and low-level access. It could be one of the few options to overtake C++ as a game programmers choice language.

      • xfertu

        The programmer should decide what to use, not the language. It’s much better to design three level of API in one place, than write stupid crap like Vector.add(Vector.scale(2.0), Vector.sub(r, vx)), vx) all over the code.
        Actually, right now I prefer to annotate functions like [CCode(cname="vector___add__")] because I don’t care about C API at all, but want to, at least, have nice API it python.

  • w1ngnut

    The less code, less likely a software pkg is exposed to bugs. This is one of the winning features of python. Vala also seems a very polished language so it’s a nice addition. Now, I really don’t see why so much hype about gCalc.

    • Craig

      The Vala compiler catches many types of errors at compile-time. Python errors mostly occur at runtime, and only if they’re invoked. Sound bites and flimsy opinions aren’t a “winning feature”. Python is fine, but it can’t beat Vala at it’s own game.

  • http://profiles.google.com/l33ts0n Arron Washington

    I wouldn’t use Vala for a Gnome application: there’s a few nit-picks like no operator overloading (in a _static_ language!) but my problem is mostly tooling. If you’re going to make me use a static language I want tooling — Eclipse-level tooling, frankly.

    Python and Ruby’s sparseness in their respective toolspace is fine since they’re both dynamic languages and writing code is pretty straight-forward, but when I’m dealing with a static language I want tooling and debuggers and all that baggage because its pretty much required to keep me sane. I mean, stacktraces! I don’t really depend on a Ruby / Python debugger because the stack-trace will often tell me everything I need to know: where the error occured and what the error was. If not, there’s Pry or Python’s REPL to the rescue. Vala? It’s C code that gets run and executed. I can’t start an interactive session because there’s no REPL. I need a debugger to introspect, and I don’t want to tool around on the command line learning arcane commands to set breakpoints for my _statically typed program_ because its 2012 and I’m too old for that hot mess.

    It’s probably petty reasoning, but I’m a petty person. :)

    • foobar

      Dynamic language are a hell to use in large projects. (Zeitgeist got ported from py to vala a very long time ago. Their speed improved a lot, memory usage got reduced by a significant factor, etc [1]) Also, vala is much nicer to use in several areas. A library written in Python? Forget it. DBus in python? Easy but not as simple and straight forward as in vala, etc.

      But yes, tooling could be better. I’m personally a vim guy and don’t mind a lot about IDEs but I see why a lot of people are missing it. Getting a trace in Vala/C isn’t acutally hard.

      [1] http://seilo.geekyogre.com/2011/11/zeitgeist-from-python-to-vala/

      • Craig

        Agreed. I use Lua wherever possible and love dynamic languages in general but writing a large, graphical app in a dynamic language is madness. Vala gets all the trade-offs exactly right for the domain it’s aimed at.

  • Connel Hooley

    I thought the plan was to port Gnome apps to Python? Not Vala

    • alex285

      The goal with python is to port python2 to python3. There isn’t a goal to port applications in Python. Maybe some Gnome hacker just proposed that. Further more Gnome Games have (or will) already ported to Vala.

      Besides GJS is kinda the most used scripting language in Gnome3. On the other hand Clocks is written in Python, so its basically up to developers to choose the language they prefer.

    • Craig

      Well you thought wrong.