Coding things

## Category: Open Source

### How (Not) to Treat a Bug Report

This post is about a bug report I have sent to Facebook in November last year and how it was treated. Please, do not add this post to the list of FB-hate posts (product-wise) – I don’t want that. Instead, this is only a complain against the developers which work there and how they treat their IT-enabled customers.

I wanted to search something on my Wall. Something which was posted several months ago. I knew what to search but scrolling down didn’t reveal it. I asked for a simple search facility.

I have submitted the bug on 12th of November 2011. No response was given until 14th of November. Then, two responses came within an interval of 12 minutes. The first one simple closed the bug as being invalid because it was submitted using a wrong bug reporting platform (though it was the only one available via links Facebook offers to a normal user). The second one simply reopened and assigned the bug to a developer.

That was all that happened with this bug until recently. People subscribed to it, comments were added by coders at Facebook did other things, interesting or not. And now they killed the bug report using the same first reply message. This time, I have used all the links in the message to send the feature request. Maybe this time they’ll solve it though I highly doubt this since no link from these offered a public view of the bug report.

Facebook changed since November last year. Maybe that search doesn’t seem so important now. Indeed, since the feature request was added they have implemented Timeline which was supposed to make searches on your Wall more efficient. Too bad this doesn’t work too well. Thus, that search is still needed. See also the comments on the bug request to see that page admins need it too. Facebook, however, decided to ignore this problem.

This makes me think that there are two options: either they don’t care about their (human) users and everything is about add revenue or their codebase makes it impossible to retrieve something posted a while ago on a timeline or a page: that data is only mined for relevant companies in order to display better adds.

In case they decide to delete the feature request, I have created three screen captures with the relevant details of the report. You can see them in full detail by clicking on them.

I have submitted bug reports to other projects as well. But in no places were they treated like this. You may take this post as an arrogant response from an offended programmer with a great ego but this is not so. I only wanted to shine a light on how a bug report is treated at Facebook.

### Mazes (1)

As mentioned previously, I had an assignment which involved constructing a maze from code and letting a robot escape from it. This series won’t follow the second part, it will concentrate on maze specific topics. I will write about maze generation, maze drawing, maze counting and several other aspects. Maybe I’ll touch several properties of the mazes, possibly I’ll write about something like the moments in statistics. Will see where this series will end and what areas will be covered by it.

### GTK Custom Drawing and Saving

In one of the previous mentioned homework, I had to draw an image of a neural network on a custom widget and later save said image to file. This post was inspired by this task.

### A semester of coding

The last semester was a very busy one at my faculty. This is the main reason why I failed to update this blog. However, now that I have free time again, I’ll present some of the coding assignments that I’ve done during the last semester.

### Compiling GHC from sources

I’ve decided that the best way to learn about the internals of GHC is to actually look at it’s source code in parallel with some experiments. This is the first part of a series of articles related to some GHC experiments, maybe going towards a `ghcd` command. But, until then, we have much work to do.

### Visual Haskell Debugger (part 2)

The idea from the previous article received a lot of feedback both in the form of comments to the article or on reddit or on Haskell-Cafe (though, not on a dedicated topic).

For another proof of the idea, I will draw some diagrams by hand for the following suggested pieces of code. As you will see in this article, the drawing will evolve as I will tackle with more complex examples (and there are still pieces of code that I cannot render right now).

Since a few days ago a little idea is bugging me: what if debugging Haskell programs would be reduced to a graphical interface and some clicks here and there to spot the problem?

What I have in mind is a new debugger very much GUI oriented. It will parse the code and interpret it and then it will offer a picture to the user in the GUI program.

For now, I will consider only the case of functions with no side effects. Suppose our user has, at some moment in the debugging phase, observed that one particular function gives wrong results. The only method of debugging that I know as of now is to use Debug.Trace and the trace function. However, this method involves changes to the code, none of which will really solve the bug. Cannot we do better?

I think that we can. Suppose that the code debugged is the following (simple demonstrative example) and that the user is debugging f.

```f :: Int -> Int -> Int f x y  = y + g x   g :: Int -> Int g = (-1) ```

and the user observes that it gives output 7 instead of 8 when applied to 3 and 5. How the users reaches these values is beyond the scope of this article. He might have used quickcheck or he might have manually tested the code, it doesn’t matter. What does matter is what the proposed tool will show to the user:

Yes, a simple image describing only the inputs and the outputs of the function. What cannot be seen from the figure is that, although what he sees is a very abstract representation of his function, by clicking on the f name the tool will display the internals of the function, for the case taken.

The meaning of the rounded decorator around the + function is that that function’s implementation was not written by the user and it shouldn’t be debugged. However, the g function can be debugged and, by clicking on it, the GUI will open a new image, as if the user was really debugging function g right now.

Because this function doesn’t involve other user defined functions, the GUI will redirect any click on the function name to the actual implementation. The user would then be able to see what went wrong and correct the function (g was supposed to be id).

This was a simple example and the bug could be seen with naked eyes. However, this is not always the case and I think that this tool can help in debugging.

To be more helpful, I intend to extend this tool such that it can run a quickcheck test suite over one function using the informations that the user provide via the GUI. I intend to make the program to be capable of displaying informations at the type level and, maybe, allow the user to drag the boxes representing the functions and try to match them like some jigsaw puzzle. If there would be a missing link, the project might search on hoogle or hayoo for any function that matches that signature and offer a suggestion to the user.

I still have to think what should be done for functions returning other functions. I will not give up on handling curried functions but I haven’t decided yet how this would be represented graphically

Finally, maybe this tool can be also integrated with hlint, providing a visual feedback on common warnings issued by this tool (for example, runing hlint over one piece of my code showed 4 similar warnings concerning it)

Now, I don’t usually speak about my ideas in front of the public (or even remotely like blogging about it). I did this right now because this would be my first Haskell based project which could affect the community if all things are going well. But, before starting it, I want to see some feedback of whether this is needed, whether this is doable in one summer and whether this hasn’t been done before (I did a short search but found only tools remotely related to this project – either not debugging or not graphically displaying the code).

Thus, I finish this article by inviting every reader to give a feedback related to this project in the next few days. Depending on your feedback I may start working on a useful project or realise that my idea is not really such a brilliant one.

### Writing a Compiler for Verilog – part 2

As previously stated, I am working on a Verilog Compiler in Python using PLY. The last article talked in a generic way about the project, from now on we will talk about specific parts of the compiler.

Today, we begain with the first part of any compiler: the lexing part.

### Writing a Compiler for Verilog – part 1

This year, I took a class named Numerical Computers II (I had Numerical Computers I last year). The course was about Computer Architecture and things like this. However, I ended up with a very fascinating homework: to write a compiler for Verilog in a team of 2 to 4 people. The deadline is coming soon (I have to finish it by Friday) but I need a break so I’ll post here my story.

### A Puzzle and a Solution (2)

Last post was ended with a problem: our solution exhausted the memory before it could give an answer to $N=1000$, $P=42$. There were three comments trying to solve them and the last two of them are working. However, the solution involving the lcm of cycles is faster and I will post it here (the other one is posted as a comment there).