build a syntax tree

[Federico]

Hi I've some trivial question:

for exercise I want to parse a string that like this:

"x -34 + 65 * 96 = 102"

now if I had this ("(25+24)/2") is extremely easy to have a result but
I want to resolve the above string (for the 'x' variable) what can I
do?

Especially for symbolic function  I think that I've to build an
'operations tree' with a variable table.
I want to  know how Derive parse this kind of string.

If I've to build a tree, please give me resources and/or examples of
what physically is a tree and how to build on python.

Thanks :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Subprocess and 16-bit FORTRAN

[Federico Ceccatto]

Hello,

For the past year I've been building an XP Python/wxPython shell of
sorts for several dozen command line FORTRAN tools developed for
various material science problems. Given how the methods and how-to's
have been lost to everyone but the original creators for these 80's to
90's pieces of code and the fact I am no physicist, I've relied on the
subprocess module in order to feed info according to their output.

I/O in general has worked wonders up to a handful of applications that
act in the strangest of ways. I strongly believe it's a bug in the
original programs/compiler, but that gets me nowhere. There's also the
fact the error shows up in two tools compiled with different FORTRAN
versions and made by different authors. I'll probably go cry for help
in a FORTRAN forum too.

Can't quite paste code due to its size and threaded nature, but
basically I have the output PIPE rigged to a class that parses text
into a tidy list (for easier analyzing), and a function that returns
input characters to the stdin method of the subprocess object
according to wether there has been any new data from stdout and
certain conditions (specific to the executable) are met.

I've got prints and repr()s everywhere to check nothing is ignored,
written multiple times or the child process is reporting errors. As I
mentioned, it works wonders for several other executables. None of the
obvious errors seem to be the case. As far as I can tell, the
input/output is ideal until the misbehaviour described below rears its
ugly head.

This is the kind of 'bugs' i've run into, perhaps someone could shed
some light onto them?

- Sometimes execution of child process (in this case, NTVDM.exe and
its children) stops and the object is destroyed for no reason
whatsoever. Very silent, no errors.

- Sometimes '\x03' as input is ignored, working simply as a '\n' of
sorts, while most of the time it simply kills the program as expected.

- Sometimes specific points in the code where the user is asked for
input and execution should be temporarily halted are ignored, as if
somehow it got a newline character.

None of these bugs are reproducible by running the same child
processess via NTVDM.exe through say, cmd.exe and such.

This has been driving me nuts for the last three weeks...

Thanks for your time.

- F.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generator slower than iterator?

[Federico Moreira]

The defaultdict option looks faster than the standard dict (20 secs aprox).

Now i have:

#
import fileinput
import sys
from collections import defaultdict

match_counter = defaultdict(int)

for line in fileinput.input(sys.argv[1:]):
match_counter[line.split()[0]] += 1
#

About generators, now i get the idea of when use them and when not.

Thanks MRAB, Lie and Gary.
Now not only is faster but also cleaner and easy to understand =)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Generator slower than iterator?

[Federico Moreira]

2008/12/16 

> Python 3.0 does not support has_key, it's time to get used to not using it
> :)
>

Good to know

line.split(None, 1)[0] really speeds up the proccess

Thanks again.
--
http://mail.python.org/mailman/listinfo/python-list

Generator slower than iterator?

[Federico Moreira]

Hi all,

Im parsing a 4.1GB apache log to have stats about how many times an ip
request something from the server.

The first design of the algorithm was

for line in fileinput.input(sys.argv[1:]):
ip = line.split()[0]
if match_counter.has_key(ip):
match_counter[ip] += 1
else:
match_counter[ip] = 1

And it took 3min 58 seg to give me the stats

Then i tried a generator solution like

def generateit():
for line in fileinput.input(sys.argv[1:]):
yield line.split()[0]

for ip in generateit():
...the same if sentence

Instead of being faster it took 4 min 20 seg

Should i leave fileinput behind?
Am i using generators with the wrong aproach?

Thanks in advance,

Federico.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Generator slower than iterator?

[Federico Moreira]

Great, 2min 34 secs with the open method =)

but why?

ip, sep, rest = line.partition(' ')
   match_counter[ip] += 1

instead of

match_counter[line.strip()[0]] += 1

strip really takes more time than partition?

I'm having the same results with both of them right now.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Generator slower than iterator?

[Federico Moreira]

Yep i meant split sorry.

Thanks for the answer!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Generator slower than iterator?

[Federico Moreira]

Wow, thanks again =)
--
http://mail.python.org/mailman/listinfo/python-list

Re: python web programming for PHP programmers

[Federico Moreira]

You can try also web2py (http://mdp.cti.depaul.edu/) but i think you may be
interested on http://www.modpython.org/
--
http://mail.python.org/mailman/listinfo/python-list

Objective Cairo

[federico . pelloni]

As pycairo is one of the less pythonish things I ever saw, it went into
my mind to create some sort of objective wrapper over its python api
making graphic manipulation much more coherent to the python way.

As of the moment, I can:
 - create (and reorder) multiple layers (this is not present in the
original cairo, but it is an easy addiction)
 - draw, move and delete Rectangles, Lines and (simple) Texts

This is particularly useful when combined with user interaction: I
wrote a simple demo that, without redrawing everything, allows me to
move a square up and down my canvas by pressing some buttons.

Before going on with more complex forms and objects, I was wondering if
this could be useful to anyone or if I'd better giving up.

A few example lines:

import objcairo
context = objcairo.Context()
layer = context.Layer()
rect = layer.Rectangle(10, 10, 200, 100)
rect.stroke((1,0,0))
rect.fill((0,1,0))
rect.move_down(20)
context.draw(some_cairo_context)

So, what do you think?

-- 
http://mail.python.org/mailman/listinfo/python-list