Is any benchmark for this language?
Is possible to create benchmark in integer?

? if the value at the data pointer is zero , jumps to the block with : or ; and executes the commands one by one up to its correlative ;, otherwise, it executes the code until it finds a : or ;.

Do you support code like this?

+?>+?>>:<<;:<;

Expanded:

+?
    >+?
        >>
        :
        <<
    ;
    :
    <
;

Are you able to figure out which : to jump to?

This is very annoying. The build triggers are getting sudo permissions to modify the OS filesystem on building the brain compiler.

I think it is better move all the statements for linking/creating libraries, move binaries and other stuffs to install trigger and keep build rule to just... build.

This is really more simple and clear.

So the INSTALL process will be:

make
sudo make install

I'm really angry about that, because I'm pain with the idiomatic way to build packages on ArchLinux don't allow to modify the OS before build the package. All the files need be put a sandbox, so after compressed, the system get all the files whose will be inserted on operating system and that way we can know exactly the files installed after it. That way is very simple remove the package.

Yes, it's very bad.

At the line https://github.com/brain-labs/brain/blob/master/src/ast/expr/Expr.h#L91, I found a small mistake where the method flag should_update is returning true. Is is supposed to return false instead and be overriden in the classes that implement updates.

It is not a bug, however it is good code patterns.

I was thinking of having a possibility to add LLVM IR.
That would be very useful for the creation of libraries for Brain. // using functions in the future
Any considerations?

The purpose of this issue is to lay down what needs to be done in order to clean the README.md file which is huge!

• Page introducing Brain, the language and its features
• Page introducing Brain alphabet which teaches in small pieces of code what each operator does
• Compiler information, how does it work? What are the available options?

I think it would be healthier for the project to make README.md small, any information more than an simple introduction is too much.

This issue holds all tasks that we need to do to reach 1.0! If you have done a task, please, mark it, and then add the commit hash aside of the task which you completed it.

Features and whatnot

• Fix file testscripts.c.
  • Linux.
  • Mac.
• Implement ?, :, ;.
• Ignore else's without if's.
• Improve the methods IsBranch, IsTerminator and so on.
• Code refactoring for the return methods inside the recursivity.
• Code refactoring for the whole project. Improve readability (CodeGen params too).
• Create verbose mode describe on https://github.com/luizperes/brain/issues/2
• Fix InputExpression
• Implement optimization for empty whiles [ ]. Ignore them (For Else too).
• Implement optimization for empty moves ShiftExpr(0) and IncrementExpression(0).
• Change the if and while.if (*ptr != 0), not if (*ptr > 0). Although for is going to work only for positive numbers.
• Implement -version flag.
• Allow the compiler to have cells larger than 100 x 4
• Implement a generate optimized code option for the compiler.
• Implement a delete comments option for the compiler.
• Improve the return at the method Parser::isSkippable. Check switch at the parser.
• Change module's name.
• Code's refactoring:
  • Move the content of brain.cpp to a boostrap file.
  • Refactor parser.cpp.
• Make sure you are deleting objects from the heap.
• Implement $ as a print for number / 100.
  • Create tests for $ as well.
• Check if required functions (LLVM IR) are implemented.
• Breaks are not working inside if (they are going back to the beginning of the loop)
• Fix verbose mode and levels for the debug mode
• Create install script. (remember to install the libs)

Documentation

• Utils #24
• Parser #24
• Expressions #24
• AST #24

Maybe can be useful get a more descriptive and friendly the expressions of -emit-expr. The idea is put things like IncrementExpr (3) as IncrementExpression 3 times in cell x.

I setup right now all the basic necessary structure and invoked you, @luizperes , as the Team Maintainer. As you wish, you can add more people and create new teams, as new repository too.

The structure is:

