visualpython-users

[Visualpython-users] Re: "WinPyVisual" complete

[Bruce S. <bas...@un...>]

Oh, one other thing. Arthur, please don't wait for my "permission". Do make
your experiments available to all of us to try out. We'll all benefit from a
diversity of approaches being tried.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>; "vpusers"
<vis...@li...>
Sent: Sunday, March 02, 2003 3:58 PM
Subject: "WinPyVisual" complete


> As a step towards an "all_in_one" Windows distribution of PyGeo, I have a
> draft of a working all_in_one version of VPython available.
>
> As it currently exists, it is a zip file of < 1.2 meg that can be unzipped
> anywhere in the directory tree. It includes a scaled down ScITE.  Fire up
> ScITE, go to the "demos" sub-directory, open up any of the usual  VPython
> demos - see proviso as to Tkinter below -  hit F5 and the demo will run.
No
> other python, Numeric, or other files (other than normally present Windows
> dlls) are assumed to be present on the machine.
>
> If a distribution along these lines is to be developed, it would be simple
> to do it using a simple Windows installer to add icons, start files,
> licenses, etc.
>
> Also, for demonstration purposes, I have available another zip file with a
> bounce2.exe file and the minimal support files it needs to run.
Doubleclick
> and the bounce2 demo runs. It was built using py2exe in conjunction with
> distutils. Bounce2.exe is about 200k and includes all the Python files
> (including a version of the interpreter itself) needed to run VPython
files,
> except for the following rquired dlls:
>
> python22.dll
> umath.pyd
> multiarray.pyd
> _numpy.pyd
> _sre.pyd
> cvisual.pyd
>
> What I think is potentially interesting about this facility, as a one
trick
> in the toolchest, is the ability to demonstrate one's work to others
without
> asking them to do anything major in terms of an installation on their
> machine.  Assuming they at least have access to a Windows machine, if they
> are given the above listed dlls in a directory, any VPython constructions
> then built as .exe will run as an executable from that directory.  I
include
> in the zip the simple required setup.py and a .bat file to run which -
> assuming one downloads py2exe (there is a Windows installer for it) - will
> create, with minimal editing,  an executable out of any VPython script.
>
> With Bruce's permission (and some instructions on how to do so) , I will
> make these files available.
>
> Art
>
> FWI, the PyGeo situation is a little more complicated in that it requires
> TkInter.  But its quite doable, just adds a little more bulk to the
> distribution.
>
> Do any of the VPython demos rely on Tk?  If so, those will not run
> successfully with the "distribution" in its present form.
>
>
>
>
>

[Visualpython-users] Re: "WinPyVisual" complete

[Bruce S. <bas...@un...>]

This sounds pretty interesting, Arthur. Thanks for the research! I myself am
recovering from being sick for several days, so it will be a while before I
can play with your ideas.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>; "vpusers"
<vis...@li...>
Sent: Sunday, March 02, 2003 3:58 PM
Subject: "WinPyVisual" complete


> As a step towards an "all_in_one" Windows distribution of PyGeo, I have a
> draft of a working all_in_one version of VPython available.
>
> As it currently exists, it is a zip file of < 1.2 meg that can be unzipped
> anywhere in the directory tree. It includes a scaled down ScITE.  Fire up
> ScITE, go to the "demos" sub-directory, open up any of the usual  VPython
> demos - see proviso as to Tkinter below -  hit F5 and the demo will run.
No
> other python, Numeric, or other files (other than normally present Windows
> dlls) are assumed to be present on the machine.
>
> If a distribution along these lines is to be developed, it would be simple
> to do it using a simple Windows installer to add icons, start files,
> licenses, etc.
>
> Also, for demonstration purposes, I have available another zip file with a
> bounce2.exe file and the minimal support files it needs to run.
Doubleclick
> and the bounce2 demo runs. It was built using py2exe in conjunction with
> distutils. Bounce2.exe is about 200k and includes all the Python files
> (including a version of the interpreter itself) needed to run VPython
files,
> except for the following rquired dlls:
>
> python22.dll
> umath.pyd
> multiarray.pyd
> _numpy.pyd
> _sre.pyd
> cvisual.pyd
>
> What I think is potentially interesting about this facility, as a one
trick
> in the toolchest, is the ability to demonstrate one's work to others
without
> asking them to do anything major in terms of an installation on their
> machine.  Assuming they at least have access to a Windows machine, if they
> are given the above listed dlls in a directory, any VPython constructions
> then built as .exe will run as an executable from that directory.  I
include
> in the zip the simple required setup.py and a .bat file to run which -
> assuming one downloads py2exe (there is a Windows installer for it) - will
> create, with minimal editing,  an executable out of any VPython script.
>
> With Bruce's permission (and some instructions on how to do so) , I will
> make these files available.
>
> Art
>
> FWI, the PyGeo situation is a little more complicated in that it requires
> TkInter.  But its quite doable, just adds a little more bulk to the
> distribution.
>
> Do any of the VPython demos rely on Tk?  If so, those will not run
> successfully with the "distribution" in its present form.

[Visualpython-users] "WinPyVisual" complete

[Arthur <ajs...@op...>]

As a step towards an "all_in_one" Windows distribution of PyGeo, I have a
draft of a working all_in_one version of VPython available.

As it currently exists, it is a zip file of < 1.2 meg that can be unzipped
anywhere in the directory tree. It includes a scaled down ScITE.  Fire up
ScITE, go to the "demos" sub-directory, open up any of the usual  VPython
demos - see proviso as to Tkinter below -  hit F5 and the demo will run.  No
other python, Numeric, or other files (other than normally present Windows
dlls) are assumed to be present on the machine.

If a distribution along these lines is to be developed, it would be simple
to do it using a simple Windows installer to add icons, start files,
licenses, etc.

Also, for demonstration purposes, I have available another zip file with a
bounce2.exe file and the minimal support files it needs to run.  Doubleclick
and the bounce2 demo runs. It was built using py2exe in conjunction with
distutils. Bounce2.exe is about 200k and includes all the Python files
(including a version of the interpreter itself) needed to run VPython files,
except for the following rquired dlls:

python22.dll
umath.pyd
multiarray.pyd
_numpy.pyd
_sre.pyd
cvisual.pyd

What I think is potentially interesting about this facility, as a one trick
in the toolchest, is the ability to demonstrate one's work to others without
asking them to do anything major in terms of an installation on their
machine.  Assuming they at least have access to a Windows machine, if they
are given the above listed dlls in a directory, any VPython constructions
then built as .exe will run as an executable from that directory.  I include
in the zip the simple required setup.py and a .bat file to run which -
assuming one downloads py2exe (there is a Windows installer for it) - will
create, with minimal editing,  an executable out of any VPython script.

With Bruce's permission (and some instructions on how to do so) , I will
make these files available.

Art

FWI, the PyGeo situation is a little more complicated in that it requires
TkInter.  But its quite doable, just adds a little more bulk to the
distribution.

