1 |
Hello, |
2 |
|
3 |
Last week has been a very "paradigmatic" working week. Several problems |
4 |
urged with the addition of symlinking dependency/inheritance functions. |
5 |
|
6 |
sym actions where converted to the form of: |
7 |
|
8 |
user action bin { |
9 |
description "Change Python's Version" |
10 |
type sym |
11 |
sym python { |
12 |
bin python |
13 |
target /usr/bin/python |
14 |
prefix /usr/bin/ |
15 |
regexp python([0-9]+\.[0-9]+$) |
16 |
sym python-config { |
17 |
bin python-config |
18 |
destination /usr/bin/python-config |
19 |
prefix /usr/bin/ |
20 |
regexp python([0-9]+\.[0-9]+)-config($) |
21 |
} python-config |
22 |
} python |
23 |
} bin |
24 |
|
25 |
Soon urged the need for more complex lexical analysis and started |
26 |
implementing lex rules and yacc skeleton. |
27 |
|
28 |
With this step a question bounced into my head. |
29 |
|
30 |
Am I reinventing the wheel? |
31 |
Why implement lex/yacc to translate a block of code into a python's |
32 |
block of code? |
33 |
Why not use plain python in modules? |
34 |
|
35 |
After discussing with mentor, we decided to adopt python as the base |
36 |
language for uselect modules. |
37 |
|
38 |
The final objective is something similar to this: |
39 |
|
40 |
# Start of Module |
41 |
|
42 |
# Define the module |
43 |
module = Module(description = "Python Version Switcher", version = |
44 |
"0.1", author ="mephx.x@×××××.com") |
45 |
|
46 |
# Define a Symlinking Action |
47 |
bin = Action (description = "Change Python's Version", type = "sym") |
48 |
|
49 |
#Define the SymLinks |
50 |
python = Link(bin = "python", target = "/usr/bin/python", prefix = |
51 |
"/usr/bin/", regexp = "python([0-9]+\.[0-9]+$") |
52 |
|
53 |
python-config = Link(bin = "python-config", target = |
54 |
"/usr/bin/python-config", prefix = "/usr/bin/", regexp = |
55 |
"python-config([0-9]+\.[0-9]+$") |
56 |
|
57 |
python.add_link(python-config) # For inheritance |
58 |
bin.add_link(python) # Adding The Link to the action |
59 |
module.add_action(bin) #Adding the action to the module |
60 |
|
61 |
# End of Module |
62 |
|
63 |
This may seem complex at a glance. But why learn uselect scripting |
64 |
language when you do modules without even knowing python? |
65 |
|
66 |
Keep in mind that runnable actions will still be supported and therefore |
67 |
supporting any scripting language for actions. Python will be the |
68 |
easiest one as will depend on basic class inheritance and implementation |
69 |
of functions. |
70 |
|
71 |
All this lead to the start of a new phase. Define a strong and simple |
72 |
API definition for all of uselect's capabilities creating the interfaces |
73 |
easily usable. |
74 |
|
75 |
uselect's profiles will also be in plain python, using the API of |
76 |
uselect's Python Module umodule. |
77 |
|
78 |
Last week had no commits to git due to all this. |
79 |
|
80 |
I intend to clean up all the "basic (ang buggy) lexical analysis" that |
81 |
was already implemented and re-implement the new module API during this |
82 |
week. |
83 |
|
84 |
Stay tuned on git for more updates during this week. |
85 |
|
86 |
http://git.overlays.gentoo.org/gitweb/?p=proj/uselect.git;a=summary |
87 |
|
88 |
Cheers, |
89 |
Sérgio |
90 |
|
91 |
-- |
92 |
Sérgio Almeida - mephx.x@×××××.com |
93 |
mephx @ freenode |