Mailman 3 May 2006 - Edu-sig

Panda3D + Blender on Edubuntu
by kirby urner 10 May '06

10 May '06

Per this blog post, I've got Panda3D running on Edubuntu: http://controlroom.blogspot.com/2006/05/edubuntu.html Blender was already a part of the default installation. However, on this Compaq Deskpro, I'm noticing a lot of graphical anomolies around menu highlighting and other controls. Blender, you may recall, distinguishes itself by defining all controlling widgets (of which it has many) internally to the OpenGL interface, i.e. there's no sense of a frame different from the canvas (Panda3D by contrast, uses the Tk-based Python Megawidgets classes for controls). It'd be useful to have Blender stay in the picture, from a Panda-user viewpoint, as from what I've gleaned from the docs, Blender is one of the best platforms for creating new action figures for Panda. There's a file format they have in common, given an included conversion utility. Kirby

2 2

Errors in Wikipedia entry for IronPython?
by kirby urner 10 May '06

10 May '06

I have a problem with this example code: from BookService import BookDictionary booksWrittenByBookerPrizeWinners = [] for book in BookDictionary.GetAllBooks: if "Booker Prize" in book.Author.MajorAwards: booksWrittenByBookerPrizeWinners.append(book.Title) booksWrittenByBookerPrizeWinners First, the variable names seem intentionally ugly, but I'm not going to worry about that. What really bugs me is BookDictionary.GetAllBooks without making it callable. The prefixing verb Get would imply a function, and Python distinguishes itself from Ruby (per Martelli) by making a sharp distinction between a function *named* and a function *called*. Perhaps its just an unfortunate naming issue, i.e. GetAllBooks is really to be thought of as an iterable, not a function call. Under the hood, there might be some property, i.e. if it has to consult a database (whatever BookService does). But in that case, I'd really prefer a function with no arguments, a callable in other words. Anyway, as you can see, I'm unhappy with this code. Plus there's a clear typo in the next sentence: "In this case, assume that the .NET framework implements a class, BookDictionary, in a module called BookService, and publishes an interface into which IronPython scripts can be sent and exectuted." I've edited Wikipedia before, but hesitate to dive in on this one without more seasoning (comments?). Kirby

4 6

More on Panda3D
by kirby urner 10 May '06

10 May '06

So I think the first thing will be to write a new subclass of writer, as I've already done for VRML, VRML2, EIG, POV-Ray, and Live3D.[1] There's already an Egg API that will allow me to avoid low-level bricking in with strings (no direct eggfile.write('stuff')). Here's what it looks like (from the documentation [2]): def makeWedge(angleDegrees = 360, numSteps = 16): data = EggData() vp = EggVertexPool('fan') data.addChild(vp) poly = EggPolygon() data.addChild(poly) v = EggVertex() v.setPos(Point3D(0, 0, 0)) poly.addVertex(vp.addVertex(v)) angleRadians = deg2Rad(angleDegrees) for i in range(numSteps + 1): a = angleRadians * i / numSteps y = math.sin(a) x = math.cos(a) v = EggVertex() v.setPos(Point3D(x, 0, y)) poly.addVertex(vp.addVertex(v)) # To write the egg file to disk, use this: data.writeEgg(Filename("wedge.egg")) # To load the egg file and render it immediately, use this: node = loadEggData(data) return NodePath(node) So I'll just suck up a Polyhedron from my rbf.py, spoon feed the vertices and polygons via the Egg API, then load the egg in a Panda scenegraph for display. I should be getting my initial results shortly. I'll publish some source code. Query: could we reimplement the whole Elastic Interval Geometry thing inside of Panda3D. At this point, I see no reason why not. If we treated the intervals as changing-size Bones at runtime, I bet we could get some interesting Creatures. I recently sent a heads-up to Gerald (originator of EIG, inspired by Kenneth Snelson [3]), regarding my appreciative mention of his work a few times in my LKL talk.[4] Kirby [1] http://www.4dsolutions.net/ocn/python/povray.html (example POV writer) [2] http://panda3d.etc.cmu.edu/wiki/index.php/Writing_3D_Models_out_to_Disk [3] Kenneth Snelson: http://www.kennethsnelson.net/ http://www.grunch.net/snelson/ http://worldgame.blogspot.com/2006/05/barrel-tower.html [4] http://bfi.org/pythonicmathematics