Do any of the VPython demos rely on Tk?  If so, those will not run
successfully with the "distribution" in its present form.

[Visualpython-users] Ellipsoid

[John K. <joh...@ho...>]

I've finished a producing an ellipsoid object.  I think it will add a little 
flexibility to the kind of things one can depict with VPython.  Except for 
the normals, the program is a simple variation on Thom Ives's spherepart 
routine.

I believe, but am not absolutely certain, that the normals are correct.  I 
hope someone who is better than I am at geometry will take a look to verify. 
  I would greatly appreciate that.

Even if the ellipsoid generator is not perfect, I hope that you enjoy the 
demo program.

Sincerely,

John



Here is the program:
--------------------------------------------------------------
from visual import *

# Ellipsoid
# John W. Keck
# February 2003
# based on "spherepart" by Thom Ives

newframe = frame # this makes "newframe()" mean what "frame()" usually means

class ellipsoid(object):
    # This routine draws an ellipsoid with axes given by size.
    # axis gives the orientation of x-axis, up rotates about the axis (i.e., 
"roll")
    # Default parameters draw an ellipsoid with dimensions 1x2x3 at origin.
    def __init__(self, frame=None, pos=(0,0,0), axis=(1,0,0), up=(0,1,0), 
size=(1,2,3), color=scene.foreground, incs=25):
        self.frame = newframe(pos=pos, axis=axis, frame=frame, up=up)
        self.__pos = vector(pos)
        self.__axis = norm(vector(axis))
        self.__up = norm(vector(up))
        self.__size = vector(size)
        self.f = 0.0
        self.r = mag(self.axis)
        self.a = vector(size).x*0.5 # user specifies axes
        self.b = vector(size).y*0.5 # but use the semi-axes
        self.c = vector(size).z*0.5 # for "radii"
        self.phi_b = 1.5*pi
        self.phi_f = 0.5*pi
        self.__color = color
        self.incs = incs
        VertexList, NormalList = self.buildfaces()
        self.faces = faces(frame=self.frame, pos=VertexList, 
normal=NormalList, color=color)

    def buildfaces(self):
        VertexList = []    # Create an empty vertex list for the body's 
vertices.
        NormalList = []     # Ditto for the vertex normals.
        length = mag(self.axis)

        cosphi = cos(self.phi_b)
        sinphi0 = sin(self.phi_b)
        sinphi = cosphi**2 - 1 #sin(self.phi_b)
#        print sinphi, sinphi0
        dphi = (self.phi_f - self.phi_b)/self.incs
        cosdphi = cos(dphi)
        sindphi = sin(dphi)
#        sindphi = 1 - cosdphi**2 #sin(dphi)
        p0 = vector(self.a*sinphi,0,0);        n0 = (-1.0,0.0,0.0)
        p5 = vector(self.a,0,0);        n5 = (1.0,0.0,0.0)

        a = self.a
        b = self.b
        c = self.c

        for i in range(self.incs):
            newcosphi = cosphi*cosdphi-sinphi*sindphi
            newsinphi = sinphi*cosdphi+cosphi*sindphi

            costheta = 1.0
            sintheta = 0.0
            dtheta = 2*pi/self.incs
            cosdtheta = cos(dtheta)
#            sindtheta = 1 - cosdtheta**2 #sin(dtheta)
            sindtheta = sin(dtheta)

            for j in range(self.incs):

        # Calculate four pts that form a small rectangle on each of the 
surfaces.
        # Use these points to make the vertices of two triangles that form 
each of these reactangles.
        # Find a normal to the rectangle. Store vertices and normals.
        # Repeat for the number of increments you want - more increments 
better visual quality.

                # recursion relations for cosine and sine of (theta+dtheta); 
avoid lots of trig functions
                newcostheta = costheta*cosdtheta-sintheta*sindtheta
                newsintheta = sintheta*cosdtheta+costheta*sindtheta

                # Vector / Vertices and Triangles
                p1 = 
vector(self.a*sinphi,self.b*costheta*cosphi,self.c*sintheta*cosphi)
                p2 = 
vector(self.a*sinphi,self.b*newcostheta*cosphi,self.c*newsintheta*cosphi)
                p3 = 
vector(self.a*newsinphi,self.b*newcostheta*newcosphi,self.c*newsintheta*newcosphi)
                p4 = 
vector(self.a*newsinphi,self.b*costheta*newcosphi,self.c*sintheta*newcosphi)

                # normals chosen for smoothing - an Oil of Olay technique
                # I'm don't think the immediately following normals work
##                n1 = 
vector(sinphi/a**2,costheta*cosphi/b**2,sintheta*cosphi/c**2)
##                n2 = 
vector(sinphi/a**2,newcostheta*cosphi/b**2,newsintheta*cosphi/c**2)
##                n3 = 
vector(newsinphi/a**2,newcostheta*newcosphi/b**2,newsintheta*newcosphi/c**2)
##                n4 = 
vector(newsinphi/a**2,costheta*newcosphi/b**2,sintheta*newcosphi/c**2)
                # I'm pretty sure the following are the correct normals
                n1 = vector(sinphi/a,costheta*cosphi/b,sintheta*cosphi/c)
                n2 = 
vector(sinphi/a,newcostheta*cosphi/b,newsintheta*cosphi/c)
                n3 = 
vector(newsinphi/a,newcostheta*newcosphi/b,newsintheta*newcosphi/c)
                n4 = 
vector(newsinphi/a,costheta*newcosphi/b,sintheta*newcosphi/c)

                if i > 0 and i < (self.incs-1):
                    VertexList = VertexList + [p1,p2,p3,p1,p3,p4]
                    NormalList = NormalList + [n1,n2,n3,n1,n3,n4]
                elif i == 0:
                    VertexList = VertexList + [p0,p2,p1,p1,p2,p3,p1,p3,p4]
                    NormalList = NormalList + [n0,n0,n0,n1,n2,n3,n1,n3,n4]
                elif i == (self.incs-1):
                    VertexList = VertexList + [p1,p2,p3,p1,p3,p4,p4,p3,p5]
                    NormalList = NormalList + [n1,n2,n3,n1,n3,n4,n5,n5,n5]

                sintheta = newsintheta
                costheta = newcostheta

            sinphi = newsinphi
            cosphi = newcosphi

        return VertexList, NormalList

    def getpos(self):
        return self.__pos

    def setpos(self, pos):
        self.frame.pos = self.__pos = vector(pos)

    pos = property(getpos, setpos)

    def getaxis(self):
        return self.__axis

    def setaxis(self, axis): # scale all points in front face
        k = mag(vector(axis))/mag(self.axis)
        self.frame.axis = self.__axis = vector(axis)
        for pos in self.faces.pos:
            pos[0] *= k; pos[1] *= k; pos[2] *= k

    axis = property(getaxis, setaxis)

    def rebuild(self):
        VertexList, NormalList = self.buildfaces()
        self.faces.pos = VertexList
        self.faces.normal = NormalList

    def getcolor(self):
        return self.__color

    def setcolor(self, color):
        self.__color = color
        self.faces.color = color

    color = property(getcolor, setcolor)

    def DrawNormal(self, scale):
        pos = self.faces.pos
        normal = self.faces.normal
        for i in range(len(pos)):
            arrow(pos=pos[i], axis=normal[i]*scale,color=color.yellow)

