User talk:Kevin Reid
What resolution are you running at? I designed the theme for 1024x768. shortcircuit is working on a non-fixed width version too, but it's a lot harder than you'd think ;) --qrush 12:32, 24 June 2008 (UTC)
- Kevin Reid is kpreid_ on the IRC channel. The problem isn't so much with the resolution, such that the user may not choose to have the browser window maximized. In addition, things like horizontal toolbars (Firefox has some of those) can also reduce the available horizontal resolution. --Short Circuit 03:23, 25 June 2008 (UTC)
Hi, this is Arie Groeneveld. If you are interested have a look at my two alternative Haskell solutions for the zigzag task. User_talk:Gaaijz
- --Gaaijz 07:58, 6 September 2008 (UTC)
Eval & Drastic changes
Please discuss before making changes that invalidate so many entries. Thanks, --Paddy3118 18:24, 25 May 2009 (UTC)
- I wrote the task originally and the changes match my original intent. All of the examples I marked were incorrect originally for not discussing "how you get values in and out".
- Hm. But I also added some requirements and didn't distinguish them. Perhaps we should have a separate template to distinguish "the example was incorrect" (which has a negative tone) from "the task has been expanded, please add this behavior/documentation".
- +1 on the added template idea. (I had not realised that you wrote the original). --Paddy3118 18:55, 25 May 2009 (UTC)
- --Kevin Reid 18:46, 25 May 2009 (UTC)
I think you're wrong about introducing a new categorization scheme for that page. It's inconsistent with the vast bulk of RC (yes, I have read a large fraction of it...) and the consistent focus on the language as the primary axis of differentiation of solutions is a strong feature. Also, the task needs splitting up into more smaller ones; right now, it's asking for the world on a stick (and a pony too). Maybe have basic sound playing as one thing, then add mixing as a separate task, then ... —Donal Fellows 15:37, 11 June 2009 (UTC)
Looks like you're playing whack-a-mole with spammers. You'll need to take more extensive action because they never give up. Which is sucky to the nth degree, but can't be helped. You might need to ban people from particular netblocks from contributing any content (including registering). CAPTCHAs won't work; you're dealing with people here. —Donal Fellows 13:34, 28 June 2009 (UTC)
- I am not an administrator; I have no particular power. I just blanked that page to reduce the amount of time the spammers have their links out. --Kevin Reid 14:24, 28 June 2009 (UTC)
Spammers are a real problem. You have my sympathy and I hope you win through in the end. :-)18.104.22.168 16:29, 14 February 2010 (UTC)
eql and = in CL
I noticed the change from eql to = on Combinations. I'm not going to undo it or anything, but it's worth nothing that = takes an arbitrary number of args and will compare numbers of different types. I'd guess that most compilers have a specialized =2 (e.g., LispWorks has
system:=2), but without type declarations or a compiler smart enough to figure out that the values are integers, = still has the overhead for different numeric types. It's why I (by default) use
eql for comparing two integers.
Tayloj 04:58, 8 August 2009 (UTC)
Unless performance is at issue, code should be written to be clear. One heuristic for clarity is to use the most specific (reasonably) operator that applies to the types being worked with, so = rather than EQL for numbers. Also, = will compare integers and floats by value. With regard to performance: I could equally argue that a compiler with unboxed-number support but not a full set of optimizations would need to box the numbers to invoke EQL on them, but not for = since that is an always-numeric operator. So I can't agree with your performance assumption without actual benchmark data. --Kevin Reid 16:43, 8 August 2009 (UTC)
I've often contributed to WIKI sites and spammers are a bother. They just can't be stopped. They just keep coming back time and time again. Now I here they also utilise fake references and the like. I hope you win through and carry the day. :-) 22.214.171.124 16:26, 14 February 2010 (UTC)
Toadstool not lispy enough?
The problem with the syntax I saw is that it has not enough parentheses :) Or rather, specifically, you have to look forward to the "->", count back, and divide by two to know how many values/patterns are involved. If the syntax were analogous to cl:case (parens around each case, around the lists of patterns and items to be matched, and no decorative "->" symbol), I would be entirely happy with it:
(toad-ecase (color left val right)
(('black (tree 'red (tree 'red a x b) y c) z d)
(tree 'red (tree 'black a x b) y
(tree 'black c z d)))
As a practical example, by putting parens around each case, it is possible to easily copy and paste the whole case by selecting balanced parentheses (an entire s-expression); as it is one has to be very careful to find the boundaries.
This is entirely my own opinion, of course (though I think it is not unusual). --Kevin Reid 20:38, 11 August 2009 (UTC)
You never used Gaffers????!!? 126.96.36.199 16:22, 14 February 2010 (UTC)
NevilleDNZ 14:39, 2 May 2010 (UTC)
Thanks for the clean up on my little addition. --La Longue Carabine 22:36, 20 June 2012 (UTC)