Section 3.5 of Structure and Interpretation of Computer Programs describes streams. Does Common Lisp have such streams built in or is there a good Common Lisp library implementing such streams?
[I mean streams in all the generality presented in section 3.5 of SICP; not just your usual i/o streams.]
SERIES is a featureful library providing that sort of functionality. For a shorter and more readable example of how the concept of streams maps to Common Lisp, see Pipes.
Related
I have been reading about libadalang 1 2 and I am very impressed by it. However, I was wondering if this technique has already been used and another language supports a library for syntactically and semantically analyzing its code. Is this a unique approach?
C and C++: libclang "The C Interface to Clang provides a relatively small API that exposes facilities for parsing source code into an abstract syntax tree (AST), loading already-parsed ASTs, traversing the AST, associating physical source locations with elements within the AST, and other facilities that support Clang-based development tools." (See libtooling for a C++ API)
Python: See the ast module in the Python Language Services section of the Python Library manual. (The other modules can be useful, as well.)
Javascript: The ongoing ESTree effort is attempting to standardize parsing services over different Javascript engines.
C# and Visual Basic: See the .NET Compiler Platform ("Roslyn").
I'm sure there are lots more; those ones just came off the top of my head.
For a practical and theoretical grounding, you should definitely (re)visit the classical textbook Structure and Interpretation of Computer Programs by Abelson & Sussman (1st edition 1985, 2nd edition 1996), which helped popularise the idea of Metacircular Interpretation -- that is, interpreting a computer program as a formal datastructure which can be interpreted (or otherwise analysed) programmatically.
You can see "libadalang" as ASIS Mark II. AdaCore seems to be attempting to rethink ASIS in a way that will support both what ASIS already can do, and more lightweight operations, where you don't require the source to compile, to provide an analysis of it.
Hopefully the final API will be nicer than that of ASIS.
So no, it is not a unique approach. It has already been done for Ada. (But I'm not aware of similar libraries for other languages.)
I want to convert my lane detection code written by C++ (OpenCV) to FPGA. Vivado HLS or Vivado SDSoC can help to embed the C ++ code into the FPGA. Or I can rewrite the lane detection code with verilog. The question is, what are the advantages and disadvantages of these three ways?
I want to use one of the cheap Zynq-7000 FPGAs.
Verilog is considered low-level these days. Compare it with assembly for software implementation. People use it only to get performance that they cannot attain with high-level languages such as C or Java in the software domain.
In the hardware domain, C (for Vivado HLS) or OpenCL are considered high-level languages. OpenCL was developed with portability to other architectures like GPUs and CPUs in mind. It has a lot more overhead in terms of communicating with the FPGA than Vivado HLS however.
Vivado HLS by itself produces just hardware modules in VHDL or Verilog, which you still have to connect to FPGA pins, ARM processors, etc. It does not take care of the communication to your module. You will still have to integrate your module in a Vivado block design or top-level VHDL or Verilog implementation yourself.
SDSoC, not "Vivado SDSoC" by the way, also lets you to write your entire implementation (hardware and software) in C. Under the hood, it will invoke Vivado HLS to implement the hardware module. Afterwards, the tool will take care of implementing an interface between your hardware and the on-board ARM processors that will run the software.
In summary, I recommend SDSoC unless you have a good reason not to use it. I do want to warn, however, that analyzing the synthesis results of Vivado HLS is a lot harder than analyzing Vivado output for Verilog or VHDL. Therefore, I always recommend to make sure that your code works as a software implementation first. With minimal effort, you should be able to compile any code in gcc or another compiler too. Don't use the synthesis results to debug your code, but just to analyze the performance.
SDSoc is better and easier, HLS like a blackbox, even UG902 have so many pages.
only my own opinion.
Take a look at Xilinx XAPP1167 and the Xilinx HLS Video Library Wiki.
That appnote is a few years old (older than the SDSoC tools) but has a reference design for accelerating OpenCV applications in a Zynq using HLS.
I can't speak to SDSoC, but I would highly recommend starting with HLS over a rewrite in Verilog. It sounds like you have exactly an intended use-case for HLS: to implement existing C++ applications in an FPGA. The downsides to it are (1) you'll likely need to modify your code a bit, since HLS doesn't support all C++ features, and (2) the performance may not be quite as good as a pure Verilog implementation.
Even if you have hardware design experience, manually translating C++ to Verilog will require some significant effort. I'd avoid that approach unless HLS or SDSoC doesn't give you the performance you need.
Start using OpenCL SDAccel or Intel SDK. OpenCL has verbose and well defined API - which is a good thing. It is very easy to learn and you can have parallel code execution similar to multi-module instances of Verilog/VHDL. OpenCl vs. HLS has benefits in not requiring to re-invent the whole system for managing data, I/O, pipes. etc. You get quite a bit of helper logic in OpenCL BSP (Intel) or shell (XILINX). Yeah, and start reading these long guides.
I would recommend SDAccel, as it is much more C++ "software" user friendly. At the same time, don't quote me on this, but I think they provide a OpenCV implementation out of the box, which means that probably you only need to massage you non-OpenCV code to achieve the performance you want.
I would like to provide a very simple scripting interface for a program I'm working on. My program would expose some functions that could be called from the script. I don't need much, maybe just variables, if/else, and loops. The two most popular languages seem to be lua, and python. I really do not like lua from my days of writing World of Warcraft plugins and both seem a lot more complicated than I need. What other languages are available?
Try the Ring programming language (http://ring-lang.net)
The compiler + The Virtual Machine are 15,000 lines of C code
The Ring can be embedded in C/C++ projects, extended using C/C++ code and/or used as standalone language.
The language is simple, trying to be natural, encourage organization and comes with transparent implementation. It comes with compact syntax and a group of features that enable the programmer to create natural interfaces and declarative domain-specific languages in a fraction of time. It is very small, fast and comes with smart garbage collector that puts the memory under the programmer control. It supports many programming paradigms, comes with useful and practical libraries. The language is designed for productivity and developing high quality solutions that can scale.
Learn about embedding the language from
https://en.wikibooks.org/wiki/Ring/Lessons/Embedding_Ring_Interpreter_in_C/C%2B%2B_Programs
I'm figuring that CORBA is considered a legacy technology that just refuses to die. That being said, I'm curious if there are any known standards out there that are preferred (and are also as platform independent.)
Thoughts? TIA!
Many organization are moving to WebServices and the open standards relating to them (HTTP, WS-*) as alternatives to Corba.
This article provides a comparison of the two technologies and offers some recommendations on when to use which.
If you really care about platform independence and protocol standardization - then the WS-* standards are something to look into.
There is now a state of the art modern CORBA implementation using C++11, TAOX11. This uses the new IDL to C++11 language mapping. For TAOX11 see the TAOX11 website. TAOX11 is supported on a wide range of platforms and compilers.
I have recently tried Google Protocol buffers, they seem rather similar to CORBA by design (some kind of IDL with compiler, binary compact messages, etc). It is probably one of the many possible successors.
Web services are good for the right tasks but creating and parsing messages needs more time and text based messages are more bulky than binary ones. REST API with JSON looks like a good solution where binary protocols do not fit well.
ICE from ZeroC aims to be a "better CORBA".
Unfortunately their licensing terms are crap (at least last time I checked with them), as they do not sell developer licenses but only (roughly) per-installation terms.
It is offered via GPL license too, if you can live with this.
I'd like to implement a Lisp interpreter in a Lisp dialect mainly as a learning exercise. The one thing I'm thrown off by is just how many choices there are in this area. Primarily, I'm a bit more interested in learning about some of the Lisps that have been around a while (like Scheme or Common Lisp). I don't want to use Clojure to do this for the sheer fact that I've already used it. :-)
So is one of the flavors any better than the others at parsing? And do you think it's a good idea to say implement Scheme in Common Lisp (or vice versa)? Or will there be enough differences between the two to throw me off?
And if it makes any difference, I'd like something that's cross-platform. I have a Windows PC, a Mac, and a Linux box, and I could end up writing this on any of them.
There are some books about that:
SICP chapter 4 and 5
PAIP, chapter 5
LiSP, the whole book explains implementing Lisp
Anatomy of Lisp, old classic about implementing Lisp
All of the above books are highly recommended, though Anatomy of Lisp is oldish, hard to get and hard to read.
Both Scheme and Common Lisp are fine for your task.
Implementing Common Lisp is a larger task, since the language is larger. Usually one implements Common Lisp better in Common Lisp, since there are Common Lisp libraries that can be used for new Common Lisp implementations. ;-)
PLT Scheme is an excellent platform for experimenting with programming languages, especially Lispy languages. PLT has an extensible parser (usually called a reader in Scheme) that provides reader macros to manipulate the built in syntax; or you can completely replace the reader with your own. If you'd rather use traditional lex/yacc style parsers and lexers, PLT comes with a parser-tools module that provides those, too. As a bonus, it has comprehensive documentation and a repository for third-party packages (two things that are missing from a lot of Schemes).
The reference implementation of Arc (arclanguage.org) is a fairly simple and readable
example of building a language that compiles to Scheme. It uses PLT's reader mostly, with a couple of reader macros to change the bits of Scheme syntax that differ from Arc's. There's also a JavaScript implementation available from PLT's package repository (planet.plt-scheme.org) if you want to see how to implement a non-Lisp language.