if __name__ == '__main__':

    scene.title = "Golden Egg and Proud Hen"
    scene.background = (0.7,9.0,9.0)
    # Provide a simple program to illustrate how the ellipsoid object works.
    color.gold = (3,2,0.9)
    color.orange = (1.0,0.5,0)
    color.brown = (0.46,0.28,0.10)

    # which came first?
    # a golden egg
    egg = ellipsoid(pos=(4,3.6,0), axis=(1,1,0), 
size=(6,8.1,6),color=color.gold)

    # a comical chicken
    hen = frame()
    body = ellipsoid(frame=hen, pos=(-10,15,0), axis=(-1,0.2,0), 
size=(30,20,20), color=color.white, incs=25)
    wngl = ellipsoid(frame=hen, pos=(-7,18,7), size=(20,10,6), 
axis=(-1,0.1,0), up=(0,1,-0.5), color=color.white)
    wngr = ellipsoid(frame=hen, pos=(-7,18,-7), size=(20,10,6), 
axis=(-1,0.1,0), up=(0,1,0.5), color=color.white)
    head = ellipsoid(frame=hen, pos=(-19,23,0), axis=(-3,1,0), 
size=(8,18,8), color=color.white)
    comb = ellipsoid(frame=hen, pos=(-16,31,0), 
size=(4,4,2),color=(1.0,0.7,0.7))
    tail = ellipsoid(frame=hen, pos=(4,15,0), axis=(-1,1,0), 
size=(2.5,8,8),color=color.white)
    beak = cone(frame=hen, pos=(-20,28,0), radius=1.2, length=4, 
axis=(-1,0,0), color=color.orange)
    eyel = sphere(frame=hen,pos=(-19,30,2), radius=0.7, color=color.blue)
    eyer = sphere(frame=hen,pos=(-19,30,-2), radius=0.7, color=color.blue)
    legl = 
curve(frame=hen,pos=[(-10,7,2),(-10,0,2),(-13,0,2)],color=color.orange, 
radius=0.3)
    ftl = 
curve(frame=hen,pos=[(-12.5,0,3),(-10,0,2),(-12.5,0,1)],color=color.orange, 
radius=0.3)
    legr = 
curve(frame=hen,pos=[(-10,7,-2),(-10,0,-2),(-13,0,-2)],color=color.orange, 
radius=0.3)
    ftr = 
curve(frame=hen,pos=[(-12.5,0,-3),(-10,0,-2),(-12.5,0,-1)],color=color.orange, 
radius=0.3)
    hen.pos = (-3,0,0)

    # the surroundings
    gnd = box(size=(40,2,20),pos=(-10,-1,0), color=color.green)





_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: [Visualpython-users] distutils

[Arthur <aj...@ix...>]

As  per Arnd's suggestion, we are probably not facing anything that others
haven't faced and othercome.  And its probably a good idea to see how others
are handling these issues.

On that score:

It might be worthwhile to download the pygame source distro -
http://pygame.org/ -  to see how a complex - I think more than VPython
faces - situation with a host of dependencies is handled.  There is a
generic config.py script that calls platform specific config scripts, which
then finally configures the workable setup.py.

More bads news:

On the start menu, icon issue for Windows - I see that while pygame
accomplishes it with a pure Python script, the script working is dependent
on having win32all installed.

Art
----- Original Message -----
From: "Bruce Sherwood" <bas...@un...>
To: "Arthur" <ajs...@op...>; "vpusers"
<vis...@li...>
Sent: Tuesday, February 25, 2003 11:57 AM
Subject: Re: [Visualpython-users] distutils


> There's quite a large number of detailed issues. To give a simple example,
a
> machine (my Mac OSX 10.2 is an example) may not have gtk-config to be
driven
> to identify the gtk library environment. And gtk-config only applies to
GTK
> 1, not GTK 2. Etc. As Jonathan Brandmeyer has pointed out to me, distutils
> doesn't address a large number of the configuration/environment issues
that
> are handled by the autoconfig machinery used for example in the
compilation
> of Python itself from source. Sometime last year I complimented Guido on
the
> fact that the source compilation of Python worked flawlessly on many
> different Unix-like platforms, and he said that there had been a huge
amount
> of work on the autoconfig aspects over a couple of years to reach this
point
> of universality.
>
> So while distutils may have some uses with respect to VPython (including
as
> Arthur has shown a nice way to produce an executable installer on
Windows),
> it does seem alas that eventually we'll have to bite the bullet of
learning
> to use autoconfig to address the many nagging problems that people have
> experienced on diverse Linux/Unix platforms.
>
> The problems will be eased by Jonathan's intention to try to simplify the
> Visual environment using newer schemes such as Boost, which Arthur made us
> aware of.
>
> Bruce Sherwood
>
> ----- Original Message -----
> From: "Arthur" <ajs...@op...>
> To: "Bruce Sherwood" <bas...@un...>; "vpusers"
> <vis...@li...>
> Sent: Tuesday, February 25, 2003 9:03 AM
> Subject: Re: [Visualpython-users] distutils
>
>
> > I am running into some isues as well.
> >
> > I am not sure it even solves the most substantial issues, but thinking
> about
> > it, is there any reason the Windows and non-Windows setup.py's cannot be
> > separate scripts?
> >
> > Would also be interested in what you are running into.  Are the issues
> > intra-Linux, Linux/Mac?
> >
> > Since I have only one Linux and no Mac to test, I suspect issues, but
> cannot
> > actually see them.
> >
> > Art
> >
> > Art
> > ----- Original Message -----
> > From: "Bruce Sherwood" <bas...@un...>
> > To: "vpusers" <vis...@li...>
> > Sent: Tuesday, February 25, 2003 8:51 AM
> > Subject: [Visualpython-users] distutils
> >
> >
> > > Prompted by Arthur Siegel's suggestions, Jonathan Brandmeyer and I
have
> > been
> > > doing some experimenting with distutils as a mechanism for building
> > VPython
> > > installers. The situation is not as simple as one would like.
> Dynamically
> > > supporting all of our platforms and different compilers with a single
> > script
> > > will be difficult at best. We'll keep at this.
> > >
> > > Bruce Sherwood
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Visualpython-users mailing list
> > > Vis...@li...
> > > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
> >
> >
>

Fw: [Visualpython-users] distutils

[Bruce S. <bas...@un...>]

Maybe there's something useful here. Thanks.

----- Original Message -----
From: <ba...@ph...>
To: "Bruce Sherwood" <bas...@un...>
Sent: Tuesday, February 25, 2003 9:11 AM
Subject: Re: [Visualpython-users] distutils


