Difference between revisions of "User:Ggregori"
Jump to navigation
Jump to search
Line 35: | Line 35: | ||
**Create some additional classes in order to add some flexibility (e.g. parent class parser with the common code). |
**Create some additional classes in order to add some flexibility (e.g. parent class parser with the common code). |
||
(09/05 - 15/05): This week I had to redo some work because of the Python3 switch, so didn't accomplish want I wanted. Anyway, two weeks of university classes remaining until I can focus exclusively in this project. |
|||
*Switched to Python 3, reasons: |
|||
**I hope to get better UTF-8 support among other things. |
|||
**Had to test if the modules I use were fully available/compatible in Python3. |
|||
**Had to read and research (again...) about str/bytes and std{in,out}.buffer and, in general, everything related to Unicode, UTF-8... |
|||
*Started implementing the really basics of the compiler’s architecture: |
|||
**Command-line arguments and help, input and output, logging... |
|||
*Another think I realized this week is that a lot of the thinking done last week about trying to make a flexible prototype so it is easy to modify in the future doesn’t really apply to Python. For example, my design involved creating interfaces/abstract classes in order to be able to easily change components, but that in Python isn’t needed. In conclusion: duck-typing, although I will need my design in the C++ version. |
|||
[[Category:Users]] |
[[Category:Users]] |
Revision as of 19:46, 16 May 2011
About me
Name: Gabriel Gregori Manzano
Email/Google chat: Email me
IRC nick: ggregori
GSoC 2011
VM for the transfer module - Application
Github repository: pending...
TODO list
- Research and experiment with the topics mentioned by my mentor:
- implementation of UNIX wildcards.
- Start the work refining last year's architecture (e.g. choosing the modules for logging...).
- Define and implement some small tests for the compiler.
Weekly reports
(25/04 - 01/05): Basically this week has been dedicated to research/review some topics (some of them suggested by my mentor)
- I have been reviewing NLP and Python using 'Natural Language Processing with Python' book.
- I have been looking for a way to represent morphological labels in UCS/UTF and my mentor suggested using negative numbers as in Apertium internals. Anyway, I can worry about this later.
- Using UTF with Python: 'codecs' and 'unicodedata' can be some useful modules.
- Testing the option 'lt-proc' -b which is going to be the input of my compiler.
(02/05 - 08/05): This week I ended all the review/research needed, although I couldn't do all I wanted because I had to travel.
- Ended with the introductory book reviewing NLP and Python.
- Started designing and redefining the compiler's architecture following last year work and selected and did some tests with some modules. Some of the changes or improvements:
- Use of pipes/command-line arguments for the input of the compiler (like the rest of Apertium).
- Configurable logging module for info and debugging purposes (module: logging).
- Refactoring some methods in the expatparser class (e.g. extracting common code of the callback method).
- Create some additional classes in order to add some flexibility (e.g. parent class parser with the common code).
(09/05 - 15/05): This week I had to redo some work because of the Python3 switch, so didn't accomplish want I wanted. Anyway, two weeks of university classes remaining until I can focus exclusively in this project.
- Switched to Python 3, reasons:
- I hope to get better UTF-8 support among other things.
- Had to test if the modules I use were fully available/compatible in Python3.
- Had to read and research (again...) about str/bytes and std{in,out}.buffer and, in general, everything related to Unicode, UTF-8...
- Started implementing the really basics of the compiler’s architecture:
- Command-line arguments and help, input and output, logging...
- Another think I realized this week is that a lot of the thinking done last week about trying to make a flexible prototype so it is easy to modify in the future doesn’t really apply to Python. For example, my design involved creating interfaces/abstract classes in order to be able to easily change components, but that in Python isn’t needed. In conclusion: duck-typing, although I will need my design in the C++ version.