project and group still active

[Apil Tamang]

Hey All,

Noob here.. found this project accidentally, and keen on getting to know more. Is the project still active? Don't see a post been made in a while. Where can I get support for ramping up, general questions, etc... ?

[stub22]

Hi Apil and group,

Yes, the project is still quite active, as you will see if you look at the SVN commit logs.
The cogchar project is part of the larger glue.ai constellation of software.
We have been wanting to update these groups and our websites, but that effort always lags
behind our work on actual features.   I will give a very brief, rough explanation here and
will attempt to follow up more when you ask more questions.

The best way to get started is probably to read the glue.ai website. 
Then you can pull down the current SVN trunk for the friendularity project,
and do a maven build of that.  It will pull in all the binary dependencies you need.  
From there the next steps vary depending on your interests.
You can launch the org.friendularity.bundle.demo.ccmio   bundle to see a simple
virtual world demo.  There are flags in the bundle activator source there that
turn on some different features, including camera processing.  There are a
few keystrokes you can press to activate different features in the virtual world.
There are several kinds of networking available to that VirtualWorld process
(AMQP via Apache Qpid, Akka Remote, Spray.io HTTP).     Text To Speech
services are usually connected using AMQP, running external speech
processes defined in the MechIO.org software.

In theory the software should work across all platforms at JDK 7 and up, but our main
testing is currently with JDK 7 (slowly moving towards JDK 8), using Ubuntu Linux for
robots and Windows 7 for OpenGL simulation.    (We recently had a bug
in using OpenGL on Linux, but it may be fixed now).

Stu

[Apil Tamang]

Nice to know. 

There a particular reason y'all are not working in the git (github) space? Nowadays, most project seem to stem off of git.

One of the high-level questions I wanted to ask is the directions that the project(s) is(are) moving forward to. Is all of the work culminating to some system, or is it mostly individuals and groups extending the code-base to their own interest-spheres? The reason I ask is that I originally found this project via its reference in the "Hanson Robotics" site. I can imagine all this work being required for the robots featured in their site, but glue.ai appears much vaster.

Anyways, I have a growing interest for NLP and reasoning systems and if this suite of software is the entirety of the system for the Hanson robots, I'm sure I'll have more than enough of my share. Anything you can tell me about some of the higher-level goals and directions would be great!!

And I'm pleasantly surprised to see this project based on the OSGI framework. I use it a lot for my work, and I always thought OSGI  bundles/services provided the most natural development interface for intelligent subsystems. However, leveraging a heavy-weight framework (such as OSGI) which introduces ton of interfaces have been reported to cause performance degradation. Have you ever experienced something like this, for my own curiosity?

I'll check out the work and the docs sometimes tomorrow. Thanks for your time.

[stub22]

Hi Apil,

There a particular reason y'all are not working in the git (github) space?

We have historically used subversion and found it to be quite satisfactory. 
The Tortoise-SVN client is still very usable, IMHO.  
We have no compelling reason to switch to git, although it is a good system, too.
I suppose if we had a lot of people making forks, then git would pay off more.
But we don't have that situation, currently.
 

One of the high-level questions I wanted to ask is the directions that the project(s) is(are) moving forward to. Is all of the work culminating to some system, or is it mostly individuals and groups extending the code-base to their own interest-spheres? The reason I ask is that I originally found this project via its reference in the "Hanson Robotics" site. I can imagine all this work being required for the robots featured in their site, but glue.ai appears much vaster.

My view is that our overall goal is to provide the best possible foundation for building embeddable interactive AI systems based
on the JVM platform, open source software, and open data standards.   Beyond that, there are some different teams building
their own packaged systems based on the glue.ai foundation, but since some of that work may be commercial and/or proprietary,
it is difficult for me to comment publicly.
 

Anyways, I have a growing interest for NLP and reasoning systems and if this suite of software is the entirety of the

system for the Hanson robots, I'm sure I'll have more than enough of my share. Anything you can tell me about

some of the higher-level goals and directions would be great!!

My own personal interest is more in the physical movement aspects of performance, as well as musical awareness,
and less in the NLP areas.  I am also interested in general behavior and motivation issues.  Other contributors have
deeper interests in NLP, and there are indeed some pieces of that to be found in the glue.ai codebase today.  However, that
is not really the strongest aspect of what you can most easily download and run, currently.  I would say our strongest
qualities are in the generalized approach to assembling flexible character systems using RDF, AMQP, and OSGi, as
well as the duality between OpenGL simulation and and the physical servo + sensor interfaces defined in the
MechIO.org subproject.

If you would like to contribute some more NLP capabilities to the glue.ai projects, we would be glad to hear your proposals.
 

And I'm pleasantly surprised to see this project based on the OSGI framework. I use it a lot for my work, and I

always thought OSGI  bundles/services provided the most natural development interface for intelligent subsystems.

However, leveraging a heavy-weight framework (such as OSGI) which introduces ton of interfaces have been reported

to cause performance degradation. Have you ever experienced something like this, for my own curiosity?

I'm not sure why you would call OSGi "heavy-weight", or what you are referring to as a "ton of interfaces".
(Feel free to be more specific in a followup).  There are a lot of optional pieces to OSGi, and there may
be some parts of some OSGi impls that wind up matching those descriptions, but not in the areas that
I have used.  
 
We use OSGi bundles to provide clear modularity in terms of the build process, and the isolation of classpaths
at runtime.  We do use the OSGi registry in some places, but I don't see that as a heavy mechanism.  Furthermore
in our more recent code we are relying more and more on akka actors to hold references (instead of
using lookups in the OSGi registry).     OSGi does not really interfere with the way our code executes, and there
is no interception of object creation or database operations or thread pooling, etc., like you would
see with old EJB stuff  (which I haven't used myself in 15+ years,I am happy to say).    I don't think there is any
performance issue related to OSGi in the glue.ai codebase; it typically runs just as fast as any JVM program without
OSGi, except during startup.    There is some delay at startup of an OSGi system, if there are a lot of bundles to be
loaded and wired.   There is naturally some memory consumption related to those bundles as well, but we have not
observed the overhead to be significant.  We have been somewhat lazy about making sure that only the absolutely
required bundles are started in each case, and that is an area for future improvement. 

Perhaps when Java 9 and Jigsaw finally arrive we will start to see OSGi bundles as less necessary; time will tell. 
But we are right now still just beginning to move towards Java 8, so we will likely stick with OSGi for several
more years, at least.  It has served us well so far!

> I'll check out the work and the docs sometimes tomorrow. Thanks for your time.

You're welcome.  Have fun!