> Hi,
>
> just a remark (maybe its useless ;-):
>
> The scipy people have spent quite some effort for the installation
> and devised some add-ons (scipy-distutils,
>
http://www.scipy.org/site_content/remap?rmurl=http%3A//scipy.net/cgi-bin/vie
wcvsx.cgi/scipy/scipy_distutils/
>
> Maybe something of that there is useful to you.
>
> Best,
>
> Arnd
>
>
> On Tue, 25 Feb 2003, Bruce Sherwood wrote:
>
> > Prompted by Arthur Siegel's suggestions, Jonathan Brandmeyer and I have
been
> > doing some experimenting with distutils as a mechanism for building
VPython
> > installers. The situation is not as simple as one would like.
Dynamically
> > supporting all of our platforms and different compilers with a single
script
> > will be difficult at best. We'll keep at this.
> >
> > Bruce Sherwood
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
>
>

Re: [Visualpython-users] distutils

[Bruce S. <bas...@un...>]

There's quite a large number of detailed issues. To give a simple example, a
machine (my Mac OSX 10.2 is an example) may not have gtk-config to be driven
to identify the gtk library environment. And gtk-config only applies to GTK
1, not GTK 2. Etc. As Jonathan Brandmeyer has pointed out to me, distutils
doesn't address a large number of the configuration/environment issues that
are handled by the autoconfig machinery used for example in the compilation
of Python itself from source. Sometime last year I complimented Guido on the
fact that the source compilation of Python worked flawlessly on many
different Unix-like platforms, and he said that there had been a huge amount
of work on the autoconfig aspects over a couple of years to reach this point
of universality.

So while distutils may have some uses with respect to VPython (including as
Arthur has shown a nice way to produce an executable installer on Windows),
it does seem alas that eventually we'll have to bite the bullet of learning
to use autoconfig to address the many nagging problems that people have
experienced on diverse Linux/Unix platforms.

The problems will be eased by Jonathan's intention to try to simplify the
Visual environment using newer schemes such as Boost, which Arthur made us
aware of.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>; "vpusers"
<vis...@li...>
Sent: Tuesday, February 25, 2003 9:03 AM
Subject: Re: [Visualpython-users] distutils


> I am running into some isues as well.
>
> I am not sure it even solves the most substantial issues, but thinking
about
> it, is there any reason the Windows and non-Windows setup.py's cannot be
> separate scripts?
>
> Would also be interested in what you are running into.  Are the issues
> intra-Linux, Linux/Mac?
>
> Since I have only one Linux and no Mac to test, I suspect issues, but
cannot
> actually see them.
>
> Art
>
> Art
> ----- Original Message -----
> From: "Bruce Sherwood" <bas...@un...>
> To: "vpusers" <vis...@li...>
> Sent: Tuesday, February 25, 2003 8:51 AM
> Subject: [Visualpython-users] distutils
>
>
> > Prompted by Arthur Siegel's suggestions, Jonathan Brandmeyer and I have
> been
> > doing some experimenting with distutils as a mechanism for building
> VPython
> > installers. The situation is not as simple as one would like.
Dynamically
> > supporting all of our platforms and different compilers with a single
> script
> > will be difficult at best. We'll keep at this.
> >
> > Bruce Sherwood
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Visualpython-users mailing list
> > Vis...@li...
> > https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>
>

Re: [Visualpython-users] distutils

[Arthur <ajs...@op...>]

I am running into some isues as well.

I am not sure it even solves the most substantial issues, but thinking about
it, is there any reason the Windows and non-Windows setup.py's cannot be
separate scripts?

Would also be interested in what you are running into.  Are the issues
intra-Linux, Linux/Mac?

Since I have only one Linux and no Mac to test, I suspect issues, but cannot
actually see them.

Art

Art
----- Original Message -----
From: "Bruce Sherwood" <bas...@un...>
To: "vpusers" <vis...@li...>
Sent: Tuesday, February 25, 2003 8:51 AM
Subject: [Visualpython-users] distutils


> Prompted by Arthur Siegel's suggestions, Jonathan Brandmeyer and I have
been
> doing some experimenting with distutils as a mechanism for building
VPython
> installers. The situation is not as simple as one would like. Dynamically
> supporting all of our platforms and different compilers with a single
script
> will be difficult at best. We'll keep at this.
>
> Bruce Sherwood
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] distutils

[Bruce S. <bas...@un...>]

Prompted by Arthur Siegel's suggestions, Jonathan Brandmeyer and I have been
doing some experimenting with distutils as a mechanism for building VPython
installers. The situation is not as simple as one would like. Dynamically
supporting all of our platforms and different compilers with a single script
will be difficult at best. We'll keep at this.

Bruce Sherwood

[Visualpython-users] setup.py

[Bruce S. <bas...@un...>]

Jonathan Brandmeyer found that changing the last line of the setup.py in the
VPython CVS to the following fixed a problem with using this distutil script
on RedHat 8.0:

libraries = ["GL","gtkgl","stdc++"]

This has been checked into CVS.

Bruce Sherwood

[Visualpython-users] Distutils metadata

[Arthur <ajs...@op...>]

Those with an interest in the installation and packaging thread that has
been undertaken here might want to check out the following feature of
Python2.3, now released in alpha 2 version.

From the "what's new":

a.. Package index and metadata for distutils. This is support of the Python
catalog, now open for business at python.org/pypi. (PEP 301)

Essentially this is the first step in what is hoped to be an online
cataloguing mechanism for Python moudles, extensions, and applications. The
mechanics seemed to just adding a line ow two to one's setup.py and using it
to "register" one's distribution.

IMO, another good reason for VPython to consider conversion to the distutils
methodolgies, ASAP.

Art

[Visualpython-users] IEEE NaN handling, rotating scene with mouse

[John K. <joh...@ho...>]

A suggestion for future versions of Vpython:

It would be very useful to enable the curve feature to "pick up the pen" 
(leave a break in plotting) when it encounters the IEEE NaN (non-a-number) 
as a position coordinate.  This would allow the user to generate a 
discontinuous curve with a single curve object by introducing NaN's into the 
position coordinates.  (Is there perhaps another way to get this same 
behavior in the mean time?)  Right now, NaN's crash the curve routine.  (Now 
I'm wondering how it handles IEEE Inf.)

Also, I've been noticing that rotating the scene with the mouse works in an 
intuitive way until the view is along the y-axis.  The intuitive way is for 
up-down mouse movement to rotate along the vertical line of the window and 
for left-right mousemovent to rotate along the horizontal line.  The way it 
actually works is for horizontal movement to rotate in plane perpendicular 
to the y-axis (what would be azimuthal angle in spherical coordinates, 
except in x-z plane), and vertical movement to rotate to and from the y-axis 
(what would be polar angle in spherical coords, except from y-axis, not z).  
Is there any simple way to change this bevavior? At least to change the 
preferred axis?

