# ticket_change

author: PatrickHorn
field: comment
oldvalue: 1
newvalue:
  I think if you type continue in gdb it recovers--I think this is the way Mono catches a null pointer exception *somewhere*


author: ewencp
field: comment
oldvalue: 2
newvalue:
  I ran with the correct settings in GDB for debugging Mono (see http://www.mono-project.com/Debugging ).  With these settings there should be no unexpected breaks.


author: PatrickHorn
field: comment
oldvalue: 1
newvalue:
  danielrh fixed the outstanding issues yesterday morning. Hopefully we don't run into any more protobuf issues


author: danielrh
field: comment
oldvalue: 3
newvalue:
  Still crashes when monoscript module is compiled without ever unpinning objects

      ~MonoGCObject() {
          if (mGCHandle) {
              //mono_gchandle_free(mGCHandle);

  After first crash, always crashes when the instruction pointer reaches
  0xe823cf01 in  IronPython.Modules.PythonWeakRef/weakproxy:Finalize ()
  (I don't know how to preemptively break at the weakproxy:Finalize () function)


author: danielrh
field: comment
oldvalue: 5
newvalue:
  Built IronPython in debug at http://graphics.stanford.edu/~danielrh/IronPython2.0.2-dbg.zip
  Still crashes at 
  (gdb) call mono_pmip ($eip)
  $6 = 0x9a68ec0 " IronPython.Modules.PythonWeakRef/weakproxy:Finalize () + 0xc9 (0xe76cf1b0 0xe76cf2d9) [0x34ee0 - Root Domain]"
  (gdb) call mono_debug_print_vars ($eip, 1)
  prints nothing

  This is with no unpins...so I'm right now out of ideas...thoughts anyone?


author: danielrh
field: comment
oldvalue: 6
newvalue:
  And just when I thought I was out of ideas:
  It looks like the problem comes from a specific module being used by google protobufs, specifically weakref.py which references _weakref.cs

  looking closer at the _weakref.cs class reveals 
  {{{
                  // remove our self from the chain...
                  try {
                      IWeakReferenceable iwr = _target.Target as IWeakReferenceable;
                      if (iwr != null) {
                          WeakRefTracker wrt = iwr.GetWeakRef();
                          wrt.RemoveHandler(this);
                      }
                     _target.Free();
                  } catch (InvalidOperationException) {
                      // target was freed
                  }
  }}}

  Perhaps microsoft's C# will catch bad references using the InvalidOperationException--and perhaps mono happens differently. 
  Either way it seems like one solution could be to modify google's protocol buffers not to import weakref


author: danielrh
field: comment
oldvalue: 8
newvalue:
  Fixed in fdf216412e2c50308492e1d89516694554bc3ba0 by avoiding mono-incompatible weakref.py
  #22 may be caused by fix, but current experimentation indicates #22 may not occur.


author: PatrickHorn
field: comment
oldvalue: 1
newvalue:
  Just need a cron script on dreamhost. Probably the two things we are concerned about are a mysqldump (or whatever database store we use) and a tarball of the content/names directory (to make sure we don't have any more name collision problems). assets are likely too big for a tarball to make sense--plus, they never can get overridden.

  If we're worried about dreamhost itself failing we can make the database dump live inside some server readable directory, and rsync the sqldump along with the content directory (assets and names) to our own systems.


author: PatrickHorn
field: comment
oldvalue: 1
newvalue:
  I suspect the problem is that I broke in the debugger between when a message was sent and when the response was received. When I hit cont, I suspect the order of actions was:
  * Received response message, put on IOService queue
  * Timeout occurred, put on IOService queue.
  * Queue is processed:
  * SentMessage deleted. and its timer is Cancelled, pushed on the IOService queue.
  * Timeout is processed but not treated like a cancellation.
  * Cancellation processed

  The solution is probably to keep a boolean in SentMessage::TimerHandler whether it was cancelled instead of looking at the boost::asio::error_code.

  Have only encountered this bug once. Only likely to happen when messages are sent over the network.


author: danielrh
field: description
oldvalue:
  6>C:/Documents and Settings/Owner/My Documents/Workspaces/sirikata/liboh/scripts/csharp/protocol/Sirikata.pbj.cs(1649,33): error CS1501: No overload for method `CastBool' takes `0' arguments

  ----
  code :

     public bool Stateless{ get {
              if (HasStateless) {
                  return PBJ._PBJ.CastBool(super.Stateless);
              } else {
                  return PBJ._PBJ.CastBool();
              }
          }

newvalue:
  6>C:/Documents and Settings/Owner/My Documents/Workspaces/sirikata/liboh/scripts/csharp/protocol/Sirikata.pbj.cs(1649,33): error CS1501: No overload for method `CastBool' takes `0' arguments

  ----
  code :

     public bool Stateless{ get {
              if (HasStateless) {
                  return PBJ._PBJ.CastBool(super.Stateless);
              } else {
                  return PBJ._PBJ.CastBool();
              }
          }


author: danx0r
field: comment
oldvalue: 2
newvalue:
  not clear why this is owned by me (I've not been party to the discussion), nor why the milestone is "MusicDeptDeliverable" -- I assmue that means MiTo?


author: danx0r
field: comment
oldvalue: 1
newvalue:
  I believe this has been addressed, will leave it to someone else to close as I'm not 100% sure of the status


author: danx0r
field: comment
oldvalue: 1
newvalue:
  spaces in material names (again), I believe -- in any case, the problem has been addressed and has been reported to me as having been dealt with.

  Sirikata should produce cogent, useful error messages in cases such as this


author: danielrh
field: comment
oldvalue: 2
newvalue:
  Fixed in 0fea50d3a22612632ed946621de03b85da3de0c6 and 7fb1fef6d62089b280ce7f028f2f839aca2c68ff and 41f07dec8fe8ad4efab08f10e1c4fbb185f0e2eb and f1fb5f2629a88f41254996b6516afacc086485ab and 4c66bc454e8eef59049948416056b763c5f6469c and 6d6ebc4ddf9c20ead8d918e26010b390ed21c88b and e47e0a37d523acfcdf45d035a33074ff807cf5a9


author: danielrh
field: comment
oldvalue: 1
newvalue:
  It appears they need to have their centers at their centers of mass rather than off in the boonies, which can ruin sort ordering for translucent materials.


author: danielrh
field: comment
oldvalue: 3
newvalue:
  Determined it was invalid assets being uploaded to the servers that were not named by hash.
  Possible fixes include checksumming the download and making the upload script atomically move the assets to the appropriate filename.
  The switch to collada will obviate the long term need for security fixes for maliciously planted poor ogre mesh files.


author: danielrh
field: comment
oldvalue: 1
newvalue:
  Fixed in cac305823166fbafe97fdbda1214b0aa0782afd7 ed76d82e8c6a67e47eb7ca117f8477284a08159d and  557fd05d8f178c417623ac0b3ec8c1c8f49fb654


author: danielrh
field: comment
oldvalue: 1
newvalue:
  Not being able to walk up and down the subunit tree was one of the biggest complaints from fellow coders (eg spiritplumber and jacks) in vega strike. We should avoid the mistake this time around
  weak pointers up, shared pointers down? or weak both ways?


author: danielrh
field: comment
oldvalue: 2
newvalue:
  It appears to be hanging because mEnqueuers in ObjectHost.cpp is getting set to garbage memory somehow.
  That's one of the few variables in the program that is not actually used until shutdown so if it were corrupted during the run it would only be evidenced at the end.

  I need to reproduce this once in valgrind or something--I'm worried it's some sort of very sneaky bug


author: PatrickHorn
field: comment
oldvalue: 2
newvalue:
  We currently have ObjectReference's up the tree (can be easily changed to weak_ptrs which would both save memory and make lookups more efficient)

  Down the tree is currently using the ListenerProvider interface (with ProxyObject*, really ProxyObjectListener*) so the children know when their parent is destroyed in order to update their position.

  That can be changed to a set of ProxyObject pointers (can be shared or plain), giving the ability to traverse the list of children.


author: danielrh
field: comment
oldvalue: 5
newvalue:
  I get a throw() in /home/daniel/sirikata/libcore/src/util/SentMessage.cpp:63
  {{{
  48      void SentMessage::timedOut() {
  49          RoutableMessageHeader msg;
  50          if (this->header().has_destination_object()) {
  51              msg.set_source_object(this->header().destination_object());
  52          }
  53          if (this->header().has_destination_space()) {
  54              msg.set_source_space(this->header().destination_space());
  55          }
  56          msg.set_source_port(this->header().destination_port());
  57          msg.set_return_status(RoutableMessageHeader::TIMEOUT_FAILURE);
  58          msg.set_reply_id(this->getId());
  59          this->mTimerHandle.reset();
  60
  61          // Make sure this is on the same thread--
  62          // We can use mQueryTracker->sendMessage(msg) to send it via the same loop
  63          this->mResponseCallback(this, msg, MemoryReference(NULL,0));//dies here
  64      }
  }}}
  #9  0xf7f3c6da in Sirikata::SentMessage::timedOut (this=0x94400b0)
      at /home/daniel/sirikata/libcore/src/util/SentMessage.cpp:63
  63          this->mResponseCallback(this, msg, MemoryReference(NULL,0));

  {{{
  #7  0xf7ecc509 in boost::throw_exception<boost::bad_function_call> (
      e=@0xffdc9c98)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/throw_exception.hpp:64
  #8  0xf7f3e020 in boost::function3<void, Sirikata::SentMessage*, Sirikata::RoutableMessageHeader const&, Sirikata::DataReference<void const*> >::operator() (this=0x9440120, a0=0x94400b0, a1=@0xffdc9ce4, a2=
       {first = 0x0, second = 0})
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/function/function_template.hpp:986
  #9  0xf7f3c6da in Sirikata::SentMessage::timedOut (this=0x94400b0)
      at /home/daniel/sirikata/libcore/src/util/SentMessage.cpp:63
  #10 0xf7f3da2e in boost::_mfi::mf0<void, Sirikata::SentMessage>::operator()
      (this=0x9402e70, p=0x94400b0)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/bind/mem_fn_template.hpp:49
  #11 0xf7f3dc0c in boost::_bi::list1<boost::_bi::value<Sirikata::SentMessage*> >::operator()<boost::_mfi::mf0<void, Sirikata::SentMessage>, boost::_bi::list0> (this=0x9402e78, f=@0x9402e70, a=@0xffdc9db7)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/bind.hpp:232
  #12 0xf7f3dc4f in boost::_bi::bind_t<void, boost::_mfi::mf0<void, Sirikata::SentMessage>, boost::_bi::list1<boost::_bi::value<Sirikata::SentMessage*> > >::operator() (this=0x9402e70)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/bind/bind_template.hpp:20
  #13 0xf7f3dc69 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, Sirikata::SentMessage>, boost::_bi::list1<boost::_bi::value<Sirikata::SentMessage*> > >, void>::invoke (
      function_obj_ptr=@0x9402e70)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/function/function_template.hpp:152
  #14 0xf7f1356f in boost::function0<void>::operator() (this=0x9402e6c)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/function/function_template.hpp:989
  #15 0xf7f14a10 in Sirikata::Network::TimerHandle::TimedOut::timedOut (
      error=@0xffdc9f28, wthis=@0xffdc9e84)
      at /home/daniel/sirikata/libcore/src/network/IOServiceFactory.cpp:117
  #16 0xf7f0faa6 in boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > >::operator()<void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list1<boost::system::error_code&> > (this=0xffdc9f20,
      f=@0xffdc9f1c, a=@0xffdc9ec4)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/bind.hpp:292
  #17 0xf7f0fb1e in boost::_bi::bind_t<void, void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > > >::operator()<boost::system::error_code> (
      this=0xffdc9f1c, a1=@0xffdc9f28)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/bind/bind_template.hpp:32
  #18 0xf7f0fb3b in boost::asio::detail::binder1<boost::_bi::bind_t<void, void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > > >, boost::system::error_code>::operator() (this=0xffdc9f1c)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/asio/detail/bind_handler.hpp:39
  #19 0xf7f0fb4f in boost::asio::asio_handler_invoke<boost::asio::detail::binder1<boost::_bi::bind_t<void, void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > > >, boost::system::error_code> > (function=@0xffdc9f1c)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/asio/handler_invoke_hook.hpp:63
  #20 0xf7f0fb89 in boost_asio_handler_invoke_helpers::invoke<boost::asio::detail::binder1<boost::_bi::bind_t<void, void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > > >, boost::system::error_code>, boost::_bi::bind_t<void, void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > > > > (function=@0xffdc9f80,
      context=0xffdc9f80)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/asio/detail/handler_invoke_helpers.hpp:39
  #21 0xf7f0fbd4 in boost::asio::detail::asio_handler_invoke<boost::asio::detail::binder1<boost::_bi::bind_t<void, void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > > >, boost::system::error_code>, boost::_bi::bind_t<void, void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > > >, boost::system::error_code>
      (function=@0xffdc9f80, this_handler=0xffdc9f80)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/asio/detail/bind_handler.hpp:72
  #22 0xf7f0fbee in boost_asio_handler_invoke_helpers::invoke<boost::asio::detail::binder1<boost::_bi::bind_t<void, void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > > >, boost::system::error_code>, boost::asio::detail::binder1<boost::_bi::bind_t<void, void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > > >, boost::system::error_code> > (function=@0xffdc9f80, context=0xffdc9f80)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/asio/detail/handler_invoke_helpers.hpp:39
  #23 0xf7f1111f in boost::asio::detail::handler_queue::handler_wrapper<boost::asio::detail::binder1<boost::_bi::bind_t<void, void (*)(boost::system::error_code const&, boost::weak_ptr<Sirikata::Network::TimerHandle>), boost::_bi::list2<boost::arg<1> (*)(), boost::_bi::value<boost::shared_ptr<Sirikata::Network::TimerHandle> > > >, boost::system::error_code> >::do_call (
      base=0x92950f0)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/asio/detail/handler_queue.hpp:192
  #24 0xf7f0a216 in boost::asio::detail::handler_queue::handler::invoke (
      this=0x92950f0)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/asio/detail/handler_queue.hpp:39
  #25 0xf7f1c78a in boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor<false> >::do_one (this=0x8211720, lock=@0xffdca05c,
      this_idle_thread=0x0, ec=@0xffdca08c)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/asio/detail/task_io_service.hpp:268
  #26 0xf7f1c9e7 in boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor<false> >::poll (this=0x8211720, ec=@0xffdca08c)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/asio/detail/task_io_service.hpp:130
  #27 0xf7f1ca7c in boost::asio::io_service::poll (this=0x82078a8)
      at /home/daniel/sirikata/dependencies/installed-boost/include/boost-1_37/boost/asio/impl/io_service.ipp:84
  #28 0xf7f09cab in Sirikata::Network::IOServiceFactory::pollService (
      ios=0x82078a8)
      at /home/daniel/sirikata/libcore/src/network/IOServiceFactory.cpp:63
  }}}


