Hi all, I developed the basic structure of xapian_index() function which enables the content of a data frame to be indexed with Xapian search engine library. I pushed it to a git repository at https://github.com/amandaJayanetti/RXapian. It'd be a great favour if Mr. Dirk Eddelbuettel as well as other interested developers could kindly review the function and give me some feedback on it. Thanks in advance, Amanda -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20160530/0a1de5f2/attachment.html>
On Mon, May 30, 2016 at 10:47:45AM +0530, Amanda Jayanetti wrote:> I developed the basic structure of xapian_index() function which enables > the content of a data frame to be indexed with Xapian search engine > library. I pushed it to a git repository at > https://github.com/amandaJayanetti/RXapian. > It'd be a great favour if Mr. Dirk Eddelbuettel as well as other interested > developers could kindly review the function and give me some feedback on it.Hi, Amanda -- I don't have R installed on the computer I have with me, so I can't play with it and give any feedback on the API; hopefully Dirk and others can jump in on that. But this feels like a good start against your project plan. There are a few little things I think you can tidy up on non-R issues. 1. You don't need to commit autom4te.cache, config.log or config.status (these are all working files that are part of the autoconf system). If they're in the repository, then (a) they'll change whenever the underlying files change, and (b) people will have to download them even though they'll be regenerated locally after that. 2. You almost certainly don't want to commit configure, since configure.ac is committed. (I assume that a simple run of autoconf will regenerate configure? It looks like it will.) 3. You still have the Read-and-delete-me file in the repo, which I assume was created automatically by Rcpp or similar. If you think that preserving any parts of that are helpful to end users, or to yourself while developing the extension, I'd add them to README.md. 4. Rather than keeping lots of 'Delete <file>' commits, it's possible to 'squash' multiple commits together. I think it'd be worth doing this for most of the commits you currently have, so there's an initial commit and then the later 'real' changes (830d3c2 onwards). You can do this using git rebase -i; if you haven't used it before then there are tutorials online, but if you get stuck then drop me an email with some times you can be online and I'll walk you through it. (It can be confusing the first time; git isn't always the most friendly of tools!) 5. Those later changes should have meaningful commit messages. 'Update <filename>' is just restating something that should be clear from the commit itself. I wrote something about commit messages in the developer guide (https://xapian-developer-guide.readthedocs.io/en/latest/contributing/workflow.html#good-commit-messages), which has a further link out to an article I've found helpful on this. 6. In README.md, you can mark code by surrounding it by backticks (`...`). With github-flavoured markdown (which is what github will render README.md as) you can also put 'code fences' around it, lines that just contain three backticks (```). (GFMD understands R, so you can use ```R as the opening fence, and it'll syntax highlight too.) 7. In configure.ac, you should default to xapian-config, not xapian-config-1.3; anyone who's using a development version can point XAPIAN_CONFIG to the relevant binary. It isn't a huge issue right now (since you're not targetting Xapian 1.2), but 1.4 should be out during the course of GSoC, and we'll want RXapian to support that without people having to do anything special. Going forward, github provides some helpful tools for discussing changes if you work on a branch and then create a pull request (back to your own repo for the time being). The discussion tools don't really work as well unless you're using pull requests, unfortunately, but it should be an easy habit to get into (and is how a lot of open source projects work). J -- James Aylett, occasional trouble-maker xapian.org
Thanks a lot for the feedback James!>> There are a few little things I think you can tidy up on non-R issues.Although I created the github account several years ago, haven't really used it much. Will read about it and make the changes you pointed out.>> if you get stuck then drop me an email with some times you can be online > and I'll walk you through itWill do. Thanks :)> >> In configure.ac, you should default to xapian-config, not > xapian-config-1.3; anyone who's using a development version can point > XAPIAN_CONFIG to the relevant binaryWill change it. I haven't made the package compatible with Windows yet. I'm planning to work on these things during the last few weeks.>> github provides some helpful tools for discussing>>changes if you work on a branch and then create a pull requestI'll read about these. Best regards, Amanda -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20160530/70967526/attachment.html>
Hi James,
>> Rather than keeping lots of 'Delete <file>' commits,
it's possible> >> to 'squash' multiple commits together. I think
it'd be worth doing
> >> this for most of the commits you currently have, so
there's an
> initial
> >> commit and then the later 'real' changes (830d3c2
onwards). You can
> do
> >> this using git rebase -i; if you haven't used it before
then there
> are
> >> tutorials online, but if you get stuck then drop me an email
with
> some
> >> times you can be online and I'll walk you through it. (It
can be
> >> confusing the first time; git isn't always the most
friendly of
> tools!)
>
Using git rebase-i only the commits that were pushed via a local repository
can be squashed. Could you kindly tell me if there's a way to squash
commits that were made directly via the git hub web interface?
Best regards,
Amanda
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xapian.org/pipermail/xapian-devel/attachments/20160605/bae9dda4/attachment.html>
On Sun, Jun 05, 2016 at 04:09:34PM +0530, Amanda Jayanetti wrote:> Using git rebase-i only the commits that were pushed via a local repository > can be squashed. Could you kindly tell me if there's a way to squash > commits that were made directly via the git hub web interface?The best way of thinking of this is that changes via the github web interface are like changes someone else made to the remote repository, and which you want to incorporate into your local branch (which is what you operate on using `git rebase -i`). I've written an article to try to explain remotes, branches and how to incorporate changes from remotes into a local branch: https://tartarus.org/james/diary/2016/06/05/git-remotes You can ignore the stuff about `git merge`, which you don't want to use here. Hopefully this will make it more clear what's going on! J -- James Aylett, occasional trouble-maker xapian.org
On Mon, May 30, 2016 at 04:35:15PM +0100, James Aylett wrote:> 7. In configure.ac, you should default to xapian-config, not > xapian-config-1.3; anyone who's using a development version can point > XAPIAN_CONFIG to the relevant binary. It isn't a huge issue right now > (since you're not targetting Xapian 1.2), but 1.4 should be out during > the course of GSoC, and we'll want RXapian to support that without > people having to do anything special.It would be better to use the XO_LIB_XAPIAN macro provided by xapian-core instead of writing your own code to probe for xapian-config. Everything from line 3 to line 18 of your current configure.ac could be replaced with just: XO_LIB_XAPIAN If you've installed xapian-core then the macro should just be found automatically. If you want to build against an uninstalled xapian-core, you need to pass -I options to aclocal so it can find the macro (the top level `bootstrap` does this automatically - at some point we should probably sort out support for RXapian in there). Cheers, Olly