BTW a good example of the intuitive rotational behavior is at the 
outstanding java applet at Nasa's Marshall Center: 
http://liftoff.msfc.nasa.gov/realtime/jtrack/3d/JTrack3d.html
Worth examining in its own right!

JK

P.S. This is the only way I could find to generate NaN without crashing:
nan = struct.unpack("f", '\xff\xff\xff\xff').  Anyone know of a more 
straight-forward way?  JK


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

Re: [Visualpython-users] Further adventures with primitives

[Arthur <ajs...@op...>]

Further adventures with primitives>The major focus of my project is getting VPython to run on the Wedge 3D visualisation system (see photo on the web page).

Not fair. That looks like too much fun.


> As an extra part of the project there is a requirment to extend VPython for use by the Maths Department at the ANU for teaching purposes. So all my hacking of VPython is connected >to this.

Obviously very interested to know where you are going there - as my work with VPython has been related to math education. 

>When I finish programming a reasonable set of shapes, I will see if Bruce et al are interested in adding them to the next release of VPython. 

Good!

>At this moment my ability to work on VPython is limited by time but I am starting a new position at the ANU very soon and will have more time (I hope) to work on both my project and >general VPython hacks. I will probably set up a web page where my code can be accessed when I start my new job. In the meantime I will keep posting descriptions of what I have been >doing to this list.

Look forward to it.


Art

RE: [Visualpython-users] Further adventures with primitives

[Press, S. <sha...@ai...>]

