As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
The current, official compiler for Go (http://code.google.com/p/go/) currently uses a handcrafted, arguably arcane code generator, which includes injecting custom sections into the ELF Binary.
This approach has spawned quite a few bugs related to utilities that directly read and/or write ELF Information, such as ldd, objdump or strip.
I believe that this could have been prevented by using a welltested crossplatform code generator, such as LLVM, and then just use linking facilities shipped with the OS, such as ld on Unix/Linux (or ld.exe on windows w/ MinGW), or link.exe on Windows with Visual Studio.
So why does Go use its very own code generator? Is it really just reinventing the wheel? Or are there more important reasons behind it?
For information on how to use gccgo, a more traditional compiler using the GCC back end, see Setting up and using gccgo.
The Go Language Specification is compiler agnostic. You can choose from the available compilers, write one yourself, or contribute to the LLVM Go frontend project.
For an historical perspective on the Go compiler technology, read the answer to this question: What compiler technology is used to build the compilers?
The reference compiler (5g, 6g, and 8g, collectively referred to as gc) was written by Ken Thompson based on the C compiler he wrote for the Plan 9 operating system. There are a couple reasons he did this:
He was already familiar with how his C compiler worked, so it was easier for him to adapt his existing work rather than learning an entirely new framework.
One of Go's goals is to compile fast. The gc compiler is probably faster than an LLVM-based compiler could be because it's just not doing as much work. Then again, it's also not optimizing as well.
As Peter mentioned, there's also gccgo, which uses gcc as a backend. I suspect there will eventually be other options for Go compilers, especially given that the Go libraries include a complete Go parser and a (partially complete) type checker.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Which are mature, maintained and flexible open source genetic algorithm (GA) libraries for Scala?
Mature meaning that it is quite feature complete and bug free, ideally well documented.
Maintained meaning that it is not an abandoned project, and it works fine with current the current (2.10) Scala version.
Flexible meaning that it is fully configurable, I can plug in my own chromosome representations, fitness, breeding etc. functions, and it is generic and uses well Scala's type system.
Ideally on GitHub so it integrates best with my work flow.
If your main priority is maturity, I'd recommend JGAP, a library written in Java (which I used in my bachelor's with very successful results).
Using the natural interoperability between Java and Scala, there shouldn't be any problems about that. (But sure it would be great to see a Scala equivalent to it in terms of maturity and flexibility, taking advantage of Scala idioms)
About being maintained, it has not released new versions since 2009.
Sure there are other implementations out there but just wanted to add my 2¢ about a library I would sure revisit when the need comes (even if it is to start a port).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I did a fair amount of Lisp programming a few years back, but it was all really console-based things. I did use cells-gtk(2), but now that's really not maintained anymore and obviously we're Gtk3 now.
Does anyone know of a good Lisp library for GUI programming (I don't mind if which dialect).
For Common Lisp all the solutions are listed in Cliki as usual.
Personally I am quite content with ltk, but it's probably not for complex GUIs. CAPI should be the best for such.
If you are into scheme check out chicken which gets compiled to C and has very good Foreign Function Interface support to call native C code. If you go down that path , a lot of options arise.
interfacing libGTK using FFI (easyffi example)
using the SDL egg
using the XLIB egg
using the cairo egg
good luck!
If you really mean that you don't mind the dialect, then you can have a look at Racket which has GUI toolkit.
You could also consider ABCL, which is a Common Lisp that runs in the jdk, and has interfaces for calling out to Java classes. The ABCL website has one or two simple examples of Lisp programs that use Java libraries for graphics.
Clozure Common Lisp and OS X Cocoa through CCL's Objective C bridge.
For common lisp you can try the LTK library, which is a wrapper for TCL/TK. Works on linuxes and on windows(on windows with the Active State distribution of tcl/tk).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a big project with many .c and .h files to navigate. What tool do you have the best experience?
I searched online and found users recommend etags, global, and ECB. I just wonder which one is best for my case so that I can stick with it. Thanks.
I think etags or ctags are easy to use. Many open source projects come with make rules to generate the databases for these type. For C++, ebrowse is better. Personally, I like to use a project bundled with emacs. If you download a 3rd party app, you will have to re-compile whenever you upgrade, and often there is more integration work. At least if you start with etags and ctags, you can find they don't have the needed features and then investigate some of the 3rd party eLISP packages.
I have made some assumptions.
You use *nix.
You use Gnu emacs.
Something else may be better with XEmacs and/or on Windows and OSx.
Apparently, global fits my criteria; but I have never used it personally. I have tried to get CEDET working and it is very difficult. It might be easier if your distro comes with a package (.deb, .rpm, etc) for something like CEDET.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've just watched a video of the Groovy inventor, James Strachan, in which he goes on quite passionately about loving Scala. That caused me to want to find out more about Groovy which lead me to Groovy++. Groovy++ is a statically typed and compiled version of Groovy (which is apparently completely dynamic).
I attempted to figure out what Groovy++ (latest version at 0.9.1?) was in contrast with Scala (latest version at 2.10). The activity on the Groovy++ forum doesn't have very much recent activity regarding the latest version for which to be able to draw much information.
So, is there a nice simple comparison/contrast of Scala to Groovy++? I am not interested in Groovy itself (other than being the basis upon which Groovy++ is designed) as I want to compare statically compiled features side by side. A simple advanages/disadvantages (i.e. tradeoffs) list is basically what I am seeking without having to do dozens to hundreds of hours of research and experimentation.
Thank you, in advance, for anything you can contribute to this contrast and compare query.
Groovy++ project died last year-ish, apparently due to schism between SpringSource Groovy team and non-SpringSource supported Groovy++ team (led by Alex T. who now seems to be an active contributor to the Kotlin project along with, ironically enough James Strachan).
Was pretty ugly, Alex T. was understandably pissed off about getting the rug swept out from under him (Spring Groovy announced their own static Groovy). Check through some of the Old Nabble entries for the back & forth, heated at times. Not sure how things stand now, competition brings out the best & worst, maybe both sides are over it...
At any rate I too bailed, ditching Groovy for Scala and am overwhelmingly happy to have made that decision -- Scala rocks, I dare say, it Scocks™, give Scala a try! ;-)
Groovy was a great transition-to-JVM language for me, but the lack of compile time guarantees just drove me nuts after awhile (probably why static Groovy project(s) came into being in the first place)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Dev-C++ was one of the first IDEs that I got my hand on long ago. To me, Dev-C++ was a small software that can be downloaded and I could quickly do academic assignments with it.
In my college, people have been suggesting Dev-C++ for a quick download and just do the homework, for a few generations now. I recalled I used to have some problems with Dev-C++, mainly not understanding what exactly are mingw, different dependencies, different compilers, and all the complicated stuff.
When I tried to go for bigger projects, I always have the trouble of getting help. Other online helps seem to favor Visual Studio a lot more. For veteran developers who understand compilers and how things go around in software development, this may not be so difficult. But for people who are new to learning programming, is Dev-C++ a reasonable choice? Or should they not use Dev-C++ at all? Will the end justify the mean in the long run?
It's my understanding that Dev-C++ hasn't been supported for a long time and accepts a lot of bad code which it should reject, and it's not recommended simply because it's low quality compared to Visual Studio. Dev-C++ was my first C++ development environment too, and I wouldn't recommend it. VS also has one hell of a debugger, and some strong online reference material, not to mention all the other fun features of having a proper IDE. Visual Studio Express is free for everyone, even the current version, and whilst it's not quite as powerful as the commercial versions, it's still far superior in quality to Dev-C++.
All you have to do is look at the supported versions of Windows. Their latest non-beta version doesn't even list XP as supported.