I'm going to reproduce some private conversation between Rod and
myself concerning calioPY here because I think calioPY is likely an
extremely important program. I'd like to understand it better.
Rod, please continue our conversation here. I think many people will
be interested.
QQQQQ
Thanks for your valuable comments about the program. I view calioPY
as an exploratory prototype for a type of software that I think is
needed in the work I do. There is way too much calculation repetition
without the benefit of templates, and commercial programs that try to
do what calioPY does (mathcad for example) do not seem to have caught
on. My thought is that Open Source may be able to break this low
productivity log jam and maximize the possibility of contribution and
distribution. I hope glimpsing this possibility, by using calioPY as
a motivation, will encourage more structural engineers to get involved
in learning some programming and contributing code or structural
procedures to some sort of widely available framework. In that sense
the program is a catalyst for something better down the road.
In addition, commercial programs so far do not have the organizational
facilities of Leo. Structural engineering calculations are typically
so straightforward that a one deep outline captures the calculation
structure. Yet they are voluminous and varied, so an outline is
invaluable and a natural way to organize. I have been looking for
something like this for two decades, never found it, so tried to write
it myself. The code is quite rough - as you see - but it does show
that it can be done. Over time, it should improve, or get replaced by
something better.
I often did not use the Leo directives, in part because I wanted to
learn how to script the interface, and in part because I wanted
maximum flexibility while I was working out how I wanted things to
work together. At the beginning I was not sure about directive
limitations. Also it seemed like they were in some flux. As I
refactor the code, and become more fluent in Leo, I will look for ways
to use standard Leo directive techniques.
Please feel free to pursue discussions about calioPY in any way that
seems interesting and instructive. I will participate as much as I
can.
Re examples: If you look at the figures at the end of the paper, you
can see both the output and input. Also, over a dozen examples are
included in calioPY core. If you load it you will see a cpy menu
entry - "expand examples" that expands all of the them. There is an
"hello world" node at the top of the outline as well that tests the
installation.
Questions:
I make generous use of plug-ins and scripts, and the Tk interface
works well for me in this respect. When do you think the qt plug-in
will be able to replace all of the TK functions?
By the way, for the purposes I am using it for, TK does not strike me
as ugly - a common complaint. Do you have a problem with TK
aesthetics?
Finally, do you have any general thoughts on the work flow of calioPY
related to Leo (aside from using directives more effectively):
1. Write some ascii markup
2.. Press a button that
a. assembles some python code into a program
b. assembles the markup from the selected node and optionally other
nodes
c. uses the markup as input to the python program
d. emits a pdf file
Does it make sense to include the program and data in the same file?
Do you think that using the underscore method to avoid naming
problems is sound?
Thanks,
Rod
QQQQQ
Here is my reply:
QQQQQ
> I often did not use the Leo directives, in part because I wanted to learn
> how to script the interface, and in part because I wanted maximum flexibility
> while I was working out how I wanted things to work together. At the
> beginning I was not sure about directive limitations. Also it seemed like
> they were in some flux. As I refactor the code, and become more fluent in
> Leo, I will look for ways to use standard Leo directive techniques.
I think that would be a good idea.
> Please feel free to pursue discussions about calioPY in any way that seems
> interesting and instructive. I will participate as much as I can.
>From my (unusual) point of view, the go-f9 and go-f11 buttons appear
to be the heart of the process. I could be wrong. But a detailed
explanation of what these buttons do and why they are useful would
seem like a good first start.
> Re examples: If you look at the figures at the end of the paper, you can see
> both the output and input. Also, over a dozen examples are included in
> calioPY core. If you load it you will see a cpy menu entry - "expand
> examples" that expands all of the them. There is an "hello world" node at
> the top of the outline as well that tests the installation.
I don't see a cpy menu. It looks like I haven't installed needed
dependencies. I'd like to install the dependencies today...
And a later continuation (by EKR):
Just did that. I installed matplotlib etc. Still no cpy menu. Here
are my install notes:
- Installed matplotlib 0.91.4 for Python 2.6 (only) from binary.
- libpng (1.2.37) Installed in c:\program files\GnuWin32
- freetype (2.3.5-1) Installed in c:\program files\GnuWin32
Installed on python 2.6 and 2.6:
- numpy 1.1.0.
- reportlab build 3093 (version 2.3).
- pypdf 1.11 (1.12).
- pil 1.1.6.
ipython -pylab now loads matplotlib and I can import matplotlib from
test.leo, so all appears well.
> I make generous use of plug-ins and scripts, and the Tk interface works well
> for me in this respect. When do you think the qt plug-in will be able to
> replace all of the Tk functions?
Which tk functions do you need that are missing?
> By the way, for the purposes I am using it for, TK does not strike me as ugly
> - a common complaint. Do you have a problem with TK aesthetics?
The Tk font's seem to be the biggest issue. However, I think Tk may
now have anti-aliased fonts, so perhaps even that is not a real issue.
Given all the work I have done with Qt lately, it would be nice to be
able to say that Qt is clearly better, but I'm not sure I can actually
say that.
> Finally, do you have any general thoughts on the work flow of calioPY
> related to Leo (aside from using directives more effectively):
1. Write some ascii markup
2.. Press a button that
a. assembles some python code into a program
b. assembles the markup from the selected node and optionally
other nodes
c. uses the markup as input to the python program
d. emits a pdf file
I think discussing the workflow just this way (simply) would make the
docs clearer. If there is, in fact, just one button that does all of
point 2, you should by all means discuss that button in detail!
> Does it make sense to include the program and data in the same file?
It would be typical to put the calioPY sources in a a calioPY.py
module. That way, the user's myCalioPYProject.leo could simply create
one or two calioPY buttons that would import the calioPY module. In
other words, the user's myCalioPYProject.leo should, it seems to me,
contain only the users data. That seems *much* cleaner than putting
calioPY code in the users projects.
In a similar way, test.leo does not duplicate the code in leoPy.leo,
but merely imports parts of it as needed.
Furthermore, as I said earlier, it would seem to make much more sense
to use "normal" Leo programming style to create the calioPY module.
Possibly you didn't do that because you wanted to use calioPY features
for the actual calioPY sources, but to repeat again, you appear to be
paying a heavy price for that choice, and I suspect a much easier way
can be found to accomplish what you want.
My impression is that calioPY already is an important project, and
that if we could sit down and talk we could make it much easier to
user and/or develop. It's a bit frustrating to communicate only via
email for this. The telephone might be better. Feel free to call me
if you like.
> Do you think that using the underscore method to avoid naming problems is
> sound?
It's not a big deal. Usually, classes have methods intended to be
used externally, and other methods for internal use. I almost never
use the underscore convention, but that's just me.
Edward
QQQQQ
Edward
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