A little bit of background.
My work with VisualPython is part of my Masters in eScience (
http://eScience.anu.edu.au ) at the Australian National University. The
major focus of my project is getting VPython to run on the Wedge 3D
visualisation system (see photo on the web page). As an extra part of the
project there is a requirment to extend VPython for use by the Maths
Department at the ANU for teaching purposes. So all my hacking of VPython is
connected to this.
When I finish programming a reasonable set of shapes, I will see if Bruce et
al are interested in adding them to the next release of VPython. At this
moment my ability to work on VPython is limited by time but I am starting a
new position at the ANU very soon and will have more time (I hope) to work
on both my project and general VPython hacks. I will probably set up a web
page where my code can be accessed when I start my new job. In the meantime
I will keep posting descriptions of what I have been doing to this list.
 
Now replying to Jonathan Brandmeyer
Modifying cylmodel.h 
cylmodel.h is used at the moment to calculate cones and cylinders. It is
probably worth creating a conemodel.h file which can then be used by
cone/pyramid etc shapes (ie shapes that have a point) as then the more
efficient GL_TRIANGLE_FAN method can draw these. Cylinders and frustums
could remain in a modified cylmodel.h file, which would support top and
bottom radii parameters. Of course this could then be used to do cones etc
by setting the minor radius to 0 but would also create the redundant tip
points so I suppose it is generality versus speed!
One thing I am interested in adding is a general n-polygon shape eg 4 =
tetrahedron, 6 = octahedron 8 = cube etc Hopefully a bit of reading and I
should be able to do it.
 

-----Original Message-----
From: Arthur [mailto:ajs...@op...]
Sent: Friday, 21 February 2003 0:08
To: Press, Shaun; vis...@li...
Subject: Re: [Visualpython-users] Further adventures with primitives


Shaun - 
 
How does one get one's greedy hands on what you have done.
 
Interested both as to the specifics of what you have implemented, and for
the tutorial value of understanding, in full specifics, how you have
accomplished it.
 
Art

 

Re: [Visualpython-users] idlefork

[Bruce S. <bas...@un...>]

With hundreds of student users and many others including myself I've not
seen the problem you report, at least using the idlefork version distributed
with VPython. Sounds idiosyncratic to your installation, somehow. No clue
what the problem could be.

The very severe problems you describe in the recent alpha distribution of
idlefork are being worked on intensely.

Bruce Sherwood

----- Original Message -----
From: "Gary Pajer" <pa...@in...>
To: "vpusers" <vis...@li...>
Sent: Thursday, February 20, 2003 1:27 PM
Subject: [Visualpython-users] idlefork


> The recent discussion about idlefork and SciTE reminded me that I don't
use
> idlefork, but I didn't remember why.  Now I remember. It doesn't work for
> me.  (Win98, here)  After running a visual script once or twice it crashes
> with a dialog box about a page fault.  The dialog box won't close, and
won't
> go away.  Gotta restart Windows.  I tried the alpha on SF, but that
doesn't
> work either.  For that one, after closing the visual window I get a dialog
> telling my that vpython is still running, do I want to kill it?  Yes, but
it
> won't die.  At least this time I can use the Close Program dialog to wipe
it
> out.  Any clues about that?
>
> So I'm using my fave texteditor, NoteTab Pro, and keeping a DOS window
open.
> Works fine, but no syntax highlighting.  Bells and whistles are possible,
> but I'd have to figure out the editor's macro language to customize for
> python.  I tried SciTE, and that seems to work.
>
> -Gary
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

[Visualpython-users] idlefork

[Gary P. <pa...@in...>]

The recent discussion about idlefork and SciTE reminded me that I don't use
idlefork, but I didn't remember why.  Now I remember. It doesn't work for
me.  (Win98, here)  After running a visual script once or twice it crashes
with a dialog box about a page fault.  The dialog box won't close, and won't
go away.  Gotta restart Windows.  I tried the alpha on SF, but that doesn't
work either.  For that one, after closing the visual window I get a dialog
telling my that vpython is still running, do I want to kill it?  Yes, but it
won't die.  At least this time I can use the Close Program dialog to wipe it
out.  Any clues about that?

So I'm using my fave texteditor, NoteTab Pro, and keeping a DOS window open.
Works fine, but no syntax highlighting.  Bells and whistles are possible,
but I'd have to figure out the editor's macro language to customize for
python.  I tried SciTE, and that seems to work.

-Gary

Re: [Visualpython-users] Further adventures with primitives

[Arthur <ajs...@op...>]

Further adventures with primitivesShaun - 

How does one get one's greedy hands on what you have done.

Interested both as to the specifics of what you have implemented, and for the tutorial value of understanding, in full specifics, how you have accomplished it.

Art
  ----- Original Message ----- 
  From: Press, Shaun 
  To: 'vis...@li...' 
  Cc: 'hen...@an...' 
  Sent: Wednesday, February 19, 2003 5:48 PM
  Subject: [Visualpython-users] Further adventures with primitives


  I have managed to add Tetrahedron, Pyramid and Frustum to the primitive shapes in my copy of Visual Python. 
  The terahedron and pyramid a pretty simple to do as they are a specific form of the cone shape. 
  In the cone.cpp file there is a section devoted to calculating the level of detail for the shape. The idea is that closer shapes are drawn with a lot of detail while distant shapes require less. Depending on the size and location of the cone it can be drawn with 20 panels down to 5 panels. The number of panels is passed to the cyl_model object which returns the vertices required to draw the shape.

  To draw a pyramid, simply drop the level of details code and just pass 5 to the cyl_model::get(n) method. This will return the vertices of a cube. Of course a cube isn't what was asked for but some extra work is done. The tip of the cone is calculated by passing a vector (2,0,0) to the mct.project method. This point is the middle of the base, moved two units along the x-axis. Inside the projection loop every second vertex is replaced by the tip vertex, which when rendered makes the faces of the shape meet at the tip. This results in a cone/pyramid/tetrahedron depending on the number of faces required. For tetrahedron simply use the 4 vertices rather than 5 for a pyramid.

  As for the actual rendering by openGL, the array of vertices is used to draw GL_TRIANGLE_STRIP geometries. This is a pretty flexible and efficient way to do it, as GL_QUAD_STRIP geometries require some extra vertex calculations. In the case of a cone the triangle strip vertecies go 

  v1 |\   |\v3 
      | \  | \ 
      |  \ |  \ 
  v0 |   \|v2\| 

  etc (hopefully this crude ascii diagram comes out ok) 
  OpenGl fills in both sides of the triangle ie v0,v1,v2 and v1,v2,v3 are filled when drawn. 
  Of course when drawing a cone/pyramid/tetrahedron there is obvious redundancy as v1==v3==v5 etc. A more efficient method would be to use GL_TRIANGLE_FAN which has a central point for all triangles and the vertices for the base points eg tip would be v0 and v1, v2, v3 etc would be the base points. The triangles would the be (v0,v1,v2), (v0,v2,v3) etc Using this method would cut the calculating/drawing time for  cones etc in half.

  The final rendering is for the base. This is done using the GL_POLYGON geometry which fills in a shape enclosed by points v0,v2,v4 etc ie the triangle base points.

  The frustum was a little more frustrating to get right. In the end I made a copy of cylmodel.h and called it frustmodel.h. I then modifed the method that returns the vertices of the cylinder to set the top vertices at half the radius of the bottom ones. Trying to do this inside the frustum projection loop in frustum.cpp caused some bizzare results.

  I had hoped to avoid making almost identical copies of other modules as this adds to code bloat, but for the moment this will do.

  I haven't added any new attributes to the shapes, instead relying on the ones provided. That means that the size of the base of the pyramid/tetrahedon uses the radius attribute and is the distance from the mid point of the base to the corner vertex. For the frustum the radius at the top is fixed to be half the radius of the base.

  BTW As I remarked in my first post frustum is not a good name for this shape, at least internally, as it causes compile errors due to the clash with the frustum methods used to handle the camera in openGl. I've called it frustm in the short term but does anyone have a better suggestion?

    

Re: [Visualpython-users] Further adventures with primitives

[Jonathan B. <jbr...@ea...>]

On Wed, 2003-02-19 at 17:48, Press, Shaun wrote:
> I have managed to add Tetrahedron, Pyramid and Frustum to the primitive
> shapes in my copy of Visual Python.
> The terahedron and pyramid a pretty simple to do as they are a specific form
> of the cone shape. 

--snip--

> The frustum was a little more frustrating to get right. In the end I made a
> copy of cylmodel.h and called it frustmodel.h. I then modifed the method
> that returns the vertices of the cylinder to set the top vertices at half
> the radius of the bottom ones. Trying to do this inside the frustum
> projection loop in frustum.cpp caused some bizzare results.
> I had hoped to avoid making almost identical copies of other modules as this
> adds to code bloat, but for the moment this will do.

If they are nearly identical, is it possible to create a conic_base
class, and implement the cone-like shapes as specializations of the base
class?  That would cut down on the redundancy.  It would also be an
excellent modification to the library.

> I haven't added any new attributes to the shapes, instead relying on the
> ones provided. That means that the size of the base of the
> pyramid/tetrahedon uses the radius attribute and is the distance from the
> mid point of the base to the corner vertex. For the frustum the radius at
> the top is fixed to be half the radius of the base.

So you are already inheriting from axialSymettry?  Maybe conic_base can
have a protected member function (or several) that represents the shared
code between the different models.  Then, pyramid, tetrahedron,
cylinder, cone, and frustm would only implement the varient code with
glRender, calling the private functions of the base class for the common
stuff.  Something like a base_verticies function or the like.  Also, if
a minor_radius property is useful to frustm, we can add it as a property
of conic_base.  However, adding extra properties is clumsy right now. 
Moving to Boost will make extensions like this much easier.  You might
want to go ahead and implement it with a temporarily fixed value for
now.

> BTW As I remarked in my first post frustum is not a good name for this
> shape, at least internally, as it causes compile errors due to the clash
> with the frustum methods used to handle the camera in openGl. I've called it
> frustm in the short term but does anyone have a better suggestion?

As part of the move to Boost, I plan to place all of the classes and
free functions within cvisual into namespace cvisual:: (or maybe just
visual::).  Long term, this should prevent clashes with the OpenGL and
other function namespaces.

-Jonathan

[Visualpython-users] Further adventures with primitives

[Press, S. <sha...@ai...>]

I have managed to add Tetrahedron, Pyramid and Frustum to the primitive
shapes in my copy of Visual Python.
The terahedron and pyramid a pretty simple to do as they are a specific form
of the cone shape. 
In the cone.cpp file there is a section devoted to calculating the level of
detail for the shape. The idea is that closer shapes are drawn with a lot of
detail while distant shapes require less. Depending on the size and location
of the cone it can be drawn with 20 panels down to 5 panels. The number of
panels is passed to the cyl_model object which returns the vertices required
to draw the shape.
To draw a pyramid, simply drop the level of details code and just pass 5 to
the cyl_model::get(n) method. This will return the vertices of a cube. Of
course a cube isn't what was asked for but some extra work is done. The tip
of the cone is calculated by passing a vector (2,0,0) to the mct.project
method. This point is the middle of the base, moved two units along the
x-axis. Inside the projection loop every second vertex is replaced by the
tip vertex, which when rendered makes the faces of the shape meet at the
tip. This results in a cone/pyramid/tetrahedron depending on the number of
faces required. For tetrahedron simply use the 4 vertices rather than 5 for
a pyramid.
As for the actual rendering by openGL, the array of vertices is used to draw
GL_TRIANGLE_STRIP geometries. This is a pretty flexible and efficient way to
do it, as GL_QUAD_STRIP geometries require some extra vertex calculations.
In the case of a cone the triangle strip vertecies go 

v1 |\   |\v3
    | \  | \
    |  \ |  \
v0 |   \|v2\|

etc (hopefully this crude ascii diagram comes out ok)
OpenGl fills in both sides of the triangle ie v0,v1,v2 and v1,v2,v3 are
filled when drawn.
Of course when drawing a cone/pyramid/tetrahedron there is obvious
redundancy as v1==v3==v5 etc. A more efficient method would be to use
GL_TRIANGLE_FAN which has a central point for all triangles and the vertices
for the base points eg tip would be v0 and v1, v2, v3 etc would be the base
points. The triangles would the be (v0,v1,v2), (v0,v2,v3) etc Using this
method would cut the calculating/drawing time for  cones etc in half.
The final rendering is for the base. This is done using the GL_POLYGON
geometry which fills in a shape enclosed by points v0,v2,v4 etc ie the
triangle base points.

The frustum was a little more frustrating to get right. In the end I made a
copy of cylmodel.h and called it frustmodel.h. I then modifed the method
that returns the vertices of the cylinder to set the top vertices at half
the radius of the bottom ones. Trying to do this inside the frustum
projection loop in frustum.cpp caused some bizzare results.
I had hoped to avoid making almost identical copies of other modules as this
adds to code bloat, but for the moment this will do.

I haven't added any new attributes to the shapes, instead relying on the
ones provided. That means that the size of the base of the
pyramid/tetrahedon uses the radius attribute and is the distance from the
mid point of the base to the corner vertex. For the frustum the radius at
the top is fixed to be half the radius of the base.

BTW As I remarked in my first post frustum is not a good name for this
shape, at least internally, as it causes compile errors due to the clash
with the frustum methods used to handle the camera in openGl. I've called it
frustm in the short term but does anyone have a better suggestion?
  

Re: [Visualpython-users] Installer issues

[Bruce S. <bas...@un...>]

It's true that I don't ever use those other wonderful tools, either. But
maybe I should? You're right that none of that is appropriate for my
students.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>;
<vis...@li...>
Sent: Wednesday, February 19, 2003 11:56 AM
Subject: Re: [Visualpython-users] Installer issues


> [Bruce]
> > I should indeed take a look at ScITE. I vaguely remember bouncing off it
a
> > long time ago, but I now forget why. Maybe it was Windows-only at that
> time?
>
> I am glad.
>
> Because after pledging not to hardsell it, I was going to relent - having
> thought about it some more - and pitch it a little more.
>
> I will discuss it as to PyGeo.
>
> What I think is important about the environment, as customized, is not
only
> what it has, but what it doesn't have.  I have been doing Python for some
> time, and have never used a class browser, formal debugger, etc.  Simply
was
> inconsistent with how I approached the learning curve, and what felt
natural
> to me specifically as it concerns Python.
>
> Having superfluous features in the environment I think makes it feel
> foreign.  And one is not sure as to what features one should or should not
> be exploring.
>
> The features you describe you are focusing one for your students, are the
> same features I have wanted and accessed as a user -  and essentially only
> those.  And I have gotten pretty far with them.
>
> A very focused environment, uncluttered is the ideal, IMO.  And with some
> customization - more taking away unneeded features (e.g. the ability to
> syntax highlight REXX), than adding new ones  - one can be left with very
> much that.
>
> And in fact this kind of customization as an environment for specialized
> needs is exactly the niche ScITE is designed to fill.  And I think that is
> also important.  It is using ScITE/scintilla exactly as it designed to be
> used - not hacking at it.
>
> Art
>
>
>

Re: [Visualpython-users] Installer issues

[Arthur <ajs...@op...>]

[Bruce]
> I should indeed take a look at ScITE. I vaguely remember bouncing off it a
> long time ago, but I now forget why. Maybe it was Windows-only at that
time?

I am glad.

Because after pledging not to hardsell it, I was going to relent - having
thought about it some more - and pitch it a little more.

I will discuss it as to PyGeo.

What I think is important about the environment, as customized, is not only
what it has, but what it doesn't have.  I have been doing Python for some
time, and have never used a class browser, formal debugger, etc.  Simply was
inconsistent with how I approached the learning curve, and what felt natural
to me specifically as it concerns Python.

Having superfluous features in the environment I think makes it feel
foreign.  And one is not sure as to what features one should or should not
be exploring.

The features you describe you are focusing one for your students, are the
same features I have wanted and accessed as a user -  and essentially only
those.  And I have gotten pretty far with them.

A very focused environment, uncluttered is the ideal, IMO.  And with some
customization - more taking away unneeded features (e.g. the ability to
syntax highlight REXX), than adding new ones  - one can be left with very
much that.

And in fact this kind of customization as an environment for specialized
needs is exactly the niche ScITE is designed to fill.  And I think that is
also important.  It is using ScITE/scintilla exactly as it designed to be
used - not hacking at it.

Art

RE: [Visualpython-users] Installer issues

[jon s. <js...@so...>]

I picked up ScITE just a few weeks ago and it has quickly become my default
programming environment.
Its really first rate.
When I need a shell, I open another window and run python or idle.


------------------------------------------
Jonathan Schull, Ph.D.
Sc...@Di... <mailto:Sc...@Di...>
http://radio.weblogs.com/0104369/stories/2002/09/24/JonathanSchullOnOnePage.
html
<http://radio.weblogs.com/0104369/stories/2002/09/24/JonathanSchullOnOnePage
.html>
36 Brunswick St., Rochester NY 14607
585-738-6696 cell and v-mail
585-242-9497 landline
978-246-0487 fax
------------------------------------------



> -----Original Message-----
> From: vis...@li...
> [mailto:vis...@li...]On Behalf Of
> Bruce Sherwood
> Sent: Wednesday, February 19, 2003 9:33 AM
> To: vis...@li...
> Subject: Re: [Visualpython-users] Installer issues
>
>
> Sounds interesting indeed, Arthur. Thanks for the overview. It doesn't
> matter that the Mac is out in the cold, I suspect. If ScITE runs
> on Linux it
> should run on Mac OSX + Apple X11, which is also the only
> environment where
> idlefork has a chance of running on a Mac.
>
> Indeed, the terminate program issues in idlefork are being addressed. An
> advantage of the separate process is that if something goes wrong in the
> run, the editing environment is still up.
>
> Another feature important for my uses is the automatic save that
> is done on
> a run, which protects students from losing work. Is that a possibility in
> ScITE?
>
> I don't care at all about the interactive capability and I don't have my
> students use that facility at all. For novices the Python shell is a bad
> environment, because it undercuts the notion of a program as a thing to be
> executed, and edit and import history in the shell is very murky. In
> contrast to what some others think, to me the shell is useful only for
> experts. And when there is one-key rapid turnaround as there is
> in idlefork
> (and I gather in ScITE) the need for a shell is extremely small.
>
> I should indeed take a look at ScITE. I vaguely remember bouncing off it a
> long time ago, but I now forget why. Maybe it was Windows-only at
> that time?
>
> Bruce Sherwood
>
> ----- Original Message -----
> From: "Arthur" <ajs...@op...>
> To: "Bruce Sherwood" <bas...@un...>;
> <vis...@li...>
> Sent: Tuesday, February 18, 2003 10:09 PM
> Subject: Re: [Visualpython-users] Installer issues
>
>
> > > I had the vague notion that ScITE is Windows-specific --
> right or wrong?
> >
> > Windows and Linux GTK.   Mac out in the cold, once again.
> >
> > >
> > > Highlighting Visual keywords might be nice, but it is really the high
> > > interactivity of idlefork that matters to me. Anything that offers
> one-key
> > > edit/run cycles is what I want, and what I want for my
> students. Is that
> > > possible with ScITE?
> >
> > Absolutely.  Out of the box, it works with about 25 languages.
> One thing
> I
> > do in my cusotmization is narrow it down to 1 - Python.
> >
> > F5 is "Go" - run Python against the current script.
> > Cntrl 1 runs a Python syntax check.
> >
> > No "seperate process" issues as in the standard IDLE, that as per your
> > posting - confirmed by own own testing of alpha2 - have not
> been corrected
> > yet in the merged IDLE. (Though I am confident it will be.)
> >
> > And the opportunity to go much further down the road toward VPython
> specific
> > customization beyond simple keyword syntax highlighting -  like VPython
> word
> > completion (cntrl enter), hints, etc.
> >
> > A good counter argument is the importance of IDLE's inactive
> prompt. Which
> I
> > happen to believe *is* important. I happen to use IDLE only for
> that.  And
> > have never found it strange to use it only for that and
> something else for
> > editing.   But there is an argument to be made that an "all in one" tool
> has
> > its advantages.
> >
> > PyGeo does not work at the interactive prompt the way VPython can.  So
> > perhaps I am prejudiced by that, and that IDLE does make more sense for
> > VPython than it might for PyGeo.
> >
> > Anyway, more offering to lend assistance if you think the concept has
> > merit - not selling it too heavily.
> >
> > Art
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] Installer issues

[Bruce S. <bas...@un...>]

Sounds interesting indeed, Arthur. Thanks for the overview. It doesn't
matter that the Mac is out in the cold, I suspect. If ScITE runs on Linux it
should run on Mac OSX + Apple X11, which is also the only environment where
idlefork has a chance of running on a Mac.

Indeed, the terminate program issues in idlefork are being addressed. An
advantage of the separate process is that if something goes wrong in the
run, the editing environment is still up.

Another feature important for my uses is the automatic save that is done on
a run, which protects students from losing work. Is that a possibility in
ScITE?

I don't care at all about the interactive capability and I don't have my
students use that facility at all. For novices the Python shell is a bad
environment, because it undercuts the notion of a program as a thing to be
executed, and edit and import history in the shell is very murky. In
contrast to what some others think, to me the shell is useful only for
experts. And when there is one-key rapid turnaround as there is in idlefork
(and I gather in ScITE) the need for a shell is extremely small.

I should indeed take a look at ScITE. I vaguely remember bouncing off it a
long time ago, but I now forget why. Maybe it was Windows-only at that time?

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>;
<vis...@li...>
Sent: Tuesday, February 18, 2003 10:09 PM
Subject: Re: [Visualpython-users] Installer issues


> > I had the vague notion that ScITE is Windows-specific -- right or wrong?
>
> Windows and Linux GTK.   Mac out in the cold, once again.
>
> >
> > Highlighting Visual keywords might be nice, but it is really the high
> > interactivity of idlefork that matters to me. Anything that offers
one-key
> > edit/run cycles is what I want, and what I want for my students. Is that
> > possible with ScITE?
>
> Absolutely.  Out of the box, it works with about 25 languages.  One thing
I
> do in my cusotmization is narrow it down to 1 - Python.
>
> F5 is "Go" - run Python against the current script.
> Cntrl 1 runs a Python syntax check.
>
> No "seperate process" issues as in the standard IDLE, that as per your
> posting - confirmed by own own testing of alpha2 - have not been corrected
> yet in the merged IDLE. (Though I am confident it will be.)
>
> And the opportunity to go much further down the road toward VPython
specific
> customization beyond simple keyword syntax highlighting -  like VPython
word
> completion (cntrl enter), hints, etc.
>
> A good counter argument is the importance of IDLE's inactive prompt. Which
I
> happen to believe *is* important. I happen to use IDLE only for that.  And
> have never found it strange to use it only for that and something else for
> editing.   But there is an argument to be made that an "all in one" tool
has
> its advantages.
>
> PyGeo does not work at the interactive prompt the way VPython can.  So
> perhaps I am prejudiced by that, and that IDLE does make more sense for
> VPython than it might for PyGeo.
>
> Anyway, more offering to lend assistance if you think the concept has
> merit - not selling it too heavily.
>
> Art

