Forgot your password?
typodupeerror

Comment: Re:In time (Score 1) 103

by TheRaven64 (#48194083) Attached to: Doctor Who To Teach Kids To Code

My ability to put 'latex manuscript.tex' and 'dvi2pdf manuscript.dvi' into a makefile is not magic, it is basic automation

It's also redundant and likely not to do the right thing (ironic, given previous comments about libraries). Look for latexmk, which is part of the standard LeXLive distribution. Oh, and since this is not 1970 anymore, let's skip the DVI step and go straight to PDF with pdflatex (latexmk -pdf manuscript.tex is probably what you actually want).

Comment: Re:I am not going to convert (Score 1) 207

by TheRaven64 (#48193991) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime
You can checkout a subdirectory if (and that's a big proviso) you structure your code in such a way that each directory is a separate git repository, referenced as a submodule. The submodule points to a specific version of the other repository. Unfortunately, there are still a lot of issues with this approach:

The biggest is that you have to think about what parts of the project you might want to check out individually before you start. For new (small) projects, it's sometimes easy, but typically projects grow organically and parts get factored out. There's no good way of turning a subtree in a git repo into a new repo preserving history (and no way at all that allows you to merge into both).

The second big one is that you lose atomic commits (the thing we all switched to svn from cvs for in the first place). If you only have one layer of submodules, it's quite nice because committing something to the submodule and updating the version of the submodule are independent. That means that you can make changes to a component, unit test them, commit, and then later update their consumers. Unfortunately, there's no way of atomically updating two independent subtrees simultaneously.

The third annoyance is the most embarrassing for a DVCS: the remote repository for upstream is identified by an absolute URL. You can do relative URLs, but they don't work very well, which means that if you want people to use a local version then it's quite convoluted. There's no simple 'clone this repo and all of the submodules in such a way that someone else can clone my copy and it all work sensibly'.

In general, the dire UI of git has been an unexpected advantage. No one can stand working with it, so people have been motivated to write nice GUIs that make it tolerable.

Comment: Re:Newton anyone? (Score 1) 79

by TheRaven64 (#48193681) Attached to: IBM Pays GlobalFoundries $1.5 Billion To Shed Its Chip Division
Freescale mostly sells PowerPC chips for automotive and similar applications. They already had the low power parts, but they didn't have them at the speeds that Apple wanted. Most of their customers use their chips for engine control or entertainment systems. They also made the chips for consoles. Their biggest weakness was that Apple was the cheapest supplier of a PowerPC system that you could develop on, and they were undercut by a long way by Intel machines. This is the same problem that Alpha had: it didn't matter that their Windows NT systems were faster than Intel's, they didn't get them into the hands of developers so everyone wrote software for Intel.

Comment: Re:Newton anyone? (Score 1) 79

by TheRaven64 (#48186769) Attached to: IBM Pays GlobalFoundries $1.5 Billion To Shed Its Chip Division
ARM exists largely because of Apple. They didn't want to buy mobile chips from a competitor (Acorn), so invested in a joint venture so that Acorn would spin off their chip division into a company that would sell to both. They then ignored ARM after killing the Newton though. Many of the people working on the current ARM cores at Apple formerly worked on a PowerPC processor at PA Semi. I think, if IBM and Freescale, had been serious about selling desktop chips that Apple would have been happy to avoid a load of software costs by having a single CPU family for their entire product suite. IBM didn't want to compete with Intel in mobile chips and Freescale kept promising exciting parts and never quite bringing them to market.

Comment: Re:Why fear the iMac? (Score 1) 352

by TheRaven64 (#48184647) Attached to: Apple Announces iPad Air 2, iPad mini 3, OS X Yosemite and More
They're still not offering a retina external display, but they're about the only manufacturer that isn't. I just got a 4K 27" display at work (and I'm now back to preferring to read text on the big screen instead of on the laptop screen). The panel quality is nice, but it lacks any bells and whistles. They're only £300 now though, so we're buying them as the standard external displays.

Comment: Re:Is D3D 9 advantageous over 10? (Score 1) 52

by TheRaven64 (#48179763) Attached to: Direct3D 9.0 Support On Track For Linux's Gallium3D Drivers

Direct3D 10 is very different from DirectX 9. The latter was designed with modern GPUs in mind and so is based around an entirely programmable pipeline. DirectX 9 is predominantly a fixed-function API with various places where you can insert shader programs into the pipeline. This means that DirectX 10 is easier to support because there's less provided by the API.

Supporting D3D 9 is akin to supporting OpenGL 2. You need to expose most of the programmable interfaces but also have a load of fixed-function stuff work, typically (on modern hardware) by providing shader programs that do the same thing. Supporting D3D10 is more similar to supporting OpenGL 3, where most of the complexity is in moving data to and from the GPU and compiling shader programs.

With Gallium, there are two aspects to supporting these APIs. The first is the compiler turning programs from a source language (HLSL, GLSL) into TGIR. The second is the state tracker, which handles API-specific state. The former part is about as complex for D3D 9 and 10, as they have similar shader language support. The latter is a lot simpler for 10, as it is a much less stateful API.

Machines certainly can solve problems, store information, correlate, and play games -- but not with pleasure. -- Leo Rosten

Working...