Hacker Newsnew | comments | ask | jobs | submit | freedrull's commentslogin

I believe they have upgraded to 3, thanks to @tmm1. It was mentioned in some talk, probably by Zach Holman.

-----

bnferguson 23 days ago | link

Significant work has been done by tmm1, rsanheim and a host of others, but it's not complete yet.

Basically, the work is on-going and pretty amazing to watch!

-----


Wow, I think the new profiles on github are a definite improvement for this kind of situation. :D

-----


I do it all the time without thinking about it. I have no idea why. Please help me. :(

-----


Why on earth would the people who wrote V8 use UCS-2? What about alternative JS runtimes?

-----

marshray 508 days ago | link

Because Unicode was sold to the world's software developers as a fixed-width encoding claiming 16 bits would be all we'd ever need.

-----

thristian 508 days ago | link

Yes it was, in 1991 when NT and Java and Cocoa were new or under development. In 1996, Unicode 2.0 came out with surrogate pairs and astral planes, and Unicode was no longer a 16 bit encoding.

I'm pretty sure work on V8 started after 1996.

More likely is the idea that the authors of V8 felt that UCS-2 was an acceptable speed/correctness trade-off.

-----

dmethvin 508 days ago | link

Yes, and several C/C++ conventions and types seemed to make that a safe choice, for example wchar_t. Let's face it, collectively we really screwed this one up. It's the biggest mistake since Microsoft chose the backslash as a path separator in DOS 2.0.

-----

magic_haze 508 days ago | link

It was actually IBM's fault: they used '/' to denote CLI args in the apps they wrote for DOS 1.0, which didn't have any concept of directories. From Larry Osterman's blog [1]:

> Here's a little known secret about MS-DOS. The DOS developers weren't particularly happy about this state of affairs - heck, they all used Xenix machines for email and stuff, so they were familiar with the *nix command semantics. So they coded the OS to accept either "/" or "\" character as the path character (this continues today, btw - try typing "notepad c:/boot.ini" on an XP machine (if you're an admin)). And they went one step further. They added an undocumented system call to change the switch character. And updated the utilities to respect this flag.

[1] http://blogs.msdn.com/b/larryosterman/archive/2005/06/24/432...

-----

dmethvin 508 days ago | link

Larry has that wrong, IBM wasn't to blame.

IBM licensed DOS from Microsoft. Microsoft bought DOS from Seattle Computer Products QDOS. That software got its command line switches using "/" from CP/M for compatibility reasons; originally, both CP/M and MS-DOS were available for the IBM PC.

CP/M borrowed the convention primarily from RT-11, the OS for the PDP-11, although it wasn't consistently followed there. Programs on RT-11 were responsible for parsing their own command line args, and not all of them used the same convention.

Inside Windows itself, most APIs accept either forward or backward slashes in paths (even both in the same path) without any special incantation. The problem is mainly at the application level where the whole forward/backward slash thing gets messed up because technically you should accept either one from user input and most app code expects one or the other.

-----


Why doesn't he just go to the local sports bar?

-----

estel 628 days ago | link

With up to 24 simultaneous events for 12 hours a day across 18ish days, that's a lengthy time spent at a bar that might not even be showing the event you're interested in.

-----


I use most of these methods for caching. I have my own little methods for making cache keys. I use Rails.cache all over the place. I have a couple sweepers. What I really struggle is testing this stuff. You really can't do it anywhere other than an integration test, and they're ugly. I mostly just test the sweepers. Anyone have any nice solutions for testing caching, or think its unnecessary?

-----

joevandyk 788 days ago | link

I would try to remove as much caching as possible. It is complicated and hard to test.

-----

nfm 788 days ago | link

I haven't had a lot of experience with caching, and I agree with your comment above about database views, but wouldn't the complications be mitigated by using the approach DHH detailed recently? http://37signals.com/svn/posts/3113-how-key-based-cache-expi...

That is, incorporating `updated_at` into the cache key, and using `touch: true` on your AR relations to make sure that caches of affected parent objects get expired too?

Are there other complications I may not have run into yet?

-----

joevandyk 788 days ago | link

Imagine you have User has_many Comments. When someone's username is updated, you might need to update all the user's cached html comment fragments to include the new username.

However, ActiveRecord doesn't support touch on has_many relations. (It probably shouldn't, as updating the username would mean updating/touching thousands (or more) comment rows).

Also, if you have to update the database outside of ActiveRecord for any reason, you could be screwed - the cache would become out of sync with the database.

-----

nfm 787 days ago | link

Cheers, a helpful and extremely likely case!

-----

johnkchow 788 days ago | link

I've never had a production Rails project, but do you have any anecdotes or numbers to back up your statement? From initial glance, it looks like the win in processing speed outweights the complexity. So then you're implying that this win isn't required. I'm assuming that scaling out is cheaper than the complexity cost of implementing/maintaining such a caching solution?

-----


Uh yeah, of course html5 sound is awful. I'm hoping projects like areweplayingyet.org will gain traction to help solve this.

-----


Oh great another ultra thin laptop with a glossy screen that will probably last 1-2 years until you buy another one that is even thinner and the screen so shiny you can use it as a shaving mirror. Give me a laptop that will last me more than 2 years and then I will give a damn.

-----

freedrull 940 days ago | link | parent | on: A zsh Workshop

Looking through the feature list, is there anything that stands out as something bash cannot do, that is useful and not superfluous(like checking the mailbox?!)?

http://www.acm.uiuc.edu/workshops/zsh/why.html

-----

Symmetry 940 days ago | link

Nope, none of the cool stuff, like extended globbing or name completion, that makes me use zsh rather than bash is on that list.

-----

crazydiamond 937 days ago | link

Have your tried https://github.com/zsh-users/zsh-history-substring-search ? Search history using substring of earlier command. Really good.

-----

freedrull 961 days ago | link | parent | on: GitHub Flow

Learn to use rebase and squash commits! It solves a lot of the issues you talked about.

-----

cpeterso 961 days ago | link

Ironically, it seems like more feature branches is the solution to the "feature branch problem". :) With more, smaller branches, their changes will be laser-focused and easier to squash.

-----

pgr0ss 961 days ago | link

Squashing commits can fix up git history, but it does not address the bigger issues: refactoring, lack of builds, and having to deploy multiple branches to test features. The first two make it very hard to do any significant code reworking on a feature branch.

-----

tpz 960 days ago | link

I intend no ill will with this response, but it is worth pointing out that "the first two" "bigger issues" have nothing to do with your revision control system.

Lack of builds is something about which you and your CI server need to have a chat, and refactoring is something about which you and your people need to have numerous chats before, during, and afterwards.

-----

simonw 961 days ago | link

GitHub seem to have solved both the lack of builds issue and the challenge of deploying multiple branches (their bot can deploy a branch to staging with a single command) - which just leaves refactoring. I imagine they deal with refactoring by broadcasting a message to the team saying "I'm working on refactoring area X, try not to touch that code until I'm done if you don't want to deal with a painful merge".

-----

More

Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library

Search: