|
News
I would like to apologize for the lack of updates to sbf. Two factors have contributed to this:
1) The translation. I am trying to do a restructuring of the brainfuck-to-language-X translation functions so that they are more efficient. Previously, the translate() function simply called the appropriate function for language X and was done, and all the real grunt work was done in the language X translation function. This means that several loops that did essentially the same things were repeated for each language. This is horribly inefficient. I am trying to restructure the code so that the translate() function does more of the grunt work, and only calls out to other language-specific functions when it needs to. I would have used function pointers and left it at that, but the damn java_header() function needs one more argument than all the other lang_header() functions, so I opted not to require them all to take an extra argument. And I'm not looking forward to writing the massive if { ... } else if { ... } else blocks that need to be written.
2) I have a life. More accurately, I have school.
This can be seen as an open call to any C (and maybe brainfuck) programmers out there who want to aid me. In particular, if you have any nifty ideas on how to handle the problem of trying to deal with all the different languages, please tell me. I might still use function pointers, but the _header() functions can't use it because of our outlier Java, and the _footer() functions can't use it because all the languages have different footer requirements (Perl/Python/Ruby have no footer, C/C++ simple modes have really basic footers compared to the full mode footers, etc.), so it looks like the only time I can try a function pointer is for the _main() functions. Ah well. It'll work.
Anyway, yes. Anyone who is interested in trying to help me with this during this time of intense activity when I can't really do a lot of heavy C work, that would be awesome. Right now I'm focusing on a related-ish side project for fun, but I'll try to help out as much as I can. If not, of course, I'll just have to find enough time to do it myself. Such is life.
One thing that I have done is improved the code reader. The translator has always been fine, but will now be easier, and the interpreter is now fixed. Previously, large amounts of brainfuck code (such as that generated by the bfer.bf program, which takes text input and outputs a brainfuck program that prints the text it recieved as input) would trip up the interpreter - it would try to read the code in chunks, and preserve the state of the brainfuck list between reads. It needed to read entire loops at a time, though, otherwise the loop would fail, so if a program had a particularly large loop you would get UNBALANCED BRACKETS! errors even if your program appeared to work. This is now fixed. sbf supports a brainfuck code-reading function that reads the entire brainfuck-relevant contents of a file into the program via dynamic memory allocation. I also re-implemented the ANSI version of the my_gets() function with the same techniques to read an entire line, regardless of length. Such code can be memory intensive, but on modern CPUs the performance for both functions is fine. If you're using the ANSI my_gets() and you try to enter more than about 1,000 characters on a single line, you may begin to notice some performance penalties due to repeated calls to strlen() and realloc(), but the getcode() function which is used on files reads the entire BSD.bf (generated by bfer.bf, prints the BSD license) almost instantly on my computer. getcode() does not use calls to strlen(), but a counter variable to keep track of string length, so the response time is much faster. my_gets(), however, uses fgets() instead of getc() to get characters in larger chunks, and has a buffer of 100 characters, so it will be completely fine for most average users (who will rarely enter more than 80 characters on a standard terminal window anyway).
Expect at least basic optimization capability in the next release, even if it's only for Perl/Python/Ruby. C/C++ full translations, due to the nature of linked lists, make it harder to optimize the > and < commands, but I'll see what I can do.
Also expect code for the interpreter to clean up after itself (i.e. any dangling 0s at the end of the list will be cleaned up during interpreting rather than at the end), so a program like +[->+] will loop forever and never run out of memory (hopefully). I tried to implement this before, but it broke the interpreter. I used an #if 0 to comment out the entire blocks, and I'm tired of them not working, so I'm going to get on it by the next release.
Top
sbf is now up to version 0.9.4! There are two major features of 0.9.4 - Ruby and Unicode.
In 0.9.2, Ruby translation was iffy, if present. In 0.9.4, Ruby translation is as well supported as Perl and Python, including the infinite list.
Also in 0.9.4, UTF-8 support has been added for those who are growing tired of the old ASCII. Now your brainfuck programs can take advantage of that extra bit for more than just math! brainfuck programs can now properly display the creator of brainfuck Urban Müller's name. UTF-8 is supported by the interpreter, the translator for C, Perl, Python, and Ruby, and by the compiler.
A number of old options have been renamed - -n is now -l and -r is now -p. -l lists a count of brainfuck commands and comments in a program. -p enters the interactive prompt (formerly REPL).
I've also added companions to the hex dump for those who prefer decimal (-n) and octal (-8).
I've also added a comment stripper (-d) and an option to disable cell wrapping (-w), in addition to planned support for raw (unbuffered) input (-r), which is just as useless as -o right now.
Optimization is still incomplete, but oh well! We got Unicode!
Top
A number of new features have been added, a number of broken things have been fixed, and a number of updates will soon be posted. Well, only one update, but you know how it goes.
New features:
-s option for simple translation. Instead of using confusing linked lists, it uses a flat array. Faster than linked lists, and code generated (and used) is easier to understand for newbies, but has inherent limitations on array size. Takes optional argument to specify the array size, defaults to 30,000 (the default in the original brainfuck implementation).
-x option to display all output as hexidecimal numbers rather than ASCII characters. Useful in writing brainfuck programs - you can just dump your state to stdout and not have to worry about non-printing characters. How nice!
Also added support for GNU Readline/BSD Editline in the REPL. If your system has either of these libraries, your REPL will no longer output arrows as "^[[A", but allow moving the cursor left and right in the line, inserting characters in the middle, and pressing the up and down arrows to cycle through a history of commands you've entered. All the nice things you're used to using. If your system does not have GNU Readline or BSD Editline installed, an ANSI line editor is provided, but it has none of the above functionality. Sorry. Working on it.
I also added a little Ruby translation from a Ruby interpreter. Input doesn't appear to work, but I don't know Ruby so I can't improve on it. Hopefully this will get fixed someday, along with the Java input problems.
I also added some new brainfuck programs (Gasp! Who writes brainfuck?) to the bf/ directory, and not all of them were just found on the Internet! I wrote itos.bf (input an ASCII character, output it's ASCII code) all by myself, with Urban Müller's divide by 10 function. The other big one, bfer.bf, is a fairly basic program I found that takes text input and outputs brainfuck code that produces said input. Also a program that outputs the lyrics of 99 Bottles of Beer seems to have crept in there at some point. I don't remember ever putting it in there, but perhaps that's how it should be.
The big fix:
ASSEMBLY LANGUAGE TRANSLATION WORKS! I finally implemented some working brackets, and all brainfuck programs I translate assemble properly with NASM, link properly, and then run properly. It is still a finite-list translation, but who cares? Despite this massive progress (i.e. all programs assemble/link/run properly out of the methaphorical box) assembly is still only available in experimental builds. Now on to linked lists...
And actually, that's the only broken thing that was fixed. Java input still doesn't work, Lisp enlightenment still eludes me.
Anyway, I'm wrestling with some interface issues (I want to add more features than I have letters for), so I'll make a new release once I get that over with. Or maybe sooner. Depends.
Todo:
Add comment stripping feature.
Add Unicode support (?).
Add unbuffered input (??).
Add more than just hex dumps.
Restructure assembly translation (?).
Restructure compiling (??).
Top
I have uploaded sbf to the tubes! At last, the taste of sweet, sweet victory!
Ahem. sbf, version 0.9.2, is now available for download in source code form at SourceForge.net. Just go to https://sourceforge.net/project/showfiles.php?group_id=246670&package_id=303658 and select the compression format of your choice (I recommend .tar.bz2 - it's the best compression of the three), and then download it!
There are some issues that still need to be resolved:
1) Windows users will probably need Cygwin to install it. In the future, it may be easier to provide a precompiled version for Windows, because I can't re-write the config.sh shell script for DOS. And however horrible DOS is I want sbf to run natively on it if possible.
2) Some of sbf's documentation may be out of date, and the "-h" flag shows at least one flag that sbf no longer supports (hint: it's -s)
3) Java, Lisp, and assembly still don't work.
4) bf2C (the extra program made with "make extra") is massive, because rather than make the program more complicated, I just linked more files together. Bad practice I'm sure, but it works, and it demonstrates the (easy) way to interface with sbf's functions and steal its code. Perhaps later I'll make a better implementation of bf2C that is leaner and does it the harder (but better) way. Later.
5) THE OPTIMIZATION FLAG (-o) IS STILL USELESS and the code is written only so I have room to add it in later. Again, there is currently NO OPTIMIZATION done on anything. Writing an optimizer is what will take sbf from 0.9 to 1.0. Until even a basic optimizer is written, sbf will go all the way to 0.9.42 if it has to.
Most of those caveats (all but the last) are relatively minor and can be worked with easily. I look forward to any feedback and anyone willing to contribute to the optimizer.
Top
sbf source code and documentation will be online soon. I promise. I just need to iron out some interface issues. 0.9.something will probably be online by this time tomorrow. At the very least before Friday.
Top
No newer entries |
Older |
|