3 5

PySqueak: "Self" as the source of many ideas in Squeak
by Paul D. Fernhout 08 May '06

08 May '06

In continuing to contemplate what are the essential ideas of Squeak in terms of using them in an educational environment resting on Python, I decide to revisit some of Squeaks' roots. Many of these are in "Self", a prototype based programming language (and IMHO a constructivist one too). The main page for Self: http://research.sun.com/self/language.html I had read of Self, and met one of the key people once at a conference, and I was inspired by many ideas from those interactions, as well as work with NewtonScript (the native programming language of the Newton, also inspired by Self), but I had never seen the Self system in action. It turns out there is a 15 minute or so video on Self, linked to from here: http://www.merlintec.com:8080/Self Kirby, you mentioned the persuasive power of videos in another context, and I suggest viewing the high definition version of the videos there would be useful in seeing how a graphical environment for students could approach the immediate feedback of the command line, especially with most of today's students who are presumably already "point and click" mouse literate. The key principles mentioned in movie for Self's design are based on ideas from the physical world, and are summarized as: * Directness (everything is potentially visible and touchable) * Uniformity (you can consistently change everything) * Modelessness (always running, so no editing/running distinction) Self also demonstrates multiple people doing activities together in one (2D) environment. [BTW Neometron's Learningworks was about 3D communities using Smalltalk and was deployed a decade ago, which shows some other roots of Squeak/Croquet roots here.] From the paper here (first seen in a link below): http://research.sun.com/self/papers/programming-as-experience.html "Finally, in designing Self, we have learned one lesson by making mistakes: examples can persuade the designer to include additional features which later turn out to produce incomprehensible behavior in unforeseen circumstances. This might be called the language designer's trap. Minimalism, simplicity and consistency are better guides. They benefit every programmer, not just the ones who need advanced features. We suspect that many of today's object-oriented languages could profit by dropping features." In my own work in Smalltalk development, knowing that Self existed, and having experience with prototypes in Newtonscript, I was often frustrated by Smalltalk not having Self's elegance. And I think many of the issues Self addresses (particularly eliminating a class side / instance side distinction) are very important to making programming easy to get into, as well as keeping it more fun. In the movie near the end they make the distinction between telling objects what to do (writing code) and just banging them around into position (which Self's GUI helps support, in addition to programming). By building in "Morphic" (the Self GUI paradigm) Squeak tries to get this Self leverage, but I think, given Squeak's use of Smalltalk (which has classes), Morphic always seemed to me to be rather inelegantly bolted on (this is not a slam at the developers, just an inherent problem of a class based programming system trying to work with dynamic constructivist material). One of the things I have always liked about Python is its use of dictionaries for storing values in instance objects. This is computationally inefficient compared to looking up things by position in an array as C or Smalltalk do, but it is more flexible in terms of taking any specific instance and adding more data fields to it, so it is efficient in a human-oriented way and can lend itself somewhat to this sort of prototype based work. So, another idea when thinking about PySqueak is: how can Python better support prototype based development? As well as: how can what we have with Python2.4/Jython2.1 now be used to do that in interesting ways? Now this certainly isn't a new idea, see for example these discussions: http://lists.canonical.org/pipermail/kragen-hacks/2000-September/000264.html http://www.thescripts.com/forum/thread30832.html http://www.prothon.org/ http://www.google.com/search?hl=en&q=Prothon or Prothon's apparent successor, PyCS: http://www.prothon.org/pipermail/prothon-user/2004-August/003269.html http://pycs.org [However, the Prothon and Pycs links seem to be down right now, I read them through the Google cache just now as this project is new to me, perhaps an indication the project is ended?] These three key principles above, relating to a dynamic nature of the Self system, are probably needed to support any constructivist approach to software creation and use. But notice how they are the opposite of the principles behind something like C++ or other statically typed languages, which focus on data hiding, specialized interfaces, and set-in-stone compiled applications. Or as Alan Kay put it: http://www.smalltalk.org/articles/article_20040731a.html "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." This statically compiled approach culminates brilliantly in something like OCaml, http://en.wikipedia.org/wiki/Ocaml since if you want types with the least pain and syntactic clutter, OCaml can infer many of them for you. C++ or OCaml are pretty much about specifying everything in advance and locking down the system, assuming it will never change at runtime, to get the most out of memory and computer cycles focused on a narrowly defined fixed problem. This is not to say C++ or OCaml can't be used to make open systems (say, by defining a Smalltalk or Common Lisp or Python virtual machine in some way), but openness at runtime is clearly not what those languages are about. Now there are places for that sort of efficient and effective closedness, but it is a very different philosophy from creating open systems like Self, or Squeak. Python clearly potentially can be used in a Self-like or Squeak-like open way, and some core development tools rely on that, but in practice most of the time Python seems not to be used that way. Perhaps this is due to, as a speculation, that most people come to Python from a C/C++ background, which is why they liked the "f(a, b, c)"-style syntax as opposed to keywords (Smalltalk) or lots of parens (Lisp). Clearly, if most Python development had a long legacy of being oriented around that sort of open and dynamic constructivist principle, with the size of the Python community and its technical skill, we would probably already have a dynamic environment better than Squeak for all the things Squeak does. :-) So, as I reflect on this, the roots of not having Squeak on Python *already* may have more to do with Python community culture and history and mindset than Python limitations. One can of course hope that a successful PySqueak project in that direction will prove to be a "better mouse trap" and the Python community will flock to it, although that may not be realistic, speculating about the Prothon and PyCS sites being down. And as it pointed out here by Sjoerd Visscher: http://lambda-the-ultimate.org/classic/message11653.html "Flexibility is nice, but useless when the libraries are implemented in one programming style. That programming style will be the only natural style of the language." I want to underscore and emphasize this difference between these two philosophies of programming language design, because it seems that the directions proposed for mainstream Python, if anything: http://www.artima.com/weblogs/viewpost.jsp?thread=86641 have been in directly the opposite direction to Self, to a Python with static typing (including RPython). So, frankly, there very well simply be an insurmountable cultural barrier here. And there is nothing wrong with that -- static types are a valid way to generate code that efficiently uses memory and computation to solve a specific well defined purpose (like a well specified Python VM or any other well specified problem). However such a focus will remain at odds as far as I can see with the notion of a living and evolving population of objects system, which is at the core of a constructivist vision of education or programming. Hopefully a diverse Python community could productively use both paradigms in language variants, so an RPython for certain specific tasks, and a proto-Python for everything else (or at least, some forms of educational use)? Unfortunately, the more one sees a path diverging from Python as it is commonly defined (towards, say, a Prothon? direction) the quicker interest in a PySqueak will evaporate, if it has not already. :-) Because then it is just some quirky side variant. Still, there are niches in the Python community, like with Jython, where a slight change in direction may be more feasible, at the very least as a proving ground of sorts (Jython sometimes has its own identity crisis of whether to track CPython or strike out on its own, usually resolved in favor of tracking.). So, again, in thinking what Squeak on Python might mean, as opposed to aping Squeak, Python could build on its strength of using dictionaries internally and support a more prototype based environment like what Prothon or PyCS tried to move towards, making it more similar to Self than the derivative (in that sense) Squeak (which still uses classes). Coupled with a self-like GUI, I think that would better support constructivist educational needs. Of course, then one can ask, is this just reinventing the Self wheel and is that worth doing (to potentially gain Python community advantages, which might be questionable if the approach deviated in any significant way from mainstream Python)? It would seem clearer that the most leverage would be gained if Python (or Jython) as it is now (or with at best trivial changes) could be used to support Self-like features, and thus realize some of the constructivist ideals also embodied and further popularized in Squeak. Or, as Ian Bicking points out here in "Initial thoughts on Prothon": http://www.artima.com/forums/flat.jsp?forum=122&thread=41588 "[After mentioing Prothon syntax changes from Python...] I actually wonder to what degree prototypes could be implemented in Python with metaclasses. While some of the syntax would currently be crufy with Python (e.g., you'd have to create a function, then assign the function to an object), that's kind of a separate issue. The bpython metaclasses asic object model in Python feels like it should be replaceable, especially since we already have both new and old style classes. I think it's still a bit hard to think about these with the syntax getting in the way or otherwise being distracting, but feel like the potential is in there somewhere. If it could be hacked onto Python instead of developed entirely separately from Python, it could make Prothon much more interesting from the perspective of practical programming. Ultimately it would probably have to be like Stackless -- a patch against Python implementing some necessary changes to syntax. But that's a more viable development effort, and one that's more likely to percolate ideas into the main Python interpreter." I think that Ian's suggestion is the most sensible strategy for proceeding in that direction and continuing to maintain community interest in a PySqueak inclined towards Self-like prototypes and a related GUI for constructivist educational use (and other general use as well). And if metaclasses turn out to not be the best approach, still anything simple which preserves the Python syntax while giving the new features (say, having all prototypes inherit from a common class which overrides __getattr__ and __setattr__ to simply look into the instance to find data and behavior?) Ian, any recent thoughts on that? I would speculate that part of the general interest of the world in HyperCard was that it to some extent worked in a direct-manipulation protype-based way. Perhaps that similarity resonates with you as well? --Paul Fernhout