author: danielrh
field: comment
oldvalue: 1
newvalue:
  Not sure this is helpful, but this is what --track-origins gives
  {{{
  ==28620==  Uninitialised value was created by a stack allocation
  ==28620==    at 0x4B17E1B: Sirikata::Quaternion::toAxes(Sirikata::Vector3<float>&, Sirikata::Vector3<float>&, Sirikata::Vector3<float>&) const (Quaternion.hpp:260)
  }}}


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed by 823378c525a0d8bc6def8a166195499eb572d10a, which collects plugins into a list (requiring them to be added when they are created).  The same applies for at least one protocol buffers (mono) target.  Closing this ticket, but having a more organized, automatic way of generating these would be good.


author: ewencp
field: comment
oldvalue: 4
newvalue:
  Seems to be working ok again, both with mono and without it.  Closing as worksforme for the time being.


author: danielrh
field: comment
oldvalue: 1
newvalue:
  Fixed in 434c0dd1bb7b68af93592c4d05457a51a75e72de of awesomium external
  incompatible with older chromium versions, so need to wait until universal version rev


author: danielrh
field: comment
oldvalue: 6
newvalue:
  Fixed in c6096a23589c5bfc379d1a406c4ce5ab8309fc6b and  bf728677436533e0d2b46cda2adbc3098c7aba2a
  Additional asserts in 6f81d687ffaf4e2798e9b120cc933b1617ee9b82 and 096ef251972a8d932201bac132d6c89e150e51de to verify usage is single threaded and proper


author: danielrh
field: comment
oldvalue: 2
newvalue:
  It appears that webpages do not render at all unless the window is sufficiently big for them.
  This could be a regression of some kind


author: Henrik Bennetsen
field: comment
oldvalue: 3
newvalue:
  Just looked into what automated backup Dreamhost offer and it is described as item no 2 in this newsletter:

  http://www.web-hosting-top.com/web-hosting/newsletter/news/118/dream-host-newsletter-v10.05-may-2008 

  Disconcerting writeup of the feature here:

  http://wiki.dreamhost.com/Domain_Restore

  Info for manual backup here:

  http://wiki.dreamhost.com/Backup_Website_Manually

  Is there a script that can get this done automatically?


author: PatrickHorn
field: comment
oldvalue: 4
newvalue:
  There is a tool that does this automatically, and it's called "rsync"

  I have copied the whole directory tree to my computer and others with ssh access can do it as well with:
  rsync -av user@sirikata.com:sirikata.com my-sirikata-backup

  rsync -av user@sirikata.com:/home/slartist content-backup

  If you run rsync with the same directory, it will recognize files that already exist and only copy the files that have changed, so it is very efficient.

  However, there is still the matter of database dumps and "names" backups, which are smaller bits of data that change more often. These would preferably be backed up daily or more by some cron script.


author: danielrh
field: comment
oldvalue: 1
newvalue:
  This means sirikata crashed--the Cg compiler has nothing to do with it and we need a backtrace to investigate further


author: ewencp
field: comment
oldvalue: 1
newvalue:
  I've bumped the timeout for the compiler calls to 3600 seconds.  Note that this could also be resolved by getting the compiler output to stream out instead of being dumped all at once.


author: ewencp
field: comment
oldvalue: 4
newvalue:
  Closing since nobody has mentioned any problems for awhile, seems to have just been getting the dependencies for generated files correct.


author: danx0r
field: comment
oldvalue: 1
newvalue:
  did some debugging on this -- we are definitely creating just one light, and we appear to be doing the right Ogre calls.  This seems to be an Ogre bug.


author: danx0r
field: comment
oldvalue: 3
newvalue:
  patch fixes bug in OgreConversions that was ignoring alpha channel and sending wrong data to shader

  this has been applied to speedlimits/museum but not yet to trunk


author: danx0r
field: comment
oldvalue: description.1
newvalue:
  Replying to [ticket:65 danx0r]:
  > if the scale of the avatar is not (1,1,1), there is some problem where the actual camera location is not the reported location.  Apparently someone is not paying attention to the scale, or is incorrectly looking at scale.  The offset should be in global units, not adjusted by scale of the avatar
  > 
  > problem can be seen in museum build, curator mode -- set scale of Avatar (in scenes/curator.env) to .5, .5, .5, and selection of paintings is off by some # of meters


author: ewencp
field: comment
oldvalue: 3
newvalue:
  It looks like this only happens when the monoscript plugin is loaded.  However, as far as I can tell the main loop is successfully getting closed up, so there must be some other thread causing problems.

  However, I do also rarely get this message:

  ResourceBackgroundQueue - thread stopped.
  Assertion failed: (!pthread_mutex_lock(&m)), function lock, file /Users/ewencp/sirikata.sirikata/dependencies/installed-boost/include/boost-1_39/boost/thread/pthread/mutex.hpp, line 50.

  suggesting maybe there's a thread which is continuing to use resources from the main thread after the main thread has exited.  What's especially odd is that I believe the first line is printed by an ironpython script but the name appears more like something from Ogre.


author: danielrh
field: comment
oldvalue: 1
newvalue:
  I'm in the callback and I want to indicate that I do not want to deal with this chunk now nor do I want to take ownership of it--I want it to stay on the queue until I pause the read--how do I indicate this without a return value? If the size of the chunk is 0 or something?


author: ewencp
field: comment
oldvalue: 2
newvalue:
  No longer relevant since we're not using Awesomium. Fixed by 2d905d67408745544d8636167a36015805fb8a1e.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  No longer relevant since we're not using Awesomium.  Fixed by 2d905d67408745544d8636167a36015805fb8a1e.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  I should also note that this should work on linux, but currently fails on mac complaining about ppmrender.app.  This seems like its just a bad interaction between the new Berkelium build and Sirikata's CMakeLists.txt


author: danielrh
field: comment
oldvalue: 1
newvalue:
  Since object hosts are going to have their own encoded messages in scripts and those will need to be unalterable and that portion of the system will work in space time, I think all parts of the system need to follow suit and work in space time rather than local time


author: danielrh
field: comment
oldvalue: 2
newvalue:
  Getting there...
  hopefully I get this fixed up soon because Henrik asked Patrick to get things working on snow leopard tomorrow and that will likely require more changes of this sort, so I've prioritized fixing this bug to get our branches unified before the snow leopard is taken on


author: danielrh
field: comment
oldvalue: 3
newvalue:
  and 11 hours later: that was so impossible to get right! with cmake 2.4 and 2.6 and all these symlinks needing to be made, etc
  I "just can't wait" until we have to start supporting cmake-2.8

  anyhow the new design is much more flexible and should make things much easier to restructure into .app structures for the future


author: danielrh
field: comment
oldvalue: 1
newvalue:
  I think we should focus on networking for a virtual world-- advanced users who want to run offline can setup their private network


author: danielrh
field: comment
oldvalue: 3
newvalue:
  No longer crashes, but it won't play videos

  neither will vanilla chrome, so I'm thinking "not our problem" for now


author: danielrh
field: comment
oldvalue: 1
newvalue:
  I believe we tracked this down to random selection of servers with one missing the content and the other being selected previously for a material download


author: danielrh
field: comment
oldvalue: 1
newvalue:
  Remembered that it got previous assets from graphics and failed to look at sirikata.com for future assets even if they did not have a mirror at graphics


author: danielrh
field: comment
oldvalue: 1
newvalue:
  There is a demo folder now--so this seems somewhat resolved--I'm bumping down the priority so that the important bugs get looked at


author: danielrh
field: description
oldvalue:
  when resizing a webview, sometimes that object's coordinates get thrown out to a very large float position

newvalue:
  when resizing an object, sometimes that object's coordinates get thrown out to a very large float position


author: danielrh
field: comment
oldvalue: 1
newvalue:
  Fixed by polling for position updates every frame
  Should actually get notified on position updates, which is reported in #81


author: danielrh
field: comment
oldvalue: 2
newvalue:
  It seems that you can avoid problems with the current interface by having proper accounting (i.e. limiting size of your queues) at inter-strand barriers.
  In fact it was simple to augment the experimental space with a pause callback when the strand crossing queue was full.

  Sure it might be nice to have the ability to pause a stream at an arbitrary time, but in our current code I believe we shouldn't need such an ability, so I'm reducing the priority of this bug unless anyone objects


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in danielrh/pbj.git:289749ce266dde2a98bcea400396a96420edcf41, fixing this for uint16, int16, and sint16.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  And also pushed to sirikata/pbj.git, where it ultimately belongs but which we are not yet referencing.


author: bhupc
field: comment
oldvalue: 1
newvalue:
  Additionally, it might be useful to actually have a message constructor: something similar to system.Message


