forked from pyre/pyre
-
Notifications
You must be signed in to change notification settings - Fork 2
/
TODO
197 lines (124 loc) · 6.93 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
# -*- coding: utf-8 -*-
#
# michael a.g. aïvázis
# orthologue
# (c) 1998-2020 all rights reserved
#
- calc:
- calc nodes cannot inherit from {Ordering} because {Observable} stores the callbacks in a
weak key dictionary, which is incompatible with an overloaded __eq__
- framework:
- take advantage of the new class creation protocol in 3.6+
- have component+trait+schema paritcipate in value resolution, not just schema
- pyre.patterns.Named has to become a little more sophisticated with its name handling:
- passing name=<foo> to the constructor must have an indentical net effect as leaving it
blank at construction time and setting it later
- look for a better way to install escape handlers for the command line parser; does the
actual parsing happen too early? how would i then bootstrap the framework without having to
check its state every time something significant happens?
- package names can be placed in their own namespace by auto prepending a special character
to their name. which character? what is the current status?
- what is the full set of options for allowing configuration changes past the initialization
phase?
- deal with this on a component by component basis?
- flag the capability?
- trap the events and redistribute?
- is this a component attribute? or a trait decoration?
- configuration errors:
- trap, collect, show on exit
- is it part of {help}?
- temporary invalid assignments that get later overriden by valid ones are not fatal
errors; they could get reported by {help}
- is the last valid assignment the one that wins? is it fatal if the last assignment
violates a constraint or do I fall back? how does the user control this behavior?
- traits:
- treat them like components; some are: input and output streams have both configuration and
initialization phases; the latter grabs the system resource and should be done after it's
reasonably certain that the user has made up her mind about the name of the file. the goal
is to not leave behind zero length output files that were created when some assignment was
made that was later overriden by something else
- same considerations apply to components themselves; formalize the sequence of
startup/shutdown steps
- filesystem:
- the factories in __init__ are kind of ugly. fix
- sync should not be done by default, especially now that it supports the number of levels to
expand; this should speed up {import pyre} in directories with deep structures. this means
that i need to hunt down all uses of filesystems and make sure the clients sync before they
look things up. also, folders need to know how to cause their filesystems to fillout their
contents, which means adding a {sync} method that dispatches to the filesystem with
root=self
- implement http
- transport mechanisms: wget/curl, ftp, scp, rsync, ...
- can i build one dynamically? create a folder and start adding files?
- how do i know that a filesystem node is a "future" one?
- history tracking:
- must trace all the paths that assign values to slots and make sure that locator/priority
are saved in _history
- install a tracker as a command line event handler; make it save the names of the traits to
track; make it print out a report of the history of tracked traits at shutdown
- should this be part of {help}? see below
- journal:
- weaver:
- i want my own rst, and my own sphinx...
- help: make
- component Inspector
- how does python help work? who/how generates the formatted output?
- inspect:
properties, facilities: doc, tip, current value, default value, history?
interface: doc, arg list, annotations, return value
- make sure inline documentation is always sufficient for Inspector to work
- use in opal and fold into the UI for Forms
- db:
- db Query and View as Components
? not sure what i meant with this. records, sheets and views are now closer to this
- opal: make
- Form as Component
- merlin:
- while i am dreaming: i want my own coverage tool...
- tabular:
- give records some of the aggregator capabilities that tables have so that streams of data
with no associated storage can be binned; of course, no storage implies that the charts
must immediately update some reduction, since no ranks or references to the data should be
retained. what effect should this have on the design/implementation of Sheet, Chart and
Pivot?
- sheet inheritance is "broken" because derived classes rearrange the order of measures and
derivations. this means that instances of a class are not compatible with instances of its
direct ancestor, even in single inheritance
- resolve the uri argument to cvs.read through the pyre fileserver
- indexed columns must support iteration over their contents, like non-indexed ones. should
they iterate in record order? or is any order ok?
- take advantage of change notifications: should a record know that one of its values
changed? should a sheet know that one of its values changed
- allow the creation of records over multiple sessions
- allow the deletion of records; rethink this from a {calc} viewpoint: what does it mean for
a {calc} node to disappear? aggregators can drop it from their domain; others may raise
UnresolvedNode, or some such...
- views
- pivots
- {chart}: related to {SELECT} and {GROUP BY} from SQL: given a table, a chart can
aswer quickly questions like "produce the set of records that have <measure>=<value>", or
even "<measure> in the neighborhood of <value>" by controlling the binning strategy
- implement using {chart}, i.e. the binning strategy that specifies the dimensions, and
a {cell}, i.e. the description of what operation to perform on the data slice that
corresponds to each fully qualified coordinate vector
- CHANGE notification: rebin a record when the matching value changed, just like an
aggregation gets recomputed when one of the factors changes
- function overload: revisit
- use function annotations instead of explicit signatures in the decorator
- can the full set of funcdecls be supported?
- positional args, positionals with defaults, keyword only, keyword only with defaults
- what to register
- what to cache
- who shadows whom? what's ambiguous?
- how to retrieve a matching signature quickly
- is it worth the hassle and performance penalty?
- overload on precondition a la Ebby?
- shells:
- let "pyre" be the hosting script:
- hosting options are command line options to this script
- the application is specified as the directory appname.pyre
- pyre looks inside for geometry and dynamics
- can the reconfiguration of a component get triggered after the application has started? the
use case here is manipulating the journal channels for long-running apps: can i turn on
channels after launch?
# end of file