Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling liblcthw on Fedora: refer to forum lcthw #20

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

gbonnema
Copy link

Hi Zed,

As per your request a pull request with the code I created up until now, excluding the implementation of the heapsort. I refer to the discussion on: https://forum.learncodethehardway.com/t/has-anyone-successfully-compiled-and-used-liblcthw/548.

Forgot to mention in the commit message: I also changed the compare function that you use for suffix_array in order to make it compile.

The weird thing is, I added testcases for the heapsort, and it should fail, because the heapsort doesn't sort.

The concern in my post was the number of debug messages concerning bstring. Probably the testset from bstring.

Kind regards, Guus.

…for use.

Makefile: added _GNU_SOURCE and _XOPEN_SOURCE=700
Added header and empty definitions for heapsort and mergesort.
Added testset for heapsort.

I replaced the heapsort implementation I have because it is not finished yet.
These changes are for a pull request to check on debug messages from bstring.
I still wonder why the test for heapset passes: it should fail as it doesn't sort.
Added a way to debug the heapsort with a print function as variable in __heapsort.
Added a target-dependency to test. Otherwise change in src will not result in recompile of test.
@gbonnema
Copy link
Author

gbonnema commented Sep 30, 2017

Hey Zed,

I implemented, committed and pushed the heapsort. Also some smaller changes to Makefile in order to have the tests compiled if the src/lcthw/*.h or *.c files are changed.

I still have to start looking at the mergesort, but I suspect the algorithm is less complex, so it shouldn't take too long.

Let me know if you find any discrepancies.

EDIT: I also committed the mergesort, which was indeed simpler to implement. The code could use some love w.r.t. readability. At the moment all pointer calculations are done for each time it needs a memory location. I should probably change that to something less error prone.

Kind regards, Guus.

@zedshaw
Copy link
Owner

zedshaw commented Mar 15, 2018

Hey, this is looking good. Sorry it's taken me so long to get to it. Did you run some kind of code formatting thing on the source? And what's that .py file in the commit?

@gbonnema
Copy link
Author

Hi Zed,
Thanks for your response. It's been a while I was working on this. The plugins for vim I use are:

 Plugin 'Valloric/YouCompleteMe'
 Plugin 'Chiel92/vim-autoformat'

I do autoformatting with astyle (allman style with 1tbs = one true brace style) plus a vim plugin to execute it at every write.

The .py file is for ycm (YouCompleteMe), an addon in vim for autocompletion. I switched off autocompletion and use it for timely coding errors, like not defining a prototype when I should. It works with clang, so is largely compatible with gcc. The .py file is a project file so the ycm-addon knows with which params to compile.

I probably should not have included the ycm file in the commit. In my own project I do, cause I am too lazy to remember to copy the file for every project I checkout.

Kind regards, Guus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants