Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
deng
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
69 ms
·
871.
▲
by
deng
12y ago
> They stopped updating GCC precisely when they decided, and announced, they were moving to llvm/clang. Not true. They switched to clang with OS X 10.7. That was 2011. At that time, their gcc fork, based on 4.2 and carefully avoidi
872.
▲
Linux RT: New stable release, but next one depends on more support from industry
(osadl.org)
2 points
by
deng
12y ago
|
0 comments
873.
▲
by
deng
12y ago
> Your reply certainly implied you thought GCC was fine along the same axises your parent said clang was better. No. I simply corrected a false statement regarding gcc. I did not compare it to clang at all. I have no illusions how gcc do
874.
▲
by
deng
12y ago
For years developers begged Apple to update gcc, and they did not do it. Mind you, that was at a time when Clang was not nearly where it is today. They dumped Samba and replaced it with a new development of their own that was vastly i
875.
▲
by
deng
12y ago
> The licensing stuff is tangential. Yes, it's their stated reason, but it's a cover story. So it's a pure coincidence they stopped updating gcc in OSX right when it moved to GPLv3? And the reason they stopped updating bas
876.
▲
by
deng
12y ago
Did I say that gcc has the better infrastructure, the more modern code base, better modularity? I don't think so. That would actually be pretty weird, given that its code base is nearing 30 years of history. But I hope that it is still
877.
▲
Add new warnings to GCC with Python
(blog.cuviper.com)
1 points
by
deng
12y ago
|
0 comments
878.
▲
by
deng
12y ago
GCC has support for plugins since version 4.5, which is over four years old. Also, the error messages have improved greatly in the last releases.
879.
▲
by
deng
12y ago
More information from Tollef Fog Heen: http://err.no/personal/blog/tech/Debian/2014-11-16-23-55_res...
880.
▲
Resignation from the pkg-systemd maintainer team
(lists.alioth.debian.org)
195 points
by
deng
12y ago
|
162 comments
881.
▲
Editing Julia code with Emacs
(wilfred.me.uk)
38 points
by
deng
12y ago
|
10 comments
882.
▲
by
deng
12y ago
Previous discussion: https://news.ycombinator.com/item?id=3896404
883.
▲
by
deng
12y ago
> but also some long term contributors have ceased contributions because they considered bzr to be too much of a hassle I wonder who those could be. I can't remember any major contributor leaving because of bzr.
884.
▲
by
deng
12y ago
During which it became abundantly clear that he is surely no git expert (which does not diminish the work he did).
885.
▲
Welcome, New Emacs Developers
(lars.ingebrigtsen.no)
195 points
by
deng
12y ago
|
45 comments
886.
▲
by
deng
12y ago
Then you are a lucky man. Ever tried to work with MsysGit in a Cygwin shell? For starters, there's the CR-LF vs LF problem, which can screw you big time. Then there's the problem that Cygwin handles Windows paths differently from
887.
▲
by
deng
12y ago
Indeed. Cygwin is fantastic, but one must always remember: once you go there, you can never go back. If you mix native Windows binaries with ones from Cygwin, all kinds of weird things can happen. I mostly work with native Windows binaries
888.
▲
by
deng
12y ago
MsysGit is still way slower than Git on Linux, at least on larger repositories. Calling stat() on lots of small files is pretty much a worst-case scenario for NTFS.
889.
▲
by
deng
12y ago
From the looks of it this is definitely not an alternative to Cygwin, because the latter implements a complete POSIX layer. Instead, this seems to be a collection of native and MSYS binaries, which is fine and all, but I kinda doubt that th
890.
▲
by
deng
12y ago
I see your point, but still find it to be a very nice visualization, and I think the 2D interpretation is actually quite close. I really like that pupils can play with this themselves. Yes, you'd be more exact with showing bending spac
891.
▲
by
deng
12y ago
Was there any work done to replace XML for configuration? You may call it superficial, but I'd make that a priority over pretty much everything else. Many people won't get past that bullet point.
892.
▲
by
deng
12y ago
The actual Lisp interpreter is rather tiny compared to the other stuff. Just do a 'ls -l *.c | sort -gk 5' in the src directory. By far the largest file is xdisp.c, which is the redisplay engine, and only a handful of people in th
893.
▲
by
deng
12y ago
Your information is old. You can easily access the C++ parse tree by writing a gcc plugin. This is possible since gcc 4.5 or so, but somehow nobody really noticed since everyone just stared at the new kid on the block. You might say the tre
894.
▲
by
deng
12y ago
RMS is fine with an FFI as long as you cannot use it to inject non-free code. This is usually done by requiring an exported symbol saying that the code is GPL compatible. GCC does it this way: https://gcc.gnu.org/onlinedocs&
895.
▲
by
deng
12y ago
You are aware though that without RMS we wouldn't have Emacs?
896.
▲
by
deng
12y ago
The name is correct, but I'm not CEDET's maintainer; that would still be Eric Ludlam, its original author.
897.
▲
by
deng
12y ago
Regarding the C++ parser, here's the current state: It does not support any C++11. Especially 'auto' is problematic, since type inference is quite a hard problem. Basic templates are handled, but things like template speciali
898.
▲
Thomas Gleixner lacking proper funding for RT-PREEMPT Linux development
(mail-archive.com)
3 points
by
deng
12y ago
|
0 comments
899.
▲
by
deng
12y ago
> This will revolutionize programming education. It could, if it were open and not limited to iOS/OSX.
900.
▲
by
deng
12y ago
As I've written, there is a core written in C. The ratio of Emacs Lisp vs C is about 80/20. 20% might look rather large at first, but if you keep in mind that Emacs supports a large variety of operating systems (from MS-DOS(!) ove
More ›