4 18

Re: [Edu-sig] Petty Issue
by Laura Creighton 08 May '06

08 May '06

Fredrik Lundh's introduction to the python standard library comes with a CD. http://www.oreilly.com/catalog/pythonsl/ It is a little dated, being from 2001, but since you are trying to get around a rule .... Laura In a message of Fri, 05 May 2006 12:14:42 MDT, Chuck Allison writes: >Hello edu-sig, > > I'm really sorry to waste your time, but this is the only place I > know to go to get a quick answer. > > I have mentioned here before that I am teaching intermediate Python > at Symantec in June. Since they merged with another company last > year, they have some new red tape that disallows one-person > companies like myself to do business with them (it seems I don't > have enough liability insurance - true - I have none!). To get > around the system, I have to, among other things, "sell" them a > Python book with a CD in it. (Don't ask me why - this is bean > counting mentality at its best). Anyway, I can't find a worthy book > with a CD. Most are out of date or too simple. (I wish Martelli's > books had CDs!) Even John Zelle's excellent book, with has an > accompanying CD, is too basic for our needs (it's an ideal CS1 book, > of course). So: do you know of a book with a CD that is > intermediate, or... do you know of a stand-alone CD product that > covers some meaty Python? > > Thanks, and again, sorry to interrupt more profitable discussion. > >-- >Best regards, > -- Chuck Allison > > >_______________________________________________ >Edu-sig mailing list >Edu-sig(a)python.org >http://mail.python.org/mailman/listinfo/edu-sig

