Tuesday, December 21, 2010
Tuesday, November 23, 2010
I communicated with my group mates and completed the initial version of the SRS on 26th October. As requested from the course coordinator I uploaded that version to the Moodle on 29th October. After the project meeting with course coordinator, we thought of altering our SRS a bit, and agreed to again look into parts did in the SRS by each one of us and come up with an improved version by 1st of November. As discussed I made few small changes to the parts I had done in the SRS, and send them to Chamilka, for formatting tasks on 31st of October.
Meantime I had few chats going on with the OpenCog developers community, mainly with Dr. Joel Pitt, Jerad, and Linas, at the #opencog IRC channel, for better understanding of our requirements. Since our project idea came from Dr. Ben Goertzel, I thought to have a chat with him to get clarify few problems. I had a google chat with him on 1st of November and the points discussed were following.
Why the existing RelEx2Frame code is kind of hacky?
What if the introduction of a standard rule engine degrades the performance?
Is there a corpus that can be used for testing purposes?
For final presentation purposes is it possible to use the virtual dogs developed by OpenCog?
That discussion was really worth, and I shared the chat log in our mailing list.
I did a bit research on the generated drools rules after converting hand written rules using the Rule Converter developed by Danaja and Nisansa. To get clarified few things which I came across from those converted rules, I contacted the Drools community through their mailing list on 31st of October. There I had a discussion with a Drools developer called Wolfgang Laun and figured out few important facts that we should condider.
In Drools rule eval() function is the least efficient way of formulating a condition; none of the optimizations will work this way.
eval() cannot be used on the RHS, after 'then'. It is a wrapper for general
boolean expressions, to be used as a constraint in a Pattern.
I shared these with my group mates and did necessary modifications.
In this period I had taken up another task which is to integrate RelEx with Drools, using minimum number of dependencies needed to get Drools to work. I integrated a test class given by Drools into the successfully configured RelEx Eclipse Project Folder, and built it and find out the missing libraries (JAR files) and added them to the Java Build Path of the RelEx project. Following were the minimum JAR files needed from the Drools 'bin' folder for a successful build.
Sunday, October 31, 2010
Tuesday, October 12, 2010
- Download link-grammar http://www.abisource.com/projects/link-grammar/#download
- Extract link-grammar
- Issue following commands in a terminal invoked in the place where you have link-grammar extracted. (eg: /media/OS/OtherNirmal/L4-S1/Project/link-grammar-4.7.0)
- Install libgetopt-java package:sudo apt-get install libgetopt-java
- Install Wordnet:sudo apt-get install wordnet
- Download JWNL from http://sourceforge.net/projects/jwordnet/files/jwnl/JWNL%201.4/jwnl14-rc2.zip/download and Extract it .Go to the folder where jwnl.jar contains (in jwnl 1.4 it's inside extractedPlace/jwnl14-rc2) and issue following command to copy the jar into /usr/share/javasudo cp jwnl.jar /usr/share/java
- Go to http://wiki.bazaar.canonical.com/Download and download our VCS bazzar or simply open up a terminal and type
- Go to the folder where you need the RelEx trunk to be in and issue following:
- In relex source code there's a build.xml file. Open it up and change the following:
- Finally go to the folder which contains build.xml (relex) & issue:
Saturday, October 2, 2010
Saturday, September 25, 2010
Sunday, August 22, 2010
අගෝස්තු 20 වෙනිදා "ගූගල් සමර් ඔෆ් කෝඩ් -2010" වැඩ නිල වශයෙන් අවසන් කලා :),එ අවසන් ප්රතිඵල නිකුත් වීමත් සමගයි. ගූගල් නිල වශයෙන් ප්රතිඵල 23 වෙනිදා දැනුම් දීමට නියමිතයි. මගේ ප්රජෙක්ට් එක වූනේ Apache Derby වලට අලුත් ටූල් එකක් හදන්නයි. Derby කියන්නේ සරලව කිව්වොත් දත්ත ගබඩා කරන්න සහ අවශ්ය දත්ත ලබාගන්න උදව්වෙන FOSS software එකක්, ඉන්ග්රිසියෙන් කිව්වොත් Relational Database Management System (RDBMS) එකක්.
මගේ ටූල් එක ගැන කිව්වොත් එය Derby යූසර්ස්ලට තමා execute කරපු query එකක් execute වෙන අවස්ථාවෙදී Derby අනුගමනය කරපු පියවරවල් tree අකෘතියක් ලෙස බලා ගන්න හැකියාව සලසනවා. Tree අකෘතියේ තියෙන හැම node එකක් ගැනම තෝරා ගත් විස්තර සමූහයක් අන්තර්ගතයි. මෙමගින් Derby යූසර්ස්ලට තමා execute කරපු query එකේ performance බලාගන්න පුලුවන් වීම නිසා, performance අඩුයි වගේ පෙනෙනවානම් එ query එක වෙන විදියකට ලියන්න උනන්දු කරවනවා. මෙම අලුත් ටූල් එක Derby මීළග release එකට එ කියන්නේ 10.7 වලට අන්තර්ගත කරන්න ඉන්නෙ. ටූල් එකේ එක interface එකක් මෙතනින් බලන්න පූලූවන්.
මගේ ප්රජෙක්ට් මෙන්ට වුනේ Bryan Pendleton. Bryan ගෙ උදවූ මට ගොඩාක් උපකාරී වුනා ප්රජෙක්ට් එක වෙලාවටත් ඉස්සෙල්ලා ඉවර කරන්න, මට කියන්න බරිවුනානේ ප්රජෙක්ට් එක මම වෙලාවටත් ඉස්සෙල්ලා ඉවර කලා (අගෝස්තු 4) (මෙන්ට බලාපොරොත්තු වුන විදියට), ඊට පස්සෙ community එකෙන් පොඩි පොඩි අදහස් මතු වුනා. එ අදහස් වලට ගරැ කරමින් මට අගෝස්තු 16 ට ඉස්සෙල්ලා කල හැකි දේවල් මම කලා, community එක එකග වුනා අනිත් අදහස් ඉදිරියේදී කරන්න, තව සාකච්චා වලින් පස්සෙ. මෙහෙම තමා FOSS ප්රජෙක්ට් එකක් ඉදිරියටම යන්නේ.:)
Community එකේ හැමෝම මට ගොඩාක් උදවු කලා Derby එක්ක familiar වෙන්න. හැමෝටම ගොඩාක් Thanks! ගොඩාක් අය මට සුබ පැතුවා, එ අයටත් Thanks! මේ මගේ පළමු සිංහල බ්ලොග් පෝස්ට් එකයි.:)ස්තූතියි!
Saturday, August 7, 2010
I was not familiar with any of scripting languages before start up of the project. The most challenging task was to find a scripting language which can be used to automate a Windows GUI. After searching in the Internet I found a scripting language called AutoIt (AutoIt), which is capable of automating Windows GUIs, and also very easy to learn type of language. After went through some tutorials on AutoIt, I started writing small scripts, which are basically will automate a simple installation process. Next I got familiar with the tool that is currently used at IFS. After designing a process view I implemented the needed functionality.
Thursday, August 5, 2010
You can visit this page to see the prototype.
This tool provides a high level view of the execution plans of complex queries you have executed. You can see the steps followed by the "Query Optimizer" of Derby, in order to execute the particular query. In this case Optimizer had followed a query plan with four "plan nodes", namely PROJECTION, HASH JOIN, TABLE SCAN and HASH SCAN. Intermediate results flow from the bottom of the tree to the top. In this case the filtered results of TABLE SCAN and HASH SCAN was given as the input for HASH JOIN. After performing the HASH JOIN the filtered result set given as a input to the PROJECTION node.
You can move the mouse point over an any node of the query plan to view set of available details about the execution at that step.
It is just the output that shown there. To convert to this output I had done lot of coding :).
Thanks for reading!