Hi Erin, Really good to hear that you've got passed your issue with getting narrow strings into Python and NuPIC. In the whole, NuPIC is fairly robust with narrow string passing. Down the line wider string format support could be added, but that is likely to be use-case specific in the initial instance. With community support required to assist with such an engineering tasks, if required.
I don't recall any issues, similar to your findings, when porting NuPIC to Windows. Within the unit and integration tests, and the more thorough and extensive Numenta Anomaly Benchmark (NAB) tests, the checkpoint load and saving performed well. NuPIC makes extensive use of Python file handling to cope with variation across operating systems. Whether some form of checkpoint resource handling issue exists just on Windows is difficult to tell, and certainly sounds like a further integration test is required to check for checkpoint resource management failures and/or dangling file handles, across all operating systems. It's certainly possible that some assumptions have been made with checkpoint load and saving that Numenta engineers could help discover or know? It'd be great to discover a consistent method to recreate the exceptions you see there, to then work up into a unit/integration test to add to NuPIC. Best regards, Richard. On Fri, Feb 12, 2016 at 5:10 PM, Erin Loy <[email protected]> wrote: > I've worked thorough this issue. The COM wrapper was passing in a BSTR > object, which behaves a lot like a string in python, except with code that > cares about type, such as (I assume) the bindings to the nupic core library > that are using the object type to find the right overloaded function > signature. Wrapping it in str() resolved the issue. > > If anyone knows how to craft IDL that will map to a native python string, > that would be a nice improvement. (It might be as simple as using "char *" > instead of BSTR.) > > For anyone that's interested in using nupic from another language on > Windows, I've posted my simple COM wrapper to the project below. I plan to > add a C# client example in the near future. > https://github.com/erinloy/nupic_bridge > > Richard, there's currently a hack around the save() function that saves to > a temp location first, and then copies to the primary location. I've found > that save() fails every once in a while (from memory, I think it was > something like an access denied or file in use error - sorry I don't have > more detail at the moment). When saving every n iterations of a loop, it's > frustrating to loose work randomly, so I made it eat the exception and only > disrupt the previously saved files on success. This is something you might > want to follow up on (unless it's just happening to me?) > > Matt, regarding the HTIC project, I've normalized the views_api.py line > endings for you. However, I wouldn't recommend pulling any of that code > back to the main project. It was my first experience working with both > python and nupic, so it's quite likely I did some things *very* wrong. The > reason I dove into the code in the first place was that it was focused on > anomalies, and didn't return useful details about predictions. I added the > prediction bits, and later extended with metrics and time shifting (which I > think was not correctly implemented). I'm not actively working on that > code anymore, but it's still probably worth a look, if only to understand > the spirit of it. > https://github.com/nupic-community/hitc/compare/master...erinloy:master?w=1 > > Best, > -Erin > > On Wed, Feb 10, 2016 at 12:46 PM, Richard Crowder <[email protected]> > wrote: > >> Hi Erin, >> >> As you've seen with a native Python application, the loading and saving >> of pickled model checkpoint files does currently work. An example is the >> opf integration test called opf_checkpoint_stress_test.py >> >> You're calling the loadFromCheckpoint correctly to use the pickled (.pkl) >> form for saving and loading (using the default 'newSerialization=False'). >> I'm guessing that you have tried loading checkpoint'd model directory files >> in a native Python app, and that works? >> >> It's difficult to tell without seeing more of the exception output where >> inside loadFromCheckpoint hierarchy the failure you're seeing is. Can you >> supply more of that output? >> >> My first though was towards malformed/relative network share URI(s). Is >> the model checkpoint directory on a network drive? >> >> Regards, Richard. >> >> On Wed, Feb 10, 2016 at 6:18 PM, Matthew Taylor <[email protected]> wrote: >> >>> Erin, >>> >>> First of all, kudos to you, brave Windows developer, for getting NuPIC >>> up and running in your development environment! Please document your >>> progress and problems if you can, because we'd like to try to make this >>> easier for all Windows users. This is of course an ongoing problem. >>> >>> Also, thanks for trying out HITC and making changes to enable >>> predictions. However it is hard to tell what you've done in the comparison >>> [1] because of the Windows line breaks :P. In any case, I believe that HITC >>> can provide predictions if different model params are used that specify >>> that "inferenceType" in them. I don't think any code changes are necessary. >>> That's probably a different discussion, so if you have any input, let's >>> please communicate via Github Issues [2]. >>> >>> Regarding the model load error you are getting, I'm not sure that any of >>> us have tested model serialization on Windows just yet. You may be the >>> pioneering engineer (pioengineer?) who's first run into this problem. I >>> will have to defer to Richard Crowder and Marion LeBorgne, who've been >>> running NuPIC on Windows lately. I will make sure they see this message. >>> >>> [1] >>> https://github.com/nupic-community/hitc/compare/master...erinloy:master >>> [2] https://github.com/nupic-community/hitc/issues >>> >>> Thanks for trying NuPIC! >>> >>> >>> --------- >>> Matt Taylor >>> OS Community Flag-Bearer >>> Numenta >>> >>> On Wed, Feb 10, 2016 at 9:25 AM, Erin Loy <[email protected]> >>> wrote: >>> >>>> Hi Everyone, >>>> >>>> I'm using nupic\opf from C# on Windows (Thanks for doing the work to >>>> make this possible!). I have a simple console app for testing, and an >>>> add-in extension for another larger commercial application. >>>> >>>> I've experimented with a few RPC/bridging approaches: >>>> >>>> - Web service (a branch of "htic" project, hacked up to support >>>> predictions - *probably broke anomalies though*): works well, but >>>> request/response slows everything down (it's not very clean, but you can >>>> get the gist here: >>>> https://github.com/erinloy/hitc/blob/master/htm-over-http/htmoverhttp/views_api.py >>>> ) >>>> >>>> - Python.NET (wrapper for accessing .NET from native python, or in my >>>> case, embedding native python in a .NET app: >>>> https://github.com/pythonnet/pythonnet): Works in the console app >>>> (after a lot of hacking on the python environment), but chokes on the code >>>> obfuscation in the parent app when trying to discover the contents of all >>>> loaded assemblies. Probably not a good idea to mix technologies in the >>>> same process - too many bad interactions. >>>> >>>> - A regular Windows COM server (via python comtypes library): This was >>>> easy to build, performs well, and seems to play nice with everything else >>>> by keeping processes separate, and can be extended for remote access if >>>> needed. I'll probably end up sticking with this option. >>>> >>>> In all cases, I can create a model, run data through it, get >>>> predictions back, and save it at checkpoints. However, the latter two >>>> options (not sure if I tried it with the web service option) give me an >>>> error when trying to load a saved model: >>>> >>>> Code: >>>> def load_model(self, modelSaveDir): >>>> print "Loading model from %s..." % modelSaveDir >>>> model = ModelFactory.loadFromCheckpoint(modelSaveDir) >>>> >>>> Error: >>>> Wrong number or type of arguments for overloaded function 'new_Network'. >>>> Possible C/C++ prototypes are: >>>> nupic::Network::Network() >>>> nupic::Network::Network(std::string const &) >>>> >>>> This works when running from native python (via a hacked up onegym >>>> sample). >>>> The latest version of Nupic was installed via pip. >>>> >>>> Thoughts? >>>> >>>> -Erin >>>> >>> >>> >> >
