If this was a joke, I think it just didn't parse right through my brain. But if you do actually use Puppet, do you know of any learning tools other than just diving in with Ralsh and trying stuff out?
I started with the example modules from Example42 and used the Puppet docs, particularly the types reference and metaparameters reference. Never used ralsh.
It wasn't. He was saying that you could have asked, "If anybody uses Puppet, do you know of any learning tools other than just diving in with Ralsh and trying stuff out?" Instead, you basically asked, "Is it okay if I ask a question about Puppet?"
Actually, it was meant as "Does anybody here actually use Puppet", as in are there people working in the industry who use it as their tool of choice for various tasks, because I've heard that it's very unfriendly in terms of using it in combination with other tools and I was wondering if it was a language that didn't see much use in practice. Does that make sense? If that doesn't seem like a sensical or sensible question, I'm sorry.
Puppet is probably the number one config management tool for greenfield Linux-based deployments right now. I would say it is the second most popular tool of its class, after in-house crap.
The last startup I was at switched from makefiles to cons (not scons for some reason; I guess people loved the hell out of perl), and our experience was pretty mixed. It let us do cool things, but after a while maintaining the build system became an engineer's fulltime job. And not in the traditional build engineer sense, but in the "Oh, you want to add that to the project? Go ask Dave, he's the only one who understands any of this" sense. I'm pretty glad he didn't quit or get hit by a bus or anything. On the other hand, when things were all set up the build system was way smoother than the cobbled-together makefile monster it replaced, so that was nice.
SCons is a lot better than Cons, but you'll still hit a point where someone has to dedicate a serious amount of time and effort to making it work for you. That's probably true of any build system, though. If you do use it for a project of any size, I highly recommend starting out with the intention of building your own wrapper library around it. When I used it, we had a dozen sizable projects, each with their own gigantic and slightly different SConscript. Your goal should be for SConscripts to be small and built of common components. Also, SCons works on Windows, but it doesn't integrate into VS at all. If you do a lot of Windows dev, you might want to check out cmake. (Not an endorsement, as I've never used it, but it looks interesting.)
Yes, this is true of all build systems. In particular it's really true of cross-platform build systems that may have shared host/target, disparate host/target, different file systems, different hosts, and of course different projects entirely. We build tools, libraries (and multiple variants of those libraries), and examples. The appeal of scons to me is that it's Python based, so instead of trying to sort through some arcane makefile bullshit, I can at least muddle through the Python side of things pretty easily. I target a shit ton of platforms, so I much prefer a pure command line driven interface that's portable if at all possible.
I'd say scons is your winner then. If you get stuck on anything feel free to PM me and I'll sort through our build files and see if we've done anything similar so I can provide you some examples. We don't do cross platform though, unless you count very similar flavors of unix as cross platform.
Thanks. We'll muddle ahead, it's just frustrating having to rediscover a lot of stuff with a 10 year old software solution. As an example of what I'm dealing with (host/target): tools: Win/Win (32 and 64), OSX/OSX, Linux/Linux (32 and 64) runtime: Win/Win32, Win/Win64, Win/360, Win/PS3, Win/SPU, Win/WiiU, OSX/OSX, OSX/iOS, Linux/Linux (x86, x64, and ARM) And for compilers we're using several different Visual Studio variants (2K5, 2K8, and 2K11/12), various gcc and clang; and Green Hills Software. We target x86, x64, PPC, SPU and ARM (v6 and v7) processors. At least I don't have to deal with Metrowerks anymore.
I'm just curious, but why use multiple versions of Visual Studio? Edit: Oh, VC compilers, which makes a bit more sense, older libraries?
Some targets require MSVC > X, and versions past 2K5 can't generate libs compatible with VC6 (don't ask), and there is other stuff that requires even newer versions of the compilers
Sounds a lot like the place I used SCons. We were all Unix types and worked on Windows only grudgingly, so the lack of VS integration wasn't a problem for us. That said, cmake can generate VS build files which you can execute from the command line using the right Windows tool. I suspect it may work better if you're trying to integrate into a normal Windows environment. You have a lot more Windows builds than we did--we were ten flavored of Unix plus a redheads stepchild of a Win32 build.
My team at Microsoft is almost entirely on the down-low, but recently the skies parted and a single ray of disclosure shone out, revealing an OOPSLA paper about some C# language extensions for implementing read-only, isolated, and immutable types. I blogged about it. Interested? We're hiring. (Lum, if those last three words are inappropriate here, please advise and I'll edit the hell out of it.)
Wow, that sounds awesome. By the way there's a Hire me thread. I don't speak for Lum, but I can't imagine he'd have a problem with it.
Someday I'll get back into programming enough that I could actually understand that entire blog post RepoMan.
That reminds me. Fuck COM. Jesus Christ what a pile of shit. Spent pretty much two days trying to figure out why a customer's DIA SDK wasn't working.
I don't hate COM that much. Probably because I never use it. Also, I learned COM right after learning C++, and thanks to Don Box, I grokked the Essentials of COM (oh, it's just a pure virtual class with a specified vtable layout?) pretty easily. Then I could pretty easily layer IDispatch knowledge on top of that, the tlb, and put together a whole internal COM server for my application so it could be scripted by Visual Basic (over a decade ago at this point). But through that entire thing, with IDL and the TLBs and the ATL CComObject and all that crap, it got to the point where I had this fragile beast of an implementation that mostly worked, but woe be upon anyone else who ever tried to work on it. And so, coming full circle, I decided that it perhaps, this technology is not one that should be used by mere mortals, as it was just so damn easy to screw up. I saw C# and decided that it was much better. I saw WCF and decided (for some reason) that it was much better than DCOM (did anyone, ever, anywhere, get DCOM to work?), but then I continued on and decided that, you know, sometimes what you really need is just a good old C++ class. I find it funny that I think Microsoft decided mostly the same thing, and I will grant them that they basically keep COM unchanged and keep using it. Oh, and did I mention that I also wrote Excel Object Model code... in C++?. OH GOD, the horror.
Yeah. The platform I'm working on (Windows 8 Metro) doesn't support D3D9 or OGL, just D3D10/11. I have to say, the Microsoft::WRL::ComPtr<T> class does make things a lot easier than manually calling adapters and passing strings with the names of functions, which I seem to recall having to do once. This makes COM classes act mostly like normal objects!
To be honest, I've mostly been working within other peoples frameworks, but here is a link with lots of links that might help: http://stackoverflow.com/questions/...ting-c-application-from-directx9-to-directx10
For COM just read Don Box's book. It makes more sense if you treat it as an abstract overview of how to design version independent interfaces for concrete binary running code, which just so happens to have an implementation under it. You can probably ignore the lesser used areas, but the first couple chapters are essential. The problem is that it's uh, really hard. Hard enough that your average application developer has no chance of writing anything with that model that functions. The ongoing evolution of that (hint - .NET is basically a COM overaly) has helped quite a bit.
They're just an arbitrary way of giving a language independent path to object, where you can define your own path structure. There's other fancier examples like the elevation moniker, which is effectively a pass-through for elevating the creation request for a CLSID.
.NET is a separate development based on the same ideas. I think there's some COM in the runtime, and you can rig .NET assemblies for COM interoperation, but .NET assemblies as such are not based on COM. WinRT, on the other hand, is in fact directly based on enhanced COM (which is why it's fairly primitive compared to .NET).
The issue isn't that programming COM is hard -- it's not, it's just really goddamn tedious -- it's that you can do everything right as a programmer and it'll fuck up on an end user's machine due to DLL registration issues. You can try to do registration free COM, but that's it's own ball of worms. We spent a day dealing with someone who had 32-bit DLLs registered but not 64-bit ones, and then today another customer had the opposite problem. And these are things that are supposed to be handled automatically as part of the Visual Studio installation but sometimes it just falls apart. But it manifests as a bug in our software because, hey, CoCreateInstance failed, and they just assume we screwed up. So we have to tell them "run REGSRV32 on the appropriate MSDIAxx.DLLs plz, kthx".
Ugh. Just Ugh. 32 bit and 64 bit, Ugh, so many nightmares. And I figure about the time that 32 bit leaves us forever, 128bit will start to come in.
You're probably looking at the BCL passing functionality through to native Windows libraries. There's a lot of that but pure .NET assemblies shouldn't have anything to do with COM.
