PyKE project still active?

[Charles McKnight]

Hi All,

I'm looking at using PyKE for a project and I noticed that the last commits / updates seem to be close to two years old. Is this project still being actively maintained?

Thanks!

Chuck

[Paul Haesler]

I did some work on PyKE in November 2010 but it looks like it hasn't been touched since.

I'm just gearing up to start having another look at it now.  Not sure if Bruce is still around?

Paul (aka linkjuggler).

[Bruce Frederiksen]

Hi Paul!

Yeah, I'm still floating out here.  I haven't had any bug reports or requests for new features, and so haven't seen a need (yet) for another release.  I've put one or two pings out there to see if anybody is using it, but haven't had any responses.

I just took another look (for the first time in a couple of years) at the number of downloads on SF, and was surprised that it's up to nearly 80,000 now over the project's lifetime (last time I looked it was around 30,000).  Activity has been picking up since Nov, 2011 with a large spike in Jan, 2013!

I'm now available if anybody wants a gun for hire on PyKE.

Paul, you now have admin permissions on the project.  I may be in and out.  Please keep me informed on what you're doing with PyKE.

If anybody else reads this and is using PyKE, I'd love to hear from you!  Just drop a line on this google group.

-Bruce

--
You received this message because you are subscribed to the Google Groups "PyKE" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyke+uns...@googlegroups.com.

To post to this group, send email to py...@googlegroups.com.

Visit this group at http://groups.google.com/group/pyke.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[B. Jack]

I'm guessing many developers have not yet discovered how they might apply PyKE to their own projects.

---

Date: Mon, 17 Jun 2013 13:53:26 -0400
Subject: Re: PyKE project still active?
From: dang...@gmail.com
To: py...@googlegroups.com

[Paul Haesler]

Thanks Bruce!

Pyke still seems to get mentioned when discussions about knowledge based programming come up - it seems to be reasonably well respected by those in the field at any rate.

Paul.

[Bruce Frederiksen]

Yes, that's one of the reasons I encourage people to post what they're doing on this group, so that others can get ideas.  If you have any, please don't be shy!  :-)

-Bruce

[B. Jack]

Some possible recipes to explore with PyKE:

***

I toyed with the idea of making a 3D game builder using on Python and Panda3D (which I've codenamed 'Bamboo' [Pandas eat bamboo]) that works similar to Construct2 (a commercial 2D game builder found at scirra.com).  It occurred to me that the ability of PyKE to bake a call graph would be able to compile the user's project into an executable game.  It would be possible to add new functionality by creating additional rule bases for new object classes (eg: adding network protocols, facebook support, etc. after initial release)  Construct2 has a very usable drag-and-drop WYSIWYG IDE for game design that I'd be hoping to emulate in Bamboo.  One thing is for certain: Construct2's drag-and-drop object placement and WYSIWYG game layout beats out Blender's BGE logic brick methodology by a considerable margin.

A cursory design guess would be that C2's modules would be realized as rule bases in this design.

What I'm not so sure is the handling of objects, properties and variables.  It seems like I'd have to generate huge fact bases that enumerate all the objects and properties, the game's local and global vars, etc.  Since PyKE fact base entries are constants I'd have to enumerate these opaquely by type since the values in things like object properties, and local and global variables are going to change while the game runs.

Construct2 projects use an Actions/Conditions/Expressions model for objects.  Conditions trigger events which consists of lists of operations on objects using the object's Actions, possibly evaluating object state using its Expressions.  Eg: a project responding to mouse movement would have an event entry that triggers on Mouse object "Whenever mouse is moving" condition.

***

A possibly simpler alternative might be to adapt the rule bases to target Blender's game engine (BGE) using Blender's own objects instead (and some hinting properties (ie: facts) that rules can test to determine desired game behavior).  The result would be a pure python scripted game that does not require using logic bricks and might even promote use of Blender's game engine up from "toy" status (or like is frequently heard on the forums "it's only good for testing things and not for complete games").

On that note a complementary idea is to cajole the Blender devs into using PyKE in Blender internally and completely nip the long-standing infamous issue of high game logic overhead by utilizing PyKE rule bases to bake the logic bricks with PyKE whenever the game engine is started (unless newer Blender versiosns have already made this change).

***

Another possible application for PyKE is in MMORPG (or other system) networking to efficiently bake a lightweight protocol adapted to the game's (or system) current design as an automated build step but also allowing changes to the protocol.  The power of doing so is leveraged even more if the whole thing can be unpickled and used from PyPy (a Python interpretor utilizing python-to-native JIT).  The benefit here is you can also do some automagical testing of the protocol in advance by analysing the plan (or adding rules to the rule base to check for deadlocks, regressions, etc).

A generalization of this idea could also be used to bake UML models into executable Python code.

***

What about automagical thread assignment?  The application can assess the system and what needs to be done and the resulting plan includes an efficient split of thread assignments for the given task (the fact base might include things like the live system's number of available cores, available RAM, GPU cores, etc).

***

In similar manner to building project-specific SQL queries one might be able to build runtime-specific vertex, geometry and/or fragment shaders that adapt for the current hardware (read: GPU driver bugs/missing feautures/etc.) and the current needs of the running project (such as mesh types to be displayed, assets being used such as additional bump maps, alpha maps, normal maps, etc and configuration settings adjusted by the user to tune system performance...

***

CA-inspired evolutionary code.  Each active cell contains a code piece formed from the available primitives and expected to obey any primitive combination rules.  PyKE can compile the primitives and verify that the stitching is consistent with whatever combination rules that are in effect. Rule bases include primitive definitions (the set of functions here define what a "cell" can do), rules for how primitives can be combined, cell survival/death/birth rules (may include environment rules to determine cell fitness)...  Every non-empty cell is compiled then all cells are run (result will be every changing cell generating an operation to survive, birth a new cell, mutate, die off, etc. all applied in a single transaction after all operations are enumerated).  Whenever a cell mutates (or is a birth) rules are reset and that cell is compiled (with a hashtable cells needn't be confined to a fixed grid).  Pick your favorite RNG seed and let er rip.  Conway's Life 2.0 (on massive steroids).

***

A ton of other possibilities I've forgotten to remember.

---

Date: Mon, 17 Jun 2013 22:11:14 -0400

[Nicola Vitucci]

Hi all,

I'm using PyKE as well to build an OWL-RL reasoner, I'll keep you up to date as it becomes more stable and usable.

By the way, thanks Bruce for all the great work on PyKE!

Nicola