9 ms·

Hey guys, Slava here. I've been up since yesterday, so I'm going to clock out (though some of the team members are still lurking here). I wanted to thank everyo

Hey guys, Slava here. I've been up since yesterday, so I'm going to clock out (though some of the team members are still lurking here). I wanted to thank everyone for great feedback. We're working hard to improve Rethink over the next few months. FYI, you can always hop on IRC (#rethinkdb on freenode) or github tracker (https://github.com/rethinkdb/rethinkdb/issues https://github.com/rethinkdb/rethinkdb/issues) with questions and we'll help you out.

biturd 14y ago
Thanks for this work, it looks really nice. I was looking at the github comments about a home brew recipe in which it was stated that aside from a recipe creating a VM, the Mac OS X port would take a bit longer. Is that a full port from one language to another? Or just an issue of the different flavors of *nix that need dealing with and probably some of the dependency tree issues that come with it? I'm curious what needs be done to get it building on Mac OS X — perhaps I could assist somehow. I see a few dependencies that don't immediately sound familiar. You may have better luck with MacPorts, which uses tcl as the language for their portfiles. Portfiles are just like homebrews recipes, but MacPorts always builds new, including the entire dependency tree ( and dependencies of dependencies etc., etc. ), for which they have thousands of working portfiles. Since those are completed and working, you wouldn't have to worry about those until you wanted to be able to make a binary outside of any package manager. MacPorts can build binaries now ( new feature ), so you could just as easily instruct it to create a standard Mac OS X installer .pkg which makes sure everything goes in the right place, on the right platform, for the right architecture. They are an exceedingly friendly and helpful group, I'm sure they would live to see this software in their package/portfiles list.
- i386 14y ago
  Seems to me that most of us who have used MacPorts have moved to Homebrew or that could just be the bubble I'm living in. Is there anyone still who still uses MacPorts who could chime in and say why they never made the switch?
  - j-kidd 14y ago
    Come on, Homebrew doesn't even have gcc. I am not a Mac user, but a designer using MacBook joined our team last week, and we struggled for half a day with Homebrew. The next day, we installed MacPorts instead, and with just: $ sudo port install python27 py27-virtualenv gcc46 we were able to proceed and get the whole stack up and running. Not to mention everything from MacPorts is installed nicely under /opt/local. MacPorts is just way ahead of Homebrew. OTOH, Portage is way ahead of MacPorts ;)
    - merlincorey 14y ago
      clang is better than gcc, IMO
      - dman 14y ago
        By what metric?
      - irahul 14y ago
        > clang is better than gcc, IMO Maybe. Maybe not. But I don't think that's the reason homebrew doesn't have gcc. The OP is pointing out homebrew isn't extensive, and misses some commonly used utilities.
      - hyperbovine 14y ago
        clang either does not build or defectively builds certain things on OS X, for instance Ruby 1.9.3. I had to acquire vanilla GCC for this reason the other day, and was relieved to find it in HomeBrew.
        i386 14y ago
        Ruby 1.9.3 working fine here and built with clang. What was defective?
        getsat 14y ago
        Old-ass versions of Clang would build Ruby and PostgreSQL (client) binaries which would segfault upon execution. Try grabbing the latest XCode/command line tools package and you should be fine. I've been running Ruby 1.9.3 with Clang for quite a while. brew install rbenv ruby-build; /* rc file shenanigans */; rbenv install 1.9.3-p327; rbenv global 1.9.3-p327; ruby --version
- coffeemug 14y ago
  Most of the issues come from kernel differences. Some are relatively big, like epoll vs. kqueue, and some are very subtle (some syscalls have subtly different behavior on strange edge-case scenarios). I don't think building this natively would be too hard, but in the context of everything else left to do, it isn't an absolutely trivial project.
tedjdziuba 14y ago
Why did you guys abandon the SSD focused storage engine for MySQL? I was excited about that.

biturd 14y ago

Thanks for this work, it looks really nice. I was looking at the github comments about a home brew recipe in which it was stated that aside from a recipe creating a VM, the Mac OS X port would take a bit longer. Is that a full port from one language to another? Or just an issue of the different flavors of *nix that need dealing with and probably some of the dependency tree issues that come with it? I'm curious what needs be done to get it building on Mac OS X — perhaps I could assist somehow. I see a few dependencies that don't immediately sound familiar. You may have better luck with MacPorts, which uses tcl as the language for their portfiles. Portfiles are just like homebrews recipes, but MacPorts always builds new, including the entire dependency tree ( and dependencies of dependencies etc., etc. ), for which they have thousands of working portfiles. Since those are completed and working, you wouldn't have to worry about those until you wanted to be able to make a binary outside of any package manager. MacPorts can build binaries now ( new feature ), so you could just as easily instruct it to create a standard Mac OS X installer .pkg which makes sure everything goes in the right place, on the right platform, for the right architecture. They are an exceedingly friendly and helpful group, I'm sure they would live to see this software in their package/portfiles list.

i386 14y ago
Seems to me that most of us who have used MacPorts have moved to Homebrew or that could just be the bubble I'm living in. Is there anyone still who still uses MacPorts who could chime in and say why they never made the switch?
- j-kidd 14y ago
  Come on, Homebrew doesn't even have gcc. I am not a Mac user, but a designer using MacBook joined our team last week, and we struggled for half a day with Homebrew. The next day, we installed MacPorts instead, and with just: $ sudo port install python27 py27-virtualenv gcc46 we were able to proceed and get the whole stack up and running. Not to mention everything from MacPorts is installed nicely under /opt/local. MacPorts is just way ahead of Homebrew. OTOH, Portage is way ahead of MacPorts ;)
  - merlincorey 14y ago
    clang is better than gcc, IMO
    - dman 14y ago
      By what metric?
    - irahul 14y ago
      > clang is better than gcc, IMO Maybe. Maybe not. But I don't think that's the reason homebrew doesn't have gcc. The OP is pointing out homebrew isn't extensive, and misses some commonly used utilities.
    - hyperbovine 14y ago
      clang either does not build or defectively builds certain things on OS X, for instance Ruby 1.9.3. I had to acquire vanilla GCC for this reason the other day, and was relieved to find it in HomeBrew.
      - i386 14y ago
        Ruby 1.9.3 working fine here and built with clang. What was defective?
      - getsat 14y ago
        Old-ass versions of Clang would build Ruby and PostgreSQL (client) binaries which would segfault upon execution. Try grabbing the latest XCode/command line tools package and you should be fine. I've been running Ruby 1.9.3 with Clang for quite a while. brew install rbenv ruby-build; /* rc file shenanigans */; rbenv install 1.9.3-p327; rbenv global 1.9.3-p327; ruby --version
coffeemug 14y ago
Most of the issues come from kernel differences. Some are relatively big, like epoll vs. kqueue, and some are very subtle (some syscalls have subtly different behavior on strange edge-case scenarios). I don't think building this natively would be too hard, but in the context of everything else left to do, it isn't an absolutely trivial project.

tedjdziuba 14y ago

Why did you guys abandon the SSD focused storage engine for MySQL? I was excited about that.