From: Christophe R. <cs...@ca...> - 2014-03-06 08:39:30
|
Erik Varga <eri...@gm...> writes: > Hello everyone, > I'm Erik Krisztián Varga, and I'm planning to apply to SBCL for the > Google Summer of Code. Hi! > One project I'd possibly like to work on is modernising the register > allocator. I'm not entirely sure if this project is still active or if > it was left in the project ideas page by mistake, because it seems > someone had done something like this the previous year. If it's still > needed, however, I'd be happy to work on it. I have hacked around with > assembly before to have a basic understanding of it. I have also > learned about the fundamentals of graph theory and colouring, and I'd > like to apply the theory in practice. Hm, it shouldn't have been left in the project page -- of course, there's only a subtle difference between the 2013 list and the 2014 one. Ah, what seems to have happened is that I carefully did the renumbering but without actually removing that section. Sorry for the confusion; you're quite right, that work was done last year. (I'll try to update the page later in the day) > I'd also be interested in making constant divisions more efficient, as > that seems like an interesting problem. I have sufficient grasp of > number theory to be able to understand and apply methods for this, and > I also have some level of assembly knowledge. > > Is it possible to know who will be mentoring these projects or who I > should turn to if I have questions related to these problems? Paul Khuong, if he's available, would be the logical mentor on constant divisions; I believe he has some work in some progress in this direction. If not, I could, and there are probably others who'd be interested. > I made a small patch (attached) for bug #1254511 to get a bit familiar > with rewriting and building sbcl. I'm not sure what's the usual way to > submit patches, should I submit it to the launchpad site instead? If there's already a numbered bug, it's probably best to send patches to the bug tracker; it doesn't hurt to send them to sbcl-devel too, but at least if it's in the bug tracker it probably won't get lost. > I have one more question: What do you think is the best way to test > the changes to the source? Right now I just run make.sh after having > made some changes, but the build process takes an long time and I > probably shouldn't need to recompile everything if I only changed a > few files. Well, on one level you shouldn't and on another you should. I have to give you the short version at this point as I'm nearly out of time, but: because compiling Lisp code cause have arbitrary side-effects in the running compiler, in principle there's no way of knowing that a change in one file doesn't affect changes in others. (For example, think about the effect of changing a macro definition: you have to recompile everywhere it's used.) So the normal way to build is indeed to use ./make.sh and make a cup of coffee. That said, there are shortcuts. For incremental development, it's possible to evaluate forms in slime, or using other tools after loading src/cold/chill.lisp. And for faster-but-riskier rebuilds, there is a script called slam.sh, which depends on a previous full build with the :sb-after-xc-core feature, and attempts to work out just what needs rebuilding. It's fiddly and not 100% foolproof, but it can shorten things. Best, Christophe |