(setf brain-labs ('brain
                  'brain-repl
                  'brain-docs
                  'brain-experiments
                  'brain-examples
                  'brain-training
                  'brain-labs.github.io))

You are welcome.

Happens with v1.0 and master.

debian-jessie64(robert)brain-labs$ git describe --tags
v1.0
debian-jessie64(robert)brain-labs$ clang++ --version
clang version 5.0.0 (tags/RELEASE_500/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
debian-jessie64(robert)brain-labs$
debian-jessie64(robert)brain-labs$ ~/bfi/bf.bin/bfi -c tests/helloworld.b > c.cpp
debian-jessie64(robert)brain-labs$ clang++ -O3 -o c c.cpp
debian-jessie64(robert)brain-labs$ ./c
Hello World!
debian-jessie64(robert)brain-labs$
debian-jessie64(robert)brain-labs$ gdb -args bin/brain tests/helloworld.b                                                                           GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from bin/brain...done.
(gdb) run
Starting program: /home/robert/brain-labs/bin/brain tests/helloworld.b
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000e9c55b in llvm::Value::setNameImpl(llvm::Twine const&) ()
(gdb) bt
#0  0x0000000000e9c55b in llvm::Value::setNameImpl(llvm::Twine const&) ()
#1  0x0000000000e9c9b9 in llvm::Value::setName(llvm::Twine const&) ()
#2  0x0000000000e3cfd5 in llvm::Function::BuildLazyArguments() const ()
#3  0x000000000073c2b4 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) ()
#4  0x000000000073b5a3 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) ()
#5  0x00000000004c2071 in (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) ()
#6  0x00000000008ae0b6 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) ()
#7  0x0000000000e6afd3 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#8  0x0000000000e6b1c3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#9  0x0000000000e6b5c8 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#10 0x0000000000b49b8c in llvm::MCJIT::emitObject(llvm::Module*) ()
#11 0x0000000000b49da4 in llvm::MCJIT::generateCodeForModule(llvm::Module*) ()
#12 0x0000000000b4a7c1 in llvm::MCJIT::finalizeObject() ()
#13 0x000000000042de8c in Bootstrap::init (this=0x1698170, argc=<optimized out>, argv=<optimized out>) at src/utils/Bootstrap.cpp:119
#14 0x00007ffff69ddb45 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#15 0x000000000042c6e7 in _start ()
(gdb)

Make code refactoring to follow the CppCoreGuidelines as described here

We need to rename all files and classes because they are being described wrongly.
For example:

OutputExpr, should be OutputStmt, however, ArithmeticExpr should probably be kept the same. We need to discuss it.

Any thoughts @haskellcamargo, @ryukinix, @rafaelcn ?

Implement new command ^

Benefits:
Right now, If you want to move from the 1st cell to 100th cell you will need to write something like:

1st way

++++++++++>**-{>}

2nd way

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

While the 1st way runs in O(n), the 2nd way runs in O(1), where n is the desired cell. In this way, the 2nd way of writing is way faster, however, when the desired cell increases/decreases (let's think in a big number like 1000000), we would need need to write the command > one million times!

That is why I think that we should have a command ^.
In this way, if one wanted to move the pointer from the 1st cell to the 1-million-th cell that would be as easy as:

++++++++++>+******^

That would be also O(1) for all cases :D

I'm opening this new thread because Brain needs to represent literal numbers in a better way than Brainfuck. How can we do that?

I have seen some languages doing (and @leonardohn has also suggested to use)

5+4---->3*

Although that would make us implement at least 10 more commands 0-9 and they would not be one byte commands anymore. Because of that, I'm thinking of a new way of representing numbers in a cheap way.

For example, image the number 123. How would one represent that in Brain?

+++++++++++ make number 11 on cell 0
> + make number 1 on cell 1 
* make number 11 on the next cell
* multiply cells 0 and 1 = 121
++ add 2 on cell 1

For that, I think that we should think on a new and faster way (that wouldn't create more commands). For example:

+    step 1 \ make number 1 on cell 0
>++ step 2 \ make number 2 on cell 1
>+++ step 3 \ make number 3 on cell 2
<<< step 4 \ return to cell 0
$ step 5 \ eval the number and write it on cell 4

In that way, $ would work as an eval for a number (making the literal number), in this way:

• Step 1: [1][0][0][0][0]...
• Step 2: [1][2][0][0][0]...
• Step 3: [1][2][3][0][0]...
• Step 4: [1][2][3][0][0]...
• Step 5: [1][2][3][123][0]... // evaluates until it find a '0' and replace it with the number found

What do you guys think?

Well, as I already wrote a package for Arch Linux using PKGBUILD, the good news is I found a transpiler package: https://github.com/matthewbauer/unipkg

Take a look, we can generate the .deb packages with a formal ArchLinux package. After #29 fixed I can do this.

Compiler enter in undetermined when compiling with following code (Generated code by Headache):

test.brain.zip

We should investigate and fix it :)

Check and fix:

warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]

Travis is not working properly. PR #44 was supposed to have broken, but it is not, once Travis is downloading my dev branch instead.

I would like to get some pros and cons related to the use of a pre-processor on Brain. Any suggestions?

Initially I was thinking about using the char $ for converting the current cell back and forth with float and int, that would have some implications with the LLVM IRBuilder, since we would need to implement suppport to floating numbers for each arithmetic operation, debug and so on... Although, my real concerns are related on how we would do it... I was thinking of using union for that

Implement mov instruction as described on #17:

====== From #17

To keep the pattern in Brain, we decided that instead of allowing functions, we will implement the operator @ (or the &) as:

Imagine the tape with: [2][4][100][5000][0]....

The code >>>@ would then copy the number 100 to cell number 5000

BreakExpr does not seem to be working properly for nested statements, such as an IfExpr in a LoopExpr

The Docker is in my personal DockerHub. Make Brain own DockerHub repository

The compiler should also, besides being a JIT compiler, read a brain file and generate an executable, the discussion is concerned on to whether the compiler should generate it only when requested, throught a flag, or it would generate the binary when called, like gcc and other compilers do.

Currently, each cell has the size of 32 bits. It should be custom, once Brainfuck interpreters rely on many cell sizes (you will find all kinds of them: 8, 16, 32 or 64 bits). This way we can keep the suporte do Brainfuck

Our current problems are:

• aliases on Linux seem to not be working with clang on Brain.
• Brain can be compiled with the versions of LLVM 3.5, 3.8 and 3.9 (we have not tested versions 3.6 and 3.7)
• We have way too many bash scripts. Should we reduce it?

This is really wishful.

The compiler currently does not link the output code.

• Implement functions call on Brain.
• Allow it to be compatible with LLVM IR.

A tool that accepts its configuration with a file is highly customizable and fairly easy to work, we save two things when implementing a configuration file:

• Time
• Time

The process of compilation can last longer as the project increases, so it's to keep those things in mind. Therefore a configuration file to Brain would be nice to be implemented. All the properties of Brain would be customizable from that file.

Clang is complaining that we did not initialize a variable