1 0

PySqueak: more on the cultural divide among paradigms
by Paul D. Fernhout 08 May '06

08 May '06

In discussing with my wife some of the ideas of my previous post (on "Self" as the source of many ideas in Squeak) a greater clarity has emerged for me on a programming paradigm issue (in large part due to her input related to her own related experiences with some people resisting prototype-style approaches in application design and others embracing them). Our best Physics and Psychology (taken together, as interpreted by me :-) right now suggests the universe is a sea of subatomic particles in relation to each other in complex ways (determining how those relations change in the future). "Objects" (and Platonic "classes" for objects) are fictions our mind uses to try to make sense of all that complexity. So too, the notions of "class" and "objects" are fictions we programmers invent to get a handle on the raw sea bits of computer memory as they change over time from computational rules applied to them. But they are also fictions we try to apply to the real world when we write accounting systems as well. And they often break down, as illustrated in depth in the late William Kent's book _Data and Reality_. http://www.bkent.net/ We often use the term "Abstraction" to point at this problem (or even cover it up), but that doesn't capture the whole notion, since it that word is often used with the intent that there is one abstraction, as opposed to the notion that the abstraction is just one possibility we chose because it was useful at the moment for specific human goals. So, as far as computer language paradigms go (and teaching people about them), there are then two sets of issues. One relates to modeling the "real world" (because computers are often used to do that) and one relates to getting a handle on "telling the computer what to do" (because you can't do the first without the second). These are somewhat related issues (after all, we are in some sense building models of the real world even when they are about programs running on VMs), though they are still distinct issues in my mind. In terms of increasing levels of computing machinery, we have something like: Machine -> Assembly -> Functions -> Classes -> Prototypes -> Relations In terms of world modeling done by a human mind about the world, we have somewhat the reverse, in: Classes -> Objects(Prototypes) -> Relations -> Reality [Kent outlines an idea for a relation programming system called ROSE or STAR, and I have worked towards something similar in my Pointrel ideas, but the common metaphor is an "entity-relational" model of data). http://en.wikipedia.org/wiki/Entity-relationship_model There of course may be other levels, or even a branching tree, and one might organize these differently, if say, you build a Smalltalk on top of Self, so this is all a big simplification to get one started thinking about this issue. Simplifying greatly even further, it has been the history of computing to move away from the machine to what is often called "higher levels" of abstraction. While it has been the history of (western) Physics to drill ever deeper into the notion of perceptions of reality starting from the perception of Platonic ideals (or classes). Integrating perceptions across these levels is not that easy. Forth does is somewhat for computing though IMHO, a tiny language that can easily be extended to support various paradigms. And here is the cultural divide: when a person is at one level of understanding of all this, it is very hard to convince them of the value or even feasibility of the other levels they may have no experience with. This notion is inspired somewhat by my reading "Future Shock Levels" by Eliezer S. Yudkowsky: http://yudkowsky.net/sing/shocklevels.html "The use of this measure is that it's hard to introduce anyone to an idea more than one Shock Level above - and Shock Levels measure what you accept calmly, not what you know about.") But clearly thinking about levels of understanding is a common teacher-type curriculum design thing to do. And, these other levels may (at least initially) impose discouragingly large cognitive and computational burdens to try out. So, it is just very hard to get someone used to thinking hierarchically about classes of birds that such distinctions are somewhat arbitrary if you truly understand taxonomic issues. Or further, that the very notion of a specific individual bird is a convenient fiction the mind invented for surviving in and making sense of the universe (instead of modeling the bird and its environment at a horrendously detailed quantum level, plus modeling the minds goals in such a way if such was possible). Or, looking at this issue from programming point of view, one can implement Classes in C, but they seem slower for the standard problems C is used to solve. Or one can implement Morphic and prototypes in Smalltalk, but they feel like a kludgey add on. Or one can implement relations with prototypes, but they will certainl at first seem inelegant and slow. [As an aside, I have a prototype of a Smalltalk-like VMs in C and Python that uses a entity-relational model of triads of data for their cores; inefficient yes, but elegant IMHO, and it turns out easy to reach into remotely, or have one simple unified browser to study system state, or be able to imagine the system running backwards for debugging.] There may also even be a personality effects related to feelings about authoritarianism and control, or where one falls on the "meshwork vs. hierarchy" preference landscape. http://www.t0.or.at/delanda/meshwork.htm For a (personal example), having some Dutch roots myself, yet being an outsider to Holland, I can see in that culture a paradox of both pride and success in being a permissive society, while at the same time pride and success in being a society influenced by some fairly strict religious ideals (including compassion) as well as pressures towards conformist behaviors. (This is true of all societies to some extent, but walking around Amsterdam is a very graphic example of this. :-) Or as is said in the intro to "The Portable Henry James" edited by John Auchard (my wife is reading it; I just glanced at it. :-): http://www.amazon.com/gp/product/0142437670/103-1147318-5179869?v=glance&n=… "The divide between a culture of individual freedom and a culture of tradition -- H.G. Wells identified communities of will, and communities of faith and obedience -- is a great divide, and it is a persistent and deep one in Henry James, as it should be, even though many Americans in the novels scarcely seem to notice. In the tales and novels it often is the exact place where things tear asunder, a place of broadly political crisis that stubbornly refuses reconciliation -- at least without the virtual annihilation of one side or the other". Beyond how this currently effects Dutch politics relating to immigration and integration issues, I think that factor is at play somewhat in Python's evolution too -- as the Python community is IMHO one that, with Pythons success in gaining broad interest, is currently struggling to reconcile both supporting a desire for prototypes and a desire to move in a strict static typing direction. :-) It's hard to do all these ideas justice in a few word, and I've probably lost many people trying to follow this by now who firmly believe objects really do exist they way they see them, but suffice to say, Python right now sits somewhat straddling the boundary between modeling data as classes and prototypes. Squeak is also at that boundary, less so as a language, but more so as a library and environment when it tries to patch Morphic prototype widgets on top of Smalltalk classes. So, in terms of moving PySqueak forward, the question is, whether to try to push a little like Squeak does, or to push even further, like on to entire prototype systems or even relational systems. Python has better support for prototypes than conventional Smalltalk since Python already uses a dictionary for instance variables as opposed to Smalltalk which uses an array of slots where the slot<->name correspondence is managed by a class. So if Python were to gain something like Morphic widgets, they would probably fit much more nicely into Python than they ever would on Smalltalk. (Ignoring the dominant paradigm determined by library code issue mentioned previously.) Still, Python doesn't try to do a entity-relationship model directly. So, one can ask, is it worth trying to do as Squeak specifically does (Morphic), or try to see the higher ideal of Squeak pushing up another level (Classes -> Prototypes), and try to go it one better (Prototypes -> Relations)? The Self video shows that once you do have a working prototype based system, making a Smalltalk with classes is fairly easy, and what more, actually runs faster than a typical Smalltalk. So too, perhaps a successful entity-relational language might be able to do prototypes easily and more quickly? In the triadal systems I work on (essentially a long list of items which are three pointers: P1 P2 P3) and a few operations on that, http://www.kurtz-fernhout.com/pointrel/ prototypes and classes merge naturally as useful approaches to many problems. But obviously, such a push risks drifting much further from any unifying vision driving interest in something like PySqueak, yet at the same time, it is less "reinventing the wheel", and more "burn the disk packs" to go beyond full steam ahead. At least in my own explorations of computation, trying to make systems that are more entity-relational has been what I have for two decades felt driven towards, informed by a certain conception of Physics and Psychology. But, the new insight from me is to see these two spectrums of (again): Machine -> Assembly -> Functions -> Classes -> Prototypes -> Relations and: Classes -> Objects -> Relations -> Reality and how human personality and cultural and economic pressures help determine individual choices about where to program and think on these spectrums. It's not an easy thing to wrestle with. Yet, as I learned from one smart person who had studied the patent literature, innovative progress comes from a successful attempt to reconcile seemingly opposing needs both at the same time (e.g. cheap and fast), rather than just compromise between them (e.g. cheaper but slower -- compromise being just engineering, or politics, as usual). As far as I am concerned, Squeak was a step backwards from Self in many ways (while forward in others, especially marketing and adoption-wise in an educational setting), as Self elegantly reconciles needs for prototypes and classes in a way that Squeak Smalltalk compromises with. Will PySqueak be a compromise or an innovation (or both)? It remains to be seen. Trying to keep this short, but failing. :-) --Paul Fernhout

7 19

KPL v 1.1 seems to go "Open Source"
by francois schnell 08 May '06

08 May '06

I've never tried KPL "Kids Programming Language" (Windows, .Net based) but I just saw they're moving to "open source" for v 1.1 (which eventually/maybe open some possibilities for Linux/Mono/Python ports). seen here: http://digg.com/software/Kids_Programming_Language_(KPL)_going_open-source and: http://p211.ezboard.com/fkplfrm20.showMessage?topicID=1.topic francois

1 0

Panda3D looks cool so far...
by kirby urner 08 May '06

08 May '06

Just to give the flavor of 'Hello World' in the basic tutorial. Don't worry, I won't be cutting and pasting a ton of stuff. I figure if you're interested, you'll check into it yourself. But yes, it's helping me get clear on some issues. Kirby ==== # Author: Shao Zhang and Phil Saltzman # Last Updated: 4/19/2005 # # This tutorial is intended as a initial panda scripting lesson going over # display initialization, loading models, placing objects, and the scene graph. # # Step 2: After initializing panda, we define a class called World. We put # all of our code in a class to provide a convenient way to keep track of # all of the variables our project will use, and in later tutorials to handle # keyboard input. # The code contained in the __init__ method is executed when we instantiate # the class (at the end of this file). Inside __init__ we will first change # the background color of the window. We then disable the mouse-based camera # control and set the camera position. import direct.directbase.DirectStart #Initialize Panda and create a window from pandac.PandaModules import * #Contains most of Panda's modules from direct.gui.DirectGui import * #Imports Gui objects we use for putting #text on the screen import sys class World: #Our main class def __init__(self): #The initialization method caused when a #world object is created #Create some text overlayed on our screen. #We will use similar commands in all of our tutorials to create titles and #instruction guides. self.title = OnscreenText( text="Panda3D: Tutorial 1 - Solar System", style=1, fg=(1,1,1,1), pos=(0.8,-0.95), scale = .07) #Make the background color black (R=0, B=0, G=0) #instead of the default grey base.setBackgroundColor(0, 0, 0) #By default, the mouse controls the camera. Often, we disable that so that #the camera can be placed manually (if we don't do this, our placement #commands will be overridden by the mouse control) base.disableMouse() #Set the camera position (x, y, z) camera.setPos ( 0, 0, 45 ) #Set the camera orientation (heading, pitch, roll) in degrees camera.setHpr ( 0, -90, 0 ) #end class world #Now that our class is defined, we create an instance of it. #Doing so calls the __init__ method set up above w = World() #As usual - run() must be called before anything can be shown on screen run()

2 2

History of Croquet?
by kirby urner 07 May '06

07 May '06

So I've only recently been exposed to screen shots of Croquet, including animated on Google video, but the whole experience is reminiscent of ActiveWorlds, which my friends and I have been exploring for years. Bonnie DeVarco (exBFI archivist) was a chief avatar for this technology, developing Virtual High School, or, as our oncologist would prefer, Virtual Cancer Conference (why fly to San Antonio to an overbooked venue, to watch PowerPoints from the cafeteria on a flat screen?). You can network virtually too, given sufficient bandwidth (which busy doctors should have). In other words, I'm seeing a lot of precedent for Croquet in the culture already, which means it likely does have a bright future. But I'm not sure everyone will syndicate under the one brand name. If t-Time is as good as people say, it oughta go the route of HTTP and promote interoperability between several alternatives in the same "virtual worlds" genre. We're not all about to jump ship, having collectively spent hundreds of man years builting nifty little cities in EduVerse or wherever (friends and I built an entire university based on Fuller's 60 degree coordination, versus the mainstream's 90 degree idea of "normal"). So let's assume peer-to-peer updating and synching becomes another basic protocol over TCP/IP, and various OSs rise to the occassion and develop a "shared world" mentality (suitable for doctor conferencing, other communications). The "NetMeeting" idea evolves to a more OpenGL style board room, complete with water pitcher and fluttering staff. The shared white board, although virtual, is persistent, and the company's legal department is actually authorized to take these peer-to-peer meetings as the real deal. That'd be a fulfillment of the Croquet prophecy I think, but we wouldn't necessarily have its characteristic branding going (e.g. that whole Alice in Wonderland theme). There's ample precedent to keep the "worlds" genre heterogenous. I personally might prefer a product from Cyan out of Spokane, just as t-Time compatible. When Alan Kay and I communicate virtually, we'd each have a selection of clients. Kirby

1 0

Re: [Edu-sig] Pythonic Mathematics (session 3)
by kirby urner 07 May '06

07 May '06

On 4/30/06, kirby urner <kirby.urner(a)gmail.com> wrote: > CLASS: Saturday Academy: Pythonic Mathematics > LOCATION: Portland State University, Neuberger Hall > TIME: 10 AM - 12:30 PM > I chose a different forum for the next session: http://mathforum.org/kb/thread.jspa?threadID=1377897 I'm working to interest community college teachers in the Gnu Math approach. Kirby

1 1