ANNOUNCE Poet version 2.1.0
Phil Mercurio
the assimilation of Ttk widgets. Poet has now been compiled
for the Mac (OS X, Tcl 8.5 only) and Poet.kit is now a
combined Windows/Mac/Linux kit. Numerous bug fixes, including
one in the C code, so even 8.4 users should upgrade.
The poet.sourceforge.net website now includes two screen-capture
videos, one presenting Poet and one presenting Poetics.
Poet (Prototype Object Extension for Tcl) is an object-oriented
extension to Tcl/Tk that features prototype-based inheritance,
constraints, and persistence. It includes Poetics (Poet Integrated
Construction Set), a set of tools allowing the end-user to inspect and
modify a running Poet application.
--
Phil Mercurio
merc...@thyrd.org
stevel
> This release has been updated for Tcl/Tk 8.5.0, including
> the assimilation of Ttk widgets.
Nice work Phil.
Did you get a chance to look at sitting Poet on TclOO? It'd be a good
time to get any feedback to Donal.
Steve
Ron Fox
Phil gave a very nice presentation on Poet and Poetics. The
sort of presentation that should make everyone want to attend
Tcl 2008 this Sept. in Philly.
Ron.
Phil Mercurio
that would be a major project. Of course, one of the
great things about Tcl is having multiple OO choices
that can be used simultaneously. Poet has always
been intended for the top-level objects, the ones
closest to the user. It might make sense to use
TclOO for the stuff underneath, for speed.
Probably the most significant part of Poet I'd like
to see available via TclOO is the constraint network.
This is implemented in C, so it should probably be
written in C for TclOO. It's an implementation of
Brad Vander Zanden's algorithm for one-way constraints,
but I could see scrapping that in favor of a full-blown
multi-way constraint solver (though there's a lot you
can do with one-way constraints, ask any spreadsheet
programmer). Constraints can be a good way to exploit
parallelism, especially for the application programmer,
who might be able to avoid dealing with multiprocessing
at all and just think in terms of constraints.
Imagine Tcl rising up as the preeminent scripting
language for the multicore world we now live in,
with a parallel constraint solver for when you
want parallel speed-ups to just happen, and TclThreads
for when you need to get your hands dirty.
Phil
Donal K. Fellows
> Probably the most significant part of Poet I'd like
> to see available via TclOO is the constraint network.
One of the design goals of TclOO is that it should be possible to
build other extensions (in C) on top of it. Another is that it should
be kept small and focus on being a good solid fast OO core without any
of the complexity of an advanced class library. In short, if you want
me to add new features, you have to argue *very* fast and well, since
I'll likely ask "why can't you just plug in on top?" :-)
Donal.
Phil Mercurio
to the traces available on Tcl variables, then implementing
Poet's constraint network on top should be pretty straightforward.
So, if traces aren't already supported, please consider it.
The other thing that's needed is a way to supplant the
instance variable read code (essentially, a way to set a
read trace on all variables on all objects) so that when an
instance variable is read from inside a formula the appropriate
node in the constraint network can be constructed.
Gimme all that and I won't bug you, at least for a while. :-)
Phil
Andreas Kupries
> read trace on all variables on all objects) so that when an
> instance variable is read from inside a formula the appropriate
> node in the constraint network can be constructed.
Ok, that semi-answers a question I had about how the constraints
work. Namely, how does the system determine the inverted dependencies,
given that the slot references can be inside of arbitrary Tcl code. I
am now guessing what happens is that
(a) A formula is run the first it is defined, to set the initial state
for the slot.
(b) During this execution the system has set up some internals so that
any slot read during the execution of the formula is made a
predecessor of the formula.
(c) Whenever a predecessor changes the formula is rerun, the internals
are set up again to capture slot reads, and all new slots accessed
during the run are added to the list of predecessors.
That way the web of dependencies is determined/constructed dynamically
and incrementally at runtime, based on the code paths actually
executed by all the defined formulas.
> written in C for TclOO. It's an implementation of Brad Vander
> Zanden's algorithm for one-way constraints,
Do you have links to online papers, articles, tutorials,
etc. pp. about this algorithm ?
Given the reference to spreadsheets, have you tried to create one
based on this constraint system, with one Poet object per cell ?
--
So long,
Andreas Kupries <akup...@shaw.ca>
<http://www.purl.org/NET/akupries/>
Developer @ <http://www.activestate.com/>
-------------------------------------------------------------------------------
Donal K. Fellows
> If you've got traces on TclOO object instance variables similar
> to the traces available on Tcl variables, then implementing
> Poet's constraint network on top should be pretty straightforward.
> So, if traces aren't already supported, please consider it.
Right now, each object has its own namespace. Your instance variables
are just normal namespace variables. Is that good enough? :-)
(OK, I admit that this was because I couldn't decide how to do a fancier
state model on top of that. Instead I thought it best to give people
familiar tools.)
> The other thing that's needed is a way to supplant the
> instance variable read code (essentially, a way to set a
> read trace on all variables on all objects) so that when an
> instance variable is read from inside a formula the appropriate
> node in the constraint network can be constructed.
Hmm, theoretically you've not got that. However, since you'll be
defining all the variable access methods (it's only a few minutes of Tcl
scripting) you'll be able to watch everything that's going on no
problem. You'll probably want to make a superclass of all poet objects
though. That's fairly easy to do. (You can get advanced and do this by
defining a metaclass to make this easier, but you can get a long way
without going to that level of fanciness.)
> Gimme all that and I won't bug you, at least for a while. :-)
Is there enough there for you? :-D
Donal.
Kevin Walzer
> This release has been updated for Tcl/Tk 8.5.0, including
> the assimilation of Ttk widgets. Poet has now been compiled
>
>
When I clicked the "Mac OS" link at the SF download site, all I got was
the source tarball. I didn't see any binary for Mac OS X. Am I missing
something?
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Phil Mercurio
the method that accesses slots ("slot") checks to see if
we're inside a formula and, if so, considers creating a
source node in the constraint network. Changing that
slot later causes the corresponding destination node(s)
to be marked as dirty, and an event to be queued to clean it
up by re-running the formula. There's also a mechanism to
temporarily suspend node checking inside a formula (Poet sideEffect
<script>), so you can access slots that you do not want
dependencies attached to. And there's tricky stuff in
there so that formulas can be paused and resumed (i.e.,
a formula can return indicating that it's not done yet,
the destination node is still dirty) so that other events
can get processed.
I have to do this check on every slot access, but it's
inside the C code, so hopefully it doesn't slow things down
too much.
Brad Vander Zanden has a lot of publications on constraints,
especially on constraints in UIs (Poet, in a lot of ways, is
an attempt to implement in Tcl what Brad Myers et al did
with Garnet and Amulet, in Lisp). I think this paper
http://citeseer.ist.psu.edu/zanden94integrating.html
has a good presentation of the algorithm.
The visual programming language I'm working on, Thyrd,
uses the spreadsheet model and relies heavily on Poet's
constraints. I thought about creating a really simple
spreadsheet as a Poet programming example, but decided
it wouldn't be short enough to really be a good example.
Instead I wrote the scale with reset button example
that's in the paper, which demos UI constraints in just
a few lines.
Phil
Phil Mercurio
to implement the constraint network in TclOO. Though
what would be even cooler would be support in the core
for constraints among any Tcl variables, essentially
making formulas first-class features of Tcl, like procs.
Because constraints don't necessarily have anything to do
with objects, it's just that implementing an OOP extension
is a good opportunity to slip in constraint support. Occasionally
when I'm coding in Poet I have to manually associate
some external variable with a slot on a Poet object just
so it can participate in the constraint network, and I
wish I could just constrain any variable.
Hey, I can dream, can't I?
Phil
Donal K. Fellows
> Thanks, Donal, I think that is everything I would need
> to implement the constraint network in TclOO. Though
> what would be even cooler would be support in the core
> for constraints among any Tcl variables, essentially
> making formulas first-class features of Tcl, like procs.
That's not a TclOO change; it's entirely outside the scope of what TclOO
tries to do.
> Because constraints don't necessarily have anything to do
> with objects, it's just that implementing an OOP extension
> is a good opportunity to slip in constraint support.
Umm, I'm fairly strict about scope creep. Not that constraints aren't
cool; did you know that the core of the [grid] geometry manager is a
constraint solver? But it would be interesting to understand what is
making handling constraints within Tcl tricky at the moment. In
particular, is Tcl currently powerful enough that it can be done nicely
with just an extension, or are patches needed as well?
Donal.
Phil Mercurio
variable accesses within a formula so source nodes
in the constraint network can be constructed. One
way to do this is to require that variables in a
formula be accessed via a proc, rather than $ or set,
and put the trap in the proc. This is essentially
how it's done in Garnet, which was the inspiration
for Poet. But to allow formulas to look like normal
Tcl code would probably require a patch to the core,
unless there's some tricky way to trap all variable
accesses.
Phil
Donal K. Fellows
> I think the major problem would be in trapping all
> variable accesses within a formula so source nodes
> in the constraint network can be constructed.
> But to allow formulas to look like normal
> Tcl code would probably require a patch to the core,
> unless there's some tricky way to trap all variable
> accesses.
Well, we're considering putting something in 8.6 that'll let people
parse expressions and scripts to pick out things like that. If you'll
remember Kevin Kenny's talks from the 2007 Conference about solving
partial differential equations with Tcl, he was using an adaptation of
some code that's been around for a while that does that sort of
parsing. Making that parser (or something like that) available for
more general use is the idea that's on the table.
The tclparser extension (http://wiki.tcl.tk/1660) is what people are
thinking about integrating, and http://tip.tcl.tk/310.html has the
current plan in this area (such as it is) but it may be modified
before implementation. But it should be enough to let you do the
constraint handling with little extra effort (assuming that nobody's
writing nasty code that hides variable accesses in places where
they're hard to see).
Donal.
Phil Mercurio
and all the procs that the formula invokes, all
the way down, just to trap variable accesses. In
addition, it would have to figure out the results of
conditionals, since variable accesses in the clause
of an if that is not executed should not become
sources for the constraint.
I think what would work would be an extension to
the trace command, something like "trace add
variable * read <proc>" where * means all vars.
Phil