author: bhupc
field: comment
oldvalue: 2
newvalue:
  This is blocking the "Bulletin Board" release. We need to know the ids. Someway or the other to communicate the id to the bulletin board


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Commit 278f824 should fix this particular crash, although its possible similar bugs still exist in the SST code. Please reopen this bug if you get a similar crash again.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This was only being used to get sha1 hashes of bounding boxes.  That code has been replaced with a custom function to do the same packing manually. Fixed in 8a35ce631f.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  New header format is separated into header and payload is held separately inside, so is not vulnerable to this.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Interaction with new space server handles this properly.  Location updates are delivered to HostedObject, so it is aware of any location changes.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  This was fixed by getting objects connections to disconnect properly when the object host quit(#107).


author: ewencp
field: comment
oldvalue: 2
newvalue:
  This is actually a symptom of #117. Commit c42bd2401ea2d5964eb3ef16090058702cd51450 is a hackish solution to this -- it just assume the space and object host were started at the same time and synchronizes based on that.


author: PatrickHorn
field: comment
oldvalue: 2
newvalue:
  Found a temporary hack, though still doesn't work perfectly and selected text is invisible:
  src/RenderWidget.cpp:440 (mouseMoved)
  event.button = mModifiers?WebKit::WebMouseEvent::ButtonLeft:WebKit::WebMouseEvent::ButtonNone;
  Formerly this was set to ButtonNone, so dragging didn't work.

  Also, need to add "host()->DragSourceSystemDragEnded();" in WindowImpl::StartDragging.


author: PatrickHorn
field: comment
oldvalue: 1
newvalue:
  Some progress in the "script" branch: made a Script::Variant class.

  Adding nested objects and arrays will be tricky, since even the slightest use of STL in a header causes a crash in windows. (even for an "inline" constructor calling string.data())

  Using this, we can add functions which take an array of Variant's, and pass them to javascript, or have javascript call a C++ function and decode JSON into an array of Variant's. Still need to add this JSON parsing function, possibly exposing it in the public API.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed in 0c77bb6dce94b2b31abd65c6241c60d662befdc8 by making MigrationMonitor treat degenerate server bounding regions as covering the entire world.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in commits 8df569a7f6d7bc8bad28e0ee7be7d834fb0956a5 to f4fc610470b3488bedebd909ed47b6a6262279d4.  TransferManager and many related classes have been removed.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed by 746bab1d800b0fa3bdc6a859aae57b3190d3782b. You can now specify a list of "simulations" to run using --oh.sims=[list,of,sims].


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed by commits 0254526061d64aa0fb361ab074fb90cf30a82069 through ec0d725a9d356edbc70d6003a1c76043c51123b6.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 869a503e0b2da84f4a3a023b3ca1b5fed1268bc4. A few different signals are handled by Contexts shutting down when they hear them so they will hopefully clean up successfully.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  No longer valid, old object property system isn't in use anymore. This is an application level issue.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed by 1e7533aefff2cf2b929908fc02fe752e742fcbba, which adds an interface for magic number checking, and 316a39580c2f5d7f0b61005e2ee785cc4d82d4c9 which adds a ModelsSystem implementation that can defer loading to other loaders that indicate they can load that mesh by checking magic numbers.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed by 316a39580c2f5d7f0b61005e2ee785cc4d82d4c9 which makes everything use the AnyModelsSystem which results in supporting all available loaders instead of having to choose between them.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This is an ancient bug and the CDN has changed significantly, but it looks like we still don't have all the scripts in the repository for running a CDN.  Even if these are just a few php scripts, they need to be in there since the protocol assumed isn't even documented anywhere.

  Ownership of CDN code has shifted, so I'm reassigning this to jterrace.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This is fixed in the js branch. Reassigning to bmistree so this will get closed when that code is merged into master.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  This bug needs to be verified again, it was reported so long ago that it may no longer be valid, especially since known uninitialized memory bugs were fixed in the core vector classes.


author: ewencp
field: comment
oldvalue: 3
newvalue:
  I can't reproduce this, so I'm closing as invalid. It can be reopened if somebody can trigger it again.


author: ewencp
field: comment
oldvalue: 5
newvalue:
  This is no longer valid, the quit timer takes care of forcing a quit when necessary and the previously discussed code has been removed since this was reported.


author: jterrace
field: comment
oldvalue: 1.2
newvalue:
  Replying to [comment:1 ewencp]:
  > This is an ancient bug and the CDN has changed significantly, but it looks like we still don't have all the scripts in the repository for running a CDN.  Even if these are just a few php scripts, they need to be in there since the protocol assumed isn't even documented anywhere.
  > 
  > Ownership of CDN code has shifted, so I'm reassigning this to jterrace.

  There is actually documentation on the HTTP protocol on the wiki here:
  http://www.sirikata.com/wiki/index.php?title=CDN_Transfer_Layer

  Going to add the scripts in now.


author: bhupc
field: comment
oldvalue: 2
newvalue:
  working on this
  When entities come back again after disconnection, they should resume by having the same uuid in the space. 


author: ewencp
field: comment
oldvalue: 1
newvalue:
  One part of this bug was that the CSVObjectFactory had an unitialized variable that caused it to sometimes not load the objects. The other part is that networking currently runs on separate IOServices, so the main IOService does in fact run out of work to do.  The right way to fix this is to make TCPSST work on a strand so it can be run on the main IOService.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in c562e870803b972a91b05f0857c873f9ba7a0441. The code has mainly been cleaned out because it was specific to Ogre. Essentially only the ResourceDownloadTask, which had been converted to use TransferMediator, was preserved.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  As of c562e870803b972a91b05f0857c873f9ba7a0441 there is very little left in meruCompat, essentially only the SequentialWorkQueue.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  I can't reproduce this and can't find any mActiveStreams in the code, so I assume this was a bug in the old space server.  I've removed the test code. Fixed by 09066eaba2d538ea18c16ec32bfdf3fe13d2872b.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  A few of the things I know need to be fixed:

  * TCPSST uses an OpenSSL header to do the handshake for WebSockets. This library isn't available to our Windows build yet.
  * OpenCollada needs to be updated to include the libraries with interfaces for writing.
  * We now require the boost iostreams library for compression on CDN transfers. We need to add this library to the dependencies.


author: bhupc
field: comment
oldvalue: 3
newvalue:
  I have tested it on my side. I do get persisted physical properties in the scene.db file. However, camera rotation still needs a fix for this to get completely fixed.


author: bhupc
field: comment
oldvalue: 2
newvalue:
  Talked with Ewen and Daniel. This involved playing with the bullet Physics engine. This is not required for  the Multiserver chat demo. Therefore, shifting it to the next milestone.


author: bhupc
field: comment
oldvalue: 1
newvalue:
  Talked with Behram.Assigning it to Behram.He already has a code merge pending for few functionalities.

  @Behram: Please bounce this back to me explaining what new features need to be put in. 


author: bhupc
field: comment
oldvalue: 1
newvalue:
  The csv file should hold a new "solid_angle" field so that entities can actually query for appropriate solid angle. By default it should be a small value. If not specified, entity is not registered for proximity query..


author: bhupc
field: comment
oldvalue: 2
newvalue:
  This is fixed now. We do need a way for the camera to script itself apart from specifying just the emerson script in the scene file


author: bhupc
field: comment
oldvalue: 3
newvalue:
  Added changes so that the entity can register the solid angle query through the csv file. Need to work on interface..This might require making a new type of proximity message.


author: bhupc
field: description
oldvalue:
  Entities can subscribe for a proximity query. There should be events generated for the proximity query results. Emerson should provide an interface to register these proximity queries.

newvalue:
  Entities can subscribe for a proximity query. There should be events generated for the proximity query results. Emerson should provide an interface to register these proximity queries.

  The complete fix can be provided once the ticket 161 is closed. 


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed by 62891705ddc61b7667f1090e1b0870fea4363f7f.  The filter stage is there, but it needs to be integrated with the uploader when that lands.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Rev c0e759c84ee9235248a74866ce839237324325f7 adds some debugging code to try to get more information about what's going wrong here.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed by 2e15dfbc74beeb117707c5d24cebc7ab337874de. One of the test scenes, colladasmall.csv, now uses this to generate the camera.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed by 2e15dfbc74beeb117707c5d24cebc7ab337874de. The startup options are still stored, which seems incorrect, but gets rid of the potential for people adding a ton of script-specific fields to ObjectScript, instead only storing a type and an options string.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Some additional locations were converted to ignore errors and report the bad messages. The following was logged from a server with these changes:


  [SPACE] Error parsing ObjectMessage in ObjectHostConnectionManager::handleConnectionRead. Contents: (67 bytes)
  [SPACE]   10
  [SPACE]   16
  [SPACE]   103
  [SPACE]   135
  [SPACE]   142
  [SPACE]   119
  [SPACE]   243
  [SPACE]   121
  [SPACE]   78
  [SPACE]   109
  [SPACE]   179
  [SPACE]   90
  [SPACE]   6
  [SPACE]   49
  [SPACE]   30
  [SPACE]   180
  [SPACE]   45
  [SPACE]   78
  [SPACE]   16
  [SPACE]   0
  [SPACE]   253
  [SPACE]   1
  [SPACE]   26
  [SPACE]   0
  [SPACE]   16
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   32
  [SPACE]   0
  [SPACE]   253
  [SPACE]   1
  [SPACE]   40
  [SPACE]   0
  [SPACE]   0
  [SPACE]   50
  [SPACE]   0
  [SPACE]   0
  [SPACE]   12
  [SPACE]   0
  [SPACE]   0
  [SPACE]   8
  [SPACE]   0
  [SPACE]   16
  [SPACE]   1
  [SPACE]   24
  [SPACE]   1
  [SPACE]   32
  [SPACE]   1
  [SPACE]   42
  [SPACE]   2
  [SPACE]   0
  [SPACE]   1
  [SPACE] Error parsing ObjectMessage in ObjectHostConnectionManager::handleConnectionRead. Contents: (49 bytes)
  [SPACE]   10
  [SPACE]   16
  [SPACE]   6
  [SPACE]   43
  [SPACE]   104
  [SPACE]   16
  [SPACE]   128
  [SPACE]   218
  [SPACE]   67
  [SPACE]   210
  [SPACE]   191
  [SPACE]   35
  [SPACE]   130
  [SPACE]   57
  [SPACE]   175
  [SPACE]   130
  [SPACE]   240
  [SPACE]   12
  [SPACE]   16
  [SPACE]   4
  [SPACE]   26
  [SPACE]   16
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   32
  [SPACE]   4
  [SPACE]   0
  [SPACE]   40
  [SPACE]   0
  [SPACE]   50
  [SPACE]   0
  [SPACE]   2
  [SPACE]   0
  [SPACE]   8
  [SPACE]   3
  [SPACE] New object host connection handled
  [SPACE] Error parsing ObjectMessage in ObjectHostConnectionManager::handleConnectionRead. Contents: (67 bytes)
  [SPACE]   10
  [SPACE]   16
  [SPACE]   95
  [SPACE]   108
  [SPACE]   196
  [SPACE]   78
  [SPACE]   96
  [SPACE]   143
  [SPACE]   77
  [SPACE]   136
  [SPACE]   167
  [SPACE]   30
  [SPACE]   235
  [SPACE]   84
  [SPACE]   238
  [SPACE]   167
  [SPACE]   142
  [SPACE]   56
  [SPACE]   16
  [SPACE]   0
  [SPACE]   253
  [SPACE]   1
  [SPACE]   26
  [SPACE]   0
  [SPACE]   16
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   32
  [SPACE]   0
  [SPACE]   253
  [SPACE]   1
  [SPACE]   40
  [SPACE]   0
  [SPACE]   0
  [SPACE]   50
  [SPACE]   0
  [SPACE]   0
  [SPACE]   12
  [SPACE]   0
  [SPACE]   0
  [SPACE]   8
  [SPACE]   0
  [SPACE]   16
  [SPACE]   1
  [SPACE]   24
  [SPACE]   1
  [SPACE]   32
  [SPACE]   1
  [SPACE]   42
  [SPACE]   2
  [SPACE]   0
  [SPACE]   1
  [PROX] Error opening Prox substream, retrying...
  DELETING STREAM 2973461608
  [PROX] Query removal initiated server query request.
  [SPACE] Error parsing ObjectMessage in ObjectHostConnectionManager::handleConnectionRead. Contents: (51 bytes)
  [SPACE]   10
  [SPACE]   16
  [SPACE]   136
  [SPACE]   10
  [SPACE]   183
  [SPACE]   110
  [SPACE]   113
  [SPACE]   112
  [SPACE]   68
  [SPACE]   190
  [SPACE]   133
  [SPACE]   140
  [SPACE]   209
  [SPACE]   135
  [SPACE]   195
  [SPACE]   63
  [SPACE]   23
  [SPACE]   145
  [SPACE]   16
  [SPACE]   0
  [SPACE]   4
  [SPACE]   26
  [SPACE]   0
  [SPACE]   16
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   32
  [SPACE]   0
  [SPACE]   4
  [SPACE]   0
  [SPACE]   40
  [SPACE]   0
  [SPACE]   0
  [SPACE]   50
  [SPACE]   2
  [SPACE]   8
  [SPACE]   4
  [SPACE] Error parsing ObjectMessage in ObjectHostConnectionManager::handleConnectionRead. Contents: (47 bytes)
  [SPACE]   10
  [SPACE]   0
  [SPACE]   16
  [SPACE]   136
  [SPACE]   10
  [SPACE]   183
  [SPACE]   110
  [SPACE]   113
  [SPACE]   112
  [SPACE]   68
  [SPACE]   190
  [SPACE]   133
  [SPACE]   140
  [SPACE]   209
  [SPACE]   135
  [SPACE]   195
  [SPACE]   63
  [SPACE]   23
  [SPACE]   145
  [SPACE]   16
  [SPACE]   4
  [SPACE]   26
  [SPACE]   16
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   0
  [SPACE]   32
  [SPACE]   4
  [SPACE]   40
  [SPACE]   0
  [SPACE]   50
  [SPACE]   2
  [SPACE]   8
  [SPACE]   9
  DELETING STREAM 2973567528
  [PROX] Query removal initiated server query request.
  [PROX] Error opening Prox substream, retrying...

  These connections were all WebSocket connections from web browsers.


author: ewencp
field: comment
oldvalue: 3
newvalue:
  This appears to be due to the client (katajs) sending invalid messages, not a bug in the space server. Once that bug is pinned down, I'll close this one.


author: ewencp
field: comment
oldvalue: 4
newvalue:
  Closing as this seems to be a bug specific to FF4b7 and it no longer crashes but instead logs the error and continues.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in fcf574ed348b5a530f81d897226d38d99832cd32. Saving orphan updates was only required on the object host currently. The updates between space servers have a single reliable, ordered channel and the pinto service doesn't send loc updates since it only needs to inform the servers which other servers to register queries with.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This works properly when setting prox.object.handler to brute or rtree, so this looks like a bug in the clean up process for RTreeCutQueryHandler in libprox.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This occurs when Berkelium isn't loaded properly. I'm going to leave this open since we should probably be disabling the webviews if Berkelium isn't available or at a minimum generate a transparent texture so it doesn't block everything else.

  Alternatively, we should have Berkelium as a hard requirement so that the plugin won't build without it.


author: bhupc
field: comment
oldvalue: 1
newvalue:
  This seemed to be a problem only with the 32 bit system. Worked fine with the 64 bit. Pushed in a fix for the 32 bit system. 


author: ewencp
field: comment
oldvalue: 1
newvalue:
  A related problem is that an empty object literal doesn't compile:

  Escape = {};

  results in this output:

  -unknown source-(0)  : error 3 : , at offset 0


author: bhupc
field: comment
oldvalue: 1
newvalue:
  Updated the chat terminal to have the proximity updates rather than broadcasting..So, closing this bug..It seems to have fulfilled it's purpose..


author: bhupc
field: comment
oldvalue: 1
newvalue:
  missed an extra space after the "else" keyword and so the generated code has "elsesystem." which was throwing the error I suppose. 


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This is also required to handle circular dependencies in messages, making this more important to fix soon.


author: bhupc
field: comment
oldvalue: 2
newvalue:
  Provided fix for this in the pbj repos. The pbj code can now generate a separate .cpp and .hpp for the class file. Also generated a .fwd.hpp file for a forward declaration. 


author: bhupc
field: comment
oldvalue: 1
newvalue:
  Fixed the base bug for this in pbj. Required forward declaration functionality from the pbj compiler. Working on this . ETA 5th Feb '2011


author: bmistree
field: comment
oldvalue: 1
newvalue:
  Still have extra ;, but have made it so that Emerson compiler accepts single ; lines.  Added test case for this to alt_regression as well.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This appears to be fixed, we now have JSVisibleStruct::decodeVisible, JSPresenceStruct::decodePresence, etc.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  We throw exceptions on parser errors now, which should also include messages. They are easily caught within Emerson code just as any other exception.


author: ewencp
field: comment
oldvalue: 3
newvalue:
  This object storage interface is deprecated and only being kept around as a reference for the reimplementation. Closing.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  I think this refers to the old space server, and we seem to be handling this case fine anyway since the space servers have a time sync and we sync with the space server we're connected to as well to get the offset.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Reboot/reset has recently been reimplemented. 025e67a950f2338fb33b5e228d5cfd2f4e14f5e9 should have fixed this as well.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Specifically, both https://github.com/sirikata/sirikata/blob/master/liboh/src/HostedObject.cpp#L461 for proximity update requests and https://github.com/sirikata/sirikata/blob/2285e13b32095f1901be4198db9193fe201fac2b/liboh/src/HostedObject.cpp#L1141 for location update requests must store the last value and retry if the datagram() calls fail to enqueue the data.


author: danielrh
field: comment
oldvalue: 2
newvalue:
  Could be Related: on windows placing a mParent->requestLocationUpdate(mID.space(), mID.object(), newloc);
  in onConnected fails to cause the object to move like it does in windows...
  however following it up with an arbitrary 5 second delay and then requestLocationUpdate will cause the object to move.

  On linux it appears that waiting until onConnected is called to request a move is sufficient to get the object moving, but it sounds like a possible race that could be solved by a retry


author: ewencp
field: comment
oldvalue: 1
newvalue:
  I can't reproduce this, although certainly that patch will increase CPU usage since it needs to periodically re-evaluate to update the velocity.

  You could try turning the period for the reeval, on moveAndRotate.em:74, way up, i.e. make it reevaluate much less frequently. At .25 its still smooth, at 1 its workable allow some jitter was noticeable.

  Also, make sure your V8 is up to date. Its presumably gotten a lot faster in the ~4000 commits since the we updated the version in the dependencies. It should be at something like v3.2.6 now.


author: ewencp
field: comment
oldvalue: 4
newvalue:
  Unclear if this meant from the CDN layer, via some zip -> url request, or just from the UI. Also ancient. Closing.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Closing as nobody is actively working on audio. Could be revived if somebody revived the audio branch.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Does this still happen, and if so does it really happen with just pressing forward or is it for both?

  We fixed a timer bug that was causing high cpu usage, although it should not have caused problems with framerate since the timer shouldn't have triggered any faster than the renderer. Since that bug fix, even when the timer for this code is active I still see pretty minimal CPU usage above the normal for when its rendering, e.g. from 30% to 34% of one core.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  There are sample scripts showing groups of objects and multiple servers were addressed in other bugs.


author: ewencp
field: comment
oldvalue: 3
newvalue:
  Not specifically terrain, but the Bullet plugin functions well enough to mark ground as static and objects as dynamic and have them land on the ground.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  You can do this by messaging another object. Other object hosts aren't directly addressable. To do this explicitly (rather than implicitly via another object) you'd need some side channel with the OH, e.g. if it exposed a web interface for allocating new objects.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Let's make this one refer to optimizing draw calls for a single loaded mesh, i.e. having the ogre plugin try to reduce the number of draw calls (possibly balancing with memory usage) for each loaded model. #217 deals with optimization between models.


author: ewencp
field: comment
oldvalue: 3
newvalue:
  This is largely fixed by 55f63e103c4967750e7449cd040363a777f11ae5. The remaininng problem is that some types of geometry can't be simplified with the current reduce-draw-calls filter. Next step is to either make SquashPrimitives support them, or have a filter that converts from any type to triangles/lines/points so that SquashPrimitives will be able to combine them.


author: ewencp
field: comment
oldvalue: 4
newvalue:
  Commit f9ad3d8c189f9f5ade4175c681fc9c83e9b06f78 adds the above suggested functionality for triangles (tristrips + trifans -> triangles), which solves the draw call efficiency issue for the vast majority of models. Linestrips are still missing.

  However, I'd also like to look into merging of tristrips before closing this. Within a single model, I think its likely we'd see all tristrips, and if they are sufficiently long, then merging them directly (with degenerate triangles) is likely a memory win as well, even if not a draw call win. After adding that type of merging to SquashPrimitives, the new TriangulateFilter in reduce-draw-calls *might* be reduced to only operate on trifans. The drawback is that if there is a mix of triangles and tristrips, we may end up with better memory efficiency but more draw calls since those ones won't be combinable.


author: jterrace
field: comment
oldvalue: 5
newvalue:
  Have you actually seen files with trifans, tristrips, and linestrips in practice? I don't think I've ever come across them in any collada file.


author: ewencp
field: comment
oldvalue: 6
newvalue:
  Good point, it looks like the majority of exporters don't bother with this and a scan of the content on open3dhub.com doesn't reveal any either. I think if we saw content coming in already prepared for a game engine we might see it, but most seems to come direct from modelling packages.

  There are still some models that aren't running through the reduce-draw-calls filter properly (i.e. hitting an assert). Once those are fixed I'll close this bug.


author: ewencp
field: comment
oldvalue: 7
newvalue:
  Commits 10fb6ddec56983769c228f10aca433c994002e62 and 7836332a805e78853bc2026dea38ae5078dc388e fix the remaining bugs/crashes known with this pipeline.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This one actually doesn't look inside out, it just looks like something is going wrong with the texturing or vertex indexing on the bodies of the logs.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Actually, I guess there seem to be 2 issues. Without the reduce-draw-calls filter, it's showing up as you described. A sphinx model (http://open3dhub.com/view/bmistree/models/model.dae/1) had a similar problem. With reduce-draw-calls, it seems to corrupt the texturing.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This was disabled, at least on the Ogre side, because it 'looks awful for some reason'. It probably looked awful because the shininess was not being set. Of course, shininess wasn't being stored by the collada code. Also, the collada code doesn't look like its going to handle the differences between Blinn and Phong properly, and especially won't handle the two modes commonly used by the Blinn tag.


author: jterrace
field: comment
oldvalue: 2
newvalue:
  The trick everyone seems to be using is to set shininess = shininess * 128.0 if it falls in the 0 to 1 range, otherwise use whatever's in the material.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed by 7b456ef6546389c1906ec41707ea816d0898110a which merges in refactored code that provides a standalone libogre which does most of the heavy lifting for the ogre graphics plugin.  Also includes meshview, a simple application that takes a URL and loads and displays it.


author: jterrace
field: comment
oldvalue: 1
newvalue:
  The fields 'version_num' and 'username' were already there.

  I've added 'base_name' and 'prefix_path'. Fixed in e516ce6


author: jterrace
field: comment
oldvalue: 1
newvalue:
  This was already fixed in:
  https://github.com/pycollada/meshtool/commit/218049fb2011b0fc077a60497fb61af4fba19065

  I reran the optimized script for that file, and it looks correct now:
  http://open3dhub.com/view/echeslack/SportsMaleAvatarIdle.dae/0

  I didn't rerun everything yet, because I'm trying to fix some more bugs first (like incorrect transparency in the screenshot), but if you want me to rerun any others, let me know.


author: ewencp
field: comment
oldvalue: 3
newvalue:
  danielrh says that this is no longer a problem since an V8 update, and the sub-second timer fix should help even more.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed by dc3e28c7f0b5cf7fb0f082cca3b81972aa465def which lets you write statements like

  sirikata.log('warn', 'Command: ', command);


author: ewencp
field: comment
oldvalue: 1
newvalue:
  We concluded that it wasn't worth maintaining the comma operator in the way JavaScript provides it since it isn't especially important.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This bug is from when keybindings were handled in C++. Since they've completely changed and the particular binding isn't there anymore, I'm closing this.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  We've concluded that this is the wrong thing to do. While the example is nice, it leads to other confusing behavior, for instance

  var pos = system.self.position;
  pos.y += 2;
  setCameraPos(pos);

  ends up moving yourself and the camera. The problem is that Emerson doesn't have a natural way to handle value types. A very inefficient workaround would be to have the compiler force the copy to be made upon assignment, but we don't think this is enough of an issue to add that.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  This was a bug in libprox where we weren't removing some leaf nodes when their parent went from satisfying the query to not satisfying it, resulting in the node being removed from the cut. Fixed in 0d718a3bf74a1f057aa6f165c10d59609b433b19.


author: ewencp
field: comment
oldvalue: 4
newvalue:
  Fixed in 14492437a581232f0f18f8067ac6a005da2cbf27 by tracking the values of fields where sends failed. Tested by triggering a high rate of failures and checking that updates still get through.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed by 231fb1c8a723316d9b6c1ec6599a94269baa0324 by resetting the modifier key state on window focus changes.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed in 38b3f3e4a74ef4b65a2646e1e7f24a97389754c1 by addressing some escaping issues with the serialized string in system.createEntityScript.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed sufficiently for standardization in 852b3bc2a42a426602c285cea006d91ff0c481f6.  We want more functions + more customization on top of plain old jQuery, but this puts enough in place to allow us to standardize some calls instead of using jQuery directly.


author: ewencp
field: comment
oldvalue: 5
newvalue:
  Content names are now separated out to a different CDN, but the entire sirikata.com web site, including the trac bug database and blog database, are now being rsynced to an external machine daily and backed up weekly to S3.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 2fed65d6237bdb19f5dc3ff20b09a23b1208349f by tracking the actual hit point and moving based on that instead of the center of the selected object.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed by a series of commits and finally working relatively nicely in 1bbef5fa616e87ad7012d6b58a3b7197fefffe8a.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  'Fixed' by 7c9f6dd2a15a104b7f5c46b994b551edd06a32ff by ignoring the transparency channel, which was being handled incorrectly. In this model, it seems that the transparency shouldn't even be there, so ignoring it is the right thing to do. In the future, when we add support for the transparency channel, this model will probably end up looking a bit transparent since its using the same texture for diffuse and transparency, but the texture has no alpha channel.


author: bmistree
field: comment
oldvalue: 2
newvalue:
  Run the new binary emheadless with a single argument containing the filename of the script you want to run headlessly.  You can't do certain things while headless (eg. create a presence); if you try to, the system will throw an error.


author: bmistree
field: comment
oldvalue: 2.3
newvalue:
  Replying to [comment:2 bmistree]:
  > Run the new binary emheadless with a single argument containing the filename of the script you want to run headlessly.  You can't do certain things while headless (eg. create a presence); if you try to, the system will throw an error.


  Oh.  The commit id for the fix is: c548e6aaccc1.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  The windows version was already building, and the mac version has had bullet added to its dependencies and the build fixed to find it again.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 9112f97c4a52798c1b5a7a858903c93af8737333 by reverting to using a sphere for the collision mesh.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 9a7c1ee9c499ad4c97335833045d59e3a86aaaf4 by making the model loading asynchronous. The rest of the settings are setup immediately, so only physics simulation has a delay.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed in da09ade4213bd52af518da5fc6e5ebaeaf1692c8. The rigid body is entirely removed and then re-added.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed in 963ffea99e726a7710287495dfbc608a20aa083d. Code was already there to notify the user, but a bug in the SessionManager was preventing it from working properly.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  It seems like a 4th option is to use a btActionInterface: the normal object is added but also a btActionInterface is added which allows us to adjust the item. I think setting it as a kinematic object and then trying to only resolve collisions with static objects will give the basic effect we want -- other objects that are movable will get pushed out of the way, but static objects, including the ground, will cause collisions which will get resolved.


author: bmistree
field: comment
oldvalue: 3
newvalue:
  Fixed by commit eb057cbd.

  For subtraction and addition, had been casting to float instead of keeping number as double, and doing addition and subtraction on doubles.  Fixed.  

  (NOTE: numbers still are either int32s, uint32s, or doubles.  You can't go larger than those.)


author: bmistree
field: comment
oldvalue: 1
newvalue:
  See commit 818e017.  Added a check to see if exceeded fixed number of evaluations.  In practice, max call stack exceeded occurs before that resource exhaustion error.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This was due to uncaught exceptions that only ran through C++ code, no Javascript code to catch them. Fixed in 7ddd2d56d2f815f5b55caf2d82b4963c2772135f.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Actually, the cancellation should happen automatically as the AssetDownloadTask is a SelfWeakPtr and the only reference to it should disappear if the Entity is deleted. However, the second item is still an issue.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  This should be fixed by ff2987c59cf105ba637285a9fc847ecfe895444d which uses a new utility class to make sure the Entity is still alive.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  0c6f6ce36067c63148f8 changed this from an assert to a check, and no crash has popped up since. This was probably due to something posting across strands, resulting in an out of date connection being used. Closing since there doesn't seem to be a problem anymore.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This has been added on Linux, which should be sufficient for now. Fixed in 232e2a776444a76bdb441a7b8d831d11076f358c.


author: danielrh
field: description
oldvalue:
   AsyncConnectionGet::~AsyncConnectionGet()
  seems to depend on DeadlineTimer::cancel not calling back.

  but DeadlineTimer often can still allow events through even after cancellation

  clear_all_deadline_timers may depend on similar behavior

  This should be replaced with IOService, or if craq is deprecated, this bug should be closed and the corresponding code removed

newvalue:
   AsyncConnectionGet::~AsyncConnectionGet()
  seems to depend on DeadlineTimer::cancel not calling back.

  but DeadlineTimer often can still allow events through even after cancellation

  clear_all_deadline_timers may depend on similar behavior

  This should be replaced with IOTimer, or if craq is deprecated, this bug should be closed and the corresponding code removed


author: bmistree
field: comment
oldvalue: 2
newvalue:
  In default.em and defaultAvatar.em, accidentally doubly-executed initialization function when setting inital script.  See commit #6a6144 for change.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in dc9f392a825fbe9c2b56ba6b404cd8f3f8c00da7. Currently this ends up leaking ProxyEntities, but for clients this shouldn't be critical. Notes in code about where we'd have to fix that up (or rather, where we were deleting them but it is no longer safe to).


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed in f6260a19a533995a8795588b9fed7782adc42295 by forcing user-select off. UIs can reenable them in their own CSS if it's appropriate.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 1435af8d2bb68cb085edc09dded4feaef2d68da1 by doing automatic JSON encoding and decoding. Not going to autoconvert presences and visibles to avoid confusion if they pop out on the other end as strings -- the user should know what they are going to get on the other side.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  701436b1cd92eadd6446eedc336c090023ccfae0 increases the logging so we can try to track down which crash is causing the problem and maybe figure out how to respond to it.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 4451b43f27718e6d882a5c65411854b7954edd2a with new std.graphics.Graphics.addGUITextModule method.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in a3a9cfe2a5725f0db5c1e2a5e7604493854d1291. The whole setup still needs work since predictive updates always dominate so long running movements requiring constant updates (e.g. running in a circle) never get corrected if the space server has to correct one of the updates (e.g. for physics). However, this should make things work well for unconstrained movements.


author: bmistree
field: comment
oldvalue: 1
newvalue:
  Fixed.  See commit 4fb78f1.  Can get the prox result set via system.getProxSet(pres), and can run prox added callback over visibles already in result set by setting a flag when calling onProxAdded.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This is actually throwing an exception for me as expected, even if we're in the invocation of the initial script. Of course things don't work then since it kills the GUI setup, but it doesn't generate a crash. Marking as invalid.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  I have yet to be able to reproduce this, and the only way it seems to make sense is if its just a key press being dispatched before the GUI finishes loading.  We should check after 0.0.8 if it still persists.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  There was a question from a student about the orientation, but it turns out its just because the object was rotated but the model that was previously being used made it difficult to tell. Closing as invalid.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This looks like its going to be tough to fix because Berkelium isn't getting WindowImpl::RequestOpenURL calls, which means that we in turn don't get WindowDelegate::onNavigationRequested calls (which aren't currently overridden in WebView, but which I added to test this).


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This bug should just be for getting the (real) bounding box of the object/mesh. #310 deals with raytracing.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 0352005705a06795171bf1506194380c76bd84fd. Has two modes, linear_dynamic for moving only linearly in all dimensions and vertical_dynamic for only moving vertically.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in bc66cea3641abf03dbbbe8eb2f14299f0a2b61b2. Turned out to be a combination of things: we weren't running the filters to be consistent with the way the client behaves (centering the mesh) and the CenterFilter was also broken, not handling globalTransforms properly.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed in a833537c01bc73764549132d1e7988788c8aed54, exposing both transformed (by the visible/presence) and untransformed (object space) bounding boxes.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  I have seen this one time, but not after closing. Instead, it was when the GUI was loading very slowly and I was able to click before all the GUIs finished loading because we don't block on all GUIs before proceeding to setup bindings, we only wait for the main graphics system to be finished.


author: ewencp
field: comment
oldvalue: 3
newvalue:
  As far as I can tell, 8ffcdc55ec6ecc4b195d07504f33bf36da20eeca should fix the only problem I could find here. There's no code path that allows this._ui to get reset, so this only seems to be possible on first load. That commit makes it so you can't click through until after the UIs, including the physics one, have finished loading.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  This is going to take quite a bit of effort to get right, see https://groups.google.com/d/topic/berkelium/HCecf3vKF4k/discussion. Basically, we'll never get easy support for intercepting these, at least not on any version of Chromium that Berkelium is close to using.  For now, we'll end up just trusting GUIs, since they are generally created by us or you accept them, but this will be left open so it doesn't get lost.


author: bmistree
field: comment
oldvalue: 1
newvalue:
  Fixed by 5b97d18.  All messages now in Emerson go over the reliable channel.  Eventually should re-expose unreliable messages to Emerson (cpp code still exists, but should actually expose callback to system).


author: bmistree
field: comment
oldvalue: 1
newvalue:
  Fixed with commit e92518.  We had been wrapping the string in a lot of extra quotes and doing excessive escaping that wasn't needed.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Did a little digging and it looks like Chrome has a pretty good example of how to manage OOP dump generation.  The dump generation is managed by a server, chrome's example is at http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/crash_service/ . We need to get that up and running and then we change our ExceptionHandlers (which wrap the CrashGenerationClient class) to talk to the server over a pipe rather than generate dumps in-process.  The server can be shutdown when it runs out of clients.

  I think the right approach is to make crashreporter handle this dump server functionality and then do the reporting, just as the Chrome crash_service does.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed in 4bc78c1b5c3be2a9078ce13bb28c95f0291efd6a by catching crashes, reloading, and providing callbacks to be notified when a reset occurred so we can reinitialize GUIs. Not the ideal solution (we'd prefer that the Berkelium renderer not crash), but should hopefully make things a lot more usable for long sessions.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Actually, so far it seems to be fine under OpenGL & DirectX on windows, but broken on Linux -- we may have to resort to moving back and forth between RAM and GPU there. Need to check on Mac as well.


author: bmistree
field: comment
oldvalue: 1
newvalue:
  Removed it from tutorials with commit f137cd7.  About to add a new tutorial ('managing presences') about self versus presences and how to create presences.


author: bmistree
field: comment
oldvalue: 1
newvalue:
  Fixed by commit #1a2db3f.  Before an entity received a message acknowledging connection of presence (and therefore providing firm position, sporef, mesh, etc.), that presence would receive a message from other presences in the space.  We weren't checking that the presence hadn't been fully connected to the space before trying to read these characteristics (which were essentially null data).


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in b04b7ae0a4aaa31b9b155d0a87877a754d3cd712, although it doesn't address problems with the camera needed the model orientation -- fixing #285 should let us fix that from within Emerson.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in f5d07e46477ee23ce4e118819526694c11f73826. Was actually due to not cleaning up properly in the main thread when there was no work left, resulting in another thread trying to access already deleted data.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed in 32d34db6d844b4aeb33173fbf48dde3881194ed1 by using a buffer in RAM and moving between the GPU and RAM. This is inefficient and we should fix it if the functionality gets fixed in Ogre, but is the only solution I could find for now.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 8cb5376a8e93f1a3de5b0a780cfeb3a86256a5a1 by providing a list of valid revisions. I think a better long term solution is to try to track the output and check if no symbols can be found, but this requires changing the system to process minidumps as soon as they're submitted so that information is available.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Closing this since we definitely can differentiate between the two -- they should be different key codes. On some restricted keyboards that overload keys using Fn keys, we may end up with duplicate keys because of the keyboards settings, but there's not much we can do about that. Also, I'm not getting a response from the original reporter about it anymore, so I can't tell if just the keycode is enough to differentiate on the machine that had a problem and another laptop does not exhibit the problem.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Seems to be an ordering problem -- the createProxyPtr seems to be called via some JS code during restore but is called from the onConnected code in the normal case.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Actually this turned out to be easier than I thought -- the ProxyCreationListener was being setup to late. Triggering an explicit onCreateProxy for the presence's own proxy fixed this. Fixed in 130ba2dcad78c0c7b8cb629be885df8e5921ddb1.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This is no longer valid since we exposed camera control directly to scripts via Invokable, so they can just set the position instead of having to use the interpolation previously provided by Ogre.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This actually looks like it *was* because of datagrams being used to send update requests (or at least mostly because of that). 48db16486e15abaaf6cd60c65bd52adcc0e348c1 seems to largely fix the problem by making these requests reliable (the space server still supports datagrams for backward compatibility), made much better by 2962729d69dec99c3a99b98e2e7b6d12526e9578, which makes retries faster when the initial packet fails. Longer term solution is a better send-last since reliable messages for all updates is overkill.

  I'll leave this open for now since bmistree said he observed a different problem, where updates got to the space server but not down to clients. He can close it if this seems to fix things for him as well.


author: ewencp
field: comment
oldvalue: 3
newvalue:
  Fixed in b4db195c6743f90f20151381a3e1004447d99753, at least in Windows which is where we really cared about it.


author: bmistree
field: comment
oldvalue: 3
newvalue:
  Fixed by #bbcfba599.  Syntax:

  var caps = new util.Capabilities(util.Capabilities.IMPORT,
                                   util.Capabilities.EVAL,
                                   util.Capabilities.CREATE_PRESENCE);

  var whichPresence = system.presences[0];
  var newContext = caps.createSandbox(whichPresence,null);


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 0b76098214bd6b658f6d6df8a85557e8afdee02b. No run scripts added, but as they only require adding an environment variable, its not a problem to manage running with the performance/heap monitoring manually.


author: jterrace
field: description
oldvalue:
  1. Bring up alt+s on an object
  2. system.set_script("system.import('std/default.em'); system.import('std/shim.em'); system.import('myScript.em');");
  3. system.reset();

  Produces this:


  [JS] ERROR: Uncaught exception:
  std/shim/system.em:842: TypeError: Object [object Object] has no method '__addToPresencesArray'
  system.__addToPresencesArray( presConn );
         ^
  TypeError: Object [object Object] has no method '__addToPresencesArray'
      at Object.<anonymous> (std/shim/system.em:842:8)
      at std/core/bind.em:33:13

  std/shim/system.em:842: TypeError: Object [object Object] has no method '__addToPresencesArray'
  system.__addToPresencesArray( presConn );
         ^
  TypeError: Object [object Object] has no method '__addToPresencesArray'
      at Object.<anonymous> (std/shim/system.em:842:8)
      at std/core/bind.em:33:13
  [OH] ERROR: Uh oh: this object connected twice 12345678-1111-1111-1111-defa01759ace:ff37a05c-1d43-47e0-92b1-58e39fb9e767
  Assertion failed: (it == mObjectInfo.end()), function add, file /Users/sns/ewencp/sirikata.git/liboh/src/SessionManager.cpp, line 76.
  Abort trap

newvalue:
  1. Bring up alt+s on an object
  2. system.set_script("system.import('std/default.em'); system.import('std/shim.em'); system.import('myScript.em');");
  3. system.reset();

  Produces this:



  {{{
  [JS] ERROR: Uncaught exception:
  std/shim/system.em:842: TypeError: Object [object Object] has no method '__addToPresencesArray'
  system.__addToPresencesArray( presConn );
         ^
  TypeError: Object [object Object] has no method '__addToPresencesArray'
      at Object.<anonymous> (std/shim/system.em:842:8)
      at std/core/bind.em:33:13

  std/shim/system.em:842: TypeError: Object [object Object] has no method '__addToPresencesArray'
  system.__addToPresencesArray( presConn );
         ^
  TypeError: Object [object Object] has no method '__addToPresencesArray'
      at Object.<anonymous> (std/shim/system.em:842:8)
      at std/core/bind.em:33:13
  [OH] ERROR: Uh oh: this object connected twice 12345678-1111-1111-1111-defa01759ace:ff37a05c-1d43-47e0-92b1-58e39fb9e767
  Assertion failed: (it == mObjectInfo.end()), function add, file /Users/sns/ewencp/sirikata.git/liboh/src/SessionManager.cpp, line 76.
  Abort trap
  }}}


author: bmistree
field: comment
oldvalue: 1
newvalue:
  Fixed in commit 41c644cb08.  I took the first approach described above.  It isn't nearly as flexible as the second one potentially could be.  The challenge for the time being is what to do with basic types, especially considering that we don't have the +/- symbol available to us when defining the potential .add and .minus functions.  I may eventually revisit this decision.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  This turns out to be an issue only if the files are in a subdirectory, i.e. if you have scripts/foo/test1.em and scripts/foo/test2.em. The information about which directories to search is lost when you hit the callback, causing it to fail to find test2.em.

  We'll close this as invalid for now since fixing this would require some fundamental changes in how we maintain callbacks and import path state (we'd have to store a copy with every callback function).


author: bmistree
field: comment
oldvalue: 1
newvalue:
  Fixed with commit #94d65f1.  Had been always re-firing timer after callback.  Added logic to check if had requested suspend from within callback.

  Additionally, pass repeating timer back in callback.


author: bmistree
field: description
oldvalue: Also, have the calls drop into javascript instead of doing the computations in cpp.
newvalue:
  Vecs and quaternions now have these operators (and !=, ===, !==) overloaded.  If notice that things are getting slow, may eventually want to call into javascript to prevent overhead of calling back to cpp.  Can either do this in the compiler or by allowing us to execute js lines.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  This is due to NaNs. We should try to catch them and cancel the operation. If you checkout a684573423f8cee2ac79b8bcb042b3538d3029a9 it should be able to trigger this same problem with this script.


author: bmistree
field: comment
oldvalue: 2
newvalue:
  Fixed by commit #f60a00c9.  Running 20 timers firing at 100 Hz for > 30 minutes, while variously permuting clear calls, etc. didn't produce any errors, and kept memory usage relatively low.  I'm pretty sure it's fixed.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed with merge cfdefe405c7d692e841b2bb77d0f4b474c6abb4b. Doesn't support data URIs, but http support was added in the process.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Fixed in 891aa6ec863b65895175286bf2a0d21eb1b0c532 by naming meshes by the hash of all hashes they refer to (the original mesh + textures).


author: bmistree
field: comment
oldvalue: 2
newvalue:
  Closed by commit #461ce4c15.  I re-ran the scripts that were causing the problem ~20 times after this, and didn't see the problem again.  In at least one case, looking through all my print statements, I think that the fix avoided what would have been a problem without the sequence numbers.  

  The problem was that the object host had no way of determining ordering between prox additions and removals and loc updates.  In some cases, a prox removal would wipe out the information from the last loc update, then a prox addition would occur, then an old loc update would occur, causing the system to read old loc data.


author: bmistree
field: comment
oldvalue: 2
newvalue:
  I think that Ewen fixed this with commit 2fb82ef.  (I had using internal jstimer data after it should have been deleted.)


author: bmistree
field: comment
oldvalue: 2
newvalue:
  Fixed by commit #897097f.  Added @namespace to top of util file.  Also, removed @namespaces from vec3.em and quaternion.em files to prevent their constructors from being overwritten in the documentation.  Should see vec3, etc. documentation in next automatic build of documentation.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  I think this was actually a problem with restoration due to multiple callbacks, some (falsely) indicating failure, resulting in a bad presence being stored back to the database. I believe a5c5c0b427005588003c7b73319351139a98d954 has fixed this. If I don't see this for a few more days I'll close this bug.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  I audited all the protocols and except for one internal Migration message, all uses of strings appear to be correct. The migration messages should only be between space servers, so shouldn't be the trigger of this bug report.

  I especially looked into JSMessages since the report was about port 12, which is used by the js plugin. Still nothing popped up, and I also verified we were extracting UTF-8 strings from V8 when we encode strings in the serialization code, or they originate from code which is only generating UTF-8 (e.g. SpaceObjectReference::toString()).

  Commit 10e5ebf2f3fb2fa6396a12d2c86f0d77a8011344 addresses the issues mentioned above. As far as I can tell, there isn't a problem with cppoh. I'm closing as invalid, reopen if you can actually pin it down to something testable. Currently there's not enough useful information to even verify this bug.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 1f45e0d42e3349e2b8955f50750589a0fa79477e. The script won't be executed if the presences can't be restored properly.


author: ewencp
field: comment
oldvalue: 2
newvalue:
  Besides the problems wither restoration, this actually appears to just be a timing issue -- if you kill cppoh too quickly not all objects will have finished connecting (they may appear in world, but are still working on building SST streams) and so won't have written their presences. They appeared in the PersistedObjectSet but had not stored any presence data.


author: ewencp
field: comment
oldvalue: 1
newvalue:
  Fixed in 428242ad0ae014d1adc2902253eecec30155f342 by diverting the callback due to migrations to onMigrated instead of onConnected.


author: bmistree
field: comment
oldvalue: 3
newvalue:
  Should be closed by commit 3096f50.  Can call system.sendSandbox to send sandboxes messages.  Can call system.registerSandboxMessageHandler to register a callback for particular sandbox messages.  No special syntax is currently enabled for sandbox messages.


# milestone

name: Public Alpha Release
description:
  We need a version of Sirikata that is easily buildable for new developers and runnable by average users to experience a particular virtual world we have made.

  Bugs that increase build usability or end-user usability but are not required for project-specific deliverables should be targeted to this release.


name: Multi-server Chat Demo
description:
   * Chat world ( running multiple space servers)
   * Multiple entities running on different entity hosts connect to this Chat world 
   * The entities talking are connected to the world using emerson script ( waiting on Behram's merge for it )
   * Entity A, once connected and gets a presence in the world, should be getting proximity events. Entities should register to these proximity events through Emerson.
   * Entities update their working set when they get updates on the proximity events. When Entity discovers a new entity, it has to perform a handshake in order to be sure that this new entity actually speaks the chat protocol. ( This is required because we may be having trees/rocks ).
   * The chat message is multicasted to the working set of the entity.


# report

title: Active Tickets
description:
  * List all active tickets by priority.
  * Color each row based on priority.

query:
  SELECT p.value AS __color__,
     id AS ticket, summary, component, version, milestone, t.type AS type, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t
    LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
    WHERE status <> 'closed'
    ORDER BY 1*p.value, milestone, t.type, time


title: Active Tickets by Component
query:
  SELECT p.value AS __color__,
     component AS __group__,
     id AS ticket, summary, component, version, t.type AS type, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t
    LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
    WHERE status <> 'closed'
    ORDER BY (component IS NULL),component, 1*p.value, t.type, time

description:
  This report shows how to color results by priority,
  while grouping results by version.

  Last modification time, description and reporter are included as hidden fields
  for useful RSS export.


title: Active Tickets by Milestone
query:
  SELECT p.value AS __color__,
     'Milestone '||milestone AS __group__,
     id AS ticket, summary, component, version, t.type AS type, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t
    LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
    WHERE status <> 'closed' 
    ORDER BY (milestone IS NULL),milestone, 1*p.value, t.type, time

description:
  This report shows how to color results by priority,
  while grouping results by milestone.

  Last modification time, description and reporter are included as hidden fields
  for useful RSS export.


title: Accepted, Active Tickets by Owner
description: List accepted tickets, group by ticket owner, sorted by priority.
query:
  SELECT p.value AS __color__,
     owner AS __group__,
     id AS ticket, summary, component, milestone, t.type AS type, time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t
    LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
    WHERE status = 'accepted'
    ORDER BY owner, 1*p.value, t.type, time


title: Accepted, Active Tickets by Owner (Full Description)
query:
  SELECT p.value AS __color__,
     owner AS __group__,
     id AS ticket, summary, component, milestone, t.type AS type, time AS created,
     description AS _description_,
     changetime AS _changetime, reporter AS _reporter
    FROM ticket t
    LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
    WHERE status = 'accepted'
    ORDER BY owner, 1*p.value, t.type, time

description:
  List tickets accepted, group by ticket owner.
  This report demonstrates the use of full-row display.


title: All Tickets By Milestone (Including closed)
description: A more complex example to show how to make advanced reports.
query:
  SELECT p.value AS __color__,
     t.milestone AS __group__,
     (CASE status 
        WHEN 'closed' THEN 'color: #777; background: #ddd; border-color: #ccc;'
        ELSE 
          (CASE owner WHEN $USER THEN 'font-weight: bold' END)
      END) AS __style__,
     id AS ticket, summary, component, status, 
     resolution,version, t.type AS type, priority, owner,
     changetime AS modified,
     time AS _time,reporter AS _reporter
    FROM ticket t
    LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
    ORDER BY (milestone IS NULL), milestone DESC, (status = 'closed'), 
          (CASE status WHEN 'closed' THEN changetime ELSE (-1) * 1*p.value END) DESC


title: My Tickets
query:
  SELECT p.value AS __color__,
     (CASE status WHEN 'accepted' THEN 'Accepted' ELSE 'Owned' END) AS __group__,
     id AS ticket, summary, component, version, milestone,
     t.type AS type, priority, time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t
    LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
    WHERE t.status <> 'closed' AND owner = $USER
    ORDER BY (status = 'accepted') DESC, 1*p.value, milestone, t.type, time

description:
  This report demonstrates the use of the automatically set 
  USER dynamic variable, replaced with the username of the
  logged in user when executed.


title: Active Tickets, Mine first
query:
  SELECT p.value AS __color__,
     (CASE owner 
       WHEN $USER THEN 'My Tickets' 
       ELSE 'Active Tickets' 
      END) AS __group__,
     id AS ticket, summary, component, version, milestone, t.type AS type, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t
    LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
    WHERE status <> 'closed' 
    ORDER BY (owner = $USER) DESC, 1*p.value, milestone, t.type, time

description:
   * List all active tickets by priority.
   * Show all tickets owned by the logged in user in a group first.


title: Active Tickets by Milestone (latest changes first)
description: Active Tickets by Milestone (latest changes first)
query:
  -- ## 11: Active Tickets by Milestone (latest changes first) ## --

  SELECT p.value AS __color__,
     milestone||' Release' AS __group__,
     id AS ticket, summary, component, version, t.type AS type, severity, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE status <> 'closed' 
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY (milestone IS NULL),milestone, _changetime DESC, p.value, severity


title: Active Tickets, Open Contest
query:
  SELECT p.value AS __color__,
     (CASE owner 
       WHEN $USER THEN 'My Tickets' 
       WHEN 'ewencp' THEN 'Ewens Tickets' 
       WHEN 'danielrh' THEN 'Daniels Tickets' 
       WHEN 'PatrickHorn' THEN 'Patricks Tickets' 
       ELSE 'Active Tickets' 
      END) AS __group__,
     id AS ticket, summary, component, version, milestone, t.type AS type, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t
    LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
    WHERE status <> 'closed' 
    ORDER BY (owner <> $USER AND owner <> 'ewencp' AND owner <> 'danielrh' AND owner <> 'PatrickHorn'), (owner <> $USER AND owner = 'danielrh'), (owner <> $USER AND owner = 'ewencp'), (owner <> $USER AND owner = 'PatrickHorn'), owner = $USER DESC, 1*p.value, milestone, t.type, time

description:
   * List all active tickets by priority.
   * Show all tickets owned by the logged in user in a group first.


title: Closed Tickets, Scoring round
query:
  SELECT p.value AS __color__,
     (CASE owner 
       WHEN $USER THEN 'My Tickets' 
       WHEN 'ewencp' THEN 'Ewens Tickets' 
       WHEN 'danielrh' THEN 'Daniels Tickets' 
       WHEN 'PatrickHorn' THEN 'Patricks Tickets' 
       ELSE 'Active Tickets' 
      END) AS __group__,
     id AS ticket, summary, component, version, milestone, t.type AS type, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t
    LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
    WHERE status == 'closed' 
    ORDER BY (owner <> $USER AND owner <> 'ewencp' AND owner <> 'danielrh' AND owner <> 'PatrickHorn'), (owner <> $USER AND owner = 'danielrh'), (owner <> $USER AND owner = 'ewencp'), (owner <> $USER AND owner = 'PatrickHorn'), owner = $USER DESC, 1*p.value, milestone, t.type, time

description:
   * List all active tickets by priority.
   * Show all tickets owned by the logged in user in a group first.


