I've been looking to evaluate the red programming language - red-lang.org
While it is nice that you can obtain a working executable easily I prefer to compile things from source. It is less obvious how to do that for red.
The instructions ask you to download a rebol compiler/intepreter which is itself just an executable.
If you do that it works but it screams "don't do that" very loudly.
rebol> do/args %red.r "-v 2 %tests/hello.red"
will compile hello world but how do you bootstrap the red compiler itself?
1. Assuming you have rebol how do build the 'red' executable?
aside: Are the authors aware that there is a program called 'red' installed on many Linux boxes already (a version of the ancient ed program)?
I thought this might be done by:
rebol> do/args %red.r "-r %environment/console/console.red"
but "console" is not the executable also known as 'red' it doesn't support the same commmand line options such as -c to compile.
2. Assuming the proper way to do this involves bootstrapping from rebol (rather than C or something else) how do you build (a suitable) rebol from source?
I would like to build both red and red/system or any other interesting variants.
This question mentions a youtube video but is there something written down somewhere?
This seems like the sort of thing than ought to be near the front of the documentation to me.
I asked a similar question in their Google Group about a year back.
https://groups.google.com/forum/#!topic/red-lang/zZ3jEeNJ5aI
The short answer is this ...
The current “bootstrap” Red compiler is written in Rebol. Rebol is not compilable. The downloadable Red binaries are not compiled but encapsulated (containing both the compiler and a Rebol executable) using the Rebol Software Development Kit (SDK). The Rebol is SDK is a commercially licensed product that is probably not available any longer. (The REBOL SDK used by the Red team is properly licensed).
There are scripts and instructions on how to build a Red binary at https://github.com/red/red/tree/master/build
That said anything you can compile with the Red binary, you can compile with the source compiler. The source compiler is just as fast as the “binary” one. (As you know, the source compiler happily runs under free Rebol versions that are still easily available.) In fact, the red team uses the source compiler not the “binary” one.
So until the self-hosted Red compiler is available, there are two basic options:
if you want to use the Red binary, get it from the automated builds
if you want the absolute, up to the minute compiler, use it in source form.
Hope this helps.
Peter
Related
When (dynamically) compiling CUDA code to PTX, you can pass the --generate-line-info command-line parameter, and get a bunch of .loc entries in your PTX, which relate PTX locations to source file locations.
Is something like this also available when compiling OpenCL code into PTX (clBuildProgram) on NVIDIA platforms?
Try -nv-line-info. I can't find documentation for it, but the compiler accepts it and generates exactly what you are looking for.
The option is notable absent from their official OpenCL compiler options extension.
NOTE: Your mileage may vary. A few years ago when I fiddled around with this the mapping accuracy was not great compared to CUDA +nvcc. Maybe they've improved things though.
Suppose that there is a simple binary that depends on three libraries, libA.so, libB.so, and libC.so. In the usual case, these three dependencies would show up in readelf as needed. However, I am curious about whether it is possible to make a shared library libABC.so that does absolutely nothing but act as an interface to the three actual libraries by "redirecting" the symbols. This way, perhaps one can have multiple versions of libABC.so that in turn point to different versions of the three dependencies, and the binary can "depend" on just libABC.so. Is this possible with ELF?
Another possible use case is the inverse, when the binary already depends on an existing library libABC.so that just so happens to have become split up into three individual libraries.
Beware that I do not necessarily have a practical use or actual use case for this. Whether or not the above example cases are practical, I am merely curious about the possibility.
Re-export Shared Library Symbols from Other Library (OS X / POSIX) has a promising title, but the answers seem either Darwin-specific, or do not quite answer this question.
That kind of works with ELF because of the flat namespace of symbols: if you're depending on one library you usually get access to the symbols of its dependencies at the same time (the exception being when dlopen() is used).
But most link editors (ld) do not do that by default (anymore), because it would let unneeded libraries to be added to the dependencies otherwise. In GNU ld the feature is controlled by the --as-needed flag, and was turned on around 10 years ago by default if I remember correctly.
You should be able to force the behaviour you're looking into with GNU ld by linking (e.g. via the GCC frontend) with gcc yourprogram.c -Wl,--no-as-needed -lABC -Wl,--as-needed. That will force linking to libABC.so whether the program is using one of its exported symbols or not.
I have written extensively on the feature, because it solved many problems for distributions at the time, on my blog if you're looking into what the practicalities of it are.
Can someone help me on porting a game written in BlitzBasic to BlitzMax IDE. I tried running the .bb file into MaxIDE but it says "process failure with file.bb". Also where can i find more information regarding this?
You must rename the .bb files to .bmx. Though a superset, BlitzBasic is a completely different language than BlitzMax.
You can use the BlitzMax IDE Community Edition project which has the feature to import .bb files then convert them to .bmx files.
In regard to the 3D commands part and as Spark Fountain as mentioned, it is not supported by default, but you can use MiniB3D or OpenB3DMax.
http://blitzmax-ide.sourceforge.net/
BlitzMax IDE Community Edition
BlitzMax introduces several new features such as classes, real object orientation, inheritance and many more. Anyways, most of the BlitzBasic syntax elements remain or can at least be re-used.
To port your BlitzBasic programs to BlitzMax, I suggest you learn and understand the basic language elements. You can also use the following guide as a starting point.
comments start with ' or REM instead of ;
arrays are defined with Local array[10] instead of Dim array(10)
3D commands are not supported but you could use i. e. MiniB3D
I'm looking into installing a disassembler (or decompiler) on my Linux Mint 17.3 OS and I wanted to know what the difference is between a disassembler and a decompiler. I have a rough idea of what they are (the names are fairly self-explanatory), but they are still a bit confusing.
I've read that a disassembler turns a program into assembly language, which I don't know, so it seems kind of useless to me. I've also read that a decompiler turns a 'binary file' into its source code. What exactly is a binary file?
Apparently, decompilers cannot decompile to C, only Python and other similar languages. So how can I turn a program into its original C source code?
A disassembler is a pretty straightforward application that transfers machine code into assembly language statements - This activity is the reverse operation that an assembler program does and is straightforward because there is a strict one-to-one relationship between machine code and assembly. A disassembler aims at a specific CPU. The original assembler that was used to create the executable is only of minor relevance.
A decompiler aims at recreating a compiled high-level language program from machine code into its original format - Thus trying the reverse operation of a C or Forth (popular languages for which de-compilers exist) compiler. Because there are so many high-level languages and thus so many ways in how original high-level language constructs could be expressed in machine code (even a lot of different strategies for the same language and construct, even in the same compiler, and even different strategies depending on the compiler mode and situation), this operation is much more complex and very dependent on the original compiler (and maybe even the command line that was used, it's chosen optimization level and also the used version).
Even if all that fits, most of the work of a decompiler is educated guessing and will most probably never reach a point where it can reconstruct the original program in its source code form 100% - It will rather end up with a version of source code that could have been the original program.
Christian Queinnec has written a masterpiece called LISP In Small Pieces, which features eleven Lisp Interpreters and two Lisp compilers.
When you go to download the code from the website here - it has the comment:
The programs of this book are available on the net.
These programs used to run with some Scheme systems around 1994.
Any idea:
(a) What Scheme systems these ran on at the time, and more importantly;
(b) What Scheme systems these would run on today?
There's a lot of programs in there. I did a few tests to see how well I could answer this without having to try them individually. There are 131 files in the tarball with extension ".scm". However there appear to be Scheme programs with other extensions such as .bgl. So I did a search for files containing 'L i S P' in the first five lines. That yields 173 files. I tried running all of these on my preferred Scheme implementation. 31 of these run without error. Almost all of these are in the "src" directory. So the language-specific programs really do seem language-specific. Let's look at one of the src/ files that failed, "chap9z.scm". It's choking on define-abbreviation. I don't know the origin of this symbol, but it's not defined anywhere in guile. But all of its uses could be performed by guile's syntax-rules.
Some Scheme implementations that existed in 1994 still are still around and maintained: Scheme 48, Chez Scheme, Gambit, Bigloo, MIT Scheme and SCM.
Probably the code from LiSP will run in other modern Scheme systems such as Guile or Larceny.
Personally, I would recommend using Racket. Most likely, much of the code will run in #lang racket with no changes, and there's no requirement to use [] (but your code may be easier to read :). Things that don't work are probably easy to fix, and you can also use the R5RS language implementation provided by Racket which will likely work for all of the code.
(a) What Scheme systems these ran on at the time
The Makefile in the source tarball from the author's website has targets for running the code under bigloo, elk, gambit, mit-scheme, scheme2c, and scm.
The Makefile mentions SCM 4e1 and Bigloo 1.9d as known working versions, though I haven't tested them myself. I didn't find any mention of specific versions for the other schemes.
(b) What Scheme systems these would run on today?
The code in this github repo has been updated so that almost all of the tests in the included test suite pass with current (as of 06/2014) versions of bigloo, gambit, and mit-scheme.
If you just want to be able to run the code and follow along with the book, one of those schemes should work for you.
[full disclosure: I'm the owner of the repo and I'm a Scheme noob. The code in the repo is WOMM certified, but your mileage may vary.]
If, on the other hand, you're not content to use bigloo / gambit / mit-scheme, it shouldn't be too hard to add support for guile / racket / insert-favorite-scheme-here. Use one of the book.* files as a starting point, e.g. gambit/book.scm or mitscheme/book.mit. If you can get a version of book.scm to load in your favorite scheme, then have a look at the test.interpreters make target, and finally the grand.test target to verify things are working as expected.
The included README file states:
These files were tested with a Scheme interpreter augmented with
a test-suite driver (tester.scm),
the define-syntax and define-abbreviation macros (using
Dybvig's syntax-case package),
and an object system: Meroonet (meroonet.scm).
Bigloo, Scheme->C, Gambit, Elk or SCM can be used. The first three are
better since a specialized interpreter may be built that contains a
compiled Meroonet and compiled hygienic macros.
Apparently Appleby has posted an updated version of the source code. Racket is missing though )=
See https://github.com/appleby/Lisp-In-Small-Pieces