Re: [Visualpython-users] Installer issues

[Arthur <ajs...@op...>]

> I had the vague notion that ScITE is Windows-specific -- right or wrong?

Windows and Linux GTK.   Mac out in the cold, once again.

>
> Highlighting Visual keywords might be nice, but it is really the high
> interactivity of idlefork that matters to me. Anything that offers one-key
> edit/run cycles is what I want, and what I want for my students. Is that
> possible with ScITE?

Absolutely.  Out of the box, it works with about 25 languages.  One thing I
do in my cusotmization is narrow it down to 1 - Python.

F5 is "Go" - run Python against the current script.
Cntrl 1 runs a Python syntax check.

No "seperate process" issues as in the standard IDLE, that as per your
posting - confirmed by own own testing of alpha2 - have not been corrected
yet in the merged IDLE. (Though I am confident it will be.)

And the opportunity to go much further down the road toward VPython specific
customization beyond simple keyword syntax highlighting -  like VPython word
completion (cntrl enter), hints, etc.

A good counter argument is the importance of IDLE's inactive prompt. Which I
happen to believe *is* important. I happen to use IDLE only for that.  And
have never found it strange to use it only for that and something else for
editing.   But there is an argument to be made that an "all in one" tool has
its advantages.

PyGeo does not work at the interactive prompt the way VPython can.  So
perhaps I am prejudiced by that, and that IDLE does make more sense for
VPython than it might for PyGeo.

Anyway, more offering to lend assistance if you think the concept has
merit - not selling it too heavily.

Art

Re: [Visualpython-users] Installer issues

[Bruce S. <bas...@un...>]

To facilitate people trying out Arthur's ideas, I've put his distutils
machinery in the "contributed" section of http://vpython.org as a
pseudo-permanent place to find the machinery. There are two items there,
both with minor revisions by me (and labeled as such so that errors can be
ascribed to me rather than to Arthur!).

One of the files is just the setup.py program alone, and the other is a 3 MB
zip file containing all of the pieces other than Numeric (includes
idlefork). In particular, I added some stuff to provide the next/back/up
icons needed by the Visual docs, which they used to get from the Python doc
icons when the Visual docs were in the Python docs folder.

Arthur, as you come up with revisions or new ideas I'll be happy to post
them in the contributed section. I was stimulated to post things by a
request from a user for your files, due I think to the fleeting nature of
attachments (or their nonexistence for those readers who get the news as a
daily digest). On the other hand, you have your own web site and might
consider if you prefer putting test versions there. Whatever you like.

Bruce Sherwood